The inevitability of failure in security has been up for discussion a lot during the past couple of years. It's a mentality that a lot of security professionals have subscribed to because of various reasons: proliferation of malware, user behavior, advanced persistent threat (APT), or simply Murphy's Law.

John H. Sawyer, Contributing Writer, Dark Reading

June 9, 2010

3 Min Read

The inevitability of failure in security has been up for discussion a lot during the past couple of years. It's a mentality that a lot of security professionals have subscribed to because of various reasons: proliferation of malware, user behavior, advanced persistent threat (APT), or simply Murphy's Law.So if you're doomed to failure, then you need to have plans ready for eradication and recovery, right? Burning everything down and rebuilding might be fine for a small business or a small department of users. It might even be OK to bring some laptops for users to work temporarily while their workstations are being rebuilt. But that won't fly with mission-critical servers, an Active Directory domain that's been rooted, and an enterprise that must allow remote users to connect in.

Last week, I was listening to a presenter discussing the problem of eradicating the compromise while maintaining a "business as usual" posture. Sitting there, I wondered what it would be like to be dealing with a large compromise where you know the attackers have access, but you cannot simply disconnect from the Internet. Talk about an impossible-feeling conundrum.

One of speaker's suggestions was trying to slow the attacker so he was less likely to be able to exfiltrate data. For example, as the attacker is trying to transfer files, start "flipping bits" in the files so they end up corrupted once the attacker has them. The speaker didn't say how it was done, but the first thing to pop into my mind was to use Snort Inline and the "replace" keyword.

For example, you could write a Snort rule looking for the header of a particular file the intruder has been transferring, like a compressed file containing your data. Since files pretty much all have a standard header, and sometimes footers, a Snort rule could be written to replace the header (and footer) with something else entirely so the attacker won't be able to view the files easily.

Another possibility would be to modify the network quality of service or inject TCP Resets and small TCP window sizes into the attackers traffic to slow transfers down to a crawl.

There's a lot of "fun" to be had during a not-so-fun time, and I hope that you never have to experience anything of that sort. Something to keep in mind is that you need to be careful doing something like this as you could end up angering the attacker so they end up retaliating. It doesn't hurt to test these things out and know your capabilities if the need ever should arise.

John H. Sawyer is a senior security engineer on the IT Security Team at the University of Florida. The views and opinions expressed in this blog are his own and do not represent the views and opinions of the UF IT Security Team or the University of Florida. When John's not fighting flaming, malware-infested machines or performing autopsies on blitzed boxes, he can usually be found hanging with his family, bouncing a baby on one knee and balancing a laptop on the other. Special to Dark Reading.

About the Author(s)

John H. Sawyer

Contributing Writer, Dark Reading

Keep up with the latest cybersecurity threats, newly discovered vulnerabilities, data breach information, and emerging trends. Delivered daily or weekly right to your email inbox.

You May Also Like


More Insights