1. 1 Steve Chenoweth Tuesday, 10/18/11 Week 7, Day 2 Right – One view of the layers of ingredients to an enterprise security program. From www.451group.com/security/451_security.php.www.451group.com/security/451_security.php Background – From http://brooknovak.wordpress.com/2009/07/28/webkit-clipboard-security- hole/ http://brooknovak.wordpress.com/2009/07/28/webkit-clipboard-security- hole/ CSSE 477 – Intro to Security

2. 2 Today How to do Project 5… Get ideas from “implementers” on “what should be more secure.” Software security – this  –SA Ch 4, pp 85-88 (Security scenarios) & Ch 5, pp. 116- 118 (Security tactics) –More in depth – take CSSE 442 Computer Security (usually taught in winter term – and many of you are signed up!). –Security also is discussed in these courses: CSSE 332 Operating Systems CSSE 432 Computer Networks CSSE 433 Advanced Database Systems

3. 3 Coming up… Today: Show testability results in class Project 5 (security) ideas turned in tonight Thursday: Discuss software product lines (cntd from CSSE 375 intro) Team time to work on the security project

4. 4 We next pick security from Bass’s QA list… Bass’s list of six, from the inside back cover of his book: –Availability –Modifiability –Performance –Security –Testability –Usability

5. 5 And here’s the project about it: On the project where you were designers, Use an arch tactic to make it more secure: –Determine what is not very secure in your current project system. –Implement a tactic to improve this by a predicted amount! We’re also going to continue our study of how to document the arch, so: –An added feature of this project – add the functional requirements, quality attribute and tactics sections (3 – 5) to your draft of that, for your sys. And a first step to take today: Try to think of a problem area in the security of your current system. (See “characteristics of a secure system,” slide 11.) Consult with your “implementers” to get additional ideas on problem areas. These also will be a “target” for making changes efficiently. Run through this area of your system as it exists now, and verify that it really is a problem. Document that in your journal. Make a “prediction” about how the system will be more secure, with the changes you plan to make. Turn in your ideas, that data on the “existing situation,” and your prediction, in your “team journal” by tonight 11:55 PM. Next step – Make the changes to security that will fix the problem.

6. 6 Everyone’s interested in security E.g., Federal Transit Administration, part of the US Dept of Transportation: From http://transit-safety.volpe.dot.gov/Security/SecurityInitiatives/DesignConsiderations/CD/sec9.htm.http://transit-safety.volpe.dot.gov/Security/SecurityInitiatives/DesignConsiderations/CD/sec9.htm

7. 7 What’s Bass say about this QA? Problem – Security is an architectural issue. If any part is not secure in some way, the whole system may be. Goal – Resist unauthorized usage while still providing its services to legitimate users. –Related goals like “nonrepudiation.” Motivation – With almost everything “online” from the WWW, they are all theoretically vulnerable. Scenarios – What’s in “The Notes” at the end of the supplementary spec template? supplementary spec template What is Security “about” – Ch 4? What are some good tactics – Ch 5?

8. 8 Bass’s security scenarios Source: user/system, identified? Stimulus: display info, change info, access services, deny services Artifact: services, data Environment: online/offline, connected? Response: logging, block access, notification Measure: time, probability of detection, recovery

9. 9 Example scenario Source: Correctly identified individual Stimulus: Tries to modify information Artifact: Data within the system Environment: Under normal operations Response: System maintains audit trail Response Measure: Correct data is restored within a day

10. 10 Security situations A runtime attribute, which might include any of these ingredients: Attack or threat Confidentiality Integrity Assurance Availability Ch 4 Above - System security patent art, from www.freepatentsonline.com/6965992.html. www.freepatentsonline.com/6965992.html

11. 11 Characteristics of a secure system Nonrepudiation –users can’t deny they did something Confidentiality –No unauthorized usage Integrity –Data and services delivered as intended Assurance –Parties are who they say they are Availability –Denial of service attacks won’t prevent services Auditing –System tracks activities so that they can be reconstructed Ch 4 – p. 86

12. 12 Tactics to achieve security Try one of these 3 Strategies: –Resisting attacks –Detecting attacks –Recovering from an attack See next slides for details on each  Ch 5

13. 13 Resisting Attacks Authenticate users –Verify who they are Authorize users –What can each class of users do? Maintain data confidentiality –Encryption, VPNs, SSLs Maintain integrity –Data redundancy, checksums, hash results Limit exposure –Allocate services to hosts so each has limits Limit access –Firewalls, DMZ’s

14. 14 Detecting and Recovering Intrusion detection system –Anomalous patterns Historical baseline decides this Filter packets according to types –Compare with known attacks Restoration –See availability tactics –Restoring “state” to pre-attack is critical Identification –Maintain audit trail Trace attacker’s actions Support nonrepudiation Provide system recovery Audit trails themselves are a common target!

15. 15 Project 5 – Security part Overall theme (of the security part of this project) – Pick an area where you want to improve security. Pick a strategy to improve it, using one of the above tactics, and verify with your implementers. They may have more ideas! The improvement can be in either of these three areas: –Resisting attacks –Detecting attacks –Recovering from an attack You can also look ahead at Friday’s lecture for more ideas! –E.g., Check for security issues at multiple levels, default to “threat” Try it “as-is” to verify the security problem. Document this. Make a “prediction” about how the system will be more secure, with the changes you plan to make. Make the change to improve security. Run the security tests again, with the change. Measure how well you achieved the goal. Report on the results.