Добавил:
Я за два дня прошел весь курс ТВиМС Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:
!ОСНОВНАЯ КНИГА КУРСА! Chapple M. (ISC)2 CISSP Certified IS...Study Guide 9ed 2021.pdf
Скачиваний:
0
Добавлен:
20.06.2025
Размер:
15.75 Mб
Скачать

952Chapter 20  Software Development Security

Systems Development Lifecycle

Security is most effective if it is planned and managed throughout the lifecycle of a system or application. Administrators employ project management to keep a development project on target and moving toward the goal of a completed product. Often project management is structured using lifecycle models to direct the development process. Using formalized life-

cycle models helps ensure good coding practices and the embedding of security in every stage of product development.

All systems development processes should have several activities in common. Although they may not necessarily share the same names, these core activities are essential to the development of sound, secure systems:

■■

■■

■■

■■

■■

■■

■■

■■

Conceptual definition

Functional requirements determination Control specifications development Design review

Coding

Code review walk-­through System test review

Maintenance and change management

The section “Lifecycle Models,” later in this chapter, examines two lifecycle models and shows how these activities are applied in real-­world software engineering environments.

At this point, the terminology used in systems development lifecycles varies from model to model and from publication to publication. Don’t spend too much time worrying about the exact terms used in this book or any of the other literature you may come across. When you take the CISSP examination, it’s much more important that you have an understanding of how the process works and of the fundamental principles underlying the development of secure systems.

Conceptual Definition

The conceptual definition phase of systems development involves creating the basic concept statement for a system. It’s a simple statement agreed on by all interested stakeholders (the developers, customers, and management) that states the purpose of the project as well as the general system requirements. The conceptual definition is a very high-­level statement of purpose and should not be longer than one or two paragraphs. If you were reading a detailed summary of the project, you might expect to see the concept statement as an abstract or introduction that enables an outsider to gain a top-­level understanding of the project in a short period of time.

Introducing Systems Development Controls

953

The security requirements developed at this phase are generally very high level. They will be refined during the control specifications development phase. At this point in the process, designers commonly identify the classification(s) of data that will be processed by the system and the applicable handling requirements.

It’s helpful to refer to the concept statement at all phases of the systems development process. Often, the intricate details of the development process tend to obscure the overarching goal of the project. Simply reading the concept statement periodically can assist in refocusing a team of developers.

Functional Requirements Determination

Once all stakeholders have agreed on the concept statement, it’s time for the development team to sit down and begin the functional requirements process. In this phase, specific system functionalities are listed, and developers begin to think about how the parts of the system should interoperate to meet the functional requirements. The deliverable from this phase of development is a functional requirements document that lists the specific system requirements. These requirements should be expressed in a form consumable by software developers. The following are the three major characteristics of a functional requirement:

Input(s)  The data provided to a function

Behavior  The business logic describing what actions the system should take in response to different inputs

Output(s)  The data provided from a function

As with the concept statement, it’s important to ensure that all stakeholders agree on the functional requirements document before work progresses to the next level. When it’s finally completed, the document shouldn’t be simply placed on a shelf to gather dust—­the entire development team should constantly refer to this document during all phases to ensure that the project is on track. In the final stages of testing and evaluation, the project managers should use this document as a checklist to ensure that all functional requirements are met.

Control Specifications Development

Security-­conscious organizations also ensure that adequate security controls are designed into every system from the earliest stages of development. It’s often useful to have a control specifications development phase in your lifecycle model. This phase takes place soon after the development of functional requirements and often continues as the design and design review phases progress.

During the development of control specifications, you should analyze the system from a number of security perspectives. First, adequate access controls must be designed into every system to ensure that only authorized users are allowed to access the system and that they are not permitted to exceed their level of authorization. Second, the system must maintain the confidentiality of vital data through the use of appropriate encryption and data protection technologies. Next, the system should provide both an audit trail to enforce individual accountability and a detective mechanism for illegitimate activity. Finally, depending on the

954Chapter 20  Software Development Security

criticality of the system, availability and fault-­tolerance issues should be addressed as corrective actions.

Keep in mind that designing security into a system is not a onetime process and it must be done proactively. All too often, systems are designed without security planning, and then developers attempt to retrofit the system with appropriate security mechanisms. Unfortunately, these mechanisms are an afterthought and do not fully integrate with the system’s design, which leaves gaping security vulnerabilities. Also, the security requirements should be revisited each time a significant change is made to the design specifications. If a major component of the system changes, it’s likely that the security requirements will change as well.

Design Review

Once the functional and control specifications are complete, let the system designers do their thing! In this often-­lengthy process, the designers determine exactly how the various parts of the system will interoperate and how the modular system structure will be laid out. Also, during this phase the design management team commonly sets specific tasks for various teams and lays out initial timelines for the completion of coding milestones.

After the design team completes the formal design documents, a review meeting with the stakeholders should be held to ensure that everyone is in agreement that the process is still on track for the successful development of a system with the desired functionality. This design review meeting should include security professionals who can validate that the proposed design meets the control specifications developed in the previous phase.

Coding

Once the stakeholders have given the software design their blessing, it’s time for the software developers to start writing code. Developers should use the secure software coding principles discussed in this chapter to craft code that is consistent with the agreed-­upon design and meets user requirements.

Code Review Walk-Through

Project managers should schedule several code review walk-­through meetings at various milestones throughout the coding process. These technical meetings usually involve only development personnel, who sit down with a copy of the code for a specific module and walk through it, looking for problems in logical flow or other design/security flaws. The meetings play an instrumental role in ensuring that the code produced by the various development teams performs according to specification.

Testing

After many code reviews and a lot of long nights, there will come a point at which a developer puts in that final semicolon and declares the system complete. As any seasoned software engineer knows, the system is never complete. Initially, most organizations perform the initial system testing using development personnel to seek out any obvious errors. As the testing progresses, developers and actual users validate the system against predefined scenarios that

Introducing Systems Development Controls

955

model common and unusual user activities. In cases where the project is releasing updates to an existing system, regression testing formalizes the process of verifying that the new code performs in the same manner as the old code, other than any changes expected as part of the new release. These testing procedures should include both functional testing that verifies the software is working properly and security testing that verifies there are no unaddressed significant security issues.

Once developers are satisfied that the code works properly, the process moves into user acceptance testing (UAT), where users verify that the code meets their requirements and formally accept it as ready to move into production use.

Once this phase is complete, the code may move to deployment. As with any critical development process, it’s important that you maintain a copy of the written test plan and test results for future review.

Maintenance and Change Management

Once a system is operational, a variety of maintenance tasks are necessary to ensure continued operation in the face of changing operational, data processing, storage, and environmental requirements. It’s essential that you have a skilled support team in place to handle any routine or unexpected maintenance. It’s also important that any changes to the code

be handled through a formalized change management process, as described in Chapter 1, “Security Governance Through Principles and Policies.”

Lifecycle Models

One of the major complaints you’ll hear from practitioners of the more established engineering disciplines (such as civil, mechanical, and electrical engineering) is that software engineering is not an engineering discipline at all. In fact, they contend, it’s simply a combination of chaotic processes that somehow manage to scrape out workable solutions from time to time. Indeed, some of the “software engineering” that takes place in today’s development environments is nothing but bootstrap coding held together by “duct tape and chicken wire.”

However, the adoption of more formalized lifecycle management processes is seen in mainstream software engineering as the industry matures. After all, it’s hardly fair to compare the processes of a centuries-­old discipline such as civil engineering to those of an industry that’s still in its first century of existence. In the 1970s and 1980s, pioneers like Winston Royce and Barry Boehm proposed several software development lifecycle (SDLC) models to help guide the practice toward formalized processes. In 1991, the Software Engineering Institute introduced the Capability Maturity Model, which described the process that organizations undertake as they move toward incorporating solid engineering principles into their software development processes. In the following sections, we’ll take a look at the work produced by these studies. Having a management model in place should improve the resultant products. However, if the SDLC methodology is inadequate, the project may fail to meet business and user needs. Thus, it is important to verify that the SDLC model is properly implemented and is appropriate for your environment. Furthermore, one of the initial steps of implementing an SDLC should include management approval.

956Chapter 20  Software Development Security

Choosing an SDLC model is normally the work of software development teams and their leadership. Cybersecurity professionals should ensure that security principles are interwoven into the implementation of whatever model(s) the organization uses for software development.

Waterfall Model

Originally developed by Winston Royce in 1970, the waterfall model seeks to view the systems development lifecycle as a series of sequential activities. The traditional waterfall model has seven stages of development. As each stage is completed, the project moves into the next phase. The original, traditional waterfall model was a simple design that was intended to be sequential steps from inception to conclusion. In practical application, the waterfall model, of necessity, evolved to a more modern model. As illustrated by the backward arrows in Figure 20.3, the iterative waterfall model does allow development to return to the previous phase to correct defects discovered during the subsequent phase. This is often known as the feedback loop characteristic of the waterfall model.

FIGURE 20 . 3   The iterative lifecycle model with feedback loop

System

Requirements

Software

Requirements

Preliminary

Design

Detailed

Design

Code

and Debug

Testing

Operations

and

Maintenance

The waterfall model was one of the first comprehensive attempts to model the software development process while taking into account the necessity of returning to previous phases to correct system faults. However, one of the major criticisms of this model is that it allows

Introducing Systems Development Controls

957

the developers to step back only one phase in the process. It does not make provisions for the discovery of errors at a later phase in the development cycle.

The waterfall model was improved by adding validation and verification steps to each phase. Verification evaluates the product against specifications, whereas validation evaluates how well the product satisfies real-­world requirements. The improved model was labeled the modified waterfall model. However, it did not gain widespread use before the spiral model dominated the project management scene.

Spiral Model

In 1988, Barry Boehm of TRW proposed an alternative lifecycle model that allows for multiple iterations of a waterfall-­style process. Figure 20.4 illustrates this model. Because the spiral model encapsulates a number of iterations of another model (the waterfall model), it is known as a metamodel, or a “model of models.”

FIGURE 20 . 4   The spiral lifecycle mode

Determine objectives,

Evaluate alternatives.

alternatives, and constraints.

Identify and resolve risks.

P1 P2 P3

Plan next phases.

Develop and verify

 

next-level product.

Notice that each “loop” of the spiral results in the development of a new system prototype (represented by P1, P2, and P3 in Figure 20.4). Theoretically, system developers would apply the entire waterfall process to the development of each prototype, thereby incrementally working toward a mature system that incorporates all the functional requirements in a fully validated fashion. Boehm’s spiral model provides a solution to the major criticism of the waterfall model—­it allows developers to return to the planning stages as changing technical demands and customer requirements necessitate the evolution of a system. The

waterfall model focuses on a large-­scale effort to deliver a finished system, whereas the spiral

958Chapter 20  Software Development Security

model focuses on iterating through a series of increasingly “finished” prototypes that allow for enhanced quality control.

Agile Software Development

More recently, the Agile model of software development has gained popularity within the software engineering community. Beginning in the mid-­1990s, developers increasingly embraced approaches to software development that eschewed the rigid models of the past in favor of approaches that placed an emphasis on the needs of the customer and on quickly developing new functionality that meets those needs in an iterative fashion.

Seventeen pioneers of the Agile development approach got together in 2001 and produced a document titled Manifesto for Agile Software Development (agilemanifesto.org) that states the core philosophy of the Agile approach:

We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:

Individuals and interactions over processes and tools

Working software over comprehensive documentation

Customer collaboration over contract negotiation

Responding to change over following a plan

That is, while there is value in the items on the right, we value the items on the left more.

The Agile Manifesto also defines 12 principles that underlie the philosophy, which are available here: agilemanifesto.org/principles.html.

The 12 principles, as stated in the Agile Manifesto, are as follows:

■■Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.

■■Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.

■■Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.

■■Business people and developers must work together daily throughout the project.

■■Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.

■■The most efficient and effective method of conveying information to and within a development team is face-­to-­face conversation.

■■Working software is the primary measure of progress.

■■Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.

Introducing Systems Development Controls

959

■■Continuous attention to technical excellence and good design enhances agility.

■■Simplicity—­the art of maximizing the amount of work not done—­is essential.

■■The best architectures, requirements, and designs emerge from self-­ organizing teams.

■■At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

Today, most software developers embrace the flexibility and customer focus of the Agile approach to software development, and it is quickly becoming the philosophy of choice for developers. In an Agile approach, the team embraces the principles of the Agile Manifesto and meets regularly to review and plan their work.

It’s important to note, however, that Agile is a philosophy and not a specific methodology. Several specific methodologies have emerged that take these Agile principles and define specific processes that implement them. These include Scrum, Kanban, Rapid Application Development (RAD), Agile Unified Process (AUP), the Dynamic Systems Development Model (DSDM), and Extreme Programming (XP).

Of these, the Scrum approach is the most popular. Scrum takes its name from the daily team meetings, called scrums, that are its hallmark. Each day the team gets together for a short meeting, where they discuss the contributions made by each team member, plan the next day’s work, and work to clear any impediments to their progress. These meetings are led by the project’s scrum master, an individual in a project management role who is responsible for helping the team move forward and meet their objectives.

The Scrum methodology organizes work into short sprints of activity. These are well-­ defined periods of time, typically between one and four weeks, where the team focuses on achieving short-­term objectives that contribute to the broader goals of the project. At the beginning of each sprint, the team gathers to plan the work that will be conducted during each sprint. At the end of the sprint, the team should have a fully functioning product that could be released, even if it does not yet meet all user requirements. Each subsequent sprint introduces new functionality into the product.

Integrated ProductTeams

Although the Agile concept is a product of recent years, the idea of bringing together stakeholders for software and system development is a long-­standing concept.The Department of Defense introduced the idea of Integrated ProductTeams (IPT) in 1995 as an approach

to bring together multifunctional teams with a single goal of delivering a product or developing a process or policy. In the guidance creating IPTs, the Defense Department said that “IPTs are set up to foster parallel, rather than sequential, decisions and to guarantee that all aspects of the product, process, or policy are considered throughout the development process.”

960Chapter 20  Software Development Security

Capability Maturity Model (CMM)

The Software Engineering Institute (SEI) at Carnegie Mellon University introduced the Capability Maturity Model for Software, also known as the Software Capability Maturity Model (abbreviated as SW-­CMM, CMM, or SCMM), which contends that all organizations engaged in software development move through a variety of maturity phases in sequential fashion. The SW-­CMM describes the principles and practices underlying software process maturity. It is intended to help software organizations improve the maturity and quality

of their software processes by implementing an evolutionary path from ad hoc, chaotic processes to mature, disciplined software processes. The idea behind the SW-­CMM is that the quality of software depends on the quality of its development process. SW-­CMM does not explicitly address security, but it is the responsibility of cybersecurity professionals and software developers to ensure that security requirements are integrated into the software development effort.

The stages of the SW-­CMM are as follows:

Level 1: Initial  In this phase, you’ll often find hardworking people charging ahead in a disorganized fashion. There is usually little or no defined software development process.

Level 2: Repeatable  In this phase, basic lifecycle management processes are introduced. Reuse of code in an organized fashion begins to enter the picture, and repeatable results are expected from similar projects. SEI defines the key process areas for this level as Requirements Management, Software Project Planning, Software Project Tracking and Oversight, Software Subcontract Management, Software Quality Assurance, and Software Configuration Management.

Level 3: Defined  In this phase, software developers operate according to a set of formal, documented software development processes. All development projects take place within the constraints of the new standardized management model. SEI defines the key process areas for this level as Organization Process Focus, Organization Process Definition, Training Program, Integrated Software Management, Software Product Engineering, Intergroup Coordination, and Peer Reviews.

Level 4: Managed  In this phase, management of the software process proceeds to the next level. Quantitative measures are used to gain a detailed understanding of the

development process. SEI defines the key process areas for this level as Quantitative Process Management and Software Quality Management.

Level 5: Optimizing  In the optimized organization, a process of continuous improvement occurs. Sophisticated software development processes are in place that ensure that feedback from one phase reaches to the previous phase to improve future results. SEI defines the key process areas for this level as Defect Prevention, Technology Change Management, and Process Change Management.

Introducing Systems Development Controls

961

CMM has largely been superseded by a new model called the Capability Maturity Model Integration (CMMI).The CMMI uses the same five stages as the CMM but calls level 4 Quantitatively Managed, rather than Managed.The major difference between CMM and CMMI is that CMM focuses on isolated processes, whereas CMMI focuses on the integration among those processes.

Software Assurance Maturity Model (SAMM)

The Software Assurance Maturity Model (SAMM) is an open source project maintained by the Open Web Application Security Project (OWASP). It seeks to provide a framework for integrating security activities into the software development and maintenance process and to offer organizations the ability to assess their maturity.

SAMM divides the software development process into five business functions:

Governance  The activities an organization undertakes to manage its software development process. This function includes practices for strategy, metrics, policy, compliance, education, and guidance.

Design  The process used by the organization to define software requirements and create software. This function includes practices for threat modeling, threat assessment, security requirements, and security architecture.

Implementation  The process of building and deploying software components and managing flaws in those components. This function includes the secure build, secure deployment, and defect management practices.

Verification  The set of activities undertaken by the organization to confirm that code meets business and security requirements. This function includes architecture assessment, requirements-­driven testing, and security testing.

Operations  The actions taken by an organization to maintain security throughout the software lifecycle after code is released. This function includes incident management, environment management, and operational management.

Each of these business functions is then broken out by applicable security practices, as shown in Figure 20.5.

962

Chapter 20  Software Development Security

 

 

 

FIGURE 20 . 5   Software Assurance Maturity Model

 

 

 

 

SAMM

 

 

 

 

Software Assurance

 

 

 

SAMM v2

Overview

 

 

 

 

 

 

 

 

 

 

 

 

Lifecycle

 

 

 

 

 

 

 

 

 

 

 

 

 

Business

Governance

Design

 

 

Verification

Operations

Function

Implementation

Security

 

 

 

 

 

 

 

 

 

 

Practices

Strategy

Threat

Secure

Architecture

Incident

 

 

& Metrics

Assessment

Build

Analysis

Management

 

Create &

Measure &

App Risk

Threat

Build

Software

Architecture

Architecture

Incident

Incident

 

Promote

Improve

Profile

Model

Process

Dependencies

Validation

Compliance

Detection

Response

 

Policy &

Security

Secure

Requirements-driven

Environment

 

Compliance

Requirements

Deployment

Testing

Management

 

Policy &

Compliance

Software

Supplier

Deployment

Secret

Control

Misuse/Abuse

Configuration

Patch &

 

Standards

Management

Requirements

Security

Process

Management

Verification

Testing

Hardening

Update

 

Education &

Secure

Defect

Security

Operational

 

Guidance

Architecture

Management

Testing

Management

 

Training &

Organization

Architecture

Technology

Defect

Metrics &

Scalable

Deep

Data

Legacy

 

Awareness

& Culture

Design

Management

Tracking

Feedback

Baseline

Understanding

Protection

Management

 

Stream A

Stream B

Stream A

Stream B

Stream A

Stream B

Stream A

Stream B

Stream A

Stream B

IDEAL Model

The Software Engineering Institute also developed the IDEAL model for software development, which implements many of the SW-­CMM attributes. The IDEAL model has five phases:

1:Initiating In the initiating phase of the IDEAL model, the business reasons behind the change are outlined, support is built for the initiative, and the appropriate infrastructure is put in place.

2:Diagnosing During the diagnosing phase, engineers analyze the current state of the organization and make general recommendations for change.

3:Establishing In the establishing phase, the organization takes the general recommendations from the diagnosing phase and develops a specific plan of action that helps achieve those changes.

4:Acting In the acting phase, it’s time to stop “talking the talk” and “walk the walk.” The organization develops solutions and then tests, refines, and implements them.

5:Learning As with any quality improvement process, the organization must continuously analyze its efforts to determine whether it has achieved the desired goals, and when necessary, propose new actions to put the organization back on course.

The IDEAL model is illustrated in Figure 20.6.

 

 

 

Introducing Systems Development Controls

963

FIGURE 20 . 6  

The IDEAL model

 

 

 

 

 

 

Learning

 

 

 

 

 

Propose

Analyze

Acting

 

 

 

 

and

 

 

 

 

Future

 

 

 

 

Validate

Implement

 

 

 

 

Actions

 

 

 

 

 

 

 

 

 

 

 

Solution

 

Stimulus for Change

 

 

 

Refine

 

 

 

 

 

 

Solution

 

Set

Build

 

Charter

 

 

 

Context

Sponsorship

 

Infrastructure

 

 

 

 

 

 

 

 

Pilot Test

 

Initiating

Characterize

 

Solution

 

 

 

Current &

 

 

 

 

 

Desired States

 

 

 

 

 

 

 

 

Create

 

 

 

 

Develop

 

Solution

 

 

 

 

 

 

 

 

Diagnosing

Recommendations

 

 

 

 

 

 

Plan

 

 

 

 

 

 

 

 

 

 

Set

Develop

Actions

 

 

 

 

Priorities

 

 

 

 

 

Approach

 

 

 

 

 

 

 

 

Establishing

Special permission to reproduce “IDEAL Model,” ©2004 by Carnegie Mellon University, is granted by the Carnegie Mellon Software Engineering Institute.

SW-­CMM and IDEAL Model Memorization

To help you remember the initial letters of each of the 10 level names of the SW-­CMM and IDEAL models (II DR ED AM LO), imagine yourself sitting on the couch in a psychiatrist’s office saying, “I…I, Dr. Ed, am lo(w).” If you can remember that phrase, then you can extract the 10 initial letters of the level names. If you write the letters out into two columns, you can reconstruct the level names in order of the two systems.The left column is the IDEAL model, and the right represents the levels of the SW-­CMM.

Initiating

Initial

 

 

Diagnosing

Repeatable

 

 

Establishing

Defined

 

 

Acting

Managed

 

 

Learning

Optimizing

Соседние файлы в предмете Информационная безопасность автоматизированных систем