Fighting The Advanced Attacker: 9 Security Controls You Should Add To Your Network Right Now

By Trevor on December 19, 2011 — 5 comments

There’s an ever increasing number of products and solutions available to combat advanced attackers, modern malware, and mis-behaving employees. These solutions do some really cool things and the technology they use is awesome.

However, there are some controls that everyone can and should be doing on their networks before they run out and procure such high-end technologies. As with nearly everything in our industry, the list below isn’t a silver bullet. Rather, it represents the foundation of a defensible network and a network that helps the responders detect and recover when things go wrong.

Yes, defending against “advanced” threats is hard. It doesn’t mean that you should throw your hands up and simply not try. Below are the bare minimum steps that modern organizations should be doing.

1. Configure firewalls with a default-deny egress security policy: It’s simple; web servers don’t need to web surf. There is no business justification for allowing your web server to initiate a connection to an IP in China. Rather, allow servers to connect to certain specific hosts/ports (e.g. web service call to a business partner). Keep in mind that some well-known sites may be used as command and control channels like Twitter or Blogspot. As such, filter and log accordingly.

2. Log  DNS queries and the client that requested it: It’s been said that DNS is the linchpin of the Internet. It’s arguably the most basic and under appreciated human-to-technology interface. It’s no different for malware. When you suspect that a device has been compromised on your network, it’s important to be able to see what the suspected device has been up to. The DNS logs of a compromised machine will quickly allow responders to identify other machines that may also be infected.

3. Enable logging on DHCP servers: A responder’s worst nightmare is learning of an anomaly on the network and learning that the IP address that it originated from is a DHCP address and has been leased out several times since. By logging the date, time, hostname, and the IP that it was assigned will allow responders to look back in time and figure out what machine generated the traffic.

4. Log all outbound firewall packets: It is possible to tunnel data out of even the most restrictive networks using a wide array of protocols. When an IP on the Internet is implicated in an incident, responders need to understand if any other hosts on the network communicated with the IP. A quick search of the firewall log will show all traffic to the IP. Here’s tip to save some disk space: full packet captures are not required. Rather, only the date, time source/destination IP and source/destination ports are required.

5. Log Success and Failures on all central authentication: According to Mandiant, attackers are increasingly using legitimate access methods (e.g. VPN, RDP, OWA, etc.) to gain unauthorized access to victim organizations. And why wouldn’t they? Anti-malware controls such as AV, IDS/IPS, and anomaly or behavioral detection systems can detect the presence of malware. Malware is the “smoking gun” that is left over for the responder to reverse engineer, fingerprint, and investigate. The bad guys may use malware in the initial stages of the attack, but that quickly changes. By logging ALL access (successes and failures) you ensure that you have an accurate audit trail of what users are connecting to.

6. Centrally log everything: When investigating a possible or confirmed incident, the analyst needs as much data in one place so that it can be correlated. Central logging is also an old school “n0 brainner” security consideration to prevent local logs from being tampered with on the compromised device.

7. Log as much data as you can at the proxy server: Mantiant’s M-Trends report found that 83% of malware used 80 and 443 to establish a command and control (C2C) channel to the attacker’s server. Your proxy is in a fantastic position to log a lot of details about outbound HTTP (and if you break SSL, HTTPS) connections. Here, make sure you log date, time, client IP, requested URL, browser agent, etc. Get it all.

8. Break SSL: Breaking client SSL connections used to be rare because it was hard. However we have found an increase in the amount of customers who are man-in-the-middling clients. Yes, attackers can use advanced techniques like custom crypto or obfuscated commands embedded in HTML comments. However that is hard(er) for the attacker to pull off. SSL is easy. It’s usually a check box. You should at least make it hard on the bad guys. Once client SSL is being inspected at the proxy, identify those devices that are NOT being proxied. This may indicate mis-configured machines, rogue devices not playing by the rules, or a process running on a machine that isn’t using the local system settings. All are suspect and warrant investigation.

9. Test your assumptions about your network: The final recommendation we have is to test your assumptions. You assume that your proxy will filter HTTP traffic, that your DLP solution will catch things at the email gateway and that the IDS will catch C2C traffic. You assume that all packets out of the firewall are logged and that correlating events will be easy. Our clients that use our Xfil exfiltration agent are able to understand the limitations of their current controls and gain a better understanding of their network blind spots. Xfil always surprises ourcustomers and sheds a light on areas of improvement.

So while product-based security solutions have their place when defending the enterprise, there are many product-agnostic steps you can take right now before going shopping.

Ever wonder what your network looks like to an attacker trying to exfiltrate data out? Are you getting a return on your investments in security products? Does your firewall/IDS/Proxy/SIEM/DLP even work? Talk to us about ThreatSim’s Xfil Data Exfiltration service. Web-based, on-going, repeatable, and on-demand.

Be Sociable, Share!

•