Showing posts with label responsible disclosure. Show all posts
Showing posts with label responsible disclosure. Show all posts

Saturday, August 03, 2019

the disclosure debate is the wrong argument

prompted by an exchange on twitter this morning i began spending mental resources on an old favourite that everyone loves (hates) to go over again and again - the disclosure debate.

the disclosure debate is a debate over what the right answer is to the question  "i found a problem, now what do i do with it?". it's a natural place to come from for many in the security community and the question surely needs an answer. but the disclosure debate tries to raise the answer into a principle and each side of the debate believes that their side is more principled, more virtuous than the other. you have to pick a side and in so doing you also pick a tribe and signal your allegiance.

the disclosure debate has been raging in the security community for a long time and the two major sides right now are full disclosure which is generally favoured by security researchers, and responsible disclosure which is generally favoured by vendors. when you pick a side you're choosing to align with one of these groups.

but is that really it? is it just a choice between researchers and vendors? are they the only ones with real skin in the game? hell no.

so then let's catalog the groups of people involved:
  1. vendors of vulnerable products/systems/services. these are the people who, when faced with discovery of a security vulnerability in their product, are expected to act quickly and create a fix for their product to eliminate the risk posed by by that vulnerability
  2. security researchers. these are the people who find the vulnerabilities. often a great deal of work goes into finding vulnerabilities and consequently researchers often want and even deserve some kind of reward, whether simply adding to their reputation which they can parlay into better paying job or a more direct financial reward like a bug bounty.
  3. attackers. these are the people who would actually exploit the vulnerability to victimize people, whether for money, ideology, or a laundry list of other reasons
  4. users of vulnerable products/systems/services, be they businesses, institutions, individuals, etc. these are the people who are actually affected by vulnerabilities and arguably should be the most important consideration
now attackers and users don't figure all that much in the disclosure debate. sure the ostensible reason we have the debate is because we say we want to help the users, and the reason for doing the vulnerability research and disclosing the results at all is supposed to be to thwart attackers, but when arguing over which side of the disclosure debate is best attackers and users are treated as constants, as monolithic homogeneous groups that always present the same issues in every case and that's just not an accurate reflection of reality. 

not all attackers would be able to find the vulnerabilities on their own. those that can are just as much a minority as the security researchers themselves are. not all attackers are interested in any given vulnerability. those that target foreign states may be more interested in PLC vulnerabilities than VLC vulnerabilities. some may not have the connections or resources to exploit a particular vulnerability. some may specialize in attacks against a completely different kind of technology. some are simply not motivated enough to add a new exploit to their arsenal.

meanwhile, not all users pay attention to the channels where disclosures are communicated, in large part because most users can't understand or meaningfully act on the information in a disclosure. filtering out attack traffic, using IOCs, deploying mitigations, etc. are all the domain of a very select group. additionally not all users are aware of all patches when they become available, or are willing or able to apply them.

these are only a fraction of the variations among the two groups that can affect if/how they'll use a vulnerability and if/how they might be affected by the vulnerability. the reason we keep having the disclosure debate is because that debate has never adequately addressed these variables, because they have the potential to make the answer change depending on the vulnerability, which would mean there is no single right answer or right side in the debate. the debate focuses on principles to the exclusion of nuance, only paying lip service to the people who would use the vulnerabilities and the people those vulnerabilities would be used against. 

those who find a problem in some kind of technology want an easy answer to the question of what they should do with it - that's why the disclosure debate exists, to try and arrive at an easy answer so people can just follow the one right principle for handling the situation and be done with it. it follows a trend that has become all too common in the technology sector of trying to abstract people out of the equation because people are messy and complicated. but people are part of the equation whether we like it or not so the argument shouldn't be about which principle is right, but rather whether our actions should be governed by principle or by considerations for people.

in the watchmen, the character rorschach was governed by principles to the exclusion of virtually everything else ("never compromise. not even in the face of armageddon"). defending truth and justice so stridently made him arguably the most heroic, in the comic book sense of the word. but the more realistic portrayal of individuals and circumstances and society as a whole in the watchmen highlighted how ill-fitting such unwavering adherence to principles can be in the real world.

we need to stop talking about the disclosure debate, not because it should be settled already, but because it can never be settled, because it's parameters don't fit the real world. it's the wrong argument. if we really want to help protect one group of people from another group of people then we need to spend a lot more time thinking about those people each and every time the subject comes up. there are no shortcuts when it comes to doing the right thing.

Thursday, July 22, 2010

disclosure options

kevin townsend drew my attention to this post on the google online security blog about responsible disclosure (should you read the post, pay special attention to the list of authors - if you've been paying attention to the disclosure debate lately you'll recognize one of the names). it discusses the fact that responsible disclosure sometimes fails to provide adequate motivation for software vendors to fix their code and how that actually puts users in danger because it means the vulnerabilities in question won't get fixed.

unfortunately the security folks over at google fall into pretty much the same trap that a lot of the security community falls into - the trap of binary thinking (i'm sure there's a loftier term but this will do). when we talk about disclosure many people only consider two main alternatives: full disclosure and responsible disclosure. in reality, however, there are additional alternatives between those two and even some beyond those two.

unless you're quite new to the security field or have been living under a rock these past couple of years you probably have heard of partial disclosure - dan kaminski famously used it for the DNS vulnerability discovered back in 2008. whatever your opinion of partial disclosure might be, it clearly highlights the fact that there are more than 2 options when it comes to disclosure. in fact, partial disclosure opens up an entire range of options depending on how much information you disclose. the number of options for partial disclosure is limited only by one's own imagination and creativity.

what that means in practice is that it's actually possible to apply a strategy of 'graduated response' if you find a vendor is being too stubborn. it's not necessary to jump directly from responsible disclosure to full disclosure, you can gradually apply increasing amounts of pressure while at the same time not arming malicious attackers with new digital weapons.

unfortunately the disclosure debate has become religious. this is a big problem because it prevents people from considering alternatives. it polarizes opposing sides (which is odd when you consider that the true opposite of full disclosure is not responsible disclosure but actually non-disclosure) and creates an environment where people exhibit what emerson might well describe as 'a foolish consistency'. people need to get over themselves and their dogmas. disclosure (like many other things) is just a tool, and it's important to use the right tool for the job. sometimes the right tool may well be full disclosure, other times it may well be responsible disclosure, and still other times it might be something in between. the google folks are right to put the focus on protecting the users, but focus alone won't really help if they can't figure out how to use the right tool for the job (and one of them, at least, appears unable to).

Wednesday, July 21, 2010

why the disclosure debate does in fact matter

some time ago dennis fisher published a post on threatpost explaining why the disclosure debate doesn't matter.
from the article:
In recent discussions I've had with both attackers and the folks on enterprise security staffs who are charged with stopping them, the common theme that emerged was this: Even if every vulnerability was "responsibly" disclosed from here on out, attackers would still be owning enterprises and consumers at will. A determined attacker (whatever that term means to you) doesn't need an 0-day and a two-week window of exposure before a patch is ready to get into a target network. All he needs is one weak spot. A six-year-old flaw in Internet Explorer or a careless employee using an open Wi-Fi hotspot is just as good as a brand-spanking-new hole in an Oracle database.
his argument seems to be that since a determined adversary is going to get in regardless of whether people practice full disclosure or responsible disclosure, the method of disclosure makes no difference. if they don't use the vulnerability in question then they'll just use something else.

what this basically boils down to in practice (whether dennis likes it or not) is 'since they're going to get in anyways we might as well make it easy for them'. does that seem right to you? it doesn't to me. how about this - if it doesn't matter whether we keep a particular vulnerability out of the attacker's toolbox (since they'll just find some other way to get in), why does it matter if we fix the vulnerability at all? whether the vulnerability is kept hidden or made non-existent, it should have the same effect, namely that it doesn't get exploited, so if one of those is pointless doesn't that mean the other one is too?

this strikes me as the security equivalent of nihilism, which quite frankly is not conducive to progress. as such i have an exercise for all those agree with dennis' sentiments (that the disclosure debate doesn't matter) to rouse them from their apathy:
publicly post your full personal details, including name, address, phone number, bank account number, credit card number, social security number, etc, etc.
after all, if someone really wants to steal your identity they're going to do it anyways, so you might as well  hand the bad guys the tools they need on a silver platter, assume you're going to get pwned (in accordance with the defeatist mindset that has become so popular in security these days), and start the recovery process. just bend over and think warm thoughts.

"that's not the same thing" you say? well of course not. in one instance you're handing over tools that enable attackers to victimize somebody somewhere (often many somebodies all over the place) and in the other you're handing over tools that enable attackers to victimize YOU. clearly things are a lot different when it's your own neck on the line than when it's some nameless faceless mass of people who are out of sight and out of mind.

will responsible disclosure prevent attackers from victimizing people or organizations? in the most general sense, no. but there is definitely value in making things harder for them, and it should be blatantly obvious that there is no value in making things easier for them. the concept of not making the attacker's job easier is why there's a disclosure debate in the first place, and the fact that so many people still don't understand that is why it's still important.

Thursday, August 02, 2007

the blue pill - once more, with feeling

i kinda hoped to never again darken my blog with those two words again... i even resisted the temptation to point to the response to the matasano challenge and say 'nyah, nyah, i told you so'...

and frankly, i'm not even interested in debunking the hogwash about it being 100% undetectable anymore - i know that perfect protection from detectors is impossible, joanna knows it's impossible, and i know that joanna knows that it's impossible...

if it were any of that stuff i've already posted about before i wouldn't be posting again because i've already said my peace about that... no, despite all the faults, all the criticisms i've made, the one good thing i was able to say was that at least she didn't release it - at least she was being responsible...

now even that is gone... maybe i should write viruses, slap a research sticker on them, release them and call it good... does that work? no? i didn't think so...

was there a compelling reason to make the stealthkit available to the public? was someone feeling the heat over some ridiculous claims and rather than eat crow decided to let those detractors test it for themselves with the cop-out caveat that it's not finished?... seems a plausible explanation - at any rate, congratulations joanna on becoming part of the problem, i'm sure that black hat you've made yourself will go over well at that conference by the same name...

Friday, April 28, 2006

vulnerability escrow

while engaged in a discussion about a vulnerability disclosure over at spire security an idea came to me...

one of the reasons people disclose vulnerabilities without making any effort to first work with the affected vendor(s) to correct the problem is that they want to be known as the person who discovered the vulnerability - they want to be able to prove they were the first to discovered it and the way to do that is to blurt it out in a public forum so that it becomes trivial to verify who was first to post the vulnerability...

ignoring the fact that putting the advancement of your reputation ahead the security of others is an entirely self-serving thing to do, i think there's a relatively easy solution to this... put the details of the vulnerability into escrow with a trusted 3rd party such that the 3rd party timestamps the details you give them and keeps them secret until the researcher who submitted the vulnerability unlocks it for public scrutiny... that way the researcher can prove when s/he discovered the vulnerability and get the credit s/he's due and still work with the vendor to correct the problem...

ideally we'd want to fix the vulnerability prior to public disclosure so that the window of exposure is more or less closed when information that might have otherwise lead to exploitation in the wild is released... of course things don't always go as we'd hope and sometimes vendors dick researchers around instead of taking them seriously so full public disclosure before the vulnerability gets corrected may still be necessary some of the time, but hopefully only as a last resort...

of course this idea of having a vulnerability escrow system only addresses the problem of letting people motivated by personal advancement follow responsible disclosure and still get the credit they were seeking... it doesn't address other motivations like spite, where they try to punish the vendor by releasing vulnerability information - that hurts the vendor by hurting their customers and that kind of collateral damage clearly doesn't work towards the greater good...

now that i've written this, it occurs to me that vulnerability escrow can't be a new idea... and google says i'm right, it's not... so then this is my voice supporting the idea...