1. Security Engineering II

2. Problem Sources 1.Requirements definitions, omissions, and mistakes 2.System design flaws 3.Hardware implementation flaws, such as wiring and chip flaws 4.Software implementation errors, program bugs, and compiler bugs 5.System use and operation errors and inadvertent mistakes 6.Willful system misuse 7.Hardware, communication, or other equipment malfunction 8.Environmental problems and natural causes. 9.Evolution, maintenance, faulty upgrades, and decommissions

4. Security Engineering in a Software Process

5. Security Objectives. Define security objectives and requirements early in the process. Security objectives are goals and constraints that affect the confidentiality, integrity, and availability of your data and application. Design Guidelines for Security. To avoid many of the vulnerabilities introduced by poor design choices, your design activity should use proven design practices, patterns, and principles. By organizing these design patterns and practices into common vulnerability categories, you can focus on those areas where security mistakes are most often made. Threat Modeling. Threat modeling helps you to understand and identify the threats and vulnerabilities relevant to your specific application scenario.

6. Security Engineering in a Software Process Architecture and Design for Security. The architecture and design review process analyzes the architecture and design from a security perspective. It examines a number of aspects including deployment and infrastructure, overall application architecture and design, and each tier in the application. Code Review for Security. All code should be subject to code inspections where the emphasis is on identifying security vulnerabilities. This should be a continuous activity during the development and test phases of the application life cycle. Security Testing. Use a risk-based approach and use the output from the threat modeling activity to help establish the scope of your testing activities and define your test plans. Deployment Review for Security. When your application is deployed, you need to be sure that weak or inappropriate configuration settings do not introduce security vulnerabilities.

7. Phase: Requirements Entry Criteria –Business requirements/objectives –Constraints & assumptions –Project plans –High level architecture Activities –Engage Security Expert –Determine Predictive Threat Index –Determine if application is a candidate for SDL process –Identify key compliance objectives –Define secure integration with external systems –Define application security test process & deliverables –Adjust project plan to include security resources –Contract needed resources –Review test process/strategy –Review project plan & budget Deliverables –Security Expert/Consultant assigned –Preliminary security requirements defined –Security test strategy –Security integrated into the development process –Predictive Threat Index (Asset Value, Attack Surface) Tools –Security consultant –Design Review Checklist –Roles and Responsibilities Matrix –Predictive Threat Index calculator –Security Knowledge Portal Exit –Test strategy approved –Project plan approved

8. Security Objectives

9. Phase: Design Entry Criteria –Security requirements –Functional requirements –Use cases –Project plan & budget Activities –Identify components responsible for security functions –Identify secure design techniques –Document attack surface –Create threat model –Review/modify security requirements –Identify components for Secure Code Review –Define security test requirements –Determine authorization requirements model –Update Security Master Test Plan –Update test schedule and budget Deliverables –Minimized application attack surface –Application security test roles –Threat model –Security requirements in well defined components –Test plans application security –Certified components identified Tools –Threat Model Checklist –Threat Model –Platform dependent coding checklist –Certified Components Exit –Baseline established for requirements, test schedule and test budget

10. Application Threat Classification Authentication Authorization Client-side attacks Command execution Information disclosure Logical attacks

11. Threat Modeling Structured approach to identifying, quantifying and addressing threats Allows security personnel to communicate potential risks and prioritize remediation efforts in a tangible form

12. Threat Modeling Activities InputStepOutput Business requirements Security policies Compliance requirements 1.Identify security objectives Key security objectives Deployment diagrams Use cases Functional specifications 2.Create an application overview Whiteboard-style diagram Key scenarios Roles Technologies AppSec mechanisms Deployment diagrams Use cases Functional specifications Data flow diagrams 3.Decompose your application Trust boundaries Entry points Exit points Data flows Common Threats4.Identify, document and rate threats Threat List Common Vulnerabilities5.Identify vulnerabilities Vulnerability List

13. Threat Model

14. Design Guidelines for Security

16. Phase: Implementation Entry Criteria –Threat model –Master test plan –Security test plans –Use cases/roles Activities –Code Certified components Security development/coding guidelines –Test / Verify Security Code Review Static code analyzer Deliverables –Working application Tools –Static Code Analyzer –Certified Components –Security Development Guidelines Exit –Code verified using code review –Code verified using static code analysis tool

17. Security Code Review Control flow analysis. Control flow analysis is the mechanism used to step through logical conditions in the code. The process works as follows: 1.Look at a function and determine each branch condition. These can include loops, switch statements, if statements and try/catch blocks. 2.Understand the conditions under which each block will be executed. 3.Move to the next function and repeat. Dataflow analysis. Dataflow analysis is the mechanism used to trace data from the points of input to the points of output. 1.For each input location, determine how much you trust the source of input. When in doubt you should give it no trust. 2.Trace the flow of data to each possible output, noting along the way any attempts at data validation. 3.Move to the next input and continue.

18. Phase: Integrate / Release Entry Criteria –Build from source code repository –Test documents –Unit & integration test results (no severity 1 defects) Activities –Integrate Formal Secure Code Review Automated Application Assessment –Final Security Review Review of all bugs for possible security vulnerabilities Review threat model for possible late developing threats Manual penetration testing Deliverables –Problems, defects, enhancements logged –Detailed test results –Validated requirements –Updated test results in centralized location –Certification Tools –Secure Code Review –Automated security tool –Manual Penetration Test –Final Review Checklist Exit –No high severity security defects

20. Security Toolbag Authentication Encryption Virtual Private Networks (VPN) Strong Code Anti-Virus Software Strong Security Policy Secure Networks Firewalls Application Proxies Intrusion Detection Systems (IDS)

21. Security Principles Use least privilege Defense in depth Don’t trust user input Check at the gate Fail securely Secure the weakest link Create secure defaults Reduce your attack surface

22. Web Application Design for Security

23. Trends In Securing Information Technologies Numbers of attacks and the number of attackers are increasing The military and banks are leading the industry Trends include: –VPNs –Firewalls & IDS –Closed networks –Internal auditing

24. Security Architecture and Design Review