The new NIST guidelines: Why customized training is essential to create secure software

Published Dec 02, 2019
by Pieter Danhieux
cASE sTUDY

The new NIST guidelines: Why customized training is essential to create secure software

Published Dec 02, 2019
by Pieter Danhieux
View Resource
View Resource

On June 11, 2019, the National Institute of Standards & Technology (NIST) released an updated white paper, detailing several action plans for reducing software vulnerabilities and cyber risk. Titled Mitigating the Risk of Software Vulnerabilities by Adopting a Secure Software Development Framework (SSDF), NIST provides organizations solid guidelines to avoid the nasty - not to mention expensive - consequences of a data breach.

It is important to note that the SSDF is deliberately generic, it does not assume every organization has the exact same software security goals, nor does it prescribe an exact mechanism for achieving them. The main objective is implementing security best practices. As is stated by the writer, Donna Dodson: "While the desire is for each security producer to follow all applicable practices, the expectation is that the degree to which each practice is implemented will vary based on the producer's security assumptions. The practices provide flexibility for implementers, but they are also clear to avoid leaving too much open to interpretation".

Of particular interest to me, of course, were the specific inclusions around software security training for developers. Now, we have known for a long time that developers need adequate training if they are to defend an organization from the very beginning of the software development process... but what is adequate, exactly? There are a lot of differing opinions out there. However, I think the envelope is finally being pushed in a direction that will ignite significant positive results.

There's security training... and there's effective security training.

I have spoken at length about the need for software security training to be more effectively implemented, engaged with and tailored to the needs of the developer. Even now, in many organizations, it's a "tick-the-box" exercise at best. Perhaps there are a few hours of video training, or even precious time spent off the tools for some classroom-based learning. The fact there are large-scale data breaches every other day, perpetrated by attackers who are exploiting well-known (and usually, easily fixed) vulnerabilities is evidence that software security training isn't anywhere near as effective as it needs to be. And, perhaps most importantly, there is very little in place to verify whether the training was effective at all: are vulnerabilities fixed faster? are vulnerabilities reducing in code? Have people actually completed the training, or have they just clicked "next" to complete it?

Developers are busy people, working hard to deliver to strict deadlines. Security is an inconvenience a lot of the time, and rarely are they equipped with the knowledge during their education to successfully mitigate cyber risk. The word "security" usually comes up when a member of the AppSec team is pointing out flaws in their work, making for a rather cold and dysfunctional relationship. A "your baby is ugly; go fix it" scenario.

What does this tell us? It's a decades-old red flag that we are not doing enough to win developers over on security; they are not motivated to take responsibility, nor seek out the tools they need to create software that is functional, yet made with security best practice in mind.

Developers are clever, creative and love to solve problems. It is quite unlikely that watching endless videos on security vulnerabilities is going to excite them, or help them remain engaged. In my time as a SANS instructor, I learned very quickly that the best training is hands-on, forcing them to analyze and be challenged intellectually, using real-world examples that test their brain and build on prior learning. Gamification and friendly competition are also powerful tools to get everyone on-board with new concepts, while remaining useful and practical in application.

NIST's guidelines specify: "Provide role-specific training for all personnel in roles with responsibilities that contribute to secure development. Periodically review role-specific training and update it as needed." And later: "Define roles and responsibilities for cybersecurity staff, security champions, senior management, software developers, product owners, and others involved in the SDLC."

This statement, while not specific on the type of training, is still helping to shift organizations left and help keep security best practice front-of-mind. It is putting the onus on finding effective, more specific training solutions back onto the company, and this will hopefully result in developers being armed with the right tools and knowledge to succeed.

Culture: the missing link.

Even if an organization is putting time and resources into training developers and other key staff, placing emphasis on their role in preventing vulnerabilities and reducing security risk, the effort can often go to waste if the security culture of an organization remains fundamentally broken.

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 front-of-mind 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, this is a fallacy.

While this new NIST framework does not specifically articulate the requirement to nurture a positive security culture, adhering successfully to their guidelines will most certainly require one. They 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".

The above is vital to scale and hone security skills within teams, and it may be helpful to consider the following 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?

Now, that last part is, as I have said, largely up to the organization and the training they choose. It must be relevant, it must be frequent, it must be engaging. Find a solution that can be applied to their everyday work and contextually build their knowledge.

What now?

A deep-dive into these new guidelines is likely to be fairly 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 in the OWASP Top 10, after all), 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 Dr. Gary McGraw's BSIMM model, 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.

References:

  1. MITIGATING THE RISK OF SOFTWARE VULNERABILITIES BY ADOPTING AN SSDF (JUNE 11, 2019), Page 2.
  2. MITIGATING THE RISK OF SOFTWARE VULNERABILITIES BY ADOPTING AN SSDF (JUNE 11, 2019), Page 5.
  3. MITIGATING THE RISK OF SOFTWARE VULNERABILITIES BY ADOPTING AN SSDF (JUNE 11, 2019), Page 4.
View Resource
View Resource

Author

Pieter Danhieux

Pieter Danhieux is a globally recognized security expert, with over 12 years experience as a security consultant and 8 years as a Principal Instructor for SANS teaching offensive techniques on how to target and assess organizations, systems and individuals for security weaknesses. In 2016, he was recognized as one of the Coolest Tech people in Australia (Business Insider), awarded Cyber Security Professional of the Year (AISA - Australian Information Security Association) and holds GSE, CISSP, GCIH, GCFA, GSEC, GPEN, GWAPT, GCIA certifications.

Want more?

Dive into onto our latest secure coding insights on the blog.

Our extensive resource library aims to empower the human approach to secure coding upskilling.

View Blog
Want more?

Get the latest research on developer-driven security

Our extensive resource library is full of helpful resources from whitepapers to webinars to get you started with developer-driven secure coding. Explore it now.

Resource Hub

The new NIST guidelines: Why customized training is essential to create secure software

Published Dec 02, 2019
By Pieter Danhieux

On June 11, 2019, the National Institute of Standards & Technology (NIST) released an updated white paper, detailing several action plans for reducing software vulnerabilities and cyber risk. Titled Mitigating the Risk of Software Vulnerabilities by Adopting a Secure Software Development Framework (SSDF), NIST provides organizations solid guidelines to avoid the nasty - not to mention expensive - consequences of a data breach.

It is important to note that the SSDF is deliberately generic, it does not assume every organization has the exact same software security goals, nor does it prescribe an exact mechanism for achieving them. The main objective is implementing security best practices. As is stated by the writer, Donna Dodson: "While the desire is for each security producer to follow all applicable practices, the expectation is that the degree to which each practice is implemented will vary based on the producer's security assumptions. The practices provide flexibility for implementers, but they are also clear to avoid leaving too much open to interpretation".

Of particular interest to me, of course, were the specific inclusions around software security training for developers. Now, we have known for a long time that developers need adequate training if they are to defend an organization from the very beginning of the software development process... but what is adequate, exactly? There are a lot of differing opinions out there. However, I think the envelope is finally being pushed in a direction that will ignite significant positive results.

There's security training... and there's effective security training.

I have spoken at length about the need for software security training to be more effectively implemented, engaged with and tailored to the needs of the developer. Even now, in many organizations, it's a "tick-the-box" exercise at best. Perhaps there are a few hours of video training, or even precious time spent off the tools for some classroom-based learning. The fact there are large-scale data breaches every other day, perpetrated by attackers who are exploiting well-known (and usually, easily fixed) vulnerabilities is evidence that software security training isn't anywhere near as effective as it needs to be. And, perhaps most importantly, there is very little in place to verify whether the training was effective at all: are vulnerabilities fixed faster? are vulnerabilities reducing in code? Have people actually completed the training, or have they just clicked "next" to complete it?

Developers are busy people, working hard to deliver to strict deadlines. Security is an inconvenience a lot of the time, and rarely are they equipped with the knowledge during their education to successfully mitigate cyber risk. The word "security" usually comes up when a member of the AppSec team is pointing out flaws in their work, making for a rather cold and dysfunctional relationship. A "your baby is ugly; go fix it" scenario.

What does this tell us? It's a decades-old red flag that we are not doing enough to win developers over on security; they are not motivated to take responsibility, nor seek out the tools they need to create software that is functional, yet made with security best practice in mind.

Developers are clever, creative and love to solve problems. It is quite unlikely that watching endless videos on security vulnerabilities is going to excite them, or help them remain engaged. In my time as a SANS instructor, I learned very quickly that the best training is hands-on, forcing them to analyze and be challenged intellectually, using real-world examples that test their brain and build on prior learning. Gamification and friendly competition are also powerful tools to get everyone on-board with new concepts, while remaining useful and practical in application.

NIST's guidelines specify: "Provide role-specific training for all personnel in roles with responsibilities that contribute to secure development. Periodically review role-specific training and update it as needed." And later: "Define roles and responsibilities for cybersecurity staff, security champions, senior management, software developers, product owners, and others involved in the SDLC."

This statement, while not specific on the type of training, is still helping to shift organizations left and help keep security best practice front-of-mind. It is putting the onus on finding effective, more specific training solutions back onto the company, and this will hopefully result in developers being armed with the right tools and knowledge to succeed.

Culture: the missing link.

Even if an organization is putting time and resources into training developers and other key staff, placing emphasis on their role in preventing vulnerabilities and reducing security risk, the effort can often go to waste if the security culture of an organization remains fundamentally broken.

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 front-of-mind 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, this is a fallacy.

While this new NIST framework does not specifically articulate the requirement to nurture a positive security culture, adhering successfully to their guidelines will most certainly require one. They 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".

The above is vital to scale and hone security skills within teams, and it may be helpful to consider the following 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?

Now, that last part is, as I have said, largely up to the organization and the training they choose. It must be relevant, it must be frequent, it must be engaging. Find a solution that can be applied to their everyday work and contextually build their knowledge.

What now?

A deep-dive into these new guidelines is likely to be fairly 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 in the OWASP Top 10, after all), 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 Dr. Gary McGraw's BSIMM model, 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.

References:

  1. MITIGATING THE RISK OF SOFTWARE VULNERABILITIES BY ADOPTING AN SSDF (JUNE 11, 2019), Page 2.
  2. MITIGATING THE RISK OF SOFTWARE VULNERABILITIES BY ADOPTING AN SSDF (JUNE 11, 2019), Page 5.
  3. MITIGATING THE RISK OF SOFTWARE VULNERABILITIES BY ADOPTING AN SSDF (JUNE 11, 2019), Page 4.

We would like your permission to send you information on our products and/or related secure coding topics. We’ll always treat your personal details with the utmost care and will never sell them to other companies for marketing purposes.

To submit the form, please enable 'Analytics' cookies. Feel free to disable them again once you're done.