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