Developing Secure Software

1. Developing Secure Software Secure UML Security Planning Susan Lincke

2. Objectives The Student shall be able to: Define command injection, cross-site scripting, cross-site request forgery. Draw a Misuse Case Diagram and Security Use Case Diagram Prepare a Misuse Case Description and Security Use Case Description Define the five steps of the OCTAVE security requirements process Describe the functionality of a Missequence diagram, Misuse Deployment Diagram, state diagram Describe how and why each of the following coding recommendations are important: sanitize input and output; never expose internal data structures; minimize access; use tried and true security algorithms; validate and control the configuration; and manage exceptions. Define BugBar, fuzz testing, reliability testing, sandbox, vulnerability scanner, web spider.

3. Security Assures … CIA (Review) 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 (Review) 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 Diagram 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 Diagram 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: Intro to Misuse Case Description:Change Valid Data

14. Step 3 Cont’d: Light-weight Misuse Case DescriptionDOS

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

16. Step 4: Analyze Risks

17. Step 5: Define Security Requirementsusing Security Use Case Diagram Definitions

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

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

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 Programming& Secure Test

29. Coding Safeguards Sanitize input & output Overflows: strings, buffers, integers, float Suspect input: parameters or arguments, cookies, network packets, environment variables, client request data, query/server results, URL components, e-mail, files and databases Never expose internal data structures: Protect database keys, object references or IDs, file references Structures may be modified to access other data

30. Coding Safeguards Cont’d Minimize access: Permissions: Only provide higher level access for shortest possible time Resources: Keep resources such as files, devices and communications open for the shortest time possible Jail: OS can impose resource limits on programs: I/O, disk, network, files Caching: Sensitive pages are not cached, use an active authorization token Use tried & true security algorithms Open Design uses algorithms created/shared by many users to withstand the test of time Critical algorithms include: input sanitization, encryption, integrity, authentication, authorization, session management, logging, random number generators Nonce: an active authorization ticket that restricts the time auser may respond Do not trust 3rd party software without good inspection!

31. Coding Safeguards, Cont’d Validate & control the configuration Programs often require files to run properly: configuration or environmental files. If an attacker changes them, a program can operate improperly To safeguard: Store files in a location that prevents access to users. Use the full pathname to access the file Validate that the file does indeed have the required minimal access permissions. If your program is on a website, establish certain paths with restricted outside access Never hardcode configurations since the attacker can reverse engineer code.

32. Coding Safeguards, Cont’d Manage exceptions The programmer can abort, continue or commit after an exception recovery is preferable recover at lower levels is best, where the specific condition is known. automatic exception handling is preferred Mission critical function requires recovery or manual intervention Use Safe Coding Practices Static analysis tools inspect code without execution Provides warnings beyond what a compiler normally provides. e.g., variable or environment contents not initialized, possibly leaking previous data Fix all warnings Error messages should be helpful to the user, but not too explicit. Chatty error message: “Cannot find file: C:/users/Lincke/validation.txt” Error messages should avoid file, network configuration and personal info Remove debug information before release.

33. Test Tools Fuzz and robustness testing generate a large number of inputs to find subtle flaws Fuzz testinggenerates random input to test exception handling and input validation Reliability testingensures software can survive unusual conditions, e.g., faults or unusual operating conditions. For mission critical code, functions shall not fail; failure rate must be known. Vulnerability scannerstest for web attacks: integer, float or string overflows, SQL injection and cross-site scripting Web spidersparse website(s) to find embedded links Follows all links recursively to determine full connectivity of a website. Finds cross-site scriptingin websites Manual penetration tests are tailored for specific applications Proxies and vulnerability scanners allow dynamic packet creation.

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

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

36. BugBar

37. Mature Software Practices

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

39. Summary Building Security Into Software Designers and developers are trained in standard security practices Security requirements are decided based on risk analysis and regulatory compliance High priority risks are mitigated and included in the schedule. Secure designs ensure that the architecture is effective and efficient When code is written, secure utilities are familiar to the coders and correctly used the first time. Knowledgeable testers perform competent penetration testing and use automated test tools for faster, more accurate testing. The code may still be released before all bugs are fixed, but the organization knows and approves of any security flaws that remain.

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

41. Step 1: Identify Critical Assets All of this information is protected by HIPAA 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.

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

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

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

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

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