All Posts Tagged Cloud Computing Security
Cloud Security Startups: Where For Art Thou?
Recently I asked ‘Where are the Cloud Security Evangelists?’. Now I’m asking ‘Where are the Cloud Security startups?’.
I’ve had briefings and Q&A sessions with a few but a recent email from a regular reader over at ‘Under the Radar’, prompted me to think “Yeah, where are they?”.
If you or someone you know are working at a pure-play Cloud Security or SaaS Securty startup, I’d love to hear from you.
First, I’m really curious what security challenge you are addressing. Second, if you make it past this application form and can get yourself over to San Francisco in April, you get to pitch your offering to a group of CIOs at ‘Under the Radar’.
Ordinarily, the prospect of meeting a room full of CIOs just doesn’t get me all that excited, however, you’ll get to meet CISCO Cloud pin-up James Urquhart!
As its looking highly likely I will be declining my invitation (logistics, logistics), I’d like to make an offer to any security startup that gets accepted to pitch: I will give you up to 2 hours of my personal time (gratis) to grill you on your solution from an enterprise security perspective. Let me find the security holes before the panel does :-). If you think that might be valuable, reach out here.
And just to be clear, no-one is paying me for this - I’m just very curious and a firm believer in good karma.
What new Cloud Security startups are you aware of? Hit the comments…
The UItimate Cloud Security Challenge: Spot the Cloud Security Evangelist!
Information Security magazine just ran a decent piece on Cloud Computing Security called ‘How To Secure Cloud Computing’.
I was asked for my opinion on the security challenges facing enterprises today and what they can start doing about it.
One of the concerns I expressed is the lack of security evangelism around Cloud Computing Security by Cloud Providers. Attend a Cloud Conference and you’ll see what I mean. The Cloud Provider Evangelists do a great job turning up at conference after conference explaining the benefits and use cases of their respective Clouds. But when it comes to a meaningful discussion about security, who can you talk to? The stock answer is ‘we’ll hook you up with our security team’ or ‘we have a whitepaper about this’ or even ‘we use SSL so its OK’. Um, what?
Cloud Evangelists quickly get out of their depth when it comes to security. Now, is that bad? No, I don’t think so. If I ran a Cloud company, I’d want my evangelists drumming up business, helping build my brand by being highly visible and keeping an eye on my competitors. But if the sales process is about one thing more than anything else, its about removing barriers to “yes”. And if survey after survey is telling you that the biggest barrier to Cloud adoption is security, why can’t you find a Cloud Security Evangelist when you need one?
Have the Cloud Security geeks been told they can’t go outside and play with the other geeks?
To me, as someone actively seeking information on this subject, I’m stunned by the lack of attention Cloud companies are paying to their marketing efforts around security. I’m no Seth Godin or Guy Kawasaki, so if the lack of a security marketing strategy is so blindingly obvious to me, rest assured dear reader, it must be pretty bad.
And just to be really clear: I’m not suggesting that Cloud providers don’t have smart security people. Its just that their masters don’t seem to realise that invisible security may be the holy grail of usability, but it isn’t when it comes to moving the security conversation forward.
The irony here is that it seems to be the smaller players that actually have people on hand that can directly speak to security.
Can anyone explain this conundrum? And more importantly, have you ever met a Cloud Security Evangelist? Perhaps I should start a ’sightings’ page ;-).
US Government Creates Cloud Computing Security Group
Federal Computing Weekly recently reported that the National Institute of Standards and Technology (NIST), an agency of the Commerce Department’s Technology Administration, has announced plans to create a Cloud Computing Security group.
The National Institute of Standards and Technology has created a new team to determine the best way to provide security for agencies that want to adopt the emerging technology called cloud computing, said Ron Ross, a senior computer scientist and information security researcher at NIST.
“The team will give our customers a sense of what kinds of risks they may be taking on by moving into that new territory,” Ross said today at the SaaS/Gov 2009 conference produced by the Software and Information Industry Association and market research firm Input.
Googling reveals an earlier presentation titled ‘Perspectives on Cloud Computing and Standards‘ by Peter Mell and Tim Grance from the Information Technology Laboratory at NIST, wherein they announce plans to develop a NIST Special Publication on Cloud Computing Security to cover the following:
I recommend reading the rest of the presentation, particularly around the NIST definition of Cloud (”what you can’t define, you can’t standardize”) and some of the implementation options under consideration. You can catch the authors giving this presentation in person at the Cloud Computing Interoperability Workshop on March 32rd 23rd in Virginia, US.
It will be interesting to see what this group proposes/mandates.
On a sidenote, this post is the perfect opportunity to draw your attention to fellow Cloud blogger Kevin Jackson. Kevin focuses on Public Sector Cloud news and developments making his blog a must-read.
IGT2008 World Cloud Computing Summit Videos Now Online
Shortly before the holiday break, I presented my take on Cloud Computing and Security at the IGT2008 World Cloud Computing Summit in Tel Aviv, Israel.
This was a great conference for me personally as it was an opportunity to meet face to face with some very smart people that are passionate about the Cloud. It also provided an even greater insight into the steamroller that is the Cloud - company after company lining up to either “Clouderize” their current offerings or in most cases, “doing something new”. I met a few startups looking to solve some tricky problem including a stealth mode security outfit looking to provide enhanced security for SaaS (I can’t say more right now but watch this space).
The main thrust of my talk was that there needs to be a deeper conversation about the security implications of Cloud Computing and Cloud Services in general. That’s not because I think there is anything innately insecure about Cloud offerings, more that we are venturing into the great unknown with layers of offerings, greater trust transitivity and new (and old) technologies meshed together in ways we frankly don’t understand. We need to progress the dialogue beyond crying out that the ‘Cloud is insecure’ or just saying ‘the biggest Cloud issue is security’ and get into the nitty gritty details. But my argument is we can only do that if the providers engage in that conversation. It’s one of the reasons I encourage Cloud providers to reach out and talk security - most large enterprises have responsibilities that mean they cannot treat the Cloud as a black box.
The 25 minute talk is split into 2 parts:
- after a brief intro - I believe I was the only one there not representing a company - I laid out what I mean by ’security’. As this wasn’t an information security conference and there was a wide range of people present, I wanted to lay out what I mean by “information security” to provide context for what was to follow. If you’ve been “doing” enterprise security for years, you can safely skip the first 10 minutes (unless you want to critique me!).
- the second half focused on the need for a new risk model that better represents the ebb and flow of risk in Cloud environments - especially with Cloud Stacks (if someone has a better term, let me know) followed by the Enterprise Cloud Security version of “Hot or Not” - complete with audience voting. Given that some of the providers I’d included in the game were sitting in the audience, this sparked some decent conversations later that evening. If you are a Cloud provider featured in the presentation and you didn’t catch my talk, feel free to contact me to discuss your “hotness” ;-).
The videos are now online (IE only), along with the slides. My talk was on Day 2 in the afternoon (halfway down the right hand side). I welcome your feedback - feel free to leave comments or ask questions.
You also want to check out the Security Panel on Day 1 hosted by Sam Bercovici. Professor Barton P. Miller and Alexis Richardson from CohesiveFT and myself.
What’s New in the Amazon Cloud?: Security Vulnerability in Amazon EC2 and SimpleDB Fixed (7.5 Months After Notification)
If you surfed up to the Amazon Web Services homepage today, you’d be forgiven thinking all has been well in the Amazon cloud.
Recent news stories highlight new features and capabilities, including a SQL-like SELECT API for Amazon SimpleDB and the (significant news) that Cloud Compute is now available in the EU.
More worryingly, however and missing from the Amazon AWS homepage, is that Amazon just rolled out an important security fix to correct a basic, but significant, cryptographic weakness in their request signing code. The flaw affects their database API (SimpleDB) and compute API (EC2) services.
Colin Percival discovered the weakness and reported it to Amazon back in May (!). Thats 7.5 months ago. Here’s the “executive summary” from Colins’ write-up:
AWS signature version 1 is insecure
The important bit first: If you are making Query (aka REST) requests to Amazon SimpleDB, to Amazon Elastic Compute Cloud (EC2), or to Amazon Simple Queue Service (SQS) over HTTP, and there is any way for an attacker to provide you with data which you use to construct your request, switch to HTTPS or start using AWS signature version 2 now. For example, if you allow users to add arbitrary “tags” to documents, and you use SimpleDB to store those tags, this means you. (Amazon Flexible Payments Service (FPS) and Amazon Devpay also use the same insecure signature method, but they already require the use of HTTPS. Amazon S3 and other services use different signature methods.)
So in a nutshell, if you only ever accessed SimpleDB or EC2 services over HTTPS, you’re not impacted.
But if you did use the non-encrypted transport, you were vulnerable to a man-in-the-middle attack (MITM) that could expose your data hosted in SimpleDB and your EC2 compute instances.
Overall, Colin is generous in his praise of the response from the Amazon team - although did express concern at the time it took for the vulnerably to be closed:
I reported this issue to Amazon via an email to Jeff Barr, the “Lead Web Services Evangelist” at Amazon on May 1st, and while it took a long time — 7.5 months — for it to be fixed, I’m happy to say that Amazon took this issue seriously at all times, and the lengthy timeline was simply because of the large amount of work involved. Jeff forwarded my email to someone working on SimpleDB (I’ve been asked not to mention names), who confirmed that they agreed that this was a problem. As part of their review of my findings, Amazon’s security people realized that this also affected EC2 and SQS — in my initial investigation I had only looked at SimpleDB — and at the beginning of July they agreed to send me their planned signature version 2 so that I could review it.
Based on the timeline provided by Colin, it took about 2 months for Amazon to assess the extent of the exposure across their other service APIs and come up with a proposed fix. That’s a considerable length of time given the simplicity of the weakness. They then took over 5 months to actually implement the fix. I don’t care how many client libraries you offer Mr Cloud Provider, thats still a very, very long time to leave your customers exposed while you get a fix into production.
Back to Colin as he describes the vulnerable signing process:
AWS signature version 1 signs an HTTP query string as follows:
- Split the query string based on ‘&’ and ‘=’ characters into a series of key-value pairs.
- Sort the pairs based on the keys.
- Append the keys and values together, in order, to construct one big string (key1 + value1 + key2 + value2 + … ).
- Sign that string using HMAC-SHA1 and your secret access key.
Did you spot the problem? Colin did and explains as follows:
When Amazon invented this signature scheme, they forgot about one of the foremost design principles relating to cryptographic signatures: Collisions are BAD! In a well-designed signature system, it should be computationally infeasible to construct two different messages which have the same signature; this prevents substitution attacks where an attacker convinces the key holder to sign a “harmless” message, and then attaches that signature to a different message. Looking at how AWS signature version 1 is computed, it’s easy to see how to construct collisions: Because there are no delimiters between the keys and values, the signature for “foo=bar” is identical to the signature for “foob=ar”; moreover, the signature for “foo=bar&fooble=baz” is the same as the signature for “foo=barfooblebaz”.
Oops. He then goes on to explain how a man in the middle attack could exploit the weakness.
Taking a step back, what are the concerns with this weakness and the way Amazon handles security vulnerability reports in general?
Vulnerability Reporting
- Amazon doesn’t provide a visible mechanism for researchers/customers to report security vulnerabilities. You can report ‘abuse’ (i.e. your EC2 image is under attack) via a contact form on the AWS website but unless you know someone at Amazon, you have to guess how to report a security vulnerability.
- Amazon has no published policy on how they handle vulnerability reports. Nothing to explain their commitment to following up, promptly responding to reports, overall process etc. Now, it seems they do follow up and overall Colin says good things but that timeline sends shivers up my spine.
- Amazon doesn’t have a dedicated security page, mailing list, RSS feed or pigeon carrier for alerting customers of security issues. This makes it a PITA for enlightended customers to even know they are at risk (unless they setup Google News Alerts) and comes across to me at least as a trifle arrogant.
Vulnerability Notification
- Amazon hasn’t notified their customers yet that their SimpleDB and EC2 instances were vulnerable for the past 7.5 months (I’m a customer and I’ve yet to receive an email). Obviously the vulnerability itself goes back further than 7.5 months.
- Amazon have not published how customers can determine if the issue was exploited (back to the visibility issue again). Clearly, Amazon doesn’t have full visibliity of the network between the customer and their data centers, however what analysis has Amazon performed on the logs *only they have access to* that could highlight an issue? (frankly, due to the nature of this issue and the lack of event logs/audit trails I suspect the simple answer is there isn’t much they can do here).
Secure Software Development
- Amazons’ internal code review process failed to detect a basic cryptography flaw. Note, although the error is pretty basic, errors do happen. The real problem here is the failure of peer review processes to identify the problem prior to going into production. Cryptography routines along with other sensitive security routines should be subject to greater security analysis as clearly the stakes are higher. If they did in fact have this code reviewed for security weaknesses, this is a huge oversight. So this is now fixed, what else is vulnerable? It would be great to learn that the lengthy delay in delivering the fix was due to Amazon have all their source code reviewed for security issues…
- Amazon have made no public commitment regarding how security is factored into their software development lifecycle. Until now they could argue they didn’t need to - they hadn’t messed up (or at least, we don’t think they did).
The geek in me loves Amazon AWS and the promise that it holds, but the Security Professional rooted in the “here and now” is seeing too many red flags (the issues are wider than the handling of this one bug).
If anyone from Amazon reads this and wants to talk security roadmap and go “beyond the whitepaper”, you know where I am.
