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. Objectives The student shall be able to: Define the 5 OCTAVE security requirements process Draw a misuse case diagram with and without security use cases.

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

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

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

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

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

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

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

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

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

13. Step 3 (optional)Threat Tree

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

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

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

17. Step 4: Analyze Risks

18. Step 5: Define Security Requirements Definitions

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

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

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

22. Secure UML Secure Design

23. Mis-Sequence Diagram

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

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

26. Security Diagrams:Security Patterns Authenticator Pattern Authorization Pattern

27. Secure UML Secure Test

28. Testing Software Testing = Software works as it should Penetration Testing = Probes security risks addressing threats to policy

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

30. Vulnerability Inspection Diagram (VID) • Activity Diagram used for testing • Models procedural instructions • Automated testing from Activity Diagram possible

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

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

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

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

35. Step 3: Identify Threats Use Case Diagram Use Cases: Ovals representing the functions that users will need to perform Medical Admin use cases include: • Make appointment • Create Patient Record (To make an appointment, a minimal patient record must exist – or be created) • Update Patient (for subsequent visits) • Determine Health Plan Eligibility: Ask HMO/PPO what the patient is eligible for in coverage – and conditions

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

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