Cloud Computing and Security For The Masses: Interview on NPR

US National Public Radio

Cloud Computing is starting to escape the technical and business press.

The proof?

I was invited to talk about Cloud Computing and Security on NPR “Morning Edition”.

NPR - National Public Radio - is a US based, non-commercial radio station covering news, talk and current affairs. British readers may find it similar to BBC Radio 4.

Every Monday, the “Morning Edition” has a technology theme. The Cloud Computing segment was high level and aimed primarily at a non-tech audience. I always find it hard to answer the question ‘what is Cloud Computing?’ as there are so many different definitions. Regardless, it was a great chance to talk about an exciting technology and highlight the need for a real security conversation between the providers and people interested in IT security - the primary reason why I created cloudsecurity.org.

The show boasts a very impressive audience - around 13 million! I’ve never before had the opportunity to confuse that many people in one shot ;-).

If you would like to listen (its short - 3.5 mins), click here.

I’d like to publicly thank Nina at NPR for reaching out and extend a warm ‘Welcome’ to any NPR listeners who have dropped by. Feel free to leave a message below or email me if you have any comments or questions.

Your Turn At The Bar Again? Security Costs in a Pay Per Drink Cloud

Lounge

With in-house IT, you pay your upfront capital costs and maintenance fees and you get whatever compute power you paid for. If you over-specify, you have excess computer power or disk - you are wasting money.  If you under-specify, you may be forced to raid your ‘rainy day’ budget and order new hardware.

A primary selling point of Cloud Computing is the ‘pay by the drink’ billing model - you only pay for the CPU cycles and storage you use - that’s it.

If you run any IT security tools at all, Cloud Computing may impact the way you calculate your IT security budgets.

Assessing The Cost of Runtime Security

Security costs can be overt or hidden:

  • budget items spread across infrastructure, security, compliance, midrange.
  • the runtime security costs of security tools that execute on the systems.

How many organisations know their runtime security compute costs?  My guess is not many.  Under the traditional IT billing model, you mostly don’t need to figure this stuff out. As long as your security tools don’t chew up the CPU unnecessarily or fill the disk, everyone is happy.

The performance of security products varies greatly.  On the negative side, poor design or implementation are problems only the vendor can address.   Site specific issues arise through all kinds of madness - customers failing to “read the label” and provision properly, insufficiently trained people making poor configuration choices or simply relying on the default settings in a very non-default environment!

The negative side effects of in-line security tools hit home as system load increases.  Access checks, logging and other ‘in-line’ security operations may perform fine under normal load fail to scale as load increases past a certain threshold.  This can lead to CPU spikes or poor disk access patterns.

Switch Off Or Pay Up?

To bring this closer to home, lets explore how the impact of security tools plays out today under traditional IT and tomorrow, under Cloud Computing.  Lets eavesdrop on a fictitious conversation between Oscar the ORACLE DBA and Simon the Security Dude.

Oscar: Hey Simon, your Security Agents are killing system performance again. Anna in accounts called up to say they can’t do the Quarterly close, the jobs are getting killed before they finish.

Simon: Hi Simon, I understand but we can’t just disable all the security!

Oscar: Well, we need to do something if we are going to finish posting our numbers this quarter. Are you volunteering to explain to our CEO why we didn’t?

Simon: Hmm. Let me check the agent logs, perhaps there is a problem.

Oscar: I already checked them, no errors reported.

Simon: Hmm. I’ll log a call with the Premium International Support Service.

Oscar: You did that last time and the support guy stuck to the party line that the security agent takes 5-10% of CPU. We know those numbers are wrong from our benchmarking - sometimes it takes 20% of CPU and always a lot more during quarter close.

Simon: Hmm. Are there any other processes running on the system we can disable for a while?

Oscar: Nope - we’re running a tight a ship as we can here. I’ve already told Steve from sourcing he is going to have to wait for his reports.

Simon: Hmm. Bugger. OK, I’ll disable the agents - but you must tell me as soon as the quarter close completes so I can start them up again.

Oscar: Thanks - will do.

A classic conversation under the ‘old regime’. Simon is forced into an operational security decision due to an under-specified system or an over indulgent security agent. His only option in this scenario is to disable the poorly scaling security tool. He can’t just scream “Need more power!” and additional CPUs appear.

Now lets see how this plays out with Cloud Computing, where the change in paradigm will remove the compute limits and make your on the spot risk decisions link directly to your costs and security tool efficiencies:

Simon the Security Dude receives an auto-generated email from the Cloud Provider:

A virtual CPU was auto-inserted on virtual machine image FINANCE1 at 10:30am as Runtime Security Compute usage exceeded the agreed threshold in the SLA.   Please note, you have now reached your soft credit limit - please click the link below to authorize an increase. You currently have 4USD left in your account.

So what does Simon do now? He already tapped into his security compute budget five times this week and he’s running low. The silver lining is that at least he gets to make the decision now - he isn’t forced to ’switch off security’. If he has the cash, he can attempt to buy his way out of the problem. The obvious negative is “death by a thousand costs” - he’s running out of budget.

The root cause of the problem is that prior to moving to the Cloud, Simon didn’t have a handle on how much runtime security was *really* costing. He didn’t know (a) his runtime security costs or (b) how much of that cost was unnecessary - caused by security tool inefficiency.  He wasn’t the one paying, so most of the time he didn’t have to care. Even if he had found a way to calculate his costs, he’d still have to figure out how performance differences of Cloud Computing would skew his numbers.

And therein lies the rub: if you don’t know your security runtime costs are today - and where the waste is - how will you cope “tomorrow” when it’s always your turn to pay for drinks at the Cloud Bar?

12 Signs that Your Company is Already in the Cloud

building_gap

What are the telltale signs that your company is already Computing in the Cloud?

Is it when the CIO makes a big announcement at the monthly IT meeting?

Is it when the IT newsletter drops a reference to pilot testing of some ‘web based’ software?

Or, is it when the secretary whips out the boss’s Corporate Credit Card and signs up to a Cloud Service?

Here are 12 indicators that your company is *already* part of the Cloud:

  1. Your internal helpdesk reports fewer password resets.
  2. Finance contacts you to confirm all the DVD readers are disabled - they are puzzled by the number of recurring credit card charges for Amazon (are the secretaries spreading out their orders for “Lost” DVDs again?).
  3. You are asked to authorise a network change ticket that modifies the LAN routing policy.  All traffic will be sent directly to the Internet proxy (for performance reasons).  From the accompanying diagram, the data center appears to have been cut and pasted on the wrong side of the firewall (idiots!).
  4. You walk into the Data Center and it feels cooler than usual.
  5. When the builders next door accidentally saw through the company Internet connection, people complain there must be a DoS attack going on as they can’t get to their files.
  6. During physical inspections, you notice unexplained gaps in server cabinets.
  7. Login failures go down, in fact login “attempts” in general go down but the company car park is full.
  8. As you walk through the office, you notice all the “Security Awareness” posters have been replaced with pictures of Jeff Bezos (!)
  9. You are asked to authorise a visit from the local environment group. Fearing protesters, you are surprised to learn that your company has won a prize for reducing its Carbon Footprint
  10. Your Intrusion Prevention System is preventing the call center from uploading contracts stored as GIF files.
  11. You detect the presence of ‘malware’ in the form of unexplained ‘Machine Images’ on IT’s desktops.
  12. You stop finding Windows passwords under keyboards, instead you find random hex digits next to the words ‘Access Key’ and ‘Secret Key’. You sigh, but at least they are setting difficult to guess passwords now!

If you are charged with IT security in your company, you may want to start checking your web proxy logs for telltale signs that people are talking to the Cloud…or just talk to finance.

Cloud Stacks: Please Mind The Gap

MIND THE GAP

Security gaps creep in when people think other people are ‘taking care of it’.

When a security practitioner assesses a complex system, they’ll look at the ‘hand offs’ between different players within the system.  In fact, if they’ve been in the game for a while, they’ll apply laser sharp focus to where the responsibilities of one party ends and another party begins.  In other words, they’ll be searching for the security gaps, the security ‘no-mans land’.   This is a dark place where - as a good friend of mine puts it - “the bad stuff” gets in and the “good stuff” doesn’t flow.

If you’ve ever performed a security review of an outsourced IT system, you’ll know exactly what I mean.

In the context of Cloud Computing then, who takes responsibility for what?

As a customer of the Cloud, you or your company may strike an agreement with a company perched atop the Cloud.  They provide you with Software as a Service (SaaS) or some other form of high level, end-user service.  Your service agreement and/or contract will define what you can expect from them and what they expect from you.

However, to deliver the service to you, they rely on other Cloud providers further down the stack.  In fact, at any level in the Cloud Stack, it could be multiple players providing the service *they* rely on; e.g. Cloud Storage, Cloud Compute, Cloud Security (?). 

These providers in turn depend upon other service providers at the next layer down in the Cloud and so on.

See where I’m going with this?

This is a new game I’m going to call “Join the Security Dots in Cloud Land“.

And even then it isn’t as simple as I’ve presented it.

To end this post I’m going to ask a question to readers of this blog that provide a service on top of the Cloud (I have logs, I know you’re out there ;-):

What *security* arrangements do you have in place with Cloud Service Providers you rely on to deliver your service?  What are you doing to build “trust in depth” in the Cloud?

To clarify, I’m not asking you to spill your secret sauce on the Cloud Security alter - rather I want to hear what you are doing for your customers to build assurance (and I don’t mean ‘fluffy’ clouds ;-).

Personally, I think this will be one of the keys to selling Cloud Services to Enterprise customers.

Please reply in the comments below or email me.

5 Reasons Why IT Security People Shouldn’t Ignore Cloud Computing

What a job!

You’ve read the headlines.  You’ve heard the buzzwords.  

Cloud Computing just seems like hype, right?  

“But it’s just another technology getting hyped to the max”.

The best case scenario is that your analysis is correct and you can go back to reading Slashdot and Daily Dave (you are reading Daily Dave aren’t you?).  You can pride yourself on your ability to recognise web hysteria and laugh at the losers that invested, wrote blog posts (!) and dared to take it seriously.

OK.  Now lets flip that around and just say for a moment you’re wrong - that Cloud Computing turns out to be a huge deal and takes off.  What could that mean for your day job?  No in-house servers to secure?  No in-house security operations to deal with? No in-house penetration tests to run?  No vulnerability assessment tools to run? No incident response where you actually ‘do something’?  

One scenario is you find yourself on a constant round of conference calls with 3rd parties trying to ‘pin down’ security in the cloud…  If you thought handling security issues associated with outsourcing was painful and slow, the Cloud will bring a multitude of competing providers that decision makers can switch from ‘digitally’ when the numbers ($$) make sense.

As the person responsible for your employer’s security arrangements, you may want to consider these 5 reasons for not dismissing Cloud Computing out of hand:

  • Unless you work for an IT company, your employer did not go into business to ‘do IT’.  They are in business to sell a product or a service - in-house IT may have enabled that up to now but it was out of need rather than desire.  Cloud Computing has hit the cover of popular business magazines - its starting to get on the radar of CEO’s that ask questions like ‘how can I cut my costs?’, ‘how can I make my business more agile?’.  They may not switch overnight, but once the first goes in a given vertical, the clock is ticking.
  • The temptation to contractually outsource security responsibility.  ”Our customer data got stolen from a cloud storage provider - not us - we don’t run IT!”.  Sure the buck stops with the org from a regulatory perspective but media coverage around recent data leakages involving 3rd party providers elicits a mixed reaction and thus diffuses the “reputation issues” to some extent.
  • The skills you need to deal with Cloud Security may be different from the skills you have today.  Your “window” on Cloud security will be what the Cloud Provider gives you.  Beyond that you may be able to do an on-site audit from time to time but its a shared facility so no monkey in a cage pen-testing, scanning or filesystem forensic analysis.
  • There’s a large cloud forming over the horizon.  The level of investment by providers doesn’t bear ignoring.  IBM, Google, Amazon, Microsoft and others are ploughing hundreds of millions of dollars building out data centers specifically for Cloud Computing.
  • You may just end up working for the Cloud Provider!  This is something I believe will start happening in the next 2-3 years.  If you need a second opinion, go see Richard Bejtlich’s blog when he shared his own perspective.

What say you?  Hype or pending reality?

 

Security In The Cloud: Introducing Cloud Mashups

Cloud Mashup

“Security in the cloud” just got more complicated with the introduction of “Cloud Mashups”.

What Do You Get When You Cross Salesforce.com and Amazon S3?

The answer we are told is Appirio Cloud Storage - a fully integrated Salesforce.com add-on that uses Amazon’s Simple Storage Service (S3) to store larger files. Previously, Salesforce.com users were limited to 5MB file uploads.

Read this quote from Appirio and think about it from a security perspective:

We’re excited not only about the service itself, but also what it represents. It shows where the industry as a whole can head - as the platforms mature, there is a substantial opportunity for ISVs to tie together the different clouds and provide offerings that extend and fill in the platforms themselves. In traditional enterprise application integration (EAI), packaged integrations were difficult to commercialize. The permutation of versions and customizations created and “n times n” problem, making it too expensive to create something “packaged” that appealed to more than a very small number of customers. But in the cloud, because SaaS providers commit to stable interfaces - Salesforce has maintained backwards compatability for more than a dozen revisions of its API - “integrating the cloud” can become a new class of solution.

From a security risk assessment perspective, you now need to factor in 3rd parties that hook into your “primary” cloud providers API.

If your company goes with Appirio, company data is now stored in Amazon S3 buckets paid for by Appirio, instead of storage paid for by Salesforce.com. This means your data is actually split across both providers (!) - old attachments and CRM data with Salesforce.com and new attachments with Appirio (if someone from Appirio is reading this and can say differently, please do).

As it happens, Salesforce.com already uses Amazon for computing and storage so its the same back-end storage. But what happens when another cloud storage provider pops up that offers a better deal? Lets say salesforce.com stays with Amazon S3 but Appirio migrates to the new player to attract more customers.  [Just to be clear, not picking on Appirio here - this applies to *any* ISV - particularly those that store data somewhere else in the Cloud].

Multiple cloud storage providers for a single app, raises some issues.

  • Is ISV obligated to tell you they are migrating to a cheaper cloud storage provider? (think cross border data transfer issues).
  • What security ‘certification’ will take place of the new provider and what visibility will you have of that?
  • How much notification do you get before the switchover?
  • If you don’t want to go with the new provider, but that is the only supported option, what happens to all your data? Even if we *assume* an export function is provided you still need to find an alternate ISV that has coded a compatibility layer to access your existing data. If you can’t, where do you export the data too? Will we have ‘frozen clouds‘?
  • What integrity checks take place to ensure data was properly migrated over?
  • When the migration happens, what clean-up happens at the source? (can anyone say forensic wiping?). What about any backup tapes or off-line copies? Who is responsible for making sure those are wiped/destroyed?

Suddenly your cloud storage arrangements have gotten more complex and thus, less secure. Security issues aside, how does an agile business cope with this? With multiple providers, data portability becomes a real issue.

And we haven’t even dug into the API level security issues yet! (yeah, you get to assess that too!).

As an Information Security community, we have to start figuring out some of these issues before we find our options severely limited…

What do you think?