Professional Services Council (PSC) Comments on OMB draft guidance #43
Comments
|
PSC Cover Letter (Overall Comments): September 10, 2015 The Honorable Anne Rung, Administrator Dear Administrators Rung and Scott: On behalf of the Professional Services Council (PSC), I am pleased to submit these comments on the proposed OMB guidance titled “Improving Cybersecurity Protections in Federal Acquisitions” posted on the Federal CIO Council website for public comment on August 11, 2015. This guidance covers a number of important considerations on cybersecurity in federal acquisitions. It will be crucial to ensure that the guidance, and any subsequent Federal Acquisition Regulation (FAR) changes and related contract clauses, appropriately address issues of concern to contractors. PSC is the voice of the government technology and professional services industry, representing the full range and diversity of the government services sector. As a trusted industry leader on legislative and regulatory issues related to government acquisition, business and technology, PSC helps build consensus between government and industry. Our nearly 400 member companies represent small, medium, and large businesses that provide federal agencies with services of all kinds, including information technology, engineering, logistics, facilities management, operations and maintenance, consulting, international development, scientific, social, environmental services, and more. As a part of our Technology Council, we have convened a Cybersecurity Committee to ensure that the requisite expertise of our member companies and their employees are brought to bear on the vital cybersecurity challenges our government faces. Together, the trade association’s members employ hundreds of thousands of Americans in all 50 states. We have significant concerns with the OMB guidance—both for what and how it covers the five topics and for what it fails to cover. We view the current draft version of the guidance as being too little, too late and too flexible in addressing even the five areas covered in the document. The OMB guidance is “too little” because it fails to provide meaningful standardized and uniform guidance to the federal agencies and contractors in the five areas covered by the draft guidance. Instead, it offers only generalized statements with explicit authority for agencies to deviate from it almost at will. In addition, significant areas of cybersecurity protection, such as the need for common cybersecurity definitions for federal acquisition are not addressed, except as cross-references in the existing National Institute of Standards and Technology (NIST) guidance documents that are mentioned in the OMB draft; nor is there any coverage for government/contractor training or outreach to industry, again leaving critical areas to be covered—or not covered—by individual agencies or subsequent acquisition regulations. And yet, there exist a number of best practice models (e.g., the Department of Defense Computer Network Defense Service Provider model) to which the guidance could refer, and we recommend incorporation of these models in a more explicit fashion. The OMB guidance is “too late” because too many agencies have already taken regulatory and contractual actions to address many of the five components of this OMB guidance, thus undercutting any hope for uniform, government-wide guidance resulting from this document in its current form. Further, the OMB guidance is inconsistent with existing guidance and rules promulgated by other agencies. For example, in the section on security controls, the OMB guidance provides, without establishing as a firm baseline, that when a contractor is operating an internal company system containing controlled unclassified information, the contractor is only required to comply with the security controls in NIST Special Publication (SP) 800-171 (as issued on June 18, 2015). As we address below, however, each agency is free to modify that security standard “to meet its risk management needs” or to adopt another standard, without due regard for the standards being addressed by best practice models already adopted by government agencies. This is exactly the interpretive, decentralized behavior that has produced the current state of network security vulnerabilities. Further, the existing contractual requirements for the Defense Department’s Unclassified Controlled Technical Information (UCTI) rule, adopted in 2013, already requires contractors who come into possession of UCTI to comply with more than fifty controls from NIST SP 800-53. Prior to release of the OMB guidance, DoD issued its January 12, 2015 Cloud Computing Security Requirements Guide with its specific directive for security objectives and information impact levels for controlled unclassified information that do not align with the OMB guidance. Then, subsequent to the release of the OMB guidance, on August 26, 2015, DoD issued an interim rule on network penetration reporting and contracting for cloud services that conflicts with aspects of the OMB draft guidance. Finally, the OMB guidance fails to account for cybersecurity contracting policies and clauses already in effect at the Departments of Energy and Homeland Security and at GSA for its Schedules contracts. Nothing in the OMB guidance reconciles these existing actions with the OMB objectives. Finally, the OMB guidance is too flexible. As noted above, agencies are encouraged to determine which of the NIST guidance documents are to be applied to individual solicitations as well as being given new authority to even modify the NIST 800-171 itself. This will only make federal agency efforts more complicated and perpetuate a lack of interoperability. The OMB guidance does not include any contract terms and conditions, and recommends that agencies address on a contract-by-contract basis the specific contract clauses and remedies to be applied in individual solicitations and contracts. Ironically, despite all of these issues, OMB compounds the problems of its own creation by directing federal agencies to “immediately begin working together to apply the (OMB) guidance.” We strongly recommend and would support that OMB take one of two alternative approaches to creating coverage for cybersecurity protection in federal acquisition: (1) either fulfill the objective for a consistent, unified approach for agencies by significantly enhancing the current OMB guidance coverage, eliminating conflicts and overlaps with current coverage and reducing the vagueness of the application of future version of the OMB guidance to federal agencies, or (2) withdraw the OMB guidance completely and default to the standard federal acquisition regulatory process to establish the government-wide contracting standards. You’ll find our detailed comments on the OMB draft guidance as an enclosure to this letter. Please feel free to contact Dave Wennergren, our Senior Vice President, Technology, by email at [email protected], or by phone, 703-778-7557, if you have any questions or need additional information. Sincerely, Stan Soloway Enclosure |
|
PSC Enclosure (Detailed comments organized by sections of the document): PSC Specific Comments on Proposed OMB Guidance: Improving Cybersecurity Protections in Federal Acquisitions As noted in our cover letter, while improving cybersecurity is a national imperative, the draft OMB guidance does not ensure consistent, streamlined reporting requirements across federal agencies, nor will it result in significantly improved cybersecurity outcomes. In its current form, the guidance allows inconsistencies in agency actions, creates more onerous requirements for industry than government and allows decisions on cybersecurity competence to be based on innuendo rather than fact. Below you will find specific comments, structured to follow the organization of the draft policy guidance. A. Introduction • By including all systems covered under Controlled Unclassified Information (CUI) guidance, the draft OMB guidance will impact both systems operated by contractors on behalf of government and internal company systems that hold government CUI. Given this broad scope, the guidance will need to distinguish the differences in requirements for these two categories of systems, particularly around access to data (company proprietary data vs. government CUI), facilities and equipment. The two types of systems covered will also require differentiating system assessment requirements. Currently, the guidance allows agencies to significantly deviate from consistent guidelines and approaches. We recommend that this guidance be coordinated with the NARA CUI Program Manager to ensure alignment with on-going CUI rules and FAR clause development. • Agencies are told to “immediately begin” to apply this guidance. We are very concerned about this requirement and request that implementation of this guidance be postponed until the guidance can be finalized and incorporated into solicitations and contract regulations. This will help to avoid having agencies launch on potentially divergent paths and continue to create disparate requirements for compliance and reporting. B. Background • The draft guidance does not address federal agency obligations, including sharing information with the private sector, maintaining their own equally high level of security compliance and specific responsibilities in areas such as continuous diagnostics and monitoring. • Currently there are far too many conflicting sets of cybersecurity guidance and implementing procedures. It is crucial that a consistent and streamlined approach for reporting compliance and incidents be developed. Here are just some of the current guidance documents that need to be brought into a consistent framework: o DoD guidance on the safeguarding of unclassified controlled technical information and reporting of associated cyber incidents. C. Applicability and Scope • Thought must be given as to how and which of these requirements will flow down to subcontractors. We recommend only minimal flow down requirements of the detailed rules. Subcontractors should be able to tailor their systems to meet performance objectives rather than detailed prescriptive requirements. A flow down exemption should be provided for commercial item providers. D. Guidance D1. Security Controls • As noted above, the two types of systems covered by CUI rules need to be addressed. For government CUI operated on behalf of the government, companies must meet the NIST “moderate baseline” level of security controls in NIST SP 800-53. For internal contractor systems, companies must comply with NIST 800-171. Currently it is too easy for agencies to individually decide that information is not “incidental” and thus significantly elevate the controls required by SP 800-53. Consideration should be given to the approach to controls employed by models known to be effective, such as the Computer Network Defense Service Provider (CND-SP) model. Otherwise, industry implementation will result in increased costs without a return on investment. D2. Cyber Incident Reporting • OMB should ensure that proposed reporting requirements do not create a double standard, with a significantly higher set of expectations and compliance burdens for contractors than for government. • OMB should also ensure that all federal agencies adopt a consistent, unified incident reporting approach, and that a company can report once and have the information available to all necessary agencies. Moreover, when a contractor files a notice of breach with an agency, the contractor should be able to file the report confidentially (i.e., not subject to FOIA). The agency should also take into account the impact on the contractor of any additional post-notification compliance obligations where the contractor has already put in place successful mitigation from the breach. We believe OMB should consider the DoD Defense Industrial Base (DIB) program as a suitable breach notification approach. • As noted above, distinctions in incident reporting need to be made for the two categories of systems covered by the guidance: (1) those operated on behalf of the government, and (2) internal company systems which hold government CUI. • Liability and immunity issues also need to be addressed. If a company reports a cyber incident to the government and has exercised due diligence in protecting the information, then the company should receive immunity from prosecution and contractual and administrative penalties. This is one of the primary issues creating hesitancy on the part of industry to report cyber incidents to the government. A company should not be unfairly penalized and put at a competitive disadvantage against other contractors, because it reported a cybersecurity incident. It should be noted that companies do receive immunity today when they report incidents to the DoD Defense Industrial Base (DIB) initiative. The system works well and DoD gets reports from the companies that participate with the DIB. This should be the model for the rest of the government. • In addition, contractors should be able to report incidents to the government and have the reports anonymized so that the rest of the “world” can’t tell who reported the incident. Again, the DIB provides that opportunity as it passes out incident data which occurred to one contractor to the rest of the participating contractors. • Incident reporting should not include “potentially adverse effects.” This is far too broad, subjective and not fact-based. It will result in over-reporting, and it will divert resources from responding to events that cause actual harm without yielding significant security benefits. • Timelines for reporting and taking actions must be consistent for both government and industry. Currently, the requirements for a government agency, like OPM, are different than the expectations for a private sector firm without discernible reasons. D3. Information System Security Assessments • The guidance needs to clarify who bears the cost of the independent security assessment and/or the information security continuous monitoring and IT security scanning. What is the government’s obligation? What is the contractor’s responsibility? The document says that third party validation is acceptable depending on the risk assessment. Self-assessment may also be an appropriate mechanism depending on the circumstances and risks associated with a particular system. • As noted above, additional clarity is needed on the difference in assessments of systems operated on behalf of government and internal company systems that hold government CUI. • Government agencies must be directed to accept reciprocity in ATO’s, certifications and accreditations. • Clarification is needed on the language requiring a contractor proposal team to demonstrate NIST 800-171 requirements compliance via documentation or attestation, e.g., can the company self-attest or is a third party attestation required? The level and degree of self-assessment is also dependent on the nature of the government information in the system and on whether it’s a system operated on behalf of the government or an internal company system containing government CUI. This issue should not be left to individual contract solicitations, but rather standardized so that individual agencies cannot create undue additional onerous requirements. • In the language requiring contractors to certify conformance with sanitization requirements for government and government-related files and information, clarification should be given as to the scope of this requirement, e.g., does it apply to laptops, SharePoint sites, etc.? • Audit and inspection rights should be limited to reviewing artifacts of testing done by the vendor or a third party. Direct inspection of physical facilities by the government is not appropriate, particularly for internal company systems. And, in shared, multi-tenant cloud environments, other tenants may have sensitive data or trade secrets and object to government officials being able to inspect the hardware holding that data. D4. Information Security Continuous Monitoring • The guidance needs more specificity on how government and industry will work together to “implement an appropriate solution that fulfills these CM requirements.” What are the agency vs. company obligations to provide tools and ensure availability? Will there be outcome-based performance measures that are operational targets for everyone to meet? Compliance regimes, in and of themselves, do not guarantee security improvements. • The default position/baseline for government agencies should be the DHS CDM program. Deviation from the use of these tools should require clear justification. • The proposed guidance needs to clarify and distinguish requirements for the two types of systems covered. Particularly in the case of internal company systems, OMB’s proposal to allow agencies to directly monitor a contractor’s systems with the “tools and infrastructure of its choosing” raises significant privacy and legal concerns since the government would be monitoring a private entity’s network and infrastructure. Thought needs to be given to tools and techniques used to verify contractors’ compliance with the monitoring obligation—such as audit rights or validation by a third (private) party—where such reports would be provided to the agency. D5. Business Due Diligence • The idea that GSA would set up a database on companies with bad cyber hygiene based in part upon publicly available information, news reports, etc., is very disconcerting. Great care will need to be taken that any such database is data driven and not based on rumors and innuendos. In addition, there must be due process to dispute erroneous claims, just as can be done to correct erroneous items on a credit report. There must be a well understood due diligence process to ensure accuracy and fairness. A number of issues need to be considered, including: o The right to see what is in the record relating to your company, • One way to mitigate this situation would be to include in the guidance an appeal process. If the company believes it is cited unfavorably or unreasonably for a cybersecurity incident that “punishes” the company on a current contract or for being considered for new contracts, there would be a process for a company to be heard. This would allow a company to explain its position, before the government could cite a company for breach of contract or otherwise provide a negative report on the company. • The draft guidance does not provide any details or standards as to how this database will be used by agencies in procurements. • OMB proposes to produce "risk indicators" for agencies to use in making determinations as to how a contractor assures information integrity and security. The guidance does not provide any direction as to how these risk indicators will be used by agencies in their acquisition activity. Concerns include whether these risk indicators will be uniformly and consistently evaluated, what criteria will be used and who will be performing the evaluations, and how disagreement with the evaluations will be adjudicated by contractors and acquisition staff. OMB should consider if the risk indicators associated with the NIST framework (applied to sectors covered by EO 13636) are suitable in this regard. E. Closing/Other The draft guidance provides a number of opportunities, if revisions are made, to streamline reporting requirements, reduce compliance burdens and improve information sharing between the public and private sectors. A number of additional considerations and issues warrant further discussion and resolution: • OMB must avoid creating burdensome compliance requirements that don’t improve security outcomes. • OMB must avoid perpetuating the current double standard—where industry is required to adopt and pay for requirements not similarly levied on government agencies. Companies are currently expending substantial resources not only to ensure good cybersecurity but to also deal with the many and often disparate compliance burdens levied by federal agencies. • The draft guidance does not address whether and how contracts and contractors should incorporate actions being taken in response to the ongoing OMB “cyber-security sprints,” including the role contractors should play in these sprints. • The draft guidance does not address fairness in the use of FedRAMP, both from the standpoint of agencies accepting reciprocity of authorizations and ATOs and prohibiting solicitation provisions that require FedRAMP authorization prior to being able to submit a bid. • To the extent that contractors are handling personally identifiable information (PII), the draft guidance only speaks to Senior Agency Official for Privacy (SAOP) review and certification. A separate section on how PII should be handled would be helpful, including safeguards, notice, breach response and reporting, etc. • Clarity is also needed on how this draft guidance relates to the recently issued DFARS provisions on network penetration coverage and cloud computing. Finally, it is important that this draft guidance process not take the place of the formal rulemaking process for FAR contract clauses. References to guidelines and standards are not regulatory in and of themselves. The proposed OMB guidance has the effect of imposing a regulatory burden, not to mention additional costs and requirements, while bypassing the regulatory process. |
PSC is the voice of the government technology and professional services industry. On behalf of our almost 400 member companies, we are submitting a number of substantive comments and concerns with the current draft guidance. Here is a link to our complete submission:
https://www.pscouncil.org/PolicyIssues/AcquisitionPolicy/AcquisitionPolicyIssues/Comments_on_OMB_Cyber_Acquisition_Guidance.aspx
The text was updated successfully, but these errors were encountered: