Your Article Review should include:
– Summary of the article's core contents, arguments, conclusions (3 pages)
– Critical assessment & comment based on your own research on the topic. For example, new
developments (technologies, theories) on the topic can be included in your critical review
Software Engineering Institute Carnegie Mellon University 4500 Fifth Avenue Pittsburgh, PA 15213-2612 Phone: 412-268-5800 Toll-free: 1-888-201-4479 www.sei.cmu.edu
Secure Software Development Life Cycle Processes
ABSTRACT: This article presents overview information about existing process- es, standards, life-cycle models, frameworks, and methodologies that support or could support secure software development. The initial report issued in 2006 has been updated to reflect changes.
INTENDED AUDIENCE1: The target audience for this document includes pro- gram and project managers, developers, and all individuals supporting improved security in developed software. It is also relevant to software engineering process group (SEPG) members who want to integrate security into their standard soft- ware development processes.
Scope Technology and content areas described include existing frameworks and stand- ards such as the Capability Maturity Model Integration2 (CMMI) framework, Team Software Process (TSP),3 the FAA-iCMM, the Trusted CMM/Trusted Software Methodology (T-CMM/TSM), and the Systems Security Engineering Capability Maturity Model (SSE-CMM). In addition, efforts specifically aimed at security in the SDLC are included, such as the Microsoft Trustworthy Compu- ting Software Development Lifecycle, the Team Software Process for Secure Software Development (TSPSM-Secure), Correctness by Construction, Agile Methods, and the Common Criteria. Two approaches, Software Assurance Ma- turity Model (SAMM) and Software Security Framework (SSF), which were just released, have been added to give the reader as much current information as pos- sible.
1 Some of the content of this article is used with permission from the Software Engineering Institute report CMU/SEI-2005-TN-024.
2 CMM, Capability Maturity Model, and CMMI are registered in the U.S. Patent and Trademark Of- fice by Carnegie Mellon University.
3 Team Software Process and TSP are service marks of Carnegie Mellon University.
Definitions These are some terms used in this document for which a common understanding would be useful.
Process – The IEEE defines a process as "a sequence of steps performed for a given purpose" [IEEE 90]. A secure software process can be defined as the set of activities performed to develop, maintain, and deliver a secure software solution. Activities may not necessarily be sequential; they could be concurrent or itera- tive.
Process model – A process model provides a reference set of best practices that can be used for both process improvement and process assessment. Process models do not define processes; rather, they define the characteristics of process- es. Process models usually have an architecture or a structure. Groups of best practices that lead to achieving common goals are grouped into process areas, and similar process areas may further be grouped into categories. Most process models also have a capability or maturity dimension, which can be used for as- sessment and evaluation purposes.
It is important to understand the processes that an organization is using to build secure software because unless the process is understood, its weaknesses and strengths are difficult to determine. It is also helpful to use common frameworks to guide process improvement, and to evaluate processes against a common model to determine areas for improvement. Process models promote common measures of organizational processes throughout the software development life cycle (SDLC). These models identify many technical and management practices. Although very few of these models were designed from the ground up to address security, there is substantial evidence that these models do address good software engineering practices to manage and build software [Goldenson 03, Herbsleb 94].
Even when organizations conform to a particular process model, there is no guarantee that the software they build is free of unintentional security vulnerabil- ities or intentional malicious code. However, there is probably a better likelihood of building secure software when an organization follows solid software engi- neering practices with an emphasis on good design, quality practices such as in- spections and reviews, use of thorough testing methods, appropriate use of tools, risk management, project management, and people management.
Standards – Standards are established by some authority, custom, or by general consent as examples of best practices. Standards provide material suitable for the definition of processes.
1 | SECURE SOFTW ARE DEVELOPMENT LIFE CYCLE PROCESSES
Assessments, evaluations, appraisals – All three of these terms imply compari- son of a process being practiced to a reference process model or standard. As- sessments, evaluations, and appraisals are used to understand process capability in order to improve processes. They help determine whether the processes being practiced are adequately specified, designed, integrated, and implemented to support the needs, including the security needs, of the software product. They are also an important mechanisms for selecting suppliers and then monitoring sup- plier performance.
Software assurance – SwA is defined as “the level of confidence that software is free from vulnerabilities, either intentionally designed into the software or ac- cidentally inserted at anytime during its life cycle, and that the software func- tions in the intended manner” [CNSS 06]. In the Capability Maturity Model for Software, the purpose of “software assurance” is described as providing appro- priate visibility into the process being used by the software projects and into the products being built [Paulk 93].
Security assurance – Although the term “security assurance” is often used, there does not seem to be an agreed upon definition for this term. The Systems and Security Engineering CMM describes “security assurance” as the process that establishes confidence that a product’s security needs are being met. In gen- eral, the term means the activities, methods, and procedures that provide confi- dence in the security-related properties and functions of a developed solution.
In the Security Assurance section of its Software Assurance Guidebook [NASA], NASA defines a minimum security assurance program as one that ensures the following:
• A security risk evaluation has been performed. • Security requirements have been established for the software and data being
developed and/or maintained. • Security requirements have been established for the development and/or
maintenance process. • Each software review and/or audit includes evaluation of security require-
ments. • The configuration management and corrective action processes provide se-
curity for the existing software and the change evaluation processes prevent security violations.
• Physical security for the software and the data is adequate.
Security assurance usually also includes activities for the requirements, design, implementation, testing, release, and maintenance phases of an SDLC.
2 | SECURE SOFTW ARE DEVELOPMENT LIFE CYCLE PROCESSES
BACKGROUND A survey of existing processes, process models, and standards identifies the fol- lowing four SDLC focus areas for secure software development.
1. Security Engineering Activities. Security engineering activities include activities needed to engineer a secure solution. Examples include security requirements elicitation and definition, secure design based on design prin- ciples for security, use of static analysis tools, secure reviews and inspec- tions, and secure testing. Engineering activities have been described in oth- er sections of the Build Security In web site.
2. Security Assurance Activities. Assurance activities include verification, validation, expert review, artifact review, and evaluations.
3. Security Organizational and Project Management Activities. Organiza- tional activities include organizational policies, senior management spon- sorship and oversight, establishing organizational roles, and other organiza- tional activities that support security. Project management activities include project planning and tracking resource allocation and usage to ensure that the security engineering, security assurance, and risk identification activi- ties are planned, managed, and tracked.
4. Security Risk Identification and Management Activities. There is broad consensus in the community that identifying and managing security risks is one of the most important activities in a secure SDLC and in fact is the driver for subsequent activities. Security risks in turn drive the other securi- ty engineering activities, the project management activities, and the security assurance activities. Risk is also covered in other areas of the Build Securi- ty In web site.
Other common themes include security metrics and overall defect reduction as attributes of a secure SDLC process. The remainder of this document provides overviews of process models, processes, and methods that support one or more of the four focus areas. The overviews should be read in the following context:
• Organizations need to define organizational processes. To do that, they use process standards, and they also consider industry customs, regulatory re- quirements, customer demands, and corporate culture.
• Individual projects apply the organizational processes, often with appropri- ate tailoring. In applying the organizational processes to a particular project, the project selects the appropriate SDLC activities.
• Projects use appropriate security risk identification, security engineering, and security assurance practices as they do their work.
• Organizations need to evaluate the effectiveness and maturity of their pro- cesses as used. They also need to perform security evaluations.
3 | SECURE SOFTW ARE DEVELOPMENT LIFE CYCLE PROCESSES
CAPABILITY MATURITY MODELS Capability Maturity Models provide a reference model of mature practices for a specified engineering discipline. An organization can compare its practices to the model to identify potential areas for improvement. The CMMs provide goal- level definitions for and key attributes of specific processes (software engineer- ing, systems engineering, security engineering), but do not generally provide operational guidance for performing the work. In other words, they don’t define processes, they define process characteristics; they define the what, but not the how. “CMM-based evaluations are not meant to replace product evaluation or system certification. Rather, organizational evaluations are meant to focus pro- cess improvement efforts on weaknesses identified in particular process areas” [Redwine 04].
Historically, CMMs have emphasized process maturity to meet business goals of better schedule management, better quality management, and reduction of the general defect rate in software. Of the four secure SDLC process focus areas mentioned earlier, CMMs generally address organizational and project manage- ment processes and assurance processes. They do not specifically address securi- ty engineering activities or security risk management. They also focus on overall defect reduction, not specifically on vulnerability reduction. This is important to note, since many defects are not security-related, and some security vulnerabili- ties are not caused by software defects. An example of a security vulnerability not caused by common software defects is intentionally-added malicious code.
Of the three CMMs currently in fairly widespread use, Capability Maturity Mod- el Integration (CMMI), the Federal Aviation Administration integrated Capabil- ity Maturity Model (FAA-iCMM), and the Systems Security Engineering Capa- bility Maturity Model (SSE-CMM), only the SSE-CMM was developed specifically to address security. The Trusted CMM, derived from the Trusted Software Methodology, is also of historical importance.
Capability Maturity Model Integration (CMMI) Capability Maturity Model Integration (CMMI) helps organizations increase the maturity of their processes to improve long-term business performance. Three different constellations of the CMMI exist: CMMI for Acquisition (CMMI- ACQ), CMMI for Services (CMMI-ACQ), and CMMI for Development (CMMI-DEV). As of December 2005, the Software Engineering Institute (SEI) reports that 1,106 organizations and 4,771 projects have reported results from CMMI-based appraisals. In November 2010, all three CMMI constellations were updated to version 1.3.
CMMI-ACQ provides improvement guidance to acquisition organizations for initiating and managing the acquisition of products and services. CMMI-SVC
4 | SECURE SOFTW ARE DEVELOPMENT LIFE CYCLE PROCESSES
provides improvement guidance to service provider organizations for establish- ing, managing, and delivering services.
CMMI-DEV provides the latest best practices for product and service develop- ment, maintenance, and acquisition, including mechanisms to help organizations improve their processes and provides criteria for evaluating process capability and process maturity. Improvement areas covered by this model include systems engineering, software engineering, integrated product and process development, supplier sourcing, and acquisition. CMMI-DEV has been in use for many years, replacing its predecessor, the Capability Maturity Model for Software or Soft- ware CMM (SW-CMM), which has been in use since the mid-1980s.
CMMI-DEV addresses four categories for process improvement and evaluation. Each category includes several Process Areas. As can be seen from Figure 1, CMMI-DEV addresses project management, supplier management, organization- level process improvement and training, quality assurance, measurement, and engineering practices. However, it does not specifically address the four areas mentioned earlier (security risk management, security engineering practices, se- curity assurance, and project/organizational processes for security). Although it is not unreasonable to assume that all of these could be addressed as special cas- es of practices already addressed by CMMI-DEV, additional goals and practices to make assurance explicit are under development through a partnership of Booz Allen Hamilton, Motorola, and Lockheed Martin. Progress of this effort can be found on the Processes and Practices Working Group page on the Software As- surance Community Resources and Information Clearinghouse site. Further in- formation on CMMI is available on the SEI website.
5 | SECURE SOFTW ARE DEVELOPMENT LIFE CYCLE PROCESSES
Figure 1. CMMI-DEV Process Areas
The FAA-iCMM is widely used in the Federal Aviation Administration. The FAA-iCMM provides a single model of best practices for enterprise-wide im- provement, including outsourcing and supplier management. The latest version includes process areas to address integrated enterprise management, information management, deployment/transition/disposal, and operation/support. The FAA- iCMM integrates the following standards and models: ISO 9001:2000, EIA/IS 731, Malcolm Baldrige National Quality Award and President's Quality Award
6 | SECURE SOFTW ARE DEVELOPMENT LIFE CYCLE PROCESSES
criteria, CMMI-SE/SW/IPPD and CMMI-A, ISO/IEC TR 15504, ISO/IEC 12207, and ISO/IEC CD 15288.
The FAA-iCMM has been organized into the three categories and 23 Process Areas shown in Figure 2. The FAA-iCMM addresses project management, risk management, supplier management, information management, configuration management, design, and testing, all of which are integral to a secure SDLC. However, the FAA-iCMM does not address security specifically in any of these areas. Just as with CMMI, the FAA-iCMM includes generic set of best practices that do not specifically address security concerns. A reference document (PDF) with pointers to the details about the model and each process area is available.
7 | SECURE SOFTW ARE DEVELOPMENT LIFE CYCLE PROCESSES
Figure 2. FAA-iCMM Process Areas
To address gaps in the coverage of safety and security, some organizations with- in the FAA and the Department of Defense (DoD) sponsored a joint effort to identify best safety and security practices for use in combination with the FAA- iCMM. The proposed Safety and Security extension to the FAA-iCMM identi- fies standards-based practices expected to be used as criteria in guiding process improvement and in appraising an organization’s capabilities for providing safe and secure products and services.
8 | SECURE SOFTW ARE DEVELOPMENT LIFE CYCLE PROCESSES
The proposed Safety and Security additions include the following four goals and sixteen practices:
Goal 1 – An infrastructure for safety and security is established and maintained. 1. Ensure safety and security awareness, guidance, and competency. 2. Establish and maintain a qualified work environment that meets safety and
security needs. 3. Ensure integrity of information by providing for its storage and protection
and controlling access and distribution of information. 4. Monitor, report, and analyze safety and security incidents and identify po-
tential corrective actions. 5. Plan and provide for continuity of activities with contingencies for threats
and hazards to operations and the infrastructure.
Goal 2 – Safety and security risks are identified and managed. 1. Identify risks and sources of risks attributable to vulnerabilities, security
threats, and safety hazards. 2. For each risk associated with safety or security, determine the causal fac-
tors, estimate the consequence and likelihood of an occurrence, and deter- mine relative priority.
3. For each risk associated with safety or security, determine, implement, and monitor the risk mitigation plan to achieve an acceptable level of risk.
Goal 3 – Safety and security requirements are satisfied. 1. Identify and document applicable regulatory requirements, laws, standards,
policies, and acceptable levels of safety and security. 2. Establish and maintain safety and security requirements, including integrity
levels, and design the product or service to meet them. 3. Objectively verify and validate work products and delivered products and
services to assure safety and security requirements have been achieved and fulfill intended use.
4. Establish and maintain safety and security assurance arguments and sup- porting evidence throughout the life cycle.
Goal 4 – Activities and products are managed to achieve safety and security requirements and objectives. 1. Establish and maintain independent reporting of safety and security status
9 | SECURE SOFTW ARE DEVELOPMENT LIFE CYCLE PROCESSES
2. Establish and maintain a plan to achieve safety and security requirements and objectives.
3. Select and manage products and suppliers using safety and security criteria. 4. Measure, monitor, and review safety and security activities against plans,
control products, take corrective action, and improve processes.
Further information about safety and security extensions developed for this mod- el is available in [Ibrahim 04].
Trusted CMM/Trusted Software Methodology (T-CMM, TSM) In the early 1990s, the then-Strategic Defense Initiative (SDI) developed a pro- cess called the “Trusted Software Development Methodology,” later renamed to the “Trusted Software Methodology (TSM).” This model defined levels of trust, with lower trust levels emphasizing resistance to unintentional vulnerabilities and higher trust levels adding processes to counter malicious developers. SDI ran experiments with the TSM to determine whether such processes could be im- plemented practically and what the impact of those processes would be (especial- ly on cost and schedule). The TSM was later harmonized with the CMM, pro- ducing the Trusted CMM (T-CMM) [Kitson 95]. While the TCMM/TSM is not widely used today, it nevertheless remains a source of information on processes for developing secure software.
Systems Security Engineering Capability Maturity Model (SSE-CMM) The SSE-CMM® is a process model that can be used to improve and assess the security engineering capability of an organization. The SSE-CMM provides a comprehensive framework for evaluating security engineering practices against the generally accepted security engineering principles. By defining such a framework, the SSE-CMM, provides a way to measure and improve perfor- mance in the application of security engineering principles. The SSE-CMM is now ISO/IEC 21827 standard and version 3 is now available. Further infor- mation about the model is available at http://www.sse-cmm.org [Redwine 04].
The stated purpose for developing the model is that, although the field of securi- ty engineering has several generally accepted principles, it lacks a comprehen- sive framework for evaluating security engineering practices against the princi- ples. The SSE-CMM, by defining such a framework, provides a way to measure and improve performance in the application of security engineering principles. The SSE-CMM also describes the essential characteristics of an organization’s security engineering processes.
The model is organized into two broad areas: (1) Security Engineering and (2) Project and Organizational processes. Security Engineering in turn is organized
10 | SECURE SOFTW ARE DEVELOPMENT LIFE CYCLE PROCESSES
into Engineering Processes, Assurance Processes, and Risk Processes. There are 22 Process Areas distributed amongst the three organizations. Each Process Area is composed of a related set of process goals and activities.
SEE-CMM was last revised in 2005. The model became an ISO standard in 2008. The International Systems Security Engineering Association (ISSEA) maintains the SSE-CMM.
Figure 3. Process Areas of the SSE-CMM
11 | SECURE SOFTW ARE DEVELOPMENT LIFE CYCLE PROCESSES
Microsoft’s Trustworthy Computing Security Development Lifecycle The Trustworthy Computing Security Development Lifecycle (or SDL) is a pro- cess that Microsoft has adopted for the development of software that needs to withstand security attacks [Lipner 05]. The process adds a series of security- focused activities and deliverables to each phase of Microsoft's software devel- opment process. These security activities and deliverables include definition of security feature requirements and assurance activities during the requirements phase, threat modeling for security risk identification during the software design phase, the use of static analysis code-scanning tools and code reviews during implementation, and security focused testing, including Fuzz testing, during the testing phase. An extra security push includes a final code review of new as well as legacy code during the verification phase. Finally, during the release phase, a final security review is conducted by the Central Microsoft Security team, a team of security experts who are also available to the product development team throughout the development life cycle, and who have a defined role in the overall process.
Microsoft has augmented the SDL with mandatory security training for its soft- ware development personnel, with security metrics, and with available security expertise via the Central Microsoft Security team. Microsoft is reporting encour- aging results from products developed using the SDL, as measured by the num- ber of critical and important security bulletins issued by Microsoft for a product after its release.
The book titled The Security Development Lifecycle [Howard 06] further ex- pands information about SDL from the article referenced above. Emphasis is given to the approach an organization must use for effective adoption of SDL. Management commitment to improved product security is essential. In addition to training developers and designing and building the product with appropriate security, the SDL incorporates planning for security failures after release so the organization is ready to swiftly correct unforeseen problems. The SDL is articu- lated as a 12 stage process as follows:
Stage 0: Education and Awareness Stage 1: Project Inception Stage 2: Define and Follow Design Best Practices Stage 3: Product Risk Assessment Stage 4: Risk Analysis Stage 5: Creating Security Documents, Tools, and Best Practices for Cus- tomers Stage 6: Secure Coding Policies
12 | SECURE SOFTW ARE DEVELOPMENT LIFE CYCLE PROCESSES
Stage 7: Secure Testing Policies Stage 8: The Security Push Stage 9: The Final Security Review Stage 10: Security Response Planning Stage 11: Product Release Stage 12: Security Response Execution
Team Software Process for Secure Software Development (TSP) The Software Engineering Institute’s (SEI) Team Software Process (TSP) pro- vides a framework, a set of processes, and disciplined methods for applying software engineering principles at the team and individual level. Software pro- duced with the TSP has one or two orders of magnitude fewer defects than soft- ware produced with current practices—that is, 0 to .1 defects per thousand lines of code, as opposed to 1 to 2 defects per thousand lines of code.
TSP for Secure Software Development (TSP-Secure) extends the TSP to focus more directly on the security of software applications. The TSP-Secure project is a joint effort of the SEI’s TSP initiative and the SEI’s CERT program. The prin- cipal goal of the project is to develop a TSP-based method that can predictably produce secure software. TSP-Secure addresses secure software development in three ways. First, since secure software is not built by accident, TSP-Secure ad- dresses planning for security. Also, since schedule pressures and people issues get in the way of implementing best practices, TSP-Secure helps to build self- directed development teams and then put these teams in charge of their own work. Second, since security and quality are closely related, TSP-Secure helps manage quality throughout the product development life cycle. Finally, since people building secure software must have an awareness of software security issues, TSP-Secure includes security awareness training for developers.
Teams using TSP-Secure build their own plans. Initial planning is conducted in a series of meetings called a project launch, which takes place over a three- to four-day period. The launch is led by a qualified team coach. In a TSP-Secure launch, the team reaches a common understanding of the security goals for the work and the approach they will take to do the work, produces a detailed plan to guide the work, and obtains management support for the plan. Typical tasks in- cluded in the plan are identifying security risks, eliciting and defining security requirement, secure design, secure design and code reviews, and use of static analysis tools, unit tests, and fuzz testing. (Fuzz testing involves sending random inputs to external program interfaces during black-box testing. The term origi-
13 | SECURE SOFTW ARE DEVELOPMENT LIFE CYCLE PROCESSES
nates from the fuzz testing application that was developed and is maintained by the University of Wisconsin [Fuzz 06, Michael 05]).
Each team member of a TSP-Secure team selects at least one of nine standard team member roles (roles can be shared). One of the defined roles is a Security Manager role. The Security Manager leads the team in ensuring that product re- quirements, design, implementation, reviews, and testing address security; ensur- ing that the product is statically and dynamically assured; providing timely anal- ysis and warning on security problems; and tracking any security risks or issues to closure. The security manager works with external security experts when needed.
After the launch, the team executes its plan and ensures that all security-related activities are taking place. Security status is presented and discussed during eve- ry management status briefing.
Visits to web sites such as the SANS Institute’s Top 20 list of security vulnera- bilities, the MITRE Common Vulnerabilities and Exposures (CVE) site, the US- CERT Technical Cyber Security Alerts site, and the Microsoft Security Advisory site show that common software defects are the leading cause of security vulner- abilities (buffer overflows have been the most common software defect leading to security vulnerabilities) [Microsoft 06, MITRE 06, SANS 05, US-CERT 05]. Therefore, The TSP-Secure quality management strategy is to have multiple de- fect removal points in the software development life cycle. The more defect re- moval points there are, the more likely one is to find problems right after they are introduced, enabling problems to be more easily fixed and the root cause to be more easily determined and addressed.
Each defect removal activity can be thought of as a filter that removes some per- centage of defects that can lead to vulnerabilities from the software product (see Figure 4). The more defect removal filters there are in the software development life cycle, the fewer defects that can lead to vulnerabilities will remain in the software product when it is …
We are a professional custom writing website. If you have searched a question and bumped into our website just know you are in the right place to get help in your coursework.
Yes. We have posted over our previous orders to display our experience. Since we have done this question before, we can also do it for you. To make sure we do it perfectly, please fill our Order Form. Filling the order form correctly will assist our team in referencing, specifications and future communication.
2. Fill in your paper’s requirements in the "PAPER INFORMATION" section and click “PRICE CALCULATION” at the bottom to calculate your order price.
3. Fill in your paper’s academic level, deadline and the required number of pages from the drop-down menus.
4. Click “FINAL STEP” to enter your registration details and get an account with us for record keeping and then, click on “PROCEED TO CHECKOUT” at the bottom of the page.
5. From there, the payment sections will show, follow the guided payment process and your order will be available for our writing team to work on it.
Need this assignment?
Order here and claim 25% off
Discount code SAVE25