Previously, we discussed preparing for the new PCI DSS 4.0 standard and how to wrap your head around the first requirement–network and system security. The following requirement moves on to another critically important aspect of compliance and security–configuration management. 

Here, we’ll break down the concept of configuration management in PCI DSS and how this is spelled out in the Second Requirement.

What Are Security Configurations, and Why Are They So Important for PCI DSS?

Security configurations are, simply put, the settings, patches, upgrades and settings that an IT system, hardware device, or software package has in place to control their operations. In terms of security and compliance, these are more accurately ascribed to the controls relevant to protecting and facilitating data flows. 

As such, configurations can apply to the following categories:

• Technical Configurations: All technology comes, in part or whole, with default configurations that help users and administrators get it up and running. Default admin accounts, port access, API exposure, etc., are all set with factory defaults that an organization will almost invariably need to adjust based on their business and regulatory needs. 
• Inventories: Data moves through networks of devices and will touch several different resources as it moves from one point to another. As such, configurations are critical not simply to harden isolated pieces of technology but long interacting chains of data systems. Configuration settings will rely on resource inventories to place them within a specific context. 
• Policies: Configuration management is, at an enterprise level, a strategic endeavor that takes planning, goal-setting, and follow-through. As such, a business or other organization must have top-down-level policies in place to support such efforts. 
• People: At any stage, people must plan, implement, and manage configuration settings. Furthermore, configuration settings will dramatically affect how people work and interact with technology, including the security threat they can pose as they interact with data. 

What Are Common Threats Emerging from Improper Configuration Management?

With all of these moving pieces in place, all with their own settings and interactivity, it’s obvious that a poorly managed or mismanaged configuration policy will introduce potential security hazards into your organization. 

Some of the common issues that come from a lack of proper configuration management include:

• Default Settings: All systems come with default settings, and in many cases, these default settings are well-known to technicians and administrators. The problem is whether a hacker or inside threat should discover these default settings. They can use them to exploit a system. A typical example is using default passwords for admin accounts to aid easy setup–these are useful for developers and engineers implementing a system. Still, if they aren’t changed, they provide attackers with an open backdoor to the system with elevated privileges. 
• Insecure Ports or APIs: Many pieces of software come with default API and port connections in place to support interoperability with common systems–connections that will most likely change during implementation. However, insecure ports left open during that change provide yet another attack surface for hackers who know the system and its default settings. 
• Vulnerabilities: As malicious software evolves, so too must patches and configuration settings. Without regular upkeep and maintenance, including response to official bugs and vulnerability notices, improperly managed configuration standards can open holes in a system.

Because these vulnerabilities can be so severe and pervasive, PCI DSS 4.0 requires companies to implement proper configuration management controls. 

What Is the Second Requirement for PCI DSS 4.0?

The second requirement is all about configuration management and how companies implement them. Malicious attackers often use default configuration standards, or poorly configured systems, to gain access.

2.1 – Processes and Mechanisms for Applying Security Configurations

• Documentation: As with most requirements, your organization must have proper documentation for all configuration management processes, including updated policies and procedures.
• Roles and Responsibilities: Additionally, the documented configuration management process must have clear definitions of roles and responsibilities.

2.2 – System Component Configuration and Management

• System-Wide Configuration Standards: Configuration standards must apply to all system components, address all vulnerabilities, comply with industry hardening standards, and undergo regular updates when systems are introduced, upgraded, or when new vulnerabilities are identified.
• Prevention of Misuse: All systems must be adequately configured (that is, you should be able to vet the people and procedures used to implement security parameters and that these parameters are consistent with configuration settings). 
• Encryption: Any administration access to a system from a remote or non-local workspace must be done through acceptable strong cryptography. 
• Vendor Defaults: All vendor default passwords must be changed and adhere to PCI DSS authentication requirements. Furthermore, if the account isn’t used, it must be removed. 
• System Function Isolation: Systems with different functions, protocols, and services include profiles for each type of function, and systems without overlapping parts (i.e., either connecting or not connecting to the public Internet) should be isolated so that one function does not undermine the security of the other. 
• Unnecessary Services: Any unnecessary service or protocol is disabled or removed entirely. 
• Risk and Security: If any insecure features remain, then there must be a risk and business justification for that remaining feature.
  

2.3 – Wireless Environment Configuration and Management

• Vendors and Default Configurations: If you use wireless devices to access secure environments, all requirements for managing vendor configuration defaults are followed through on those devices, including in applications and hardware settings. 
• Encryption Keys and Key Management: Anyone using mobile devices with encryption must surrender those devices on termination or compromise of the device, and those keys should be changed throughout the system.

Get Moving on PCI DSS 4.0 with Lazarus Alliance

As we dig into the requirements of PCI DSS, you will see the increasing complexity and interoperability of the different technologies, policies, and practices you’ll need to deploy to receive PCI verification and maintain compliance. These practices aren’t just to complete a checklist. However–they are tried-and-true security practices that will help support your security efforts ten years from now.

Are You Thinking Ahead for PCI DSS 4.0?

Call Lazarus Alliance at 1-888-896-7580 or fill in this form.