SSW 540

Foundations of Software Engineering

Week 9Risk Management and

Software Assurance

Outline

Generic Risk Management– Risk identification– Probability and

damage estimation– Risk mitigation– Risk monitoring

Software Assurance Risk Management– Vulnerability and

threat identification– Analysis of risks– Risk mitigation– Assessment of

software assurance processes and practices

2

Rick Management

• Risk Assessment– Risk Identification– Risk Analysis– Risk Prioritization

• Risk Mitigation– Risk Management Planning– Risk Resolution– Risk Monitoring

Week 9 3

Risk Identification

• Consider top causes of project failure• Use a risk item checklist

Week 9 4

5

Risk Item Checklists

• Product Size• Business Impact• Customer-related• Process• Technology• Development Environment• Staff Size and Experience

6

Product Size

• Estimated size of the product in LOC or function points?

• Degree of confidence in estimated size estimate?

• Number of users of the product? • Number of projected changes to the

requirements for the product? Before delivery? after delivery?

7

Business Impact

• Affect of this product on company revenue? • Number of customers who will use this product? • Number of other products/systems with which

this product must be interoperable?

8

Customer-related

• Does the customer have a solid idea of what is required? Has the customer spent the time to write it down?

• Is the customer willing to participate in reviews? • Is the customer technically sophisticated in the

product area?

9

Process

• Are staff members "signed-up" to the software process as it is documented and willing to use it?

• Is the software process used for other projects?• Are formal technical reviews conducted

regularly?

10

Technology

• Are specific methods used for software analysis?

• Are configuration management software tools used to control and track change activity throughout the software process?

• Are metrics collected for all software projects?

11

Development Environment

• Are compilers or code generators available and appropriate for the product to be built?

• Are all software tools integrated with one another?

• Have members of the project team received training in each of the tools?

12

Staff Size and Experience

• Do the people have the right combination of skills?

• Are enough people available? • Are staff committed for entire duration of the

project? • Will some project staff be working only part time

on this project? • Have staff received necessary training?

Risk Analysis

Risk Exposure =Probability of occurrence * Expected loss

Overly optimistic schedule example:50% * 5 weeks = 2.5 weeks exposure

Week 9 13

14

Risk Estimation

1. List all possible risks2. Assign a probability to each (low, medium,

high)3. Assign an impact to each (low, medium, high)4. Sort by probability and impact

15

Sorted Risks

LowImpact

ModerateImpact

HighImpact

LowProbability

ModerateProbability

HighProbability

Criticality 1

Criticality 2

Criticality 2

Criticality 3

Criticality 4

Criticality 4

Criticality 5

Criticality 5Criticality 6

Yellow

Yellow

Yellow

Green

Green Green

Red

Red

Red

16

Risk Mitigation

• Develop a strategy for each risk– May require some creativity– May use successful strategies from past

• Apply each strategy• Monitor for changes

Mitigation Strategies

• Avoid the risk• Transfer the risk to

another part of system

• Buy information about the risk

• Eliminate the root cause of the risk

• Assume the risk• Publicize the risk• Control the risk• Remember the risk

17

18

Risk Monitoring

• Keep Top-10 Risks List• Conduct Interim Retrospectives• Assign Role of Risk Monitor

Software Assurance Risk Management

1. Functional decomposition: to define the attack surface

2. Attacker categorization: identify possible attackers

3. Threat categorization: identify risks4. Threat ranking: estimate damage of risks5. Mitigation planning: formulate plans to

avoid or lessen the impact of risks

19

1. Functional Decomposition

• Create a one-page architectural overview of your system

• Look for vulnerabilities– Consider top vulnerabilities in Common

Weakness Enumeration (CWE)– Map the Attack Surface

Week 9 20

Common Weakness Enumeration (CWE)• The Common Weakness Enumeration is a list of

vulnerabilities maintained by MITRE for the National Cyber Security Division (NCSD) of the Department of Homeland Security (DHS)

• Available online: http://cwe.mitre.org/• Quoting from their About CWE web page:

"CWE is a formal list of software weakness types created to:

– Serve as a common language for describing software security weaknesses in architecture, design, or code

– Serve as a standard measuring stick for software security tools targeting these weaknesses

– Provide a common baseline standard for weakness identification, mitigation, and prevention efforts"

21

Top 25 CWEs

• Collaborative effort of SANS (SysAdmin, Audit, Network, Security) Institute, MITRE and many security experts

• Top 25 are those programming errors that lead to the most serious vulnerabilities

• Updated each year

http://cwe.mitre.org/top25/

22

Information with Each CWE (1/2)• Attack Frequency

– how often the weakness occurs in vulnerabilities that are exploited by an attacker

• Ease of Detection – how easy it is for an attacker to find this

weakness• Remediation Cost:

– amount of effort required to fix the weakness• Attacker Awareness

– likelihood that an attacker is going to be aware of this particular weakness, methods for detection, and methods for exploitation

23

Information with Each CWE (2/2)• Discussion

– narrative description• Detection Methods

– static and dynamic analysis methods that might detect it• Demonstration Examples

– code examples and discussion• Observed Examples

– URLs to real instances• Potential Mitigations

– steps that developers can take to avoid or mitigate the effects

• Related CWEs and Attacks

24

The List of Top 25 CWEs1. CWE-79: Failure to preserve web page

structure ("Cross-Site Scripting")2. CWE-89: Improper sanitization of special

elements used in an SQL command ("SQL Injection")

3. CWE-120: Buffer copy without checking size of input ("Classic buffer overflow")

4. CWE 352: Cross-site request forgery (CSRF)5. CWE-285: Improper access control

(Authorization)6. CWE-807: Reliance on un-trusted inputs in a

security decision7. CWE-22: Improper limitation of a pathname

to a restricted directory ("Path traversal")8. CWE-434: Unrestricted upload of file with

dangerous type9. CWE-78: Improper sanitization of special

elements used in an OS command ("OS Command Injection")

10. CWE-311: Missing encryption of sensitive data

11. CWE-798: Use of hard-coded credentials12. CWE-805: Buffer access with incorrect length

value13. CWE-98: Improper control of filename for

Include/Require statement in PHP program ("PHP File Inclusion")

14. CWE-129: Improper validation of array index15. CWE-754: Improper check for unusual or

exceptional conditions16. CWE-209: Information exposure through an

error message17. CWE-190: Integer overflow or wraparound18. CWE-131: Incorrect calculation of buffer size19. CWE-306: Missing authentication for critical

functions20. CWE-494: Download of code without integrity

check21. CWE-732: Incorrect permission assignment

for critical resource22. CWE-770: Allocation of resources without

limits or throttling23. CWE-601: URL redirection to site ("Open

Redirect")24. CWE-327: Use of a broken or risky

cryptographic algorithm25. CWE-362: Race condition

25

1. CWE-79: Failure to preserve web page structure ("Cross-Site Scripting")

• Cross-site scripting (XSS) is the most common publicly-reported security vulnerability1. Attacker injects code as input to some command2. Command does not adequately check or sanitize its

input, passing it back to the browser as part of the command result.

3. Result is the execution of the injected code by they browser

• Error is failure to prevent user input from propagating through the command

26

Cross-Site Scripting (XSS)• Consider the following scenario (from Wikipedia):1. Alice often visits Bob's website, where she logs in with a

username/password pair and stores sensitive data.2. Mallory observes that Bob's website contains a reflected

XSS vulnerability.3. Mallory crafts a URL to exploit the vulnerability, and sends

Alice an email, enticing her to click on a link for the URL under false pretenses. This URL points to Bob's website, but contains Mallory's malicious code, which the website will reflect.

4. Alice visits the URL provided by Mallory while logged into Bob's website.

5. The malicious script embedded in the URL executes in Alice's browser, as if it came directly from Bob's server (this is the actual XSS vulnerability). 27

2. CWE-89: Improper sanitization of special elements used in an SQL command ("SQL

Injection")1. Similar to XSS, attacker places something in the

input to a command that is passed to a SQL query

2. When the SQL query runs it does more than was originally intended by the programmer

3. The attacker uses the result to steal information or corrupt data

• Error is failure to check or sanitize input

28

SQL Injection Example

1. Suppose a SQL command is constructed like this:

SELECT * FROM users WHERE name = userName

where userName comes from an input field. The intent is to select only the record that matches the userName.

2. The attacker provides a userName:'' or '1'='1'

3. The resulting command is:SELECT * FROM users WHERE name = ''

OR '1'='1'4. The command will retrieve all user records.

29

3. CWE-120: Buffer copy without checking size of input ("Classic buffer overflow")

• A large input value is moved into a storage area that is too small, overflowing the target area.

• The resulting corruption of memory may allow the attacker to bypass access controls or corrupt data.

• The error is failure to check that input values will fit within their target areas.

30

Security PerimeterSecurity perimeter: the border between the

assets we want to protect and the outside world– Airports have a security perimeter maintained

by the US Transportation Security Administration

– For a web application a security perimeter might extend around:• Web server• Application server• Database server

– Outside the security perimeter are:• Web browsers• Other applications• External databases

31

Attack SurfaceAttack surface: all possible entry points that

an attacker can use to attack the application or system.

• Open sockets or ports• Remote Procedure Call (RPC) entry points• All web pages an attacker can access• Every point at which the attacker can

interact with an application (input fields, cookies, URL variables)

• Every function provided by an application32

Mapping the Attack Surface• Crawl every page of the application• Identify all available functionalities

– Follow every link– Fill every form with valid/invalid data

• Look for points where user can supply information– GET requests– POST requests– HTTP headers– Cookies– Hidden parameters

33

2. Attacker Categorization• OWASP recommends considering these attacker types:

– Accidental Discovery: An ordinary user stumbles across a functional mistake in your application, just using a web browser, and gains access to privileged information or functionality.

– Automated Malware: Programs or scripts, which are searching for known vulnerabilities, and then report them back to a central collection site.

– Curious Attacker: A security researcher or ordinary user, who notices something wrong with the application, and decides to pursue further.

– Script Kiddies: Common renegades, seeking to compromise or deface applications for collateral gain, notoriety, or a political agenda, perhaps using the attack categories described in the OWASP Web Application Penetration Checklist.

– Motivated Attacker: Potentially, a disgruntled staff member with inside knowledge or a paid professional attacker.

– Organized Crime: Criminals seeking high stake payouts, such as cracking e-commerce or corporate banking applications, for financial gain.

34

3. Threat Categorization

• Use the STRIDE framework developed by Microsoft to classify threats:– Spoofing identity: Using someone else's

authentication– Tampering: Modification of data– Repudiation: Denying performance of acts,

such as purchase of products or services– Information disclosure: Reading private

information– Denial of service: Preventing others from using

a service– Elevation of privileges: Gaining authorization to

access data or services35

4. Threat Ranking

• Estimate the degree of damage caused by a threat using DREAD, developed by Microsoft:

• Damage potential: How great is the damage?

• Reproducibility: How easy is it to reproduce the attack?

• Exploitability: How easy is it launch the attack?

• Affected users: How many users are affected?

• Discoverability: How easy is it to discover the vulnerability?

36

Calculating DREAD Estimate (1/3)Risk = (D + R + E + A + D) / 5

where:Damage Potential If a threat exploit occurs,

how much damage will be caused? • 0 = Nothing • 5 = Individual user data is compromised or affected. • 10 = Complete system or data destruction

Reproducibility How easy is it to reproduce the threat exploit? • 0 = Very hard or impossible, even for administrators• 5 = One or two steps required, may need to be an

authorized user. • 10 = Just a web browser and the address bar is

sufficient, without authentication. 37

Calculating DREAD Estimate (2/3)

– Exploitability What is needed to exploit this threat? • 0 = Advanced programming and networking

knowledge, with custom or advanced attack tools. • 5 = Malware exists on the Internet, or an exploit is

easily performed, using available attack tools. • 10 = Just a web browser

– Affected Users How many users will be affected? • 0 = None • 5 = Some users, but not all • 10 = All users

38

Calculating DREAD Estimate (3/3)

Discoverability How easy is it to discover this threat? • 0 = Very hard to impossible; requires source code or

administrative access. • 5 = Can figure it out by guessing or by monitoring

network traces. • 9 = Details of faults like this are already in the public

domain and can be easily discovered using a search engine.

• 10 = The information is visible in the web browser address bar or in a form.

Risk = (D + R + E + A + D) / 5yields a number from 0 to 10

39

5. Mitigation Planning

• Reduce likelihood– improve authentication mechanisms– close user sessions more often

• Reduce impact– encrypt data– increase logging and monitoring

Week 9 40

Adopt Best Security Practices

• OWASP Best Practices• Build Security In website:https://buildsecurityin.us-cert.gov/bsi/articles/knowledge/principles.html

• Adopt a Security Maturity Model

Week 9 41

Open Web Application Security Project (OWASP)

• "open community dedicated to enabling organizations to conceive, develop, acquire, operate, and maintain applications that can be trusted."

• Projects:– OWASP Top 10– OWASP ESAPI– (many others)

42

OWASP Best Practices for Software Development

1. Apply defense in depth2. Use a positive security model3. Fail securely4. Run with least privilege5. Avoid security by obscurity6. Keep security simple7. Detect intrusions8. Don't trust infrastructure9. Don't trust services10.Establish secure defaults 43

1. Apply Defense in Depth• Use overlapping layers of control and

countermeasures:– Prevention– Detection– Response

• House analogy:– Locks on doors and windows– Sensors on doors and windows– Motion detectors in house– Logging of all access events– Security company or police notified of

anomalies 44

2. Use a Positive Security Model

• Instead of enumerating all the bad values (blacklisting), enumerate all the good values (whitelisting)– Example: if an operation is supposed to write

to a log file, check that the destination is a valid log file

• Deny access to everything unless explicitly listed

45

3. Fail Securely

• Exceptions that occur in the processing of a security control itself should result in denial of access.– Don't allow access if an exception occurred

• Exceptions that occur elsewhere should not subvert normal security controls.– Don't skip access controls– Don't set the state of the system to open

46

4. Run with Least Privilege• Only use root privileges when they are

really needed• Enforce limits on use of resources

– CPU – watch process consumption– Memory – watch process consumption– Network – use access control– File system – use access control

47

5. Avoid Security by Obscurity

• Don't rely on the secrecy of the implementation of security to prevent vulnerabilities.

• Examples:– Hiding the source code for a cryptographic

algorithm– Using alternate ports for network services

48

6. Keep Security Simple• Complicated systems and

implementations can be misunderstood, resulting in bugs that expose vulnerabilities

• Break security functions and features into discrete objectives:1. Keep services running and information away

from attackers.2. Allow the right users access to the right

information.3. Defend every layer as if it were the last layer of

defense.4. Keep a record of all attempts to access

information.5. Compartmentalize and isolate resources.

49

7. Detect Intrusions• Log all security-relevant information

– Log everything you will need to identify the problem and the perpetrator

– MITRE has created a standard for logging:Common Event Expression (CEE) for Event Interoperabilityhttp://cee.mitre.org/

• Monitor logs regularly• Respond to intrusions

– Don't give the attacker a second chance50

8. Don't Trust Infrastructure

• The underlying system and environment where your application resides may change.

• Check all input and all requests for validity.

51

9. Don't Trust Services

• Services provided by third-parties should not be trusted.

• You have no control over their security policies and procedures.

• They may subcontract to someone else.

52

10. Establish Secure Defaults

• Every application should be secure as it is initially installed "out of the box".

• Allow users to relax security if they wish, but the default setting should be maximum security.

53

Software Security Maturity Models

• Security is a function of all the practices of an organization

• Open Software Assurance Maturity Model (OSAMM)http://www.opensamm.org/

• Build Security In Maturity Model (BSIMM)http://bsimm.com/

Week 9 54

BSIMM Touchpoints

55

Touchpoints (1 of 2)

• Abuse Cases– Use cases where an attacker is one of the

actors• Security Requirements

– Specified requirements to protect information, ensure accuracy, etc.

• Risk Analysis– (today's lecture)

• Risk-Based Security Tests– Thinking like an attacker in creating system

testsWeek 9 56

Touchpoints (2 of 2)

• Code Review– Manual code inspection– Static analysis tools

• Penetration Testing– Attempting to break into the system using

hacker's tools• Security Operations

– Installation and account creation– Logging and monitoring

Week 9 57