Software Security Perspectives with Joe Jarzombek from The Department of Homeland Security

Joseph Jarzombek serves as Director for Software Assurance in the Policy and Strategic Initiatives Branch of the National Cyber Security Division (NCSD) within the Department of Homeland Security (DHS). He hosts and sponsors many public-private collaboration efforts focused on software security. He recently spoke at the AIE Conference on Military Open Source Software, and he shared his perspectives on “Security Considerations in the Use of Open Source Software". The following is my commentary and his words from the conference.


Ernest Park: The weakness in blind trust of a decentralized community was clearly pointed out with the recent Debian issue(http://www.metasploit.com/users/hdm/tools/debian-openssl/ ). Without objective mandatory and measurable delivery against processes, software flaws can go unnoticed for periods of time. Joe, is this an example of existing complacency in the use of open source software, and who should accept responsibility for this major security oversight?

Joe Jarzombek: The OSS community still needs a mature and widely-recognized OSS governance regime. If organizations were to adopt OSS, then our acquisition and security personnel need to become more OSS-savvy. They would need to establish an OSS security expert role for verifying and enforcing OSS conformance to organizational requirements and policy.

Ernest Park: It seems like a well organized group with political or financial motivations could wreak havoc on our country using open source software to open the doors to an attack. Is the government concerned about open source applications being used to hide intentionally hidden trojans and coding flaws, such that institutions using such software can be exposed to highly targeted attacks?

Joe Jarzombek: As part of enterprise risk management, organizations should evaluate the trustworthiness of suppliers, and that includes enhanced due-diligence to better understand the pedigree or provenance of the software and the capabilities of the suppliers to deliver secure products and services before acquiring any developers' OSS. Generally the significant OSS projects are maintained by well known developers in the community. They would have to make sure the project team monitored each developer's initial contribution or only his/her later modifications and updates. Their process would also need to include checks/controls to establish developers' identities and trustworthiness. The developers' geographical locations, nationalities, affiliations, ideologies, and loyalties are also easier to obtain with OSS. On OSS projects, it's often possible to discover developers' identities (at least who they claim to be). The same is not true of many proprietary software projects/developers.

Ernest Park: The FLOSS, OSS, FOSS, free software, open source community is a non-centralized ‘socialist’ network. Does the lack of perceived central responsibility pose a higher obligation of risk awareness and mitigation on enterprise users of these applications?

Joe Jarzombek: First, people should understand that many of the issues identified with OSS are equally true for proprietary software. The ability to determine pedigree/provenance should be one factor, but not the only factor, in decision-making on whether or how to proceed with software security evaluation. If there is inadequate information then there needs to be deeper security analysis, vulnerability mitigation and environment-level isolation and constraints to separate “not yet trusted” from “more trusted” software. If there is no pedigree/provenance information then that has sometimes been used as a reason to reject the software especially if it were to be used in national security systems with US only content requirements.

Ernest Park: Do you feel that enterprises are exposing themselves to undue risk if they choose to save money by using open source applications without budgeting for additional resources to manage and oversee such applications?

Joe Jarzombek: Many organizations are already looking into additional resources to manage and oversee applications that they might use. Several companies such as Palamida and Black Duck Software offer discovery programs that will find "hallmarks" in the source code, COTS products, and large software systems. Several companies now offer services that focuses on software security. We have also collaborated with vendors who have made a business out of scrutinizing OSS code, such as Fortify Software, Ounce Labs, Coverity, Cigital, and others. OSS "commodification" potentially provides the best of both worlds: OSS design/code openness and vendor support.

Ernest Park: I have run into some efforts to increase usage of open source within government. Has DHS been involved with these efforts, and is any policy defined to assure high operational security for all applications going forward?

Joe Jarzombek: DHS has sponsored the Vulnerability Discovery and Remediation Open Source Hardening Project in which Coverity, in collaboration with Symantec and Stanford University, evaluated popular OSS to discover and remediateexploitable vulnerabilities.. In this project 40+ OSS packages, including Linux, Apache, MySQL, Perl/Python/PHP were evaluated for vulnerabilities. 11 packages were remediated.

Ernest Park: What should we be doing as a minimum to insure that we are diligent, responsible technology users and proud citizens defending our homeland?

Joe Jarzombek: The broader stakeholder community needs to be security-aware with a better appreciation of just how much our enterprise missions are more at risk because of exploitable software. These risks have to be mitigated during development and in use. We need more security-informed procurements. As consumers we need to exercise more due-diligence in selecting software suppliers and products More comprehensive software diagnostic capabilities need to be used by developers and testers. Also problems that are found need to be reported as soon as possible so that they can get fixed immediately, ideally before code is released. And users should also keep their software up to date by installing the latest patches.

Ernest Park: Has anyone assembled a best practices guideline for using your data sources to more securely and proactively manage our computing environments? Joe Jarzombek: Our DHS Software Assurance “Build Security In” website offers many publicly available resources which are free to download. BSI at https://buildsecurityin.us-cert.gov/ offers several sound practices from respected practitioners of software security. David A. Wheeler is well know for his contributions in OSS endeavors. He has released papers and projects on OSS and security, including "Open Source Software (OSS) and the U.S. Department of Defense (DoD) – Webinar". If people are interested in further collaboration on software security practices, I would invite the to join us in future Software Assurance Forums and working group sessions which are publicized on our BSI web site under Events.

Ernest Park: We are repeatedly told that the next big attack will come via the internet. What steps can I do to empower myself, my fellow software users and my country to proactively defend, and more predictively manage my environment?

Joe Jarzombek: Software users should, as a minimum, perform a security evaluation on the programs they choose to use that answer these questions:

• Are the software's security assumptions consistent with the security assumptions made by and about the component that the software will implement?
• Can unused functions and interfaces be removed, disabled, or fully isolated without affecting the correct execution of other functions?
• Does the software expose and provide access paths (intended or unintended) to its vulnerabilities?
• What are the common exploitable weaknesses in the code, and what form of static or dynamic code analysis has been performed to determine the resiliency of that code?
  

The open design and source code availability of OSS should make security evaluation easier.

References:
http://ttcus.com/oss/
The Military Open Source Software Conference
April 21-22, 2008
-Goertzel-Jarzombek-OSS_Security SwA.ppt

Trust but Verify

Ronald Reagan

Farewell Address to the Nation, Oval Office, January 11, 1989

"If they persist, pull the plug. It's still trust but verify. It's still play, but cut the cards. It's still watch closely. And don't be afraid to see what you see." http://www.reaganlibrary.com/reagan/speeches/farewell.asp

This is a file from the Wikimedia Commons. The description on its description page there is shown below. Commons is a freely licensed media file repository.

This is the first time that I have had the justification to quote the late President Ronald Reagan to make an obvious point. In the Debian example, the open source community trusted that someone else would look and find the problem. Users believed that the power of community review would reduce the risk of using the software. Users were lulled into a complacency whereby nobody felt the obligation to "verify". Just like when an accident happen, we cannot all just assume that someone else will call 911, offer assistance, get involved. If we accept the socialism of free software, then we must mutually accept the responsibilities associated with the use of such software, or we must impose the obligations of these responsibilities onto the vendors that offer service agreements for such software.

I in no way single out open source software from proprietary software. The point is that just because there is nobody to blame does not mean we cannot look for problems. In the use of open source software, we must be prepared to know how to look, qualify the process by which software is checked and validated, and then centrally and proactively share this information. Forums exist for the distribution of risk issues, and copious amounts of data has been amassed to allow management of complex environments. Regardless of whether the applications being used are "open source" or proprietary, objective rules and guidelines must be put in place and enforced in order to assure that the power of the community actually means something. I tend to believe that long past are the days when each user would be forced to review source of any distribution prior to compiling for one's own platform. We as users find it too easy to download the bits, decompress and run. We entrust that in the community of users, someone else will find the problem. This complacency to decentralized responsibility can lead to big problems. The use of open source alternatives to prorietary software is not more risky, it just imposes objective responsibilities and processes that must be abided to in order for open source solutions to continue offering an advantage in the workplace.

Users need to realize that nothing comes free. If we look at the real savings of open source software as that of time, the budget usually allocated to the purchase of commercial solutions can be spent to provide diligent review and management of "open" applications, following documented guidelines, with results of such copious review being continually shared with the community.