The Ultimate Network Security Checklist
Working on your network security? Check.
Want to make sure you have all your bases covered? Check.
Need some help getting started? Check.
How about a simple list you can follow, broken down by category, which includes some tips and tricks for getting the job done?
Here it is – The Ultimate Network Security Checklist: a document that provides you with the areas of information security you should focus on, along with specific settings or recommended practices that will help you to secure your environment against threats from within and without.
Using this checklist as a starting point and working with the rest of your IT team, your management, human resources, and your legal counsel, you will be able to create the ultimate network security checklist for your specific environment. That’s an important distinction; business requirements, regulatory and contractual obligations, local laws, and other factors will all have an influence on your company’s specific network security checklist, so don’t think all your work is done. You’ll need to tweak this to suit your own environment, but rest assured the heavy lifting is done!
We’ll break this list down into broad categories for your ease of reference. Some of the breakdowns may seem arbitrary, but you have to draw lines and break paragraphs at some point, and this is where we drew ours.
The best laid plans of mice and men oft go awry, and nowhere can this happen more quickly than where you try to implement network security without a plan, in the form of policies. Policies need to be created, socialized, approved by management, and made official to hold any weight in the environment, and should be used as the ultimate reference when making security decisions. As an example, we all know that sharing passwords is bad, but until we can point to the company policy that says it is bad, we cannot hold our users to account should they share a password with another. Here’s a short list of the policies every company with more than two employees should have to help secure their network:
1. Acceptable Use Policy
2. Internet Access Policy
3. Email and Communications Policy
4. Network Security Policy
5. Remote Access Policy
6. BYOD Policy
7. Encryption Policy
A great resource for policy starter files and templates is the SANS Institute at http://www.sans.org.
2. Provisioning Servers
When asked why he robbed banks, American criminal Willie Sutton answered “because that’s where the money is”. If you could ask a hacker why s/he breaks into servers would probably reply with a similar answer “because that’s where the data is”. In today’s society, data is a fungible commodity that is easy to sell or trade, and your servers are where most of your company’s most valuable data resides. Here are some tips for securing those servers against all enemies – both foreign and domestic. Create a server deployment checklist, and make sure all of the following are on the list, and that each server you deploy complies 100% before it goes into production.
Maintain a server list that details all the servers on your network – SharePoint is a great place for this. At a minimum it should include all the name, purpose, ip.addr, date of service, service tag (if physical), rack location or default host, operating system, and responsible person. We’ll talk about some other things that can be stored on this server list down below, but don’t try to put too much data onto this list; it’s most effective if it can be used without side to side scrolling. Any additional documentation can be linked to or attached. We want this server list to be a quick reference that is easy to update and maintain, so that you do.
Each server must have a responsible party; the person or team who knows what the server is for, and is responsible for ensuring it is kept up-to-date, and can investigate any anomalies associated with that server.
Naming conventions may seem like a strange thing to tie to security, but being able to quickly identify a server is critical when you spot some strange traffic, and if an incident is in progress, every second saved counts.
Ensure that all network configurations are done properly, including static ip.addr assignments, DNS servers, WINS servers, whether or not to register a particular interface, binding order, and disabling services on DMZ, OOB management, or backup networks.
All servers should be assigned static IP addresses, and that data needs to be maintained in your IP Address Management tool (even if that’s just an Excel spreadsheet). When strange traffic is detected, it’s vital to have an up-to-date and authoritative reference for each ip.addr on your network.
Every server deployed needs to be fully patched as soon as the operating system is installed, and added to your patch management application immediately.
All servers need to run antivirus software and report to the central management console. Scanned exceptions need to be documented in the server list so that if an outbreak is suspected, those directories can be manually checked.
Host intrusion prevention/firewall
If you use host intrusion prevention, you need to ensure that it is configured according to your standards, and reports up to the management console. Software firewalls need to be configured to permit the required traffic for your network, including remote access, logging and monitoring, and other services.
Pick one remote access solution, and stick with it. I recommend the built-in terminal services for Windows clients, and SSH for everything else, but you may prefer to remote your Windows boxes with PCAnywhere, RAdmin, or any one of the other remote access applications for management. Whichever one you choose, choose one and make it the standard.
UPS and power saving
Make sure all servers are connected to a UPS, and if you don’t use a generator, that they have the agent needed to gracefully shut down before the batteries are depleted. While you don’t want servers to hibernate, consider spinning down disks during periods of low activity (like after hours) to save electricity.
Unless there’s a really good reason not to, such as application issues or because it’s in the DMZ, all Windows servers should be domain joined, and all non-Windows servers should use LDAP to authenticate users against Active Directory. You get centralized management and a single user account store for all your users.
Administrator account renamed and password set
Rename the local administrator account, and make sure you set (and document) a strong password. It’s not a foolproof approach, but nothing in security is. We’re layering things here.
Local group memberships set and permissions assigned
Make any appropriate assignments using domain groups when possible, and set permissions using domain groups too. Only resort to local groups when there is no other choice and avoid local accounts.
Correct OU with appropriate policies
Different servers have different requirements, and Active Directory Group Policies are just the thing to administer those settings. Create as many OUs as you need to accommodate the different servers, and set as much as possible using a GPO instead of the local security policy.
Confirm its reporting to management consoles
No matter what you use to administer and monitor your servers, make sure they all report in (or can be polled by) before putting a server into production. Never let this be one of the things you forget to get back to.
Unnecessary services disabled
If a server doesn’t need to run a particular service, disable it. You’ll save memory and CPU, and it’s one less way bad guys will have to get it.
If you are going to use SNMP, make sure you configure your community strings, and restrict management access to your known systems.
Backup agents, logging agents, management agents; whatever software you use to manage your network, make sure all appropriate agents are installed before the server is considered complete.
If it’s worth building, it’s worth backing up; no production data should ever get onto a server until it is being backed up.
And no backup should be trusted until you confirm it can be restored.
If you really think the server is ready to go, and everything else on the list has been checked off, there’s one more thing to do – scan it. Run a full vulnerability scan against each server before it goes production to make sure nothing has been missed, and then ensure it is added to your regularly scheduled scans.
Signed into production
Someone other than the person who built the server should spot check it to be sure it’s good to go, before it’s signed into production. By “signing” it, that user is saying they confirmed the server meets your company’s security requirements and is ready for whatever the world can throw at it. That person is also the second pair of eyes, so you are much less likely to find that something got missed.
3. Deploying workstations
Making sure that the workstations are secure is just as important as with your servers. In some cases it’s even more so, since your servers benefit from the physical security of your datacenter, while workstations are frequently laptops sitting on table tops in coffee shops while your users grab another latte. Don’t overlook the importance of making sure your workstations are as secure as possible.
Keep a list of all workstations, just like the server list, that includes who the workstation was issued to and when its lease is up or it’s reached the end of its depreciation schedule. Don’t forget those service tags!
Track where your workstations are by making sure that each user’s issued hardware is kept up-to-date.
It’s very helpful when looking at logs if a workstation is named for the user who has it. That makes it much easier to track down when something looks strange in the logs.
You’ll probably assign IP addresses using DHCP, but you will want to make sure your scopes are correct, and use a GPO to assign any internal DNS zones that should be searched when resolving flat names.
Since your users are logged on and running programs on your workstations, and accessing the Internet, they are at much higher risk than servers, so patching is even more important. Make sure all workstations are fully up-to-date before they are deployed, update your master image frequently, and ensure that all workstations are being updated by your patch management system.
Here’s how to handle workstation antivirus: 100% coverage of all workstations; workstations check a central server for updates at least every six hours, and can download them from the vendor when they cannot reach your central server. All workstations report status to the central server, and you can push updates when needed – Easy.
Host intrusion prevention/firewall
Consider using a host intrusion prevention or personal firewall product to provide more defense for your workstations, especially when they are laptops that frequently connect outside the corporate network. Make sure that the configuration does not interfere with your management tasks, like pushing antivirus updates, checking logs, auditing software, etc.
Like servers, pick one remote access method and stick to it, banning all others. The more ways to get into a workstation, the more ways an attacker can attempt to exploit the machine. The built-in Remote Desktop service that comes with Windows is my preference, but if you prefer another, disable RDP. Ensure that only authorized users can access the workstation remotely, and that they must use their unique credential, instead of some common admin/password combination.
Consider deploying power saving settings through GPO to help extend the life of your hardware, and save on the utility bill. Make sure that you have Wake-On-LAN compatible network cards so you can deploy patches after hours if necessary.
All workstations should be domain joined so you can centrally administer them with unique credentials.
Administrator account renamed and password set
Rename the local administrator account and set a strong password on that account that is unique per machine. Trust me, one of these days you will have no choice but to give some travelling user the local admin account, and if that is the same across all machines, you will then have to reset them all. Use a script to create random passwords, and store them securely where they can be retrieved in an emergency. It seems like a lot of work up front, but it will save you time and effort down the road.