US Government Software Assurance and Security Initiativesi


Published on

Published in: Technology
  • Be the first to comment

  • Be the first to like this

US Government Software Assurance and Security Initiativesi

  1. 1. SwA and SEC. INITIATIVES 1Running Head: SwA and SEC. INITIATIVES United States Government Software Assurance and Security Initiatives Lindsey Landolfi Towson University Software Security Professor Charles Pak May 2012
  2. 2. SwA and SEC. INITIATIVES 2 As technology advances, the United States government and society are becomingincreasingly dependent on software services. Increased incorporation of software technologiesinto daily life activities presents new opportunities for attackers. Safeguarding softwarefunctionality, for example protecting confidential security information or the controlling theoperations of vital machinery, is essential to the protection of US citizens and criticalinfrastructures. It is necessary, especially for government users, to recognize and address thelimitations of software technologies specifically the associated security concerns. This documentprovides an overview of the software assurance (SwA) initiatives used within the US federalgovernment, 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 businessoperations, services, and information security. A cyber-attack refers to the exploitation ofhardware and/or software vulnerabilities in order to perform unauthorized actions such as datatheft or manipulation. A cyber-system breach can result in access and malicious use of ordestruction of confidential data, DDoS (distributed denial of service), DoS, and/or other criminalactivities. IT systems are constantly under attack and/or subject to attack; typical threats to ITsystems include viruses, worms, backdoor programs, Trojan horses, and social engineeringtactics. “Software enables and controls the nation‟s critical infrastructure, and in order to ensurethe 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 tocyber-dependent operations. New technological opportunities increase service and operationalefficiency as well as create new opportunities for cyber-based attacks. For organizations
  3. 3. SwA and SEC. INITIATIVES 3dependent on software to maintain business functionality, the case examples discussed in thisdocument can be used to help understand existing software vulnerabilities and risk mitigationmeasures. If an organization, specifically the US government, is not properly prepared for thethreats to software dependent and cyber-based systems it will result in financial, legal, andreputational ramifications. If an organization wishes to survive and thrive in a softwaredependent environment it is necessary to maintain appropriate SwA measures, network defenses,strongly enforced security policies, and proper employee security in order to defend againstcyber-system attacks. Security it not simply technology, it is the human implementation,enforcement, and management of that technology supported by security policy which enablesstrong defense. The Department of Homeland Security (DHS) National Cyber Security Division (NCSD)Software Assurance (SwA) Program was established in response to the National Strategy toSecure Cyberspace (A/R 2-14), specifically to promote government SwA efforts such assoftware security, integrity, and resiliency. The collaborative efforts of the DHS NCSD SwAprogram have produced valuable SwA products and concepts; see Appendix A for a synopsis ofDHS NCSD SwA program contributions. Included among the many resources created by theDHS NCSD SwA program is a common measurement framework co-sponsored by theDepartment of Defense (DoD), DHS, and National Institute of Standards and TechnologySoftware Assurance, intended to help build security into the Software Development Lifecycle(SDLC). The goal of the Practical Measurement Framework for Software Assurance andInformation Security is to increase the security and reliability of software and softwaredependent systems. It is designed to provide a robust methodology of quantitatively andqualitatively measuring the effectiveness of an organization‟s software assurance (SwA)
  4. 4. SwA and SEC. INITIATIVES 4technology, strategy, and protocols. The framework was developed from a SwA viewpoint inorder to guide the adaptation and integration of SwA measurements into existing securityprograms. This common measurement framework is based on five widely used and acceptedexisting security measurement methodologies; these five industry approaches as well as theirassociated measurement specifications and approaches, including commonalities and differences,are listed under Appendix B; Integrated Measurement Approach, Five Common IndustryFrameworks. Comprehensive SwA requires interdisciplinary cooperation; security vulnerabilities andmitigation measures from “other disciplines including project management, processimprovement, quality assurance, training, information security/information assurance, systemengineering, safety, test and evaluation, software acquisition, reliability, and dependability”(Booz Allen Hamilton, 2008, 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 canbe tailored to an organization‟s specific levels of security needs. A SwA model can be not fullycomplete due the fact that SwA is a constant and rapidly evolving field and there are manyunknown risk factors. The practical measurement framework provides an initial approach toSwA 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 theSDLC. To employ the SwA common measurement framework an organization must firstconsider the goals and information needs of stakeholders concerned with SwA measurements,this includes both supplying and acquiring organizations. Different security concerns are
  5. 5. SwA and SEC. INITIATIVES 5applicable to different stakeholders; Appendix D; SwA Measurement Stakeholder ExampleGoals and Information Needs, provides examples of the security and data requirements ofgeneric SwA stakeholders. Examples of common SwA measurement methodologies, arranged bystakeholder 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 incorporatedinto the organization‟s current security evaluation processes. Implemented measures can beadjusted 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 inimplementing the measurement framework. When using the framework, good documentation practices are important to supportconsistent and accurate data intake. Reliable data is necessary in order to efficiently use themeasurements for analysis. “Enumerations provide a common language that describes aspects ofSwA, such as weaknesses, vulnerabilities, attacks, and configurations, and by doing so enableconsistent and comparable measures.” (Booz Allen Hamilton, 2008, p.30) Enumerations supporta 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)[], and Common Attack Pattern Enumeration and Classification (CAPEC)[]. Enumeration measurements should be adapted the organizational goals,requirements, and SwA needs. Since the framework provides both quantitative and qualitativemeasurements it is possible to evaluate security standards and track progress in a consistent andrealistic manner. Once data has been gathered and analyzed, the documented measurements canbe used to justify changes in security policy or protocols as well as in resource allocation. It is
  6. 6. SwA and SEC. INITIATIVES 6beneficial to incorporate SwA measurements into the budget allocation of a risk managementstrategy in order to promote budget implementation designed to best achieve the desired riskmitigation results. To be successful SwA measures must be present in all stages of the SDLC includingacquisition and outsourcing, development, lifecycle support, measurement and informationneeds. The DHS NCDS initiatives to build security into the SDLC are presented in the processagnostic approach, specifically as best practice touchpoints resulting in software artifacts.Appendix G; Process Agnostic Approach exhibits the DHS NCDS recommended SwA andsecurity touchpoints to incorporate into secure software lifecycle processes. Additional SwArelated documents and resources are available for free downloading via the Department ofHomeland Security National Cyber Security Division website []. SwA is becoming increasingly important to national security efforts since the majority ofsoftware dependent services are virtually interconnected. For example, cyber-communicationsystems such as Supervisory Control and Data Acquisition (SCADA) are highly vulnerable; theprobability of a cyber-attack on critical infrastructure (CI) is definite. The ability to control CIfunctionality makes energy management systems (EMS), such as SCADA, among the mostlikely target for an asymmetric attack; unauthorized access to SCADA is a major vulnerabilitysince these systems basically control the power systems. This type of attack is relatively cheap toexecute and is associated with catastrophic failures and large scale damages. Additionally,threats to SCADA dependent systems expose the vulnerability of the increasinginterdependencies between CI sectors as well as the SCADA system.
  7. 7. SwA and SEC. INITIATIVES 7 SCADA is an Industrial Control Systems (ICS) for monitoring and process controlcomposed of geographically dispersed IT infrastructure, networks, and processes designed tobest manage the data and activities of SCADA dependent systems with real-time datasurveillance and evaluation. SCADA uses cyber-communication networks to connect remoteterminal units (RTU) to the master terminal unit (MTU); secure facilitation of thiscommunication is vital since many CI sectors are reliant on SCADA automation to maintainfunctionality. SCADA dependent U.S. critical infrastructure includes but is not limited to, waterdistribution and wastewater collection systems, oil and natural gas pipelines, electrical powergrids, railway transportation systems, nuclear and chemical refineries, and the Public SwitchedNetwork (PSN). Appendix H “shows a single view of a typical SCADA system and itscomponents consisting of computers, networks, databases, RTUs, and software.” (Lewis, 2006,p. 225) Compromise of software and related systems threatens data integrity and businessoperations; 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 andinformation security controls and policy. Presidential Decision Directive 63 (PDD63) policydocument helped to establish the distribution of SCADA security responsibility. Federalstakeholders include lead federal agencies specifically the Department of Energy (DOE),Department of Homeland Security (DHS) National Cyber Security Division (NCSD), as well asthe National Information Assurance Partnership (NIAP) - National Institute of Standards andTechnology (NIST) and National Security Agency (NSA). NIAP provides policy guidancedocument designed to promote best-practices in SCADA/CI security for example facilitatingcoordinated communication as well as standardization between the various SCADA dependent
  8. 8. SwA and SEC. INITIATIVES 8CI-ISACs (Information Sharing and Analysis Centers). SCADA security falls under theInformation Technology ISAC (IT - ISAC). The NIAP also delegates CI responsibilities amongthe private sector; the Process Control Security Requirements Forum (PCSRF) establishedsecurity 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 oneanother;” (Lewis, 2006, p.365) therefore TCP/IP is synonymous with internet datacommunications such as SCADA and EMS. The structure of the internet makes it resilient tooutages occurring in unrelated parts of the network; complex and decentralized networks ofnetworks help to contain cascade failures and prevent the complete comprise of internetbroadband supply. Multiple networks, routing systems, and hundreds (conservative estimate) ofISPs help to ensure the robustness of the US internet. Even the shut-down of a major ISP wouldnot result in to total comprise of internet broadband supply. It is plausible to shut-down smallerUS 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 asingle entity does not face this same vulnerability. The versatility of independentlyowned/privately operated of US ISPs inherently supports the redundancy and resilience of theUS internet network. However, SCADA systems are vulnerable to the same threats as anyTCP/IP-based system. Including but not limited to; attacks on operating systems such as DOSattacks and/or IP Spoofing, application layer attacks such as common viruses, worms, and/orTrojan 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 aresummarized in Appendix I; SCADA Attack Matrix. Additionally, there is a possibility of an
  9. 9. SwA and SEC. INITIATIVES 9attack on the physical SCADA communication infrastructure for example, Electro MagneticPulse (EMP) attacks on transmission networks or destroying a critical hub such as a SCADAfacility hosting control servers. The multiple layers comprising SCADA physical and cybernetworks must all be simultaneously protected using general IT risk profile and mitigation tacticsassociated with networked software. SCADA security initiatives resemble compliance to general IT security requirementsincluding but not limited to threat and vulnerability assessments, security audits, informationassurance tactics such as strong authentication and encryption practices, hardening physical andvirtual 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 processingtransactions 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 necessaryto complete the transaction. IDPS may be used to detect or stop an attack in progress should anattacker get through the firewall, mitigating any damage or compromise of data the attacker mayattempt. IDPS should be deployed behind the firewall and should monitor traffic in multiplelocations. In this way, the IDPS is capable of reporting if any one part of the network shouldbecome compromised. Encryption may be employed to render any stored data indecipherable toan attacker, but care must be taken to use strong encryption algorithms and keys. Encryptionkeys should be carefully protected and only accessible to those who require access. Securitypolicy and procedures should be based on a combination of open standards and COTS products. Other techniques include building security directly into the technology through processessuch as the secure systems development lifecycle as well as employing redundancy in order to
  10. 10. SwA and SEC. INITIATIVES 10increase reliability and security. For example, using redundant connections such as implementingdual LAN/WAN networks; if WAN networks are compromised the associated devices canmaintain functionality through the alternative LAN network. Also, redundant data-storage forexample the configuration of the primary sever is replicated onto redundant servers;synchronization technology can help to prevent system faults such as single point failure. Inaddition to employing technological prevention measures, SCADA security solutions must alsofocus on physical access controls such as using carful hiring practices (ie. background check,security clearances) and mandatory employee security training. Security policies should be inplace that can direct employees on how to properly maintain a secure environment. An employeetraining program that educates employees to recognize an attack and common attackmethodologies should be standard. Additionally, it would prove beneficial to require refresherclasses to be held yearly. Employees should also have easy access to a technical security team toreport any suspicious activity, files, or e-mails. A comprehensive SCADA security strategy mustinclude software security assurance measures that consider technological as well as humanfactors both internally and externally. Appendix J “illustrates the typical corporate network „ringof 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 andoperational confidentiality, integrity, and availability. Confidentiality refers to the assurance ofauthorized disclosure of privy information between parties. Integrity refers to the assurance ofun-manipulated and completed data transmission, specifically to ensure data and operationalaccuracy and trustworthiness. Availability refers to the assurance of accessibility and reliabilityof data processing, delivery, and storage systems. The National Communications System (NCS),in response to Executive Order (E.O.) 12472, established National Security and Emergency
  11. 11. SwA and SEC. INITIATIVES 11Preparedness (NS/EP) and CI protection functional requirements; the NS/EP requirementsaddress the security needs of SCADA systems. The NS/EP requirements mainly addresstechnological implementation and functionality; a matrix of NS/EP requirements is presented inAppendix K. SCADA security policy and protocols strive to achieve the NS/EP requirementsand CI protection missions of the NCS; incorporation of SCADA specific security featuresdesigned to support NS/EP requirements will help to mitigate some of the risks associated withTCP communications. In addition to the NS/EP requirements it is important to consider thehost‟s operating environment as well as their adherence, evaluation, and modification oforganizational security policies. In both of the two case examples provided the attacks andassociated damages are attributed to a lack of proper security policy and enforcement. The Stuxnet malware exposed security vulnerabilities in cyber-based industrial controlsystems such as SCADA. Stuxnet provides a great example of the potential capabilitiesassociated with cyber-weapons. Cyber-attacks such as the sophisticated Stuxnet worm could beused to target CI for example, executing an attack on US industrial software and equipment suchas SCADA systems. Author(s) of Stuxnet and/or individuals with similar knowledge andexpertise have the ability to develop more and potentially more effective viruses and wormsdesigned to execute coordinated attacks on selective targets. The possible threats associated withStuxnet and Stuxnet like malware are a major implication on homeland security considerationsand strategy. It should be noted that Stuxnet was not a networked-based attack, the Iraniannuclear program uses an air gap security system, therefore it was necessary for Stuxnet to haveeither accidental or intentional introduction to the program prior to Stuxnet replication andconsequential program manipulation/compromise. With better/additional security protocols (ie.
  12. 12. SwA and SEC. INITIATIVES 12blocking access to external ports via a device control policy) and employee security trainingStuxnet infiltration may have been prevented. A second case that illustrates the problems of lacking proper policies is that of RSA andits SecurID tokens. RSA SecurID tokens are used to authenticate a user based on the „somethingyou have‟ principle. The „something you have‟ human authorization approach requires a tangibleobject such as a hardware token or an i.d. card. The second aspect of RSA SecurID‟s two-factorauthentication is the „something you know‟ approach, such as password. RSA is “the onlysolution that automatically changes your password every 60 seconds.” (RSA SecurID, 2011) Thetokens 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 isimpossible for an attacker to calculate the current or next random number in a sequence. Thesecurity offered by SecurIDs led many large corporations and the US government to use RSAtechnology to secure their own networks and Virtual Private Networks (VPN). As a companyspecializing in security products, RSA was an industry leader in maintaining a secure localnetwork including defensive countermeasures such as firewalls, IDS/IPS, secure passwords, andencryption. RSA fell victim to an Advanced Persistent Threat (APT) in 2011; an ATP typicallyprogresses through different phases each customized to achieve the maximum effect. RSAs network initially came under a social engineering attack when low levelemployees received "two different phishing emails over a two day period" (Rivner, 2011)containing Excel spreadsheet attachments harboring malicious code. The employees did not havethe necessary security training to advise them not to open the attachments or to forward them to asecurity department for examination. When the infected attachments were opened a Trojan wasexecuted that began an escalation of privilege until the attacker was able to access accounts of
  13. 13. SwA and SEC. INITIATIVES 13individuals with credential to access to the database containing the seeds used for initializing theSecurID tokens. See Appendix L for a visual of the various stages of the ATP attack strategy onRSA. Additionally, the algorithm used to generate the random number from the seed was alsocompromised rendering the SecurID tokens vulnerable. Shortly after the RSA attack, "severallarge defense contractors" (Diodati, 2011) were attacked and had confidential data removed fromtheir systems. RSA utilized the latest in security technology enabling the companys Computer IncidentResponse Team to detect and stop the attack quickly, but not quickly enough to stop the attackersfrom obtaining confidential data. In RSAs case it was not a lack of technology but instead a lackof policy on training employees to recognize threats and procedures for non-technical employeesto confirm or report those threats that lead to the data breach. A policy defining the amount oftraining employees receive, what types of threats they should be trained to watch for, and waysfor 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 dependenton the security measures of a security technology provider. Developing, enforcing, and maintaining an applicable and robust security policy is vitalto security efforts of both government and private sectors. In response to increased securityneeds and standards, government and private initiatives to support SwA have drasticallyincreased over the past few years. Numerous guidance programs, assessments, and standardshave been developed by both government and private sectors to address the issue of softwaresecurity assurance. Major government and private SwA initiatives are categorized and listedunder Appendix M; further elaboration on the listed initiatives is available at[]. Additionally, the MITRE Corporation, with
  14. 14. SwA and SEC. INITIATIVES 14DHS sponsorship, complied a free collection of information security data standards and industrysecurity initiatives as a service for the secure cyber industry and community; the “MakingSecurity Measureable” is a living document and is available at[]. The document lists and elaborates on theinformational building blocks for developing and supporting SwA and security specificallyenumerations (standards), languages (encoding), repositories (storage), and security tools such asassessment methodologies. No single building block can successfully prevent or mitigate attacks,but when properly combined together into a comprehensive security plan used throughout theSDLC 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: Technologies, Inc. (2004, October). Supervisory Control and Data Acquisition (SCADA) Systems (TECH INFO BULLETIN 04-1). Retrieved from National Communications System website:, M. (2011, June 2). The seed and the damage done: RSA SecurID [Web log post]. Retrieved from Gartner: 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:
  15. 15. SwA and SEC. INITIATIVES 15Appendix A;The Department of Homeland Security (DHS) National Cyber Security Division (NCSD)Software Assurance (SwA) Program Contributions Build Security In - 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 SOARJarzombek, 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: SMA/ispab/documents/minutes/2009-07/ispab_july09-jarzombek_swa-supply- chain.pdfAppendix 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 andsystem development community (PSM and CMMI®) and information security community(NIST). The ISO/IEC standard was selected due to the broad industry use of the correspondingrequirements standard – ISO/IEC 27001, Information Security Management System-Requirements which should facilitate swift acceptance of ISO/IEC 27004.”(Booz Allen Hamilton, 2008, p.21)
  16. 16. SwA and SEC. INITIATIVES 16Synopsis of Common Measure Specifications:
  17. 17. SwA and SEC. INITIATIVES 17(Booz Allen Hamilton, 2008, p.24)Appendix C;Cross-disciplinary Nature of SwA“SwA measurement can leverage measures and measurement methods and techniques alreadyestablished in those disciplines (listed in the diagram above) and adapt them to SwA.”(Booz Allen Hamilton, 2008, p.3)Appendix D;SwA Measurement Stakeholder Example Goals and Information NeedsSupplier• Identify and prioritize defects in the design, architecture, and code to reduce risks of futureexploitation of software• Understand the level of assurance vs. residual risk associated with making decisions at eachphase 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
  18. 18. SwA and SEC. INITIATIVES 18• 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 appropriatelyaddress SwA needs• Enable quantifiable comparison with competitors to enhance organization‟s reputation andachieve product and service differentiation from competition• Ascertain understanding of operational environment and integration of accidental andintentional use, misuse, abuse, and threat considerations into the SDLC activities• Identify causes of poor design and coding practices that may be introducing vulnerabilities intosoftware• Demonstrate effectiveness and repeatability of assurance processesAcquirer• Cost effectively integrate SwA considerations into the acquisition and development lifecycle• Ascertain that contracting officers have a good understanding of information securityrequirements of the Federal Acquisition Regulation (FAR)• Validate that contracting officers request assistance from information security specialists whenrequired• Validate that requirements for compliance with FISMA, OMB A-130, Appendix III, and NISTstandards and guidelines have been integrated into procurement language• Gain insight into how the software to be acquired will impact the organization‟s SwA andsecurity posture• Validate that SwA considerations are included in the procurement• Validate that SwA requirements defined in the RFP and in the contract have been satisfiedthroughout product and service delivery• Ascertain that the supplier has a process for testing and reviewing software for vulnerabilitiesthat 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 theevaluation process• Verify that SwA requirements are integrated into SwA RequirementsDocument 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 supportExecutive• 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 ofcredibility, 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 itscomponent(s)• Understand the impact of SwA on regulatory compliance
  19. 19. SwA and SEC. INITIATIVES 19Practitioner• Understand impact of SwA and security on business and mission support• Identify vulnerabilities exploitation of which would have an unacceptable impact on themission• Gain insight into the potential and actual cost of vulnerabilities in software (e.g., costs ofleaving vulnerabilities or removing them)• Provide inputs into risk management(Booz Allen Hamilton, 2008, p. 9)Appendix E;Example Measures for the Stakeholder GroupsExample Supplier Measures
  20. 20. SwA and SEC. INITIATIVES 20
  21. 21. SwA and SEC. INITIATIVES 21
  22. 22. SwA and SEC. INITIATIVES 22Example Supplier Measures
  23. 23. SwA and SEC. INITIATIVES 23Example Executive Measures
  24. 24. SwA and SEC. INITIATIVES 24Example Practitioner Measures
  25. 25. SwA and SEC. INITIATIVES 25
  26. 26. SwA and SEC. INITIATIVES 26(Booz Allen Hamilton, 2008, p. 20)Appendix F;Basic Measures Implementation Process(Booz Allen Hamilton, 2008, p. 20)
  27. 27. SwA and SEC. INITIATIVES 27Appendix G;Process Agnostic Approach“The process agnostic approach incorporates security into each basic phase of softwaredevelopment. The best practices and methods described are applicable to any and alldevelopment 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: BSI.html#
  28. 28. SwA and SEC. INITIATIVES 28Appendix H;Representation of Typical SCADA System(RTU) = Remote Terminal UnitLewis, 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
  29. 29. SwA and SEC. INITIATIVES 29Communication Technologies, Inc. (2004, October). Supervisory Control and Data Acquisition (SCADA) Systems (TECH INFO BULLETIN 04-1). (pp. 42) Retrieved from National Communications System website:
  30. 30. SwA and SEC. INITIATIVES 30Appendix J;Relationship Between Corporate and SCADA NetworksCommunication Technologies, Inc. (2004, October). Supervisory Control and Data Acquisition (SCADA) Systems (TECH INFO BULLETIN 04-1). (pp. 46) Retrieved from National Communications System website: K;Matrix of National Security and Emergency Preparedness (NE/EP) Requirements
  31. 31. SwA and SEC. INITIATIVES 31Communication Technologies, Inc. (2004, October). Supervisory Control and Data Acquisition (SCADA) Systems (TECH INFO BULLETIN 04-1). (pp. 3) Retrieved from National Communications System website:
  32. 32. SwA and SEC. INITIATIVES 32Appendix L;The Various Stages of the ATP Attack Strategy on RSARivner, U. (2011, April 1). Anatomy of an attack [Web log post]. Retrieved from RSA: 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)
  33. 33. SwA and SEC. INITIATIVES 33 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.2Further 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: