CSC 593: Secure Software Engineering Seminar

CSC 593: Secure Software Engineering Seminar Slide #1

CSC 593: Secure Software Engineering Seminar

James Walden and Charles Frank

Secure Development Lifecycle


Topics

1. Common Approaches.

2. Categories of Security Flaws.

3. Security first and last.

4. The Lifecycle.


Common Approaches

1. Penetrate and PatchLet someone else find flaws, then we’ll fix it.

2. Penetration TestingWe’ll test it until we find all the flaws.

3. Secure CodingFollow this checklist, and everything is fine.


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.


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 testingDemonstrate that features work as desired.

Security testingDemonstrate that application has no extra capabilities.

How can you prove a negative?


Secure Coding

Secure codingCoding 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.


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.


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.


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.


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.


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.


SDLC Artifacts


Trustworthy Computing SDLC


SD3+C

Secure by Designprotect application and its data.

Secure by Defaultdesigners should assume that security flaws exist.principles: least privilege and fail-safe defaults

Secure in Deploymentdocumentation and tools for users and administrators.easy to install security updates.

Communicationscommunicate openly and responsibly with end users and/or

administrators to help them take protective action.


What is Threat Modeling?

Assessing security risks of a software system from an adversary’s perspective.


Requirements

Management supportSecurity advisor / officer

Security FeaturesAuthentication, access control, cryptography.

Misuse CasesHow might application features be abused?

Threat ModelingWhat assets are you protecting?What threats to those assets exist?


Design

Design PrinciplesLeast Privilege

Compartmentalize

Design Patterns

Threat ModelingIdentify assets.

Identify entry points.

Design security mechanisms.


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.


Threat Modeling Process

1. Understand adversary’s view of system.

2. Characterize security of system.

3. Evaluate threats.


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.


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

http://at204m02/ctrl.psp?pg=login


Data Flow DiagramsVisual model of how system processes data.Hierarchical

Level 0: Models whole system.Level 1: Models subsystems, …

1. SystemClient

Report System

Database


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.


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?


STRIDE Threat Categorization

Spoofingex: Replaying authentication transaction.

Tamperingex: Modifying authentication files to add new user.

Repudiationex: Denying that you purchased items you actually did.

Information disclosureex: Obtaining a list of customer credit card numbers.

Denial of serviceex: Consuming CPU time via hash algorithm weakness.

Elevation of privilegeex: Subverting a privileged program to run your cmds.


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.


Attack Trees—Graph Notation

Goal: Read file from password-protected PC.

Read File

Get Password Network Access Physical Access

Search Desk Social Engineer Boot with CD Remove hard disk


Attack Trees—Text NotationGoal: 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.


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.


Quantifying ThreatsCalculate 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.


Implementation

Coding standardsAcceptable libraries and functions.

Checklists.

Static analysis toolsIdentifies common errors.

Code reviewsMore effective than testing in many reports.


Verification

Fuzz TestingAutomatic testing with random data.

Unit TestsTest security features.

Penetration TestingDriven by application risks.

Threat model identifies most important assets and entry points.


Maintenance

Prepare before release time.Receiving vulnerability reports.

Releasing security advisories.

Developing, testing, and distributing patches.


SDLC at Microsoft

Management supportBill Gates letter about 2002 security push.

Mandatory educationFor managers and engineers.Annual updates.

MetricsEducation coverage.Vulnerabilities discovered.

Central Security TeamEnsures someone is responsible.Keeps process and education updated.


SDLC Results


References1. Brad Arkin, “Software Penetration Testing,” IEEE Security & Privacy,

3(1):84-87, 2005.2. Matt Bishop, Introduction to Computer Security, Addison-Wesley, 2005.3. Graff, Mark and van Wyk, Kenneth, Secure Coding: Principles & Practices,

O’Reilly, 2003.4. Greg Hoglund and Gary McGraw, Exploiting Software: How to Break Code,

Addison-Wesley, 2004.5. Howard, Michael and LeBlanc, David, Writing Secure Code, 2nd edition,

Micorosft Press, 2003.6. Steve Lipner and Michael Howard, “The Trustworthy Computing Secure

Development Lifecycle,” http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnsecure/html/sdl.asp, 2005.

7. Frank Swiderski and Window Snyder, Threat Modeling, Microsoft Press, 2004.

8. John Viega and Gary McGraw, Building Secure Software, Addison-Wesley, 2002.

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnsecure/html/sdl.asp

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnsecure/html/sdl.asp

CSC 593: Secure Software Engineering Seminar

Documents