So a buddy of mine and myself have been talking a lot about this concept of the Holy Trinity of Infosec. The three main technologies that you should put the most time and effort into making sure they are working as expected, and yet, seems to be the most ignored areas of Infosec because they don't have blinky lights and aren't all that shiny anymore.
We can all agree that AV needs to change - the concept of signature based anti-virus isn't working anymore since every other day a new variant can be built, thus bypassing current detection methods. Heuristics are great, especially if they include some sort of behavioral analysis of the binary - if it's connecting outbound, listening on a port, and changing important files, probably a bad thing. However, the failure in this area is that, you can't clean something found with huristics / behavioral, because you don't know what your cleaning. Of course, given the size of your IS shop, at the very minimum a sample should be taken, an Image of the box if possible (That's the GREM in me talking), and a complete re-image should be done - I'm a firm believer in the re-image only option when malware is detected on a box. Having said all that, AV is still one of the Holy Trinity of Infosec, because that's the first stop in detecting bad things - when implemented correctly.
When talking about Vulnerability assessment, I include not only VA, but Web Application Scanning, Database Scanning, and Configuration Management/Compliance. Given today's tools, there is no reason not to be doing these things - and it should work. This really is the first defense against any attack as it *should* show you where your weakness is. Yes, the argument is that your not going to find 0-Days, or more complex vulnerabilities, but those are always going to be there anyway - You want to protect at the very least the known bad, and low hanging fruit. Let's be realistic, a lot of the attacks that's happened in the past few months have been low hanging fruit - and that's just sad on the part of the companies - I can only hope the IS department for those companies have been screaming about these issues, or the failure of their VA programs. Oh, as a side note here, if your VA takes out a firewall (which you shouldn't be scanning though anyway) that's still a vulnerability and not the fault of the VA systems - that's called a DoS, and should still be fixed by your network team.
The one thing we all take for granted - we all expect the IDS/IPS systems to detect and/or block when someone comes a knocking. The most common problems I see when it comes to IDS: 1) Network changes happen all the time, and there is little to no communication between the IS-OPs team and the Network team to make sure coverage still exists. 2) People are still using something that was implemented 6+ years ago, was good at the time, the vendor failed to keep up with new technologies, and then your team doesn't want to out-lay the money to replace a huge investment. In both cases, it sucks. From an IDS/IPS section, I want to see the following abilities:
Detect attempts at known vulnerabilities - This should have a high confidence rate - Its great to detect edge cases, but give it a different detection name, this separates the real attacks from the possible false positives.
Detect Command & Control Traffic - Really, this shouldn't be that hard, IRC, HTTP, and other non-encrypted protocols, there is no excuse. Even encrypted tunnels, if it's going to a known DNS name, detect the DNS request.
Anomaly Detection - If after 6 months of traffic, all of a sudden something is trying to connect to all other computers on the network, this should toss up red flags - it's just that simple.
IP based reputations - We have lists of SPAMers, C&Cs, and world wide attackers, there is no reason why an IDS can't pull at least from DShield or some other reputation IP database, given enough customers, the vendor should even be able to use opt-in anonymous information from it's clients to build it's own database - I for one would consider it.
In the center of this Triad is broken up into two parts, both are things that really isn't specific to Info Sec; Log Correlation, and Asset Management.
Log Collection and Correlation:
You should have some sort of Log Collection system, even if its a simple box that runs syslog and dumps all the logs to disk - it's hugely important not only for the Info Sec shop so you have something to analyze when things go horribly wrong during an attack, but also the IT department as a way to track issues away from a box. It's a very simple thing to implement, and really, the only outlay of money would be hard drive space. Given higher volumes then a SOHO or SMB moving into an enterprise grade tool bring Correlation to the mix which really increases the proficiency of your log analysis teams, whether it be troubleshooting or investigations.
If you've listened to the Jump Bag podcast you've heard me talk about the requirement to have a good asset control system. This integrates with so much of the above and is increasing important. The biggest Challenge of any investigation or troubleshooting process is identifying what an asset does, who owns it, who supports it, and where it is. A good asset tool should be able to keep track of all of that as well as the configuration of the device from at the very least the identifying characteristics. These include, not only Asset Identifiers, Serial Numbers, Hostnames, and local IP addresses, but if it's behind a load balancer or NATing device, it should also contain any IPs and DNS names that get redirected to the boxes.
This is something I've been thinking about for a while, and I'd like comments on it - Submit them here, or find my email address and flip me one - I'd like your thoughts on this concept.