PCI DSS Requirement 2.2 is one of the stringent requirements of the Payment Card Industry Data Security Standard (PCI DSS). PCI requirement 2.2 requires the system to be hardened by ensuring that system elements are reinforced as much as possible before joining the network.
The default operating systems and application configurations were created for the ease of use and ease of deploying a system, not for security purposes. Such a system, when used as supplied, leaves your entire infrastructure vulnerable. Strengthening the operating system and applications is an essential requirement in the corporate security posture.
The process of system hardening requires changes to default configurations according to industry standards.
The purpose of system hardening is to further protect your organization by reducing vulnerabilities in your applications, systems, and information technology infrastructure. By doing system hardening, you create fewer opportunities for malicious attacks because you remove unnecessary programs, applications, and access points that compromise your system’s security.
PCI DSS Requirement 2 is for your systems’ security and includes items such as passwords, configuration settings, and hardening of the system. Below you can find the control items you must comply with to comply with PCI DSS Requirement 2.
What Are System Hardening Standards for PCI DSS and What Can Be Applied?
System hardening means you remove all unnecessary features from your system and securely configure the rest. Any program, device, driver, function, and configuration installed on a system potentially create security holes.
To comply with PCI DSS requirement 2.2, merchants must fix all identified vulnerabilities and comply with well-known hardening practices. The following organizations publish common industry-accepted standards that contain clear hardening guidelines:
- Center for Internet Security (CIS)
- International Organization for Standardization (ISO)
- SysAdmin, Audit, Network, and Security (SANS) Institute
- National Institute of Standards and Technology (NIST)
You can also use and review other resources such as:
- Information Assurance Support Environment (IASE)
- Vendor hardening guides
For all parts of your ever-changing systems, you want to prevent attacks and vulnerabilities as much as you can. Hardening your network, servers, applications, database, and operating systems is an excellent start to meeting industry-accepted configuration standards. Your retrofit standards will change as your systems and technology differ.
You can focus on developing standards to apply system hardening steps to the following key components:
- Network Hardening
- Firewall configuration
- Regular network inspection
- Limit users and secure access points
- Block unnecessary network ports
- Deny anonymous access
- Server Hardening
- Administrative access and rights are correctly allocated.
- Protect your data center where servers are located
- Deny shutdown without logging in
- Application Hardening
- Application access control
- Remove default passwords
- Implement the best password practices
- Configure account lockout policy
- Database Hardening
- Implement administrator restrictions on access
- Encrypt data entering and leaving the database
- Remove unused accounts
- Operating System Hardening
- Automatically apply necessary updates and patches.
- Remove unnecessary files, libraries, drivers, and functions.
- Log all events, errors, and warnings.
- Limit sharing and system permissions
- Configure file system and registry permissions
Implementing these system hardening techniques is by no means a comprehensive security approach. Still, it is an excellent start to getting your organization moving in the right direction for a more secure information security program. By combining the right tools and techniques, you can prepare yourself for security success.
What are the Differences between System Hardening and System Patching?
When a new system, program, device, or any other appliance is installed in an environment, system hardening must be applied. The system hardening process provides a standard for device functionality and security.
The purpose of hardening a system is to remove all unnecessary features and securely configure the rest. Vulnerabilities can be exposed by any program, device, driver, function, and setting installed or allowed on a system. If you remove more features that you do not use or are not required on your systems, you will consolidate that much.
See Also: Patching for Complying with PCI DSS Requirement 6
When a device is hardened and added to an environment, it is essential to maintain its security level by proactively upgrading or patching to reduce any new vulnerabilities and bugs.
The system hardening process will then be modified to merge these new patches or software updates into the default installation. Old vulnerabilities are not reintroduced the next time a similar program is implemented.
Patch management should only be part of your general vulnerability program. Your program should also include AV, FIM, and logging reviews, defined policies and procedures, tools to identify missing patches or vulnerabilities, and sufficiently trained personnel to address identified issues. You should also keep in mind that the patching is not just about your workstation or servers.
What is System Configuration Management?
Consistency is paramount when it comes to providing a secure environment. Once the system hardening requirements are determined, they must be applied equally to all systems in the environment. When you properly configure every system or computer in the environment, you are not finished.
Many companies, as new hardware or technologies are added to the system, fail to retain standards over time. That’s why you should keep an up-to-date inventory of all types of equipment, applications, and software used on your CDE. It’s not a good and useful list when your inventory list is out of date and doesn’t represent the truth.
Ensure someone is responsible for keeping the inventory up to date and focusing on what’s in use. Applications or systems not approved for use in the CDE can be discovered and used in this way.
See Also: Change Control Management for PCI DSS
Many companies use one of the many systems management software packages available on the market to collect and maintain device inventory. Systems management software searches and reports hardware and software used in a network. It can also determine and report when new devices are online.
These tools can often also apply configuration and hardening standards by alerting administrators when a system does not meet your internal hardening standard.
Steps You Can Take to Comply With PCI DSS Requirement 2.2
Some mistakenly believe that firewalls and data protection software layers are sufficient to secure networks and meet system hardening requirements. Compliance hardening is not about securing them by installing new protection software and hardware but about locking, fixing, and reinforcing fundamental system components.
For example, fences, locks, and other similar layers will protect your home from the outside, but hardening the structure is the act of making the house as solid as possible. There are five necessary steps you can take to meet the PCI DSS requirement 2.2:
1. Devices are not secure right out of the box.
Most system administrators often consider hardening up systems a chore, but most systems and devices are not secure right out of the box, or security settings are not applied.
For example, Windows, Linux, and other operating systems are not pre-hardened. It is your responsibility to learn and implement how to keep apps and devices secure.
Most merchants consider it to be part of the vendor’s job to harden the system. Even if your contract with the vendor states that the vendor will do the system hardening work, they probably will not do it properly because they do not understand the PCI DSS.
When you add your devices or applications to the network, you should make sure that hardening work is done. However, system hardening is strategic; many of the tasks require tactical changes for different systems. Finding a similar solution for all environments is also very difficult.
Before you add your devices or apps to the network, you can take the following hardening steps:
- Each server must have one primary function.
- All unnecessary services and applications should be removed.
- Unnecessary accounts should be disabled or deleted.
- Only appropriate updates should be applied.
- Implement auditing.
- Apply the policy of least privilege and need to know.
2. Do the research and get help with system hardening
Each device needs to be modified to suit the specific needs of your organization’s environment. Depending on your environment’s needs, you may want to run a different operating system version for the database, a newer web server, or an open-source application.
Because every environment is different, there is often no precise method of hardening and configuring to suit your specific needs. Environment differences mean that system hardening and compliance with PCI DSS requirement 2.2 by you will take a fair amount of discovery time.
It is best to take the time to research and review the standards for each part of your environment and then put together the appropriate pieces you set to create your hardening standard.
Similarly, various organizations are developing guidelines that help system administrators understand common gaps in the operating systems and environments they want to implement.
These detailed instructions, accessible online, describe the most critical steps in protecting your device from attacks. In general, the guidelines list vulnerability definitions, fix methods, online guides to learn more about the vulnerability, and other detailed settings on how to harden a particular part of the system.
3. Harden your systems
There is a lot to think about system hardening, it usually takes a certain amount of time and effort, and eventually, things may not go exactly as expected. But the truth is that a lot of research and fine-tuning is required to harden the systems.
In basic system hardening, you may need to do the following:
- A specific port may need to be disabled.
- You may need to stop or deactivate a particular service.
- You may need to uninstall a feature of the operating system.
- You may need to uninstall the software you are using.
Most suggestions might include changing or disabling default settings and removing unused features or programs. Testing during the hardening process is essential to ensure that business-critical or required functionality is not compromised.
Some of the primary PCI DSS requirements clearly state how you should strengthen your systems. The controls required for compliance with PCI DSS requirement 2.2 are as follows:
Ensure that servers do not have more than one primary role or function: Servers with more than one primary role are not compliant with PCI DSS requirement 2.2. You need to make sure that your systems only have one primary function per server.
For example, if your organization has a server in the application tier, it should not be a different application at the same server’s data tier. Combining a POS system with a workstation used for daily operations means placing disorganized functions on the same server with the most confidential and essential cardholder data.
The reason for requiring only one primary function per server is to avoid vulnerabilities if one layer of security is compromised and everything else at that layer becomes vulnerable. Therefore, you need to make sure that one layer does not pose a risk to the other.
PCI DSS indicates that if server functions that need different security levels are located on the same server, the security level of tasks with higher security needs will decrease due to lower security functions.
Also, server functions with a lower security level can introduce security weaknesses to other functions on the same server. You should ensure that functions requiring different security levels do not coexist on the same server by considering the security requirements of varying server functions as part of system configuration specifications and related processes.
In summary, to be compliant with PCI Requirement 2.2.1, security layers must be separated, and servers should not have more than one primary role. You may also need to reconfigure your network to isolate different functions. It should not be forgotten that the same distinction should be applied to virtualization technologies.
Remove unnecessary services and features from your systems: PCI DSS Requirement 2.2 requires you to remove unnecessary services and servers’ features. Removing unnecessary services and features will lower the attack surface.
By allowing only appropriate services, protocols, and applications, you reduce the risk of an attacker exploiting a vulnerability to gain access to your network.
A simple way to eliminate unnecessary functionality is to go through each service running in a program’s task manager and analyze if you need it. If you don’t need service, disable it. It takes many tasks running on your machine for the system to work, but you should examine and evaluate these services.
According to the PCI DSS, you only need to enable the necessary services, protocols, and daemon procedures as required for the system’s function. You should be aware that hackers regularly use some services and protocols to compromise an organization’s network.
PCI Requirement 2.2.5 requires you to remove all unnecessary functions such as scripts, drivers, features, subsystems, file systems, and redundant web servers. Unnecessary functions are another way hackers can gain access to your system, so if a function is not required, it must be turned off.
By removing all unnecessary functions, you can focus on securing essential functions and reduce the risk of misuse of unknown functions. However, to remove unnecessary functionality, you should not only focus on the servers; you must follow the same procedures for protocols, ports, services, applications, and databases.
It is not the job of your PCI QSA to define what is necessary or unnecessary for your business; it is your responsibility. The auditor has to verify that you are doing what you say you are doing to ensure your system’s security. The best way to identify unnecessary functionality is to take a sample of system components and compare them to your configuration and hardening standards.
Change Default Passwords and Configuration Settings: Devices such as firewalls, routers, or POS systems usually come directly with factory settings such as vendor’s default usernames and passwords. Default accounts ensure that each model has the same username and password.
Default passwords and configuration settings are well known to most hacker communities and can be determined simply by searching the Internet. It provides attackers with a simple way to access the network when the default settings are not updated. To protect your data from unauthorized users on any device connected to the CDE, you must disable or change the vendor defaults.
Vendor-provided accounts and passwords pose a severe threat to your organization’s security because it is relatively straightforward for hackers to find vendor-supplied information needed to attack your system and gain unauthorized access. Until installing a device on the network, you must permanently change the vendor-provided defaults and delete or disable unwanted default accounts, according to PCI Requirement 2.1.
All default passwords, accounts, and settings, such as operating systems, security service apps, and payment applications, are covered by PCI Requirement 2.1. To test that you have properly updated vendor-supplied defaults, you should try to log in to a system component instance using vendor-supplied default passwords.
Then you should do the same with unnecessary default accounts to make sure they are removed or disabled. It’s important to remember that even if you don’t intend to use a default account, you will have to change its default password to something unique and then deactivate the account.
This way, you can prevent a hacker from reactivating the default account with the default password and leaving your system vulnerable to an attack.
The default information provided by the vendor is public information. A hacker can also easily find this information. Therefore, it is essential for your organization always to change vendor-provided defaults.
Additionally, PCI Requirement 2.2.3 requires you to implement additional security features for any required services, protocols, or daemon procedures that are considered insecure.
There may be situations where you need to use an application, service, or protocol that is considered insecure. In these cases, PCI DSS will not prevent you from running them, but you must implement additional security features to secure these risky applications or services.
PCI Requirement 2.2.3 exists to make it harder for malicious people to get into your network. Therefore, applying additional security features to risky or insecure services, protocols, or background procedures makes it difficult for hackers to exploit security breach points commonly used within a network.
PCI Requirement 2.2.3 recommends that organizations implement additional security features before a new server is deployed to prevent servers from being installed in an environment with insecure configurations.
To comply with PCI Requirement 2.2.3, you can determine which open ports are in your environment and which services are running by running a Nmap scan. Next, you should compare the open ports and running services you set against your hardening standards and configuration guidelines. Add additional security features to services you identify as risky and document how you secure dangerous services.
Additional security features may be to implement strong cryptography. You can also refer to industry standards and best practices such as NIST SP 800-52, SP 800-57, and OWASP to define services, protocols, and background procedures as risky or secure.
4. Document Your System Hardening Standard
You may need to change your systems again after setting up your system and applying the hardening procedures. The easiest way to know what you are doing before system and infrastructure changes is to consult the documentation. Making changes to your environment can have harmful consequences if you do not have the proper documentation.
Documentation is essential for system and compliance hardening. You must indicate why you have chosen specific hardening standards and the hardening checklists you have completed in the system hardening documentation.
Besides, the documentation will be guiding and informative for PCI auditors, new employees, and your organization. Your PCI auditor (QSA) should learn and see that you are doing your job and applying the appropriate settings for each system component. New employees can review details through documentation to understand the hardening settings used.
The system hardening standard documents you create for your installation are not static and immutable. Because many changes occur in your system over time, therefore, the hardening documentation should be checked periodically for necessary improvements and revised as methods evolve.
Additional tips to consider about PCI DSS requirement 2 and PCI System Hardening
Here are a few things to consider with PCI DSS requirement 2:
- Educate employees on policies: Ensure that employees know policies related to password management and program configuration.
- Update documents consistently: make sure you keep saving your changes, help avoid liability issues, and coordinate your security policies.
- Work with experts: If you are not technically interested, it is helpful to have a specialist to assist you with basic configurations and device hardening.
Hardening systems requires careful and continuous effort, but it pays off in meaningful and positive ways throughout your organization:
- Enhanced system functionality: You get fewer programs and less functionality as a result of hardening systems. This way, you are less at risk of operating problems, misconfigurations, incompatibilities, and compromise.
- Significantly improved security: Through hardening the systems, you get a reduced attack surface, lower risk of data breaches, unauthorized access, system hacking, or malware.
- Simplified compliance and auditability: Hardening systems mean fewer programs in a less complex environment. In this way, the environment is generally more transparent and easier to control.
There is no quick and easy button to fulfill PCI DSS Requirement 2.2. There are no special tools to harden your systems and devices automatically. You can set an efficient hardening standard by creating a research-intensive project. Fortunately, there are many industry-standard guidelines available to help you know where to start.
See Also: What Are The Essential Controls To Ensure The Security Of Databases?
The time and energy spent hardening the system will go a long way towards designing and implementing practical retrofitting standards in your environment and protecting data that is very important to your business.
Enforcing basic configuration and hardening changes on production servers can cause system downtime and application failures. Configuration changes must be carefully tested in laboratory environments before they are put into production.
See Also: What You Should Know About PCI Compliant File Transfer
If you need help with system and compliance hardening, it is recommended that you speak to IT security consultants highly qualified in both PCI DSS expertise and IT skills.
