PCI Requirement 2.2.3 – Implement Additional Security Features
by Randy Bartels / June 30th, 2017
Why Your Organization Needs To Implement Additional Security Features
Under PCI Requirement 2, which focuses on hardening your organization’s systems and assets, we find PCI Requirement 2.2.3. PCI Requirement 2 is not just about your servers, it’s about any asset within your environment. PCI Requirement 2.2.3 is also about all types of assets within your environment. PCI Requirement 2.2.3 instructs, “Implement additional security features for any required services, protocols, or daemons that are considered to be insecure.”
There may be situations when your organization needs to use something that is considered insecure, like an application, service, or protocol. In these situations, the PCI DSS does not prohibit you from running these things, but you must implement additional security features to render these risky applications, services, etc. safe to use.
PCI Requirement 2.2.3 exists to make it harder for malicious individuals to enter your network. Implementing additional security features to risky or insecure services, protocols, or daemons makes it a challenge for hackers to take advantage of commonly used points of compromise within a network. PCI Requirement 2.2.3 recommends that organizations implement additional security features before a new server is deployed in order to prevent servers being installed into the environment with insecure configurations.
In order to help your organization comply with PCI Requirement 2.2.3, an assessor may ask for a copy of your Nmap or run an Nmap scan to determine what the open ports are within your environment and which services are running. This list of open ports and running services will be compared to your hardening standards and configuration guidelines. If an assessor identifies something as risky, they need to see appropriate documentation that explains your additional security features and how they make risky services safe. Then, they will verify that those security features are actually implemented within your environment, not just documented.
It’s important to note that if SSL/early TLS is being used, the testing procedures outlined in Appendix A2: Additional PCI DSS Requirements for Entities using SSL/Early TLS need to be performed.
To find industry standards and best practices for implementing additional security features, strong cryptography, and identifying services, protocols, and daemons as risky or secure, look at NIST SP 800-52, SP 800-57, OWASP, etc.
PCI DSS Requirement 2.2.3
From the hardening perspective, there might be situations where your organization has to use an application that might be insecure, or use a protocol, service, or something that might be considered insecure. To give an example, years ago we used TLS 1.0. You might have Legacy applications that will only run on a TLS 1.0 protocol. In these situations, the PCI DSS does not prohibit you from running these protocols, ports, and services. But what it does say, is that if you’re going to be running these risky protocols, ports, and services, that you have to implement other security features or other security measures to render these risky protocols, ports, and services as un-risky.
So as an assessor, we’re likely going to be asking you for a copy of your Nmap or run an Nmap scan within your environment. This will let us know: what are the open ports? What are these services running? Once we get this list, we’re going to want to marry this up to your hardening standards and configuration guidelines to see why you have these things open, what’s running. We’re going to look at the running services on the boxes. If we identify that something is risky, we’re then going to look for what you’ve documented; you’re required to document about these security features. So we’re going to look at what you’ve done from a documentation perspective, in terms of rendering these particular protocols, ports, and services un-risky. Once we’ve identified what you’ve done from a risk perspective, we’re going to actually look to see that those particular things that you’ve documented have been implemented within your environment.
