Jim Guckin

In todays age, you can not be too secure when it comes to your network it’s better to be safe than sorry.  In the current economy I’ve seen many companies consolidate jobs and add new burden to already over-burdened admins.  One of the places where this will hurt companies is the network security departments.
I’ve learned many security faux pas in my career, but luckily only one of them has lead to any system being compromised to a limited degree.  With many admins now doing the duty or having the added duty of securing their network, I’ve come up with a couple basic security practices for windows systems.

1. Reduce the area of attack
   I find this doesn’t come as a thought to some administrators out there, the more code that is running on a particular machine, the more entry points a hacker can take advantage of.  I generally do not install any software on a server that doesn’t need to be there, and remove any components that are not being used by that particular server.
2. Use only reputable software
   With IT budgets slashed to the bone, many administrators want to head the freeware or open source route and that can cause problems.  I am not saying that you shouldn’t use freeware or open source, since I use many myself, but take time to investigate the software before installing it. This even goes with cheaper alternative software where some can be loaded with spyware that could steal information.  On any account use software that is well known and has a good reputation.
3. Use a normal user account
   When possible make sure you are using a normal user account rather than an administrator account.  This is because where malware occurs it generally runs with the same rights as the user currently logged in.  It can minimize damage if it’s running as a user as compared to your networks admin account.
4. Multiple Administrator accounts
   At most companies I’ve worked for there was a created admin account, meaning we didn’t use the Administrator login.  This was kept off limits so this account couldn’t be compromised, instead we used something like ITAdmin or the CompanyAdmin to do admin functions.  While this did the job for what we needed I’ve learned that it could be hard to track which admin actually made the change.  More recently I’ve come to the conclusion that for every admin on the network I’d create a second login for them, the primary account follows #4 above (it’s just a user account) and a administrator version of that account.  For example I would have 2 accounts on a system Jim.Guckin (normal account) and Jim.Guckin.Admin (a account with Administrator rights).
5. Use the Security Configuration Wizard
   The Security Configuration Wizard allows you to create XML-based security policies, which can then be applied to your servers. These policies can be used to enable services, configure settings, and set firewall rules.
6. Don’t go crazy with audit logging
   I’ve seen many an admin try to audit every single thing that goes on in the system, but that tends to be too much of a good thing.  If you over audit, when something does happen, you’ll spend time crawling through massive logs entries trying to find the information you need.
7. Use local security policies
   Another blind spot most admin have are is security policy.  Most think that by using Active Directory’s Group Policy that their systems are secure.  To be honest this is only 1/2 of the workstation/laptop security, since AD’s Group Policy only affects domain accounts.  If someone logs into the computer with a local account AD’s Group Policy does nothing, that’s where the local security policy takes effect.
8. Periodically review your firewall configuration
   This is the one that bit me, I was a new Administrator and just left the firewall alone, not thinking to check on what ports where opened or closed.  A hacker somewhere took advantage of the fact I removed a server from the network at one point and placed another one (less secured) in it’s place and blam-o the machine was eventually compromised.  I could have avoided this headache by making sure I knew what was opened to where and closed ports that where no longer needed.
9. Practice isolation
   I generally think that if possible each server should do just it’s own role and not place too many roles on one server (file+print+iis).  Though in this budget tightening times, its sometimes hard, but for security reasons it might be better to try and separate your servers.  Like I said it point #1, if every server has it’s own roles and they aren’t mixed, it limits the areas a hacked can take advantage of.  The second reason, if the system is compromised or down, you only loose one role and not multiple.
10. Apply security patches in a timely manner
    This is a “duh we already knew that” kind of reminder, but it doesn’t make it any less important.  I’ve been in environments that a company told me 1 hour of downtime was completely unacceptable, and so the servers were never patched (I never stopped fighting for that downtime to update) and eventually the servers were horribly out of date.  This left them open to many virus/malware/hackers that could have brought down the system, while I was lucky in this scenario many people aren’t.  I make sure to get downtime as quickly as I can for updates when they are released, usually after testing them out on a test network first.

Now by all means these aren’t the only things that you can do to secure your network, and these may not be the best for your particular network.  But this is meant as a place to start your on your way to secure your network, and make sure you stay on top of security alerts that are out there.