Software Security Assurance
From Wikipedia, the free encyclopedia
Software is itself a resource and thus must be afforded appropriate security. Software also contains and controls data and other resources. Therefore, it must be designed and implemented to protect those resources. Software Security Assurance is a process that helps achieve that goal.
Contents
|
[ is Software Security Assurance?">edit] What is Software Security Assurance?
Software Security Assurance (SSA) is the process of ensuring that software is designed to operate at a level of security that is consistent with the potential harm that could result from the loss, inaccuracy, alteration, unavailability, or misuse of the data and resources that it uses, controls, and protects.
The Software Security Assurance process begins by identifying and categorizing the information that is to be contained in, or used by, the software. The information should be categorized according to its sensitivity. For example, in the lowest category, the impact of a security violation is minimal (i.e. the impact on the software owner's mission, functions, or reputation is negligible). For a top category, however, the impact may pose a threat to human life; may have an irreparable impact on software owner's missions, functions, image, or reputation; or may result in the loss of significant assets or resources.
Once the information is categorized, security requirements can be developed. The security requirements should address access control, including network access and physical access; data management and data access; environmental controls (power, air conditioning, etc.) and off-line storage; human resource security; and audit trails and usage records.
[edit] What Causes Software Security Problems?
Security problems related to software are usually caused by one of two reasons:
- Non-conformance, or a failure to satisfy requirements
- An error or omission in the software requirements
[ or Failure to Satisfy Requirements">edit] Non-conformance, or Failure to Satisfy Requirements
A non-conformance may be simple; the most common is a coding error or defect, or more complex (i.e., a subtle timing error or input validation error). The important point about non-conformances is that verification and validation techniques are designed to detect them and security assurance techniques are designed to prevent them. Improvements in these methods through a software security assurance program can improve the security of software.
[ or Omissions in Requirements">edit] Errors or Omissions in Requirements
The most serious security problems with software-based systems are those that develop when the software requirements are incorrect, inappropriate, or incomplete for the system situation. Unfortunately, errors or omissions in requirements are more difficult to identify. For example, the software may perform exactly as required, but the requirements do not correctly deal with some system state. When the system enters the undefined state, unexpected and undesirable behavior may result. This type of problem cannot be handled within the software discipline; it results from a failure of the system and software engineering processes which developed and allocated the system requirements to the software.
[edit] Software Security Assurance Activities
There are two basic types of Software Security Assurance activities.
1. Software Security Assurance activities that focus on ensuring information being (or to be) processed by an information system is assigned a proper sensitivity category and that the appropriate protection requirements have been developed and met in the system being developed or maintained.
2. Software Security Assurance activities that are focused on ensuring the control and protection of the software being developed and/or maintained, and of software support tools and data.
At a minimum, a Software Security Assurance program should ensure that:
- A security evaluation has been performed for the software.
- Security requirements have been established for the software.
- Security requirements have been established for the software development and/or operations and maintenance (O&M) process.
- Each software review, or audit, includes the evaluation of the security requirements.
- A configuration management and corrective action process is in place to provide security for the existing software and to ensure any proposed changes do not inadvertently create security violations or vulnerabilities.
- Physical security for the software is adequate.
[edit] Building Security In
Improving the software development process and building better software are ways to improve software security, i.e. by producing software with fewer defects and vulnerabilities. A first order approach is to identify the critical software components that control security-related functions and pay special attention to them throughout the development and testing process. This approach helps focus scarce security resources on the most critical areas.
[ and Techniques">edit] Tools and Techniques
There are many Commercial-Off-the-shelf (COTS) software packages that are available to support software security assurance activities. However, before they are used, these tools must be carefully evaluated and their effectiveness must be assured.
[edit] Common Weaknesses Enumeration
One way to improve software security is to gain a better understanding of the most common weaknesses that can affect software security. With that in mind, there is a current community-based program called the Common Weaknesses Enumeration project[1], which is sponsored by The Mitre Corporation to identify and describe such weaknesses. The list, which is currently in a very preliminary form, contains descriptions of software weaknesses, faults, and flaws.
[edit] Security Architecture/Design Analysis
Security Architecture/Design Analysis verifies that the software design correctly implements security requirements. Generally speaking, there are four basic techniques that are used for security architecture/design analysis.
[edit] 1. Logic Analysis
Logic analysis evaluates the equations, algorithms, and control logic of the software design.
[edit] 2. Data Analysis
Data analysis evaluates the description and intended usage of each data item used in design of the software component. The use of interrupts and their effect on data should receive special attention to ensure interrupt handling routines do not alter critical data used by other routines.
[edit] 3. Interface Analysis
Interface analysis verifies the proper design of a software component's interfaces with other components of the system, including hardware, software, and end-users.
[edit] 4. Constraint Analysis
Constraint analysis evaluates the design of a software component against restrictions imposed by requirements and real-world limitations. The design must be responsive to all known or anticipated restrictions on the software component. These restrictions may include timing, sizing, and throughput constraints, input and output data limitations, equation and algorithm limitations, and other design limitations.
[ and Walkthroughs">edit] Secure Code Reviews, Inspections, and Walkthroughs
Code analysis verifies that the software source code is written correctly, implements the desired design, and does not violate any security requirements. Generally speaking, the techniques used in the performance of code analysis mirror those used in design analysis.
Secure Code Reviews are conducted during and at the end of the development phase to determine whether established security requirements, security design concepts, and security-related specifications have been satisified. These reviews typically consist of the presentation of material to a review group. Secure Code Reviews are most effective when conducted by personnel who have not been directly involved in the development of the software being reviewed.
[edit] Informal Reviews
Informal secure code reviews can be conducted on an as-needed basis. To conduct an informal review The developer simply selects one or more reviewer(s) and provides and/or presents the material to be reviewed. The material may be as informal as pseudo-code or hand-written documentation.
[edit] Formal Reviews
Formal secure code reviews are conducted at the end of the development phase for each software component. The acquirer of the software appoints the formal review group, who may make or affect a "go/no-go" decision to proceed to the next step of the software development life cycle.
[ and Walkthroughs">edit] Inspections and Walkthroughs
A secure code inspection or walkthrough is a detailed examination of a product on a step-by-step or line-of-code by line-of-code basis. The purpose of conducting secure code inspections or walkthroughs is to find errors. Typically, the group that does an inspection or walkthrough is composed of peers from development, security engineering and quality assurance.
[edit] Security Testing
Software Security Testing, which includes Penetration Testing, confirms the results of design and code analysis, investigates software behavior, and verifies that the software complies with security requirements. Special security testing, conducted in accordance with a security test plan and procedures, establishes the compliance of the software with the security requirements. Security testing focuses on locating software weaknesses and identifying extreme or unexpected situations that could cause the software to fail in ways that would cause a violation of security requirements. Security testing efforts are often limited to the software requirements that are classified as "critical" security items.
