July 2009 Archives

Leaving Las Vegas ... and DefCon

| | Comments (1)
Bookmark and Share

One thing those of us who've spent any time in the security business know is that you either learn to deal with a flexible schedule or you change professions.  Dilbert called them "unplanned emergencies" but whatever you call them, they are a fact of our life.  So here I am, sitting in the Las Vegas airport on the first day of DefCon, headed back to California.  Right now I'm missing some great sessions at the Riviera but luckily, I was able to get registered this morning (albeit with a temporary plastic badge and no schedule of events...what's up with that Jeff?) and the CD with all the presentations so it wasn't a total loss. 

 

Before heading to the airport, I was able to sit in on the first hour and hit Rod Beckstrom's "The Economics of Networks (and Beckstrom's Law)" presentation.  Rod is the former Director of the National Cyber Security Center at DHS and was recently named the CEO of ICANN.  He's also the co-founder of an acquired software company and the author of the best selling "The Starfish and the Spider" book which describes a new theory for organizational strategies. 

 

The thrust of the Rod's presentation today was to introduce Beckstrom's Law and establish that while economics of networks do matter, rather than use the number nodes on a network to determine value, the real key is the number of transactions conducted and the value added by each.  Beckstrom's Law solves the valuation problem by looking at how valuable the network is to each individual user.  One of the key, and hard, things about Beckstrom's Law that Rod readily points out is that you must either have access to the transaction data or be able measure it.  Depending upon the size of your organization, wrapping your brain around that might be a challenge.

 

Rod posits that while the economics of the basic security model are Value = Benefits - Cost, the more fundamental risk management model calls for minimizing costs which requires additional variables that include SI (Security Investment) and L (Losses) and the new equation V = B - C' - SI - L.  It's a little too detailed for this blog but you can get the Wikipedia description here wikipedia - Beckstroms Law and see the entire presentation here The Economics of Networks  If you spend some time with Beckstrom's Law and have thoughts or comments, I'm sure Rod would be happy to hear from you.

Another Year @ Black Hat

| | Comments (0)
Bookmark and Share

So, another year at Black Hat in Las Vegas has come and gone.  While attendance may have been down a little and there wasn't any legal gunslinging' like in past years when talks were pulled or moderated as a result of legal threats from the vendor community, there were more interesting talks than one person could fit into two very full days.  The challenge, like usual, was trying to decide which to attend, especially when several interesting sessions were scheduled at the same time.  I participated on a couple of panels so that decreased my viewing availability and I missed a couple I really wanted to hear.  Not only were there a lot of great talks, the creative session naming by those selected to present was enticing.  Some of the better session titles were:  "I Just found 10 Million SSN's" (more below); "Exploratory Android Surgery"; "Mo' Money Mo' Problems: Making A LOT More Money on the Web the Black Hat Way"; "Reverse Engineering By Crayon: Game Changing Hypervisor Based Malware Analysis and Visualization"; and my favorite, "Psychotronica: Exposure, Control, and Deceit".

 

A couple of the sessions I attended and thought were particularly interesting were the "I Just found 10 Million SSN's" by Alessandro Acquisti, "Cloud Computing Models and Vulnerabilities: Raining on the Trendy New Parade" by Alex Stamos, and the always popular Bruce Schneier gave a presentation called "Re-conceptualizing Security."

 

"I Just found 10 Million SSN's" caught my eye because it made headlines a few weeks ago when Wired magazine published an article on the subject called "Social Security Numbers Deduced from Public Data" located here Predicting SSNs.  Making predictions based entirely on public data, Alessandro and his colleagues at Carnegie Mellon were able to detects patterns from Social Security Administration Death Master File (DMF) information that are highly reliable.  Essentially, by knowing date and location of birth, in less than 1000 attempts, the CMU folks were able to correlate and determine all nine digits of the SSN's for 8.5% the study group.  One of the funnier things Alessandro mentioned was that during their research, in coordinating with the Social Security Administration and telling them that they thought they may have found a way to predict SSN's, he got an email back that said something like, "if you think you can figure out a way to determine the SSNs of individuals, you are smarter than I am."  What else can you say?

 

Cloud Computing Models and Vulnerabilities: Raining on the Trendy New Parade" is the topic de jour and faddish to talk about.  Alex Stamos is one of the smarter guys I know and deceptively funny.  He's also good at understanding his audience so he takes a very complicated subject and presents it so everyone gets it.  One of the more important points of his Cloud Security presentation were the legal concerns about search and seizure.  Essentially, by moving data to the cloud, Alex' research says that you give up some of your 4th Amendments rights against search and seizure because the physical location of the data, legally speaking, is critically important.  So, where you have valid expectations of protection against unreasonable search and seizure for data in your home, putting the same data out in the cloud changes the equation and you may lose your: 1)  protection of a warrant; 2) guarantee of notice; and 3) your ability to fight the seizure beforehand.  These are things that should be consciously addressed before making the move to the cloud.

 

Finally, Bruce Schneier talked about Re-conceptualizing Security.  If you've been following Bruce's work for the past couple of years you know that he has been engaged in studying behavioral economics, the psychology of decision making, and evolutionary biology and how these relate to security.  Well known for his thoughts about Security Theater, where security measures that do little to improve actual security but give the impression that the security measures are effective, Bruce gave a very interesting talk on the perception of security, risk, and cost.

 

Overall, another successful Black Hat conference so props to Jeff Moss and his crew.  Tomorrow, I head over to the darker side where we'll see what DefCon has in store.

Does a DDOS Equal a Cyber-War?

| | Comments (1)
Bookmark and Share

It's been a pretty interesting week on the cybersecurity front with the DDOS attacks on South Korea and the United States making the most headlines.  I've been trying to keep up with all of the regular media and blogs and quite frankly, it's a bit overwhelming.  There's a lot of intrigue to this story but I'm beginning to wonder now if it's been over-blown a bit because a couple of things just don't seem to add up.

The first interesting thing that jumped out at me was that, while the attacks apparently began on July 4, there wasn't any mention in the media until July 9.  This is interesting because it appears that something getting so much attention by the affected organizations wasn't even noticed publicly for at least four days.  Doesn't that sound amazing when the media is so quick to jump on anything that sounds sexy like a "cyber attack"?  From what I've been able to determine based upon dozens and dozens of "unofficial" media reports and blogs, five U.S. websites were initially assaulted by a DDOS on July 4 and that number grew to more than 35 over the next few days that included both South Korea and U.S government and private sector company websites.  Wow!

What does that really mean?  Well, the estimates I've read put the botnet at around 60,000 bots.  While it appears that the attacks were actually targeted attacks and certainly not trivial, 60,000 is also not a large botnet.  So the second puzzle is that, if the botherder was truly a professional wanting to do harm, why would they distribute the attack from a relatively small botnet across over 35 websites?  That's lots of sizzle but no steak.  I read one blog that said this attack was "more like arming a troupe of girl-scouts with water-balloons and Nerf guns."  Seriously though, while there's no doubt that the attack caused some outages, a professional cowboy botherder would have either mustered up a bigger botherd or just attacked a small number of the most of significant targets.

Here's the real perplexing question to me though - why would someone wanting to cause any real damage use a variant of the old Mydoom worm family?  This thing has been around for five years and every anti-virus vendor in the world has a signature available for it.  That doesn't pass the smell test for someone trying to do real harm...unless the DDOS was simply a diversion for some other really bad stuff going on somewhere else (but that's for those with more official intel.)

While I'm positive there is a lot more information, probably classified or at least very sensitive, that I don't have access to, on the surface this appears to be a somewhat amateurish hack that took advantage of some organizations that may not have been as prepared as they thought they were.

There are certainly some tools you can and should deploy to mitigate and deflect a DDOS (IPS at the edge, router ACL's) but the bottom line is that if you get enough traffic, from enough distributed sources, in a short enough period of time, you are going to have problem.  Among the things (the top three in my opinion) you need to have in place BEFORE a DDOS are:

1.     Know who your carrier is and have a relationship with them so they can begin upstream filtering and be able to bump up your bandwidth (your BCP should address this) if you are under attack

2.     Have staff that are trained and know how to read logs and determine what IP's are causing the problem and need to be blocked.  If your staff is not technically prepared to understand what is going on, no amount of planning will be enough.

3.     Most important and most often neglected - have up to date contact information.  Trying to track someone down, whether it's your ISP, a vendor, or your own staff on a Saturday 4th of July holiday when your site is down and you don't have a name and telephone number can be one of the most frustrating events of your life.

Bonus #4 - If you have externally hosted web sites, know where they are, who manages them, and how to get in touch with them...on a holiday!

Categories