Cloud Security: To patch or not to patch…
Time to continue with our important Amazon Web Services best practices from the Gartner paper on Cloud Workload Security. Actually, time is at the heart of this top tip.
Picture yourself April 1, 2014. The Heartbleed vulnerability is disclosed. It allows attackers to pull potentially sensitive information from memory using a flaw in the SSL handshake of any application using OpenSSL. The library OpenSSL is baked into many applications worldwide!
What do you do?
First, you need to know if you are affected. Vulnerability scanning, either network-based or privileged, can help identify impacted workloads. But then what? Now, this is where we fully agree with the experts at Gartner and recommend something that I’m sure goes against most organizations’ operational methodology: Don’t Patch. That’s right… don’t patch the live system!
We don’t mean, do not fix the vulnerability and leave your server exposed. What we mean is: don’t apply potentially disruptive patches to live systems.
Instead, apply the patch to your template and conduct testing before deploying. In our last tip we talked about baking in security from the start and how you can dynamically or statically build your new servers. Having this pipeline and the ability to test reduces your chances of patches disrupting operational systems. Again, the key is automation to ensure you have a pipeline to rapidly build and test new environments for your applications.
But what about the vulnerability? The clock is ticking…
This is where virtual patching, through a software IPS like Deep Security, can help find the vulnerable instances and close that window of vulnerability. Applying a virtual patch allows you to prevent exploitation of the vulnerability quickly and safely. This stops the potential of data exfiltration, or intrusions on the system in its tracks.
This fundamentally changes the operational model. Servers in the cloud are disposable, it’s the data that matters. Stop hugging your servers and open up the options of zero-downtime migrations with techniques like green/blue deployments.
Not all workloads take well to this model, for instance legacy applications that have been lifted-and-shifted to the cloud. In this case you still apply virtual patches to your production workloads while testing the patches on a staging set of instances. However, the stateless server model is ultimately what you should be aiming for and evaluating your purchases against.
For more on how to respond to vulnerability and perform both the initial response and long term repair, check out Mark Nunnikhoven’s talk from this year’s AWS re:invent.
Interested in learning more best practices for securing AWS workloads? Read the Gartner paper on best practices for securing AWS workloads.
If you have questions or comments, please post them below or follow me on Twitter: @justin_foster.
from Trend Micro Simply Security http://ift.tt/1GLr0vX
via IFTTT