Townsend Security Data Privacy Blog

As a security company, it always puts a smile on our face when we see people properly protecting their (our) data.  Microsoft made this much easier for organizations running Microsoft SQL Server 2008 with Transparent Data Encryption (TDE) and Extensible Key Management (EKM).  By using TDE, EKM, and an encryption key management appliance, proper encryption and key management is now affordable to even small and medium sized businesses.

As recently as last month I had a small organization tell me, “I just pay the PCI fines.  It is part of my monthly budget and cheaper than doing encryption.”  This sort of thinking is making less and less sense these days.  Today, we can tell these smaller organizations that encryption and key management is now affordable and that we have a solution that was built specifically for their SQL Server.

I recently sat down with Patrick Townsend, our Founder & CTO and asked him what Microsoft customers should be thinking about when they consider using TDE and EKM on Microsoft SQL Server 2008:

A number of questions pop up right away for Microsoft customers when they start thinking about SQL Server EKM.  The first question is usually, “What is the performance impact going to be?”  I think Microsoft has done a great job of minimizing the performance impact using TDE.  Microsoft says that you will see about a 2-4% additional load on servers when you implement encryption.  In a practical sense, and from our customers, I think those are pretty good numbers.  There is some impact on doing encryption, but it is probably much less than you might think.  The performance impact has been really minimized by Microsoft in this approach.  Cell Level Encryption will have a little bit higher performance impact, but most people will use TDE and that has a very good performance profile for encryption.

I think the other thing to think about, if you are going to implement encryption using EKM is to address the key server question right up front.  Even though Microsoft gives you the ability to store an encryption key on the local server, it is not considered good security practice and Microsoft recommends the use of an HSM to protect encryption keys.  You should be thinking about using an appliance or HSM as you go forward to protect your encryption keys and give you the best security practice from a compliance point of view.  You don’t want to go down the path of implementing encryption and not following security best practices.  If you have a data breach, you are going to have to defend the approach that you took if you are trying to avoid legal liability and the cost of breach notification.  Using a proper key server should really be a no-brainer.  It is the right thing to do and the right approach.

Finally, an organization needs to look at the affordability of an encryption key management appliance.  In the past, I think one of the real barriers for encryption has been the very high cost of acquiring HSM technology.  I am very proud of our company for really beating down those costs and making them much more reasonable in terms of creating affordable HSM solutions.  With our solution, every mid-market to large-enterprise customer now has HSM technology within their grasp that is affordable and easy to deploy. 

Download our podcast “Encryption Key Management with Microsoft SQL Server 2008” to listen to our complete discussion and learn even more about TDE and EKM.

Last week we held a well-attended webinar titled “Secure Managed File Transfers” Meeting Compliance Regulations.” The webinar covered meeting the data in motion requirements of PCI DSS, HIPAA/HITECH, and other regulatory compliance requirements with Alliance FTP Manager, our secure managed file transfer solution for the IBM i.  During the presentation we received several great questions that we’d like to share with you on our blog.  As always, if you have any additional questions, send them our way.

Is there a reason why I shouldn't use PGP on windows? I can just transfer my file from IBM i to windows and then PGP encrypt it there. Does this make sense?

Yes, I fully understand why customers would want to take that approach, however if you are under PCI DSS regulations you would be out of compliance. The transfer of sensitive data across a network and then landing unencrypted will take you out of compliance, even if you encrypt it later. There is no question about that. That is a situation we have been remedying for customers for a number of years. The security best practice standard is to encrypt at the source and decrypt at the destination. So you need to avoid the transfer of unprotected data through internal servers or across any network. You really want to make sure that the encryption is in place and that the data lands encrypted.

Can managed file transfer be used on just one side or do both sides of the transfer have to have the same software?

Good question, first off, I'd like to point out that managed file transfer is a term of art. There is no formal definition, no RFC, no NIST standard. So for this answer, you're going to get my opinion on this. In our managed file transfer solution there are absolutely no requirement that a recipient of an encrypted file or a secure transfer needs to have our software. Our solution is based on open standards and no customer ever needs to deploy software in order to process a transfer. Open standards give you many software choices and give your trading partners a lot of choices on what they want to use.

Regarding Open PGP implementation, which RFC or RFC's do you follow? 

Well there are a couple. There is an original RFC2448  and there is a later RFC4884. Our commercial PGP product from Symantec is compliant with all of those standards - so the original and newer PGP RFC's are fully supported in our commercial product. Therefore we stay well lined up with those particular standards. Of course, there are some capabilities in the commercial product that are not defined as a part of the open standard - they are an extension if you will. There are a number of capabilities in the commercial version that really help larger enterprises stay lined up with compliance requirements and meet best practices. Those are built on top of full compliance with open standards.

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.

In part one of "HIPAA, HITECH Act, & Encryption Key Management" I sat down with Patrick Townsend, Founder & CTO, to discuss discuss the increased focus on HIPAA and the HITECH Act and the different types of encryption an organization could use to satisfy these requirements.  In part two, Patrick speaks on the benefits of encryption to organization in the health care industry, what the Department of Health and Human Services has to say, and finally how Townsend Security can help meet HIPAA and HITECH requirements for encryption and encryption key management.  Here is the second part of our conversation:

Download Podcast Now

Besides protecting patient information, does encryption provide any other benefits to the medical provider?

Yes, there is one particularly big benefit to anybody who is a covered entity, and that has to do with breach notification.  There is a breach notification requirement for anybody who loses patient data or thinks that patient data has been stolen from their system.  If you read the rules, there is no place where it says you must encrypt patient data – BUT- there is a section that says, if you have a breach, and if you have encrypted your data properly, there is a safe harbor from breach notification.  In other words, you don’t have to go through the expensive process of remediating the breach. 

So, there is a very, very positive practical benefit to any covered entity from using encryption, which is, if you have a breach, then that encryption will give you a safe harbor, or a way out from some of the more painful parts of breach notification.  Under breach notification, that information becomes public.  There can be fines levied around the loss of data.  Additionally, you must provide assistance to the patients whose information has been breached, which can be quite expensive.  In the credit card world, we know that the typical cost of remediating a breach is $214 per record, and now the average cost to an organization for having a breach is around $7 million.  So, the use of encryption and proper key management does have a very practical benefit to the covered entity itself in helping them avoid the more difficult and expensive costs of a breach notification.

What does the Department of Health and Human Services have to say about encryption key management?

Again, reading the rules, you will find references to NIST standards and best practices around key management.  It takes a lot of drilling down into the NIST best practices documents to really understand key management, but the information is there.  If I could boil it down to one really important concept, it is that managing encryption keys is the most important part of your strategy.  Protecting the keys is really what you do to protect the data.  So, implementing good key management is a core principle.  If you read the NIST standards, they talk about separation of duties, dual control, and split knowledge.  These are all concepts that have very real world implementations.

Dual control just says that when you are managing keys, you should have two people who must authenticate to manage encryption keys.  It makes sense if you want to avoid the potential for collusion around key management.  Separation of duties means that the people who manage data, or patient information, should NOT be the people who manage encryption keys.

These are the kind of concepts that auditors and others look for in a key management strategy.  In the real world, key management systems are very specialized appliances.  We are a vendor of general-purpose encryption key management solutions that implement these kinds of standards.  This is really how HIPAA and the HITECH Act approach the question about encryption key management.  Again, if you read the IFR’s, which become finalized later this year, they say to use encryption key management that is based on standards, such as NIST.

As a company that provides encryption and key management solutions, can you tell our listeners how these solutions can help them meet HIPAA and HITECH Act requirements? 

Traditionally, encryption key management has been the more difficult part of an encryption strategy, which we are now making easy.  It can be the most expensive part and most difficult to implement.  I think we have done a great job of creating affordable and cost-effective key management solutions, which are FIPS 140-2 certified and work well in a variety of environments across a lot of platforms.  So, the first thing that we have done that’s really beneficial in the medical segment, is creating an encryption key management solution that is affordable to customers and that works well with partners who distribute solutions in the medical environment.  Our encryption key management solutions really help drive down the cost of doing encryption the right way.  Again, the NIST certification on the key manager is important to provably meet the standards called out by the HITECH Act and the rules that they have been promoting.

Secondly, we do provide encryption libraries for customers who need them, so if you need to do AES encryption, for example, which is a NIST standard, we have encryption libraries that are very cost-effective, highly tuned for performance, and will work well in small and large organizations within the medical segment.

Lastly, we have some solutions around secure transfer of data, including PGP encryption and secure transport of data using SSL/TLS technologies.  Again, these match well with HIPAA and HITECH Act requirements for encrypting data.  I think this broad set of key management and encryption capabilities really help our partners and our customers meet these requirements.

To hear this conversation in it's entirety, download our podcast titled "HIPAA, HITECH Act, and Encryption Key Management."

Last week Townsend Security exhibited at the PASS Summit and showed off our new encryption key management appliance.  This was our first time attending this show, and if you aren’t familiar with the PASS Summit, it is the world’s largest, most-focused, and most intensive conference for Microsoft SQL Server and BI professionals.  This year's show was the biggest conference to date with over 4000 attendees.

This was a good show for us.  The SQL Server community really understands the importance of encryption and key management.  Microsoft made encryption much easier with the introduction of Transparent Data Encryption (TDE) in SQL Server 2008 and opened the doors for proper encryption key management with Extensible Key Management (EKM).  With this combination, it is now easier than ever for organizations to be encrypting their sensitive data with “best practices.”

It was encouraging to see how many people were encrypting their sensitive data using TDE.  When we told them about our encryption key management appliance, their eyes lit up and said, “I need that!  We need to meet PCI DSS and get our encryption keys off of our SQL Server.”  We were more than happy to tell them how easy it is to start properly managing their encryption keys – both technically and financially.  Our client installs easily - just like any other application on SQL Server and set up is a breeze.  When the average cost of a data breach to an organization is over $7 million dollars, it is getting easier to justify the business case for proper encryption and key management.

Of course not everyone was encrypting.  Some people just didn’t need to.  Others though, when asked about encryption, hung their head and said “No, but I probably should be.”  And these were people in the medical and financial industries!  (Note to self: don’t give these organizations my personal information.)

The concept of “leaving your keys under the mat” really resonated with this crowd.  If they didn’t know the importance of separating encryption keys from the encrypted data before they visited us, they certainly knew it well by the time they left.  We look forward to attending this show again next year and maybe the people who currently aren’t encrypting our private information will be first in line next year telling us about their “nightmare audit.”

For more information on our encryption key management appliance, built specifically for SQL Server, view our webinar “Encryption Key Management with Microsoft SQL Server.”  See how easy it can be to implement strong key management and hear what hundreds of attendees learned at PASS last week.

HIPAA and the HITECH Act have been hot topics lately.  Why is that?  First, the U.S. Department of Health and Human Services has recently issued guidance stating “unsecure protected health information (PHI)” is essentially any PHI that isn’t encrypted or destroyed.  This means that no matter how much technology you throw at securing the data, if it isn’t encrypted, then it isn’t considered secure.  The second, and arguably more compelling reason, is that HIPAA-covered entities are required to send notification letters if there is a breach of unsecured PHI.  Only using proper encryption grants safe harbor in the event of a breach.

I recently sat down with Patrick Townsend, our Founder & CTO, to discuss HIPAA, the HITECH Act, and encryption key management.  Here is part 1 of 2 of his thoughts on this topic:

Download Podcast Now

With HIPAA and the HITECH Act, there seems to be an increased focus on encryption.

Yes, there really is.  The technology that everyone looks to for protecting PHI is encryption.  So, yes, there is a real focus on encryption.  It is important.  Everyone who is a covered entity within the definition of HIPAA and the HITECH Act really needs to focus on protecting their patient information.  Encryption is specifically called out in the rules for covered entities, whether you are a health provider, an HMO, or any organization that is within that arena of medical delivery.

Are there any specifications on what type of encryption an organization should use?

Yes.  The HIPAA and HITECH Act are pretty explicit in providing the standards that are the basis of the approach you should take.  If you read the rules, as they are today, which are due to be finalized this year, they point straight to industry standards in terms of the kind of encryption and the techniques you should use to protect data.  The basic recommendations, in terms of standards, are to look at the National Institute of Standards and Technology (NIST) for proper ways of doing encryption and key management.

While the regulations aren’t specific in saying “You must use XXX algorithm for your encryption” they say you must base your encryption approach on widely accepted standards.  Additionally, they make specific recommendations to NIST for those standards.  If you look at the NIST standards, which have been in place for a long time, they publish standards on encryption and key management.  The proper encryption for “data at rest” or database files is AES encryption.  So patient data, at rest, in any type, is typically protected with AES.

For “data in motion” or data that you are transmitting, like patient claim data or patient information, we have standard protocols.  PGP whole file encryption, for example, is a well-accepted mechanism for protecting whole files.  It has been FIPS 140-2 certified, which means it is provably based on NIST standards for encryption.  Also, using a SSL/TLS connection for protecting data that you transmit over a web site or a web connection is another standard that maps directly to NIST.  Customers who base their encryption on those particular technologies will line up with NIST recommendations and best practices, and therefore align up with HIPAA and the HITECH Act. 

There is also a set of standards around encryption key management.  NIST publishes the best practices standards for encryption key management.  You have Special Publication 800-57 and other Special Publications that go together that really talk about key management.  And you also have FIPS 140-2 certification.  So key management solutions that are FIPS 140-2 certified match up to these regulations. 

To summarize, you want to find technologies that are based on standards.  Certifications lend credibility to the claim that they are based on standards.  Any organization that needs to protect data should look for solutions that have FIPS 140-2 and NIST certifications to indicate they are properly based on standards.

To hear this conversation in it's entirety, download our podcast titled "HIPAA, HITECH Act, and Encryption Key Management."

Last week we hosted a webinar titled “Encryption Key Management with Microsoft SQL Server 2008” and had excellent attendance!  The webinar covered meeting encryption key management compliance requirements on Microsoft SQL Server.  Patrick Townsend, Founder and CTO, discussed how our new hardware security module (HSM) is simplifying how organizations are meeting compliance requirements and how it removes cost as a barrier for a professional encryption key management solution. 

During the webinar we received some excellent questions that we would like to share.  As always, let us know if we can answer any further questions!

What are the performance impacts of encryption?

That’s a great question.  Encryption has a reputation for being very demanding from a performance point of view.  It doesn’t have to be that way.  We know from our own practice that encryption can be optimized and very efficient.  In the Microsoft SQL Server EKM environment, especially if you are using TDE, the SQL Server itself is doing the encryption of the entire table space and the encryption key manager is providing the vault and protection of the encryption keys.  Microsoft will tell you that TDE will impose about a 2-4% performance impact on your applications.  I think that is relatively accurate.  We have done our own testing with TDE and we come in closer to a 2% impact, and in some cases we come in even less.  Of course, you have to have the usual caveats.  Your applications and the size of your database may show you different results in terms of performance, but I think those are good numbers for guidance.  So, encryption is a pretty small impact on overall application environment for the protection that it provides.

Does your Enterprise Edition of Alliance Key Manager serve encryption keys to Oracle databases as well?

Yes!  We have customers today that are protecting data in Oracle databases using key retrieval libraries that we provide.  The same is true for MySQL, DB2, and other databases.  We provide a wide set of libraries to help customers protect data in any database.

How do you price your encryption key management for SQL Server solution?

The product is based on the number of key managers.  Depending on what customers need in the way of production and development environments, we provide a set of pricing plans to help them get into the technology in a very cost effective way.  If you would like formal pricing, let us know and we would be happy to schedule a call and see how we can meet your needs.

We are very focused on cost-effective solutions for our Microsoft mid-market customers.  We know that everyone’s resources are constrained these days.  We are philosophically committed to helping customers with cost-effective and FIPS-certified encryption key management solutions.

View our webinar "Encryption Key Management with Microsoft SQL Server" to learn more about utilizing Microsoft’s Extensible Key Management (EKM) interface in SQL Server 2008.

Welcome to our final installment in the "Data Privacy for the Non-Technical Person" series.  In case you missed the other two blogs in this series, here are the links to part one and part two.  This third and final blog will cover data privacy compliance regulations and how an organization would begin to develop a security policy.

We hope that these blogs have been informative and answered questions that you might have had about data privacy.  If you still have questions, please feel free to send us an email.  Additionally, download our podcast "Data Privacy for the Non-Technical Person" to hear my conversation with Patrick Townsend, Founder & CTO, in its entirety.

Are there are any laws or regulations requiring businesses to protect their sensitive data?

Yes.  There are quite a number of laws, and they cross over each other too.  Many find themselves having to work with several regulations when protecting data.  If you take credit cards, you fall under the Payment Card Industry Data Security Standard (PCI DSS). PCI DSS is a private regulation promoted by the card brands (Visa, MasterCard, etc.).  If you are a bank or engaged in the banking industry you fall under the Gramm-Leach-Bliley Act (GLBA) and FFIEC regulations for protecting information.  Those are specific to the banking industry.  If you go to the doctor or are a doctor/medical clinic or any place in the medical industry, you fall under the HIPAA/HITECH Act to protect patient’s medical information.  There are also other regulations too.  The government is moving laws through congress to define protections for PII.  So there are a number of regulations affecting data that needs to be protected.

So how would an organization begin to develop a security policy?

This is a real challenge, particularly if you are starting for the first time.  It can seem overwhelming, especially when we read about the sophistication of data breaches and the attacks on companies.  Keep it simple to start – there are things that you can do to that are very effective upfront and know that you are vulnerable.  I think one think that sometimes inhibits people from taking action is thinking that they are not going to be subject to a data breach.  That is a dangerous attitude.  So, keeping it simple, taking simple steps, ranking where the vulnerabilities are and doing those things first are really important things.  There are really the obvious things like making sure you have good anti-virus software running on your computers and using good, strong passwords.  If you have a web site, there are scanning tools that will help you scan to see if your web site is secure.  And if your business is handling sensitive data, run background checks as part of your new employment procedures.  Finally, there is some online help that can be really useful for most people – sans.org is a place where you can go to get basic policy information and educated on threats.  For business that need to secure data, we have a lot of resources on our website to help you understand the various regulations and what encryption and key management tools you can use to begin protecting your data.

Download our podcast “Data Privacy for the Non-Technical Person” to hear more of this conversation.

This week brings part two of the "Data Privacy for the Non-Technical Person" series.  Last week we determined what constitutes personal information that needs to be protected.  This week Patrick Townsend, Founder & CTO, talks about how organizations are protecting sensitive information, how encryption and key management relate to each other, and what happens when encryption is not done correctly.  If you are jumping in mid-stream, you can read part one here.  Additionally, you can download our podcast titled "Data Privacy for the Non-Technical Person" to hear our conversation in its entirety.

How do organizations protect sensitive information?

They use a number of techniques.  Some of them are pretty obvious.  Businesses use anti-virus software and software to detect intrusions on their network, as well as making sure they have a secure web site if they are taking sensitive information from you over the internet.  And then they do some things that most people might not be aware of.  A business that is trying to protect your personal information will do some things that are procedural in nature – for example a lot of companies will now make sure all new employees have a background check.

Companies are also doing things that help make their data very difficult to steal.  Encryption, which is the process of taking a credit card or social security number and turning it into and encrypted value, makes stealing data near impossible.

Companies who are really trying hard to protect information of their customers and employees are deploying a variety of tools.  Encryption is probably one of the more important ones and it is one of the more difficult technologies to deploy, but certainly all of the major companies that you might do business with over the Internet will be using encryption to protect your data.

Encryption and key management have been talked about a lot lately.  How do they relate to each other?

Encryption and key management go together.  They are very complimentary technologies.  When you encrypt a credit card number, you have an encryption algorithm that takes your credit card number and turns it into something totally different.  But another important input into that process is a secret key.  Many people think that the encryption algorithm itself is some kind of secret mechanism, which isn’t the case.  Encryption is well understood.  There are standards for it and it is readily available.  What is really the secret that prevents losing data is the encryption key – just like the key to your front door is what protects your house.  An encryption key works very much in the same way.  Companies that use encryption really have to create a key that is very unique and very strong, and they have to protect it so that it doesn’t escape into the wild. Anyone that has the encrypted data and the encryption key, really can get the sensitive data back.  In the real world of protecting data with encryption, measures are taken to protect the encryption key – that is the real secret that people are trying to protect in a business environment. 

What happens when encryption is not done correctly?

There are many ways that encryption can be done poorly or incorrectly.  We see that sometimes around the area of encryption key management.  For example, storing an encryption key on the same platform where the data that it is protecting is just bad practice.  Sometimes you hear the term “integrated key management” or people say “we are storing the encryption key in a database file and we have locked that database file down.”  These are really poor practices and, in fact, cannot meet compliance regulations about encryption key management.  So, that is just one example of encryption that is done badly.

Other examples are just using non-standard or proprietary encryption.  The CUSP mode of AES encryption, for example, is not a standard mode and is a proprietary protocol that can’t be a part of true compliance.  It is just another example of running off the rails in terms of best practice for encryption.  A company that is purchasing encryption technologies should really examine their vendors carefully.  I always point back to NIST certification because it is the bottom-line indication you have that the encryption product is a good quality solution. 

Here is another interesting thing that I think people sometimes forget.  If you have a data loss, it is going to be your problem, not the vendors problem.  Even though you may have acquired a solution that is not right, it is still going to fall on you.  It is going to be your headache to solve, your customers that are upset, and your financial loss when data gets out.  The loss of trust from your customers and employees is also difficult too.  For all these reasons, I think paying attention to encryption technologies is a good idea.

Stay tuned for our next and final installment in this series.  Download our podcast “Data Privacy for the Non-Technical Person” to hear more of this conversation.

As I attend industry events, it is surprising how many times we hear questions like “what constitutes personal information that needs to be protected?”  I recently sat down with Patrick Townsend, our Founder and CTO to discuss data privacy for the non-technical person. 

When speaking about data privacy, the conversation often turns technical with common questions like “How do we implement encryption and encryption key management?”  This time, we intentionally kept our conversation focused on data privacy topics that can be understood from a high-level. 

I have created a series of blog posts from this conversation that will be posted in the next couple weeks.  Hopefully this blog series will answer any questions that you might have.  If you still have questions, feel free to send us an email.

What constitutes personal information that needs to be protected?

The first thing that everyone thinks of are credit cards numbers.  We know that we don’t want our credit card numbers escaping into the wild and having to go through the process of replacing them.  I think that by now, most people have experienced getting a call from their bank, being alerted to potential fraud, and going through the process of having to replace a card.  So credit card numbers are obviously personal information that people need to protect.

There are also other things that I think are important – financial bank account numbers.  We are all doing a little bit more now in terms of online banking.  Those bank account numbers carry value and we need to be very careful about that.  There are also some other items that tend to be used to commit financial fraud, such as social security numbers, driver’s license numbers, birthdate, etc.  In fact, information like your passport number, military ID, or health ID – all of those are examples of information that you should try and protect and make sure you are not sending them around or leaving them in places that can be easily picked up.

Other things like maiden name or previous addresses are also important.  Think about the types of questions your bank asks you when you give them a call.  They are using that information to identify you and the fraudsters will use that information to impersonate you.  These are all examples of sensitive information that we should be protecting.  For people who are interested, the technical term for this type if information is Personally Identifiable Information or PII.

Stay tuned for our next installment in this series.  Download our podcast “Data Privacy for the Non-Technical Person” to hear more of this conversation.

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.