Townsend Security Data Privacy Blog

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!

IBM announced recently the end of support date for V5R4. This has prompted many IBM i shops running this older OS to upgrade to a newer release - either V6R1 or V7R1. Traditionally, we have seen that most IBM i administrators upgrade just one release forward. In this particular case, we recommend going to V7R1. Not only is upgrading to V7R1 a fully supported path by IBM, there are security reasons. I recently sat down with Patrick Townsend, Founder & CEO, to discuss IBM i V7R1 and how Townsend Security can help organizations take advantage of FIELDPROC, a new feature that allows companies to encrypt their sensitive data without changing their applications.

You said recently that upgrading your IBM i to V6R1 is a bad idea. Can you explain why?

Security today is more important than it was even two or three years ago. We live in an evolving world around security and organizations of every size - from small companies to global companies - really have been under severe attack. The bad guys are getting much better at what they do and we are faced with highly sophisticated attacks. Even mid-sized companies are now under pressure to protect their data. So we live in a world that is far more sensitive and insecure, and we really have to put more attention on protecting sensitive data.

IBM gave us FIELDPROC in the latest release of the operating system (V7R1), which allows encryption with no application changes. FIELDPROC is really attractive for mid-sized and large customers. It makes the usually very difficult task of encrypting data in our systems much easier. I think that customers who are on older versions of the operating system (V5R4, for example) and who might in the past have just moved up one level, should really move up to V7R1. From a security perspective, it is time to jump a level from V5R3 or V5R4, past V6R1, which would be the next release, to V7R1 and get the benefits of FIELDPROC encryption.

What would an organization need to do to take advantage of FIELDPROC once they upgrade? They still need third-party encryption, right?

Yes, FIELDPROC is the ability to do encryption, but IBM relies on third-party vendors like us to actually provide the encryption libraries and appropriate encryption key management. When customers deploy our FIELDPROC encryption solution on V7R1, they are getting our NIST-certified encryption libraries, as well as seamless integration with Alliance Key Manager, our encryption key manager. Alliance Key Manager is FIPS140-2 certified, and when used with our encryption, lines up perfectly with best practices for encryption across all compliance regulations. Whether it is PCI/DSS with Credit Cards, HIPAA/HITECH in the Healthcare industry, FFIEC in the financial industry, DICAP if you are a civilian company working with the federal government, or if you are a federal agency where it is a mandate that you must have a FIPS140-2 solution.

Our FIELDPROC solution installs into an IBM i customer’s environment, provides both our optimized and certified AES encryption libraries, and the key management you need to be compliant. IBM has done the hard work of making this capability available and we do the work of snapping in proper encryption and key management.

Download a free 30-day evaluation of our Alliance AES/400 encryption, built specifically for IBM i V7R1. Alliance AES/400 is the only NIST-certified FIELDPROC encryption available.

We have been talking a lot recently about the benefits of FIELDPROC as being the main reason to upgrade to IBM i 7.1 (V7R1). Since IBM recently announced the end of support date for IBM i 5.4 (V5R4), we are seeing many shops planning upgrade projects and discussing whether to move their systems to V6R1 or V7R1. Without a doubt, V7R1 is the correct choice – it is even a fully supported V5R4 upgrade  path from IBM.  So, aside from FIELDPROC, what other security reason is there to skip V6R1?  Simply, the updates to Secure Shell sFTP.  I recently sat down with Patrick Townsend, Founder & CEO, to discuss how these updates can help further secure your data.

Another key security feature in V7R1 is a new version of the Secure Shell sFTP application. How is it different and better?

IBM has been making Open SSH available on the IBM i for quite some time. We had the ability to install it back on V5R3. It has become a very popular secure file transfer mechanism, especially for financial institutions. We are seeing large commercial banks across the board moving to Secure Shell sFTP for encrypted file transfers. IBM brings the latest version of SSH to each new release and V7R1 is no exception. The latest version has picked up new security features since the V5R4 release, some of which are quite important. I think moving to V7R1 and getting the latest version of Secure File Transfer (sFTP) is really important. We are learning from security professionals at the NSA, NIST, and SANS just how important it is to make sure the patches to our systems are up-to-date. So again, having the latest version of any security technology is imperative, which re-emphasizes skipping V6R1 when upgrading from V5R4.

Download our podcast “IBM i Security: Skip V6R1 and Upgrade to V7R1” for more information on the security reasons that you should go straight to V7R1. Additionally, we will discuss how Townsend Security can help you take advantage of FIELDPROC, a new addition to V7R1, which allows companies to encrypt their sensitive data without changing their applications.

Whenever I am asked what Townsend Security does I have to explain that we aren't in the business of deploying security cameras or contracting out shopping mall guards. We are actually a software security vendor for the IBM i (AS/400) platform.  It's usually at this point the recipient's eyes glaze over and I am left simply stating that I am in the 'computers' field.  On occasion however I will be chatting with a colleague who also works in the tech industry who will scoff when they hear the name AS/400, iSeries, Systemi (take your pick).  Often I'll hear, "Whoa, that's legacy technology. You have customers still using that platform?"

The simple answer is “yes”, many of the companies that we rely on for consumer needs, medical services and entertainment, to name a few, depend upon the stability of IBM's iSeries platform.  It's the system that you rarely have to IPL.  As a matter of fact, I was surprised to learn many of the casinos in Nevada and N.J. run on AS/400's. 

However, despite the pervasive use of the platform, is it legacy?  The AS/400 was introduced in 1988 and is actually younger than the PC!   Much like the PC, IBM rolls out continuous hardware and software improvements to keep the platform stable and secure.   As a matter of fact, I am sure many of you are planning to upgrade your systems as V5R4 nears its EOL date later this year.  Take a look at this blog on why skipping V6R1 and going straight to V7R1 will benefit you.

Security on the IBM i

Townsend Security offers a variety of security solutions to help your business meet regulatory compliance.  In addition to our AES encryption and key management offerings for the enterprise platforms, we offer solutions specifically for the IBM i (AS/400).  For instance, FTP manager, our secure managed file transfer offering, can automatically transfer PGP encrypted files using sFTP or SSL to banks or trading partners.  Or Alliance LogAgent, our system logging solution, can be used to capture all your logs from your AS/400's audit journal and transmit them via UDP,TCP, or SSL to a log collection server to just name a few.

For more information on data privacy, download our podcast Data Privacy for the Non-Technical Person.  Patrick Townsend, our Founder & CTO, discusses what PII (personally identifiable information) is, what the most effective methods for protecting PII, as well as the first steps your company should take towards establishing a data privacy strategy.

As security auditors get more educated on the IBM i platform, more customers are having the experience of failing a security audit around encryption key management. CIOs, IT Managers, and System Administrators want to know why this is happening to them now? They ask, why was our approach OK two years ago, and why is it not OK now?

I think I can answer that.

My job brings me into conversations with a lot of companies undergoing security audits under a broad range of regulations including PCI DSS, SOX, GLBA/FFIEC, FERPA, and many others. Security and compliance auditors look to industry standards and best practices for guidance on what their clients should be doing in the area of key management. In the US this inevitably brings them into contact with the National Institute of Standards and Technology (NIST), an agency within the US Department of Commerce. NIST provides a wide set of standards and best practices guidance in the area of encryption and key management.

As you become familiar with the broader set of data security regulations, you start to realize that the one common source they have is NIST. Even if not directly referenced in the regulations, the concepts are largely drawn from work done by NIST, and that is why there are a set of common attributes that auditors look for in a key management implementation.

So, auditors now look for key management implementations based on NIST best practices and standards. Key management best practices can be found in the NIST Special Publication 800-57 (three parts).

One of those best practices is Separation of Duties. This best practice says that the people who manage encryption keys should not be the same people who manage and have access to sensitive data such as credit card numbers, social security numbers, patient data, and so forth. It makes sense – you want as few people as possible with access to sensitive data, and you only want people who have a real need to access sensitive data to do so. The same is true with encryption keys that protect that sensitive data.

On the IBM i platform the security officer and anyone with All Object (*ALLOBJ) authority can access any database file at any time, and can access any locally stored encryption key at any time, regardless of the protections you try to put in place. This is not really a limitation or weakness of the IBM i platform, the same condition exists on other operating systems and platforms, too. No matter what you do you can’t achieve a defensible level of Separation of Duties if you store encryption keys on the IBM i platform. You can try to mitigate this situation through system logging and similar controls, but you can’t eliminate it.

Auditors have learned this about the IBM i platform.

Separation of Duties is only one problem area with the local storage of keys. You also have to contend with Dual Control, Split Knowledge, key lifecycle management, and a broader set of key management best practices most of which are difficult or impossible to achieve when encryption keys are stored locally.

And that’s the main reason IBM i customers are failing security audits around encryption key management.  Download our our Encryption Key Management Requirements for PCI white paper to learn more on how you can pass your next key management audit with flying colors.

Patrick

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 today’s environment, most organizations fall under multiple compliance regulations. If you are taking credit cards, you need to meet PCI data security standards. If you are in the health care industry, you have HIPAA and HITECH to work on. If you are in the banking industry or any financial segment, you have the Graham Leech Bliley Act (GLBA) and FFIEC requirements to meet. All of us have to deal with state and federal privacy regulations about protecting data.

A secure Managed File Transfer solution with NIST validated PGP encryption can help meet compliance regulations for securing data in motion.

Compliance regulations come full bore on all of us - whether you are in the business, Federal, or non-profit world. PCI DSS and a number of other regulations require encryption of data in motion. Townsend Security has partnered with Symantec to offer the only commercial and fully supported version of PGP encryption on the IBM i (AS/400).

Maintaining proper audit trails is also a very clearly defined requirement of compliance regulations. I think as we see compliance regulations evolve, making sure that your Managed File Transfer solution is based on well accepted standards is very important. For example, the commercial version of PGP encryption that we offer has been through multiple certifications with the National Institute of Standards and Technology (NIST). We have seen fines given to companies using non-standard implementations, so having those certifications and having the confidence that you’re using a solution that provably meets industry standard is really important.

Compliance regulations are still evolving and we continue to see new regulations being brought forward. For example there is a new federal data privacy regulation coming through Congress. There is also a clear evolution of compliance regulations requiring solutions to meet defined industry standards (such as NIST). I know our certifications give our customers confidence that they are meeting compliance regulations and that they are using the right kind of encryption.

Townsend Security’s FTP Manager has been helping IBM i (AS/400) users meet compliance regulations by securing and automating their data in motion to trading partners, customers, employees, and internal systems. Download our podcast “Secure Managed File Transfer on the IBM i – An Introduction” for more information on how we can help your organization save time and money by securely automating your file transfers.

Today, data security is more important than ever. We live in world now where organizations of every size - from small companies to large global companies – need to make sure their sensitive data is safe. The bad guys are getting much better with more sophisticated attacks. Even mid-sized companies are now targets. So, with the most up-to-date security features included in IBM i 7.1 (V7R1), why would you still be using or consider using the V6R1 release?  I recently sat down with Patrick Townsend, Founder & CEO, to discuss the latest IBM i OS and the security reasons a company who is on an upgrade path from V5R4 should bypass V6R1 and install V7R1.

What do you have to say to the company who traditionally moves up just one release? For example the company that would just upgrade to V6R1 because they feel that it has all the kinks worked out.

Well, I understand that motivation and I have been in that seat before. OS upgrades are always something you want to be very cautious about - whether you are talking about your IBM i or even your Linux, UNIX, and Windows servers. You know that a certain number of bugs will get worked out after a new release has come into the market and you tend to be a little cautious about applying the latest release upgrade. Having been released for over a year, V7R1 is now pretty mature and I haven’t heard of any significant upgrade problems.

IBM i users that are on V5R4 know that IBM recently announced the end of support date for that release (which means maintenance and support will stop in about a year) and people will need to upgrade. There are two reasons it is a good idea to jump past V6R1 straight and to V7R1. First, it is a fully supported path by IBM. Second, there are security benefits to making that jump. You are getting significant new security features in V7R1 that you won’t see in V6R1. I know that there are external factors that sometimes influence moving forward on releases. Some software vendors may not be ready for V7R1 and this can represent a significant barrier in terms of getting to the latest release of the operating system. If you have not yet begun a discussion with your software vendors on whether they have certified their software on V7R1, now is the time to do that. IBM makes it very easy for a software vendor to test their software on a pre-release version of the operating system. We do that, and your other software vendors should be doing that too, well before IBM releases a new version of the operating system. This is one time that you should balance the security benefits of V7R1 against the cautionary approach of going only to V6R1, which will be just one step for many people.

Download our podcast “IBM i Security: Skip V6R1 and Upgrade to V7R1” for more information on the security reasons that you should go straight to V7R1. Additionally, we will discuss how Townsend Security can help you take advantage of FIELDPROC, a new addition to V7R1, which allows companies to encrypt their sensitive data without changing their applications.

As more and more organizations are falling under compliance regulations, IT managers are being tasked with finding a secure Managed File Transfer solution to secure and automate data in motion with their trading partners, customers, employees and internal systems.  There are a few out there, but how do you decide which is the best for your organization?  I recently sat down with Patrick Townsend, Founder & CEO to learn more about the core components of a Managed File Transfer solution.  Here is what he has to say:

First, you must have security built-in with your solution. Our Alliance FTP Manager uses a number of secure encrypted mechanisms for transferring files. We use SSL FTP, Secure Shell sFTP, PGP encryption and decryption. That security component is absolutely crucial to the product. I’m really happy with our security, and we have a great partnership with Symantec around their PGP product. Our enterprise customers really expect the highest level of solution when it comes to encryption. We have partnered with Symantec on the PGP product and it carries the proper certification and the depth of support that customers want.

Automation is another core component. If you are dealing with a lot of files, you need to have automation to be efficient. You don’t want to have to do a lot of manual intervention. There should also be a centralized management environment so that configurations can be set up and managed from a central location.

Additionally, notification is another core component. For example you may have files that you’re sending to a customer or your bank. You may only do that transfer once a month, but wouldn’t it be nice if after you transferred the file you sent the customer an email telling them your file is transferred and is ready for processing. With Alliance FTP Manager, we can notify your customer or an entire email list of recipients when a file transfer is complete. Or if there is a failure in a transfer, maybe a customer turned off their FTP server, we can notify that too.  We can do both success and failure notifications in our Managed File Transfer product.

Finally, to meet compliance regulations, you need to have full audit capabilities. We can create audit trails of all the transfers, which is really important from a compliance point of view.

View a recording of our webinar Secure Managed File Transfers: Meeting Compliance Regulations for more information on meeting data in motion requirements of PCI DSS, HIPAA/HITECH, and other compliance requirements on your IBM i.

Managed File Transfer is an easy way to meet business requirements and comply with data privacy regulations.  With a solution like Alliance FTP Manager, businesses can meet compliance regulations by securely transmitting files from their IBM i (AS/400) to their trading partners and customers. Additionally, a Managed File Transfer solution can help your organization save time and money by automating processes that traditionally have eaten into IT manpower. I recently sat down with Founder & CEO Patrick Townsend to discuss how Managed File Transfer can help businesses assure their customers and partners that their sensitive data is secure and in compliance with data privacy requirements such as PCI DSS, HIPAA/HITECH, FFIEC and other regulations.

Can you walk us through a typical business problem that Managed File Transfer Solves?

If you’re a mid-sized or large company, security is absolutely crucial in today’s environment. We all hear over and over again about data losses by large companies and the damage that causes to both the business and the reputation of those companies. Business executives around the world are trying to protect their data, their customer data, and supplier information so they can have the confidence to go forward with their business plans. A managed file transfer solution provides a start-to-finish mechanism for securing data in motion.

If you are using a Managed File Transfer solution like our Alliance FTP Manager, you can have the confidence that you are doing things right, that you are meeting best practices in the industry and that you are less likely to  wake up one day and find yourself in a headline in the New York Times about some large data loss.

Can you explain how a Managed File Transfer works?

Managed File Transfer solutions, like our Alliance FTP Manager, need to meet a number of core requirements. Obviously, they need to protect data in motion and we use SSL session encryption and PGP encryption, which are the industry standards. Automation is also very important. Most of our customers are transferring multiple files everyday to banks, trading partners and suppliers. You don’t want to burn resources by having someone manually transfer files any time it needs to be done.

Additionally, policy driven configuration and reporting by exception are extremely important. Some of our customers are sending tens of thousands of files every day to their trading partners, which can be a lot to manage. You need to be sure that you can manage by exception if there is a problem.

Finally, a Managed File Transfer Solution not only automatically picks up and transfer files, but provides additional controls to make the process efficient - not only from a human resource point of view, but also from a cost point of view. You don’t want to be spending valuable human resources, picking up files and processing them. This should all be an automatic process and that is really the core idea behind Managed File Transfer – automation and security. 

Download our podcast “Secure Managed File Transfer on the IBM i – An Introduction” for more information on how we can help your organization save time and money by securely automating your file transfers.