Partial Disclosure - The Good

The responsible disclosure process tends to break down in rare occasions where the vendor doesn’t want to fix the issue. When this occurs, the researcher is put into a difficult position whereby full disclosure could put users’ systems at high risk of compromise. The other case where partial disclosure becomes an alternative is when the researcher has discovered a design flaw in a protocol or underlying multiple vendor component. Examples of this case include the DNS flaws published this past summer by Dan Kaminsky and the TCP denial of service condition discovered by Robert E. Lee and Jack Louis that is currently in the disclosure process. When the flaw affects a very large number of vendors and the actual problem is located within the underlying protocols that support the communications of the Internet as a whole, one possible solution is to follow a partial disclosure model where phasing the details to the general public can be used to encourage adoption and creation of patches throughout the enormous target audience.

Partial Disclosure - The Bad

What is driving the fear surrounding partial disclosure is the potential for abuse. When a major flaw is partially disclosed, a number of potential issues may occur. First and foremost, the further along the partial disclosure path we are, the more details will be released to the public, and the higher the probability that someone (either good or bad intentioned) will figure out the exploit and disclose the details. Second, when partially disclosing, the vendor’s hand is being forced into a situation that could speed up fixes, reduce testing, and cause ripple problems elsewhere within the infrastructure. It is difficult enough to dance the fine time line when doing responsible disclosure, but if we are escalated to the point of partial disclosure, additional fuel is added to the fire.

The Ugly

The real ugly part of partial disclosure is when we add to the equation the ability to spread fear, uncertainty, and doubt into the normal user community. It is generally well accepted that FUD can be used to drive additional revenue. If it is possible to increase the perceived magnitude of the “problem” that your product or service solves, it is possible to directly impact the demand for that product or service. That is the major fear imposed by the growing trend of partial disclosure. By releasing just enough information to trigger wide scale speculation into the flaw, it is possible to create buzz and garner media attention resulting in a lot of speculation and very little hard facts around the issue. The potential for abuse by the security industry at large is enormous.

The Fix

Some have suggested a group of security researchers be convened to vet the requirement of partial disclosure and to allow for independent peer review of any security research that requires the partial disclosure process. This suggestion leaves questions regarding who would stand on this group and who would be impartial enough to ensure that the right thing was always done regardless of profit potential. It also leaves open the opportunity for member researchers to utilize the information gathered during the vetting process to position themselves to profit from the data upon release. It might be wiser to rely on a higher level authority or government entity to manage this process and use the services of security researchers as required for subject matter expertise. While a group of this type wouldn’t ensure that all partial disclosure is appropriate, it would hopefully limit the potential for abuse and the ever present chance that people try to profit from the FUD that surrounds the current partial disclosure process.

TECHNOLOGY AREAS: Air Platform, Information Systems, Space Platforms, Human Systems

The technology within this topic is restricted under the International Traffic in Arms Regulation (ITAR), which controls the export and import of defense-related material and services. Offerors must disclose any proposed use of foreign nationals, their country of origin, and what tasks each would accomplish in the statement of work in accordance with section 3.5.b.(7) of the solicitation.

OBJECTIVE: Develop visualization techniques for planning and execution of Cyberspace operations.

DESCRIPTION: Fulfilling the Air Force mission “… to fly and fight in Air, Space, and Cyberspace” requires effective C2 tools for the observation, planning and execution of cyberspace operations. Conventional battlespace visualization tools were developed for the physical world (i.e., geospatially oriented), where the battlespace, weapons and effects are concrete, often observable entities. Cyberspace and its critical electronic infrastructures are an artificial world that must be created, modified and sustained by the warfighter. This artificial world of cyberspace has concrete links back to the physical world that shape the information landscape, affect the decision-making process, and control the communication channels crucial to C2.

Standard, geospatially oriented C2 tools are not suitable for providing cyber combatants with comparable situation awareness to understand events, evaluate options, and make decisions in the electromagnetic domain. The combatants in the cyber domain needs to be able to quickly see and understand not just the physical relationships of the traditional battlespace, but also the logical relationships and information dependencies in the abstract landscape of cyberspace. Cyber C2 visualizations need to provide information for strategy, tactics and execution of effects that may, or may not, have physical correlates. Examples of these cyber events include network attack detection, attack identification, damage assessment, denial of service (DOS) warnings, and information warfare or cyber-attack operations.

For example, a commander may be planning to intentionally disrupt a portion of his network to investigate a cyber-attack. He will need to understand what ripple effects will occur across the functionally diverse and geographically distributed network. These ripple effects will have both a cyber component (e.g., locations that will lose connectivity or suffer degraded performance characteristics) and a real-world component (e.g., information about enemy forces may be unavailable or delayed, reducing blue force effectiveness) that must be visualized, explored and tasked from within his C2 tools.

Decision makers will greatly benefit from innovative visualization tools that can improve their understanding of all aspects of the Cyber domain. These aspects include 1) the current state of the information environment, the physical and virtual battlespace and enemy and friendly capabilities and vulnerabilities; 2) the scope and scale of courses of action that affect information or information networks; 3) the primary effects and ripple effects of an operation in both the physical and cyber battlespaces, and 4) the risks for collateral damage associated with cyber warfare activities.

PHASE I: Identify cyberspace characteristics relevant to C2 visualization. Identify correlation methods and visualization techniques to understand battlespace, operations, and effects. Define metrics to evaluate efficacy. Document results in a written report, including mockups of proposed visualizations.

PHASE II: Construct a working prototype to demonstrate integrated visualization of cyber data showing 1) the status of information environment, 2) its effect on the conventional battlespace, and 3) the status of information operations. Evaluate effectiveness using metrics defined in Phase I.

PHASE III / DUAL USE: Military application: Additional military applications include command and control environments, like the Air Operations Centers (AOCs). Commercial application: Monitoring and defending infrastructures (e.g., financial and energy) against cyber-attacks. Visualization cyberspace is beneficial for security of commercial communication and information networks.

REFERENCES:

1. ‘Air Force leaders to discuss new ‘Cyber Command’

2. Laura S. Tinnel, O. Sami Saydjari, and Joshua W. Haines, An Integrated Cyber Panel System, IEEE Computer Society,

3. Anita D’Amico and Stephen Salas, Visualization as an Aid for Assessing the Mission Impact of Information Security Breaches, IEEE 2003.

4. Tim Bass, “Cyberspace Situational Awareness Demands Mimic Traditional Command Requirements,” AFCEA Signal Magazine, February 2000.

KEYWORDS: visualization, cyber, human factors, planning, situation awareness, command and control, HCI

Reference. SITIS Topic Details, Visualization for Command and Control of Cyberspace Operations

See also:  http://www.dodsbir.net/solicitation/sbir083/af083.doc

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.

This essay previously appeared on Wired.com.

EDITED TO ADD (8/26): Matt Blaze has a good essay on the topic.

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.

The lawsuit claimed that the students’ planned presentation would violate the Computer Fraud and Abuse Act (CFAA) by enabling others to defraud the MBTA of transit fares. A different federal judge, meeting in a special Saturday session, ordered the trio not to disclose for ten days any information that could be used by others to get free subway rides.

“The judge today correctly found that it was unlikely that the CFAA would apply to security researchers giving an academic talk,” said EFF Staff Attorney Marcia Hofmann. “A presentation at a security conference is not some sort of computer intrusion. It’s protected speech and vital to the free flow of information about computer security vulnerabilities. Silencing researchers does not improve security — the vulnerability was there before the students discovered it and would remain in place regardless of whether the students publicly discussed it or not.”

This sets a good precedent for future cases, and perhaps next time a similar situation arises, a judge will not be so quick to issue a gag order. It’s not a happy ending yet though, as the original lawsuit is still in effect.

As Chris Wysopal pointed out last week, the MBTA’s ire is misdirected. Rather than suing the vendor who sold them the defective system, they sued and attempted to silence the students who discovered the weakness. This is 2008, not 1988 — did they honestly think a gag order would prevent the information from reaching the general public? The DEFCON presentation was already available on the Intertubes prior to the injunction being issued, and the MBTA attorneys included a copy of the confidential whitepaper with their filing, thereby making it public.

I guess you wouldn’t expect that a transit authority would have paid any attention to theCiscogate fiasco from a few years ago. That presentation never got out either, did it? All that taxpayer money the MBTA spent on ridiculous lawsuits and restraining orders could have been put toward fixing the security flaws. What a concept.

Four chains, four Wi-Fi pay policies: CIO magazine looks at Borders, McDonald's, Panera, and Starbucks, and how they're offering Wi-Fi. I'd like to suggest you read this article, but the author writes, "Right now, according to Hotspot Locations, there are more than 33,000 WLAN hotspots worldwide, and more than 10,000 in the United States alone." I don't know who "Hotspot Locations" is, and I need to disclose that I have a financial interest in what must be their competitor, JiWire, but any hotspot finder that calls them "WLAN Hotspots" and reports 11,712 in the U.S. and 33,106 worldwide just isn't working very hard. JiWire lists over 230,000 hotspots worldwide, and notes over 60,000 in the U.S., while Boingo and iPass each resell access to over 100,000 hotspots worldwide.

Up, up, and away in my beautiful, my beautiful warballoon: Defcon hackers deployed a balloon with Wi-Fi receivers on it 150 feet in the air to scan for network vulnerabilities in Las Vegas last week. They found 1/3rd of networks had no encryption--although I always wonder if they're using passive scanning where 802.1X allows a limited connection for authentication and appears "open" in some ways, or if they were actively scanning, in which case 802.1X networks would be unavailable.

Cincinnati Metro service has Wi-Fi on 20 buses: The free service supplied by AT&T in an ads-for-access deal with the authority was placed after a couple years of testing on a relatively long commuter run. The authority spends $15,000 per bus to setup a connection, which seems rather pricey. Other authorities are paying in the low thousands, from what I've seen, so I'm not sure what their particular case is.

First, let me disclose something - my frantic efforts with the Paint allow me to proudly proclaim: I am a certified, trusted "Good Guy":

Good guys, let me tell you, do not need any controls placed on them; they are "trusted." Don't you have to trust somebody? Why not trust a sysadmin, for example?

So, what about controls? Ah, glad that you asked! "Controls" are for the bad guys; they are in place to prevent the bad guys from doing "an unspeakable evil" (tm) :-) on you. On the other hand, good guys are doing "the right thing" every time - why monitor them? It goes without saying that nobody ever moves between these groups, especially, not from "good guys" to "bad guys."

As I am rambling about this, many of my security-minded readers are wondering "what is Anton up to? Isn't it kind of OBVIOUS that controls are for everybody?" Controls know no good/bad! For example, a network control, say a NIPS, will block malicious web access due to a typo in a URL (by - gasp! - a good guy) or due to determined malicious hacking.

I think a few of my readers have watched one too many "Batman" movies and have acquired the dark side of the "IT hero" mentality." How about getting an "IT employee" mentality? If your boss is an idiot (and Terry's managers definitely seem pretty far gone in that direction...), than your "heroic duty" is to let them impale themselves on a sword of their idiocy, not to commit crimes (even if cybercrimes) to prevent that idiocy. Really, go find another job if you do not like the environment; good admins are needed in many places. For example, if your boss insists on posting all VPN passwords for all users publicly out of his sheer and unfathomable stupidity, it is your duty to tell him that it is "a very bad idea" - and not to change all passwords and not let him see it. "Doing you job" despite your boss and despite the law just doesn't work...

In other words, I want a banker making policy decisions at a bank, not a sysadmin. If a banker makes a wrong decision, his will suffer. If he is an idiot, he will most likely make the wrong decision. However, it is NOT the admin's decision to make - he does not "own" the business.  BTW, the fact that it is a city, not a bank, and it is taxpayer funded, does not change it.

Am I "anti-admin" for saying that admins should not run the business?  Am I "anti-admin" for saying controls (at least logging/auditing) on administrator activities are needed?  You call it "anti-admin", I call it common sense!!  Pray tell me, what makes admins float above accountability, control and  IT governance?

Please also read what Randy Smith said about this issue; a lot of good thoughts that I agree with.

Now I would like to respond to specific comments from my readers:

"What rankles your readers is how blithely you imply this problem has a simple or effective solution. It doesn't, all the processes or tools you advocate can do is speed up the time it takes to detect the lock-out, but not actually prevent it - i.e. they are ineffective at tackling the primary problem."

That is correct; the rogue admin problem has NO simple solution. You might prevent some (few, really) things, you might log some of them and then figure what happened, but there is no simple solution (it goes without saying that "just trust them" is NOT a solution...)

"We all know companies run without sane risk management all the time and are rarely held accountable in America. What makes you think anyone is "screwed"?"

Well, this is a good point; maybe I let my idealistic side take over. But, come on, just the fact that bad IT governance is somewhat common, doesn't make it right!

"Now ask yourself who is "screwed" by one person at a small company having all access and no accountability on a network. That's how I run my home network. Big deal."

Nobody is. I addressed it here. The risk is acceptable for smaller environments, usually. I don't have an overseeing body set up to control my home passwords :-)

"You seem to forget that sometimes the management just has to trust somebody. "

Addressed above.

"Chuvakin, you're a tool. Given the recent idiocy of the releasing of the VPN names and codes, it obviously shows that any sort of detest that Childs had against his superiors at the city were justified."

The fact that his bosses are idiots (which seems fairly well established!) does not make him right!

Bad boss + admin out of control =/= right :-)

"This is not a private organization. His superiors don't own the company and are NOT entitled to the data. We are, the taxpayers. And as a California taxpayer I fully support someone with the paranoia and technical skill of Terry Childs over a group of bureaucrats who release secure information to the public."

Properly evaluating this statement requires a law degree. Thus, no comment. Bureaucrats suck, but rogue admins are not a solution to that. Really!

"The guy was doing his job and doing it incredibly well, and keeping it out of the hands of those who, given their most recent choices, would bring potential disaster to the city."

He was NOT, unless crime is part of his job :-) Also, see comments on "IT heroes" above. If your boss is an idiot AND you don't like it, quit.

"Anton Chuvakin seems to think that all admins should be kept underneath management's boot at all times. [...]  Managers can't and don't understand what we do, and thus eventually come to the conclusion that we can't be trusted with our own knowledge. [...] Perhaps it's human nature to fear what you don't know or understand -- and that's why management can develop a fear of their own employees."

You say 'fear of employees', I say "insider risk management." You say "trust employees", I say "trust but [be able to] verify (=log)"

"his blog leads the casual reader to infer that their businesses are in danger of being hijacked by disgruntled Sys Admins and that isn’t the case." (from here)

Eh, not all businesses, but some businesses - definitely (hmm, see Terry Childs story or other published insider attack cases, all the way back to Omega Engineering case and maybe all the way back to ancient history)

"I despise people like Terry Childs, but despise Chicken Little’s like Anton Chuvakin even more." (from here)

You say  I am 'chicken little', I say "if your boss ignores insider risk management, he is stupid and deserves his business to fail."  I also add "if you think admins are 'above the law', you have a good chance of 'turning rogue' yourself AND then ending in jail."

Finally, this and my other posts about the case are inspired by on the media reporting; I possess no "insider knowledge" on this case  whatsoever.

Possibly related posts:

• "On Doomsaying (Terry Childs case)"
• "So ... Am I? Maybe I Am!"