+1.800.357.1019

+1.800.357.1019

Feel free to call us toll free at +1.800.357.1019.

If you are in the area you can reach us at +1.360.359.4400.

Standard support
6:30am - 4:00pm PST, Monday - Friday, Free

Premium support
If you own Townsend Security 24x7 support and
have a production down issue outside normal
business hours, please call +1.800.349.0711
and the on-call person will be notified.

International customers, please dial +1.757.278.1926.

Townsend Security Data Privacy Blog

The Future of Active Security Monitoring on the IBM i

Posted by Luke Probasco on Jan 24, 2017 8:19:21 AM

Active monitoring is one of the most effective security controls an enterprise can deploy. In fact, a large majority of security breaches occur on systems that have been compromised days, weeks, or even months before sensitive data is lost. A recent Verizon Data Breach Investigations Report indicates that a full 84 percent of all breaches were detected in system logs.  By actively collecting security logs in real-time, organizations can not only monitor security events, but also prevent a data breach before it starts.  I recently sat down with Patrick Townsend, to discuss log collection and active monitoring on the IBM i.

Hi Patrick, can you give our readers an overview on the importance of collecting and monitoring security logs on the IBM i?

The Future of Active Security Monitoring on the IBM iOne of the most effective things that you can do to prevent a data breach is to deploy an active monitoring solution, sometimes also known as system logging.  You’ll find active monitoring at the top of all cyber-security lists of things to do – because it is effective.  Active monitoring is key to a strong security posture, for anybody.

Today, we all know that there is no longer a true perimeter and that our systems are at risk.  Luckily, active monitoring can help.  Here are some key principles that organizations need to understand.  First, an active monitoring solution needs to involve a log collection server or SIEM solution (IBM Security QRadar, Splunk, LogRythm, etc.) to collect security events across the entire enterprise and actively detect threats.  Second, there needs to be real-time collection and monitoring of security events.  Rather than scooping up the security events once or twice a day, it is imperative to be collecting these events in real-time. When you collect logs across the entire enterprise, a SIEM can provide a lot of intelligence to identify patterns and anomalies – which will identify a potential attack.  The final critical components are good reporting, query, and forensics tools.  SIEM solutions also give you the ability to quickly run reports and analyze suspect data.  This is important for two reasons.  If you are having an attack you need to identify quickly where the attack is originating and how it is happening.  This is essential in order to know how to remediate it.  If you aren’t able to pinpoint the problem, it is very likely that you are going to be attacked by the same methods again.

Switching gears, the serious points for an IBM i customer revolve around the fact that the IBM i is a critical back-office processor for most customers and runs multiple applications.  Too often the IBM i is an island within an organization, but it is important that it is fully integrated in your enterprise’s entire infrastructure security strategy.

Also, it is generally true that a cyber-attack almost never starts on an IBM i server.  They typically start on a compromised user PC or someplace in the organization.  From there, a hacker spends a fair amount of time probing around the IBM i finding any weak points.  We shouldn’t be naïve – hackers know about IBM i servers.  They know what to look for, they know the user IDs, they know how to compromise these systems – they are very good at it.

IBM introduced some new security event sources in V7R3.  Can you talk a bit about those? And what events should an IBM i customer be collecting?

Every release of the IBM i server has had new security events and fields to collect and monitor.  At Townsend Security we work very hard to stay ahead of these releases so that our customers are well positioned to handle new information and use it for protection.  A couple examples include IPV6 address support and new fields in existing events.  Regarding the recent V7R3 release, new sources include:

  • QAUDLVL (Auditing level) system value
  • *NETSECURE (to audit secure network connections)
  • *NETTELSVR (to audit Telnet connections)
  • *NETUDP (to audit UDP connections)

To address the second part of your question, when you deploy an active monitoring solution on the IBM i, you are certainly going to want to collect events from QAUDJRN, QHST, QSYSOPR, as well as exit points.  Interestingly, the QAUDJRN security audit journal does not exist when you first install a new IBM i server. You must create the journal receivers and the journal to start the process of security event collection.

Aside from the new log sources that IBM introduced in V7R3, for someone who maybe deployed a logging solution a few years ago, what should they be aware of now?

First, let’s take a look at how compliance regulations have been evolving.  We now know that most attacks work on the basis of privilege escalation.  For example, an attacker gets access to our systems and then eventually gets sufficient authority to steal data. Because of this, we are seeing that it is more important to identify when an administrative level or highly privileged user logs in to our system.  This is an example of how a logging solution needs to evolve to meet current compliance requirements. Businesses are now required to log and monitor that activity.

Unfortunately, this can be particularly hard on the IBM i.  On first look, an IBM i account may appear to have normal user privileges, but may in fact inherit higher privileges through a Group Profile or Supplemental Group Profile. It is important to detect these elevated privileges in real time and provide the security administrator with an easy-to-use report to identify the source of elevated privileges. This is an excellent example of how logging solutions need to evolve with the ways security events are monitored.  We recently tackled this in the latest release of our Alliance LogAgent.

Where do you see the future of logging on the IBM i?

Let me dust off my crystal ball!  First off, File Integrity Monitoring (FIM) will become more important.  To maintain a strong posture, security administrators need to know who is accessing sensitive data and system values on the IBM i.  We’re also going to see more requirements around File Integrity Monitoring across the regulatory compliance environments.  Why?  Because, as we discussed earlier, cyber-attackers escalate privileges, access sensitive data, and change security configurations in order to get the work done that they want to do.  Again, this is why we are seeing increased requirements in regulations like the Payment Card Industry Data Security Standard (PCI DSS) and new financial services regulations.

Another interesting prediction:  It won’t be unheard of for organizations to use multiple SIEM solutions. We are starting to see businesses use one SIEM for traditional security monitoring and another to monitor operational data.  Operational data, you ask?  Sure.  Logging solutions can easily allow administrators to answer operational questions like: How full are my disks?  Do I have any critical hardware errors?  Second, they can benefit from deploying a SIEM to monitor application data.  Sales teams, for example, can track inventory status, trending products, etc.  The benefits of file monitoring don’t have to be exclusive to security.

In the near future, we will also see a pickup of integration with Artificial Intelligence (AI), also commonly referred to as cognitive computing.  IBM has the Watson platform, and there are others, which I believe will be used to enhance security.  We are already seeing initial efforts in this respect.  Harnessing that AI capability with security makes total sense.  

Finally, as we are seeing, everything not bolted down is going to the cloud.  We will definitely see an evolution of new cloud services around security and logging.  It may take a little time for vendors to start leveraging that, but I believe it is definitely in the works.

To hear this interview in it’s entirety, download our podcast “The Future of Security Logging on the IBM i” and hear Patrick Townsend, founder and CEO of Townsend Security, further discuss log collection and monitoring on the IBM i, new log sources in V7R3, and the future of security logging on the IBM i.

The Future of Active Security Monitoring on the IBM i

Topics: System Logging, Alliance LogAgent

IBM i Security Architecture & Active Monitoring

Posted by Patrick Townsend on Dec 6, 2016 7:30:42 AM

Excerpt from the eBook "IBM i Security: Event Logging & Active Monitoring - A Step By Step Guide."


IBM i Security: Event Logging & Active MonitoringActive monitoring (sometimes referred to as Continuous Monitoring) is a critical security control for all organizations. And it is one of the most effective security controls you can deploy. The large majority of security breaches occur on systems that have been compromised days, weeks, or even months before sensitive data is lost. A recent Verizon Data Breach Investigations Report1 indicates that a full 84 percent of all breaches were detected in system logs. This is why the Center for Internet Security includes active monitoring as a Critical Security Control (Control number 6).

There are several elements of a truly effective Active Monitoring strategy:

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 IT infrastructure to gain the best early detection opportunities.

Real Time Event Collection
Data breaches are happening much faster than in the past. In some cases the loss of data happens just minutes after the initial breach. This means that you must collect security events in real time. Good active monitoring solutions are able to digest threat information
in real time and give you the chance to deter them. Avoid batch event collection – you can collect IBM i security audit journal information in real time and you should.

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.

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.

Alerting and Resolution Management
When a problem is discovered we need to know about it as soon as possible. A good active monitoring solution will inform us through a variety of alerting channels. Emails, text, dashboards and other mechanisms can be deployed to bring attention to the problem - and we need to be able to track the resolution of the event! We are all processing too much information and it is easy to forget or misplace a 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.

IBM i


Topics: System Logging, IBM i

IBM i Security: Auditing Privileged Users, Applications, and Database Files

Posted by Patrick Townsend on Nov 3, 2016 9:21:51 AM

Excerpt from the eBook "IBM i Security: Event Logging & Active Monitoring - A Step By Step Guide."


IBM i Security: Event Logging & Active Monitoring

Audit Privelaged 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 Object (*ALLOBJ) or Audit (*AUDIT) capabilities. The commands executed by the audit user are logged to the QAUDJRN journal. You can identify privileged users by running an IBM security report:

   PRTUSRPRF TYPE(*AUTINFO)
   SPCAUT(*ALL)

Once you identify privileged users you can enable user auditing with the Change User Audit (CHGUSRAUD) command like this:

   CHGUSRAUD USRPRF(QSECOFR)
   OBJAUD(*ALL) AUDLVL(*AUTFAIL *CMD
   *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.

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. For example, a core HR application that contains employee information, or a core ERP application that 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 (CHGOBJAUD) command to enable auditing. Audit records are sent directly to the QAUDJRN security journal.

   CHGOBJAUD OBJ(PRODLIB/ORD001)
   OBJTYPE(*PGM) OBJAUD(*ALL)

For IFS Files and directories you can use the Change Audit (CHGAUD) command like this:

   CHGAUD OBJ(‘/mydirectory’)
   OBJAUD(*ALL) SUBTREE(*ALL)
   SYMLNK(*YES)

For more information on auditing privelaged users, applications, and database files, as well as more information on IBM i event logging and active monitoring, download our ebook "IBM i Security: Event Logging & Active Monitoring - A Step By Step Guide."
IBM i

Topics: System Logging, IBM i, Alliance LogAgent

System Logging for the IBM i - A Must Have Security Control

Posted by Patrick Townsend on Oct 5, 2016 7:49:48 AM

IBM i (AS/400, iSeries) customers now know that their systems are no more secure than any other. That is, they are just as much a target as any Windows or Linux server that exist in less secure network environments. This is not a criticism of the IBM i security implementation, it just reflects the fact that our IBM i servers are connected to a wide range of other devices including user PCs, network devices, local and WAN networks, and so forth. The attack surface is broad, IBM i servers are a rich target for data thieves, and we are all just one user PC infection away from an IBM i server data breach.

IBM i Security: Event Logging & Active MonitoringA lot of IBM i customers postpone deploying a system logging and SIEM solution to actively monitor for security threats, even though this is one of the most effective means of detecting and preventing a data breach. There is a reason that the Center for Internet Security recommends system log collection and monitoring with a SIEM solution as the 6th Critical Security Control. It just works really well when done properly.

I suspect that cost is one of the reasons that projects are postponed. This reasoning is “penny wise and pound foolish”. Here’s why:

  • There are now very cost effective log collection and SIEM monitoring solutions available for the smaller Enterprise. Some of these solutions are cloud-based and some can be deployed in VMware infrastructure. Cost is not as big an issue as it has been.
  • The failure to collect system logs means that it will be difficult to do the forensic investigation that you must do after a data breach. Imagine a costly data breach and then imagine not being able to figure out how the data thieves entered your system! All too often this means that a second and third data breach happens after the first. Without collecting system logs you won’t be able to deploy the forensics tools to trace the path of the cyber criminal through your organization. Another data breach is almost a certainty.
  • Early detection is one of the most effective means of preventing the data breach. This means large savings on outside security consultants, litigation costs, and the deployment of log collection and monitoring tools at inconvenient times. Early detection is a life-saver for those who can prevent a breach.
  • Log collection and SIEM monitoring solutions are easier to deploy than ever. While deploying an active monitoring system was complex and costly in the past, many SIEM solutions can be deployed and start working to protect your organization is just a matter of hours. Unlike in years past when SIEM solutions took weeks to install, configure and deploy, many are now extremely easy to setup and administer.

From a Governance, Risk Management and Compliance point of view deploying the CIS Critical Security Controls is a minimum requirement. Here is what the California Department of Justice said in this year’s data breach report under “Recommendations”:

“The 20 controls in the Center for Internet Security’s Critical Security Controls identify a minimum level of information security that all organizations that collect or maintain personal information should meet. The failure to implement all the Controls that apply to an organization’s environment constitutes a lack of reasonable security.”

Every senior executive in the modern organization understands that canceling the fire insurance policy on their headquarters building would be a bad idea. You would be one fire away from the end of your career. The same now holds true for IT security. Shareholders and the board of directors now understand that the failure to use reasonable measures to protect data assets is a fundamental failure of governance. Don’t be the executive who has to try to defend that failure!

Patrick

IBM i

Topics: System Logging, IBM i

Creating the IBM Security Audit Journal QAUDJRN

Posted by Patrick Townsend on Sep 28, 2016 8:49:33 AM

Excerpt from the eBook "IBM i Security: Event Logging & Active Monitoring - A Step By Step Guide."


IBM i Security: Event Logging & Active Monitoring

The QAUDJRN security audit journal does not exist when you first install a new IBM i server. You must create the journal receivers and the journal to start the process of security event collection. As is the case with any journal on the IBM i server you must first create a journal receiver and then create the QAUDJRN journal and associate it with the journal receiver.

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

CRTJRN JRN(QSYS/QAUDJRN)
JRNRCV(MYLIB/AUDRCV0001)
MNGRCV(*SYSTEM) DLTRCV(*NO)
RCVSIZOPT(*RMVINTENT *MAXOPT3)
AUT(*EXCLUDE) TEXT(’Auditing Journal’)
IBM i

Topics: System Logging, IBM i

IBM i Security: Event Logging & Active Monitoring

Posted by Patrick Townsend on Sep 20, 2016 9:40:55 AM

Excerpt from the eBook "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 effective security controls. IBM i (AS/400, iSeries) users have to solve some special challenges to implement this critical security control. 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 i Security: Event Logging & Active MonitoringIBM 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.

Open Source Applications
For some years IBM has been bringing a wide variety of open source applications to the IBM i platform. This includes applications like OpenSSH with Secure Copy (sCP), Secure FTP (sFT) and remote command shell. Many other application frameworks have
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.

System and Applications Messages in QSYSMSG AND QSYSOPR
Many customer and vendor applications write important operational and security messages to the system operator message queue QSYSOPR and to the optional system message queue QSYSMSG.

IBM i

 

Topics: System Logging, IBM i

How System Logging and Snowstorms Can Provide Important Information

Posted by Alex Bryan on Feb 12, 2016 2:44:00 PM

When the weather outside is frightful, keep a watchful eye on those tracks in the snow!

I used to love looking out the sliding glass doors at my parents deck when it would snow. I would rush to the cold glass first thing in the morning to see just who had been out and about. It was always exciting to see what footprints the various critters had left behind from the night before. Strange topic for a tech blog to be sure, however this memory always pops to the front of my mind when discussing system logging, log collectors, and their ever-important counterpart, SIEM solutions. The one question I hear most in our support department is “I’ve got a log collector do I really need a SIEM?” Well let’s think about that and compare log collection and monitoring to a fresh snowfall.Request the white paper: Simplifying Security for IBM I and IBM QRadar

Envision the log collector as a blanket of snow over a deck. The deck in this example represents your database, the footprints are the events. Just one database server can generate millions of events in a day. With that kind of traffic your blanket of snow is going to become packed ice very quickly. You wouldn’t be able to pick out and clearly identify any one specific footprint from that mess. The shear amount of events generated by the average system makes detecting an anomalous event a logistical nightmare for a human observer. So simply having a good log collector is great, but it is only half of the equation. You have to be able to identify events and act on the information gathered, preferably in real-time.

One morning, after it had snowed I was up early peering out at the snow cover when I noticed boot prints near the garage. This was unusual as we lived in a relatively rural area. I told my parents what I’d seen, and tried to show them, but the snow was starting to melt. So the evidence that I had seen was rapidly being lost to time and inactivity. My parents brushed off my concern and went on with their day, opting to forego any further “analysis”. The following morning they awoke to an open garage door and a missing car.

This scenario is strikingly similar to how cyber criminals operate. Evidence of a breach is often left long before any data is actually stolen. It can take weeks and, in some cases, months for an intruder to find the data they want and take it. Early detection has spelled the end of many data theft attempts. Unusual events like someone accessing the system from an unfamiliar location, or an unexpected access of a sensitive file can be identified before data goes missing. All of those events show up in the system logs, but if you aren’t doing anything with the information, then you are making it easy for criminals to get what they came for. When properly deployed, and monitored in real-time, a SIEM can be your strongest weapon in actively preventing breaches.

Proper set-up can appear to be daunting because the system logging solution needs to be able to understand the events being received. The SIEM can’t correlate data to recognize patterns, and identify suspicious activity if the log collector is sending events in a language the SIEM doesn’t understand. In a perfect scenario SIEMs and log collectors would work together to create an “out of the box “ solution. Townsend Security has recently worked with IBM to enhance our system logging solution to include support for IBM Security QRadar.  Alliance LogAgent for IBM QRadar can now send events in IBMs “Log Event Extended Format” or LEEF to the QRadar SIEM. Because we worked directly with the IBM team for the QRadar Device Support Module (DSM) definitions, you just need to pull the latest DSM definitions from IBM to get started. Though it’s similar to other log formats like syslog, QRadar can sort and use the information received without any major set up.  This means that instead of logging tons of unreadable, unsorted events, you can query the SIEM to find something specific like a log on, or file change - which, going back to the original analogy, can help you find the boot prints in the snow!

Alliance LogAgent for IBM QRadar works seamlessly with IBM Security QRadar to give you the real-time, active monitoring tools you need to be proactive when dealing with a potential data breach. For more information, request this white paper on Making Security Better for the IBM i and IBM QRadar:


Request the white paper: Simplifying Security for IBM I and IBM QRadar



Topics: System Logging, White Paper, IBM QRadar, Alliance LogAgent for IBM QRadar

FAQ: IBM i System Logging for IBM Security QRadar

Posted by Patrick Townsend on Feb 1, 2016 10:08:00 AM

When our customers consider deploying Alliance LogAgent for IBM QRadar on their IBM i (AS/400, iSeries) servers, they often have a number of questions about how the application works. Here are a few of the common questions we encounter:

IBM i Security QRadar Log CollectionCan I monitor security events collected in the IBM security audit journal QAUDJRN?
Yes, all of the events in the QAUDJRN security journal are processed by Alliance LogAgent and assigned a severity level that is recognized by QRadar. Be aware that the security event information collected in the QAUDJRN security audit journal depend on system values that you define. Minimally you should configure your IBM i server to collect all *SECURITY level events. See the Alliance LogAgent documentation for more information.

Can I monitor user messages in the security audit journal QAUDJRN?
Yes, Alliance LogAgent for IBM QRadar processes all user-defined events in the security audit journal. If you wish to write user-defined events to QAUDJRN you should be aware of the data format defined for QRadar called the Log Event Extended Format, or LEEF. The LEEF format documentation is available from IBM.

Why is Alliance LogAgent for IBM QRadar better than what I already have?
Alliance LogAgent for IBM QRadar has several security advantages over the native AS/400 DSM definition in QRadar. The most important is that Alliance LogAgent processes security events in real time. This means that QRadar can perform event correlation and alerting more effectively. There is less chance that a security breach will result in the loss of data. Additionally, Alliance LogAgent provides more information for security events. For example, when a user profile is changed all of the granted authorities are reported to QRadar, not just the summary information. Lastly, Alliance LogAgent collects information from a variety of sources including IBM i Exit Points, the system message file QHST, the system operator’s message queue, and user defined messages via a data queue. For all of these reasons Alliance LogAgent for IBM QRadar will improve your IBM i security.

Do I have to make any changes to QRadar?
No, you just need to pull the latest QRadar Device Support Module (DSM) definitions from IBM and you are ready to use Alliance LogAgent for IBM QRadar. If you are automatically updating your DSM definitions you probably already have the DSM support you need. Townsend Security worked with the IBM QRadar team for the DSM definitions. You do not need to do any manual work for IBM QRadar to recognize and process IBM i security events transmitted by Alliance LogAgent for IBM QRadar.

Is Alliance LogAgent for IBM QRadar certified by IBM?
Yes, Townsend Security worked directly with the IBM Security QRadar technical team to certify the security events transmitted by Alliance LogAgent. Out of the box the QRadar SIEM will recognize and process events sent by Alliance LogAgent for IBM QRadar. Townsend Security is validated to the Ready For IBM Security Information program.

What is the performance impact?
Alliance LogAgent for IBM QRadar runs as a low priority batch job on the IBM i platform and will have minimal impact on CPU and other resources. The application uses normal IBM APIs for security event information and does not bypass normal application performance controls. You should not notice any significant impact on interactive user jobs or system resources.

Can I filter messages that are sent to QRadar?
Yes, Alliance LogAgent for IBM QRadar provides several ways to filter messages sent to IBM QRadar including:

  • Which QAUDJRN events are reported
  • Which QAUDJRN user events are reported
  • Which System Values are reported
  • Which libraries and objects are included or excluded
  • Which IFS directories and files are included or excluded
  • Which user profiles are excluded.
  • Which IBM i Exit Points are monitored
  • Which files and tables are monitored at the field level

As you can see you have many options for filtering which events are transmitted to IBM QRadar.

How much storage does Alliance LogAgent use, and will I need to add storage?
Alliance LogAgent does not make any temporary or permanent copies of security information and will not impact your storage utilization. The only storage you need is for the Alliance LogAgent program objects (about 100 Megabytes) and you will not need to add additional storage.

How are security events transmitted to QRadar, and will I need third party software for this?
Alliance LogAgent provides the communications applications as a part of the base product and you will not need any third party software.

Can I monitor exit points like FTP?
Yes, Alliance LogAgent monitors the FTP exit point and several other critical exit points provided by IBM. These include the exit points for remote data queues, SQL (including ODBC), DB2, FTP and many others. Please contact Townsend Security if you have questions about a specific exit point. New Exit Point monitors are added on a periodic basis.

Can I monitor messages in the system history file (QHST)?
Yes, Alliance LogAgent for IBM QRadar can monitor messages in the QHST system history files. It automatically detects new QHST files created by the operating system and processes messages in near real time.

Can I monitor changes to database files at the field level?
Yes, Alliance LogAgent for IBM QRadar includes a license for the File Integrity Monitoring module. This gives you the ability to monitor access to one or more fields in any database file. There is no limit to the number of fields or files that you can monitor. Monitoring also includes processing file open and close requests so that you have a full picture of user access to a file.

Can I my RPG and CL applications write messages to QRadar?
Yes, Alliance LogAgent can monitor one or more user data queues and transmit messages to QRadar. Your application can write the important security information to the data queue and Alliance LogAgent will add the QRadar headers, convert to the ASCII character set, and transmit the event to QRadar in the appropriate format. There is no limit to the number of data queues you can define or the number of messages.

We use Splunk for log collection, can we use IBM QRadar at the same time?
Yes, many customers use both Splunk and QRadar at the same time. You will find information in the IBM and Splunk documentation on how to implement these solutions together. It is recommended that you send information to QRadar in the native Log Event Extended Format (LEEF) first, and then forward the information to Splunk. This will give you the best security implementation.

How is Alliance LogAgent for IBM QRadar licensed?
Alliance LogAgent for IBM QRadar is licensed on a Logical Partition (LPAR) basis at a flat fee per LPAR. Multiple license discounts are available. Please contact Townsend Security for pricing and support options.

I am using a different SIEM solution, can I use Alliance LogAgent?
Yes, Alliance LogAgent works with all major SIEM solutions including, but not limited to, LogRhythm, Alert Logic, AlienVault, Splunk, McAfee and managed service providers like Dell SecureWorks, NTT/Solutionary and others. If you decide to upgrade to IBM Security QRadar you can easily upgrade to Alliance LogAgent for IBM QRadar.

I need help installing IBM Security QRadar, can you help us?
Townsend Security provides no-charge support for installation and configuration of Alliance LogAgent for IBM QRadar on your IBM i server. If you need assistance with installing, evaluating and using IBM Security QRadar we will provide you with an introduction to a certified IBM QRadar partner company.

Can I try Alliance LogAgent for IBM QRadar on my IBM i server?
Yes. Alliance LogAgent for IBM QRadar can be downloaded and installed on your IBM i server at no charge. During the evaluation period the solution is fully functional and you can integrate it with IBM Security QRadar at no charge for the Townsend Security software (IBM QRadar EPS charges may apply).

How do I get started with Alliance LogAgent for IBM QRadar?
Once you request an evaluation of Alliance LogAgent for IBM QRadar you will receive information on how to download the software and install it on your IBM i server. The Townsend Security customer support team will provide you with training and support at no charge.

If you have any other questions about Alliance LogAgent for IBM QRadar, or other Townsend Security solutions, please contact us.

IBM i Security QRadar Log Collection

Topics: System Logging, IBM QRadar, Alliance LogAgent for IBM QRadar

Congratulations on taking the first step with IBM QRadar!

Posted by Patrick Townsend on Jan 20, 2016 2:55:00 PM

Now it’s time to take the next step and improve your IBM i security.

Take a victory lap, you deserve it!

IBM i Security QRadar Log CollectionYou deployed one of the best security applications to help protect your IBM i data - IBM Security QRadar. As a Gartner Magic Quadrant leader in SIEM the QRadar solution is proving a valuable part of your company's’ security strategy. IBM QRadar is easy to deploy, easy to use, easy to manage, and automatically learns about your environment to get better over time. Actively monitoring your network, applications and systems is one of the Top 10 security controls, and QRadar is one of the leading SIEM solutions. You deserve that victory lap!

After you take that victory lap and catch your breath, it is time to take the next step.

The NEXT STEP ???   I thought I was DONE !!!

Not quite. Like all SIEM solutions IBM QRadar works best when it gets information in real-time. When QRadar can see an authority failure, a rogue SQL statement, a change to a system value, or any other critical security event in real time it can correlate that event with all of the others from across your Enterprise. It can evaluate its likely impact and compare it with other events to understand the severity of the event. Real-time monitoring is crucial for good security.

The default Device Support Module (DSM) provided by IBM QRadar provides for a periodic, batch view of basic IBM i security events. Because it is a batch process most IBM i users only collect security events once or twice a day. There is no real-time collection available and your QRadar implementation is not functioning as well as you might like.

Fortunately, it is really easy to fix this. Alliance LogAgent for IBM QRadar from Townsend Security helps you take the next step by providing that real-time monitoring for your IBM i server. Running in the background, Alliance LogAgent collects security events, converts them to IBM QRadar format, and transmits them to QRadar as they happen. Attempted hacks to your IBM i server are captured when they happen, not hours later. And QRadar sees them immediately. You get better security within a few minutes of installing Alliance LogAgent for IBM QRadar.

In addition to real-time monitoring, you also get these critical security functions that are not included in the default QRadar DSM for the IBM i:

  • File Integrity Monitoring (FIM) for any DB2 database file on your system. You can monitor access to sensitive data on a field level.
  • System history file (QHST) monitoring for critical messages and interactive logon and logoff activity.
  • User data queue monitoring so that you can write your own security events from your RPG and CL applications.
  • Exit Point monitoring so that you can monitor and record the host server activity and send the information to QRadar.
IBM Business Partner: Certified Ready for Security Intelligence

Active monitoring with IBM Security QRadar is one of the most important things you can do. Deploying Townsend Security’s Alliance LogAgent for IBM QRadar will make you more secure by making QRadar better. It’s affordable and easy to deploy. You can download a fully functional evaluation and see for yourself. Alliance LogAgent for IBM QRadar is certified by IBM and supported by the QRadar DSM.

That next step is not a big one, but it has big benefits.

Patrick

IBM i Security QRadar Log Collection

Topics: System Logging, IBM QRadar, IBM Security Solutions, Alliance LogAgent for IBM QRadar

How Does LogAgent Send Security Information? Is Information Batched?

Posted by Patrick Townsend on Oct 23, 2015 4:34:00 PM

Q: How does LogAgent send security information to my SIEM or log collection server? Is information batched or real time?

System Logging Resource Kit The Townsend Security solution for system logging and SIEM integration is Alliance LogAgent. It works with a large number of SIEM solutions including IBM QRadar, LogRhythm, Dell SecureWorks, NTT/Solutionary, Splunk, Alert Logic, HP ArcSight, McAfee, and many others. It brings the IBM i (iSeries, AS/400) into an active monitoring strategy that is so important to good security. Since real-time security event collection is crucial to active monitoring, customers often ask us how Alliance LogAgent achieves this? Let’s take a deeper dive into how this is accomplished.

The IBM security audit journal is named QAUDJRN and it collects most of the critical security events on the IBM i platform. Unlike many IBM i system logging tools, Alliance LogAgent collects events from this journal in real time. Using IBM provided application program interfaces (APIs), events are collected from the security journal as they are written to the journal by the operating system. There is no batch-oriented extraction of events once or twice a day, and no batch transfer using unsecure FTP. Alliance LogAgent is able to grab the events as they become available. This provides the real-time view of security events that is so critical to active monitoring, correlation and alerting by SIEM solutions.

Once the event is extracted it has to be converted into a usable format. The security event information in QAUDJRN is in an internal IBM format and is stored in the EBCDIC character set which is largely unusable by SIEM solutions. Alliance LogAgent immediately converts the important information into a system log format (syslog, Common Event Format, or Log Event Extended Format), and translates it to the ASCII character set that is used by SIEM solutions. To make the information usable to SIEM solutions the event information is normalized into fields that are easy for SIEM solutions to understand. These normalized fields are in the keyword=value format (more on this is another blog). The formatting also happens in real time so that there are no delays imposed by the conversion process.

Once the security event is extracted and converted to a usable format, it must be communicated to the SIEM solution for processing. Alliance LogAgent implements a set of syslog communications modules that immediately send the security event to the SIEM server. Alliance LogAgent supports three different syslog communications options:

  • Internet UDP protocol
  • Internet TCP protocol
  • Internet TLS encrypted TCP protocol

By default these communications programs send security events to the standard syslog port of 514 on the SIEM server, but you can easily change the port number if needed. Not every SIEM solution supports encrypted transfer of log events, but Alliance LogAgent gives you this option along with non-encrypted options for log transfer.

Alliance LogAgent runs in a background batch process at a low priority so that it does not disrupt normal interactive response times. Using the optimized processes of Alliance LogAgent the IBM i customer achieves real-time processing of security events and gets the best results and maximum benefit from their SIEM solution. Security issues are identified immediately and the IBM i system administrator can react swiftly to potential security breaches.

Additionally, Alliance LogAgent takes a similar approach to monitoring other security event sources on the IBM i platform. The QHST system message facility is also monitored in near real-time as messages are logged to the QHST files. For messages sent to the system operator message queue QSYSOPR or QSYSMSG, Alliance LogAgent also monitors these message queues for events and sends the information to the SIEM server in real time. The same is also true of the Alliance LogAgent exit point monitoring applications.

Alliance LogAgent was built from the ground up to accommodate real-time security event collection and transmission to your SIEM solution. It is fast, efficient, and non-intrusive. Exactly what you need to collect and monitor security information on your IBM i platform.

Request your System Logging Resource Kit

Topics: System Logging, IBM i, Alliance LogAgent


Subscribe to Email Updates

Posts by Topic

see all