Security in the Cloud Requires a New Way of Thinking

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.

3. Access Roles – Moving on to separation of duties in the cloud, that bus has left quite some time ago. However, we need to drive the need for very specific IAM (Identity and Access Management) roles to be created so that individual accounts or API keys only have finite access to what they require and are not overly permissive.

4. Vulnerability Remediation – A darling topic for our IT and Dev teams, nobody wants to focus on vulnerability remediation until we have a critical application vulnerability exploited and an incident on our hands. So, how do we drive improvement on vulnerability remediation? We do it by getting embedded into the Dev Ops CI/CD (Continuous Integration/Continuous Delivery) pipeline by building automated vulnerability scans of applications so teams see the defects prior to promoting code into production. It’s also a good idea to start calling vulnerabilities “defects” so that Dev Ops teams start listening. A slight twist to our wording has a large effect since Dev teams take defects personally and will be more inclined to fix a defect.

The cloud has changed the way security teams work in this new world of unlimited speed and scale

5. Threat Detection–The first start to any good Security Operations in the cloud is knowing your use cases and creating playbooks for how your team will handle commodity-based threats that happen multiple times a day. It is of the utmost importance that process diagrams are created to know who is doing what task and in what sequence. Many Security Operations teams go wrong because they have all the tools at their disposal but no solid plan or direction as to how they can be utilized.

Threat detection alerting must be accurate and actionable along with providing the owner of the system real-time alerting. For example, if a system is spun up without being patched and then it gets exploited and is running cryptomining, you need to have threat detection in place to identify internal hosts reaching out to cryptomining pools and then send the IT owner an IM/email to notify them of the issue. Once you have extremely high accuracy for these types of commodity-based threats, you have to automate the response so that you’ll be able to scale for the cloud. With the vast scale and speed of the cloud, there is no way to keep up if you do not automate responses for these types of threats.

6. Threat Response –On the incident response (IR) side for cloud, you will also want to automate as much of the forensic analysis preparation as possible so that you can focus on the analysis of the incident and not the logistics. Let’s take acryptomining example: Acryptomining alert is kicked off, an admin is notified, the security groups get locked down on an ec2 instance, scripts are kicked off to perform a snapshot/memory image, timeline and all the data is bundled up into a security account. The amount of time saved by automating this part of the incident response process is huge.

7. Threat Intelligence Ecosystem – Lastly, now that you have an IR process in place, it is important to incorporate the threat data gathered into a threat intelligence ecosystem to better understand the threat actors targeting your organization and what tactics, techniques, and procedures they are using to compromise your company’s systems. In order, to attempt to get one step ahead of threat actors, you need to have a threat intelligence program in place.

Change Enables Security Innovation

The cloud has changed the way security teams work in this new world of unlimited speed and scale. If security teams change their perspectives and capabilities to fit into this new agile Dev Ops world, they will enable the business to innovate faster, improve security, and automate good security practices and incident response.