One of my HIPS rules specifically blocks any access to a *.torrent file, for obvious reasons. Going through my HIPS logs today, I see the following event:

It’s fascinating to think that WoW uses bittorrent to manage itself, just not on one of my work machines, thank you very much.

CSOonline.com has a good article about some emergent technology (the A1000) designed to create rules dynamically to detect malware.

There isn’t a lot of information on the technology yet but it seems that it does have strong roots in IDS tech, which is exactly what I’ve been hoping will happen to AV.

It sounds like it might be gateway-based. I’d prefer it to be closer to the network fabric, possibly based off netflow or something similar. But hey, its a start and from the looks of it, AV is indeed getting their peanut butter stuck in IDS’s chocolate.

Over the course of several years I’ve written a lot about network security and effective strategies. Mostly I’ve kept this blog, a sort of journal, as my own documentation. But as the popularity of blogs grew, my intentions morphed more towards a contribution to the community.

The aim of this document is to wed all of my observations on network security to produce a single document that hopefully defines the nature of network security so that one can understand the very nature of the struggle and thus gain empowerment. Delusions of grandeur? Sure, why not?

Default Disadvantage

The defender of the network is at a near-constant disadvantage for various reasons. The conflict between attacker and defender is asymmetrical. The two parties don’t meet on the Internet; two opposing networks squared off for battle. Instead, the attacker uses guerilla tactics, such as compromising one node, then using it to compromise the next, or using psy-ops (social engineering) to leverage users to aid the attack.

The attacker ultimately chooses where, when, and how to engage. The defender, by definition, can do nothing more than wait, anticipate, and then try to fend off the attack. This requires the defender to have at least some basic knowledge about a huge range of attacks, whereas the attacker can be specialized.

There is inherit chaos in the network that the defender must contend with and conversely, the attacker can leverage. Often there are many factors of a given network that are unknown to the individuals charged with its defense. For example, there is likely a wide range of system types and roles within the network, all of which must be known and understood before they can be properly defended. There is also likely to be various generations of a given operating system, each with unique vulnerabilities and defense requirements.

Disproportionate Costs

The cost of defense is immensely disproportionate to the cost of offense. This is due to many factors. For example, the knowledge requirements that must be met by the defense come at a cost in training, cost to travel to the training, and cost in lost man hours while attending the training. Another example is the broadness of defensive systems adds to their cost. For example, a HIPS infrastructure incurs the cost of licensing for numerous hosts. Many solutions incur yearly maintenance fees and/or support fees. Penetration tests or audits are also rather expensive. This is not to say that the cost of attacking is trivial, but I argue that it’s nowhere near the monetary investment required for a solid defense.

The attacker has an ethical advantage over the defender because the attacker, by definition, need not abide by ethics or morals. The defenders are rarely able to ethically initiate an attack or even ‘attack back’. The exceptions to this would of course be legal action (which is still hit-or-miss, the legal apparatus needs to catch up) or in the event the attacker is physically located on the network owned and operated by the defender, in which case all bets are off. Call it the Castle Law of the network.

Arms Race

Zero day attacks are an interesting topic for debate and I find they have an integral, necessary function in the evolution of defensive tactics. For the sake of argument, I’ve defined a zero day attack as one for which there is currently no patch available to correct. Because the vulnerability can’t be programatically corrected (because no patch is available), it forces other countermeasures, which often push the envelop and thus create new defensive techniques not previously needed or known by the defense. This defines the arms race between attacker and defender and the successful defender is one which is agile and flexible in their techniques and able to adapt to any situation.

Based on the fluidity of the network and the constant evolution of the attack and its defense — the arms race — we can conclude that the best defense is not a product or combination of products. It’s a process; a collective knowledge, a learned behavior, and an efficient, learned method of learning. The best defense becomes the ability to adapt.

Network security is a game of chess stuck in a perpetual state of middlegame. Just as in chess, its important to know how to best lose an asset and to always learn from the loss.

Now that we know the nature of the conflict, how do we proceed?

That’s the topic for the next installment.

I’ve spent the last two or three years focusing the lion’s share of my security energy on implementing proactive measures to reduce our dependence on Microsoft patches. To wit, here is what my Black Tuesday routine looks like:

Tuesday - I usually wait for the ISC to publish their overview, which is easily digested. I then check out Microsoft’s bulletins and see how they impact our environment. I also check out information received from our IPS vendor as well as other news groups I’m a member of.

Wednesday - I release a bulletin to our security group that summarizes information from all the sources I’ve read. We have a policy that all workstations be patched within one week of that bulletin and all servers be patched within thirty days. Each office is responsible for their networks and I prod them along with random checks for compliance.

I also go through and verify what level of protection our IPS and HIPS provides so that I can inform the team. Usually we get about 70% or better coverage from the IPS units, meaning they can detect and/or protect against 70% of the exploits directly through virtual patching and/or malicious behavior detection. Firewall best practices usually protect against another 10 - 20% of attacks. That includes the firewalls deployed through the HIPS to road warriors as well as network firewall appliancess in all offices.

I also investigate email filters on possible email-borne attacks. We filter email attachments based on MS KB262631 but attackers are increasingly using HTML email to bypass email gateway filters, so its getting trickier to protect your email clients.

That leaves about 10 - 20% exposure, which is usually in the form vulnerabilities we have to accept due to business impact. For example, images are a big part of our business model, therefore we can’t filter them from emails proactively and we can’t have over-zealous IPS units sniping them from web pages, web-based email, FTP transfers, etc. So in all cases where we can’t protect, we at least detect. That way in the event of a compromise, we know what hit us, where it hit us, and what damage it caused. Case in point; we had a laptop pwned while it was on a client’s network. We had the HIPS downgraded to HIDS mode for troubleshooting a problem so we were able to determine the extent of compromise easily and quickly.

We also harden hosts directly exposed to the Internet, such as public FTP servers, web servers, DNS servers etc. This serves several purposes; first it makes them harder to hack. Second it serves as damage control to minimize our exposure when one does get hacked. Third it makes forensics easier due to hyper-logging.

The main point you should take home from this is that defense-in-depth is the best course of action in reducing one’s dependency on Microsoft patches for network security. If your IT department looks like the Keystone Cops every four weeks trying to ensure your hosts are patched then you’re doing something wrong. Black Tuesday should be the start of a relaxed but controlled and methodical monthly routine of assessing your exposure to attack.

I had another laptop get partially compromised by the Big Yellow worm, which attacks Symantec Antivirus. I learned my lesson after the first compromise by locking down the HIPS rules to the point of specifying the IP’s of our SAV servers being the only IP’s allowed to talk through the HIPS to the SAV.

Unfortunately, one of our laptops was on a hotel network in Australia, which happens to use the same subnet we do and as the planets aligned, the right IP was compromised and popped our laptop. Granted, we should have all our SAV clients updated by now but unfortunately we simply don’t and that’s just reality.

Luckily, I didn’t stop with just firewall rules on the HIPS. I also wrote rules that stated that FTP and TFTP clients can’t write to the Symantec program directory. That stopped the payload delivery dead in its tracks, several times. Evidently that hotel network is infested with Big Yellow.

The point of the story is to maintain defense-in-depth at the micro level. Yes, defense in depth means firewalls, IPS, etc on the network. But it also means analyzing attack patterns and countering them at every point possible using any means possible. It means building defenses at every phase of the worm’s life cycle, whenever possible.

The typical phases of a worm are:

*I had a run-in with an IRCBot a short while ago, delivered by a similar Big Yellow worm, that uses custom commands when joining the IRC server. Instead of issuing the standard “/join” and “/nick” commands, it simply uses “join” and “nick”, which sailed right past my IPS. The reason I caught it was because by default I block ports 6661-7000 outbound at the firewalls. I got curious what it was and opened the firewall temporarily while running a packet capture to see what it was.

Some tricks you can use if your HIPS is configurable enough:

1. Only allow approved FTP clients to use the FTP protocol
2. Treat all FTP clients as untrusted
3. Protect security directories from write access
4. Protect the major registry launch points
5. Once you identify a payload app by name, block access to that filename. Yes this is reactive but is fairly effective in preventing an outbreak of the same variant.