Pass UNIX/Linux Audits with Symark PowerBroker A Symark White Paper

Pass UNIX/Linux Audits with Symark PowerBroker

-May 2008

This white paper explains why the design of UNIX and Linux systems prevents them from passing today's
security and compliance audits, and how Symark PowerBroker can bring these systems into compliance with
multiple mandates such as PCI DSS (the Payment Card Industry Data Security Standard), the Sarbanes-Oxley
Act (SOX), the Health Insurance Portability and Accountability Act (HIPAA), and the Gramm-Leach Bliley Act
(GLBA). How PowerBroker addresses such UNIX/Linux security issues as the shared use of accounts with
elevated privilege and the absence of least-privilege access control is described. A table shows the security
and compliance requirements PowerBroker meets in specific compliance mandates. How PowerBroker creates
RBAC-like access control that simplifies and lowers the costs security administration across heterogeneous
platforms is also explained.

30401 Agoura Road, Suite 200

Agoura Hills, CA 91301
Tel: (818) 575-4000
Fax: (818) 889-1894
Email: [email protected]
Website: www.symark.com

Symark PowerKeeper is a registered trademark of Symark Software.

Other names are trademarks and registered trademarks of their respective holders.

30401 Agoura Road, Suite 200, Agoura Hills, CA 91301 Page 1 of 11

800.234.9072 2008 Symark Software, Inc. All rights reserved. Rev. 05/11/08
Pass UNIX/Linux Audits with Symark PowerBroker A Symark White Paper

Contents

Executive Summary 3

Security Issues of UNIX and Linux Systems

Meeting Audit Requirements with PowerBroker

How PowerBroker Works
How PowerBroker Enables UNIX/Linux
Systems to Meet Audit Requirements
Audit Trails: Logs and Reports

Meeting Requirements Across Multiple Compliance Mandates

Conclusion: Successful Audits of UNIX and Linux Systems

Notes and Citations

30401 Agoura Road, Suite 200, Agoura Hills, CA 91301 Page 2 of 11

800.234.9072 2008 Symark Software, Inc. All rights reserved. Rev. 05/11/08
Pass UNIX/Linux Audits with Symark PowerBroker A Symark White Paper

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
1
effort saves time and money as well as establishes a framework for responding to future requirements."
PowerBroker enables security best practices for UNIX/Linux systems, such as segregation of duties, individual
accountability, and least-privilege 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
2
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.

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.
Symark 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.

30401 Agoura Road, Suite 200, Agoura Hills, CA 91301 Page 3 of 11

800.234.9072 2008 Symark Software, Inc. All rights reserved. Rev. 05/11/08
Pass UNIX/Linux Audits with Symark PowerBroker A Symark White Paper

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 Control: 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
3
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.
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

30401 Agoura Road, Suite 200, Agoura Hills, CA 91301 Page 4 of 11

800.234.9072 2008 Symark Software, Inc. All rights reserved. Rev. 05/11/08
Pass UNIX/Linux Audits with Symark PowerBroker A Symark White Paper

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 best-practices 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 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

30401 Agoura Road, Suite 200, Agoura Hills, CA 91301 Page 5 of 11

800.234.9072 2008 Symark Software, Inc. All rights reserved. Rev. 05/11/08
Pass UNIX/Linux Audits with Symark PowerBroker A Symark White Paper

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.
User task submission: pbrun. pbrun is the PowerBroker component that receives task requests; all secured
tasks must be submitted through pbrun. A separate pbrun process is started for each secured task request
that is submitted. If the use of pbrun is not enforced for secured tasks, a company’s security policy
implementation may be compromised.
Security policy file processing: pbmasterd. pbmasterd applies the security rules defined in the
PowerBroker security policy files. pbmasterd performs security verification processing to determine whether to
accept or reject a request, based on these security rules. If a request is rejected, the result is logged and
processing terminates. If a request is accepted, it is passed to pblocald for execution.
Task execution: pblocald, 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 job 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 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

30401 Agoura Road, Suite 200, Agoura Hills, CA 91301 Page 6 of 11

800.234.9072 2008 Symark Software, Inc. All rights reserved. Rev. 05/11/08
Pass UNIX/Linux Audits with Symark PowerBroker A Symark White Paper

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 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
4
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

30401 Agoura Road, Suite 200, Agoura Hills, CA 91301 Page 7 of 11

800.234.9072 2008 Symark Software, Inc. All rights reserved. Rev. 05/11/08
Pass UNIX/Linux Audits with Symark PowerBroker A Symark White Paper

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 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

30401 Agoura Road, Suite 200, Agoura Hills, CA 91301 Page 8 of 11

800.234.9072 2008 Symark Software, Inc. All rights reserved. Rev. 05/11/08
Pass UNIX/Linux Audits with Symark PowerBroker A Symark White Paper

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;
 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.
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)

30401 Agoura Road, Suite 200, Agoura Hills, CA 91301 Page 9 of 11

800.234.9072 2008 Symark Software, Inc. All rights reserved. Rev. 05/11/08
Pass UNIX/Linux Audits with Symark PowerBroker A Symark White Paper

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/ PowerBroker Support

Mandate
Security Planning and HIPAA, NISPOM, PCI PB can be used to create, document, review, and modify UNIX task authorization policies for
Process 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, PB can require password authentication, including root or other special passwords.
PCI, 21 CFR Part 11 Additionally, PB provides PKI support using OpenSSL which offers additional public/private
key authentication for PB components. Using PAM, PB supports Kerberos, SecurID,
Smartcards, and LDAPv2. PB also supports LAM .
Access Control: System GLBA, PCI, SOX, 21 PB policies provide granular controls for which users may access which UNIX/Linux system
CFR Part 11 commands, directories, and files.
Access Control: Data GLBA, NISPOM, PCI, PB policies provide granular controls for which users may access which commands,
SOX, 21 CFR Part 11 directories, and files. PB can also delegate privileges for 3rd-party 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, PB logs all UNIX/LINUX task requests, acceptances, and rejections, including all I/O down to
21 CFR Part 11 the keystroke, in order to verify data integrity or what modifications may have taken place.
Task Authorization GLBA, 21 CFR Part PB provides granular delegation of UNIX/Linux task privileges across more than 30
11 UNIX/Linux platforms.
Encryption (both GLBA, HIPAA, PCI, All task requests made by a user are encrypted as they are communicated to the PB Master,
transmission and SB1386, SOX, 21 as are communications between the PB Master and executing Local host, the PB log server,
storage) CFR Part 11 etc. PB supports several algorithms including AES and TripleDES.
Intrusion Monitoring and GLBA, SB1386, SOX PB policies and logs can be used to monitor suspicious activities by setting specified alerts
Response and notifications. PB can secure specified tasks with policies requiring secondary
authentication, and administrator alerts on rejected tasks.
Auditing HIPAA, NISPOM, PCI, PB logs all UNIX/LINUX task requests, acceptances, and rejections, including all I/O down to
SB1386, SOX, 21 the keystroke. PB logs can be encrypted and secured by mandatory authentication
CFR Part 11 techniques.

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, Symark 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.

30401 Agoura Road, Suite 200, Agoura Hills, CA 91301 Page 10 of 11

800.234.9072 2008 Symark Software, Inc. All rights reserved. Rev. 05/11/08
Pass UNIX/Linux Audits with Symark PowerBroker A Symark White Paper

Notes and Citations

1
"Understanding the Costs of Compliance," John Bace, Carol Rozwell, Joseph Feiman, and Bill Kirwin, Gartner Research,
July 7, 2006.
2
"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 2008.
3
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, 2004. "Examine Sarbanes-Oxley Section 404 Weaknesses and Use IT as Your Solution," Gartner
Research, 5 August 2005, p. 4.
4
"Best Practices for Managing Shared Superuser and Firecall Accounts," Ant Allan, Gartner Research, 28 March 2008, p. 1.

30401 Agoura Road, Suite 200, Agoura Hills, CA 91301 Page 11 of 11

800.234.9072 2008 Symark Software, Inc. All rights reserved. Rev. 05/11/08