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

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

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

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)

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 - https://buildsecurityin.us-cert.gov 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.

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

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

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”)

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

CWE Web Site http://cwe.mitre.org

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

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

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)

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

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

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 (http://www.cnss.gov/Assets/pdf/cnssi_4009.pdf) throughout the Lifecycle Including design, coding, testing, deployment, configuration and operation

Automation is one piece of the SwA puzzle.

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?

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

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

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

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

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?

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

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?

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

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

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?

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

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

Discussion