ssw 540 foundations of software engineering week 9 risk management and software assurance
DESCRIPTION
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 - PowerPoint PPT PresentationTRANSCRIPT
![Page 1: SSW 540 Foundations of Software Engineering Week 9 Risk Management and Software Assurance](https://reader036.vdocuments.site/reader036/viewer/2022062316/5681673d550346895ddbeec9/html5/thumbnails/1.jpg)
SSW 540
Foundations of Software Engineering
Week 9Risk Management and
Software Assurance
![Page 2: SSW 540 Foundations of Software Engineering Week 9 Risk Management and Software Assurance](https://reader036.vdocuments.site/reader036/viewer/2022062316/5681673d550346895ddbeec9/html5/thumbnails/2.jpg)
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
![Page 3: SSW 540 Foundations of Software Engineering Week 9 Risk Management and Software Assurance](https://reader036.vdocuments.site/reader036/viewer/2022062316/5681673d550346895ddbeec9/html5/thumbnails/3.jpg)
Rick Management
• Risk Assessment– Risk Identification– Risk Analysis– Risk Prioritization
• Risk Mitigation– Risk Management Planning– Risk Resolution– Risk Monitoring
Week 9 3
![Page 4: SSW 540 Foundations of Software Engineering Week 9 Risk Management and Software Assurance](https://reader036.vdocuments.site/reader036/viewer/2022062316/5681673d550346895ddbeec9/html5/thumbnails/4.jpg)
Risk Identification
• Consider top causes of project failure• Use a risk item checklist
Week 9 4
![Page 5: SSW 540 Foundations of Software Engineering Week 9 Risk Management and Software Assurance](https://reader036.vdocuments.site/reader036/viewer/2022062316/5681673d550346895ddbeec9/html5/thumbnails/5.jpg)
5
Risk Item Checklists
• Product Size• Business Impact• Customer-related• Process• Technology• Development Environment• Staff Size and Experience
![Page 6: SSW 540 Foundations of Software Engineering Week 9 Risk Management and Software Assurance](https://reader036.vdocuments.site/reader036/viewer/2022062316/5681673d550346895ddbeec9/html5/thumbnails/6.jpg)
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?
![Page 7: SSW 540 Foundations of Software Engineering Week 9 Risk Management and Software Assurance](https://reader036.vdocuments.site/reader036/viewer/2022062316/5681673d550346895ddbeec9/html5/thumbnails/7.jpg)
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?
![Page 8: SSW 540 Foundations of Software Engineering Week 9 Risk Management and Software Assurance](https://reader036.vdocuments.site/reader036/viewer/2022062316/5681673d550346895ddbeec9/html5/thumbnails/8.jpg)
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?
![Page 9: SSW 540 Foundations of Software Engineering Week 9 Risk Management and Software Assurance](https://reader036.vdocuments.site/reader036/viewer/2022062316/5681673d550346895ddbeec9/html5/thumbnails/9.jpg)
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?
![Page 10: SSW 540 Foundations of Software Engineering Week 9 Risk Management and Software Assurance](https://reader036.vdocuments.site/reader036/viewer/2022062316/5681673d550346895ddbeec9/html5/thumbnails/10.jpg)
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?
![Page 11: SSW 540 Foundations of Software Engineering Week 9 Risk Management and Software Assurance](https://reader036.vdocuments.site/reader036/viewer/2022062316/5681673d550346895ddbeec9/html5/thumbnails/11.jpg)
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?
![Page 12: SSW 540 Foundations of Software Engineering Week 9 Risk Management and Software Assurance](https://reader036.vdocuments.site/reader036/viewer/2022062316/5681673d550346895ddbeec9/html5/thumbnails/12.jpg)
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?
![Page 13: SSW 540 Foundations of Software Engineering Week 9 Risk Management and Software Assurance](https://reader036.vdocuments.site/reader036/viewer/2022062316/5681673d550346895ddbeec9/html5/thumbnails/13.jpg)
Risk Analysis
Risk Exposure =Probability of occurrence * Expected loss
Overly optimistic schedule example:50% * 5 weeks = 2.5 weeks exposure
Week 9 13
![Page 14: SSW 540 Foundations of Software Engineering Week 9 Risk Management and Software Assurance](https://reader036.vdocuments.site/reader036/viewer/2022062316/5681673d550346895ddbeec9/html5/thumbnails/14.jpg)
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
![Page 15: SSW 540 Foundations of Software Engineering Week 9 Risk Management and Software Assurance](https://reader036.vdocuments.site/reader036/viewer/2022062316/5681673d550346895ddbeec9/html5/thumbnails/15.jpg)
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
![Page 16: SSW 540 Foundations of Software Engineering Week 9 Risk Management and Software Assurance](https://reader036.vdocuments.site/reader036/viewer/2022062316/5681673d550346895ddbeec9/html5/thumbnails/16.jpg)
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
![Page 17: SSW 540 Foundations of Software Engineering Week 9 Risk Management and Software Assurance](https://reader036.vdocuments.site/reader036/viewer/2022062316/5681673d550346895ddbeec9/html5/thumbnails/17.jpg)
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
![Page 18: SSW 540 Foundations of Software Engineering Week 9 Risk Management and Software Assurance](https://reader036.vdocuments.site/reader036/viewer/2022062316/5681673d550346895ddbeec9/html5/thumbnails/18.jpg)
18
Risk Monitoring
• Keep Top-10 Risks List• Conduct Interim Retrospectives• Assign Role of Risk Monitor
![Page 19: SSW 540 Foundations of Software Engineering Week 9 Risk Management and Software Assurance](https://reader036.vdocuments.site/reader036/viewer/2022062316/5681673d550346895ddbeec9/html5/thumbnails/19.jpg)
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
![Page 20: SSW 540 Foundations of Software Engineering Week 9 Risk Management and Software Assurance](https://reader036.vdocuments.site/reader036/viewer/2022062316/5681673d550346895ddbeec9/html5/thumbnails/20.jpg)
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
![Page 21: SSW 540 Foundations of Software Engineering Week 9 Risk Management and Software Assurance](https://reader036.vdocuments.site/reader036/viewer/2022062316/5681673d550346895ddbeec9/html5/thumbnails/21.jpg)
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
![Page 22: SSW 540 Foundations of Software Engineering Week 9 Risk Management and Software Assurance](https://reader036.vdocuments.site/reader036/viewer/2022062316/5681673d550346895ddbeec9/html5/thumbnails/22.jpg)
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
![Page 23: SSW 540 Foundations of Software Engineering Week 9 Risk Management and Software Assurance](https://reader036.vdocuments.site/reader036/viewer/2022062316/5681673d550346895ddbeec9/html5/thumbnails/23.jpg)
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
![Page 24: SSW 540 Foundations of Software Engineering Week 9 Risk Management and Software Assurance](https://reader036.vdocuments.site/reader036/viewer/2022062316/5681673d550346895ddbeec9/html5/thumbnails/24.jpg)
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
![Page 25: SSW 540 Foundations of Software Engineering Week 9 Risk Management and Software Assurance](https://reader036.vdocuments.site/reader036/viewer/2022062316/5681673d550346895ddbeec9/html5/thumbnails/25.jpg)
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
![Page 26: SSW 540 Foundations of Software Engineering Week 9 Risk Management and Software Assurance](https://reader036.vdocuments.site/reader036/viewer/2022062316/5681673d550346895ddbeec9/html5/thumbnails/26.jpg)
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
![Page 27: SSW 540 Foundations of Software Engineering Week 9 Risk Management and Software Assurance](https://reader036.vdocuments.site/reader036/viewer/2022062316/5681673d550346895ddbeec9/html5/thumbnails/27.jpg)
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
![Page 28: SSW 540 Foundations of Software Engineering Week 9 Risk Management and Software Assurance](https://reader036.vdocuments.site/reader036/viewer/2022062316/5681673d550346895ddbeec9/html5/thumbnails/28.jpg)
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
![Page 29: SSW 540 Foundations of Software Engineering Week 9 Risk Management and Software Assurance](https://reader036.vdocuments.site/reader036/viewer/2022062316/5681673d550346895ddbeec9/html5/thumbnails/29.jpg)
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
![Page 30: SSW 540 Foundations of Software Engineering Week 9 Risk Management and Software Assurance](https://reader036.vdocuments.site/reader036/viewer/2022062316/5681673d550346895ddbeec9/html5/thumbnails/30.jpg)
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
![Page 31: SSW 540 Foundations of Software Engineering Week 9 Risk Management and Software Assurance](https://reader036.vdocuments.site/reader036/viewer/2022062316/5681673d550346895ddbeec9/html5/thumbnails/31.jpg)
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
![Page 32: SSW 540 Foundations of Software Engineering Week 9 Risk Management and Software Assurance](https://reader036.vdocuments.site/reader036/viewer/2022062316/5681673d550346895ddbeec9/html5/thumbnails/32.jpg)
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
![Page 33: SSW 540 Foundations of Software Engineering Week 9 Risk Management and Software Assurance](https://reader036.vdocuments.site/reader036/viewer/2022062316/5681673d550346895ddbeec9/html5/thumbnails/33.jpg)
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
![Page 34: SSW 540 Foundations of Software Engineering Week 9 Risk Management and Software Assurance](https://reader036.vdocuments.site/reader036/viewer/2022062316/5681673d550346895ddbeec9/html5/thumbnails/34.jpg)
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
![Page 35: SSW 540 Foundations of Software Engineering Week 9 Risk Management and Software Assurance](https://reader036.vdocuments.site/reader036/viewer/2022062316/5681673d550346895ddbeec9/html5/thumbnails/35.jpg)
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
![Page 36: SSW 540 Foundations of Software Engineering Week 9 Risk Management and Software Assurance](https://reader036.vdocuments.site/reader036/viewer/2022062316/5681673d550346895ddbeec9/html5/thumbnails/36.jpg)
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
![Page 37: SSW 540 Foundations of Software Engineering Week 9 Risk Management and Software Assurance](https://reader036.vdocuments.site/reader036/viewer/2022062316/5681673d550346895ddbeec9/html5/thumbnails/37.jpg)
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
![Page 38: SSW 540 Foundations of Software Engineering Week 9 Risk Management and Software Assurance](https://reader036.vdocuments.site/reader036/viewer/2022062316/5681673d550346895ddbeec9/html5/thumbnails/38.jpg)
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
![Page 39: SSW 540 Foundations of Software Engineering Week 9 Risk Management and Software Assurance](https://reader036.vdocuments.site/reader036/viewer/2022062316/5681673d550346895ddbeec9/html5/thumbnails/39.jpg)
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
![Page 40: SSW 540 Foundations of Software Engineering Week 9 Risk Management and Software Assurance](https://reader036.vdocuments.site/reader036/viewer/2022062316/5681673d550346895ddbeec9/html5/thumbnails/40.jpg)
5. Mitigation Planning
• Reduce likelihood– improve authentication mechanisms– close user sessions more often
• Reduce impact– encrypt data– increase logging and monitoring
Week 9 40
![Page 41: SSW 540 Foundations of Software Engineering Week 9 Risk Management and Software Assurance](https://reader036.vdocuments.site/reader036/viewer/2022062316/5681673d550346895ddbeec9/html5/thumbnails/41.jpg)
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
![Page 42: SSW 540 Foundations of Software Engineering Week 9 Risk Management and Software Assurance](https://reader036.vdocuments.site/reader036/viewer/2022062316/5681673d550346895ddbeec9/html5/thumbnails/42.jpg)
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
![Page 43: SSW 540 Foundations of Software Engineering Week 9 Risk Management and Software Assurance](https://reader036.vdocuments.site/reader036/viewer/2022062316/5681673d550346895ddbeec9/html5/thumbnails/43.jpg)
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
![Page 44: SSW 540 Foundations of Software Engineering Week 9 Risk Management and Software Assurance](https://reader036.vdocuments.site/reader036/viewer/2022062316/5681673d550346895ddbeec9/html5/thumbnails/44.jpg)
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
![Page 45: SSW 540 Foundations of Software Engineering Week 9 Risk Management and Software Assurance](https://reader036.vdocuments.site/reader036/viewer/2022062316/5681673d550346895ddbeec9/html5/thumbnails/45.jpg)
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
![Page 46: SSW 540 Foundations of Software Engineering Week 9 Risk Management and Software Assurance](https://reader036.vdocuments.site/reader036/viewer/2022062316/5681673d550346895ddbeec9/html5/thumbnails/46.jpg)
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
![Page 47: SSW 540 Foundations of Software Engineering Week 9 Risk Management and Software Assurance](https://reader036.vdocuments.site/reader036/viewer/2022062316/5681673d550346895ddbeec9/html5/thumbnails/47.jpg)
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
![Page 48: SSW 540 Foundations of Software Engineering Week 9 Risk Management and Software Assurance](https://reader036.vdocuments.site/reader036/viewer/2022062316/5681673d550346895ddbeec9/html5/thumbnails/48.jpg)
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
![Page 49: SSW 540 Foundations of Software Engineering Week 9 Risk Management and Software Assurance](https://reader036.vdocuments.site/reader036/viewer/2022062316/5681673d550346895ddbeec9/html5/thumbnails/49.jpg)
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
![Page 50: SSW 540 Foundations of Software Engineering Week 9 Risk Management and Software Assurance](https://reader036.vdocuments.site/reader036/viewer/2022062316/5681673d550346895ddbeec9/html5/thumbnails/50.jpg)
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
![Page 51: SSW 540 Foundations of Software Engineering Week 9 Risk Management and Software Assurance](https://reader036.vdocuments.site/reader036/viewer/2022062316/5681673d550346895ddbeec9/html5/thumbnails/51.jpg)
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
![Page 52: SSW 540 Foundations of Software Engineering Week 9 Risk Management and Software Assurance](https://reader036.vdocuments.site/reader036/viewer/2022062316/5681673d550346895ddbeec9/html5/thumbnails/52.jpg)
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
![Page 53: SSW 540 Foundations of Software Engineering Week 9 Risk Management and Software Assurance](https://reader036.vdocuments.site/reader036/viewer/2022062316/5681673d550346895ddbeec9/html5/thumbnails/53.jpg)
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
![Page 54: SSW 540 Foundations of Software Engineering Week 9 Risk Management and Software Assurance](https://reader036.vdocuments.site/reader036/viewer/2022062316/5681673d550346895ddbeec9/html5/thumbnails/54.jpg)
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
![Page 55: SSW 540 Foundations of Software Engineering Week 9 Risk Management and Software Assurance](https://reader036.vdocuments.site/reader036/viewer/2022062316/5681673d550346895ddbeec9/html5/thumbnails/55.jpg)
BSIMM Touchpoints
55
![Page 56: SSW 540 Foundations of Software Engineering Week 9 Risk Management and Software Assurance](https://reader036.vdocuments.site/reader036/viewer/2022062316/5681673d550346895ddbeec9/html5/thumbnails/56.jpg)
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
![Page 57: SSW 540 Foundations of Software Engineering Week 9 Risk Management and Software Assurance](https://reader036.vdocuments.site/reader036/viewer/2022062316/5681673d550346895ddbeec9/html5/thumbnails/57.jpg)
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