
- •Acknowledgments
- •About the Authors
- •About the Technical Editors
- •Contents at a Glance
- •Contents
- •Foreword
- •Introduction
- •Overview of the CISSP Exam
- •The Elements of This Study Guide
- •Study Guide Exam Objectives
- •Objective Map
- •Reader Support for This Book
- •Security 101
- •Confidentiality
- •Integrity
- •Availability
- •Protection Mechanisms
- •Security Boundaries
- •Third-Party Governance
- •Documentation Review
- •Manage the Security Function
- •Alignment of Security Function to Business Strategy, Goals, Mission, and Objectives
- •Organizational Processes
- •Organizational Roles and Responsibilities
- •Security Control Frameworks
- •Due Diligence and Due Care
- •Security Policy, Standards, Procedures, and Guidelines
- •Security Policies
- •Security Standards, Baselines, and Guidelines
- •Security Procedures
- •Threat Modeling
- •Identifying Threats
- •Determining and Diagramming Potential Attacks
- •Performing Reduction Analysis
- •Prioritization and Response
- •Supply Chain Risk Management
- •Summary
- •Exam Essentials
- •Written Lab
- •Review Questions
- •Job Descriptions and Responsibilities
- •Candidate Screening and Hiring
- •Onboarding: Employment Agreements and Policies
- •Employee Oversight
- •Compliance Policy Requirements
- •Privacy Policy Requirements
- •Understand and Apply Risk Management Concepts
- •Risk Terminology and Concepts
- •Asset Valuation
- •Identify Threats and Vulnerabilities
- •Risk Assessment/Analysis
- •Risk Responses
- •Cost vs. Benefit of Security Controls
- •Countermeasure Selection and Implementation
- •Applicable Types of Controls
- •Security Control Assessment
- •Monitoring and Measurement
- •Risk Reporting and Documentation
- •Continuous Improvement
- •Risk Frameworks
- •Social Engineering
- •Social Engineering Principles
- •Eliciting Information
- •Prepending
- •Phishing
- •Spear Phishing
- •Whaling
- •Smishing
- •Vishing
- •Spam
- •Shoulder Surfing
- •Invoice Scams
- •Hoax
- •Impersonation and Masquerading
- •Tailgating and Piggybacking
- •Dumpster Diving
- •Identity Fraud
- •Typo Squatting
- •Influence Campaigns
- •Awareness
- •Training
- •Education
- •Improvements
- •Effectiveness Evaluation
- •Summary
- •Exam Essentials
- •Written Lab
- •Review Questions
- •Planning for Business Continuity
- •Project Scope and Planning
- •Organizational Review
- •BCP Team Selection
- •Resource Requirements
- •Legal and Regulatory Requirements
- •Business Impact Analysis
- •Identifying Priorities
- •Risk Identification
- •Likelihood Assessment
- •Impact Analysis
- •Resource Prioritization
- •Continuity Planning
- •Strategy Development
- •Provisions and Processes
- •Plan Approval and Implementation
- •Plan Approval
- •Plan Implementation
- •Training and Education
- •BCP Documentation
- •Summary
- •Exam Essentials
- •Written Lab
- •Review Questions
- •Categories of Laws
- •Criminal Law
- •Civil Law
- •Administrative Law
- •Laws
- •Computer Crime
- •Intellectual Property (IP)
- •Licensing
- •Import/Export
- •Privacy
- •State Privacy Laws
- •Compliance
- •Contracting and Procurement
- •Summary
- •Exam Essentials
- •Written Lab
- •Review Questions
- •Defining Sensitive Data
- •Defining Data Classifications
- •Defining Asset Classifications
- •Understanding Data States
- •Determining Compliance Requirements
- •Determining Data Security Controls
- •Data Maintenance
- •Data Loss Prevention
- •Marking Sensitive Data and Assets
- •Handling Sensitive Information and Assets
- •Data Collection Limitation
- •Data Location
- •Storing Sensitive Data
- •Data Destruction
- •Ensuring Appropriate Data and Asset Retention
- •Data Protection Methods
- •Digital Rights Management
- •Cloud Access Security Broker
- •Pseudonymization
- •Tokenization
- •Anonymization
- •Understanding Data Roles
- •Data Owners
- •Asset Owners
- •Business/Mission Owners
- •Data Processors and Data Controllers
- •Data Custodians
- •Administrators
- •Users and Subjects
- •Using Security Baselines
- •Comparing Tailoring and Scoping
- •Standards Selection
- •Summary
- •Exam Essentials
- •Written Lab
- •Review Questions
- •Cryptographic Foundations
- •Goals of Cryptography
- •Cryptography Concepts
- •Cryptographic Mathematics
- •Ciphers
- •Modern Cryptography
- •Cryptographic Keys
- •Symmetric Key Algorithms
- •Asymmetric Key Algorithms
- •Hashing Algorithms
- •Symmetric Cryptography
- •Cryptographic Modes of Operation
- •Data Encryption Standard
- •Triple DES
- •International Data Encryption Algorithm
- •Blowfish
- •Skipjack
- •Rivest Ciphers
- •Advanced Encryption Standard
- •CAST
- •Comparison of Symmetric Encryption Algorithms
- •Symmetric Key Management
- •Cryptographic Lifecycle
- •Summary
- •Exam Essentials
- •Written Lab
- •Review Questions
- •Asymmetric Cryptography
- •Public and Private Keys
- •ElGamal
- •Elliptic Curve
- •Diffie–Hellman Key Exchange
- •Quantum Cryptography
- •Hash Functions
- •RIPEMD
- •Comparison of Hash Algorithm Value Lengths
- •Digital Signatures
- •HMAC
- •Digital Signature Standard
- •Public Key Infrastructure
- •Certificates
- •Certificate Authorities
- •Certificate Lifecycle
- •Certificate Formats
- •Asymmetric Key Management
- •Hybrid Cryptography
- •Applied Cryptography
- •Portable Devices
- •Web Applications
- •Steganography and Watermarking
- •Networking
- •Emerging Applications
- •Cryptographic Attacks
- •Salting Saves Passwords
- •Ultra vs. Enigma
- •Summary
- •Exam Essentials
- •Written Lab
- •Review Questions
- •Secure Design Principles
- •Objects and Subjects
- •Closed and Open Systems
- •Secure Defaults
- •Fail Securely
- •Keep It Simple
- •Zero Trust
- •Privacy by Design
- •Trust but Verify
- •Techniques for Ensuring CIA
- •Confinement
- •Bounds
- •Isolation
- •Access Controls
- •Trust and Assurance
- •Trusted Computing Base
- •State Machine Model
- •Information Flow Model
- •Noninterference Model
- •Take-Grant Model
- •Access Control Matrix
- •Bell–LaPadula Model
- •Biba Model
- •Clark–Wilson Model
- •Brewer and Nash Model
- •Goguen–Meseguer Model
- •Sutherland Model
- •Graham–Denning Model
- •Harrison–Ruzzo–Ullman Model
- •Select Controls Based on Systems Security Requirements
- •Common Criteria
- •Authorization to Operate
- •Understand Security Capabilities of Information Systems
- •Memory Protection
- •Virtualization
- •Trusted Platform Module
- •Interfaces
- •Fault Tolerance
- •Encryption/Decryption
- •Summary
- •Exam Essentials
- •Written Lab
- •Review Questions
- •Shared Responsibility
- •Hardware
- •Firmware
- •Client-Based Systems
- •Mobile Code
- •Local Caches
- •Server-Based Systems
- •Large-Scale Parallel Data Systems
- •Grid Computing
- •Peer to Peer
- •Industrial Control Systems
- •Distributed Systems
- •Internet of Things
- •Edge and Fog Computing
- •Static Systems
- •Network-Enabled Devices
- •Cyber-Physical Systems
- •Elements Related to Embedded and Static Systems
- •Security Concerns of Embedded and Static Systems
- •Specialized Devices
- •Microservices
- •Infrastructure as Code
- •Virtualized Systems
- •Virtual Software
- •Virtualized Networking
- •Software-Defined Everything
- •Virtualization Security Management
- •Containerization
- •Serverless Architecture
- •Mobile Devices
- •Mobile Device Security Features
- •Mobile Device Deployment Policies
- •Process Isolation
- •Hardware Segmentation
- •System Security Policy
- •Covert Channels
- •Attacks Based on Design or Coding Flaws
- •Rootkits
- •Incremental Attacks
- •Summary
- •Exam Essentials
- •Written Lab
- •Review Questions
- •Apply Security Principles to Site and Facility Design
- •Secure Facility Plan
- •Site Selection
- •Facility Design
- •Equipment Failure
- •Wiring Closets
- •Server Rooms/Data Centers
- •Intrusion Detection Systems
- •Cameras
- •Access Abuses
- •Media Storage Facilities
- •Evidence Storage
- •Restricted and Work Area Security
- •Utility Considerations
- •Fire Prevention, Detection, and Suppression
- •Perimeter Security Controls
- •Internal Security Controls
- •Key Performance Indicators of Physical Security
- •Summary
- •Exam Essentials
- •Written Lab
- •Review Questions
- •OSI Model
- •History of the OSI Model
- •OSI Functionality
- •Encapsulation/Deencapsulation
- •OSI Layers
- •TCP/IP Model
- •Common Application Layer Protocols
- •SNMPv3
- •Transport Layer Protocols
- •Domain Name System
- •DNS Poisoning
- •Domain Hijacking
- •Internet Protocol (IP) Networking
- •IP Classes
- •ICMP
- •IGMP
- •ARP Concerns
- •Secure Communication Protocols
- •Implications of Multilayer Protocols
- •Converged Protocols
- •Voice over Internet Protocol (VoIP)
- •Software-Defined Networking
- •Microsegmentation
- •Wireless Networks
- •Securing the SSID
- •Wireless Channels
- •Conducting a Site Survey
- •Wireless Security
- •Wi-Fi Protected Setup (WPS)
- •Wireless MAC Filter
- •Wireless Antenna Management
- •Using Captive Portals
- •General Wi-Fi Security Procedure
- •Wireless Communications
- •Wireless Attacks
- •Other Communication Protocols
- •Cellular Networks
- •Content Distribution Networks (CDNs)
- •Secure Network Components
- •Secure Operation of Hardware
- •Common Network Equipment
- •Network Access Control
- •Firewalls
- •Endpoint Security
- •Transmission Media
- •Network Topologies
- •Ethernet
- •Sub-Technologies
- •Summary
- •Exam Essentials
- •Written Lab
- •Review Questions
- •Protocol Security Mechanisms
- •Authentication Protocols
- •Port Security
- •Quality of Service (QoS)
- •Secure Voice Communications
- •Voice over Internet Protocol (VoIP)
- •Vishing and Phreaking
- •PBX Fraud and Abuse
- •Remote Access Security Management
- •Remote Connection Security
- •Plan a Remote Access Security Policy
- •Multimedia Collaboration
- •Remote Meeting
- •Instant Messaging and Chat
- •Load Balancing
- •Virtual IPs and Load Persistence
- •Active-Active vs. Active-Passive
- •Manage Email Security
- •Email Security Goals
- •Understand Email Security Issues
- •Email Security Solutions
- •Virtual Private Network
- •Tunneling
- •How VPNs Work
- •Always-On
- •Common VPN Protocols
- •Switching and Virtual LANs
- •Switch Eavesdropping
- •Private IP Addresses
- •Stateful NAT
- •Automatic Private IP Addressing
- •Third-Party Connectivity
- •Circuit Switching
- •Packet Switching
- •Virtual Circuits
- •Fiber-Optic Links
- •Security Control Characteristics
- •Transparency
- •Transmission Management Mechanisms
- •Prevent or Mitigate Network Attacks
- •Eavesdropping
- •Modification Attacks
- •Summary
- •Exam Essentials
- •Written Lab
- •Review Questions
- •Controlling Access to Assets
- •Controlling Physical and Logical Access
- •The CIA Triad and Access Controls
- •Managing Identification and Authentication
- •Comparing Subjects and Objects
- •Registration, Proofing, and Establishment of Identity
- •Authorization and Accountability
- •Authentication Factors Overview
- •Something You Know
- •Something You Have
- •Something You Are
- •Multifactor Authentication (MFA)
- •Two-Factor Authentication with Authenticator Apps
- •Passwordless Authentication
- •Device Authentication
- •Service Authentication
- •Mutual Authentication
- •Implementing Identity Management
- •Single Sign-On
- •SSO and Federated Identities
- •Credential Management Systems
- •Credential Manager Apps
- •Scripted Access
- •Session Management
- •Provisioning and Onboarding
- •Deprovisioning and Offboarding
- •Defining New Roles
- •Account Maintenance
- •Account Access Review
- •Summary
- •Exam Essentials
- •Written Lab
- •Review Questions
- •Comparing Access Control Models
- •Comparing Permissions, Rights, and Privileges
- •Understanding Authorization Mechanisms
- •Defining Requirements with a Security Policy
- •Introducing Access Control Models
- •Discretionary Access Control
- •Nondiscretionary Access Control
- •Implementing Authentication Systems
- •Implementing SSO on the Internet
- •Implementing SSO on Internal Networks
- •Understanding Access Control Attacks
- •Crackers, Hackers, and Attackers
- •Risk Elements
- •Common Access Control Attacks
- •Core Protection Methods
- •Summary
- •Exam Essentials
- •Written Lab
- •Review Questions
- •Security Testing
- •Security Assessments
- •Security Audits
- •Performing Vulnerability Assessments
- •Describing Vulnerabilities
- •Vulnerability Scans
- •Penetration Testing
- •Compliance Checks
- •Code Review and Testing
- •Interface Testing
- •Misuse Case Testing
- •Test Coverage Analysis
- •Website Monitoring
- •Implementing Security Management Processes
- •Log Reviews
- •Account Management
- •Disaster Recovery and Business Continuity
- •Training and Awareness
- •Key Performance and Risk Indicators
- •Summary
- •Exam Essentials
- •Written Lab
- •Review Questions
- •Need to Know and Least Privilege
- •Separation of Duties (SoD) and Responsibilities
- •Two-Person Control
- •Job Rotation
- •Mandatory Vacations
- •Privileged Account Management
- •Service Level Agreements (SLAs)
- •Addressing Personnel Safety and Security
- •Duress
- •Travel
- •Emergency Management
- •Security Training and Awareness
- •Provision Resources Securely
- •Information and Asset Ownership
- •Asset Management
- •Apply Resource Protection
- •Media Management
- •Media Protection Techniques
- •Managed Services in the Cloud
- •Shared Responsibility with Cloud Service Models
- •Scalability and Elasticity
- •Provisioning
- •Baselining
- •Using Images for Baselining
- •Automation
- •Managing Change
- •Change Management
- •Versioning
- •Configuration Documentation
- •Managing Patches and Reducing Vulnerabilities
- •Systems to Manage
- •Patch Management
- •Vulnerability Management
- •Vulnerability Scans
- •Common Vulnerabilities and Exposures
- •Summary
- •Exam Essentials
- •Written Lab
- •Review Questions
- •Conducting Incident Management
- •Defining an Incident
- •Incident Management Steps
- •Basic Preventive Measures
- •Understanding Attacks
- •Intrusion Detection and Prevention Systems
- •Specific Preventive Measures
- •Logging and Monitoring
- •The Role of Monitoring
- •Log Management
- •Egress Monitoring
- •Automating Incident Response
- •Understanding SOAR
- •Threat Intelligence
- •Summary
- •Exam Essentials
- •Written Lab
- •Review Questions
- •The Nature of Disaster
- •Natural Disasters
- •Human-Made Disasters
- •Protecting Hard Drives
- •Protecting Servers
- •Protecting Power Sources
- •Trusted Recovery
- •Quality of Service
- •Recovery Strategy
- •Business Unit and Functional Priorities
- •Crisis Management
- •Emergency Communications
- •Workgroup Recovery
- •Alternate Processing Sites
- •Database Recovery
- •Recovery Plan Development
- •Emergency Response
- •Personnel and Communications
- •Assessment
- •Backups and Off-site Storage
- •Software Escrow Arrangements
- •Utilities
- •Logistics and Supplies
- •Recovery vs. Restoration
- •Testing and Maintenance
- •Structured Walk-Through
- •Simulation Test
- •Parallel Test
- •Lessons Learned
- •Maintenance
- •Summary
- •Exam Essentials
- •Written Lab
- •Review Questions
- •Investigations
- •Investigation Types
- •Evidence
- •Investigation Process
- •Major Categories of Computer Crime
- •Military and Intelligence Attacks
- •Business Attacks
- •Financial Attacks
- •Terrorist Attacks
- •Grudge Attacks
- •Thrill Attacks
- •Hacktivists
- •Ethics
- •Organizational Code of Ethics
- •(ISC)2 Code of Ethics
- •Ethics and the Internet
- •Summary
- •Exam Essentials
- •Written Lab
- •Review Questions
- •Software Development
- •Systems Development Lifecycle
- •Lifecycle Models
- •Gantt Charts and PERT
- •Change and Configuration Management
- •The DevOps Approach
- •Application Programming Interfaces
- •Software Testing
- •Code Repositories
- •Service-Level Agreements
- •Third-Party Software Acquisition
- •Establishing Databases and Data Warehousing
- •Database Management System Architecture
- •Database Transactions
- •Security for Multilevel Databases
- •Open Database Connectivity
- •NoSQL
- •Expert Systems
- •Machine Learning
- •Neural Networks
- •Summary
- •Exam Essentials
- •Written Lab
- •Review Questions
- •Malware
- •Sources of Malicious Code
- •Viruses
- •Logic Bombs
- •Trojan Horses
- •Worms
- •Spyware and Adware
- •Ransomware
- •Malicious Scripts
- •Zero-Day Attacks
- •Malware Prevention
- •Platforms Vulnerable to Malware
- •Antimalware Software
- •Integrity Monitoring
- •Advanced Threat Protection
- •Application Attacks
- •Buffer Overflows
- •Time of Check to Time of Use
- •Backdoors
- •Privilege Escalation and Rootkits
- •Injection Vulnerabilities
- •SQL Injection Attacks
- •Code Injection Attacks
- •Command Injection Attacks
- •Exploiting Authorization Vulnerabilities
- •Insecure Direct Object References
- •Directory Traversal
- •File Inclusion
- •Request Forgery
- •Session Hijacking
- •Application Security Controls
- •Input Validation
- •Web Application Firewalls
- •Database Security
- •Code Security
- •Secure Coding Practices
- •Source Code Comments
- •Error Handling
- •Hard-Coded Credentials
- •Memory Management
- •Summary
- •Exam Essentials
- •Written Lab
- •Review Questions
- •Chapter 2: Personnel Security and Risk Management Concepts
- •Chapter 3: Business Continuity Planning
- •Chapter 4: Laws, Regulations, and Compliance
- •Chapter 5: Protecting Security of Assets
- •Chapter 10: Physical Security Requirements
- •Chapter 11: Secure Network Architecture and Components
- •Chapter 12: Secure Communications and Network Attacks
- •Chapter 17: Preventing and Responding to Incidents
- •Chapter 18: Disaster Recovery Planning
- •Chapter 19: Investigations and Ethics
- •Chapter 20: Software Development Security
- •Chapter 21: Malicious Code and Application Attacks
- •Chapter 3: Business Continuity Planning
- •Chapter 5: Protecting Security of Assets
- •Chapter 6: Cryptography and Symmetric Key Algorithms
- •Chapter 12: Secure Communications and Network Attacks
- •Chapter 15: Security Assessment and Testing
- •Chapter 17: Preventing and Responding to Incidents
- •Chapter 18: Disaster Recovery Planning
- •Chapter 19: Investigations and Ethics
- •Chapter 21: Malicious Code and Application Attacks
- •Index

952 Chapter 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
954 Chapter 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.

956 Chapter 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
958 Chapter 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.”
960 Chapter 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 |