By James Condon, Director of Research at Lacework

Automating Enforcement and Response in 2020

In 2019, organizations adopted containers, embraced DevSecOps, and shifted security focus to earlier in the software development lifecycle. "Secure by Default" became the new goalpost. We now see the various places we need to insert security into our CI/CD pipelines. But with so many new areas for security to keep tabs on, how will teams keep pace? The same way software development accelerated, automation.

In 2020, we will see organizations automating enforcement, remediation, and response. Trying to "Shift Left,", cover the middle, and respond to runtime attacks is simply too much to handle without tapping into the power of automation. However, on the other side of the coin, security automation is risky. What if you disrupt services and cause an outage? Now that we have automated most every other piece in the development lifecycle, it's time to figure out how to take security automation to the next level.

There are many pieces we can look at automating, such as enforcement. Early in the software development lifecycle we will move from flagging issues to blocking them from moving forward. Here are a few examples we may see adopted in 2020:

1. Build systems will reject code that is checked in containing hardcoded secrets.
2. Images containing critical and high severity vulnerabilities will be blocked from deployment.
3. Container orchestrators like Kubernetes will reject the admission of containers that do not conform with best practices.
4. Infrastructure as code will be audited to prevent insecure deployments.
   

We've learned a lot about infrastructure security over the past year. It is well known that misconfigurations are an ever present danger. Hardly a week went by in 2019 without learning of a new data breach coming from something like an internet accessible Elasticsearch cluster with no authentication, containing highly sensitive data. In 2020 we will see auditing systems move from using a pull system to report misconfigurations, to real time alerting systems that can fix the problem right away. Here are a few examples.

1. Storage buckets that are exposed to the public will immediately be made private.
2. Network firewall policies that are too permissive will automatically be fixed.
3. Audit logs will be automatically re-enabled if they become disabled.
4. Servers not intended to be exposed to the internet will automatically be moved to a private subnet.
5. Appropriate logging will be automatically enabled when new infrastructure is created.
   

Even if software and infrastructure is secure by default, an attack surface can still present itself. A number of critical CVEs affecting applications commonly used in the cloud were disclosed in 2019. Containerized and virtual workloads present a unique opportunity to automate response efforts. Here are a few examples of how this could occur in 2020:

1. Runtime detection systems will automatically pause, quarantine, and prep compromised containers for forensic analysis.
2. Outbound network traffic for compromised services will be sinkholed and collect for analysis.
3. Containers in production that are vulnerable to newly disclosed CVEs will be automatically identified.
   

The technology and security adoptions in 2019 have set the stage for further security enablement in 2020. Just as technology and automation has empowered developers and applications, it too will empower security. Next year we will see the difficult and complex security issues addressed with automation. This will extend from early enforcement before deployment, to continuous security of infrastructure, to automating incident response at runtime.

##

About the Author