Unwelcome visitors to your network are at best a nuisance and at worst an absolute disaster. Yet, no matter how diligent you are, unless you lock your kit in a concrete bunker with no connections to the outside world, there’s always a chance of someone getting in through a previously unknown crack.
This checklist will help you keep the bad guys out or deal with them if they do manage to get in.
|Put in place strict procedures concerning the sharing of password and other security information among staff and educate your users. Enforce password policies electronically where possible.
||You need to think the worst and ensure that should someone get into the network, they can't rampage around the entire system.|
|Centralise as much of your access control and authentication functions as possible, preferably into a directory service.
||One user database is easier to manage efficiently than half a dozen.|
|Give staff as much access as they need to do their job, but no more.
||Another way to limit an intruder's range within the network.|
|Work with the Board to integrate IT access into the human resources process and provide easy-to-use tools to prevent misconfiguration.
||It may be sensible to allow HR to define access rights for new users, as they are the most up-to-date on staff changes.|
|Put in place whatever measures you can afford for detecting attacks.
||If you are able to afford intrusion detection hardware/software, it can be a huge help and will spot problems much more quickly than the overworked network manager.|
|Consider worst-case scenarios (e.g. that you may need to reinstall some equipment from scratch) and ensure that all materials required are up to date.
||When you come to reinstall your main server, you don't want to find that you've lost the CD for the disaster recovery system.|
|Ensure you have an efficient backup/recovery strategy.
||If you have to reinstall servers, you need to have easy access to the backup tapes. The tapes also need to contain the data you think they contain.|
|Implement time synchronisation across all your servers.
||If you're to trace attacks through log files, you need to be able to match logs from different machines, based on the time events happened.|
|Set alarms where possible.
||If your systems page you, when something weird is happening, you stand a chance of stamping on a problem early.|
|Have a serious discussion of security issues and consider potential enhancements for the new budget season.
||New attacks come along all the time, but so do new protection mechanisms. You should stay as up-to-date as resources permit.|
|Re-evaluate all threats, physical (e.g. break-ins or misbehaving staff) and electronic.
||As companies' budgets tighten, it's easy for security measures such as building patrols to gradually reduce.|
|When the network changes|
|Ensure that the security facilities of the new equipment are understood and used correctly.
||It's easy when adding a new piece of equipment to leave a default password unchanged, or a management port open to intruders.|
|Run proactive security checks using one of the widely available commercial or freeware packages.
||There are plenty of applications that will check your network security. Plan carefully, though, as some of them will cause outages if (say) they probe a susceptible machine with a denial-of-service attack.|
|Examine a manageable number of your user accounts and verify that they have been configured correctly.
||If somebody is setting user accounts up wrongly, you will only find out by looking.|
|Examine your disaster recovery systems and ensure they are working correctly.
||You don't want to encounter a scratched CD, just when you need to use it.|
|Spend some time looking into newly-discovered attacks and understand how they are perpetrated.
||Attack types tend to come in waves - you may have a series of buffer-underrun attacks and then a flurry of denial-of-service ones, for instance. If you understand how they work, you're better placed to eradicate them.|
|Audit the directory service to ensure that staff changes (particularly departures) are enforced correctly.
||It's all too common to find live accounts for people who left months ago but still have (say) remote access.|
|Install any security patches you have come across in your daily research (see below) and which need downtime.
||It's reasonable to have an "at risk" period for the network once per week.|
|Obtain all software patches for all of your equipment and install those that require no system downtime (e.g. Windows updates).
||If there's a security patch and it costs nothing to install, install it.|
|Keep your eyes open.
||Technical staff are among the few people who rove around the entire company, and they are ideally placed to spot misuse or potential issues.|
|When you get hacked|
|Cut off the source of the intrusion.
||If you can figure out where the attack has come from, isolate that source. Otherwise consider splitting the components of the network physically apart, until you figure out where the attack is coming in. There is a school of thought that says you should allow the intruder to stay put until you can trace him back to the source but this is for experts only.|
|Limit the scope of the attack.
||If, for instance, you are experiencing a denial-of-service attack for application X, isolate all instances of that application.|
|Keep staff informed.
||If you communicate with the users, they will generally stay off your back and allow you to get on with fixing the problem.|
|Make detailed notes of every aspect of the attack you can. Archive any informative materials (e.g. log files, screenshots) to write-only media.
||If a prosecution ensues, you need as much evidence as you can muster,|
|Figure out the type of attack you're experiencing and use whatever resources are available to understand how to stop it. If a patch is available, install it; otherwise, attempt to devise a workaround.
||Even if there isn't a specific patch for application X on machine Y, if you understand what is happening you may be able to adjust the settings somewhere else in the network and prevent the attack from happening.|
|Once you are certain you have eradicated the attack, piece the network back together carefully, reconfiguring/reinstalling as required.
||As you go along, you should double-check each element of the network to ensure its configuration has not been altered.|
|Analyse the damage done - including both the cost of putting it right and the possible collateral problems (e.g. the business and privacy issues of confidential data being uploaded from your network).
||As well as the time and cost issues, there may be legal issues with data leaving the building.|
|When normal service has been restored, write up your notes about the attack while they're still fresh in your mind; if you have a large team working on the problem, this should be done collectively.
||If you leave this until later, important details will fade from memory.|
|If you can trace the intruder's IP address, speak with their ISP (if it looks like an individual) or network manager (if it looks like a rogue employee of a company).
||The chances are they're committing an offence in their country. Cutting them off at the source will help end your troubles.|
|Monitor the network for future attacks of a similar nature.
||Intruders often return for another try at a later date. You want to be sure that you really did close the hole.|