Townsend Security Data Privacy Blog

Because Townsend Security provides encryption for IBM System z Mainframes we often get asked about system logging for that platform. Our Alliance LogAgent solution provides system log collection for the IBM i (AS/400, iSeries) platform, so this is a natural question from Mainframe customers.

We don’t have a solution for IBM Mainframe customers, but I am happy to report that our partner CorreLog does! IBM System z Mainframe users can deploy the CorreLog solution and get the same types of security event collection and SIEM integration that we provide in Alliance LogAgent. The two products are not exactly the same in terms of features, but CorreLog will give you the security event collection and SIEM integration that you need.

Like the IBM i platform the IBM Mainframe contains a lot of sources for security event information and the data must be transformed into a usable format and transmitted to a SIEM. This is a daunting task for even an experienced Mainframe developer, so this is a perfect area for a third party product. CorreLog has just the right solution to make this happen.

IBM has been enhancing the System z Mainframe to bring it into the modern Internet-connected world. This means you have more security attack points on this venerable platform, and need to deploy modern security tools to protect it. Active monitoring of security audit logs by a SIEM solution is a must-have for Mainframe shops and CorreLog has a great solution.

CorreLog provides their own SIEM solution, but they also integrate with a wide variety of other SIEM vendor solution. You can deploy CorreLog to send security events to IBM Security QRadar, LogRhythm, HP ArcSight, Dell SecureWorks, RSA Envision, and many other SIEM solutions! This also means that you are not locked into any one SIEM vendor and can easily migrate to a new solution if or when you want to.

Another big bonus of the CorreLog solutions is support for File Integrity Monitoring, or FIM. FIM is an integral part of many compliance regulations such as PCI Data Security Solutions, and with CorreLog you can address that need along with the rest of you security monitoring needs. Many IBM Mainframe applications use DB2 files to store configuration information, so the FIM module really helps meet the compliance requirements.

You can get more information about CorreLog here.

Patrick

We all now know that active monitoring and rapid response is one of the critical security controls that really make a difference. That is why system log monitoring makes the Top Ten list of almost all cyber security controls. What is not so well known is how hard it can be to get active monitoring right. We have a lot of Security Information and Event Monitoring (SIEM) solutions to choose from, but very few of them are effective right out of the box. Why is this?

First, system generated logs are a mess. They are largely unformatted text messages without unique identifiers that make it hard for a SIEM solution to interpret. Add many different spoken languages and you have a major headache when it comes to interpreting log messages.

Second, other than some basic formatting guidelines, information in system logs is not normalized. While some log formatting standards like Common Event Format (CEF) and Log Event Extended Format (LEEF) attempt to provide this, very few devices actually format to these standards. The lack of system log standards contributes to the confusion when SIEM solutions attempt to interpret the log messages. It would make a database administrator shed tears.

Lastly, many SIEM solutions collect logs once or twice a day with some type of batch transfer, and events are not processed in real-time. Real-time analysis is core to effective SIEM monitoring of system logs. Without real time event collection it is difficult or impossible to do event correlation and the result is missed positives. All of that intelligence built into modern SIEM solutions can go to waste.

One thing I like about the IBM Security QRadar solution is that it comes with pre-defined definitions that out of the box know how to interpret logs from a wide variety of devices. IBM packages these definitions in a configuration object known as a Device Support Module, or DSM. IBM QRadar customers get access to all of these DSM definitions and they can be easily updated as new and revised configurations become available. This saves a security administrator a lot of time in configuring the SIEM to recognize events.

Another thing I like about IBM Security QRadar is that it understands that normalized data is important. The QRadar Log Event Extended Format, or LEEF, builds on IETF system log standards by adding well-defined data formats and field definitions. If all of your systems are reporting an IP address like this:

src=1.2.3.4

then you know that event correlation is going to work a lot better.

Our IBM i (AS/400, iSeries) solution for IBM Security QRadar integration is named Alliance LogAgent for IBM QRadar. It implements support for the QRadar LEEF data format for all IBM i security events, and transmits events in real time. IBM has now released an updated AS/400 DSM that includes recognition of the more than 200 security events transmitted by Alliance LogAgent for IBM QRadar. This means that customers deploying or updating their QRadar implementation get a much faster implementation and a much better security posture right out of the box. This new solution installs on an IBM i server very quickly and in minutes can be sending security events to IBM Security QRadar.

No one security control will make you safe. But actively monitoring your system and audit logs is crucial to a good security implementation.

For more information, visit our Alliance LogAgent for IBM QRadar or get started with a free evaluation.

Othwer Resources

Center for Internet Secuirity

SANS Top Ten (see CSC 6)

This is the third part in our series looking at recent announcements by Amazon, Microsoft and other cloud service providers regarding new encryption and key management services. Let’s talk about log collection and active monitoring as a security best practice, and as a requirement to meet PCI DSS security requirements. Since the PCI DSS guidelines implement common security best practices, they are a good starting point for evaluating the security of any application and platform that processes sensitive data. Following the practice of the first part of this series we will use the PCI document “PCI DSS Cloud Computing Guidelines, Version 2.0” as our reference point, and add in some other sources of security best practices. Even if you don’t have to meet PCI data security requirements, this should be helpful when evaluating your security posture in the cloud.

Collecting system logs and actively monitoring them is a core component of every cyber security recommendation. Cybercriminals often gain access to IT systems and go undetected for weeks or months. This gives them the ability to work on compromising systems and stealing data over time. Active monitoring is important in the attempt to detect and thwart this compromise.

Here is what PCI says about active monitoring in Section 10 of the PCI DSS (emphasis added):

Review logs and security events for all system components to identify anomalies or suspicious activity.

Many breaches occur over days or months before being detected. Checking logs daily minimizes the amount of time and exposure of a potential breach. Regular log reviews by personnel or automated means can identify and proactively address unauthorized access to the cardholder data environment. The log review process does not have to be manual. The use of log harvesting, parsing, and alerting tools can help facilitate the process by identifying log events that need to be reviewed.

In recognition of the importance of ongoing, active monitoring the National Institute of Standards and Technology (NIST) provides this guidance in their Special Publication 800-137 “Information Security Continuous Monitoring (ISCM)” guidance:

The Risk Management Framework (RMF) developed by NIST, describes a disciplined and structured process that integrates information security and risk management activities into the system development life cycle. Ongoing monitoring is a critical part of that risk management process. In addition, an organization’s overall security architecture and accompanying security program are monitored to ensure that organization-wide operations remain within an acceptable level of risk, despite any changes that occur. Timely, relevant, and accurate information is vital, particularly when resources are limited and agencies must prioritize their efforts.

And active monitoring is a component of the SANS Top 20 security recommendations:

Collect, manage, and analyze audit logs of events that could help detect, understand, or recover from an attack.

Deficiencies in security logging and analysis allow attackers to hide their location, malicious software, and activities on victim machines. Even if the victims know that their systems have been compromised, without protected and complete logging records they are blind to the details of the attack and to subsequent actions taken by the attackers. Without solid audit logs, an attack may go unnoticed indefinitely and the particular damages done may be irreversible.

Because of poor or nonexistent log analysis processes, attackers sometimes control victim machines for months or years without anyone in the target organization knowing, even though the evidence of the attack has been recorded in unexamined log files.

Deploy a SIEM (Security Incident and Event Management) or log analytic tools for log aggregation and consolidation from multiple machines and for log correlation and analysis.

This is why actively collecting and monitoring system and application logs is critical for your security strategy.

Implementing this critical security control in a cloud environment presents some special challenges. Here is what the PCI cloud guidance says:

Additionally, the ability to maintain an accurate and complete audit trail may require logs from all levels of the infrastructure, requiring involvement from both the CSP and the client. For example, the CSP could manage system-level, operating-system, and hypervisor logs, while the client configures logging for their own VMs and applications. In this scenario, the ability to associate various log files into meaningful events would require correlation of client-controlled logs and those controlled by the CSP.

It is not enough to collect logs from a few selected points in your cloud application environment. You need to collect all of the logs from all of the components that you deploy and use in your cloud application. This is because the effectiveness of active monitoring depends on the correlation of events across your entire application, database, and network and this includes the cloud providers systems and infrastructure. Here is what ISACA says about security event correlation:

Correlation of event data is critical to uncover security breaches because security incidents are made up of a series of events that occur at various touch points throughout a network--a many-to-one process. Unlike network management, which typically is exception-based or a one-to-one process, security management is far more complex. An attack typically touches a network at multiple points and leaves marks or breadcrumbs at each. By finding and following that breadcrumb trail, a security analyst can detect and hopefully prevent the attack.

Your encryption key management system is one of those critical system components that must be monitored and whose events should be aggregated into a unified view. Key management logs would include encryption key establishment and configuration, encryption key access and use, and operating system logs of every component of the key management service. You should be able to collect and monitor logs from all parts of your applications and cloud platform.

Unfortunately, current key management services from cloud providers only provide a very limited level of access to critical component logs. You might have access to a limited audit trail of your own access to encryption keys, but no access to the key service system logs, HSM access logs, HSM audit logs, or HSM operating system logs. Without access to the logs in these components it is not possible for you to implement an effective log collection and active monitoring strategy. You are working in the dark, and without full access to all logs on all components of your cloud key management service you can’t comply with security best practices for log collection, correlation, and active monitoring.

Since key management systems are always in scope for PCI audit and are extensions of your application environment it is difficult to see how these new cloud key management services can meet PCI DSS requirements for log collection and monitoring as currently implemented.

Does this mean you can’t implement security best practices for key management in the cloud? I don’t think so. There are multiple vendors, including us (see below), who offer cloud key management solutions that provide full access to key management, configuration, key usage, application, and operating system logs.  You can deploy a key management service that fully supports security best practices for log collection and monitoring.

In part 4 of this series we’ll look at the topic of key custody and multi-tenancy and how it affects the security of your key management solution in the cloud.

Patrick

---

Resources

Alliance Key Manager for AWS

Alliance Key Manager for Azure

Alliance Key Manager for VMware and vCloud

Alliance Key Manager for Drupal

 

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.

We’ve had an upsurge in interest recently in our Alliance LogAgent solution for the IBM i (AS/400) platform. This solution sends security events from the IBM i in real time to log collection servers and SIEM solutions. As I’ve talked to IBM i customers, I am beginning to appreciate how difficult it is to get IBM i security information into a usable format so that events can be collected and monitored. The challenges are big:

• Data format – IBM security events are in internal IBM format, not syslog format.
• Multiple sources – Security events get collected in a variety of locations, almost always in an internal and proprietary IBM format.
• Timeliness – Tools are lacking to collect security events in real-time, increasing the security exposure.
• Communications – There are no native syslog UDP, TCP or SSL TCP communications facilities.
• Data completeness – While it is possible to print security information using IBM tools, critical information is missing from reports.

Here is a really good example of this last point. I can use the Display Audit Journal Entry command (DSPAUDJRNE) to print a report of user ID and password failures. Here is a bit of what that report looks like:

Can you imagine a SIEM solution or poor network administrator trying to get useful information from this? Fields are not easily identified and extracted, and most SIEM query tools would have a really hard time extracting the meaning from this report. There are user ID and password failures here, but hard to parse them out.

And one of the most important pieces of information is missing. Can you see what it is?

Right, the IP address of the originator of the error. SIEM solutions are good at correlating events if they know where they are coming from. The IP address is critical for accomplishing this. This report could probably tell you when you are under attack, but not where it is coming from and certainly not in real-time.

Our Alliance LogAgent solution solves all of these problems. Events are extracted from all of the relevant sources, in real time, converted to standard syslog format, and communicated using your choice of UDP, TCP, or secure TLS communications to your log server. And, Yes, the IP address is in the event! Here is an example of a PW event as it is processed by Alliance LogAgent:

<118>Sep 20 15:47:11 S10125BA QAUDJRN:[PW@0 event="PW-Invalid user or password" event_type="Q-Signon failed profile disabled" user_profile="QTCP" device="*N" jrn_seq="002273092" timestamp="20120120154711021000" job_name="QTLPD00145" user_name="QTCP" job_number="630743" ip_addr="10.0.1.205" port="15427"]                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                             

This is caviar to your SIEM solution!  Real time alerts, event queries, and forensics become a snap when you get the right data into your SIEM solution. And real time system monitoring is one of the top recommendations by security professionals to keep your IBM i (AS/400) safe.

I’m proud of our system logging solution for the IBM platform. Our customers have deployed the solution in under an hour starting from the time they do the download from our web site.

Patrick

In our final installment on system logging on the IBM i series, Patrick Townsend, Founder & CTO, discusses what to look for when selecting and deploying a logging solution.  As we found out in part two of this series, it really isn’t a good idea to take the “do it yourself” approach.  System logs are in several different locations on the IBM i, and even if you get them all together, it is still a challenge to get them in a useable format.  Here is what Patrick has to say about selecting a logging solution:

So what do you need to look for when selecting and deploying a logging solution?

I think that there are four key points when looking at a logging solution especially on the IBM i Platform. One is, you want a real-time logging solution.  It won’t cut it to have a system collecting events once or twice a day and sending them off to a log server.  You need a real-time system that is collecting events as they happen so that your log collection server and your SIEM can actually correlate events across multiple servers and “see” what’s happening.

Secondly, on the IBM i, performance is always an issue. We have many customers running Alliance LogAgent with tens of millions of events a day.  Just this week we talked to a customer who was generating 120 million events a day.  That is a lot of events to be collecting and other solutions just can’t keep up with the sheer volume of events.  If your system can’t keep up with that, you will have a real compliance problem.  I’m really proud of the performance of our solution and that it allows us to do hundreds of millions of events every day, keeping up with the security events of the largest customers.

Third, logs should be protected while they are being transmitted to a log server.  Alliance LogAgent protects the transmission with a SSL/TCP connection.  Some of the information in your system logs can be very sensitive and it would be a bad idea to transmit this data in the clear.  When choosing a logging solution, it should have full support for a secure transfer mechanism.

Finally, industry standards are very important.  Standards are important on a very practical level.  When you buy a light bulb in the store, you want to be able to take it home and plug into a light socket.  You are able to do this because of standards.  The same is true for logging events on the IBM i.  There is a standard format for logging system events and the way you send your logs from an IBM i to a log collection server.  Query, reporting, and alerting tools depend on those standard formats.  The solution that you decide to deploy should be built on industry standards.  We support both the RFC Format and Common Event Format standards.

Those are the four most critical points for a standard logging solution and I am really proud that our product, LogAgent stands up really well on all four of those points. Overall, I think if you focus on those four items you’ll be in a good place.

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.

In the first part of our series on system logging on the IBM i (AS/400) we discussed why system logging is so important and where security information lives on the IBM i.  We will now continue my conversation with Patrick Townsend, Founder & CTO, and talk about log collection and meeting compliance regulations with system logging.

So now that you have identified the sources of this important system information, how do we format it for log collection and SIEM Servers?

This is probably the biggest challenge for IBM i users - getting log information from the IBM i into a usable format.  IBM i logs are not recognizable by a typical log collection sever or a SIEM console that monitor log data.  With Alliance LogAgent, we have tackled this problem by reading all of these sources of event information and translating from the IBM i format to a standard log format.  IBM does provide a few utilities for printing log information, and I have seen people try to use those to get data into a text type format, but they are unsuccessful because the printed log information is not in a standard format.  Another reason why this method doesn’t work is that it is typically not in real-time, so you’re not picking up information in a timely fashion - meaning you are missing threats that are happening in your machine.

Formatting data is a major challenge and we decided that the right way to do this was to bite the bullet and read the internal format of the logs, while they are completely unrecognizable to any standard log collection server, and format them to industry standard formats - based on existing RFC’s in terms of SYSLOG formats or Common Event Format.  Alliance LogAgent puts them in the right format and transmits them.  The technology in our logging solution is really focused on making all that log information usable, doing it in real-time, and then getting it to where it needs to go – allowing it to be monitored by your SIEM in real time.

System logging is also important for meeting compliance regulations too, right? 

Absolutely, if you take a look at PCI data security standards from the beginning, section 10 is focused on collecting logs and analyzing them in a timely fashion.  If you drill down into the recommendations for HIPAA/HITECH Act, or if you’re looking at FFIEC in the financial sector, or even privacy notification laws, they are all very consistent about requiring proper monitoring of system logs.  And this is understandable, looking at how threats evolve and what the typical threat looks like.

Sometimes bad software gets installed on a system and sits there for months at a time, undetected because nobody is monitoring the logs. That software can be phoning home through an IP connection and checking in through remote servers.  Your logs should be showing that activity.  That is why you’ll find across the board, in almost every compliance regulation, a need or requirement to collect logs in a central location, on a log collection server, or in a SIEM.  Someone needs to be paying attention to those logs and “someone” could be automated software, including products from SIEM vendors.  It is really important from a compliance point of view that you are collecting logs, doing it in a fast, real-time fashion, and have something monitoring those logs looking for threats.

View our Webcast “Understanding Log Management on the IBM i” for more information on logging and how it can help you meet compliance requirements with real-time security event logging across your Enterprise.

As a company that works hard to protect your data, we get a lot of questions – from people wanting to know the ins and outs of our products to IT professionals who are new to the world of meeting compliance regulations.  Luckily, our company has several experts to answer these questions.  One topic that we often get questions regarding is system logging on the IBM i (AS/400).  Logging on the IBM i is different than logging on other platforms.  I recently sat down with Patrick Townsend, Founder & CEO, to pick his brain on what system logging is, and why it is so unique on the IBM i.

System logging has become one of the most essential compliance tasks in contemporary corporate IT. Can you give a brief explanation of what logging is and why it is so important?

Sure, all computer systems, including the IBM i (AS/400, iSeries, System i) collect lots of important information about the security state or the operational state of the system as a whole.  We call these System Logs and they often include a great deal of information about what is going on in the system.  In a lot of systems, including the IBM i, these logs are created in real-time.  To give an example, if someone tries to sign into an IBM i and for whatever reason the username or password is invalid, that event is logged in the system log.  This is an important thing to log 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.”  In summary, System Logs are just a central repository on the computer system that say what is going on within the system.  This is why they are so important from a security point of view.

Where does security information live on the IBM i?

Security information lives in a number of places, which is one of the challenges that IBM i administrators have.  On the IBM i, IBM creates a central repository (QAUDJRN in the IBM i world) for a large number of security events including password and other security events. Our Alliance LogAgent customers can decide what kind of events they want to collect.  QAUDJRN is not the only place to look for this security information. There is also a system event log file called QHST that has important log-on and log-off information for users.  The operators console (QSYSOPR) collects and tracks important events and messages for security monitoring.  Finally, the IBM i sports a lot of new, web-type services that have their own log collection facilities including WebSphere, Apache, and SSH.  In order to properly look at all of the security events that are happening on an IBM i, you have to look in several places, which can be a challenge.

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.

As “The Encryption Company,” we often blog about meeting PCI DSS with encryption and key management.  Our NIST-certified technologies will help your organization satisfy Section 3 of PCI DSS, as well as other privacy regulations.  But there is another section of PCI DSS that Townsend Security can help you with – Section 10.

Section 10 states the requirements for tracking and monitoring access to network resources and cardholder data.  Some things that this section speaks on is procedural – daily reviewing logs for all system components and retaining an audit trail history for at least one year.  Section 10 also specifies how your logging solution needs to perform.  This includes automating audit trails for all system components and securing audit trails so that they cannot be altered.

This regulation is especially important for organizations using IBM i’s.  The state of logging on most IBM i’s is not good.  The IBM i doesn’t log information like your other systems and the security logs that it does produce are often an enclave inside the IT organization.

So what does this mean?  Only the IBM i administrators can know what is happening on that machine – all the valuable logging information is sequestered on the IBM i.  Network originated threats to the IBM i are often not noticed or responded to by the security team.  This puts a lot of sensitive data at risk and your organization not meeting compliance regulations.

There is an answer.  Townsend Security has been helping customers meet section 10 of PCI DSS with Alliance LogAgent.

Alliance LogAgent

• A complete solution that can capture and forward all IBM i security events
• Built by IBM i experts specifically for SIEM integration
• Robust filtering capability minimizes network impact
• Strong encryption between IBM i and SIEM console
• Seamless integration with ANY SIEM console
• Integrated User Monitoring and log forwarding 

To learn more, we recently recorded a webinar titled “Understanding Log Management on the IBM i.”  View this 30-minute webinar and learn how to meet compliance requirements with real-time security event logging across your Enterprise.