IBM i SECURITY

EVENT LOGGING &

ACTIVE MONITORING
A STEP BY STEP GUIDE
“
Active monitoring and log collection are at the top of the list of effec-
tive security controls. IBM i (AS/400, iSeries) users have to solve some
special challenges to implement this critical security control. IBM i cus-
tomers often run multiple back-office applications on the IBM i server
and it is a well-known repository for sensitive information and an active
target of cyber criminals and state actors. In this eBook we discuss the
core requirements for a successful active monitoring strategy, how to
identify sources of security information on the IBM i platform, and steps

”
you can take to implement an IBM i active monitoring solution.

Patrick Townsend, Founder & CEO,

Townsend Security

Page 2
 SECURITY ARCHITECTURE

Active monitoring (sometimes referred to as IT infrastructure to gain the best early detection
Continuous Monitoring) is a critical security control for opportunities.
all organizations. And it is one of the most effective
security controls you can deploy. The large majority REAL TIME EVENT COLLECTION
of security breaches occur on systems that have
been compromised days, weeks, or even months Data breaches are happening much faster than in
before sensitive data is lost. A recent Verizon Data the past. In some cases the loss of data happens just
Breach Investigations Report1 indicates that a full 84 minutes after the initial breach. This means that you
percent of all breaches were detected in system must collect security events in real time. Good active
logs. This is why the Center monitoring solutions are able
for Internet Security includes
active monitoring as a Critical “
A recent Verizon Data
to digest threat information
in real time and give you the
Security Control (Control Breach Investigations Report chance to deter them. Avoid
number 6). indicates that a full 84 percent batch event collection – you
of all breaches were detected can collect IBM i security audit
There are several elements
of a truly effective Active
Monitoring strategy:
in system logs.
” journal information in real time
and you should.

EVENT CORRELATION
CENTRAL COLLECTION AND
REPOSITORY OF ALL EVENTS Event correlation is key to an effect active monitoring
solution. This is typically accomplished through the
Attackers almost never start with your core IBM i use of special software implemented in Security
server directly. They attack a web application or infect Information and Event Management (SIEM) solutions.
a user PC and work their way into the IBM i server. A Highly automated SIEM solutions have the ability to
defensible active monitoring strategy has to collect correlate events across a large number of systems
events from across the entire organization. By the and automatically identify potential problems. They
time they show up on your IBM i server they have do exactly what we want computer systems to do –
probably compromised a number of intermediate handle large amounts of data and apply intelligent
systems and an opportunity to prevent the breach interpretation of the data.
has been missed. Collect all events across your entire

1
2012 Data Breach Investigations Report, Verizon

Page 3
 SECURITY ARCHITECTURE (CONT)

ANOMALY DETECTION

Anomaly detection is another aspect of active

monitoring. That unusual system login at 3:00am on a
Sunday morning would probably escape the attention
of our human IT team members, but good active
monitoring solutions can see that anomalous event
and report on it.
“That unusual system
login at 3:00am on a
ALERTING AND RESOLUTION Sunday morning would
MANAGEMENT
probably escape the
When a problem is discovered we need to know
about it as soon as possible. A good active monitoring
attention of our human
solution will inform us through a variety of alerting IT team members, but
channels. Emails, text, dashboards and other
mechanisms can be deployed to bring attention to good active monitoring
the problem - and we need to be able to track the
resolution of the event! We are all processing too
solutions can see that
much information and it is easy to forget or misplace a anomalous event and
report on it.”
problem.

FORENSIC TOOLS

Forensic tools are critical to an active monitoring

solution as they enable the rapid analysis of an
attacker’s footprints in our system. The key tool is an
effective and easy-to-use query application. Log data
can include millions of events and be impossible to
inspect without a good query tool. The ability to save
queries and use them at a later time should also be a
core feature of your forensic toolset.

Page 4
 LOGGING SOURCES ON THE IBM i

The IBM i server is a rich source of security important operational messages are written to QHST
information. Unlike many Windows and Linux server files and should be collected and monitored.
deployments the IBM i platform can host a complex
mix of back-office applications, web applications, EXIT POINTS
and open source applications and services. For The IBM i operating system provides a number of
convenience we will address these various log “hooks” for network and other services on the IBM i
sources in terms of primary sources and secondary platform. These hooks are referred to as exit points.
sources. Primary sources should be given priority in IBM i customers or vendors can write applications
your implementation processes, as the most critical that collect information and register them for the
events are likely to be found in primary event sources. exit points. Once registered an exit point monitoring
application can collect information on a wide variety of
PRIMARY SOURCES activities. These include information on inbound and
outbound FTP sessions, TCP sockets activity, network
IBM SECURITY AUDIT JOURNAL QAUDJRN authentication, administrative commands through
When configured properly the IBM i server records a Operations navigator, and many other core operating
wide variety of security events in the security journal system services. A good active monitoring strategy
QAUDJRN. Events such as password failures, network should collect information from exit points and pass
authentication failures, failed SSL and TLS network the information to the centralized log collection server.
negotiations, application and database authority
failures, and many others go straight into the security SECONDARY SOURCES
audit journal QAUDJRN. This would naturally be the
first focus of your event monitoring strategy. We WEB APPLICATIONS
discuss the setup and configuration of the QAUDJRN Most IBM i customers do not deploy the server as a
journal below. primary web server, but selected web applications
and services are often incorporated into a customer’s
SYSTEM HISTORY FILE QHST primary web deployment. The IBM i supports a rich
The system history message file QHST (actually a set of web server platforms including IBM Websphere,
collection of files that start with the name QHST) is PHP, Perl, Python, and traditional HTML/CGI services.
also a repository of important security information. All When web applications are deployed on an IBM i
job start, job termination, and abnormal job termination server they are a target for traditional attacks. Web
events are recorded in the QHST files. Additionally, logs should be included in your event collection and
monitoring strategy.

Page 5
 LOGGING SOURCES ON THE IBM i (CONT)

OPEN SOURCE APPLICATIONS SYSTEM AND APPLICATION MESSAGES IN

For some years IBM has been bringing a wide variety QSYSMSG AND QSYSOPR
of open source applications to the IBM i platform. Many customer and vendor applications write
This includes applications like OpenSSH with Secure important operational and security messages to the
Copy (sCP), Secure FTP (sFT) and remote command system operator message queue QSYSOPR and to
shell. Many other application frameworks have the optional system message queue QSYSMSG.
been added like Perl, PHP, and Python. All of these
applications provide entry points and potential points
of compromise for attackers. If you deploy these types
of solutions you should enabled and collect their logs.

“The IBM i server is a rich source of security

information. Unlike many Windows and
Linux server deployments the IBM i platform
can host a complex mix of back-office
applications, web applications, and open
source applications and services.”

Page 6
 Creating the IBM Security Audit
Journal QAUDJRN

The security audit journal does not exist when you

first install a new IBM i server. You must create the CRTJRN JRN(QSYS/QAUDJRN)
journal receivers and the journal to start the process JRNRCV(MYLIB/AUDRCV0001)
of security event collection. As is the case with any MNGRCV(*SYSTEM) DLTRCV(*NO)
journal on the IBM i server you must first create a RCVSIZOPT(*RMVINTENT *MAXOPT3)
journal receiver and then create the QAUDJRN journal AUT(*EXCLUDE) TEXT(’Auditing
and associate it with the journal receiver. Journal’)

The first step is to create a journal receiver which

will be the actual container of security events. You
can create the journal receiver in a user library or in
the IBM general-purpose library QGPL. Creating a
library to hold the journal receivers is recommended
as this allows more flexible system management. You
should use a sequence number in the last four or five
characters of the journal receiver name. This allows
the IBM i operating system to automatically create new
receivers. You can use this command to create the
journal receiver.

CRTJRNRCV JRNRCV(MYLIB/AUDRCV0001)
THRESHOLD(1000000) AUT(*EXCLUDE)
TEXT(’Auditing Journal Receiver’)

Now that we have created the first journal receiver,

we can create the QAUDJRN journal. The QAUDJRN
journal is always created in the operating system
library QSYS. You can use this command to create the
journal and associate it with the first journal receiver:

Page 7
 ENABLING IBM SECURITY EVENTS
THROUGH SYSTEM VALUES
The IBM i operating system will not start writing want to have a lot of information available if you need
security events to the QAUDJRN journal until certain it. Here is how to establish a broad configuration:
system values are changed to indicate that you want
CHGSYSVAL SYSVAL(QAUDLVL)
to collect events and which types of events are to be
VALUE(‘*SECURITY’)
collected. The QAUDJRN journal can collect a broad
set of operational and security events depending on After setting the initial value of the QAUDLVL system
the system value settings. value use the WRKSYSVAL and add the following
additional options:
The first value you must set with the Change
System Value (CHGSYSVAL) command is QAUDCTL. *PGMFAIL
Changing this system value immediately enables *AUTFAIL
the collection of events. This is an example of the *PGMADP
command to change this system value: *SAVRST
*OFCSRFV
CHGSYSVAL SYSVAL(QAUDCTL) *SECURITY
VALUE(‘*AUDLVL’ ‘*OBJAUD’) *SERVICE
*NETSCK
The system values QAUDLVL and QAUDLVL2
*NETUDP
determine which types of events you want to collect.
*NETTELSVR
Here is where you can make choices on how much
*NETSECURE
information you want to collect in the QAUDJRN
journal. You can establish a minimal set of security Congratulations! You are now collecting events in your
events, or you can collect a broader set of security QAUDJRN security journal. You can display them using
and operational messages. IBM gives you some the Display Journal (DSPJRN) command like this:
shortcuts when establishing these system values. In
general it is better to collect more information than DSPJRN JRN(QAUDJRN)
less. Attackers are smart and creative, and you will

Townsend Security’s Alliance LogAgent allows you to select which events are
transmitted to your log collection server or SIEM solution. This means you can
enable maximum collection of events to QAUDJRN but you won’t have to transmit
them.

Page 8
 AUDIT PRIVILEGED USERS

Attackers attempt to gain privileged access to your

IBM i system and as a privileged user can perform
a wide variety of tasks on the IBM i server. As a
privileged user, an attacker can steal sensitive data or
damage your system. You should strongly consider
enabling full user auditing of any user profile that
has a high level of privilege. This should include the
IBM user profile QSECOFR and any user with All
“As a privelaged
Object (*ALLOBJ) or Audit (*AUDIT) capabilities. The user, an attacker can
commands executed by the audit user are logged
to the QAUDJRN journal. You can identify privileged
steal sensitive data or
users by running an IBM security report: damage your system.
PRTUSRPRF TYPE(*AUTINFO) You should strongly
SPCAUT(*ALL)
consider enabling full
Once you identify privileged users you can
enable user auditing with the Change User Audit user auditing of any user
(CHGUSRAUD) command like this:
profile that has a high
CHGUSRAUD USRPRF(QSECOFR)
OBJAUD(*ALL) AUDLVL(*AUTFAIL *CMD
level of privelege.”
*PGMADP *NETCMN *PGMFAIL)

Note that you may want to increase or decrease the

information you audit for privileged users. See the
help for the command options.

Townsend Security’s Alliance LogAgent allows you to

select which events are transmitted to your log collection
server or SIEM solution. This means you can enable
maximum collection of events to QAUDJRN but you won’t
have to transmit them.

Page 9
 AUDITING HIGHLY SENSITIVE
APPLICATIONS AND DATABASE FILES
You should also consider enabling application
and database access audit where sensitive data
can be changed or where sensitive data is stored. PODCAST:
For example, a core HR application that contains System Logging on the IBM i:
employee information, or a core ERP application that
How To Do It Better
stores credit card information should be audited. Once
you have a list of sensitive application programs and
database files you can use the Change Object Audit Collecting and monitoring
system logs has recently
(CHGOBJAUD) command to enable auditing. Audit
become a hot topic for orga-
records are sent directly to the QAUDJRN security nizations that need to meet
journal. compliance regulations such
as PCI DSS, HIPAA/HITECH,
CHGOBJAUD OBJ(PRODLIB/ORD001) and other state privacy laws.
OBJTYPE(*PGM) OBJAUD(*ALL) System logging on the IBM i is different than
other platforms - logs are stored in many dif-
ferent places in a proprietary IBM format. This
For IFS files and directories you can use the Change
presents a challenge for security administrators
Audit (CHGAUD) command like this: who need to monitor their IBM i logs.

CHGAUD OBJ(‘/mydirectory’) This podcast discusses:

OBJAUD(*ALL) SUBTREE(*ALL)
SYMLNK(*YES) • How your organization can better
monitor system logs - managing by
exception, etc.
• What features administrators need in a
logging solution
• How to easily and affordably meet
compliance regulations that require
system logging

DOWNLOAD

Page 10
 FILES, MESSAGE QUEUES, AND
EXIT POINTS
QHST MESSAGE FILES EXIT POINTS

The system message history files that reside in library IBM provides the ability for a customer to register
QSYS are an important source of security information. an application to receive real-time notification about
User logon and logout events as well as critical job selected system services. These are called Exit Points
messages are logged in the QHST files. The QHST in IBM terminology. A user or vendor program can be
files are automatically managed by the operating created to receive the defined information for an exit
system. You don’t need to perform any actions to point, and then the application can be registered to
start collection of QHST events – the system always the exit point. Exit points are available for a number of
performs this task. Minimally you will want to collect critical operating system and network actions.
user logon and logoff events from the QHST files.
A number of web and client applications access the
Alliance LogAgent automatically collects information from
IBM i server for critical functions. For example, the
QHST files. When the system is stopped or restarted it will
remember where it left off and resume processing messages. Operations Navigator application runs on a system
Messages are transformed to a standard format and
administrator’s PC and enables a number of critical
transmitted to the log collection or SIEM server.
system and security tasks. The only way to adequately
monitor the use of Operations Navigator is to monitor
QSYSMSG MESSAGE QUEUE the exit points for the services it uses. Another
example is access to IBM i database files through
Another source of security information are the system
ODBC connections. These connections can be
message queues QSYSOPR and QSYSMSG. Line
monitored through the SQL exit points.
of business applications often send critical security
messages to one or both of these message queues.
IBM does not provide exit point applications. You must
Minimally you should collect messages from the
write the exit point applications or deploy a vendor
QSYSMSG message queue, transform them to
solution that monitors critical exit points. Once you
a standard format, and transmit them to your log
have an exit point program you can use the Work With
collection or SIEM server.
Registration Information (WRKREGINF) command to

Alliance LogAgent gives you the option of sending add and enable the exit point.
messages from both QSYSOPR and QSYSMSG message
queues. Data is collected and transmitted in real time in a Alliance LogAgent provides exit point monitors for critical
standard format. exit points. You can selectively deploy the exit point monitors
and log information directly to your log collection server or
SIEM solution. Alliance LogAgent also manages the task of
registering and activating the exit point.

Page 11
 LINUX/UNIX STYLE LOGS

IBM has been bringing new web and open source Perl, PHP, Python, and many others. Most of these
technologies to the IBM i platform for many years. applications create Linux-style logs in the IFS file
These applications have helped the IBM i customer system. It is important to enable log generation and to
interoperate with applications on Windows and Linux. collect and centralize these logs.
While these applications add significant value to the

IBM i customer they present new security challenges Alliance LogAgent includes an implementation of syslog-ng
in terms of active monitoring. These applications for the IBM i platform. You can use this application to collect
and transmit Linux-style logs generated by open source and
include OpenSSH, Apache web server, WebSphere, proprietary applications such as WebSphere.

OPERATIONS NAVIGATOR

Many IBM i customers are concerned about properly

controlling and monitoring Operations Navigator. WEBINAR:
Operations Navigator is used by system administrators
and security administrators to perform sensitive
Real-time IBM i Log Collection
privileged operations on the IBM i server. Fortunately, & Monitoring
Operations Navigator uses network services on
the IBM i server that have exit point capability. You
can monitor activities and transmit events to the log
collection server if you have exit point monitors (see
section above).

VIEW

Page 12
 SYSTEM LOG FORMATS & STANDARDS
All of the log sources on the IBM i server contain When a SIEM receives understandable data it can
security event information in internal IBM formats function far more effectively.
(EBCDIC character set, binary numeric, etc.) that are
not compatible with centralized log collection servers While the syslog standard for event information does
and SIEM solutions. It is important to convert the not specify normalization rules, devices that generate
IBM security events to a standardized format so that event information can place data in a normalized
events can be properly correlated and categorized. format, and many do. This is always a better option.
There are three common formats for log data:
Alliance LogAgent implements all of the common standards
for security event information including syslog, CEF and LEEF.
• Syslog (RFC 3164 and RFC 5424) Syslog messages are normalized into a Tag/Value format that
makes the use of query, reporting and forensics tools much
• Common Event Format (CEF) easier to use and more effective.
• Log Event Extended Format (LEEF)

The syslog format is the most common format for

security event information and all major SIEM solutions
and forensics tools work with events in syslog format.
The Common Event Format, or CEF, is used by
“It is important to
HP’s ArcSight product and has been proposed as a convert the IBM
standard. However, it is largely only used by ArcSight.
The Log Event Extended Format, or LEEF, is defined security events to a
by the IBM Security QRadar SIEM solution and is
specific to QRadar.
standardized format
so that events can be
Both CEF and LEEF attempt to normalize data to make
it more useful. By defining a Tag/Value format and by properly correlated and
defining common field definitions the SIEM can do a
better job of understanding the event information and
categorized.”
processing it correctly. This is an example of a CEF
field for the IP address:

src=10.0.1.4

Page 13
 COMMUNICATIONS WITH SYSLOG
Transmitting events to a log collection server or SIEM packet loss. The reliable TCP protocol is better in that
solution is done via the Internet standard for syslog packets are guaranteed to be delivered to the log
communications. The default port number is 514, but collection server or SIEM solution. Lastly, many log
some SIEM solutions use a different port number. IBM collection and SIEM solutions support the encrypted
does not provide a syslog communications facility for transmission of events over a secure TLS TCP session.
the IBM i operating system. You can use a third-party Security events can contain sensitive data so it is
vendor solution for communications, or use the syslog always best to use TLS TCP for your communications
facility of the PASE operating environment. Three session if it is available.
different protocols are commonly used for syslog
communications: In order to prevent corruption, substitution, or deletion
of security events you should incorporate serialization
• UDP – User Datagram Protocol or secure hashing into your security events.
• TCP - Transmission Control Protocol
• TLS TCP - Transmission control Protocol
Alliance LogAgent provides all three types of syslog
with TLS security communications as options. When security events are
collected and transformed into a standard format they are
automatically transmitted to the log collection server or SIEM
Almost all log collection servers support the UDP solution using UDP, TCP or TLS TCP as you select during
configuration.
protocol, however the UDP protocol is subject to

“IBM does not provide a syslog

communications facility for the IBM i
operating system. You can use a third-party
vendor solution for communications, or use
the syslog facility of the PASE operating
environment.”

Page 14
 CENTRALIZED LOG COLLECTION
As mentioned above a core requirement for an active
monitoring solution is a central repository of security
event information that is being collected in real time
from all user PCs, application servers, web servers,
firewalls, switches, routers and all other network
infrastructure. In the most basic implementation
that central repository can be a collection of events
performed by a log collection system like syslog-ng
“Regardless of the
(www.balabit.com). Syslog-ng is a very common Linux/ log collection or SIEM
Unix facility that is optimized for receiving and storing
log information. There are forensic and reporting solution that you deploy
tools that can operate directly on syslog-ng data
repositories. If you do not have a SIEM solution this
you should maintain
can be an effective way of collecting and archiving at least 90 days of log
security events.
history in your repository
Many SIEM solutions provide a syslog collector and
repository for events. If you deploy a SIEM solution
to support rapid
it is unlikely that you will need to deploy a separate response to potential
log collection system. Because SIEM solutions are
processing event information in real-time to perform attacks. Be sure to
correlation, anomaly detection, and flow analysis the
log repository is automatically updated.
maintain at least 3 years
of log history online or
offline.”
You can combine a log collection solution with a SIEM
solution and this may be preferable in some cases.
For example, you can collect logs with syslog-ng and
these logs can be automatically processed by Splunk.

Regardless of the log collection or SIEM solution that

you deploy you should maintain at least 90 days of log
history in your repository to support rapid response to
potential attacks. Be sure to maintain at least 3 years
of log history online or offline.

Page 15
 ACTIVE MONITORING & ALERTING
With millions of security events collected on a daily Some examples of SIEM solutions that you might
basis it is clearly not possible for any person or group consider (this is not an exhaustive list and not in any
of people to effectively monitor them. This is the particular order):
province of special security software called Security
Information and Event Management systems, or • IBM Security QRadar
SIEMs. There are many vendors of SIEM solutions • LogRhythm
and there are many very cost effective SIEMs for IBM • HP ArcSight
i customers to choose from. A good SIEM will provide • Splunk
the log collection server, log archival services, event • McAfee
correlation, query, and alerting services you need • Alert Logic
to implement a good active monitoring strategy. • AlienVault
Most SIEMs provide compliance reports to help • And many others
you organize your security strategy to meet various
compliance regulations such as PCI DSS, HIPAA There are also Security-as-a-Service vendors like
and many others. If you do not have a SIEM solution SecureWorks who can manage your SIEM deployment
for your organization, don’t let that stop you. You and monitor it for you.
can deploy a log collection system and add a SIEM
solution at a later time.

“With millions of security events collected

on a daily basis it is clearly not possible for
any person or group of people to effectively
monitor them.”

Page 16
 FILE INTEGRITY MONITORING
File Integrity Monitoring (FIM) is
an important part of compliance
regulations such as PCI DSS and PODCAST:
others. The fundamental concept File Integrity Monitoring on
behind FIM is that it is important to the IBM i:
monitor critical system configuration files, application
configuration files, and database files that contain
sensitive information. On the IBM i platform the As cyber attacks become
more sophisticated, File
system configuration settings for security are largely
Integrity Monitoring (FIM) is
controlled by system values (see notes above) and becoming a key component
changes to these system values are recorded in the for IBM i administrators to
QAUDJRN journal as SV events. However, application protect and monitor data ac-
cess and change activity of
configuration files and database files with sensitive
files at the column or field level - without chang-
data are not automatically monitored. You should ing applications or user accounts. Additionally,
enable object level auditing for these applications and FIM is required for many data security compli-
files and consider adding a third party solution for FIM ance regulations such as PCI DSS (Sections 10
and 11).
monitoring. All events should be converted to syslog
or other standard format and transmitted in real time to This podcast discusses:
your log collection server or SIEM solution.
• Why implementing FIM tools is a best
practice and compliance requirement
Alliance LogAgent provides a File Integrity Monitoring • How administrators are using them
option that you can deploy to monitor your applications and • How easy and affordable it is to deploy a
database files.
FIM solution

DOWNLOAD

Page 17
STEP BY STEP CHECKLIST

PHASE ONE • Identify all database files that contain sensitive

information.
• Deploy a log collection server or SIEM solution. • Start auditing all database files with sensitive
If you do not yet have a SIEM solution deploy a information using the CHGOBJAUD command.
Linux server with the syslog-ng solution. • Identify all IFS directories, scripts, and files
• Deploy an IBM i log collection solution that that perform sensitive operations or which
contains syslog communications and configure contain sensitive data
it to send information using UDP, TCP or TLS • Start auditing IFS directories and files using the
TCP to the log collection server or SIEM CHGAUD command.
solution.
• Modify the IPL startup program (system value PHASE THREE
QIPLSTRUP) to automatically start your IBM i
log collection application. • Configure your IBM i log collection application
• If you use a monitoring tool, configure the tool to start collecting events from QAUDJRN and
to always expect the IBM i log collection transmitting them to the log collection server or
solution to be active. SIEM solution.
• Verify that you can view the events on the log
PHASE TWO collection server.
• Verify that you can use query tools and
• If needed create the QAUDJRN journal and forensics tools to inspect log events.
journal receivers.
• Change the QAUDCTL system value to enable PHASE FOUR
event collection.
• Change the QAUDLVL and QAUDLVL2 system • On the IBM i server configure your IBM i log
values to define the events you want to collect. collection application to start collecting events
• Identify the privileged users on your IBM i from the QHST files.
server. • Verify the QHST events are received on the log
• Start auditing all privileged users with the collection server or SIEM solution.
CHGUSRAUD command.
• Identify the sensitive applications on your IBM i
server.
• Start auditing the sensitive applications using
the CHGOBJAUD command.

Page 18
STEP BY STEP CHECKLIST (CONT)

PHASE FIVE

• On the IBM i server configure your IBM i log

collection application to start collecting
messages from the QSYSOPR and QSYSMSG
message queues.
• Verify that the QSYSOPR and QSYSMSG
events are received on the log collection
server or SIEM solution

PHASE SIX

• On the IBM i server configure your IBM i log

collection application to start collecting events
from IBM Exit Points.
• Restart TCP servers as necessary to activate
Exit Point event collection.
• Verify that the Exit Point events are received on
the log collection server or SIEM solution

PHASE SEVEN
• On the IBM i server configure your IBM i log
collection application to start collecting
events from all IFS directories with sensitive
applications or files.
• Use the Change Audit (CHGAUD) command to
start auditing relevant IFS files and directories.
• Verify that the IFS events are received on the
log collection server or SIEM solution

Page 19
 ALLIANCE LOGAGENT

MEET COMPLIANCE REGULATIONS BY

collecting all system logs on your IBM i (AS/400,
iSeries, System i) and converting them to
standard syslog (RFC3164), Common Event Format
30-DAY EVALUATION
(CEF), or Log Event Extended Format (LEEF) - formats
that can be read by your SIEM or log collection server.

Alliance LogAgent for IBM i helps Enterprise

customers bring their IBM i platforms into compliance
with PCI DSS, Sarbanes-Oxley (SOX), HIPAA and other
ALLIANCE
regulations requiring active security monitoring of
their servers. Alliance LogAgent automatically collects
LOGAGENT
system security events in real time, formats them into
an open systems log format, and securely transmits
them to a log server for consolidation with the security
events from other servers.
• Automatically collect and transmit
For organizations who need to monitor access system security events
to sensitive information stored on in their IBM i • Convert IBM i system logs to
databases, Alliance LogAgent Suite includes File common syslog formats (CEF, LEEF,
Integrity Monitoring (FIM). With Alliance LogAgent or RFC3164)
Suite, IBM i administrators can monitor access on a • High performance event handling
field-by-field, record-by-record basis. User
• Meet compliance regulations like
accesses and changes at the field level can be
PCI DSS, HIPAA, FFIEC, and more
logged to the IBM Security Audit journal QAUDJRN to
meet the strictest compliance regulations. Townsend
Security offers a 30-day, fully-functional evaluation of
the solution.

REQUEST EVALUATION

Page 20
STOP A DATA BREACH
BEFORE IT HAPPENS
2015
780 data breaches1
177,866,236 compromised records

84% of data breaches 2

are detectable via security logs

ALLIANCE LOGAGENT FOR IBM i

» Monitor security events in real-time (QAUDJRN, QSYSOPR, etc.)
» Send logs to ANY SIEM (IBM QRadar, LogRhythm, Splunk, etc.)
» File Integrity Monitoring (FIM) at the column or field level
» Meet compliance (PCI DSS, HIPAA, FFIEC, etc.)

FREE 30-DAY EVALUATION

www.townsendsecurity.com/logagent

1) Identity Theft Resource Center

2) 2012 Data Breach Investigations Report, Verizon

Page 21
 ABOUT TOWNSEND SECURITY

“Townsend is a full service security

provider that remains on the cutting
edge and has demonstrated
exceptional customer service.”
- CSU FRESNO

TOWNSEND SECURITY CREATES DATA PRIVACY

solutions that help organizations meet evolving
compliance requirements and mitigate the risk of data
breaches and cyber-attacks. Over 3,000 organizations
worldwide trust Townsend Security’s NIST and FIPS
140-2 compliant solutions to meet the encryption
and key management requirements in PCI DSS,
HIPAA/HITECH, FISMA, GLBA/FFIEC, SOX, and other
regulatory compliance requirements.

CONTACT TOWNSEND SECURITY

www.townsendsecurity.com
@townsendsecure

724 Columbia Street NW, Suite 400

Olympia, WA 98501

360.359.4400

Page 22