Security Compliance as Code On AWS
The advancement to public cloud has been phenomenal. Cloud computing has gone mainstream as more organizations shift their applications and workloads from on-premise data centers to public cloud platforms. Almost 96 % of companies, according to one annual, survey have moved some part of their business to the cloud. The cloud adoption is at neck-breaking speed and we should not stop ourselves from welcoming this change. With this high rate of adoption, the question that comes to our mind is are we doing it right? I am not trying to put a correlation between the data security breaches and the rate of cloud adoption but the figures for data breaches have been on the rise. The Office of the Australian Information Commissioner Notifiable Data Breaches for October — December 2018 is certainly an eye-opener. In 91 Days, we had 262 data breaches which were “notified”. That’s almost 3 data breaches per day. 97% of these breaches could have been stopped if we had some kind of automated system in place. Why are breaches on the rise? Where have we gone wrong? How can we stop this? What tools are out there that will help us remediate? These questions lead to my weekend adventure.
My cause for making the system secure is more personal than professional.
- Why: Push the limits and create new “Best Practices” for a secure world
- How: Continuous testing of configuration and auto remediate where possible
- What: Build Compliance as Code and auto-remediation
During my research, I happen to stumble upon an open-source solution (AWS Config RDK: Rules Development Kit) for the AWS public cloud provider. RDK use AWS Config Rules that provides automated, periodic or change triggered security and compliance checking of AWS resources, and affords customers the ability to forego manual inspection of security configurations. You can write your own config rules as code test it and deploy it to your environment. Apart from the RDK, I found a resourceful community-based source of custom AWS Config Rules.
My top 5 security compliance rules.
- Ensure CloudTrail is enabled in all regions
- Ensure all accounts have multi-factor authentication (MFA) enabled
- Ensure no access keys exist for the root account
- Ensure IAM roles and users have mandatory policies attached
- Ensure access keys are rotated
Here’s an output of my 2-hour investment
Config compliance dashboard
Security Compliance Rule Deployed
Security Compliance Rule Monthly Cost Forecast
The compliance check cost you pay is minimal compared to brand damage.
Security Compliance can only raise alarms and apply remediation when things have gone wrong when your product is out in the wild. Let’s not make security as an afterthought. Putting a cart before the horse really does not help. Ingrain the three golden rules into every secure software engineering life-cycle:
- secure by design
- secure by default
- secure in deployment
Here’s a link to my git project for security compliance as code. I have added a Dockerfile template to help you develop your code if your work laptop has an endpoint protection/ no elevated privileges.
Tools used for development:
- [x] visual studio code
- [x] command line of choice WSL Ubuntu
- [x] Docker Desktop for Windows
