From Cradle to Autopsy - the lifecycle of exploited data.
A collaborative speech with an FBI friend... actually fleshed out an outline for this talk. It'd be about an hour and cover pretty much everything in security, but in an interesting narrative fashion. I'm excited about this one.
Third Party Due Diligence
Sounds boring but really critical process to master here. A large number of breaches are coming from third parties. Throw all the new regulations and requirements (like the recent FDIC FIL-44-2008), this really needs to be done right. And as far as I've seen, most third-party audits aren't being done right. Hint: It's not a checklist of controls. And it's not blindly asking for a SAS-70 Type 2. I've got about an hour long speech mapped out in my head on do this, how to intepret SAS-70, CyberTrust, ISO 27001 reports... and roll your own proccess.
Recovering from a breach - what to do, what not to do
Title says it all. I think this is an over-looked topic. Cognitively, a lot of folks don't think about breach beyond writing an incident response plan. Remember the title of this blog. And how you recover from a breach can mean the world of difference to your organization. Short version - do it right and your company's market position will actually increase (I can show proof), do it wrong and you're toast. Might see if I can pawn this idea off on a mentor-buddy for him to present.
Aligning InfoSec to Business
A common topic but people are still doing it wrong. I wanna get to down to brass tacks and explain how to speak risk management in terms that the suits will understand. And note the title - you align infosec to business, not the other way around. Yet that is how most IT security people (and IT people in general) view their job - make the business adapt to the technology. Doesn't work so well, does it? We can do better.
So you've decided to use ISO 27000, now what?
ISO 27000 is not just a list of controls that you can throw onto a checklist. The heart of the ISMS is risk analysis & treatment and executive involvement in that process. Risk management is a radically different approach than the compliance work that many people are calling ISMS. Time to learn how to do it right.
Defining a process for quantitative analysis of data breach information
See previous post. Not my talk, but the fine researchers at UW. This one will happen. And soon.
Assuming the breach
What this blog is all about. Doing security in the mindset (dare I say paradigm) that the barbarians are already past the gate and in the courtyard. Tons of stuff to write up here. Still need to get to it!
Thursday, June 19, 2008
Tuesday, June 17, 2008
The Breach Data Report
Today I want to talk about the breach data report. No, not the
Verizon breach report, but the other one. The one you haven't seen yet.
Over the past semester, University of Washington researchers in the
iSchool Information Assurance program spent hundreds of hours analyzing breach data. This was a semester-long final project for a pretty senior group of graduate, under-graduate, and returning professional students.
Initially, the goal was to dig for nuggets of useful information in the breach data, much like the results of the Verizon study. However, the analysis quickly uncovered that most of the breach data out there is incomplete, inaccurate, or just plain incomprehensible.
How did Verizon get such accurate results? Well, according to them, they used data incidents they were involved in. Specifically, they say the data comes "directly from the casebooks of our Investigative Response team." So we know that this data is at least biased towards Verizon customers, which is interesting. I'll mention that I am a Verizon Business Security customer but I've never been involved in a breach investigation with their team. If I did have an incident, I don't know if they'd be the ones I'd call. The data they examined is probably complete for the cases involved. It's just that cases do not represent the entire range of possibilities.
Now our project, Defining a process for quantitative analysis of data breach information, cast a much wider net. And the results were startling. The students could only verify 30% of the reported breaches with high confidence. And many data sources had to be thrown out since they were so incomplete to be not useful.
The whole report is 56 pages long and covers processes for vetting, parsing, and querying breach information sources. The report isn't available yet, but soon will be. If you're in the Pacific Northwest, we will be having a special InfraGard meeting with the researchers to go over the results in detail.
Verizon breach report, but the other one. The one you haven't seen yet.
Over the past semester, University of Washington researchers in the
iSchool Information Assurance program spent hundreds of hours analyzing breach data. This was a semester-long final project for a pretty senior group of graduate, under-graduate, and returning professional students.
Initially, the goal was to dig for nuggets of useful information in the breach data, much like the results of the Verizon study. However, the analysis quickly uncovered that most of the breach data out there is incomplete, inaccurate, or just plain incomprehensible.
How did Verizon get such accurate results? Well, according to them, they used data incidents they were involved in. Specifically, they say the data comes "directly from the casebooks of our Investigative Response team." So we know that this data is at least biased towards Verizon customers, which is interesting. I'll mention that I am a Verizon Business Security customer but I've never been involved in a breach investigation with their team. If I did have an incident, I don't know if they'd be the ones I'd call. The data they examined is probably complete for the cases involved. It's just that cases do not represent the entire range of possibilities.
Now our project, Defining a process for quantitative analysis of data breach information, cast a much wider net. And the results were startling. The students could only verify 30% of the reported breaches with high confidence. And many data sources had to be thrown out since they were so incomplete to be not useful.
The whole report is 56 pages long and covers processes for vetting, parsing, and querying breach information sources. The report isn't available yet, but soon will be. If you're in the Pacific Northwest, we will be having a special InfraGard meeting with the researchers to go over the results in detail.
Monday, June 9, 2008
Back from vacation and ready to rant!
How many cases of breached privacy do you need?! How many people have to lose their identity to make it cost efficient for you people to do something about it? A million? A billion? Give us a number so we won't annoy you again until the amount of money you begin spending on lawsuits makes it more profitable for you to protect information than to leak it!
Channeling Alan Alda from And The Band Played On
Channeling Alan Alda from And The Band Played On
Subscribe to:
Posts (Atom)