Comments from the Department of Homeland Security's National Cybersecurity Assessments and Technical Services (NCATS)

[cisagov]

This comment represents only the views of NCATS, not necessarily those of the US Department of Homeland Security or its Chief Information Officer.

We are the National Cybersecurity Assessments & Technical Services (NCATS) team, a unit inside the Department of Homeland Security’s National Cybersecurity and Communications Integration Center (NCCIC). NCATS concurs (and applauds!) the comments posted by the DHS CIO (#222).

Thank you for this opportunity to submit comments, and for extending the deadline.

To what extent is the proposed pilot an effective means to fuel innovation, lower costs, benefit the public, and meet the operational and mission needs of covered agencies?

As a federal team that includes software developers, penetration testers, and security analysts, NCATS supports any government initiative that enables technologists, federal or not, to reuse or enhance others’ work, especially to reduce cost and duplicative effort, speed the delivery of products and services, and solve hard, shared problems. Open sourcing government-produced or -procured software is an important way for the public to be more direct beneficiaries of the services they have paid for. It also enables direct collaboration and information sharing which, if engaged in transparently, creates trust. This trait, along with increased software security generally, is what we hope to see because of this action.

Would a different minimum percentage be more or less effective in achieving the goals above? Would an “open source by default” approach that required all new Federal custom code to be released as OSS, subject to exceptions for things like national security, be more or less effective in achieving the goals above?

Defaults are important because they codify norms. In our networks, we like to see ingress/egress policies where traffic is denied by default and opened by exception. We prefer open source policies with the reverse characteristics.

• For federal teams, defaulting to open demands better work because we’ll know we’re being watched. Naturally, those federal teams not operating fully in the open like this policy envisions (e.g., NCATS) will need to instantiate new processes to operate this way; however, such processes will help us be more responsive and accountable to our stakeholders, the public, and ourselves.
• For federally-procured code, 20% seems too low a target. We note that any approach below “open source by default” will by nature create a regime of bureaucracy that doesn’t serve (and will likely actively detract from) the goal of creating value for the American people.

In Section 2 (PDF lines 89 and 90), it states that “this policy applies to all custom code created by covered agency employees in the course of their official duties...” However, Section 5.1 appears to contradict this, indicating that “Each covered agency shall release at least 20 percent of its newly-developed custom code each year as OSS.” Footnote 36 seems to resolve this tension, but the body of the policy should be updated to clarify that 20 percent of new externally-developed custom code should be shared, not that only 20 percent of covered agency employees’ custom code be open sourced.

What are the advantages and disadvantages associated with implementing this type of pilot program?

Section 4 (PDF lines 173 and 174), speaking of externally-developed code to which one agency has secured government-wide code reuse, “covered agencies must make custom-developed code available to all other Federal agencies.” If the 20% (or any percent, for that matter) rule stands, how would OMB propose sharing code that isn't open sourced but is intended to be reused by other federal agencies? If the solution is a single federally-accessible system, authenticated access would be a major control against loss. When access is obtained without authentication (i.e., when the system is hacked, which we know happens to government systems), the government is effectively at the same state as if “open by default” was the rule. If the solution is multiple systems owned and operated by the developer (procurer) of the code, how will access to the system be provided? This second example still suffers from hackability, though it doesn’t follow an “eggs in one basket” approach-- which is great for security and really bad for code discoverability or usability, even if a code inventory is robust. Both are examples of overhead that wouldn’t be necessary with an “open by default” approach.

In reference to the “all custom code” clause for covered agency employees, we suggest “all” be loosened very slightly, or at least given more color. We submit that one-off scripts or anything not significant enough to be committed to a repository should be exempted from the policy unless they are intended for reuse (or are actually reused), or if there is some novelty or broader potential for usefulness. We recognize 'broader usefulness' can be difficult to predict a priori. In the face of doubt, though, openness should prevail.

How broadly should an open source policy apply across the Government? Would a focus on particular agencies be more or less effective?

We submit that the open source policy should apply across the government equally. It is worth noting that some agencies with a clear intelligence or national security mission are already posting some source code publicly.

A 2012 study funded by the DHS Science and Technology Directorate concluded “To maximally use its limited resources, the U.S. government must… reduce the unnecessary barriers to the use and development of OSS.” We concur.