+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

IBM i System Logging – QHST Messages

Posted by Patrick Townsend on Jun 24, 2014 10:36:00 AM

IBM i users who need to meet compliance regulations for actively monitoring their systems are faced with the challenge of collecting system and security events from a variety of log sources. Collecting events from the security audit journal QAUDJRN is a fundamental requirement, but is it the only place that contains significant security events? The answer is no, there are also significant security events in the system history message file QHST.

IBM i Logging for Compliance & SIEM Integration The most significant security events contained in QHST are the user log on and log off messages. These are stored in the QHST message files with message IDs CPF1164 (log on) and CPF???? (log off). User log on and log off events are, of course, critical for active monitoring of system access, especially for highly privileged users such as QSECOFR and any user with All Object (*ALLOBJ) and security special authorities of Audit (*AUDIT) and ????.  The log on and log off activities recorded in the QHST message files are not available in the security audit journal QAUDJRN, so you must be able to retrieve these messages from QHST to meet compliance regulation requirements for log collection and active monitoring.

Alliance LogAgent supports this requirement by enabling the collection of these events from QHST message files. You can filter QHST message to collect only events for:

  • Log on and Log off messages for all users
  • Log on and Log off messages for only highly privileged users
  • Log on and Log off messages for only QSECOFR
  • All QHST messages

User log on and log off messages are not the only events that have security information. Most IBM i customers will select the Alliance LogAgent option to process all messages in QHST. This gives you a complete record of all events in the QHST message file in your log collection central repository.

There are many challenges in processing messages in the QHST file. These include:

  • The QHST information is in an IBM proprietary format that is impossible for log collection servers and SIEM solutions to process. The messages must be converted to a usable format.
  • QHST message files have a special naming convention and the system automatically generates new QHST message files on a regular basis. You must detect new message files and keep track of which files and messages have been processed.
  • There are no event-driven APIs that allow you to collect new QHST messages in real time. Your QHST collector application must detect new events and process them quickly.
  • The QHST files are not updatable, so your QHST event collector must keep track of the messages that have been processed, and must resume after a system IPL or a system failure without lost information.
  • QHST messages are not automatically transferred to a log collection server or SIEM solution. Communications programs must be able to transfer the messages in real time.

Alliance LogAgent meets all of these challenges. QHST message files are automatically processed in near real time, and handles the generation of new QHST message files by the system. Messages are converted from the proprietary IBM format to the industry standard syslog format (RFC 3164) and converted from EBCDIC to ASCII. Messages are then transmitted to the log collection server or SIEM solution securely and in real time.

The Alliance LogAgent QHST message collector is a part of the base product. If you are currently using LogAgent to process QAUDJRN events, you can just enable the QHST option and you will start processing messages the next time the Alliance LogAgent subsystem starts. If you are implementing Alliance LogAgent for the first time, just enable the Logagent QHST collector before you start the subsystem.

View our webinar "IBM i Logging for Compliance and SIEM Integration" to learn more about meeting compliance regulations and sending logs to any SIEM.

Patrick

IBM i logging for compliance & SIEM Integration

Topics: System Logging, Alliance LogAgent

Actively Monitoring Your IBM i for Security and Compliance

Posted by Patrick Townsend on Jun 13, 2014 10:32:00 AM

Active monitoring is one of the core security recommendations to help prevent unauthorized access to sensitive systems and information. It is a requirement of a wide variety of compliance regulations such as PCI-DSS, HIPAA/HITECH Act, GLBA/FFIEC, FISMA, and many others. From a security perspective, active monitoring makes it into the SANS Top 20 list of things you should do, and is a key recommendation from the US Cyber Security teams.

IBM i Logging for Compliance & SIEM Integration What are the core requirements for active monitoring and what are the special challenges for the IBM i platform? Some core requirements include:

  • Centralize security events from all servers and PCs
  • Perform real-time collection to one central repository
  • Real-time monitoring of events
  • Conduct real-time event correlation for pattern recognition
  • Store events in historical archives for forensics
  • Pro-actively alert the security team for possible breaches
  • Provide event query and reporting services

To meet these requirements for active monitoring, the IBM i can’t be an island of event information. IBM i security events must be consolidated with event information for all of your PCs, servers, and network devices to get a complete picture. Because the volume of events is typically quite large, most organizations will deploy a centralized log collection server combined with a SIEM solution that provides event correlation, real-time monitoring, alerting, and log collection archival.

One of the biggest challenges for IBM i customers is the large number of sources for log information. These include:

  • IBM Security Audit Journal QAUDJRN
  • System operator message queue (QSYSOPR, QSYSMSG)
  • System history message file QHST
  • IBM exit points (SQL, Telnet, FTP, and many more)
  • Linux/Unix style logs (Apache, OpenSSH, Perl, PHP, etc.)
  • DB2 column access
  • User and ISV applications

A good security event collection strategy will have to address all of these sources. Added to the large number or sources are some additional challenges:

  • Security event collection applications are not provided by IBM. They must be written by in-house developers or acquired from third parties.
  • Security information is in non-standard, proprietary IBM formats.
  • There are no native communications applications to securely transmit event information to a log collection or SIEM server.
  • There is no application management structure (start, stop, re-start, audit, etc) for log collection activities.

Alliance LogAgent helps IBM i customers meet all of these challenges. It collects security event information from all significant log sources, converts information to industry standard formats including the syslog format (RFC 3164) and Common Event format (CEF), provides filtering options for messages, and securely transmits them to the log collection server or SIEM solution. Alliance LogAgent keeps track of event sources and won’t skip messages due to an IPL or network outages.

Alliance LogAgent is compatible with all major log collection servers and SIEM solutions, and is an affordable solution for small organizations. View our webinar "IBM i Logging for Compliance and SIEM Integration" to learn more about meeting compliance regulations and sending logs to any SIEM.

 
Patrick

IBM i logging for compliance & SIEM Integration

Topics: System Logging, Alliance LogAgent

System Logging and Compliance Regulations

Posted by Michelle Larson on Jun 6, 2014 9:51:00 AM

Do you know which of these 3 key regulations apply to you and your company?

System Logging Resource Kit Secure system logging on your IBM i (AS/400) can do more than help you meet compliance requirements, it can also help you stop a data breach before it happens!  We will take a quick look at three of the major regulations; PCI DSS, GLBA/FFIEC, HIPAA/HITECH, (keep in mind, there may be other compliance regulations that apply to system logging in your industry as well).

All regulations 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, tamper resistant, and verifiable.

PCI DSS

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.6.x v3 (Nov 2013) noted this clarification: Clarified the intent of log reviews is to identify anomalies or suspicious activity, and provided more guidance about scope of daily log reviews. Also allowed more flexibility for review of security events and critical system logs daily and other logs events periodically, as defined by the entity’s risk management strategy.
  • 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.

FFIEC Action Summary

Financial institutions should gain assurance of the adequacy of their risk mitigation strategy and implementation by:

      • Monitoring network and host activity to identify policy violations and anomalous behavior
      • Monitoring host and network condition to identify unauthorized configuration and other conditions which increase the risk of intrusion or other security events
      • Analyzing the results of monitoring to accurately and quickly identify, classify, escalate, report, and guide responses to security events
      • Responding to intrusions and other security events and weaknesses to appropriately mitigate the risk to the institution and its customers, and to restore the institution's systems

HIPAA / HITECH ACT

Requires system logs of access to Protected Health Information (PHI) in the medical sector

  • Security Management Process - §164.308(a)(1)(ii)(D):
    - Implement procedures to regularly review records of information system activity, such as audit logs, access reports, and security incident tracking reports.
  • LOG-IN MONITORING (A) - § 164.308(a)(5)(ii)(.c) 
    …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.

System logging is important across all operating systems, however the IBM i is a major target for data theft because of the volume of information that can be managed in the system. 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 may deal with large volumes: Up to 3,500 events per second…250 Million of events per day! These events need to be consolidated and correlated in a separate location, usually a Security Information and Event Management (SIEM) console, in order to see the whole picture and understand potential attacks on the system.

Because many unwanted intrusions start with a simple password hack that gives deeper access into your system, there is usually a long trail visible within 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 (forensics show 69% of breaches were detectable via log evidence). Everything, starting from the original breach, can be detected and identified with proper monitoring of the system logs.

To delve deeper into system logging, we are sharing a resource kit of materials by industry expert Patrick Townsend about 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 the IBM i and SIEM Console.

Alliance LogAgent from Townsend Security

  • Creates real-time logs that ALL SIEM consoles can read
  • Forwards important information to your SIEM console in a standard format
  • Uses SSL/TLS encryption to secure delivery
Request your System Logging Resource Kit

Topics: System Logging, IBM i, Alliance LogAgent, Resource Kit

IBM i System Logging – System Operator (QSYSOPR) Messages

Posted by Patrick Townsend on May 30, 2014 11:37:00 AM

IBM i users who need to meet compliance regulations for actively monitoring their systems are faced with the challenge of collecting system and security event information from a variety of log sources. We know we have to collect information from the IBM security audit journal QAUDJRN, but there are often additional security events in the system operator’s message queue QSYSOPR. The system operator message queue receives message from the IBM i operating system as well as from user applications.

IBM i Logging for Compliance & SIEM Integration There are many challenges in processing messages in the QSYSOPR file. These include:

  • The QSYSOPR message information is in an IBM proprietary format that is impossible for log collection servers and SIEM solutions to process. The messages must be converted to a usable format.
  • Access to the QSYSOPR message file by an event collector can conflict with the access by the actual system operators.
  • There are no event-driven APIs that allow you to collect new QSYSOPR messages in real time. Your QSYSOPR message collector application must detect new events and process them quickly.
  • The QSYSOPR messages are not updatable, so your QSYSOPR event collector must keep track of the messages that have been processed, and must resume after a system IPL or a system failure without lost information.
  • QSYSOPR messages are not automatically transferred to a log collection server or SIEM solution. Communications programs must be able to transfer the messages securely in real time.

Alliance LogAgent meets all of these challenges. QSYSOPR messages are automatically processed in near real time. To avoid potential access conflicts, Alliance LogAgent can collect messages from the QSYSMSG message queue. Messages are converted from the proprietary IBM format to the industry standard syslog format (RFC 3164) and converted from EBCDIC to ASCII. Messages are then transmitted to the log collection server or SIEM solution securely and in real time.

The Alliance LogAgent QSYSOPR message collector is a part of the base product. If you are currently using LogAgent to process QAUDJRN events, you can just enable the QSYSOPR message file option and you will start processing messages the next time the Alliance LogAgent subsystem starts. If you are implementing Alliance LogAgent for the first time, just enable the LogAgent QSYSOPR collector before you start the subsystem.

View our webinar "IBM i Logging for Compliance and SIEM Integration" to learn more about meeting compliance regulations and sending logs to any SIEM.

IBM i logging for compliance & SIEM Integration

Topics: System Logging, Alliance LogAgent

Five Things About Alliance LogAgent You May Not Know

Posted by Jared Mallory on Feb 27, 2014 7:52:00 AM

Alliance LogAgent is a product designed with the intent of reading your security audit journal event entries, then formatting and forwarding those events to any SIEM or LEM device, but LogAgent provides several significant features and functions that you may not be aware of.   In this article I will discuss five of these highly valuable features of the Alliance LogAgent product that you may not know about.

  1. Signs Your IBM i may have been Hacked Exclude trusted users to reduce volume. In addition to allowing system administrators to filter out various event types from reporting, Alliance LogAgent will also allow you to filter out all events created by specified user profiles through the use of an “Excluded Users” list.  System admins may occasionally find it necessary to filter out all audit events created by implicitly trusted system user profiles.  Alliance LogAgent allows you to configure this ability at the IBM i level so that you can block those events from reaching your SIEM, thus reducing the volume of events that the SIEM must filter from reports.
  2. Secure communications between agent and SIEM. While most SIEM solutions provide support for TCP and/or UDP connections to agents, Alliance LogAgent also supports the use of SSL/TLS secure connection for customers who need to protect the privacy of the communications between the agent and the SIEM.  With the simple addition of certificates to the IBM i Digital Certificate Manager and configuration of an Application ID tied to the certificate, Alliance LogAgent can be quickly configured to use SSL/TLS communications to protect your communications with the SIEM.
  3. Exit Point monitoring. In the IBM i environment many IBM applications provide Exit Points that can be used to trigger flags for reporting or launching other processes.  Alliance LogAgent has the ability to monitor these Exit Points and create audit events that get reported to the SIEM so that system administrators can use the SIEM to monitor many of those functions.  Providing Exit Point monitoring within Alliance LogAgent allows the SIEM to provide administrators with valuable reporting of the use of many of these systems within the IBM i.
  4. File Integrity Monitoring. File integrity monitoring is recommended under PCI DSS and other regulations.  Even in other environments it is often highly desirable to be able to verify and monitor the integrity of data within database files.  Alliance LogAgent has an add-on module that provides this highly valuable File Integrity Monitoring (FIM) function.  Database Monitor allows the admin to determine which files and which fields within those files need to monitored for access and integrity.  Database Monitor will record the original field data and also the new values recorded in the field, as well as application and user information for how and when the data was changed.  This integrity monitoring allows you to also set alerts to administrators if unauthorized users, or applications alter data, or if data changes violate configurable thresholds. 
  5. Simplified formatting for event reporting. In the world of event management there are many possible SIEM and LEM systems and services available.  Some of these SIEM and LEM systems use Common Event Format (CEF) for handling event data, while others use the Syslog (RFC3164) format.  Alliance LogAgent provides configuration options to support either of these two formats and is compatible with a wide range of SIEM and LEM devices and services without any need for additional IBM i support or programming.  Simply select a couple of collector and formatting options in the product configuration panels, specify the destination address of the SIEM device, and start the system.  You can begin seeing your IBM i audit events at the SIEM in a matter of minutes from initial installation of the product.

With the importance of event monitoring becoming more critical for system administrators, it is important to choose a logging solution that will meet your needs.  Alliance LogAgent’s wide range of features, combined with the ease of setup and configuration, allows system administrators great flexibility while still allowing for rapid deployment with nearly zero impact on daily operations. 

Learn the importance of system logging and monitoring

Topics: System Logging, Alliance LogAgent

Signs Your IBM i May Have Been Hacked - part 2

Posted by Michelle Larson on Oct 3, 2013 9:20:00 AM

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. Signs Your IBM i may have been Hacked  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:

Learn the importance of system logging and monitoring

Topics: System Logging, File Integrity Monitoring (FIM), IBM i, Alliance LogAgent, Data Breach, Integrity

Signs Your IBM i May Have Been Hacked!

Posted by Michelle Larson on Sep 24, 2013 3:40:00 PM

(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. Signs Your IBM i may have been Hacked 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:

Learn the importance of system logging and monitoring


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


Topics: System Logging, File Integrity Monitoring (FIM), IBM i, Alliance LogAgent, Integrity

Understanding System Logging on the IBM i – Part 2 – Webinar Q&A

Posted by Michelle Larson on Jul 26, 2013 8:39:00 AM

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. System Logging on the IBM i

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

DOWNLOAD WEBINAR Understanding System Logging  

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

Topics: System Logging, File Integrity Monitoring (FIM), IBM i, Alliance LogAgent

Understanding Log Management on the IBM i: Part 1

Posted by Michelle Larson on Jul 12, 2013 8:30:00 AM

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. System Logging on the IBM i  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.

DOWNLOAD WEBINAR Understanding System Logging

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

Topics: System Logging, HITECH, IBM i, Alliance LogAgent, HIPAA, PCI, GLBA/FFIEC

Zen and the Art of System Logging (System Monitoring for your IBM i)

Posted by Liz Townsend on Feb 21, 2013 1:29:00 PM

Podcast: Better System Logging

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.

Click me

Topics: System Logging, Alliance LogAgent


Subscribe to Email Updates

Posts by Topic

see all