Open source software is an attractive option for organizations looking to employ inexpensive or “free” solutions into their environments. This desire must be tempered by a thorough understanding of the pros and cons associated with the use of these applications. Using this information, organizations can make a risk-based decision as to whether or not they should use this type of software. Open source software is ubiquitous and is relied upon by major organizations throughout the world. Organizations such as Linux Foundation, Apache Software Foundation and Mozilla develop open source software solutions that are considered the industry gold standard. This software consists of or resides on everything from graphics cards and central processing units (CPU) to workstations, web browsers, web servers, server clusters, firewalls, routers, intrusion prevention systems and everything from smartphones to massive virtualized computing environments. Without open source software, it is possible that our current computing environment would not be nearly as mature as it is today. One of the most highly touted reasons for using open source software is the fact that it may be inexpensive or “free.” One of the big questions regarding how this software can be provided at low or no cost is answered by understanding that these applications have several sources: College or university departments that have a team of software development students or researchers focused on a specific topical area. Not-for-profit organizations consisting of paid and volunteer developers (e.g., Mozilla, Apache). Many times, these organizations are supported both financially and with development personnel, by traditional vendors that rely on this software as well. Developers (individuals or small teams) with an interest and expertise in a topical area (e.g., tcp wrapper – Wietse Venema). The reason for providing this background information is that it is important to understand the organization residing behind or supporting the continued development of the application under consideration. Depending on the application and the organization that stands behind it, there may be a tremendous amount of support for evaluating the software. An example of this is OpenSSL. When the Heartbleed vulnerability was identified, developers immediately worked to assist with remediation efforts. Patches were available within 24 hours of the vulnerability being officially registered. There are some areas of concern to consider regarding the use of open source software: It may be unknown whether the developers follow security best practices when developing their software. In comparison, many vendors have developed strict security development lifecycle models for their proprietary products. It may be difficult to determine whether an organization developing an open source application adheres to a mature development methodology that incorporates security principles. The security programming skills and vulnerability testing expertise, associated with the development of the application may be unknown, unacceptable or unable to meet IRS Publication 1075, Tax Information Security Guidelines for Federal, State, and Local Agencies (Pub 1075) requirements for secure software development, deployment and maintenance. Support for open source software is not always provided because it may not be backed by a vendor. Per Pub. 1075, Section 4.17, Unsupported System Components (SA-22), all system components must be supported. Training for the proper implementation and maintenance of this application may not be available to operations staff. Open source software maintainers may be slow to respond to identified flaws in their applications with a security fix; however, this may be no different than with closed source software developers. Open source software does not always integrate NIST-validated, latest FIPS 140 compliant encryption modules for the protection of federal tax information (FTI). When deciding to procure open source software, IRS recommends that the agency pursue a conservative approach and seek organizations that will provide assurance that a secure development lifecycle is employed and that software support for the application being considered for use is available. This may include the use of a third-party vendor that specializes in supporting this application, but is separate from the primary development organization. As mentioned above, this may be required if direct support from the software developer is not an option. Any agency considering the use of FTI in open source software must adhere to the following considerations: Software that will transmit FTI must encrypt the FTI using the latest FIPS 140 compliant encryption module that has been validated through the NIST Cryptographic Module Validation Program (CMVP). Software must be supported, by a vendor or organized community. Resources Publication 1075, Tax Information Security Guidelines for Federal, State and Local Agencies and Entities PDF NIST Cryptographic Module Validation Program (CMVP) Open Source Initiative – OSI Corporate Sponsors and Support
