CSSE 477 – Intro to Security

1. CSSE 477 – Intro to Security 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. Background – From http://brooknovak.wordpress.com/2009/07/28/webkit-clipboard-security-hole/

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

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? • What is Security “about” – Ch 4? • What are some good tactics – Ch 5?

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

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