System Hardening Standards: How to Comply with PCI Requirement 2.2
Five key steps to understand the system hardening requirement.
 |
| By: David Page |
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:
- Center for Internet Security (CIS)
- International Organization for Standardization (ISO)
- SysAdmin, Audit, Network, and Security (SANS) Institute
- National Institute of Standards and Technology (NIST)
System Hardening (PCI 2.2) Vs. Patching (PCI 6.2)
System hardening is not the same as software patching, though the two processes complement each other.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.
TweetThe 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.
5 Steps to Comply With PCI Requirement 2.2
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.
1) Understand you’re not safe right out of the box
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
2) Get help
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.
3) Prepare for research
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.
4. Harden your systems
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:
- Disable a certain port
- Stop a service
- Remove a feature of the OS
- Uninstall software
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:
Example 1: Ensure servers don’t have more than one primary function
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.)
Example 2: Remove unnecessary services and functionality
This portion of Requirement 2.2 is kind of like preparing a racecar. 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!
5. Document your hardened systems
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:
- PCI auditors: After you ensure all system hardening guidelines are met, you may be asked to convince others (PCI auditors) that you did a good job. Your auditor wants to know and see that you did your research, and have applied appropriate settings for each system.
- New hires: If you leave a company, how will the new IT director know exactly what you did to harden the organization’s systems? Documentation helps drop the breadcrumbs for replacements to understand what’s already been done with the system.
- Yourself: If you decide to change an aspect of your environment and already have the documentation for existing systems, you’ve cut out hours of time-consuming research.
There’s No Easy Button
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.
David Page is a Qualified Security Assessor and has been working at SecurityMetrics for 2 and a half years. He has over 18 years experience in network and system engineering, design, and security.
