Remember when it was the Security team’s job to implement policies, procedures, and controls that an organization “must” follow to ensure they were “secure”? The typical Security team approved tickets for firewall rule changes, required network-based firewall segmentation and separation of duties for access in addition to investigating the back log of security alerts, running vulnerability scans and providing dictionary-sized reports along with other various tasks.
In today’s new world of Infrastructure as a Service and Platform as a Service, the Dev Ops teams have the ability to move at the speed of light, build infrastructure on demand, and manage their own security controls. The cloud has put the Dev Ops teams in the driver’s seat so to speak. And Security teams that have not transformed in this new world and way of thinking are left out of the equation until they are responding to a security incident.
Practical Steps to Modernize Your Security Approach
How can we, as security professionals, make the world between the Dev Ops and Security teams a partnership while enabling the business at the same time? We need to change our way of thinking to more of a guardrail, continuous feedback, and integrated approach to enable Dev Ops teams and the business.
Here are seven practical steps companies can take to modernize their security approach.
1. Firewall Changes – Let’s first start with firewall changes in the AWS world, which are security groups. Let’s allow our Dev Ops teams to manage their security groups, however, let’s put automation and real-time feedback in place to allow security groups to be setup within certain guardrails i.e. auto-remediating ANY/ANY security groups. If by some chance they put in a “naughty” security group, let’s automatically correct it and then send them a real-time alert/ instant message of how to do it better next time, making it a “teachable moment.”
2. Blast Radius – The same approach of empowering Dev Ops teams holds true for Amazon S3 buckets. Now hold on to your seats…let’s not worry about network segmentation, but instead, let’s focus on blast radius. It is absolutely important to separate your AWS accounts by criticality, i.e. production systems need to be put within a prod account and non-prod systems put in a non-prod account.