Last week I wrote that compliance and complacency are major challenges in the cloud. Yes, defensive technology is the same. However, the cloud poses some specific threats.
Multitenancy scares people the most. You share cloud infrastructure with other customers. Your cloud services are running on virtual machines. Those VMs run on shared hardware. You have no idea who is sharing, or how many, but you know they’re there.
Worse yet, all this is built on platforms that weren’t designed for strong isolation. The CPUs, GPUs, cache architecture, memory controllers, none were designed for multi-tenant use.
Now, I think this gets overblown. People fear that the Chinese military will run a VM next to theirs. What’s more, the threat will know this. Even worse, the threat will somehow pick where their VM runs.
In reality, major public cloud providers host an enormous number of small business websites. Or, your VM might run next to isolated columns of hotel chain databases. Or, scientific compute jobs. You have no idea. Additionally, you have no control.
I think it’s good to know about data leakage through CPU caches. But, it’s not good to obsess about that. I have links to further details here, if you’re curious about these so-called speculative execution attacks.
The paper “Clusters of Re-used Keys” has some startling information. They found large numbers of Internet servers with identical cryptographic keys. Also see “Mining Your Ps and Qs: Detection of Widespread Weak Keys in Network Devices“.
These authors didn’t speculate much about exactly how this came to be. However, I suspect that some, possibly a large percentage, are poorly built VM images at cloud servers. Most of the rest will be unpatchable Internet-connected devices.
When an SSH service starts, it checks whether the host has a key pair. If not, it generates one. Then, it’s ready to use that to negotiate shared keys for connections.
I have used Linux and FreeBSD VMs on Amazon and Google. Those providers do a good job of building images. Their VMs generate key pairs as needed. Better yet, there aren’t any old authentication keys lying around.
However, Amazon’s collection of public images includes some dangerously old and unpatched systems. Also, it has some real junk. I can’t blame Amazon too much. If someone wants to pay to store and run bad machine images, why not accept their money? It just seems the bad images should have stronger warning labels.
Cloud sprawl describes the situation when an organization’s cloud instances and servers have gotten out of control. Or, more to the point, things have gotten so large and complicated that you aren’t sure that it is under control.
Worse yet, shadow IT is when groups and individuals buy their own cloud services. All it takes is a credit card, and it can be cheap. Now you think you know where your data is. But, that might be an old copy no one uses. The real data might be somewhere your IT department doesn’t know about.
This is the biggest problem for most organizations.
When you move data or an operation into the cloud, you give up some control and visibility. Even if it’s an IaaS cloud solution, the cloud provider controls the physical infrastructure. Even if you pay significantly more to know and even specify some details, they run the facility, the connectivity, the hypervisor, and the compute hardware.
However, you are still accountable for:
In the U.S., depending on the sector of your business or government agency, you must comply with HIPAA, SOX, GLBA, or others.
If you’re in a U.S. Government agency, then you must also comply with FISMA, FedRAMP, and the NIST SP 800-* series.
There has been the EU Data Protection Directive. Officially, that was Directive 95/46/EC.
Now that’s replaced by GDPR, the EU General Data Protection Regulation.
If you handle credit or debit cards, you must follow PCI DSS, or the Payment Card Industry Data Security Standard. It’s not a law, but it might as well be. “Do it this way, or you can’t accept card payments.”
Then there are the many ISO/IEC standards documents. Some (like 27001, 27002, and 27034) apply to any cyber security setting. Others are specific to the cloud. Check out 27017 for security guidelines and control for the cloud. Also, 27018 addresses privacy in the cloud.
SAS 70 used to be the standard auditing report. That was replaced by SSAE 16. Then, in turn, that was replaced by SOC 1, SOC 2, and SOC 3. SOC 1 is mainly for financial auditors and potential investors. SOC 2 reports in detail on security and privacy controls. Finally, SOC 3 is for current or potential customers. It’s basically a pass/fail report on SOC 2. You tell the market “See, we’re careful!” Meanwhile, you keep the security details to yourself.
Then there are the various roles referenced in these various law, regulations, rules, and guidelines. Who in a given scenario is the data subject, data owner, data controller, data custodian, data steward, and data processor?
Cloud providers make their services easy to use. You will probably start with a graphical dashboard in your browser. Then there are command-line interfaces like Google’s Cloud Shell and Amazon’s CLI. Programmers will use provider APIs in a variety of languages.
It’s easy to deploy and control cloud resources.
It’s much more difficult to maintain compliance, especially when you can’t see or control everything.
Learning Tree’s course 1213, CCSP Training, prepares you for the (ISC)2 Certified Cloud Security Professional exam.
It’s a test-prep course, so it’s definitely not about how to use the technology. There’s nothing about the dashboards, or command line, or programming. However, it has a great explanation of the various standards and compliance issues.
Many exam questions use scenarios. It describes a situation. Then it asks what you must do for compliance. That’s good practice for the exam. But, it’s also a good introduction for doing this for real!