We recently moved workloads to the public cloud and the public cloud reality does not match the hype, nor does it match the application security requirements of a small or even large organization. There are two sides to the public cloud security discussion, the one that covers management access and the other that covers application security. For the former, you must trust the cloud, however for the later, you basically get the security you bring to the cloud. The public cloud reality is that you do not magically gain application security when using a cloud.
There are two sides to the infrastructure as a service (IaaS) public cloud that need to be addressed and we have been addressing on the Virtualization Security Podcast. The first is management security where we are concerned about the cloud seeing and manipulating our data. The second is application security where we are concerned about normal attack methods. So how do you address each of these?
Public Cloud Reality: Management Security
Unfortunately, in the realm of management security, you are really in the hands of the public cloud. You must trust their APIs, their portals, and their administrators. This has been the same since the first day of the cloud, and things have not improved much. When we talk about public cloud security, this is the nature of the conversation. We ultimately have to Trust. Even with such tools as High Cloud Security and AFORE Technologies, in some clouds it is nearly impossible to prevent the cloud administrator from seeing your data.
In some clouds, using High Cloud Security or AFORE Technologies would keep administrators from seeing your data from casual viewing, as those administrators cannot log in to your workloads. A typical precaution as the data is encrypted at rest. However, with other clouds, they leave a backdoor and if you do not keep it open, you do not get support. Support in the public cloud is a necessity. This access, can be under your control as well and should be. If you can find the backdoor lock it down and only open it up as needed. Such as a break glass situation.
So how can you improve public cloud management security:
- Always access the public cloud from a well known system (your tablet for example at the coffee shop is NOT a well known system. Do you trust the Wifi signal and everyone attached to it? Perhaps this where Bromium could assist (once they support tablets)
- Encrypt your data at rest using High Cloud Security, AFORE Technologies, or Trend Micro Secure Cloud. This covers casual view as well as disk failure concerns. You can also use tools such as Bitlocker and TrueCrypt to achieve the same type of encryption but you if the workload reboots you may have to type in a password. Availability would be a concern here.
- Lock down any back doors the cloud provider leaves behind to aid in support. One cloud actually requires root access to assist you, instead of using a support account. This to me is just a bit too much trust. Follow the Salesforce approach. Grant access on an as needed basis for a length of time (if you are using Linux, the plug-able authentication module (PAM) limits module is a great way to go for this.)
Public Cloud Reality: Application Security
In the public cloud the extent of application security is usually a firewall. Not even an application specific firewall, just a plain-Jane firewall you cannot even control. There may be, if you are lucky, denial of service mitigation on the firewall. Application security therefore becomes a major issue within the public cloud. The reality is that it is only as good as what you bring to the cloud. The workloads within an IaaS cloud run on an OS that is provided to you. That OS may or may not be hardened (in most cases NOT). Then you layer an application on the OS that may or may not be hardened. If you use a specialty cloud built for your application then security may be inherent. Such clouds exist for SAP, Oracle, WordPress, Exchange, etc.
However, in the public cloud, there is no specialization, you need to consider all aspects of your own application security. You need to understand your operating system security and how workloads talk to each other. Will traffic from those workloads be talking on any other networks, etc? Application security is in your hands. As part of putting our workloads into the public cloud we came across this same issue. Our workloads were not secure by default.
How do you manage application security within the public cloud? Bring your security measures with you! I.e.
- If you harden the OS within your data center, on migration to the cloud, harden the OS once more.
- If you use a application specific firewall within your data center, use it within the cloud.
- Harden the Application in the cloud
- Lock down access to the application from unknown sources (for application management)
- Ensure your network is on its own VLAN (at the very least) but its own network segment would be ideal.
- Use internal networks (non-public facing) for inter-workload communication.
Public Cloud Reality
The security of the public cloud is in your hands. Yes, the underlying environment is probably more secure than your local data center, however you will want to work with your public cloud provider to get some compliance report that shows you, your expected level of security. But the public cloud reality for IaaS is that your applications are only as secure as you make them. You bring the security, it is not provided for you UNLESS you use an application specific cloud.
If you move workloads to an IaaS based public clouds, ensure your security measures are in place for those workloads starting with the security of your underlying storage, working up through the operating system, to the application itself. Ultimately, you need to pass the compliance audit, not the cloud, so bring your security with you.
Public Cloud Reality: BYOS (Bring your own Security)
Share this Article:
Latest posts by Edward Haletky (see all)
- Moving Up the Stack Does not Really Simplify Anything! - September 13, 2016
- VMware Shows a Way Forward - September 7, 2016
- Containers: Distributed Disruption - August 30, 2016