Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Email Comment: Department of Homeland Security Office of the Chief Information Officer and Components #152

Closed
OMBPublicComments opened this issue Apr 11, 2016 · 12 comments

Comments

@OMBPublicComments
Copy link

commented Apr 11, 2016

[Email Comment, received on 4/11/2016 at 1:52PM ET]

Open Source Software Policy Comments (DHS Consolidated).xlsx

@fureigh

This comment has been minimized.

Copy link
Contributor

commented Apr 11, 2016

Copying and pasting the contents of the document for those who can’t open .xlsx files. The views expressed herein are those of the original poster, not my own. All emphasis matches the original:

# RECOMMENDATION RATIONALE
1 Remove lines 229-233, 235-243, 391-400, 414-416 Many private companies (especially security companies) do not publish their source code is because it allows attackers to (a) construct highly targeted attacks against the software, or (b) build-in malware directly into the source code, compile, then replace key software components as 'doppelgangers' of the original. How will this be prevented? Government-specific examples: citizenship anti-fraud rules that are coded into software, identification of special codes used to flag law enforcement actions, APT threat indicator scripts, Mafia having a copy of all FBI system code, terrorist with access to air traffic control software, etc. How will this be prevented?
2 Add new section entitled "Mandatory GOTS and Custom Code License Clause". Add new paragraph in this section: "All Custom Code and GOTS development will contain the following provisions in all Custom Code development contracts and GOTS programs starting the effective date of the memorandum: This software application / source code is licensed as GOTS to the Department/Agency as the sole and exclusive agent of the U.S. Government and must not be released to the public or other non-U.S. Government entities. The government has unlimited and unrestricted government-purpose rights to the software in perpetuity; subject to the obsolescence clause below. The Department/Agency at their discretion, may choose to share or redistribute the software application / source code to other branches of the U.S. Government at no cost to the receiving parties; and subject to the government employee and contractor clause below. Under this license, the government has the right to alter, update, or change the software. The Department / Agency may also utilize or authorize the modification of the software application / source code to develop alternative and derived applications for any alternative purpose; or alternatively designate in writing and post publicly any government entity for this purpose. Parties utilizing this application/source code may not resell or re-license the source code to non-U.S. Government entities or back to the U.S. Government." Reference Comment #1
3 Add new section entitled "Mandatory Government Employee and Contractor Clause". Add new paragraph in this section: "Employees and contractors of the government are only permitted to modify or derive alternative applications from the source code for the sole and exclusive use of the U.S. Government. Employees and contractors of the government who may modify or derive alternative applications from the software application / source code are not permitted to make intellectual property claims upon, or make profit from, the modified or derived source code or applications." Reference Comment #1
4 Add new section entitled "Open Source Clause". Add new paragraph in this section: "Open Source Clause. The Department/Agency may, at its discretion, determine that some or all of the application / source code is suitable for OSS release for use outside of the U.S. Government after an Agency security review and redaction of Inherently Governmental Functions that could pose a risk to the American Public or U.S. Government." Reference Comment #1
5 Add new section entitled "Obsolescence Clause". Add new paragraph in this section: "The Department/Agency CIO must be kept apprised of the re-development, maintenance, and derived applications of this software application / source code and any derived applications. If the Department/Agency fails to utilize and maintain the software application / source code and any derived applications for a period of one year, this license is voided and the software may be petitioned for OSS release after an Agency sensitive information security review, privacy review, and redaction of Inherently Governmental Functions that could pose a risk to the American Public or U.S. Government. Reference Comment #1
6 Remove Footnote 8. Footnote 8. Although Microsoft publishes the .NET framework and Apple provides Swift, neither publish their application source code. An important distinction.
7 Request document address Inherently Governmental Functions and Controlled Unclassified Information (CUI). The policy seems to rely on the CIO's best judgement, but does not sufficiently address the procedures necessary for agencies to make proper determinations. It is clear that OSS is appropriate for functions common between the Government and Civilian sectors. However, when Inherently Governmental Functions, non-FOIA releasable, law enforcement, or security functions that are non-NSS are involved, there is risk that the Government can compromise law enforcement investigations, increase the possibility of fraud or crimes, or compromise security tools not technically NSS.
8 Request provide the rationale for mandatory 20% annual and 80% overall software release figures listed in the policy. There is no justification listed as the basis for this baseline
9 Request analysis of the types of open source software is successful without the need of custom coding, and whether this is the same model that this policy hopes to re-leverage Although Educational Institutions may wish to contribute to OSS; it is unclear whether contractors and vendors will really wish to contribute to Government Open Source improvements. Another possibility is that the contractors or vendors will take the code, improve upon it, then sell it back as COTS to the Government. However, if the source code involves inherently governmental functions; then information regarding those functions could be inadvertently leaked (such as law enforcement or anti-fraud / criminal activity processes, which is not a desirable outcome).
10 Request analysis of the long-term legal and resource costs; as well as impact to domestic versus foreign software development Once source code is released, it is difficult to determine if any of it has been re-utilized in other commercially available programs, such as those developed by foreign software companies. In the event of legal action, does the Government possess the Intellectual Property and Code Vetting resources to protect its interests against commercial companies (both domestic and internationally) abusing the licensing agreement?
11 Request analysis of the impact upon government software development. The benefit to private and foreign corporations is clear, however it is unclear how this policy impacts current Government software developers. If GOTS custom code is given to commercial corporations which can be re-engineered and/or sold (since there are no resources or provisions for code vetting and legal enforcement in this policy), what effect will this have on existing GOTS software development efforts?
12 Request an analysis of the ROI (both domestically and overseas) Although the U.S. once enjoyed a relative monopoly of software development, the growing trend is the outsourcing of software code development overseas. "Globally, only 10 percent of MNCs outsourced IT work offshore in 2002, but that figure had risen to 70 percent by 2008, according to Oppenheimer Equity Research. Gartner Inc. estimates that by 2012, the worldwide IT services market, which is the largest segment within the outsourcing industry as a whole, will top $1 trillion." China Business Review, China’s Emerging Role in Global Outsourcing, Nov 1, 2009. EXAMPLE SCENARIO: Release of U.S. taxpayer-funded code development will, over time, provide foreign access to U.S. GOTS source code but without reciprocation; placing U.S. government-funded software contractors at a distinct disadvantage unless they claim proprietary software rights over the developed custom code. Once that is done, then the software development silo is reborn (but this time in a private company that could go bankrupt or be sold to a foreign entity). The now proprietary code could not be transferred to a new company in the case of a contract change; so the new company would be forced to develop their own system or alternatively purchase the rights from the exiting contractor. To avoid bankruptcy, the exiting contractor could now charge what they wish for the now proprietary code (the exact spiraling cost scenario that this policy presumably claims to avoid). Eventually, this will have the adverse effect of either (a) U.S. code developers not wishing to produce code for the U.S. Government knowing that their intellectual property could be poached by overseas competitors, or (b) ensure that only certain companies maintain proprietary code for which they could charge any undetermined amount.
13 The government should require and facilitate discipline in the development of its software and establish practices/conventions to ensure visibility in use of OSS and ensure the provenance of components in all software used by and for the government.
Ref: Project Open Source (lines 336 and following).
There is a decided lack of recognition of the desirability or need for provenance in open source code use and in re-use of code or applications which might have incorporated such code—especially in embedded information technology/platform computing.
Though source code is to be made available for inspection, the lack of evident methods for vetting and versioning code are likely to result in instantiating and perpetuating version-specific vulnerabilities with no effective method for attribution or remediation.
The policy acknowledges (line 336) the need for use of “existing code repositories and common third-party repository platforms” (lines 338- 339), but there is no forecast of practice, guidance, or rule to promote stability, standardization, or trust.
14 Provide guidelines to assist agencies, particularly those with a national security mission, to determine which source code will be selected as the 20% of developed custom source code for release to the public
Ref: Lines 229-230
Given that national security systems are exempted from this policy, and virtually all DHS systems are deemed mission/business essential, any release of code is potentially exploitable. A "one size fits all" policy across the Federal government is unrealistic. Priorities will need to be balanced.
15 Critical Systems Protection or any computer forensics tools developed through Federally Funded Research and Development Centers (FFRDC) should not be available to the public. If the public and other agencies had access to these tools, it could potentially compromise sources and methods. To avoid having our in‐house developed code becoming open‐source, we will have to either get the DHS CIO approval to the exceptions or declare our in‐house developed systems to be National Security Systems and take them off the Sensitive But Unclassified (SBU) blue line and put them on classified networks, thus increasing our costs of operation and support.
  • Software Engineering Institute (SEI) is a DoD FFRDC. This creates two facts: (1) they cannot open source anything without DoD review & approval, that would be in violation of our contract; (2) The government already has unlimited use rights in all the code we develop. Because of (1), it is not practical for SEI to develop code on a public source‐ code control system. Consequently Carnegie Mellon University maintains copyright and intellectual property rights in the tools developed.

Other concerns:
  • To avoid having our in‐house becoming open‐source, we will have to either get the DHS CIO approval to the exceptions or declare our in‐house developed systems to be National Security Systems and take it off the Sensitive But Unclassified (SBU) blue line and put it on classified networks, thus increasing our costs of operation and support.
16 Provide guidelines for funding and staffing associated with this policy Supporting policy would require another layer of governance across agency that will cost another technical team to review/publish
17 Suggest use of definitions of software in accordance with acquisition policy. COTS software definition should be included in the Appendix A. Clarify Software Procurement Considerations
18 Clarify how this policy is intended to work with OMB M-04-16, Software Acquisition Clarify Software Procurement Considerations
19 This draft should take into consideration OMB circular A-11, A-130 and the Federal Acquisition Regulation (FAR), guide agency information technology (IT) investment decisions. Clarify Software Procurement Considerations
20 This guidance must review and provide acquisition and legal software development guidance. Routinely the government acquires software development with the right to the code but the code itself is the Intellectual property of the vendor. All code should go through an acquisition review prior to any release to open source community (in-house or public). Clarify Software Procurement Considerations
21 Procurement executives and program managers should consult with their General Counsel’s Office to ensure the requirements are understood before using open source software. Clarify Software Procurement Considerations
22 Even with open source there are libraries and modules that are not free to use and require procurement. In addition, it is essential for procurement executives and program managers to make sure employees are aware of the licensing restrictions of the software they are using. Clarify Software Procurement Considerations
23 Consideration need to be defined on how open source software can be brought into and out of the public domain. Exceptions need to be defined that include things that could impact security, legality, acquisition policy, confidentially, privacy and/or protections of CUI type data (including business logic). Clarify considerations for releasing code to public
24 Releasing code to the public should be approved by D/A CIOs and should not be a carte blanche decision.  Each release of code need to be reviewed. Clarify considerations for releasing code to public
25 Need to provide guidance and distinction between code for public use or for other federal agency use Clarify considerations for releasing code to public
26 D/As need policies to govern how code is shared Needs a federal wide policy to control code if shared just to Federal agencies but not intended for public use; need same if shared with Public.
27 Guidance needed for how D/As determine what is deemed usable for public consumption Need “context” of software design. Without context, there are a number of downstream issues
28 Clarify how security will be handled. If Government gets into sharing code, a vulnerability/weakness found in the software provides our enemies with great insight into how to compromise these parts/applications, especially if widely used. Security-based concerns
29 Need minimum thresholds/guidance for how code is tested/verified and maintained before bringing code back into Federal space. Security-based concerns
30 Clarify what is the responsibility for maintaining code base and addressing security vulnerabilities. Is there going to be a government wide repository manager? Is it the owner of the code that posted/shared it? If it is vulnerable, is it removed/deprecated? Security-based concerns
31 Clarify where code will be released? Will there be a Fed Only source code repository with FISMA ID and separate public repository?
If the code is released and later determined that the government did not have right to release what are recourses? How will code be sanitized, recovered from this type of release
Security-based concerns
32 Reference page 3, 1. Objectives, 2 “Establish policy requirements for Government-wide source code receipt and reuse, including requirements for covered agencies to require delivery of source code produced in the performance of a Federal Government agreement and, subject to certain exceptions, make it broadly available Government-wide”.
Who is given this authority to develop policy?
Clarify authority, roles and responsibilities
33 Reference implementation section 6, in accordance with FITARA agency CIOs have responsibilities. It later states Project Open Source will provide guidance and language-- where does this authority come from? If the Project Open Source will provide definitions, evaluation metrics, checklists, case studies, model contract language-- how will evaluation metrics be funded? Code inventories and discovery-- who funds this responsibility? Clarify authority, roles and responsibilities
34 IAW A-130, The agency is responsible for an Information Dissemination Management System, which would include government software. This seems to be in conflict with this policy where they want the programs to work directly with the Project Open Source. This policy should be reviewed by the Department POC responsible for IDMS. Clarify authority, roles and responsibilities
35 Need to include "accessibility" into the "Software Procurement Considerations" (SPC) section as well as in "Appendix B: Software Procurement Analysis". Suggest adding the word "accessibility" in Step 2 of the SPC so it reads "Covered agencies must then select, if available, a software solution that best meets the operational and mission needs of the agency, taking into consideration factors such as performance, total life-cycle cost of ownership, security and privacy protections, interoperability, accessibility, ability to share or reuse, resources required to later switch vendors, and availability of support." Need to add "accessibility" in the Appendix B: Software Procurement Analysis (SPA) section. Suggest adding "Accessibility" near top of the SPA section under "Consider the following factors...." - use the universal symbol of accessibility in front of it to be consistent with other factors. Section 508 accessibility is required by law just as security and privacy are. Including it in this policy clearly identifies it as something that must be included early in the process rather than "bolted on" later at a much higher cost.
@adammaz

This comment has been minimized.

Copy link

commented Apr 11, 2016

DHS raises specter of cyber risks from open source in OMB comments

On Apr 11, 2016, at 15:07, OMBPublicComments notifications@github.com wrote:

[Email Comment, received on 4/11/2016 at 1:52PM ET]

Open Source Software Policy Comments (DHS Consolidated).xlsx


You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub

@waldoj

This comment has been minimized.

Copy link

commented Apr 15, 2016

Mafia having a copy of all FBI system code

wat

@NoahKunin

This comment has been minimized.

Copy link

commented Apr 15, 2016

...build-in malware directly into the source code, compile, then replace key software components as 'doppelgangers' of the original. How will this be prevented?

Is the DHS truly claiming they aren't using hashes or some other method to validate software involved in critical mission operations now? If so, this OSS policy is really the least of our worries.

@inetbiz

This comment has been minimized.

Copy link

commented Apr 16, 2016

Why even bother about this issue? No one is assigned to it. @parisj ?? Is Corina available to Github?

@misdemeaner

This comment has been minimized.

Copy link

commented Apr 16, 2016

Sensitive software is listed as FOUO - For Official Use Only - and that
information is restricted internal only.
There are review procedures in place. They are not going to publish
anything that would be an at risk disclosure.
Having said that - I have seen deliberate abuse of this - where parties label non-sensitive items - to prevent access / criticism of the content involved - and/or to continue funding of pet projects that are clearly worthless - or have public open solutions already in place - but we're paying to make a poor substitute government one.
Worse - duplicate efforts in different government areas are essentially building the same thing. The GAO should be all over this - but again - lack of transparency and correct labelling of purpose - prevents correlation - and cross-pollenization.
Ironically there is probably a need for such government open source and internal sharing more than public!!!
Btw, it's ironic that DHS provided their comments in the form of an Excel
spreadsheet, which is itself a proprietary format that requires Microsoft
software to read natively.

@bharadwaj-raju

This comment has been minimized.

Copy link

commented Apr 17, 2016

To quote Reddit user /u/DopePedaller,

If the bad guys have the ability to replace your binaries with their own, you've got bigger issues that need to be addressed.

https://www.reddit.com/r/linux/comments/4ew1va/dhs_open_source_software_is_like_giving_mafia_a/d248xmi

@johnnewton

This comment has been minimized.

Copy link

commented Apr 18, 2016

The comment "Many private companies (especially security companies) do not publish their source code because it allows attackers to...[et al]" fails to address the primary reason that private companies do not publish their software. They do not release their software because they are trying to make money on it and are trying to prevent other people using it unless they are paid. This is the issue that this policy is trying to address and to deny that will end up costing the Federal Government millions or billions for that very reason. I was the founder of Documentum (closed source) and Alfresco (open source) and are therefore familiar with both models. Security of the software very, very rarely has anything to do with keep code closed.

What this argument fails to take into account, but many military and intelligence agencies have, is that open source is inherently more secure. Transparency of source code means that many more eyes have looked at the code and often corrections are provided by people who discover vulnerabilities. When we have done penetration testing, the pen testers are able to find any potential faults and they are corrected. When code is a black box, it is a race by brute force means to discover the holes. Even then, corrections may take awhile as it goes back to the original team to fix. With open source you have other options.

Having open source also allows for more secure alternatives. Many of the security and intelligence agencies have deeper requirements than the commercial world. With closed source companies, they are at the mercy of the vendor to prioritize those changes that may be useful for a small number of companies. We have already seen that with open source these agencies will create their own alternatives. Using tools like Github, they can keep track of the evolution of the open source platform and maintain their own more secure extensions.

Finally, many closed source products already use 20% open source code at least. Anything written in anything other than .NET probably has significant amounts of open source code. That does not make them insecure. If I were the DHS, I would be more concerned about the large vendors writing significant amounts of code in China, which is later released to the world without the review of the wider open source community.

The comment about the Mafia having access to FBI code is ironic, because the FBI uses open source. Not everything, but some things. That means the Mafia does have access and it does not make one bit of difference. Open code does not mean unsecure code. Transparency and constant review makes secure code.

@johnnewton

This comment has been minimized.

Copy link

commented Apr 18, 2016

A more useful alternative to closing off everything because it may include vulnerabilities is to make secure code the exception. This is not too different from open source companies releasing enterprise features that are not open source. Or indeed, the difference between Classified and Unclassified information. Just as records must be declared Classified in order to have stricter access controls, code could be declared Classified with a similar fileplan process.

Information created by the government is inherently unclassified in the interests of the people and transparency. Code should be no different. The examples of rules for anti-fraud detection is a good example, but by exception rather than by rule. This code could be classified and extended under protected rules. But why should the code such as general purpose libraries, simple user interfaces, connections to common unclassified systems be closed by default. 80-90% of code probably has no impact on the security of any system. This seems very much like a bygone age where much of what some agencies used to do was classified by default, even lunch menus.

In the end, the code is being funded by the people, not the department, and the people have the right to get the most out of their investment in the code, just as they have a right to the information that has been created in their name.

@lukemccormack

This comment has been minimized.

Copy link

commented Apr 18, 2016

We appreciate the discussion around these topics. The comments posted here reflect a variety of individual positions across DHS components, but they do not represent DHS policy or views. We have now posted new comments (#222) reflecting the DHS Office of the Chief Information Officer’s formal position.

Luke J. McCormack
Chief Information Officer
Department of Homeland Security

@misdemeaner

This comment has been minimized.

Copy link

commented Apr 18, 2016

This is unusual Deja Vu .. as this argument was resolved years ago in favor of open source. Perhaps the DHS CIO should be consulting non vendor experts.. as getting DHS up to speed and in alignment with the scientific community is beneficial to the country.

@Scotchester

This comment has been minimized.

Copy link

commented Apr 18, 2016

@lukemccormack Thank you for clarifying your department's official position!

@chasingamy chasingamy closed this Apr 19, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
You can’t perform that action at this time.