Develop an effective communication plan. Decide what types of events require you to notify local law enforcement, the FBI, other sites, and coordinating bodies like those identified in the Appendix. Decide in advance what types of events require you to notify as many people as possible and which incidents demand secrecy. If you suspect an employee is the source of trouble, privacy has legal implications. Rumors based on incorrect assumptions and inadequate data can lead to court action by those incorrectly accused. If the employee is guilty and hears through the grapevine of your suspicions, you might lose the trail of evidence. A disgruntled employee facing prosecution for computer mischief may not have much to lose, and that last hidden bomb could be detonated instead of disarmed.

Keep your users informed about potential problems. As you saw in earlier chapters, humans are the weakest link. Warn employees about giving away user names or passwords over the phone, for example. Conduct regular classes and encourage your employees to attend (perhaps by giving away prizes). The importance of user education cannot be emphasized enough because almost everyone spends some time browsing the Internet looking for competitive information, ordering from business partners, or keeping current with technology. Of course, you might want to keep some secrets. If you give detailed explanations of all of your tools and techniques, a clever insider could suddenly find new ways to go undetected.

Keep logs of important activities. Unfortunately, this area requires tradeoffs. You cannot go back and look at historical data to determine how your site was hacked if you do not keep logs. How much data to keep and how long to store the data are variables whose values you must determine. To be safe, log everything that you can without seriously degrading the performance of your systems. Audit logs are the most comprehensive source of system activities. Network logs are equally important. Logs generated by applications also must be kept. If not already supported by the product generating the log, consider adding cryptographic integrity protection to your log files. Depending on your requirements, you can compute cryptographic hashes on each record or only on the log files. Ensure that you have appropriate automated mechanisms in place for log file storage. You do not want to discover that the data you need most is missing because that $500 disk drive wasn’t ordered. If your systems support it, logging to write-once media is another way to protect the integrity of log files.

Keep records of system configuration changes and enforce a strict regimen for when changes are allowed. Any time the firewall packet filters are changed, a well-understood process should document who requested the change, the design for the proposed change, who implemented the change, who reviewed it, and so on. If an intrusion occurs because of one of these changes, ready access to the change log can help diagnose the problem quickly.

Discovery and Detection

IDSs grew out of a need to search a large space of information and glean out only the important data. Many systems administrators knew that it was important to keep audit logs. They just didn’t know all of the different things to look for in that mountain of data. Similarly, network packet-based IDSs filter through many megabytes of data each day looking for individual problems or attack patterns. How do you know when you’ve been hit? Hopefully, your IDS will tell you this. If you’ve deployed an IDS and configured it properly, the IDS will catch a number of common attacks intruders launch against your site.

One potential area of weakness is application logging. Most IDSs are not flexible enough today to read log files generated by arbitrary applications. Looking for attack patterns or statistical profiles in firewall logs is something that some IDSs are beginning to do today. However, this capability is far from perfect.

If you have installed Tivoli’s Management Environment (TME), you can write your own log file adapter objects. These adapters will send event notifications to the central TME console. There, custom responses can be designed for each event of interest. Your adapter object can be sophisticated enough to send an event only when three failed logins have been detected in your custom application, for example. Thus, you should consider using something like TME’s Event Console for extending your coverage of IDSs to include custom applications.

Another thing to remember is to have a site policy which actually ensures that an event will be discovered by someone. If your IDS prints reports each morning, rather than sending real-time alerts, an accountable individual should be looking for evidence of misuses or intrusions each morning. Similarly, if your system generates real-time alerts, but your paging system experiences problems the same weekend you’re hit, you’ll realize the importance of backup notification mechanisms such as hard copy reports. Historically, hard copy reports are often favored as evidence in court proceedings, although this could change as knowledge about proper use of digital signatures becomes more widespread. Thus, it’s a good idea to print hard copy reports from your IDSs and assign personnel to look through these reports on a daily basis (if not more often).