Research

After two years of development, yesterday we flipped the switch and our Nexus product is officially live with our first partner, the Cloud Security Alliance. After all the stress of a nearly-failed launch (one of our security controls decided to filter the payment system) it is incredibly exciting to have this out there for paying customers. Here are some details: You can access the CSA Nexus at nexus.cloudsecurityalliance.org. Subscriptions are $200 annually, and it is available internationally. We launched with the CSA first because the timing was better to support a number of CSA initiatives. Also, we decided to completely rework our content structure for Securosis research to better fit our target market, and that will take us a few months. The systems are otherwise identical, running on the same platform (ain’t SaaS wonderful?). CSA customers gain access to existing and draft CSA research, some exclusive non-public research, and all the Securosis cloud research under development. Since we will be charging a lot more for the full Securosis library, this is a good way for cloud-only people to get discounted access to the exact same content. In other news, I’m a crappy sales guy. Questions submitted to the Ask an Analyst system will be handled by Securosis and CSA experts, depending on who is best for the question at hand. That’s right, full access to Securosis analysts for only $200 (on cloud issues). To support the CSA, we added a full discussion (forum) system that’s tightly integrated with the research, as well as the ability to ask the community (public) questions, not just the experts. You get to pick who you are asking when you submit a question, and our experts will watch both queues. Think of it like Quora or Stack Overflow, except you get to pick whether you want a guaranteed answer from us or responses from your peers. CSA enterprise members get licenses to the system as part of their memberships. We will have more activities and announcements over the next weeks and months, but those are the basics. We really aren’t aware of anything like this on the market that combines structured, professional research with access to both experts and peers for direct answers to your tough questions. Then again, for once, we are totally and completely biased. I also need to thank our developers JT and Jon, and James at our hosting provider (no links because they aren’t ready to take more business right now). I think once you look at what we built, you’ll be amazed that a small company without external funding could pull this off. Share:

Let’s just say I almost failed sharing back in kindergarten. Almost 40 years later I’m not a hell of a lot better at sharing (just ask my kids), but if you want to be good at security, you had better do better at sharing than me. Good points here by Don Srebnick (CISO of the City of NY) on using an ISAC to your advantage: A structure for this type of sharing has been developed within multiple sectors. If you haven’t heard, the Information Sharing and Analysis Center, or ISAC, is that structure. An ISAC provides members with a private community for dispensing information about security threats, incidents and response, and critical infrastructure protection. ISACs are an effective method of sharing your information without direct attribution. If your site is under cyber attack or you become aware of an imminent threat to your sector, details can be exchanged without ever revealing your identity, thereby facilitating sharing, but maintaining confidentiality. I’ve been doing a lot of research on threat intelligence and believe (as many of the CISOs I speak with believe) that no one organization can do it themselves. The only way to shorten the window between attack and detection is to get much better at searching for indicators of compromise in your environment. And bi-directional sharing of the attacks you’re seeing, and learning about attacks similar organizations are seeing, are becoming key success criteria for security in the age of advanced attackers. The New School guys were absolutely right years ago about the need to share. They were just way ahead of the curve. It’s good to see a lot more discussion about sharing happening in the industry. It’s about time… Photo credit: “Sharing” originally uploaded by Toban Black Share:

You know a technology is close to the top of the hype cycle when talking heads start calling for its demise. Zeus Kerravala goes medieval on MDM in this NetworkWorld column: I believe we’re starting to see the beginning of the end of the red hot MDM market. More and more network vendors are rolling out solutions for BYOD that make the traditional solutions somewhat of a commodity. Now Zeus is talking about a new product from F5 that basically wraps apps before delivery to a mobile device, to ostensibly provide proper protection, authorization, etc. Hmmm. Sounds a lot like VDI to me. Or remote control. Or the zillion other technologies that are supposed to take devices out of the equation and manage applications and desktops and everything else remotely. Let’s just say we have seen this movie before and device-centric management approaches continue to be alive and well. And I don’t have any doubt that MDM will be here for the foreseeable future to manage the configurations and hygiene of mobile devices. Will MDM be bundled into a broader endpoint and/or IT management suite? Absolutely. Everything is a feature (in time). Though some folks think this is very big market, as evidenced by AirWatch raising $200 MILLION. Not that investors are always right, but that sounds like a market on the upswing. To say it’s the beginning of the end is, well, wrong. It’s the beginning of the beginning. Photo credit: “it’s dead Jim” originally uploaded by Eddie Codel Share:

In addition to all the cycles we spent in our weekly research meeting trying to come up with cool t-shirt ideas featuring APT1, we also spent a bunch of time talking about the real impact of the Mandiant report, and how hacking for the Chinese is just different than what the US (and most other governments) do. I’m pretty sure Rich will do a much more detailed post on this, following up on his great House of Cybercards ideas. But suffice it to say you probably wouldn’t get much of a hearing if you asked the US military apparatus to help figure out what price a Chinese competitor was planning to bid on a big power plant in South America. But the Chinese have no issue with hacking into all sorts of places to assist their commercial entities, many of which are still at least partially owned by the government. But that’s another discussion for another day – one with a lot of beer. I want to follow up on this week’s Incite snippet, Attribution. Meh. Indicators. WIN! on what I see as the real value of Mandiant’s report. It’s not like most of us in the industry didn’t know that the Chinese military was behind a lot of the so-called APT activity. Now we have a building to go visit. Whoopee! I was far more interested to see the malware indicators they found published, if only to see how some smart folks will use that information to help the industry. First send some kudos over to the folks at Tenable, who quickly posted checks you can load directly into Nessus to look for the malware. Part of the reason to do malware analysis in the first place is to be able to search for those indicators within your environment, using tools you already have. This audit file determines possible infections by several of the malware items identified in the Mandiant Intelligence Center Report – APT1: Exposing One of China’s Cyber Espionage Units. It includes checks for 34 of the malware variants identified in Appendix C The Malware Arsenal. The audit file utilizes a combination of registry checks and file system checks to find hosts that might likely be at risk or infected. Wesley McGrew’s students at Mississippi State also got a little gift, in terms of a bunch of new samples to analyze, as described by TechWorld. It’s great to see students able to learn on real world ammo. “Oh, it’s fantastic,” said McGrew, who will defend his doctoral thesis on the security of SCADA (supervisory control and data acquisition) systems next month. “The importance of having malware that has an impact on the economic advantage of one company over another or the security of a nation is priceless. This is exactly what they should be learning to look at.” Not to get all New School now, but access to the malware and associated indicators used in many of these advanced attacks can be instructive for tons of reasons. We can only hope this is the first of many instances where the industry works together to improve the practice of security, as opposed to competing against each other for purely economic gain. Yeah, not sure what I was thinking with that last statement. Share:

One of the responses that keeps coming up as everyone discusses Mandiant’s report on APT1 is, “yeah, but China isn’t the only threat, and even the U.S. engages in offensive hacking”. That is completely true, but there is a key difference. China is one of the only nations which uses government resources to steal intellectual property and provides it to domestic business for competitive economic advantage. Of the countries that do this (France and Israel come to mind, according to rumor), China is the only one operating at such a massive scale and scope. Most countries engage in cyberattacks for traditional espionage or, on occasion, in offensive actions like Stuxnet designed to support or obviate a kinetic (boom) response. (“Cyber Missiles” as Gal Shpantzer called it in our research meeting today). China is using the power of the government, at scale, to steal from private businesses in other countries and provide the spoils to its own businesses. This is an important difference, and the reason the response to Chinese hacking is so complex. We can’t treat it like traditional criminal activity because there isn’t anyone to arrest. We can’t treat it as normal government espionage because private businesses are both the targets and the beneficiaries. We can’t treat it like war or offensive operations like Stuxnet, since we sort of can’t go to war with China right now. We can’t stick it back to them and do the same thanks to a combination of our laws and the different natures of our economies. We can’t write it off like we do certain other countries which also steal our IP, because the scale is so massive and the consequences (losses) have grown to measurable levels. In other words, China is different, so the potential responses are more complex. The threat is also greater than many of the other cybersecurity (and I use that term advisedly) problems we face – again due to the scope and losses. There are ulterior motives all over the place right now, and little is as it seems on the surface. There are vested financial interests, both at agency budget levels and within private corporations, manipulating the public dialogue. But that doesn’t mean the threat isn’t real, or that doesn’t need a response. We just should avoid being naive about it. (As a side note, in the same meeting today Gunnar Peterson reminded us that China isn’t doing anything that the US didn’t do back when we were a developing nation. I believe his exact words were, “the US stole everything from Britain that wasn’t nailed down”. We are seeing a natural political progression, but that doesn’t mean we should take it up the ….). Share:

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

In the least surprising news of the day, the guy who sold his start-up, Zenprise, to Citrix, concluded that selling standalone MDM was a tough sell. Even though Zenprise had around 100 developers, it would have been tough to respond to all those demands, he said. “We were feeling pressure from larger enterprises to offer data, secure email, secure browsing, and tie it into other third party and native apps,” he said. “We didn’t feel we had the resources to really deliver a lot of these pieces.” What’s the guy going to say? He took the money and ran and now can throw developers at the problem. That’s his differentiation against the start-ups that remain. And the folks who haven’t sold yet probably want to talk about how innovation stops when a start-up gets bought and how their nimble focus will provide a better solution for customers. Blah blah blah. Over time, pretty much all the MDM start-ups will be acquired and MDM will be integrated into the management stack. It could be the systems management stack or perhaps the security stack. But it will be integrated. We have seen this movie and it always has the same ending. Over time, everything is a feature. Everything. And before you tell me one of the stand-alone companies will go public and remain independent, remember that the day their stock starts trading they begin looking for other stuff to buy to integrate into their platform. As a former boss of mine said, “if you aren’t moving forward, you’re moving backward.” That’s the way technology markets work. Photo credit: “Penn and Teller Get Killed + Pee Wee’s Big Adventure” originally uploaded by Double Feature Podcast Share:

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