Dark Reading is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them.Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Application Security

12/22/2020
10:00 AM
Dan Hubbard
Dan Hubbard
Commentary
Connect Directly
Twitter
LinkedIn
RSS
E-Mail vvv
100%
0%

Security as Code: How Repeatable Policy-Driven Deployment Improves Security

The SaC approach lets users codify and enforce a secure state of application configuration deployment that limits risk.

The adoption of infrastructure as code (IaC) practices to help automate and accelerate IT operations has really taken hold in recent years — even more so during the pandemic.

With IaC, organizations are moving away from a model where humans are required to make manual changes in order to configure and deploy application infrastructure, both on-premises and more often than not, in the cloud. IaC offers the promise of automation and repeatable predictable patterns for software infrastructure deployment. There are multiple popular models and services used today for enabling an IaC approach, including Terraform, Chef, Puppet, Ansible, SaltStack, and AWS CloudFormations.

Related Content:

Why Vulnerable Code Is Shipped Knowingly

The Changing Face of Threat Intelligence

How to Stay Secure on Github

While the approach has many benefits, traditional security approaches typically slow down the software development life cycle and can evaporate the benefits of using IaC. That's why there is a real need for organizations to take a "security as code" (SaC) approach to fully recognize the benefits of automation that composable, repeatable, and fully auditable infrastructure can provide.

IaC Requires A New Security Approach
Simply put, securing automation code is critical because in many cases it literally runs our businesses. IaC systems are automatically deploying resources and applications. A vulnerability or a misconfiguration in an IaC workflow could have a cascading impact, across multiple workloads and deployments that could enable a potential attacker to cause a lot of damage. IaC is very powerful, so when mistakes happen, they happen fast, and exponentially.

One of the challenges with securing automated workflows is there can often be multiple paths into a system or service for executing an action. There could also well be multiple people from different parts of the organization that have access to the various entry points for IaC. Adding further complexity is that some organizations might not be effectively communicating about objectives and required changes across a distributed organization.

Core Security Principles
A primary foundation for securing infrastructure created and managed by IAC templates is by first establishing a source of truth for configuration. There needs to be a codified version of configuration, usually in a Git software repository, that defines the desired state of configuration. It's an approach that some refer to as GitOps, which helps to enable IaC. With a defined source of truth, it's time to implement access, audit, and review processes.

  • Access control. With a defined source of truth for configuration, secure controls can and should be applied. There needs to be access control that strictly defined who can access and make changes to the configuration code

  • Auditing and compliance. Controlling access is only the first part of security IaC. All changes need to be audited and monitored for compliance with corporate policy and regulatory compliance frameworks.

  • Review. Even with auditing and access controls, changes that might not be ideal can still slip through the cracks. That's why it's imperative to also actively have a change management and review process to further validate the state of IaC configuration and any changes.

Define a Single, Secure Path to Production
To fully secure IaC, there also must be a well-defined single path to production, so that all stakeholders in the organization, including developers, operations, and security are involved.

Defining the path to production is often about breaking down silos within the company and focusing on cross-team collaboration. More often than not in the past, developers have viewed security as a blocker and not as an enabler. The security-as-code approach can help to change that mindset by working with developers in a language they understand: code.

A key concept that we have seen work well is the use of guardrails, rather than gates, as part of the SaC process. Rather than implementing a gate, where code cannot pass through unless it is approved by security, a guardrail keeps code within certain defined boundaries, that limits risk.

Guardrails can help developers and organizations to focus on speed, in a way without sacrificing security.

Security as Code in Practice
How does it actually work to improve security? The reality is that with continuous visibility you can ensure correctness, alert and then correct any divergence in a repeatable, auditable, secured approach.

Here's just one example where this approach can help. The issue of unsecured cloud storage buckets, often on Amazon S3, is one that is well documented and has been reported on extensively at Dark Reading and other places. The SaC model can help to effectively eliminate that risk.

By running continuous compliance assessments of cloud environments, an organization can be alerted whenever an S3 bucket has been inadvertently provisioned with public read or write access. An administrator can then go to the Git repository where the configuration code for the IaC service is defined and make the required change to eliminate the risk. After the change has been committed, it can get through the approval process, and once accepted, the IaC pipeline can execute the code to remediate the issue across all deployments. The entire process is logged and auditable as well.

Mistakes happen, and vulnerabilities seem to come from new places all the time. But with the SaC approach, it is possible to codify and enforce a secure state of application configuration deployment that limits risk.

Dan Hubbard is CEO at Lacework, driving innovation and expanding the company's security strategy for public and private clouds. A pioneering force in Internet security, Dan's expertise spans from reputation and advanced classification systems to large-scale security data ... View Full Bio
 

Recommended Reading:

Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
Attackers Leave Stolen Credentials Searchable on Google
Kelly Sheridan, Staff Editor, Dark Reading,  1/21/2021
How to Better Secure Your Microsoft 365 Environment
Kelly Sheridan, Staff Editor, Dark Reading,  1/25/2021
Register for Dark Reading Newsletters
White Papers
Video
Cartoon Contest
Write a Caption, Win an Amazon Gift Card! Click Here
Latest Comment: I can't find the back door.
Current Issue
2020: The Year in Security
Download this Tech Digest for a look at the biggest security stories that - so far - have shaped a very strange and stressful year.
Flash Poll
Assessing Cybersecurity Risk in Today's Enterprises
Assessing Cybersecurity Risk in Today's Enterprises
COVID-19 has created a new IT paradigm in the enterprise -- and a new level of cybersecurity risk. This report offers a look at how enterprises are assessing and managing cyber-risk under the new normal.
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2021-21275
PUBLISHED: 2021-01-25
The MediaWiki "Report" extension has a Cross-Site Request Forgery (CSRF) vulnerability. Before fixed version, there was no protection against CSRF checks on Special:Report, so requests to report a revision could be forged. The problem has been fixed in commit f828dc6 by making use of Medi...
CVE-2021-21272
PUBLISHED: 2021-01-25
ORAS is open source software which enables a way to push OCI Artifacts to OCI Conformant registries. ORAS is both a CLI for initial testing and a Go Module. In ORAS from version 0.4.0 and before version 0.9.0, there is a "zip-slip" vulnerability. The directory support feature allows the ...
CVE-2021-23901
PUBLISHED: 2021-01-25
An XML external entity (XXE) injection vulnerability was discovered in the Nutch DmozParser and is known to affect Nutch versions < 1.18. XML external entity injection (also known as XXE) is a web security vulnerability that allows an attacker to interfere with an application's processing of XML ...
CVE-2020-17532
PUBLISHED: 2021-01-25
When handler-router component is enabled in servicecomb-java-chassis, authenticated user may inject some data and cause arbitrary code execution. The problem happens in versions between 2.0.0 ~ 2.1.3 and fixed in Apache ServiceComb-Java-Chassis 2.1.5
CVE-2020-12512
PUBLISHED: 2021-01-22
Pepperl+Fuchs Comtrol IO-Link Master in Version 1.5.48 and below is prone to an authenticated reflected POST Cross-Site Scripting