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
Edge-DRsplash-10-edge-articles
7 Old IT Things Every New InfoSec Pro Should Know
Joan Goodchild, Staff Editor,  4/20/2021
News
Cloud-Native Businesses Struggle With Security
Robert Lemos, Contributing Writer,  5/6/2021
Commentary
Defending Against Web Scraping Attacks
Rob Simon, Principal Security Consultant at TrustedSec,  5/7/2021
Register for Dark Reading Newsletters
White Papers
Video
Cartoon
Current Issue
2021 Top Enterprise IT Trends
We've identified the key trends that are poised to impact the IT landscape in 2021. Find out why they're important and how they will affect you today!
Flash Poll
How Enterprises are Developing Secure Applications
How Enterprises are Developing Secure Applications
Recent breaches of third-party apps are driving many organizations to think harder about the security of their off-the-shelf software as they continue to move left in secure software development practices.
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2020-36197
PUBLISHED: 2021-05-13
An improper access control vulnerability has been reported to affect earlier versions of Music Station. If exploited, this vulnerability allows attackers to compromise the security of the software by gaining privileges, reading sensitive information, executing commands, evading detection, etc. This ...
CVE-2020-36198
PUBLISHED: 2021-05-13
A command injection vulnerability has been reported to affect certain versions of Malware Remover. If exploited, this vulnerability allows remote attackers to execute arbitrary commands. This issue affects: QNAP Systems Inc. Malware Remover versions prior to 4.6.1.0. This issue does not affect: QNAP...
CVE-2021-28799
PUBLISHED: 2021-05-13
An improper authorization vulnerability has been reported to affect QNAP NAS running HBS 3 (Hybrid Backup Sync. ) If exploited, the vulnerability allows remote attackers to log in to a device. This issue affects: QNAP Systems Inc. HBS 3 versions prior to v16.0.0415 on QTS 4.5.2; versions prior to v3...
CVE-2021-22155
PUBLISHED: 2021-05-13
An Authentication Bypass vulnerability in the SAML Authentication component of BlackBerry Workspaces Server (deployed with Appliance-X) version(s) 10.1, 9.1 and earlier could allow an attacker to potentially gain access to the application in the context of the targeted user’s acco...
CVE-2021-23134
PUBLISHED: 2021-05-12
Use After Free vulnerability in nfc sockets in the Linux Kernel before 5.12.2 allows local attackers to elevate their privileges. In typical configurations, the issue can only be triggered by a privileged local user with the CAP_NET_RAW capability.