Education Connection – Knowing Your Network
5 Prerequisites for Proper Security Application Deployment
By: Kyle Capatosto

I read a great post today from the Carnal0wnage and Attack Research blog that shed a huge light on a lot of issues that security and support personnel see on a regular basis: a lack of preparedness in the essentials of IT security. We talk about Data Loss Prevention and Intrusion Prevention but a lot of folks needs help that is far more basic. Patch management, log management, basic security awareness – these things are seemingly missing from a lot of organization’s IT foundation. This has to stop now or at least soon. We have to get folks to really know their network and not just know it but be friends with it, take it out for a bit, get to love it. The best part is, if you find parts you just can’t love, you can change them, it’s really the best kind of relationship. Network diagrams, for instance, are useless if they’re not kept up to date and they cannot be your only source of documentation. Remember, it might not be you managing the network next week, you could be promoted or get a new job somewhere else. It’s really just the polite thing to do to leave behind great documentation, right? You cannot deploy an effective security program without a solid understanding of your network, it simply will not work. Below are five things I think will help in getting some control of your network and help us to help you.

1. Network Topology
Keep an updated network diagram on file. Use Google Docs, SharePoint, a network share, napkin, whatever you need to do, but any change that is made on your network to the physical or logical layout needs to be represented on it somehow. Have someone take a day or two out to get the most up-to-date and usable diagram they can. Network documentation goes a long way in troubleshooting an issue and acting quickly. It may seem like a waste of time and a low priority project, but it very quickly escalates into a big deal when you are in the middle of an attack and you don’t know what your DMZ and external networks look like. Management doesn’t like it (and I don’t like sitting on a conference call listening to an employee getting reamed out for not doing their job).

2. LOGS LOGS LOGS
I can’t stress this enough. Know where your logs go, know how to search them, who you need to contact to get a hold of them, and what is logging and being logged. Have a centralized point of collection (Splunk anyone?) and verify that your critical devices are logging to it. This can include firewalls, IDS, IPS, domain controllers, web servers, door scanners, and whatever else you deem necessary. Logs are invaluable when kept on a log server, but useless sitting on the local system. You don’t want to be the one who has to log into 50 different machines to track down a problem, or chase after fictitious/deleted logs from an intruder. Log smartly; don’t just put everything into debug mode and blast the log server, but be sure to have multiple log sources for essential functions and try to reduce duplication where it is not needed. A prime example of this is Cisco ASA logs. Typically an ASA will log when a connection is built, and when it is torn down. If you think about it though, the teardown message is really all you need, as ASAs include the connection duration and amount of data transmitted in the connection teardown logs; why log double when you don’t need to?

3. Server Documentation
How many Unix servers do you have on your network? Do you know where they are? Know where your different operating systems exist, what software they are running, and what their upgrade schedule is. You are only as strong as your weakest link, but if you don’t know where that link exists (in-house developed application, legacy OS, abandoned project) where do you know where to start looking when you think you are getting attacked? How can you eliminate false positives in your IPS/IDS solution if it needs to watch for Linux, Macintosh, and Windows on your Windows-only network because you are too lazy to go out and verify this? A great open source tool that is surprisingly accurate is p0f.

4. Asset History
How much web traffic do you process per day? How about per month, per server? If you don’t know these stats, how can you identify anomalies? Cacti, an open source monitoring tool, has a great plugin called “abherrant behavior” which watches for exactly that. Spikes and dips over time. If a server that normally sends a low amount of traffic all of a sudden starts blasting out gigabits worth of information on your network over the span of a day, it is your duty to investigate why. Let the recent behavior-based malware analysis movement from anti-virus providers be an example; IPS/IDS signatures only get you so far. It is time to listen to your network. Figure out its busy and idle periods, and create a baseline to work off of. In an ideal world we would not have to use historical data to weed out false positives, but unfortunately we live in an era where there seems to be an acceptable amount of errors and noise generated on the network and in the logs. If you don’t know how to identify this, then you don’t know how to respond to deviations from it.

5. Incident Response and Escalation
This builds on everything that I have talked about so far. What do you do when you suspect a compromise? Do your first-responders also know this? Take a lesson from Joe, he offers some great tips to get you started. Get a plan in place to deal with incidents such as outages and attacks and make sure that everyone knows what they need to do to follow it. Running around like a chicken with it’s head cut off solves nothing, and wastes time that could have been spent preventing an attacker from stealing company data. Don’t be caught explaining this to your superiors. Keep a timeline of actions taken from an incident’s birth all the way up until it’s resolution. Know your fellow employees’ strengths and weaknesses and use them to your advantage to get an incident resolved quickly. Now is not the time to try to learn how to make changes to your firewall, save that for when you have an ample amount of time to get it right. Unfortunately this is not always possible, but keep it in the back of your mind.

You’ve probably heard all of these things I mentioned before, so why haven’t you been doing it? Get the basics out of the way so that you can get to the cool stuff, like OSSEC, Snort, honeypots, reverse proxies, and all the other things that make you happy. This isn’t Congress, this isn’t the [insert favorite losing sports team here], this is IT; we move quickly, we move quietly, and we get things done!