The assumption "bug collisions are so common in all software that everyone should assume that for any bug disclosed, it's probably been found by attackers & exploited already" contrasts how scientific research works. Security research is no exception.
Bug & research "collisions" can happen due to lots of low-hanging fruit. It can also occur when researchers pay attention to reach other's work. I've discussed researcher "swarming" for years, & recently on stage at BlackHat this summer.
Bug collision or correlation rates for software that has a lot of bugs (bug dense, say, because of not being well-tested) will generally model higher bug collision rates than in software with low bug density. See slides #23-27 from my RSA talk in 2015.
rsaconference.com/writable/prese…
In the case of #Meltdown & #Spectre , it seems to be more like the specialists in this research area were paying attention to, & building upon, publicly discussed research areas of interest. Hence, these bug "collisions" were following what we see & accept in other sciences.
Researchers will swarm areas that others show results in. Let's not assume that further variants of these or other published bugs mean that we should assume all bugs are already under attack.
Time, scientific research, & bug hunting are still experienced as linear by most humans.
An old example of this "20 year old bugs, now suddenly uncovered by many at once" due to researchers swarming is format string vulnerabilities. crypto.stanford.edu/cs155/papers/f… Discussed openly for years, but the CVEs only really started rolling in after a critical mass of publications.
I'm seeing a forgetfulness that "bug collisions" can happen for different reasons, a lack of critical thinking when it comes to interpreting why it happened for #Meltdown #Spectre , AND an unfounded leap to say that these or any examples of bug collisions should set broad policy.
Both Harvard & RAND paper authors very much were trying to push the notion that by "measuring" bug collision rates using "real data", conclusions could be drawn across all software.
My minority report on this triad is this:
No it cannot because reasons for bug collisions vary.
1 characteristic about software itself that can statistically increase bug collisions is bug density. The characteristics about researchers that can increase bug collision rates include reading each other's work & talking through ideas. There are more factors of course.
My point isn't to list all possible factors that go into bug collision rates. My point is that it's dangerous to draw broad conclusions around this or other example of bug collisions to set policy like the government Vulnerability Equities Process (VEP) or disclosure deadlines.
Why did we (MIT Sloan, Harvard, & I) look at bug collision rates several years ago, one may ask. It was to answer the challenge posed by Dan Geer in his 2013 BlackHat keynote, where he argued that the US gov should try to outbid the black market for bugs if it would make a dent.
Sorry, it was 2014: wired.com/2014/08/cia-0d…
We looked at bug density, supply of finders, & other factors to build a system dynamics model. Best lever for govs to improve defense wasn't buying bugs & shoving it at vendors to fix. We've already seen vendors struggle to handle their incoming bugs, even with bug bounties.
We recommended govs sponsor creation of better tools to determine exploitability & give them to vendors. Rather than force feed vendors bugs (or "fish"), instead teach them to determine exploitability ("fish or not fish"). Vendors' capabilities need more fixing than their bugs.
When the DARPA Cyber Grand Challenge was just a concept, I pointed out that AI bug hunting would devour all vendor triage resources if unleashed upon the world. Pile of rotting "fish" bugs. So the organizers added the AI fixing requirements. But performance & app compat, I warned
Back to #Meltdown & #Spectre
1. Performance hits with patches in some circumstances? Yep
2. App compat issues w third party AV playing out? You betcha
On bug collision rates:
1. Causes for collision rates vary
2. #Meltdown & #Spectre collisions don't change the fix issues above
1. Bug collisions exist
2. Bug collision *rates* vary based on variables
3. Broad policy shouldn't be set by any 1 example or data set
3. #Meltdown & #Spectre collisions likely due to researcher swarming
4. "Assume breach" is sound, but "assume bug collision for all bugs" is not

• • •

Missing some Tweet in this thread? You can try to force a refresh
 

Keep Current with Katie🌻Moussouris (she/her) is not coming to Vegas

Katie🌻Moussouris (she/her) is not coming to Vegas Profile picture

Stay in touch and get notified when new unrolls are available from this author!

Read all threads

This Thread may be Removed Anytime!

PDF

Twitter may remove this content at anytime! Save it as PDF for later use!

Try unrolling a thread yourself!

how to unroll video
  1. Follow @ThreadReaderApp to mention us!

  2. From a Twitter thread mention us with a keyword "unroll"
@threadreaderapp unroll

Practice here first or read more on our help page!

More from @k8em0

Sep 21, 2018
I just got this from Twitter, so I asked:
"I received notice that Twitter employees had access to some of my DMs. Which DMs were they exactly? How many Twitter employees had access to them? Were the recipients of my DMs also told that my private messages to them were compromised?
Putting this at the top of the replies so that people can stop feeling like they need to correct my original tweet. :) Clarification is in my timeline, but not high enough in the replies to see that it is *even worse* than I initially thought:
Read 5 tweets
Sep 21, 2018
I got 2 consecutive restraining orders against an MIT professor, the 1st of which he forced an evidentiary hearing w his own character witnesses & full cross examination of me on the stand, he wasn't disciplined at all.
I was 21. He was 34.
Why do that ever again
#WhyIDidntReport
I left my job at MIT, where I'd worked 4 years, moved across the country & became a Linux dev. I chose not to get a 3rd restraining order in San Francisco, so that he wouldn't know where I lived. To this day, now that I'm a public figure, I worry that he will snap & come hurt me.
It's been over 20 years. He was known to hit on undergrads. Known to MIT by complaints by students. Even when court found him to be a credible threat to me, his position at MIT remained unchanged. I spoke up loudly for myself & to stop him from hurting anyone else. MIT failed us.
Read 6 tweets
Aug 29, 2018
Marketing can often get things wrong. So can media. I expect technical folk to use technical terms correctly.
"Integration in SDLC" which I've discussed extensively regarding vuln disclosure/bug bounties has little to do with nifty JIRA bug bounty integration (which is cool).
It sure makes for glossy marketing to say that it does - but that labels a feature erroneously. It is actually a process. The process can still be missing. Why does it matter so much?
It's like saying a bug bounty can make you more secure - which is a lie without back-end process
It's accurate to say that bug bouny platform-JIRA integration streamlines the vulnerability response process, because that is all that it does. This is quite useful without the marketing deception & complete misuse of the technical process term "SDLC". That's for preventing bugs.
Read 11 tweets
Aug 13, 2018
Last view of the crime scene that was my invaded hotel room and violated space, courtesy of @CaesarsPalace who still have not told me anything, offered me anything (except to move my room - like that really would prevent their security team screaming at me again). My last #DEFCON
The reporting out of this event so far has noted "privacy" concerns. The fact of the matter is, a male's chief concern is privacy. Women's includes that, but our high order bit is that this policy designed to keep people safe from gun attacks *increases* our chance of assault.
Threat models change, & we as security professionals know that. October 1 changed the threat model for Vegas hotels. That in no way changed the threat models for women traveling alone. Only @CaesarsPalace security did that. They are sacrificing women's safety for gun inspections.
Read 19 tweets
Jul 26, 2018
TFW you're happy folks are celebrating others & you, yet there's still an annoying focus on your least significant bit, nothing to do with your work. I'm so fucking sick of the "women in" lists. The equality I crave is that professional lists have plenty of unscripted diversity.
Also annoying as hell: people coming to me, expecting me to be an expert in diversity & diversity hiring. What the fuck does hacking (my tech background) or policy work have to do with recruiting skills? To me, it's as offensive as expecting all women to know how to cook & clean.
For the record: I don't know anything about how to recruit more women. Please tax the men w fixing their own shitty hiring pipeline they created. We pay enough overhead just being recognized for our work. We aren't typically paid or promoted equally. I'm already fighting that.
Read 4 tweets
Mar 19, 2018
What used to frustrate me as a young professional pen tester was needing to overprove myself each time, whereas junior males were assumed to be more technical than me. Now I get it on Twitter w people who know my work, yet still think dismissing my expertise counts as "debate".
Feed the pipeline, they say. Get more♀️interested in STEM. We don't have enough qualified candidates, or we'd totally hire them/have them speak. As a♀️who's done pro hacking, IT admin, development, & shifted major company bounty policy w data, I can tell you it's not worth it
Read 5 tweets

Did Thread Reader help you today?

Support us! We are indie developers!


This site is made by just two indie developers on a laptop doing marketing, support and development! Read more about the story.

Become a Premium Member ($3/month or $30/year) and get exclusive features!

Become Premium

Don't want to be a Premium member but still want to support us?

Make a small donation by buying us coffee ($5) or help with server cost ($10)

Donate via Paypal

Or Donate anonymously using crypto!

Ethereum

0xfe58350B80634f60Fa6Dc149a72b4DFbc17D341E copy

Bitcoin

3ATGMxNzCUFzxpMCHL5sWSt4DVtS8UqXpi copy

Thank you for your support!

Follow Us!

:(