The document discusses engineering software systems to be more secure against attacks. It notes that reducing a system's attack surface alone is not enough, as software and networks are too complex and it is impossible to know all vulnerabilities. It then discusses characteristics of advanced persistent threats, including that the initial attack may go unnoticed and adversaries cannot be fully kept out. Finally, it argues that taking a threat-driven perspective beyond just operational defense can help balance mitigation with detection and response.

1. Tagging Your Code with a Useful Assurance Label
Engineering Your Software For Attack
Robert A. Martin
Senior Principal Engineer
Cyber Security Center
Center for National Security
The MITRE Corporation

2. About Me
• About Me
Identified
Hosted by OWASP & the NYC Chapter

3. What We’ve Learned
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
Cyber Attack Lifecycle
Recon
Deliver
Weaponize
Control
Exploit
Maintain
Execute

4. 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”

5. Cyber Threat Intelligence Sharing
Building Blocks – Phases of a
Cyber Attack Lifecycle
Recon
Deliver
Weaponize
Proactive Detection Mitigation
Recon
Weaponize
Control
Exploit
Maintain
Execute
Incident Response & Mission Assurance
• Obtain information to conduct the attack
• Place payload into delivery vehicle
Deliver
• Send the attack to the potential victim
Exploit
• The point of no return
Control
• Direct the victim system to take actions
Execute
• Fulfill mission requirements
Maintain
• Insure future access

6. Hockey Goalie
6

8. 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)

9. Extending the Threat-Driven
Perspective Beyond
Operational Defense
Risk-Based, Attack-Aware, and Threat-Driven
Operational
Strategic

10. 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
M
• Defenders become demanding consumers of
intelligence, informed by understanding of the attacks their
software systems face
D
• Producers of intelligence
R

11. What is “Cyber Threat Intelligence?”
Consider these questions:
 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?

21. A1
Threat
Agents
Risk
Application Specific
Application Security Risks
What Are Application Security Risks?
Attackers can potentially use many different paths through your application to do harm to your business or organization. Each of
these paths represents a risk that may, or may not, be serious enough to warrant attention.
Threat
Agents
Attack
Vectors
Security
Weaknesses
Security
Controls
Weakness
Control
Attack
Technical
Impacts
Business
Impacts
Impact
Asset
Attack
Weakness
Attack
Impact
Weakness
Control
Function
Impact
Asset
Weakness
What’s My Risk?
References
The OWASP Top 10 focuses on identifying the most serious risks for a broad array
of organizations. For each of these risks, we provide generic information about
likelihood and technical impact using the following simple ratings scheme, which is
based on the OWASP Risk Rating Methodology.
OWASP
Weakness
Prevalence
Weakness
Detectability
Technical
Impacts
Easy
Widespread
Easy
Severe
Average
Common
Average
Moderate
Difficult
App
Specific
Attack
Vectors
Uncommon
Difficult
Minor
Attack
Vectors
Business
Impacts
App /
Business
Specific
Only you know the specifics of your environment and your business. For any given
application, there may not be a threat agent that can perform the relevant attack,
or the technical impact may not make any difference to your business. Therefore,
you should evaluate each risk for yourself, focusing on the threat agents, security
controls, and business impacts in your enterprise. We list Threat Agents as
Application Specific, and Business Impacts as Application / Business Specific to
indicate these are clearly dependent on the details about your application in your
enterprise.
The names of the risks in the Top 10 stem from the type of attack, the type of
weakness, or the type of impact they cause. We chose names that accurately
reflect the risks and, where possible, align with common terminology most likely to
raise awareness.
• OWASP Risk Rating Methodology
• Article on Threat/Risk Modeling
External
• FAIR Information Risk Framework
• Microsoft Threat Modeling (STRIDE
and DREAD)
Security
Weakness
Exploitability
EASY
Attacker sends
simple text-based
attacks that exploit
the syntax of the
targeted
interpreter. Almost
any source of data
can be an injection
vector, including
internal sources.
Control
Sometimes, these paths are trivial to find and exploit and sometimes they are extremely difficult. Similarly, the harm that is
caused may be of no consequence, or it may put you out of business. To determine the risk to your organization, you can
evaluate the likelihood associated with each threat agent, attack vector, and security weakness and combine it with an estimate
of the technical and business impact to your organization. Together, these factors determine the overall risk.
Threat
Agents
Consider anyone
who can send
untrusted data to
the system,
including external
users, internal
users, and
administrators.
Injection
Prevalence
COMMON
Detectability
AVERAGE
Injection flaws occur when an application
sends untrusted data to an interpreter.
Injection flaws are very prevalent,
particularly in legacy code. They are often
found in SQL, LDAP, Xpath, or NoSQL
queries; OS commands; XML parsers,
SMTP Headers, program arguments, etc.
Injection flaws are easy to discover when
examining code, but frequently hard to
discover via testing. Scanners and fuzzers
can help attackers find injection flaws.
Technical
Impacts
Business
Impacts
Impact
SEVERE
Application /
Business Specific
Injection can result
in data loss or
corruption, lack of
accountability, or
denial of access.
Injection can
sometimes lead to
complete host
takeover.
Consider the
business value of
the affected data
and the platform
running the
interpreter. All data
could be stolen,
modified, or
deleted. Could your
reputation be
harmed?
Am I Vulnerable To Injection?
How Do I Prevent Injection?
The best way to find out if an application is vulnerable to
injection is to verify that all use of interpreters clearly
separates untrusted data from the command or query. For
SQL calls, this means using bind variables in all prepared
statements and stored procedures, and avoiding dynamic
queries.
Automated dynamic scanning which exercises the application
may provide insight into whether some exploitable injection
flaws exist. Scanners cannot always reach interpreters and
have difficulty detecting whether an attack was successful.
Poor error handling makes injection flaws easier to discover.
Preventing injection requires keeping untrusted data
separate from commands and queries.
1. The preferred option is to use a safe API which avoids the
use of the interpreter entirely or provides a
parameterized interface. Be careful with APIs, such as
stored procedures, that are parameterized, but can still
introduce injection under the hood.
2. If a parameterized API is not available, you should
carefully escape special characters using the specific
escape syntax for that interpreter. OWASP’s ESAPI
provides many of these escaping routines.
3. Positive or “white list” input validation is also
recommended, but is not a complete defense as many
applications require special characters in their input. If
special characters are required, only approaches 1. and 2.
above will make their use safe. OWASP’s ESAPI has an
extensible library of white list input validation routines.
Example Attack Scenarios
References
Scenario #1: The application uses untrusted data in the
construction of the following vulnerable SQL call:
OWASP
Checking the code is a fast and accurate way to see if the
application uses interpreters safely. Code analysis tools can
help a security analyst find the use of interpreters and trace
the data flow through the application. Penetration testers can
validate these issues by crafting exploits that confirm the
vulnerability.
String query = "SELECT * FROM accounts WHERE
custID='" + request.getParameter("id") + "'";
Scenario #2: Similarly, an application’s blind trust in
frameworks may result in queries that are still vulnerable,
(e.g., Hibernate Query Language (HQL)):
Query HQLQuery = session.createQuery(“FROM accounts
WHERE custID='“ + request.getParameter("id") + "'");
• OWASP SQL Injection Prevention Cheat Sheet
• OWASP Query Parameterization Cheat Sheet
• OWASP Command Injection Article
• OWASP XML eXternal Entity (XXE) Reference Article
• ASVS: Output Encoding/Escaping Requirements (V6)
• OWASP Testing Guide: Chapter on SQL Injection Testing
In both cases, the attacker modifies the ‘id’ parameter value
in her browser to send: ' or '1'='1. For example:
External
http://example.com/app/accountView?id=' or '1'='1
• CWE Entry 89 on SQL Injection
This changes the meaning of both queries to return all the
records from the accounts table. More dangerous attacks
could modify data or even invoke stored procedures.
• CWE Entry 564 on Hibernate Injection
• CWE Entry 77 on Command Injection

22. Industry
Uptake
CWE

24. Software Assurance Methods
Countermeasure
Selection
Development Process
Apply assurance activities to the
procedures and structure imposed on
software development
Operational System
Implement countermeasures to the
design and acquisition of end-item
software products and their interfaces
Development Environment
Apply assurance activities to the
environment and tools for
developing, testing, and integrating
software code and interfaces
Additional Guidance in PPP Outline and Guidance

25. Public Law 113-239 Section
933 - Software Assurance
DoD Software-based System
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 part
of the software, throughout the life cycle. Sect933
confidence
functions as intended
Program Office
Milestone Reviews
with 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
free of vulnerabilities

27. SQL Injection Attack Execution Flow
User
1. Web Form with ‘ in all fields
MS SQL
Database
2. One SQL error message
SELECT ITEM,PRICE FROM PRODUCT
WHERE ITEM_CATEGORY='$user_input'
3. Web Form with ‘ in ITEM_CATEGORY field
ORDER BY message
PRICE
4. SQL error
5. Web Form with: ' exec master..xp_cmdshell 'dir' -6. a listing of all directories

28. Simple test case for SQL Injection
Test 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 behavior
Context:
• 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 fields
Test Data:
• ASCII single quote character
Action Steps:
• Enter single quote character into each web form
field on
the registration page
• Submit the contents of the registration page
Postconditions:
• Test case fails if SQL error is thrown
• Test case passes if page submission succeeds without
any SQL errors

29. Security
Feature
Cross-site Scripting (XSS)
Attack (CAPEC-86)
Improper Neutralization of
Input During Web Page
Generation
(CWE-79)
SQL Injection Attack (CAPEC-66)
Improper Neutralization of Special
Elements used in
an SQL Command
(CWE-89)
29

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

33. Engineering For Attack – ISO/IEC TR 20004:
Refining Software Vulnerability Analysis Under
ISO/IEC 15049 and ISO/IEC 18045
Known
Threat
Actors
Attack Patterns
(CAPECs)
Attack
Weaknesses
(CWEs)
Weakness
Controls*
System & System
Security
Engineering
Trades
Technical
Impacts
Operational
Impacts
Impact
Item
Asset
Attack
Weakness
Impact
Item
Function
Attack
Impact
Weakness
Asset
Weakness
Item
* Controls include architecture choices, design choices, added security
functions, activities & processes, physical decomposition choices, code
assessments, design reviews, dynamic testing, and pen testing

34. Technical Impacts –
Common Consequences

35. Scoring Weaknesses
Based on Context
Archetypes:
• Web Browser User Interface
• Web Servers
• Application Servers
• Database Systems
• Desktop Systems
• SSL
Vignettes:
1. Web-based Retail Provider
2. Intranet resident health
records management system
of hospital
Web
Browser
Web
Browser
Web
Browser
2
1
Web
Browser
Web
Browser
Web
Browser
Web
Browser

36. Vignettes – Technology Groups & Business/Mission Domains
Common Weakness Risk Assessment Framework uses Vignettes with Archetypes to identify top CWEs in respective Domain/Technology Groups

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

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

39. Calculating CWSS Impact
Weights

40. Scoring Weaknesses Discovered
in Code using CWSS

41. Utilizing Coverage Claims
Code
Review
CWE’s a capability
claims to cover
Static
Analysis
Tool A
Static
Analysis
Tool B
Pen Testing
Services
Most
Important
Weaknesses
(CWE’s)
Which static analysis tools
and Pen Testing services
find the CWE’s I care
about?

42. Leveraging and Managing to take
Advantage of the Multiple
Perspectives of Analysis
•
•
•
•
•
Null Pointer Dereference
Threading Issues
Issues in Dead Code
Insecure Crypto Functions
…
Total Potential
Security Weaknesses
Static
Analysis
 Application Logic Issues
•
•
•
•
•
•
Environment Configuration Issues
Issues in integrations of modules
Runtime Privileges Issues
Protocol Parser/Serializer Issues
Issues in 3rd party components
…
Dynamic
Analysis
•
•
•
•
•
•
SQL Injection
Cross Site Scripting
HTTP Response Splitting
OS Commanding
LDAP Injection
…

43. Leveraging and Managing to take
Advantage of the Multiple
Perspectives of Analysis
Different perspectives are effective at finding different types of weaknesses
 Some are good at finding the cause and some at finding the effect

Static
Code
Analysis
Penetration
Test
Data
Security
Analysis
Code
Review
Cross-Site Scripting (XSS)
X
X
X
SQL Injection
X
X
Architecture
Risk
Analysis
X
Insufficient Authorization Controls
X
X
X
X
Broken Authentication and Session Management
X
X
X
X
Information Leakage
X
X
Improper Error Handling
X
X
Insecure Use of Cryptography
X
X
Cross Site Request Forgery (CSRF)
X
X
Denial of Service
X
Poor Coding Practices
X
X
X
X
X
X

44. SwA and Systems
Development (example)
Abuse Case
Development
Cyber
Threat/
Attack
Analysis
Application Security Code
Review (developed and
purchased), Penetration
Testing & Abuse Case
Driven Testing
Gather All of the
Evidence for the
Assurance Case
and Get It Approved
and Systems
Design
Attack Analysis against
Supply Chain &
Application Architecture
Security Review
Attack-based
Application Design
Security Review
* Ideally Insert SwA before RFP release in Analysis of Alternatives
Application Security Code
Review, Penetration Testing &
Abuse Case Driven Testing of
Maintenance Updates

45. (Page 1 of 3)
Want Discernibility
Suggestions
Started with
Mitigation Suggestions

46. (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
Binary Static
Analysis
Automated
Dynamic
Analysis
81 CWEs
91 CWEs
56 CWEs
31 CWEs
69 CWEs
60 CWEs
74 CWEs
26 CWEs
Penetration
Testing
Review of Live System
(2) Read Data
Source
Code
Static
Analysis
Review of Code
(1) Modify data
Design
Review
Review of Architecture and
Design
Architecture
Analysis
Red Team
Assessment

47. “An Assurance Tag for Binaries”
Architecture
Analysis
(1) Modify data
Design
Review
Source
Code Static
Analysis
Binary Static
Analysis
Automated
Dynamic
Analysis
Penetration
Testing
CWE-23
CWE-23
Relative Path
Traversal
CWE-131 CWE-131
Incorrect Calculation
of Buffer Size
CWE-311
(2) Read Data
CWE-14
CWE-14
Compiler Removal of
Buffer Clearing
CWE-129 CWE-129
Improper Validation
of Array Index
CWE-209
CWE-209
CWE-209
Information Exposure Through an
Error Messages
(3) DoS: unreliable
execution
CWE-36
CWE-476 CWE-476
Null Pointer
Dereference
CWE-406
(4) DoS: resource
consumption
CWE-395
CWE-395
Use of
NullPointerException
CWE-190
CWE-412
(5) Execute
unauthorized code
or commands
CWE-88
CWE-120
(6) Gain privileges
/ assume identity
CWE-96
(7) Bypass
protection
mechanism
(8) Hide activities
CWE-89
CWE-36
Absolute Path
Traversal
CWE-88
Argument Injection
CWE-96
Static Code
Injection
CWE-89
SQL Injection
CWE-78
CWE-78
OS Command
Injection
CWE-190
Integer Overflow
CWE-120
CWE-489
Leftover Debug Code
CWE-311
Missing Encryption of Sensitive Data
CWE-406
CWE-406
Network Amplification
CWE-412
CWE-412
Unrestricted Externally Accessible Lock
CWE-120
Buffer Overflow
CWE-489
CWE-311
Red Team
Assessment
CWE-79
CWE-79
Cross-site Scripting
CWE-309
CWE-309
CWE-309
Use of Password System for Primary
Authentication
CWE-357 CWE-357
Insufficient UI
Warning of Dangerous
CWE-665
CWE-168 CWE-168
Improper Handling of
Inconsistent
CWE-444
CWE-665
CWE-665
Improper Initialization
CWE-444
CWE-444
HTTP Request Smuggling

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

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

50. 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 CWEtechnical 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?

51. Big finish?
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.
51

52. Optional: FFRDC name here
Optional
Image
Here
Optional
Image
Here
Optional
Image
Here
Optional
Image
Here
Optional
Image
Here
Optional
Image
Here

53. Questions?
ramartin@mitre.org