DevOps has been a revolution in software development. It brings together software creation, deployment, and management into a single process. Development and operations may become a single team; if not, the teams work very closely together. The benefit is better control over the software release cycle and faster updates.
At the same time, there has been a growing recognition that security needs to be an integral part of the development process. Writing code and then figuring out how to make it secure doesn’t accomplish its goal as well, and it takes longer. The combination of these trends has spawned a new term, DevSecOps.
The central idea of DevSecOps is that everyone is responsible for security. Management needs to keep it in mind when setting out requirements and creating schedules. Developers must build it into every aspect of their specifications and code. QA testers need to check for security as well as functionality. Operations teams have to monitor software behavior and deal promptly with any issues that arise.
Implementing DevSecOps requires a shift in thinking for all parties involved. They each have their responsibilities, and they need to form a solid chain of communication. No concerns should get dropped for lack of a channel. Often security teams have been at a distance from others in the development cycle. With DevSecOps, they become part of every step of the operation, ready to give input.
The shift requires building security awareness into every step of developing, maintaining, and updating software.
The initial steps come in advance of any specific project. All the people involved need to know their role in delivering a product that will withstand hostile action. Communication channels have to be set up so that security specialists are available at every step and can provide input wherever it’s necessary. Everyone should understand the business’s special concerns. For example, if a company makes medical diagnostic equipment, it has to live up to the HIPAA Security Rule.
The first step in a software project is usually the requirements document. Traditionally it addresses functionality, but it should also address security issues. It should assess the level of risk associated with the project as a whole and identify its special concerns. Questions which it addresses include who will use the software, how users or processes gain access, and how the product will interact with other software. Each of these questions implies risk management issues.
The customer has to be involved in the process and should provide input on what needs the greatest protection. A successful product has to be both usable and secure, and the requirements document needs to provide guidance for creating a product that won’t sacrifice either one to the other.
The design documents need to go into further detail about security, following the lead set in the requirements. In an agile DevSecOps environment, the first iterations of the code will come quickly, and this is where concrete steps come in.
The design will specify use cases which could entail risk. User authentication, public access, and APIs need to be handled in a way that minimizes an intruder’s chances of overcoming protections. The design document should enumerate protection methods, including expiration of credentials, logging, and encryption. They shouldn’t be left as mere implementation details.
Coding methods need to follow the best practices for avoiding vulnerabilities. Using secure design patterns, such as sanitizing of all inputs, will minimize the chance that dangerous errors will creep into the code. Doing this from the earliest prototypes is more reliable than going over code later to check for gaps.
People who have worked in DevOps will already be familiar with the use of automation tools, such as Jenkins and Puppet. Running an automated process for building and testing, deploying nothing till it passes all tests, has become widespread practice for good reasons. DevSecOps requires making sure that the tests cover malicious inputs as well as merely unexpected ones.
The OWASP Top Ten list of security risks is a good starting point. Developers should consider how each of the risks applies and devise tests against them.
Adding backdoors to aid in the development cycle often leads to weaknesses in the final product, because they’re forgotten or they’re imperfectly removed. Backdoors sometimes remain in a final product for maintenance purposes. If they’re necessary, they should be treated with the same care as any other feature. They need to be secure, cleanly written, well-documented pieces of code. Too many backdoors are hastily written hacks that rely on security by obscurity.
Where possible, tests should run on the source code (static analysis) as well as compiled or interpreted code. Some vulnerabilities are most easily caught by analyzing the structure of the code.
Software is secure only if it’s configured securely. The server environment, the creation of authorized users, the deployment of access keys, and the account under which the code runs are just some of the aspects that affect code safety. Operations people need to understand these factors and make a checklist of critical issues.
The deployed software should undergo a final set of security tests and be rolled back immediately if it fails any of them.
Once the software is deployed, network monitoring tools should track its behavior and report any significant anomalies. Any indication that an attack has gained a foothold requires prompt remediation. Automation is as valuable in maintaining applications as in building them.
Third-party software on which the deployed software depends needs attention as well. The operations staff needs to track reports of discovered vulnerabilities and fixes for them.
Penetration testing is valuable in discovering any weaknesses before an attacker does. It has to be coordinated with ops, so that it doesn’t interfere with normal use of the software or damage live data. This doesn’t always mean that ops should know in advance that it’s a test; their response may be part of what is being tested.
Each update needs the same care as the initial release, even if it’s happening under pressure. Frequent incremental updates are good, but only if they don’t introduce new risks. It’s better to roll back to a known good version of the code than to push out a new version without proper testing.
Updates need to take into account the state of third-party code which goes into the build. It may need to be replaced by a newer version to deal with newly discovered problems. Commercial and free software is available to help track an application’s dependencies and keep them updated as necessary.
The move to DevSecOps requires a large amount of rethinking of development processes, by management as well as engineers. If a team is already using DevOps, it’s at least halfway there. DevSecOps simply takes the next logical step of bringing security into close cooperation with software design, development, and maintenance. Making the transition will result in code with fewer vulnerabilities, meaning fewer disruptions and emergencies.
