If we’ve learned anything from the rise of Marvel Cinematic Universe, it’s that good things tend to happen when heroes intervene. For securing new applications, this metaphor is a useful one because security isn’t always top-of-mind for scrum teams, nor is it always conducive to meeting aggressive deadlines. But in the world of software security these heroes are critical because they are risk-aware, highly skilled developers who understand software design, robust development, and the importance of architecting for resiliency.
During my session at IANS Los Angeles Information Security Forum this week about driving security into DevSecOps, I was reminded how difficult it is for company leaders who are strapped for time and resources to find, train, and integrate these heroes. While I covered topics like how to measure the maturity of a DevSecOps program, and ways to incentivize the development team to work with security, the conversation often came back to finding good people and getting them integrated into existing team processes.
Meanwhile more organizations are moving to a full continuous integration/continuous deployment (CI/CD) model for faster software development as consumer demands evolve faster than ever and expectations rise alongside the rapid deployment of new enhancements and features in the market place. While this model can help improve the speed of new technology to market, the core of its success or failure is how well scrum teams collaborate to address complex design and implementation problems. Communication is another critical component, and can be the difference between a successful launch and an insurmountable gating factor, such as needing to punch a new hole in the firewall to get a service to run. The bottom line is nobody wins when security is compromised to standup a new release.
Scrum teams need a security master to facilitate this communication. But this individual isn’t a scrum dictator sent to hijack control. They should be a facilitator who works with the scrum team and product owner to drive security into the development process. This is where these individuals really start to attain hero status because they aren’t just defining a critical set of security requirements, they are relationship builders fostering new collaborations.
A collaborative DevSecOps security hero guides the team through general security requirements, features, functions, and architectures in an appropriate fashion and cadence that can easily be integrated into existing processes. It’s important for this scope of work to be well defined and present to meet the team’s Definition of Done (DoD). Specific requirements defined by individual user stories in the working code spring help speed the process by ensuring security is represented properly in the DoD. These user stories are important artifacts that can be utilized by the entire scrum team for better alignment, and ensure there are no lengthy gating “gotchas” at the end of the process.
For example, a common vulnerability in modern applications revolves around the improper use, or lack of use, of cryptography with encrypting sensitive data. A general requirement could be written to protect data entered in a form cryptographically that ties back to a user story about a phase-locked loop (PLL). Once the data is encrypted it can be sent to a server team with agile security experts. By writing these agile security requirements and by addressing them systematically at all levels of the development process, teams can layer in security to existing user stories more quickly, resulting in apps services, or products with less vulnerabilities.
So where do scrum teams find these heroes? The right person might be closer than you think. Often you don’t need to hire an outsider or pilfer resources from the security operations center. Instead, you can evaluate in-house developers with an affinity for security, a code expert in the reverse engineering team, or anyone in the release pipeline really who is interested, engaged, and shows the acumen to be a part of what the organization is looking to accomplish. The key is once you’ve identified and selected this individual that you nurture them. Provide additional security training, allow them the requisite time to fully understand the current processes in play, and ensure their annual business goals reflect their security work. Remember if someone is only rewarded for speed, security will take a back seat and your apps, services, and products will suffer.
Every organization has unique challenges, so start with one team and learn what works and what doesn’t work before making broad, sweeping changes. Once the process is clicking, and new security requirements are flowing into your applications, you can radiate out the agile security hero model to your other internal, and even external (sourced via a third party) teams. Implementing this model doesn’t mean your code will be perfectly secure. But having a security minded advocate in the scrum makes it a lot easier to incorporate secure measures and features into new releases.
