pci dss compliance in the unix/linux datacenter...

PCI DSS Compliance in the UNIX/LINUX Datacenter Environment

Publication No. PBWP26-20090909 August 2009

About the Company

BeyondTrust is the only provider of Privileged Access Lifecycle Management (PALM) solutions for heterogeneous IT environments. The BeyondTrust suite of products reduces the risks associated with insider sabotage and theft of proprietary data, while documenting accountability to support increasing demands of regulatory compliance required across many industries.

PALM is a technology architecture framework consisting of four continual stages running under a centralized automated platform: Access to privileged resources, Control of privileged resources, Monitoring of actions taken on privileged resources, and Remediation to revert changes made on privileged IT resources to a known good state.

More than half of the companies listed on the Dow Jones rely on BeyondTrust to secure their enterprises. BeyondTrust customers include eight of world's 10 largest banks, seven of world's 10 largest aerospace and defense firms, and six of the 10 largest U.S. pharmaceutical companies, as well as renowned universities. BeyondTrust's customer retention rate is over 90%. The company is headquartered in Los Angeles, California, with East Coast offices in Greater Boston and EMEA offices in London, UK. For more information, visit www.beyondtrust.com.

BeyondTrust Corporation ▪ 30401 Agoura Road ▪ Agoura Hills, CA 91301 ▪ USA

Legal Disclaimer

BeyondTrust, Privilege Manager and PowerSeries are trademarks of BeyondTrust Corporation. This document is for informational purposes only. BeyondTrust offers no warranties, express or implied, in this document. Microsoft, Microsoft Outlook, Microsoft Exchange, Microsoft Internet Explorer, Microsoft Windows, Microsoft Windows 2000, Microsoft Windows XP, and Microsoft Windows Server 2003 are trademarks of Microsoft Corporation. Other names mentioned herein may be trademarks of their respective owners.

© 2009 BeyondTrust Corporation. All Rights Reserved.

Table of Contents

Executive Summary .............................................................................................. 4

PowerBroker and PCI DSS Compliance ................................................................... 5

How PowerBroker Works.................................................................................... 5PowerBroker Components .................................................................................. 5

How PowerBroker Supports PCI DSS Requirements ................................................ 7

Payment Card Industry Data Security Standard* ................................................. 7PCI DSS 1.1 Requirement ................................................................................... 7

Designed for Best-Practices Security .................................................................... 11Strong Command and Privilege Delegation ............................................................ 11

Key Features of PowerBroker Version 5.0 .............................................................15

PowerBroker Reporting to Demonstrate Compliance..............................................17

Individual Accountability and Segregation of Duties...........................................17Audit Trails: Logs and Reports...........................................................................17Avoiding Audit ―Trouble Points .........................................................................17IT Audit Checklist for PCI: Audit "Trouble Points" Addressed by PowerBroker .....17

Maintaining Compliance and Safe Harbor Protection..............................................19

Conclusion...........................................................................................................19

White Paper BeyondTrust™ Corporation

4 PCI DSS Compliance in the UNIX/Linux Datacenter

Executive SummaryPCI compliance is again top of mind for decision makers, in part because of the possibility of more stringent enforcement. Visa has been especially focused on compliance by retail stores, since it is the "full track data" collected when a magnetic stripe card is swiped in a store that can be used to create perfect counterfeit cards. PCI compliance seems to have reached a tipping point, with most Level 1 or Level 2 merchants compliant or well on the way.2

To implement PCI DSS compliance, many organizations are turning to automated security solutions. Automated solutions reduce errors, reduce costs compared to manual solutions, and create logs that can be used for audit trails. Key to improving security to meet PCI is creating a secure access control infrastructure as well as a secure auditable process. BeyondTrustPowerBroker enables IT organizations to create a secure access control infrastructure through granular authorization and ―delegation of the UNIX/Linux root or super user password to users based on their role and duties in the organization in line with segregation of duties (SoD) and the principle of least privilege.

The root password in native UNIX/Linux operating systems serves as the keys to the kingdom in this environment and affords little or no control over who can do what once logged on as the root or super user account. Your trusted administrators are often forced to share this password with other users and contractors to

complete the performance of routine activities that normally do not pose a security threat. But users who need to access UNIX/Linux operating systems and the files and directories on those systems to perform their jobs, have no restrictions on what they can access or when once in possession of the password to the root account.

PowerBroker controls and monitors access to database and CRM applications administrators and end-users may need to access and which may contain customer credit card data. Not only can PowerBroker control and monitor who has access to what UNIX/Linux resources and when, it provides extensive I/O or keystroke logging of their activity once they have access. PowerBroker‘s keystroke log captures complete session input, output, and error and is easily configured and managed.

A CISP Bulletin issued by Visa to clarify PCI requirements on logging reads, "It is not necessary to log all application access to cardholder data if the following is true (and verified by assessors):

Applications that provide access to cardholder data do so only after making sure the users are authorized;

Such access is authenticated via requirements 7.1 and 7.2, with user IDs set up in accordance with requirement 8; and

Application logs exist to provide evidence in the event of a compromise.

PowerBroker meets all three requirements. It functions as Visa describes: using an individual user ID and password to authenticate a user, then checking that user's authorization to execute the command or program he/she has requested. PowerBroker then logs all actions taken by that user.

PowerBroker also provides auditors with reports that help in validating PCI compliance. This includes an Entitlement Report that, by showing who can run which programs under what circumstances, demonstrates that the organization has a baseline for determining accountability.

PowerBroker is a policy-driven solution and highly user configurable thus making it perfect

AbstractThis document explains how BeyondTrust

PowerBroker supports the Payment Card Industry Data Security Standard (PCI DSS) by limiting and tracking authorization to execute commands and programs that access servers and applications storing and using proprietary cardholder. BeyondTrust PowerBroker provides an auditable process that controls, monitors and records that access. PowerBroker establishes and enforces auditable control and process for preventing unauthorized data access. PowerBroker can be customized to tightly control authorization to meet the requirements outlined in PCI DSS specification.

BeyondTrust™ Corporation White Paper

PCI DSS Compliance in the UNIX/Linux Datacenter 5

for meeting standards that are often subject to many revisions and refinement. With its powerful scripting language, PowerBroker can map to changing regulatory requirements and internal security policies. By controlling authorization at the system, application, and file level, PowerBroker provides control at the best-practices ―close to the data‖ level.

PowerBroker supports PCI DSS compliance by reducing the number of individuals who need to know the actual root password to do their work, and by controlling what they are authorized to do. This significantly lowers the risk of compromising cardholder data.

PowerBroker and PCI DSS ComplianceHow PowerBroker Works

PowerBroker lets root authority be delegated or partitioned without compromising root security. PowerBroker does this by binding specific root-level tasks to UNIX or Linux user IDs, so operators and system administrators can complete the specified tasks without knowing the root password. In this way PowerBroker protects the root account from internal exploitation by a rogue employee or by a hacker who has breached the network. By preventing unauthorized access, PowerBroker secures cardholder data and prevents the deletion of logged events and audit trails.

PowerBroker lets the system administrator specify whether, under what conditions, and when a user's request to run a program will be accepted or rejected. This granular control of authorization is achieved through PowerBroker's policy language. With PowerBroker, administrative tasks such as managing system programs, mounting devices, performing backups, and adding new users can be delegated to individuals or groups at a granular level. PowerBroker also grants user access to files, directories, and third-party applications and accounts (such as database, CRM, ERP, SAP, or generic accounts). PowerBroker authorizes users to perform the root actions for which they are responsible, but no other commands or programs requiring the root account.

With PowerBroker, the user requests that a program be run as root (or as another privileged UNIX or Linux account, such as dba on Oracle). PowerBroker evaluates the request. If the request is accepted, PowerBroker runs the program locally or across a network for the user. By enabling system administrators to delegate administrative privileges and authorization without disclosing the root password, PowerBroker enables selective access to UNIX-and Linux-based corporate resources while protecting the root account from hackers who could gain access to sensitive cardholder data and and delete audit trails. PowerBroker‘s policy scripting language lets administrators restrict user actions to only specified applications, commands, or files. Its extensive logging and reporting, including keystroke logging and Entitlement reporting, provide the data auditors require.

PowerBroker establishes the cornerstone requirements of compliance: security and accountability. PowerBroker's privilege delegation, customized to an organization‘s needs through policy scripts, provides proactive security, keeping sensitive cardholder data out of sight and out of reach.

PowerBroker Components

A typical PowerBroker configuration consists of four software modules: pbrun, pbmasterd, pblocald, and pblogd.

User task submission: pbrun. pbrun is the PowerBroker component that receives task requests; all secured tasks must be submitted through pbrun. A separate pbrun process is started for each secured task request that is submitted. If the use of pbrun is not enforced for secured tasks, a company‘s security policy implementation may be compromised.

Security policy file processing: pbmasterd. pbmasterd applies the security rules defined in the PowerBroker security policy files. pbmasterd performs security verification processing to determine whether to accept or reject a request, based on these security rules. If a request is rejected, the result is logged and processing terminates. If a request is accepted, it is passed to pblocald for execution.



Task execution: pblocald. pblocald executes task requests that have passed security verification processing. As soon as a task request has been accepted, it is immediately passed from pbmasterd to pblocald. By default, pblocald executes the task request as the account specified in the policy variable runuser, typically as root or as another administrative account. As a result, all task input and output information is transferred back to the pbrun component. In addition, pblocald logs pertinent task information to the PowerBroker Event Log, via pbmasterd or pblogd, depending on how PowerBroker has been deployed. The Run Host can also record task keystroke information to a PowerBroker I/O Log.

Logging: pblogd. pblogd is an optional PowerBroker component that writes event and I/O Log records. If pblogd is not installed, pbmasterd writes log records directly to the appropriate log files rather than passing these records to pblogd. If pblogd is not installed, pbmasterd must wait for the pblocald process to complete. If pblogd is used, pbmasterd terminates once task execution starts and pblocald sends its log records directly to pblogd. Using pblogd therefore optimizes PowerBroker processing by centralizing the writing of log records in a single, dedicated component and eliminating the need for the pbmasterd process to wait for task execution to complete.

The machine from which a task is submitted is the Submit Host. A secured task request must undergo security validation processing by pbmasterd before it is allowed to run. The machine on which Security Policy File processing takes place is the Master Host. The machine on which a task is actually executed is the Run Host. The logserver daemon pblogd writes Event Log records and I/O Log records on the Log Host.

The PowerBroker settings file: pb.settings. Although PowerBroker provides strong root and command delegation, it is also highly customizable. This begins with the pb.settings file, which lists a number of parameters that can be defined to best suit an organization‘s security policy. These parameters are stored on each machine in the /etc/pb.settings file. They include:

Masters: Allows administrators to define PowerBroker master servers to either request or accept permissions.

Log Servers: Allows administrators to define a single, central server to consolidate all PowerBroker events and I/O Logs.

Logging: Allows the administrator to define the filenames where various data will be logged, including Event logs, I/O logs, and Error logs.

Encryption: Enables DES or 3DES encryption of all PowerBroker communication among submitting machines, the PowerBroker Master server, and executing machines. All policies and log files can be encrypted, further securing PowerBroker authorization.

SSL: Administrators can enable public-key infrastructure support, using SSL for certificate and key management.

Kerberos: PowerBroker can use Kerberos to authenticate its various components and to exchange encryption-key information.



Firewalls: PowerBroker can operate in very secure environments where firewalls are used to separate clients and servers.

How PowerBroker Supports PCI DSS RequirementsPublished in January 2005, the PCI DSS standard gives companies that transmit, process, or store cardholder data guidelines for securing that data. There are 12 security requirements, grouped under 6 control objectives.

Payment Card Industry Data Security Standard*

Build and Maintain a Secure Network1. Install and maintain a firewall configuration to

protect data 2. Do not use vendor-supplied defaults for system passwords and other security parameters Protect Cardholder Data3. Protect stored data

4. Encrypt transmission of cardholder data and sensitive information across public networks Maintain a Vulnerability Management Program5. Use and regularly update anti-virus software

6. Develop and maintain secure systems and applications Implement Strong Access Control Measures 7. Restrict access to data by business need-to-know 8. Assign a unique ID to each person with computer access 9. Restrict physical access to cardholder data Regularly Monitor and Test Networks10. Track and monitor all access to network resources

and cardholder data 11. Regularly test security systems and processes Maintain an Information Security Policy 12. Maintain a policy that addresses information security * From Payment Card Industry Data Security Standard, January 2005, © 2005 MasterCard International Incorporated

PCI DSS 1.1 Requirement

2. Do not use vendor-supplied defaults for system passwords and other security parameters.

PowerBroker meets this broad requirement by providing a way to avoid revealing the “factory installed’ root password to all administrators. Instead of everyone sharing the root password that comes with each UNIX/Linux server,

PowerBroker enables you to write policies that determine which administrators can run what commands as root and when. Furthermore, those same administrators can be prevented from knowing the root password altogether, because these commands are launched via PowerBroker.

Also, the policies you create and store in the PowerBroker program examine each request by administrative user and determine if, according to policy, that request from that user should be approved and the command allowed to run. By assigning root-level privileges based on role and the individual program or command the administrator has asked to run, the root password is never revealed. PowerBroker can also delegate special account privileges for generic application accounts, such as Oracle and SAP.

2.3 Encrypt all non-console administrative access. Use technologies such as SSH, VPN, or SSL/TLS (transport layer security) for web-based management and other non-console administrative access.

PowerBroker can encrypt network traffic, including traffic generated by an administrator using its Web-based GUI. If SSL is used, it supersedes the network-traffic encryption algorithms once the start-up protocol is complete.

3. Protect stored cardholder data.

3.4 Render PAN (the Principal Account Number), at minimum, unreadable anywhere it is stored (including data on portable digital media, backup media, in logs, and data received from or stored by wireless networks) by using any of the following approaches:

Strong one-way hash functions Truncation Index tokens and pads Strong cryptography with associated key

management processes and procedures.

The MINIMUM account information that must be rendered unreadable is the PAN. If for some reason, a company is unable to encrypt cardholder data, refer to Appendix B: “Compensating Controls for Encryption of Stored Data.”



PowerBroker encrypts logs to protect PAN (principal account number) data they contain. Of the methods listed under Requirement 3.4, the PCI Standards Council has indicated that encryption is by far the preferred method, and that encryption may in the future become the only accepted method of protecting PAN data. PowerBroker supports over 30 different types of encryption to secure network traffic, logs and configuration files including AES 256.

3.4.1 If disk encryption is used (rather than file- or column-level database encryption), logical access must be managed independently of native operating system access control.

Through policies and the encryption it provides, PowerBroker provides a way to manage logical access independently of native operating system access control, in situations when disk encryption is used.

3.5 Protect encryption keys used for encryption of cardholder data against both disclosure and misuse.

PowerBroker's pbkey command generates an encryption key suitable for any of PowerBroker's encryption algorithms, and stores it in a file. This file's name is specified on PowerBroker's command line or in the pb.settings file. The keys are accessible only by the root account; this access can be delegated for emergency situations. An organization can use PowerBroker to control user behavior, protecting against abuse or accident.

3.5.1 Restrict access to keys to the fewest number of custodians necessary

PowerBroker best practices is to have the pb.settings file owned by root, and have permissions set so only root can read or write to the file.

3.5.2 Store keys securely in the fewest possible locations and forms.

Storing the key name only in the pb.settings file and only in digital form meets this requirement. The key is stored in only one place: a single file.

3.6 Fully document and implement all key-management processes and procedures for keys used for encryption of cardholder data.

Since PowerBroker logs containing PAN data would be sent over the network encrypted, the key management processes and procedures described in response to Requirements 3.5-3.5.2 would be satisfied. This same information would also satisfy Requirement 3.6.3, “Secure Key Storage.”

4. Encrypt transmission of cardholder data across open, public networks

4.1 Use strong cryptography and security protocols such as secure sockets layer (SSL) / transport layer security (TLS) and Internet protocol security (IPSec) to safeguard sensitive cardholder data during transmission over open, public networks.

PowerBroker supports SSL and TLS.

7. Restrict access to cardholder data by business need-to-know

7.1 Limit access to computing resources and cardholder information only to those individuals whose job requires such access.

PowerBroker is a uniquely customizable and granular way to limit access to UNIX and Linux systems—the systems used by most large financial institutions to store and process sensitive cardholder data. As previously mentioned, PowerBroker’s rich policy language can easily restrict access based on need to know and role within the company. The product also records keystrokes and creates an unalterable audit trail of such keystrokes. So even if an authorized, trusted employee did access data they are not authorized to access, there would be an audit trail and record of such activity.

7.2 Establish a mechanism for systems with multiple users that restricts access based on a user’s need to know and is set to “deny all” unless specifically allowed.



PowerBroker meets requirement 7.2 by binding specific root-level tasks to specific UNIX/Linux user IDs and its strong access-control model denies access by default. PowerBroker's policy-writing language allows specification of highly granular attributes for access; these can be based on each organization's “need to know” security rules. If and when these rules change, the policy can be changed to use the new attributes.

8. Assign a unique ID to each person with computer access

8.1 Identify all users with a unique user name before allowing them to access system components or cardholder data.

PowerBroker uses the existing UNIX or Linux user ID for each user, even when users use shared or generic accounts.

8.2 Employ at least one of the methods below, in addition to unique identification, to authenticate all users: password; token devices (for example, SecurID®, certificates, or public key); or biometrics

PowerBroker can use Pluggable Authentication Modules (PAM) for authentication on systems where it is available. PowerBroker’s pbpasswd command generates an encrypted password that can be used by the getstringpasswd () function in the configuration file. In addition to unique identification, PowerBroker uses passwords to authenticate users. For example, a user who wants to use the PowerBroker GUI is authenticated by checking the entered user name and password against the UNIX passwords on the host running pbguid (the PowerBroker GUI daemon). All PowerBroker client and server programs can use Kerberos Version 5 for authentication. If PowerBroker is configured to use Kerberos, the user is asked to enter a password for Kerberos authentication in addition to his password to access the host.

8.4 Encrypt all passwords during transmission and storage, on all system components.

PowerBroker passwords are encrypted during transmission—30 symmetric encryption algorithms are supported. PowerBroker also supports SSL/TLS. PowerBroker passwords are stored only in logs, which can be encrypted. Login passwords can be suppressed, so that they do not appear in encrypted logs.

8.5 Ensure proper user authentication and password management for non-consumer users and administrators, on all system components.

PowerBroker ensures proper user authentication through individual IDs and passwords especially for administrators. PowerBroker can meet all subsections of this Requirement that lie within the scope of its operation.

10. Track and monitor all access to network resources and cardholder data

10.1 Establish a process for linking all access to system components (especially access done with administrative privileges such as root) to each individual user.

PowerBroker links all access to UNIX- and Linux-based system components to individual users by binding specific root-level tasks to UNIX/Linux user IDs.

10.2 Implement automated audit trails for all system components to reconstruct the following events:

10.2.1 All individual user accesses to cardholder data

10.2.2 All actions taken by any individual with root or administrative privileges

10.2.3 Access to all audit trails 10.2.4 Invalid logical access attempts 10.2 5 Use of identification and

authentication mechanisms 10.2.6 Initialization of the audit logs 10.2.7 Creation and deletion of system-level

objects.

PowerBroker can log all the events listed for UNIX and Linux systems. PowerBroker’s event log records every PowerBroker request. The event log contains the initial user ID, environment and command requests as well as all arguments used, what the new environment is, and the launched binary and its



arguments. Full, indelible keystroke logs with replay functionality are also created.

10.3 Record at least the following audit trail entries for all system components for each event:

10.3.1 User identification 10.3.2 Type of event 10.3.3 Date and time 10.3.4 Success or failure indication 10.3.5 Origination of event 10.3.6 Identity or name of affected data,

system component, or resource.

PowerBroker logs all these audit-trail items by default for UNIX- and Linux-based systems.

10.5 Secure audit trails so they cannot be altered.

10.5.1 Limit viewing of audit trails to those with a job-related need

10.5.2 Protect audit trail files from unauthorized modifications

10.5.3 Promptly back-up audit trail files to a centralized log server or media that is difficult to alter 10.5.5 Use file integrity monitoring and change detection software on logs to ensure that existing log data cannot be changed without generating alerts (although new data being added should not cause an alert).

PowerBroker logs can be encrypted, satisfying the objective of Requirement 10.5 for UNIX- and Linux-based systems. 10.5.1: PowerBroker best-practices security recommends limiting access to logs to the highest-level administrators only; this can be enforced by a PowerBroker policy:

10.5.2, and 3: Encryption makes PowerBroker logs impossible to alter. 10.5.5: Since logs would need to be unencrypted even to be read (let alone changed), the decryption would be logged, and notification could be made from inside a policy written to protect against such an action.

10.7 Retain audit trail history for at least one year, with a minimum of three months' online availability.

PowerBroker logs can be backed up to a log server for 3 months' online availability, then transmitted in encrypted form to an archive server for the rest of the year. The pbsync command can be used to send logs to a secure repository.

Requirement 11: Regularly test security systems and processes

11.5 Deploy file integrity monitoring software to alert personnel to unauthorized modification of critical system or content files; and configure the software to perform critical file comparisons at least weekly.

Critical files are not necessarily only those containing cardholder data. For file integrity monitoring purposes, critical files are usually those that do not regularly change, but the modification of which could indicate a system compromise or risk of compromise. File integrity monitoring products usually come pre-configured with critical files for the related operating system. Other critical files, such as those for custom applications, must be evaluated and defined by the entity (that is the merchant or service provider).

PowerBroker can require a checksum match before running any host-based program, thereby checking file integrity of critical program files it might be asked to run and guarding against virus or Trojan horse attack. The checksum can check file system security to ensure that security couldn't have been breached by any user or account (except root). Checksums can be used to keep unchecked upgrades or shell scripts from being run until they have been checked for data integrity and approved. PowerBroker can also be used to define what privileges a given process can run as.

Many security experts think pursuing best-practices security is a faster, more comprehensive way to achieve compliance than trying to back out security policies from compliance regulations.4 If you dissect PowerBroker, what you find is the anatomy of best-practices security.



Designed for Best-Practices Security

Using PowerBroker, IT departments can adhere to a fundamental tenet of a sound security, the Principle of Least Privilege. The Principle of Least Privilege dictates that a user be granted only the minimum access necessary to complete a legitimate task. PowerBroker provides the means for an organization to build on this principle,establishing a layered defense of policies, procedures, and technical controls.

Since root can modify any file, PowerBroker has been designed in modules to make it difficult for any administrator to have end-to-end access to program submission, authorization, execution, and the resulting logs (the audit trail). PowerBroker can be configured to receive user requests from the Submit Host machine, authorize tasks on the Master Host machine, execute tasks on the Run Host machine, and log these activities on a fourth, very secure log server. The machines containing the policy files and the log files can be made physically inaccessible to users and isolated from remote login over the network. The logs can also be printed on a secure printer or recorded on a WORM drive.

For enhanced security, the Master Host and log server (Log Host) should be on separate machines that are isolated from easy physical access. Each machine should have its own administrator, who does not have access to the other machine. Because these two people would have to collude to subvert system security, this precaution reduces the likelihood of a breach.

Strong Command and Privilege Delegation

Command and privilege delegation have two fundamental modes of operation – a strong model and a weak model. The strong model only delegates commands and files as needed. Privileges are delegated on an as-needed basis. All other operations are restricted by default. This model is highly restrictive (and its high security comes at the cost of occasional inconvenience). The weak model allows access to all commands and files by default. The security policy then attempts to remove specific privileges on a case-by-case basis. This model is highly permissive. Its permissiveness comes at the cost of possible security holes and breaches.

PowerBroker is designed to the strong model, where privileges are delegated on an as-needed basis and any privileges not covered by the security policy are denied.

Fine-grained command and access control through policies.

PowerBroker lets the systems administrator create policies specifying:

Which users can perform a particular task. Which tasks can be run through the system. When the user can do the task. From which machine the user may initiate a

request to do the task. On which machine the task can be done. Whether another user's permission (in the

form of a password) is required before the task is started.

The decisions to be made by a program the systems administrator supplies and which programs PowerBroker calls to determine if a request should be accepted or rejected.

Many other attributes and modifications of requests, including other restrictions for security purposes. For example, users can be required to work from within a restricted shell or editor when they need to access certain programs or files as root.

The following one-line sample policy shows how easy it is with PowerBroker to restrict commands using time constraints:

reject from "ellen" when timebetween (1700, 0800) || dayname in {"Sat", "Sun"};

If Ellen requests a command outside office hours, this one-line policy will reject her request, enforcing the organization's security policy.

Access Control Lists (ACLs).

PowerBroker‘s Access Control Lists simplify the definition of access privileges. Using a simple ACL, system administrators can specify the most commonly used PowerBroker access-control mechanisms for users or for groups, without having to compose policy scripts. Access Control Lists can control privileges by:

User;



System; Command; Time of day; Day of the week.

This creates a profile of each user‘s access rights to various systems, which in turn lets administrators produce detailed lists of users‘ permissions for internal and external audits. These lists help demonstrate compliance with such PCI DSS requirements as separation of duties (Requirement 6.3.3.) and strong access control (Requirement 8). PowerBroker‘s ACLs do not eliminate or replace policies or scripting, but do streamline the process of specifying access privileges for large groups of users. For example, an ACL could be used to set up access privileges for the Finance Department, with minor changes to elevate privileges for the CFO. In an ACL-based security model, when a subject submits a request to perform an operation on an object, the system first checks the ACL for an applicable entry in order to decide whether or not to proceed with the operation. PowerBroker‘s ACLs specify the user, submithost, command, and runhost. For example, PowerBroker‘s ACL can have specifications such as: ―Joe on Host 265‘ can kill a root-owned process on ‗Host 10’.‖Individual accountability on shared accounts. PowerBroker works within UNIX or Linux to establish the accountability of individual users who are using a shared privileged account, and does this without altering UNIX commands. Suppose a user performs an su –oracle and is running as the oracle account, doing some file editing. The Oracle Administrator does not know which user with the oracle password has su'ed to Oracle, or which tasks that user performed as oracle. Forcing a pbrun oracle (transparent to the user) secures the Oracle administrative account and enforces many types of password authentication, logging, and privilege delegation—providing user accountability and administrator control. PowerBroker can authenticate users through any or all of the three authentication factors: what you know (e.g., passwords), what you have (e.g., a token), or who you are (biometrics). This kind of authentication is usually done through PAM (pluggable authentication modules) or through an external authentication program.

Secure editors. PowerBroker provides pbvi, pbmg, and pbumacs, secure versions of the UNIX vi, mg (micro-GNU-emacs), and umacs (Gosling-style emacs) text editors. These programs were adapted and made secure for PowerBroker users. For example, a user can only read or write to the file whose filename is given on the command line; features of the text editor that allow reading or writing to other files are disabled. The user is also prohibited from starting any subprocesses, including subshells, from within the editors. PowerBroker also provides pbless, a secured version of the UNIX less viewer. Secure editors are important when users are editing files that require root or other generic accounts (such as dba on Oracle). Normally, if a user escapes out of an editor, he is dumped into the root shell or the generic-account shell. Preventing shell escapes secures both trusted and untrusted users from gaining additional access within privileged accounts, by confining them to just the tasks administrators delegate to them.

Extensive Logging FunctionalityPowerBroker can record all actions performed under its policies, down to the keystroke level. Accurately logging actions in a secure environment results in an unalterable audit trail. The logs will show an auditor exactly what was done as root, as well as who did it, from which system the command originated, on which system it was executed, and when this was done.

Event Log. PowerBroker can record the following events in the Event Log file on the Log Host or Master Host (if a log server is not being used):

The date and time of a request; What program(s) a user attempts to run; What user requested the program; What machine he was on; On what machine he requested the program

be executed; Whether the request was accepted or

rejected; Who the user is running the program as

(e.g., as root, another provided account, another user account).

The Event Log may be reviewed through the PowerBroker GUI or with the pblog command. PowerBroker can also log these events to the Syslog system. An advanced form of reporting



based on Event Log data is also available. The pbreport command extracts data from the PowerBroker Event Logs and generates one or more reports. The report file is an XML file containing the extraction and reporting specifications, usually configured using the Event Log reporting feature of pbguid (PowerBroker's web GUI).

Keystroke logging and keystroke replay. PowerBroker can let administrators view session keystrokes in

Keystroke Log Viewer real time. PowerBroker can also record keystrokes—including when and where they occurred, the resulting output, and any errors. Administrators can view an entire recorded session, seeing the keystrokes just as they appeared during the session. These sessions can be played back for auditors.

I/O Log. The I/O Log can log individual keystrokes as well as what is displayed on the screen. There are a number of options for fine tuning the amount of data that will be logged. PowerBroker makes it possible to I/O Log only specific programs and users. The keystroke logs are stored in distinct files for each logged session, separately from the Event Log for the session. PowerBroker can maintain I/O Logs of sessions under control of the configuration policy language. The passwordlogging and Rootshelldefaultiolog settings provide additional system-wide control of the I/O Logs. On Master and Log Hosts, the administrator can control how much file system space is used.

Syslog. The Syslog uses the standard OS implementation of syslog to record major connection failures, major policy failures, and certain PowerBroker daemon diagnostic messages. The messages PowerBroker transmits

to the Syslog facility are labeled with a Syslog level. The level and a severity specified internally to PowerBroker on a per-message basis are handled by Syslog according to the rules specified by the administrator in the Syslog configuration file.

System Login Records. PowerBroker records login records, such as utmp, wtmp, and logins using PAM modules.

User-Defined Logs. User-defined logs are optional files that record information custom-defined by the administrator within the PowerBroker rules. These logs can be encrypted and stored on a separate machine to facilitate troubleshooting, forensics, quality assurance, and auditing.

Reports Generating PowerBroker reports is straightforward. PowerBroker can generate Event Log reports and Entitlement Report to include complete data for a defined period of time, or just the data types specified by the user, filtered by the parameters he chooses. Authorized users can also extract log data in CSV format for export to third-party reporting programs, such as Microsoft Excel or Crystal Reports. PowerBroker decrypts the log data needed for a report ―on the fly‖ as it generates the report.

Entitlement Report. The Entitlement Report shows what commands users are authorized to execute and on what systems they can execute them. If your organization‘s security policies restrict access to specific programs at certain times of day, this too will be indicated in the Entitlement Report. Entitlement Reports show auditors that segregation of duties is being enforced and those steps are being taken to create a secure access-control infrastructure.

PowerBroker Entitlement Reports include a built-in GUI report writer that combines a Web-based interface with a wizard-style workflow, eliminating the time-consuming process of creating reports manually. The data available for an Entitlement Report is presented in comma-separated value (CSV) format and contains ASCII values for the following:

Submit host User



Command Argv Accept/reject/error text Run host Run user Run command Run argv Iolog (yes/no) (Long form only) Dependencies (Long form only) Master host (Long form only) Policy file name (Long form only) Policy line number (Long form only) Constraints – semi-colon separated (Long

form only).

Administrators and auditors have the ability to edit pbcheck to specify what filters they want to use when generating a report. For example, pbcheck can be filtered to produce an Entitlement Report showing what privileges User 12 can access, or an Entitlement Report showing what users can run the pbvi command. The screen shots that follow show one of the four screens in the Entitlement Report Wizard, and the Report that would result if an administrator requested an Entitlement Report: Report by System.

Entitlement Report Wizard

Entitlement Report: “Report by System”

Secure Operations

Hardened Shells. To provide a middle ground for those who find strong-model security too restrictive, there are two hardened PowerBroker shells. Both shells are based on a single copy of the public domain version of the Public Domain Korn Shell, pdksh version 5.2.14. PowerBroker's pbksh shell uses the full code base of pdksh to provide a shell oriented to interactive use. User actions are secured and logged by this shell, although there is no difference in the appearance of the UNIX or Linux command line. PowerBroker's pbsh shell uses a subset of the pdksh code base to provide a shell oriented to script use.

These modified shells contain the full functionality and features of the standard public domain shell, but they have been modified to verify all command operations through PowerBroker before allowing execution. Any user running pbksh or pbsh will be under the full control of the PowerBroker access-control mechanisms. The PowerBroker Shells provide full security for shell scripts. They can:

I/O Log the entire shell session, or selected commands;

Log all authorization attempts into the Event Log; and

Eliminate the need to search the I/O Logs for commands.

These shells provide administrators with a transparent user interface to all PowerBroker functionality without requiring that requests be entered using the PowerBroker pbrun command. Pbksh and pbsh allow PowerBroker to control all user commands and scripts, providing greater session logging control and reducing the scripting needed to generate reports. These shells also:

Provide the ability to authorize commands by a PowerBroker Master Daemon.

Run commands either locally or through a PowerBroker Local Daemon.

Control shell built-in commands, including directory changes.

Control I/O redirection. Provide PowerBroker security for shell

scripts. Apply all PowerBroker capabilities to a shell

command line without the need to



continually invoke pbrun or to camouflage commands.

Log the activity of native root shells.

Encryption. PowerBroker can encrypt all network traffic it generates, including traffic containing access-control information for stores of cardholder data. This protects sensitive data from network monitoring. PowerBroker can also encrypt control messages, input keyed by users, and output generated by commands run through PowerBroker, as well as Event Logs, I/O Logs, policy files, and its own settings file. PowerBroker supports 30 encryption algorithms. The default encryption method is DES. If SSL is used, it supersedes the network traffic encryption algorithms once PowerBroker's start-up protocol is complete.

Checksum Verification. PowerBroker can verify the checksum of a file prior to permitting it to be run. By matching the checksum of a file to a previously stored checksum, PowerBroker can prevent Trojan programs or rogue program modification from compromising security. Replacing a critical file with a similar file is one way attackers attempt to gain control of a system. Since such programs have been used to transmit cardholder data to the attacker, the checksum verification is especially important.

Forbidden Keystrokes. PowerBroker can be configured to block access to specified data or to prevent the execution of certain commands, known as ―Forbidden Keystrokes.‖ Using this functionality, PowerBroker can also trigger notifications, preventing potential damage to your operating system(s).

Real-Time Monitoring. PowerBroker can show the system administrator the keystrokes of a user as they are being entered. The pbreplay utility allows sessions to be viewed while they are happening, providing proactive security that can help the administrator stop malicious activity before extensive damage is done. PowerBroker can also examine a program file‘s checksums and permissions, comparing the results against a policy containing criteria that indicate the file may have been changed. In that case, PowerBroker refuses to execute the program file.

Notifications. PowerBroker can notify administrators of actions that go against security policy files. A notification can be sent from within the policy itself, and can be logged to the Syslog.

Idle Session Logout. PowerBroker includes idle-session logout, which automatically terminates a root session if nothing has been typed for a specified period of time, reducing the risk of unauthorized use of a privileged user‘s terminal.

Key Features of PowerBroker This overview shows how PowerBroker 5.0 improves efficiency and ease of use. Since its launch in 1994, PowerBroker has established itself as a complete solution for centralized authorization management across a network of UNIX and Linux hosts. PowerBroker runs on many different UNIX and Linux operating systems without modifying the kernel or requiring any binary replacement or system reboot. The product's architecture is fully compatible with existing network architectures and security devices, including firewalls and routers.

PowerBroker provides a secured method ofenabling users to access multiple accounts, rather than having them use the ―su‖ (switch user) command and have to remember multiple passwords. PowerBroker also provides secure access to multiple-user accounts while creating an audit trail of each user‘s activity. Suppose a user performs an su –oracle command and is running as the oracle account, doing some file editing.

The Oracle Administrator does not know which user with the oracle password has su 'ed to Oracle, nor which tasks that user performed asoracle. Forcing a pbrun oracle secures the Oracle administrative account, enabling many types of password authentication, logging, and privilege delegation, while providing user accountability and administrator control.

Non-intrusive to operating system. PowerBroker is non-intrusive to UNIX and Linux operating systems. No kernel rebuild or system reboot is required after installation. PowerBroker does not replace any binaries, but does modify /etc/services (to designate port numbers),



/etc/inetd.conf, and the xinetd configuration (where daemons start up). If an organization doesn't use these locations for ports or daemons, PowerBroker will leverage whatever location is used.

PowerBroker reduces the risk of accidental damage, theft of digital assets, or malicious activities without altering or disrupting the operating system—a practice that can violate software and systems warranties. Often third-party UNIX software vendors place files and programs throughout a UNIX system. Conflicts arise between the new software package and existing applications, and often UNIX operation is impaired. PowerBroker does not affect the UNIX kernel or other software applications.

Centralized Administration. PowerBroker allows IT professionals to centrally manage complex heterogeneous environments from a single server. PowerBroker‗s central administration capabilities enable cost-effective and consistent security management for diverse machines across local, national, or global networks. Central administration means all policy files are controlled through a central server. This allows for central administration of access, so that even if a client is compromised, PowerBroker and its configurations cannot be modified.

PowerBroker has specialized client/server architecture, with failover servers that provide fault tolerance and load balancing for continuous availability. Configuration settings provide for redundant Master Hosts to eliminate the possibility of a single point of failure. The redundant Master Hosts can be positioned throughout the network, so they can respond to local authorization requests. This is especially valuable to an organization with a large WAN or global presence, where a lapse in network connectivity could impact usage. Redundant local Master Hosts protect service uptime. BeyondTrustrecommends setting up at least one failover master for the PowerBroker master daemon. Masters and failover masters have identical settings and security policy files.

Centralized log pooling. PowerBroker collects and stores PowerBroker logs from multiple servers onto one PowerBroker server, enabling administrators to review and manage logs from a centralized location. The log pooling feature allows administrators to discover anomalies

sooner, and also reduces the administrative overhead associated with the log-review process.

Web-based GUI. PowerBroker comes with a web-based graphical user interface (GUI) that provides a user-friendly alternative to administering PowerBroker from a UNIX command line. From the GUI authorized users can create and modify policy files, edit the PowerBroker settings file, view Event Logs and replay Keystroke Logs, and create and run Log and Entitlement Reports.

Web-based GUI Showing PowerBroker Settings File

This easy-to-use GUI lets non-programmers create security policies to support their business practices. The policies can grant access by user, group, netgroup, or host without requiring a group password, simplifying password management. Policies can also grant access by day, date, and time, to prevent after-hours abuse of systems, and access to and from specified hosts (including remote hosts) to selectively assign administrative powers. Organizations can fully specify run-time environments; restrict the machines programs run on, and the machines from which programs may be requested; and control programs‘ access to files and directories. Such control eliminates the risk that a flawed run-time environment will enable unauthorized root actions.

Large file system support. To ensure complete logging, PowerBroker supports large file systems. BeyondTrust recommends that you regularly rotate your logs for better manageability.

Quick Deployment, Quick Results.PowerBroker is quick to deploy, and even a large deployment can be done without Professional



Services. Log and report generation is available immediately.

PowerBroker Reporting to Demonstrate Compliance

PowerBroker logs and GUI report writer make it easy for auditors and IT staff alike to create reports to demonstrate PCI DSS compliance, internally and to third party auditors.

Individual Accountability and Segregation of Duties

Gartner recently published a Research Note that collected questions from merchants confused about PCI compliance and gave Gartner's recommendations. One of the questions: ―How can large retailers secure hundreds or thousands of store servers . . . that host a rash of legacy applications that include point-of-sale (POS) processing? . . . Often times, security is limited to a single password used to access all the store server‘s applications, and there is no added security around POS processing. Gartner answers: ―First, ensure that your application isn‘t storing any sensitive cardholder data on the servers. Implement access controls to ensure segregation of duties, and log user activity... to address audit trail issues. PowerBroker provides individual accountability by assigning individual IDs to all users, solving the problem of accountability for shared accounts on UNIX and Linux systems. Segregation of duties can be ensured through PowerBroker policies, customized to each organization‘s security and access requirements.

Audit Trails: Logs and Reports

PowerBroker logs extensive data in the Event Log, I/O Log, Syslog, system login records, keystroke logs, and user-defined logs. User-defined logs are extremely useful for an organization‘s PCI compliance: optional files can record information custom defined by the administrator within the PowerBroker rules. User-defined logs can be encrypted and stored on a separate machine to facilitate forensics and auditing, as well as the data requirements of the organization‘s PCI compliance plan.

Reports. Authorized users can extract log output in CSV format for export to third-party reporting programs, such as Microsoft Excel or Crystal Reports. IT managers can show auditors that logs are encrypted until a report is generated, and are then decrypted ―on the fly.‖ They can also point out that a checksum run on the decrypted log data and compared to the checksum run on the data before encryption will demonstrate that the PowerBroker log data has not been altered.

Avoiding Audit ―Trouble Points

The PCI Audit Checklist from the IT Compliance Institute identifies a number of "trouble points" merchants may encounter during an audit for PCI compliance.6 The following table lists which of these trouble points PowerBroker can help organizations avoid, and explains how. ITCi groups the 12 PCI DSS Requirements under five Themes (shown in the table), and explains the ―trouble points‖ merchants encounter in achieving compliance with each theme.

IT Audit Checklist for PCI: Audit "Trouble Points" Addressed by PowerBroker

Theme 2: Protecting Cardholder Data (Requirements 3, 4)

Requirement 3: Protect stored cardholder data Encryption and key mgmt, (DSS sections 3.3.4-3.6)

Issue: Although merchants can sometimes avoid deploying encryption by offering a compensating control, the card brands are expected to become stricter about requiring encryption. For example, Visa is expected to become stricter about PANs (personal account numbers) that are not rendered "unreadable wherever they're stored." Key management is the most common issue in implementing encryption to meet this requirement.

Any cardholder data logged by PowerBroker can easily be encrypted, since the logs are encrypted. Storing the key name only in the pb.settings file and only in digital form meets this requirement 3.5.2. The key is stored in only one place: a single file. Since PowerBroker logs containing PAN data would be sent over the network encrypted, the key management processes and procedures described in response



to Requirements 3.5-3.5.2 would be satisfied. This same information would also satisfy Requirement 3.6.3, “Secure Key Storage.”

Theme 4: Implementing Strong Access Control Measures (Requirements 7-9)

Grouped or shared accounts (DSS sections 8.1 and 8.2). Issue: Group Accounts. The issue is that not all merchants use software that lets them assign individual accountability:

Requirement 8.1 Identify all users with a unique user name before allowing them to access system components or cardholder data

Requirement 8.2 In addition to assigning a unique ID, employ at least one of the following methods to authenticate all users: Password Token Devices (for example, SecurID, certificates, or public key) Biometrics

On UNIX and Linux systems: 8.1 PowerBroker uses a unique identifier for each user. 8.2 PowerBroker uses passwords to authenticate users in addition to the individual user ID.

Two-factor authentication (DSS section 8.3)

Issue: Implementing two-factor authentication for remote network access can be costly and can increase liability unless 1) merchants understand that the requirement applies only to users who access the network that "stores, processes, or transmits cardholder data"; AND 2) merchants pursue an aggressive scope reduction strategy. The Checklist advises that "in a highly segmented approach, two-factor authentication is required of only a handful of people, mostly system administrators."

Requirement 8.3 Implement two-factor authentication for remote access to the network by employees, administrators, and third parties. Use technologies such as remote authentication and dial-in service (RADIUS) or terminal access controller access control system (TACACS) with tokens; or VPN (based on SSL/TLS or IPSEC) with individual certificates.

8.3 PAM modules can be plugged in to provide as many authentication methods as desired for

remote access to the network, including the use of external authentication programs.

Authentication required for any database containing cardholder data. (DSS section 8.5.16)

Issue: This requirement generated controversy, since it seemed to require that users and applications be authenticated and the authentication logged on each database access. This was clarified by Visa in a July 2006 bulletin, which explains that users who access data through a secure application do not need to be authenticated on each access.

Requirement 8.5.16 reads, "Authenticate all access to any database containing cardholder data. This includes access by applications, administrators, and all other users." Direct SQL queries should be limited to database administrators. According to the Checklist, "This requirement has generated such controversy that Visa has issued clarification on access logging requirements. The bulletin essentially says that users who access data through a secure application do not need to be authenticated on each access."

8.5.16 PowerBroker can authenticate access to any database containing cardholder data that runs on UNIX or Linux.

Log retention and security (DSS sections 10.2-10.5, 10.7)

Issue: The key issue for merchants is to secure audit trails so they cannot be altered. The Checklist recommends log management systems to satisfy this requirement, since they act as both a monitoring tool and a forensics tool.

Requirement 10.7 Retain audit trail history for at least one year, with a minimum of three months available online.

PowerBroker can encrypt logs, so audit trails cannot be altered without decrypting them, which action would be logged by PowerBroker and could be monitored by a policy written to notify administrators of such an action.



10.7 PowerBroker’s logserver can meet the requirement to make 3 months of logs available online; encrypted logs can be securely transmitted to an archive server for a year’s storage. The pbsync command, which starts the log synchronizationprocess, can be used in meeting this requirement. The command takes as an input one or more log servers, port numbers and log file names and uses that information to synchronize the network logs. This component is referred to as the "client". The complete log is transferred from the failover log servers to the primary log server; log files will be merged there into a single log file to make auditing easier, and then synchronized from the master back to the failover servers.

Maintaining Compliance and Safe Harbor Protection

If achieving PCI compliance is like ―ramping up‖a new business, maintaining compliance is like managing ongoing operations—in an industry where government regulation, financial pressure from industry players, technology change, and pressure from consumers all conspire to change the rules on a regular basis. Many security experts think adopting a ―best practices‖approach to security is the most efficient path to compliance, since the thinking behind ―best practices‖ remains valid and doesn‘t change that often—not as often as evolving regulations, and certainly not as often as newly invented threats. The strong, ―exclusion by default‖ model PowerBroker uses for access control is an example of security best-practices thinking. PowerBroker can help organizations achieve compliance with a number of regulations, since it excludes any action not explicitly permitted and may exclude threats that have not yet appeared.

A “safe harbor” is a provision of a statute or regulation that reduces or eliminates a party's liability under the law, on the condition that the party performed its actions in good faith. Legislators include safe-harbor provisions to protect legitimate or excusable violations. Texas House of Representatives Bill 3222, which would have codified PCI DSS into law if it had passed the Texas Senate, provided safe harbor for thosecompanies that are compliant with PCI DSS, but made those merchants who are not compliant liable for card re-issuing fees.7

Once achieved, PCI DSS compliance must be maintained, since organizations must be able to demonstrate compliance at the time of a breach to exercise the safe harbor clause. By securing cardholder data in databases through access control, and cardholder data in PowerBroker logs by encrypting those logs, PowerBroker helps merchants demonstrate continuous PCI DSS compliance, in intent and in fact.

Conclusion

When it comes to protecting cardholder data Gartner says, "Don‘t store information if you don't need it, encrypt it if you can, and put strong access controls around it—and then monitor the access."8 In the October 2007 issue of Information Security Magazine, PowerBroker 5.0 received a "straight A" report card: A in Configuration/Management, A in Policy Control, A in Effectiveness, and A+ in Reporting. Their verdict: ―PowerBroker is a scalable solution that effectively delegates root privileges securely and provides excellent audit trails for regulatory compliance.‖9

By blocking the opportunity for insider malfeasance and error, PowerBroker provides the "strong access control" required by PCI to protect cardholder data. Extensive logs and reports, including an Entitlement Report to assist in establishing accountability, supply the means to demonstrate compliance to an auditor. A powerful scripting language ensures that as PCI requirements evolve, the organization will be able to maintain compliance. PowerBroker secures cardholder data on Linux and UNIX systems throughout the enterprise--including legacy systems, where critical cardholder data is most often processed and stored. PowerBroker's proactive security provides auditable control and prevention to secure sensitive cardholder data stored or processed on UNIX or Linux systems.

pci dss compliance in the unix/linux datacenter...

Documents