Most application security failures are the result of people. Consequently, technology professionals understand that they should rotate access credentials/keys. Programmers know that SQL injection is bad, just as network engineers understand that opening SSH or RDP to the internet is dangerous. You probably know that you should not email financial information to the individual claiming to have millions of dollars of your frozen assets—even though that individual asserts that they mean you no ill will.
As fascinating as famed exploits like Heartbleed, Meltdown, and KRACK are—most security breaches don’t occur because of an arcane exploit that demands cryptographic expertise to understand. In truth, the three attacks mentioned can be resolved by installing a patch. If these resolutions are so simple, why do so many organizations fall victim to these attacks? Many simply forgot to click the “update” button.
The traditional cybersecurity
approach to preventing mistakes from compromising a system was a combination of:
- Policies
- Controls
- More people and bureaucracy (oversight)
There are deficiencies with this approach because the
points enumerated are susceptible to rebuttal. Firstly, most people do not read
policies, even if instructed or required to do so. Secondly, controls can be
effective, but many are enforced manually by people. Lastly, introducing layers
of bureaucracy and staff intended to enforce controls/policy can be effective
in achieving greater security all-around—but this significantly slows the pace
of innovation and product delivery. Even with this traditional approach,
security vulnerabilities still slip through. It doesn’t take long to think of
an enterprise/entity/government/organization with multiple layers of security
staff and approvals that has made front-page news for massive security breaches.
How can we stop humans (ourselves) from introducing security vulnerabilities?
DevOps (Development Operations)
has infused application development with an “automate first” imperative to
accelerate the software development lifecycle (SDLC)—delivering products faster
and more consistently. DevOps achieves this, in part, by collaborating
with IT infrastructure teams to extend automation and idempotence into these
teams via concepts/technologies such as infrastructure-as-code. In short, DevOps
encompasses people, process, and technology. However, it has traditionally left
behind security people, security process, and security
technology. DevSecOps (Development Security Operations) extends the
CI/CD approach to its next logical domain: security.
DevSecOps has a veritable cornucopia of benefits, a great number of which can be incorporated into a CI/CD pipeline. DevSecOps seeks to make application security less a matter of reactionary manual verification and testing—shifting it into CI/CD pipelines so that security is at the forefront of the SDLC from its very origin.
Here are just a few examples of how security technology can mitigate our own inherent failings:
- Source code analysis tools (SAST) can be
implemented to identify mistakes introducing vulnerabilities into the
application. These tools are generally run prior to deployment, thus allowing
the detection of vulnerabilities earlier in the SDLC.
- Open source code analysis can be used to check
that packages/libraries listed in a manifest (package manager file), or
incorporated into an application, are up-to-date and that the versions utilized
do not contain vulnerabilities. This analysis occurs prior to deployment. Some
tools will also check the licensing status of these packages to ensure that the
code can be used in enterprise systems without breaching the license, to reduce
legal exposure.
- Dynamic scanning tools can be run
post-deployment, particularly in UAT environments, to ensure that the deployed
application does not have vulnerabilities. These tools can also be used to
verify that infrastructure is setup and configured in a secure manner. Dynamic
scanning tools are used to check everything from SSL/TLS configuration, port
and protocol availability, to asset patch compliance. Additionally, these tools
can be used to scan and enforce compliance with frameworks such as SOC2, NIST,
PCI and HIPAA.
- Configuration management tools and patch
managers can be used to automate, schedule, and administer the application of
infrastructure patches. Furthermore, configuration management tools can prevent
all-to-common configuration mistakes made during manual environment
configuration.
- Automated compliance tools can enforce that the
state of an environment is maintained and tracked so that configuration drift
does not engender a security risk.
- Threat modeling tools can analyze and identify
application components that present risk.
- Intrusion prevention systems (IPS) can
automatically detect suspicious traffic flows at OSI (Open Systems
Interconnection) layer 3 and 4 and take action to resolve the threat
automatically.
- Last but not least: alerting, monitoring, and
log aggregation tools are a pivotal part of securing applications and CI/CD
pipelines. Moreover, this data can now be combed by machine learning tools
designed for intelligent, real-time threat analysis and detection.
DevSecOps is not just security technology. It is people, process, and technology. Technology can mitigate human fallibility—but people and process are still required to achieve the greatest level of security to deliver products in the SDLC faster, consistently, and securely.
