I am in your base killing all your d00ds
The insider threat is a big deal where I work. Industrial espionage, terrorism, personal gain, disgruntled employee vandalism, etc are all motives that I worry about.
What are some of the things we can do? Glad you asked…
I’m feeling lazy today so you get a bulleted list that I’ll hopefully have the motivation to expand on later. =)
- Background checks before hiring new employees.
- Use least privilege on host endpoints as well as server endpoints
- Deploy HIPS to your servers to protect them. I can’t stress this enough. Your perimeter might be hard as nails but your server (candy) center is likely very soft and attackable. If you don’t believe me, download metasploit and play with it against your servers.
- Deploy NAC to protect the network from foreign machines.
- revisit least privilege!!!
- Deploy IPS/IDS and keep an eye on it. Especially check after hours times for suspicious activity.
- Deploy ADS (anomaly detection).
- Know what you have on your network and reduce the attack surface. If you don’t need IIS running, disable the service (which is enabled by default on Windows 2000 servers).
I’ll give you a good example of knowing what’s on your network. Last weekend I completed a project of hardening all servers participating in a WWW application on our intranet. After I completed the hardening I did one last sweep with NMAP to ensure I had all listening ports under control.
I found one server responding on port 25. The way I firewalled the hosts was by using Windows firewall. However, I needed to permit FTP access to the machine in order to upload new code to the websites, so to get around this I created an application exception in Windows Firewall to permit the IIS executable to listen on any port it needed. I had to do it using an application exception because you can’t create port ranges in Windows Firewall (WTF is that all about!?). So anyway, SMTP was enabled on that particular server, and Windows SMTP is controlled by the same executable that also controls WWW and FTP (talk about risk!). The fix was to control access to SMTP through the IIS management applet. Port 25 still shows as listening, but only specified hosts can issue commands to the SMTP engine.
My point is this; audit, harden, audit again. Repeat regularly.
