Documente Academic
Documente Profesional
Documente Cultură
Table of Contents
Executive Summary PowerBroker for Servers and PCI DSS Compliance How PowerBroker for Servers Works PowerBroker for Servers Components How PowerBroker for Servers Works How PowerBroker for Servers Supports PCI DSS Requirements Designed for Best-Practices Security Individual accountability on shared accounts Maintaining Compliance and Safe Harbor Protection Conclusion About BeyondTrust 3 4 4 4 5 6 11 12 13 13 14
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 Serverss 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 users 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. PCI DSS Compliance in UNIX/LINUX Datacenter Environ. 3 2013. BeyondTrust Software, Inc.
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.
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 organizations 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. PCI DSS Compliance in UNIX/LINUX Datacenter Environ. 5 2013. BeyondTrust Software, Inc.
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.
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 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 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 Serverss pbkey command generates an encryption key suitable for any of PowerBroker for Serverss encryption algorithms, and stores it in a file. This files name is specified on PowerBroker for Serverss 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 PCI DSS Compliance in UNIX/LINUX Datacenter Environ. 7 2013. BeyondTrust Software, Inc.
abuse or accident. 3.5.1 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. 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 for Servers 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 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 Serverss 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 users 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 Serverss policy-writing language allows specification of highly granular attributes for access; these can be based on each organizations 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; PCI DSS Compliance in UNIX/LINUX Datacenter Environ. 8 2013. BeyondTrust Software, Inc.
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 Serverss 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 transmission30 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. 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 for Servers can log all the events listed for UNIX and Linux systems. PowerBroker for Serverss 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. 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 9 2013. BeyondTrust Software, Inc.
10.3.5 Origination of event 10.3.6 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. 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 for Servers logs can be encrypted, satisfying the objective of Requirement 10.5 for UNIX- and Linux- based systems. 10.5.1: 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: 10.5.2, and 3: Encryption makes PowerBroker for Servers 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 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 couldnt 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.
10
If Ellen requests a command outside office hours, this one-line policy will reject her request, enforcing the organizations security policy. Access Control Lists (ACLs). PowerBroker for Serverss 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 users 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 for Serverss 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 Serverss ACLs specify the user, submithost, command, and runhost. For example, PowerBroker for Serverss ACL can have specifications such as: Joe on Host 265 can kill a root-owned process on =Host 10.||
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).
Conclusion
When it comes to protecting cardholder data Gartner says, Dont store information if you dont need it, encrypt it if you can, and put strong access controls around itand 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 Serverss proactive security PCI DSS Compliance in UNIX/LINUX Datacenter Environ. 13 2013. BeyondTrust Software, Inc.
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 worlds 10 largest banks, seven of the worlds 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 1.800.234.9072 sales@beyondtrust.com EMEA SALES Tel: + 44 (0) 8704 586224 emeainfo@beyondtrust.com CORPORATE HEADQUARTERS 550 West C Street, Suite 1650 San Diego, CA 92101 1.800.234.9072 CONNECT WITH US Twitter: @beyondtrust Facebook.com/beyondtrust Linkedin.com/company/beyondtrust www.beyondtrust.com
14