There are threats to the cloud and there are risks within the cloud. A recent article from Tech Target Search Security blog spurred several thoughts. The main claim here is that there are not enough people who can differentiate threats and risks enough to talk to business leaders who may know very little about security, but do know the business. I have been known to state that there are prominent threats to my data once stored in the cloud and that we should plan to alleviate those threats to reduce our overall risk. But what is the risk?
An analogy comes to mind. Many years ago I ripped my Achilles tendon, and while talking with the doctors they all said that without surgery there was a 50% more likely chance that the Achilles tendon would rip again. So this got me thinking about what they really meant, 50% of what? My next question to the doctors was “how likely is it to fail if I do not have surgery?” Their response was enlightening, there is a 2% failure rate for naturally healed Achilles tendons. Because of that number, I realized that the failure rate for those tendons that undergo surgery is really only 1% vs 2% without. Well that put a different picture on everything. I went without surgery as that particular area of the body has very thin skin, not as much blood flow, and would take a long time to heal from surgery and there was always the risk of picking up something in the hospital, however remote at the time.
So the real question is what is the true risk to an environment if the threat becomes a reality?
Threats
When it comes to threats, many security folks focus on the technical aspect of the threat, not how it will ultimately impact a business. We know for example that SSL MiTM attacks a2re trivially easy to perpetrate under the proper circumstances and we know the proper circumstances but are security professionals concentrating only on the technology, yes it is cool, and I will be the first one to say I do concentrate on the attacks. So what are the common threats to the cloud environment.
- Escape the VM Issues (most of these have not been implemented in the wild)
- Application Faults (most of the world runs via the web, web based attacks are prevalent)
- Access Issues (this is where the SSL MiTM attacks are prevalent and who can access the data)
- Data Integrity/Confidentiality Issues (ownership of encryption keys and who has access to the data)
- Data Leakage Issues (such things as being able to look at CPU registers and caches to determine encryption keys, etc.)
- Source Code Leakage Issues (will leakage of source code cause security issues, such as the recent vSphere source code leakages)
The real question is not whether the threats are real, they are, but whether or not there is an impact to the business, and there is. This is where Risk assessment comes in and methods to mitigate and report that risk.
Risk
So how do we take the list of threats and delve down to see if we are really at Risk for attack. Well for starters always assume you are at risk of attack. The real questions are how good are you are preventing the threats or mitigating the risks? and how much will such prevention and mitigation cost in the long run vs how much would be at risk? The best measurement whether that be dollars and cents or lack of prestige depends on the business and specifically those in control and how they respond.
I can for example say you are risk for SSL MiTM attacks, but perhaps I really should say it will cost X dollars to mitigate this very real risk, then perhaps demonstrate how easy it is to perpetrate the attack in the wild. This is the low hanging fruit of Risk, the easy to demonstrate in the wild. However, there are several class of attacks that are very hard to quantify:
- Those that seem to be pure research, such as the El Gamal encryption key data leakage in virtual environments.
- Those that are unknown-unknowns, such as zero day attacks, code leaks, etc.
How do you explain this risk to higher ups? Perhaps it is better to assume we will be attacked successfully and that our data is at risk. Once we accept this fact we can get on with real protection. This is our goal as security professionals.
Planning
We need to plan for attacks being successful even though we rather they were not, to plan properly we need to fully understand the data that could become at risk. For example, if all we store in the cloud is unclassified public data, should we worry about it? So how do we approach risk analysis and how do we approach this with the people who hold the purse strings?
- Know your data
- Know the value of your data
- Know where your data resides
- Know the jurisdictional issues surrounding your data
- Know the Data Security and Protections required
- Know the access requirements for your data
It ends up all about planning but more importantly it ends up all about the data. What level of protections do you need for your data and access to your data? Why separate access vs the data itself? Because data security is really about digital signatures, encryption, availability, backup and recovery while access covers end user computing devices, networks, clouds, and all those machines you have to traverse to finally reach the data. Where ever there is a connection there is a chance of attack and we need to plan the access around that while providing data security. We need to plan for the unkn0wn-unknown
Compliance
In all the above, not once was compliance mentioned, and that is because security is very different than compliance. Security needs to move at the speed of the network while compliance moves at the speed of legislation. Yes be compliant, but realize compliance is not necessarily about security. Take HIPAA for example, all you need to do to allow a third party to possibly look at medical data is ensure they understand the responsibility involved with looking at medical data and assume the responsibility for the data, which implies securing the data. Well, that just takes signing a document and does not require an audit of the environment in which that data will reside. An audit for security not compliance.
Even so, Compliance is a big deal, so speaking about security in terms of compliance is a big win. Compliance fines can be huge.
The Cloud Conclusion
Getting data into and out of the cloud securely is the key to good data hygiene within the cloud. However the term securely depends entirely on your organizational definitions of security and NOT the cloud’s definition. You have to live within your security policies as the data enters the cloud. In this case knowing your data is crucial. It is also crucial to understand the risk to your data. The real risk, not the FUD spread about various services. For some, given the nature of the data Dropbox is just fine. But for others they may instead put an encrypted container within Dropbox to which they write all their data. Thereby gaining even more security for crucial elements while making use of a well known cloud service. This best practice of encrypting the data before placing it into the cloud also mitigates the current encryption key data leakage research.
Nearly everyone uses the cloud today, and that implies your corporate data could be within the cloud, as people want to get their job done easily. Therefore they may use a cloud service you do not know about and place the data within it. Take a simple iPhone device, we could have data in iCloud as well as Google and other cloud based applications. Even a phone list could be considered valuable.
Think about the value of your data when determining risk, think about the data itself. Think less about the technology but communicate the risk effectively to those who may not be as technical. However, do not just discount theoretical sounding attacks. Plan for unknown-unknowns by following best practices and be fluid when those practices change.
Do you know how your data is protected?