|
||
|
||
| |
|
|
| Columns | Security Matters | Second
Quarter 2001 |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Read
previous Read
previous features
If
you would like
|
CERT®
System and Network Security Practices Editor’s Note: This paper was presented at the NCISSE 2001: Fifth National Colloquium for Information Systems Security Education, held at George Mason University in Fairfax, VA, May 22-24, 2001. It will be published in the NCISSE proceedings. Systems, networks, and sensitive information can be compromised by malicious and inadvertent actions despite an administrator’s best efforts. Even when administrators know what to do, they often don’t have the time to do it; operational day-to-day concerns and keeping systems functioning take priority over securing those systems. Administrators need easy-to-access, easy-to-understand, easy-to-implement security practices. The CERT® system and network security practices are intended to meet those needs. The Problem as Viewed by Administrators Administrators choose how to protect assets, but when managers are unable to identify the most critical assets and the nature of the threats against them (as part of a business strategy for managing information security risk), then the protections an administrator offers are likely to be arbitrary at best. Unfortunately, managers often fail to understand that securing assets is an ongoing process and not just a one-time fix. As a result, they do not consider this factor when allocating administrator time and resources. Even if an organization decides to outsource security services, it will probably continue to be responsible for the establishment and maintenance of secure configurations and the secure operations of critical assets. Most system and network administrators only have their experience and well-meaning advice from peers to guide them in deciding how to protect and secure systems. They do not consult a published set of procedures that serve as de facto standards generally accepted by the administrator community because no such standards exist. Administrators are sorely in need of documented practices that are easy to access, understand, and implement. The practices summarized in this paper are intended to meet this need. They are fully described in my book The CERT Guide to System and Network Security Practices, recently published by Addison-Wesley. We recognize that it may not be practical to implement all steps within a given practice or even all practices. Business objectives, priorities, and an organization’s ability to manage and tolerate risk dictate where information technology (IT) resources are expended and determine the tradeoffs among security and operational capability. However, by adopting these practices, an administrator can protect against today’s threats, mitigate future threats, and improve the overall security of an organization’s networked systems.
CERT Security Practices Structure The CERT System and Network Security practices address 75 to 80 percent of the problems that are reported to the CERT/CC.1 The practices describe the steps necessary to protect systems and networks from malicious and inadvertent compromise. Each practice consists of an introduction and a series of practical steps presented in the order of recommended implementation. There is also a section describing policy considerations that complements the steps and helps ensure that they will be deployed effectively. All practices assume the existence of
Practices were written without reference to any one operating system or version. This makes the practice steps specific but still broadly applicable and ensures the practices will be useful and stay relevant longer than the most current version of an operating system. Examples of practice implementations specific to operating systems are available at the CERT Web site (http://www.cert.org).
Figure 1: Steps for Securing Information Assets
Figure 1 serves as a top-level depiction of how to secure and protect information assets. It includes steps to harden/secure, prepare, detect, respond, and improve. The
recommended practices to harden and secure systems form a strong foundation
by securely configuring information assets (such as networks, systems,
and critical data) and by establishing secure access to these assets.
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. Prepare,
detect, respond, and improve practices assume that harden/secure practices
have been implemented and provide further guidance about what to do
when something suspicious, unexpected, or unusual happens.
Step One: Harden/Secure Systems shipped by vendors are very usable but, unfortunately, often contain many weaknesses when viewed from a security perspective.2 Vendors seek to sell systems that are ready to be installed and used by their customers. The systems 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. Therefore, an administrator must first redefine the system configuration to match the organization’s security requirements and policy for that system. This step will yield a hardened (secure) system configuration and an operational environment that protects against known attacks for which there are defined mitigation strategies. To complete this step, follow the instructions below in the order listed:
Practices for hardening and securing general-purpose network servers (NS) and user workstations (UW) are listed in Table 1 and are fully described on the CERT Web site [Allen 2000a], [Simmel 99].
Table 1: Practices for Hardening and Securing Network Servers (NS=general-purpose network servers; UW=user workstations) Additional hardening details can be found in the CERT document, Installing and securing Solaris 2.6 servers.3 Practices addressing more specific details for securing public Web servers (such as Web server placement, security implications of external programs, and using encryption) are listed in Table 2 and are documented on the CERT Web site [Kossakowski 2000].
Table 2: Practices for Securing Web Servers
Practices that provide guidance on deploying firewall systems (such as firewall architecture and design, packet filtering, alert mechanisms, and phasing new firewalls into operation) are listed in Table 3 and are presented on the CERT Web site [Fithen 99]. Public Web server and firewall practices assume that you have first configured a secure general-purpose server and have then built on it.
Table 3: Practices for Deploying Firewall Systems
The philosophy of the preparation step hinges on the recognition that despite steps taken to harden and secure a system, there exist vulnerabilities yet to be identified. Consequently, an administrator must be able 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 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. In addition, the administrator and his or her manager must develop policies and procedures to identify, install, and understand tools for detecting and responding to intrusions well before such policies, procedures, and tools need to be invoked. 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 administrators 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. Practices for characterizing information assets, preparing to detect signs of intrusion, and preparing to respond to intrusions are listed in Table 4 and are fully described on the CERT Web site [Allen 2000b], [Kossakowski 99].
Table 4: Practices for Characterizing Assets and Preparing for Intrusions
Step Three: Detect This 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 source (a user report, a call from another organization, a security advisory or bulletin). These indicate either that something should be analyzed further or that something on the system has changed or should change (a new patch should be applied, a new tool version should 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. Possible changes include a number of improvement actions (see Improve, below) such as
Practices are listed in Table 5 for detecting signs of intrusion in detection tools, networks, systems (including processes and user behavior), network and system performance, files and directories, hardware, and access to physical resources. These practices are fully described on the CERT Web site [Allen 2000b].
Table 5: Practices for Detecting Signs of Intrusion
In this step, an administrator further analyzes the damage caused by an intrusion (including the scope and effects of the damage), contains these effects as far as 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 case it is needed for legal proceedings against the intruder. Respond practices are listed in Table 6 and are described on the CERT Web site [Kossakowski 2000].
Table 6: Practices for Responding to Intrusions
Improvement actions typically occur following a detection or response activity. In addition to those noted under detect, above, improvement actions may include
Improvement actions may cause you to revisit harden/secure, prepare, and detect practices.
References
Julia Allen is a senior member of the technical staff within the Networked Systems Survivability Program at the Software Engineering Institute. The CERT® Coordination Center is also a part of this program. Allen is engaged in developing security-improvement practices for network-based systems. Prior to this technical assignment, Allen served as acting director of the SEI for an interim period of six months as well as deputy director/chief operating officer for three years. She started the Industry Customer Sector at the SEI in 1992. Allen has more than 25 years of managerial and technical experience in software engineering. Before joining the SEI, she held the position of vice president at Science Applications International Corporation (SAIC), where she was responsible for starting a new software division specializing in embedded systems software for government customers. She was at SAIC for eight years. Allen also spent 10 years at TRW in Redondo Beach, CA., where her work included a range of assignments from integration, test, and field site support to managing major software-development programs. She received a BS in computer science from the University of Michigan, an MS in electrical engineering from the University of Southern California, and an executive business certificate from the University of California at Los Angeles (UCLA). Her professional affiliations include ACM and IEEE Computer Society. Allen’s publications include Security for Information Technology Service Contracts (CMU/SEI-SIM-003, 1998); Responding to Intrusions (CMU/SEI-SIM-006, 1999), Deploying Firewalls (CMU/SEI-SIM-008, 1999), Detecting Signs of Intrusion (CMU/SEI-SIM-009, 2000), Securing Network Servers (CMU/SEI-SIM-010, 2000), Securing Public Web Servers (CMU/SEI-SIM-011, 2000); six reports within the Security Improvement module series; State of the Practice in Intrusion Detection Technologies (CMU/SEI-99-TR-028); The CERT Guide to System and Network Security Practices (Addison-Wesley, June 2001); and various presentations and papers on the CERT security practices, intrusion detection systems, and the SEI's strategic plan and technical program.
The views expressed in this article are the author's only and do not represent directly or imply any official position or view of the Software Engineering Institute or Carnegie Mellon University. This article is intended to stimulate further discussion about this topic. |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
 |
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Copyright
© 2001 by Carnegie
Mellon University.
All rights reserved. |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
