NIST announced the publication of Initial Public Draft Special Publication 800-128, Guide for Security Configuration Management of Information Systems.

Configuration management remains a challenging issue especially for small and mid-size organizations.  With the complex dependencies of modern applications a modification to an organization browser, a security patch of the operating system, and even hard-ware upgrades can introduce incompatibilities or security vulnerabilities into your organization’s information system. Today NIST announced the publication of Initial Public Draft Special Publication 800-128, Guide for Security Configuration Management of Information Systems. This publication provides guidelines for managing the configuration of information system architectures and associated components for secure processing, storing, and transmitting of information.  Security configuration management is an important function for establishing and maintaining secure information system configurations, and provides important support for managing organizational risks in information systems.  This publication beyond providing an excellent resource includes two invaluable appendices.

First, the SP 800-128 includes a sample of the data elements that should be tracked for a change request:

• Date Prepared;
• Title of Change Request;
• Change Initiator/Project Manager;
• Change Description;
• Change Justification;
• Urgency of Change: {Scheduled/Urgent/Unscheduled};
• Personnel involved with the Change;
• Expected Security Impact of Change;
• Expected Functional Impact of Change;
• Expected Impact of Not Doing Change;
• Potential Interface/Integration Issues;
• Required Changes to Existing Applications;
• Project work plan including change implementation date, deliverables, and back-out plan; and
• Funding Required Implementing Change.

Appendix F to SP 800-128, entitled BEST PRACTICES FOR ESTABLISHING SECURE CONFIGURATIONS provides very specific industry guidance on good security configuration management practices. (the following is largely a reproduction of Appendix F, however, I have summarized what I consider to be the most significant issues and removed duplicative references to some NIST Publications.  Some personal commentary appears in red below.

Use Standards for Secure Configuration Settings. Organizations should consider available standards as the basis for establishing secure configuration settings. A source for information on configuration settings is the National Checklist Program.

• NIST SP 800-68: Guide to Securing Microsoft Windows XP Systems for IT Professionals;
• NIST SP 800-69: Guidance for Securing Microsoft Windows XP Home Edition: A NIST Security Configuration Checklist; and
• NIST SP 800-70: National Checklist Program for IT Products-Guidelines for Checklist Users and Developers.

Centralize Policy and Standards for Configuration Settings. Where possible and appropriate, secure configurations should be developed and implemented in a top-down approach to ensure consistency across the organization. An example is the implementation of the group policy functionality, which can be used to distribute secure configuration policy in a centralized manner throughout established domains.

Tailor Secure Configurations According to System/Component Function and Role. Secure configuration settings should be tailored to the system component’s function. For example, a server acting as a Windows domain controller may require stricter auditing requirements (e.g., auditing successful and unsuccessful account logons) than a file server. A public access Web server in a DMZ may require that fewer services are running than in a Web server behind an organization’s firewall supporting an intranet.

• NIST SP 800-41: Guidelines on Firewalls and Firewall Policy (Consumer grade network routerts and wireless routers can be significant improved by using DD-WRT.  “DD-WRT is a Linux based alternative OpenSource firmware suitable for a great variety of WLAN routers and embedded systems.” (See http://www.dd-wrt.com/site/index.) ;
• NIST SP 800-44: Guidelines on Securing Public Web Servers;
• NIST SP 800-45: Guidelines on Electronic Mail Security;
• NIST SP 800-48: Guide to Securing Legacy IEEE 802.11 Wireless Networks (I would avoid having a wireless network connected to a e-PHI system if possible);
• NIST SP 800-52: Guidelines for the Selection and Use of Transport Layer Security (TLS) Implementations; (Mandatory TLS encryption is still difficult to implement, most organizations are not in a position to support this functionality on their email solution);
• NIST SP 800-95: Guide to Secure Web Services;
• NIST SP 800-123: Guide to General Server Security; and
• NIST SP 800-124: Guidelines on Cell Phone and PDA Security. (Consumer grade cell phones, PDAs, and blackberries have a number of security configurations available (e.g. timeout, password protection, etc.) that can help to secure these devices).

Eliminate Unnecessary Ports, Services, and Protocols (Least Functionality). Devices should be configured to allow only the necessary ports, protocols, and services in accordance with functional needs and the risk tolerance in the organization. Open ports and available protocols and services are an inviting target for attackers, especially if there are known vulnerabilities associated with a given port, protocol, or service. Sources such as the NIST National Vulnerability Database (NVD) are available for highlighting vulnerabilities in various system components.

Limit the Use of Remote Connections. While connecting remotely to information systems allows more flexibility in how users and system administrators accomplish their work, it also opens an avenue of attack popular with hackers. Use of remote connections should be limited to only those absolutely necessary for mission accomplishment.

• NIST SP 800-46: Guide to Enterprise Telework and Remote Access Security;
• NIST SP 800-47: Security Guide for Interconnecting Information Technology Systems; and
• NIST SP 800-77: Guide to IPsec VPNs.

Develop Strong Password Policies. Passwords are a common mechanism for authenticating the identity of users and if they are poorly implemented or used, an attacker can undermine the best security configuration. Organizations should stipulate password policies and related requirements with the strength appropriate for protecting access to the organization’s assets.

Implement Endpoint Protection Platforms (EPPs). Personal computers are a fundamental part of any organization’s information system. They are an important source of connecting end users to networks and information systems, and are also a major source of vulnerabilities and a frequent target of attackers looking to penetrate a network. User behavior is difficult to control and hard to predict, and user actions, whether it is clicking on a link that executes malware or changing a security setting to improve the usability of their PC, frequently allow exploitation of vulnerabilities. Commercial vendors offer a variety of products to improve security at the “endpoints” of a network. These EPPs include:

• Anti-malware. Anti-malware applications should be a part of the standard secure configuration for system components. Anti-malware software employs a wide range of signatures and detection schemes, automatically updates signatures, disallows modification by users, run scans on a frequently scheduled basis, have an auto-protect feature set to scan automatically when a user action is performed (e.g., opening or copying a file), and may provide protection from zero-day attacks. For platforms for which anti-malware software is not available, other forms of anti-malware such as rootkit detectors may be employed.
• Personal Firewalls. Personal firewalls provide a wide range of protection for host machines including restriction on ports and services, control against malicious programs executing on the host, control of removable devices such as USB devices, and auditing and logging capability.
• Host-based Intrusion Detection and Prevention System.  Host-based IDPS is an application that monitors the characteristics of a single host and the events occurring within that host to identify and stop suspicious activity.
• Restrict the use of mobile code. Organizations should be cautious in allowing the use of “mobile code” such as ActiveX, Java, and JavaScript. An attacker can easily attach a script to a URL in a Web page or email that, when clicked, will execute malicious code within the computer’s browser.

NIST SP 800-28: Guidelines on Active Content and Mobile Code.

Use Cryptography.  In many systems, especially those processing, storing, or transmitting information that is moderate impact or higher for confidentiality, cryptography should be considered as a part of an information system’s secure configuration. There are a variety of places to implement cryptography to protect data including individual file encryption, full disk encryption, Virtual Private Network connections, etc.

NIST SP 800-111: Guide to Storage Encryption Technologies for End User Devices.

Develop a Patch Management Process. A robust patch management process is important in reducing vulnerabilities in an information system. As patches greatly impact the secure configuration of an information system, the patch management process should be integrated into SCM at a number of points within the four SCM phases including:

• Performing security impact analysis of patches;
• Testing and approving patches as part of the configuration change control process;
• Updating baseline configurations to include current patch level;
• Assessing patches to ensure they were implemented properly; and
• Monitoring systems/components for current patch status.

NIST SP 800-40: Creating a Patch and Vulnerability Program.

Control Software Installation. The installation of software is a point where many vulnerabilities are introduced into an organization’s information system. Malware or insecure software can give attackers easy accessto an organization’s otherwise tightly protected network. Although the simplest approach is to lock down computers and manage software installation centrally, this is not always a viable option in many organizations. Other methods for controlling the installation of software include:

• Whitelisting – All software is checked against a list approved by the organization;
• Checksums – All software is checked to make sure the code has not changed;
• Certificate – Only software with signed certificates from a trusted vendor is used;
• Path or domain – Only software within a directory or domain can be installed; and
• File extension – Software with certain file extensions such as .bat cannot be installed.

Related Blogs

• The Internet Public Libraray With a Useful Guide to Photo Sharing …
• PREPRINT: Free Access: “Use of Web Resources in the Journal …
• Israel's Policy and the idea of A One State solution
• Researchers Map Multi-Network Cybercrime Infrastructure — Krebs on …
• Alan Taub Elected Vice Chair of NIST Advisory Group | Japanese …

          

Related posts:

1. Business Associate and Covered Entity HIPAA Compliance — Auditing Questions and NIST 800-53 Security Controls. This article discusses techniques for implementing the updated requirements of...
2. Evaluating Secutiy Incidents — Security Incident DOs and DON’Ts Security Incidents can be accidental incursions or deliberate attempts to...
3. Key Issues in Privacy and Security for 2010 Next year should be interesting. From Red Flag compliance, federal...
4. NIST Approves XTS-AES for Secure Encryption of Block Devices: TrueCrypt Meets FIPS 140-2 Standard Thus Becoming a HHS Approved Algorithom for Securing PHI NIST approved XTS-AES for the secure encryption of block devices...