Secure Software Design with UML

1. Secure SoftwareDesign with UML Secure UML: Requirements System Architecture/Design Test

2. Acknowledgments References are provided per page. Most diagrams are original, but ideas are adapted from references. Author: Susan J Lincke, PhD Univ. of Wisconsin-Parkside Contributors/Reviewers: Tim Knautz, Janine Spears PhD, David Green PhD, Megan Reid Funded by National Science Foundation (NSF) Course, Curriculum and Laboratory Improvement (CCLI) grant 0837574: Information Security: Audit, Case Study, and Service Learning. Any opinions, findings, and conclusions or recommendations expressed in this material are those of the author(s) and/or source(s) and do not necessarily reflect the views of the National Science Foundation.

3. Security Assures … CIA Confidentiality: Limits access of authorized users and prevents access to unauthorized users Integrity: The reliability of information resources and data have not been changed inappropriately Availability: When something needs to be accessed by the user, it is available

4. Security Vocabulary Asset: Diamonds Threat: Theft Vulnerability: Open door or windows Threat agent: Burglar Owner: Those accountable or who value the asset Risk: Danger to assets

5. Registration System Use Case Register: Clients register to obtain documentation by providing name, email, job function Provider: Send periodic updates to Clients to indicate changes in materials

6. OCTAVE Security Requirements Process Risk: Threat and vulnerability(s) -> negative impact Identify critical assets Define security goals Identify threats Analyze risks Define security requirements

7. Step 1. Identify Critical Assetsvia Business Process Diagram • Contact Info: Name, email, job function • Materials: Course materials • Comments: Feedback, saved & sent as email

8. Step 2. Define Security Goals Impact Rating: * Low Priority ** Medium Priority *** High Priority

9. Step 3: Identify Threats What it isSoftware TechniquesAdvanced Security STRIDE General Threats

10. Step 3. Identify Threatsvia Misuse Case Diagram Which misuse cases relate to: Confidentiality? Integrity? Availability? Definitions: DOS = Denial of Service misuser Misuse case

11. Step 3 (cont’d):Expand DOS Misuse Case Overflow DB: Fill disk with records Send Continual Requests: (Distributed Denial of Service) No processor remains

12. Step 3 (optional)Threat Tree

13. Step 3 cont’d: Lightweight Misuse Case:Change Valid Data

14. Step 3 Cont’d: Mid-weight Misuse CaseDOS

15. Step 3 Cont’d: Mid-weight Misuse Case:Circumvent Input

16. Step 4: Analyze Risks

17. Step 5: Define Security Requirements Definitions

18. Stage 5: Define Security RequirementsModify Register Use Case Desc.

19. Stage 5: Define Security Requirements:Validate Registration Security Use Case

20. Business Process Diagram Enhancement Loc Loc Local Access AD AD Attack Detection Pr Pr Privacy

21. Secure UML Secure Design

22. Mis-Sequence Diagram

23. State Diagram State Diagrams can ensure software: • Retains proper order of processing • Recognizes out-of-sequence steps • Can change behavior based on time or past history

24. Documenting Security Packages Sanitizer <<Security Package>> Sanitize Input <<Risk Factor>> 9 <<Security Descriptor>> Injection Attack Defense Registration <<protects>> CAPTCHA <<Security Package>> <<Risk Factor>> 9 <<Security Descriptor>> DOS Defense <<Security Descriptor>> 3rd Party S/W

25. Open Group’s Common Data Security Architecture

26. Security Diagrams:Security Patterns Authenticator Pattern Authorization Pattern

27. Misuse Deployment Diagram • Shows attacks/defenses • Shows where attacks are handled • Useful for: • Security Planning • Audit • Test - QC • S/W Development

28. Secure UML Secure Test

29. BugBar

30. When to Release Software? Attack Surface Bug Bar Security threshold that must be achieved for release • Knight: suit of armor protects attack surface by covering most of his body • Software: where are (new) vulnerabilities that are not mitigated?

31. Testing Software Testing = Software works as it should Vulnerability Testing = Automated testing checks for holes Penetration Testing = Probes security risks addressing threats to policy Reliability testing: Can s/w survive unusual conditions: faults or unusual operating conditions?

32. Software Testing • Static Testing: Analyzes code (not execution) for potential bugs: warnings • May be an option on a compiler • Fuzz Testing: generates random input to test exceptions, incorrect input

33. Vulnerability Testing Buffer Overflow: Can long input affect service? Script Injection: Can input with scripts execute? Numeric Overflow: Can a large number become a negative or small number? Race Condition: Can multiple threads cause errors? Configuration Issues: Can software be installed improperly, causing abuse? Programmer Backdoors: Have programmers left hooks providing entry or information?

34. Mature Software Practices

35. Agile Development • Security training is important! • Include Evil User Stories in every Sprint • "As a hacker, I send bad data in forms, so I can modify the database in unauthorized ways." • Analyze risk at start of sprint, backlog change • Address Security features • authentication, access control, input validation, output encoding, error/exception handling, encryption, data integrity, logging and alarms, and data communication security • Review code for security • Test using code analyzers, fuzz testing, auto/manual penetration tests

36. Security Requirements Jamie Ramon MD Doctor Chris Ramon RD Dietician Terry Medical Admin Pat Software Consultant Health First Case Study

37. Step 1: Identify Critical Assets All of this information is protected by HIPAA HIPAA=Health Insurance Portability and Accountability Act HIPAA protects: Confidentiality: In transmission, on disk, or any other form. Integrity: All transactions are logged as to who did them and why. Hashing (sophisticated checksums) are also required.

38. Step 2: Define security goals Impact Rating: * Low Priority ** Medium Priority *** High Priority

39. Step 2: Define security goals Impact Rating: * Low Priority ** Medium Priority *** High Priority

40. Step 3: Identify Threats Use Case Diagram Medical Admin use cases include: • Make appointment: Patient may phone for an appt. • Create Patient Record To make an appt, a minimal patient record must exist or be created • Register for Appointment: When the patient arrives for his/her appt. • Update Patient: Update patient medical history • Determine Health Plan Eligibility: Ask HMO/PPO what the patient is eligible for in coverage – and conditions

41. Step 3: Identify Threats What it isSoftware TechniquesAdvanced Security STRIDE General Threats

42. Security Requirements Process OCTAVE Security Requirements Process • Identify critical assets • Define security goals • Identify threats • Draw Misuse Diagram from Use Case Diagram • Analyze risks: • Priority = Impact * Likelihood • Define security requirements • Draw Misuse Diagram with Security Use Cases • Define one Misuse Description (Lightweight or Midweight)