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.

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

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
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. For
convenience we will address these various log
sources in terms of primary sources and secondary
sources. Primary sources should be given priority in
your implementation processes, as the most critical
events are likely to be found in primary event sources.
PRIMARY SOURCES
IBM SECURITY AUDIT JOURNAL QAUDJRN
When configured properly the IBM i server records a
wide variety of security events in the security journal
QAUDJRN. Events such as password failures, network
authentication failures, failed SSL and TLS network
negotiations, application and database authority
failures, and many others go straight into the security
audit journal QAUDJRN. This would naturally be the
first focus of your event monitoring strategy. We
discuss the setup and configuration of the QAUDJRN
journal below.
SYSTEM HISTORY FILE QHST
The system history message file QHST (actually a
collection of files that start with the name QHST) is
also a repository of important security information. All
job start, job termination, and abnormal job termination
events are recorded in the QHST files. Additionally,
important operational messages are written to QHST
files and should be collected and monitored.
EXIT POINTS
The IBM i operating system provides a number of
“hooks” for network and other services on the IBM i
platform. These hooks are referred to as exit points.
IBM i customers or vendors can write applications
that collect information and register them for the
exit points. Once registered an exit point monitoring
application can collect information on a wide variety of
activities. These include information on inbound and
outbound FTP sessions, TCP sockets activity, network
authentication, administrative commands through
Operations navigator, and many other core operating
system services. A good active monitoring strategy
should collect information from exit points and pass
the information to the centralized log collection server.
SECONDARY SOURCES
WEB APPLICATIONS
Most IBM i customers do not deploy the server as a
primary web server, but selected web applications
and services are often incorporated into a customer’s
primary web deployment. The IBM i supports a rich
set of web server platforms including IBM Websphere,
PHP, Perl, Python, and traditional HTML/CGI services.
When web applications are deployed on an IBM i
server they are a target for traditional attacks. Web
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
The system message history files that reside in library
QSYS are an important source of security information.
User logon and logout events as well as critical job
messages are logged in the QHST files. The QHST
files are automatically managed by the operating
system. You don’t need to perform any actions to
start collection of QHST events – the system always
performs this task. Minimally you will want to collect
user logon and logoff events from the QHST files.
Alliance LogAgent automatically collects information from
QHST files. When the system is stopped or restarted it will
remember where it left off and resume processing messages.
Messages are transformed to a standard format and
transmitted to the log collection or SIEM server.
QSYSMSG MESSAGE QUEUE
Another source of security information are the system
message queues QSYSOPR and QSYSMSG. Line
of business applications often send critical security
messages to one or both of these message queues.
Minimally you should collect messages from the
QSYSMSG message queue, transform them to
a standard format, and transmit them to your log
collection or SIEM server.
Alliance LogAgent gives you the option of sending
messages from both QSYSOPR and QSYSMSG message
queues. Data is collected and transmitted in real time in a
standard format.
EXIT POINTS
IBM provides the ability for a customer to register
an application to receive real-time notification about
selected system services. These are called Exit Points
in IBM terminology. A user or vendor program can be
created to receive the defined information for an exit
point, and then the application can be registered to
the exit point. Exit points are available for a number of
critical operating system and network actions.
A number of web and client applications access the
IBM i server for critical functions. For example, the
Operations Navigator application runs on a system
administrator’s PC and enables a number of critical
system and security tasks. The only way to adequately
monitor the use of Operations Navigator is to monitor
the exit points for the services it uses. Another
example is access to IBM i database files through
ODBC connections. These connections can be
monitored through the SQL exit points.
IBM does not provide exit point applications. You must
write the exit point applications or deploy a vendor
solution that monitors critical exit points. Once you
have an exit point program you can use the Work With
Registration Information (WRKREGINF) command to
add and enable the exit point.
Alliance LogAgent provides exit point monitors for critical
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
technologies to the IBM i platform for many years.
These applications have helped the IBM i customer
interoperate with applications on Windows and Linux.
While these applications add significant value to the
IBM i customer they present new security challenges
in terms of active monitoring. These applications
include OpenSSH, Apache web server, WebSphere,
Perl, PHP, Python, and many others. Most of these
applications create Linux-style logs in the IFS file
system. It is important to enable log generation and to
collect and centralize these logs.
Alliance LogAgent includes an implementation of syslog-ng
for the IBM i platform. You can use this application to collect
and transmit Linux-style logs generated by open source and
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
security event information in internal IBM formats
(EBCDIC character set, binary numeric, etc.) that are
not compatible with centralized log collection servers
and SIEM solutions. It is important to convert the
IBM security events to a standardized format so that
events can be properly correlated and categorized.
There are three common formats for log data:
• Syslog (RFC 3164 and RFC 5424)
• Common Event Format (CEF)
• Log Event Extended Format (LEEF)
When a SIEM receives understandable data it can
function far more effectively.
While the syslog standard for event information does
not specify normalization rules, devices that generate
event information can place data in a normalized
format, and many do. This is always a better option.
Alliance LogAgent implements all of the common standards
for security event information including syslog, CEF and LEEF.
Syslog messages are normalized into a Tag/Value format that
makes the use of query, reporting and forensics tools much
easier to use and more effective.

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
solution is done via the Internet standard for syslog
communications. The default port number is 514, but
some SIEM solutions use a different port number. 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. Three
different protocols are commonly used for syslog
communications:
• UDP – User Datagram Protocol
• TCP - Transmission Control Protocol
• TLS TCP - Transmission control Protocol
with TLS security
Almost all log collection servers support the UDP
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.”
packet loss. The reliable TCP protocol is better in that
packets are guaranteed to be delivered to the log
collection server or SIEM solution. Lastly, many log
collection and SIEM solutions support the encrypted
transmission of events over a secure TLS TCP session.
Security events can contain sensitive data so it is
always best to use TLS TCP for your communications
session if it is available.
In order to prevent corruption, substitution, or deletion
of security events you should incorporate serialization
or secure hashing into your security events.
Alliance LogAgent provides all three types of syslog
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
solution using UDP, TCP or TLS TCP as you select during
configuration.
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