If someone in security isn’t yet convinced it is as much an art as it is a science, I’d expect they’ve not done security long enough (or they’ve been lucky to work in a high security environment or focus solely in academic computer science).

For as much as security wants credibility and to make a difference, it dashes our efforts when someone runs into a room waving around an automated vulnerability report and demanding that every (every!) item be fixed or business will be denied. …including such idiotic things like “hiding” http 403 errors because they give away directory presence or a single weak cipher is enabled or something else so low as to be valueless to any attacker. Or at least less value than it costs to mitigate the low issue! It hurts worse when this report-waving person is another “security” dude. To those people, way to sour everyone’s grapes.

I also read a recent post on Bejtlich’s blog as well as the links and comments for the post. Some great thoughts in there.

I’m convinced of a few things…

First, there are very few (if any) correct answers that work on a global or universal or even “just really large” scale. What works for one organization may not work for another, for any countless reasons. We have lots of great ideas, collectively, in security, most of which probably work. The biggest problem is inertia and getting someone to actually devote some time and resources to the cause in the first place.

Second, the only way to combat the crap being passed around is to be an expert in security (in as many veins as possible) and being able to maintain credibility to educate management. This means being pragmatic and yet effective. It means being able to talk to someone and explain why issue #87 is not the Big Deal they’re running around trying to make it be, just because it appeared on an automated scan. This means not making ultimatums over useless low risk issues and actually tackling issues and initiatives that will actually have some value (even if you don’t understand fully how to measure and prove that).

I really think good security geeks know in their gut when something is useful to the cause or not, even if it is hard to actually justify it every time.

Praetorian Prefect has a video posted demonstrating the Aurora attack against IE6. It also shows how easy Metasploit is to use once you get some experience with it. While nothing new to sec geeks, I think it is mind-boggling to norms who have no idea how slickly you can own a system.

This incident centering around Google has raised tons of discussion. I really can’t add too much more to what has already been said in various corners of the net, but I can at least add my own voice to the cacophony…

First, Google is a large, public company. They, like most any company, will not come out with a declaration like this without a firm economic reason to do so. I think the best response I’ve seen was Moxie’s over on the DailyDave list.

Second, lots of people rightly diss on these companies for probably using IE6 widely. This is an easy argument (just like saying ‘why are you insecure?’ after someone is hacked…), but not one I tend to take too deeply because, quite honestly, it takes time and effort (i.e. MONEY!) to change things in an IT environment. Good point, but don’t bandy this too hard.

Third, stop being surprised that Google has automated systems to dump your data to authorities. Don’t be naive, both about Google and about economic entities.

Fourth, Google uncovered several attacks to something like 30 other large companies. Wait…does that mean all of them didn’t detect the attacks? Pass the whiskey…

Fifth, defense in depth and detection helps. Having operators/analysts keeping their fingers on the pulse of networks and systems helps (or more appropriately properly augments automated tools). Signatures (and automation) do help and have their place, but nothing will be able to interpret suspicious or strange behavior like a human.

Sixth, speaking of defense in depth, we’ve all seen the vectors of initial attack. We’ve all heard rumors about just how deeply that attackers got inside their targets. But who is connecting the dots? Exactly how did owning the clients pivot over to the servers or systems? I’m not saying I don’t believe those rumors, but I am saying it sounds like we still have a non-secure interior. I know security is reactionary in nature and economically-bound, but what the hell?

Sixth, attackers were originally curious and self-serving in a non-financial way. Then they realized they can make money stealing directly from accounts in a very liquid fashion, and a subset who directly utilized CPU cycles collectively. I think now we’re seeing more realization that there is value in information held by corporations; on the level of corporate espionage. This is far less liquid to most people, but to nation-states or other corps… I’m not saying this is cyberwarfare! But less-liquid espionage is the next natural step…should we be surprised that Google reportedly had a team ready to attack the attackers? Shadowrun, anyone?

I hadn’t mentioned the Google/China drama because pretty much everyone else has, but new details have emerged on this topic in regards to an IE 0day exploit in the wild. Both Brian (“How-Many-Bloggers-Can-Say-They-Have-Sources?”) Krebs and The H Security have good posts on it, and both link to Microsoft’s new advisory on the problem.

The H Security has an interesting comment:

The advisory states that, while the hole affects versions 6, 7 and 8, the current attacks only appear to have targeted version 6 – which raises a question as to how current the affected companies’ software inventory is.

Indeed. They also mention what is becoming the attack method du jour:

The attackers apparently used the flaw to inject a trojan downloader into compromised computers. The downloader then proceeded to retrieve further modules, including a back door that gave the attackers remote access to the computer, from a server via an SSL-encrypted connection. Links to the crafted web pages were likely sent in emails to selected employees of the targeted firms.

Outbound SSL-encrypted connection. Take that firewall egress filters! This gets back to how prevention eventually fails, and you’re down to relying on your layers of defense to detect the issue and respond appropriately (unless you aggressively whitelist, I guess). And while we often pass off 0days as exotic and not a threat, tell that to the high-profile targets that just got hit. And we all know that once high-profile targets don’t look as juicy anymore, attackers will go after their partners, vendors, providers, contractors, and smaller shops that have far less ability to prevent and detect these attacks.

BackTrack 4 Final is out. Thanks to the Twitter community for getting the word out (to me at least).

In case anyone missed it, Brian Krebs (just formerly from the Washington Post’s Security Fix blog) has his own blog opened up that is well worth the bookmark. Krebs’ blog on the Post site has long been one of the few truly useful “mainstream” outlets for security news that I keep in my RSS feeds. In reading his latest posts, I’m excited for his new venue, especially that he is his own editor now, and we don’t only get the cream of the crop as far as news stories, but also the difficult-to-explain-in-a-mainstream-site issues.

In short, we need people like Krebs who can sit quite comfortably between three parties: the technical geeks, the business people who may either act as his sources or his subjects, and the people who make up the journalism entity. By that last part, I mean he knows the ropes about what he can and cannot write, has demonstrated journalistic integrity, and has contacts and knowledge of the laws and protections he may enjoy. We don’t have all that many people like him in the security “blogosphere.”

Rich Mogull has been around in security for 20 years, and he posts about his guiding security principles. I think I agree with them all ( to varying degrees), but there are a couple I’d like to build on.

1. “Don’t expect human behavior to change. Ever.” – Fine, you *can* change human behavior to an extent, but we in security can’t *expect* it to change. Otherwise it just becomes an excuse for insecurity and we start taking steps away from reality. We have to work with human behavior or find ways to influence it that are not like flatly telling someone, “No.” Positive and negative conditioning should be general vocabulary terms for security geeks, let alone the other influencers (economics, psychology, politics, etc). We social engineer on a weekly basis, or at least should.

2. “…keep it simple and pragmatic.” – Yeah, we all get sick of the KISS principle after even one semester of technical coursework. But it absolutely must be a guiding principle in what we do, not just in security, but IT in general. Keep it simple. Keep it simple. Keep it simple. The more complex something is, the larger the total cost of ownership, the worse the security will be, and the more annoying it will be to anyone involved. Keep it simple. This becomes easier when you agree to Rich’s other principles. That way you stop yourself from trying to block every last % of vulnerabilities that have a miniscule chance of occuring or account for every possible action a human employee may take. Keep it simple. There is a reason this permeates so many personal philosophies in every facet of business and life.

As one of my favorite quotes, “Simplify, simplify.” -Thoreau.

I was a little excited to see the headline, “Good Guys Bring Down the Mega-D Botnet” over at PCWorld, as the article promised that researchers have gone on the offensive to bring down a bonet. To go on the offensive against a botnet, to me, means targeting the actual perpetrators or actually taking over the botnet and disassembling it.

Ok, well, not quite. Thank you editors making strange headlines and taglines.

Turns out the researchers did perform some excellent hard work in blackholing the C&C servers for this particular botnet, at least enough to reduce it to a fraction of its power, by contacting registrars, server hosts, and even taking over some of the unused domains the bots would check.

But they’ve done nothing except put their fingers into holes in a leaky dam (or maybe sticking a hose in every hole in the dam and siphoning it back on up over the dam and back behind it). Or put a fairly thick blanket over a raging bull’s face. Or cleaning up the spills in your store while some stranger somewhere in the store is running amok dropping bottles everywhere. The botnet is still there. The attackers are still there. The bots are still there. The vulnerabilities are still there.

I would rather have seen the researchers actually usurp control over the botnet by using one of those domains they snatched up. I know that’s a grey area of defense/attack research, but at least I would personally find more value in it. Or maybe not even take it over, but masquerade as a C&C server and see if you can trace back the activities. Then hopefully once you have control of the botnet, issue a kill order on the malware if that feature was coded in (as long as it does not do something destructive on the host like format the system) or issue an update that permanently has it check the loopback address for commands.

There is value in this effort, but let’s not get ahead of ourselves. They didn’t “take down a botnet,” at least in the way I envision it, and they haven’t done a ton that will absolutely have a long-term effect; at least not without ongoing investment in time and money. Perhaps they will do this long enough to choke off this botnet, which is great, but what do you have left but to just do it again next year?

I knew when I finally got around to reading this post, it would be cool. Michael Rash posted last month about a fun way to use single packet authorization to create what he calls “ghost services.” Basically, you send an SPA packet to the target server on a port that is already in use, such as port 80. The firewall then sends just you over to the service you really want, such as SSH, but everyone else still sees the regular port 80.

This can be useful when on a network that only allows certain ports outbound (such as 80/443/53). It can also be useful to just thwart any future investigators who try to recreate your connection but only see the service everyone else sees. I’d find this less suspicious than an actual port 22 connection or strange port connection that no longer is listening, to be honest. Yes, there are plenty of other ways to skin this cat, but I really dig creative thinking like this.