CSC 593: Secure Software
Engineering Seminar
James Walden and Charles Frank
Secure Development Lifecycle
CSC 593: Secure Software Engineering Seminar
Slide #1
Topics
1.
2.
3.
4.
Common Approaches.
Categories of Security Flaws.
Security first and last.
The Lifecycle.
CSC 593: Secure Software Engineering Seminar
Slide #2
Common Approaches
1. Penetrate and Patch
Let someone else find flaws, then we’ll fix it.
2. Penetration Testing
We’ll test it until we find all the flaws.
3. Secure Coding
Follow this checklist, and everything is fine.
CSC 593: Secure Software Engineering Seminar
Slide #3
Penetrate and Patch
Discover flaws after deployment.
Often by attackers.
Users may not deploy patches.
Patches may have security flaws (15%?)
Patches are map to vulnerabilities.
Attackers reverse engineer to create attacks.
CSC 593: Secure Software Engineering Seminar
Slide #4
Penetration Testing
Allocate time at end of development to test.
Often time-boxed: test for n days.
Schedule slips often reduce testing time.
Problem: fixing flaws is expensive late in lifecycle.
Regular testing
Demonstrate that features work as desired.
Security testing
Demonstrate that application has no extra capabilities.
How can you prove a negative?
CSC 593: Secure Software Engineering Seminar
Slide #5
Secure Coding
Secure coding
Coding methods training.
Checklist-based approach.
Problem: relies on flawless developers.
Not all problems are implementation based.
Requirements may be wrong.
Design may not allow for security.
CSC 593: Secure Software Engineering Seminar
Slide #6
Categories of Security Flaws
1. Architectural/design-level flaws: security
issues that original design did not consider
or solve correctly.
2. Implementation flaws: errors made in
coding the design.
3. Operational flaws: problems arising from
how software is installed or configured.
CSC 593: Secure Software Engineering Seminar
Slide #7
Architecture/Design Flaws
• Race Condition
– Application checks access control, then accesses a file as
two separate steps, permitting an attacker to race
program and substitute the accessible file for one that’s
not allowed.
• Replay Attack
– If an attacker can record a transaction between a client
and server at one time, then replay part of the
conversation without the application detecting it, a replay
attack is possible.
• Sniffing
– Since only authorized users could directly access
network in original Internet, protocols like telnet send
passwords in the clear.
CSC 593: Secure Software Engineering Seminar
Slide #8
Implementation Flaws
• Buffer overflow
– Application with fixed-size buffer accepts unlimited
length input, writing data into memory beyond buffer in
languages w/o bounds checking like C/C++.
• Input validation
– Application doesn’t check that input has valid format,
such as not checking for “../” sequences in pathnames,
allowing attackers to traverse up the directory tree to
access any file.
• Back door
– Programmer writes special code to bypass access control
system, often for debugging or maintenance purposes.
CSC 593: Secure Software Engineering Seminar
Slide #9
Operational Flaws
• Denial of service
– System does not have enough resources or
ability to monitor resources to sustain
availability under large number of requests.
• Default accounts
– Default username/password pairs allow access to
anyone who knows default configuration.
• Password cracking
– Poor passwords can be guessed by software
using dictionaries and permutation algorithms.
CSC 593: Secure Software Engineering Seminar
Slide #10
Why security first?
1. Adding security later is wrapping security
around existing features, not designing
features with security in mind.
2. Adding security later is expensive.
3. Adding security may change how you
implement application features.
4. Adding security may change user interface.
CSC 593: Secure Software Engineering Seminar
Slide #11
SDLC Artifacts
CSC 593: Secure Software Engineering Seminar
Slide #12
Trustworthy Computing SDLC
CSC 593: Secure Software Engineering Seminar
Slide #13
SD3+C
Secure by Design
protect application and its data.
Secure by Default
designers should assume that security flaws exist.
principles: least privilege and fail-safe defaults
Secure in Deployment
documentation and tools for users and administrators.
easy to install security updates.
Communications
communicate openly and responsibly with end users and/or
administrators to help them take protective action.
CSC 593: Secure Software Engineering Seminar
Slide #14
What is Threat Modeling?
Assessing security risks of a software system
from an adversary’s perspective.
CSC 593: Secure Software Engineering Seminar
Slide #15
Requirements
Management support
Security advisor / officer
Security Features
Authentication, access control, cryptography.
Misuse Cases
How might application features be abused?
Threat Modeling
What assets are you protecting?
What threats to those assets exist?
CSC 593: Secure Software Engineering Seminar
Slide #16
Design
Design Principles
Least Privilege
Compartmentalize
Design Patterns
Threat Modeling
Identify assets.
Identify entry points.
Design security mechanisms.
CSC 593: Secure Software Engineering Seminar
Slide #17
Goals of Threat Modeling
1. Understand threats to guard against during
requirements analysis.
2. Provide basis for which security
mechanisms to include during design.
3. Verify security of system design.
4. Provide basis for prescribing secure
implementation practices.
5. Provide basis for testing system security
after implementation.
CSC 593: Secure Software Engineering Seminar
Slide #18
Threat Modeling Process
1. Understand adversary’s view of system.
2. Characterize security of system.
3. Evaluate threats.
CSC 593: Secure Software Engineering Seminar
Slide #19
Understanding the Adversary’s View
1. Identify System Assets.
– System resources that an adversary might attempt to
access, modify, or steal.
– Ex: credit cards, network bandwidth, user access.
2. Identify Entry Points.
– Any location where data or control transfers between
the system being modeled and another system.
– Ex: network sockets, RPCs, web forms, files
3. Determine Trust Levels.
– Privileges external entities have to legitimately use
system resources.
CSC 593: Secure Software Engineering Seminar
Slide #20
Entry Points
• Any method for system to accept input
• Example: http://at204m02/ctrl.psp?pg=login
– Web server: at204m02
• All network protocols that can access host
• Web server specific attacks
– ctrl.psp
• Your controller application
– pg=login
• The login subsystem invoked by controller
CSC 593: Secure Software Engineering Seminar
Slide #21
Data Flow Diagrams
Visual model of how system processes data.
Hierarchical
Level 0: Models whole system.
Level 1: Models subsystems, …
Client
1. System
Database
Report System
CSC 593: Secure Software Engineering Seminar
Slide #22
Evaluate Threats
Identify Threats
– For each entry point, determine how an
adversary may attempt to affect an asset.
– Based on asset, predict what adversary would try
to do and what his goals would be.
Analyze Threats.
– Decompose threats into individual, testable
conditions using techniques like attack trees.
– Evaluate risk of threat with DREAD categories.
CSC 593: Secure Software Engineering Seminar
Slide #23
Identify Threats
• Can an unauthorized network user view
confidential information such as addresses or
passwords?
• Can an unauthorized user modify data like
payments or purchases in the database?
• Could someone deny authorized users access to
the application?
• Could an authorized user exploit a feature to raise
their privileges to administrator level?
CSC 593: Secure Software Engineering Seminar
Slide #24
STRIDE Threat Categorization
Spoofing
ex: Replaying authentication transaction.
Tampering
ex: Modifying authentication files to add new user.
Repudiation
ex: Denying that you purchased items you actually did.
Information disclosure
ex: Obtaining a list of customer credit card numbers.
Denial of service
ex: Consuming CPU time via hash algorithm weakness.
Elevation of privilege
ex: Subverting a privileged program to run your cmds.
CSC 593: Secure Software Engineering Seminar
Slide #25
Analyze Threats
• Decompose threats into individual, testable
conditions using attack trees.
• Attack Trees
– Hierarchical decomposition of a threat.
– Root of tree is adversary’s goal in the attack.
– Each level below root decomposes the attack
into finer approaches.
– Child nodes are ORed together by default.
– Special notes may indicate to AND them.
CSC 593: Secure Software Engineering Seminar
Slide #26
Attack Trees—Graph Notation
Goal: Read file from password-protected PC.
Read File
Get Password
Search Desk
Network Access
Social Engineer
Physical Access
Boot with CD
CSC 593: Secure Software Engineering Seminar
Remove hard disk
Slide #27
Attack Trees—Text Notation
Goal: Read message sent from one PC to another.
1. Convince sender to reveal message.
1.1 Blackmail.
1.2 Bribe.
2. Read message when entered on sender’s PC.
1.1 Visually monitor PC screen.
1.2 Monitor EM radiation from screen.
3. Read message when stored on receiver’s PC.
1.1 Get physical access to hard drive.
1.2 Infect user with spyware.
4. Read message in transit.
1.1 Sniff network.
1.2 Usurp control of mail server.
CSC 593: Secure Software Engineering Seminar
Slide #28
Evaluate Risk with DREAD
Damage Potential
– Extent of damage if vulnerability exploited.
Reproducibility
– How often attempt at exploitation works.
Exploitability
– Amount of effort required to exploit vulnerability.
Affected Users.
– Ration of installed instances of system that would be
affected if exploit became widely available.
Discoverability
– Likelihood that vulnerability will be discovered.
CSC 593: Secure Software Engineering Seminar
Slide #29
Quantifying Threats
Calculate risk value for nodes in attack tree
–
–
–
–
Start at bottom of tree.
Assign a number 1-10 to each DREAD item.
Assign average of numbers to node.
Propagate risk values to parent nodes.
• Sum risk values if child nodes are ANDed together.
• Use highest risk value of all children if nodes are ORed together.
Alternate technique: monetary evaluation
– Estimate monetary value to carry out attacks.
– Propagate values to parent nodes as above.
– Note: smaller values are higher risks in this method.
CSC 593: Secure Software Engineering Seminar
Slide #30
Implementation
Coding standards
Acceptable libraries and functions.
Checklists.
Static analysis tools
Identifies common errors.
Code reviews
More effective than testing in many reports.
CSC 593: Secure Software Engineering Seminar
Slide #31
Verification
Fuzz Testing
Automatic testing with random data.
Unit Tests
Test security features.
Penetration Testing
Driven by application risks.
Threat model identifies most important assets and
entry points.
CSC 593: Secure Software Engineering Seminar
Slide #32
Maintenance
Prepare before release time.
Receiving vulnerability reports.
Releasing security advisories.
Developing, testing, and distributing patches.
CSC 593: Secure Software Engineering Seminar
Slide #33
SDLC at Microsoft
Management support
Bill Gates letter about 2002 security push.
Mandatory education
For managers and engineers.
Annual updates.
Metrics
Education coverage.
Vulnerabilities discovered.
Central Security Team
Ensures someone is responsible.
Keeps process and education updated.
CSC 593: Secure Software Engineering Seminar
Slide #34
SDLC Results
CSC 593: Secure Software Engineering Seminar
Slide #35
References
1.
2.
3.
4.
5.
6.
7.
8.
Brad Arkin, “Software Penetration Testing,” IEEE Security & Privacy,
3(1):84-87, 2005.
Matt Bishop, Introduction to Computer Security, Addison-Wesley, 2005.
Graff, Mark and van Wyk, Kenneth, Secure Coding: Principles & Practices,
O’Reilly, 2003.
Greg Hoglund and Gary McGraw, Exploiting Software: How to Break Code,
Addison-Wesley, 2004.
Howard, Michael and LeBlanc, David, Writing Secure Code, 2nd edition,
Micorosft Press, 2003.
Steve Lipner and Michael Howard, “The Trustworthy Computing Secure
Development Lifecycle,”
http://msdn.microsoft.com/library/default.asp?url=/library/enus/dnsecure/html/sdl.asp, 2005.
Frank Swiderski and Window Snyder, Threat Modeling, Microsoft Press,
2004.
John Viega and Gary McGraw, Building Secure Software, Addison-Wesley,
2002.
CSC 593: Secure Software Engineering Seminar
Slide #36