Security Engineering II

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

Security Engineering in a Software Process

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.

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.

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

Security Objectives

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

Application Threat Classification

• Authentication• Authorization• Client-side attacks• Command execution• Information disclosure• Logical attacks

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

Threat Modeling Activities

Input Step Output

• 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 Threats 4. Identify, document and rate threats

• Threat List

• Common Vulnerabilities 5. Identify vulnerabilities

• Vulnerability List

Threat Model

Design Guidelines for Security

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

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.

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

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)

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

Web Application Design for Security

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

Security Architecture and Design Review