The "Oyster card" used on the London Tube was at issue in the Dutch case, and a similar fare card used on the Boston "T" was the center of the U.S. case. The Dutch court got it right, and the American court, in Boston, got it wrong from the start -- despite facing an open-and-shut case of First Amendment prior restraint.

The U.S. court has since seen the error of its ways -- but the damage is done. The MIT security researchers who were prepared to discuss their Boston findings at the DefCon security conference were prevented from giving their talk.

The ethics of full disclosure are intimately familiar to those of us in the computer-security field. Before full disclosure became the norm, researchers would quietly disclose vulnerabilities to the vendors -- who would routinely ignore them. Sometimes vendors would even threaten researchers with legal action if they disclosed the vulnerabilities.

Later on, researchers started disclosing the existence of a vulnerability but not the details. Vendors responded by denying the security holes' existence, or calling them just theoretical. It wasn't until full disclosure became the norm that vendors began consistently fixing vulnerabilities quickly. Now that vendors routinely patch vulnerabilities, researchers generally give them advance notice to allow them to patch their systems before the vulnerability is published. But even with this "responsible disclosure" protocol, it's the threat of disclosure that motivates them to patch their systems. Full disclosure is the mechanism (.pdf) by which computer security improves.

Outside of computer security, secrecy is much more the norm. Some security communities, like locksmiths, behave much like medieval guilds, divulging the secrets of their profession only to those within it. These communities hate open research, and have responded with surprising vitriol to researchers who have found serious vulnerabilities in bicycle locks, combination safes (.pdf), master-key systems and many other security devices.

Researchers have received a similar reaction from other communities more used to secrecy than openness. Researchers -- sometimes young students -- who discovered and published flaws in copyright-protection schemes, voting-machine security and now wireless access cards have all suffered recriminations and sometimes lawsuits for not keeping the vulnerabilities secret. When Christopher Soghoian created a website allowing people to print fake airline boarding passes, he got several unpleasant visits from the FBI.

This preference for secrecy comes from confusing a vulnerability with information about that vulnerability. Using secrecy as a security measure is fundamentally fragile. It assumes that the bad guys don't do their own security research. It assumes that no one else will find the same vulnerability. It assumes that information won't leak out even if the research results are suppressed. These assumptions are all incorrect.

The problem isn't the researchers; it's the products themselves. Companies will only design security as good as what their customers know to ask for. Full disclosure helps customers evaluate the security of the products they buy, and educates them in how to ask for better security. The Dutch court got it exactly right when it wrote: "Damage to NXP is not the result of the publication of the article but of the production and sale of a chip that appears to have shortcomings."

In a world of forced secrecy, vendors make inflated claims about their products, vulnerabilities don't get fixed, and customers are no wiser. Security research is stifled, and security technology doesn't improve. The only beneficiaries are the bad guys.

If you'll forgive the analogy, the ethics of full disclosure parallel the ethics of not paying kidnapping ransoms. We all know why we don't pay kidnappers: It encourages more kidnappings. Yet in every kidnapping case, there's someone -- a spouse, a parent, an employer -- with a good reason why, in this one case, we should make an exception.

The reason we want researchers to publish vulnerabilities is because that's how security improves. But in every case there's someone -- the Massachusetts Bay Transit Authority, the locksmiths, an election machine manufacturer -- who argues that, in this one case, we should make an exception.

We shouldn't. The benefits of responsibly publishing attacks greatly outweigh the potential harm. Disclosure encourages companies to build security properly rather than relying on shoddy design and secrecy, and discourages them from promising security based on their ability to threaten researchers. It's how we learn about security, and how we improve future security.

---

Bruce Schneier is Chief Security Technology Officer of BT Global Services and author of Beyond Fear: Thinking Sensibly About Security in an Uncertain World. You can read more of his writings on his website.

Here’s an interesting post on High Earth Orbit about the usage and promotion of open source software for defense contracts. As a developer of open source tools, Andrew Turner of course brings up some “pros” for the government to push open source, but it’s the “cons” that are really interesting. A big “con” – the US government having something called “sovereign immunity” which apparently means something like it can’t be sued unless it consents to be sued. Hunh – the Republic of ScienceLogic-Land? Closing the loop here, a federal appeals court just boosted open-source software licenses by saying that any infringements can now get more severe remedies under copyright law (instead of contract law); here’s the case, Jacobsen v Katzer. But apparently not if it’s the US government?? Who knows more?

Does Linus Torvalds hate everyone except for developers? You have to check out this article on an email exchange he had with Network World this week, talking about how fed up he is with the “security circus”. Over the course of the exchange and some other comments from last month, he manages to blast security folk, OpenBSD (on security) in particular, vendors and PR people (of course). In the midst of the barrage of colorful language, it’s difficult to really get his point – which if you can dig it out, ends up being surprisingly sensible.

Sharon Taylor, Chief Architect of ITIL V3, recently wrote that with the release of the latest version of ITIL, BSM is now an ‘ITIL best practice.’ You say potato… “The distinction between IT and the business has blurred, and the language of IT has been replaced with the language of the business.”

he Court of Federal Claims that first heard the case threw it out, and the new Appellate ruling upholds that decision. The reasoning behind the decisions focuses on the US government's sovereign immunity, which the court describes thusly: "The United States, as [a] sovereign, 'is immune from suit save as it consents to be sued . . . and the terms of its consent to be sued in any court define that court's jurisdiction to entertain the suit.'"

In the case of copyright law, the US has given up much of its immunity, but the government retains a few noteworthy exceptions. The one most relevant to this case says that when a government employee is in a position to induce the use of the copyrighted material, "[the provision] does not provide a Government employee a right of action 'where he was in a position to order, influence, or induce use of the copyrighted work by the Government.'" Given that Davenport used his position as part of the relevant Air Force office to get his peers to use his software, the case fails this test.

But the court also addressed the DMCA claims made by Blueport, and its decision here is quite striking. "The DMCA itself contains no express waiver of sovereign immunity," the judge wrote, "Indeed, the substantive prohibitions of the DMCA refer to individual persons, not the Government." Thus, because sovereign immunity is not explicitly eliminated, and the phrasing of the statute does not mention organizations, the DMCA cannot be applied to the US government, even in cases where the more general immunity to copyright claims does not apply.

It appears that Congress took a "do as we say, not as we need to do" approach to strengthening digital copyrights.

Belkin gives us plenty of time to get ready for streaming high def: FlyWire uses an adapted form of Wi-Fi in the 5 GHz band to stream HD without having the HD set in close proximity. They're not shipping until October, which could give you some time to get used to the price tag. A $1,000 model is designed to cover a home, and has various infrared and wireless options to control current A/V gear, some of which might be hidden in cabinets away from view. A cheaper $700 option covers just one room, Belkin says, and excludes the IR help. The transmitter has 3 HDMI jacks, including DVI support with audio inputs, along with two component and one composite video and audio input panels. The receiver has a single HDMI output. All HD resolutions are supported. These devices are aimed at people who buy large HDTVs and want to wall mount them.

If you read my blog, or know me, you probably know I do NOT like software (and it usually doesn’t like me). So, I’d be the first to jump on the ‘anti-software-peer-based-NAC’ train, but I think we have to be informed before we jump to conclusions and hop on any trains.

Mirage’s recent blog post on Symantec’s ‘Silly SNAC’ was certainly a result of a mis- (or un-) informed person. Tim did a much better job on his mention of SNAC in the NWW blog, but all the dots still aren’t connected. It proves the point that sometimes we (as bloggers) tend to write based on a feeling and sometimes don’t dig for the fact.

So, in an effort to make sure I understood this new peer-based NAC, I reached out to Patrick Wheeler, Symantec’s Senior Product Manager for Network and Endpoint Security. Based on my conversations with him, and a pretty detailed investigation into the options and configurations of their NAC products, I have some slightly more informed opinion to share with you now.

Symantec has a variety of NAC enforcement components and options. I’m going to keep all the software-type-stuff out of this conversation for the time being. They have (among other things) the NAC Enforcer, an appliance similar to the other NAC controllers we see from traditional hardware vendors. Just like it’s counterparts, Symantec’s NAC Enforcer can be configured for DHCP, inline or 802.1X based enforcement.

The piece that’s different is the integration of the NAC Enforcer with Symantec’s Endpoint Protection Manager server that hosts the policies for the NAC. It’s similar to the management-enforcement configuration we see from other vendors, only the management piece is housed on a server instead of another appliance.

And, just as other vendors offer some type of endpoint integrity agent, the Symantec agent comes in the form of the Symantec NAC Client, which can be used by itself, or integrated with the Symantec Endpoint Protection Client for an even more robust feature-set. (The Endpoint Protection Client offers some additional host-based firewall features that the NAC can leverage).

So, what about the Peer-Based NAC? Ah, well that’s just the first iteration of a ‘vision’ to address mobile corporate users. If employees have laptops in an ad-hoc situation outside of the enterprise infrastructure (and therefore, outside of enterprise enforcement), then the peer-based NAC can port the enforcement rules set at the ‘mothership’ and enforce them individually. The peer-based NAC can protect mobile assets in their most vulnerable situation, outside the security of the corporate network. But, the rules are still set centrally and the peer-based NAC was designed to be just one step towards an added layer of protection, not as a replacement for network-based NAC.

For now, I’ll stay off the hate train, since the peer-based NAC is more of a supplement to a more robust traditional NAC solution. If they move to a fully-host-enforced product, I’ll buy my tickets…

Image shown is copyright of Symantec Corporation.

# # #