Townsend Security Data Privacy Blog

As we discovered in the blog Signs Your IBM i May Have Been Hacked, the combination of secure system logging on the IBM i and log monitoring with a SIEM will help you secure sensitive data and minimize the impact of security breaches.  Hopefully you were able to watch the webinar resource provided (if not, you can request it HERE).  After the webinar, we had a number of questions asked by attendees and answered by industry experts from Townsend Security and Integrity.  Here is a recap of that Q&A session:

Q: Do compliance regulations require system logging?

A: Most regulatory compliance standards such as PCI-DSS, FISMA, GLBA, and HIPAA/HITECH require organizations to monitor their network in real-time and provide audit reports. For the Payment Card Industry Data Security Standard (PCI-DSS), there are numerous logging requirements to be PCI compliant. Auditors want to look at how the logs are generated, whether it’s systematic or whether an operator can access/edit them, go in and pull them off and move them somewhere else. They want to look at if there’s mirrored events, where they go off the system through an automated process without any potential human intervention. It also details if people have the right privileges. Logs will show user events as well as what individuals are accessing libraries, files, or other areas outside of their designations. Logging is not only an industry best practice, it is a critical control to understanding access to a system.

Q: We have some custom applications that run our core business. Can a SIEM solution analyze the log files that come from these applications?

A: Dave Nelson from Integrity answers “Some SIEM applications are able to analyze log files from custom applications, others are not. Integrity’s SIEM can create a custom parser that can take just about any log that you can provide. Integrity can analyze that, we’ll work with your internal application development staff to identify what different error codes or security event log codes or whatever it is that you’re creating to identify a specific event. We can map that then into the parser then we can map those to either standard alerts or we can create new custom alerts, we can customize thresholds and a lot of different things. That’s one of the reasons that our customers choose us most frequently is because they have those internal applications that are custom that a lot of the other SIEM tools can’t handle, but we can handle and we can give them a lot of information about something that’s very unique to their business.”

Q: You mentioned File Integrity Monitoring (FIM), can you further explain how an organization would use it?

A:  It’s not every field that you’re going to want to alert and log and monitor on, but there might be ones with credit card numbers or store order authorization codes that you want to monitor and make sure the data hasn’t been altered or accessed without consent. The point to stress with logging and file integrity monitoring is ultimately it helps the individual system operator. You can have mirror alerts go to multiple people in the company, security officers as well as system operators. With FIM you take responsibility off of any one person having to follow up and do it all and you can create more of a collective team that analyzes this data to help the business.

Q: How can we distinguish a false alarm from a successful attack?

A: Sometimes it can be very difficult to determine a false alarm from a successful attack until you have done an entire investigation.  People that do this day in and day out and can begin to identify the patterns and trends of what makes an attack successful or not.  In our experience, the easiest way to do it is to look for key data points or key events that should have happened. One of the things you can do is jump right to the end if you know that a specific attack is successful, and work your way back through the system to determine the file name and creation date.  This really only comes with experience and practice of identifying the missing pieces.

Please post any additional questions you may have here on the blog!

For a much deeper and more detailed discussion on secure system logging and monitoring as essential controls to detect and mitigate the risk of a data breach, please request a download of the entire webinar:

(Based on a recent webinar with Townsend Security and Dave Nelson, President of Integrity)

Your IBM i may have been hacked and you don’t even know it yet!

Industry experts from Townsend Security and Integrity discuss how the combination of secure system logging on the IBM i and log monitoring with a SIEM will help you secure sensitive data and minimize the impact of security breaches. Topics cover (and go beyond) how log files and log data are the digital evidence (artifacts) that actually take us to a point of action within a system. They look at what the false alarms are within the plethora of data and how to screen those out. Then they also talk about the next steps: What are the red flags to watch for, and what to do with those red flags.

“As we look at the millions of data points that are created each day, every login or logout, every time a user is created, every time a user accesses a resource or adds a new resource or saves a file…. amidst all that data, hacking events happen. What we have to try and do is understand the ways that we can sift through that data and reduce the background noise and address the successful attacks.” (Dave Nelson)

Things to look for in log files as we’re trying to identify what’s real data, false alarms, or red flags:

New users and user accounts - Look for things like random names (like BSX or BS4XOR) and be able to identify new users. Always be able to trace these new user accounts back to a user account request and be able to identify which of those accounts have an approved resource and which ones have not.

New files and directories - Identify new directories, look for batches of files that show up between things that are normally next to each other. One of the things hackers love to do is hide files on any sort of Windows mountable or UNIX mountable directories within your i Series because a lot of times the IBM i doesn’t have an antivirus check or an antivirus application on it.

Date and time stamps - There are some (system) files that you know shouldn’t change. If you start to notice that those file modification dates or the save dates on those files and libraries have changed, that should start to be a red flag.

Significant increase or decrease in the size of a file or a library - Hackers will inject data into the back end of an existing file so that the file itself doesn’t change and it can still be executed. So watch for files that used to be a few kilobytes and are now a few megabytes or even gigabytes.

New processes or services that are running - Anytime you have a batch job that’s running and you’re not familiar with it, that should be something that you look at right away. Look for unusual interactive jobs working between LPAR’s or between systems. Do you normally have data leaving your IBM i and going to another platform? or a direct connection from a Windows server directly into your IBM i?

Cryptic or unusual file names - Create some sort of naming convention within your organization so that you know if something is outside of that standard.

It is suggested that we think of log files as the forensic evidence for the IBM i system and think about monitoring almost as a crime scene investigation. The relationship between the logging agent and the collector of those logs is very important because unexplained system value configuration changes, application changes, changes to privileges and privileged user profiles are indicators of potential malicious activity that you can record. These logging tools are strengths for an organization to really get to know what the system is doing as part of daily business activity, and then how to alert and monitor for data protection.

With all the different types of data that you can look for, the sheer volume of information that’s out there, there’s absolutely no way that an individual system administrator and application developer, even a full time security professional is going to be able to sift through that amount of information. Partnerships between the SIEM (Security Information and Event Management) collector and the logging agent are now industry standard defense and depth controls. Automation and email notifications about potential malicious activity can immediately give you the chain of custody to provide the digital evidence you require to go investigate further. You want to be able to drill down to specific threats, events, and user specific events as part of any good governance risk & compliance program and risk management approach. Essential for a total enterprise solution is the partnership (and strong encryption) between LogAgent and a SIEM.  

As a SIEM solution that partners with Townsend Security’s logging solution*, what Integrity’s done differently is provide a managed SIEM service. Dave tells us “We’ve got clients running this on the i Series platform using Alliance LogAgent to monitor, interfacing with our SIEM, and  they have said ‘Wow, we didn’t have any idea that we could get this much information and that it could be this easy to access and that we can share it’.  Clients want to be able to share that with their network administrators and say ‘See, this is what we’re seeing, we’re seeing this traffic and we don’t know why it’s coming in, can you please stop it and block it’.  One of the best things about Integrity’s SIEM solution from a cost perspective is that there’s no capital investment. You don’t have to spend $100,000 for the software, $50,000 for hardware and then go out and hire a full time person to review these logs and to set up the system and manage another system and application within the environment. It’s all provided for you for a low monthly cost. You get this in a matter of days and weeks instead of a matter of months. So you’re getting immediate return on your investment. In these economic times we all know how important that is to be able to show ‘Hey, we’re getting some real value for this expenditure that we’re making, we’re seeing a lot of things happening’. One of the other benefits is that you’re not going to see just security information from this. The amount of information that you’re going to get, you’re going to see operational things that you hadn’t seen in the past. You’re going to see things that you look at and say ‘Wow, we had no idea the system was operating that way, or those processes were running, or those jobs were running or taking so long to run’. The feedback that we get from our clients is that the value they get from the operational side of the SIEM is almost, if not as much, as what they get from the security side of the SIEM. So just being able to see deeper into the environment and seeing what’s happening, what’s going on has been great for a lot of our clients as well.”

*Townsend Security’s Alliance LogAgent is a comprehensive platform specific solution for IBM i which helps cut through the noise and deliver granular valuable data, providing file integrity monitoring right down to field level changes. Key steps you want and need for compliance purposes as well as data security.  

For a much deeper and more detailed discussion on secure system logging and monitoring as essential controls to detect and mitigate the risk of a data breach, please request a download of the entire webinar:

If these technologies are not in place, do you really know you haven't been hacked?

As we discussed in the blog Understanding System Logging on the IBM i – Part 1, secure system logging on the IBM i (AS/400) can not only help you meet compliance requirements, it can help you stop a data breach before it happens!  Hopefully you were able to watch the webinar resource provided (if not, you can request it HERE).  After the webinar, we had a number of questions asked by attendees and answered by security expert Patrick Townsend.

Here is a recap of that Q&A session:

Q: Can you pick which group of users to audit?

Patrick: In our current version of Alliance LogAgent, our IBM i system logging solution, you can define a list of “excluded users.”  So you can actually tailor events on the IBM i platform and exclude particular user profiles.  We also provide some basic filtering capability allowing you to filter based on IBM event type and on User event type.  So yes, there is a fair amount of filtering capability in the product.  From a security posture, it would be a mistake to filter out significant security events, however the solution allows you to easily choose and select the events you want.  We have an option that maps straight to the security system values so you can easily set LogAgent to process those or you can establish and select any and all of the event types in the product that you want to monitor.

Q: With all the different IBM system events, is it possible to set up filtering of just the IBM security event types?

Patrick: Yes, In our solution, collection of the system security events is set as the default “out of the box” setting.  You have total control over the events you collect, and with just a few keystrokes, you can re-map your collection and filter in additional events, or leave it set to what IBM identifies as the security type events being collected in QAUDJRN.

Q: Can File Integrity Monitoring (FIM) also monitor read access to a database file? What about a user that comes in from another server doing just a select in SQL?

Patrick: The File Integrity Monitoring component in LogAgent is based on a database journal. A record-level read event is not collected in a database journal; but a file open and closed event is collected.  So if a user does access a file through read and there’s no update, insert, or add type of event, it may not appear in the journal. We capture all the information that the system makes available to us in the file integrity monitoring component on significant changes or access to any protected file.

Q: You mentioned File Integrity Monitoring. Can you further explain how an organization would use it?

Patrick:  File Integrity Monitoring is designed to monitor configuration changes and highlight them for early detection.  Generally, when an attack happens on an application it often involves changes to configuration files in an attempt to escalate privileges and give the attacker more authority or access than they should have.  For example if a new user is suddenly granted authority in the HR application to print checks, that is an important indicator of a potential problem!  Another common use for File Integrity Monitoring is to monitor the use of stored sensitive information (credit card information or social security numbers) on your IBM i platform, you would want to use FIM on those databases or applications in order to strengthen your security stance and identify those potential attacks early on.

Q: How do you keep QAUDJRN entries from flooding the network?

Patrick: With the large volume of events that can be collected by QAUDJRN, you can really help minimize network impacts by filtering out events that are not security related.  You can still collect those events, but exclude them from being transmitted to your SEIM console.  Because LogAgent works in real time it helps reduce the impact on your network because you are not transmitting millions of events all at once. We also provide metering capabilities so you can reduce the number of events per second that are being transmitted.

Q: How do these logs get stored?

Patrick: When it comes to log storage, you want them off of your IBM i platform as quickly as possible to avoid potential tampering or corruption.  With LogAgent, we do not make a copy of the events, we take the filtered events out of QAUDJRN in real time, format and transfer them to your log collection server or SEIM.  Since some compliance regulations require the events are stored for a defined period of time, SEIM consoles compress, store, and protect those log events so you have the ability to do forensics, queries, and reporting on them.

To learn more, view our webinar "Understanding Log Management on the IBM i" which examines the security principles, compliance requirements, and technical challenges for log collection and forwarding on the IBM i platform with the following learning objectives:

• Security principles of log collection and monitoring
• Compliance requirements of PCI DSS, HIPAA/HITECH, SOX, GLBA/FFIEC
• Communicating with log collection and SIEM servers
• File Integrity Monitoring and log collection
• IBM i log collection challenges

 

If you have further questions, please list them here in the comment section and we will be sure to get you an answer!

Secure system logging on the IBM i (AS/400) can not only help you meet compliance requirements, it can help you stop a data breach before it happens!  Intruders may start with a password hack that gives them access deeper into the system.  There is usually a long trail, visible within system logs. Everything from the original breach can be detected and identified with proper monitoring of the system logs.  What really is driving the need to collect and monitor system logs centers around how often breaches are easily detected with log management.  For example:

• Less than 1% of the breaches were discovered through active log analysis
• Forensics showed 69% of these breaches were detectable via log evidence

Compliance regulations require (or strongly recommend) system logging. Do you know which of these apply to you and your company?

PCI Section 10 requires logging for anyone who collects credit card data

Requirement 10:  
 “Track and monitor all access to network resources and cardholder data”

• 10.1 Establish a process for linking all access to system components (especially access done with administrative privileges such as root) to each individual user.
• 10.2 Implement automated audit trails for all system components to reconstruct the following events:
• 10.3 Record at least the following audit trail entries for all system components for each event:
• 10.4 Using time-synchronization technology, synchronize all critical system clocks and times
• 10.5 Secure audit trails so they cannot be altered.
• 10.6 Review logs for all system components at least daily.
• 10.7 Retain audit trail history for at least one year, with a minimum of three months immediately available for analysis.

GLBA / FFIEC recommends data security logs of actions that could affect financial reporting or fraud for financial institutions.

• Network and host activities typically are recorded on the host and sent across the network to a central logging facility.
• The logging facility may process the logging data into a common format. That process is called normalization. Normalized data frequently enables timely and effective log analysis.

(This Link provides more information about FFIEC recommendations for logging)

HIPAA / HITECH ACT requires system logs of access to Protected Health Information (PHI) in the medical sector

• LOG-IN MONITORING (A) - § 164.308(a)(5)(ii)©

…the covered entity must implement: “Procedures for monitoring log-in attempts and reporting discrepancies.”

• Access controls - § 164.312(b)

(section b) Standard: Audit controls. Implement hardware, software, and/or procedural mechanisms that record and examine activity in information systems that contain or use electronic PHI.

There are other compliance regulations and protocols that apply, but they all say about the same thing … you should be collecting system logs, you should be monitoring them, and you should take action based on anomalies that you find in them.  It is not enough to assert that you are doing the right thing; you have to be able to prove it with system logs that are independent from the original system files and verifiable.

System logging is important across all operating systems, but we are going to look at IBM i with greater detail due to it’s complexity.  Because the IBM i system can handle multiple applications, it doesn’t log information like others do.  The IBM i collects logs simultaneously from multiple sources and deal with large volumes: Up to 3,500 events per second…250 Million of events per day!  The essence of good reporting is externalizing the systems logs and collecting them in a central repository which helps remove the risk of tampering. Compliance regulations recognize the need to watch all users – including the most powerful users, because network originated threats to the IBM i are often not noticed or quickly responded to by IT security professionals without close monitoring of system logs.

Creating the QAUDJRN (Security Audit Journal) on the IBM i

QAUDJRN is not created or enabled by default on the IBM i platform.  If you have not set it up, you are not yet collecting system logs.  To implement system logging you create the journal and journal receiver, then set system values that control options about what information is collected. Once the values are set, the collection process begins.  QAUDJRN is non-modifiable and date-stamped and a large amount of useful information can be collected in each event.  However just running system log reports on the security audit journal are not enough. Centralizing events and monitoring them off the IBM i platform are crucial. The events need to be consolidated and correlated in a separate location (usually a SIEM Console) in order to see the whole picture and understand potential attacks on your system.  

Take Away:
If you are properly collecting and monitoring your system logs, you can detect a breach before data is lost.

To delve deeper into this topic, we are sharing this newly recorded webinar in which, security expert Patrick Townsend talks about system logging on the IBM i today and how the capabilities of Alliance LogAgent can provide you with a high performance, affordable solution that will communicate system logs securely between your IBM i and Security Information and Event Management (SIEM) Console.

As always, we welcome your questions and comments posted here!

Podcast: Better System Logging Download the podcast "System Logging on the IBM i - How to Do It Better." Click Here to Download Now

If you could find out if your network is being hacked or tampered with, as it happens in real time, would you want to know? If there was a tool that collected, encrypted, and standardized your IBM i security events to give you peace of mind, would you use it?

We’re guessing yes. Luckily, system monitoring software is widely available for IBM operating systems, and there are two big reasons why you should use system monitoring:

1. Most system breaches go unnoticed for months (sometimes years) before the breach is discovered and dealt with. By then a hacker or employee may have gained access to thousands of personal files containing sensitive information such as credit card numbers and home addresses.

2. Less than 1% of the breaches in 2011 were discovered through log analysis, even though 69% of these breaches could have been detected before any data was lost if proper system logging was in place.

You know you need to collect your system logs in real time in order to detect unauthorized changes to your system, but with all of your security logs being created on different systems, web services, and applications, the task might seem overwhelming. How do you get a consolidated view of the security state of your database? How do you get information into usable format for log collection and Security Information & Event Management (SIEM) servers?

The answer is in a third party logging solution that can standardize, collect, and report security events. There are many logging solutions out there, but your solution should always provide you with these four key points:

1. Real time Log Collection. Your logging solution should collect logs of events in real time as they happen across multiple applications and servers. You should be alerted immediately to suspicious log events on your servers instead of receiving a batch at the end of the day or week.

2. High Speed Performance. Performance should not be a barrier when it comes to log collection and analysis. Your logging solution should be able to collect tens of millions of events from multiple applications and thousands of users per day without huge performance impacts.

3. Secure Communication. Your logging solution also needs to secure the transfer of events to a log server. Your logging solutions should use SSL TCP to encrypt log entries in transit from an IBM server to a log collection server.

4. Industry Standard. There is a standard format for system log events, and the data you collect from your IBM i and transfer to your log collection server should be in that format. The most widely used standards are the syslog standard based on RFC 3164 and the Common Event Format (CEF) used by a number of SIEM vendors.

Townsend Security’s Alliance LogAgent and LogAgent Suite with File Integrity Monitoring (FIM) allows IBM i users to meet compliance regulations by collecting security system logs and transmitting to a log collection server or any SIEM solution. Alliance LogAgent will help you achieve inner peace of mind.

Download Trial: Alliance LogAgent Suite Download a free trial of Alliance LogAgent Suite, our file integrity monitoring Solution. Click Here to Download Now

Many compliance regulations require that you monitor critical system files, application configuration files, and sensitive file content for unauthorized changes. In the PCI Data Security Standard (PCI DSS) which applies to everyone who accepts credit and payment cards, here is what Section 11.5 says:

11.5 Deploy file-integrity monitoring software to alert personnel to unauthorized modification of critical system files, configuration files, or content files; and configure the software to perform critical file comparisons at least weekly.

Other compliance regulations also require this type of integrity monitoring and they are reflecting the security best practices in NIST’s Special Publication 800-53. Here are a couple of extracts on integrity monitoring from that guidance:

Section 3.4 – Monitoring Security Controls: Significant changes to the configuration of the information system through the removal or addition of new or upgraded hardware, software, or firmware or changes in the operational environment potentially degrade the security state of the system.

And:

SI-7 Software and Information Integrity

Control: The information system detects unauthorized changes to software and information.

Supplemental Guidance: The organization employs integrity verification applications on the information system to look for evidence of information tampering, errors, and omissions. The organization employs good software engineering practices with regard to commercial off-the-shelf integrity mechanisms (e.g., parity checks, cyclical redundancy checks, cryptographic hashes) and uses tools to automatically monitor the integrity of the information system and the applications it hosts.

What do IBM i (iSeries, AS/400) customers need to do to meet these file integrity monitoring compliance regulations? Here are the steps you should take to meet file integrity monitoring requirements:

• Identify, inventory, and monitor the application configuration files that control important security controls. You may need to work with your third-party software suppliers to know which files contain this information.
• Identify, inventory, and monitor the application database files that contain sensitive information. This would include files that have credit card numbers, social security numbers, and other Personally Identifiable Information (PII).
• Configure and enable system monitoring of changes to system values and network attributes. This involves setting up the system security journal QAUDJRN and initiating monitoring. IBM provides guidance on how to do this.
• Collect and transfer file integrity security events to an organization-wide security monitoring and alerting system. This will be a Security Information and Event Monitoring (SIEM) solution that you deploy in-house or through a Managed Security Services Provider (MSSP). It is impossible for humans to properly monitor file integrity events and this is the province of SIEM solutions.

Implementing all of the components of a file integrity monitoring system on the IBM i system is a huge task. Almost all IBM i customers will turn to off-the-shelf solutions to help them achieve compliance with data security regulations.

Our Alliance LogAgent Suite provides the full set of functions and capabilities you need to meet compliance regulations for file integrity monitoring. It monitors system configuration changes through the QAUDJRN security journal and from system history file QHST. It monitors and reports changes to your application configuration files. It monitors and reports changes to sensitive data such as credit card numbers, social security numbers, or any field you want to monitor. It applies user and application whitelists to minimize the volume of events.  And it securely reports events to a SIEM solution using industry standard formats. It is affordable, easy to deploy, and is easy on system resources.  We encourage you to try a free 30-day evaluation of our file integrity monitoring solution and see for yourself. We can get you up and running within an hour.

Because file integrity monitoring is crucial to your security posture, I will be talking more about the functions and features of Alliance LogAgent Suite for the IBM i platform in future posts.

Patrick

PCI DSS.  HIPAA/HITECH.  State Privacy Laws.  What do all these compliance regulations have in common?  They require you to be collecting and monitoring your system logs.  To give an example of how logging works, if someone tries to sign into an IBM i (or any server) and for whatever reason and the username or password is invalid, that event is logged in the system log.  Why is this important?  Because if you were to look at this system log in real-time and notice several invalid username and password events, you would say “Hey, our system is being attacked. We need to take action on this now.”  

Unfortunately, compliance regulations sometimes aren’t enough of a reason for a company to do everything that they should to protect your sensitive data.  Many times there just isn’t a budget for additional technology or when management does spend money, they want to see a return on their investment (ROI).  Luckily, there is a clear ROI when you invest in a system logging solution.  Here are three things to help you make your case to management on why you need to purchase a system logging solution:

1) Save Time
System logging can make life easier for the IT department, giving them back time to work on other projects.  Recently we had a customer purchase Alliance LogAgent, our IBM i (AS/400) system logging solution, and was sending system logs to his SIEM console within an hour of getting started.

2) Save Money
Everyone wants to save money, right?  Sure, it might be possible to write your own logging application (not an easy feat on the IBM i), but why waste a developers valuable time?  Alliance LogAgent is a low-cost solution that is trusted by companies worldwide.

3) Solve Business Problems
System logging will solve business problems. An audit can be a problem and we see companies getting dinged on logging all the time.  Not knowing who is logged into your system is a problem that auditors will not overlook.  The sooner you can get through an audit, the sooner you can be back to focusing on business.

Listen to our podcast “System Logging on the IBM i” for more information on logging, how it can help you meet compliance requirements, what to look for in a logging solution, and how Townsend Security can help you transmit the logs from your IBM i to any SIEM console.

Podcast: Better System Logging Download the podcast "System Logging on the IBM i - How to Do It Better." Click Here to Download Now

Townsend Security’s latest version of Alliance LogAgent, Alliance LogAgent Suite, will allow IBM i log agent administrators to stay one step ahead of security compliance regulations. In a recent podcast, Patrick Townsend, Founder & CEO, discussed this enhancement:

Our major enhancement to Alliance LogAgent allows system logging administrators to extend visibility right down to the field and column level, record-by-record, in their databases. With the new features you’ll have the ability to monitor any particular file in order to recognize exactly which fields were viewed or changed by a particular user. The ability to do this is a soon-to-be critical area of compliance. Customers will need to be able to do forensics on access to particular fields in particular records.

European companies have some additional log management compliance regulations that we don’t yet experience in the United States, but these regulations are coming towards us. Advanced system logging on the IBM i is becoming more important than ever. With Alliance LogAgent Suite we give you the option to log the before and after versions of a particular field so you can see if there was a change made and what it was. If the field contains sensitive data, we can also log a secure hashed value of that field in order to keep the field completely secure.

Alliance LogAgent Suite will also let you create white lists of inclusion (people who should be able to see values in the database) and exclusion (who should not be able to see them). We can then log those unauthorized accesses, so that log management administrators don’t need to depend on native object authority on the IBM i. Instead you’ll see record-by-record, column-by-column level access and who has seen data they should or shouldn’t have seen.

We’ll also let you select floor and ceiling values, so that when a value goes over or under a certain amount, Alliance LogAgent Suite will alert you and record the event in a log. For example, a systems administrator at a bank could establish a wire transfer ceiling of $10,000 so that if an employee tried to wire $1 million to Aruba, LogAgent Suite would detect this report this large transfer attempt immediately.

These new features in Alliance LogAgent Suite will substantially improve the security posture of a company using system logging the IBM i. The implementation of LogAgent suite is easier than ever and will help to prepare IBM i users for the evolution of new compliance regulations.

Download a free 30-day evaluation of Alliance LogAgent Suite to start meeting compliance regulations (PCI DSS, HIPAA, etc.).  In under an hour, you can start collecting all system logs on your IBM i (AS/400) and converting them to syslog or CEF format for any SIEM or log collection server.

Section 10 of PCI DSS requirements v2.0 states the need to track user activities, to be able to detect, prevent or minimize the impact of a data compromise.  Because of the mere fact that most every application under the sun produces a log entry for when something goes amiss, you can also use that same log file as a security tool.  It can provide a means of tracking and analysis when a possible data breach may be occurring as well as add crucial detail for investigative purposes.  Now a smart criminal knows to cover their tracks at the scene of a crime, and they can do this simply by wiping out any log data that may exist.  However if you’re capturing these logs in real time and sending them to a third party server, even the most savvy of crooks will be caught red handed.

Our Alliance LogAgent solution helps accomplish that, as well as satisfying parts of section 10 of PCI DSS by being able to capture logs from your IBM i’s audit journal, formatting them and sending them off to a waiting log collection server.  We monitor for log entries out of numerous places on the iSeries allowing the user the a level of granularity to choose what log messages to capture and kick over the wall to the waiting log server.  It's always a good idea to work hand-in-hand with your PCI auditor to make sure you're collecting all the appropriate events on your system to meet their requirements.

For instance, you'll want to make sure you're collecting AF (Authority Failure Events) events which come from the System Value QAUDLVL.  This particular event is triggered by all access failures, such as sign-ons authorization, and job submissions. It also includes incorrect password and user ID attempts from a device.  These details can play a crucial role in tracking down details around a possible breach into your system.  

As I mentioned, Alliance LogAgent sends these events to a listening collection server or SIEM solution.  We work with any SIEM product that is actively listening and waiting for logs to arrive and can accept messages in the RFC 3164 or Common Event format.  There are a number of SIEM products available on the market and they help parse the influx of log messages as they arrive, as well as send out notification and alert emails when something suspicious is detected.

Currently, the PCI guidelines don't include transmitting logs over a secure SSL/TLS session (it’s a very, very good idea).  However, looking ahead to when this becomes a requirement, you can rest assure that you’re already running software that can meet those needs.  LogAgent is already setup to handle secure SSL/TLS transmissions and is one of the reasons it stands apart from the competition.  The only change you'll have to make in the configuration of the product when switching over from UDP/TCP to SSL will be to provide an SSL application ID.  This is an ID that is associated with a digital certificate that you can create with IBM's Digital Certificate Manager (DCM).   Having this secure session in place will ensure that your log message data won't be intercepted on its journey to the collection server.

Download a free 30-day evaluation of Alliance LogAgent Suite and meet Section 10 of PCI DSS.  In under an hour, you can start collecting all system logs on your IBM i (AS/400) and converting them to syslog or CEF format for any SIEM or log collection server.

The Alliance LogAgent Solution for system logging on the IBM iSeries is able to grab log messages out of a variety of places such as your system's audit journal, (QAUDJRN), your history log (QHST), and system operator messages (QSYSOPR) and format them to either a standardized Syslog format, in this case RFC3164 or Common Event Format (CEF). Once formatted, we pass the messages over to the communications module that handles the transmission of the messages to your waiting log collection server using either the UDP, TCP or SSL/TLS protocol.  

LogAgent can send to any collection server that is listening for messages.  You simply assign either a remote host or IP address of the waiting server as well as the port number.  Ideally you would want a SIEM (like from LogRhythm, Solutionary, or SolarWinds, for example) running on that server to read the messages that are received, sort them and send out alarms to your security team when dubious messages arrive.

More often than not you'll want to use the Syslog format as it is generally accepted.  The RFC3164 format that we use is composed of three parts.  The first part is called the PRI, the second part is the HEADER, and the third part is the MSG.  

The PRI part is the Priority value and begins the log message.  Its value is contained within angled brackets and is either two or three digits in length.  It is comprised of the Facility value and the Severity level of the message.  The Priority value is calculated by first multiplying the Facility number by 8 and then adding the numerical value of the Severity.  (Example: <40> )

The second part of the message is the header which will contain a timestamp, and an indication of the hostname or IP address of the device it originated from.  The MSG part will fill out the remainder of the syslog packet and contain the generated message and the text of the message.  

Here is a quick sample of a log message in RFC 3164 format.

<118> Apr 18 16:32:58 10.0.1.11 QAUDJRN: [AF@0 event="AF-Authority failure" violation="A-Not authorized to object" actual_type="AF-A" jrn_seq="1001363" timestamp="20120418163258988000" job_name="QPADEV000B" user_name="TESTFORAF" job_number="256937" err_user="TESTFORAF" ip_addr="10.0.1.23" port="55875" action="Undefined(x00)" val_job="QPADEV000B" val_user="TESTFORAF" val_jobno="256937" object="AFTEST" object_library="CUS9242" object_type="*FILE" pgm_name="" pgm_libr="" workstation=""]


If you're using a SIEM such as ArcSight who is expecting logs messages in the Common Event Format (CEF) you can easily switch the formatting from the configuration menu of LogAgent to send in this manner.  Much like the RFC 3164 version, the message contains a timestamp and hostname or IP address at the beginning.  This is followed by the Extension part of the message and is really a placeholder for additional fields.  Some common fields you'll find are CEF version, Device Vendor, Device Product Severity and Signature ID just to name a few.   

Example of what a CEF formatted log message looks like.

Feb 29 15:47:25 10.0.1.43 CEF: 0|PATownsend|IBM-QAUDJRN|1.28|1007|CO-Create object|4|msg=CO-Create object act=N-Create of new object actual_type=CO-N jrn_seq=102361 timestamp=20120229154725823000 dproc=ICC suser=MVAGANEK job_number=638012 eff_user=MVAGANEK object=X_BIGNUM object_library=ICAPITST object_type=*MODULE object_attrCLE

It's always a good idea to check with the team managing your log collection server to see what format they are expecting log messages to arrive in. Hopefully having a clearer understanding of what your choices are will help make the task of deploying system logging on your AS/400 smoother and easier to satisfy section 10 of PCI DSS compliance.  If you haven't yet, download a free 30-day evaluation of our Alliance LogAgent for IBM i system logging software.  Our customers have deployed the solution in under an hour from the time they download the evaluation from our website!