Merchants must “address all known security vulnerabilities and [be] consistent with industry-accepted system hardening standards.”
One of the most confusing Payment Card Industry Data Security Standard (PCI DSS) requirements is Requirement 2.2. It involves system hardening, which ensures system components are strengthened as much as possible before network implementation.
According to the PCI DSS, to comply with Requirement 2.2, merchants must “address all known security vulnerabilities and [be] consistent with industry-accepted system hardening standards.” Common industry-accepted standards that include specific weakness-correcting guidelines are published by the following organizations:
Merchants can use and research other resources as well, such as the following:
System hardening should occur any time you introduce a new system, application, appliance, or any other device into an environment. A hardening process establishes a baseline of system functionality and security.
The goal of hardening a system is to remove any unnecessary functionality and to configure what is left in a secure manner. Every application, service, driver, feature, and setting installed or enabled on a system can introduce vulnerabilities.
Once a system is hardened and deployed into an environment, it’s critical to maintain its level of security through proactively updating or patching it to mitigate new vulnerabilities and weaknesses that are discovered. The hardening process should then be updated to include these new patches or software versions in the baseline configuration, so that the next time a similar system is deployed, old vulnerabilities are not re-introduced into your environment.
There are five steps you should follow to comply with PCI 2.2, which can more easily be understood through the analogy of building and protecting a home.
Fences, gates, and other such layers may protect your home on the outside, but system hardening is the act of making the home itself (the bricks, siding, doors, and everything inside) as strong as possible.
Many falsely believe firewalls and data security software layers are enough to protect systems and to comply with system hardening requirements. In reality, system hardening is all about locking, protecting, and strengthening components of the actual system, not protecting it by adding new security software and hardware.
Plenty of system administrators have never thought about system hardening. They probably think, ”We just installed our system . . . why would it have a problem already?”
Say you hire a builder to construct a home. Would you assume your homebuilder changes the locks on every home he builds? What if he installs the same lock on every home because he assumes you’ll rekey it once you move in?
In the same way you shouldn’t rely 100% on your builder to secure your home, you shouldn’t expect your system to be 100% secure when you pull it out of the box. Windows, Linux, and other operating systems don’t come pre-hardened. It’s your job to figure out how to make them safe, and it’s going to take work on your part.
A lot of merchants assume system hardening is part of a POS installer’s job. Most of the time, it’s not. If the installer does take on that responsibility, they’re probably not doing it correctly because they don’t understand the PCI DSS.
When installing a new POS system, the PCI Council recommends hiring a PCI DSS Qualified Integrated Reseller (QIR) because they’ve gone through training to understand system hardening and other PCI DSS qualifications.
See also: Recording Your QIR: SecurityMetrics’ New QIR Feature
Unless you’re a homebuilder or architect, there are likely aspects about safe home construction you don’t understand. Luckily, builders rely on industry-accepted guidelines when building, and understand how to prevent common structural weaknesses.
For example, the home design you choose may have lots of windows, which may weaken the structure. Builders have guidelines on how to correctly frame out windows to ensure they won’t be a point of weakness.
Similarly, there are guidelines created by organizations (see above bullet points) that help system administrators understand the common holes in operating systems and environments they want to integrate.
Available online, these comprehensive instructions outline the most critical steps to secure your system from attacks. The guidelines usually list vulnerability descriptions, procedures to remediate vulnerabilities, online references to learn more about the vulnerability, and other specific configurations on how to harden that particular part of the system.
If I built a home, I might want a three-car garage and five extra windows upstairs. You may wish to replace standard lighting with grand chandeliers and add a giant front door instead.
Just as each home is different, each system environment is modified to fit your organization’s specific needs. You may want to run a specific OS version, a newer web server, or use a free database application.
Because every environment is unique, there usually isn’t a simple how-to document that fits your specific needs. This means system hardening, and compliance with Requirement 2.2, will require a fair amount of research and discovery time on your part.
You must spend the time researching and finding guidelines that pertain to each specific part of your environment, and then combine the applicable pieces to form your own standard.
Everyone knows that building a home is hard work. There are lots of details to worry about, it takes months (sometimes years), and not everything goes exactly as planned.
Similarly, hardening your systems takes a lot of detailed work and tweaking. For example, some guidelines can require you to:
Most guidelines also involve changing or turning off default settings and removing unnecessary features or applications. For example, HP computers used to come with customer service software preinstalled that automatically reported all events back to headquarters. I’m sure you can imagine the security implications of this, which is why security guidelines for HP computers recommended removing it from the system entirely.
It’s important to perform testing throughout the hardening process to ensure business-critical or required functionality isn’t impacted.
Here are some key examples from the PCI DSS that state specifically how you’re supposed to harden your systems. Pay attention to these two examples, as they are common PCI 2.2 compliance problems:
It is common in many small retail chains I’ve audited to have web browsing, email, and Microsoft Office capabilities available on the same back-office workstation running their POS server. This is not compliant with PCI 2.2! By integrating a POS server with a workstation used for day-to-day operations, these merchants put uncontrolled functions on the same server as their most secret and important cardholder data.
If this sounds like your business, reconfigure your network to separate these functions. (You may find it useful to read a bit more about network segmentation.)
This portion of Requirement 2.2 is kind of like preparing a race car. To race, only items that make the car go fast are needed. Backseats, radio, and anything else that adds weight to the car is stripped.
By ensuring only necessary services, protocols, and applications are enabled, a business reduces the risk of an attacker compromising a vulnerability to get into a system.
An easy way to remove unnecessary functionality is by going through each running service in a system’s task manager and asking, “Do I really need this?” If not, disable it. A lot of tasks running on your system are required for the system to function, but don’t ever assume. If you don’t recognize it, look it up!
If you changed some things on your original house blueprint, and 10 years down the road want to remodel, the best way to remember exactly what you did is to refer to the changes on the blueprint. It’s going to be risky to knock out that kitchen wall if your remodeler doesn’t have correct information from the blueprint telling him or her what is inside the wall.
Documentation is key to system hardening. It’s important to keep track of why you chose certain hardening standards and the hardening checklists you’ve completed.
Here are three reasons why:
Once you document and establish your configuration hardening standard be sure that it is not a static document. It should be reviewed annually for needed changes and updated as methods of compromising systems develop. Criminals are constantly finding new ways to exploit vulnerabilities. They have developed tools to quickly check and automatically exploit old vulnerabilities. It is shocking that I still run into systems that are not being patched on a regular basis. This is plain system administrator negligence and is similar to leaving the keys in your brand-new Ferrari and inviting thieves to take a test drive. Not hardening systems makes you an easy target increasing your risk for a system breach.
There is no easy button for the PCI DSS, and especially for PCI Requirement 2.2. There aren’t magic tools to harden your system automatically. There is no master checklist that applies to every system or application out there. Creating an effective hardening standard can be a research-heavy project. Luckily, there is a lot of information available in the form of industry-standard guidelines that can help you know where to start.
The time and resources involved in system hardening are well-spent. Creating and applying appropriate hardening standards in your environment will go a long way toward securing the data that is so critical to your business.
If you need assistance with system hardening, I recommend talking to IT security consultants who are well equipped with both PCI DSS experience and IT proficiency.
.svg)
