Research

We are in the middle of what may be the single most disruptive transition in the practice of information security. Not one of technology, threats, or practices, but of politics. It is occurring in the hallways of capitals and the planning rooms of militaries, instead of in boardrooms of enterprises and startups in California and Massachusetts. This transition will define our priorities for the coming decades, as well as the winners and losers of the future. We, as an industry and collection of communities, need to understand this transition and find our places within it, or risk irrelevance. The president of the United States has placed cybersecurity on par with gun control, tax and education reform, and job creation, in the State of the Union address. It is time to step back, take stock, and understand the implications. We are playing an old game, where we are barely in the stands, never mind on the field.   First, let’s take a moment to look at the buildup to this point. Major security incursions, even at the nation-state level, have been occurring for decades. But beginning in 2010 with Google’s revelation of the Operation Aurora attacks, followed up by disclosures that dozens of technology firms believed they were targeted and attacked by China, we have seen a flood of major attack disclosures – RSA, Stuxnet, Lockheed-Martin, and the New York Times, just to get started. Some here in the US, some perpetuated by the US, but all focused on the cat and mouse game between world powers, not merely banks and criminal hackers. The revelation of these attacks and its timing is more significant than the attacks themselves. Defense contractors don’t reveal they have been breached without a good reason. Seven recent events best illustrate the nature of the impending shift. The first, clearly, was the State of the Union address. The second followed closely with the President signing an executive order on cybersecurity. This was preceded by revelations that a classified National Intelligence Estimate was issued, naming China as the top cybersecurity threat. Combine these three events with the failure of Congress to pass a cybersecurity bill (due to competing lobbying efforts) and the European Commission proposing new cybersecurity legislation, and it becomes clear that the politicians and lobbyists are fully engaged. This was accelerated dramatically this week by Mandiant’s release of specific intelligence tying China to a massive attack campaign, and the White House’s release of the Administration strategy on mitigating the theft of U.S. trade secrets (PDF) strategy position paper. And let’s not forget that the US government apparently used cyberarms to attack Iran’s nuclear program, instead of allowing Israel to launch kinetic weapons. Cybersecurity is now operating fully at a geopolitical level. (As much as you might hate the word ‘cybersecurity’, that battle is long lost, and fighting it is the quickest way to the kids’ table). That means future regulations, and massive amounts of government cash, will be fought over by lobbyists and special interests; in national capitals and on the screens of Sunday morning talk shows. Although we may be the professionals with the most experience in security, that doesn’t buy us an inch of credibility or influence in this process. And I mean ‘buy’ in the literal sense. Just ask teachers how much influence they have over education legislation – and they even own a union. Security standards, disclosure laws, information sharing, criminal laws, and cyber arms control (vulnerability research and exploit development) are all likely to be regulated in one way or the other in the coming years across different nations. Many of these have the potential to directly affect how we do our jobs, and the direction of federal funding will influence what tools and technologies succeed in the market. It doesn’t matter if you are a vendor, researcher, or practitioner – the only way to influence this process (if you care) is to play the political game. Engage with politicians, hire lobbyists, and start making the rounds in the halls of government. Understand that other vendors or “industry representatives” won’t necessarily represent your needs, and are focused on their own narrow interests. Your opinion, however logical, doesn’t matter unless you have a lever to pry decisions in your direction – the effective ones are all built around large wads of cash. Those of you in the vendor community, in particular, need to realize you are up against defense contractors looking to maintain profits as two wars end. And they can no longer afford to perform poorly in the commercial market. If your CEO doesn’t have a travel schedule that involves Dulles or Reagan, you are already losing. You don’t need to be a cynic to know it’s the toughest game in history, and we just landed in the middle. Share:

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

5 years. It doesn’t seem that long. It seems like yesterday I was on the phone screaming at the office manager of my (previous) dentist. He told the Boss something and then backtracked on it, and I had to write a check to fix the problem. I had just dropped my dental insurance and that little optional procedure wasn’t going to be covered as he had said it would. I told them to pound sand, which was a good move – I settled for perhaps 30% of the cost 18 months later, before it went to collection. But at the same time, I dropped the dentist. He violated my trust and that was that. Though I seemed to have forgotten to find a new one. This was pretty uncharacteristic – I had been going every 6 months for cleanings since I was a kid. I had a handful of cavities but my teeth were in great shape. But none of my pals had a dentist they liked, so I kind of forgot about it. No big deal, I’ll find one. Sooner or later. And one year became two years, which then turned into 5. Turns out a friend of ours recently moved his dental practice around the corner, so I had a new guy I trusted. Combined with the call I got last week about the Boss needing a root canal (she hadn’t been in 5 years either), I knew it was time. The fact that Arthur Treacher’s famous Tartar Sauce was caked onto my teeth notwithstanding, it was time to pay my penance and go in. First of all, my guy does it right. Most folks hate the dentist, so he staffs his office with the nicest people on Earth. I wasn’t in a great mood, and within a minute they had me smiling and chatting it up. That is nothing short of amazing, given my general state of grumpiness. They were all super helpful and by the time my hygienist got through my health forms and X-rays, I knew her life story. Then she proceeded to sandblast my teeth for 35 minutes to clean them off. Evidently a lot of crap sticks to your teeth over 5 years. Yes, it was uncomfortable. But penance is never pleasant. At least she gave my gums a rest halfway through. A little polish, a bunch of floss and I was ready to meet with the big man. I was a little apprehensive because I figured with all the plaque build-up my teeth must be a train wreck. He cracks some jokes and then pokes and prods with his tools. Oh crap, here it comes… 3 new cavities and about 5 other areas to watch. Wow, it could have been a lot worse. I guess all that fluoride my Mom made me take when I was a kid worked okay. Of course he did mention my habit of grinding my teeth. Evidently that’s my subconscious way of dealing with the stress and paranoia of being me. Though it’s not causing too much damage right now. So I’ll need to be more aware and cut it out. Evidently I need to find another stress outlet. Maybe some vendor will have a nice squeeze toy or punching bag to give away at the RSAC next week. He also made an impassioned plea for me to floss more. I hate flossing. I mean hate. But hey, if it means I won’t have to get more fillings next year and the year after that, then I’ll just do it. I have declared war on tartar, and that damn floss is a key armament in my arsenal so I have no choice. A man’s got to do what a man’s got to do. –Mike Photo credits: Thong Lor dentist originally uploaded by Mrs Hilksom Heavy Research We’re back at work on a variety of blog series, so here is a list of the research currently underway. Remember you can get our Heavy Feed via RSS, where you can get all our content in its unabridged glory. And you can get all our research papers too. Network-based Threat Intelligence Quick Wins with NBTI Following the Trail of Bits Understanding the Kill Chain Understanding Identity Management for Cloud Services Architecture and Design Integration Newly Published Papers Building an Early Warning System Implementing and Managing Patch and Configuration Management Defending Against Denial of Service Attacks Securing Big Data: Security Recommendations for Hadoop and NoSQL Environments Pragmatic WAF Management: Giving Web Apps a Fighting Chance Incite 4 U Attribution. Meh. Indicators. WIN! With the Mandiant APT1 report making mass market waves yesterday (Rich covered it, and Adrian has some thoughts below), attribution is now big news. John Sawyer discussed this on Dark Reading last week, of course quoting the Mandiant PR machine. His point is that attribution is hard and the kind of profiling and work done by Mandiant is required to really be sure who a specific attacker is. And although Jeffrey Carr brings up some decent points about considering other actors before attributing (though he has no way to know to what degree Mandiant considered competing hypotheses), the reality is that Mandiant did the work and showed with reasonable certainty the specific actor is who they think it is. But ultimately will this do anything besides force the attackers to change tactics and reconsider their OpSec? Probably not, but that misses the point. What will be most valuable is the hundreds of indicators published with the research. Kudos to Mandiant for that. – MR Siri, build me a cloud: If you have been paying any attention to anything I have written or said on cloud security the past couple years (something I’m definitely not about to assume), you know I’m a huge fan of cloud automation and software defined security. We really cannot manage cloud security manually, and need to take lessons from the whole DevOps movement to become much more efficient in protecting cloud instances. One thing I have mentioned frequently is use of tools like Chef and Puppet for configuration automation (in the