1. Software Assurance: Building Security In
TGDC Winter Meeting, 16 December 2011
Leveraging DHS/DoD/NIST Software Assurance Efforts for Voting Standards
Joe Jarzombek, Director of Software Assurance,
DHS National Cyber Security Division

2. Outline
Short background on DHS/DoD/NIST Software Assurance Forums , Workshops and Products
Focus on the Common Weakness Enumeration (CWE) and Common Attack Pattern Enumeration (CAPEC) ITU draft standards
Applicability of CWE and CAPEC to voting security
Creating a “vignette” for voting

3. Critical Considerations
Software is the core constituent of modern products and services – it enables functionality and business operations
Dramatic increase in mission risk due to increasing:
Software dependence and system interdependence (weakest link syndrome)
Software size & complexity (obscures intent and precludes exhaustive test)
Outsourcing and use of un-vetted software supply chain (COTS & custom)
Attack sophistication (easing exploitation)
Reuse (unintended consequences increasing number of vulnerable targets)
Number of vulnerabilities & incidents with threats targeting software
Risk of asymmetric attacks and threats
Increasing awareness and concern
Software and the processes for acquiring and developing software represent a material weakness

4. Defining Software Assurance
Software Assurance (SwA) is the level of confidence that software is free from vulnerabilities, either intentionally designed into the software or accidentally inserted at any time during its life cycle, and that the software functions in the intended manner (from CNSS 4009 IA Glossary)

5. Products and Contributions
Software Assurance Forum and Working Groups
… encourage the production, evaluation and acquisition of more secure and resilient software through targeting:
People
Processes
Technology
Acquisition
Developers and users education & training
Sound practices, standards, & practical guidelines for secure software development
Security test criteria, measurement, diagnostic tools, common languages & enumerations, SwA Research & Development
Software security improvements through due-diligence questions, specs and guidelines for acquisitions/ outsourcing
Products and Contributions
Build Security In - and SwA community resources & info clearinghouse
SwA Common Body of Knowledge (CBK) & Glossary Organization of SwSys Security Principles/Guidelines SwA Developers' Guide on Security-Enhancing SDLC
SwA Curriculum Project: Masters and Undergraduate
Software Security Assurance State of the Art Report
Systems Assurance Guide, via DoD and National Defense Industrial Association (NDIA)
SwA-related standards – ISO/IEC JTC1 SC7/27/22, IEEE CS, OMG, TOG, & CMM-based Assurance
Practical Measurement Framework for SwA/InfoSec
Making the Business Case for Software Assurance
SwA Metrics & Tool Evaluation (SAMATE) with NIST, SwA Ecosystem w/ DoD, NSA, NIST, OMG & TOG NIST Special Pub 500 Series on SwA Tools
Security Automation Enumerations & Languages (CVE, OVAL, CWE, CAPEC, MAEC, CybOX), scoring systems, and risk analysis capabilities
SwA in Acquisition: Mitigating Risks to Enterprise
Software Project Management for SwA State of the Art
Report (SOAR)
* SwA Forum is part of Cross-Sector Cyber Security Working Group (CSCSWG) established under auspices of the Critical Infrastructure Partnership Advisory Council (CIPAC) that provides legal framework for participation.

7. How can the Software Assurance Community
Contribute to Voting? Through Standards!
The Voluntary Voting System Guidelines (VVSG) leverages standards wherever possible in specifying requirements for voting system quality assurance (ISO 9000), workmanship (ASTM), common data format (IEEE P1622) and other areas
Standards promote quality, transparency, interoperability and testability in voting systems for stakeholders, including:
Voting system manufacturers
Voting system testing laboratories
States that acquire those systems
The software assurance community has developed a suite of industry standards in support of software weakness understanding and automated analysis. We focus on two ITU draft standards that could further strengthen VVSG with respect to security, integrity and privacy, in particular:
The Common Weakness Enumeration (CWE),
The Common Attack Pattern Enumeration and Classification (CAPEC)
VVSG defines requirements

8. What is a Weakness?
A (software) weakness is a property of software/ systems that, under the right conditions, may permit unintended or unauthorized behavior

9. What is a Vulnerability?
A (software) vulnerability is a collection of one or more weaknesses that contain the right conditions to permit unauthorized parties to force the software to perform unintended behavior (a.k.a. “is exploitable”)

10. An Opportunity to Embrace an Emerging Set of Standards that Strengthens VVSG
The Common Weakness Enumeration (CWE) is a (consensus built) dictionary of software weaknesses
Funded through DHS National Cyber Security Division
6 years ago, there was no CWE
Today the software assurance community “speaks CWE”
31 organizations
53 products and services
800+ software weaknesses (throughout the Software Development Lifecycle) defined and documented
Voted on at last ITU-T Study Group 17 Question #4 Meeting in Geneva, August 2011; will be finalized in February 2012

11. CWE Web Site

12. CWE Content Each CWE entry includes: Description
SDL time of introduction
Common consequences
Likelihood of exploit
Detection methods
Examples (in source code)
Mitigations
Relationship to other weaknesses (parent, child, sibling)
Related attack patterns , described in the Common Attack Pattern Enumeration and Classification (CAPEC)
White box definition (lower-level, structural description)
Common Vulnerability Enumerations (CVEs) with this “root cause” weakness

13. An Example of Mapping a CWE as a
Normative Reference in VVSG Requirements
VVSG 1.1/2.0 – “If stack overflow does not automatically result in an exception, the application logic shall explicitly check for and prevent stack overflow. “
CWE-400: Uncontrolled Resource Consumption (‘Resource Exhaustion’)
VVSG 1.1/2.0 – “If the programming language does not provide automatic run-time detection of numeric overflow, all arithmetic operations that could potentially overflow the relevant data type shall be checked for overflow.”
CWE-190: Integer Overflow or Wraparound

14. CWE Promotes Better Understanding of and Automated Verification of Software Weaknesses
VVSG can use CWE in its normative descriptions of “non-conformant” weaknesses in software
A common (standardized) lexicon of security automation languages and enumerations facilitates:
As a reference: greater (human) understanding of software weaknesses, vulnerabilities, attacks and mitigations through common terminology and concepts
In automated tooling: machine verification through consumption and understanding of that lexicon, and as a common language for reporting results
This requires machine-readable, formalized definitions of CWE (an effort underway in the SwA Technology/Tools Working Group)

15. CWE and Tool “Effectiveness” Testing, Another Resource for Voting System Assurance
DHS and NIST (through SAMATE) are developing a CWE Compatibility Effectiveness Testing Program for software assurance tools:
To determine how effectively automated software tools (in particular, source code analysis tools) can identify individual CWEs in source code
VVSG 1.1/2.0 focuses on “integrity” CWEs
This testing program will provide users of tools such as voting system manufacturers and Voting System Testing Laboratories (VSTLs) with increased confidence that the tools that they use truly identify the kinds of weaknesses that are “disallowed” in voting system software
Dr. Paul Black (NIST) is spearheading this project

16. A Complementary Standard to CWE: CAPEC http://capec.mitre.org
The Common Attack Pattern Enumeration and Classification (CAPEC) is a complementary (draft) ITU standard to CWE for describing (with a similar level of detail as CWE) known patterns of cyber attack. Information for each attack type includes:
Description
Related CWE
Attack prerequisites
Likelihood of exploit
Method of attack
Resources required
Probing techniques
Indicators – Warnings of attack
Related attack patterns
Related security principles
Confidentiality/Availability/Integrity (CAI) impact
Together, CWE and CAPEC provide a foundation of information to the security analyst as to the nature of a particular weakness, as well as how that weakness might be exploited maliciously

17. Leveraging CWE in Security Assurance Automation
Software Assurance
The level of confidence that software is free from vulnerabilities, either intentionally designed into the software or accidently inserted at anytime during its life cycle and that the software functions as intended. Derived From: CNSSI-4009
Automation
Languages, tools, enumerations and repositories
Committee on National Security Systems (CNSS) Instruction Number 4009, April 2010 (
throughout the Lifecycle
Including design, coding, testing, deployment, configuration and operation

18. Automation is one piece
of the SwA puzzle.

19. Where can automation help - today?
What is the context?
Where can automation help - today?
What problems are we trying to solve?
Where do we start?

20. S: The set of all software in existence at some point in time
Notional W
W: The set of all instances of software weaknesses in S

21. Wd: The set of all discovered software weaknesses in W
Notional W Wd
Wd: The set of all discovered software weaknesses in W

22. V: The set of all vulnerabilities in W
Notional W Wd V
V: The set of all vulnerabilities in W

23. Vd: The set of all discovered vulnerabilities in V
Notional W Wd V Vd
Vd: The set of all discovered vulnerabilities in V

24. Weaknesses we really care about
For the software we’re responsible for
Notional W Wd
Weaknesses we really care about
How do we identify these?
which weaknesses are most important?

25. Lists are a good start but they are designed to be broadly applicable
Prioritizing weaknesses to be mitigated
OWASP Top 10
CWE/SANS Top 25
Lists are a good start but they are designed to be broadly applicable
We would like a way to specify priorities based on business/mission risk

26. Common Weakness Risk Analysis Framework (CWRAF)
How do I identify which of the 800+ CWE’s are most important for my specific business domain, technologies and environment?
Common Weakness Scoring System (CWSS)
How do I rank the CWE’s I care about according to my specific business domain, technologies and environment?
How do I identify and score weaknesses important to my organization?

27. Common Weakness Risk Analysis Framework (CWRAF)
Example Weightings
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
W1=0
W2=0
W3=10
W4=4
W5=10
W6=0
W7=0
W8=0
Layers
1. System
2. Application
3. Network
4. Enterprise
Technical Impact Scorecard
Multiple pieces – we’ll focus on “Vignettes”

28. and Communication Technology (ICT) Applications in various Domains
Leveraging Vignettes in Cyber Security Standardization for Key Information
and Communication Technology (ICT) Applications in various Domains
Common Weakness Risk Assessment Framework uses Vignettes with Archetypes to identify top CWEs in respective Domain/Technology Groups

29. Most Important Weaknesses
“Vignette”
CWSS
Scoring Engine
CWSS
Score
CWE 97
CWE-79 95
CWE-78 94
CWE-22
CWE-434
CWE-798 93
CWE-120
CWE-250 92
CWE-770 91
CWE-829
CWE-190
CWE-494 90
CWE-134
CWE-772
CWE-476
CWE-131 … W Wd
Most Important Weaknesses
User-defined cutoff
CWRAF/CWSS in a Nutshell

30. Creating a Voting “Vignette”
Some questions that a Voting vignette may help answer:
What CWEs are “disallowed” in VVSG?
What are the most common CWEs identified in test lab, red team and source code analysis reports of voting systems?
What CWEs have been identified in test lab, red team and source code analysis reports, but are NOT mentioned in VVSG?
What are the differences in CWEs for polling-place (vs. internet) voting system architectures?

31. Potential Benefit of a Voting Vignette To EAC/TGDC/NIST
A way to apply risk analysis to weaknesses (as opposed to vulnerabilities) in voting system software
A way to prioritize potential weaknesses in voting system associated with (more serious) reported vulnerabilities and therefore
A way to identify and address these types of weaknesses early in the manufacturer’s development process for the voting system

32. Summary
DHS/DoD/NIST Software Assurance Forums and Working Groups provide a broad resource of assurance activities across process, people, technology and acquisition
In particular, the CWE and CAPEC ITU standards can be leveraged to strengthen VVSG in defining and automated detection of software weaknesses
A voting “vignette” is an opportunity to explore:
What software weaknesses are most important, and
What software weaknesses are prevalent in today’s voting systems, versus what is identified as important in VVSG
How weakness priorities change, based upon different voting system architectures

33. Discussion