Last week, Justin covered some of the high level issues around AMI development. This week, we’re going to take a look at how to protect the guest operating system running on your EC2 and VPC instances.
AWS had published quite a few papers around their services. AWS Security Best Practices [PDF] and AWS Risk and Compliance [PDF] stand out as excellent security resources. In the best practices paper, under the section “Secure your Application” (pg. 4), they make a few recommendations which boil down to:
- patch ASAP
- use recommended secure settings for operating systems & services
- test, test, and test some more
These are solid recommendations, so let’s take a look at some of the practical aspects associated with them.
This is a message we hear often in IT. We know we need to patch but it can be a real pain and most of that pain is usually associated with testing. When your application lives in the cloud, you’re not patching live systems so much as your base AMIs which should makes things easier.
You should deploy a new instance of your base AMIs in a test environment, patch those, and then running any required tests. If the patch doesn’t break your configuration, create updated base AMIs. The next step is to schedule the deployment of the new AMIs to production which–depending on your application–might happen side-by-side with the previous version in order to eliminate downtime.
Use recommended secure settings
Most operating systems and services publish a set of suggested configurations. Read them! Also do some research for recommendations on configuration settings from reputable sources. Pull these together and assess the settings versus your requirements. Remember to apply the principle of least privilege, don’t turn on a service or feature unless you absolutely need it.
Test, test, and test some more
With every resource in AWS available via API, there’s no reason not to automate almost all–if not all–of your testing. From deployment status, patch validation, and basic security smoke tests. Automated tests can be run quickly and repeatedly. Anytime you make a change, you should test all of your previous configuration to make sure that nothing other than your intended change took place.
Even simple tests like;
- can server A talk to server B on port 22?
- is server A blocked from talking to server B on port 53?
Will greatly improve your security and reassure you that your security is working as expected.
Rinse & repeat
If you follow the AWS recommendations you’re well on your way to a improving the security of your deployment. More importantly, you now have a solid process by which you can continuously improve your deployment.
Take action, test, take action, test, repeat as required.
If you have any tips on protecting the guest operation system in AWS, Please share them in the comments! And if you’re interested in securing your EC2 or VPC instances check out our new Deep Security as a Service for cloud servers, currently in free Beta.