SSW 540 Foundations of Software Engineering Week 9 Risk Management and Software Assurance

1. SSW 540 Foundations of Software Engineering Week 9 Risk Management andSoftware Assurance

2. 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

3. Rick Management • Risk Assessment • Risk Identification • Risk Analysis • Risk Prioritization • Risk Mitigation • Risk Management Planning • Risk Resolution • Risk Monitoring Week 9

4. Risk Identification • Consider top causes of project failure • Use a risk item checklist Week 9

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?

13. Risk Analysis Risk Exposure = Probability of occurrence * Expected loss Overly optimistic schedule example: 50% * 5 weeks = 2.5 weeks exposure Week 9

14. Risk Estimation • List all possible risks • Assign a probability to each (low, medium, high) • Assign an impact to each (low, medium, high) • Sort by probability and impact

15. Sorted Risks High Probability Yellow Red Red Criticality 2 Criticality 1 Criticality 4 Moderate Probability Green Red Yellow Criticality 3 Criticality 2 Criticality 5 Low Probability Green Green Yellow Criticality 6 Criticality 5 Criticality 4 High Impact Moderate Impact Low Impact

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

17. 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

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

19. Software Assurance Risk Management Functional decomposition: to define the attack surface Attacker categorization: identify possible attackers Threat categorization: identify risks Threat ranking: estimate damage of risks Mitigation planning: formulate plans to avoid or lessen the impact of risks

20. 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

21. 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"

22. 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/

23. 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

24. 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

25. The List of Top 25 CWEs CWE-79: Failure to preserve web page structure ("Cross-Site Scripting") CWE-89: Improper sanitization of special elements used in an SQL command ("SQL Injection") CWE-120: Buffer copy without checking size of input ("Classic buffer overflow") CWE 352: Cross-site request forgery (CSRF) CWE-285: Improper access control (Authorization) CWE-807: Reliance on un-trusted inputs in a security decision CWE-22: Improper limitation of a pathname to a restricted directory ("Path traversal") CWE-434: Unrestricted upload of file with dangerous type CWE-78: Improper sanitization of special elements used in an OS command ("OS Command Injection") CWE-311: Missing encryption of sensitive data CWE-798: Use of hard-coded credentials CWE-805: Buffer access with incorrect length value CWE-98: Improper control of filename for Include/Require statement in PHP program ("PHP File Inclusion") CWE-129: Improper validation of array index CWE-754: Improper check for unusual or exceptional conditions CWE-209: Information exposure through an error message CWE-190: Integer overflow or wraparound CWE-131: Incorrect calculation of buffer size CWE-306: Missing authentication for critical functions CWE-494: Download of code without integrity check CWE-732: Incorrect permission assignment for critical resource CWE-770: Allocation of resources without limits or throttling CWE-601: URL redirection to site ("Open Redirect") CWE-327: Use of a broken or risky cryptographic algorithm CWE-362: Race condition

26. 1. CWE-79: Failure to preserve web page structure ("Cross-Site Scripting") • Cross-site scripting (XSS) is the most common publicly-reported security vulnerability • Attacker injects code as input to some command • Command does not adequately check or sanitize its input, passing it back to the browser as part of the command result. • Result is the execution of the injected code by they browser • Error is failure to prevent user input from propagating through the command

27. Cross-Site Scripting (XSS) Consider the following scenario (from Wikipedia): Alice often visits Bob's website, where she logs in with a username/password pair and stores sensitive data. Mallory observes that Bob's website contains a reflected XSS vulnerability. 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. Alice visits the URL provided by Mallory while logged into Bob's website. 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).

28. 2. CWE-89: Improper sanitization of special elements used in an SQL command ("SQL Injection") Similar to XSS, attacker places something in the input to a command that is passed to a SQL query When the SQL query runs it does more than was originally intended by the programmer The attacker uses the result to steal information or corrupt data Error is failure to check or sanitize input

29. SQL Injection Example • 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. • The attacker provides a userName: '' or '1'='1' • The resulting command is: SELECT * FROM users WHERE name = '' OR '1'='1' • The command will retrieve all user records.

30. 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.

31. 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

32. 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

33. 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

34. 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.

35. 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

36. 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?

37. Calculating DREAD Estimate (1/3) Risk = (D + R + E + A + D) / 5where: 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.

38. 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

39. 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

40. 5. Mitigation Planning • Reduce likelihood • improve authentication mechanisms • close user sessions more often • Reduce impact • encrypt data • increase logging and monitoring Week 9

41. 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

42. 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)

43. OWASP Best Practices forSoftware Development • Apply defense in depth • Use a positive security model • Fail securely • Run with least privilege • Avoid security by obscurity • Keep security simple • Detect intrusions • Don't trust infrastructure • Don't trust services • Establish secure defaults

44. 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

45. 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

46. 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

47. 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

48. 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

49. 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: • Keep services running and information away from attackers. • Allow the right users access to the right information. • Defend every layer as if it were the last layer of defense. • Keep a record of all attempts to access information. • Compartmentalize and isolate resources.

50. 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 chance