Why is Secure System Development So Hard?
Because we are not really trying
So why is secure system development so hard? Too many of the major defense contractors use this as an excuse and too many contract officers don’t enforce the contract’s cybersecurity requirements. Some of this is not totally at the feet of the Contract Officer (CO/KO), but the leadership that places their least able Contract Officer Representatives (COR) on the task of oversight.
It should not be difficult and should follow existing best practices that have been available for decades. It should follow the same path as normal software, hardware, or system development. At the core of the current break-down is the disconnect between security requirements, as formulated as a “security control,” and the systems engineering process.
Systems engineering is the foundation of all development efforts. It translates the sought general functionality into a technical specification. For example, a possible function for a modern-day tank is to fire a round for a “threshold” distance of 5 kilometers with and “objective” range of 6 kilometers. The Systems Engineer takes the base functional requirement of “shooting a high explosive round” to a specified and measurable distance. In the case of security, an example of a specified security control would state that all “data at rest be encrypted.” The Systems Engineer would take this broad requirement and define it better with, for example, “employ a 256-bit AES symmetric encryption application.”
Unfortunately, these obvious connections typically do not occur—until the very end when the system is already built!
While many believe that this process is already understood and completely adhered to by major businesses and governments, this in fact is far from the truth. The effort here is to simply educate those overseeing cybersecurity development contracts and to ensure their ability to recognize good engineering processes that meet defined requirements.
What is Systems Security Engineering?
For example, NIST 800-160, Systems Security Engineering (SSE), provides the strategic overview of the SSE process; however, it fails to provide the pragmatic help and direction to users that desperately need better guidance than best practice suggestions.
This is not a condemnation of NIST’s excellent work in this area for years but is an unfortunate rebuke. NIST’s works are too academic and strategic to be implemented by novice companies and agencies.
SSE provides the foundation for a structured method to engineering and creating a “trusted” and secure system. “Trust” implies that required or critical security functional requirements needed for a component, subsystem, system, network, application, mission, or enterprise are an integral part of the target entity. Systems security engineering is a sub-set of the field of Systems Engineering (SE); however, the process an SE uses is no different than SSE.
A trusted system is a system that meets specific security requirements. SSE provides the needed balancing engineering capability that provides security trust to the target system entity. The specific scope of security must be clearly defined by the functional security requirements by the user, system owner and stakeholders, collectively, in terms of the assets to which security applies and the consequences against which security is assessed.
SSE contributes to a broad-based and holistic security perspective and focus. SSE actions use standard and accepted systems engineering and security principles, concepts, and techniques to leverage, adapt, and supplement the relevant principles and practices. These actions are performed systematically to produce acceptable outcomes at every phase of the System (or Software) Development Life Cycle (SDLC).
NIST 800-53 is cumbersome
In the age of lean and agile development, can SSE and “Agile Cybersecurity” fit into these paradigms? Is it possible to take the complexity of security controls and measures from the varied National Institute of Standards and Technology’s (NIST) frameworks to keep pace with the demands for agility? Suggest it is possible to use these already defined “security functionality controls” and directly convert them into typical technical specifications.
Furthermore, if we determine, based upon the current mainstream direction from NIST to establish such standards, a hybrid solution is necessitated. For any of the several NIST candidate frameworks, to even include NIST 800-53, NIST 800-171, and the National Cybersecurity Framework, a “roadmap” to transition to good and secure system development best-practices.
“Agility already exists within these frameworks”
Considering the strengths and weaknesses of the “agile” versus the “non-agile” cybersecurity frameworks, agile is a certain possibility when the processes and principles described in the next chapter are effectively employed. While NIST 800-53, revision 4, “Security and Privacy Controls for Federal Information Systems and Organizations”[1], specifically, is a cumbersome and bottom-driven approach to cybersecurity, it has its own distinct advantages and disadvantages within secure system development.
We should also consider the advent of the National Cybersecurity Framework (NCF), NIST 800-171, the System Administration, Audit, Network and Security (SANS) Institute (a non-NIST based) solution and the Health Insurance Portability and Accountability Act (HIPAA) as the most likely to inject agility to the system and software development processes. These are the major candidates most likely to ensure solid cybersecurity protections and meet the rapidity called for by agile development; the hope lies with these faster-moving solutions than NIST 800-53.
These frameworks and their associated strengths can be contrasted to NIST 800-53. These “agile” approaches have a defined set of top-down and global controls that affords actual simplicity that may in fact be where cybersecurity must go to remain viable. These controls more easily address and limit the major risks and threats affecting the cybersecurity environment across the nation and the globe; while not as all-encompassing as NIST 800-53, the immediate solutions rest with these four major approaches depending in part to their unique IT environments.[2]
“Agility” Cybersecurity Framework Spectrum (ACFS)
Viewing the advantages of each side of the “Agility” Cybersecurity Framework Spectrum (ACFS)(above), the real agility lies with the simplicity and more specifically, the constrained number of controls on the left side of the ACFS Venn diagram. It provides the broadest solutions for disparate IT systems and environments. NCF, for example, and its brethren frameworks, are ideal to describe an agile environment and to address software release/version updates in much shorter timeframes.
SSE is not difficult if we only:
- Enforce the cybersecurity contractual requirements of the system developer (and, not the cybersecurity assessors to fix/solve).
- Place our best and brightest as CORs, or continue to deliver insecure systems to the government and business sectors
[1] NIST 800-53 revision 5 is currently in draft. When finally released, it will remove the word “federal” to denote its applicability by companies, agencies, and organizations not US federal entities.
[2] For example, HIPAA was created around the protection of Personal Health Information (PHI) and is mandated under federal law as the requited framework specific to the defined “covered entities.”
Ms. Columbus has worked in the Intelligence Community (IC) for over 20 years. She retired from the US Air Force in 2014 after working as a Senior Advisor providing authoritative advice on all aspects of Cyberspace operations, force structure and organizational concepts. She oversaw strategic support activities to enable the right mix of cyber capabilities for future operations.
