InfoSec perspective on public clouds
My colleague, Adrian, made a great post about Public and Private clouds. Aside from the Operations implications, his post also got me thinking about the Information Security perspectives.
1) Figure out what InfoSec controls your CSP provides; be prepared to build/buy the rest.
Developers and DevOps teams need to bake security controls into their apps in the Public Cloud. Every IaaS Cloud Service Provider (CSP) SLA I've read basically says that they provide security controls to protect their infrastructure -- not yours. If your app gets popped and the attacker gains a shell on your VM, or if your data gets compromised because you failed to detect and prevent a SQL injection or similar attack, that's your problem. You need to bring along the right detective and preventative controls with you to the Cloud.
Figure out what security controls the CSP brings to the table, then go back to your risk assessment and build/buy to satisfy the residual risk on the table. Network firewalls and VLANs, network IDS/IPS, host IDS/IPS, application-layer firewalls, security event monitoring and correlation capabilities, strong authentication/authorization, etc. It starts with your risk assessment -- moving to the Cloud doesn't diminish this core capability. In fact, it makes it even more important because your CSP has effectively transferred much of that risk to you.
2) Keep your developers and DevOps staff aware of security threats and trained in defensive coding techniques.
In The Cloud, your VM and application are probably more exposed than they were back in the DataCenter. Some CSPs may only provide a thin network firewall between you and the big bad Internet. Moving to The Cloud has implications on availability, data persistence, etc, etc -- it also means that security controls need to be baked into your VM image and application. If you rely on Operations Security controls to keep your app secure ("we have a firewall, aren't we safe?") then you really need to up on secure coding / defensive coding techniques.
Information Security isn't a destination, it's a process. There's no "silver bullet" except perhaps continuous education and awareness of the bad guy threat and the vulnerabilities of your OS, libraries, and applications. If your developers roll their eyes when you talk about the need for security awareness and training, you need to find a way to make this work and keep them educated without FUD lectures and vague threats. You need to become entrenched in what they're doing and stay informed on changes to the system. Then you can make relevant contributions about what your business' actual risks are.
3) Build InfoSec controls into your applications and infrastructure from the start.
As development teams take on operations responsibilities, this is a fantastic opportunity for InfoSec staff to train and work with developers (and/or DevOps) more closely on a continuous basis. There's a lot of great information embedded in error logs, for example. Having the right data logged within your application means your InfoSec detection, prevention, and response capabilities will be crisper from the start.
Assume attackers will poke at your application. Assume that some will be successful. Create the right level of logging and reporting during the design phase. Re-evaluate and improve them in each release cycle.
If you're building your own AMIs and OS images as you move to The Cloud, this is a great time to look at Host Intrusion Detection/Prevention System (HIDS/HIPS) capabilities. Linux and Windows have competent host firewalls. There are great open source HIDS alternatives that have detection and response capabilities, there are open source Web Application Firewalls too. Find an option that meets your needs, make it scalable and manageable for your environment, and start putting security controls close to your application and data where they belong.
This blurs the traditional lines of "application logs" and "security logs" -- and this is a good thing IMO. Use the information from your security controls in your application, and vice verse. SIEM is expensive but powerful tool -- perhaps this is an opportunity for CSPs to provide SIEM functionality as part of their offering.
3) Include the CSP in your Incident Response plan
Understand how you and your CSP will interact during a Security Incident. If possible, get this in writing, in your SLA. During an Incident, that is not the time to find out what logs they won't share with you or how much investigative assistance they are willing to provide. Practice your IR plan with your CSP and your developers/DevOps staff -- they have the freedom to play in Cloud operations, and Incident Response is one of the responsibilities.
Interesting products, no affiliation or endorsement should be inferred:
