05:55 PM
Connect Directly

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 --

Comment  | 
Print  | 
More Insights
Register for Dark Reading Newsletters
Partner Perspectives
What's This?
In a digital world inundated with advanced security threats, Intel Security seeks to transform how we live and work to keep our information secure. Through hardware and software development, Intel Security delivers robust solutions that integrate security into every layer of every digital device. In combining the security expertise of McAfee with the innovation, performance, and trust of Intel, this vision becomes a reality.

As we rely on technology to enhance our everyday and business life, we must too consider the security of the intellectual property and confidential data that is housed on these devices. As we increase the number of devices we use, we increase the number of gateways and opportunity for security threats. Intel Security takes the “security connected” approach to ensure that every device is secure, and that all security solutions are seamlessly integrated.
Featured Writers
White Papers
Current Issue
Dark Reading's October Tech Digest
Fast data analysis can stymie attacks and strengthen enterprise security. Does your team have the data smarts?
Flash Poll
Title Partner’s Role in Perimeter Security
Title Partner’s Role in Perimeter Security
Considering how prevalent third-party attacks are, we need to ask hard questions about how partners and suppliers are safeguarding systems and data.
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
Published: 2014-10-20
Cross-site scripting (XSS) vulnerability in the ja_purity template for Joomla! 1.5.26 and earlier allows remote attackers to inject arbitrary web script or HTML via the Mod* cookie parameter to html/modules.php.

Published: 2014-10-20
Multiple SQL injection vulnerabilities in Banana Dance B.2.6 and earlier allow remote attackers to execute arbitrary SQL commands via the (1) return, (2) display, (3) table, or (4) search parameter to functions/suggest.php; (5) the id parameter to functions/widgets.php, (6) the category parameter to...

Published: 2014-10-20
Multiple SQL injection vulnerabilities in Bulb Security Smartphone Pentest Framework (SPF) before 0.1.3 allow remote attackers to execute arbitrary SQL commands via the (1) agentPhNo, (2) controlPhNo, (3) agentURLPath, (4) agentControlKey, or (5) platformDD1 parameter to frameworkgui/attach2Agents.p...

Published: 2014-10-20
Multiple cross-site request forgery (CSRF) vulnerabilities in Bulb Security Smartphone Pentest Framework (SPF) 0.1.2 through 0.1.4 allow remote attackers to hijack the authentication of administrators for requests that conduct (1) shell metacharacter or (2) SQL injection attacks or (3) send an SMS m...

Published: 2014-10-20
Bulb Security Smartphone Pentest Framework (SPF) before 0.1.3 does not properly restrict access to frameworkgui/config, which allows remote attackers to obtain the plaintext database password via a direct request.

Best of the Web
Dark Reading Radio
Archived Dark Reading Radio
Follow Dark Reading editors into the field as they talk with noted experts from the security world.