Software Security vs. Application Security

The increased targeting by attackers of vulnerable applications has led to a gradual recognition that the network- and operating system-level protections that are now commonplace for protecting Internet-accessible systems are no longer sufficient for that purpose. This recognition has given use to emerging application security measures to augment system and network security

measures. Application security protections and mitigations are specified almost exclusively at the level of the system and network architecture rather than the individual application’s software architecture. They are primarily implemented during the application’s deployment and operation.

Application security combines system engineering techniques, such as defense-in-depth (DiD) measures (e.g., application layer firewalls, eXtensible Markup Language (XML) security gateways, sandboxing, code signing) and secure configurations, with operational security practices, including patch management and vulnerability management. Application security DiD measures operate predominately by using boundary protections to recognize and block attack patterns, and using constrained execution environments to isolate vulnerable applications, thus minimizing their exposure to attackers and their interaction with more trustworthy components. Operational security measures are focused on reducing the number or exposure of vulnerabilities in the applications (i.e., through patching), and by repeatedly reassessing the number and severity of residual vulnerabilities, and of the threats that may target and exploit them, so that the DiD measures can be adjusted accordingly to maintain their required level of effectiveness.

Application security falls short of providing an adequate basis for software security assurance comparable to the quality and safety assurances that can be achieved through use of established quality assurance practices and fault tolerance techniques respectively.

While application security practitioners acknowledge that the way in which the application is designed and built is significant in terms of reducing the likelihood and number of vulnerabilities the application will contain, these practitioners are not directly concerned with the application’s development life cycle. By contrast, software security requires security to be seen as a critical property of the software itself—a property that is best assured if it is specified from the very beginning of the software’s development process.

Software security assurance is addressed holistically and systematically, in the same way as quality and safety. In fact, security shares many of the same constituent dependability properties that must be exhibited in software for which safety and quality are to be assured. These properties include

correctness, predictability, and fault tolerance (or, in the case of security, attack tolerance). The analogy between safety and security is particularly close. The main difference is that safety-relevant faults are stochastic (i.e., unintentional or

Software Security Assurance State-of-the-Art Report (SOAR)

24 Scope.

Section 2 Definitions

accidental), whereas security-relevant faults are “sponsored,” i.e., intentionally created and activated through conscious and intentional human agency.

The ability of software to continue to operate dependably despite the presence of sponsored faults is what makes it secure. This ability is based largely on the software’s lack of vulnerability to those sponsored faults, which may be activated by direct attacks that exploit known or suspected vulnerabilities, or by the execution of embedded malicious code. This is why most definitions of secure software emphasize the absence of malicious logic and exploitable vulnerabilities.

2.4 Software Security vs. Quality, Reliability, and Safety

The difference between software security and software quality, reliability, and safety is not their objectives: the objective of each is to assure that software will be dependable despite the presence of certain internal and external stimuli, influences, and circumstances. Rather the difference lies in the nature of those stimuli, influences, and circumstances.

These differences can be characterized in terms of threats to whichever property is desired. The main threat to quality is internal, i.e., the presence in the software itself of flaws and defects that threaten its ability to operate correctly and predictably. Because such flaws and defects result from errors in judgment or execution by the software’s developer, tester, installer, or operator, they are often termed unintentional threats.

The main threats to reliability are internal and external. They include the threats to quality augmented by threats from the software’s execution environment when it behaves unpredictably (for whatever reason). The threats to safety are the same as those for reliability, with the distinction that the outcome of those threats, if they are realized, will be catastrophic to human beings, who may be killed, maimed, or suffer significant damage to their health or physical environment as a result.

The faults that unintentionally threaten the quality, reliability, and safety can also be intentionally exploited by human agents (attackers) or malicious software agents (malware). Security threats are differentiated from safety, reliability, and quality threats by their intentionality. A flaw in source code that threatens the compiled software’s reliability can also make that software vulnerable to an attacker who knows how to exploit that vulnerability to compromise the dependable execution of the software.

Security threats to software are intentional. The presence of the vulnerabilities that enable security threats to achieve their objectives may not be intentional, but the targeting and exploitation of those vulnerabilities are intentional.

Security threats to software usually manifest either as direct attacks on, or execution of malicious code embedded in, operational software, or as implantations of malicious logic or intentional vulnerabilities in software under development. John McDermott of the Naval Research Laboratory’s Center for High Assurance Computer Systems (NRL CHACS) [14] characterizes the

Software Security Assurance State-of-the-Art Report (SOAR) 25 Assumptions and Constraints.

Section 2 Definitions

difference between threats to security on the one hand and threats to safety, reliability, quality, etc., on the other. He characterizes the threats in terms of stochastic (unintentional) faults in the software vs. sponsored (intentional) faults. Stochastic faults may cause software to become vulnerable to attacks, but unlike sponsored faults, their existence is not intentional.

References

8 Committee on National Security Systems, National Information Assurance (IA) Glossary, CNSS instruction No. 4009 (revised June 2006).

Available from: http://www.cnss.gov/Assets/pdf/cnssi_4009.pdf

9 Mitchell Komaroff (ASD/NII) and Kristin Baldwin (OSD/AT&L), DoD Software Assurance Initiative (September 13, 2005).

Available from: https://acc.dau.mil/CommunityBrowser.aspx?id=25749

10 National Aeronautics and Space Administration (NASA), Software Assurance Standard, Standard No.

NASA-STD-2201-93 (Washington, DC: NASA, November 10, 1992).

Available from: http://satc.gsfc.nasa.gov/assure/assurepage.html

11 National Institute of Standards and Technology, “SAMATE—Software Assurance Metrics and Tool Evaluation” [portal page] (Gaithersburg, MD: NIST).

Available from: http://samate.nist.gov

12 US Computer Emergency Response Team, “Build Security In” [portal page] (Washington, DC).

Available from: https://buildsecurityin.us-cert.gov 13 “SAMATE” [portal page] op. cit.

14 John McDermott (Naval Research Laboratory Center for High Assurance Computer Systems), “Attack-Potential-based Survivability Modeling for High-Consequence Systems,” in Proceedings of the Third International Information Assurance Workshop, March 2005, 119–130.

Available from: http://chacs.nrl.navy.mil/publications/CHACS/2005/2005mcdermott-IWIA05preprint.pdf

Why is Software