Jim’s CISSP Notes
Toggle Dark/Light/Auto mode Toggle Dark/Light/Auto mode Toggle Dark/Light/Auto mode Back to homepage

8: Software Development Security

Software development lifecycle (SDLC)

Software platforms

Endpoint applications

  • self-contained on a device
  • example: calc.app

Client/server applications

  • most business applications user this

  • example: databases

  • alteration attacks seek to undermine integrity

  • web applications

    • client/server applications over the web

Mobile endpoint

  • commonly run both endpoint applications and client/server applications

Embedded endpoints

Development methodologies

  • every project should begin w/business requirements
  • quality software requires quality design


  • unidirectional, step-by-step

  • doesn’t accommodate changes well

  • can be easier to secure

  • pros of waterfall

    • specific deliverable and review process for each phase
    • phases completed one at at time
    • good for small projects with defined / understood requirements
    • reinforces:
      • “define before design”
      • “design before code”
  • cons of waterfall

    • scope changes midway can kill a project
    • working software isn’t ready until very late into the process
    • high risk and uncertainty
    • not good for long ongoing projects
    • not good if changes are likely
    • project end can be far removed from initial requirements definition stage


  • circular development process

  • prototypes are built, customer gives feedback, prototypes are refined

  • pros of prototyping

    • developers can get customer feedback early in design process
    • developers and customer can compare requirements and software being built
    • developers can tell early on if estimates for deadlines and milestones will be met
  • cons of prototyping

    • customers don’t understand impact of changes requested
    • developers might take shortcuts during the prototyping process that are undocumented


  • combination of prototyping and waterfall

  • pros of spiral

    • lots of risk analysis
    • good for large projects
    • good for mission critical projects
    • software is produced early in the process (inner spirals)
  • cons of spiral

    • can be costly
    • risk analysis requires expertise
      • success is dependent on that risk analysis
    • not good for small projects


  • addresses that customers can request changes quickly

  • pros of agile

    • fewer defects
    • greater flexibility
    • immediate feedback
  • cons of agile

    • less documentation
    • less focus on system design
    • not good for security

Integrated product teams

  • multi-functional teams
  • develop a product, process or policy through parallel decision making

Maturity models

  • provide standard benchmarks

CMMI (compatibility maturity model integrated)

  • assesses an org’s process maturity

  • earlier version of CMMI were focused on software development

  • levels

    1. initial

      • work gets done, but is delayed or over-cost
    2. managed

      • configuration management
      • measurement and analysis
      • project monitoring and control
      • project planning
      • process and product QA
      • requirements management
      • supplier agreement management
    3. defined

      • defined analysis and resolution
      • integrated process management
      • org process definition
      • org training
      • org process focus
      • product integration
      • requirements development
      • risk management
      • technical solution
      • validation
      • verification
    4. quantitatively managed

      • org process performance
      • quantitative project management
    5. optimizing


  • initiating
  • diagnosing
  • establishing
  • action
  • learning

SAMM (software assurance maturity model)

  • developed by OWASP

Change management

  • standardizes code release procedures
  • software development never finishes
    • need to maintain software
    • addition of new features

Request control

  • manages, evaluates and prioritizes requests from customers

Change control

  • grants permission for developers to make changes
  • if approved, developers change code

Release control

  • tests code
  • performs QA checks
  • release manager moves code from development environment to production

Coding environments

  • dev

  • test

  • staging

  • prod

  • all of the above processes are known as software configuration mangement (SCM)

  • all changes and configuration management should be logged

Automation and DevOps


  • partners developers and operations

  • builds collaborative relationships

  • embraces automation

  • facilitates rapid code release

  • provides a stable operating environment for developers

  • devops and agile are related

    • both seek continuous integration

Infrastructure as code

  • scripts the creation of resources

  • example: spinning up new servers w/ scripts that auotmatically configure them to org specifications

  • advantages

    • increases environment scalability
    • reduces user error
    • facilitates testing of new code
    • facilitates security automation
      • DevSecOps applies DevOps principles to security

DevOps tools

  • continuous validation
  • continuous integration
  • continuous delivery
  • continuous deployment
  • continuous monitoring

Programming languages

Interpretted languages

  • translate source code into machine code when the software is run

Compiled languages

  • uses compiler to create machine code executible
  • compiled software is run

Reverse engineering

  • starts w/ a finished product

  • decomposes it to determine how it was made

  • interpretted languages

    • look at source code
  • compiled languages

    • use a sandbox

      • observe code
      • attempt to determine how it runs
    • use a decompiler

      • attempts to convert machine language back into source code
      • produces difficult to understand results

Acquired software

COTS (commercial off-the-shelf)

  • purchased from a third party vendor
  • runs on customer systems

SaaS (software as a service)

  • developed by a vendor

  • runs in a cloud environment for customers

  • security professionals must understand and assess all software used by the org

    • regular vulnerability scans should be run on acquired software

    • vendor security updates should be applied

      • security patches
      • hotfixes
      • critical updates
      • major/minor releases
    • open source software also requires careful management

      • might not have as much support as commercial software
      • might become abandoned
    • software security needs to be configured

      • user accounts
      • admin privileges
      • IP range restrictions

Software Quality Assurance

Code review

  • use peer analysis to assess code

Fagan inspection

  • planning

    • leader prepares for code review
      • prepares materials
      • identifies participants
      • schedules review
  • overview

    • leader assigns roles to participants
    • provides overview of software
  • preparation

    • participants review code individually
      • make note of issues
  • meeting

    • formal meeting w/ participants
    • developers discuss defects
  • rework

    • developers correct defects
  • followup

    • leadership confirms that defects are fixed
  • most orgs use a much less formal process

Software testing

  • ensures that the finished software functions properly

Verification and validation

  • verification

    • checks that the software meets the business requirements
  • validation

    • checks that the software works properly

Stress testing

  • uses automated scripts to verify system capacity
  • may be run internally or by an outside vendor
  • verifies that the system can handle the maximum expected load
  • often determines the maximum capacity by testing to failure

User acceptance testing (UAT)

  • checks that software will work for users
  • users test the software
  • focus on usability
  • also known as beta testing

Regression testing

  • checks for unexpected side effects from updating software
  • checks that software behaves in the same manner compared to the previous version
    • except any new added functionality

Code security tests

  • checks code for security flaws
  • uses technology to test software

Static testing

  • uses automated technology to analyze code for errors
  • doesn’t run code
  • like an automated version of a code review

Dynamic testing

  • automated testing that actually executes code

  • provides inputs and tests outputs

  • verifies that the code is functioning correctly

  • synthetic transaction

    • developers supply inputs to code w/ known expected outputs
code reviews, static testing and dynamic testing are complementary.
they are not competing, and can be used together.

Fuzz testing

  • software testing technique that feed many different input values into a program
  • attempts to cause unpredictable states ot unauthorized access

Input sources

  • developer-supplied input
  • developer-supplied script that generates input
  • generation fuzzing
    • fuzz testing app generates random input
  • mutation fuzzing
    • fuzz testing app analyzes real input and generates input from that
remember to avoid looking like a hacker…
fuzz testing should only be done w/ permission.

Code repos

  • provide secure store and version control

  • allows for coordinated code changes among multiple developers

  • version control helps meet audit requirements

  • promotes code reuse and helps avoid dead code

  • public repos

    • potential disclosure issue
    • be sure to remove API keys, passwords, etc.
  • secure de-/provisioning

    • ensures the integrity of released code

    • integrity measurement

      • verifies that released code isn’t changes
      • hashes code before moving to production
      • ensures that malicious code isn’t released

Application management

Application control

  • restricts software that can run on a system

  • Applocker: example of Windows application control technology

  • application control logs should be sent to SIEM or central log storage repo

  • whitelisting

    • admins create a list of all applications that may run on a system
  • blacklisting

    • admins create a list of applications that are prohibited from running on a system
  • integrate application control logs into SIEM

  • host software baselining

    • identifies expected system software
    • helps with updates
    • reports deviations from baselines

Third-party code

  • developers often rely on third-part code
    • raises security concerns if not vetted


  • shared software code objects with relavent functions

Software development kits (SDKs)

  • created by vendors
  • provide programming resources
  • include documentation and testing utilities


  • allow for interaction w/ remote services

  • outsourcing code development introduces security concerns

Software risk analysis and mitigation

  • many practices combine to produce secure software

  • security should be integrated w/ the SDLC

    • shouldn’t be bolted on after the fact
  • need to understand software security threats

Mitigating software risks

  • input validation

  • encrypt sensitive data

  • enforce least privilege

  • test all code before deploying to production

  • sandboxing

    • isolates development
    • allows developers to test code prior to committing changes

Application Attacks


Open Web Application Security Project maintains a list of common web security issues

  1. Injection flaws
    • attacker inserts unwanted transaction code
  2. Broken authentication
    • exploitation of session management
  3. Sensitive data exposure
    • disclosure of sensitive info
  4. XML external entities
    • allows for remote code execution
  5. Broken access control
    • allows unauthorized access
  1. Security mis-configurations
    • occurs in many locations (Apache, PHP, Python, firewall, etc.)
  2. Cross-site scripting
    • inserts malicious scripts onto sites
  3. Insecure de-serialization
    • allows for API exploitation
  4. Using vulnerable components
    • jeopardizes web application security
  5. Insufficient logging
    • prevents security analysis

Application security

Application types

  • purchased software
    • acquired from a software vendor
    • made of use by many orgs
  • developed software
    • customer-developed software
    • written to meet the needs of the org

Application hardening

  • use proper authentication
  • encrypt sensitive data
  • validate input
  • avoid and remediate known exploits
  • deploy obfuscation and camoflague
  • prompt patching
    • attackers quickl exploit new vulnerabilities

Application configuration

  • type and scope of encryption
  • user access to application
  • access granted to authorized users
  • security of underlying infrastructure
    • servers, firewalls, etc.
  • configuration baselines
    • allow for quick identification and remediation of security gaps

SQL injection

SQL injection

  • dynamic web applications rely on back-end databases to store user info, product info, etc.
  • attackers can exploit input fields to inject SQL commands into a database as part of a normal action
  • Bobby Tables!


  • input validation

    • checks user input on server prior to executing SQL commands
    • checks must be server-side; attackers can easily bypass client-side checks
  • parameterized SQL

    • pre-compiles SQL code on the database server
    • prevents user input from altering query structure

Cross-site scripting

aka XSS

  • attacker embeds malicious code into third party websites that is later run by innocent users

  • XSS attackers commonly embed scripts into sites via user input

    • via <script> tags
  • prevention

    • use input validation
      • don’t allow users to submit fields with <script> tags

Cross-site request forgery

aka XSRF, CSRF, “sea surf”

  • similar to XSS, but more dangerous

  • use one site to trick browsers into sending malicious requests to another site

  • leverage the fact that users are logged into multiple websites

    • persistant cookies keep users logged in for periods of time
  • XSRF secretly send requests to other websites

    • usually through images
  • prevention

    • orgs:
      • rearchitect websites
      • prevent HTTP GET requests
      • leverage Access-Control-Allow-Origin
      • educate users
      • auto-log users out of site after period of time
    • users
      • log out of sites
  • server-side request forgery

    • manipulate servers into retrieving malicious data from what it thinks is a reputable source

Directory traversal attacks

attack allows an attacker to manipulate a web server’s file directory

  • Unix file system directory references

    • ./ current directory
    • ../ one directory up
    • ../../ two directories up
    • etc
  • attacker users file system references to look for files on the server

  • prevention

    • input validation
    • strict file system access controls — user running web server should only have access to web server files

Overflow attacks

  • developers often set aside memory buffers for user input when developing applications

  • attackers input a string much larger than the buffer

  • the server can then inadvertantly return information outside of the buffer

  • prevention

    • input validation


  • track user activities on the web

  • stored by websites in the user’s browser

  • used to recognize and remember the user

  • are also used in some applications

    • known as locally stored objects (LSOs)

Privacy concerns

  • track users on the web
  • often used by ad networks
  • logging into one site has the potential de-anonymize the user

Session hijacking

  • cookies are used for web authentication

  • cookie guessing

    • guessable cookie jeopardize security
    • cookie values (such as session ID) should be random, not based on a guessable pattern
  • session replay

    • cookies are susceptible to replay attacks
    • cookies should be sent over an encrypted connection to prevent eavesdropping

Code execution attacks

  • occur when an attacker exploits vulnerabilities on a system that allow them to run commands on the systems

  • arbitrary code execuction

    • code execution attack where the attacker runs commands of his choice
  • remote code execution

    • code execution attack that takes place over a network
  • objectives

    • install malware
    • join the host to a botnet
    • steal sensitive information
    • install a backdoor for later use

Privilege escalation

  • gain admin access

  • often exploit buffer overflow attacks

  • prevention

    • input validation
    • enforce least privilege
    • keep OS, platform, apps patched
    • use data execution prevention (DEP) and address space layout randomization (ASLR) technology

Driver manipulation

  • device drivers act as a software interface between an OS and hardware
  • requires low-level access to the OS

Driver refactoring

  • modifying a driver to carry malicious code
  • requires access to the device driver’s source code
  • less common
    • attackers rarely have access to source code

Driver shimming

  • wraps a legitimate driver w/ a malicious shim containing malicious code
  • doesn’t require acces to the driver’s source code

Code signing

  • protects against malicious drivers
  • ensures that drivers are authentic and safe

Memory vulnerabilities

  • memory management provides isolated memory for each system process and application

Memory overflow

  • allows for arbitrary code execution

Resource exhausting

  • has the potential to slow down or disable a system

Memory leaks

  • applications fail to release memory for resuse

Memory pointers

  • variable that stores the address to a location in memory

  • pointer deferencing

    • process of following a point

    • NULL pointer dereferencing

      • situation where a pointer isn’t set, therefore it points nowhere
      • best case scenario: application crashes and attacker can access a debug log
      • worst case scenario: allows an attacker to bypass security controls

DLL injection

  • tricks an application into loading malicious code
  • often attempted through the use of memory vulnerabilities

Race condition vulnerabilities

  • when the proper function of a security control depends on the timing of actions performed by the user or system
  • uncontrolled race conditions can be a security vulnerability

Time of check/time of use (TOC/TOU)

  • there is a time elapsed between authorization and the action taken
  • can be prevented by locks that prevent simultaneous transactions from creating race conditions

Secure Coding Practices

Input validation

  • should filter user-supplied input

    • should always be performed on the server
  • approaches

    • whitelisting

      • specifies allowed input
      • not always practical
        • can you come up w/ a list of every possible good input?
    • blacklisting

      • specifies disallowed input
      • more difficult
      • less effective

Parameterized queries

  • SQL template pre-compiled on the database server
  • used by stored procedures
  • example

Authentication/session management

  • never store passwords in plaintext
    • use hashing and salting
  • encrypt passwords in transit
  • use SSL/TLS
    • encrypts web traffic

Output encoding

  • encoding
    • replaces dangerous characters used in SQL injection attacks and XSS

    • HTML encoding

      • uses &xxx;
      • example: ' = &apos;
    • URL encoding

      • uses %####
      • example: ' = %27

Error and exception handling

  • appropriate error handling is critical to software security

  • unpredictable states jeopardize application security

  • error handling
    exception handling

    • avoids unpredictable states
  • try-catch model

Code signing

  • ensures users that code comes from a legitimate source

  • applies digital signatures to software

  • signing code

    1. developer obtains a digital cert
    2. developer creates a digital signature w/ private key associated w/ digital cert’s public key
  • verifying code signatures

    1. user downloads software
    2. user’s OS validates digital signature of the software
    3. user’s OS validates the signature’s hash of the software
    4. software is trusted
  • this process is similar to digital signatures used in email

Database security

  • database normal forms

    • design rules for columns and tables in a data base

    • why normalize?

      • prevent data inconsistancies
      • prevent update anomolies
      • reduce need for restructuring
      • make database schema more informative
  • obsfuscation and camoflauge can hide the locations of sensive data

  • database activity monitoring

    • logs and analyzes database requirements
  • stored procedures

    • protect against SQL injection attacks

Data deidentification

  • removes obvious identifiers

  • anonymization

    • removes the possibility of identification
  • HIPAA deidentification standards

    • expert determination

      • apply scientific / statistical principles
    • safe harbor

      • remove 18 types of identifiers

Data obfuscation

  • transforms PII into a form where it isn’t possible to tie that info to an individual

  • hashing

    • replaces sensitive fields w/ hash values
    • salting decreases likelihood that data will be recovered by a rainbow table attack
  • tokenization

    • replaces sensitive fields w/ a random identifier
    • uses a lookup table to find sensitive info
      • lookup table must be. secured
  • masking

    • redacts sensitive info in a file
    • masking ████ like this ████

Cloud Computing

What is the cloud?

  • Mike Chapple
  • “delivering computing resources to a remote customer over a network”
  • examples:
    • accessing web-based email
    • building servers in AWS
    • running scripts on Salesforce
  • NIST
  • “a model for enabling ubiquitous, convenient, on-demand network access to a shared pool of configurable computing resources (e.g. networks, servers, storage, applications and services) that can be readily provisioned and released with minimal management effort or service provider interaction”

Cloud computing roles

people and orgs play different roles in cloud computing

Cloud service provider

  • offers cloud computing services to third parties
  • run infrastructure
  • might outsource to other cloud providers

Cloud customer

  • consumer of cloud services
  • purchases cloud computing services from one or more cloud service provider
  • nature of relationship with provider can vary
    • self-service
    • one-on-one support w/ account managers

Cloud service partner

  • provides add-on services
    • might assist org in implementing cloud for org
    • might offer security monitoring

Cloud access security brokers (CASBs)

  • provide managed IAM services

  • can add a third party security layer between an org and their cloud service provider

    • network-based CASBs

      • intercepts network traffic between the org and cloud
      • monitors traffic for security issues
      • can block access if issue discovered
    • API-based CSABs

      • queries cloud service by API and monitors
      • may be limited by API access and what information is available from API

Drivers for cloud computing

  • on-demand self-service

    • resources are available when the org needs them
    • can spin up servers on demand using pre-configured images
  • scalability

    • can increase capacity on demand

    • horizontal scaling

      • adding additional servers to a pool to meet increased demand
    • vertical scaling

      • adding more resources (CPU, memory, storage) to a server on demand
  • elasticity

    • the ability to expand and contract quickly
  • broad network access

    • provide anywhere anytime access
  • measured service

    • pay only for what you consume

Security service providers

Managed service provider (MSP)

  • offer managed IT services to customers

Managed security service providers (MSSPs)

  • offer managed IT security services to customers

  • if used, must be carefully monitored and documented

  • examples of services offered

    • management of entire security infrastructure
    • monitoring of system logs
    • management of firewalls and network security
    • performance of IAM
  • exam tip: MSSPs may also be referred to as security as a service (SECaaS)

Cloud access security brokers (CASBs)

  • add a third party security layer between an org. and their cloud service provider
  • network-based CASBs
    • intercepts network traffic between the org and cloud
    • monitors traffic for security issues
    • can block access if issue discovered
  • API-based CSABs
    • queries cloud service by API and monitors
    • may be limited by API access and what information is available from API

Cloud activities and the cloud reference architecture

Cloud Reference Architecture

  • ISO 17789: Cloud Computing Reference Architecture
    • the reference architecture is a helpful framework, but is just a starting point

    • defines cloud computing activities

    • customer activities

      • user cloud services
      • perform service trials
      • monitor services
      • administer security
      • provide billing reports
      • handle problems
      • administer tenancies
      • perform business admin
      • select services
      • request audit reports
    • cloud service provider activities

      • prepare systems and services
      • monitor services
      • manage assets
      • provide audit data
      • manage customer relationships
      • perform peering
      • ensure compliance
      • provide connectivity
    • partner activities

      • design, create, maintain services
      • test services
      • perform audits
      • set up legal agreements
      • acquire and assess customers
      • assess the market

Cloud deployment models

Private cloud

  • org uses a dedicated cloud infrastructure

Public cloud

  • org uses multi-tenancy info structure
  • public cloud computing uses a shared responsibility model

Hybrid cloud

  • org uses both private and public cloud

Community cloud

  • cloud created by a consortium or group of orgs
  • example: PASSHE makes a cloud for all state universities
  • no cloud model is superior, it all depends on context and the org’s needs

Cloud service categories

  • _X_aaS
    • x as a service

Software as a service (SaaS)

  • customers purchase an entire application
  • often run through a browser
    • compatibility is less of an issue
    • example: Gmail, Boxer, O365, OneDrive, etc.
  • can be specialized
    • example: credit card processing software, Square, etc.

Infrastructure as a service (IaaS)

  • customers purchase servers or storage
  • example: AWS, GCP, Azure

Platform as a service (PaaS)

  • customer purchases an application platform

Function as a service (FaaS)

Security responsibility

  • depends on the level of the service

    IaaS PaaS SaaS
    data customer customer customer
    app customer customer vendor
    OS customer vendor vendor
    hardware vendor vendor vendor
    data center vendor vendor vendor
    exam tip
    understanding the shared responsibility model is important for infosec professionals.

Design Process

  • reduce attack surface of product
    • user input
    • protocols / services / interfaces / processes — minimize
    • resource files
    • open named pipes / open sockets
    • how many items are accessible
    • dynamic web pages (ASP, etc.)
    • ACL configuration

Threat Modeling

  • identify security objectives
    • legislative drivers
    • contractual requirements
    • alignment with business objectives
  • CIA triad
  • tools for threat modeling
    • data flow diagrams
    • use/misuse cases


Threat Mitigation
Spoofing authentication
Tampering integrity verification (message digests/CRCs)
Repudiation non-repudiation (digital signatures, keys)
Information Disclosure confidentiality, encryption
Denial of Service high availability, redundancy, fault tolerance
Escalation of Privilege Authorization

Considerations for design

  • CIA
  • AAA
  • secure design principles

Risks in Design

  • code reuse
  • flaws vs. bugs
    • flaw: inherent fault with the design of code
    • bug: implementation fault
  • open vs. closed design

Secure Design Principles

  • good enough security
  • least privilege
  • depth of defense
  • separation of duties
  • fail safe
  • complete mediation
  • open design
  • economy of mechanism
  • least common mechanism
  • psychological acceptability
  • leverage of existing components
  • weakest link
  • single points of failure

Quality vs. Security

  • quality: does it do what it’s supposed to do?
  • security: focus on reducing the probability and/or impact of vulnerabilities/threats
  • best implemented together throughout the SDLC

Requirements to Writing Secure Code

  • training / awareness for developers
    • security is often not emphasized in universities / academia
    • often push to get it done and make fixes after deployment via patches
  • a shift of focus and understanding from managers
    • need to budget time and money in development to include security
  • bug tracking classification — DREAD
    • D: damage potential
    • R: reproducability
    • E: exploitability
    • A: affected user base
    • D: discoverability