Research

A couple years ago Brian Sullivan of Microsoft demonstrated blind SQLi and server-side JavaScript injection attacks on Mongo, Neo4j, and other big data engines, but this is the first time I have seen someone get a shell and bypass ASLR. From the SCRT Information Security Team Blog, they found an 0-day to do just that: Trying some server side javascript injection in mongodb, I wondered if it would be possible to pop a shell. … nativeHelper is a crazy feature in spidermonkey missused by mongodb: the NativeFunction func come from x javascript object and then is called without any check !!! … This feature/vulnerability was reported 3 weeks ago to 10gen developers, no patch was commit but the default javascript engine was changed in last version so there is no more nativeHelper.apply function. A metasploit module is comming soon… Go read the post! They laid out their work step by step, so it’s easy to see how they performed their analysis and tried different tweaks to get this to work. A side note to NoSQL vendors out there: It may be time for some of you to consider a bug bounty program on commonly used components – or maybe throw some money SCRT’s way? Nice work, guys. A big “thank you” to Zach (@quine) for spotting this post and bringing it to our attention! Share:

What happened to the guru? The magician? The computer expert at your company who knew everything. I have worked at firms that had several who knew IT systems inside and out. They knew every quirky little trick of how applications worked and what made them fail, and they could tell you which page of the user manual discussed the exact feature you were interested in. If something went wrong you needed a guru, and with a couple keystrokes they could fix just about anything. You knew a guru by their long hair, shabby dress, and the Star Trek paperback in their back pocket. And when you needed something technical done, you went to see them. That now seems like a distant memory. I have lately been hearing a steady stream of complaints from non-IT folks that IT does not respond to requests and does not seem to know how to get out of their own way. Mike Rothman recently made a good point in The BYOD problem is what? BYOD is not a problem because it’s already here and is really useful. Big Data is the same. Somewhere along the line business began moving faster than IT could keep up. Users no longer learn about cool new technologies from IT. If you want a new Android or iPad for work, you don’t ask IT. You don’t ask them about “the cloud”. You don’t consult them about apps, websites, or even collecting credit card payments. In fact we do the opposite – we see what our friends have and what our kids are doing, Google what we need to know, and go do it! The end-run around IT is so pervasive that we have a term for it: Rogue IT. Have credit card, will purchase. How did the most agile and technically progressive part of business become the laggard? Several things caused it. High-quality seamless rollouts of complex software and hardware take lots of time. Compliance controls and reports are difficult to set up and manage. It takes time to set up identity and access management systems to gate who gets to access what. Oh, and did I mention security? When I ask enterprise IT staff and CISOs about adoption of IaaS services, the general answer is “NO!” – none of the controls, systems, and security measures they rely on are yet fully vetted, or they simply do not work well enough. The list goes on. Technologies are changing faster than they can be deployed into controlled environments. Their problems are not just a simple download away from being addressed, and no trip to the Apple Store will solve them. It’s fascinating to watch the struggle as several disruptive technologies genuinely disrupt technology management. On to the Summary: Webcasts, Podcasts, Outside Writing, and Conferences Adrian’s DR paper: Security Implications Of Big Data. Rich quoted on Watering Hole Attacks. Gunnar’s DR Post: Your Password Is The Crappiest Identity Your Kid Will Ever See. Favorite Securosis Posts Mike Rothman & Adrian Lane: When Bad Tech Journalism Gets Worse. Totally ridiculous. The downside of page view whores in all its glory. Certainly wouldn’t want a fact to get in the way of the story… Other Securosis Posts Services are a startup’s friend. New Paper: Email-based Threat Intelligence. Who comes up with this stuff? The World’s Most Targeted Critical Infrastructure. DHS raises the deflector shields. Incite 3/20/2013: Falling down. If you don’t know where you’re going… When Bad Tech Journalism Gets Worse. The Right Guy; the Wrong Crime. New Job Diligence. Preparation Yields Results. The Dangerous Dance of Product Reviews. Limit Yourself, Not Your Kids – Friday Summary: March 15, 2013. Ramping up the ‘Cyber’ Rhetoric. Favorite Outside Posts Adrian Lane: Firefox Cookie-Block Is The First Step Toward A Better Tomorrow. Mike Rothman: Indicators of Impact. Kudos to Russell Thomas for floating an idea balloon trying to assess the impact of a breach. I’ll do a more thorough analysis over the next week or so, but it’s a discussion we as an industry need to have. Project Quant Posts Email-based Threat Intelligence: To Catch a Phish. Network-based Threat Intelligence: Searching for the Smoking Gun. Understanding and Selecting a Key Management Solution. Building an Early Warning System. Implementing and Managing Patch and Configuration Management. Defending Against Denial of Service (DoS) Attacks. Securing Big Data: Security Recommendations for Hadoop and NoSQL Environments. Tokenization vs. Encryption: Options for Compliance. Top News and Posts Critical updates for Apple TV and iOS available Ring of Bitcoins: Why Your Digital Wallet Belongs On Your Finger Subway Hit By The Ultimate Cyberthief Inside Job: A Double-Insider. Two opportunities to vet – both failed. Cisco switches to weaker hashing scheme, passwords cracked wide open Why You Shouldn’t Give Retailers Your ZIP Code Microsoft, Too, Says FBI Secretly Surveilling Its Customers The World Has No Room For Cowards. Krebs ‘SWATted’ in case you missed it. On Security Awareness Training Gravatar Email Enumeration in JavaScript. Clever. Spy Agencies to Get Access to U.S. Bank Transactions Database Blog Comment of the Week This week’s best comment goes to Dwayne Melancon, in response to New Job Diligence. Good advice, Mike. Surprised at how many people don’t look before they leap. If you apply some of your own “social engineering for personal gain” to this, you can avoid a lot of pain. Mining LinkedIn is a great shortcut, assuming the company you’re investigating has a decent presence there. Not only can you talk with specific people (including the ones who’ve left, as you mentioned), you can get a feel for whether there is a mass exodus going on. If there is, it can be a sign of a) opportunity b) Hell, or c) both. But at least you know what you’re getting into. Share:

All you IT professionals out there who want to divert attention, give your exec’s a warm and fuzzy feeling you’re saving money and making you’re users experience better, just do what the DHS did. Margaret Graves, DHS deputy CIO, pulled a page from Star Trek and flummoxed Congress with some Techno-Babble. From [Network World](http://www.networkworld.com/news/2013/032013-dhs-shifting-to-cloud-agile-267910.html): > At a hearing before the House Committee on Homeland Security on Tuesday, a DHS IT official gave lawmakers an overview of agile development methodologies, one of the tools that the department is using to fix its IT project management. Agile came up after U.S. Rep Ron Barber (D-Ariz.), a former staffer in Rep. Gabrielle Gifford’s office who won that seat after Giffords resigned, asked what DHS was doing to ensure that its IT systems met user needs. Margaret Graves, DHS deputy CIO, said the department is using agile methodologies to create user stories to help shape the systems. In agile development, user stories can be short and informal descriptions of some of the functions users would like to see. She blinded him with science! Throw out a ‘solution’ that sounds good, which lots of people ‘in the know’ approve of, but it too esoteric or complex for critics to understand. In this case it’s Agile development on Cloud resources tuned by User Stories. It’s a red-herring trifecta! I’d be a hypocrite if I said I’d not used this IT-Judo technique before. It works! It always worked on Star Trek. Get in trouble and just re-phase the shield generators and send out a broad spectrum particle beam to detect cloaked vessels. Just so happens the technique works in real life too. All kidding aside – Agile is a great development _process_ as the approach forces simplification of grand projects into simple tasks. And it intrinsically offers the benefits that you are always be working on the most important part of the project – or at least a portion that can be delivered within the coming sprint. But Agile pushes a lot of the burden of successful implementation onto the project manager. PM’s take more control over product and service enhancements, really steering the course of development through prioritization. But _if your product management already sucks, you’ll still fall off the tracks with Agile_. You’ll just do it faster. Dare I say faster than an anti-matter explosion from a warp core breach. And if you don’t understand what that means, fear not, neither does U.S. Representative Ron Barber (D-Ariz.). Chalk one up for Ms. Graves of the DHS. Share:

The Nibble security blog had a very good post on Subverting a Cloud-based Infrastructure with XSS and BEEF. They essentially constructed an XSS attack to issue network infrastructure management commands without user knowledge. The idea is pretty neat: all network devices and security appliances (wired and wireless) can be managed by a cutting-edge web interface hosted in the cloud, allowing Meraki networks to be completely set up and controlled through the Internet. Many enterprises, universities and numerous other businesses are already using this technology. As usual, new technologies introduce opportunities and risks. In such environments, even a simple Cross-Site Scripting or a Cross-Site Request Forgery vulnerability can affect the overall security of the managed networks. There are two important takeaways here, so don’t get caught up with a specific vendor’s vulnerabilities or the specific tool used to craft this attack. The management interfaces for all cloud services are browser-accessible, and browsers – and the web services they use – are open to these attacks. XSS and CSRF are major issues, and we have considerable evidence – the Mandiant report being just one source – that browser-based attacks are one of the top two current attack vectors. These are problems that most organizations don’t consider when building web applications, so they are common vulnerabilities. Which leads directly into the second issue: that all cloud services, by definition, offer broad network access. That means applications and management interfaces are both browser accessible. The beauty of cloud services for IT management is that you can access all cloud management functions from any browser, anywhere. And from that single connection you do just about anything. Very convenient! For attackers too – once they compromise a customer’s management plane for a cloud service, that is equivalent to root access. Only in this case it’s the entire cloud infrastructure, not just one server. Because the attack originates from your browser, it does not matter whether you restricted management access to in-house IP addresses – your system has one of the approved IP addresses. There are not many quick and easy ways to protect against this type of attack, but use a dedicated browser for management if you can. Other than that … be careful what you surf for. Share:

Thales released a 2012 survey on encryption spending trends today. In a nutshell, spending was up a modest amount for the first time in several years. From the Deep Dive post: estimated total spending on encryption by all sectors grew by 2.5 percent from 2011 to 2012, one of the biggest jumps in the eight years the survey has been conducted. Thales released the “2012 Global Encryption Trends Study” today. The Ponemon Institute of Traverse City, Mich., surveyed 4,205 individuals on Thales’ behalf. The spending figures were particularly interesting to Thales: “This last year we saw one of the biggest hikes in budgets that we’ve seen for the last seven years or so,” said Thales e-Security’s Richard Moulds, vice president of product strategy. In 2011, businesses and governments spent 15.1 percent of their information technology security budget on encryption. The number jumped to 17.6 in 2012. A couple things to note about this information. For security products not driven by compliance (like PCI) or vulnerabilities that totally disrupt IT (think SQL Slammer), sales typically grow at a rate of 2-3% a year. From our conversations with companies of all sizes, use of encryption is up across the board. However, adoption is mostly for new projects, rather than expansion of existing installations. And in many cases developers are the ones who select free or open source encryption products, not commercial products. They do this so the development process is not burdened by having to get budget or deal with sales droids. This means spending does not go up at the same rate that usage goes up. Still, the encryption market has not seen the sales growth we would otherwise expect – instead people invest in better key management services, or in alternatives to encryption (e.g. tokenization, masking) to protect data. It’s a growing market, but buyers are cautious about how and where they spend their money. Share:

With our last post in this series on Understanding and Selecting Cloud Identity and Access Management, we want to help guide you through product selection. No two customer environments or lists of requirements are the same, but key decision criteria will help you narrow down the field to suitable platforms. We will provide questions to help determine which vendors offer solutions that fit your architecture, a set of criteria to measure the appropriateness of a vendor solution to your design goals, and help walk you through the evaluation process. Your mileage WILL vary Spoiler alert – there’s no such thing as plain vanilla IAM. You may need a solution for customers as well as users. You may or may not need to include mobile devices. You may need fine-grained authorization controls for external applications. There are far too many variables in play for IAM evaluation to be fully quantifiable. But to help you weed out some players, to align your needs with product function, and to give you a handle on major product differentiators, we created the table below. You need to make sure products match your goals. Even IAM suites that can do everything on paper have their own strengths and weaknesses, so make sure you know them before leaping in. As we have discussed, prospective buyers should start with understanding their use cases and governance processes before analyzing the IAM marketplace. That said, here is a proposed checklist for beginning to analyze IAM products: Product Architecture What are the product’s key capabilities? What are the internal data models and formats for identity? What are the external data models and formats for identity? How does the product scale, vertically or horizontally? Development What is the development interface for implementing and extending the product? Is development typically performed by the company or third party consultants? Answer for both development and maintenance phases. What integration is available for source code and configuration management? What languages and tools are required to extend the product by with wrappers, adapters, and extensions? Interoperability What IAM standards are supported and where are they available in the product? What interfaces are standards based and what are proprietary? What directories are supported – Active Directory, LDAP …? What application servers are supported – Websphere, IIS, Tomcat, SAP …? Are cloud applications supported? Which ones? Are mobile platforms supported? Which ones? Product Security What is the product security model? Is Role-Based Access Control supported? Where? How is access audited? Use Case Support Describe the product’s support for provisioning uses Describe the product’s support for Singe Sign On uses Describe the product’s support for attribute exchange use cases What user self-service capabilities does the product support? Cost Model How is the product licensed? Does cost scale based on number of users, number of servers, or something else? What is the charge for adapters and extensions? This checklist provides a starting point for analyzing IAM products. As the evaluation unfolds, it is key to remember what matters: integration, standards, and cost. The buying process works much better if the initial step includes an inventory of IAM sources and targets: where identity is used, and what the authoritative sources are. What IAM processes exist currently, and which and are desired in future? POC FTW Securosis highly recommends a Proof-of-Concept (POC) as a final step for IAM buyers. PowerPoint does not crash much, but new implementations do. There is nothing like seeing a product working in your own environment. If there is more than one vendor in play – and there usually is – then bake-offs can be useful to determine the best fit. But we generally do not recommend bake-offs with more than two vendors. Many vendors take widely different conceptual approaches to IAM problems, and in-depth evaluations are too demanding to perform more than once or twice. Start with an initial review, against our checklist, to weed out unsuitable candidates. Then use a proof of concept to test viability and/or a bake-off to compare a couple similar candidates. Share:

I think I’m finally waking up. After a week at RSA where I basically don’t sleep – not all bad, mind you – it takes a while to recover. In fact Monday might as well not have happened – I certainly got nothing done. It was not for lack of trying, but I was simply part of the zombie apocalypse – but I don’t want brains, just some Captain Crunch and sleep. Today I had the ‘Oh crap!’ realization – I promised people things last week, and I need to deliver. As much as I’d like to shuffle this stuff onto Rich, he has got a new baby and won’t take my calls. Something about taking it easy and enjoying time with the family. On the subject of the RSA Conference, I have to confess I’m not usually surprised by trends at RSA. If you read out pre-RSAC stuff, you noticed it was clear to us that Big Data and malware were going to take center stage, and those trends did not disappoint. But we are never quite sure whether we are going to run into grumpy vendors spewing forth about their dissatisfaction with foot traffic, booth space, and the lack of quality leads. This year … none of that. In fact most vendors told me traffic was up and, more importantly, prospects were seeking them out. They were happy. It certainly made the week a lot more fun, but happy are a bit like Mike Rothman’s smile – rare and it makes me nervous. The other thing that really surprised me was that every single vendor seemed to be asking for help locating talent. Penetration testers, product managers, marketing managers, engineering managers, researchers – you name it. But I am not aware of any seasoned security people who are looking – quite the opposite. I did not anticipate the security industry hiring so heavily, but that’s a good thing, and another sign that things are humming along. Let the good times roll. You know what else surprised me? The force field surrounding the Huawei booth. Okay, maybe there was no actual force field, but people walking the show floor acted like there was. They kept a curious 2-3’ distance from the booth. Maybe their schwag sucked. Or perhaps it was Huawei’s lack of booth babes. Or maybe people are pissed about the Mandiant report and think of Huawei as part of that whole fiasco. I don’t really know, but most vendors were humming with activity, yet the half-dozen times I went by their booth they were noticeably un-busy. –Adrian On to the Summary: Webcasts, Podcasts, Outside Writing, and Conferences Our own ‘Mark’ Rothman’s DR post: You’re A Piece Of Conference Meat. snort Adrian’s Pragmatic Database Security Presentation. Favorite Securosis Posts Adrian Lane: Karmic Balance. I have witnessed 25 years of shenanigans, and it has turned out that most wrongs met their karmic opposite at some point. David Mortman: Flash! And it’s gone…. Mike Rothman: Karmic Balance. Yeah, I’m a homer for favoriting my own Incite this week. But it sums up what I’m about. Like most folk I have been scarred and battered and bruised. But I try to make those negatives into positives whenever I can. Other Securosis Posts Understanding Cloud IAM: Buyers Guide. Use cases are your friends. Isolating the Security Skills Gap. Be Careful What You Wish for…Now You’re CISO. Announcing the CCSK UK Train the Trainer Class in April. New Paper: Network-based Threat Intelligence. Friday Summary, RSA Edition: March 1, 2012. Favorite Outside Posts Dave Lewis: Time Stamp Bug in Sudo Could Have Allowed Code Entry. Gunnar: Google services should not require real names – Vint Cerf. Two years back Bob Blakley brought us on a quick tour of the weak points of Google requiring real names, in a word: insane. Adrian Lane: Creating and Validating a Sock Puppet. Everyone should have a couple of these. They come in handy. David Mortman: Barn Doors. “Mobile is just an amplification of all the insecure practices you and your company have been using for decades.” – Sing it, sister! Mike Rothman: Cisco CEO: We’re All In On Internet Of Everything. In the NSS (No Sh*t Sherlock) list this week, Cisco decides it’s in their best interest to drive “The Internet of Things.” Duh. But as we wrote in the RSAC Guide, the Internet of Things is something to keep an eye on. Check it out for the hype, but stay around because there will be all sorts of devices connecting to your stuff. Project Quant Posts Network-based Threat Intelligence: Searching for the Smoking Gun. Understanding and Selecting a Key Management Solution. Building an Early Warning System. Implementing and Managing Patch and Configuration Management. Defending Against Denial of Service (DoS) Attacks. Securing Big Data: Security Recommendations for Hadoop and NoSQL Environments. Tokenization vs. Encryption: Options for Compliance. Pragmatic Key Management for Data Encryption. Top News and Posts Appsec at RSA 2013: nice recap. Oracle Issues Emergency Java Update via Krebs. Details of the February 22nd 2013 Windows Azure Storage Disruption HP Exec: We’re Investing $1 Billion in Big Data This Year Understanding iOS passcode security The Phoenix Project Critics: Substandard crypto needlessly puts Evernote accounts at risk Evernote plans two-factor authentication following last week’s hack Recent 10-Ks mentioning “cyber” incidents Java malware spotted using stolen certificate Google+ Can Be A Social Network Or The Name Police – Not Both Blog Comment of the Week This week’s best comment goes to Matt, in response to Attribution Meh. Indicators YEAH! if for no other reason than becausae he put a lot of thought and effort into it. The greatest significance can be found in this report’s overarching message to China: we see you and we’re doing something about it. This may well represent the catalyst for major geopolitical change. The value of this report is that it will likely disrupt the adversary’s operational capability for some time as corporations bolster defenses. The adversary is no longer a vague term referring to an unknown group somewhere in the world. We’re talking about the government of China. We’re talking about disrupting their

I spent half an hour yesterday morning shoveling snow from the walkways around my house. Most of you reading this will think “so what”, as you see snow on an all-too-regular basis. For me, living in Phoenix, snow is something that happens once every 30 years or so. So for the first time in my life I got a snow day – and it was fun. Only 2 inches, but still, a totally alien experience here on the surface of the sun. Better still, the dogs loved it:   Speaking of snow, have you seen these fat bikes? No? Coincidentally Wired did an article this week called Pondering the Point of Snow Bikes While Riding With Wolves. Extra-wide mountain bikes with 4-5” tires, designed for a bike version of the Iditarod. These are the ATVs of bikes and they go over just about everything. I want one! I don’t want one because it snowed here for the first time since, I dunno, disco? I want one for the desert. For one simple reason: there is a lot of sand in the desert. And sand is a lot like snow to a bike. As an example, a few weeks ago I was barreling along on my mountain bike when I dropped into a wash – a dry river for those of you who live where there is rainfall – filled with sand. I went from 15mph to 0mph in about 7’. Needless to say, I was thrown. Several expletives went flying too. Then I bounced. More expletives and a sandy rash. Mountain bikes work great on mountain trails, but they don’t do sand or snow. But there are miles and miles of sandy washes all over the desert. They are natural roadways for all the critters in the area, and provide an easy path through some pretty rough terrain, provided you don’t sink up to your axles. But these big ugly bikes go places bikes have not gone before. And great names to boot – Surly ‘Pugsely’, riding on 5” “Big Fat Larry” tires. Hogback. TRANS-Fat. Neck-Romancer. Beargrease. I was walking by a bike shop last week and they asked if I’d like to try a Salsa Mukluk, so I said ‘Yeah!’ Offering me a bike is a bit like giving an espresso and Corvette keys to a fourteen-year-old. What did I do? Rode it straight into a ravine! The surprise was it went right through – smooth sailing. It just floated over rock and sand. I’m hooked, but that seems like a boatload of money to spend on a bicycle. Then again, since I started working from home, I only put 30 miles on my car per month but 65 a week on the bike. And the mountain bike is way more fun than driving for groceries, so game on! Whenever my wife gives my wallet back, that is. And before I forget, and in case you missed Rich’s tweet from earlier today, Gal Shpantzer (@shpantzer) is now an official Securosis Contributing Analyst! See you all at RSAC next week! On to the Summary: Webcasts, Podcasts, Outside Writing, and Conferences Adrian’s Pragmatic Database Security Presentation. Adrian’s DR Post: Restarting Database Security. Rich at Macworld on removing Java from your Mac. Rich talks security geopolitics with Ryan Naraine at Security Week. Jamie at CSO Online on China and cyberware. Favorite Securosis Posts Mike Rothman: The 2013 Securosis Guide to the RSA Conference. Yup, everyone else is going to pick the House of Cards post, so I’ll show a little love to our RSA Conference Guide. But understand that RSA is only an excuse for us to document our trends and key themes for the coming year. It’s really how we see the world of security, with a bunch of vendor booth grids thrown in for convenience. Adrian Lane: The 2013 Securosis Guide to RSA. There are some gems in here. David Mortman: Twitter and OAuth Access Loophole. Rich: Mike was wrong – no one else picked the House of Cybercards, so I’m picking my own damn post. Take that! Other Securosis Posts Everything is a feature (in time). Understanding Cloud IAM: Implementation Roadmap. Incite 2/20/2013: Tartar Wars. Cars, Babes, and Money: It’s RSAC Time. Mandiant Verifies, but Don’t Expect the Floodgates to Open. Network-Based Threat Intelligence: Quick Wins with NBTI. AV’s False Sense of Security (and a possible Mac hack?) Facebook Hacked with Java Flaw. Trust us, our CA is secure. RSA Conference Guide 2013: Security Management and Compliance. Quantify Me: Friday Summary: February 15, 2013. Favorite Outside Posts Mike Rothman: What your culture really says. Thought provoking post by Shanley. I have always under-appreciated culture, but that’s probably why I don’t work very well in a corporate environment. Anyhow, you never know what a company is really like until you are there every day, but these are some good things to consider. About any company, not just those in Silicon Valley. Adrian Lane: Chinese military hacker unit behind US attacks – YouTube. I needed some humor this week! David Mortman: How I Hacked Facebook OAuth To Get Full Permission On Any Facebook Account (Without App “Allow” Interaction). Rich: Colorado’s new CISO is revamping their security program on a $6K budget. As a former Colorado state employee, I had to pick this one. Project Quant Posts Understanding and Selecting a Key Management Solution. Building an Early Warning System. Implementing and Managing Patch and Configuration Management. Defending Against Denial of Service (DoS) Attacks. Securing Big Data: Security Recommendations for Hadoop and NoSQL Environments. Tokenization vs. Encryption: Options for Compliance. Pragmatic Key Management for Data Encryption. The Endpoint Security Management Buyer’s Guide. Top News and Posts The Mandiant Intelligence Center Report is the biggest news in security this week. If you have not read it, stop and read it. It’s good. It’s important. And it’s also important you form your own opinions. Introducing AWS OpsWorks, a Powerful Application Management Solution. I think we missed this last week. Apple releases fixes after its computers got hacked. Guns, Homicides and Data. In my best Keanu Reeves voice: “Wow”. U.S. Ups Ante

Brent Simmons brought up a great issue regarding the Twitter hack and the way OAuth works. Twitter’s notification to users: Twitter believes that your account may have been compromised by a website or service not associated with Twitter. We’ve reset your password to prevent others from accessing your account. And Brent’s response: … would lead a normal person to believe that resetting your password would prevent other people from accessing your account in any way. But it’s not true, not if they’ve already accessed your account. D’oh! I am betting most of you, like me, missed this subtlety. The issue is that if an attacker got to your account before the password was reset, the Twitter OAuth token they created for their own access will persist. That means that, despite a password reset, the attacker keeps access. Note that this is not intrinsic to OAuth – it is the choice in how the application platform (in this case Twitter) implements tokens. Some services, like Facebook, expire tokens by default. Twitter chose not to, but it’s not clear to most users (I certainly missed this point) that they should reset all Twitter apps if they are worried about a compromise. Tokens change the way access works behind the scenes, and it’s not always clear how. In fact many application developers can specify ‘lifetime’ access tokens, overriding the application usage of OAuth if they choose. This is not a straightforward issue – more correctly, as David Mortman pointed out: “It’s a complex problem … actually, no, it’s a complex thought process due to the fact that we poorly educate users on the issues and what they need to do”. If you got the email from Twitter, we advise you to go into the application sub-menu of your Twitter account and revoke any applications you see there. I understand when that retyping ginormous passwords in for every app on every mobile device is a pain, but it’s the only means we are aware of to invalidate old tokens and force re-authentication with the new password. Update Nishant Kaushik goes into much more detail at Talking Identity. Share:

IAM projects are complex, encompassing most IT infrastructure, and can take years to fully implement and roll out. So trying to do everything at once is a recipe for failure. So we turn our discussion to how to deploy IAM without biting off more than you can chew. We will discuss how to approach building an architectural schema for your particular organization, based on the cloud service and deployment models you have selected. Then we will create different implementation roadmaps depending your project goals and most critical business requirements. The last post described three common use cases for Cloud IAM: Single Sign On, Provisioning, and Attribute Exchange. The good news is that the process of creating a deployment roadmap is largely the same, regardless of which use case you choose. But every customer’s environment and priorities are different, so delivering on these use cases requires a slightly different implementation and project plan for every customer. Implementation roadmaps start with a system design, and then describe the series of steps needed to deploy the solution in phases. The roadmap should begin with the assumption that there will be a lot of catch-up to play, because most organizations do not have a cohesive identity strategy. In fact there is rarely a dedicated identity team, much less a VP-level position supporting IAM as a critical function. It is mainly an exercise left to unlucky souls who zigged when they should have zagged, and as a reward got the title “IAM Architect” tacked onto their existing laundry list of responsibilities. These people, overwhelmed by complexity, punt and outsource the problem to consultants. The predictable result is a patchwork of partially implemented tactical solutions. We started this post in Debbie Downer mode because a) you are unlikely to successfully solve the problem without appreciating its magnitude, and b) your plans need to take the current state of IAM in your company into account. With these considerations in mind you can realistically decide which problems to address first – taking into account the available organizational, process, and technology support. Try not to think of Cloud IAM as yet another point IAM solution. The total rethink of IAM prompted by cloud computing offers more flexible and effective solutions than have been available over the last decade. So we urge you to adjust your thinking, consider where identity solutions will be useful, and figure out how one of the cloud architectures we have described can extend your capabilities. Let’s drill into the use cases and focus specifically on the ‘actor’ roles, mapping how these actors interact with one another. We touched on several common roles – Identity Provider, Relying Party, Attribute Provider, Authoritative Source, and Policy Decision Point. A good first step in outlining your strategy is figuring out which servers will fill these roles. Second, determine how the parties will communicate and what information they need to exchange. This process map should provide a good understanding of how all the pieces work together, which feature will be important, and what data needs to be available. Your map should include constraints imposed by these system actors – for example, the cloud application Relying Party likely accepts a limited set of identity tokens. Understanding limitations early is just as important as knowing what the feature requirements are. Communications are often taken for granted. It’s that Internet / cloud thing, so it must all be HTTP, right? Well, mostly, but not always. It could be API calls, or HTTP communications might rely on supplementary SSL/TLS for security. To avoid surprises and last minute fire drills over firewall rule changes, trace out the necessary end-to-end communications and protocols. Often there are requirements for non-HTTP protocols buried deep beneath the surface – this is particularly common for provisioning. Security issues crop up due to information leakage, session security, spoofing, and other concerns, so it pays to examine the dialogue between parties and specify secure communications during the design phase. As we alluded earlier, the state of play in IAM is frequently a hodgepodge of stuff, with various components bolted on to solve specific problems that popped up at various times. This forces some IAM projects to burn considerable calendar time on data cleanup and transformation. Again, the starting point is a schema for identity and accounts used for cloud access decisions. It is critical to understand what work needs to be performed, and to identify the most difficult integrations. From there the order of implementation is heavily influenced by how much of a mess you need to clean up. We caution that simple is best – do not try to build a be-all end-all uber-identity-schema. Even if schema definition is straightforward, enforcing it across multiple backends rarely is. It is important to review data sources, ensure they work with the identity schema, and establish a process for cleaning up and dealing with conflicts. Realistic expectations are your friend – be conservative about what can be achieved, and don’t get too aggressive out of the gate. Do not copy your feature list from a vendor’s capabilities document and assume everything will “just work”. Be conservative; less is more. One final word on building your schema: You need to understand not only how things work, but also what happens when they don’t work. Identity and access have ugly failure modes; when they break people notice and you will get the blame. Plan for failures at each node within your schema, and understand the side effects when each service goes down; are there interesting complications if two go down at the same time, or in the worst possible sequence? Can your system withstand periodic brief outages? You need to conduct sufficient testing to discover issues before production deployment. But most security and QA tools are not well suited to testing IAM. So for each use case you deploy, build out a set of test cases (both positive: this should work, and negative: this should fail) to ensure that what you are promoting works end-to-end. These tests may influence your deployment timeline as