1 / 24

Security Engineering II

Security Engineering II. Problem Sources. Requirements definitions, omissions, and mistakes System design flaws Hardware implementation flaws, such as wiring and chip flaws Software implementation errors, program bugs, and compiler bugs

leo-love
Télécharger la présentation

Security Engineering II

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. Security Engineering II

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

  3. Security Engineering in a Software Process

  4. Security Engineering in a Software Process • 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.

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

  6. 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 Phase: Requirements

  7. Security Objectives

  8. 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 Phase: Design

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

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

  11. Threat Modeling Activities

  12. Threat Model

  13. Design Guidelines for Security

  14. 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 Phase: Implementation

  15. 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: • Look at a function and determine each branch condition. These can include loops, switch statements, if statements and try/catch blocks. • Understand the conditions under which each block will be executed. • 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. • For each input location, determine how much you trust the source of input. When in doubt you should give it no trust. • Trace the flow of data to each possible output, noting along the way any attempts at data validation. • Move to the next input and continue.

  16. 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 Phase: Integrate / Release

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

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

  19. Web Application Design for Security

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

  21. Security Architecture and Design Review

More Related