1 / 39

Secure Software Design with UML

Secure Software Design with UML. Secure UML: Requirements System Architecture/Design Test. 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

abrianna
Download Presentation

Secure Software Design with UML

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  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. Security Diagrams:Security Patterns Authenticator Pattern Authorization Pattern

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

  27. Secure UML Secure Test

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

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

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

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

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

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

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

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

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

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

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

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

More Related