appsec2013 assurance tagging-robert martin
TRANSCRIPT
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
CWE-395 CWE-395 CWE-190 CWE-190 CWE-412 CWE-412 CWE-412
(5) Execute unauthorized code or commands
CWE-88 CWE-88 CWE-120 CWE-120 CWE-120 CWE-79 CWE-79
(6) Gain privileges / assume identity
CWE-96 CWE-96 CWE-489 CWE-489 CWE-309 CWE-309 CWE-309
(7) Bypass protection mechanism
CWE-89 CWE-89 CWE-357 CWE-357 CWE-665 CWE-665 CWE-665
(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
Questions?