Perimeter
5/6/2010
05:55 PM
Connect Directly
RSS
E-Mail
50%
50%

The Idiot Threat

It's been interesting to see how the failed bombing in New York's Times Square has been sifted for "lessons."

It's been interesting to see how the failed bombing in New York's Times Square has been sifted for "lessons."The big "Times Square Lesson" in the news cycle right now is that there's something wrong with the "No-Fly" list. Of course, there's more than one way to interpret that...and so far, the media takeaway seems to be that the government and the airlines should spend even more money on it. This is preposterous.

As far as broad lessons for risk evaluation and mitigation that we might carry back to the IT security world with us, I think there are a couple lurking in the story.

First, big investments in sophisticated technologies won't catch amateur-hour attacks. It's possible that the propane tanks could have exploded and that would have been pretty serious. The current spin in the media seems to be that this was so boneheaded an attempt that it wouldn't have been likely to hurt anyone. Consensus view is that the guy was an idiot. I'm willing to believe that and I'm glad if he was too much of a rube to pull off the attack. But even goofballs can kill you. And I don't think any of the talking heads saying his bomb was never a real threat will volunteer to sit next to a smoldering car filled with propane tanks. If the propane tanks do blow, it's going to be pretty hot. So, there was danger there, but at the same time it was not the sophisticated sort of attack that we tend to focus on.

Most attacks are in fact low-tech, both in the world of home-rigged explosives and in the confines of the enterprise network. The comparatively cheap investments that give you options for finding or mitigating low-grade attacks are the investments to concentrate on. There are lots of options for sophisticated detection systems that will try to make the extended, real-time correlations that enable you to detect hackers who are trying to fly under the radar. Since this isn't most hackers, you've really got to keep these kinds of investments in perspective.

In Times Square, the low-cost investments had been made and they delivered brilliantly. There were plenty of cops on the street in the normal line of duty. There were lots of cameras to provide after-the-fact forensics (I'm not particularly espousing cameras, mind you -- my point is simply that they cost less than radiation sniffers). And the really straightforward measure of building in cement-block obstacles to prevent someone from driving a car bomb into at least some of the more sensitive buildings was in place (though, as I think about walking though the square, it occurs to me that there's probably opportunity to improve the protection of storefronts and subway entrances--if we're going to react directly to the attack with security investments, this is surely the best bang for the buck).

Another lesson: fast, old-school detective work creates fast results in catching culprits, thereby creating at least some measure of deterrence. The police closed in on the alleged attacker quickly and snatched him up before he could flee the country. This business about the no-fly list is a red herring. The point is they new how to do the basics, like track the VIN number on the Pathfinder. Basic "create the timeline using filestamps and log files" sort of work remains a skillset that every IT security team should have.

There are still plenty of sophisticated attacks and attackers, probably a lot more-so in the computer world than in the physical security environment. You can't ignore them, but you probably can't stop them during the attack, pretty much no matter what any vendor tells you about automated response. But what you can do is assemble better monitoring tools and better analysis tools and watch for anomalies that would signal that something was up. This is where we should spend the money in anti-terrorism, I'd wager, but I know less about that. I'm quite sure it's where investments are warranted in network environments, because normal parameters are easier to spell out and easier to check and recheck for exceptions.

Robert Richardson directs content and programs at the Computer Security Institute -- gocsi.com.

Comment  | 
Print  | 
More Insights
Register for Dark Reading Newsletters
White Papers
Flash Poll
Current Issue
Cartoon
Video
Slideshows
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2012-6651
Published: 2014-07-31
Multiple directory traversal vulnerabilities in the Vitamin plugin before 1.1.0 for WordPress allow remote attackers to access arbitrary files via a .. (dot dot) in the path parameter to (1) add_headers.php or (2) minify.php.

CVE-2014-2970
Published: 2014-07-31
** REJECT ** DO NOT USE THIS CANDIDATE NUMBER. ConsultIDs: CVE-2014-5139. Reason: This candidate is a duplicate of CVE-2014-5139, and has also been used to refer to an unrelated topic that is currently outside the scope of CVE. This unrelated topic is a LibreSSL code change adding functionality ...

CVE-2014-3488
Published: 2014-07-31
The SslHandler in Netty before 3.9.2 allows remote attackers to cause a denial of service (infinite loop and CPU consumption) via a crafted SSLv2Hello message.

CVE-2014-3554
Published: 2014-07-31
Buffer overflow in the ndp_msg_opt_dnssl_domain function in libndp allows remote routers to cause a denial of service (crash) and possibly execute arbitrary code via a crafted DNS Search List (DNSSL) in an IPv6 router advertisement.

CVE-2014-5171
Published: 2014-07-31
SAP HANA Extend Application Services (XS) does not encrypt transmissions for applications that enable form based authentication using SSL, which allows remote attackers to obtain credentials and other sensitive information by sniffing the network.

Best of the Web
Dark Reading Radio