We’ve known it all along, but it’s nice to get official recognition as the cloud security leader. It’s been verified by TechNavio in their Global Cloud Security Software Market report.

But beyond this obvious great news, the report is actually quite informative and talks about five major trends in the market:

• Increasing Partnerships Between Cloud Service Providers and Security Solution Providers Expected
• Increasing Emergence of Cloud Service-specific Security Solution Providers
• Identity Management and Encryption to Remain the Top Cloud Security Solutions Offered
• Increasing Availability of Cloud Security Solutions for SMBs
• Emergence of Strong Cloud Security Standard and Guidelines

View the full report here.

Trend Micro is putting on a pretty cool, free event for virtualization and security industry leaders.

We’re doing interactive roundtables and presentations to help IT people learn how to protect your data when using new innovative computing environments represented today by virtualization and cloud architectures.

Our presenters will share how progressive business and IT leaders are accelerating their paths to cloud computing with confidence without sacrificing availability or service quality — and at an improved cost of ownership.

We have some serious experts coming to present, including the Trend Micro CTO and experts from Bank of America, eBay, and VMware, along with the Chairman of the Cloud Security Alliance.

VMware Security Specialists
Ana Seijas, Keith Luck,
JJ DiGeronimo
CSA Executive Board Members
Co-Founder, Jim Reavis
Sr. VP at Bank of America, Jason Witty
Chief Security Architect at eBay, Subra Kumaraswamy
Global Security Expert
Kevin Walker
Trend Micro
Raimund Genes, CTO
Tom Kellermann, VP of Cyber Security

If this is up your alley, it’s worth your time to attend these:

New York – Register >
May 3, 2012

Chicago – Register >
May 8, 2012

San Francisco – Register >
May 10, 2012

You can hear the entire panel here.

The topic was Privacy Issues, Reliability Questions, Security Concerns in the Cloud Computing Space, and the panel included:

• Dave Asprey, VP, Cloud Security, Trend Micro
• Tom Mulally, Consultant, Numagic Consulting
• Graham Oakes, Chairman, Digital Watermarking Alliance (DWA)
• Rajan Samtani, SVP, Sales & Marketing, Peer Media Technologies
• Dan Schnapp, Prtnr. & Ch. of New Media, Ent. & Tech., Hughes, Hubbard & Reed
• Yangbin Wang, CEO, Vobile
• Marvin Wheeler, Chairman, Open Data Center Alliance (ODCA)
• Vic Winkler, Author, “Securing the Cloud”
• Moderator: Marty Lafferty, CEO, DCIA

Perhaps my biggest takeway from the show was that broadcasters have a very ambient-friendly view of the cloud. Rather than picturing data centers or centralized clouds, their content is “in the cloud” if it’s out of their hands. The difference between their content being on an iPad vs. on Amazon Web Services is often lost.

As a cloud purist, this bothers me. But as a huge fan of the ambient cloud, I think the broadcaster view is more realistic. Whether your content is on a CDN or on a distributed network of end devices with DRM, it’s still your content. The nuanced difference between content protection and cloud protection definitely showed itself on the panel.

To see why this can happen, it helps to understand how courts interpret the Fourth Amendment to the US Constitution, which provides that the people shall “be secure in their persons, houses, papers, and effects, against unreasonable searches and seizures…” (The Electronic Frontier Foundation has a great write up on this in their Surveillance Self-Defense write-up.)

It also provides a method for an unreasonable search to be called “reasonable” and, therefore, constitutionally valid. It’s called a warrant, issued “upon probable cause, supported by Oath or affirmation, and particularly describing the place to be searched, and the persons or things to be seized.”

So that means law enforcement ought to justify itself before conducting invasive searches, and if they don’t, what they find is inadmissible in court. But a warrant isn’t necessary when items are in plain view, or when a person consents to being searched.

Leave it to the courts to figure out when a search requires a warrant. They found that law enforcement requires a warrant if you had a “reasonable expectation of privacy.” That was before the cloud, back in 1967, involving wiretapping of a phone booth, and that’s where Google’s problems begin.

The court’s “reasonable expectation of privacy” test says you had to have a reasonable expectation that your stuff was private, but that it also must be something that society itself would objectively recognize as reasonably private. So you had to think it was private, and everyone else has to think it would have been too. Don’t forget this requirement, as it’s the one that is going to smack Google upside the head.

The “third-party doctrine” interpretation of the Fourth Amendment is the one that could have spelled doom for the modern cloud. That interpretation says that if your data is at a third party, it’s not protected by the Fourth Amendment. Ouch. The classic example here is that police do not need a warrant to know what calls you made because the call record data is held by a service provider. What you said was private; that you made a call is not.

Let’s generalize this to the cloud. Historically, Dropbox and Microsoft’s SkyDrive and Trend Micro’s SafeSync let you keep your copyright and IP rights to the files you upload to their cloud storage. This is a sane and normal approach for businesses. If you keep your own copyright to things you put in the cloud, you can argue that you had a reasonable expectation to privacy, and your cloud files are subject to Fourth Amendment protections even though they are at a third party cloud service.

Leave it to Google to launch a service with terms of service that break this dynamic. Look at these terms of service differences. Italics are mine. (thanks Cnet for gathering these links!)

Dropbox — terms here:

“Your Stuff & Your Privacy: By using our Services you provide us with information, files, and folders that you submit to Dropbox (together, “your stuff”). You retain full ownership to your stuff. We don’t claim any ownership to any of it. These Terms do not grant us any rights to your stuff or intellectual property except for the limited rights that are needed to run the Services, as explained below.”

Microsoft’s SkyDrive — terms here:

“5. Your Content: Except for material that we license to you, we don’t claim ownership of the content you provide on the service. Your content remains your content. We also don’t control, verify, or endorse the content that you and others make available on the service.”

Google Drive — terms here:

“Your Content in our Services: When you upload or otherwise submit content to our Services, you give Google (and those we work with) a worldwide licence to use, host, store, reproduce, modify, create derivative works (such as those resulting from translations, adaptations or other changes that we make so that your content works better with our Services), communicate, publish, publicly perform, publicly display and distribute such content.

The rights that you grant in this licence are for the limited purpose of operating, promoting and improving our Services, and to develop new ones. This licence continues even if you stop using our Services (for example, for a business listing that you have added to Google Maps).”

“Don’t be evil, unless it’s convenient.”

Google, WTF? Your terms of service for Google Drive absolutely destroy any argument that content uploaded to your cloud storage service has a reasonable expectation of privacy. Therefore, data on Google Drive is not subject to subpoena and is clearly open to viewing by law enforcement under the Third Party Doctrine.

But wait, it gets better. Google is one of the largest cloud providers on the planet. Once Google decimates Fourth Amendment protections for their cloud storage, how long will it take for law enforcement and courts to make the argument that all cloud storage shouldn’t be protected by the Fourth Amendment? Not long. Google is a large corporate citizen, large enough to set precedent with their actions.

Here’s hoping the EFF shames Google into at least being less evil. In the meantime, I’m sticking with SafeSync.

Today pundits bandy the same term about, but this time they are talking about mobile apps, and in particular a storm that erupted earlier this year around iOS applications which take data from user address books without user consent or even knowledge.

The issue first came to attention in early February when a developer discovered that a social app known as Path was exfiltrating pretty much all the data from user address books – full names, email addresses and phone numbers – as a matter of course and sending it back to the Path ‘home’ server without asking users’ permission.

After members of Congress picked up the issue and  contacted Apple to ask why this was being allowed, a whole heap of app providers including Foursquare, Hipster and the recently acquired Instagram hurriedly amended their software so that it flashed up a user permission message in such situations.

For the record, Apple told the lawmakers quite correctly that “apps that collect or transmit a user’s contact data without their prior permission are in violation of our guidelines”. This obviously didn’t stop some unscrupulous or absent minded developers from ‘forgetting’ this particular guideline in the past, however, and Apple said it will address this in a future software release.

Android, so often second best when it comes to comparing the security and privacy features of the two most popular smartphone platforms around, already has functionality to force developers to ask a user’s permission if their app requires access to the phone’s address book.

I would argue, though, that there is a more fundamental security issue at play here and it revolves around basic human behaviour – most users either don’t know enough or care enough about their phones and what could happen to their data to make the pop-up permission box a satisfactory solution.

Even in these privacy-conscious times, users will often click through whatever messages they get on their phones – they just want to get to the good stuff and start enjoying their apps.

Add to this the fact that the small message on a smartphone screen rarely explains exactly what is going to happen to the data once it is sucked into the cloud – how it is going to be used, where it is going to be used, and whether it will be transmitted and stored securely – and you have a situation of what I’m going to call “oblivious data loss”.

There are several security and privacy risks here, of course, not least the implications of BYOD smartphones in the enterprise with data hungry apps downloaded on them inadvertently exposing the confidential details of colleagues, clients and business partners.

At the moment apps don’t distinguish between groups when asking user permission to access the iOS address book, but even if they did, users may accidentally save a new business contact in their personal instead of corporate contacts group, and then allow an app access to the former, again resulting in oblivious data loss.

In a worst case scenario, then, exactly what are the risks of oblivious data loss?

Well, many apps are keen to stress that any information will be sent up to their servers ‘securely’, while not specifying exactly how this achieved. But even if it is sent securely, it’s probably more important what happens after that. Is it being stored in plain text form? Are the developer’s databases secure? How secure?  Who is allowed to see it? Under what circumstances?

Even if the reason for copying user data is innocent in the first place, which it usually is with reputable apps, there is no guarantee that the data will remain safe wherever it ends up. It’s even worse if the data is stored in plain text, as Path was found to be doing.

At the end of the day most developers just want to build the most user friendly, compelling application possible and if it’s social, they want to find all the people in your address book and use that info to improve your experience on the app. Oh, and maybe make a billion dollars along the way…

It’s unfortunate that more of them don’t use a technique known as hashing, by which they could effectively anonymize this data, which would make it next to useless for any criminals who might get their hands on it. Even better yet, these cloud providers should be using policy based key management and strong encryption to protect the precious (to someone) data they copy.

If the group or individual behind an app has more malicious intent, of course, then the kind of oblivious data loss we’re seeing at the moment will enable them to mine a rich seam of personal information with which to launch phishing scams or other social engineering-based attacks.

Then there is the question of what happens when or if a company is taken over by a third party. What will happen to the user’s data then? Don’t assume that it will be destroyed or even that your rights will be preserved.

It gets legally murky very quickly when a user obliviously leaks corporate information through a cloud based mobile app. The terms of use of the cloud service may explicitly make claims on legal ownership of the data – terms that are at odds with your enterprise rules or even regulatory guidelines. The data is probably yours if you go to court, but the social network can argue the data is theirs – and act that way – until you have enough legal muscle to stop them. This may be a non-issue for directory information, or it may be a real problem if your directory has the mobile numbers of your Board of Directors. Once the data is out of your hands, your choices diminish greatly.

One of the most challenging aspects of this oblivious data loss problem is that there is no easy solution. What makes the whole thing a lot more tricky is that even if an individual is super careful with their own address book, how do they know their own information is not being sucked up into the cloud by countless applications on their friends’ phones?

Apple certainly has to make a start by enforcing a rule that developers wanting to access the iOS address book must ask users’ permission, but developers also need become more attuned to the privacy requirements of their users and start to store data more securely.

In the end let’s hope we’re not still talking about this wild west of oblivious data loss to the cloud in five years’ time.

So one has to ask: considering the financial and legal implications of a breach of health records, why don’t organizations deploy security solutions to protect electronic health records? Answers often offered by CIOs are (1)ROI – show me the ROI on an investment in security solutions. Does it lower my cost of doing business? Does it bring me new customers? (2) Compliance / HIPAA?  “Yawn…  is there a way around this regulation? Can we give the compliance auditors, the minimum they need at the lowest cost, so we can get on with business?”

“Mr/Ms CIO, I would like to introduce you to our CFO, he/she will educate you on the costs of doing business in today’s electronic age…”

The costs of a breach can be quantified as:

1. Financial: notifying affected individuals and increased insurance premiums.
2. Reputation: loss of current patients and difficult attracting future patients.
3. Operations: cost of training staff to prevent future breaches.
4. Legal: fines, penalties and lawsuits.
5. Clinical: fraudulent medicaid and insurance claims that may be submitted from the stolen data;inaccurate diagnoses because data is missing from the electronic health record system.

Take the cost of a breach and turn that into the cost of an investment – the cost of an investment in security software solutions that lower the probability of a breach occurring. (In layman terms:  the cost of a burglar alarm or barbed wire fence that will make it more difficult for thieves steal your jewels). For electronic health record data stored in the cloud, software security solutions should include firewalls, intrusion detection/prevention systems and  data encryption so that even if the data is stolen, it is useless to the thief.

I completely agree with the post.  Risk tolerance assessments and adherence to audit standards  are essential elements of any quality data security program. I would argue though, that if the customer is following compliance and audit requirements then there is only one place keys should be stored: physically separate from the storage or infrastructure provider and under the direct control of the data owner.

A closer examination of four key compliance guidelines reveals:

1. COBIT : “COBIT is an IT governance framework and supporting toolset that allows managers to bridge the gap between control requirements, technical issues and business risks.” For management of encryption keys, COBIT states:

Verify that written procedures/policies exist,…. transporting, storage; recovery; retirement/destruction; theft and frequency of required use. Included with these procedures should be requirements over securing the key and controlling the elevation of the key…. Keys should be maintained on a computer that is not accessible by any programmers or users, such as router controls for logical access and strong physical controls with an air gap in a secured area/room.

2. PCI

The Payment Card Industry guidelines only specify that appropriate procedures should be documented, little guidance is provided for where keys should be stored.

Encryption keys used for encryption of cardholder data must be protected against both disclosure and misuse. All key  management processes and procedures for keys used for encryption of cardholder data must be fully documented and implemented.

However, PCI DSS 2.0 states in section 3.6 defers to NIST

3.6 Fully document and implement all key-management processes and procedures for cryptographic keys used for encryption of cardholder data…. Note: Numerous industry standards for key management are available from various resources including NIST, which can be found at http://csrc.nist.gov.

 3. HIPAA The Health Insurance Portability and Accountability Act in their breach notification rule  calls out

 “Protected health information (PHI) is rendered unusable, unreadable, or indecipherable to unauthorized individuals if one or more of the following applies:

1. Electronic PHI has been encrypted as specified in the HIPAA Security ……  To avoid a breach of the confidential process or key, these decryption tools should be stored on a device or at a location separate from the data they are used to encrypt or decrypt.  The encryption processes identified …. have been tested by the National Institute of Standards and Technology (NIST) and judged to meet this standard.“

4. SOX Sarbanes Oxley adheres to COBIT  in section DS 5.7:

“Accepted frameworks for use with SOX are COSO and CobiT“ accepts the COBIT framework above for security technology”

 and section DS 5.8 requires

“Dedicated key storage devices and application.

There is a very good reason for this physical division between the key server and the location of secure data stores.  In audit parlance it’s called “separation of duties.”  Separation of Duties, or “SoD”, is an important internal control concept that helps prevent mischief by ensuring an adequate system of checks and balances exists.  More specific to this topic, SoD makes sure that only the data owner can access sensitive information.  The encrypted volumes live with your cloud provider, your keys stay somewhere else and only you have all the credentials to join the pieces.  Whether your key management solution resides in your data center or with a trusted third party, only you control the credentials required to access all the necessary elements necessary to unlock encrypted data.  And control is critical for operating safely in any cloud environment.

In summary four compliance requirements call for storing encryption keys securely and separately from the data, under the control of the cloud consumer.

Many people assume that the ‘Advanced’ in Advanced Persistent Threats means the use of some incredibly new sophisticated malware but typically that’s not the case.  Usually the ‘Advanced’ element is in the research effort and the social engineering to tip a specific target over the edge and get them to click though to a URL of the attackers choosing.  Once the attacker has control of a machine on the inside of the corporate perimeter that can become a launching pad to probe for vulnerabilities on machines not directly connected to the internet.  Often well-known techniques, for which patches have been available for some time, can succeed for the attacker in this situation because machines on the internal ‘safe’ network are not considered to be at risk by many companies.  The human adversary directly controlling the compromised machine has the advantage of time (‘Persistent’) to quietly probe until they discover a weakness they can exploit.

So how should you defend against this targeted attack?  We’ll for me it’s about several things in combination to give you the best shot:

• Reduce noise.

Keep your existing outer perimeter in place and use it to keep out all the bad stuff you can.  That gives you more chance of spotting something happening out of place on your internal network.

• Build perimeter fractals.

A fractal is a mathematical shape that repeats itself on an ever smaller scale, so that as you zoom in you get back to exactly what you started with.  Doing exactly that with your perimeter boosts your defences.  Build another layer or two that has to be breached before you lose critical data en mass.  I would highly recommend deploying something we call virtual patching for all servers which protects ahead of the real patch, and crucially also reports to you when something has tried to exploit a vulnerability.

• Use specialised software to monitor the internal network traffic

Don’t just look outwards to the big wide world or watch traffic crossing your threshold.  Watch also the internal network with Specialised Threat Detection to ensure you are alerted to anything untoward.

• Track back and clean.

When machines attached to your perimeter are being attacked there is usually not much you can do other than block.  But when it’s an internal server that’s being attacked then that attack has to come from another internal machine.  Blocking that attack is gold dust – not just because you blocked it, but vitally because you now know that one of your internal machines is doing something it shouldn’t and you can remediate that before it (or the adversary controlling it) tries a more sophisticated attack which you might not detect.

• Protect your data

If everything else fails and an adversary does get thorough your defences to access critical data than that shouldn’t be game over.  You need a second layer of defences from the inside out which encrypts that data, uses data protection to watch what is exiting the organisation, and understands the contents and the context which they are being used in

• Assume Compromise

The common theme to draw from all of that is to assume that the machine next to yours is already compromised and set your defences accordingly.

It’s that final point, the summary of the preceding six, which provides the link to Cloud Security.  In a multi-tenanted environment (IaaS) you should assume that the machine next to yours is out to get you and defend accordingly.  Your provider will offer many security features: Perimeter Firewalling, IPS etc and Internal Network Segmentation between their customers – all designed to keep you safe – but typically won’t back those us with SLAs in the licence agreement.  Treat all of that as a great thing to reduce noise but assume that stuff may still get at your server or data.  Build your own perimeter around your servers to block anything that your provider misses and encrypt your cloud data so that if your provider misplaces it you are still protected.  With that also gain the business benefit of being able to switch providers to a lower priced or better performing alternative without worrying about the bread crumbs of sensitive data you are leaving behind.

If it’s an Internal (Private) Cloud the same applies.  You’ve bundled services together for cost and operational efficiency and in doing so reduced the separation between them.  Assume compromise and put Virtual Separation into the environment, with perimeters and encryption to restore and even enhance your security compared to the physical model, while taking advantage of an agentless approach wherever possible to retain the efficiencies.

So Cloud Security and APT defence may not be Identical Twins – but they can wear the same clothes!

My belief is that these are intimately involved elements within a larger spectrum of computing, where one can’t separate the two or find a well defined demarcation line between them. And, most importantly trying to keep them separate may impinge the thinking about how to deal with the issues they bring to computing overall.

As an example of current  silo thinking, cloud is often spoken of within a framework of some representative cloud computing system “out there” where remote applications are running, data is remotely stored, accessed on some company provided device, desktop or laptop system. Cloud in essence is a computing environment that utilizes not just private, or public (computing for hire) data centers or systems, but private or public pipes, routers, and other systems data travels through or is stored on. The reality is that cloud has no edge or a line where one can say, this is cloud, and on the other side, this is not cloud. It is a global conglomeration of private and public systems where utilization is traversing during the normal course of business, personal or company.

So, what does this have to do with consumerization of IT? If we think of the cloud as an amalgam of different systems companies and users can take advantage of, the aspect of the invisible edge moves again with the utilization of devices that have been seen more as traditional consumer devices. The movement to consumer type devices, BYOD, has further pushed the portable and dynamic edge of private or public cloud. To further this dynamic environment, the personal devices are now owned and in essence managed outside of traditional IT domain while they access and store information by a consuming public that connects to other consuming publics in a myriad of ways. This can include various applications and social media, so that whether a public works for your organization and uses their device to access your systems or not, all of their linkages to other consumers means in effect their device has exponential links to others uncontrolled by IT, accessing your computing environment. When you then take the devices anytime, anywhere and linkage access that then links to cloud, means that all these linkages are potential open portals to your computing environment, creating in effect an endlessly scalable number of unknown doors to your systems.

This means Consumerization to Cloud is a wide net of computing, points of entry, and escape vectors for unprotected data that organizations can’t totally control because of the endless nature of the links this chain of computing represents in today’s computing world.

Does this mean it is all hopeless, with so much we can’t control, where our data is running, where it is stored, what points it’s accessed from, that we might as well go to the beach and throw sand dollars at some unseen whales offshore to see if they notice us? No, it means, that as professionals, understanding the aspect of all these linkages, what that means our information and that we must address protecting data from multiple aspects. Reducing risk starts with protecting systems regardless of their type or point of entry, either on those systems, or from a point of access to core systems and data. Then the key must be to orient protection from a data centric perspective, with devices and the areas data is traveling and stored are the first layer in protection scheme, with data sensitivity focused on dynamic protection to data itself a primary objective, regardless of whether it is in cloud, on consumer type personal devices, or company systems, data is the king that underpins all of the mechanisms that define what is protected, and how that protection in implement.

The core is to understand the interrelatedness between all computing environments, there are no longer independent systems, clouds, or devices, and once we have a better understanding of that, the better we can protect the core of any business, the data; it’s all about the data.