Presentation on theme: "Software Assurance: A Strategic Initiative of the U.S."— Presentation transcript:
1 Software Assurance:A Strategic Initiative of the U.S.Department of Homeland Securityto Promote Integrity, Security, and Reliability in SoftwareConsiderations for OWASP in Advancing a National Strategy to Secure CyberspaceOctober 11 , 2005Joe Jarzombek, PMPDirector for Software AssuranceNational Cyber Security DivisionUS Department of Homeland Security
2 Mission to Secure Cyberspace Mission components include:Implementation of the National Strategy to Secure Cyberspace and Homeland Security Presidential Directive #7 (HSPD#7)Implementation of priority protective measures to secure cyberspace and to reduce the cyber vulnerabilities of America’s critical infrastructuresThe National Cyber Security Division (NCSD) mission, in cooperation with public, private, and international entities, is to secure cyberspace and America’s cyber assets.Three key strategies provide a road map to perform NCSD’s mission: 1) The National Strategy to Secure Cyberspace; 2) Homeland Security Presidential Directive #7 (HSPD#7); and, 3) National Infrastructure Protection Plan (NIPP)NCSD works to accomplish its cyber defense mission by facilitating interaction and collaboration between the government and private sector owners of cyber infrastructure, federal departments and agencies, state and local governments, academia and international cyber security organizations.
3 Cyberspace & physical space are increasingly intertwined and software controlled/enabled Chemical Industry66,000 chemical plantsBanking and Finance26,600 FDIC institutionsAgriculture and Food1.9M farms87,000 food processing plantsWater1,800 federal reservoirs1,600 treatment plantsPublic Health5,800 registered hospitalsPostal and Shipping137M delivery sitesTransportation120,000 miles of railroad590,000 highway bridges2M miles of pipeline300 portsTelecomm2B miles of cableEnergy2,800 power plants300K production sitesKey Assets104 nuclear power plants80K dams5,800 historic buildings3,000 government facilitiescommercial facilities / 460 skyscrapersIn the U.S. alone-The critical infrastructure is composed of 13 sectors which are in our nation’s core industries – chemical, telecommunications, banking and finance, energy, agriculture and food, defense – and bring us the services on which we all depend – water, postal and shipping, electrical power, public health and emergency services, transportation.Each sector is extremely complex and to varying degrees dependent on all the others. for example, for the delivery of goods and services, for financial transactions, and in many other ways.Attacks on critical infrastructure could disrupt the direct functioning of key business and government activities, facilities, and systems, as well as have cascading effects throughout the Nation’s economy and society. (NIPP Feb. 2005) -- this is an asymmetric target-rich environmentNeed for process controls (SCADA) standardsHackers Target U.S. Power GridGovernment Quietly Warns Utilities To Beef Up Their Computer SecurityBy Justin BlumWashington Post Staff WriterFriday, March 11, 2005; Page E01Hundreds of times a day, hackers try to slip past cyber-security into the computer network of Constellation Energy Group Inc., a Baltimore power company with customers around the country."We have no discernable way of knowing who is trying to hit our system," said John R. Collins, chief risk officer for Constellation, which operates Baltimore Gas and Electric. "We just know it's being hit."An Asymmetric Target-rich Environment
4 Critical Infrastructure / Key Resources Physical Infrastructure Cyberspace & physical space are increasingly intertwined and software controlled/enabledAgriculture and FoodEnergyTransportationChemical IndustryPostal and ShippingSectorsWaterPublic HealthTelecommunicationsBanking and FinanceKey AssetsCritical Infrastructure / Key ResourcesFarmsFood Processing PlantsPower PlantsProduction SitesRailroad TracksHighway BridgesPipelinesPortsChemical PlantsDelivery SitesNuclear Power PlantsGovernment facilitiesDamsPhysical AssetsReservoirsTreatment PlantsCableFiberHospitalsFDIC institutionsPhysical InfrastructureInternetDomain Name SystemWeb HostingHardwareDatabase ServersNetworking EquipmentAttacks on critical infrastructure could disrupt the direct functioning of key business and government activities, facilities, and systems, as well as have cascading effects throughout the Nation’s economy and society. (NIPP Feb. 2005)Control SystemsSCADAPCSDCSServicesManaged SecurityInformation ServicesSoftwareFinancial SystemHuman ResourcesCyber AssetsCyber InfrastructureNeed for secure software applications
5 National Strategy to Secure Cyberspace National Cyber Security Division (NCSD) goals are strategically aligned to four frameworksMandatesNational Strategy to Secure CyberspaceI. National Cyberspace Security Response SystemII. National Cyberspace Threat and Vulnerability Reduction ProgramIII. Nation Cyberspace Security Awareness and Training ProgramIV. Securing Governments CyberspaceV. International Cyberspace Security CooperationHSPD-7“…maintain an organization to serve as a focal point for the security of cyberspace..”NIPPProvides a consistent, unifying structure for integrating the current multitude of CIP efforts into a single national programNRP “Cyber Annex”Describes framework for Federal cyber incident response coordination among Federal departments and agenciesNCSD GOALS1. Establish a National Cyber Security Response System to prevent, detect, respond to, and reconstitute rapidly after cyber incidents.2. Work with public and private sectors to reduce vulnerabilities and minimize the severity of cyber attacks.3. Promote a comprehensive national awareness program to empower all Americans ─ businesses, the general workforce, and the general population ─ to secure their own parts of cyberspace.4. Foster adequate training and education programs to support the Nation’s cyber security needs.5. Coordinate with the intelligence and law enforcement communities to identify and reduce threats to cyberspace.6. Build a world-class organization that aggressively advances its cyber security mission and goals in partnership with its public and private stakeholders.
6 National Strategy to Secure Cyberspace Outlines a framework for organizing and prioritizing effortsProvides direction to federal government departments and agenciesIdentifies steps to improve our collective cyber securityHighlights role of public-private engagementOutlines Strategic Objectives1Prevent cyber attacks against America’s critical infrastructures2Reduce national vulnerability to cyber attacks3Minimize damage and recovery time from cyber attacks that do occur
7 HSPD-7: A national policy to protect our nation’s infrastructure Maintain an organization to serve as a focal point for the security of cyberspaceFacilitate interactions and collaborations between and among federal departments and agencies, state and local governments, the private sector, academia, and international organizationsExecute a mission including analysis, warning, information sharing, vulnerability reduction, mitigation, and aiding national recovery efforts for critical information systemsHSPD 7, Paragraph 16- The Secretary will continue to maintain an organization to serve as a focal point for the security of cyberspace. The organization will facilitate interactions and collaborations between and among Federal departments and agencies, State and local governments, the private sector, academia and international organizations. To the extent permitted by law, Federal departments and agencies with cyber expertise, including but not limited to the Departments of Justice, Commerce, the Treasury, Defense, Energy, and State, and the Central Intelligence Agency, will collaborate with and support the organization in accomplishing its mission. The organization's mission includes analysis, warning, information sharing, vulnerability reduction, mitigation, and aiding national recovery efforts for critical infrastructure information systems. The organization will support the Department of Justice and other law enforcement agencies in their continuing missions to investigate and prosecute threats to and attacks against cyberspace, to the extent permitted by law.
8 The NIPP outlines a unifying structure Allows all levels of government to collaborate with the appropriate private sector entitiesEncourages the development of information sharing and analysis mechanisms and continues to support existing sector-coordinating mechanismsBroken down into 17 sector-specific plans to cover all areas of critical infrastructure, including the Information Technology (IT) sectorNIPP Risk Management FrameworkDynamic Threat EnvironmentThe NIPP Framework’s Physical, Cyber, and Human dimensions must be considered equally throughout in order to develop a comprehensive National Risk ProfileOBJECTIVES:Improve the cyber security of critical infrastructures.Promote cyber security and reduce vulnerabilities of control systems.Promote cyber security standards and best practiceHow does the NIPP Help Protect Our Critical Infrastructure?The NIPP is broken down into 17 sector-specific plans (SSPs) to cover all the areas of our critical infrastructure in an integrated manner across sectors and address the physical, human, and cyber elements of CI. Within each sector, the NIPP describes the processes undertaken to:Identify, prioritize, assess vulnerabilities, and coordinate the protection of critical infrastructure and key resources.Facilitate sharing of information about physical and cyber threats, vulnerabilities, incidents, potential protective measures, and best practices.PhysicalAssessRisks(Consequences,Vulnerabilities& Threats)SetSecurityObjectivesImplementProtectiveProgramsIdentifyAssetsNormalize & PrioritizeMeasureEffectivenessCyberHumanGovernanceNational Risk Profile
9 NRP Cyber Annex describes the framework for response coordination National Cyber Response Coordination GroupProvide indications and warningof potential threats, incidents,and attacksAnalyze cybervulnerabilities, exploits,and attack methodologiesInformation sharingboth inside and outsidethe governmentProvide technicalassistanceConduct investigations,forensics analysisand prosecutionAttribute the sourceof the attacksThe Federal government plays a significant role in managing intergovernmental and public-private coordination in response to cyber Incidents of National Significance.Defend against the attackLead National Recovery Efforts
10 Driving Needs for Software Assurance Software vulnerabilities jeopardize intellectual property, business operations and services, infrastructure operations, and consumer trustGrowing awareness and concern over the ability of an adversary to subvert the software supply chainFederal Government relies on COTS products and commercial developers using foreign and non-vetted domestic suppliers to meet majority of IT requirementsSoftware development offers opportunities to insert malicious code and to poorly design and build software enabling exploitationGrowing concern about inadequacies of suppliers’ capabilities to build and deliver secure software with requisite levels of integrityCurrent education & training provides too few practitioners with requisite competencies in secure software engineeringConcern about suppliers not exercising “minimum level of responsible practice”Growing need to improve both the state-of-the-practice and the state-of-the-art on software capabilities of the nationProcesses and technologies are required to build trust into software acquired and used by Government and critical infrastructureAs indicated in the National Strategy to Secure Cyberspace, “software vulnerabilities jeopardize intellectual property, business operations, infrastructure services, and consumer trust.”COTS products provides functionality that we all must have and the economic incentives driving production overseas is not going to change. We are also going to see increased dependence on COTS in secure systems, and code size and complexity will continue to increase. To address these concerns we identify processes and technologies that trust into software developed and acquired by the DoD.To identify these processes and develop the required technologies to mitigate the risks, we have to focus on a few key areas.First , we need to know what it takes to build secure software. We need to document/develop practices and process that support the development of secure software and define criteria for assuring integritySecond, we need to be able to build/acquire what we need. This includes fully expressing requirements, employing failsafe design and developing error free code.Third, we need to understand what we build/acquire. This includes production assurance evidence, comprehensive testing and static analysis. This could take the form of a secure development environment being developed by DoD which will provide an accurate record of development while automating security process and best practices to minimize security related development costs while ensuring some level of trust.Finally we need to develop policy and practices for “trusted” use and acquisition without imposing unacceptable costs. This will include defining trusted paths, providing trusted hardware support and defining related policy.Strengthen operational resiliency
11 United States 2nd National Software Summit Report April 29, 2005* Identified major gaps in:Requirements for software tools and technologies to routinely develop error-free software and the state-of-the-artState-of-the-art and state-of-the-practiceRecommended elevating software to national policythrough implementation of “Software 2015: a National Software Strategy to Ensure US Security and Competitiveness”to be pursued through public-private partnerships involving government, industry and academiaPurpose of National Software Strategy:- Achieve ability to routinely develop and deploy trustworthy software products- Ensure the continued competitiveness of the US software industry* See report at Center for National Software Studies
12 PITAC* Findings Relative to Needs for Secure Software Engineering & Software Assurance Commercial software engineering today lacks the scientific underpinnings and rigorous controls needed to produce high-quality, secure products at acceptable cost.Commonly used software engineering practices permit dangerous errors, such as improper handling of buffer overflows, which enable hundreds of attack programs to compromise millions of computers every year.In the future, the Nation may face even more challenging problems as adversaries – both foreign and domestic – become increasingly sophisticated in their ability to insert malicious code into critical software.Top Ten Areas in Need of Increased SupportComputer Authentication MethodologiesSecuring Fundamental ProtocolsSecure Software Engineering & Software AssuranceHolistic System SecurityMonitoring and DetectionMitigation and Recovery MethodologiesCyber Forensics and Technology to Enable Prosecution of CriminalsModeling and Testbeds for New TechnologiesMetrics, Benchmarks, and Best PracticesSocietal and Governance IssuesKey Issues:Software is a major vulnerability“The software development methods that have been the norm fail to provide the high-quality, reliable, and secure software that the IT infrastructure requires.”Endless patching is not the answer“Security cannot be easily or adequately added on after the fact…”The way we do it now isn’t good enough“The add-on approach will not address our fundamental need for far-sighted advances in systems and software technologies that provide innovative new approaches to the problem of security.”* President’s Information Technology Advisory Committee (PITAC) Report to the President, “Cyber Security: A Crisis of Prioritization,” February 2005 identified top 10 areas in need of increased support, including: ‘secure software engineering and software assurance’ and ‘metrics, benchmarks, and best practices’
13 GAO Reports relative to Software Assurance GAO Report, “Cybersecurity for Critical Infrastructure Protection,” May 2004GAO Report, “Defense Acquisitions: Knowledge of Software Suppliers Needed to Manage Risks,” May 2004Outsourcing, foreign development risks & insertion of malicious codeDoD noted domestic development subject to similar risksRecommendations for program managers to factor in software risks and security in risk assessmentsGAO Report, “Critical Infrastructure Protection: DHS Faces Challenges in Fulfilling Cybersecurity Responsibilities,” May 2005GAO R&D study on “risks attributable to outsourcing of software throughout critical infrastructure” being completedPage GAO Patch Management, June 2004GAO identified a number of steps that can be taken to address the risk associated with software vulnerabilities and patch management challenges, including:(1) reducing the number of potential vulnerabilities through better software engineering,(2) incorporating a defense-in-depth strategy into agencies’ IT infrastructures,(3) improving currently available tools, (4) researching and developing new security technologies, and(5) leveraging the federal government’s buying power to demand more secure products.DHS has begun efforts to implement additional steps through establishment of collaborative task forces.Better Software Engineering Can Reduce Vulnerabilities. More rigorous engineering practices, which include a formal development process, developer training on secure coding practice, and code reviews, can be employed when designing, implementing, and testing software products to reduce the number of potential vulnerabilities and thus minimize the need for patching. It is much less costly and more secure to identify defects during software development than to patch vulnerabilities after the product has been distributed.However, CERT/CC has reported that because software developers do not devote enough effort to applying lessons learned about the causes of vulnerabilities, the same types of vulnerabilities identified in earlier versions continue to appear in newer versions of products. Buffer overflows, for example, which may allow an attacker to gain control of a machine or mount a denial of service attack, represent a significant proportion of all overall software security vulnerabilities.24 For example, the Blaster and Sasser worms both exploited buffer overflow vulnerabilities in Microsoft products.Vendors that are proactive and adopt known effective software engineering practices can drastically reduce the number of flaws in their software products. For example, as part of its Trustworthy Computing Initiative, Microsoft is planning to undertake several steps to strengthen the software development process. According to Microsoft officials, creating secure software starts with a formal design process that verifies the security properties of the software at each well-defined stage of construction. The need to consider security “from the ground up” is a fundamental tenet of secure systems development. Such a process is intended to minimize the number of security vulnerabilities injected into the design, code, and documentation in the first place and to detect and remove those vulnerabilities as early in the development life cycle as possible. From inception to release, a development team, along with a central security team, makes plans to evaluate the security of the software.
14 Why Software Assurance is Critical Software is the core constituent of modern products and services – it enables functionality and business operationsDramatic 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 softwareRisk of Asymmetric Attack and ThreatsIncreasing awareness and concern[Source: Interim Report on “Software Assurance: Mitigating Software Risks in the DoD IT and National Security Systems,” DoD OASD(NII) forwarded to Committee on National Security Systems (CNSS), Oct 2004]Software and the processes for acquiring and developing software represent a material weakness
15 What has Caused Software Assurance Problem Increasing software vulnerabilities and exploitationThenDomestic dominated marketStand alone systemsSoftware small and simpleSoftware small part of functionalityCustom and closed development processes (cleared personnel)Adversaries known, few, and technologically less sophisticatedNowGlobal marketGlobally network environmentSoftware large and complexSoftware is the core of system functionalityCOTS/GOTS/Custom in open and unknown, un-vetted development processes with outsourcing & reuse (foreign sourced, un-cleared, un-vetted)Adversaries numerous and sophisticated
16 Software Exploitable Software: EXPLOITABLE SOFTWARE Outcomes of non-secure practices and/or malicious intentExploitation potential of vulnerability independent of “intent”DefectsSoftwareEXPLOITABLE SOFTWARENot all defects are exploitable vulnerabilities and not all vulnerabilities are defectsExploitation potential of vulnerability often independent of “intent”UnintentionalVulnerabilitiesIntentionalVulnerabilities*Intentional vulnerabilities are spyware & malicious logic deliberately imbedded (and might not be considered defects)Note: Chart is not to scale – notional representation -- for discussions
17 Exploitation of Software Vulnerabilities Serve as primary points of entry that attackers may attempt to use to gain access to systems and/or dataEnable compromise of business and missionsAllow Attackers to:Pose as other entitiesExecute commands as other usersConduct information gathering activitiesAccess data (contrary to specified access restrictions for that data)Hide activitiesConduct a denial of serviceEmbed malicious logic for future exploitation
18 DHS Software Assurance Program Overview Program based upon the National Strategy to Secure Cyberspace - Action/Recommendation 2-14:“DHS will facilitate a national public-private effort to promulgate best practices and methodologies that promote integrity, security, and reliability in software code development, including processes and procedures that diminish the possibilities of erroneous code, malicious code, or trap doors that could be introduced during development.”DHS Program goals promote the security of software across the development life cycleSoftware Assurance (SwA) program is scoped to address:Trustworthiness - No exploitable vulnerabilities exist, either maliciously or unintentionally insertedPredictable Execution - Justifiable confidence that software, when executed, functions in a manner in which it is intendedConformance - Planned and systematic set of multi-disciplinary activities that ensure software processes and products conform to requirements, standards/ proceduresCurrent environment: Private Industry, Globalization of IT, Insider Threat
19 National Cyber Security Division (NCSD) provides the framework for addressing cyber security and software assurance challengesKey Functions of the DHS Cybersecurity Partnership ProgramCross-Sector:Public andPrivateUS-CERTLaw Enforcement and IntelligenceCross-Agency:Federal, StateAnd LocalCommunicationCollaborationAwarenessOutreach and AwarenessCross-National:American public,internationalStrategic InitiativesKey Stakeholder GroupsNCSD
20 DHS National Cyber Security Division DHS Cyber Security Partner ProgramOffice of DirectorStrategic PlanningPolicyInternationalManagement (Budget, HR)COOPPCIIActing DirectorAndy PurdyUS-CERT/OperationsJerry DixonLE/IntelligencePatrick MorrisseyOutreach/AwarenessLiesyl FranzStrategic InitiativesHun KimBriefly describe the role of each branchSituational AwarenessAnalytical CellProductionFederal CoordinationIntel RequirementsLE CoordinationNCRCGCommunicationsMessagingOutreach to StakeholdersCyber Security AwarenessPartnershipsCIP Cyber SecurityControl Systems SecuritySoftware AssuranceTraining & EducationExercise Planning & CoordinationStandards & Best PracticesR&D Coordination
21 National Strategy to Secure Cyberspace Software Assurance Program Alignment“…maintain an organization to serve as a focal point for the security of cyberspace..”Priority 5: International Cyberspace Security CooperationPriority 4: Securing Govt.’s CyberspacePriority 3: National Cyberspace Security Awareness and Training Prog.Priority 2: National Cyberspace Threat and Vulnerability Reduction Prog.Priority 1: National Cyberspace Security Response SystemNCSD Goal 4: Foster adequate training and education programs to support the Nation’s cyber security needs.NCSD Goal 5: Coordinate with the intelligence and law enforcement communities to identify and reduce threats to cyber space.NCSD Goal 3: Promote a comprehensive national awareness program to empower all Americans to secure their own parts of cyberspace.NCSD Goal 2: Work with public and private sectors to reduce vulnerabilities and minimize the severity of cyber attacks.NCSD Goal 1: Prevent, detect, and respond to cyber incidents, and reconstitute rapidly after cyber incidents.HSPD-7National Strategy to Secure CyberspaceSoftware Assurance Program alignmentSoftware Assurance is aligned to support NCSD priorities defined within the National Strategy to Secure Cyberspace and the Homeland Security Presidential Directive #7.The Software Assurance Initiative supports the achievement of NCSD goals 2, 3 and 4; yet programmatically, it is managed within Goal 2.*”National Strategy to Secure Cyberspace” and Homeland Security Presidential Directive #7
22 Software Assurance Program Alignment National Strategy to Secure CyberspaceHSPD7Priority 1: National Cyberspace Security Response SystemPriority 2: National Cyberspace Threat and Vulnerability Reduction ProgramPriority 3: National Cyberspace Security Awareness and Training ProgramPriority 4: Securing Govt.’s CyberspacePriority 5: International Cyberspace Security CooperationHSDP7: “…maintain an organization to serve as a focal point for the security of cyberspace..”NCSD Goal 2: Work with public and private sectors to reduce vulnerabilities and minimize the severity of cyber attacks.SW Security in the SDLC Developers GuideBuild Security InWeb siteSwA Common Body of KnowledgeArticles in journalsWorkshops and conferencesTools and Product EvaluationMetrics and Tool EvaluationNIAP ReviewProcurement templatesProcesses and PracticesNational & InternationalstandardsSoftware Assurance Program Management
23 Software Assurance Program Structure Program framework encourages the production and acquisition of better quality and more secure software and leverages resources to target the following four areas:People – developers (includes education and training) and usersProcesses – best practices, standards, and practical guidelines for the development of secure softwareTechnology – evaluation tools and cyber security R&DAcquisition – software security improvements through specifications and guidelines for acquisition and outsourcing
24 Software Assurance: People Provide Guide to Software Assurance Common Body of Knowledge (CBK) as a framework to identify workforce needs for competencies, leverage standards and “best practices” to guide curriculum development for Software Assurance education and training**Hosted Electronic Develop a Curriculum Event and CBK Working Groups (April, June and August 2005) to develop CBK that involved participation from academia, industry and Federal GovernmentAddressing three domains: “acquisition & supply,” “development,” and “post-release assurance” (sustainment)Distribute CBK v0.7 in October 2005, with v.0.9 in Jan 2006 and v1.0 by March 2006Develop CBK awareness materials, including Frequently Asked Questions by Oct 2005 with update in January, 2006Develop a pilot training/education curriculum consistent with CBK in conjunction with early adopters for distribution by September 2007**NCSD Goal Action 2.3.1
25 Disciplines Contributing to SwA CBK Information AssuranceSystems EngineeringSafety & SecurityProject MgtSoftware AcquisitionSoftware EngineeringSoftware AssuranceNote: Initial input (subject to update) for the contributing bodies of knowledge (BOK) comes from:IEEE CS SW Eng Body of Knowledge (SWEBOK) for Software Engineering,PMI Project Management Body of Knowledge (PMBOK) for Project Management,DAU SW Acquisition Management (SAM) Core Competencies for SW Acquisition,Safety and Security extension for integrated CMMs from 8 S&S standards (& ISSE),DoD Information Assurance Training, Certification and Workforce Management, DoD MINCOSE SE BOK (draft), DoD Systems Engineering & ISSE,Test & Evaluation in multiple disciplines plus the Test Management BOK,In Education and Training, Software Assurance could be addressed as:A “knowledge area” extension within each of the contributing disciplines;A stand-alone CBK drawing upon contributing disciplines;A set of functional roles, drawing upon a common body of knowledge; allowing more in-depth coverage dependent upon the specific roles.
26 Secure Software Assurance A Guide to the Common Body of Knowledge to Produce, Acquire and Sustain Secure Software, v0.7Offered for informative use; it is not intended as a policy or standardFurther comments welcome by November 15, 2005To provide comments, please join the Software Workforce Education and TrainingWorking Groups collaborate through the US CERT Portal (https://us-cert.esportals.net/), join using Organization ID 223
27 Software Assurance: Process Provide practical guidance in software assurance process improvement methodologies**Sponsoring work with Software Engineering Institute and industry to develop a web-based central repository “Build Security In” on US-CERT web site “buildsecurityin.us-cert.gov for dissemination of recommended standards, practices, and technologies for secure software development to launch October 3, 2005Collect, develop, and publish practical guidance and reference materials for Security through the Software Development Life Cycle for training software developers in software assurance process improvement methodologies.“SECURING THE SOFTWARE LIFECYCLE: Making Application Development Processes – and Software Produced by Them – More Secure”**NCSD Goal Action 2.3.2
29 Information for Developers Securing the Software Lifecycle: Making Application Development Processes – and the Software Produced by Them – More Secure (draft)Offered for informative use; it is not intended as a policy or standardFurther comments welcomed by November 15, 2005To provide comments, please join the Software Processes and Practices Working GroupWorking Groups collaborate through the US CERT Portal (https://us-cert.esportals.net/), join using Organization ID 223Information for Developers
30 Software Assurance: Process (cont’) Provide practical guidance in software assurance process improvement methodologies**Develop a business case analysis to support lifecycle use of security best practicesComplete the DHS/DoD co-sponsored comprehensive review of the NIAP (National Information Assurance Partnership) to be published Sep 2005Continue to seek broader participation of relevant stakeholder organizations and professional societiesParticipate in relevant standards bodies; identify software assurance gaps in applicable standards from ISO/IEC, IEEE, NIST, ANSI, OMG, CNSS, and Open Group and support effort through sponsored Processes and Practices Working group (April, June, August, October, and December 2005 and March, June and September 2006)**NCSD Goal Action 2.3.2
31 Value of StandardsSoftware Assurance needs standards to assign names to practices or collections of practices.This enables communication between:Buyer and sellerGovernment and industryInsurer and insuredStandards represent the “minimum level of responsible practice,” not necessarily the best available methods
32 Best available methods Minimum level of responsible practice Using Standards and Best Practices to Close gaps between state-of-the-practice and state-of-the-art *1, 2Raising the CeilingInformation Assurance, Cyber Security and System Safety typically treat the concerns of the most critical system assets.They prescribe extra practices (and possibly, extra effort) in developing, sustaining and operating such systems.However, some of the concerns of Software Assurance involve simple things that any user or developer should do.They don’t increase lifecycle costs.In many cases, they just specify “stop making avoidable mistakes.”Best available methodsState of ArtRaising the FloorMinimum level of responsible practiceState of Practice* Adopted from Software Assurance briefing on “ISO Harmonization of Standardized Software and System Life Cycle Processes,” by Jim Moore, MITRE, June 2, 2005, * US 2nd National Software Summit, April 29, 2005 Report (see identified major gaps in requirements for software tools and technologies to routinely develop error-free software and the state-of-the-art and gaps in state-of-the-art and state-of-the-practice
33 Best available methods Minimum level of responsible practice Using Standards and Best Practices to Close gaps between state-of-the-practice and state-of-the-art *1, 2Raising the CeilingInformation Assurance, Cyber Security and System Safety typically treat the concerns of the most critical system assets.They prescribe extra practices (and possibly, extra effort) in developing, sustaining and operating such systems.However, some of the concerns of Software Assurance involve simple things that any user or developer should do.They don’t increase lifecycle costs.In many cases, they just specify “stop making avoidable mistakes.”Best available methodsState of ArtRaising the FloorMinimum level of responsible practiceState of Practice* Adopted from Software Assurance briefing on “ISO Harmonization of Standardized Software and System Life Cycle Processes,” by Jim Moore, MITRE, June 2, 2005, * US 2nd National Software Summit, April 29, 2005 Report (see identified major gaps in requirements for software tools and technologies to routinely develop error-free software and the state-of-the-art and gaps in state-of-the-art and state-of-the-practice
34 Relating SW Assurance to Engineering Disciplines System and SW Engineering and Information Systems Security EngineeringFor a safety/security analysis to be valid …The execution of the system must be predictable.This requires …Correct implementation of requirements, expectations and regulations.Exclusion of unwanted function even in the face of attempted exploitation.Predictable ExecutionTraditional concernInformation AssuranceSystem SafetyCyber SecurityGrowing concern
35 Simplified Relationships among Disciplines Software EngineeringSoftware AssuranceKeyDisciplineVariousMulti-disciplinaryMethodsPropertyAchieves desired functionPrecludes undesired function despite attempts to exploitMeans or MethodsPredictable ExecutionRelation- shipPermits confidence inFault Tolerant DesignSecurity FunctionsSafetyInformation AssuranceAdopted from Jim Moore, IEEE CS S2ESC Liaison to ISO SC7
36 Security and Assurance Concerns in ISO TMBIECAdvisory Group on SecurityJTC 1Information TechnologyIEEE Computer SocietySC 7SC 22SC 27Software and Systems EngineeringProgramming LanguagesIT SecurityLiaison role between IEEE CS S2ESC and between ISO SCs
37 Harmonization Efforts Impacting Systems and Software Assurance Who’s CollaboratingISOIECTC176JTC1TC56SC65AQualityInformation TechnologyDependabilityFunctional SafetySC1SC7SC22SC27TerminologySystem & SW EngineeringLanguage, OSIT Security TechniquesDHSIEEE CSCNSS & MIL-STDsPolicies & DirectivesISODoDNISTIECFISMA ProjectsIEEE CSS2ESCIASCU.S. Gov’tSoftware and Systems EngineeringInformation Assurance
38 Leveraging/Linking International Standards ISOTMBIECRisk Mgmt VocabularyTC176JTC1TC56TC65Quality MgmtDependabilitySafetySC7SC27SC22SW & Sys EngineeringIT SecurityProg Lang* DHS NCSD has membership on SC7 & SC27 along with FFRDC support serving in liaison role between SC7 & SC27
39 ISO SC27 (INCITS CS1) Standards Portfolio ManagementInformation security and systemsThird party information security service providers (outsourcing)Measurement and AssessmentSecurity MetricsSecurity ChecklistsIT security assessment of operational systemsIT security evaluation and assuranceIA & Cyber Security Requirements and OperationsProtection ProfilesSecurity requirements for cryptographic modulesIntrusion detectionNetwork securityIncident handlingRole based access control
40 New Scope of ISO 15026 “System and Software Assurance” “System and software assurance focuses on the management of risk and assurance of safety, security, and dependability within the context of system and software life cycles.” Terms of Reference changed: ISO/IEC JTC1/SC7 WG9, previously “System and Software Integrity”Adopted from Paul Croll’s SSTC 2005 presentation, “Best Practices for Delivering Safe, Secure, and Dependable Mission Capabilities”
41 Practice Input from the Safety and Security Extensions for Integrated CMMs Ensure Safety and Security CompetencyEstablish Qualified Work EnvironmentEnsure Integrity of Safety and Security InformationMonitor Operations and Report IncidentsEnsure Business ContinuityIdentify Safety and Security RisksAnalyze and Prioritize RisksDetermine, Implement, and Monitor Risk Mitigation PlanDetermine Regulatory Requirements, Laws, and StandardsDevelop and Deploy Safe and Secure Products and ServicesObjectively Evaluate ProductsEstablish Safety and Security Assurance ArgumentsEstablish Independent Safety and Security ReportingEstablish a Safety and Security PlanSelect and Manage Suppliers, Products, and ServicesMonitor and Control Activities and ProductsSource: United States Federal Aviation Administration, Safety and Security Extensions for Integrated Capability Maturity Models, September 2004
42 ISO/IEC 15026 Framework for Software and System Assurance
43 Technical and Management Processes The subgroup was tasked to answer the following question: For activities and work products, what is the delta between “Typical” Development and “Safe/Secure Development?”The subgroup analyzed the Develop and Deploy Safe and Secure Products and Services Practice Area and provided areas for improvement within each stage of the software development lifecycle. The subgroup presented cross-cutting concerns for the full lifecycle to include:Security and safety criteria for selecting tools, techniques, methodologies, etc.Reviews and testing of artifacts (exit and entry criteria for each lifecycle phase)Security test plans (unit and integration) to include prescribed and situation specificUser documentation to include security/safety considerations, assumptions and constraints for useSecure installation and configuration checklist or guide to include assumptions and constraints for deployment environmentSecure configuration management
44 Risk Management and Measurement Used a framework of process, program and product, but focused on the product.Analyzed and provided recommendations on activities for the areas:Identify Safety and Security RisksAnalyze and Prioritize RisksDetermine, ImplementMonitor Risk Mitigation PlanMonitor Operations and Report IncidentsRecommended adding a timeline to identify the practice is in the development stage or the operational stage and ensure that each practice does not span stages.
45 Assurance CaseThe security target is integrity, confidentiality, availability, accountability, non-repudiation, and authenticity-related.Must span across lifespan and possible environmental situations (e.g. stolen laptop)Tradeoffs for assurance are costs, security properties, amount of assurance, performance, and usabilityEasing AssuranceConfine necessary capabilities to part of a systemSimplicityAll input handled - totality of functionsDeterministicEvery possible behavior knownAnalyzabilityConclusionsAssurance cases can be used to show good or badParts of the assurance case will be structured on different bases depending on argument/sub-arguments.
46 SwA Practice Expectations What type of tools could the buying community use that could be provided by the vendor community?For organizations that have implemented best practices, how did they do it, what were the choices/trade-offs that were made?What is being done to help the customer ask the right questions?Development of a methodology and security criteria that could be used as part of “purchase specifications”.Development of 5-10 pages of criteria/guidance that could be used to make it easier for buyers to purchase more secure software.Development of a developer’s guide which speaks to the security evaluation of components.Discussion/information provided on foreign influence control issues, specifically, what questions should critical infrastructure operators know to ask.Discussion of next steps – where do we go from here?
47 Next Steps for System and SW Assurance Modify context diagramWrite supporting textClearly establish centrality of the Assurance ArgumentDescribe the Assurance Argument in detailDescribe interfaces/ amplifications to the Technical and Management processes of and 12207Describe interfaces/ amplifications to the Risk Management Process of and the Measurement Process of and Security Metrics of 27004Reconvene in December to review and comment
48 Leveraging/Linking US Standards ANSIIEEE Reliability SocietyIEEE Computer SocietyIEEE Standards AssnANSI AccreditationNISTIEEE CS SABOpen GroupCategory A Liaison to SC7OMGIASCS2ESCCNSSMembership in US TAG to SC7Committee on Nat’l Security SystemsInformation AssuranceSoftware and Systems Engineering
49 NIST Enterprise Risk Management Framework In system security plan, provides a an overview of the security requirements for the information system and documents the security controls planned or in placeSPSecurity Control DocumentationDefines category of information system according to potential impact of lossFIPS 199 / SPSecurity CategorizationSelects minimum security controls (i.e., safeguards and countermeasures) planned or in place to protect the information systemSP / FIPS 200Security Control SelectionDetermines extent to which the security controls are implemented correctly, operating as intended, and producing desired outcome with respect to meeting security requirementsSP A / SPSecurity Control AssessmentSP / FIPS 200 / SPSecurity Control RefinementUses risk assessment to adjust minimum control set based on local conditions, required threat coverage, and specific agency requirementsSPSystem AuthorizationDetermines risk to agency operations, agency assets, or individuals and, if acceptable, authorizes information system processingSecurity Control MonitoringContinuously tracks changes to the information system that may affect security controls and assesses control effectivenessImplements security controls in new or legacy information systems; implements security configuration checklistsSecurity Control ImplementationSPStarting PointSource: FISMA Implementation Project, Dr. Ron Ross, NIST, April 2004
50 FISMA Implementation Project Standards and Guidelines FIPS Publication 199 (Security Categorization)NIST Special Publication (Certification & Accreditation)NIST Special Publication (Security Controls)NIST Special Publication A (Assessment)NIST Special Publication (National Security)NIST Special Publication (Category Mapping)FIPS Publication 200 (Minimum Security Controls)Source: FISMA Implementation Project, Dr. Ron Ross, NIST, April 2004
51 Integrating SwA CBK with CNSS IA Standards System Administrators4013Senior System ManagersInformation Systems Security Officers40124014Software Assurance4011Information Security Professionals40154016Systems Certifiers4011 – Information Systems Security ProfessionalsPLUS – 1 Additional Standard (your choice)Risk AnalystSoftware Assurance considerations for IA functional roles:-- add SwA material in each CNSS 4000 series standard-- add a new CNSS 4000 series standard on SW Assurance
52 Examples of Desired Relationships NIST 800IEEE IASCJTC 1/SC 27Security threat analysis nomenclature and techniquesLife cycle processesAgreement on selected Concepts relating disciplinesIEEE S2ESCJTC 1/SC 7SWE means to mitigate programming language vulnerabilitiesCharacterization of V & V techniquesJTC 1/SC 22Harmonization of Concepts among organizations working in the same discipline
53 Key Standards for Software and System Processes ISO/IEC 15288, System Life Cycle Processes25 processes spanning the life cycle of a system.The standard is primarily descriptive.ISO/IEC 12207:1995, Software Life Cycle Processes17 processes spanning the life cycle of a software product or service.The standard is somewhat prescriptive in defining a minimum level of responsible practice.Describes processes meeting the needs of organizational process definition.ISO/IEC 12207:Amd 1Redescribes processes to meet the needs of process assessment and improvement.ISO/IEC 15026, Integrity Levels AssuranceDescribes additional techniques needed for high-integrity systems.Currently, not process-oriented, but is being repositioned.ISO/IEC 16085, Risk Management ProcessISO/IEC 15939, Measurement ProcessOther standards treating specific processes in greater detail
54 Some Current Efforts SC7 SC22 SC27 IEEE S2ESC Incorporate “raise the floor” assurance practices into life cycle standards.Incorporate “raise the ceiling” practices into separate standards strongly related to the life cycle standards.Use “16 Practices” as a benchmark for measuring success.SC22Develop coding guidelines for common programming languages.SC27Expand their perceived context to include assurance concerns.IEEE S2ESCUse as an “integrator” of standards for packaging and transition to industry.
55 Software Assurance: Acquisition Enhance software supply chain management through improved risk mitigation and contracting for secure software**Collaborate with CNSS and industry working groups to identify needs for reducing risks associated with software supply chainDevelop and disseminate templates for acquisition language and evaluation based on successful modelsDevelop and disseminate common or sample statement of work / procurement language that includes provisions on liability for federal acquisition managersCollaborate with organizations providing acquisition training and educationChair WG to update of IEEE 1062, Software AcquisitionCollaborate with agencies implementing changes responsive to changes in the FAR that incorporated IT security provisions of FISMA when buying goods and services**NCSD Goal Action 2.3.4
56 Supply chain introduces risks to American society that relies on Federal Government for essential information and services30 Sep 2005 changes to Federal Acquisition Regulation (FAR) focus on IT SecurityFocuses on the role of contractors in security as Federal agencies outsource various IT functions.
57 FISMA IT security provisions now in FAR 30 Sep 2005 amended FAR parts 1, 2, 7, 11, and 39 implements IT security provisions of FISMA for all phases of IT acquisition life cycleIncorporate FISMA into Fed Acquisition with clear and consistent IT security guidanceRequire agencies to identify and provide InfoSec protections commensurate with security risks to Federal information collected or maintained for the agency and info systems used or operated on behalf of an agency by a contractorIncorporate IT security in buying goods and servicesRequire adherence to Federal Information Processing StandardsRequire agency security policy and requirements in IT acquisitionsRequire contractors and Fed employees be subjected to same requirements in accessing Fed IT systems and dataApplies Information Assurance definitions for Integrity, Confidentiality and Availability to Federal IT, including Sensitive But Unclassified information
58 Context for IT Security The environment consists of a changing set of conditions,Policies, and other factors unknown at the time ofimplementation but realized during use or consumptionThe system is an arrangement of products fulfilling a needConstrains the environment of each productDomain ofFIPSThe product is the unit of purchaseAnd frequently has multiple usesImplementation of an IAalgorithm in a product“feature function”Domain ofNIAP for IA and IAEnabled products“product”Domain ofCertification andAccreditation(all products, interfaces,configuration and otherIssues)“system”“environment”
59 Examining IT Security Requirements How are common flaws (vulnerabilities) in software addressed in procurements?Are existing schemes for product evaluation adequate?What test guidance should be provided?How should certification and accreditation process better address security requirements?How does acquisition community evaluate capabilities of suppliers to deliver secure software?
60 Software Assurance: Technology Enhance software security measurement and assess Software Assurance testing and diagnostic tools**Collaborate with National Institute of Standards and Technology (NIST) to inventory software assurance tools and measure effectiveness, identify gaps and conflicts, and develop a plan to eliminate gaps and conflictsHost workshops with NIST to assess, measure, and validate tool effectivenessDevelop R&D requirements for DHS S&T consideration; coordinating Software Assurance R&D requirements with other federal agenciesFund a R&D project (through the DHS S&T Directorate) that will examine tools and techniques for analyzing software to detect security vulnerabilities.– Lead multi-agency Cyber Security and IA R&D being provided to stakeholders.Include techniques that require access to source code & binary-only techniquesCollaborate with other agencies and allied organizations to mature measurement in security**NCSD Goal Action 2.3.3
61 SwA Security Measurement Federal Agencies need better information to support IT Security related decisions:The National Strategy to Secure Cyberspace [WH2003]Federal Information Systems Management Act (FISMA)Etc.Address Needs:Acquisition of security capabilitiesCertification and Accreditation of systemsProduct evaluationsecurity flaws in softwareScope:Recommendations should apply government-wide and industryFocus on IT security issues for cyber security and information assurance
62 Software Assurance (SwA) Public Service Co-sponsor semi-annual Software Assurance Forum for government, academia, and industry to facilitate the ongoing collaboration held April 2005, 3-4 October 2005, and March 2006Sponsor SwA issues of CROSSTALK and other journals, and provide SwA articles to “spread the word” to relevant stakeholdersProvide free SwA resources via “BuildSecurityIn” portal to promote relevant methodologiesCollaborate with DHS Speakers Bureau to provide material and speakers
63 DHS SwA Program Alignment with National Software Strategy DHS SW Assurance ProgramPeople – developers (includes education and training) and usersProcesses – best practices, standards, and practical guidelines for development of secure softwareTechnology – evaluation tools and cyber security R&DAcquisition – software security improvements in specifications and guidelines for acquisition and outsourcingNSG National Software StrategyImproving SW TrustworthinessTrustworthy SW Measurement & AnalysisTrustworthy SW DevelopmentTrustworthy SW Ed & AwarenessTrustworthy SW Business PracticesTrustworthy SW R&DEducating & Fielding SW WorkforceScience & Eng RevitalizationSW Engineering EducationUnderstanding Impact of Offshore Outsourcing on WorkforceRe-energizing SW R&DSW R&D Roadmap (Grand Challenges & SW capability Business Case Development)Government-led Strategic SW R&DEncouraging Innovation in US SW industrySoftware Innovation InitiativeDHS NCSD has liaison membership on National Steering Group
64 Software Assurance Program Overview Program goals promote security for software throughout the lifecycle:Secure and reliable software supporting mission operational resiliency *Better trained and educated software developers using development processes and tools to produce secure softwareInformed customers demanding secure software, with requisite levels of integrity, through improved acquisition strategies. *Program objectives are to:Shift security paradigm from Patch Management to SW Assurance.Encourage the software developers (public and private industry) to raise the bar on software quality and security.Partner with the private sector, academia, and other government agencies in order to improve software development and acquisition processes.Facilitate discussion, develop practical guidance, development of tools, and promote R&D investment.Current environment: Private Industry, Globalization of IT, Insider Threat* Guiding principles in the National Strategy to Secure Cyberspace provide focus on “producing more resilient and reliable information infrastructure,” and includes “cyber security considerations in oversight activities.”
65 The National Vulnerability Database (NVD) is new vulnerability resource tool co- sponsored by NIST and the DHS National Cyber Security Division/US-CERT, and:Is a comprehensive IT vulnerability database that integrates all publicly available U.S. Government vulnerability resources and provides links to industry resourcesIs built upon the CVE standard vulnerability nomenclature and augments the standard with a search engine and reference libraryProvides IT professionals with centralized and comprehensive vulnerability information in order to assist with incident prevention and management to mitigate the impact of vulnerabilitiesStrives to include all industry vulnerability databases, creating a “meta search engine”Provides official U.S. Government information on virtually all vulnerabilitiesProvides a fine grained search capabilityProvides user requested vulnerability statistics
66 NVD Search Capability http://nvd.nist.gov The NVD enables users to search a database containing virtually all known public computer vulnerabilities by a variety of vulnerability characteristics including:related exploit rangevendor namesoftware name and version numbervulnerability type, severity, impactUpdated every 4 minutes, to date, the NVD contains:Over 12,000 vulnerability summaries482 US-CERT Advisories1095 US-CERT Vulnerability Notes781 OVAL references47,000 industry references36 executable Cold Fusion programs
67 Software Assurance Observations Business/operational needs are shifting to now include “resiliency”Investments in process/product improvement and evaluation must include securityIncentives for trustworthy software need to be considered with other business objectivesPivotal momentum gathering in recognition of (and commitment to) process improvement in acquisition, management and engineeringSynergy of good ideas and resources will continue to be key ingredientSecurity requirements need to be addressed along with other functionsFrom a national/homeland security perspective, acquisition and development “best practices” must contribute to safety and securityMore focus on “supply chain” management is needed to reduce risksNational & international standards need to evolve to “raise the floor” in defining the “minimal level of responsible practice” for software assuranceQualification of software products and suppliers’ capabilities are some of the important risk mitigation activities of acquiring and using organizationsIn collaboration with industry, Federal agencies need to focus on software assurance as a means of better enabling operational resiliency
68 Joe Jarzombek, PMPDirector for Software AssuranceNational Cyber Security Division (NCSD)U.S. Department of Homeland Security(703)Software Assurance Forum 3-4 Oct 2005 at Hilton McLean https://www.seeuthere.com/event/m2c
70 Common Vulnerabilities and Exposures (CVE) Initiative An international security community activityto provide common names for publicly known security vulnerabilities and exposuresKey tenetsOne name for one vulnerability or exposureOne standardized description for eachExistence as a dictionaryPublicly accessible on the InternetIndustry participation in open forum (editorial board)The CVE list and information at [cve.mitre.org]12,081 unique CVE names ~ new/month
71 OVAL Concept - The Open Vulnerability and Assessment Language Initiative Community-based collaborationPrecise definitions to test for each vulnerability, misconfiguration, policy, or patchStandard schema of security-relevant configuration informationOVAL schema and definitions freely available for download, public review, and commentSecurity community suggests new definitions and schemaOVAL board considers proposed schema modifications1,141 OVAL DefinitionsPublic unveiling - December 2002
72 Common Malware Enumeration (CME) Initiative “For those of your customers that use more than one companies anti-virus product, … [the lack of common identifiers] left them with an even bigger mess than just the virus outbreak…. We should not have to work so hard to figure out if your products are keeping us protected.”-Chris Mosby, SMS Administrator, open letter posted to SANS Internet Storm Center and directed toward Anti-Virus companies.Assign unique IDs to high profile malware threatsCreate a community forum for sample exchange and deconflictionStandardize malware analysis content to provide consistent information to incident responders and enable machine consumption by network management toolsBuilding on CVE and OVAL efforts
Your consent to our cookies if you continue to use this website.