1. CERT® System and Network Security Practices
Presented by
Julia H. Allen
at the
NCISSE 2001: 5th National Colloquium for Information Systems Security Education, held at George Mason University in Fairfax, VA on May 22-24, 2001
Networked Systems Survivability
CERT® Coordination Center
Software Engineering Institute
Carnegie Mellon University
Pittsburgh, PA
© 2001 by Carnegie Mellon University
® CERT, CERT Coordination Center, and Carnegie Mellon are registered in the U.S. Patent and Trademark Office
The Networked Systems Survivability Program (NSS) and its CERT® Coordination Center (CERT®/CC) are part of the Software Engineering Institute (SEI), a federally funded research and development center at Carnegie Mellon University. The program is recognized by government and industry as a neutral, authoritative source of information assurance data and expertise.
In 1988, as a result of an attack on the Internet, the CERT/CC was established as an emergency response team and a central point for communication among computer experts. Today the CERT®/CC serves as a central response and coordination facility for global information security incident response and countermeasures for threats and vulnerabilities. As the Internet and other national information infrastructures have grown more complex and more interdependent, the frequency and severity of unauthorized intrusions into systems connected to these networks has increased. Since 1988, the CERT®/CC has responded to more than 54,000 information security incidents, affecting host systems in the Department of Defense, other federal agencies, and the private sector. The CERT/CC has also helped establish other response teams worldwide.
In addition to incident response and analysis, the CERT®/CC publishes advisories and other related publications to alert the Internet community regarding current and continuing information security threats and vulnerabilities, and measures to safeguard against them. Security practices, technical implementations, training courses, research articles on risk and survivability, and other information security publications of the SEI NSS program are available at http//

2. The Problem - in the Large
85% of respondents to Computer Security Institute/FBI 2001 survey reported security breaches (70%, 2000; 62% 1999)*
186 organizations (35%) able to quantify financial loss reported $377.8M (273 organizations [51%], $265.6M in 2000 survey)
theft of proprietary information and financial fraud most serious
70% cited their Internet connection as a frequent point of attack (59% in 2000 survey)
*Computer Crime and Security Survey, Computer Security Institute and the FBI, 2001,
Attacks on networks can lead to lost money, time, products, reputation, sensitive information, and in the case of medical and patient data, even lives.
New attacks methods and vulnerabilities emerging constantly; old ones mutating.
Vendor product engineering for ease of use is not being matched by engineering for ease of secure administration.
Product time to market is more important than building in security features.
Until customers demand products that are more secure, the situation is unlikely to change. We recommend voting for security features with your dollars when purchasing these products.
Last but not least, demand for qualified administrators and other knowledgeable professionals far exceeds supply. Unqualified staff often placed in key positions to fill gap.

3. The Problem - as Viewed by Administrators
Lack of management understanding and guidance
Lack of or arbitrary priorities (business goals, assets, threats, risks, protection strategies)
Lack of time, resources, and qualified staff
New and mutating attacks, new vulnerabilities
Insecure products, bad patches
Systems shipped by vendors are very usable but unfortunately, often contain many weaknesses when viewed from a security perspective.
Vendors seek to sell systems that are ready to be installed and used by their customers. The systems perform as advertised, and they come with most, if not all, services enabled by default. Vendors apparently want to minimize telephone calls to their support organizations and generally adopt a “one size fits all” philosophy in relation to the systems they distribute. As a result, an administrator needs to first redefine the system configuration to match the organization’s security requirements and policy for that system.
Security starts to degrade almost immediately after fixes, workarounds, and new technology are put in place.
Administrators need practices that are easy to access, understand, and implement. We believe the CERT security practices are a step in this direction.

4. The practices, organized into five top-level steps as shown here, cover the actions necessary to protect your systems and networks against malicious and inadvertent compromise. They are based on CERT/CC data on breaches and vulnerabilities and protect against up to 80% of the attacks reported to CERT/CC. They are technology, operating system-neutral for broad applicability and are often accompanied by procedures for specific operating systems.
All practices assume the existence of (1) business goals and objectives from which security requirements derive and (2) organization- and site-level security policies.
The first step yields a hardened (secure) system configuration and an operational environment that protects against known attacks for which there are defined mitigation strategies. The subsequent steps - Prepare, Detect, Respond, and Improve - assume that Harden/Secure practices have been implemented and provide further guidance about what to do when something suspicious, unexpected, or unusual happens.
Prepare addresses practices that should be in place prior to the occurrence of an intrusion to maximize your likelihood of detecting and effectively responding to the intrusion. Detect and Respond practices assume that Prepare practices have been implemented.
Detect describes practices that monitor for signs of suspicious or unexpected behavior in systems, networks, files and directories, user behavior, and hardware. First pass analysis is performed here.
During Respond, more detailed analysis is performed. Corrective actions are taken based on this analysis.
Following the occurrence of any intrusion, we recommend a set of improvement practices that mitigate against damages caused by a similar attack in the future. Improvement may include enhancing preparation practices.
I will now describe in more detail the practices contained in each of these 5 steps.

5. Harden/Secure
Install the minimum essential operating system and all applicable patches
Remove all privilege/access and then add back in only as needed (“deny first, then allow”)
Address user authentication mechanisms, backups, virus detection/eradication, remote administration, and physical access
Record and securely store integrity checking (characterization) information
The recommended practices to harden and secure systems (network servers, user workstations) form a strong foundation by establishing secure configurations of and access to information assets (networks, systems, critical data, etc.). If this is done correctly and maintained, many of the common vulnerabilities used by intruders are eliminated. Following these practices can greatly reduce the success of many common, recurring attacks.
Other practices include the creation of a computer deployment plan (network services, users/user privileges, access enforcement, intrusion detection, backup/recovery, network connections), securely configuring network service clients, using a tested model configuration for workstations, and developing an acceptable use policy.
More specific practices are available for securing public web servers (web server placement, security implications of external programs (plug ins, scripts), and using encryption) and deploying firewalls (firewall architecture and design, packet filtering, alert mechanisms, and phasing new firewalls into operation).

6. Prepare
Identify and prioritize critical assets, level of asset protection, potential threats, detection and response actions, authority to act.
Identify data to collect and collection mechanisms
Characterize all assets, establishing a trusted baseline for later comparison
Identify, install, and understand detection and response tools
Determine how to best capture, manage, and protect all recorded information
The philosophy of the preparation step hinges on the recognition that there exists a collection of vulnerabilities yet to be identified. This requires an administrator to be in a position to recognize when these vulnerabilities are being exploited. To support such recognition, it is vitally important to characterize a system so that an administrator can understand how it works in a production setting. Through a thorough examination and recording of a known baseline state and of expected changes at the network, system (including kernel), process, user, file, directory, and hardware levels, the administrator learns the expected behavior of an information asset.
One way to think about the distinction between the hardening and securing step and the characterization part of preparing is that hardening attempts to solve known problems by applying known solutions, whereas characterization helps identify new problems and formulate new solutions. In the case of characterization, the problems are identified through anomaly-based detection techniques, that is departures from normal behavior, so that new solutions can be formulated and applied.
Categories of data to collect include network, system, and process performance, other network, system, and process data, files and directories, users, applications-specific, log files, and vulnerabilities.

7. Detect
Ensure that the software used to examine systems has not been compromised
Monitor and inspect network and system activities
Inspect files and directories for unexpected changes
Investigate unauthorized hardware
Looks for signs of unauthorized physical access
Initiate response procedures
The Detect step occurs during the monitoring of transactions performed by some asset (such as looking at the logs produced by a firewall system or a public web server). The administrator notices some unusual, unexpected, or suspicious behavior, learns something new about the asset's characteristics, or receives information from an external stimulus (a user report, a call from another organization, a security advisory or bulletin).
These indicate either that something needs to be analyzed further or that something on the system has changed or needs to change (a new patch needs to be applied, a new tool version needs to be installed, etc). Analysis includes investigating unexpected or suspicious behavior that may be the result of an intrusion and drawing some initial conclusions, which are further refined during the Respond step.

8. Respond Analyze all available information; determine what happened
Disseminate information per policy, using secure channels
Collect and preserve evidence, including chain of custody
Contain damage
Eliminate all means of intruder access
Return systems to normal operation
During Respond, an administrator further analyzes the damage caused by an intrusion (including the scope and effects of the damage), contains these effects to the extent possible, works to eliminate future intruder access, and returns information assets to a known, operational state. It may be possible to do this step while continuing analysis.
Other parties that may be affected are notified, and evidence is collected and protected in the event it should be needed for legal proceedings against the intruder.
Your policies may require that you return a compromised asset to operation before all analysis and containment practices are completed. You need to understand your risk of exposure when doing so.

9. Improve
Identify lessons learned; collect security business case information
Install a new patch (re-harden); uninstall a problem patch
Update the configuration of alert, logging, and data collection mechanisms
Update asset characterization information
Install a new tool; retire an old tool
Update policies, procedures, and training
Improvement actions may cause you to revisit Prepare, Detect, and Respond practices.

10. For More Information http://www.cert.org/security-improvement
The CERT® Guide to System and Network Security Practices, Addison-Wesley, June 2001
Phone:
Handouts: Practices one page description, available on CERT web site