I’ve often read people who say that we (security, risk management) need to “think like the attacker”.  And when you read this sort of article, that usually alludes to trying to anticipate the tactics an attacker might use to mess with your C, I, or A.  Smart stuff, that, and very useful when architecting security solutions.  But as I was training some folks Monday, I was thinking in the back of my head about Threat Capability (TCap) in FAIR.  As you might know, we like to estimate the capability of a threat to apply some level of “force” against our assets.  This ability to apply force is a byproduct of the attacker’s skills and resources.  And thinking of how an attacker applies skills and resources, I came across another way we might “think” like an attacker.

Traditionally, I’ve thought of “skills” as being a byproduct of the toolset an attacker has.  This mindset probably stems from my time with Penetration Testing teams, where in the process of scoping the  PenTest I would ask our clients to select the level of effort that they wanted us to throw at them.  If a client chose “high” we’d throw every ‘spoit we had at them.  If they chose “low” we’d limit ourselves to a more commonly available toolset.

But while the resources part of TCap is time & materials (money) - the skills are really more than just the toolset.  Skills would include the ability of the attacker to be creative and innovative.    As an example of that innovation from those PenTesting days - when we got a “high” effort request, we would always try to couple that with some “social engineering”-type of attack, or some unique means of delivering an existing exploit.  Our creativity was not necessarily a byproduct of a unique exploit or tool we had, but the process by which we might deliver pre-existing or commonly available exploits.  I remember when we first got ahold of a handful of 32mb thumb drives (hey, 32mb was huge back then) and “dropped” a few in the lobby of a client’s retail space.  The keystroke loggers and phone-home script weren’t new, but using the thumb drive as delivery vehicle certainly was.

So I’ve started to really think about this concept of innovation, and how if “thinking like an attacker” means to be innovative, we ought to do the same.  I’ve been thinking of two main categories of innovation this morning.

INNOVATION

The first I’ll call Technology Innovation.  And by Technology Innovation, I mean some new, unique, “ahead of the curve” technology that an attacker can use against us.  The obvious example of which is a zero-day.  It’s that “high” tool set our PenTesters would use against the clients.  For security departments, this might be the latest security product designed to enhance our ability to P, D, and/or R.

Alternately, we can be creative in the way we deliver (manage) existing technology.  I think of this as Process Innovation.  It’s doing more with what we already have, just like the PenTest team would be creative in the delivery of an existing exploit.

Unfortunately for us - attackers have traditionally had quite a leg up on us in terms of Process Innovation.  It is much easier fro them to be creative, as they are free of political constraints and bureaucracy.  In contrast, when the security industry tries Process Innovation, the results are checklists and “standards”.  It’s committees and consensus.  An extreme example of which might be something like SABSA - a great work if you want to understand some very smart people’s comprehensive understanding of organizational security  - but the “adoption”of which will do very little to help you be innovative in P/D/R.

It’s worth noting that ultimately, this is one reason I don’t like regulatory compliance efforts - they simply serve to prove how mundane your security department is,  wasting valuable resources that could be spent on creating ways to be more effective.

PROCESS INNOVATION AS A SUBSTITUTE FOR TECHNOLOGY INNOVATION

As we come to the close of 2009, some surveys suggest that security spending isn’t horribly impacted yet by the economy (the latest from E&Y points to only 5% of their respondents getting budget cuts).  But if this is a protracted downturn, and because InfoSec is an operational expense, I would expect cash to become more and more difficult to keep.  And regardless if technology spends do slow, I believe it makes sense to think about Process Innovation because I see Process Innovation as a means to increase effectiveness without significant capital expenditures (effectiveness increases because our ability to manage risk has a direct correlation to the amount of risk we have).

The bad news is, of course, that great innovation is hard.  It is R & D.  Failure is usually a pre-requisite to success.

The good news is, our current state is so bad that many of us don’t need to come up with a whizbang new way of reducing software defects in the SDLC as innovation.  Simply inserting a risk analyst into the PMO’s processes might count as a big enough victory. Be cautioned, though,  that if we’re substituting the risk reductions provided by technology acquisition - Process Innovation might actually be even more “expensive” as it requires us to expend political capital.   But there are (forgive the term) innovative ways to spend this political capital.

For example, by taking a second now and figuring out the 3 things that the rest of the organization can do to make your life easier, when that “I need to reduce your budget” talk comes, you can be prepared to negotiate.  Get a political capital “loan” or “investment” from the C-Suite reducing your budget.  Something to the effect of: “I expected this, and am happy to give up my budget.  But if our tolerance for risk hasn’t changed, what I’d like to do is get you to personally back my office on three projects I’ve identified that can reduce our risk without requiring significant capital expenditure.”

But that credit card weirdness is nothing compared to the one I’m about to describe.

Before we do that, let’s take a moment to discuss the design principle of failing securely. The general idea is that if a security mechanism fails, it should fail closed. If your firewall crashes, it should block all traffic, not allow all the packets through. If the power source to your card key system is interrupted, it shouldn’t unlock all the doors. If the connection between your application server and your LDAP directory is severed, subsequent authentication requests should be rejected, not approved. This is not rocket science.

So back to credit cards. I had a conversation last night with an old friend who related a bizarre situation they had encountered during the QA process for one of their web applications. One of their tests involved repeatedly attempting a credit card transaction using a canceled/expired American Express card. Here’s what they saw in their logs, paraphrased by me:

Attempt 1: Denied
Attempt 2: Denied
Attempt 3: Denied
 .
 .
 .
Attempt 49: Denied
Attempt 50: Denied
Attempt 51: Approved

What the…? Approved? That can’t be right. So they ran the test again. Every time, after multiple consecutive rejected attempts, the transaction would inexplicably go through. The threshold wasn’t always 50, but the general pattern was consistent — keep trying and eventually it’ll work. Clearly, this had to be a bug in the code, but a deep-dive into the guts of the application turned up nothing. The application security group got American Express on the phone to see if they had any insight on this odd behavior. The answer? They didn’t concede the failure was on their end, despite log data showing the successful authorization codes.

My gut instinct would be that the application requesting the transactions wasn’t failing securely (e.g. network connection to AmEx timed out, so just approve the transaction). But that explanation wouldn’t account for authorization codes coming back.

So what in the world is going on here? Why would the system behave this way? Is it by design? I can’t think of a single legitimate use case for failing open like this. If this is actually a design decision by the credit card companies, I have no doubt that someone in our audience knows the rest of the story.

This is just ridiculous. Of course the bad guys will use all the communications tools available to the rest of us. They have to communicate, after all. They'll also use cars, water faucets, and all-you-can-eat buffet lunches. So what?

This commentary is dead on:

Steven Aftergood, a veteran intelligence analyst at the Federation of the American Scientists, doesn't dismiss the Army presentation out of hand. But nor does he think it's tackling a terribly seriously threat. "Red-teaming exercises to anticipate adversary operations are fundamental. But they need to be informed by a sense of what's realistic and important and what's not," he tells Danger Room. "If we have time to worry about 'Twitter threats' then we're in good shape. I mean, it's important to keep some sense of proportion."

This is a quick and dirty video documentary of the things that when on around the talks and event at Phreaknic 12 (2008). Don't watch if you get sick at shaky cam movies like Blair Witch or Cloverfield. A rough timeline of the content in the video is as follows:

        Intro and leaving Louisville with Brian. Morgellon talks about hacking the Arduino micro controller platform. Sorteal talks about the LiVes Open Source video editor. AT&T Batman building by night. Mojo-JoJo soldering some stuff for the shooting range. The patron gods of hackerdom. Registration. Con swag overview. Morgellon  gets his discreet logic on. AK-47 building with HandGrip and Buttstock. Froggy talks up Notacon, which I plan to go to next year. Skydog explains the Jware chair toss event, and then we compete. Rootwars hacker wargames. I ask Int80 about using his nerdcore music in some of my videos. NotLarry explains rootwars. Some iPhone hacking with Lee Baird and John Skinner. I do a little Bluecaseing/Warnibbling with the Bluetooth on my Nokia n810. John, Lee, Brian and I go to the German restaurant. I blind DOSman with the light from my camera and check out what folks are doing with the Arduinos Droops brought for folks to play with. I check back in on R00tW4rz. I blind Droops. I talk Ettercap filters with operat0r. USB door key fun with the Arduino. More breadboard fun. Nokia n810 + Ettercap Filter + Lemon-part = win. Int80 gets down with his own bad self, and the rest of Phreaknic. I find an energy drink with protein. Folks play with the hardware keyloggers I brought, and we have some epic fail with the IBM Model M + USB adapter + Mac OS 10.5. Winn Schwartau joins in on the keylogger fun. DOSman and Zack use a directional antenna from the 9th floor to search downtown Nashville for WiFi access points. Zoom in on Al. John and Lee eat jerky. Daren and Shannon from Hak5 blind me this time. :) Then they do a quick interview. I interview TRiP about the legalities of wardriving, sniffing and leaving your access point open so you have plausible deniability of copyright infringement (most likely it won't hold water in court if you are a computer geek). I give Hak5 Daren beef jerky. Ziplock had more con badges than God. I meet up with Iridium. I talk with Nightcarnage about the audio/video setup at Phreaknic. As I predicted, the Potters won the WiFi Race. I say why this was the best Phreaknic ever. Using green lasers on crack dealers. Techno in the dark, the Aiptek action HD does not do well in low light. Nicodemius shows off his Minority Report like multi-touch table. Hula hoop contest. I check back in with Jeff Cotton and his USB keyed door. I strap on my gear to leave the con. Brian and I do a wrap up of our thoughts on Phreaknic 2008.