Skip to content
This repository has been archived by the owner on Mar 3, 2022. It is now read-only.

Raytheon's Comments on Proposed Guidance #59

Open
RaytheonCompany opened this issue Sep 10, 2015 · 0 comments
Open

Raytheon's Comments on Proposed Guidance #59

RaytheonCompany opened this issue Sep 10, 2015 · 0 comments

Comments

@RaytheonCompany
Copy link

Raytheon Company has reviewed the “Improving Cybersecurity Protections in Federal Acquisitions” draft guidance and has the following feedback regarding its content and proposed requirements.

Our primary concern lies with the usage of past performance issues for “non-cost evaluation factors” as it pertains to security controls. Defense contractors have voluntarily been forthcoming in offering information on or related to cybersecurity compromises on their networks through the DIB CS/IA voluntary framework and similar channels. This was facilitated through the guarantee that such information would not be used against contractors in evaluating bids. In contrast, the OMB guidance as stated may result in decreased information sharing and collaboration across the DIB and reduce overall DIB’s cyber awareness.

The policy states that due diligence may encompass “public record, publicly available… data,” would provide questionable benefit as many open sources, such as news media, struggle to present discrete cyber incidents accurately, much less the organization and the general concepts overall. In addition, the guidance does not indicate whether contractors will be able to view and provide input into any such diligence assessments, and does not delineate how exactly the government will use due diligence. Raytheon recommends due diligence without the use of public or commercial subscription data.

The expectation that contractors are to provide access to systems and personnel used in the performance of the contract, regardless of location, for investigations and evidence preservation during incidents also raises concerns. The contractor may have other agreements or non-disclosure agreements that create legal conflict with this requirement.

The expansion of the cyber incident reporting requirement will prove burdensome. As a member of the DoD’s Defense Industrial Base Cybersecurity and Information Assurance (DIB CS/IA) voluntary sharing program, Raytheon already submits incident reports as needed. In fact, the DIB CS/IA program was established to serve as a single point of entry for reporting such incidents and act as the nexus for information exchange between DoD and contractors. Multiple reporting stream requirements will result in inefficiencies and hinder the response and remediation process overall. We also recommend that the guidance make clear that the cyber incident reporting requirements apply only to CUI that is marked by the government or should be marked by contractors pursuant to clear government instructions in contract, in order to assist contractors in their efforts to comply with the reporting requirements.

In addition, the guidance does not address how the Government should protect proprietary and attribution information shared by contractors that report cyber incidents. We recommend that appropriate restrictions and parameters be used to protect unauthorized use or disclosure of such information.

We recommend that reporting responsibility be with the prime contractor with whom the government agency has a direct contractual relationship. There is concern that sub-contractors may leapfrog the prime and directly notify the government agency due to confusion on reporting requirements.

This draft guidance allows US government agencies to define specific control requirements, such as the required timeline for incident reporting. Such variances between agencies will create confusion and undue administrative burden on defense contractors for meeting compliance. In certain scenarios, a determination will need to be made on what requirements take precedence in situations where requirements are in conflict.

Raytheon agrees that information system security assessments play a critical role in verifying the implementation of security controls in information systems being operated on behalf of the government. However, Section 3 is rather vague on the scope and expectations of conducting the same on internal contractor systems and could become a significant effort. Consequently, it would be beneficial to identify the cost category that will be utilized to capture the work associated with completing this activity. We recommend allowing self-assessments for contractor’s internal systems with documentation being provided if requested. In addition, given contractor concerns for protecting proprietary and/or privileged information, the guidance should address these concerns with appropriate restrictions and protections when providing for access to contractor facilities, systems, and other property for the purpose of conducting security assessments.

The cost impact of levying these security controls on the internal systems of smaller subcontractors and suppliers cannot be overstated. The success of major programs is built on such companies that could potentially be put out of business due to the sheer cost of control implementation. For example, NIST 800-171 3.5.3 introduces a multifactor requirement for network access of non-privileged accounts. Since a company’s email system will store CUI, and generally all employees use that system, this requirement effectively mandates multifactor for all employees within a company. That is not a cost that is easily absorbed, especially for our smaller suppliers. Beyond cost, there is an overarching concern on the efficacy of certain security controls.

While many of these controls are best practice, not all have a non-trivial impact to the security posture. We recommend the security requirements be prioritized. A more stratified approach to control requirements would be more digestible than the current one size fits all approach. This would go a long way in enabling smaller companies to know where they need to spend incremental funding.

Thank you for the opportunity to offer feedback on the draft guidance.

Jeff Brown
Vice President, IT Security and Chief Information Security Officer
Raytheon Company

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant