Developing Secure Software Secure UML Security Planning Susan

Developing Secure Software Secure UML Security Planning Susan Lincke

Security Planning: An Applied Approach | 11/27/2020 | 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 Bug. Bar, fuzz testing, reliability testing, sandbox, vulnerability scanner, web spider.

Security Planning: An Applied Approach | 11/27/2020 | 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

Security Planning: An Applied Approach | 11/27/2020 | 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

Security Planning: An Applied Approach | 11/27/2020 | 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

Security Planning: An Applied Approach | 11/27/2020 | 6 OCTAVE Security Requirements Process Risk: Threat and vulnerability(s) -> negative impact 1. Identify critical assets 2. Define security goals 3. Identify threats 4. Analyze risks 5. Define security requirements

Security Planning: An Applied Approach | 11/27/2020 | 7 Step 1. Identify Critical Assets via Business Process Diagram Contact Info: Name, email, job function Materials: Course materials Comments: Feedback, saved & sent as email

Security Planning: An Applied Approach | 11/27/2020 | 8 Step 2. Define Security Goals Assets Confidentiality Integrity Availability Contact Info ** No PII maintained *** Require accurate list of interested persons * Weekly backup Materials * Public with login *** Accurate – tamper-proof ** 24/7 preferred Comments ** Confidential pref. *** Accurate – tamperproof * Weekly backup, email Impact Rating: * Low Priority ** Medium Priority *** High Priority

Security Planning: An Applied Approach | 11/27/2020 | 9 Step 3: Identify Threats What it is Spoof Identity STRIDE General Threats Software Techniques Advanced Security Assume identity Encrypt passwords Bypass protection No backdoor entry Secure Password Digital Certificate Sec. Awareness Tamper w. Data Modify data Repudiation Hide activities Info Disclosure Read data Denial of Service Unreliable execution, resource consumption Validate real user via CAPTCHA Test for Failures Firewall Intrusion Prevention System Elevation of Privilege Gain privileges Execute unauthorized cmds/code Take care with error messages Hide system files Require approval Access Control Segregation of Duties Validate input Stop buffer overruns Close unused resources Authentication Access Control Message Digest Require passwords Trans. Logging Log user transactions Digital Signature Encrypt data Encrypt packets Minimal permissions Encryption Authentication Secure Handling

Security Planning: An Applied Approach | 11/27/2020 | 10 Step 3. Identify Threats via Misuse Case Diagram Which misuse cases relate to: • Confidentiality? • Integrity? • Availability? Definitions: DOS = Denial of Service misuser Misuse case

Security Planning: An Applied Approach | 11/27/2020 | 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

Security Planning: An Applied Approach | 11/27/2020 | 12 Step 3 (optional) Threat Tree

Security Planning: An Applied Approach | 11/27/2020 | 13 Step 3 cont’d: Intro to Misuse Case Description: Change Valid Data User Intention User requests Reg. form Attacker enters form input but appends additional SQL commands System Response System provides form System processes input Security Threat SQL injection Obtain (client) list Change valid data

Security Planning: An Applied Approach | 11/27/2020 | 14 Step 3 Cont’d: Light-weight Misuse Case Description Launch DOS Misuse Case: Launch Denial of Service Summary: An attacker issues repeated Registrations, resulting in filling the database with fake data, and depleting system and file resources. Basic Path: 1. Do forever 2. The attacker requests a Registration form 3. The attacker sends random fake data in the form 4. Enddo Alternative Paths: AP 1. Repeat data is entered Mitigation Points: MP 1. At BP Step 2 -3 use CAPTCHA in Registration form to avoid bot attack. MP 2. At BP Step 3 validate data: no duplicates, data type matching

Security Planning: An Applied Approach | 11/27/2020 | 15 Step 3 Cont’d: Mid-weight Misuse Case Description: Circumvent Input Misuse Case: Circumvent Input Summary: Deviant Client bypasses registration by going directly to the download web page. Pre. Condition: Client does Google search and finds link to download web page OR obtains link reference from a colleague Basic Path: 1. Deviant. Client obtains web reference from Google or friend. 2. Deviant. Client uses web reference to download materials without registering. Mitigation Points: MP 1: Web page has no other web references. MP 2: Create dynamic web page with unique reference. This web page is accessible only if a key is provided during registration. Key expires in one week. Related Business Rule: Users must register to obtain materials. Mitigation Guarantee: MP 1 and MP 2 solves Google search problems. MP 2 could be used by friends for one week, which is acceptable.

Security Planning: An Applied Approach | 11/27/2020 | 16 Step 4: Analyze Risks Threat Impact Likelihood Priority = I*L DOS 7 5 35 SQL Attack (affects integrity, confidentiality) 10 8 80 Invalid Input 3 10 30 Circumvent input 3 5 30

Security Planning: An Applied Approach | 11/27/2020 | 17 Step 5: Define Security Requirements using Security Use Case Diagram Definitions

Security Planning: An Applied Approach | 11/27/2020 | 18 Stage 5: Define Security Requirements Register Client Use Case Desc. Use Case: Register Summary: Client registers to obtain access to download materials. Preconditions: Client is at Welcome Web Page Basic Path: 1. The client selects the Obtain Materials link. 2. The system asks the client for name, email address, job function, and CAPTCHA. 3. The client enters all three required information. 4. Include (Validate Registration) 5. The system displays the URL for the download materials. Alternative Path: AP 1. If an attack is detected, no URL is displayed. Postcondition: The client has access to the download materials. The database contains the client contact information.

Security Planning: An Applied Approach | 11/27/2020 | 19 Stage 5: Define Security Requirements: Validate Registration Security Use Case Descr. Security Use Case: Validate Registration Summary: This include validates a registration. Precondition: A name, email, job function, and Captcha are provided. Basic Path: 1. The user enters a name, email, and job function in Step 3 of Register 2. Do until valid CAPTCHA. 3. Rerequest form with new CAPTCHA 4. The system checks for valid characters, to prevent SQL injection. 5. The system checks for valid name, email and job function 6. If email is unique in database 7. Save record to database 8. The system returns success. Postconditions: The input has been checked for bot attempt, SQL attempt, and validity.

Security Planning: An Applied Approach | 11/27/2020 | 20 Business Process Diagram Enhancement Loc Local Access AD AD Attack Detection Pr Pr Privacy

Security Planning: An Applied Approach | 11/27/2020 | 21 Secure UML SECURE DESIGN

Security Planning: An Applied Approach | 11/27/2020 | 22 Mis-Sequence Diagram

Security Planning: An Applied Approach | 11/27/2020 | 23 State Diagrams can ensure software: Retains proper order of processing Recognizes out-of-sequence steps Can change behavior based on time or past history

Security Planning: An Applied Approach | 11/27/2020 | 24 Documenting Security Packages Sanitizer Registration <<Security Package>> Sanitize Input <<Risk Factor>> 9 <<Security Descriptor>> Injection Attack Defense <<protects>> CAPTCHA <<Security Package>> <<Risk Factor>> 9 <<Security Descriptor>> DOS Defense <<Security Descriptor>> 3 rd Party S/W

Security Planning: An Applied Approach | 11/27/2020 | 25 Open Group’s Common Data Security Architecture Application Common Security Services Manager Application Programming Interface System Security Services (Digital Certificate, key management, integrity services, security contexts) Cryptographic Services Mgr. CS Library Trust Policy Services Mgr. Trust Library Authorization Certificate Computation Library Mgr. AC Library Cert. Library Data Storage Library Mgr. DS Library Elective Module Mgr New Services Lib.

Security Planning: An Applied Approach | 11/27/2020 | 26 Security Diagrams: Security Patterns Authenticator Pattern Authorization Pattern

Security Planning: An Applied Approach | 11/27/2020 | 27 Misuse Deployment Diagram Shows attacks/defenses Shows where attacks are handled Useful for: • Security Planning • Audit • Test - QC • S/W Development

Security Planning: An Applied Approach | 11/27/2020 | 28 Confidentiality Integrity Secure UML SECURE PROGRAMMING & SECURE TEST Availability

Security Planning: An Applied Approach | 11/27/2020 | 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

Security Planning: An Applied Approach | 11/27/2020 | 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 a user may respond Do not trust 3 rd party software without good inspection!

Security Planning: An Applied Approach | 11/27/2020 | 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.

Security Planning: An Applied Approach | 11/27/2020 | 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.

Security Planning: An Applied Approach | 11/27/2020 | 33 Test Tools Fuzz and robustness testing generate a large number of inputs to find subtle flaws Fuzz testing generates random input to test exception handling and input validation Reliability testing ensures 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 scanners test for web attacks: integer, float or string overflows, SQL injection and cross-site scripting Web spiders parse website(s) to find embedded links • Follows all links recursively to determine full connectivity of a website. • Finds cross-site scripting in websites Manual penetration tests are tailored for specific applications • Proxies and vulnerability scanners allow dynamic packet creation.

Security Planning: An Applied Approach | 11/27/2020 | 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?

Security Planning: An Applied Approach | 11/27/2020 | 35 When to Release Software? Attack Surface Bug Bar Knight: suit of armor protects Security threshold that must be attack surface by covering most achieved for release of his body Software: where are (new) vulnerabilities that are not mitigated?

Security Planning: An Applied Approach | 11/27/2020 | 36 Bug. Bar Bug Bar Standard for Tampering and Repudiation Severity Permanent modification of any user data in a common scenario that High persists after restarting the OS/application. Permanent modification of any user data in a specific scenario, or Moderate temporary modification of user data in a common scenario. Temporary modification of data in a specific scenario that does not persist after restarting the OS/application. Low

Security Planning: An Applied Approach | 11/27/2020 | 37 Developing A Test Case (Manual) Test Case: Create Patient Information Test Case ID: 3 Test Purpose: 1. Ensure a valid new client can be entered into the system, and the appropriate tabs are created as expected. 2. Ensure a duplicate entry is not created for an existing patient. 3. Ensure invalid data is detected, including wrong data types, overflow text, overflow math numbers, blank required fields, and inappropriate data. Primary Actors: Medical Administrator (Nurse, Doctor) Preconditions: The user is at the main menu. Flow of Events: 1. The test case begins when a Medical Admin selects “Manage Patient” or as an extension to Make Appointment 2. The Tester: enters last name and first name for an existing patient and press ‘Create’. 3. While the system finds a matching record 1. The system displays an error message: “Match Exists”, and requests the tester revise the information. 2. The tester changes the name to a new patient name.

Security Planning: An Applied Approach | 11/27/2020 | 38 Developing A Test Plan (Manual) Flow of Events: …. . 6. The tester enters inappropriate data types for each field of the new Patient and presses ‘Save’. (Example form shown below. ) 7. The system recognizes the invalid information and gives error messages. 6. The tester enters too much information for text strings or overflow data for arithmetic fields for each field of the new Patient and presses ‘Save’. 8. The system recognizes the overflow and gives error messages. 9. The tester leaves some required fields empty for the new Patient and presses ‘Save’. 10. The system recognizes the lacking information and gives error messages. 11. The tester enters inappropriate information for many fields of the new Patient and presses ‘Save’ (e. g, illegal state, sex, number of children, etc. ) 12. The system recognizes the errors and gives error messages. 13. The tester enters valid information for the new Patient and presses ‘Save’. 14. The system displays: ‘Record Updated’ 15. The system creates a Patient Plan Management (Form 6. 5) tab for Patients with health plans, or a Patient Bill Management tab for Patients without. Postconditions: 1. The new record has been saved into the test database. 2. For Patients with health plans, a Patient Plan Management tab is available with information about the Patient’s plan. For Patients without, a Patient Bill Management tab is provided.

Security Planning: An Applied Approach | 11/27/2020 | 39 Mature Software Practices Software Assurance Maturity Model Governance Construction Verification (SAMM) Strategy & Metrics Governance (BSIMM) Strategy & Metrics Policy & Compliance & Policy Education & Guidance Training Threat Assessment Intelligence Attack Models Security Requirements Security Features & Design Secure Architecture Standards & Requirements Design Review Architectural Analysis Security Testing Secure Software Development Life Cycle Touchpoints Vulnerability Mgmt Deployment Penetration Testing Code Review Deployment Building Security In Maturity Model Code Review Security Testing Environment Hardening Software Environment Operational Enablement Configuration Mgmt. & Vulnerability Mgmt.

Security Planning: An Applied Approach | 11/27/2020 | 40 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

Security Planning: An Applied Approach | 11/27/2020 | 41 Example Evil User Stories: University Evil User Story Corresponding Security Story As a failing student, I use a password dictionary to break into a professor’s grades to change my grade. As a system administrator, I require passwords to be 10 characters long and lock out accounts after 6 invalid attempts, to prevent password guessing. As a budding script kiddie, I try different hacking tools on university websites for fun. As a system administrator at the university, I monitor illegal accesses, note their IP addresses, find offending students and charge them. As a criminal cyber-hacker, I try to break As a network administrator, I partition into student accounts to learn their social the confidential zone within the firewall security and credit card numbers. and monitor for specific, legal protocols to prevent exfiltration of data. As a professor with a grant, I am too busy As a financial officer in charge of grants, I to be careful that the money I spend is review grant expenses to ensure they are according to my grant contract. in line with the approved grant.

Security Planning: An Applied Approach | 11/27/2020 | 42 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.

Security Planning: An Applied Approach | 11/27/2020 | 43 Jamie Ramon MD Doctor Chris Ramon RD Dietician Terry Medical Admin HEALTH FIRST CASE STUDY Security Requirements Pat Software Consultant

Security Planning: An Applied Approach | 11/27/2020 | 44 Step 1: Identify Critical Assets All of this information is protected by 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.

Security Planning: An Applied Approach | 11/27/2020 | 45 Step 2: Define security goals Confidentiality Integrity Patient Information: Appointments, Medical history, Treatment, Prescriptions, Bills Impact Rating: * Low Priority ** Medium Priority *** High Priority Availability

Security Planning: An Applied Approach | 11/27/2020 | 46 Step 2: Define security goals Confidentiality Patient Information: Appointments, Medical history, Treatment, Prescriptions, Bills HIPAA Requirement 10 Integrity Availability HIPAA Malpractice law suit Requirement, if information not Malpractice law suit available if accidental death 10 10 Impact Rating: * Low Priority ** Medium Priority *** High Priority

Security Planning: An Applied Approach | 11/27/2020 | 47 Step 3: Identify Threats 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 Use Case Diagram

Security Planning: An Applied Approach | 11/27/2020 | 48 Identifying Proper Threats In the Registration case we are talking about clients registering at our Documentation Database (DD). Which of these are valid misuse cases? Attack SQL: Directly affects DD Password guessing: Directly affects DD if there is a login page. Phishing: Affects OS: does not directly affect DD Virus: Affects OS, does not directly affect DD.

Security Planning: An Applied Approach | 11/27/2020 | 49 Step 3: Identify Threats What it is Spoof Identity STRIDE General Threats Software Techniques Advanced Security Assume identity Encrypt passwords Bypass protection No backdoor entry Secure Password Digital Certificate Sec. Awareness Tamper w. Data Modify data Repudiation Hide activities Info Disclosure Read data Denial of Service Unreliable execution, resource consumption Validate real user via CAPTCHA Test for Failures Firewall Intrusion Prevention System Elevation of Privilege Gain privileges Execute unauthorized cmds/code Take care with error messages Hide system files Require approval Access Control Segregation of Duties Validate input Stop buffer overruns Close unused resources Authentication Access Control Message Digest Require passwords Trans. Logging Log user transactions Digital Signature Encrypt data Encrypt packets Minimal permissions Encryption Authentication Secure Handling

Security Planning: An Applied Approach | 11/27/2020 | 50 Security Requirements Process OCTAVE Security Requirements Process ü Identify critical assets ü Define security goals 3. Identify threats Draw Misuse Diagram from Use Case Diagram 4. Analyze risks: Priority = Impact * Likelihood 5. Define security requirements Draw Misuse Diagram with Security Use Cases Define one Misuse Description (Lightweight or Midweight)