Over many years the industry and the defense organizations have been developing in-house and third party approaches to evaluate and measure security posture of systems. Although significant progress has been made in understanding and documenting “what” needs to be evaluated together with expected results (e.g., Common Criteria [ISO 15408]), the lack of efficient approaches that address the “how” component made these evaluation methods underutilized. Currently, vendors who hope (or have hoped) to have their software systems certified are influenced by the slogan “Fewer is Better.” The fewer the security requirements to evaluate, the better their chances for success, and the process will be faster and less costly. This is a key reason why many systems are not being evaluated for environments requiring high robustness.

Understanding and assessing risks of the systems in cyberspace is a very challenging task. There is a whole industry that has been trying to crack this challenge for some time, and for that reason, it is important that we understand what the influencers of the challenge are by examining how systems are being developed and managed throughout their life cycles, and by examining the systems' complexities. Examining the key development trends and their management will give us a better understanding of areas that are necessary to cover in security evaluation approaches.

The system complexity trends have been impacted by a rapid pace of software evolution as new technologies and supported feature sets continue to introduce ever greater levels of complexity to an already complex system of networked and autonomous software components.

A majority of development trends make it very difficult to assess security posture of systems, making the software and the processes for developing and acquiring software a material weakness. Some of the key trends include:

“As the complexity of a particular system can be viewed as the degree of difficulty in predicting the properties of the system if the properties of the system's parts are given” [Weaver 1948] it will greatly influence evaluation methodology and should play a key component in risk assessment and management.

We all agree that the current software systems are larger and continue to grow in sheer size and complexity. Very rarely does a software development project start from a clean sheet of paper. More than half of all code written today is based on enhancements and maintenance of existing functions. More often than not, new features or functionality on top of an existing code base is a large, complex piece of software that has evolved into conflicting or challenging designs that often resists evolution and/or bug fixes. Furthermore, market consolidation brings the challenge of integrating these components into net-centric systems from mergers and acquisition activities, making an existing system even larger, more complex, and harder to comprehend. The system's structure includes interconnected software components that were developed using differing methodologies, a variety of technologies, and under varying constraints and assumptions. At the same time, the documentation of such systems is never up-to-date and the information available is largely folk- or judgment-driven in nature and difficult to access. The only thing trusted to be an up-to-date source is the code itself; however, comprehension of such a code is further obscured by uncontrolled use of multiple programming languages, allowing developers to freely express themselves in more artistic ways. This causes the lack of control over software architecture, leading to erosion of the initial structural concepts of the system, increasing a system's complexity even more. This is a major source of latent security defects that assessment should uncover.

The majority of system assessments primarily focus on assessing and evaluating the development process and a product's documentation, rather than the formal artifacts. Formal security analysis is rarely performed and can be characterized at the most as opportunistic. Although the development process provides a structured way of developing the system, and as such, greatly influences security posture of the system, it still only provides a single data point to corroborate the system security, leaving some major assessment methodology gaps such as:

System development usually follows one of several development processes: waterfall, iterative (e.g., agile, Rapid Application Development (RAD), Capability Maturity Model (CMM), Model Driven Architecture (MDA)), or some custom process. Besides providing a structured way to develop the product, it also provides a framework for establishing multi-segmented traceability by connecting high level policy to objectives, requirements, design specification (captured as document or prototype), and implementation of system artifacts. However, once a product is fully developed, that structure is often dissolved, creating a traceability gap between requirements and the corresponding system artifacts. Because of this traceability gap the current assessment approaches resist automation, and as the result the formal analysis of the artifacts is either skipped entirely, or at some rare occasions substituted by a very laborious and costly application of formal methods applied to manually developed models. Neither approach addresses software supply chain and pedigree of the development team.

Recently, with development of new technologies in the area of white-box and black-box vulnerability detection it became possible to automate some of the security testing for software and networked systems. Although a very powerful, cost-effective way of examining formal artifacts, the results are not conclusive when determining trustworthiness of the system. This is due to issues associated with the way these technologies are implemented in commercial tools and how these tools are applied on the given system. Let's examine these technologies and tools in more detail.

There are two types of security testing methods: white-box testing and black-box testing.

White-box testing is based on knowledge of the system internals derived directly from the code (source or binary). The white-box testing is associated with testing of the software and has inside-out focus, targeting particular constructs, statements, code paths, or code sections. A technology used in security white-box vulnerability testing is known as static analysis and is commercialized in source and binary code analyzer tools. The promise of this technology is the 100% coverage of all code paths in the system. However, tools implementing this technology have several weaknesses producing inconclusive evidence of a system's trustworthiness.

An automatic static analysis tool goes through the code, parses it, analyzes it, and searches for patterns of vulnerabilities. As a result, the tool produces a report describing the findings. As part of this process, a great deal of detailed knowledge of the system is generated because finding vulnerabilities requires a fine-grained understanding of the structure, control, and data flow of each application. However, as soon as the report is produced, this detailed knowledge disappears. It can no longer be used to systematically reproduce the analysis or to aid the assessment team to understand the system. It is only the list of vulnerabilities that they are provided with. A similar situation occurs during compilation. A compiler generates large amounts of fine-grained knowledge about the system, only to be discarded as soon as the object file is generated.

However, a consistent approach to representing and accumulating this knowledge is critical for a systematic and cost-efficient security evaluation, because not only do all code analysis capabilities need to share this knowledge, but also any inconsistencies in addressing the basic knowledge of the system will lead to bigger inconsistencies in derived reports.

An exploitable vulnerability is a complex phenomenon, so there are multiple possibilities to report it in a multitude of ways. The industry of vulnerability detection tools is still immature. There is no standardization on the nomenclature of vulnerabilities or on the common reporting practices, although several community efforts are emerging.

It is easy to make a case for the multi-stage analysis where a particular vulnerability detection capability is just one of the “data feeds” into the integrated system assessment model.

In order to obtain a cohesive view of the security application, software evaluation teams often need to do painful point-to-point integrations between existing vulnerability detection capabilities and tools. Rarely do organizations choose this path.

Black-box testing, otherwise known as dynamic testing, is designed for behavioral observation of the system in operation. It has outside-in focus, targeting functional requirements. The activity includes an expert simulating a malicious attack. Testers almost always make use of tools to simplify dynamic testing of the system for any weaknesses, technical flaws, or vulnerabilities. Currently tools in this area are categorized based on their focus of specific areas they are targeting. These areas include network security and software security, where software security is comprised of database security, security subsystems, and Web application security.

Both techniques deal with very complex log files and they need expertise to interpret them; however, most network administrators do not have sufficient experience and expertise to either properly discern false positives or set priorities for what security holes should be fixed first, which might lead to some critical vulnerabilities not being addressed in time.

In summary, weaknesses of each technique leads to a number of false positives and false negatives, making assessments costly (“weeding” through false positives) and not so assuring (not knowing what has been missed).

Techniques used in black-box software security testing are known as penetration testing. A penetration test uses a malicious attacker behavior to determine which vulnerabilities can be exploited and what level of access can be gained. Unlike network security tools, penetration tools generally focus on penetrating ports 80 (HTTP) and 443 (HTTPS). These ports are traditionally allowed through a firewall to support Web servers. This way they can identify Web applications' and Web services-based applications' vulnerabilities and misbehaviors.

Here are some characteristics of a typical penetration test:

However, recent developments in the technology areas of System Assurance offer the most promising and practical way to enhance a vendor's ability to develop and deliver software systems that can be evaluated and certified at high assurance levels while breaking the current bottleneck, which involves a laborious, unpredictable, lengthy, and costly evaluation process. These breakthrough technologies bring automation to the system assurance process.

This book provides technology guidance to achieve automation in system assurance.

Consequently, this approach would create confidence in the security posture of systems. By regaining knowledge of our systems, and accumulating the knowledge of the attackers and their methods, we would be able to reason about the security mechanisms of our systems and clearly and articulately communicate and justify our solutions. This involves a clear and comprehensive game plan, which anticipates the possible moves of the opponent and uses the home advantage and the initiative to build a reasonably strong defense.

It is the nature of cybersecurity to provide a reasonable, justifiable answer to the question of whether the countermeasures implemented in the target system adequately mitigate all threats to that system. This answer is what is sometimes called the security posture of the system. Evaluating security posture requires detailed knowledge, in particular, the knowledge of the factors internal to the system, such as the system boundaries, components, access points, countermeasures, assets, impact, policy, design, etc., as well as the factors that are external, such as threats, hazards, capability and motivations of the threat agents, etc. As vulnerability can be described as a situation where a particular threat is not mitigated, this would mean that there exists a possibility of an attack, waiting for a motivated attacker to discover this situation, and execute the attack steps.

Answering the cybersecurity question is not easy due to the uncertainty factor. There is a great deal of uncertainty associated with any external factors, but there is uncertainty associated with the internal factors too, because our knowledge of the complex target system is not perfect. There may be some uncertainty about the impacts of the incidents to the business and even about the validity of the security policy. In a slightly different sense, there is uncertainty about the behavior of the system, but this uncertainty is only related to the current state of our knowledge, and can be removed (at a certain cost) by analyzing the system deeper.

Two disciplines, security engineering and risk assessment, address the cybersecurity question from different perspectives. Security engineering addresses this question in a practical way by selecting the countermeasures and building the target system. It emphasizes building the system rather than communicating the knowledge about the system, although some design documentation may be one of the outputs of a solid engineering process. Security engineering often uses “tried and tested” solutions based on “best practices,” and selects countermeasures from catalogs. This pragmatic approach avoids analysis of threats and their mitigation by the security architecture, so justification is often done by reference to the recommended catalog of countermeasures. A clear, comprehensive, and defensible justification of the system's security architecture ought to be one of the mainstream activities of security engineering; however, there is little evidence that this is being done, in part because of the mismatch in the qualifications required for systems engineering, system validation, and verification on one hand, and the security validation, verification, and assurance on the other hand. It is not uncommon to push some uncertainty to the market as the system is released and patched later as the vulnerability is found by someone else and reported back to the engineering team.

Risk assessment is usually considered to be part of management and governance of the system. Risk assessment answers the cybersecurity question by evaluating the system. Usually there are two points in the system life cycle when such evaluation takes place: one as early as possible, right after the countermeasures have been selected, and the other one as late as possible, when the entire system has been implemented, and it is ready to be put into operation. The decision-making process of risk assessment involves analyzing the threats to the system, the countermeasures, and vulnerabilities. The emphasis of risk assessment is to identify the risks that need to be managed, and not to communicate the knowledge about the system. Neither is a clear, comprehensible, and defensible justification of the system's security architecture a mainstream activity of risk assessment. The nature of the risk assessment is that it identifies problems—not justifies that the available solution is adequate.

Risk assessment provides a probabilistic approach to dealing with uncertainty in our knowledge about the system. Lower end varieties of risk assessment teams offer a “best practice” approach, often based on the ‘best guess.” This works, because risk assessment is a pragmatic discipline, which generates the list of risks to manage and the list of recommendations of new countermeasures that would lower the risk. Since risk assessment is part of the ongoing risk management, any miscalculations can be addressed as more operational data becomes available. Risk assessment provides input to engineering, which evaluates the recommendations and implements them.

As you can see, justifying system's security posture, and communicating this knowledge in a clear, comprehensive, and defensible way, is not addressed by either security engineering or risk assessment. Engineering builds solutions. Validation and verification justify that the solution corresponds to the requirements, objectives, and policy. Risk assessment looks for problems, identifies them, and justifies significance of their existence. Risk assessment also recommends mitigating solutions. On the other hand, assurance is considered by many as an optional activity that is applicable only for a limited number of high-profile systems where high security and safety is a “must have,” such as in nuclear reactors. The reason is the perceived high cost of assurance activities. However, it is important to note that assurance closes some gaps in both security engineering and risk analysis.

The Information and Communication Technology (ICT) security community refers to ”Assurance” as confidence and trust that a product or service will function as advertised and provide the intended results or the product or service will be replaced or reconditioned. It refers to the security of the product or service and that the product or service fulfills the requirements of the situation, satisfying the Security Requirements.

The Cybersecurity Assurance community expands this Assurance description to explicitly talk about vulnerabilities. The National Defense Industrial Association (NDIA) Engineering for System Assurance Guidebook [NDIA 2008] defines “Assurance” as “justified measures of confidence that the system functions as intended and is free of exploitable vulnerabilities, either intentionally or unintentionally designed or inserted as part of the system at any time during the life cycle.” This new definition, besides arguing positive properties, “does functions as intended,” adds a need for arguing negative properties, and “does not contain exploitable vulnerabilities,” which requires more comprehensive assurance methods. This book describes a framework for implementing comprehensive assurance for cybersecurity with emphasis on automation.

The Cybersecurity community more often refers to “Assurance” as “System Assurance” or “Software Assurance” (emphasizing importance of vulnerabilities in software itself). According to the Cybersecurity community, the system assurance as a discipline studies the methods of justifying cybersecurity. It is a systematic discipline that focuses on how to provide justification that the security posture is adequate. System assurance develops a clear, comprehensive, and defensible argument for security of the system. In order to support the argument, concrete and compelling evidence must be collected. One of the sources of evidence is system analysis. System assurance deals with uncertainty through a special kind of reasoning that involves the architecture of the target system. Instead of a never-ending process of seeking more and more data to eliminate the fundamental uncertainty, system assurance uses the layered defense considerations to address the unknowns. Needless to say, the assurance argument benefits from the available knowledge related to both the external and the internal factors of cybersecurity.

The reasoning provided by the system assurance discipline is used both in the context of engineering as well as risk assessment. System assurance is a form of systematic, repeatable, and defensible system evaluation that provides more detailed results than a traditional “best-practice” approach. The key difference of the system assurance approach and traditional risk assessment is that assurance justifies the claims about the security posture of the system. Assurance is a direct way to build confidence in the system. Deficit of assurance can be directly transformed into the requirements for additional countermeasures. On the other hand, while evidence of risks, produced by detecting vulnerabilities, can also be transformed into countermeasures, it does not build confidence in the system, because the absence of vulnerabilities makes only a weak indirect case about the security posture of the system. This is why we need system assurance. This is why we need to move beyond detecting vulnerabilities.

The answer to weaponized exploits and malware is to automate security analysis, automate checklists involved in threat and risk analysis and use the assurance case as a planning tool for establishing defense in depth.

From the system assurance perspective, deficiencies in the argument indicate defects in the defense. Particular points in the architecture of the system that prevent us from building a defensible assurance argument are the candidates for the engineering to fix. The new, improved mechanisms will directly support the assurance argument and, at the same time, improve the security posture of the system.

Collecting evidence for assurance, in particular within the layered defense argument, is more demanding on the depth and accuracy of the system analysis and the accuracy of the corresponding data.

An ecosystem refers to a community of participants in knowledge-intensive exchanges involving an explicit and growing shared body of knowledge and corresponding automated tools for collecting, analyzing, and reporting on the various facets of knowledge, as well as a market where participants exchange tools, services, and content in order to solve significant problems. The essential characteristic of an ecosystem is establishment of knowledge content as a product. An ecosystem involves a certain communication infrastructure, sometimes referred to as “plumbing,” based on the number of knowledge-sharing protocols provided by a number of knowledge-management tools.

The purpose of the ecosystem within a cybersecurity community is to facilitate collection and accumulation of cybersecurity knowledge needed for assurance, and to ensure its efficient and affordable delivery to the defenders of cybersystems, as well as to other stakeholders. An important feature of the cybersecurity knowledge is separation between the general knowledge (applicable to large families of systems) and concrete knowledge (accurate facts related to the system of interest). To illustrate this separation, a certain area at the bottom of the ecosystem “marketplace” in the middle of Figure 1 represents concrete knowledge, while the rest represents general knowledge. Keep in mind that “concrete” facts are specific to the system of interest, so, the “concrete knowledge” area represents multiple local cyberdefense environments, while the “general knowledge” area is the knowledge owned by the entire cyberdefense community. The icons titled “defender,” “inspector,” and “stakeholder” in Figure 1 represent people interested in providing assurance of one individual system. Basically, this is your team.

The OMG Software Assurance Ecosystem defines a stack of standard protocols for the knowledge-based tools, including knowledge discovery tools, knowledge integration tools, knowledge transformation tools, knowledge provisioning and management tools, and knowledge delivery tools.

The key requirement for knowledge exchange between tools in the ecosystem is a common, agreed upon vocabulary that represents the conceptual commitment of the participants. However, much of the computer security information gathered and disseminated by individuals and organizations cannot currently be combined or compared because a common vocabulary has yet to emerge in the field of computer security. Numerous individuals and organizations regularly gather and disseminate information related to computer security. This information describes security events, as well as the characteristics of computer and network systems. Unfortunately, much of this computer security information cannot be combined without significant manual effort because the terms currently used in the field of computer security tend to be unique to different individuals and organizations.

Devising a common vocabulary for cybersecurity is the first logical step in the industry evolution from proprietary, in-house, stovepipe solutions to efficient and collaborative cybersecurity ecosystem that can take advantage of the economies of scale. Established standard vocabulary brings several tangible benefits and justifies the efforts required. Indeed, at the heart of any security assessment project there is a need to manage and integrate multiple pieces of information from different sources. Standard vocabulary decouples producers of cybersecurity knowledge from the consumers of knowledge and the distribution channels, and consequently opens up the market of efficient tools that can take advantage of the economies of scale. A single coherent picture that is both accurate and comprehensive enough is necessary to reason about the security of the system and to build a defendable assurance case. Knowledge-based systems and services are expensive to build, test, and maintain. Several technical problems stand in the way of shared, reusable, knowledge-based systems. Like conventional applications, knowledge-based systems are based on heterogeneous hardware platforms, programming languages, and network protocols. However, knowledge-based systems pose special requirements for interoperability. Such systems operate on and communicate using machine-readable knowledge content. They ask queries and give answers. They take “background knowledge” as an input and exchange derived knowledge. For such knowledge-level communication, we need conventions at three levels: knowledge representation format, communication protocol, and specification of the content of shared knowledge. Standard knowledge representation formats and communication protocols are independent of the content of knowledge being exchanged or communicated. A common language is used for standardization of the knowledge content. In general, agreeing upon a vocabulary for a phenomenon makes systematic studies possible. In particular, standardization of the cybersecurity vocabulary brings the following benefits:

A common language is a linguistic model of a domain that is used to compose complex statements about the domain. The foundation of a linguistic model is a vocabulary. From a finite, well-defined vocabulary one can compose a large number of coherent sentences. A body of formally represented knowledge is based on a conceptualization: the objects, concepts, and other entities that are presumed to exist in some area of interest and the relationships between them. A conceptualization is an abstract, simplified view of the world that we wish to represent for some purpose. Every knowledge base, knowledge-based system, or knowledge-level agent is committed to some conceptualization, explicitly or implicitly. That is one reason why vocabulary, rather than format is the focus of linguistic models. The set of objects that can be represented by the statements of a linguistic model is called the universe of discourse. This set of objects, and the discernable relationships among them, are reflected in the vocabulary as a set of terms. In such a vocabulary, definitions associate the names of objects and concepts in the universe of discourse with human-readable text describing what the names are meant to denote, and formal rules that constrain the interpretation and well-formed use of these terms.

Pragmatically, a common language defines the vocabulary with which queries and assertions are exchanged among participants of the ecosystem. Conceptual commitments are agreements to use the shared vocabulary in a coherent and consistent manner. The agents sharing a vocabulary need not share a knowledge base; each knows things the other does not, and an agent that commits to a conceptualization is not required to answer all queries that can be formulated in the shared vocabulary. In short, a commitment to a common vocabulary is a guarantee of consistency, and supports multiple implementation choices with respect to queries and assertions using the vocabulary. A vocabulary serves a different purpose than a knowledge base: a shared language need only describe a vocabulary for talking about a domain, whereas a knowledge base may include the knowledge needed to solve a problem or answer arbitrary queries about a domain. Knowledge base includes concrete and specific operational facts.

Linguistic models include the following three important parts: