Keeping logs of traffic patterns and noting any deviation from normal behavior can be your first clue to a security breach. Cliff Stoll relayed his experience in The Cuckoo's Egg, in which he helped catch some cyberspies by noting a two-cent discrepancy in some accounting data.
What to Collect
The actual data you collect for your logs will differ for different sites and for different types of access changes within a site. In general, the information you want to collect includes:
User name ●
Host name ●
Source and destination IP address ●
Source and destination port numbers ●
Timestamp ●
Of course, you can gather much more information, depending on what the system makes available and how much space is available to store that information.
Note Do not record passwords that might be sent in cleartext. Doing so creates an enormous potential
security breach if the audit records should be improperly accessed. Storing the Data
Depending on the importance of the data and the need to have it local in instances in which services are being denied, data could be kept local to the resource until needed or be transmitted to storage after each event. Consider how secure the path is between the device generating the log and the actual logging device (the file server, tape or CD-ROM drive, printer, and so on). If that path is compromised, logging can be stopped or spoofed or both.
In an ideal world, the logging device would be directly attached to the device generating the log by a single, simple, point-to-point cable. Because that is usually impractical, the data path should pass through the minimum number of networks and routers. Even if logs can be blocked, spoofing can be prevented with cryptographic checksums (it probably isn't necessary to encrypt the logs because they should not contain sensitive information in the first place).
The storage device should also be carefully selected. Consider Write-Once, Read Many (WORM) drives for storing audit data. With these drives, even if an attacker can get to the data (with the exception of the physical media), they cannot change or destroy the data.
Because collecting audit data can result in a rapid accumulation of bytes, you must consider the
availability of storage for this information in advance. By compressing data or keeping data for a short period of time, you can reduce the required storage space. It is useful to determine a time frame with which everyone is comfortable and for which you will keep detailed audit logs for incident response purposes.
Audit data should be some of the most carefully secured data at the site and in the backups. If an intruder were to gain access to audit logs, the systems themselves---in addition to the data---would be at risk. Audit data can also become the key to the investigation, apprehension, and prosecution of the perpetrator of an incident. For this reason, it is advisable to seek the advice of legal counsel when deciding how you will treat audit data. Get legal counsel before an incident occurs. If your data-handling plan is not
adequately defined before an incident occurs, it might mean that there is no recourse in the aftermath of an event, and it might create a liability resulting from the improper treatment of the data.
Legal Considerations
Because of the nature of the content of audit data, a number of legal questions arise that you might want to bring to the attention of your legal counsel. If you collect and save audit data, be prepared for
consequences resulting from both its existence and its content. One area of concern is the privacy of individuals. In certain instances, audit data might contain personal information. Searching through the data, even for a routine check of the system's security, might represent an invasion of privacy.
A second area of concern involves your having knowledge of intrusive behavior originating from your site. If an organization keeps audit data, is it responsible for examining it to search for incidents? If a host in one organization is used as a launching point for an attack against another organization, can the second organization use the audit data of the first organization to prove negligence on the part of that
organization?
The following lists provide an example of the policies and procedures for the staff aspect of the university security policy.
Key positions must be identified, and potential successors should always be identified. ●
Recruiting employees for positions in the implementation and operation of the network infrastructure requires a thorough background check.
●
All personnel involved with implementing and supporting the network infrastructure must attend a two-day security seminar, which has been developed internally.
●
Equipment Acquisition and Maintenance:
All infrastructure equipment must pass the acquisition certification process before purchase. ●
All new images and configurations must be modeled in a test facility before deployment. ●
All major scheduled network outages and interruptions of services must be announced to those affected.
●
Backup Procedures:
All software images and configurations will be backed up in infrastructure devices when modified. ●
The previous image and configuration file will be kept until another change is made. Therefore, there should always be available the current and the previous image and configuration.
●
All backups will be stored in a dedicated locked area. ●