Page 12 - GCN, May 2016

CYBEREYE
BY BRIAN ROBINSON
Should we secure code before or after sharing it?
WHITE HOUSE OFFICIALS
want federal agencies to share more of their custom code with one another and provide more of it to the open-source community. That kind of reuse and open-source development of software could certainly cut costs and provide better software in the future, but is it also an opening for more bugs and insecure code?
The new draft policy, issued in support of the Obama administration’s 2014 Open Government Partnership, seeks to improve the way custom- developed code is acquired and distributed. Before moving forward with the policy, the government has asked for public comments so that it can understand how the approach would “fuel innovation, lower costs, benefit the public and meet operational and mission needs of covered agencies.” Officials also want to know what effect the policy might have on the software development market.
One thing the draft poli- cy doesn’t address directly is what impact government code could have on the security of any open-source software that results.
John Pescatore, director of emerging security trends at the SANS Institute, is
one of the experts who
has expressed concern. In comments about the draft, he points out that the government’s testing of its own code for vulnerabili- ties “has been minimal and inconsistent.”
That has sparked an
interesting discussion about the government’s role regarding code released
to the open-source com- munity. Pescatore said
he believes scanning for vulnerabilities before code is released wouldn’t be a big deal.
Others, however, believe that responsibility belongs to the open-source com- munity, which has long maintained that the more eyes the more secure the open-source code is.
Well, yes and no. That was the argument behind OpenSSL, for example, and yet a vulnerability that went unnoticed for years led to the global Heart- bleed bug and fears of widespread data leaks and breaches.
However, it’s also true that open-source code has consistently been found to be more secure than most proprietary code, though it’s not infallible by any means.
In the case of govern- ment code released to the open-source community, it will be interesting to see which would turns out to bethebestwaytogo— especially considering that some of the code might find its way back into government use at other agencies.
So sanitize before release or trust to the community to eventually secure it?
Pescatore has his doubts. Software is software, he said, whether it’s open source or proprietary. And if simple vulnerabilities are not removed before it’s released, “it is bad software.” •
What feds think
of the open-source policy
The Obama administration’s draft open-source policy drew more than 200 public comments. Among the highlights:
“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.”
— Department of Homeland Security’s National Cybersecurity Assessments and Technical Services
“The denominator of the 20% requirement [for publicly releasing code] should be the number of systems (as defined in the agency’s system inventory) — not the # of lines of code under the agency’s purview.”
— Noah Kunin, director of delivery architecture and infrastructure at 18F
“When managed appropriately, releasing code as [open-source software] and engaging with the community can have extensive cybersecurity benefits. Security through obscurity is not true security.”
— DHS CIO Luke McCormack
The full list of comments can be found at
is.gd/GCN_code_comments.
10 GCN MAY 2016 • GCN.COM