Posted on by Software and Information Assurancein
By Nancy Mead
This blog post is also co-authored by Carol Woody.
The exponential increase in cybercrime is a perfect example of how rapidly change is happening in cyberspace and why operational security is a critical need. In the 1990s, computer crime was usually nothing more than simple trespass. Twenty-five years later, computer crime has become a vast criminal enterprise with profits estimated at $1 trillion annually. One of the primary contributors to this astonishing success is the vulnerability of software to exploitation through defects. How pervasive is the problem of vulnerability? The average cost of a data breach is $4 million, up 29 percent since 2013, according to Ponemon Institute and IBM data. Ponemon also concluded that there's a 26-percent probability that an enterprise will be hit by one or more data breaches of 10,000 records over the next 2 years. Increased system complexity, pervasive interconnectivity, and widely distributed access have increased the challenges for building and acquiring operationally secure capabilities. This blog post introduces a set of seven principles that address the challenges of acquiring, building, deploying, and sustaining software systems to achieve a desired level of confidence for software assurance.
The accelerating pace of attacks and the apparent tendency toward more vulnerabilities seem to suggest that the gap between attacks and data protection is widening as our ability to deal with attacks diminish. Much of the information protection in place today is based on principles established by Saltzer and Schroeder in "The Protection of Information in Computer Systems," which appeared in Communications of the ACM in 1974. They defined security as "techniques that control who may use or modify the computer or the information contained in it" and described the three main categories of concern: confidentiality, integrity, and availability.
As security attacks expanded to include malware, viruses, structured query language (SQL) injections, cross-site scripting, and other mechanisms, those threats changed the structure of software and how it performs. Focusing just on information protection proved vastly insufficient. Moreover, the role of software in systems expanded such that software now controls the majority of functionality, making the impact of a security failure more critical. Those working with deployed systems refer to this enhanced security need as cybersecurity assurance, and those in the areas of acquisition and development typically reference software assurance.
It is usually more feasible to achieve an acceptable risk level (although what that risk level might be remains somewhat obscure) than to feel confident that software is free from vulnerabilities. But how do you know how many vulnerabilities actually remain? In practice, you might continue looking for errors, weaknesses, and vulnerabilities until diminishing returns make it apparent that further testing does not pay. It is not always obvious, however, when you reach that point. This ambiguity is especially the case when testing for cyber security vulnerabilities, because software is delivered into many different contexts and the variety of cyber attacks is virtually limitless.
We are increasingly seeing the integration and interoperation of security-critical and safety-critical systems. It therefore makes sense to come up with an overarching definition of software assurance that covers both security and safety. In some ways, the different approaches suggested by the existing definitions result from risks related to modern systems of systems.
Further challenges to effective operational security come from increased use of commercial off the shelf (COTS) and open-source software as components within a system. The resulting operational systems integrate software from many sources, and each piece of software is assembled as a discrete product.
Shepherding a software-intensive system through project development to deployment is just the beginning of the saga. Sustainment (maintaining a deployed system over time as technology and operational needs change) is a confusing and multi-faceted challenge: Each discrete piece of a software-intensive system is enhanced and repaired independently and reintegrated for operational use. As today's systems increasingly rely on COTS software, the issues surrounding sustainment grow more complex. Ignoring these issues can undermine the stability, security, and longevity of systems in production.
The myth linked to systems built using COTS products is that commercial products are mature and stable and adhere to well-recognized industry standards. The reality indicates more of a Rube Goldberg mix of "glue code" that links the pieces and parts into a working structure. Changing any one of the components--a common occurrence since vendors provide security updates on their own schedules--can trigger a complete restructuring to return the pieces to a working whole. This same type of sustainment challenge for accommodating system updates appears for system components built to function as common services in an enterprise environment.
Systems cannot be constructed to eliminate security risk but must incorporate capabilities to recognize, resist, and recover from attacks. Initial acquisition and design must prepare the system for implementation and sustainment. As a result, assurance must be planned across the lifecycle to ensure effective operational security over time.
Here we use the following definition of software assurance developed to incorporate lifecycle assurance:
Application of technologies and processes to achieve a required level of confidence that software systems and services function in the intended manner, are free from accidental or intentional vulnerabilities, provide security capabilities appropriate to the threat environment, and recover from intrusions and failures.
In the context of this definition of software assurance, the remainder of this post will detail seven principles that will help security and software professionals create a comprehensive lifecycle process for system and software security. A more comprehensive lifecycle process allows organizations to incorporate widely accepted and well-defined assurance approaches into their own specific methods for ensuring the operational security of their software and system assets.
Seven Principles for Software Assurance
In 1974, Saltzer and Schroeder proposed a set of software design principles that focus on protection mechanisms to "guide the design and contribute to an implementation without security flaws." Students still learn these principles in today's classrooms, but these principles are no longer sufficient, as we will explain below.
These principles were developed at a time when systems operated largely within the confines of isolated mainframes. Time has shown the value and utility in these principles, but new challenges surfaced soon after Saltzer and Schroeder proposed them. With the growth of interoperability and the massive connectivity of the Internet, the impact of the context in which a system operates has grown in importance. The Morris worm generated a massive denial of service by infecting more than 6,000 UNIX machines on November 2, 1988. Systems must now contend with malware, viruses, and external attacks on a constant basis. Although these principles still apply to security within an individual piece of technology, they are no longer sufficient to address the complexity and sophistication of the environment within which that component must operate.
We propose a set of seven principles focused on addressing the challenges of acquiring, building, deploying, and sustaining systems to achieve a desired level of confidence for software assurance:
- Defects in standardized pieces of infrastructure (such as operating systems, development platforms, firewalls, and routers) can serve as widely available threat entry points for applications.
- Using many standardized software tools to build technology establishes a dependency for the assurance of the resulting software product. Vulnerabilities can be introduced into software products by the tool builders.
In our soon-to-be-published book, Cyber Security Engineering, we demonstrate how to apply these seven core principles of software assurance to four key areas of cyber security engineering:
Wrapping Up and Looking Ahead
Effective cyber security engineering requires the integration of security into the software acquisition and development lifecycle. For engineering to address security effectively, requirements that establish the target goal for security must be in place. Risk management must include identification of possible threats and vulnerabilities within the system, along with the ways to accept or address them. There will always be cyber security risk, but engineers, managers, and organizations must be able to plan for the ways in which a system should avoid as well as recognize, resist, and recover from an attack.
Mechanisms that ensure correctness and compliance can be excellent tools if they are applied by teams and individuals with cyber security expertise and linked to appropriate and complete cyber security requirements.
This blog entry has been adapted from chapter one of our forthcoming book Cyber Security Engineering: A Practical Approach for Systems and Software Assurance, which will be published in November, 2016, by Pearson Education, InformIT as part of the SEI Series in Software Engineering.
The forthcoming book Cyber Security Engineering: A Practical Approach for Systems and Software Assurance, will be published in November, 2016 as part of the SEI Series in Software Engineering.