Efectos Jurídicos

Because uncontrolled software development activities make it easier for those with malicious intent to tamper with specifications or source code, potentially inserting malicious code into source code or binary executables, all software development artifacts should be kept under configuration management (CM) control. Under strict version control, it becomes difficult for developers, testers, or external attackers to tamper with the source code or executables. CM activities place additional control over a project, intentionally separating the role for managing configurable items from the developer or tester.

Security for software configuration management (SCM) practices and systems has been the subject of a number of papers and guidelines dating at least as far back as 1988, when the NSA’s National Computer Security Center (NCSC) published A Guide to Understanding Configuration Management in

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

Section 5 SDLC Processes and Methods and the Security of Software

Trusted Systems (NCSC-TG-006, also known as the “Amber Book”). [135] To date, many of the recommendations in that guide are still valid in general, although the specific technical approaches suggested may have become obsolete. Both the Amber Book and Section B.2 of NIST’s SP-800-64, Security Considerations in the Information System Development Life Cycle (2004) suggest that SCM requirements include those for methods that preserve the security of software. These methods include—

u Increasing developer accountability for software development artifacts by increasing the traceability of software development activities

u Ongoing impact analyses and control of changes to software development artifacts

u Minimization of undesirable changes that may affect the security of the software.

Since the Amber Book was published, advances in SCM technology and techniques have enabled configuration managers to improve upon the paper-trail-based SCM methods described in the Amber Book. Further improvements are still being researched, recommended, and implemented.

DHS’s Security in the Software Life Cycle includes a significant discussion of the current state-of-the-art in secure SCM practices, as well as summary of

“security enhancements” that can be added to current SCM practices, such as—

u Access control for development artifacts, including but not limited to threat models, and use/misuse/abuse cases; requirements, architecture, and design specifications; source code, binary executables; test

plans/scenarios/reports/oracles, code review findings, and vulnerability assessment results; installation/configuration guides, scripts, and tools;

administrator and end user documentation; Independent Verification and Validation (IV&V) documents (e.g., C&A documents, CC ST);

security patches and other fixes

u Time stamping and digital signature of all configuration items upon check-in to the SCM system

u Baselining of all configuration items before they are checked out for review or testing

u Storage of a digitally signed copy of the configuration item with its configuration item progress verification report

u Separation of roles/access privileges, and least privilege enforcement, for SCM system users

u Separation of roles and duties (developing, testing, etc.) within the software development team

u Authentication of developers and other users before granting access to the SCM system

u Audit of all SCM system access attempts, check-ins, check-outs, configuration changes, traceability between related components as they evolve, and details of other work done.

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

114 Scope.

Section 5 SDLC Processes and Methods and the Security of Software

Some other capabilities have been suggested in other sources as necessary for SCM to be truly secure. These include—

u Flexible but carefully controlled delegation [136] of SCM administrator privileges

u No remote access, or remote access only via encrypted, authenticated interfaces [137]

u Reporting of differences between security aspects of previous and subsequent versions and releases.

In Software Configuration Management Handbook, [138] Alexis Leon identifies security criteria that should be applied to the selection of development artifacts that should, at a minimum, be placed under configuration manager’s control as configuration items. These include—

u Items that are mission critical, security critical, safety critical, or high risk

u Items that, if they failed or malfunctioned, would adversely affect security, human safety, or mission accomplishment, or would have a significant financial impact

u Items for which an exact configuration and status of changes must be known at all times.

In practical terms, Leon is suggesting that, at a minimum, the development artifacts of high-consequence software should always be designated as configuration items.

5.1.6.1 Secure SCM Systems

The interest in secure SCM has led to the emergence of secure software version control systems and repositories, such as MKS’ (formerly Mortice Kern Systems) MKS Integrity [139] and the Oracle Developer Suite 10g Software Configuration Manager [140]. In addition, the Information Systems Security Operation research team at Sparta, Inc. is working to move secure SCM technology forward with its prototype Secure Protected Development Repository. [141]

As part of the Better SCM Initiative, Schlomi Fish, an Israeli open source programmer, compared the features, capabilities, and technical characteristics of 16 different open source SCM systems. [142] Two of the aspects he compared were directly relevant to the systems’ ability to support secure SCM:

1. Ability to assign access permissions to users and to restrict access to the repository based on those permission assignments

2. Ability to limit read and write accesses (check-ins and check-outs) to a single directory.

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

Section 5 SDLC Processes and Methods and the Security of Software

5.1.6.2 SCM and Nondevelopmental Components

CM of software systems that include acquired or reused components presents a complex challenge. The schedules and frequency of new releases, updates, and security (and nonsecurity) patches, and response times for technical support by acquired or reused software suppliers, are beyond the control of both developers and the configuration manager.

In the case of security patches, developers can never be sure when or even if the supplier of a particular software component will release a needed security patch for a reported vulnerability that might render a selected component otherwise unacceptable for use in the software system. Nor can the developer predict whether a particular security patch may invalidate the security assumptions that other components in the component-based system have about the component to be patched.

Given five COTS components, all on different release schedules, all with vulnerabilities reported and patches released at different times, the ability to

“freeze” the component-based software system at an acceptable baseline may confound even the most flexible development team. Developers may have to sacrifice the freedom to adopt every new version of every nondevelopmental component and may, in some cases, have to replace components for which security fixes are not forthcoming with more secure alternatives from other suppliers.

Security enhancements and patches announced by suppliers should be investigated and evaluated by developers as early in the software life cycle as possible to allow sufficient time for risk assessment and impact analysis. This is particularly important for new versions of or replacements for software components that perform security functions or other critical trusted function, because such new versions and replacements will also have implications for system recertification and reaccreditation.

If a particular nondevelopmental component is not kept up to date according to the supplier’s release schedule, the developer and configuration manager need to keep track of the minutiae of the supplier’s support agreement or contract to determine whether there is a point in time at which a non-updated/non-patched version of the software becomes “no longer supportable.” The risks associated with using unsupported software have to be weighed against the risks of adopting new versions or applying patches that have significant impacts on the system’s security assumptions (or of adopting an alternative product from a different supplier). A supplier’s willingness to support older versions for a fee may be worth negotiating during the product’s acquisition, as are custom modifications by the supplier to counteract security vulnerabilities that might not be deemed significant enough, by the supplier, to warrant issuing a standard patch.

Vulnerability reports issued by the United States Computer Emergency Readiness Team (US-CERT) and DoD’s Information Assurance Vulnerability Alert (IAVA) program and entries in the NIST National Vulnerability Database (NVD) and the Common Vulnerabilities and Exposures (CVE) represent reliable sources

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

116 Context.

Section 5 SDLC Processes and Methods and the Security of Software

of information about software product vulnerabilities. The software configuration manager should monitor those sources and download all necessary patches indicated by in the vulnerability reports, and then work with the developers to determine the impact of adopting those patches and the risk of not adopting them.

It is extremely critical for configuration managers to determine and understand how the security of the component-based system may be affected by new behaviors or interfaces introduced by patches applied to individual components. Suppliers often include other features that have no vulnerability-mitigating purpose in security patches, using the patch as a chance to introduce features that will later appear in their next full release of the software. Unfortunately, these features are seldom documented or even announced when delivered with the patch, making the need for impact analysis of such features impossible to recognize.

Secure SCM should track all fixes, patches, updates, and new releases by the suppliers of COTS and OSS components. It will be a challenge to both project and configuration managers to define a release schedule for systems that contain several such components so that as many of those components as possible can be brought “up to date” in terms of security (and other) patches prior to the system’s release, in hopes of reducing the amount of patching that will be needed soon after the system has been deployed.

The patch management solution typically used for post-deployment patching may not be flexible enough for patching during the development of component-based software. The patch management solution used during development needs to support the types of impact analyses that must be performed prior to assembly of patched components or integration of software products, including analysis of the patch’s impact on other components’

security assumptions.

If the system is shipped with custom-developed installation scripts, the developer needs to verify that these scripts do not overwrite security patches already installed on the target hosts. For example, when developing installation scripts for hosts running Microsoft operating systems, the developer can run Microsoft’s Baseline Security Analyzer to ensure that the script will not overwrite patches already applied in the intended target environment.

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

Section 5 SDLC Processes and Methods and the Security of Software

For Further Reading

Klaus Keus and Thomas Gast, “Configuration Management in Security related Software Engineering Processes”, in: Proceedings of the 1996 National Information Systems Security Conference, 1996.

Available from: http://csrc.nist.gov/nissc/1996/papers/NISSC96/paper035/scm_kk96.pdf

Premkumar T. Devanbu, M. Gertz, and Stuart Stubblebine, “Security for Automated, Distributed Configuration Management”, in: Proceedings of the Workshop on Software Engineering over the Internet at the 21st International Conference on Software Engineering, 1999.

Available from: http://www.stubblebine.com/99icse-workshop-stubblebine.pdf

Bob Aiello, “Behaviorally Speaking: Systems Security—CM is the Missing Link!!!” CM//Crossroads.

June 1, 2003.

David A. Wheeler, Software Configuration Management (SCM) Security, (May 6, 2005).

Mark Curphey and Rudolph Araujo, “Do Configuration Management During Design and Development”, in: Software Mag: The IT Software Journa, (October, 2005).

Available from: http://www.softwaremag.com/L.cfm?doc=2005-10/2005-10-config-man Tom Olzak, “Web Application Security: Application Denial of Service and Insecure Configuration Management”, podcast, August 2006.

Available from: http://adventuresinsecurity.com/Podcasts/AISSeries/ShowNotes/AdventuresinSecurity_

Episode_37.pdf