While there’s plenty of research on integrating security into Agile software methodologies, we’re often left only with “security sandwiches,“ where security is discussed upfront and at the far end of the development process rather than throughout.
Corporate security remains an isolated department at many organizations, one that lives outside the Agile/DevOps/Pod team practice. Developers have a list of do’s and don’ts, and quality assurance teams periodically run security tests on business applications that fall short of detecting the full sweep of security vulnerabilities. They tend to focus only on known threats and worry primarily about outside attackers. This is a serious mistake. State-of-the-art continuous monitoring of security is not continuous security.
Although security is everyone’s responsibility, someone in the organization does need to own it. Moreover, if it isn’t continuously and holistically addressed, everyone’s responsibility becomes no one’s responsibility. Agile has paved the ways for DevOps and continuous delivery. Can it establish continuous security?
Security: The Missing Link in Agile
In well-constructed Agile teams, developers implement and check the security controls in their code. Quality engineers then run checks to identify the structural vulnerabilities through continuous testing. The key element missing in this approach is there’s no one who constantly:
- Validates the organization’s threat model to align it with the design and development principles that are established by the application team at the scrum level.
- Evaluates the structural vulnerabilities (from a hypothetical hacker’s point of view) for all the multi-channel interfaces that an application may have.
Since security is a non-functional requirement, it’s hard to pin it down in Agile’s user stories. In an effort to deliver functionality and customer experience, the chance of developers missing security elements can be exceptionally high. Unless quality engineers are equipped with technical knowledge of digital security, they can’t detect all the vulnerabilities either. Simply adding someone from the chief security officer’s (CSO) team as part of every scrum team is not a viable option either. If the CSO organization doesn’t elevate from “control” to “orchestration,” it becomes an unintended organizational bottleneck in the continuous security implementation process.
Applying Continuous Engineering to Security
It’s difficult to effectively orchestrate security practices at every step of the software development lifecycle. When continuous engineering principles are used, however, they can make continuous delivery more efficient by enabling:
- More frequent reviews of software security design principles by the CSO organization. This would help align the CSO guidelines that flow top-down and the design principles at the scrum level that flow bottom-up.
- Software delivery that meets security guidelines. By continuously paying close attention to published security guidelines, developers can reduce the chance of security bugs being caught later in the lifecycle, saving time and cost.
- Continuous testing with increased unit-level verification of security vulnerabilities. More unit testing with security test cases in the scope can help maximize the chance of identifying security bugs early in the lifecycle.
- A continuous feed of newer vulnerabilities identified by the CSO organization that becomes part of the continuous testing administered by developers and quality engineers at unit, system and regression levels. This feed could eventually be expanded so that the collective wisdom of the community of security practitioners and evangelists could be better put to use in cyber security. This step helps avoid time gaps between when the CSO organization learns of newer vulnerabilities and the faster iterations of digital engineering.
- Deployment of ethical hackers to challenge the established security controls.
Continuous Security in Real Life
We implemented these steps for a large U.S. cruise line operator. The quality engineering team’s implementation of continuous testing reduced the majority of security glitches at the unit testing level. The results of the continuous security test helped identify opportunities for additional training and improved guidelines for developers.
The customer’s CSO representatives, security testing experts and select scrum masters (the Agile security governance team) conducted periodic reviews to align top-down and bottom-up learnings of existing and new security vulnerabilities. A modularized automation test design provided ways for the CSO team to continuously push additional test cases as they learn, which became part of ongoing continuous testing across all scrum teams. As a result, the business had a fully functioning continuous security process.
Security breaches cause great loss to the brand. Those who are paranoid are well prepared. By pitting technology against technology, process against process, and hackers against hackers, businesses can reduce the chance of security breaches. After all, there is no such thing as 100% security.