WHITE PAPER. PCI DSS Compliance in the UNIX/LINUX Datacenter Environment

Transcription

1 WHITE PAPER PCI DSS Compliance in the UNIX/LINUX Datacenter Environment

2 Table of Contents Executive Summary 3 PowerBroker for Servers and PCI DSS Compliance 4 How PowerBroker for Servers Works 4 PowerBroker for Servers Components 4 How PowerBroker for Servers Works 5 How PowerBroker for Servers Supports PCI DSS Requirements 6 Designed for Best-Practices Security 11 Individual accountability on shared accounts 12 Maintaining Compliance and Safe Harbor Protection 13 Conclusion 13 About BeyondTrust BeyondTrust Software, Inc.

3 Executive Summary PCI 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. 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. BeyondTrust PowerBroker for Servers 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 for Servers controls and monitors access to database, CRM applications administrators and end-users may need to access, and which may contain customer credit card data. Not only can PowerBroker for Servers 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 for Servers 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 for Servers 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 for Servers then logs all actions taken by that user. PowerBroker for Servers 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 for Servers is a policy-driven solution and highly user configurable thus making it perfect for meeting standards that are often subject to many revisions and refinement. With its powerful scripting language, PowerBroker for Servers can map to changing regulatory requirements and internal security policies. By controlling authorization at the system, application, and file level, PowerBroker for Servers provides control at the best-practices close to the data level. PowerBroker for Servers 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 BeyondTrust Software, Inc.

4 PowerBroker for Servers and PCI DSS Compliance HOW POWERBROKER FOR SERVERS WORKS PowerBroker for Servers lets root authority be delegated or partitioned without compromising root security. PowerBroker for Servers 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 for Servers 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 for Servers secures cardholder data and prevents the deletion of logged events and audit trails. PowerBroker for Servers 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 for Servers s policy language. With PowerBroker for Servers, 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 for Servers also grants user access to files, directories, and third-party applications and accounts (such as database, CRM, ERP, SAP, or generic accounts). PowerBroker for Servers authorizes users to perform the root actions for which they are responsible, but no other commands or programs requiring the root account. With PowerBroker for Servers, the user requests that a program be run as root (or as another privileged UNIX or Linux account, such as dba on Oracle). PowerBroker for Servers evaluates the request. If the request is accepted, PowerBroker for Servers 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 for Servers 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 for Servers 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 for Servers establishes the cornerstone requirements of compliance: security and accountability. PowerBroker for Servers 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 FOR SERVERS COMPONENTS A typical PowerBroker for Servers configuration consists of four software modules: pbrun, pbmasterd, pblocald, and pblogd. User task submission: pbrun pbrun is the PowerBroker for Servers 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 for Servers 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 BeyondTrust Software, Inc.

5 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 for Servers Event Log, via pbmasterd or pblogd, depending on how PowerBroker for Servers has been deployed. The Run Host can also record task keystroke information to a PowerBroker for Servers I/O Log. Logging: pblogd pblogd is an optional PowerBroker for Servers 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 for Servers 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. HOW POWERBROKER FOR SERVERS WORKS The PowerBroker for Servers settings file: pb.settings. Although PowerBroker for Servers 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 for Servers master servers to either request or accept permissions BeyondTrust Software, Inc.

6 Log Servers: Allows administrators to define a single, central server to consolidate all PowerBroker for Servers 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 for Servers communication among submitting machines, the PowerBroker for Servers Master server, and executing machines. All policies and log files can be encrypted, further securing PowerBroker for Servers authorization. SSL: Administrators can enable public-key infrastructure support, using SSL for certificate and key management. Kerberos: PowerBroker for Servers can use Kerberos to authenticate its various components and to exchange encryption-key information. Firewalls: PowerBroker for Servers can operate in very secure environments where firewalls are used to separate clients and servers. How PowerBroker for Servers Supports PCI DSS Requirements Published 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 Network 1. 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 Data 3. Protect stored data 4. Encrypt transmission of cardholder data and sensitive information across public networks Maintain a Vulnerability Management Program 5. 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 Networks 10. 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 BeyondTrust Software, Inc.

7 2. Do not use vendor-supplied defaults for system passwords and other security parameters. PowerBroker for Servers 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 for Servers 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 for Servers. Also, the policies you create and store in the PowerBroker for Servers 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 for Servers 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 for Servers can encrypt network traffic, including traffic generated by an administrator using its Webbased 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 for Servers 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 for Servers supports over 30 different types of encryption to secure network traffic, logs and configuration files including AES 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 for Servers 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 for Servers s pbkey command generates an encryption key suitable for any of PowerBroker for Servers s encryption algorithms, and stores it in a file. This file s name is specified on PowerBroker for Servers 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 for Servers to control user behavior, protecting against BeyondTrust Software, Inc.

8 abuse or accident Restrict access to keys to the fewest number of custodians necessary PowerBroker for Servers 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 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 for Servers logs containing PAN data would be sent over the network encrypted, the key management processes and procedures described in response to Requirements 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 for Servers 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 for Servers 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 for Servers 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 for Servers 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 for Servers 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 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 for Servers 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; BeyondTrust Software, Inc.

9 token devices (for example, SecurID, certificates, or public key); or biometrics PowerBroker for Servers can use Pluggable Authentication Modules (PAM) for authentication on systems where it is available. PowerBroker for Servers 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 for Servers uses passwords to authenticate users. For example, a user who wants to use the PowerBroker for Servers GUI is authenticated by checking the entered user name and password against the UNIX passwords on the host running pbguid (the PowerBroker for Servers GUI daemon). All PowerBroker for Servers client and server programs can use Kerberos Version 5 for authentication. If PowerBroker for Servers 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 for Servers passwords are encrypted during transmission 30 symmetric encryption algorithms are supported. PowerBroker for Servers also supports SSL/TLS. PowerBroker for Servers 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 for Servers ensures proper user authentication through individual IDs and passwords especially for administrators. PowerBroker for Servers 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 for Servers links all access to UNIX- and Linux-based system components to individual users by binding specific root-level tasks to UNIX/Linux user IDs Implement automated audit trails for all system components to reconstruct the following events: All individual user accesses to cardholder data All actions taken by any individual with root or administrative privileges Access to all audit trails Invalid logical access attempts Use of identification and authentication mechanisms Initialization of the audit logs Creation and deletion of system-level objects. PowerBroker for Servers can log all the events listed for UNIX and Linux systems. PowerBroker for Servers s event log records every PowerBroker for Servers 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 Record at least the following audit trail entries for all system components for each event: User identification Type of event Date and time Success or failure indication BeyondTrust Software, Inc.

10 Origination of event Identity or name of affected data, system component, or resource. PowerBroker for Servers logs all these audit-trail items by default for UNIX- and Linux-based systems Secure audit trails so they cannot be altered Limit viewing of audit trails to those with a job-related need Protect audit trail files from unauthorized modifications Promptly back-up audit trail files to a centralized log server or media that is difficult to alter 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 for Servers logs can be encrypted, satisfying the objective of Requirement 10.5 for UNIX- and Linux- based systems : PowerBroker for Servers best-practices security recommends limiting access to logs to the highest-level administrators only; this can be enforced by a PowerBroker for Servers policy: , and 3: Encryption makes PowerBroker for Servers logs impossible to alter : 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 Retain audit trail history for at least one year, with a minimum of three months online availability. PowerBroker for Servers 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 for Servers 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 for Servers 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 for Servers, what you find is the anatomy of best- practices security BeyondTrust Software, Inc.

11 Designed for Best-Practices Security Using PowerBroker for Servers, 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 for Servers 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 for Servers 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 for Servers 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 for Servers 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 for Servers 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 for Servers 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 for Servers to restrict commands using time constraints: reject from ellen when timebetween (1700, 0800) dayname in { Sat, Sun }; BeyondTrust Software, Inc.

12 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 for Servers s Access Control Lists simplify the definition of access privileges. Using a simple ACL, system administrators can specify the most commonly used PowerBroker for Servers 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 ) and strong access control (Requirement 8). PowerBroker for Servers 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 for Servers s ACLs specify the user, submithost, command, and runhost. For example, PowerBroker for Servers 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 for Servers 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 for Servers 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 for Servers 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 for Servers 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 for Servers 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 Functionality. PowerBroker for Servers 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 BeyondTrust Software, Inc.

13 which system it was executed, and when this was done. Event Log. PowerBroker for Servers 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). 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 for Servers uses for access control is an example of security bestpractices thinking. PowerBroker for Servers 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 those companies 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 for Servers logs by encrypting those logs, PowerBroker for Servers 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 for Servers 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 for Servers is a scalable solution that effectively delegates root privileges securely and provides excellent audit trails for regulatory compliance. By blocking the opportunity for insider malfeasance and error, PowerBroker for Servers 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 for Servers secures cardholder data on Linux and UNIX/LINUX systems throughout the enterprise--including legacy systems, where critical cardholder data is most often processed and stored. PowerBroker for Servers s proactive security BeyondTrust Software, Inc.

14 provides auditable control and prevention to secure sensitive cardholder data stored or processed on UNIX or Linux systems. About BeyondTrust With more than 25 years of global success, BeyondTrust is the pioneer of Privileged Identity Management (PIM) and vulnerability management solutions for dynamic IT environments. More than half of the companies listed on the Dow Jones Industrial Average rely on BeyondTrust to secure their enterprises. Customers include eight of the world s 10 largest banks, seven of the world s 10 largest aerospace and defense firms, and six of the 10 largest U.S. pharmaceutical companies, as well as renowned universities. The company is privately held, and headquartered in Carlsbad, California. For more information, visit beyondtrust.com. CONTACT INFO NORTH AMERICAN SALES sales@beyondtrust.com EMEA SALES Tel: + 44 (0) emeainfo@beyondtrust.com CORPORATE HEADQUARTERS 550 West C Street, Suite 1650 San Diego, CA CONNECT WITH US Facebook.com/beyondtrust Linkedin.com/company/beyondtrust BeyondTrust Software, Inc.