Another breach in the news and another moment I face palm. It seems like we can’t go more than a few days without reading about a cybersecurity breach of some sort. The news of a business who hosted their data or services in the public cloud, such as Amazon Web Services (AWS), always gets me riled up. Public cloud platforms were built with security as a key feature, not as an afterthought. Even more so security features are enabled by default. Despite all of this, you often see breach news articles targeted at the cloud. Many of the breaches were due to someone quite literally clicking the ‘make public’ checkbox and not thinking through the repercussions!
A cloud built on security
The cloud brings with it many security layers inherent to the various platforms. Take AWS, for example, which has a plethora of tools:
- Data at rest encryption
- Data in transit encryption
- Security groups to lock down traffic between servers or services
- Role based access which allows assignment to servers or resources without storing a password on them
- Resources are created as private by default
- Network ACLs
- Outbound only NAT gateways
- Outbound only internet gateways
- Resource access logging
- Admin logging
- AI based behavior monitoring for admin processes
Taking the time
I can’t help but think that so many of the mistakes people make with public cloud security is due to either a lack of knowledge on the platform or more importantly, not taking the time to address security. It can be so easy to create a new server that security comes as an afterthought. There you are needing to spin up a few servers with a deadline looming and you just want to get it up and tested. You’ll come back and secure everything after the fact. :facepalm:
This is such a terrible strategy, for so many reasons:
- How can you test your new application fully without having the security rules already in place?
- How can you understand the way the application works without applying security groups and locking down any unsed ports?
- Did you realize that adding security afterwards sometimes requires double the work in the long run?
Leverage the time and the tools
If you want to take security seriously, and you really should, make time for it. Build out your timeline or schedule to front-load security design and fit it in first, not last. After you start a few projects in this manner, it’ll become second nature. Your team will understand their environment better and you can rest easy knowing that each member is taking security more seriously. Oh and one last thing, when you see the checkbox which says ‘make public’ think twice about whether or not that makes sense.
About the Author
Zach Hill, CTO
Zach began his career early in life with an internship as a helpdesk technician at a recycling company out of Chicago and has worked his way through the IT ranks from System Administrator to his current role as Chief Technology Officer at Think|Stack. His specialties come from a heavy networking engineering and virtualization background allowing him to easily transition into the dynamic and complex cloud environments of the modern technical landscape. As an AWS Certified Solutions Architect – Professional, Zach is equally at home generating the architectural plans for a complex service deployment within AWS. Zach’s vision and drive to be at the bleeding-edge fuels Think|Stack’s growth and provides clients with an innovative, constantly evolving technology strategy.