Requirement 2: Apply Secure Configurations

Malicious individuals, both external and internal to an entity, often use default passwords and other vendor default settings to compromise systems. These passwords and settings are well known and are easily determined via public information. Applying secure configurations to system components reduces the means available to an attacker to compromise the system. Changing default passwords, removing unnecessary software, functions, and accounts, and disabling or removing unnecessary services all help to reduce the potential attack surface.

Requirement 2: Apply Secure Configurations

2.1 Processes And Mechanisms For Applying Secure Configurations To All System Components Are Defined And Understood

2.1.1 All security policies and operational procedures are: • Documented • Kept up to date • In use • Known to all affected parties

It is important to update policies and procedures as needed to address changes in processes, technologies, and business objectives. For this reason, consider updating these documents as soon as possible after a change occurs and not only on a periodic cycle.

2.1.2 Roles and responsibilities for performing activities are documented, assigned, and understood

Roles and responsibilities may be documented within policies and procedures or maintained within separate documents.

As part of communicating roles and responsibilities, entities can consider having personnel acknowledge their acceptance and understanding of their assigned roles and responsibilities.

2.2 System Components Are Configured And Managed Securely

2.2.1 Configuration standards are developed, implemented, and maintained to: • Cover all system components • Address all known security vulnerabilities • Be consistent with industry-accepted system hardening standards or vendor hardening recommendations • Be updated as new vulnerability issues are identified • Be applied when new systems are configured and verified as in place before or immediately after a system component is connected to a production environment

Keeping up to date with current industry guidance will help the entity maintain secure configurations.

The specific controls to be applied to a system will vary and should be appropriate for the type and function of the system.

Numerous security organizations have established system-hardening guidelines and recommendations, which advise how to correct common, known weaknesses.

2.2.2 Vendor default accounts are managed as follows: • If the vendor default account(s) will be used, the default password is changed • If the vendor default account(s) will not be used, the account is removed or disabled

All vendor default accounts should be identified, and their purpose and use understood. It is important to establish controls for application and system accounts, including those used to deploy and maintain cloud services so that they do not use default passwords and are not usable by unauthorized individuals.

Where a default account is not intended to be used, changing the default password to a unique password, removing any access to the default account, and then disabling the account, will prevent a malicious individual from re-enabling the account and gaining access with the default password.

Using an isolated staging network to install and configure new systems is recommended and can also be used to confirm that default credentials have not been introduced into production environments.

2.2.3 Primary functions requiring different security levels are managed as follows: • Only one primary function exists on a system component, OR • Primary functions with differing security levels that exist on the same system component are isolated from each other, OR • Primary functions with differing security levels on the same system component are all secured to the level required by the function with the highest security need

Ideally, each function should be placed on different system components. This can be achieved by implementing only one primary function on each system component. Another option is to isolate primary functions on the same system component that have different security levels, for example, isolating web servers (which need to be directly connected to the Internet) from application and database servers.

If a system component contains primary functions that need different security levels, a third option is to implement additional controls to ensure that the resultant security level of the primary function(s) with higher security needs is not reduced by the presence of the lower security primary functions. Additionally, the functions with a lower security level should be isolated and/or secured to ensure they cannot access or affect the resources of another system function, and do not introduce security weaknesses to other functions on the same server.

Functions of differing security levels may be isolated by either physical or logical controls. For example, a database system should not also be hosting web services unless using controls like virtualization technologies to isolate and contain the functions into separate sub-systems. Another example is using virtual instances or providing dedicated memory access by system function. Where virtualization technologies are used, the security levels should be identified and managed for each virtual component. Examples of considerations for virtualized environments include:

The function of each application, container, or virtual server instance.

How virtual machines (VMs) or containers are stored and secured.

2.2.4 Only necessary services, protocols, daemons, and functions are enabled, and all unnecessary functionality is removed or disabled

There are many protocols that could be enabled by default that are commonly used by malicious individuals to compromise a network. Disabling or removing all services, functions, and protocols that are not used minimizes the potential attack surface for example, by removing or disabling an unused FTP or web server.

2.2.5 If any insecure services, protocols, or daemons are present: • Business justification is documented • Additional security features are documented and implemented that reduce the risk of using insecure services, protocols, or daemons

Enabling security features before new system components are deployed will prevent insecure configurations from being introduced into the environment. Some vendor solutions may provide additional security functions to assist with securing an insecure process.

2.2.6 System security parameters are configured to prevent misuse

System configuration standards and related processes should specifically address security settings and parameters that have known security implications for each type of system in use.

For systems to be configured securely, personnel responsible for configuration and/or administering systems should be knowledgeable in the specific security parameters and settings that apply to the system. Considerations should also include secure settings for parameters used to access cloud portals.

2.2.7 All non-console administrative access is encrypted using strong cryptography

Whichever security protocol is used, it should be configured to use only secure versions and configurations to prevent use of an insecure connection for example, by using only trusted certificates, supporting only strong encryption, and not supporting fallback to weaker, insecure protocols or methods.

2.3 Wireless Environments Are Configured And Managed Securely

2.3.1 For wireless environments connected to the CDE or transmitting account data, all wireless vendor defaults are changed at installation or are confirmed to be secure, including but not limited to: • Default wireless encryption keys • Passwords on wireless access points • SNMP defaults • Any other security-related wireless vendor defaults

If wireless networks are not implemented with sufficient security configurations (including changing default settings), wireless sniffers can eavesdrop on the traffic, easily capture data and passwords, and easily enter and attack the network. Wireless passwords should be constructed so that they are resistant to offline brute force attacks.

2.3.2 For wireless environments connected to the CDE or transmitting account data, wireless encryption keys are changed as follows: • Whenever personnel with knowledge of the key leave the company or the role for which the knowledge was necessary • Whenever a key is suspected of or known to be compromised

This goal can be accomplished in multiple ways, including periodic changes of keys, changing keys via a defined “joiners-movers-leavers” (JML) process, implementing additional technical controls, and not using fixed pre-shared keys.

In addition, any keys that are known to be, or suspected of being, compromised should be managed in accordance with the entity’s incident response plan.

Let’s Understand With An Example

This image is borrowed from the Cybersecurity Labs. Assume it represents your work environment and cardholder data is sitting on the server dz-win10.

Requirement 2.1

It’s all about defining policies and procedures. Then, allocate the responsibilities.

Requirement 2.2

This requirement is broad. It suggests following the industry’s best practices, identifying and fixing known vulnerabilities etc. It suggests if dz-win10 is a web server, then it should act as a web server only. Adding more roles e.g. database server, can increase the attack surface. Also, hosting critical and non-critical apps on the same server will be an overhead, not only in terms of computing but also compliance.

Requirement 2.3

It does not apply to our example but if dz-win10 could be accessed via a wireless network, additional precautions will be required.