An April 2019 report from the Institute of Critical Infrastructure Technology (ICIT) makes the point that even though software ‘runs the world’, software security is an afterthought across virtually all industries. 

The report states that this lack of software security is actually a National Threat given that this approach leads to non-resilient software being utilized in highly interconnected environments to run private and public critical infrastructures.

A Microfocus 2018 report states that 33% of applications are never tested for security vulnerabilities. Data such as that reinforces the thought that ‘secure by design’ is not a priority for most enterprises.

The robust connectivity of the Internet of Things (IIOT) only exacerbates this situation making users ‘crash test dummies’ since robust security is not built into individual devices let alone system architectures. Some commercial software vendors even go further, looking to transfer risk and security responsibility onto system users instead of developers through convoluted terms and conditions.

What can be done?

Fortunately, the National Institute of Standards and Technology (NIST) has written a Special Publication (SP) that can serve as a reference framework to improve this situation.  NIST SP 800-64 Revision 2 focuses on Security Considerations in the System Development Life Cycle (SDLC).  While it was originally written to serve federal IT system needs, it stands as a reference source for all IT software based systems.  

The core objective is to build security into a system from inception instead of trying to bolt it on later by running systems through a series of security focused tests prior to deployment.  It is intended to be used in an existing SDLC and provide a security perspective throughout whatever software and systems development methodology is in use.

Furthermore, SP 800-64 is intended to work with other NIST guidelines such as SP 800-53 which is already in widespread usage and defines security control families to provide a comprehensive approach in building security architectures. Appendix D contains a full reference matrix specific to each of the SDLC phases.

The document also complements a Risk Management Framework perspective which looks to balance IT risks and software vulnerability mitigation with the protection of enterprise assets and data.

SDLC Security Integration Considerations

An essential part of building secure applications is understanding how software can be exploited, and purposefully avoiding vulnerabilities during development as well as mitigating malicious user activity prior to operational deployment through rigorous testing.  Organizations such as OWASP (Open Web Application Security Project) have for years published a top ten list of application software security risks and when used along side other items such as the SANS Top 20, have gone a long way to increasing the awareness of application software security.

Awareness is only the first step however. Building secure software applications that are resistant to weaknesses requires taking cybersecurity into consideration throughout the SDLC and purposefully choosing appropriate critical security controls.  

If the integration of security is done via requirements development and traceability, then the process becomes independent of any specific software development techniques.  Organizations choose an SDLC methodology for many reasons and the NIST SP 800-64 focus spans a solution lifecycle approach instead of being limited to a single software development approach.

The figure below shows the five sequential phases.  Control gates are defined to provide an objective way to move within each phase and then from one phase to the next.

NIST Conceptual View of SDLC

1. Initiation

At the start, cybersecurity should be considered primarily from the perspective of the business impact should the software system be compromised. What threats exist for a particular business or enterprise?  Mitigation against these threats leads to security focused requirements that are intended to directly address the identified security threat.  The classic cybersecurity principles of Confidentiality, Integrity and Availability can be used to derive explicit security requirements that support subsequent project planning that will span the entire SDLC. This includes the generation of a Concept of Operations (CONOPS) that provides secure software operations, identification of relevant security roles for support personnel and establishing communication with all system stakeholders that need to provide their perspectives on application security.

This type of robust security planning looks at the software application as integral to an overall IT system and allows the identification of likely software vulnerabilities that can be mitigated as development proceeds.

2. Development / Acquisition

Here, risks are assessed, and relevant security controls are selected and documented based on their ability to satisfy security requirements or mitigate the identified security risks.  Specific security focused tests should be designed and executed ensuring the intended robust security focused architecture was actually built.  Here commercial test tools can be invaluable by supporting both static and dynamic test methods and specialized techniques such as data fuzzing to generate random test data to look for coding errors and security loopholes due to insufficient bounds checking.

Relevant control gates such as architecture and design reviews can be used with great effectiveness by emphasizing a systems perspective and having all relevant stakeholders participate.  Software applications can be compared versus organization coding standards ensuring best practices are used and followed.

3. Implementation / Assessment

Here the system is put into production and evaluated in an operational context.  Various test readiness reviews and deployment readiness reviews are intended to anticipate system and software operational vulnerabilities and take an analytical look at the software prior to real users having access.

One robust method to use is pen (penetration) testing that seeks to identify system and software weaknesses that were not anticipated and mitigated through coding logic checks or other design techniques.  White box testing is when the testers are provided some context on the system and test conditions to use.  Black box testing is when testers are turned loose without much if any information on the system design and architecture.

The intent in all these activities is to identify software weaknesses and vulnerabilities and correct them before external malicious actors are able to perform any exploits.

4. Operations and Maintenance

O&M is typically the longest phase of the overall SDLC. Systems may take weeks to months to years to develop, but once put into production, systems may live on for years into decades, undergoing ongoing revisions to add new functions and address evolving cybersecurity vulnerabilities and threats.

Periodic vulnerability scans should be performed to keep up with ongoing software vulnerability identification from open sources, commercial software vendors and Federal Agencies such as the Department of Homeland Security (DHS). As software patches are identified and developed, they should be implemented on a timely basis to minimize threat windows where known software vulnerabilities can be exploited by widely available malware, ransomware and root kits.

5. Disposal

This phase is often overlooked but without explicit attention, system obsolescence can lead to orphaned data being unprotected or functions remaining operational beyond their anticipated timeline.  This can expose systems to exploits from determined attackers using tools to automate the generation of items such as input fields, looking for exploit paths to be found.

To be cost conscious, many organizations look to recycle storage devices without conducting adequate media sanitization.  Data exposure can lead to privacy violations or other types of inadvertent disclosure which were previously secure due to operational access restrictions.  Defining system disposal requirements early in the SDLC leads to a secure systems shut down long after the original system designers, developers and testers are long gone onto other projects.

Summary

The design, development and operation of new software applications should not markedly decrease the cybersecurity posture of an organization. By following a rigorous framework such as NIST SP 800-64 during an entire SDLC, new applications can provide their intended functionality and not introduce new threat vectors to be exploited when software applications are put into production.