Presentation on theme: "New Cybersecurity Requirements for Government Contractors and What They Mean For Your Organization Ryan C. Bradel Associate, Greenberg Traurig."— Presentation transcript:
New Cybersecurity Requirements for Government Contractors and What They Mean For Your Organization Ryan C. Bradel Associate, Greenberg Traurig
“This is a very major security compromise that has possibly put at risk numerous sensitive government sites and private industry as well.” - Former U.S. National Security Advisor Richard Clarke
Hackers reportedly exploited Lockheed's VPN access system, which allows employees to log in remotely by using their RSA SecurID hardware tokens. Attackers apparently possessed the seeds--factory-encoded random keys--used by at least some of Lockheed's SecurID hardware fobs, as well as serial numbers and the underlying algorithm used to secure the devices.
Anonymous Hacks ManTech, a FBI Cybersecurity Contractor Anonymous acquired and released to the public, a list of approximately 90,000 military s and Base64 password hashes, after hacking into systems from Booz Allen Hamilton, the large government contractor that works closely with many defense, intelligence, and civil sectors on cybersecurity.
The last couple of years have seen a flurry of activity, primarily from the Obama Administration, but also from Congress, working to stay ahead of the cybersecurity curve. Today we will be focusing on two “items” that are likely to have the most impact for government contractors: The NIST Draft of the Preliminary Cybersecurity Framework. The Proposed FAR Rule “Basic Safeguarding of Contractor Information Systems.” Both of these “items” are in draft/proposed form so the situation is very fluid.
Will the Government establish mandatory, uniform cybersecurity standards for government contractors across agencies and industries? If so, what are they likely to look like? How will it be accomplished?
I. Brief history of the cybersecurity regime a. FISMA b. NIST Special Publications / II. Recently enacted laws affecting government contractors: a. DOD Instruction b. GSAR Case 2011-G503 c. Executive Order / Presidential Policy Directive 21 III. The latest NIST guidelines a. Draft NIST Cybersecurity Framework (direct response to EO 13636) IV. The future: implications for government contractors a. Proposed Changes to the FAR b. General Services Administration RFI – more changes to the FAR?
The focus of today’s conversation will be on cybersecurity requirements for government contractors. Many of the laws and guidelines that we discuss today are also or primarily applicable to government agencies or commercial companies. But we are going to focus in on the elements that are applicable to government contractors.
Approaching the issue from a legal perspective: focusing on the institutions and entities that have been involved and the work they have done as well as complying with the legal requirements.
In place: FISMA NIST Special Publications , GSA Cybersecurity Regulation GSAR DoD Instruction Executive Order Presidential Policy Directive 21 Pending: NIST Draft Cybersecurity Framework Proposed FAR Rule—77 Fed. Reg Proposed: GSA RFI 78 Fed. Reg CISPA
If the past has been haphazard, ad hoc and piecemeal, the present has been characterized by a move—somewhat—towards uniformity and clearer standards. For example, Executive Order which sought to “harmonize and make consistent existing procurement requirements related to cybersecurity.”
Stated purposes Provide a comprehensive framework for ensuring the effectiveness of information security controls over information resources that support Federal operations and assets. Provide for the development and maintenance of minimum controls required to protect Federal information and information systems. Recognize that selection of specific technical hardware and software information security solutions should be left to individual agencies from among commercially developed products.
Basic Requirements FISMA requires each agency’s program officials, chief information officers and inspectors general to conduct annual reviews of the agency’s information security program and report the results to the Office of Management and Budget.
Basic Requirements FISMA requires each federal agency to develop, document, and implement an agency- wide program to provide information security for the information systems that support the operations and assets of the agency, including those provided or managed by contractors.
FISMA for Government Contractors FISMA really only has direct application to the agencies themselves; it puts the onus on the agency to ensure compliance. Agencies can and will conduct FISMA audits of government contractors. However, once again, the standards under which a FISMA audit is conducted will often be very agency specific and, for a contractor undergoing a FISMA audit for the first time, it can be difficult to figure out what the standards will be.
Roadmap that we recommend contractors should follow to comply with FISMA: Categorize the information to be protected. Select minimum baseline controls. Refine controls using a risk assessment procedure. Document the controls in the system security plan. Implement security controls in appropriate information systems. Assess the effectiveness of the security controls once they have been implemented. Determine agency-level risk to the mission or business case. Authorize the information system for processing. Monitor the security controls on a continuous basis.
Founded in 1901 and now part of the U.S. Department of Commerce, NIST is one of the nation’s oldest physical science laboratories. Congress established the agency to improve the U.S.’s industrial competitiveness globally. FISMA tasked NIST with developing the basic standards for cybersecurity. The result is, as is most relevant here, the NIST Special Publication , the Federal Government’s foundational cybersecurity document. It has been evolving ever since its inception with the most recent iteration published in May The standards are designed to have broad applicability and be useful for agencies, government contractors and commercial businesses.
The Guide for Applying the Risk Management Framework to Federal Information Systems. A structured process that integrates information security risk and risk management activities into a system development life-cycle.
Six Risk Management Framework steps: 1. Categorize the information system and the information processed, stored, and transmitted by that system based on an impact analysis. 2. Select an initial set of baseline security controls for the information system based on the security categorization, tailoring and supplementing the security control baseline as needed based on an organizational assessment of risk and local conditions. 3. Implement the security controls and describe how the controls are employed within the information system and its environment of operation.
Six Risk Management Framework steps (cont’d): 4. Assess the security controls using appropriate assessment procedures to determine the extent to which the controls are implemented correctly, operating as intended, and producing the desired outcome with respect to meeting the security requirements for the system. 5. Authorize information system operation based on a determination of the risk to organizational operations and assets, individuals, other organizations, and the Nation resulting from the operation of the information system and the decision that this risk is acceptable. 6. Monitor the security controls in the information system on an ongoing basis including assessing control effectiveness, documenting changes to the system or its environment of operation, conducting security impact analyses of the associated changes, and reporting the security state of the system to designated organizational officials.
NIST Special Publication is the meat on the bones of the FISMA cybersecurity regime. It is effectively a “menu” of cybersecurity control guidelines and a process for selecting an initial set of baseline security controls, tailoring the baseline security controls, and supplementing the security controls based on an organizational assessment of risk. The security rules cover 17 areas including access control, incident response, business continuity, and disaster recoverability.
Recent revisions to addressed: Additional security controls and enhancements for advanced cyber threats; Recommendations for prioritizing security controls during implementation or deployment; Guidance on using the risk management framework for legacy information systems and for external information system services providers; Updates to security control baselines based on current threat information and cyber attacks; Guidance on the management of common controls within organizations; Strategy for harmonizing FISMA security standards and guidelines with international security standard ISO/IEC 27001; Dealing with insider threats; Software application security (including web applications); Social networking/mobile devices, Cloud computing; Advanced persistent threats; Supply chain security; and Privacy/civil liberties concerns.
Criticisms of FISMA Some have criticized FISMA as a well-intentioned but fundamentally flawed tool because it measures “security planning” rather than actually measuring the security of the information. In other words, it assigns tasks and responsibilities for oversight and recommends processes but doesn’t establish clear benchmarks that organizations must meet. Some have said that the FISMA enforcement regime doesn’t do a realistic analysis of actual threats and effective responses but merely encourages box checking to please agency auditors.
Examples of Agency-Specific Rules Under FISMA Two very recently enacted regulations are prime examples of how the FISMA regime can be very agency-specific and very different from agency to agency: Department of Defense Instruction General Services Administration GSAR
Designed primarily to apply to contractors: Establishes policy for managing the security of unclassified DOD information on non-DOD information systems. Applies to all unclassified DOD information in the possession or control of non-DOD entities on non- DOD information systems. Appropriate requirements shall be incorporated into all contracts with non-DOD entities.
Information Safeguards 1. Do not process unclassified DOD information on publically available computers ( e.g., those available for use by the general public in kiosks or hotel business centers). 2. Protect unclassified DOD information by at least one physical or electronic barrier ( e.g., locked container or room, logical authentication or logon procedure) when not under direct individual control of an authorized user. 3. At a minimum, overwrite media that have been used to process unclassified DOD information before external release or disposal.
Information Safeguards (cont’d) 4. Encrypt all information that has been identified as controlled unclassified information (CUI) when it is stored on mobile computing devices such as laptops and personal digital assistants, compact disks, or authorized removable storage media such as thumb drives and compact disks, using the best encryption technology available to the contractor or teaming partner. 5. Limit transfer of unclassified DOD information to subcontractors or teaming partners with a need to know and obtain a commitment from them to protect the information they receive to at least the same level of protection as that specified in the contract or other written agreement.
Information Safeguards (cont’d) 6. Transmit , text messages, and similar communications containing unclassified DOD information using technology and processes that provide the best level of privacy available, given facilities, conditions, and environment. Examples of recommended technologies or processes include closed networks, virtual private networks, public key-enabled encryption, and transport layer security (TLS). 7. Encrypt organizational wireless connections and use encrypted wireless connections where available when traveling. If encrypted wireless is not available, encrypt document files ( e.g., spreadsheet and word processing files), using at least application-provided password protected level encryption. 8. Transmit voice and fax transmissions only when there is a reasonable assurance that access is limited to authorized recipients.
Information Safeguards (cont’d) 9. Do not post unclassified DOD information to website pages that are publically available or have access limited only by domain or Internet protocol restriction. Such information may be posted to website pages that control access by user identification and password, user certificates, or other technical means and provide protection via use of TLS or other equivalent technologies during transmission. Access control may be provided by the intranet (via the website itself or the application it hosts). 10. Provide protection against computer network intrusions and data exfiltration, minimally including: a. Current and regularly updated malware protection services, e.g., anti-virus, anti-spyware. b. Monitoring and control of both inbound and outbound network traffic ( e.g., at the external boundary, sub-networks, individual hosts), including blocking unauthorized ingress, egress, and exfiltration through technologies such as firewalls and router policies, intrusion prevention or detection services, and host-based security services. c. Prompt application of security-relevant software patches, service packs, and hot fixes.
Information Safeguards (cont’d) 11. Comply with other current Federal and DOD information protection and reporting requirements for specified categories of information ( e.g., medical, proprietary, critical program information (CPI), personally identifiable information, export controlled) as specified in contracts, grants, and other legal agreements. 12. Report loss or unauthorized disclosure of unclassified DOD information in accordance with contract, grant, or other legal agreement requirements and mechanisms. 13. Do not use external IT services ( e.g., , content hosting, database, document processing) unless they provide at least the same level of protection as that specified in the contract or other written agreement.
Take Home Message DOD Instruction is very specific and tangible with regard to its cybersecurity requirements. Contrast this with NIST Special Publication which focuses on processes and methods for establishing cybersecurity protocols. Query: is DOD Instruction any less universal or adaptable? Could it not also be used for just about any agency or any context?
Instigated by a GSA internal investigation which found that the GSA’s IT systems failed to comply with FISMA, primarily because its contractors’ IT systems were not in compliance. In response GSA adopted a regulation which, among other things, required GSA IT contractors to submit an IT Security Plan and a Continuous Monitoring Plan outlining compliance with Federal cybersecurity regulations. The regulation became final on January 6, Only applies to GSA contracts but could be a roadmap for other agencies.
The IT Security Plan Contractors must develop, provide, implement and maintain an IT security plan. The plan shall describe the processes and procedures that will be followed to ensure appropriate security of IT resources. The plan shall comply with FISMA. The plan must be consistent with and further detail the approach contained in the contractor’s proposal that resulted in the award.
The Continuous Monitoring Plan Contractors must develop a continuing monitoring strategy that includes: 1. A configuration management process for the information system. 2. A determination of the security impact of changes to the information system and environment of operation. 3. Ongoing security control assessment. 4. Reporting the state of the system to GSA officials.
Take Home Messages Contrast the GSAR regulation with the DOD Instruction—it doesn’t contain the same tangible prescriptions for cybersecurity; rather, in the spirit of FISMA, it requires the implementation of processes and protocols for assessing and implementing cybersecurity prescriptions.
Background Promulgated in response to “repeated cyber intrusions into critical infrastructure.” More of a focus on the cybersecurity of non-governmental entities that could nonetheless have a profound impact on the economy. Defines “critical infrastructure” as “systems and assets, whether physical or virtual, so vital to the United States that the incapacity or destruction of such systems would have a debilitating impact on security, national economic security, national public health or safety, or any combination of these.”
Two key provisions for government contractors: 1. Ordered the NIST to produce a baseline framework to reduce cyber risks to critical infrastructure. 2. Ordered the DOD, the GSA and FAR Council to study and make recommendations to the President on the feasibility, security benefits, and relative merits of incorporating security standards into acquisition planning and contract administration.
New NIST Cybersecurity Baseline Framework The E.O. said that the Framework “shall provide a prioritized, flexible, repeatable, performance- based and cost-effective approach” and “shall focus on identifying cross-sector security.”
Impetus Produced in direct response to the mandate of E.O that “NIST lead the development of a framework to reduce cyber risks to critical infrastructure (the ‘Cybersecurity Framework’). The Cybersecurity Framework shall include a set of standards, methodologies, procedures, and processes that align policy, business, and technological approaches to address cyber risks.”
Posture The Draft has been developed in concert with several “workshops” that NIST has hosted throughout the spring and summer for stakeholders to discuss and comment on the framework in light of industry best practices. The most recent draft of the Draft was published on Aug. 28 in advance of the fourth workshop which will be held in Dallas on Sept. 11 – 13.
Framework Development Methodology 1. In February, 2013, NIST issued an RFI to industry and stakeholders designed to identify existing cybersecurity standards, guidelines, frameworks and best practices. 245 responses to the RFI were submitted. 2. On April 3, 2013, NIST hosted an initial workshop with industry and stakeholders to identify existing resources and gaps. 3. NIST analyzed the responses to the RFI and shared initial findings on May 15, 2013.
Framework Development Methodology (cont’d) 4. A second workshop was held on May 29, 2013 to discuss the foundations of the framework and the initial analysis of the RFI responses. 5. This led to the development of the first draft on July 1, A third workshop was held on July 10, 2013 to review the first draft.
Framework Development Methodology (cont’d) Throughout this process, the following goals were developed for the Framework: Be an adaptable, flexible, and scalable tool for voluntary use; Assist in assessing, measuring, evaluating, and improving an organization’s readiness to deal with cybersecurity risk; Be actionable across an organization; Be prioritized, flexible, repeatable, performance-based, and cost-effective; Rely on standards, methodologies, and processes which align with policy, business, and technological approaches to cybersecurity; Complement rather than conflict with current regulatory authorities; Promote, rather than constrain, technological innovation in this dynamic arena; Focus on outcomes; Raise awareness and appreciation for the challenges of cybersecurity but also the means for understanding and managing the related risks; Be consistent with voluntary international standards.
Questions for Stakeholders and Reviewers How can the preliminary framework: Adequately define outcomes that strengthen cybersecurity and support business objectives? Enable cost-effective implementation? Appropriately integrate cybersecurity risk into business risk? Provide the tools for senior executives and boards of directors to understand risks and mitigations at the appropriate level of detail? Provide sufficient guidance and resources to aid businesses of all sizes while maintaining flexibility?
Questions for Stakeholders and Reviewers Will the Discussion Draft, as presented: Be inclusive of, and not disruptive to, effective cybersecurity practices in use today? Enable organizations to incorporate threat information?
Questions for Stakeholders and Reviewers Is the Discussion Draft: Presented at the right level of specificity? Sufficiently addressing unique privacy and civil liberties needs for critical infrastructure?
Key Characteristics of the Draft Framework Maintains emphasis on flexibility. Seeks to create a “common language and mechanism for organizations.” Also, new focus on “repeatable” and “performance-based.” Recognizes that there will always be a balance between cost and risk. In many ways is the best of both worlds, marrying the flexible “processes and procedures” of the FISMA regime with a more tangible standards based approach. Most useful feature: cross-referencing the Framework Core categories with specific industry standards to include NIST standards ( i.e., special publications /800-53) and the International Standards Organization (ISO) standards.
Overview of the Framework Three main components: 1. Framework Core 2. Framework Implementation Tiers 3. Framework Profile
Framework Core Presents standards and best practices in a manner that allows for communication and risk management across the organization from the senior executive level to the implementation / operations level.
Framework Core Framework Core consists of five Functions: 1. Identify 2. Protect 3. Direct 4. Respond 5. Recover
Framework Core The five Functions are further subdivided into categories and subcategories, which are then assigned an Informative Reference. For example:
Framework Core Listing of the Functions and the Categories:
Framework Implementation Tiers Demonstrate the implementation of the Framework Core Functions and indicate how cybersecurity risk is managed at each stage of implementation: 1. Tier 1 – Partial : the organization has not yet implemented a formal, threat-aware risk management process. 2. Tier 2 – Risk Informed : the organization uses a formal threat-aware risk management process to develop a Profile of the Framework. 3. Tier 3 – Repeatable : the organization updates its Profile based on regular application of its risk management process to respond to the changing cybersecurity landscape. 4. Tier 4 – Adaptive : the organization updates its Profile based on predictive indicators derived from previous anticipated cybersecurity activities.
Framework Profile Organizations should develop their Framework Profile by determining their desired Tier at the Category level to allow for maximum flexibility and adaptability to the organization’s unique situation.
Listing of the Functions and the Categories, again:
Using the Framework An organization may use the Framework as the basis for establishing a new cybersecurity program or improving an existing one: Step 1: Make Organization Wide Decisions Step 2: Establish a Target Profile Step 3: Establish a Current Profile Step 4: Compare Target and Current Profile Step 5: Implement Target Profile
Areas of Improvement: Authentication Automated indicator sharing Conformity assessment Data analytics International aspects, impacts, and alignment Privacy Supply chains and interdependencies
Criticism Some commentators have criticized the Draft Preliminary Cybersecurity Framework as merely repackaging of old methods and processes. However, there are clearly some useful innovations, e.g., the cross-referencing of the Function and Categories with Informative References. Additionally, the Draft Framework is a much more user-friendly package so, to the extent it was a repackaging, it was a necessary and efficacious repackaging.
The NIST Cybersecurity Framework is an analytical tool and a collection of best practices and is not prescriptive. However, the savvy government contractor should have every expectation that agencies will start to incorporate its guidelines into their contract or regulatory requirements like the GSA did with the previous NIST standards.
Accordingly, government contractors should become involved in the development of the ongoing preparation of the Cybersecurity Framework. Additionally, government contractors should study and understand the Cybersecurity Framework and start to implement it within their companies so that they will be prepared if it becomes mandatory.
E.O : Ordered the agencies responsible for drafting FAR regulations to study the feasibility of incorporating security standards into acquisition planning and contract administration. In response, on May 13, 2013, the GSA issued notice in the Federal Register which: Created a working group to study the issue. Issued a Request for Information (RFI) to stakeholders.
The RFI sought responses from stakeholders to 37 questions related to the implementation of cybersecurity requirements into the FAR and other procurement rules. A sampling of the questions included: What are the implications of imposing a set of cybersecurity baseline standards? How can the procurement system incentivize cybersecurity compliance? What are the greatest challenges in developing a cross-sector standards-based approach? How can the Government mitigate barriers to entry? Are there specific categories of acquisitions to which cybersecurity standards should or should not apply? How does contract type ( e.g., FFP or cost plus) and source selection method affect your cybersecurity risk assessment?
In August 2012, prior to and independent of E.O , the FAR Council proposed a new FAR Rule incorporating basic standards for the safeguarding of contractor systems. The Final Rule is expected in October, 2013.
Impetus The proposed rule acknowledges that it does not address the safeguarding of contractor information systems that contain or process information provided by or generated for the Government. The proposed rule stated that it was an extension of FISMA requirements.
Requirements The proposed rule’s requirements are very similar to the requirements of DOD Instruction
Requirements (cont’d) Government information may not be processed on computers without access control or located in public areas. Similarly, Government information cannot be posted on a public website. If posted to a website, the site must control access either through user identification or password, user certificate or other technical means, and must provide protection via use of security technologies. Electronic information may be transmitted only on systems that utilize technologies and processes that provide the best level of security and privacy available, given facilities, conditions and threat level. Transmission by voice or fax may only occur when the sender has a reasonable assurance that access is limited to authorized recipients.
Requirements (cont’d) Systems must be protected by at least one level of physical barrier and one level of electronic barrier, such as lock and key in conjunction with a password, when not in the direct control of the individual user. Media that is being released or discarded must be cleared and sanitized. The contractor must provide at least the following means of intrusion protection: Current and regularly updated malware protection, such as anti-virus software and anti-spyware software; and prompt application of security-related upgrades and patches. Information may only be transferred to those subcontractors with a contractual need to have the information and who employ the safeguards described in the clause.
First introduced in 2011 by Mike Rodgers (R- MI and Dutch Ruppersberger (D-MD). Passed the House April 2013.