More specifically, this document describes, in detail, the following practices to apply: Securing, installing, and configuring the underlying operating system Securing, installing, and configuring server software Maintaining the secure configuration through application of appropriate patches and upgrades, security testing, monitoring of logs, and backups of data and operating system files. The following key guidelines are recommended to Federal departments and agencies for maintaining a secure server.
Organizations should carefully plan and address the security aspects of the deployment of a server. Because it is much more difficult to address security once deployment and implementation have occurred, security should be carefully considered from the initial planning stage. Organizations are more likely to make decisions about configuring computers appropriately and consistently when they develop and use a detailed, well-designed deployment plan.
Developing such a plan will support server administrators in making the inevitable tradeoff decisions between usability, performance, and risk. ES-1 8. Organizations should address the following points in a deployment plan: Types of personnel required e. Organizations should implement appropriate security management practices and controls when maintaining and operating a secure server.
Appropriate management practices are essential to operating and maintaining a secure server. Organizations should ensure that the server operating system is deployed, configured, and managed to meet the security requirements of the organization. The first step in securing a server is securing the underlying operating system. Most commonly available servers operate on a general-purpose operating system.
Many security issues can be avoided if the operating systems underlying servers are configured appropriately. Default hardware and software configurations are typically set by manufacturers to emphasize features, functions, and ease of use, at the expense of security. Using security configuration guides or checklists can assist administrators in securing servers consistently and efficiently.
Securing an operating system initially would generally include the following steps: Patch and upgrade the operating system Remove or disable unnecessary services, applications, and network protocols Configure operating system user authentication ES-2 9. Organizations should ensure that the server application is deployed, configured, and managed to meet the security requirements of the organization.
In many respects, the secure installation and configuration of the server application will mirror the operating system process discussed above. The overarching principle is to install the minimal amount of services required and eliminate any known vulnerabilities through patches or upgrades. If the installation program installs any unnecessary applications, services, or scripts, they should be removed immediately after the installation process concludes.
Securing the server application would generally include the following steps: Patch and upgrade the server application Remove or disable unnecessary services, applications, and sample content Configure server user authentication and access controls Configure server resource controls Test the security of the server application and server content, if applicable. Many servers also use authentication and encryption technologies to restrict who can access the server and to protect information transmitted between the server and its clients.
Organizations should periodically examine the services and information accessible on the server and determine the necessary security requirements. Organizations should stay aware of cryptographic requirements and plan to update their servers accordingly.
Organizations should commit to the ongoing process of maintaining the security of servers to ensure continued security. Maintaining a secure server requires constant effort, resources, and vigilance from an organization. Securely administering a server on a daily basis is an essential aspect of server security. Maintaining the security of a server will usually involve the following actions: Configuring, protecting, and analyzing log files on an ongoing and frequent basis Backing up critical information frequently Establishing and following procedures for recovering from compromise Testing and applying patches in a timely manner Testing security periodically.
ES-3 Introduction 1. NIST is responsible for developing standards and guidelines, including minimum requirements, for providing adequate information security for all agency operations and assets; but such standards and guidelines shall not apply to national security systems. This guideline has been prepared for use by Federal agencies.
It may be used by nongovernmental organizations on a voluntary basis and is not subject to copyright, though attribution is desired. Nothing in this document should be taken to contradict standards and guidelines made mandatory and binding on Federal agencies by the Secretary of Commerce under statutory authority, nor should these guidelines be interpreted as altering or superseding the existing authorities of the Secretary of Commerce, Director of the OMB, or any other Federal official.
Hosts that incidentally provide one or a few services for maintenance or accessibility purposes, such as a remote access service for remote troubleshooting, are not considered servers in this document. The types of servers this publication addresses include outward- facing publicly accessible servers, such as web and email services, and a wide range of inward-facing servers.
This document discusses the need to secure servers and provides recommendations for selecting, implementing, and maintaining the necessary security controls.
This document addresses common servers that use general operating systems OS such as Unix, Linux, and Windows. Many of the recommendations in this document may also be applicable to servers that use specialized OSs or run on proprietary appliances, but other recommendations will not be implementable or may have unintended consequences, so such servers are considered outside the scope of this document.
Other types of servers outside the scope of this document are virtual servers and highly specialized servers, particularly security infrastructure devices e. The recommendations in this document are intended as a foundation for other server-related documents and do not override more specific recommendations made in such documents. The material in this document is technically oriented, and it is assumed that readers have at least a basic understanding of system and network security.
It also introduces the high-level steps for securing a server. Section 3 discusses the security planning and management for servers.
Section 5 discusses the actions needed to securely install and configure server software, such as Web server software and email server software. Section 6 provides recommendations for maintaining the security of a server.
The document also contains appendices with supporting material: Appendix A contains a glossary. Appendix B contains a list of acronyms and abbreviations. Appendix C lists print and online resources that may be helpful for understanding general server security.
Background A server is a host that provides one or more services for other hosts over a network as a primary function. Another example is a database server that provides database services for Web applications on Web servers.
This section provides background information on server security. It first discusses common server vulnerabilities and threats, and places them in the context of the types of environments in which servers are deployed. Next, it explains how the security needs of a server can be categorized so that the appropriate security controls can be determined. The section also gives an overview of the basic steps that are required to ensure the security of a server and explains fundamental principles of securing servers.
Knowledge of potential threats is important to understanding the reasons behind the various baseline technical security practices presented in this document. Many threats against data and resources are possible because of mistakes— either bugs in operating system and server software that create exploitable vulnerabilities, or errors made by end users and administrators.
Threats may involve intentional actors e. Threats can be local, such as a disgruntled employee, or remote, such as an attacker in another geographical area.
Organizations should conduct risk assessments to identify the specific threats against their servers and determine the effectiveness of existing security controls in counteracting the threats; they then should perform risk mitigation to decide what additional measures if any should be implemented, as discussed in NIST Special Publication SP , Risk Assessment Guide for Information Technology Systems.
Performing risk assessments and mitigation helps organizations better understand their security posture and decide how their servers should be secured. In particular, NIST SP , Engineering Principles for Information Technology Security A Baseline for Achieving Security , contains a set of engineering principles for system security that provide a foundation upon which a more consistent and structured approach to the design, development, and implementation of IT security capabilities can be constructed.
An important element of planning the appropriate security controls for a server is understanding the threats associated with the environment in which the server is deployed. Organizations 1 For the purposes of this document, a host that does not provide services for other hosts as a primary function, but incidentally provides one or a few services for maintenance or accessibility purposes, is not considered a server. An example is a laptop that has a remote access service enabled so that IT support staff can remotely maintain the laptop and perform troubleshooting.
For servers in legacy environments, organizations should secure them as if they were in a typical enterprise environment or a higher-security environment, as appropriate, and make the minimum possible security control alterations to facilitate legacy access.
Confidentiality refers to protecting information from being accessed by unauthorized parties. Integrity refers to ensuring the authenticity of information—that information is not altered, and that the source of the information is genuine. Availability means that information is accessible by authorized users.
Each objective addresses a different aspect of providing protection for information. Determining how strongly a system needs to be protected is based largely on the type of information that the system processes and stores. For example, a system containing medical records probably needs much stronger protection than a computer only used for viewing publicly released documents. This is not to imply that the second system does not need protection; every system needs to be protected, but the level of protection may vary based on the value of the system and its data.
A limited adverse effect means that, for example, the loss of confidentiality, integrity, or availability might i cause a degradation in mission capability to an extent and duration that the organization is able to perform its primary functions, but the effectiveness of the functions is noticeably reduced; ii result in minor damage to organizational assets; iii result in minor financial loss; or iv result in minor harm to individuals.
The potential impact is MODERATE if the loss of confidentiality, integrity, or availability could be expected to have a serious adverse effect on organizational operations, organizational assets, or individuals. A serious adverse effect means that, for example, the loss of confidentiality, integrity, or availability might i cause a significant degradation in mission capability to an extent and duration that the organization is able to perform its primary functions, but the effectiveness of the functions is significantly reduced; ii result in significant damage to organizational assets; iii result in significant financial loss; or iv result in significant harm to individuals that does not involve loss of life or serious life threatening injuries.
The potential impact is HIGH if the loss of confidentiality, integrity, or availability could be expected to have a severe or catastrophic adverse effect on organizational operations, organizational assets, or individuals.
A severe or catastrophic adverse effect means that, for example, the loss of confidentiality, integrity, or availability might i cause a severe degradation in or loss of mission capability to an extent and duration that the organization is not able to perform one or more of its primary functions; ii result in major damage to organizational assets; iii result in major financial loss; or iv result in severe or catastrophic harm to individuals involving loss of life or serious life threatening injuries.
Protection measures otherwise known as security controls tend to fall into two categories. First, security weaknesses in the system need to be resolved. For example, if a system has a known vulnerability that attackers could exploit, the system should be patched so that the vulnerability is removed or mitigated. Second, the system should offer only the required functionality to each authorized user, so that no one can use functions that are not necessary.
This principle is known as least privilege. Limiting functionality and resolving security weaknesses have a common goal: give attackers as few opportunities as possible to breach a system.
A common problem with security controls is that they often make systems less convenient or more difficult to use. When usability is an issue, many users will attempt to circumvent security controls; for example, if passwords must be long and complex, users may write them down.
Balancing security, functionality, and usability is often a challenge. This guide attempts to strike a proper balance and make recommendations that provide a reasonably secure solution while offering the functionality and usability that users require.
Another fundamental principle endorsed by this guide is using multiple layers of security—defense in depth. For example, a system may be protected from external attack by several controls, including a network-based firewall, a host-based firewall, and OS patching. The motivation for having multiple layers is that if one layer fails or otherwise cannot counteract a certain threat, other layers might prevent the threat from successfully breaching the system.
A combination of network-based and host-based controls is generally most effective at providing consistent protection for systems. This guidance should assist agencies in meeting baseline requirements for servers deployed in their environments. As a prerequisite for taking any step, however, it is essential that the organization have a security policy in place.
Plan the installation and deployment of the operating system OS and other components for the server. Section 3 addresses this step. Install, configure, and secure the underlying OS. This is discussed in Section 4.
Install, configure, and secure the server software. Section 5 describes this step. For servers that host content, such as Web servers Web pages , database servers databases , and directory servers directories , ensure that the content is properly secured. This is highly dependent on the type of server and the type of content, so it is outside the scope of this publication to provide recommendations for content security.
Readers should consult relevant NIST publications see Appendix C and other sources of security recommendations for information on securing server content. Employ appropriate network protection mechanisms e. Accordingly, this publication does not present recommendations for selecting network protection mechanisms. Employ secure administration and maintenance processes, including application of patches and upgrades, monitoring of logs, backups of data and OS, and periodic security testing.
This step is described in Section 6. The practices recommended in this document are designed to help mitigate the risks associated with servers.
They build on and assume the implementation of practices described in the NIST publications on system and network security listed in Appendix C. Complexity is at the root of many security issues. Fail-Safe—If a failure occurs, the system should fail in a secure manner, i. It is usually better to lose functionality rather than security. Complete Mediation—Rather than providing direct access to information, mediators that enforce access policy should be employed.
Common examples of mediators include file system permissions, proxies, firewalls, and mail gateways. Open Design—System security should not depend on the secrecy of the implementation or its components.
Separation of Privilege—Functions, to the degree possible, should be separate and provide as much granularity as possible. The concept can apply to both systems and operators and users. In the case of systems, functions such as read, edit, write, and execute should be separate. Checklists can comprise templates or automated scripts, patch information, Extensible Markup Language XML files, and other procedures. Checklists are intended to be tailored by each organization to meet its particular security and operational requirements.
Typically, checklists are created by IT vendors for their own products; however, checklists are also created by other organizations, such as academia, consortia, and government agencies.
The use of well-written, standardized checklists can markedly reduce the vulnerability exposure of IT products. Checklists can be particularly helpful to small organizations and to individuals with limited resources for securing their systems. The repository also hosts copies of some checklists, primarily those developed by the federal government, and has links to the location of other checklists.
Includes current Final and Draft SP pubs. Includes current Final and Draft papers. Books: NIST-authored books, book sections, and encyclopedia entries related to cybersecurity and privacy. Search Search publication record data not a full text search. Results View Brief Summary.
Items Per Page 25 50 75 All. Status Final Public Draft Withdrawn. Control Family Please fix the following:. Security Risk Self-Assessment for Midsize Organizations This free application is designed to help organizations with fewer than 1, employees assess weaknesses in their current IT security environment.
Systems Management Server 2. UrlScan 2. To provide in-depth defense or multiple layers of protection against attackers, URLscan, with customized templates for each supported server role, has been integrated into the IIS Lockdown Tool. Patch management mitigates and lessens the impact from threats in the Window of Exposure Microsoft recommends you implement a process for managing and distributing security updates within your organization.
Patch Management: Assess Inventory existing computing assets. Assess security threats and vulnerabilities. Determine the best source for information about new software updates.
Assess the existing software distribution infrastructure. Assess operational effectiveness. The goal for the Identify phase is to: Discover new software updates in a reliable way. Determine whether software updates are relevant to your production environment. Obtain software update source files and confirm that they are safe and will install successfully. Determine whether the software update should be considered a normal change or an emergency, and submit a request for change RFC to deploy it.
Details about all files in the patch File version File checksum File location Registry key applied by the patch. Patch Superseding information Microsoft security risk self assessment tool Interviews user about security policy and operations Compares scores obtained in assessment to industry averages Creates two assessment reports: Business Risk Profile-assesses risks a company in your industry faces Risk Assessment-rates your companys risk and security practices as compared to industry averages Uploads results to common database for industry comparison Always get approval of management before running assessment Consider potential side effects of running assessment tool, which may cause computer lockouts and network bandwidth problems, on production computers during business hours Run on regularly scheduled basis.
Use comparative results between assessments as an empirical measurement of improving security policies and procedures Never run without first alerting end-users Open navigation menu. Close suggestions Search Search. User Settings.
0コメント