Kymberlee Price, Bugcrowd, and Jake Kouns is the CISO for Risk Based Security.
It's well known that vulnerability statistics suck (see Steve Christey's (MITRE) Black Hat 13 talk).
But, the truth is - we are getting attacked, lots of new (and old) vulnerabilities. This is getting worse every year, not better.
Secunia says there are 15000 vulnerabilities, but they counted Heartbleed as 210 different vulnerabilities (and our speakers say it was just one, while some audience members noted it was three).
There were 100+ vendors impacted by Heartbleed, impacting over 600,000+ servers.
Very large companies are using OpenSSL: Oracle, HP, Blackberry, Juniper, Intel, Cisco, Apple, Intel, etc... so, it's not just little startups using open source anymore.
There have been 52 new vulnerabilities fixed since Heartbleed - average score of CVSS of 6.78. Nine of them had a public exploit available.
We're beating up on OpenSSL - but what about Gnu library (Ghost), which had a heap vulnerability in it. It's everywhere.
Efficiency at what cost? By leveraging this third party source, companies can deliver faster, cheaper, etc. But what are companies picking up in exchange? Some products have more than 100 third party libraries in them. Are they being treated with his much scrutiny as they should be?
The speakers aren't saying: "Don't use 3rd party libraries", but rather to think about things during design and development.
All of the data they are sharing this week are from public sources, even though that data is limited.
Look at FFMPEG - they have 191 CVEs, but over 1000 vulns fixed.
These vulnerabilities spread - think about the FreeType Project font generation toolkit. It's used by Android, FreeBSD, Chrome, OpenOffice, iOS, video games (including the American Girl Doll game). Everywhere! There was a vulnerability (missing parameter check) that allowed you to jailbreak your iPhone... or someone else to take over your iPhone. This is insiduous, as you have to wait for the vendor to fix it..
libpng, Apache Tomcat... everyone is using this and including these things in toolkits.
We shipped a vulnerability to Mars! (Java is on the Mars Rover).
Interesting to note: some vendors don't even release CVEs for anything under CVSS of 5.0. Since 2007 the number of CVEs: OpenSSL (90), Flash (522), Java (539), FreeType (50), libpng (28), APache Tomcat (100).
Now, this is not telling you what is more or less secure. For example, Adobe has an excellent bug bounty program and internal pen testers. Just because a product has only reported a few, doesn't mean more aren't lurking.
We should consider time to relief. How long does the vendor know about the issue before they provide a fix? You can use this to figure out how seriously that vendor is about security.
Had to define a framework to understand time of exposure, identify vendors and products you want to work with and establish a scorecard.
Calculating Vendor Response Time is how long from when the vendor was informed before they responded to the researcher. This can't be an automated reply, but actual acknowledgement.
Time to patch - when do the customers get relief.
But another time to consider: how long were customers vulnerable? That is, how long from when the patch is available to when the patch was applied (many folks only do updates quarterly, for example).. Total time of exposure covers the period from when the vulnerability was discovered until when was it fixed at the customer site.
We got to walk through a few case examples.
In one case, a researcher reached out to a company on twitter asking how to securely disclose a vulnerability - and for 2.5 months they kept pointing the researcher at their insecure support page.
It is critical for vendors to respond promptly and investigate the issue.
And this data is hard to figure out, as the terminology for "zero day" (oh day, 0 day) seems to be malleable.The speakers believe that it's only a 0-day when the vendor does not know about it. Once he vendor knows, or the vuln is publicly disclosed, then it's no longer a zero day.
In one case, the vendor created a patch - but did not release it, instead they wanted to roll it up to their next version release. In the end, their customers were exposed for 451 days.
While most companies update their systems every 30 days, their exposure could be much longer due to a vendor not actually providing the fix to their customers.
Advice: once you incorporate a 3rd party software suite into your tools, you need to become active in that community, watch it, help out, provide funding, or you are putting your own customers at risk.
You also need a clear prioritization scheme, to know what to fix and when (as most likely your incoming rate is higher than your fix rate).. Proactively manage your risk. Understand what third party code your organization relies and implement a plan to address the exposure, and work with the vendors.
It's well known that vulnerability statistics suck (see Steve Christey's (MITRE) Black Hat 13 talk).
But, the truth is - we are getting attacked, lots of new (and old) vulnerabilities. This is getting worse every year, not better.
Secunia says there are 15000 vulnerabilities, but they counted Heartbleed as 210 different vulnerabilities (and our speakers say it was just one, while some audience members noted it was three).
There were 100+ vendors impacted by Heartbleed, impacting over 600,000+ servers.
Very large companies are using OpenSSL: Oracle, HP, Blackberry, Juniper, Intel, Cisco, Apple, Intel, etc... so, it's not just little startups using open source anymore.
There have been 52 new vulnerabilities fixed since Heartbleed - average score of CVSS of 6.78. Nine of them had a public exploit available.
We're beating up on OpenSSL - but what about Gnu library (Ghost), which had a heap vulnerability in it. It's everywhere.
Efficiency at what cost? By leveraging this third party source, companies can deliver faster, cheaper, etc. But what are companies picking up in exchange? Some products have more than 100 third party libraries in them. Are they being treated with his much scrutiny as they should be?
The speakers aren't saying: "Don't use 3rd party libraries", but rather to think about things during design and development.
All of the data they are sharing this week are from public sources, even though that data is limited.
Look at FFMPEG - they have 191 CVEs, but over 1000 vulns fixed.
These vulnerabilities spread - think about the FreeType Project font generation toolkit. It's used by Android, FreeBSD, Chrome, OpenOffice, iOS, video games (including the American Girl Doll game). Everywhere! There was a vulnerability (missing parameter check) that allowed you to jailbreak your iPhone... or someone else to take over your iPhone. This is insiduous, as you have to wait for the vendor to fix it..
libpng, Apache Tomcat... everyone is using this and including these things in toolkits.
We shipped a vulnerability to Mars! (Java is on the Mars Rover).
Interesting to note: some vendors don't even release CVEs for anything under CVSS of 5.0. Since 2007 the number of CVEs: OpenSSL (90), Flash (522), Java (539), FreeType (50), libpng (28), APache Tomcat (100).
Now, this is not telling you what is more or less secure. For example, Adobe has an excellent bug bounty program and internal pen testers. Just because a product has only reported a few, doesn't mean more aren't lurking.
We should consider time to relief. How long does the vendor know about the issue before they provide a fix? You can use this to figure out how seriously that vendor is about security.
Had to define a framework to understand time of exposure, identify vendors and products you want to work with and establish a scorecard.
Calculating Vendor Response Time is how long from when the vendor was informed before they responded to the researcher. This can't be an automated reply, but actual acknowledgement.
Time to patch - when do the customers get relief.
But another time to consider: how long were customers vulnerable? That is, how long from when the patch is available to when the patch was applied (many folks only do updates quarterly, for example).. Total time of exposure covers the period from when the vulnerability was discovered until when was it fixed at the customer site.
We got to walk through a few case examples.
In one case, a researcher reached out to a company on twitter asking how to securely disclose a vulnerability - and for 2.5 months they kept pointing the researcher at their insecure support page.
It is critical for vendors to respond promptly and investigate the issue.
And this data is hard to figure out, as the terminology for "zero day" (oh day, 0 day) seems to be malleable.The speakers believe that it's only a 0-day when the vendor does not know about it. Once he vendor knows, or the vuln is publicly disclosed, then it's no longer a zero day.
In one case, the vendor created a patch - but did not release it, instead they wanted to roll it up to their next version release. In the end, their customers were exposed for 451 days.
While most companies update their systems every 30 days, their exposure could be much longer due to a vendor not actually providing the fix to their customers.
Advice: once you incorporate a 3rd party software suite into your tools, you need to become active in that community, watch it, help out, provide funding, or you are putting your own customers at risk.
You also need a clear prioritization scheme, to know what to fix and when (as most likely your incoming rate is higher than your fix rate).. Proactively manage your risk. Understand what third party code your organization relies and implement a plan to address the exposure, and work with the vendors.
Posts
No comments:
Post a Comment