Mitigating the Greatest Software Development Security Risk: Human Fallibility
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.
