Derbycon Videos: http://www.irongeek.com/i.php?page=videos/derbycon4/mainlist
Lacie the security dog:
 Researchers to demonstrate attacks by reprogramming firmware of commodity USB devices
 Survey find that enterprises are not paying attention to 3rd party risks, despite recent headlines
 Ransomware attack failed thanks to security awareness training
 Stubhub defrauded out of $1.6M using stolen passwords of its users
 Maricopa County fires IT manager in the wake of a data breach that the IT manager apparently warned the school about
 Why PCI can’t stop RAM scraping malware
 Plans for Israel’s Iron Dome apparently stolen by Chinese hackers
It is with a heavy heart that I have to inform our tens of listeners that unseen forces in the universe have prevented a podcast recording this week. My Scarlett 2i2 tragically died of as-yet unknown causes Tuesday evening. Subsequently, Amazon and the USPS collaborated to ensure the replacement unit, with a guaranteed delivery date of today, would not be here until Friday or Saturday. Amazon appears ready to refund the cost of the free second day shipping I incurred as a result of this travesty of logistics.
Until next week my friends…
The Defensive Security Podcast marketing department has been griping for a while about the terrible logo that Jerry made almost 2 year ago during a fit of Everclear-fueled “creativity”.
“We can’t file an for an IPO without a decent logo!”
So, we approached the most prestigious ad agency we could find – Weiden + Kennedy – of Old Spice fame – to help develop an image befitting the institution that the Defensive Security Podcast has become. After it became apparent that the ad firm wasn’t going to return our calls, we decided to take another approach and put the logo out for bid on logobids.com.
There were a lot of… interesting…. designs – clearly from people who had not heard the podcast before. And also a lot of really good ones too. The selection process was arduous. Marketing wanted one design, HR wanted another, finance wouldn’t stop complaining about the cost and the sales department was too busy playing golf to participate. We asked for feedback from our twitter followers. In the ensuing chaos, Andy and I picked our favorite. And so, here is our new logo:
Security recommendations from Bob; Meetup.com rides out a DDOS attack rather than pay a ransom; How to test the security savvy of your employees; Why companies need to think about this insider threat; 6 lessons learned from advanced attacks; How IT can establish better cloud control; Council on Cyber Security releases version 5 of critical security controls.
How to change your SSN; How Snowden was able to access and steal the documents; Liberty Mutual sues Schucks grocery store over cyber breach insurance policy; Barclays and Santander banks hit with physical IT attacks; password security
Here is an interesting article on changing the social contract of vulnerability disclosures from the current, though recent, seven day cycle, to one that follows patch Tuesday, or whatever equivalent date the particular software vendor has for patches.
It’s a good idea, but I think the author missed an important nuance: the short 7 day notice is for situations where the discovering researcher has found evidence that the vulnerability is being actively exploited. In other cases where the vulnerability is not being actively exploited, the time frame is 6o days, which is compatible with the author’s idea. Note that the 7 day recommendation comes from Google and is available to read here.
I do not think that it makes sense to wait until after the next patch Tuesday in cases of active exploitation. The point is that users of the vulnerable technology need to know that there is a vulnerability being actively exploited, whether or not a patch is available, so that the user can take steps to mitigate the problem.
One of the side effects of podcasting is that I read a lot of infosec news on a daily basis and a lot of industry reports. Sometimes, I see an odd overlap. For instance, I was reading this article about a survey from McAfee on how long IT professionals believe it would take for them to detect a breach. The numbers were all over the map, but is described like this:
“… 22 percent thought they’d need a day to recognise a breach, with one in twenty offering a week as a likely timescale.
Just over a third said they would notice data breaches in a matter of minutes, which counts as real-time by today’s standards.
In terms of general security, three quarters confidently reckoned they could assess their security in real-time, with about the same number talking up their ability to spot insider threats, perimeter threats and even zero-day malware.”
The article raises the point that the polled population seems overly optimistic, however I think it needs to be explored a little deeper.
- Mandiant’s 2013 annual report claims that data breaches take an average of 243 days to find.
- Trustwave’s report finds that the average to be 210 days.
- Verizon’s DBIR finds that 66% of breaches in the scope of their report took “months” to “years” to discover.
This is not a minor miss. This is not “being overly optimistic”. This is a fundamental lack of understanding of the world we live in.
What concerns me most about this disconnect is how these beliefs are used as an input into risk management processes. If organizations are prioritizing their security efforts based on the input from internal authoritative sources, such as the 500 people McAfee polled, that breaches will be detected quickly, when in reality they take months, there will be little appetite to make improvements in detection capabilities.