Labs: PCI DSS 3.0 Req # 7 - Implement Strong Access Controls 10-minute Challenge

Challenge Accepted!

In a previous post, we outlined the PCI DSS3 Requirement 7 10-minute challenge.
This entry is to outline current environment, high level steps and verification protocol.

Here's the current environment as of today (excluding the 2-node Hadoop cluster):

Here's what we're adding for the challenge:

The cast of characters

• J. Peterman and Elaine Benes are the PCI Developers
• On Windows - PCI Developers shall perform developer tasks like:
• Opening SQL Server Studio
• Resetting IIS websites
• Control System Services
• On Linux -  PCI Developers shall perform LAMP functions like:
• Control the httpd service
• Elevate to the mysql account (without knowing the credentials)
• Edit the httpd daemon config file /etc/httpd/conf/httpd.conf
• Jerry Seinfeld is a Domain Admin
• George Constanza is the UNIX Sysadmin

Steps to the Challenge - 10 minutes

Planning
- Will use a new zone to prove this concept (may be needed for separation of duties) - name: PCI
- Will reuse the existing ZPA service (provisioning has nothing to do with PCI, will control access with Roles)
- A Combined UNIX/Windows role will be created with the following access:

• Role Properties
• Available 24x7
• Password Login and SSO enabled
• Non-Restricted Shell
• Access Rights
• PAM SSH
• Remote (Windows)
• UNIX Commands
• systemctl (start|stop|restart)*httpd  as root (authenticated)
• su - mysql  as root (authenticated)
• vi /etc/httpd/conf/httpd.conf
• Windows Applications
• iisreset.exe  as local administrator
• services.msc as local administrator
• SQL Management studio as local administrator

- PCI Developers group will be called - PCI Developers

Implementation

On the management station:

1. In ADUC create the PCI Developers role
2. In access manager set up the new zone.
3. Set up the Unix identity properties
4. Set up the UNIX commands
5. Set up the Windows Applications
6. Create the PCI Developers role, set up properties, add the rights
7. Perform the role assignment at the zone level.

On CEN2

1. Unpack the Centrify agent bits
2. Run adcheck
3. Join the zone
4. Run adquery user and dzinfo

On APP2

1. Install the Centrify Agent
2. Join the Zone and Reboot

Test Plan (Check) - 5 minutes

• We'll verify that PCI developers can:
• Only log in via SSH (Linux) and RDP (Windows)
• Perform administrative tasks on APP2 (Win Server 2012 R2)
  Not a member of Local Administrators or Domain Admins
• Perform LAMP admin duties on CEN2 (CentOS 7)
  They shall not know the root account.
• Windows Domain admins should not be allowed to log in to the PCI systems (Jerry)
• Enterprise UNIX admins - should not be allowed to log in to the PCI systems (George)
• Any other users can't access the systems (Soup Nazi)
• The model should work for both Unix/Linux and Windows.

First Video - Challenge Explained (5:03)

Second Video - Implementation (9:40)

Third Video - Verification (6:49)

Security Corner: PCI DSS 3.0 Requirement 7 - Implement Strong Access Controls 10-minute Challenge

Background

The Payment Card Industry (PCI) Data Security Standards (DSS) is a great measuring stick for the security posture of any organization.  In fact, I love it because it's so clear.

Requirement 7: "Restrict access to cardholder data by business need to know" poses an interesting set of challenges, because it requires the enforcement of the principles of:

• Least Access - users shall only access the systems they need access to
• Least Privilege - once in these systems, they shall only do what they're supposed to do
• Implement a Role-Based Access Controls (RBAC) model
• Shall be enforced across heterogeneous platforms (7.2.1)
• Ideally the process is consistent and easy to document and adhere to workflow (7.1.4, 7.3)
• Closed systems - All systems default to deny access unless (7.2.3)

Challenge

1. Implement the technical(1) controls of Requirement 7
2. Multi-platform:  Unix/Linux & Windows
3. Implement it in less 10 minutes or less
4. Prove compliance in 5 minutes or less

The Environment:

1. Active Directory 2012 Domain (based on the Microsoft Test Lab Guides)
2. One Windows Server
3. One RHEL 7
4. Centrify software already loaded on a management server (MMCs) and copied in target systems.

Access Rules

The access rules have to be defined as per 7.1.1.

 The card data environment consists of one Windows Server 2012, a RHEL 7 and an Ubuntu 14.04 servers.  The nature of the work performed is database (SQL Server) and Web (IIS) work on Windows.  The RHEL platform is used for an Apache/MySQL app.  There are two types of roles in this environment:

• Sysadmin (cross-platform)
• Sysadmins shall perform tasks as root in RHEL systems without knowing the root password. (7.1.2/7.1.3/7.2.2)
• Sysadmins shall be able to perform tasks as Administrator on Windows platforms without being a permanent member of the Local Administrators or Domain Admins group. (7.1.2/7.1.3/7.2.2)
• Developer (cross platform)
• Developers shall perform service control of Apache and IIS services  (service httpd start | stop | restart) and iisreset.exe - No root/apache/ credentials or ocal admin rights. (7.1.2/7.1.3/7.2.2)
• Developers shall be able to elevate to the mysql service account and to run the services.msc snap-in in Windows (to stop/start/pause) SQL without the root/mysql credentials or local windows admin rights. (7.1.2/7.1.3/7.2.2)

Additional Guidelines

• Because these are PCI systems, no one than the PCI Sysadmin and PCI developer Role can log in to the system.  This includes any other trusted administrators like Domain Admin. (7.2 - deny-all)
• Access to both roles is restricted to the terminal (SSH on Linux and RDP on Windows) no console access.
• The add/moves/changes process shall be controllable via AD Group membership.  This makes easy for other upstream tools to control workflow and approvals. This makes compliance with 7.1.4 (approvals) and 7.3 (documentation) much easier.

Our next post consists of a set of steps and video challenge.