InfoSec-Specific Executive Development for
CISOs and Aspiring Security Leaders.
Live Faculty-led instruction and interactive
labs to build you and your team's InfoSec skills
All software developers know how to code, but that doesn’t mean they all fully understand how to code securely. This piece outlines the most fundamental secure software development activities and provides actionable guidance to improve secure coding practices.
We suggest integrating a series of security activities directly into your existing software development processes. Irrespective of how you currently build your software – traditional waterfall or modern DevOps and continuous integration/continuous
development (CI/CD) – you can enhance your existing practices with a carefully selected set of security activities.
Specifically, all software development activities tend to include, to one degree or another, a set of actions descended from the early waterfall methodologies of the 1970s and 1980s. At a minimum, these include:
Each of those processes can be further broken down into its core components, but from a top-level viewpoint, they comprise the fundamentals.
Today’s agile methodologies such as DevOps employ many of these same processes, but the ordering of events varies to resemble spiral and rapid prototype software engineering processes more closely. Further, agile seeks to empower software developers
themselves to perform much of the heavy lifting formerly done by security staff and others. It also focuses on re-using software components that have gone through rigorous vetting processes already to leverage those efforts over and over. All these
things are to be commended and can be thoroughly leveraged in building a set of secure development activities in an agile environment.
For each of the process steps above, one or more security activities can enhance the overall security of the end product.
READ: How to Hire and Retain Cybersecurity Talent
Threat modeling is a process in which a software product’s design is reviewed critically for potential – and often disastrous – security design defects. A good threat model can also provide vital navigational inputs to the security process
by spotlighting areas of the software that warrant extra scrutiny in code reviews and/or testing. As such, a threat model done early and updated often during the development process should be considered a vital aspect of software development.
While available tools to support threat modeling are scant, a whiteboard and a capable team of participants can prove more than adequate. Teams should consider:
Particularly in agile methodologies, the notion of a “design” may well be an ever evolving and changing thing. That is to be expected and is entirely supportable through threat modeling. Whenever material changes are made to a design, the
threat model should be re-visited to ensure it addresses any corresponding changes there. This is true irrespective of how formally or informally the actual design architecture is collected. Even a whiteboard or back-of-the-napkin view of an application’s
architecture can be helpful.
The coding process should follow existing secure code patterns and templates, and the resulting code should be reviewed for compliance as well as potential security defects. Teams should consider:
READ: How to Develop a Cybersecurity Training Program
From a unit level all the way up to the full software complement, software should be rigorously tested for security defects. This should include risk-driven testing of specific security-critical features (e.g., appropriate encryption for payment card
information) up to testing for well-known coding defects (e.g., cross-site scripting, SQL injection). Teams should consider:
During deployment, additional tests and validation steps should be performed. These steps might include:
Once deployed, the security of a software system should be maintained just as its configuration is. Threat intelligence should be seeking information about defects in all the software components, as well as for actionable indicators of compromise (IoCs)
gathered from incident response operations internally and within the industry.
During ongoing operation and maintenance, it is important to make use of threat intelligence to keep up to date with ever evolving threats and attack techniques. Periodic vulnerability scanning for known vulnerabilities is a great starting point, along
with periodically revisiting the application’s component inventory and reviewing it for newly discovered vulnerabilities, patches, updates, etc.
While everything listed within the five steps above can seem overwhelming, there is no problem with implementing these processes iteratively and growing maturity over time. To improve your chances of success, consider:
Although reasonable efforts will be made to ensure the completeness and accuracy of the information contained in our blog posts, no liability can be accepted by IANS or our Faculty members for the results of any actions taken by individuals or firms in
connection with such information, opinions, or advice.
January 20, 2022
By IANS Faculty
How sound is your data governance program? It all starts with the basics. Learn how to establish a solid foundation for your data governance program.
January 18, 2022
Learn how to put a workable data management and governance process in place.
January 13, 2022
Understand how the three lines of defense work and learn how to apply it properly inside your organization.