Security Issues Associated With Component-Based Software EngineeringSoftware Engineering

For many organizations, turnkey software applications do not provide the necessary functionality or flexibility to support their mission. Under pressure to produce systems more quickly using state-of-the-art software products and technologies, software engineers are forced to use third-party components about whose underlying security properties they have little or no knowledge.

Software engineers generally lack confidence in COTS (and to a lesser extent open source) components because they cannot assess the compatibility between the components’ security properties and the security requirements of their own applications.

In component-based software engineering, a software-intensive system is composed of several stand-alone software components acquired from

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

82

Section 5 SDLC Processes and Methods and the Security of Software

COTS or open source suppliers. In a component-based system, the developer needs to achieve both the security compatibility between pairs of interacting components and the security objectives of the entire system.

Software components range from individual procedure and object libraries to turnkey applications that may be composed of other, smaller components. Regardless, as they are considered for assembly into a new component-based system, each component’s security properties need to be defined to be sufficient and meaningful to the other components to which those properties will be exposed, i.e., the other components with which the component will interact.

Over its life time, the same component may play a variety of roles in a variety of systems running in a variety of environments. The security properties exhibited by the component will seldom satisfy the security requirements for all these possible combinations; the component may be proved secure in one application in a particular operating environment, but insecure when used in a different application and/or environment. For example, a component considered reasonably secure in an application for a car manufacturing plant may not be secure when used in an air traffic control system because although the component’s functionality provided by the component remains same for both applications the use contexts and security requirements for the applications differ.

In a well-designed software application, it should be possible to isolate various components and identify those that need to be examined in depth. For example, a component used to perform authentication of users, such as a UNIX pluggable authentication module (PAM), should have strictly defined inputs and outputs while interfacing with only a small portion of the application. In this case, in-depth security testing can be performed on the component itself in place of the entire login system used by the application. If a system is not designed to separate components, the entire system must be examined—which is often infeasible. By using a strictly defined interface, it is possible to generate a test component that will test how the application interfaces with the component, providing assurance that the integrated system will function as expected.

However, complex component interfaces or multipurpose components may be necessary for a particular system, limiting the effectiveness of testing individual components or how the application interfaces with the component.

Similarly, components should communicate using open standards.

According to David A. Wheeler of the Institute for Defense Analyses (IDA), open standards “create economic conditions necessary for creating secure components.” [89] Similarly, Jerome Saltzer and Michael Schroeder identified the need for openness in 1973: “This decoupling of protection mechanisms from protection keys permits the mechanisms to be examined by many reviewers without concern that the review may itself compromise the safeguards.” [90]

Using open standards is beneficial for security for several reasons: multiple

Software Security Assurance State-of-the-Art Report (SOAR) 83 Intended Audience.

Section 5 SDLC Processes and Methods and the Security of Software

components can be tested and compared using the same tests, and a vulnerable component may be replaced with another component easily. Finally, the ability to replace components can prove immeasurably useful when responding to vulnerabilities because it introduces diversity into the system.

For Further Reading

(DHS), “BuildSecurityIn Portal”, “Assembly, Integration, and Evolution”, (DHS).

Available from: https://buildsecurityin.us-cert.gov/daisy/bsi/articles/best-practices/assembly.html Arlene F. Minkiewicz, “Security in a COTS-Based Software System”, CrossTalk, (November).

Available from: http://www.stsc.hill.af.mil/crosstalk/2005/11/0511Minkiewicz.html

Davide Balzarotti, Mattia Monda, and Sabrina Sicari (Milan Polytechnic, University of Milan and University of Catania), “Assessing the Risk of Using Vulnerable Components”, in Springer, Quality of Protection: Security Measurements and Metrics, Advances in Information Security; 2006.

Available from: http://homes.dico.unimi.it/~monga/lib/qop.pdf

5.1.1.2.1 Assuring the Security of Component-Based Systems

Even if the security of all of the system’s individual components can be established, this will not be enough to predict whether their secure behavior will continue to be exhibited when they interact with other components in a larger component-based system. Nor will it help predict the overall security of the system assembled from those components. A security claim for a single component (e.g., a CC ST) in a system assembled from multiple components is of little help in determining the assurance of that system.

Individual component security evaluations focus on the component in isolation (and CC evaluations, as noted in Section 4.7, focus solely on the correctness of the component’s security functionality rather than its continued dependability in the face of threats). Examining a component in isolation cannot reveal the security conflicts that will arise as a result of interactions between components. Such conflicts, often referred to as security mismatches, usually originate in an inconsistency between the security assumptions one component has about another’s security properties, functionality, policy rules, constraints, etc., and those that the second component actually exhibits. The problem is complicated by the need to periodically add or change the functionality of individual components or the system as a whole, often necessitating changes to the assembly’s design, as well as to the individual components.

Research into assuring systems assembled from components dates as far back as 1973 with the Stanford Research Institute (SRI) Computer Science Lab’s (CSL) Provably Secure Operating System (PSOS). [91] The PSOS project demonstrated how a complex system of small modular components could be predictably composed and analyzed using formal specifications and examining dependencies. According to Peter Neumann, principal scientist at SRI’s CSL and one of the researchers involved with PSOS, “One of the biggest problems (associated with trustworthy systems) is the composition problem—how do we combine components into systems that predictably enhance trustworthiness.” [92]

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

84 Scope.

Section 5 SDLC Processes and Methods and the Security of Software

Neumann and the CSL, through the Defense Advanced Research Projects Agency (DARPA) Composable High-Assurance Trustworthy Systems (CHATS) project, published guidelines for composing a secure system in December 2004. [93]

With some of the same objectives, the Carnegie Mellon University (CMU) Software Engineering Institute (SEI) sponsors the Predictable Assembly from Certifiable Components (PACC) project, which aims to develop methods for predicting the behavior of a component-based system prior to implementation. [94] In addition the US Naval Research Laboratory (NRL) sponsors the Center for High Assurance Computer Systems (CHACS), which is investigating techniques for developing highly-assured building blocks (i.e., components) from which trustworthy systems can be assembled. [95]

Each of these projects is developing techniques for identifying the effects of individual components on the system as a whole. Most of this research is difficult; success stories, such as PSOS, tend to rely on highly assured custom-developed components rather than on commodity COTS components.

Assured component assembly is becoming an increasingly popular research topic for survivable systems engineering. Robert Ellison of the CMU CERT provides an overview of the composition problem with respect to systems engineering on the DHS BuildSecurityIn portal. The CMU CERT Survivable Systems Engineering team is sponsoring a number of research activities related to assured component assembly, in particular the automated component composition for developing reliable systems project, which aims to define methods for automatically calculating the composite behavior of components of a system.

Testing and certification are becoming an important factor in assessing the security of component assemblies—both to ensure the security of components and to ensure their interoperability.

The DoD Software Assurance Tiger Team (see Section 6.1) is developing a DoD Software Assurance Concept of Operations (CONOPS) explaining how to securely integrate low assurance COTS components into DoD systems to minimize the amount of high assurance software that needs be developed. This activity is in its early phases, as of December 2006, the 180 implementation planning phase was closing out, and the pilot phase was under way. The Software Assurance CONOPS will begin research into Engineering in Depth (EiD), which minimizes the number of critical components in a system and manages the risk inherent in using less assured products. Critical components will be supplied by assured suppliers, who will provide DoD with sufficient documentation to document how much risk—such as foreign control of suppliers—is inherent in the supply chain. DoD will leverage this information when awarding contracts for critical high assurance components. [96]

To complement the CONOPS, the National Defense Industrial Association (NDIA), under sponsorship of the DoD Software Assurance Program, is

developing a System Assurance Guidebook that will provide guidance to NDIA

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

Section 5 SDLC Processes and Methods and the Security of Software

members and partners in government, industry, and academia. The guidance in the Systems Engineering Guidebook is intended to supplement:

u ISO/IEC 15288, System Life Cycle Processes

u DoD Acquisition Guidebook

u IEEE STD 1220, Application and Management of the Systems Engineering Process.

The Guidebook will describe the activities necessary to address concerns for maliciousness, reducing uncertainty and providing a basis for justified confidence in the resulting system. The Guidebook should be released in early fiscal year 2007 (FY07).

The SEI’s website and the DHS BuildSecurityIn portal provide a wealth of information discussing component assembly. [97] The Assembly, Integration, and Evolution section of the DHS BuildSecurityIn portal provides insight into the security issues associated with assembly of component-based software systems.

For Further Reading

Arlene F. Minkiewicz, “Security in a COTS-Based Software System”, CrossTalk, (November, 2005).

Available from: http://www.stsc.hill.af.mil/crosstalk/2005/11/0511Minkiewicz.html

Peter G. Neumann (SRI), Principled Assuredly Trustworthy Composable Architectures (December, 2004).

Available from: http://www.csl.sri.com/users/Neumann/chats4.html

Peter G. Neumann and Richard J. Feiertag, “PSOS Revisited”, in Proceedings of the Annual Computer Security Applications Conference (ACSAC 2003), (December, 2003),

Available from: http://www.csl.sri.com/users/neumann/psos03.pdf

“NRL CHACS” [website].

Available from: http://chacs.nrl.navy.mil

Robert J. Ellison (CMU SEI), Trustworthy Composition: The System is Not Always the Sum of Its Parts (September 2003).

Available from: https://buildsecurityin.us-cert.gov/daisy/bsi/50.html?branch=1&language=1

5.1.1.2.2 Research Into Engineering of Secure Component-Based Software

Significant research has been done since the late 1990s to address the problems associated with achieving security in component-based software systems. This research has focused on the following challenges:

u How to expose component security properties in a way that is usable by other components

u How to reconcile one component’s expectations of the security functions (and associated data outputs and formats) it needs from another component versus the security functionality (and associated data/formats) actually provided by the second component

u How to predict and measure the security properties and assurance levels of individual components and the impact on those properties and measurements

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

86 Context.

Section 5 SDLC Processes and Methods and the Security of Software

u How to predict and measure the security properties and assurance levels of a system assembled from components based on the security

properties, measurements, and assurance levels of the system’s individual components as they interact to achieve their required functionality

u How to engineer component-based systems in ways that minimize the exposure and impact of individual components’ vulnerabilities and intercomponent security mismatches.

Much of this research has used information security criteria as the basis for designating an individual component or component-based system secure. The assumption is that component-based systems are most likely to be information systems (most recently, web services). Therefore, the security properties that must be exhibited are information security properties: confidentiality, integrity, and availability of information, and accountability of users.

To the extent that requirements for integrity and availability extend to the software system that handles the information, they may be seen as software security properties. However the problems most often examined and the examples most often given in the research literature revolve around how to achieve, across a system composed of components with different security properties or assurance levels, the secure, cohesive implementation of functionality for user identification and authentication (I&A), trust establishment among components (based on authenticated identity and authorization attributes, as in the WS-Trust standard), and access control and confidential exchange of data. Unsurprisingly, Common Criteria (CC), Evaluation Assurance Levels (EAL), are often suggested as the basis for defining component-level and system-level assurance.

Although such research may yield useful concepts for addressing software security challenges in component-based systems, the specific techniques, technologies, and tools produced by the researchers may not be directly useful or easily adaptable. This said, the following papers provide a representative sampling of the research that has been done, and is being done, in this area—

u Scott Hissam and Daniel Plakosh, (CMU SEI) COTS in the Real World:

a Case Study in Risk Discovery and Repair, technical note number CMU/SEI-99-TN-003, (Pittsburgh PA): CMU SEI, (June, 1999).

Available from: http://www.sei.cmu.edu/publications/documents/99.reports/

99tn003 Intended Audience./99tn003 Intended Audience.abstract.html

u Ulf Lindqvist and Erland Jonsson (Chalmers University of Technology),

“A Map of Security Risks Associated with Using COTS”, IEEE Computer, 31(1998) 60–66.

Available from: http://www.windowsecurity.com/uplarticle/1/cots98.pdf

u Khaled M. Khan, (University of Western Sydney), Jun Han (Swinburne University of Technology), “Assessing Security Properties of Software Components: a Software Engineer’s Perspective”, in Proceedings of the

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

Section 5 SDLC Processes and Methods and the Security of Software

Australian Software Engineering Conference, Sydney, Australia, April 18–21 2006.

u Ibid; “Security Characterisation of Software Components and Their Composition”, in Proceedings of the 36th IEEE International Conference on Technology of Object-Oriented Languages and Systems, Xi’an, China, October 30–November 4 2000.

Available from: http://www.it.swin.edu.au/personal/jhan/jhanPub.html#security

u Manasi Kelkar, Rob Perry, Todd Gamble and Amit Walvekar

(University of Tulsa), “The Impact of Certification Criteria on Integrated COTS-based Systems,” in Proceedings of the Sixth International

Conference on COTS-Based Software Systems. Banff, Alberta, Canada, February 26–March 2 2007.

Available from: http://www.seat.utulsa.edu/papers/ICCBSS07-Kelkar.pdf

5.1.1.3 Security Issues Associated With Custom