Recently in Risk Category

Last week was the last week of my SANS mentor class for Hacker Techniques, Exploits and Incident Handling. Hopefully my students will try out for certification and pass gloriously.

As always, we wrapped the 10-week teaching cycle up with the ever-entertaining capture-the-flag (CtF) session that really drives home a few key points. In a previous blog post (computer security badness hierarchy. January 13, 2009), I argued that when we focus on our responsibility for securing information technology (as part of a much larger socio-economic information system), information security practitioners really only have to worry about a few types of things: Bad Users, Bad Configuration, and Bad Software.

Most CtF's are completely in line with my hierarchy and by using tools such as nmap and metasploit and by leveraging exploit code that is readily available in places like the Offensive Security Exploit Database (formerly known as Milw0rm), most challenges in "hack labs" can be solved easily.

The major exploitable categories are typically credential re-use (bad users), unpatched software (bad software), running unnecessary services (bad configuration) and lack of port filtering (bad configuration), and can be found on most (if not all) enterprise networks. Of course, there are many more attack vectors (think "Web" and "end-point").

As a security practitioner, there are few tools more valuable than a well-designed and fully implemented vulnerability management program. When possible, it is nice to drop the $100K+ to purchase one of the commercial suites, but by ensuring that all your computers (servers, desktops and laptops) are configured according to a hardening template and that they receive all patches in a timely fashion is already a major gain. Put on top of that a decent (current) anti-malware package, and you have a nice start.

Do not underestimate the complexity of "just" doing this. If you haven't started this yet, get going. If you have started, but don't think you're done: welcome to the club ;)

If you are embarking on such a project, think about collecting some metrics about how well you are doing it so you can measure progress and define success. Think of numbers like: percentage of end-points that have been patched appropriately, percentage of end-points with current anti-malware software, average lag between publication of vulnerabilities and completion of roll-out, number of end-points in compliance with the hardening template, etc.

Only a few people have the ability to make people stop in their tracks and really listen to what they have to say. Not just listening to the words that they speak, but really absorbing the things that they say is probably the best of use of time possible. Dan Geer is one of these persons.

Marcus Ranum interviewed Geer on his "Rear Guard" Security Podcast and a few points that were made stood out to me. One of the points that Geer made that somewhere in the past decade, it became far cheaper to keep data than to delete it selectively. A direct consequence of keeping more and more data is that it becomes nearly impossibly to categorize data and we increasingly rely on search to find that one bit of information that we are looking for.

One of the hardest incident types for an incident handler to address are incidents in which a properly authenticated and duly authorized user decides to misuse her privileges.

Imagine a situation in which an employee has access to human resources records for legitimate reasons.

As an information security professional charged with protecting that information, the assessment if someone should be granted access (and if so, under which conditions) must be made by the information owner and not by me. In the example, if the owner of the HR database decides that a user has legitimate access, it is my job to provision that access in a controlled fashion.

Starting last week, we have been having some issues with groups of machines experiencing unexplained network connectivity outages. The pattern is typically that of one machine losing connectivity, and over the course of an hour or two, many more follow. Almost from the beginning, I had a gut feeling that something was affecting the machine's behavior that was external to them; the pattern did not point at a large-scale distribution of malware.

Late last week, I formulated the hypothesis that we might have some rogue DHCP servers popping up here and there.

Since the machines that were having the problems revert to a presumed-good image upon reboot, finding the actual problem was a little bit of a challenge. Our only real option was to wait for another outbreak, followed by a focused and temporary capture of network traffic.

A few days ago, we got a call that machines were experiencing browsing difficulties, and we were able to capture some network traffic that confirmed my hypothesis; a box that not one of our DHCP servers was sending out DHCP offers.

The offers convinced the clients that received them to switch their DNS to an external machine. We block outbound DNS to anything but our own servers, so the result was that the infected machined were no longer able to resolve any host names. Not a good thing, since they are primarily used as web browsers (non-proxied).

As we were wrapping up the incident, segmenting our network even further, putting in additional  monitoring, and doing some additional hardening in certain areas, the Internet Storm Center posts a diary message that was timely and on topic. The subject of the message was Rogue DHCP servers.

Not even a half-day later, I was on the phone with my previous employer and 'lo and behold: they were suffering outages and seeing strange DHCP traffic. It seems that whatever site is offering this Trojan.Flush.M-malware is very effective at reaching institutes for higher education world-wide. 

Symantec ranks the risk of this malware as "risk level 1: very low". I disagree with this; risk is a function of probability and impact, and looking at my own experiences, both are high. I have first-hand knowledge of at least three institutes that have been hit, and the impact of getting hit (loss of the ability to resolve hostnames) is also large.

How do we defend against this? The most important steps are to ensure proper network segmentation and providing up-to-date anti-malware software on workstations. On servers, you probably want to statically configure your DNS settings. Make sure you can monitor what's happening on your network; block outbound DNS traffic to everything except your own servers, and consider deploying hardened proxy servers for browsing.