Open-source licenses, the CISSP, and the real world

Last Updated on July 14, 2017 by Dave Farquhar

You may have a question about open-source licenses on your CISSP exam. I don’t remember the specifics and wouldn’t be able to repeat them anyway, but I had a question on my exam where knowing the differences was helpful in finding the right answer.

And I had to deal with an issue this past week involving open-source technologies where the licenses made a big difference.

The thing to remember is that not all open-source licenses are interchangeable. Although the motivation behind all of them is to share code so that anyone can modify it, there are significant differences in the specifics. The GPL (GNU Public License, also known as Copyleft) allows you to make changes but requires you to share any changes you make. That way, if you make a significant improvement to the code, the community can assimilate the improvement too, to everyone’s benefit. BSD (Berkeley–as in University–System Distribution) is an example of an open-source license that doesn’t require you to share those changes. BSD advocates argue this is actually more free. There’s something to that argument; the difference is whose freedoms you’re trying to protect.

Here’s where the difference made a difference in my work life in recent days. A client failed a security scan due to its Checkpoint firewalls running OpenSSH 3.6.1. The scanning software flagged OpenSSH 3.6.1 as having a buffer overflow condition. This vulnerability was patched a million years ago–well, 2003 if you’re counting–but the scanner saw the version number and threw a fit, which caused the auditors to throw a fit. I found a statement on Checkpoint’s web page stating that they’ve backported all relevant security patches to the version of OpenSSH 3.6.1 in their products, but that spurred another discussion. (A good vulnerability scanner will know the difference between different flavors of OpenSSH 3.6.1, but that’s another discussion. These guys weren’t using Qualys.)

One CISSP took Checkpoint at its word, which I was inclined to do. Had they not fixed it, a hole that big in such a popular product would be all over Slashdot and other tech news sites, right? Two other CISSPs hated that, saying you should never take any vendor at its word, and one called it horrible project management. Good program management requires milestones to track, he said.

I think that’s a double-standard, since we routinely take closed-source vendors at their word, deploying patches that we can’t examine in-depth. If we don’t trust Checkpoint to correctly patch and re-compile its code, why do we trust closed-source vendors? At some point, every vendor gets some benefit of the doubt. And if someone finds an exploitable condition in the revised code, a new patch gets issued.

I have a counterargument. I’m a sysadmin by trade, and I spent about half my career (not consecutively, thankfully) taking after-hours phone calls when stuff breaks unexpectedly. I know what it’s like to get two hours of sleep because the phone rang all night, then still have to come in to work and put in a full 8 hours or more. Having been that guy, I actually like Checkpoint’s approach. Fix the security issues, while leaving everything else the same, then you’ll have fewer problems. The danger when you just blindly upgrade to the new version is that something you were using got deprecated and stopped working. To see a demonstration, just build a Debian Linux server using an old version, then upgrade to the current version. Odds are the server won’t work anymore. That’s why Debian backports security fixes to individual components while holding the version number absolutely as steady as possible, and saves proper version upgrades for new releases of the entire distribution. Debian’s done it that way for more than 15 years, it works marvelously, and sysadmins love it for that.

And if there’s one thing I want to work consistently, with no surprises in the dead of night, it’s the firewall. That’s probably why Checkpoint takes an approach that’s a step beyond what Debian does.

Sure, that’s why you test, but testing doesn’t always find everything. I’ve seen products work just fine in a lab for months, then fail in production within a matter of hours. It doesn’t always happen, but in my experience, the closer you can stay to the configuration that’s worked in the past, the lower your chances of having issues.

So there’s an argument in Checkpoint’s favor, and I’ll stand by it. By-the-book project managers will disagree with me, but a good number of those with sysadmin backgrounds will agree with me, or at least concede I have a point.

Back to our story.

One way to make everyone happy would have been to download the source code for Checkpoint’s OpenSSH and look for the changes, which are brief, well documented, and simple enough that a guy like me who took one college class in C can follow them. But there’s the rub: OpenSSH is BSD-licensed, not GPL. So Checkpoint is under no legal obligation to release that particular code. If they have indeed released it, it’s buried deeply enough that I couldn’t find it.

The majority were willing to take Checkpoint at its word, so that was the end of the issue. But it’s a real-world demonstration of how not all open-source licenses are created equal.  In this case, the BSD license was good for the vendor, but a GPL license with fully open, auditable source code would have made demonstrating compliance with good security practices much easier.

If you found this post informative or helpful, please share it!

One thought on “Open-source licenses, the CISSP, and the real world

  • February 6, 2012 at 1:52 pm
    Permalink

    In your example, yes, Checkpoint would have had to distribute the source. But one minor point – GPL only requires that you share the changes in code whose object you are distributing. In-house, you can change GPL code all you like, but distribute the object code outside the organization, and you have to make the source available as well.

Comments are closed.