PCI DSS from a Linux SysAdmin's Perspective

Wednesday, September 08, 2010

Jamie Adams


A cursory glance at the PCI DSS might lead one to believe that the majority of work required to comply with the standard belongs to network, database, and application/middleware administrators as well as software developers.

Of course, every system administrator knows that there is always a great deal of work required by them anytime an application or service is deployed. During my recent review of the PCI DSS v1.2.1 to ensure our Security Blanket modules support the standard, I identified several requirements which will significantly increase a sysadmin's workload.

There is no doubt that the explosion of the Internet has facilitated electronic commerce—changing the way we do business. “E-commerce” consists of the buying and selling of products or services over electronic systems such as the Internet and other computer networks.1 The easy use of credit cards online has further fueled this commerce but requires security controls to protect consumers.

The Payment Card Industry's (PCI) Security Standards Council is an open global forum. Launched in 2006, it is responsible for the development, management, education, and awareness of the PCI Security Standards, including the Data Security Standard (DSS).2

Getting Started

Obviously, the first step is to download the PCI DSS specification. I will save you a little time by directing you to requirement 2.2. This will keep you quite busy while the rest of your team takes care of their parts.

PCI DSS requirement 2.2 states, “Develop configuration standards for all system components. Assure that these standards address all known security vulnerabilities and are consistent with industry-accepted system hardening standards.

The phrase “industry-accepted system hardening standards” should get the gears in your head turning. The test procedure (2.2.a) for this requirement states “Examine the organization’s system configuration standards for all types of system components and verify the system configuration standards are consistent with industry accepted hardening standards—for example, SysAdmin Audit Network Security (SANS), National Institute of Standards Technology (NIST), and Center for Internet Security (CIS).

If you choose to follow the CIS Benchmarks, you will soon discover that you've got a lot of work ahead of you. The Center for Internet Security (CIS) is a non-profit enterprise that helps organizations reduce the risk of business and e-commerce disruptions resulting from inadequate technical security controls. There are many benchmarks including:

  • CIS Red Hat Enterprise Linux 5.0 - 5.1 Benchmark v1.1.2
  • CIS Debian Benchmark v1.0.0
  • CIS SUSE Linux Enterprise Server 9/10 Benchmark v2.0.0
  • CIS Solaris 10 Benchmark v5.0.0

These detailed benchmarks will require you to assess your systems, develop an implementation plan, test applications after you've implemented the controls, and use a back-out plan in case an implemented security control broke an application. Fortunately, this is what Security Blanket does very well. Security Blanket will not only assess your systems but will apply the appropriate changes to your operating system and has a quick undo feature if you find yourself in trouble.

At this point, your fellow administrators might be giggling about the amount of work you just found yourself waist-deep in. If you want to wipe that grin off their face, inform them that CIS has many benchmarks for their world to include:

  • CIS MySQL 4.1/5.0/5.1 Benchmark v1.0.2
  • CIS Oracle Database 11g Benchmark v1.0.1
  • CIS Apache Tomcat Server Benchmark v1.0.0
  • CIS Apache HTTP Server 2.2.x Benchmark v3.0.0
System Minimization

Those of you who follow this blog or have listened to one of my webcasts are probably tired of hearing me chant “If you don't need it, disable it or remove it!” like a mantra. I even posted Minimize Attack Surfaces which describes how to check for system services configured to start during boot.

The Twenty Critical Controls for Effective Cyber Defense: Consensus Audit Guidelines (CAG), Critical Control 13: Limitation & Control of Network Ports, Protocols, and Services is all about reducing your attack surface. Likewise, the PCI DSS has similar requirements:

  • 2.2.2 Disable all unnecessary and insecure services and protocols (services and protocols not directly needed to perform the device’s specified function).
  • 2.2.4 Remove all unnecessary functionality, such as scripts, drivers, features, subsystems, file systems, and unnecessary web servers.
Patch Management

As every system administrator knows, the process of patching or upgrading software to newer versions to address vulnerabilities is a seemingly never ending task. This process however, raises two important questions: (1) Will newer software versions behave differently resulting in broken applications? (2) Will the installation of new software alter previously implemented security controls (i.e., security permissions and related configuration settings)?

PCI DSS requirement 6.1 states, “Ensure that all system components and software have the latest vendor-supplied security patches installed. Install critical security patches within one month of release.” The authors of the DSS recognize the need to sufficiently test your applications with the newer software prior to production deployment—hence, the phrase “...within one month of release.” This should also remind management to provide adequate test systems and resources to facilitate such testing. A few extra servers for testing is much cheaper than downtime or loss of customer confidence.

Detecting configuration changes and correcting deviations is another area which Security Blanket excels. Many existing customers love the fact that Security Blanket brings their systems back into compliancy after applying patches.

Configuration Drift

Throughout the life cycle of every system configurations vary due to new applications, upgraded software, and change in personnel. A more sinister source of change might be a result of system compromise. Regardless of the source of change, you must know that something has changed. A manifestation of system changes may be application malfunctions or performance degradation. Even worse are those changes which have not manifested in anyway—instead attackers are silently mining your customer's data. That's why it is so critical to detect system changes.

One method of detection is described in PCI DSS requirement 11.5 which states “Deploy file-integrity monitoring software to alert personnel to unauthorized modification of critical system files, configuration files, or content files; and configure the software to perform critical file comparisons at least weekly.

This is another area which Security Blanket excels. In addition to capturing SHA-1 fingerprints of critical files, it also let's you know when discretionary access controls (permissions) have changed. The baseline component of Security Blanket also captures information on all installed software packages, network routing tables, attached hardware devices, host-based firewall rules, and other vital pieces of information.

Another nice feature of Security Blanket is the ability for you to compare not only the same system at two points in time to identify changes but the ability to compare two different systems to identify changes. This is critical to ensure that all nodes in a cluster are similarly configured or a more simpler load-balanced or fail-over configuration.


This post only scratches the surface of what is required of Linux administrators responsible for systems which must adhere to the PCI DSS. The standard is detailed and requires good planning and a commitment to maintain the final achieved security posture. Security Blanket can assist organizations in configuring and maintaining their operating system level security. For for more information, check our website.

Cross-posted from Security Blanket Technical Blog

1. "Electronic Commerce". Retrieved from Wikipedia July 10, 2010 (http://en.wikipedia.org/wiki/Electronic_commerce)
2. "About the PCI Security Standards Council" (https://www.pcisecuritystandards.org/about/index.shtml)


Possibly Related Articles:
Information Security
Post Rating I Like this!
Jeffrey Huckaby CIS is a good starting point. I recently learned that Nessus's Professional Feed comes with policies to scan against the CIS guidelines. This makes it pretty nice to stay compliant to that recommendation.

I will need to check the latest PCI specifications but historically, I found most the the server side work involved SSL prototols, clear-text protocols and clearing up false-positives.

Jamie Adams @Jeffrey... you're absolutely right when saying it is a "good starting point". Because there is so much more you can do besides CIS.

As for Nessus, they are a good scanner but they are "scan-only" whereas, Security Blanket will actually configure the system, too.
Susan V. James "Install critical security patches within one month of release" - I have a couple of problems with this PCI-DSS statement.

1) "Critical" is a subjective term. Critical according to who's criteria? If CVSS2, the standard should suggest that, along with a mention of allowing alternative risk mitigation strategies besides patching (if in fact that is acceptable.) Depending upon the complexity of the environment, sometimes the patch is not the most desirable or fastest fix to the exploit.

2) With the amount of testing that should be done before wide-scale patch deployment in a large Unix shop, depending upon the potential wide range of effects the patch may have (ie: libc) one month is still a pretty aggressive turn-around time for testing, fixing any problems introduced by the patch, coordinating the rollout effort (sometimes necessitating buy-in from many different partners, with varying schedules offered for patch deployment,) conducting the roll-out, and then final verification in production that everything is ok before turning the system back over to the end users.
The views expressed in this post are the opinions of the Infosec Island member that posted this content. Infosec Island is not responsible for the content or messaging of this post.

Unauthorized reproduction of this article (in part or in whole) is prohibited without the express written permission of Infosec Island and the Infosec Island member that posted this content--this includes using our RSS feed for any purpose other than personal use.