Establish a policy and procedures that prepare your organization to detect signs of intrusion.

A security policy defines the rules that regulate how your organization manages and protects its information and computing resources to achieve security objectives. One of the policy’s primary purposes in detecting signs of intrusion is to document important information assets¹ and the threats² to those assets that your organization chooses to address³.

Preparation procedures include the actions necessary to observe systems and networks for signs of unexpected behavior, including intrusion. Observation can take the form of monitoring, inspecting, and auditing⁴. From these procedures, all concerned parties are able to determine the operational steps they need to take to comply with your policy. These steps will thereby uphold the security of your organization’s information and networked systems.

Security policies and procedures that are documented, well known, and visibly enforced establish expected user behavior and serve to inform users of their obligations for protecting computing assets. Users include all those who access, administer, and manage your systems and have authorized accounts on your systems. They play a vital role in detecting signs of intrusion.

This practice describes the topics your policy and procedures should address. They need to be tailored to reflect the specific business objectives and security requirements of your organization and its computing environment.

 

Why this is important

Having policy language and procedures in place that prepare you to detect signs of intrusion lets you use your procedures in a timely, managed, and controlled way and eliminates potential errors or omissions in advance of an attack. You do not want to be caught trying to determine what actions to take, what data to gather and preserve, and how to protect your systems from further damage while under attack or after the fact. With advance planning, documentation, and education, trained staff members are able to more effectively coordinate their activities when detecting suspicious activity, an intrusion, or an intrusion attempt. Without the proper knowledge and skills, users may inadvertently expose parts of the organization to security threats

 

How to do it

Include language in your organization’s networked systems security policy that prepares you to detect signs of intrusion.

Document the important and critical information assets and the level of protection (confidentiality, availability, integrity) required for each. Designations for the level may range from “cannot be compromised under any circumstances” (maximum protection) to “contains no sensitive information and can be easily restored” (minimal protection).

Document the types of threats or events that indicate possible signs of intrusion and also document how you intend to respond to them if they are detected. Types of threats may include⁵

• attempts (either failed or successful) to gain unauthorized access to a system or its data
  
• unintended and unauthorized disclosure of information
  
• unwanted disruption or denial of service
  
• the unauthorized use of a system to process, store, or transmit data
  
• changes to system hardware, firmware, or software characteristics without the knowledge or consent of you or of the asset owner

Recognize that there are threats that are difficult to protect against if your systems are connected to the Internet. You need to determine what actions you will take if these occur. Threats of this type include

• denial of service, including email bombing (sending a large volume of electronic messages to a targeted recipient until the system fails) and flood attacks (e.g., filling a channel with garbage, thereby denying others the ability to communicate across that channel or to the receiving host)
  

• programmed threats, such as new viruses not yet detected and eliminated by virus checking tools, and malicious software in the form of CGI scripts, plug-ins, servlets, or applets

• intruders probing or scanning your systems with the intent to exploit any vulnerabilities they discover for use in attempting an intrusion

Document the requirement to establish and maintain secure, reliable configuration information for all assets that represent your known, expected state. This includes taking inventory and tagging all physical computing resources. Periodically compare this information with your current state to determine if anything has been altered in an unexpected way.

Document the roles, responsibilities, and authority of system administrators, security personnel, and users regarding the use and administration of all assets when they participate in detecting signs of suspicious behavior, including intrusions.

Document the roles, responsibilities, authority, and conditions for the testing of intrusion detection tools, the execution of intrusion detection procedures, and the examination of assets suspected of having been compromised. We strongly recommend that your policy requires that all such activity be conducted in a test environment isolated from production systems and networks.

Document procedures and take actions that implement your intrusion detection policy.

In general terms, document what data you plan to collect⁶, why you want to collect it, and where and when you will collect it.

• Document what you want to discover by collecting the data. Typically, you should verify that levels of performance (function, throughput, load) are as you expected them to be and that there is an absence of errors and suspicious or unexpected behavior (as described in the subsequent practices of this module).

• Document where best to collect each type of data. We recommend collecting data as close to the source of its generation as possible, ideally on all hosts. If this is not possible because it would impact performance, collect the data as close to the host as possible. For example, if you cannot place an intrusion detection system on the firewall host, place it on another host that monitors network traffic on both the external (Internet) side of the firewall host and on the internal (organizational network) side of the firewall host.

• Document when to collect the data. As a starting point, we recommend collecting everything you possibly can, at every available source location, 24 hours a day, seven days a week. While this is likely to produce excessive amounts of data, you can manage this process by automating the deletion of data that you normally do not need to process or analyze further under normal operations. However, we recommend inserting a delay between the time of collection and the time of deletion⁷, in the event a suspicious event occurs that you want to analyze further using data you would normally delete⁸.

Document any special handling procedures for each type of collected data. This is particularly important for data that may be used as evidence in subsequent legal proceedings⁹.

Document how you plan to conduct your review of all collected data. Because there is a large volume of system and network data that can be collected, and because there are increasing demands on an administrator’s time, you need to carefully determine

• the order in which specific data will be reviewed
• the frequency of data review
• tools and other mechanisms, such as alerts, that can aid in better identifying suspicious and unexpected behaviors
• the types of events that warrant further investigation and in-depth analysis
• administrator authority, actions to be taken, and what circumstances warrant what actions
• how you will track the status of open events to resolution and closure

In particular

• document the procedure(s) by which monitoring is performed, i.e., the observation of data streams for specific events. This procedure specifies
  

  • the data streams to be monitored
    
  • the monitoring locations on systems and networks
    
  • the times and frequencies with which monitoring is to be performed
    
  • the activation of monitoring after the occurrence of what types of events
    
  • the operational activities necessary to alert appropriate personnel to act upon the suspected intrusion

• document the procedure(s) by which regular inspection and auditing of recorded data (e.g., logs) are performed to identify evidence of intrusions or intrusion attempts

• document the procedure by which physical audits of installed hardware and software are performed

• document the procedure by which integrity checking is performed (comparing the current operational state with a previously generated, secure, reliable, and known state). Specify
  

  • what files are to be checked
    
  • how integrity information is securely generated, maintained, and tested
    
  • frequency with which integrity checking is performed

• document the procedure by which correlation of intrusions is performed, i.e., determining when suspicious activity occurring in one part of your infrastructure may be related to activity in another part. Doing some level of correlation analysis during the intrusion detection process will assist you in determining the full extent of any compromise and its characteristics¹⁰.

Document the procedure for the acquisition and secure installation, configuration, and maintenance of all tools¹¹ necessary to implement your monitoring, inspection, auditing, and integrity checking procedures.

For each procedure and procedure step, document the roles, responsibilities, and authority of system administrators, security personnel, and users. Identify who performs each procedure activity, when, and under what conditions.

Conduct a legal review of your policy and procedures.

This should be performed by your organization’s legal counsel. It is intended to ensure that your policy and procedures

• are legally defensible and enforceable
• comply with overall company policies and procedures
• reflect known industry best practices demonstrating the exercise of due care
• conform to federal, state, and local laws and regulations
• protect your organization from being held legally responsible in the event of compromise
• require the preservation of critical evidence including a defensible, documented chain of custody for all artifacts that may be used in legal proceedings¹²

Train the users who have authorized accounts on your systems.

During the training process, users should learn

• what is expected of them
• how to identify suspicious behavior and who to notify
• what behaviors can reduce the exposure of systems to possible compromise, such as¹³
  • not opening unsolicited email attachments without verifying their source or checking their content
  • working with system administrators to install security patches for commonly used applications (such as web browsers)
  • not downloading and installing software from untrusted sources
  • making and testing backups
  • not using modems while connected through a local area network
  • protecting passwords and sensitive data
  • knowing how to respond to social engineering attempts
• what types of information are being gathered as part of routine security procedures, and the degree to which this information gathering may affect them.

Create and conduct periodic training on your intrusion preparation and detection policy and procedures. This training should be mandatory for all new employees and should cover aspects that are relevant to the employee’s knowledge and responsibilities.

Test the effectiveness of the training and each employee’s readiness. Conduct practice drills (e.g., detecting break-ins and viruses) that test procedures and execute operational activities, making sure all staff members are aware of their roles and responsibilities. Conduct post-mortem meetings with trainees. Provide remedial training as required.

Regularly conduct mandatory security awareness refresher training. Highlight recent changes to policy or procedures and summarize recent attack methods and counter measures. Make this subject a recurring topic at executive and management level staff meetings to maintain awareness.

To keep pace with the rapid rate of technological change, ensure that system and network administration staff have time set aside to maintain their knowledge, skills, and currency in technical topics required to implement your policy and procedures.

Keep your intrusion detection policy and all related procedures and training current.

Periodically review your policy, procedures, and training. Take into account

• system changes and upgrades including the introduction of new software
• changes in critical assets
• changes in security requirements
• changes in key roles and responsibilities
• public and vendor information sources. These sources regularly report current intruder trends, new attack scenarios, security vulnerabilities, methods for their detection, and guidance to address them.

If your organization suffers an intrusion, review your policy, procedures, and training to determine if revisions are necessary to ensure that future intrusion attempts of the same type can be more readily detected and controlled, if not prevented.¹⁴

 

Other Information

The most common sources of current information about security problems are the web sites of vendors, computer security organizations, and network security organizations. For example, you can find many advisories, incident notes, vulnerability notes, and tech tips at the CERT/CC web site. Refer to the implementation Maintaining currency by periodically reviewing public and vendor information sources.

There are also mailing lists (such as those maintained by the SANS Institute with subscriptions available at http://www.sans.org/), some of which are sponsored by vendors, and USENET news groups. Because lists and web sites appear, disappear, change frequently, or cease to be updated regularly, you need to ensure that the sources you consult are up-to-date.

 

Implementation Details

Maintaining currency by periodically reviewing public and vendor information sources

 

Footnotes

1. Assets generally include information, hardware, software, and people. Asset values are determined based on the impact to the organization if the asset is lost. Critical assets are those that are essential to meeting an organization's mission and business objectives. [Alberts 00] For this module, assets include information, hardware, and software that reside on and comprise the information technology infrastructure of an organization.
   

2. Threat is defined here as anything that may compromise an asset. This could be a person, such as an employee or a hacker, or it could be a competitor or anyone else with deliberate intention to compromise an asset. Threats also include anything which results in accidental disruption to an asset (such as a natural disaster), the means of access to do so, or any outcome or consequence that results in an unwanted effect such as disclosure, modification, destruction, loss, or interruption. [Alberts 00]

3. Systematic methods of information security risk analysis and assessment are emerging. These methods help an organization identify important assets, threats against these assets, security requirements for these assets, and weaknesses or vulnerabilities in current practice that increase the likelihood of these assets being compromised. Refer to Operationally Critical Threat, Assets, and Vulnerability Evaluation^SM(OCTAVE^SM) Framework, Version 1.0 [Alberts 99], Secure Computing [Summers 97], Network Intrusion Detection: An Analyst's Handbook [Northcutt 99], and "Web of Worries" [Kessler 00] for more information on this subject.

4. Monitoring is the observation of data streams for specific events. Inspection is the examination of a data resource or process. Auditing is the systematic examination of data against documented expectations of form or behavior. Refer to An Approach for Selecting and Specifying Tools for Information Survivability [Firth 97].

5. Refer also to CERT/CC summaries, advisories, incident notes, and vulnerability notes available at http://www.cert.org/ and refer to How To Eliminate The Ten Most Critical Internet Security Threats: The Experts Consensus [SANS 00].

6. Refer to the practice "Identify data that characterize systems and aid in detecting signs of suspicious behavior"

7. A reasonable starting point might be one to two weeks, but this depends on your operation, review schedule, and data storage capacity.

8. Refer to the practice "Manage logging and other data collection mechanisms," specifically the step "Document your management plan for handling log files."

9. Refer to the module Responding to Intrusions [Kossakowski 99], specifically the practice "Collect and protect information associated with an intrusion"

10. Refer to the module Responding to Intrusions [Kossakowski 99], specifically the practice "Analyze all available information to characterize an intrusion."

11. One list of such tools is contained in the implementation Identifying tools that aid in detecting signs of intrusion. Many of these tools can be downloaded from the Center for Education, Research, and Information Assurance Security [CERIAS] (formerly known as Computer Operations, Audit, and Security [COAST]).

12. Refer to the module Responding to Intrusions [Kossakowski 99], specifically the practice "Collect and protect information associated with an intrusion."

13. Refer to http://www.sans.org/ for more information on the five worst security mistakes committed by the average user.

14. Refer to the module Responding to Intrusions [Kossakowski 99], specifically the practice "Identify and implement security lessons learned."

---

Copyright 2000 Carnegie Mellon University.

CERT^® and CERT Coordination Center^® are registered in the U.S. Patent and Trademark office.

See the conditions for use, disclaimers, and copyright information.

This page was last updated on October 18, 2000.