Over the last few months a lot of customers seem to be asking me the same question, “Can IBM Endpoint Manager help me become PCI compliant? Well, the answer is not a straight yes or no, but it can help you maintain compliance to significant parts of the PCI DSS standard.
What is PCI compliance?
The Payments Card Industry has developed a Data Security Standard that is used as a benchmark to ensure sufficient security is in place to protect cardholder data.
The PCI DSS standard applies to network components, servers and applications that are included or connected to a cardholder data environment. The cardholder environment is considered to be made up of the people, processes and technology providing cardholder data services.
How can IBM Endpoint Manager help me become PCI DSS Compliant?
From the high level definition above of PCI compliance, even with a basic knowledge of IBM Endpoint Manager it is apparent that the product cannot cover all of the areas that the standard applies to.
So I have taken a quick look through the standard and highlighted some of the areas it can help you with. The Standard I used was the
Payment Card Industry (PCI) Data Security Standard
Requirements and Security Assessment Procedures Version 2.0 October 2010.
The following sections are named and numbered in accordance with the Standard mentioned above.
Firstly the standard recommends that network segmentation should be used for the cardholder data environment, this would normally imply that the devices are held within a DMZ. Which raises the question “Can IBM Endpoint Manager manage devices in a DMZ?”
IBM Endpoint Manager is an agent based solution so in order to manage a device an agent must be installed on it. If you have multiple agents within a DMZ they will need to be connected into the Endpoint Manager environment so to avoid opening a connection through the firewall for each device in the DMZ an Endpoint Manager Relay would be placed in the DMZ. All agent communications would pass through this relay, thus only requiring a single connection to be opened between the relay and its parent relay or Endpoint Manager server. Message level encryption would be enabled on all agents to encrypt all upstream data so that no data originating from agents will be visible on the network.
The following diagram shows an example of this configuration:
Requirement 1: Install and maintain a firewall configuration to protect cardholder data
1.4 Install personal firewall software on any mobile and/or employee-owned computers with direct connectivity to the Internet (for example, laptops used by employees), which are used to access the organization’s network.
There are multiple ways that you could satisfy this requirement using IEM, here are a couple of examples:
- Using IEM’s core protection module you could deploy Trend Micro’s Officescan suite of products. This would give you the ability to ensure firewall software is installed and active on target devices. This configuration allows firewall rules and exceptions to be centrally managed.
- If you already have firewall software installed, then IEM could be configured to deploy your firewall package to devices that currently do not have the software installed, analyses could be configured to determine installed firewall versions and current state active/inactive. Policies could be setup to ensure firewall services are always running.
Requirement 2: Do not use vendor-supplied defaults for system passwords and other security parameters.
2.2 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.
Sources of industry-accepted system hardening standards may include, but are not limited to:
- Center for Internet Security (CIS)
- International Organization for Standardization (ISO)
- SysAdmin Audit Network Security (SANS) Institute
- National Institute of Standards Technology (NIST)
The IBM Endpoint Manager Security Configuration module can be used to provide compliance checking against industry-accepted systems hardening standards. IEM currently supports multiple standards including the Center for Internet Security (CIS) and Defence Information Systems Agency Security Technical Implementation Guide (DISA STIG). The mechanism for checking a system against a security standard is relatively simple and follows the following steps:
- Define a company standard for a particular operating system, either by selecting a complete off-the-shelf standard (CIS) or a subset of this standard.
- Activate the analyses associated with the new company standard.
- Schedule the upload of the collected data into the Security and Compliance Analytics Module.
The Analytics module provides a historical view of the compliance of a device to a company standard, the following example shows compliance status against a Windows 2003 Security standard:
You can then drill down into the individual checks performed against each target system to view compliance against individual checks. Exceptions could then be raised against non compliant systems or the compliance check list can be used to drive security changes on non compliant systems.
Requirement 5: Use and regularly update anti-virus software or programs
5.1 Deploy anti-virus software on all systems commonly affected by malicious software (particularly personal computers and servers)
5.2 Ensure that all anti-virus mechanisms are current, actively running, and generating audit logs.
Again there is more than one way to satisfy this requirement with IEM, here are a couple of examples:
- Similarly to the firewall example above using IEM’s core protection module the Trend Micro’s Officescan suite of products could be deployed and centrally controlled with IEM. This would provide the ability to ensure anti-virus software is installed up to date and active on target devices.
- The IEM Client Manager for Endpoint protection module can be used to provide health checks on existing anti-virus software such as McAfee, Symantec and Sophos. This will ensure the software is installed up to date and active on target devices.
Requirement 6: Develop and maintain secure systems and applications
6.1 Ensure that all system components and software are protected from known vulnerabilities by having the latest vendor-supplied security patches installed. Install critical security patches within one month of release.
The IBM Endpoint Manager Patch Management Module provides both operating system and application security patching capabilities for virtually all Windows, Linux and Unix operating systems. To keep security patch content up to date IBM continually monitors vendor security patch releases and as soon new content is released it is packaged into fixlets and this new content is downloaded by IEM Servers. IEM has a limited number of applications that it supports for security patching, so if you are running applications that are not supported by IEM you will need to monitor vendor sources for updates and create custom content in IEM to deploy patches to these applications.
The following patch process diagram highlights the automated processes performed by IBM Endpoint Manager (green) and the customer specific processes (yellow) it will need to be integrated with.
6.2 Establish a process to identify and assign a risk ranking to newly discovered security vulnerabilities.
All security patch and vulnerability content in IEM is assigned a source severity in line with the vendor defined severity. When content has been assigned CVE, OVAL and CVSS ratings these are displayed in the description of the security patch or vulnerability. As with the previous section, be aware that custom content must be created for all applications and vulnerabilities that are not supported by IEM.
6.4 Follow change control processes and procedures for all changes to system components. The processes must include the following:
6.4.1 Separate development/test and production environments
6.4.2 Separation of duties between development/test and production environments
I have grouped the above requirements together as they all relate to the segregation of systems, content and operator duties in the IEM software. In IEM custom sites can be created to hold content and have only specific computers subscribed to them.
So for example a Test site could be created with only test systems subscribed to it and a Production site could be created with only Production systems subscribed to it.
Initially no content would be in the Test or Production Sites. Two operators would be created a Test operator, and a Production deployment operator. These operators would only have the rights to read their Test or Production sites.
When new patches are approved for testing, they would be copied into the Test site and the Test operator who can only see this Test site and can only manage test systems would then test the deployment of the patch. Once testing is complete the tested content can then be copied to the next site in the patching process, which could be a change manager site who only sees patches that are approved and have been tested.
When changes are approved the change manager would copy the content into the Production site and the Production operator would deploy the patches to the Production systems.
From the above you can see that environments and operator duties can be segregated to conform to PCI requirements.
If you are interested in using IEM to help achieve PCI compliance or want to discuss anything in this blog then give me a call at Orb Data on +44 (0) 1628 550450 or email me at firstname.lastname@example.org . You can also follow Orb Data on Twitter at @OrbData.