Here’s a fun experiment (if, like me, you’re a huge nerd): take an open source policy from your agency, company, whatever, and strike out the words "open source." Bam, you now have a much more sensible and reasonable "software" policy.
When the OMB and DOD declared open source software to be "commercial software," it wasn't a bureaucratic trick to legitimize open source. They meant it quite literally: software is software, and whether it was developed by open source, a proprietary company, or a team of monkeys, all the same rules apply. So if you're writing an "open source software policy," why not write a policy for the rest of the software world while you’re at it?
Let's take IRS' guidelines for using open source software. There's some good stuff in here, and long-debunked myths as well. All this can be fixed by striking the words "open source," turning the document into a "software policy" instead of an "open source software policy."
Let’s get started:
Open source software, while it can be useful in many instances and appear to be cost effective, may present a security risk because open source developers don’t typically follow security best practices when developing their software.
When I read this, my jaw dropped. We can argue about whether open source is a more secure model for software development (which it is, just ask Bruce Schneier) but we can’t summarily declare open source developers "typically" less concerned about security. That’s silly. Some of the most-reviewed, most-secured software is open source. Some of the finest minds in security are open source developers.
Also, it’s not like proprietary software is magically more security-conscious. Proprietary developers can be sloppy, companies can have poor development practices, and it’s just as likely that a bad actor will work for a proprietary software company as contribute to an open source project.
With that in mind, we can take out the words "open source," and the sentence is suddenly much more reasonable.
Additionally, support for the open source software is not always provided by the vendor, and open source vendors can be slow to respond to identified flaws in their applications with a security fix.
I work for an open source software vendor, and this is news to me. Our track record is actually stellar. I've seen no evidence and can think of no earthly reason why open source vendors would be slower to identify and respond to software flaws as a class. Again, generalizations like this are silly.
The underlying concern, though, is valid. Unsupported software presents a risk. Poor support is almost worse—think of the hours we’ve all wasted with an unqualified or unresponsive support operation. This isn’t specific to open source. Bad support is bad support, no matter how the software was developed.
Again, take out "open source," and this becomes much more accurate, and a lot less FUD-y.
Additionally, many open source software products are part of an open community that allows anyone to contribute updates and bug fixes, which isn’t always done with security in mind, so the onus is on the distribution channel to validate releases.
I’m starting to call this the "Wikipedia Myth." This clause makes it sound as though open source software is freely editable by anyone with an email address. This is obviously not the case, as anyone who’s worked with open source can tell you. Open source communities have elaborate systems for code review that can rival what's in place in proprietary development shops.
Again, though, the underlying concern is valid and the remedy is sensible. If you’re concerned about the integrity of your software, you should get the software from someone you trust.
When deciding to procure open source software, the agency should seek companies that will provide software support, and consider the cost of potentially having to pay a third-party to support the software by issuing security patches and bug fixes if direct support from the software vendor is not an option.
This clause make a lot of sense. You don’t want to run unsupported software. You want to be able to call someone to tell them about a problem, and you want them to respond promptly. The authors had open source in mind, but the need is just as strong for proprietary software. What happens if your proprietary vendors goes out of business? What if they get acquired? What if the product is discontinued? Again, the problem and the remedy apply to proprietary software just as easily as they apply to open source.
The agency should also consider the open source software's ability to comply with IRS Publication 1075 security requirements. For example, any software that will transmit federal tax information (FTI) must encrypt the FTI using a FIPS 140-2 compliant encryption module that has been validated through the NIST Cryptographic Module Validation Program (CMVP).
Here's another clause that makes sense. The IRS has a non-negotiable need for security certifications like FIPS 140-2, and any software must comply with those requirements. That's true for proprietary and open source alike.
IRS Safeguards recommends any agency considering the use of FTI in open source software mirror the IRS policy that is used internally at the IRS to govern the use of open source software. The IRS Policy in the Internal Revenue Manual (IRM 10.8.1.4.4.1) is that open source software can be installed on IRS systems if it is—
- Legally licensed software
- Approved by IRS Modernization and Information Technology Services (MITS)
- Adheres to a secure configuration baseline checklist either from government, industry or the software vendor
Agreed! It’s actually kind of funny that once you get through all these concerns about open source, the actual policy only requires that you adhere to the terms of the license, configure it properly, and get approval from the IT department. Just like proprietary software.
So here's the "de-open source'd" version, which I think reads much better:
Open source sSoftware, while it can be useful in many instances and appear to be cost effective, may present a security risk because open source developers don’t typically follow security best practices when developing their software. Additionally, support for the open source software is not always provided by the vendor, and open source vendors can be slow to respond to identified flaws in their applications with a security fix. Additionally, many open source software products are part of an open community that allows anyone to contribute updates and bug fixes, which isn’t always done with security in mind, so the onus is on the distribution channel to validate releases.
When deciding to procure open source software, the agency should seek companies that will provide software support, and consider the cost of potentially having to pay a third-party to support the software by issuing security patches and bug fixes if direct support from the software vendor is not an option.
The agency should also consider the open source software's ability to comply with IRS Publication 1075 security requirements. For example, any software that will transmit federal tax information (FTI) must encrypt the FTI using a FIPS 140-2 compliant encryption module that has been validated through the NIST Cryptographic Module Validation Program (CMVP).
IRS Safeguards recommends any agency considering the use of FTI in open source software mirror the IRS policy that is used internally at the IRS to govern the use of open source software. The IRS Policy in the Internal Revenue Manual (IRM 10.8.1.4.4.1) is that open source software can be installed on IRS systems if it is—
- Legally licensed software
- Approved by IRS Modernization and Information Technology Services (MITS)
- Adheres to a secure configuration baseline checklist either from government, industry or the software vendor
4 Comments