All business leaders are faced with an ever growing list of challenges. Those of us who manage teams of software developers struggle with our own set of difficulties. The drums beat for us to address the unknown threats from Cyber Security risk while also developing and delivering software faster and more often. Meanwhile, we need to continue to work at driving efficiencies in the organization to reduce costs while managing overall business risk.
We often say to ourselves,
How can I deliver software faster, more often, with less risk and with lower costs? Something has to give.
Heres a hint. This new age of DevOps does not directly address security issues. However, DevOps does provide a set of tools, processes and a spark in culture change to make your needs a reality.
One answer, integrate a security toolchain into the entire development pipeline.
Whats in your secure development toolchain?
The issue or workflow tracking system is at the heart of the development process. The issue tracking system maintains the history of all work completed as well as all future planned changes.
Whether your team follows Agile, Scaled Agile Framework, Waterfall or other, the place to put the security requirements around a feature or task is in the issue itself. Every time a new ticket is opened, make sure the criteria, description or definition of done includes security requirements. For example, consider a basic story that allows a user to log into a system. Ensure the requirements stipulate that a successful login is only permitted with the correct username and password combination. In addition, a failed match doesn’t permit login. Lastly, too many failed logins should trigger an account lockout. Those requirements seem pretty mundane from a security practitioner’s point of view, but sometimes if they aren’t spelled out, they won’t be implemented. Putting those security requirements at the very beginning of development ensures they continue down the entire pipeline into QA, acceptance testing and integration testing. Issues that don’t meet the security requirements should not pass go.
The second value of an issue tracking system are the historical logs. Security managers and auditors require evidence to prove controls are being followed and enforced. Make your issue tracking software the center of the universe. Every issue should contain a changelog of the code changed, who changed it and when. The system should also contain cross links to your source code revision system.
Also use your SCM to track releases. Every release should be tracked with links to the issues included in the release. When its time to push a release into production, the release ticket should contain the entire release manifest. Go a step beyond the usual software release and ensure that every configuration change, every software patch and every change request has its own ticket. Be sure your tickets contain any management approvals required by your security controls.
Pre build reports into your tracking system in preparation for an audit. Auditors will likely want to see a specific output and history to prove the team has been following the controls. Think like an auditor and be prepared. That way when the auditors arrive at your office, you aren’t scrambling to pull together the evidence requests.
Source Code Management
Whether you are running Git or any other revision control system, there are a few easy security wins that can be implemented at this level.
First off, SCM (Source Code Management) is a revision control system. Any security minded person will appreciate having a centralized location for change logs. Make sure your system maintains logs of who, why, what and where of any change. Consider using hooks. For example, Git provides a means to interrupt the normal workflow with hooks that can be used to enforce a policy like commit messages or additional logging.
Make your SCM system the source of truth for everything related to your development pipeline. The SCM should not only contain the source code for applications, but also all infrastructure and configurations. A developer should be able to checkout the master branch and have everything they need to stand up their own version of the pipeline.
Consider standardizing on a branching strategy that supports isolation and rollback. Many organizations also standardize on a development methodology called feature flags. In either case, a developer should feel comfortable working on new features or bug fixes knowing their work won’t blow up the entire application. At the same time, management needs to have a method which allows them to pick and choose which changes are incorporated in a release and when that release is introduced to customers.
Go Beyond Continuous Integration
Continuous integration tools like that of Jenkins is a perfect place to insert automated security testing. Many development teams use CI (Continuous Integration) solely for performing functional testing. QA can author security tests alongside their functional tests to match all criteria spelled out within the issue. In addition, many security services now support automation with APIs. Build and use automation to test your application during pre production. Automated security testing should include static and dynamic analysis. Last but not least, all packages, code and servers should be profiled with a vulnerability scanner.
In recent years we have started to witness an uptick in automated security testing tools targeted at the development pipeline. A few examples:
Docker-Bench can be used to automate dozens of common and best practices around deploying docker containers into production environments.
Bundler-Audit can be used on Ruby code to check for known vulnerable versions of gems.
FuzzDB uses a set of common attack payloads and locations to test your web application.
There are also a few security testing frameworks that have emerged specifically designed around behavior driven development. For example, look at Guantlt for Ruby; Mittn Python and BDD-Security for Java
Now is the time to begin implementing automating security testing and audit controls within your development pipeline.