SSW 540 Foundations of Software Engineering Week 9 Risk 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 93

Risk Identification Consider top causes of project failure Use a risk item checklist Week 94

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 913

14 Risk Estimation 1.List all possible risks 2.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 Low Impact Moderate Impact High Impact Low Probability Moderate Probability High Probability Criticality 1 Criticality 2 Criticality 3 Criticality 4 Criticality 5 Criticality 6 Yellow Green 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 risks 4.Threat ranking: estimate damage of risks 5.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 920

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: 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 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 CWEs 1.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 decision 7.CWE-22: Improper limitation of a pathname to a restricted directory ("Path traversal") 8.CWE-434: Unrestricted upload of file with dangerous type 9.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 credentials 12.CWE-805: Buffer access with incorrect length value 13.CWE-98: Improper control of filename for Include/Require statement in PHP program ("PHP File Inclusion") 14.CWE-129: Improper validation of array index 15.CWE-754: Improper check for unusual or exceptional conditions 16.CWE-209: Information exposure through an error message 17.CWE-190: Integer overflow or wraparound 18.CWE-131: Incorrect calculation of buffer size 19.CWE-306: Missing authentication for critical functions 20.CWE-494: Download of code without integrity check 21.CWE-732: Incorrect permission assignment for critical resource 22.CWE-770: Allocation of resources without limits or throttling 23.CWE-601: URL redirection to site ("Open Redirect") 24.CWE-327: Use of a broken or risky cryptographic algorithm 25.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 vulnerability 1.Attacker injects code as input to some command 2.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 , 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 Perimeter Security 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 Surface Attack 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 application 32

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 cor porate 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 services 35

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) / 5 yields 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 940

Adopt Best Security Practices OWASP Best Practices Build Security In website: cert.gov/bsi/articles/knowledge/principles.html Adopt a Security Maturity Model Week 941

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 depth 2.Use a positive security model 3.Fail securely 4.Run with least privilege 5.Avoid security by obscurity 6.Keep security simple 7.Detect intrusions 8.Don't trust infrastructure 9.Don't trust services 10.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 Interoperability Monitor logs regularly Respond to intrusions –Don't give the attacker a second chance 50

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) Build Security In Maturity Model (BSIMM) Week 954

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 tests Week 956

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 957