0day anger? naked security? prevention jab?

Go read this post from John Strand over at pauldotcom talking about the latest Microsoft 0day:

You have to ask yourself, if someone wanted to target you, how successful could they be? What’s stopping them from getting your users to click on a link or open an attachment? What stops your users from accessing SMB on your servers? How do your servers defend against a 0day attack?

I have several issues with the particular post, but maybe I’m just killing time at the end of the day being ornery…warning: this is a bit ranty/rambling/disorganized, even for my tastes.

1. Just to start, I agree with the post and position in general. There’s really nothing new or wrong here. It’s a great starting point to a discussion/thought-exercise on security paradigms/posture. Security geeks should *always* think this way.

2. It’s just that: a starting point. I liked this post at first hoping it would go into some ideas about this issue. But there’s really nothing other than the point that prevention eventually fails, therefore detection/response are important. (I’ll get back to this in a few points…) Well, if IDS is evaded, what other detections are we talking about?

3. Also, I take issue with the possible tone of the last line: “No friends, it has nothing to do with prevention anymore. It is now a questions of containment and detection.” Is that in the context of the hypothetical? I hope so, because this month’s 0day shouldn’t be the catalyst for such a position (1996’s 0day should have been) nor should we just throw our hands up about prevention just because 0days exist.

4. The problem, in business anyway, with the “prevention eventually fails so get with the detection and containment” idea is it’s only a vague concept. It sucks to get budget dollars on something that doesn’t actually empirically exist. But, I’ll defer to all risk experts out there who do just that… Yes, it’s important, it’s just more difficult to explain that to a layperson; it’s difficult for them to grasp the concept that an attack *will* be successful at some point. Even in security ranks this is spoken but not always truly followed upon.

5. Every time a new 0day comes out, there are sets of people who start wailing about how you can’t protect against unknown attacks leveraging existing holes in software. Well…that’s not a new proposition and has always and should always have been part of a security mindset. Every single piece of software, hardware, and protocol we run right now probably has a weakness we don’t know about. Hell, we should *assume* as such…at least as much as we can do anything about.

6. Before anyone gets too uptight about a currently known 0day issue, we really have to dive into the issue and what is really at risk. In this case, yes, someone can *possibly* run remote code on a domain controller. How do you do that? Fine, you can trick a user to hit a website and get their machine owned via some other exploit, which may then act as either a call-back zombie or just itself launch this new 0day attack against whatever domain it belongs to. Let’s assume said attack can run remote code and then own the domain controller. (Wormable? Only on a small scale, i.e. within trusted domains. Unless this can reliably attack the services on regular Windows machines or blend attacks [ala stuxnet]…then we’ll have to scrub all of this!)

7. Well, what next? Someone might talk about VLANs and firewalls and segmentation, but those are largely out the window when you talk about owning a box that, in a Windows environment, needs access everywhere. You can make sure your domain controllers can’t talk to any untrusted networks at all, for starters. Why let a DC call home to an attacker? I would hope proper log management and file integrity monitoring would help (for those few that actually do that passably well!) raise the alarm quickly.

8. Once an issue is known, we do start seeing signature definitions get pushed out by various AV/AM/IDS/IPS vendors. This is a start, though I’ll admit some would be stymied by even small changes in the payloads, especially for POC exploits. Yes, you can evade defenses, but how often are they *really* done in a way that isn’t a gimme. (A “gimme” is using SSL/TLS over 443 to deliver it…I mean, come on, I don’t consider that to be an *interesting* evasion of IDS. To me, evasion is walking past the security guard while he’s looking right at you, not walking in a side door he can’t even see.)

9. To build on the previous point, it is useful as a thought exercise to think about life without AV and IDS and patches and then to justify that by saying AV is weak, IDS is evadable, and patches are often not done. But that shouldn’t mean to anyone that there is no value in any of the above 3, or no need to pursue them. We need to make sure laypeople know that us security geeks are realistic, but paranoid. Trust, but verify.

10. So now we’re back to endpoint security and various ways to protect the endpoint including reduced rights, web proxies/filters, egress monitoring, education, etc. Or maybe even just data-centric security (which cloud and virtualization/consumerization of enterprise IT will tell you is now nigh impossible). In chess, how do you protect your king? You protect him with pawns, and you protect those pawns with other pieces. Now we’re starting to think in layers…

11. In the end, while I do have some small issues with the post (would have liked twice the post with some follow-up answers/solutions/theories), I do absolutely agree with the spirit of it!