Advanced Research in
Software Engineering
Advances in Measuring
and
Preventing
Software
Security
Weaknesses
Robert A. Martin
Todays Reality – We Need Confidence in
our Software-enabled Cyber Capabilities
•  Dependencies on
software-enabled cyber
technology is greater
then ever
•  Possibility of
disruption is greater
than ever because
hardware/ software is
vulnerable
•  Loss of confidence
alone can lead to
stakeholder actions
that disrupt critical
business and support
activities
•  Agriculture and Food
•  Energy
•  Transportation
•  Chemical Industry
•  Postal and Shipping
•  Water
•  Public Health
•  Telecommunications
•  Banking and Finance
•  Key Assets
Critical Infrastructure / Key Resources
•  Railroad Tracks
•  Highway Bridges
•  Pipelines
•  Ports
•  Cable
•  Fiber
•  Navigation
•  FDIC Institutions
•  Chemical Plants
•  Delivery Sites
•  Nuclear power plants
•  Government Facilities
•  Dams
•  Reservoirs Treatment plants
•  Farms
•  Food Processing Plants
•  Hospitals
•  Power Plants
•  Production Sites
Physical Infrastructure
Services
•  Managed Security
•  Information Services
Control Systems
•  SCADA
•  PCS
•  DCS
•  Vehicle Systems
•  Medical
Hardware
•  Database Servers
•  Networking Equipment
Software
•  Financial SystemsInternet
•  Human Resources
•  Domain Name System
•  Web Hosting
Cyber Infrastructure
Definitions of Software Assurance…
“Level of confidence that software is free from vulnerabilities, either intentionally
designed into the software or accidentally inserted at anytime during its lifecycle
and that the software functions in the intended manner.”
- CNSS Instruction 4009
“level of confidence that software is free from vulnerabilities, either intentionally
designed into the software or inserted at anytime during its lifecycle, and that the
software functions in the intended manner.”
- Webopedia
“confidence that software, hardware and services are free from intentional and
unintentional vulnerabilities and that the software functions as intended.”
- SAFECode, Software Assurance: An Overview of Current Industry Best Practices
"the planned and systematic set of activities that ensures that software processes
and products conform to requirements, standards, and procedures to help
achieve:
•  Trustworthiness - No exploitable vulnerabilities exist, either of malicious or
unintentional origin, and
•  Predictable Execution - Justifiable confidence that software, when executed,
functions as intended."
- NIST Software Assurance Metrics and Tool Evaluation (SAMATE) project
Everything’s Cyber Connected and Co-Dependent
Either during Operations or the Other Phases of its Life
Your System is
attackable or
susceptible to a
hazard
When this Other System gets subverted
through an un-patched vulnerability, a misconfiguration, an application weakness, or
susceptibility to a hazard or attack
Everything’s Cyber Connected and Co-Dependent
Either during Operations or the Other Phases of its Life
Legacy
Software
Reuse
Program
Program
Office
Office
?
Other
Programs
?
?
US
?
Global
Supplier
Foreign
Develop
In-house
Acquire
Off-shore
Supplier
Foreign
Location
Software
COTS
US
Supplier
Reuse
Acquire
Develop
In-house
?
?
Outsource
?
?
?
Contractor
Outsource
Prime
Prime
Contractor
Contractor
?
?
Contractor
Foreign
Developers
5
Software Assurance:
Mitigating Attacks That Impact Operations
water
flooding
Known
Threat
Actors
Attack
Patterns
(CAPECs)
Attack
screen
door in sub
close
door
sub fills
w/water
sub sinks
Weaknesses
(CWEs)
Actions*
Technical
Impacts
Operational
Impacts
Weakness
System &
System Security
Engineering
Trades
Impact
Item
Asset
Attack
Weakness
Impact
Item
Function
Attack
Impact
Weakness
Asset
Weakness
Item
* “Actions” include: architecture choices; design choices; added security
functions, activities & processes; physical decomposition choices; static &
dynamic code assessments; design reviews; dynamic testing; and pen testing
Recreation Use
Industrial Use
Power Use
Agricultural Use
Home Use
Recreation Use
Agricultural Use
STATIC ANALYSIS
STATIC ANALYSIS
Table 2. Example technical impact scores.
Technical impact
Layer
Importance
Network
3
Can’t identify attack source; can’t obtain sufficient
evidence for criminal prosecution
Denial of service (DoS):
resource consumption
System
3
Customers experience delays in reaching site; reductions
in order placement and resulting financial loss
DoS: unreliable execution
System
4
Customers can’t reach site owing to frequent application
crashes; financial loss owing to downtime
Modify data
Application
8
Modify or delete customer order status and pricing, contact
information, inventory tracking, customer credit card numbers,
cryptographic keys, and passwords (hopefully encrypted)
Modify data
Enterprise
10
Read data
Application
8
System
10
Read or modify customer credit card numbers, contact
information, order status and pricing, inventory tracking,
cryptographic keys, and passwords (plaintext and encrypted);
cause DoS; modify website to deface or install malware
to deliver to customers; uninstall critical software
Application
7
Avoid attack detection; possibly steal data; pose as other users
Hide activities
The Software Industry’s
“Clean Water Act” Alternative
Execute unauthorized
code or commands
Robert A. Martin and Steven M. Christey | MITRE
Following the water industry’s example, the authors advocate for implementing processes thatBypass
can protection mechanism
examine software and remove the most dangerous contaminants, given its intended use.
M
uch like the water we use in diverse daily activities across all aspects of our world’s ecosystem,
the actual sources of, and manner in which we receive,
the software in our cyberecosystem are often unknown
and possibly unknowable. Over time, the water industry
has developed water-quality measurements and methods that give users trust in the fact that harmful water
qualities aren’t present. This is due to the industry’s
technical ability to specify and measure water qualities,
such as temperature, hardness, volume, and pollutants,
as well as the regulatory framework that mandates that
those who offer water check these characteristics for
dangerous levels according to the water’s intended use.
When harmful levels are detected, mitigations and controls can be applied and verified, including water softeners, filtration, settling ponds, and cooling towers.
The software industry must implement similar processes and technical methods to examine software for
dangerous contaminants given its intended use and
ensure that appropriate mitigations and controls are in
place to remove the harmful characteristics. Several software assurance strategic initiatives, cosponsored by the
US Department of Homeland Security National Cyber
Security Division, attempt to make this process easier.
The Common Weakness Enumeration (CWE; https://
cwe.mitre.org) offers the industry a list of potentially
24
May/June 2012
dangerous software contaminants, and the Common
Weakness Scoring System (CWSS; https://cwe.mitre.
org/cwss) and the Common Weakness Risk Analysis
Framework (CWRAF; https://cwe.mitre.org/cwraf)
provide a standard method to identify which of these
contaminants are most harmful to a particular organization, given the software’s intended use.
In this article, we define an approach for organizations to document software’s security-relevant capabilities and rank the various potential technical impacts
from CWEs so those CWEs with the most impact to
an organization can be prioritized for mitigation. By
addressing vulnerable software and finding systematic
and verifiable ways to remove these weaknesses, software providers can improve customers’ trust in their
systems and possibly avoid a regulatory solution, which
might have unintended consequences.
Background
In the late 1990s, the sharing, discussing, measuring,
and reporting of activities surrounding software products’ vulnerabilities was unorganized and cumbersome to manage. With the help of industry, academia,
and government, MITRE attempted to change this by
introducing the Common Vulnerabilities and Exposures (CVE) effort (https://cve.mitre.org). CVE lets
Copublished by the IEEE Computer and Reliability Societies
1540-7993/12/$31.00 © 28
2012 IEEE
Explanation
Modify Domain Name System records to redirect targeted employees
to a drive-by-download site that automatically installs malware
Read customer credit card numbers, contact information,
order status, cryptographic keys, and passwords (hopefully
encrypted); read application configuration
play in that environment, where archetypes are the
notional architectural constructs of the system that the
software runs in and interacts with, including the organization’s priorities with respect to software security.
(For more information on archetypes, see the sidebar.)
A vignette identifies the essential resources and capabilities as well as their importance relative to security principles such as confidentiality, integrity, and availability.
For example, an e-commerce organization might have a
business requirement specifying 99.999 percent uptime.
This organization will view weaknesses that cause software execution interruptions as more severe than organizations without such stringent requirements.
CWSS scoring uses vignette to support diverse audiences with a wide variety of requirements for weakness
prioritization. Another important part of a vignette is the
business value context (BVC), which contains a general
description of the business domain software’s securityrelevant archetypes, assets, interfaces, and security priorities with respect to potential attack outcomes.
Linking Business Value with Weaknesses
Much like a list of the possible consequences of a person
ingesting water containing dangerous contaminants,
technical impact scorecards in CWSS and CWRAF
connect BVC business concerns with the possible technical impacts resulting from successful exploits. For
each potential technical impact, the scorecard assigns a
IEEE Security & Privacy
© 2012 The MITRE Corporation. All rights reserved.
score and the rationale for the score. Table 2 shows a
subset of technical impacts—as well as a hypothetical
score evaluation for a notional vignette—for a piece of
software that supports a Web-based e-commerce site.
The technical impact scorecard values drive the
CWSS score to reflect the organization’s business priorities and requirements as described in the BVC.
Vignettes provide the mechanism for calculating CWSS
scores so that they reflect the organization’s context for
prioritization, as captured in the vignette’s technical
impact scorecard.
Successful weakness exploitation could have varying
technical impacts that occur at four different layers:
■ system—the entity has access to, or control of, a system or physical host;
■ application—the entity has access to an affected
application;
■ network—the entity has access to/from the network;
and
■ enterprise—the entity has access to a critical piece of
enterprise infrastructure, such as a router or Domain
Name System.
When completing a technical impact scorecard, we
examine all possible combinations of technical impacts
and impact layers (32 possibilities) and capture the
analysis in the technical impact scorecard. The scorecard
May/June 2012
CWE’s all lead to these Technical Impacts
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
Assurance on the Management of Weaknesses
Mitigate
Eliminate
Alarm for Attack/Exploit
Block from Attack
Attack Surface Analysis/
Threat Modeling
An Example of Connected and Co-Dependent
Mapping
System
VPN Over the
Internet
Open Source
Map Software
Mapping
Data
Provider
Mission
Planning,
Post
Analysis
Maps and
Geo data
Mission
Plan
Mission
Results
Software Internet
Development
Tools
Internet
Software
Libraries Internet
Internet
Multi-Function Display Multi-Function Display
(MFD) Left
(MFD) Right
Joint Test
Action
Group
(JTAG)
Flash
Cartridge
Control
Panel
Pilot Trainer
Board
Test
Equipment
Firmware
Components
Display
Computer/
Bus Controller
Test
Signals
MIL-STD-1553
PC
PC
Vendor Web Server
Test
Equipment
ARINC 429
Avionics Repair
Facility
CD
Common
Data Link (CDL)
Live
Mission
Data
Data Transfer Unit
(DTU)
Link 16
ADS-B
Comm/Nav
Computer
Ground Station
Internet
Developer’s
Posts/Profile
OFPs,
Mission Data,
Maps
Mission Computer
OFP
Operating
System
Updates,
Loader Updates,
Windows-based
Avionics Full-Duplex Mission
OFP
CD Duplicator
Loader/
Computer
CD
Switched Ethernet
Vendor Web Server
Verifier
Duplicator
(AFDX) Switch
Mission Computer
OFP
Internet
Secret Internet Protocol
Router Network (SIPR)
Loader Company
Web server
Internet
Patents and
Technical Papers
Mailed
CD
Avionics Development and Loader Development
Integration Facility
System
Loader Software,
Company
Network
Duplicator
Firmware,
Loader Firmware,
CD Images
•  2014 Jeep Cherokee & 2015 Escalade: Car apps, Bluetooth and telematics -which connects the car to a cellular network like OnStar -- are on the same
network as the engine controls, steering, brakes and tire pressure monitor
system.
•  2014 Prius: the AM/FM/XM radio and Bluetooth are on the same network as the
steering, brakes and tire pressure monitor.
Prioritizing by Technical Impacts:
CWE’s Common Consequences
CWSS 1.0 (17 July 2014)
Base Finding Group
• Technical Impact
• Acquired Privilege
• Acquired Privilege Layer
• Internal Control
Effectiveness
• Finding Confidence
Environmental Group
• Business Impact
• Likelihood of Discovery
• Likelihood of Exploit
• External Control
Effectiveness
• Prevalence
Attack Surface Group
• Required Privilege
• Required Privilege Layer
• Access Vector
• Authentication Strength
• Level of Interaction
• Deployment Scope
CWRAF/CWSS in a Nutshell
CWSS
Score
97
95
94
94
94
93
93
92
91
91
91
90
90
90
90
CWSS
Scoring
Engine
“Vignette”
CWE
CWE-79
CWE-78
CWE-22
CWE-434
CWE-798
CWE-120
CWE-250
CWE-770
CWE-829
CWE-190
CWE-494
CWE-134 User-defined
CWE-772 cutoff
CWE-476
CWE-131
…W is all possible weaknesses
W
Wd
Most
Important
Weaknesse
s
Wd is all known weaknesses (CWE)
Scoring Weaknesses Discovered in Code
Of Covered
CWEs
Circa 2006
Circa 2009
CWE Coverage –
Implemented…
CWE IDs mapped to Klocwork Java issue types - current
http://www.klocwork.com/products/documentation/curren...
CWE IDs mapped to Klocwork Java issue
types
From current
CWE IDs mapped to Klocwork Java issue types
See also Detected Java Issues.
CWE ID
Klocwork Checker Code and Description
CWE IDs mapped to Klocwork C and C++ issue types/ja20
-...(http://cwe.mitre.org
http://www.klocwork.com/products/documentation/curren...
SV.TAINT Tainted data
/data/definitions/20.html)
73 (http://cwe.mitre.org
/data/definitions/73.html)
79 (http://cwe.mitre.org
/data/definitions/79.html)
< CWE IDs mapped to Klocwork C and C++ issue types
80 (http://cwe.mitre.org
CWE IDs mapped to Klocwork C and C++ issue types/ja
/data/definitions/80.html)
?; Detected C and C++ Issues.
From current
Cenzic Product Suite is CWE Compatible
Cenzic Hailstorm Enterprise ARC, Cenzic Hailstorm Professional and Cenzic ClickToSecure are
compatible with the CWE standard or Common Weakness Enumeration as maintained by Mitre
Corporation. Web security assessment results from the Hailstorm product suite are mapped to
the relevant CWE ID's providing users with additional information to classify and describe
common weaknesses found in Web applications.
CWE ID
For additional details on CWE, please visit: http://cwe.mitre.org/index.html
20
(http://cwe.mitre.org
/data/definitions
/20.html)
The following is a mapping between Cenzic’s SmartAttacks and CWE ID's:
13
Check HTTP
Methods
SV.TMPFILE Temporary file path tampering
SV.PATH Path and file name injection
CWE IDs mapped to Klocwork C and
C++File injection
SV.PATH.INJ
77 (http://cwe.mitre.org
SV.EXEC Process Injection
issue types/ja
/data/definitions/77.html)
SV.EXEC.DIR Process Injection. Working Directory
www.cenzic.com | (866) 4-CENZIC (866-423-6942)
Cenzic
SmartAttack
Name
Application
1
Exception
Application
2
Exception (WS)
Application Path
3
Disclosure
Authentication
4
Bypass
Authorization
5
Boundary
Blind SQL
6
Injection
Blind SQL
7
Injection (WS)
Browse HTTP
8
from HTTPS List
9 Brute Force Login
10 Buffer Overflow
Buffer Overflow
11
(WS)
Check Basic Auth
12
over HTTP
SV.TAINT_NATIVE Tainted data goes to native code
CWE ID/s
22
(http://cwe.mitre.org
/data/definitions
/22.html)
CWE-388: Error Handling
CWE-388: Error Handling
73
(http://cwe.mitre.org
/data/definitions
/73.html)
CWE-200: Information Leak (rough match)
CWE-89: Failure to Sanitize Data into SQL Queries (aka
'SQL Injection') (rough match)
CWE-285: Missing or Inconsistent Access Control, CWE-425:
Direct Request ('Forced Browsing')
CWE-89: Failure to Sanitize Data into SQL Queries (aka
'SQL Injection')
CWE-89: Failure to Sanitize Data into SQL Queries (aka
'SQL Injection')
CWE-200: Information Leak
CWE-521: Weak Password Requirements
CWE-120: Unbounded Transfer ('Classic Buffer Overflow')
CWE-120: Unbounded Transfer ('Classic Buffer Overflow')
CWE-200: Information Leak
SV.XSS.DB Cross Site Scripting (Stored XSS)
SV.DATA.DB Data injection
SV.XSS.REF Cross Site Scripting (Reflected XSS)
SV.XSS.DB Cross Site Scripting (Stored XSS)
SV.XSS.REF Cross Site Scripting (Reflected XSS)
SV.SQL Sql Injection
89 (http://cwe.mitre.org
SV.SQL.DBSOURCE Unchecked information from the
/data/definitions/89.html)
database is used in SQL statements
SV.DATA.DB Data injection
ABV.TAINTED @E<8"$ .".$,.
SV.TAINTED.GENERIC
@EAH9
.=D
103 (http://cwe.mitre.org
SV.STRUTS.VALIDMET Struts Forms: validate method
SV.TAINTED.ALLOC_SIZE
&'*41
@EG>
/data/definitions/103.html)
=D
105 (http://cwe.mitre.org
SV.TAINTED.CALL.INDEX_ACCESS
=I>50@E
SV.STRUTS.NOTVALID Struts Forms: inconsistent validate
G>:9-/data/definitions/105.html)
=D
113 (http://cwe.mitre.org
SV.HTTP_SPLIT HTTP Response Splitting
/data/definitions/113.html) $+,.!7
SV.CUDS.MISSING_ABSOLUTE_PATH
#/=D 117 (http://cwe.mitre.org
SV.LOG_FORGING Log Forging
/data/definitions/117.html)
129 (http://cwe.mitre.org
SV.DOS.ARRINDEX Tainted index used for array access
SV.CUDS.MISSING_ABSOLUTE_PATH
/data/definitions/129.html)$+,.!7
#/=D
74
(http://cwe.mitre.org
/data/definitions
/74.html)
SV.TAINTED.INJECTION
%-! -)1 of 4
77
(http://cwe.mitre.org
/data/definitions
/77.html)
SV.CODE_INJECTION.SHELL_EXEC +B%-! )-
78
(http://cwe.mitre.org
/data/definitions
/78.html)
NNTS.TAINTED @E(.<8FC"$ .".$,.
- 3 NULL 62AH9
SV.TAINTED.INJECTION %-! -)-
88
(http://cwe.mitre.org
SV.TAINTED.INJECTION %-! -)NNTS.TAINTED @E(.<8FC"$ .".$,.
2/26/11 10:35 AM
CWE-650: Trusting HTTP Permission Methods on the Server
Side
1 of 7
Cenzic CWE Brochure | October 2009
Company Confidential
Cenzic®, Hailstorm® and ClickToSecure® are registered trademarks of Cenzic, Inc.
The Cenzic logo, Hailstorm Enterprise ARC, and GovShield are trademarks of Cenzic, Inc.
© 2009 Cenzic, Inc. All rights reserved.
1
2/26/11 10:34 AM
Assurance, Detection Activities, & the Systems
Dev. Life-Cycle
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
There are Many Detection Methods
Available to Gain Assurance Evidence…
Different assessment methods 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
X
Architecture
Risk
Analysis
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
Technical Impacts – Common Consequences
Detection Methods
New Detection Methods and
Technical Impact Table Launched Feb 17
TABLE OF CONTENTS
Departments
3 From the Sponsor
Similarly, there is a “Detection Methods” field within many
CWE entries that conveys information about what types of assessment activities that weakness can be found by. More and
more CWE entries have this field filled in over time. The recent
BackTalk
Institute of Defense Analysis (IDA) State of the Art Research
report conducted for DoD provides additional information for
use across CWE in this area. Labels for the Detection Methods
being used within CWE at present are: Automated Analysis,
Automated Dynamic Analysis, Automated Static Analysis,
During the past several decades, software-based ICT capaBlack Box, Fuzzing, Manual Analysis, Manual Dynamic Analysis,
bilities have become the basis of almost every aspect of today’s
Manual Static Analysis, Other, and White Box.
cyber commerce, governance, national security, and recreation.
This offers a second simplification where stakeholders can
Phone 801-777-9828
Software-based
devices are
in ourtype
homes,
vehicles, communow match weaknesses
against
of assessment
activiNon-Malicious Taint:
E-mail Crosstalk.Articles@hill.af.mil
nications,
and
Unfortunately
the basis
of these
ties, and
willtoys.
thereby
gain insightssoftware,
into whether
that weakness
Bad Hygiene is as Dangerous to the Mission as Malicious Intent
CrossTalk Online www.crosstalkonline.org
cyber
capabilities,
can
be unpredictable
since there
are now
is still
an issue, or
whether
it has been mitigated
or removed.
Until both malicious and non-malicious aspects of taint can be dealt with in ways
underlying
rules
to follow
as information
opposed tointhe
rest
Continuing
thesoftware
example has
above,
using the
Figure
that are visible and verifiable, there will be a continued lack of confidence and
of our
material
world
which
constrained
theoflaws
of can
gravity,
1, the
specific
CWEs
that is
can
lead to thatby
type
impact
be
Robert A. Martin, MITRE
Corporation
, The Journal of Defense Software Engineering
assurance in delivered capabilities throughout their lifecycle.
reviewed
and
the ones
that
dynamic
analysis,
static analysis,
and
chemistry,
and
physics
with
core
factors
like Plank’s
Constant.
is co-sponsored by the U.S. Navy (USN); U.S. Air Force (USAF);
and
by Robert A. Martin
fuzzing
can
gather
evidence
about
and
which
ones
they
can
not.
This
is
even
more
true
given
the
variety
and
level
of
skills
and
Abstract. Success of thethe
mission
should
be
the
focus
of
software
and
supply
chain
U.S. Department of Homeland Security (DHS). USN co-sponsor:
relationship
between
various
assessment/
training
of those whothe
create
and evolve
cyber
capabilities.
The
assurance activities regardless
what
activityCommand.
produces the
risk.co-sponsor:
It does not matter
if
NavalofAir
Systems
USAF
Ogden-ALC
309 Understanding
detection
methods
and the artifacts
available
overremain
the lifecycle,
of Cybersecurity
and Communicaresult
is that for
the foreseeable
future
there will
a need
cause. DHS
It doesco-sponsor:
not matter ifOffice
it is malicious
logic inserted
at
Collaborating across the Supply Chain to Address a malicious saboteur is theSMXG.
better enables decision-makers to plan for: specific issue(s) to
tions
in
the
National
Protection
and
Programs
Directorate.
to address the types of quality and integrity problems that leave
the factory or inserted through an update after fielding. It does not matter if it comes
Taint and Counterfeit
review; at what point(s) in the effort; using what method(s); and
software unreliable, attackable, and brittle directly. This includes
from an
error in judgment or from a failure to understand how an attacker could
The community of acquirers and providers of technology must reach
a consenthrough the use of the coverage claims representations [10] of
The
USAF
Software
Technology
Support
Center
(STSC) addressing
is the
the problems that allow malware and exploitable
exploit
a
software
feature.
Issues
from
bad
software
hygiene,
like
inadvertent
coding
sus on two basics questions: 1) Where is the mitigation focus?, and 2) Are we
the various tools and services, which capability(s) could be leverpublisher
of
providing
both
editorial
oversight
and
vulnerabilities
to be
accidentally
inserted
flaws
or
weak
architectural
constructs
are
as
dangerous
to
the
mission
as
malicious
aged, etc. This
is depicted
in Figure
2. into products durdiscussing issues that occur in technology development or just products that
technical review of the journal. mission is to encouring development, packaging, or updates due to poor software
acts. Enormous energies are put into hygiene and quality in the medical and food
have been tampered with?
age the engineering development of software to improve the reliabil-This information can assist project staff in planning their
hygiene
practices.
industries to address any source of taint. Similar energies need to be applied to
ity, sustainability, and responsiveness of our warfighting capability.assurance activities; it will better enable them to combine the
by Dan Reddy
Computer
specifications
are
historically
vague
and
software and hardware. Until both malicious and non-malicious aspects of taint can
groupingslanguage
of weaknesses
that lead to
specific
technical
impacts
loosely
(Note:
ISO/IEC
JTC1methods.
SC22 issued
a Technibe dealt with in ways that are
visible and verifiable,
there will be a continued lack of
the listing
of specific
detection
This provides
inSubscriptions:
Visit <www.crosstalkonline.org/subscribe>
to withwritten.
formation
the presence
specific languages
weaknesses,and
enabling
cal Report
[1]about
with guidance
for of
selecting
using
confidence
and assurancereceive
in delivered
capabilities
throughout
lifecycle.
an e-mail
notification
whentheir
each
new issue is published
Software and Supply Chain Risk Management Assurance
Framework
them to more
make secure
sure theand
dangerous
areisaddressed.
languages
reliably.)ones
There
often a lack of
online or to subscribe to an RSS notification feed.
The DoD, the defense industrial base, and the nation’s critical infrastructure all
Figure
1 conveys information
associated
withinthe
“Software
concern
for
resilience,
robustness,
and
security
the
variety
Background
face challenges in Supply Chain Risk Management Assurance. These diverse
Assurance On-Ramp”
portion
of the
CWE
websoftware.
site. This area
Submissions:
Wecommunications
welcome articles technology
of interest to the defense
of development
tools used
to build
and
deploy
And of
Every Article
piece of
information and
challenges span infrastructure, trust, competitiveness, and austerity.
the site is focused on providing help to projects on how they can
software community.
mustas
bewell
approved
the there
are gaps in the skills and education of those that manage,
(ICT) hardware—this
includesArticles
computers
as anybydevice
make use of the information about weaknesses to manage their
editorial
board prior
to publication.
Please
Author Guideby Don O’Neill
specify, create, test, and field these software-based products.
that stores,
processes,
or transmits
data—has
an follow
initiallythe
embedsoftware security efforts.
lines, available
at <www.crosstalkonline.org/submission-guidelines>.
Additionally, software-based products are available to atded software
component
that requires follow-on support and
does not pay for submissions. Published articles Finally, the same type of information in this table could be
tackers
study them
and thentag
make
these
products
do
throughout the equipment’s lifecycle.
sustainment
usedwho
to produce
an assurance
for an
executable
code
remain the property of the authors and may be submitted to other
things their creators never intended. Traditionally this has led
of supply chain risk management (SCRM) must
The need for security often exceeds the ability and will of software engineers to The concept
publications. Security agency releases, clearances, and public af-bundle, leveraging ISO/IEC 19770-2:2009 [11] as impleto
calls
for
improved
security
functionality
and
more
rigorous
be
applied
to
both
the
software
and
hardware
components
mented for Software Identification (SWID) Tags [12]. SWID
fairs office approvals are the sole responsibility of the authors and
design secure software architectures, implement secure coding methods, perreview,
and management.
However,
that approach
fails
ICT.organizations.
Because of the way ICT hardware items are
Tagstesting,
can contain
assurance information
to convey
which types
their
form functional security testing, and carefully manage the installation of softwarewithin the
to account
for the
core differences
the engineering
maintained, the supply chain for ongoing sustainment support
of assurance
activities
and efforts between
were undertaken
against
products on various platforms and in different environments.
what
types
of
failure
modes.
The
receiving
enterprise
could
then
of software-based products and other engineering disciplines.
of the software
is often
disconnected
from
the support
thebe requested
Reprints:
Permission
to reprint
or post
articles for
must
by C. Warren Axelrod, Ph.D.
review
this tag and
thatlater
information
against their plan for
Those
differences
arematch
detailed
in this article.
hardware
(e.g.,the
continued
maintenance
contracts
with with
from
author orsoftware
the copyright
holder and
coordinated
howneed
they to
willaddress
use the these
software
and what failure
modes theyas
are
The
differences
has accelerated
third parties
other than the original manufacturer). As a result,
most
concerned
This
would befinancial,
invaluableand
in determining
more
of the
nation’sabout.
critical
industrial,
military casupply chain assurance regarding software requires a slightly
Problems and Mitigation Strategies for Developing
if sufficient
efforts
were taken
in the
those
areas. [Note: This
also
Trademarks
and
Endorsements:
is an authorized
pabilities
rely
on
cyber-space
and
software-based
products
unique
approach
within
the
larger
world
of
SCRM.
and Validating Statistical Cyber Defenses
supports ISO/IEC 15026 assurance cases.]
publication for members of the DoD. Contents of are
34 Upcoming Events
35
MITIGATING RISKS OF COUNTERFEIT AND TAINTED COMPONENTS
NAVAIR Jeff Schwalb
DHS Joe Jarzombek
309 SMXG Karl Rogers
Mitigating Risks of Counterfeit and Tainted
4
Publisher Justin T. Hill
Cover Design by
Article
CoordinatorAND
Heather
Giacalone
MITIGATING
RISKS OF
COUNTERFEIT
TAINTED
COMPONENTS
Kent Bingham
Managing Director David Erickson
Technical Program Lead Thayne M. Hill
Managing Editor Brandon Ellis
Associate Editor Colin Kelly
Art Director Kevin Kiernan
Components
Non-Malicious Taint
Bad Hygiene is as Dangerous to
the Mission as Malicious Intent
Figure 1: Weakness Technical Impacts by Detection Methods
10
15
20
25
30
2
that comprise this expanding cyber world. ICT systems must be
may want to focus on just “low hanging fruit” like banThe development and validation of advanced cyber security technology frequent- Somenot
necessarily the official views of, or endorsed by, the U.S. governdesigned to withstand attacks and offer resilience through betproducts by the the country they come from or
ly relies on data capturing normal and suspicious activities at various system lay-ning suspect
ment, the DoD, the co-sponsors, or the STSC. All product names Managing Risks Attributable To Taint In
ter integrity,
avoidance
of known weaknesses in code, architecof the producer due to their focused nature and
ers. However, getting access to meaningful data continues to be a major hurdlethe ownership
Software
And Hardware
referenced in this issue are trademarks of their companies.
ture, and
design.follows
Additionally,
ICT systems
shouldtobetheir
created
ignore
more
critical
issues
surrounding
the
software
aspect
of
Hardware
the physical
laws applicable
comfor innovation in statistical cyber defense research.
withposition,
designed-in
protection
capabilities
to address unforeseen
ICT like the exploitable vulnerabilities outlined in this article. It is
electrical characteristics,
and construction.
Statistiby Michael Atighetchi, Michael Jay Mayhew, Rachel Greenstadt,
Online Services:
attacks
by making
them intrinsically
more
rugged
and resilient
a misconception that “adding” software assurance to the mix of
cal
process
variations,
logical
errors
of
design,
or
mechanical
For questions or concerns about crosstalkonline.org web content
and Aaron Adler
there are
fewer
ways
to impact
the system.
This
supply chain
concerns and
activities
will add too much
com- at so that
instabilities
may
not be
originally
understood,
but can
be same
studied
or functionality
contact
the webmaster
concern has been expressed by Congress with the inclusion
plexity, thereby
making SCRM
even harder to perform. Some
801-417-3000
or webmaster@luminpublishing.com.
of a definition of “Software Assurance” in Public Law 112-239
organizations and sectors are already developing standards of
While progress has been made in understanding the utility of Earned Schedule care andBack
Section 933 [2] where they directed DoD to specifically address
due-diligence
that directly
address
these
unintended
Issues Available:
Please
phone
or e-mail
us to
(ES) in some small scale and limited studies, a significant analysis of ES in DoDand badsee
software assurance of its systems.
hygiene
types
of issues.
That said,
practices
if back
issues
are available
freesuch
of charge.
acquisition programs is missing.
for avoiding the bad hygiene issues that make software unfit
is
published
six
times
a
year
by
the
U.S.
Air
Force
for
its
intended
purpose
are
not
the
norm
across
most
of
the
Defining
“Taint” and Software Assurance
by Kevin T. Crumrine, Jonathan D. Ritschel, Ph.D., and Edward White, Ph.D.
STSC
in concert
with and
Lumin
Publishing
<luminpublishing.com>.
industries
involved
in creating
supporting
software-based
While there is no concrete definition of what “taint” specifiISSN
2160-1577
(print);
ISSN
2160-1593
(online)
products. Mitigating risk to the mission is a critical objective
cally means within the cyber realm, we would be remiss not to
Earned Schedule 10 Years Later: Analyzing Military Programs
and including software assurance as a fundamental aspect of
SCRM for ICT equipment is a critical component of delivering
mission assurance.
CrossTalk—March/April 2014
4
CrossTalk—March/April 2014
look to the general use of the term, as well as synonyms and
antonyms. Merriam Webster [3] provides a useful point-ofdeparture, as shown in Table 1 below.
Figure 2: Matching Coverage Claims to Your Organization’s Needs
and addressed using general engineering and process improvement methodologies. However, it is clear that software fails from
things other than these causes. As discussed above, software
follows no laws unless their creators impose them and can fail
due to individual implementation mistakes or through the introduction of weaknesses or malicious logic.
Few software developers or systems engineering practitioners
have the training and experience to recognize, consider, and
avoid these weaknesses. Few (if any) tools or procedures are
available to review and test for all weaknesses in a systematic
manner. Developers are rarely provided with criteria about what
types of problems are possible, and what their presence could
mean to the fielded software system and its users.
To manage these risks we cannot just expect to come up
with the “right security requirements.” We also need to provide a
methodology that assists in gaining assurance through the gathering of evidence and showing how that information provides
assurance and confidence that the system development process
addressed the removal or mitigation of weaknesses that could
lead to exploitable vulnerabilities. The changes in revision 4 of
National Institute of Standards and Technology (NIST) Special
Publication 800-53 [13] directly bring assurance into the security posture equation.
CrossTalk—March/April 2014
7
From a Priority List of Weaknesses to
Determining the Needed Detection Methods
Code
Review
CWEs a capability
claims to cover
Static
Analysis
Tool A
Static
Analysis
Tool B
Pen
Testing
Services
Most
Important
Weaknesses
(CWEs)
Which static analysis
tools and Pen Testing
services find the CWEs
I care about?
CISQ Security Measure
Objective
Develop automated source
code measures that predict the
vulnerability of source code to
external attack. Measure based
on the Top 25 in the Common
Weakness Enumeration
Measuring Security by Violated Rules
Structure of ISO 25023 Measures
Structure of CISQ Security Measure
Software Quality Characteristics
Security
Quality Sub-Characteristics
Confidentiality, Authenticity,
Integrity, Accountability, etc.
Software Quality Attributes
Quality Measure Elements
Quality Rule Violations
•
•
•
•
•
•
ISO structure
Examples from CISQ measures
29
Cross-site scripting
SQL injection
Buffer overflow
OS command injection
Unvalidated array
Etc.
Example Security Issue→Rule→Measure
CISQ measure aggregates violations of 19 of the CWE Top 25:
79, 89, 22, 434, 78, 798, 706, 129, 754, 131,
327, 456, 672, 834, 681, 667, 772, 119
Industry
Uptake
CWE
:
$ *%$
!"!% !!"!% &
##!"##($"(!##"#!$($!##!#($!$"""!!)#+
#"#"!!"#"!"##(*!(#*"!$"$#&!!####+
!
! !!
! !!
"!%
"!%
! !
! " ! !!
!!
!
!
"!
!
!
!
#"*#"#"!#!%#'#"#"#(!'#!($#+!(*#!##"
$"(" $*!#($#($$#$"""+#!#!"#($!!)#*($
%$##""#&##!##*##%#!*"$!#(&""#&#"##
##$"""##($!!)#+#!*#"#!"#!#%!!"+
% &
0/$""#(#"#"!$"!""!!!!(
!)#"+!#"!""*&!%!!#$#
##$"#&"!#""*&"
"#
"##(+
!#!#,"
!
! !!
! #
!!!%
! "(
"!
"(
%!
%!
%!
!#
$#
$#
!
" ! '
" (($&#""($!%!#($!$"""+!(%
#*#!(##!####!!#!%###*
!###(#(!#($!$"""+!!*
($"$%$#!"!($!"*$"##!##"*"$!#(
#!"*$"""#"($!#!!"+"#!##""
#*$"""#""#,$"""#
##"!!(###"$#($!#($!
#!!"+
"#!""#0/"#!##(##*##(
&""*!##(##($"+""##$!#(
!##!""*&!""*&##!("#(#
!"&!""+
&&"*%$&
!
!
(*
$*)
%$)($/%$
-%$)$
+$*(+)***%
*)/)*#2
$"+$.*($"
+)()2$*($"
+)()2$
#$)*(*%()5
**!
*%()
.&"%*"*/
**!()$)
)#&"*.*7)
**!)**.&"%*
*)/$*.%*
*(*
$*(&(*(5"#%)*
$/)%+(%*
$$$ *%$
,*%(2$"+$
$*($")%+()5
"##(
$!
!#"!&!
!"#!#-
.
+(*/
!$))
(,"$
**"*/
$ *%$"-)%+(-$$&&"*%$
)$)+$*(+)***%$$*(&(*(5
$ *%$"-)(,(/&(,"$*2
&(*+"("/$"/%5/(%*$
%+$$22&*2%(%
'+()3%##$)3&()()2
()2&(%(#(+#$*)2*5
$ *%$"-)()/*%)%,(-$
.#$$%2+*('+$*"/(*%
)%,(,*)*$5$$()$+00()
$"&**!()$$ *%$"-)5
$"
#&*)
+)$))
#&*)
#&*
&&"*%$4
+)$))&
$ *%$$()+"*
$*"%))%(
%((+&*%$2"!%
%+$*"*/2%(
$"%))5
$ *%$$
)%#*#)"*%
%#&"*%)*
*!%,(5
%$)(*
+)$)),"+%
***
$*&"*%(#
(+$$$*
$*(&(*(5""*
%+")*%"$2
#%2%(
"*5%+"/%+(
(&+**%$
(#1
#
+"$("%
$ *%$0
%-%
(,$*
$ *%$0
)*-/*%$%+*$&&"*%$),+"$("*%
$ *%$)*%,(/**""+)%$*(&(*()"("/
)&(*)+$*(+)**(%#*%##$%('+(/5%(
"")2*)#$)+)$$,(")$""&(&(
)**#$*)$)*%(&(%+()2$,%$/$#
'+()5
+*%#*/$#)$$$-.())*&&"*%$
#/&(%,$)*$*%-*()%#.&"%*"$ *%$
"-).)*5$$()$$%*"-/)($*(&(*()$
,+"*/**$-*($**!-))+))+"5
%%(((%($"$#!)$ *%$"-))(*%)%,(5
(,$*$$ *%$('+()!&$+$*(+)**
)&(*(%#%##$)$'+()5
=5 &(((%&*%$)*%+))
-,%)*
+)%*$*(&(*($*("/%(&(%,)
&(#*(0$*(5(+"-*
)2)+)
)*%(&(%+()2**(&(#*(02+*$)*""
$*(%+$ *%$+$(*%%5
>5 &(#*(0
)$%*,""2/%+)%+"
(+""/)&)&"(*()+)$*)&
)&)/$*.%(**$*(&(*(5!
&(%,)#$/%*))&$(%+*$)5
?5 "#
(%##$2+*)$%*%#&"*$))#$/
&&"*%$)('+()&"(*()$*($&+*5
)&"(*()(('+(2%$"/&&(%)=5$>5
%,-""#!*(+))5!)$
.*$)""((/%-*")*$&+*,"*%$(%+*$)5
.#&"**!$(%)
($)
$(%:=4&&"*%$+))+$*(+)**$*
%$)*(+*%$%*%""%-$,+"$("""4
*($'+(/<97%+$*)
+)*
<89;('+)*3*(#*(5996;9891
+(/(#*(0*%$**
!$*%))*$+(*-/*%)*
&&"*%$+))$*(&(*())"/5%$"/))*%%")$
"&)+(*/$"/)*$*+)%$*(&(*()$*(
**"%-*(%+*&&"*%$5$*(*%$*)*()$
,"**)))+)/(*$.&"%*)**%$(#*
,+"$("*/5
$(%:>!
*(+)*$
(#-%(!)#/()+"*$'+()**()*"",+"$("2
8552($*+(/$+8994
+(/+(/<)))%$3(*+(/
+)*
<8
5996;98961
$ *%$(,$*%$**
%##$
$ *%$(*"
*($"$**/89($(*"
4+*&+*$%$6)&$'+(#$*)8B9
)*$+4&*(%$
$ *%$)*$
!
$((%-)(*%)$48%(8:8<8:5%(.#&"4
.*($"
**&244.#&"3%#4&&4%+$*-0<8%(8:8<8:
$*(/DE%$
$ *%$
)$)*#$$%%*'+()*%(*+($""*
(%()(%#*%+$*)*"5%($(%+)**!)
%+"#%/*%(,$$,%!)*%(&(%+()5
$*(/AB@%$($*
$ *%$
$*(/CC%$%##$
$ *%$
Idaho National Labs SCADA Report
For DoD Software Assurance is defined by 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
free of vulnerabilities
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
DoD Program Protection Plan (PPP)
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
"+*#),#('#',"#++,#('*/+-)(',"/(*$+*#1(*,*,#'
4"(&&(',,$,,*''-&*,#(''%++# #,#('3'#,#,#.5
(*)(*,#('",,)+)&#,*(*!
4"(&&('$'++'-&*,#('3'#,#,#.5(*)(*,#('
",,)+/&#,*(*!
4"(&&('-%'*#%#,#+'0)(+-*+2'#,#,#.5(*)(*,#('
",,)+.&#,*(*!
,( '+' (*&,#('1+,&+!'1
http://www.acq.osd.mil/se/
initiatives/init_pp-sse.html
TECHNICAL CONSIDERATIONS FOR VETTING MOBILE APPLICATIONS (DRAFT)
NIST Special Publication 800-163 (Draft)
Technical Considerations for
Vetting Mobile Applications (Draft)
65
Table of Contents
66
Executive Summary .................................................................................................................... 1
67
1. Introduction .......................................................................................................................... 3
68
1.1 Purpose and Scope .................................................................................................... 3
69
1.2 Audience ..................................................................................................................... 3
70
1.3 Document Structure .................................................................................................... 3
71
2. Software Assurance for Mobile Apps ................................................................................ 5
72
2.1 Challenges of Software Assurance in Mobile Computing ........................................... 5
73
2.2 Software Assurance for Mobile Apps .......................................................................... 6
74
3. Overview of Mobile App Vetting ......................................................................................... 8
Jeffrey Voas
Steve Quirolgico
Christoph Michael
Karen Scarfone
75
3.1
Mobile App Vetting Planning ............................................................................ 8
76
3.2
Existing Security Infrastructure ........................................................................ 9
77
3.2.1 Performance .................................................................................................... 9
78
3.3 Expectation Management ........................................................................................... 9
79
4. Security- and Privacy-Relevant Mobile App Characteristics ........................................ 11
80
5. Mobile App Vetting ............................................................................................................ 13
81
6. Mobile App Testing ............................................................................................................ 15
82
7. App Vetting Tools and Techniques .................................................................................. 21
83
7.1 Designing Analysis Processes .................................................................................. 21
84
7.2 Vetting Source Code Versus Binary Code ................................................................ 21
85
7.3 Selecting Automated Tools ....................................................................................... 23
86
Appendix A— Examples of Mobile App Security Weaknesses ............................................ 25
87
Appendix B— App Power Consumption Testing .................................................................. 27
88
Appendix C— Android Application Vulnerability Types ....................................................... 29
89
Appendix D— iOS Application Vulnerability Types .............................................................. 32
90
Appendix E— Standard Findings Structure ........................................................................... 35
91
Appendix F— Glossary ............................................................................................................ 37
92
Appendix G— Acronyms and Abbreviations ......................................................................... 38
93
Appendix H— References ........................................................................................................ 40
94
v
Definition of Assurance Case
•  A documented body of evidence that
provides a convincing and valid argument
that a specified set of critical claims
regarding a systems properties are
adequately justified for a given application
in a given environment.
© 2014 The MITRE Corporation. All rights reserved.
For internal MITRE use
Assurance Claims with Support of
‘Substantial’ Reasoning
(probably)
CAE
Claim,
Argument,
Evidence
•  Claims are assertions put forward for
general acceptance
Stephen Toulmin, 1958
•  The justification for claim based
is on some grounds, the “specific facts about a precise
situation that clarify and make good for a claim”
•  The basis of the reasoning from the grounds (the facts)
to the claim is articulated. Toulmin coined the term
“warrant” for “substantial argument”. These are
statements indicating the general ways of argument
being applied in a particular case and implicitly relied on
and whose trustworthiness is well established”.
•  The basis of the warrant might be questioned, so
“backing” for the warrant may be introduced. Backing
might be the validation of the scientific and engineering
laws used
GSN
Goal
Statement
Notation
Justification
Solution or sub-goals
Strategy
Goal
Supply Chain Assurance Case Example
ISO/IEC/IEEE 15026:2 Assurance Case
•
•  Sub-parts
Set of structured assurance claims,
–  A high level summary
supported by evidence and reasoning
(arguments), that demonstrates how
–  Justification that product or service is
assurance needs have been satisfied.
acceptably safe, secure, or
dependable
–  Shows compliance with assurance
objectives
–  Rationale for claiming a specified
level of safety and security
–  Provides an argument for the safety and
security of the product or service.
–  Conformance with relevant standards
& regulatory requirements
–  Built, collected, and maintained throughout
the life cycle
–  The configuration baseline
–  Derived from multiple sources
–  Identified hazards and threats and
residual risk of each hazard / threat
–  Operational & support assumptions
System, Software, or Work Product
Make the case for adequate quality/ assurance of the
Quality / Assurance Case
justify belief in
Claims
supports
Arguments
Evidence
is developed for
Quality / Assurance
Factor
Quality / Assurance
Subfactor
Attributes
Clear
Consistent
Complete
Comprehensible
Defensible
Bounded
Addresses all life cycle stages
Object Management Group (OMG)
Systems Assurance Task Force
Claims-Evidence-Arguments Overview
SACM
Structured Assurance
Case Meta-model
Assurance Case
Claims (propositions)
Support of claims Precise expression of propositions
Ontology
(vocabulary)
Inferential support
Evidence
Observable Facts
Collection of evidence
KDM Analytics
The Six Goals of SACM 2.0
•
Improve support for 15026-2
–
•
Improve support for “Goal Structuring Notation”
–
•
•
In order to facilitate the use of structured assurance cases for producing and reviewing ISO/IEC 15026-2
conformant assurance cases, the structured assurance case metamodel needs to more fully support the
constructs and entities in ISO/IEC 15026-2.
In order to facilitate the use of structured assurance cases by the existing community of practitioners across
the world that are currently using Goal Structuring Notation (GSN) and the specific capabilities in GSN for
working with assurance cases, the structured assurance case metamodel needs to more fully support the
constructs and entities in GSN.
Harmonization of Parts
–
In order to facilitate acceptance and successful use of SACM, the argumentation and evidence container
metamodels need to be more consistently aligned and integrated.
–
Areas of focus include elimination of overlap, making useful facilities now available on one side generalized to
be useful on both sides, achieving uniform terminology and consistency, and using common concepts.
Add initial support for Patterns/Templates
–
In order to make the use of assurance cases more practical and efficient for users including those that don't
have in-depth experience within the assurance case domain (e.g., acquisition officials, systems integrators,
auditors, regulators, and tool vendors), the structured assurance case metamodel needs to support the
concept of assurance case patterns and templates.
–
Patterns will provide support to enable reuse and the effective composition of assurance cases along with the
underlying argumentation supporting goals.
–
Templates will provide support for defining/describing constraining conventions that a community may require
for assurance cases within a particular domain due to regulatory requirements or accepted practices in that
domain/industry/community.
•  Improve the modularity and simplicity of SACM
•
Provide for future concepts such as structured expression and other formalisms
Medical Example of Connected and Co-Dependent…
4
5
Example Medical Assurance Case (thanks to GessNet)
4
6
Medical Device Assurance Case (thanks to GessNet)
4
7
OMG’s Structured Assurance Case Metamodel (SACM)
Exchange and Integration
of Assurance Cases
between tools
Identifying Weaknesses in
Capabilities Critical to Mission/
Business Function
Attacks &
Hazards
Weakness #1
Mission/
Business
Function
Capability
sion
Mis ment
ill
Fulf
Weakness #2
Weakness #3
Identifying Weaknesses in
Capabilities Critical to Mission/
Business Function
Attacks &
Hazards
Impact from
Weakness #1
Exploitable Weakness #1
(a vulnerability)
Mission/
Business
Function
Capability
sion
Mis ment
ill
Fulf
Exploitable Weakness #2
(a vulnerability)
Weakness #3
Impact from
Weakness #3
Many Capabilities Support the Mission/Business
Functions
Capability
Capability
Capability
Capability
Hardware
Capability
Software
Processes
People
Supply Chain Activities
CAPEC’s scope is
more than just
software
Assurance on the Management of Weaknesses
Mitigate
Eliminate
Alarm for Attack/Exploit
Block from Attack
Getting Started in Assurance of the Mission/Business Functions…