US Government Software Assurance and Security Initiativesi

SwA and SEC. INITIATIVES 1

Running Head: SwA and SEC. INITIATIVES

United States Government Software Assurance and Security Initiatives

Lindsey Landolfi

Towson University

Software Security

Professor Charles Pak

May 2012


As technology advances, the United States government and society are becoming

increasingly dependent on software services. Increased incorporation of software technologies

into daily life activities presents new opportunities for attackers. Safeguarding software

functionality, for example protecting confidential security information or the controlling the

operations of vital machinery, is essential to the protection of US citizens and critical

infrastructures. It is necessary, especially for government users, to recognize and address the

limitations of software technologies specifically the associated security concerns. This document

provides an overview of the software assurance (SwA) initiatives used within the US federal

government, how SwA measures are evaluated, suggestions to mitigate software security risks,

as well as real-world examples highlighting the potential vulnerabilities of cyber-based systems.

Cyber-attacks are the single greatest source of threats to an organization‟s business

operations, services, and information security. A cyber-attack refers to the exploitation of

hardware and/or software vulnerabilities in order to perform unauthorized actions such as data

theft or manipulation. A cyber-system breach can result in access and malicious use of or

destruction of confidential data, DDoS (distributed denial of service), DoS, and/or other criminal

activities. IT systems are constantly under attack and/or subject to attack; typical threats to IT

systems include viruses, worms, backdoor programs, Trojan horses, and social engineering

tactics. “Software enables and controls the nation‟s critical infrastructure, and in order to ensure

the integrity of key assets within that infrastructure, the software must be reliable and secure.”

(Booz Allen Hamilton, 2008, p.1)

The US government and interacting industries must be prepared for the transition to

cyber-dependent operations. New technological opportunities increase service and operational

efficiency as well as create new opportunities for cyber-based attacks. For organizations


dependent on software to maintain business functionality, the case examples discussed in this

document can be used to help understand existing software vulnerabilities and risk mitigation

measures. If an organization, specifically the US government, is not properly prepared for the

threats to software dependent and cyber-based systems it will result in financial, legal, and

reputational ramifications. If an organization wishes to survive and thrive in a software

dependent environment it is necessary to maintain appropriate SwA measures, network defenses,

strongly enforced security policies, and proper employee security in order to defend against

cyber-system attacks. Security it not simply technology, it is the human implementation,

enforcement, and management of that technology supported by security policy which enables

strong defense.

The Department of Homeland Security (DHS) National Cyber Security Division (NCSD)

Software Assurance (SwA) Program was established in response to the National Strategy to

Secure Cyberspace (A/R 2-14), specifically to promote government SwA efforts such as

software security, integrity, and resiliency. The collaborative efforts of the DHS NCSD SwA

program have produced valuable SwA products and concepts; see Appendix A for a synopsis of

DHS NCSD SwA program contributions. Included among the many resources created by the

DHS NCSD SwA program is a common measurement framework co-sponsored by the

Department of Defense (DoD), DHS, and National Institute of Standards and Technology

Software Assurance, intended to help build security into the Software Development Lifecycle

(SDLC). The goal of the Practical Measurement Framework for Software Assurance and

Information Security is to increase the security and reliability of software and software

dependent systems. It is designed to provide a robust methodology of quantitatively and

qualitatively measuring the effectiveness of an organization‟s software assurance (SwA)


technology, strategy, and protocols. The framework was developed from a SwA viewpoint in

order to guide the adaptation and integration of SwA measurements into existing security

programs. This common measurement framework is based on five widely used and accepted

existing security measurement methodologies; these five industry approaches as well as their

associated measurement specifications and approaches, including commonalities and differences,

are listed under Appendix B; Integrated Measurement Approach, Five Common Industry

Frameworks.

Comprehensive SwA requires interdisciplinary cooperation; security vulnerabilities and

mitigation measures from “other disciplines including project management, process

improvement, quality assurance, training, information security/information assurance, system

engineering, safety, test and evaluation, software acquisition, reliability, and dependability”

(Booz Allen Hamilton, 2008, p.vi) should all be considered in the overall SwA methodology.

The cross-disciplinary concept of SwA is depicted and explained in Appendix C; Cross-

disciplinary Nature of SwA. SwA methodologies and associated measurement frameworks can

be tailored to an organization‟s specific levels of security needs. A SwA model can be not fully

complete due the fact that SwA is a constant and rapidly evolving field and there are many

unknown risk factors. The practical measurement framework provides an initial approach to

SwA and measurement standards and is expected to adapt to industry and technological changes.

SwA is best achieved by integrating security measures and evaluation processes throughout the

SDLC.

To employ the SwA common measurement framework an organization must first

consider the goals and information needs of stakeholders concerned with SwA measurements,

this includes both supplying and acquiring organizations. Different security concerns are


applicable to different stakeholders; Appendix D; SwA Measurement Stakeholder Example

Goals and Information Needs, provides examples of the security and data requirements of

generic SwA stakeholders. Examples of common SwA measurement methodologies, arranged by

stakeholder type, are presented in Appendix E; Example Measures for the Stakeholder Groups.

Once a set of manageable SwA measures have been established they should then be incorporated

into the organization‟s current security evaluation processes. Implemented measures can be

adjusted throughout the SDLC in order to best suit the security and evaluation needs of a project.

Appendix F; Basic Measures Implementation Process, further depicts the basic steps involved in

implementing the measurement framework.

When using the framework, good documentation practices are important to support

consistent and accurate data intake. Reliable data is necessary in order to efficiently use the

measurements for analysis. “Enumerations provide a common language that describes aspects of

SwA, such as weaknesses, vulnerabilities, attacks, and configurations, and by doing so enable

consistent and comparable measures.” (Booz Allen Hamilton, 2008, p.30) Enumerations support

a quantifiable data source therefore enabling more advanced measurements for SwA evaluation;

standard enumerations specific to SwA include Common Vulnerabilities and Exposures (CVE),

Common Control Enumeration (CCE), Common Weakness Enumeration (CWE)

[http://cwe.mitre.org/], and Common Attack Pattern Enumeration and Classification (CAPEC)

[http://capec.mitre.org/]. Enumeration measurements should be adapted the organizational goals,

requirements, and SwA needs. Since the framework provides both quantitative and qualitative

measurements it is possible to evaluate security standards and track progress in a consistent and

realistic manner. Once data has been gathered and analyzed, the documented measurements can

be used to justify changes in security policy or protocols as well as in resource allocation. It is


beneficial to incorporate SwA measurements into the budget allocation of a risk management

strategy in order to promote budget implementation designed to best achieve the desired risk

mitigation results.

To be successful SwA measures must be present in all stages of the SDLC including

acquisition and outsourcing, development, lifecycle support, measurement and information

needs. The DHS NCDS initiatives to build security into the SDLC are presented in the process

agnostic approach, specifically as best practice touchpoints resulting in software artifacts.

Appendix G; Process Agnostic Approach exhibits the DHS NCDS recommended SwA and

security touchpoints to incorporate into secure software lifecycle processes. Additional SwA

related documents and resources are available for free downloading via the Department of

Homeland Security National Cyber Security Division website [https://buildsecurityin.us-

cert.gov/swa/].

SwA is becoming increasingly important to national security efforts since the majority of

software dependent services are virtually interconnected. For example, cyber-communication

systems such as Supervisory Control and Data Acquisition (SCADA) are highly vulnerable; the

probability of a cyber-attack on critical infrastructure (CI) is definite. The ability to control CI

functionality makes energy management systems (EMS), such as SCADA, among the most

likely target for an asymmetric attack; unauthorized access to SCADA is a major vulnerability

since these systems basically control the power systems. This type of attack is relatively cheap to

execute and is associated with catastrophic failures and large scale damages. Additionally,

threats to SCADA dependent systems expose the vulnerability of the increasing

interdependencies between CI sectors as well as the SCADA system.


SCADA is an Industrial Control Systems (ICS) for monitoring and process control

composed of geographically dispersed IT infrastructure, networks, and processes designed to

best manage the data and activities of SCADA dependent systems with real-time data

surveillance and evaluation. SCADA uses cyber-communication networks to connect remote

terminal units (RTU) to the master terminal unit (MTU); secure facilitation of this

communication is vital since many CI sectors are reliant on SCADA automation to maintain

functionality. SCADA dependent U.S. critical infrastructure includes but is not limited to, water

distribution and wastewater collection systems, oil and natural gas pipelines, electrical power

grids, railway transportation systems, nuclear and chemical refineries, and the Public Switched

Network (PSN). Appendix H “shows a single view of a typical SCADA system and its

components consisting of computers, networks, databases, RTUs, and software.” (Lewis, 2006,

p. 225)

Compromise of software and related systems threatens data integrity and business

operations; compromise of a CI system is a direct threat to national homeland security.

Therefore, it is necessary for federal agencies to take action to establish high-level software and

information security controls and policy. Presidential Decision Directive 63 (PDD63) policy

document helped to establish the distribution of SCADA security responsibility. Federal

stakeholders include lead federal agencies specifically the Department of Energy (DOE),

Department of Homeland Security (DHS) National Cyber Security Division (NCSD), as well as

the National Information Assurance Partnership (NIAP) - National Institute of Standards and

Technology (NIST) and National Security Agency (NSA). NIAP provides policy guidance

document designed to promote best-practices in SCADA/CI security for example facilitating

coordinated communication as well as standardization between the various SCADA dependent


CI-ISACs (Information Sharing and Analysis Centers). SCADA security falls under the

Information Technology ISAC (IT - ISAC). The NIAP also delegates CI responsibilities among

the private sector; the Process Control Security Requirements Forum (PCSRF) established

security requirements for the operations of industrial process control systems.

To an extent, security is inherent in Transmission Control Protocol/Internet Protocol

(TCP/IP) communications. “Internet is the sum total of all TCP/IP networks that connect to one

another;” (Lewis, 2006, p.365) therefore TCP/IP is synonymous with internet data

communications such as SCADA and EMS. The structure of the internet makes it resilient to

outages occurring in unrelated parts of the network; complex and decentralized networks of

networks help to contain cascade failures and prevent the complete comprise of internet

broadband supply. Multiple networks, routing systems, and hundreds (conservative estimate) of

ISPs help to ensure the robustness of the US internet. Even the shut-down of a major ISP would

not result in to total comprise of internet broadband supply. It is plausible to shut-down smaller

US networks, as damage to the source router could result in single points of failure. A smaller-

sized network shutdown maybe inconveniencing however the US entire internet network as a

single entity does not face this same vulnerability. The versatility of independently

owned/privately operated of US ISPs inherently supports the redundancy and resilience of the

US internet network. However, SCADA systems are vulnerable to the same threats as any

TCP/IP-based system. Including but not limited to; attacks on operating systems such as DOS

attacks and/or IP Spoofing, application layer attacks such as common viruses, worms, and/or

Trojan horses, as well as key-stroke logging, system hijacking (ie. man-in-the-middle attacks),

data manipulation and/or deletion. A matrix of SCADA security risks and associated impacts are

summarized in Appendix I; SCADA Attack Matrix. Additionally, there is a possibility of an


attack on the physical SCADA communication infrastructure for example, Electro Magnetic

Pulse (EMP) attacks on transmission networks or destroying a critical hub such as a SCADA

facility hosting control servers. The multiple layers comprising SCADA physical and cyber

networks must all be simultaneously protected using general IT risk profile and mitigation tactics

associated with networked software.

SCADA security initiatives resemble compliance to general IT security requirements

including but not limited to threat and vulnerability assessments, security audits, information

assurance tactics such as strong authentication and encryption practices, hardening physical and

virtual security for example the addition of security monitoring in facility (ie. video surveillance)

and incorporation into the software via intrusion detection and prevention systems (IDPS),

firewalls, updates, or patches. Firewalls may be used to prevent systems holding or processing

transactions from accessing any system other than those necessary to carry out its function.

Firewalls should be configured to allow systems to only access other systems directly necessary

to complete the transaction. IDPS may be used to detect or stop an attack in progress should an

attacker get through the firewall, mitigating any damage or compromise of data the attacker may

attempt. IDPS should be deployed behind the firewall and should monitor traffic in multiple

locations. In this way, the IDPS is capable of reporting if any one part of the network should

become compromised. Encryption may be employed to render any stored data indecipherable to

an attacker, but care must be taken to use strong encryption algorithms and keys. Encryption

keys should be carefully protected and only accessible to those who require access. Security

policy and procedures should be based on a combination of open standards and COTS products.

Other techniques include building security directly into the technology through processes

such as the secure systems development lifecycle as well as employing redundancy in order to


increase reliability and security. For example, using redundant connections such as implementing

dual LAN/WAN networks; if WAN networks are compromised the associated devices can

maintain functionality through the alternative LAN network. Also, redundant data-storage for

example the configuration of the primary sever is replicated onto redundant servers;

synchronization technology can help to prevent system faults such as single point failure. In

addition to employing technological prevention measures, SCADA security solutions must also

focus on physical access controls such as using carful hiring practices (ie. background check,

security clearances) and mandatory employee security training. Security policies should be in

place that can direct employees on how to properly maintain a secure environment. An employee

training program that educates employees to recognize an attack and common attack

methodologies should be standard. Additionally, it would prove beneficial to require refresher

classes to be held yearly. Employees should also have easy access to a technical security team to

report any suspicious activity, files, or e-mails. A comprehensive SCADA security strategy must

include software security assurance measures that consider technological as well as human

factors both internally and externally. Appendix J “illustrates the typical corporate network „ring

of defenses‟ and its relationship with the SCADA network.” (Comm. Tech. Inc., 2004, p. 46)

The major focus of any general software security strategy is to secure data and

operational confidentiality, integrity, and availability. Confidentiality refers to the assurance of

authorized disclosure of privy information between parties. Integrity refers to the assurance of

un-manipulated and completed data transmission, specifically to ensure data and operational

accuracy and trustworthiness. Availability refers to the assurance of accessibility and reliability

of data processing, delivery, and storage systems. The National Communications System (NCS),

in response to Executive Order (E.O.) 12472, established National Security and Emergency


Preparedness (NS/EP) and CI protection functional requirements; the NS/EP requirements

address the security needs of SCADA systems. The NS/EP requirements mainly address

technological implementation and functionality; a matrix of NS/EP requirements is presented in

Appendix K. SCADA security policy and protocols strive to achieve the NS/EP requirements

and CI protection missions of the NCS; incorporation of SCADA specific security features

designed to support NS/EP requirements will help to mitigate some of the risks associated with

TCP communications. In addition to the NS/EP requirements it is important to consider the

host‟s operating environment as well as their adherence, evaluation, and modification of

organizational security policies. In both of the two case examples provided the attacks and

associated damages are attributed to a lack of proper security policy and enforcement.

The Stuxnet malware exposed security vulnerabilities in cyber-based industrial control

systems such as SCADA. Stuxnet provides a great example of the potential capabilities

associated with cyber-weapons. Cyber-attacks such as the sophisticated Stuxnet worm could be

used to target CI for example, executing an attack on US industrial software and equipment such

as SCADA systems. Author(s) of Stuxnet and/or individuals with similar knowledge and

expertise have the ability to develop more and potentially more effective viruses and worms

designed to execute coordinated attacks on selective targets. The possible threats associated with

Stuxnet and Stuxnet like malware are a major implication on homeland security considerations

and strategy. It should be noted that Stuxnet was not a networked-based attack, the Iranian

nuclear program uses an air gap security system, therefore it was necessary for Stuxnet to have

either accidental or intentional introduction to the program prior to Stuxnet replication and

consequential program manipulation/compromise. With better/additional security protocols (ie.


blocking access to external ports via a device control policy) and employee security training

Stuxnet infiltration may have been prevented.

A second case that illustrates the problems of lacking proper policies is that of RSA and

its SecurID tokens. RSA SecurID tokens are used to authenticate a user based on the „something

you have‟ principle. The „something you have‟ human authorization approach requires a tangible

object such as a hardware token or an i.d. card. The second aspect of RSA SecurID‟s two-factor

authentication is the „something you know‟ approach, such as password. RSA is “the only

solution that automatically changes your password every 60 seconds.” (RSA SecurID, 2011) The

tokens generate a random number based on the current time and a seed value set at the factory.

So long as the seed value and algorithm to generate the random number are kept secret, it is

impossible for an attacker to calculate the current or next random number in a sequence. The

security offered by SecurIDs led many large corporations and the US government to use RSA

technology to secure their own networks and Virtual Private Networks (VPN). As a company

specializing in security products, RSA was an industry leader in maintaining a secure local

network including defensive countermeasures such as firewalls, IDS/IPS, secure passwords, and

encryption. RSA fell victim to an Advanced Persistent Threat (APT) in 2011; an ATP typically

progresses through different phases each customized to achieve the maximum effect.

RSA's network initially came under a social engineering attack when low level

employees received "two different phishing emails over a two day period" (Rivner, 2011)

containing Excel spreadsheet attachments harboring malicious code. The employees did not have

the necessary security training to advise them not to open the attachments or to forward them to a

security department for examination. When the infected attachments were opened a Trojan was

executed that began an escalation of privilege until the attacker was able to access accounts of


individuals with credential to access to the database containing the seeds used for initializing the

SecurID tokens. See Appendix L for a visual of the various stages of the ATP attack strategy on

RSA. Additionally, the algorithm used to generate the random number from the seed was also

compromised rendering the SecurID tokens vulnerable. Shortly after the RSA attack, "several

large defense contractors" (Diodati, 2011) were attacked and had confidential data removed from

their systems.

RSA utilized the latest in security technology enabling the company's Computer Incident

Response Team to detect and stop the attack quickly, but not quickly enough to stop the attackers

from obtaining confidential data. In RSA's case it was not a lack of technology but instead a lack

of policy on training employees to recognize threats and procedures for non-technical employees

to confirm or report those threats that lead to the data breach. A policy defining the amount of

training employees receive, what types of threats they should be trained to watch for, and ways

for non-technical employees to report suspicious e-mails could have prevented the initial attack.

The RSA case highlights the threats of outsourcing; a client and their operations are dependent

on the security measures of a security technology provider.

Developing, enforcing, and maintaining an applicable and robust security policy is vital

to security efforts of both government and private sectors. In response to increased security

needs and standards, government and private initiatives to support SwA have drastically

increased over the past few years. Numerous guidance programs, assessments, and standards

have been developed by both government and private sectors to address the issue of software

security assurance. Major government and private SwA initiatives are categorized and listed

under Appendix M; further elaboration on the listed initiatives is available at

[http://iac.dtic.mil/iatac/download/security.pdf]. Additionally, the MITRE Corporation, with


DHS sponsorship, complied a free collection of information security data standards and industry

security initiatives as a service for the secure cyber industry and community; the “Making

Security Measureable” is a living document and is available at

[http://measurablesecurity.mitre.org/list/index.html]. The document lists and elaborates on the

informational building blocks for developing and supporting SwA and security specifically

enumerations (standards), languages (encoding), repositories (storage), and security tools such as

assessment methodologies. No single building block can successfully prevent or mitigate attacks,

but when properly combined together into a comprehensive security plan used throughout the

SDLC they can efficiently support and defend SwA and security initiatives.

References:

Booz Allen Hamilton. (2008, October 1). Practical measurement framework for software
assurance and information security (N. Bartol, Ed.) (Version 1.0). Co-sponsored by
Department of Defense, Department of Homeland Security, and National Institute of
Standards and Technology Software Assurance Measurement Working Group website:
https://buildsecurityin.us-cert.gov/swa/downloads/SwA_Measurement.pdf

Communication Technologies, Inc. (2004, October). Supervisory Control and Data Acquisition
(SCADA) Systems (TECH INFO BULLETIN 04-1). Retrieved from National
Communications System website:
http://www.ncs.gov/library/tech_bulletins/2004/tib_04-1.pdf

Diodati, M. (2011, June 2). The seed and the damage done: RSA SecurID [Web log post].
Retrieved from Gartner: http://blogs.gartner.com/mark-diodati/2011/06/02/
the-seed-and-the-damage-done-rsa-securid/

Lewis, T. (2006). Critical infrastructure protection in homeland security: defending a
networked nation. Hoboken, New Jersey: John Wiley & Sons, Inc.

RSA SecurID. (2011). Securing your future with two-factor authentication. Retrieved from EMC
Corporation website: http://www.rsa.com/node.aspx?id=1156


Appendix A;
The Department of Homeland Security (DHS) National Cyber Security Division (NCSD)
Software Assurance (SwA) Program Contributions
Build Security In -https://buildsecurityin.us-cert.govand SwAcommunity resources &
info clearinghouse
SwA Common Body of Knowledge (CBK) & Glossary Organization of SwSysSecurity
Principles/Guidelines SwADevelopers' Guide on Security-Enhancing SDLC
Software Security Assurance State of the Art Report Systems Assurance Guide (via
DoDand NDIA)
SwA-related standards –ISO/IEC JTC1 SC7/27/22, IEEE CS, OMG, TOG, & CMM-
based Assurance
Practical Measurement Framework for SwA/InfoSecMaking the Business Case for
Software Assurance
SwAMetrics & Tool Evaluation (with NIST) SwAEcosystem w/ DoD, NSA, NIST,
OMG & TOG NIST Special Pub 500 Series on SwATools
Common Weakness Enumeration (CWE) dictionary Common Attack Pattern
Enumeration (CAPEC)
SwA in Acquisition: Mitigating Risks to Enterprise Software Project Management for
SwA SOAR
Jarzombek, J., PMP, CSSLP. (2009, July 9). Collaboratively advancing strategies to mitigate
software supply chain risks. In Software assurance a strategic initiative of the U.S.
Department of Homeland Security to promote integrity, security, and reliability in
software. Retrieved from NIST, DHS NCSD websites: http://csrc.nist.gov/groups/
SMA/ispab/documents/minutes/2009-07/ispab_july09-jarzombek_swa-supply-
chain.pdf

Appendix B;
Integrated Measurement Approach, Five Common Industry Frameworks
Draft National Institute of Standards and Technology (NIST) Special Publication (SP)
800-55, Revision 1, Performance Measurement Guide for Information Security
International Organization for Standardization (ISO)/International Electrotechnical
Commission (IEC) 27004 Information technology – Security techniques - Information
security management measurement
ISO/IEC 15939, System and Software Engineering - Measurement Process, also known
as Practical Software and System Measurement (PSM)
CMMI®22 (Capability Maturity Model Integration) Measurement and Analysis Process
Area
CMMI® GQ(I)M – Capability Maturity Model Integration Goal Question Indicator
Measure.

“These methodologies were selected because of their widespread use within the software and
system development community (PSM and CMMI®) and information security community
(NIST). The ISO/IEC standard was selected due to the broad industry use of the corresponding
requirements standard – ISO/IEC 27001, Information Security Management System-
Requirements which should facilitate swift acceptance of ISO/IEC 27004.”


Synopsis of Common Measure Specifications:



Appendix C;
Cross-disciplinary Nature of SwA

“SwA measurement can leverage measures and measurement methods and techniques already
established in those disciplines (listed in the diagram above) and adapt them to SwA.”

Appendix D;
SwA Measurement Stakeholder Example Goals and Information Needs
Supplier
• Identify and prioritize defects in the design, architecture, and code to reduce risks of future
exploitation of software
• Understand the level of assurance vs. residual risk associated with making decisions at each
phase of the SDLC
• Identify software defects that may be exploited in the future
• Determine if SwA and security requirements are being planned and implemented
• Reduce opportunity for malicious software and undesirable behaviors
• Ascertain that defects have been appropriately addressed in a timely manner
• Monitor planning and implementation of SwA and security activities in SDLC


• Understand organization‟s strengths and weaknesses in SwA
• Ascertain that security is integrated into the SDLC as early as possible
• Identify appropriate staffing required to guarantee on time delivery that would appropriately
address SwA needs
• Enable quantifiable comparison with competitors to enhance organization‟s reputation and
achieve product and service differentiation from competition
• Ascertain understanding of operational environment and integration of accidental and
intentional use, misuse, abuse, and threat considerations into the SDLC activities
• Identify causes of poor design and coding practices that may be introducing vulnerabilities into
software
• Demonstrate effectiveness and repeatability of assurance processes
Acquirer
• Cost effectively integrate SwA considerations into the acquisition and development lifecycle
• Ascertain that contracting officers have a good understanding of information security
requirements of the Federal Acquisition Regulation (FAR)
• Validate that contracting officers request assistance from information security specialists when
required
• Validate that requirements for compliance with FISMA, OMB A-130, Appendix III, and NIST
standards and guidelines have been integrated into procurement language
• Gain insight into how the software to be acquired will impact the organization‟s SwA and
security posture
• Validate that SwA considerations are included in the procurement
• Validate that SwA requirements defined in the RFP and in the contract have been satisfied
throughout product and service delivery
• Ascertain that the supplier has a process for testing and reviewing software for vulnerabilities
that has been and will be applied throughout the life of the contract
• Ascertain that the delivered product arrives and performs as expected
• Ascertain that the supplier has imposed appropriate SwA practices on its own suppliers
• Ascertain the integrity of COTS and open source packages
• Ascertain SwA requirements are explicitly addressed in a solicitation and considered during the
evaluation process
• Verify that SwA requirements are integrated into SwA Requirements
Document and implemented in the system
• Assure that the staff delivering products and services are qualified to implement SwA practices
• Monitor impact of SwA and security on business and mission support
Executive
• Understand and manage risks created by software development, acquisition, and operation
• Establish costs and likelihood of breaches (e.g., loss of revenue, opportunity costs, loss of
credibility, legal consequences)
• Establish cost of remediation activities
• Establish benefits of SwA
• Compare costs of building SwA in vs. correcting it after the fact
• Compare risks across different vendor or custom products
• Gain insights into aspects of overall SwA and security posture of the organization or its
component(s)
• Understand the impact of SwA on regulatory compliance


Practitioner
• Understand impact of SwA and security on business and mission support
• Identify vulnerabilities exploitation of which would have an unacceptable impact on the
mission
• Gain insight into the potential and actual cost of vulnerabilities in software (e.g., costs of
leaving vulnerabilities or removing them)
• Provide inputs into risk management
(Booz Allen Hamilton, 2008, p. 9)

Appendix E;
Example Measures for the Stakeholder Groups
Example Supplier Measures


Example Supplier Measures


Example Executive Measures


Example Practitioner Measures



Appendix F;
Basic Measures Implementation Process



Appendix G;
Process Agnostic Approach
“The process agnostic approach incorporates security into each basic phase of software
development. The best practices and methods described are applicable to any and all
development approaches as long as they result in the creation of software artifacts.”

The Department of Homeland Security (DHS) National Cyber Security Division (NCSD). (n.d.).
Process Agnostic Navigational View. Retrieved from DHS NCSD The Build Security In
Software Assurance Initiative (BSI) website: https://buildsecurityin.us-cert.gov/bsi/438-
BSI.html#


Appendix H;
Representation of Typical SCADA System

(RTU) = Remote Terminal Unit
Lewis, T. (2006). Critical infrastructure protection in homeland security: defending a
networked nation. (pp.225) Hoboken, New Jersey: John Wiley & Sons, Inc.

Appendix I;
SCADA Attack Matrix


(SCADA) Systems (TECH INFO BULLETIN 04-1). (pp. 42) Retrieved from National


Appendix J;
Relationship Between Corporate and SCADA Networks


Appendix K;
Matrix of National Security and Emergency Preparedness (NE/EP) Requirements


Appendix L;
The Various Stages of the ATP Attack Strategy on RSA

Rivner, U. (2011, April 1). Anatomy of an attack [Web log post]. Retrieved from RSA:
http://blogs.rsa.com/rivner/anatomy-of-an-attack/

Appendix M;
Software Assurance Initiatives, Activities, and Organizations
US Government Initiatives
o DoD Software Assurance Initiative
 Tiger Team Activities (participants; OUSD/AT&L, ASD/NII, NDIA,
AIA, GEIA, OMG)
o The National Security Agency (NSA) Center for Assured Software (CAS)
 The Code Assessment Methodology Project (CAMP)
o DoD Anti-Tamper/Software Protection Initiative
o DSB Task Force on Mission Impact of Foreign Influence on DoD Software
o Global Information Grid (GIG) Lite
o NRL The Center for High Assurance Computing Systems (CHACS)
o DISA (CIAE) Application Security Project
o Other DoD Initiatives
 DoDIIS Software Assurance Initiative (ESI-3A of DIA)
 US Army CECOM Software Vulnerability Assessments and Malicious
Code Analyse
 Air Force Application Security Pilot and Software Security Workshop
o DHS Software Assurance Program
 Software Assurance Working Groups
 Other Products and Activities (US-CERT BuildSecurityIn Portal, Software
Assurance Landscape)


o NIST Software Assurance Metrics and Tool Evaluation (SAMATE) program
o The National Aeronautics and Space Administration (NASA) Reducing Software
Security Risk (RSSR) program
Private Sector Initiatives
o Open Web Application Security Project (OWASP)
 Tools; WebGoat & WebScarab
o The OMG SwA Special Interest Group (SIG)
o Web Application Security (WASC)
o The Application Security Industry Consortium (AppSIC)
o The Secure Software Forum (SSF)
 “State of the Industry” White Paper
 Application Security Assurance Programs (ASAP)
o Task Force on Security Across the Software Development Life Cycle; DHS
o CS&C NCSD co-sponsored National Cyber Security Summit
o New Private Sector Initiatives; Software Assurance Consortium
Standards Activities
o IEEE Revision of ISO/IEC 15026: 2006
o IEEE Standard. 1074-2006
o ISO/IEC Project 22.24772
o ISO/IEC TR 24731
o IEEE Standard P2600 Section 9.9.2
Further elaboration on the listed initiatives is available at:
Information Assurance Technology Analysis Center (IATAC) Data and Analysis Center for
Software (DACS). (2007, July 31). Software Security Assurance State-of-the-Art Report
(SOAR). Retrieved from The Defense Technical Information Center (DTIC) website:
http://iac.dtic.mil/iatac/download/security.pdf

US Government Software Assurance and Security Initiativesi

More Related Content

What's hot

Viewers also liked

Similar to US Government Software Assurance and Security Initiativesi

More from Lindsey Landolfi

Recently uploaded

US Government Software Assurance and Security Initiativesi