When individuals are trained effectively, with goals set and expectations clear, it becomes far easier for them to understand their place in the security landscape and take responsibility where appropriate. In the case of developers, especially, they’re given the tools and knowledge to write secure code from the beginning. However, this is best orchestrated in a positive security environment, where there is less double-handling, finger-pointing, and siloed project work.
Security must be a high priority for the entire organization, with a supportive and collaborative commitment to delivering great, secure software. This will mean budgets are adequate to roll out fun, engaging training that utilizes real-world code vulnerabilities and buy-in across the organization to keep the momentum going. In this constantly evolving digital landscape, training must be as continuous as delivery. If you’ve been told in the past that “one-time” or “set-and-forget” compliance training is adequate or effective, you should understand that this is a fallacy.
While this new NIST framework does not specifically articulate the requirement to nurture a positive security culture, adhering successfully to the guidelines will most certainly require one. The NIST guidelines do note, however, that organizations should “define policies that specify the security requirements for the organization’s software to meet, including secure coding practices for developers to follow.” This is vital to scale and hone security skills within teams. It may also be helpful to consider the following questions when assessing your own policies and current AppSec climate:
- Are software security guidelines and expectations clearly defined?
- Is everyone clear on the role they play in achieving them?
- Is the training frequent and assessed?
- Are your developers aware of the huge role they can play in eliminating common security bugs before they happen?
The answer to the last question is largely up to the organization and the training it chooses. It must be relevant, it must be frequent, and it must be engaging. Find a solution that can be applied to developers’ everyday work and contextually build their knowledge.
What Now?
A deep-dive into these new guidelines is likely to be overwhelming. It really does take a village to create, verify, and deploy the iron-clad secure software most businesses need, in the most secure way possible. It’s not just about training, either. There are guidelines to consider when using third-party software (using components with known vulnerabilities still sits on the OWASP [Open Web Application Security Project] Top 10 list of the most critical security risks to web applications, after all). These include suggestions around verification, penetration testing, and code review, as well as guidelines for security record-keeping, appropriate toolchains, and everything else. Actionable insights for the whole picture can be found in Gary McGraw’s Building Security In Maturity Model (BSIMM), which is referenced throughout NIST’s document.
However, the quickest win can be achieved if your developers are empowered with the right tools and knowledge to truly succeed in building secure software from the start. It’s cheaper for the business (and faster overall) to stop common vulnerabilities from popping up in later stages of the SDLC, time and time again. Play to their strengths and offer an incentive to get involved with the security side of the organization. It really can be fun, and they can be the just-in-time heroes you need to keep the bad guys out and our data safe.