Sometimes I really get something in a bunch over the latest and greatest article that makes IT and IT security sound so easy on paper. I especially dislike reading about things like that from a journalist who may or may not even know how to implement and support the given steps and commentary. While I can’t usually comment on their background and experience, sometimes it is pretty obvious when someone is writing about “good to haves” and “theoretical approaches” and “base-case scenarios.” In reality, most companies will never match those steps.
Today’s victim is an article on the 8 steps to a secure network found on zdnet.com.au.
1. Verify the current connections – Verifying the connections on the firewall is a good exercise, so that you know your common endpoints. Sadly, this works only in small networks that have tight control on installed software and desktops. In a large network, this will change too much to be of too much use. In networks that do not have tight controls, you can have a few instances of Skype that will constantly be running suspicious connections to various places in China, Taiwan, Iceland, Denmark, and so on. Investigating these is just an exercise in wishing for tighter desktop controls. It might be better to look for some common destination ports like 22, 21, or some others that would be suspicious.
2. Look at network traffic statistics – This is a good step, and any network admin should be pulling these stats or at least checking the latest numbers every morning. Sadly, this is usually the realm of a specialized network device or a Linux box doing some traffic analysis, two things beyond the reach of many admins. However, if the aptitude on the team is such to get good numbers, this is an excellent step.
3. Look at your antivirus logs – Centralized logs for host-based antivirus is either something a smaller network would love to have or unnecessary traffic storms on larger networks. Network-based antivirus may be better suited here, or something on a chokepoint like the email servers. Checking for updated signatures should be mandatory, but checking for captured viruses is less interesting. Not only that, but the logs won’t tell you the more important information: what wasn’t caught by the signatures.
4. Read the security logs on your domain servers – Reading Windows event logs, particular security logs, is about as bad a task as I can think of in IT and security. Hopefully anyone who has an interest in Windows security logs will be aggregating these somewhere and alerting when things like logon failures occur. If password policies are configured to properly lock out after 5 attempts and require admin intervention to unlock, this becomes moreorless a waste of time.
5. Check for new security patches – As much as I might take exception to most of these steps, I do like this one. Keep an inventory of important systems and software and do regular rounds of checks on security updates. This doesn’t need to happen every day, however. And hopefully you are controlling and know what is on your network…if not, good luck in getting everything adequately patched.
6. Meet and brief managers – Most of the time, the above 5 steps aren’t going to be terribly interesting. Step 1 might be interesting only because of the sheer number of “suspicious” connections that may or may not be around. Eventually this task will numb managers and the meets will turn informal and then non-existent. I think it would be more efficient to do this once a week.
7. Check more logs – Ok, I think this author is envisioning someone doing this job and only this job. All they do is check logs and security patches, kind of like a junior NOC operator or something. IDS/IPS logs should be checked, yes, but typically they are less useful than someone checking Snort or running some robust Linux tools for analysis.
8. Turn knowledge into action – This is a good step, but should be part of every piece mentioned above anyway. Take your information and work to either get better information, massage down the unnecessary information, implement changes like security patches, and research new tools to do all of these steps better.
conclusion – Over all, this sounds like a really cakewalk sort of job, and likely all that someone who followed these steps would be doing every day. Unfortunately, the reality is different and most admins seem to need to wear various hats or attend to other projects. These steps above are typically the first things to go when time is short. That’s not ideal, but that’s reality for most of us.