House of Cybercards

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:

Read Post

Twitter and OAuth Access Loophole

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:

Read Post

Understanding Cloud IAM: Implementation Roadmap

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

Read Post

Incite 2/20/2013: Tartar Wars

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

Read Post

Totally Transparent Research is the embodiment of how we work at Securosis. It’s our core operating philosophy, our research policy, and a specific process. We initially developed it to help maintain objectivity while producing licensed research, but its benefits extend to all aspects of our business.

Going beyond Open Source Research, and a far cry from the traditional syndicated research model, we think it’s the best way to produce independent, objective, quality research.

Here’s how it works:

  • Content is developed ‘live’ on the blog. Primary research is generally released in pieces, as a series of posts, so we can digest and integrate feedback, making the end results much stronger than traditional “ivory tower” research.
  • Comments are enabled for posts. All comments are kept except for spam, personal insults of a clearly inflammatory nature, and completely off-topic content that distracts from the discussion. We welcome comments critical of the work, even if somewhat insulting to the authors. Really.
  • Anyone can comment, and no registration is required. Vendors or consultants with a relevant product or offering must properly identify themselves. While their comments won’t be deleted, the writer/moderator will “call out”, identify, and possibly ridicule vendors who fail to do so.
  • Vendors considering licensing the content are welcome to provide feedback, but it must be posted in the comments - just like everyone else. There is no back channel influence on the research findings or posts.
    Analysts must reply to comments and defend the research position, or agree to modify the content.
  • At the end of the post series, the analyst compiles the posts into a paper, presentation, or other delivery vehicle. Public comments/input factors into the research, where appropriate.
  • If the research is distributed as a paper, significant commenters/contributors are acknowledged in the opening of the report. If they did not post their real names, handles used for comments are listed. Commenters do not retain any rights to the report, but their contributions will be recognized.
  • All primary research will be released under a Creative Commons license. The current license is Non-Commercial, Attribution. The analyst, at their discretion, may add a Derivative Works or Share Alike condition.
  • Securosis primary research does not discuss specific vendors or specific products/offerings, unless used to provide context, contrast or to make a point (which is very very rare).
    Although quotes from published primary research (and published primary research only) may be used in press releases, said quotes may never mention a specific vendor, even if the vendor is mentioned in the source report. Securosis must approve any quote to appear in any vendor marketing collateral.
  • Final primary research will be posted on the blog with open comments.
  • Research will be updated periodically to reflect market realities, based on the discretion of the primary analyst. Updated research will be dated and given a version number.
    For research that cannot be developed using this model, such as complex principles or models that are unsuited for a series of blog posts, the content will be chunked up and posted at or before release of the paper to solicit public feedback, and provide an open venue for comments and criticisms.
  • In rare cases Securosis may write papers outside of the primary research agenda, but only if the end result can be non-biased and valuable to the user community to supplement industry-wide efforts or advances. A “Radically Transparent Research” process will be followed in developing these papers, where absolutely all materials are public at all stages of development, including communications (email, call notes).
    Only the free primary research released on our site can be licensed. We will not accept licensing fees on research we charge users to access.
  • All licensed research will be clearly labeled with the licensees. No licensed research will be released without indicating the sources of licensing fees. Again, there will be no back channel influence. We’re open and transparent about our revenue sources.

In essence, we develop all of our research out in the open, and not only seek public comments, but keep those comments indefinitely as a record of the research creation process. If you believe we are biased or not doing our homework, you can call us out on it and it will be there in the record. Our philosophy involves cracking open the research process, and using our readers to eliminate bias and enhance the quality of the work.

On the back end, here’s how we handle this approach with licensees:

  • Licensees may propose paper topics. The topic may be accepted if it is consistent with the Securosis research agenda and goals, but only if it can be covered without bias and will be valuable to the end user community.
  • Analysts produce research according to their own research agendas, and may offer licensing under the same objectivity requirements.
  • The potential licensee will be provided an outline of our research positions and the potential research product so they can determine if it is likely to meet their objectives.
  • Once the licensee agrees, development of the primary research content begins, following the Totally Transparent Research process as outlined above. At this point, there is no money exchanged.
  • Upon completion of the paper, the licensee will receive a release candidate to determine whether the final result still meets their needs.
  • If the content does not meet their needs, the licensee is not required to pay, and the research will be released without licensing or with alternate licensees.
  • Licensees may host and reuse the content for the length of the license (typically one year). This includes placing the content behind a registration process, posting on white paper networks, or translation into other languages. The research will always be hosted at Securosis for free without registration.

Here is the language we currently place in our research project agreements:

Content will be created independently of LICENSEE with no obligations for payment. Once content is complete, LICENSEE will have a 3 day review period to determine if the content meets corporate objectives. If the content is unsuitable, LICENSEE will not be obligated for any payment and Securosis is free to distribute the whitepaper without branding or with alternate licensees, and will not complete any associated webcasts for the declining LICENSEE. Content licensing, webcasts and payment are contingent on the content being acceptable to LICENSEE. This maintains objectivity while limiting the risk to LICENSEE. Securosis maintains all rights to the content and to include Securosis branding in addition to any licensee branding.

Even this process itself is open to criticism. If you have questions or comments, you can email us or comment on the blog.