WHITE PAPER. Passing UNIX/Linux Audits with BeyondTrust PowerBroker

Transcription

1 WHITE PAPER Passing UNIX/Linux Audits with BeyondTrust PowerBroker

2 Table of Contents Executive Summary 3 Security Issues of Unix and Linux 4 Meeting Audit Requirements with PowerBroker 5 How PowerBroker Works 5 PowerBroker Architecture and Workflow 5 Task execution 6 How PowerBroker Enables Unix/Linux Systems to Meet Audit Requirements 8 By Securing Administrative Privilege and Establishing Best-Practices Security 8 By Extending Logging Capabilities 9 Audit Trails: Logs and Reports Logs 9 Event Log 9 Reports 10 Meeting Requirements Across Multiple Compliance Mandates 11 Conclusion: Successful Audits of UNIX and Linux Systems 13 Cited Sources 13 About BeyondTrust BeyondTrust Software, Inc.

3 Executive Summary A security or compliance audit can be a valuable ally in identifying the vulnerabilities of your UNIX/Linux systems. But since US firms on average must meet three compliance regulations, many would prefer to secure their UNIX/Linux systems before the audit. Gartner recommends that organizations combine compliance requirements and build synergistic solutions. The effort saves time and money as well as establishes a framework for responding to future requirements. 1 PowerBroker enables security best practices for UNIX/Linux systems, such as segregation of duties, individual accountability, and leastprivilege access. Compliance is simplified because the IT controls required by compliance mandates are based on these security best practices, so the security created by PowerBroker satisfies multiple compliance mandates. Supported on all widely used UNIX and Linux platforms, PowerBroker lowers the time and cost needed to create a secure UNIX/Linux infrastructure, even in a heterogeneous UNIX/Linux environment. And since PowerBroker can be deployed without kernel modifications, changes to binaries, or system reboots, disruption to production is minimal. Deployment is measured in weeks--not months--greatly shortening time to compliance. PowerBroker is an access-control application that proactively prevents security breaches. It does this by: Using a strong security design, which denies access by default; Delegating root privilege, so an individual can complete assigned tasks without knowledge of the root password; Tracking activity on shared accounts by an individual s UserID, creating individual accountability; Enabling least privilege access through access control lists (ACLs) and scripts; Enabling the definition of forbidden keystrokes, preventing keystrokes that enable malicious activity; Tracking, logging, and encrypting all activity by a user as he traverses multiple systems, so he can never be invisible within the organization. Some feel that securing UNIX and Linux systems is a minor consideration--haven t there been reports that UNIX is dying? But Fortune 500 and Global 2000 managers know their organization s most sensitive data (especially financial data and intellectual property) resides on UNIX systems. And their faith in the platform is reflected in new investment: Unix servers experienced 1.5% revenue growth year over year when compared with 4Q06. Worldwide Unix revenues were $5.2 billion for the quarter, representing 33.3% of quarterly server spending and reflecting continued IT investment in this server market segment. As for Linux, it s evolved from being the plaything of hobbyists to an enterprise mainstay. In the fourth quarter of 2007 Linux server revenue reached $2.0 billion for the first time in any single quarter on 11.6% year-over-year growth. Linux servers now represent 12.7% of all server revenue, up more than one point over 4Q06. RBAC has become the predominant model for advanced access control because it reduces the complexity and cost of security administration for large networked applications. But each RBAC implementation varies in how it controls access and how it is managed. In a multi-platform environment, these differences introduce higher administration hours and costs, increasing the potential for misconfiguration and related security issues. And since most vendors RBAC implementations are to some extent host-centric, maintenance operations may have to be performed on each host. By contrast, PowerBroker implements consistent, cross- platform access control across all major UNIX and Linux platforms. PowerBroker s centralized access control also controls costs. The product s architecture provides for centralized policy processing and logging that allow highly efficient configuration and maintenance, even in a group of heterogeneous machine types. Using the rich policy language provided in PowerBroker and its Access Control Lists (ACLs), role-based access controls can be quickly deployed in a PowerBroker-managed environment. Using PowerBroker to implement role-based access control allows an organization to efficiently deploy key security and compliance requirements not always found in operating-system RBAC implementations, including separation of duties and audit trails BeyondTrust Software, Inc.

4 As UNIX and Linux systems become more prevalent in organizations, the need to secure them becomes more urgent. This is especially true since compliance mandates, as interpreted by the courts, become more stringent. BeyondTrust PowerBroker secures UNIX and Linux systems, providing the controls needed for your organization to pass PCI DSS, SOX Section 404, HIPAA, GLBA, and other compliance audits. Security Issues of Unix and Linux Designed as a multi-user, multi-process operating system, UNIX was first used in university and laboratory settings, where shared accounts with elevated privilege were the norm for a research team. Only as organizations began using UNIX (and later Linux) for business operations did security become a concern, a concern brought into sharp focus by regulatory compliance. The IT controls mandated by regulatory compliance (for example, by Section 404 of SOX) are taken from recognized security best practices. When the functionality of UNIX and Linux operating systems is examined in light of these practices, security issues surface. For example, best-practices security requires: Access must be controlled for security, not just configured for convenience. Auditors will expect to see access control in place as specified in regulatory compliance and industry security standards. Segregation of Duties (SOD): Segregation of duties is an internal control element of compliance programs because it mitigates errors and opportunities for corporate fraud. For example, users who create data don t have permissions to process their data, and developers don t have permissions to work with client-facing production systems. But segregation of duties with the granularity needed to meet compliance requirements cannot be achieved without individual IDs. Individual Accountability: All compliance mandates require individual accountability, which in turn requires individual IDs. Without them, auditing requirements cannot be met, because an individual who has abused his access privileges cannot be identified and controlled. Even in a world without compliance mandates, individual accountability would be necessary for risk management. Least-Privilege Access: Least-privilege dictates that each individual receive only the access he needs to do his assigned tasks. Password Encryption. Passwords should be encrypted at rest and in transit across the network. Granular Logging of Access and Activity. Logs should be as complete and as granular as possible, preferably with keystroke logging capability. Without logs and reports that supply data on a granular level, auditors cannot determine that individual accountability is being tracked, or that an organization s controls are capable of providing an audit trail. Compliance must be demonstrable to auditors. Yet a security or compliance audit of UNIX and Linux systems reveals that they do not meet security best practices: Shared accounts prevent individual accountability. Compliance mandates like SOX, HIPAA, and PCI all require the establishment of individual accountability for compliance. Yet root, the most powerful account on UNIX and Linux, does not track individual accountability, since actions are logged as root or not logged at all. The same is true for all shared accounts with elevated privilege, such as SAP or Oracle. Too many people have root access. Many users who have only occasional need for root privileges have root access. This violates least privilege and individual accountability best practices. Yet it is not uncommon to see multiple users possess administrator access and privileges to ERP or database applications, to reduce dependency on system administrators BeyondTrust Software, Inc.

5 Non-console root logins can compromise security. When users log in as root to a remote system, the root password is transmitted in plain text, and so can easily be compromised. Unattended root sessions are vulnerable to disgruntled insiders. When a user logs in as root on a system, he has superuser access to all privileged tasks. If this individual leaves his system unattended while logged in, a disgruntled insider can compromise systems or sensitive data. Machines in the network must be configured manually one at a time, often resulting in inconsistent security policies. UNIX/Linux requires that machines be configured one at a time, making consistent security policies across a heterogeneous collection of systems problematic. There are no logs of individual user activity on UNIX/Linux. User auditing for accountability is extremely limited in UNIX/Linux, since no logs of activity by individual users exists. No log of user tasks performed is kept other than by applications that write specific events to the syslog daemon. Moreover, logins are audited by the last utility, which captures only successful logins while the failed logins that may signify a potential threat are not captured. Even more disconcerting, a UNIX/Linux system can be configured so that login event logs are not even enabled. Another weakness in typical UNIX/Linux environments is the inability to capture keystroke logs. This can be crucial when tracking down what actions were taken in a session. How to fill the gap between the design of UNIX/Linux systems and today s compliance requirements? The need is to enable best- practices security on UNIX/Linux systems in a way auditors can see and without kernel modification, changed binaries, or system reboots, which can slow production and cause problems with installed applications. PowerBroker can be deployed without degrading the performance of UNIX/Linux systems and can instill the bestpractices security needed to meet multiple regulatory mandates. Meeting Audit Requirements with PowerBroker HOW POWERBROKER WORKS PowerBroker provides policy-driven access control and logging across most UNIX and Linux platforms. Using a centralized policy server called a PowerBroker Master Host, every request for privileged access through a PowerBroker interface is evaluated by policy. In the policy processing, the request can be accepted or rejected, event and I/O logging turned on or off, and the request can be modified. The modifications could be as simple as removing an incorrect command-line parameter or redirecting the request to run as a different user on a different host. Access can also be managed by day, date and time, user ID and group membership. PowerBroker s rich policy language provides the capability to address almost any conceivable business or compliance requirement for privileged access. POWERBROKER ARCHITECTURE AND WORKFLOW 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. PowerBroker Architecture and Workflow. PowerBroker s architecture and workflow allow for flexibility while maintaining security best practices. PowerBroker s architecture is fully compatible with existing network architectures and security devices, including firewalls and routers. A typical PowerBroker configuration consists of four software modules: pbrun, pbmasterd, pblocald, and pblogd. 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 BeyondTrust Software, Inc.

6 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: TASK EXECUTION pblocald, pbrun, pbsh or pbksh. pblocald executes task requests that have passed security verification processing. 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 PowerBroker user interface (pbrun, pbsh, pbksh) 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. PowerBroker also supports optimized run mode where the PowerBroker user interface (pbrun, pbsh or pbksh) acts as pblocald to run a job that executes on the same host as it was submitted from. When the jo.b is submitted and executes on the same host, optimized run mode consumes fewer machine resources. 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 optimizes PowerBroker processing by centralizing the writing of log records in a single, dedicated component, eliminating the need for the pbmasterd process to wait for task execution to complete. PowerBroker Functionality. With PowerBroker, privileged access is not restricted to just the root account. PowerBroker can execute requests as any valid UNIX or Linux user accessing an application or database account. The account under which that user will run the BeyondTrust Software, Inc.

7 request can be specified by the user when the request is submitted, and it can be evaluated and changed during policy processing. PowerBroker event and I/O logging is performed on PowerBroker Log Hosts, which can be on the same or a different machine than the PowerBroker Master Host, or any other PowerBroker component for that matter. During the policy processing, the type of logging to be performed and the log file that the entries will be written to can be set. Requests can be logged in to different log files based on user, host or any other variable evaluated during policy processing. Authorized users, via either a command-line or web-based PowerBroker Console, can review log entries. The PowerBroker architecture of performing policy processing on remote Master Hosts and logging on remote Log Hosts provides an inherent separation of duty relationship between PowerBroker administrators and PowerBroker users, as the PowerBroker users need not have any access to the Master and Log Hosts. This architecture also helps prevent unintended privilege escalation issues by isolating the policy files from the hosts where the PowerBroker users will be granted access. PowerBroker provides multiple interfaces for making privileged access requests, all of which are evaluated by policy and logged. The pbrun command can be used to execute single commands or scripts, as well as to open a shell as a privileged user. The PowerBroker shells, pbsh and pbksh, are secured equivalents of sh and ksh, respectively. Each command executed through the shell, as well as the opening of the shell itself, is evaluated by policy. Finally, PowerBroker provides secured versions of several common UNIX and Linux utilities, pbvi, pbnvi, pbmg, pbumacs and pbless. For example, pbvi allows the editing of a file as the root or other privileged user, but disallows accessing other files or spawning new processes as the privileged user. PowerBroker policy language can be maintained either using a text editor or through PowerBroker s web-based Console. The Policy Editor in the PowerBroker Console presents the Policy in a tree-based hierarchy, automatically broken down into the programmatic functions of the policy. Web-based Smart Editors, which include online command syntax, can be used to quickly construct policy components. Like any good programming language, the PowerBroker policy language allows compartmentalizing logic in individual policy files, and then using include statements at run-time to implement the compartmentalized logic. PowerBroker s policy language also includes Access Control List (ACL) syntax. ACLs simplify the definition of access privileges. Using a simple list, a PowerBroker administrator can specify the most commonly used PowerBroker access control mechanisms for users without having to compose PowerBroker policy scripts. ACLs provide the capability to accept or reject access based on user, command, host the request was submitted on, and host the request will be executed on. The ACL can also be extended with conditional and pre-execution functions written in the PowerBroker policy language. The ACL syntax commands accept and reject can be freely intermixed in any PowerBroker policy, allowing customers to begin with a simple ACL-based access control system and then add PowerBroker policy language extensions. 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, stored on each machine in the /etc/pb.settings file, include: Masters : Allows administrators to define PowerBroker master servers to 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 BeyondTrust Software, Inc.

8 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 components and to exchange encryption-key information. Firewalls: PowerBroker can operate in environments where firewalls are used to separate clients and servers. RBAC has become the predominant model for advanced access control because it reduces the complexity and cost of security administration for large networked applications. But each RBAC implementation varies in how it controls access and how it is managed. In a multi-platform environment, these differences introduce higher administration hours and costs, increasing the potential for misconfiguration and related security issues. And since most vendors RBAC implementations are to some extent host-centric, maintenance operations may have to be performed on each host. By contrast, PowerBroker implements consistent, cross- platform access control across all major UNIX and Linux platforms. PowerBroker s centralized access control also controls costs. The product s architecture provides for centralized policy processing and logging that allow highly efficient configuration and maintenance, even in a group of heterogeneous machine types. Using the rich policy language provided in PowerBroker and its Access Control Lists (ACLs), role-based access controls can be quickly deployed in a PowerBroker-managed environment. Using PowerBroker to implement role-based access control allows an organization to efficiently deploy key security and compliance requirements not always found in operating-system RBAC implementations, including separation of duties and audit trails. How PowerBroker Enables Unix/Linux Systems to Meet Audit Requirements Gartner points out that superuser accounts have almost unlimited privileges and access rights. Routinely sharing superuser account passwords gives rise to significant risks....poorly controlled use of shared accounts cannot provide the individual accountability that is a security best practice and demanded by regulatory compliance. PowerBroker secures superuser accounts by enabling security best practices: delegation of privilege, which establishes least- privilege access while hiding the password to the superuser account; segregation of duties, which organizations can customize to their needs using PowerBroker ACLs and scripts; individual accountability, by tracking users through their User IDs; and the creation of audit trails through extensive logs and reports. BY SECURING ADMINISTRATIVE PRIVILEGE AND ESTABLISHING BEST-PRACTICES SECURITY PowerBroker delegates the root account by binding the tasks an individual is assigned to perform to his UNIX UserID. For example, if root access is needed for a junior administrator to modify access privileges for several users, the junior administrator s UserID is bound to this task, and he is able to perform it without knowing the root password. This greatly reduces risk, because very few people need to know the root password. Running UNIX/Linux systems without PowerBroker may require divulging the root password to all users who have even the smallest amount of administrative job function. Delegation prevents the abuse of full root power, such as the modification or deletion of corporate databases. PowerBroker can be configured to grant or deny access to group account programs in the same way it grants or denies access to the root account. Since the group account password is not given out, the risk that it will become known to unauthorized users is greatly reduced. This also allows the group account password to be preserved even when a single user s access to the group is revoked, making password management less subject to error. PowerBroker can also restrict administrative privileges for mission-critical applications such as ERP and CRM. Administrators can authorize specific UNIX privileges for any user s account ID, including privileges that require root or special account passwords (e.g., Oracle). The PowerBroker policy language allows the run- time environment of all root or group account programs to be fully specified, eliminating the risk that a flawed or modified run-time environment might allow actions other than those a user is authorized to perform. This reduces the risk of sensitive data s being illegally accessed from the UNIX/Linux BeyondTrust Software, Inc.

9 command line. It also prevents the after-hours abuse of administrative privilege, since PowerBroker can be configured to restrict access to root or group account privileges at specified times. PowerBroker s root delegation also enables least- privilege access, since users now have access only to the tasks they are required to perform. Remote logins that expose the root password in clear text are also eliminated, since individuals can log in remotely using their own passwords. UNIX/Linux has no way to link the use of a shared account with elevated privilege back to an individual user. By using individual user ID s, PowerBroker s root delegation establishes individual accountability, as required by regulatory compliance. Individual audit trails and overall security are further enhanced because PowerBroker has master daemons residing on the network that accept or reject individual users requests to run programs according to policies in a configuration file. BY EXTENDING LOGGING CAPABILITIES UNIX/Linux provides no selective mechanism for logging programs run in the root account. UNIX/Linux accounting records every activity on the system, creating a huge amount of raw data. And this data is not secure. Since root privileges include the ability to modify or delete any file on the system, it s easy for someone with root access to erase from the accounting logs any actions he wants to conceal. PowerBroker can log all system administrative actions taken by users on a separate logging machine. PowerBroker s audit logs contain a full working record of which actions were performed by which people, when, and on which machines. This includes programs used to query, extract, and present information selectively from the log files. Log files can also be viewed from a standard Web browser, making it possible for an administrator to view them from any Internet- enabled location. PowerBroker can record all keystrokes (all I/O) generated during a session. A replay program allows authorized individuals to replay a recorded session, seeing exactly what was typed and exactly what appeared on the screen. Keystroke logging provides evidence of who was responsible for a root action, exactly what was done, and what the immediate effect was, and can easily be demonstrated for auditors. AUDIT TRAILS: LOGS AND REPORTS LOGS PowerBroker encrypts, tracks, and logs all activity by a user as he traverses multiple systems, so he can never be invisible within the organization. PowerBroker logs and its GUI report writer make it easy to create reports to demonstrate compliance. 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 then are 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 show that the PowerBroker log data has not been altered. PowerBroker can record all actions performed under its policies, down to the keystroke level. Accurately logging actions in a secure environment creates a secure 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. PowerBroker logs extensive data in the Event Log, I/O Log, Syslog, system login records, keystroke logs, and user-defined logs. 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 user requested the program; BeyondTrust Software, Inc.

10 What machine he was on; What program(s) a user attempts to run; 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 privileged account, or a user account). The Event Log can be reviewed through the PowerBroker GUI or with the pblog command. PowerBroker can also log these events to the Syslog system. Data can be made available in CSV or XML format. I/O LOG AND KEYSTROKE LOGGING The I/O Log can log individual keystrokes as well as what is displayed on the screen. This includes when and where the session occurred, the resulting output, and any errors. There are options for fine tuning the amount of data that will be logged, to ensure that data required for compliance mandates is captured. 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. PowerBroker also can I/O Log only specific programs and users. Because PowerBroker can let administrators view session keystrokes in real time, it can let administrators stop a breach in progress. Administrators can also view an entire recorded session by a suspect employee, seeing the keystrokes just as they appeared during the session. These sessions can be played back for auditors. 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 and wtmp. PowerBroker also records logins using PAM (Pluggable Authentication Module) modules for Kerberos; SecurID; Smartcards; and LDAPv2; as well as logins that use (IBM s Loadable Authentication Module, used on AIX) 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 record information needed to demonstrate compliance in your line of business, as advised by your internal auditor. User-defined logs can be encrypted and stored on a separate machine to facilitate forensics and auditing. REPORTS PowerBroker can generate Event Log reports and Entitlement Reports to include complete data for a defined period of time, or just the data types specified by the user and filtered by the parameters he chooses. Authorized users can 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 will be indicated in the Entitlement Report. These reports show auditors that segregation of duties is being enforced and steps being taken to create a secure access-control infrastructure BeyondTrust Software, Inc.

11 PowerBroker Entitlement Reports include a built- in GUI report writer that combines a Web-based interface with a wizard-style workflow, eliminating the need to create 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 Run command Run host User Run argv Run user Command Iolog (yes/no) (Long form only) Policy file name (Long form only) Argv Dependencies (Long form only) Policy line number (Long form only) Accept/reject/error text Master host (Long form only) Constraints semi-colon separated (Long form only) Administrators and auditors can edit pbcheck to specify what filters to use when generating a report. For example, pbcheck can be filtered to produce an Entitlement Report showing what users can run the pbvi command. The screen shot that follows shows the Entitlement Report by System. Entitlement Report: Report by System Meeting Requirements Across Multiple Compliance Mandates The following table shows how PowerBroker addresses security requirements that span multiple compliance mandates Requirement Regulation/ Mandate PowerBroker Support Security Planning and Process HIPAA, NISPOM, PCI PB can be used to create, document, review, and modify UNIX task authorization policies for specified users, groups of users, or job functions/roles, enabling specific UNIX tasks under a variety of environmental conditions. PB logs can be used in security planning by identifying insecure behaviors that leave access to UNIX/Linux resources vulnerable. Strong Authentication HIPAA, NISPOM, PCI, 21 CFR Part 11 PB can require password authentication, including root or other special passwords. Additionally, PB provides PKI support using OpenSSL which offers additional public/private key authentication for PB components. Using BeyondTrust Software, Inc.

12 PAM, PB supports Kerberos, SecurID, Smartcards, and LDAPv2. PB also supports LAM. Access Control: System GLBA, PCI, SOX, 21 CFR Part 11 PB policies provide granular controls for which users may access which UNIX/Linux system commands, directories, and files. Access Control: Data GLBA, NISPOM, PCI, SOX, 21 CFR Part 11 PB policies provide granular controls for which users may access which commands, directories, and files. PB can also delegate privileges for 3rdparty application generic accounts, like Oracle, SAP, etc. Access Control: Media HIPAA PB can allow or deny access to media devices, or to specific related commands (e.g., mount). Data Integrity HIPAA, NISPOM, PCI, 21 CFR Part 11 PB logs all UNIX/LINUX task requests, acceptances, and rejections, including all I/O down to the keystroke, in order to verify data integrity or what modifications may have taken place. Task Authorization GLBA, 21 CFR Part 11 PB provides granular delegation of UNIX/Linux task privileges across more than 30 UNIX/Linux platforms. Encryption (both transmission and storage) GLBA, HIPAA, PCI, SB1386, SOX, 21 CFR Part 11 All task requests made by a user are encrypted as they are communicated to the PB Master, as are communications between the PB Master and executing Local host, the PB log server, etc. PB supports several algorithms including AES and TripleDES. Intrusion Monitoring and Response GLBA, SB1386, SOX PB policies and logs can be used to monitor suspicious activities by setting specified alerts and notifications. PB can secure specified tasks with policies requiring secondary authentication, and administrator alerts on rejected tasks. Auditing HIPAA, NISPOM, PCI, SB1386, SOX, 21 CFR Part 11 PB logs all UNIX/LINUX task requests, acceptances, and rejections, including all I/O down to the keystroke. PB logs can be encrypted and secured by mandatory authentication techniques BeyondTrust Software, Inc.

13 Conclusion: Successful Audits of UNIX and Linux Systems Passing UNIX and Linux security and compliance audits requires finding a way to compensate for certain inherent vulnerabilities of these operating systems. By enabling best-practices security, BeyondTrust PowerBroker supports multiple compliance mandates, including PCI, HIPAA, SOX, and GLBA. With PowerBroker, organizations can secure their heterogeneous UNIX/Linux environment, resulting in successful audits. Cited Sources 1 Understanding the Costs of Compliance, John Bace, Carol Rozwell, Joseph Feiman, and Bill Kirwin, Gartner Research, July 7, Worldwide Server Market Experiences Modest Growth in Fourth Quarter as Market Revenues Reach Seven-Year High in 2007, According to IDC, IDC Press Release, 27 Feb Gartner points out that segregation of duties was the single largest people issue creating weaknesses and deficiencies in the first 276 material weaknesses filed with the U.S. Securities and Exchange Commission after SOX Section 404 went into effect on November 15, Examine Sarbanes-Oxley Section 404 Weaknesses and Use IT as Your Solution, Gartner Research, 5 August 2005, p Best Practices for Managing Shared Superuser and Firecall Accounts, Ant Allan, Gartner Research, 28 March 2008, p. 1. 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.