DevSecOps: Solving a (Very) Common Challenge
DevSecOps is one of several new shifts in tech culture ushered in by DevOps. It’s frequently discussed nowadays. But what exactly is it? Do you need it? If so, how do you solve its most common challenge?
DevSecOps is the practice of building security into the entire software development cycle. It’s intimately connected with DevOps:
- DevOps integrates operations into the develop/release cycle. DevSecOps integrates security into the develop/release cycle.
- DevOps increases the speed at which software is developed and delivered. DevSecOps increases the security with which software is developed and delivered.
- DevOps automates much of the software lifecycle. DevSecOps requires merging and automating many of the traditional practices of security engineers, operations teams, and development teams.
Today, DevSecOps is gaining attention because of the driving need for better security. To achieve this, DevSecOps includes security practices that scale, configurations that are either immutable or auto-healing, and procedures that are as automated as the infrastructures they are protecting.
Of course, many organizations do not adhere to DevSecOps. Many executives figure that they already have security practices and devices in place. And since they already have protection for their servers and networks, they think: “Why would we need DevSecOps? After all, our network border is already protected.” [Answer: it’s still important anyway.]
“And I understand that our border protection would prevent us from implementing DevSecOps.”
Actually, it won’t. More on this in a moment. But first, some background.
Concepts
As shown above, DevSecOps is intimately related to DevOps, which uses automation to increase the speed and consistency of software delivery. Similarly, while the ultimate goal of DevSecOps is to increase the security of released software, successful DevSecOps also requires increasing the automation (and therefore, the speed and consistency) of how security is implemented and maintained during development and deployment. The changes can be categorized as follows:
- Building security into your infrastructure
- Building security into your applications
- Building security into your CI/CD pipeline
- Building security into your network’s borders
Let’s expand on each of these.
Building security into your infrastructure
Infrastructure as Code (IaC) is the management of your infrastructure components (subnets, networks, servers, databases, services, etc.) as code. IaC is done through a software revision and delivery process, just like an application.
IaC isn’t a new concept, and using tools like Puppet for desired state configuration or Terraform for cloud-native orchestration helps companies implement it effectively. Even though there are ways to use IaC tools to perform security automation, these tools don’t secure your infrastructure automatically. This takes work. However, the good news is that you can configure security through IaC tools. Here are some examples:
- Linux CIS hardening through Puppet: This forge module will help you harden Linux machines for high security. Also, since Puppet agents run every 30 minutes, you can maintain the settings in case of a configuration drift. Security auditors enjoy this kind of control because it enables them to say with confidence that settings (x, y, z) are set on every server — without having to write lengthy scripts or conduct spot checks. In fact, many compliance auditors (like HIPAA and SOC) expect this level of automation to be in place.
- Ports and protocol hardening through Terraform: You can set network boundary security NACLs and host-level or service-to-service protection through security group configuration. These configurations are easy to implement and to use to close unnecessary traffic. Better yet, you can design security groups to trust only their upstream and downstream connections.
- Baseline hardening through Dev-Sec Hardening Framework: DevSec Hardening Framework offers multiple frameworks you can use to align with tools like Chef cookbooks, Puppet modules, and Inspec profiles. These frameworks can help you better protect your databases, operating systems, and containers through code. The site is rich with direct code examples.
Building security into your application
Most companies spend considerable time securing applications from threats. DevSecOps can reduce the required effort by preventing some common security pitfalls from occurring. By setting up your code to manage application hardening, you can remove the burden of repeating security practices at each environment of your operational stack. In other words, why not implement security controls in your dev environment all the way through production?
Every year, you can find new or expanded lists about securing your applications on OWASP. One of the most popular lists is Top 10 Vulnerabilities. Yet each of these vulnerabilities have remediation actions, many which can be cured through automation.
Here are a few DevSecOps-style cures for application issues:
- Code that installs applications automatically and requests/applies trusted certificates for web endpoints, app-to-app communication, and app-to-database communication.
- Code that installs framework updates (Java and NodeJS) as part of an agent-based desired state configuration management.
- Code that creates auditable exceptions in applications that show security attacks, then alerts when those exceptions are raised.
- Code that ensures only strong cipher suites, protocols, and hashes are used in the application stack, and that all insecure methods are disabled at the OS whenever possible.
Security is not always part of the entire Software Development Life Cycle, but it should start at development, not production. Enforcing good security practices through code will ensure that configurations are not missed in testing, or that security practices aren’t forgotten once software is deployed.
Building security into your CI/CD pipeline
Speaking of enforcing security on the journey to production, there is plenty to implement in CI/CD pipelines. Of course it’s great to deliver software, but why not deliver it securely? There are several tools in your DevSecOps toolbelt that you can use to improve security in the release process. These include:
- Security testing: Application testing is critical and should be run at each environment of the pipeline, but what about security testing? A Nessus vulnerability scan can be performed on the deployment stack before it’s promoted into production. This will either give you peace-of-mind or the opportunity to write hardening code in order to fix open vulnerabilities. And API testing can verify that attacks trigger alerts based on exception handling/monitoring tools.
- Container hardening: If your CI/CD builds containers, container hardening can be a step in the pipeline.
- OS network hardening: This ensures that builds implement host-based firewalls, data loss prevention (DLP) agents, or OS firewalls such as firewalld or Microsoft Windows Server Firewall. You can implement SELinux code prior to application testing to ensure a hardened environment.
Part of the release process is to ensure that the software is being delivered as securely as possible into secure environments. There are more examples of enabling DevSecOps through code, but for now, let’s move on and discuss a bigger problem that must be addressed.
Oftentimes, the most difficult and least flexible assets to harden are the actual security appliances themselves.
A (very) common challenge: Securing the border
Security becomes a challenge when you want to perform deep security at the most critical point: your border. Traditional data centers often use a host of security appliances, while cloud-native organizations often use SaaS services or security appliances that run on server instances. Other cloud-native companies rely on tools supplied by cloud vendors, such as AWS GuardDuty (which detects unauthorized AWS account activity) or AWS Shield (which helps prevent DDoS attacks).
All of these options pose challenges for DevSecOps.
The problems with traditional appliances
Traditional security admins are used to managing security appliances. Typically, an engineer will log into the appliance, make configuration changes, review a few logs, or add a new ingress rule. No big deal, until:
- You need to scale your external-facing applications.
- You need to manage security settings consistently across devices.
- You need to manage the security appliance with code and APIs.
Traditional appliances do not support DevOps (or implicitly, DevSecOps) because:
- They are stateful through manual configuration.
- They are not designed for ephemeral workflows.
- They are not designed to support IaC modeling.
Even more troubling, many cloud-native appliances weren’t built for DevSecOps either.
The problems with cloud-native appliances
Some tools weren’t designed with simple (yet sophisticated) cloud strategies in mind. For instance, companies such as Alert Logic and Sophos require you to launch multiple instances into your environment. In the case of Alert Logic, appliances must be installed in each availability zone to sniff the traffic for that zone. And Sophos’s UTMs require additional layers of management through a Queen to keep consistent configuration across multiple nodes — otherwise, configuration must be repeated on each device.
Even if these platforms were more flexible in their architectures, they would still require intervention for dynamic deployments through CI/CD — and configuration to AWS WAF or reverse proxy to allow for changing deployments. This lack of automated control is a severely limiting issue for DevSecOps.
Getting cloud-native security that supports DevSecOps
Reblaze can help guard against the myriad of Internet threats and enable your DevSecOps practices. When focusing on automation efforts, it’s simplest to spend time building secure coding practices — from the cloud architecture to the operating system — and to rely on a strong solution surrounding your environment.
Reblaze boasts many capabilities that can assist DevSecOps teams, including:
- Dynamic recognition and protection of assets deployed through CI/CD.
- A secure isolation network (a Virtual Private Cloud) where traffic is filtered and threats are blocked before they reach your network.
- Customer-unique isolation (no multi-tenancy in the protection environment, as this can lead to spillover attacks).
- Fully managed security infrastructure.
- Deep log analysis and intelligence reporting through dashboards.
- Full integration with AWS, Google, and Microsoft cloud services.
Summary
Today, security is not simply an “add-on” to modern infrastructure and application management, but a crucial part of it. That’s why DevSecOps is especially important; it’s needed to ensure that security provisioning, patching, hardening, and configuration is applied through code. Therefore, practices and controls scale just like a business’ systems.
Furthermore, since the border is the most susceptible to attack, it’s paramount that it receives the strongest protection possible. That’s why you should choose a solution like Reblaze, which can meet the demands of cloud-native automation environments in a fully codified and SaaS-compatible way. By securing your border with a platform that enables your DevSecOps practices, you’ll be able to keep threats out of your network and out of your web apps.
To learn more about Reblaze, visit us at https://www.reblaze.com, or send us an email at hello@reblaze.com.
