Appsec2013 assurance tagging-robert martin

Tagging Your Code with a Useful Assurance LabelEngineering Your Software For Attack

Robert A. Martin

Senior Principal Engineer

Cyber Security Center

Center for National Security

The MITRE Corporation

About Me

• About Me

Hosted by OWASP & the NYC Chapter

Identified

| 2 |

Making systems secure by just reducing attack surface really hard – maybe impossible

Software Systems & Networks too large and complex

Zero vulnerabilities for all assets on network?

– Assumes you know all assets

– Assumes you can know all vulnerabilities

Recon

Weaponize

Deliver

Exploit

Control

Execute

Maintain

Cyber Attack Lifecycle

What We’ve Learned

| 3 |

Characteristics of the Advanced Persistent Threat

1. We won’t always see the initial attack

2. We can’t keep the adversary out

3. Advanced Persistent Threat is not a “hacker”

| 4 |

Cyber Threat Intelligence Sharing Building Blocks – Phases of a

Cyber Attack Lifecycle

• Obtain information to conduct the attackRecon

• Place payload into delivery vehicleWeaponize

• Send the attack to the potential victimDeliver

• The point of no returnExploit

• Direct the victim system to take actionsControl

• Fulfill mission requirementsExecute

• Insure future accessMaintain

Proactive Detection Mitigation Incident Response & Mission Assurance

Recon

Weaponize

Deliver

Exploit

Control

Execute

Maintain

| 5 |

Hockey Goalie

6| 6 |

| 7 |

Elements of an Attacker Aware Cyber Threat Intelligence Sharing-Based Approach

1. Understanding of the Attackers Building Blocks

2. Effective Cyber Threat Intelligence Sharing Model

3. Agile defensive posture aligned with threat from the attackers and attack techniques

4. Development team working side-by-side with operators (DevOps)

| 8 |

Extending the Threat-Driven Perspective Beyond Operational Defense

Strategic

Indic

ator

Dev

elopm

ent

Vuln

erab

ility S

cann

ing

Traini

ng

Prod

uct E

valu

ation

Patch

Prior

itiza

tion

Risk-Based, Attack-Aware, and Threat-Driven

Met

rics

Syste

ms E

ngin

eerin

g

Operational

Softwar

e Dev

elop

men

t

Archi

tecti

ng th

e Ent

erpr

ise

Prod

uct S

electi

on| 9 |

From Just a Mitigation Approach

A traditional information assurance approach based solely on regulation, which resulted in an approach based on mitigation and compliance around static defenses

To a threat/attacker based cyber defense that understands attacks and balances Mitigation with Detection and Response

• Defenders become demanding consumers of intelligence, informed by understanding of the attacks their software systems face

• Producers of intelligence

M

D

R

| 10 |

What is “Cyber Threat Intelligence?”

What activity/attacks are we seeing?

What attacks should I look for on my networks and systems and why?

Where has this attack been seen?

What does it do?

What weaknesses does this attack exploit?

Why does attacker do this?

Who is responsible for this attack?

What can I do about it?

Consider these questions:

| 11 |

| 12 |

| 12 |

| 13 |

| 14 |

| 15 |

| 16 |

| 17 |

| 18 |

| 19 |

| 20 |

IndustryUptake

CWE| 22

|

| 23 |

Software Assurance Methods

Additional Guidance in PPP Outline and Guidance

Development ProcessApply assurance activities to the procedures and structure imposed on software development

Operational SystemImplement countermeasures to the design and acquisition of end-item software products and their interfaces

Development EnvironmentApply assurance activities to the environment and tools for developing, testing, and integrating software code and interfaces

Countermeasure Selection

| 24 |

DoD Software-based System

Program Office Milestone Reviewswith OSD on SwA

Program Protection Plan’s “Application of Software

Assurance Countermeasures”

Development Process• Static Analysis• Design Inspection• Code Inspections• CVE• CAPEC• CWE• Pen Test• Test Coverage

Operational System• Failover Multiple Supplier

Redundancy• Fault Isolation• Least Privilege• System Element Isolation• Input checking/validation• SW load key

Development Environment• Source• Release Testing• Generated code inspection

Software Assurance.—The term ‘‘software assurance’’ means the level of confidence that software functions as intended and is free of vulnerabilities, either intentionally or unintentionally designed or inserted as partof the software, throughout the life cycle. Sect933

confidence

free of vulnerabilities

functions as intended

| 25 |

Public Law 113-239 Section 933 - Software Assurance

| 26 |

SQL Injection Attack Execution Flow

MS SQLDatabas

e 1. Web Form with ‘ in all fields

2. One SQL error message

3. Web Form with ‘ in ITEM_CATEGORY field

4. SQL error message

5. Web Form with: ' exec master..xp_cmdshell 'dir' --

6. a listing of all directories

User

SELECT ITEM,PRICE FROM PRODUCT WHERE ITEM_CATEGORY='$user_input' ORDER BY PRICE

| 27 |

Simple test case for SQL InjectionTest Case 1: Single quote SQL injection of registration page web form fields

Test Case Goal: Ensure SQL syntax single quote character entered in registration page web form fields does not cause abnormal SQL behaviorContext:

• This test case is part of a broader SQL injection syntax exploration suite of tests to probe various potential injection points for susceptibility to SQL injection. If this test case fails, it should be followed-up with test cases from the SQL injection experimentation test suite.

Preconditions:• Access to system registration page exists• Registration page web form field content are used by system in SQL queries of the

system database upon page submission• User has the ability to enter free-form text into

registration page web form fieldsTest Data:

• ASCII single quote characterAction Steps:

• Enter single quote character into each web form field on the registration page

• Submit the contents of the registration pagePostconditions:

• Test case fails if SQL error is thrown• Test case passes if page submission succeeds without any SQL errors

| 28 |

Cross-site Scripting (XSS) Attack (CAPEC-86)

Improper Neutralization of Input During Web Page Generation (CWE-79)

Cross-site Scripting (XSS) Attack (CAPEC-86)

Improper Neutralization of Input During Web Page Generation (CWE-79)

Security FeatureSecurity Feature

SQL Injection Attack (CAPEC-66)

Improper Neutralization of Special Elements used in an SQL Command (CWE-89)

SQL Injection Attack (CAPEC-66)

Improper Neutralization of Special Elements used in an SQL Command (CWE-89)

29

Software, Network Traffic, Physical, Social Engineering, and Supply Chain Attack Patterns

| 30 |

| 32 |

Weakness

Weakness

Weakness

Weakness

Asset

Attack

Impact

Item

Item

Item

Attack

Attack

Function

Asset

Impact

Impact

KnownThreatActors

Attack Patterns(CAPECs)

Weaknesses(CWEs)

Controls* TechnicalImpacts

Operational Impacts

* Controls include architecture choices, design choices, added security functions, activities & processes, physical decomposition choices, code assessments, design reviews, dynamic testing, and pen testing

System & System Security

EngineeringTrades

Engineering For Attack – ISO/IEC TR 20004:Refining Software Vulnerability Analysis Under

ISO/IEC 15049 and ISO/IEC 18045

| 33 |

Technical Impacts – Common Consequences

| 34 |

| 35 |

Web Browser

Web Browser

Web Browser

Web Browser

Web Browser

Web Browser

Web Browser

Archetypes: • Web Browser User Interface• Web Servers• Application Servers• Database Systems• Desktop Systems• SSL

Scoring Weaknesses Based on Context

Vignettes: 1. Web-based Retail Provider2. Intranet resident health

records management system of hospital

12

Common Weakness Risk Assessment Framework uses Vignettes with Archetypes to identify top CWEs in respective Domain/Technology Groups

Vignettes – Technology Groups & Business/Mission Domains

Business Value Context (BVC)

• Identifies critical assets and security concerns• Links Technical Impacts (derived from CWE

weaknesses) with business implications• More fine-grained model than the CIA Triad

• (Medical billing): Privacy is very important, claimed by one source to be the largest obstacle for sharing medical records; yet life-and-death situations in (critical care) may have different criteria than in a clinical setting. Electronic medical breaches could lead to discrimination, not just personal embarrassment or discomfort. Availability is less important - could cause delays in billing but do not directly affect health of the patient.

• (Implanted medical device): Power consumption and privacy a concern. Key management important. Must balance ease-of-access during emergency care with patient privacy and day-to-day security. Integrity and availability are essential - improper execution or failure of the device could lead to illness or death.

| 37 |

Technical Impact Scorecard

• Links business value with the technical impact of weakness exploitation

• Stays away from technical details of individual weaknesses

• Operates within the context of a vignette

| 38 |

Calculating CWSS Impact Weights

| 39 |

Scoring Weaknesses Discovered in Code using CWSS

| 40 |

Which static analysis tools and Pen Testing services find the CWE’s I care about?

Utilizing Coverage Claims

Most Important

Weaknesses(CWE’s)

Code Review

Static Analysis Tool A

Pen Testing Services

CWE’s a capability claims to cover

Static Analysis Tool B

| 41 |

Total PotentialSecurity Weaknesses

DynamicAnalysis

StaticAnalysis

• Environment Configuration Issues

• Issues in integrations of modules

• Runtime Privileges Issues• Protocol Parser/Serializer Issues• Issues in 3rd party components• …

• Environment Configuration Issues

• Issues in integrations of modules

• Runtime Privileges Issues• Protocol Parser/Serializer Issues• Issues in 3rd party components• …

• Null Pointer Dereference• Threading Issues• Issues in Dead Code• Insecure Crypto Functions• …

• Null Pointer Dereference• Threading Issues• Issues in Dead Code• Insecure Crypto Functions• …

• SQL Injection• Cross Site Scripting• HTTP Response Splitting• OS Commanding• LDAP Injection• …

• SQL Injection• Cross Site Scripting• HTTP Response Splitting• OS Commanding• LDAP Injection• …

Application Logic Issues Application Logic Issues

Leveraging and Managing to take Advantage of the Multiple

Perspectives of Analysis

| 42 |

Leveraging and Managing to take Advantage of the Multiple

Perspectives of Analysis

StaticCode

Analysis

PenetrationTest

DataSecurityAnalysis

CodeReview

ArchitectureRisk

Analysis

Cross-Site Scripting (XSS) X X X

SQL Injection X X X

Insufficient Authorization Controls X X X X

Broken Authentication and Session Management X X X X

Information Leakage X X X

Improper Error Handling X

Insecure Use of Cryptography X X X

Cross Site Request Forgery (CSRF) X X

Denial of Service X X X X

Poor Coding Practices X X

Different perspectives are effective at finding different types of weaknesses Some are good at finding the cause and some at finding the effect

| 43 |

SwA and Systems Development (example)

Cyber Threat/AttackAnalysis

Abuse Case Development

Attack Analysis against Supply Chain & Application Architecture Security Review

Application Security Code Review, Penetration Testing & Abuse Case Driven Testing ofMaintenance Updates

Application Security Code Review (developed and purchased), Penetration Testing & Abuse Case Driven Testing

and Systems Design

* Ideally Insert SwA before RFP release in Analysis of Alternatives

Attack-based Application Design Security Review

Gather All of the Evidence for the Assurance Case and Get It Approved

| 44 |

(Page 1 of 3) Want Discernibility Suggestions

Started with Mitigation Suggestions

Architecture Analysis

Design Review

Source Code Static Analysis

Binary Static Analysis

Automated Dynamic Analysis

Penetration Testing

Red Team Assessment

(1) Modify data

(2) Read Data

(3) DoS: unreliable execution

(4) DoS: resource consumption

(5) Execute unauthorized code or commands

(6) Gain privileges / assume identity

(7) Bypass protection mechanism

(8) Hide activities Revi

ew o

f Arc

hite

ctur

e an

d D

esig

n

Revi

ew o

f Cod

e

Revi

ew o

f Liv

e Sy

stem81 CWEs

91 CWEs56 CWEs31 CWEs69 CWEs60 CWEs74 CWEs26 CWEs

Notional

Architecture Analysis

Design Review

Source Code Static

Analysis Binary Static Analysis

Automated Dynamic Analysis Penetration

TestingRed Team

Assessment

(1) Modify data CWE-23 CWE-23 CWE-131 CWE-131 CWE-311 CWE-311 CWE-311

(2) Read Data CWE-14 CWE-14 CWE-129 CWE-129 CWE-209 CWE-209 CWE-209

(3) DoS: unreliable execution

CWE-36 CWE-36 CWE-476 CWE-476 CWE-406 CWE-406 CWE-406

(4) DoS: resource consumption


(5) Execute unauthorized code or commands


(6) Gain privileges / assume identity


(7) Bypass protection mechanism


(8) Hide activities CWE-78 CWE-78 CWE-168 CWE-168 CWE-444 CWE-444 CWE-444

Notional

OS Command Injection

SQL Injection

Static Code Injection

Argument Injection

Use of NullPointerException

Absolute Path Traversal

Compiler Removal of Buffer Clearing

Relative Path Traversal

Improper Handling of Inconsistent

Insufficient UI Warning of Dangerous

Leftover Debug Code

Buffer Overflow

Integer Overflow

Null Pointer Dereference

Improper Validation of Array Index

Incorrect Calculation of Buffer Size

HTTP Request Smuggling

Improper Initialization

Use of Password System for Primary Authentication

Cross-site Scripting

Unrestricted Externally Accessible Lock

Network Amplification

Information Exposure Through an Error Messages

Missing Encryption of Sensitive Data

“An Assurance Tag for Binaries”

© 2012 The MITRE Corporation. All rights reserved. For internal MITRE use

Notional

Planning to Leverage “State of the Art Resource” (SOAR): Software Table of

“Verification Methods”

Going Forward

• Put table of CWEs, by the 8 Technical Impact Types, on the “SwA On-Ramp”

• Fill in missing remediation recommendations for the rest of CWE

• Validate the CWEtechnical impact type in CWE• Fill in “Discernibility” information for each CWE leveraging

the IDA SOAR – those discernable in arch/design review; – those discernable (findable) in the code; and – those discernable on the live system.

• Other Ideas? • Volunteers?

| 50 |

Big finish?

51

Sharing knowledge of our opponents and watching the plays develop, we can make the saves that protect our networks and the software running on them.

Optional: FFRDC name here

Optional ImageHere

Optional ImageHere

Optional ImageHere

Optional ImageHere

Optional ImageHere

Optional ImageHere

© 2012 The MITRE Corporation. All rights reserved. For internal MITRE use

[email protected]

Questions?