Security
What is Software Security?
“the degree to which software protects information and system resources,
providing access only to authorized users as intended” (IEEE)
Software Security vs
Cybersecurity
• Sometimes “Cybersecurity” used to
describe all computer/IT-related security
• Specifically – Network security
• Software Security is SPECIFICALLY about
security issues in software
• Shouldn’t completely ignore hardware
(e.g. SPECTRE/MELTDOWN)
CIA triad
• Key set of software security principles
• Sometimes Security/Cybersecurity defined as the preservation of these principles)
• Other security principles exist (e.g. nonrepudation), but can typically be
reclassified within the triad
“preserving authorized restrictions on access and disclosure,
Confidentiality including means for protecting personal privacy and
proprietary information” – 44 U.S.C. 3542
Integrity “guarding against improper information modification or
destruction” – 44 U.S.C. 3542
Availability “ensuring timely and reliable access to and use of information” –
44 U.S.C. 3542
How do we preserve security
principles?
Security vs Privacy
• Security focuses on protecting data from unauthorized access
• Privacy focuses on an individuals’ control over their personal information
• Security mechanisms often have privacy benefits
• Security often “bolt-on”, handled at the last minute
Principle of • Security is more cost-effective if it is incorporated
earlier in the SDLC
“Shift Left” • Vulnerabilities easier to fix if found earlier
• Able to design systems for security and reduce
issues
• Not forced to choose between security and
deploying on-time
How do we implement Security in an
application?
• Access Control
• Cryptography
Access Control
• Authentication vs Authorization
• RBAC vs Attribute-Based
• Easier to incorporate in design than to retrofit
“The discipline that embodies the
principles, means, and methods for the
transformation of data in order to hide their
Cryptography semantic content, prevent their
unauthorized use, or prevent their
undetected modification.”
– NIST CSRC
History of Cryptography
• Predates modern computers by millenia
• Caesar Cipher used by Julius Caesar
• Efforts to create and break ciphers during WWII a key driver to
what became the modern computer
• Encryption algorithms WILL be broken
• E.g. Post-Quantum Cryptography
• Often easier to break the library/implementation than the algorithm itself
Encryption Standards
Currently – “best practice” is SHA-2
Transitioning towards post-quantum cryptography
Secure Development Lifecycles
• Security Development Lifecycle– software development lifecycle
that incorporates security practices at every stage
• Example: Microsoft’s SDL
Bill Gates TWC Memo
https://news.microsoft.com/2012/01/11/memo-from-bill-gates/
Microsoft’s Security Development Lifecycle
Key Practices
1. Establish security standards, metrics, and governance
2. Require use of proven security features, languages, and frameworks
3. Perform security design review and threat modeling
4. Define and use cryptography standards
5. Secure the software supply chain
6. Secure the engineering environment
7. Perform security testing
8. Ensure operational platform security
9. Implement security monitoring and response
10.Provide Security Training
1. Establish security standards metrics and
governance
• Focuses on updating and communicating security requirements
to reflect changes in functionality, regulations, and the threat
landscape
• Tasks
1. Identify Required Standards
2. Define Security Requirements
3. Define Metrics and Compliance Reporting
4. Create a Security Exception Process
2. Require use of proven security features,
languages, and frameworks
• Ensure dev teams use well established and proven security
solutions
• “Don’t roll your own crypto”
• Tasks:
• Define security requirements (and design) as specifically as possible
• Define and publish lists of approved tools and the requirements and
regulations they address
3. Perform Security Design and Threat
Modeling
• As part of design, focus on how products might be abused as well
as how products should work
• Tasks
1. Identify use cases, scenarios, and assets
2. Create and architecture overview
3. Identify the threats
4. Identify and track mitigations
5. Communicate threat models to key stakeholders
4. Define and Use Cryptography Standards
• Where possible, use existing standards (state-of-the-practice),
while also remaining aware of the state-of-the-art
• Tasks
• Encrypt data at rest and in transit
• Continue to monitor and learn about the cryptographic environment (e.g.
Post-Quantum Cryptography)
• Implement cryptography as flexibly as possible (e.g. interchangeable
libraries)
• Key and certificate management and rotation
5. Secure the Software Supply Chain
• Identify and mitigate risks in a project’s dependencies
• Tasks
• Establish a secure process for acquiring open-source software
• Identify and understand the direct and indirect dependencies
• SBOM
• Signing and “attesting” artifacts
6. Secure the Engineering Environment
• Identify, analyze, and mitigate risks associated with the
environment within
• Tasks:
• Establish and Implement Good Change Management Hygiene (e.g. don’t
let outsiders commit to the repo)
• Provide developers and other stakeholders with the tools they need to
access the software securely
7. Perform Security Testing
• Look for security bugs in the system both during and after
developemtn
• Tasks:
• Implement Static Analysis Security Testing (SAST)
• Implement Dynamic Analysis Security Testing (DAST) and/or Interactive
Analysis Security Testing (IAST) and/or other hybrid approaches
• Red/Blue Team exercises to simulate attacks
• Penetration Testing
• Continuous security testing and management (e.g. integrate tools into
DevOps Pipelines
• Implement a Bug-Bounty Program
8. Ensure Operational Platform Security
• Ensure security of the operational environment
• Tasks
• Enforce appropriate authentication and authorization measures (e.g. two-
factor authentication
• Establish, implement, and monitor security baselines
• Reduce the attack surface
• Implement and monitor logs
9. Implement security monitoring and response
• Plan on stuff going wrong, and be prepared for it
• Tasks:
• Monitor key indicators (e.g. network traffic, “typical” login times, etc.)
• Establish (and train on) a standard incident response process
• Be prepared to change it
10. Provide Security Training
• Everyone should be made aware of security principles
• Communicating why the Security team seems to be making your
life harder can be a useful byproduct (even if teams don’t
remember specifics)
• Tasks:
• Evaluating Training materials for appropriateness, “usability”
• Make training available to stakeholders
• Ensure training is followed (to the extent possible
Evaluating Security
Capability Maturity Models
• Tool used to assess the extent to which an organization
implements security practices & provide guidance on expanding
their ability to do so
• Include a series of practices
• “Maturity Level” assessed based on which practices are followed
Descriptive vs Prescriptive
• Descriptive models describe steps taken in the community they are
formed from
• Prescriptive models indicate what SHOULD be done to achieve
security in a community
• Most (arguably All) CMM tend towards Descriptive
• Not seen as an indicator of the maturity of the model (unlike other
Business Analytics models)
Capability Maturity Models - Examples
• Original CMM out of US DoD for contractors (late 1980s/early 1990s)
• Carnegie Mellon
• OpenSSF Scorecard (for supply chain practices)
• US Department of Energy’s C2M2
• Proprietary Models
• Companies sell a service to help assess and provide guidance based on their model
C2M2 Version 2.1 Overview
The C2M2 is a free tool to help organizations
evaluate their cybersecurity capabilities and
optimize their security investments.
• Designed for any organization regardless of • Developed in 2012 and maintained through an
ownership, structure, size, or industry extensive public-private partnership between
the U.S. Department of Energy’s Office of
• Uses a set of 350+ industry-vetted
Cybersecurity, Energy Security, and Emergency
cybersecurity practices focused on both
Response and numerous government, industry,
information technology (IT) and operations
and academic organizations
technology (OT) assets and environments
• Recent updates in 2022 reflect new
• Results help users prioritize cybersecurity
technologies, threats, and practices
investment decisions based on their risk
Slides from https://www.energy.gov/ceser/cybersecurity-capability-maturity-model-c2m2
Key Features of the C2M2
Area Description
Maturity The C2M2 consists of cybersecurity practices that are organized into three
Model progressive levels of cybersecurity maturity.
Management Management activities measure the extent to which cybersecurity is ingrained in
Activities an organization’s culture.
The C2M2 is descriptive, not prescriptive. Practice statements focus on outcomes
Specificity
that may be implemented through any number of measures.
The C2M2 may be applied to an entire enterprise or to individual parts of the
Scoping
enterprise to enable users to select an appropriate level of granularity.
A C2M2 self-evaluation can be completed in one-day using a free tool that securely
Usability
records results and generates a detailed, graphical report.
Slides from https://www.energy.gov/ceser/cybersecurity-capability-maturity-model-c2m2
Model Organized by 10 Domains
Asset, Change, and Threat and
ACCESS
THREAT
ASSET
Identity and Access
RISK
Configuration Vulnerability Risk Management
Management
Management Management
THIRD-PARTIES
WORKFORCE
RESPONSE
SITUATION
Event and Incident
Situational Third-Party Risk Workforce
Response, Continuity
Awareness Management Management
of Operations
• Domains are logical groupings of cybersecurity
ARCHITECTURE
PROGRAM
Cybersecurity
Cybersecurity practices
Program
Architecture
Management • Each domain has a short name for ease of
reference
Slides from https://www.energy.gov/ceser/cybersecurity-capability-maturity-model-c2m2
Model Structure
Model
Domain Model contains 10 domains
Multiple approach objectives in each domain
Approach Objectives Unique to each domain
Practices at MIL1
Approach objectives are supported by a progression
Practices at MIL2
of practices that are unique to the domain
Practices at MIL3
One per domain
Management Objectives Similar in each domain
Practices at MIL2 Each management objective is supported by a
progression of practices that are similar in each domain
Practices at MIL3 and describe institutionalization activities
Slides from https://www.energy.gov/ceser/cybersecurity-capability-maturity-model-c2m2
C2M2 Version 2.1 Resources
Visit energy.gov/c2m2, c2m2.doe.gov, or email C2M2@hq.doe.gov for more
information.
Model Document Introduces the model practices, key concepts, and how to use the model
Self-Evaluation Tools The tool, available on two platforms, offers interactive features and help
text, allows users to securely record results, and automatically generates a
detailed, graphical report
Self-Evaluation Guide Guides users to plan and facilitate a self-evaluation workshop with key
participants in their organization
Self-Evaluation Workshop Supports planning for a self-evaluation workshop
Kickoff Presentation
Self-Evaluation Cheat Offers a placemat-style reference guide for participants during a self-
Sheet evaluation
Slides from https://www.energy.gov/ceser/cybersecurity-capability-maturity-model-c2m2
C2M2 Self Evaluation
Tool
https://c2m2.doe.gov/
Common Criteria - Overview
• Internantional Standard for evaluating the security of an I/T
product
• Sometimes classified as a CMM, but focuses on product rather
than process
• Intended to allow cross-product comparisons
• Standards bodies exist in some countries to determine if
organizations conform with the CC
Common Criteria – Establishing
Requirements
• Target of Evaluation (TOE)– system that is the subject of the evaluation
• Protection Profile (PP) – documenting which identifies requirements for a class of
security devices
• Security Target (ST) – document that identifies the security properties of the TOE
• Includes problems, objectives, and SFRs
• May confirm with a Protection Profile
• Security Functional Requirement (SFR ) – describe security functions provided by a
product
• Example: The system shall communicate security passwords via channels using a quantum-
secure cryptographic algorithm (FIPS 203, if FIPS 203 has not been superceded)
Common Criteria - Performing Evaluation &
Analyzing Results
• Security Assurance Requirements (SARs) – describe what is done
to ensure product complies with the claimed functionality
• Example:
• A full static analysis scan shall be performed.
• The scan shall be configured to detect cryptographic misconfiguration errors with the
expectation of post-quantum cryptographic standards.
• All cryptographic misconfiguration errors thrown by the scan will be reviewed to
determine if they violate the SFR, regardless of severity level
• Evaluation Assurance Level (EAL) – rating of the depth and rigor of
the evaluation
• Levels from 1 (most basic) to 7 (most stringent)
• More stringent typically means more $$$
Using Dynamic Analysis to Find Security Vulnerabilities
• Make sure you have Firefox or Chrome installed
• Download and install OWASP ZAP: https://www.zaproxy.org/download/
• Run OWASP Juice Shop in Docker:
• In the command line:
• docker pull bkimminich/juice-shop
• docker run --rm -p 127.0.0.1:3000:3000 bkimminich/juice-shop
• To ensure it is running, open a browser and navigate to: http://localhost:3000
Activity (Continued)
• Close as many other applications as you can, including the browser
• Start the OWASP ZAP Application
• Select “Manual Explore”
• Configure the exploration as shown below, then click “Launch Browser”
• Wait for the Heads-Up Display (HUD) to come up
• Keep waiting …
• Keep waiting … (this will take awhile)
Activity- Final
• Select “Take the HUD Tutoral”
• Walk through the tutorial as far as
you can, at least through the
“Break” tools
• Then restart Zap and select
“Continue to your target”
• Explore the Juice Shop using ZAP
• Trigger at least 2 medium level or
higher alerts, and fill out the
assignment/quiz on Canvas
References
• https://www.microsoft.com/en-us/securityengineering/sdl/about
• https://insights.sei.cmu.edu/documents/443/2013_019_001_298
711.pdf
