Townsend Security Data Privacy Blog

Encryption for Data at Rest
Linux applications use a variety of database and storage methods that include MySQL, MongoDB, PostgreSQL, Amazon S3 and RDS, and many others. Like any application deployed on any operating system and storage mechanism, Linux applications need to protect sensitive data at rest using strong encryption. Compliance regulations, state and federal laws, customers, employees, and stockholders expect data to be protected and Linux developers know this.

The most common method of encryption for data at rest is the Advanced Encryption Standard, or AES. Sometimes call Rijndael, reflecting the names of the original authors Joan Daemen and Vincent Rijmen, AES is now an international standard. Using AES encryption will align you with these standards and with all major compliance regulations. Fortunately, AES is now available in a wide variety of development languages and software libraries. On the Linux platform, you will find ready-to-use AES encryption support in development languages like Java, PHP, Python, Perl, Ruby and many others. The OpenSSL software library also provides access to AES encryption.

Using the Right Mode of Encryption
AES encryption can be implemented via several modes of operation. Electronic Code Book (ECB) is the basic raw mode of operation, but you should avoid it for business applications. It can leak information when encrypting repetitive data. Probably the most common mode of operation for protecting business data with AES is the Cipher Block Chaining (CBC) mode. It takes a random Initialization Vector (IV) which helps prevent leaking information when encrypting repetitive data. You will find support AES CBC mode in all of the primary languages and software libraries. There are other modes of encryption that use IVs, but you will find AES CBC is most commonly used in business applications.

Initialization Vectors
Assuming you are using a mode of AES encryption that uses an initialization vector such as CBC, be sure that you are using a good random number generator to create the IV and that it is unique for each item that you encrypt. In other words, don’t use a fixed IV and don’t re-use an IV in your application. If you use this practice for generating unique IVs you won’t need to protect the IV with encryption as it is not considered cryptographic material. However, if you have especially sensitive data or a lot of it, it won’t hurt to take the extra precaution of encrypting the IV.

Encryption Key Management
Now we get to the hard part that most developers get wrong about encryption - the protection of the encryption keys. A good encryption strategy depends on the use of strong encryption keys, and the protection of that key. Encryption keys that are weak or that are stored on the same server as the sensitive data are likely to provide little real protection. Common poor practices include:

• Using a password as an encryption key.
• Using a flawed or non-standard random number generator to create a key.
• Storing the encryption key in the application code or in a SQL statement.
• Storing the encryption key in a file or table.
• Storing the encryption key with poor protection (XOR with weak data, etc.).
• Storing the encryption key with password-based encryption protection.
• Storing the encryption key on a mounted drive.

These are just a few of the practices that can set you up for a data breach and compliance audit failure. Use a good key management system that is designed for that purpose and which meets industry standards like FIPS 140-2.

Retrieving a Key vs. Using an Encryption Service
Assuming you are protecting the encryption key properly, you need to decide if you want to retrieve an encryption key from a key manager and then use it to perform encryption, or if you want to use an encryption service provided by the key manager. If you are developing an application in a more exposed environment such as a cloud platform, or an internet-facing web server, you may want to reduce the risk of encryption key loss by using an encryption service on the key manager. All encryption is performed on the key manager and the key never leaves the key management server. This can provide additional protections against the loss of the key.

If you are encrypting large amounts of data, or making many encryption requests in your application, retrieving the encryption key once and using it many times can provide a boost in encryption performance. Remember to securely erase the key when you are finished with it.

Key Management and Business Continuity
When you use a key management system it becomes a part of your critical infrastructure. This means that it is particularly important that the key management system provide a high level of redundancy and implement best practices related to backup and restore. If you are using a hardware security module (HSM) it should implement redundant power supplies, hot swappable RAID disk drives, and redundant network interfaces for maximum resiliency. All key management systems should implement real-time, active-active key and policy mirroring, automatic recovery from network failures, manual and automated backup, and a high availability failover strategy. The ability to implement geographic redundancy between primary and secondary key servers should be fully supported, and this can be a challenge on some cloud platforms.

Key Management and Key Custody
Who has access to your encryption keys is becoming a hot-topic issue for many organizations. In many regulated environments you must insure that unauthorized access to keys or compromised keys can be detected and managed by your organization. This is not always possible with some cloud service provider key management services. Additionally, access to encryption keys by law enforcement or government agencies may happen without your knowledge. Be sure that your key management strategy gives your organization exclusive access to encryption keys and prevents the key management vendor, cloud service provider, or another other entity from accessing encryption keys. You should be able to receive clear and unambiguous assurances from your key management vendor or cloud service provider on this question.

Key Management and Virtualization
Most organizations now deploy their Linux and Windows applications in virtualized environments such as VMware. Almost all encryption libraries and language implementations of encryption are compatible with VMware and other virtualization platforms. The same is not true for key management solutions and vendor-provided SDKs. Even if your Linux application will not be deployed on VMware today, be sure that you implement an encryption key management strategy that will allow deployment of the key manager in a secure workgroup in VMware. The key manager should be fully virtualized and able to support a no-hardware approach to deployment in VMware.

Key Management and the Cloud
If your Linux applications will be deployed on a cloud platform it can be tempting to use the key management services of the cloud service provider. These services are very low cost or free, and are therefore attractive. Think hard about this before you make this decision. Besides key custody issues (see above) most key management services on cloud platforms use proprietary interfaces to their key management services. This locks you into the particular cloud service provider and makes it difficult to migrate to other platforms. It also makes it extremely difficult to implement dedicated key management services outside of the cloud platform. As attractive as cloud key management services appear to be, there are definite downsides to binding your Linux application to one specific cloud platform.

Key Management, Developers, and SDKs
Linux developers need maximum flexibility as they deploy applications and web services. One application may be based on the Java language, another on Python, another on Ruby, and so forth. There is a rich ecosystem of development languages available to Linux developers. When deploying encryption key management to protect encryption keys be sure that you have access to a rich set of SDKs that work naturally across all of these environments. When you deploy a Java application you want a Java SDK to enable key management. Attempting to cobble together a solution using different language SDKs is going to be a difficult and unpleasant process, not to mention the problems with supporting hybrid language environments.

Key Management for Linux ISVs
If you are developing a Linux application to take to market you have a number of other issues to consider. Your customers will want to run your solution in a variety of ways. Some will be happy with a low cost, multi-tenant cloud solution. Others will want to deploy in a dedicated virtual private cloud. Others will want a traditional IT data center approach, perhaps with VMware infrastructure. And key management requirements will be all over the map. Shared multi-tenant key management, dedicated cloud key management, dedicated virtual cloud key management, and true hardware HSMs will all come into play. Be sure that your key management solution works well in all of these environments and bridges them in hybrid deployments. Getting this right from the beginning will be important to your success as a Linux ISV.

The Health Insurance Portability and Accountability Act (HIPAA) of 1996 requires that medical providers, called Covered Entities, implement data security to protect patient information from disclosure. Sensitive patient data is termed “electronic protected health information”, or ePHI, and includes information like patient names, addresses, social security numbers, procedure codes, birth dates, and much more. All Covered Entities, which is almost everyone in the healthcare system, must implement these data security controls. As a matter of law, a Covered Entity that fails to protect patient information and suffers a loss or exposure of that information must make a formal data breach report to the US Department of Health and Human Services.

Because many of the losses of patient data happened not by Covered Entities, but by vendors and service organizations they hire, the regulations were amended to cover Business Associates. Any Covered Entity that shares patient information with an outside organization must now have a Business Associate agreement with them that binds them to the same patient data protections that HIPAA requires of Covered Entities. This plugged a hole in the original HIPAA law that resulted in patient data loss through outside vendors. Everyone who handles ePHI, inside or outside the medical industry, is now obligated to implement the HIPAA data security rules.

So, to the basic question: Do I have to encrypt patient information?

The answer is Yes, but the rule allows for some exceptions. Let’s examine this more closely, because those exceptions get a lot of Covered Entities into trouble.

The HIPAA regulation requires the encryption of patient information when stored on disk, on tape, on USB drives, and on any non-volatile storage. This is called encryption of data at rest. The HIPAA regulation also requires the encryption of data as it moves across a network via a web browser session, FTP or any other method used to transfer data. This is called encryption of data in motion.

The relevant regulations which say you have to encrypt ePHI are these:

45 CFR 164.312(a)(2)(iv)

45 CFR 164.312(e)(2)(ii)

The regulations are simple and very easy to read. I suggest that you take a quick look. Just a few sentences define the requirement.

Notice that there is no mention of laptops, backup tapes, USB thumb drives, tablets, phones, or anything else in the regulation. If it is “electronic protected health information”, or ePHI, it must be protected.

Now we have to take a little side trip. Notice that this security control is “addressable”. What does that mean? Here is the formal definition for an addressable control.

So now you know that there is not a hard mandate to encrypt patient data if you can document that there is a reason you can’t do it, AND if you have an alternative that is equivalent to encryption. You might argue, for example, that it is expensive to do encryption. Or that it is really, really hard to do encryption. Those may actually be valid arguments. If you make that argument you have to document your reasons, and you have to provide a reasonable, appropriate, and equivalent alternative to encryption.

Notice those words “reasonable”, “appropriate”, and “equivalent”. Those are the words that are likely to get you into a lot of trouble. If you decide not to use encryption, you are committing to using something that is an equivalent method of protection, and you are committing to documenting your reasons.

Covered Entities put themselves at risk when they decide to use addressable controls for encryption. Those include:

• Failing to document the reasons why encryption can’t be used.
• Failing to document the particular hardship that encryption entails.
• Failing to implement a reasonable alternative to encryption.
• Failing to implement an equivalent method of protection.

When a Covered Entity experiences a data breach, the fact that data was not encrypted and the fact that the alternative method did not prevent the data breach, will put you at direct risk for a compliance action. It will be hard to argue that you’ve used a protection method that is equivalent to encryption when you’ve actually lost the patient data! It is going to be hard to win that argument.

If you review a number of the Corrective Action Plans (CAPs) for data breaches you will find that there are often a number of failures involved in the data breach besides the loss of unencrypted ePHI. Improper documentation and inadequate staff training are almost always involved when OCR issues a fine and CAP over a loss of patient data. But the failure to encrypt ePHI is always involved.

Now we are back full circle to our question: Do I have to encrypt patient information?

I think you can see now that the answer is "Yes". You need to encrypt patient data in order to provide adequate protection to your patients AND to your organization as a whole. It’s the only defensible strategy in light of how HIPAA, HHS, and OCR will evaluate your data breach.

We work with a number of Covered Entities around data protection and the implementation of encryption. I know that almost all Covered Entities have gaps in their implementation of encryption. Here are a few things you can do right now to start to address these:

• Make an inventory of all of the systems that store or transmit patient data.
• Identify all of the systems where encryption is not implemented.
• Prioritize the implementation of encryption for all of these systems. In many cases this will mean working with a software or hardware vendor.
• If vendor updates are available that add encryption capabilities, schedule those updates as soon as possible.
• Immediately notify all of your software and hardware vendors that you expect them to implement encryption according to industry standards, and that future acquisitions will require this security control.
• Remember that a proper implementation of encryption involves protecting encryption keys from loss. Be sure that encryption keys are stored away from patient data on key management servers that are designed to protect encryption keys.
• Make an inventory of all Business Associates that receive patient data from you and be sure you have a signed Business Associate agreement on file.

Encryption is far easier to implement now that at any time in the past. Covered Entities have lots of options and don’t have to be at risk of a compliance action.

Pretty Good Privacy (PGP) is a mature and well-regarded whole file encryption application. In partnership with PGP Corporation, McAfee and now Symantec, we’ve implemented PGP Command Line on both the IBM i (iSeries, AS/400) and on the IBM System z Mainframe. Our customers often have questions about PGP compatibility with open source implementations like Gnu Privacy Guard, or GPG. Let’s dive into this a bit deeper.

Before we jump into a discussion of solutions and their compatibility, it’s important to know about the Internet standards for PGP. These standards are defined in RFCs 2440 and 4880. The standards are referred to as the OpenPGP standard. These Internet RFCs define the format and behavior for any application that claims to support the OpenPGP standard. They do not define an application, and the term OpenPGP does not refer to any actual application or solution. It is just the name of the standard.

We have a standard for PGP, so now we need to identify which applications implement the standard. That’s important because we want our PGP encrypted information to be supported by the largest number of platforms and vendors.

In the open source world there are several solutions that implement the OpenPGP message format and conform to the RFC standards. Probably the most well known is the GNU Privacy Guard, or GPG, application. It is available on several operating system platforms including Windows, Linux, and Unix. GNU has a large community of developers who support this application and it is readily available. Other open source implementations include Bouncy Castle, the International PGP organization, Portable PGP, and others. While GNU Privacy Guard is actively maintained, other open source implementations may not receive as much on-going attention from developers.

Because of its history with the original developers of the PGP, the most common commercial version of PGP is provided by Symantec. Here at Townsend Security our relationship with Symantec allows us to bring the commercial version of PGP to IBM Enterprise platforms IBM i and IBM System z. We’ve been supporting PGP on the IBM platforms for more than a decade. Other commercial versions are provided by Viacrypt and SDS and are supported by those companies.

The OpenPGP standard assures customers that encrypted files can be processed by any application that supports that standard. The open source and commercial versions mentioned above do implement support for the OpenPGP standards.

The OpenPGP standard is reasonably complex and it is easy to inadvertently introduce incompatibilities. Interoperability testing is crucial to avoid implementation errors. Since there is no independent certification authority for PGP it is up to the open source and commercial vendors to perform interoperability testing. Here at Townsend Security we test our implementation against a variety of open source and commercial versions. We also perform the cryptographic test suite defined by the National Institute of Standards and Technology (NIST) to insure that our implementation of PGP Command Line meets all of the relevant encryption standards. In this respect we are standing on the shoulders of those original giants of the PGP world who brought us PGP and who regularly performed NIST FIPS 140-2 validation.

The IBM Enterprise servers are quite different than their Windows and Linux operating system cousins. You might wonder how easy it is to use PGP on these platforms. Our developers at Townsend Security have worked hard to adapt PGP to these platforms without impacting the implementation of OpenPGP. For example, PGP Command Line for the IBM System z Mainframe fully supports Batch z/OS, multiple z/OS file systems, z/OS text files, and built-in support for code page conversions. Combined with a number of JCL examples of encrypting, decrypting and signing files with PGP it provides a powerful implementation of PGP on that platform.

Our customers on the IBM i and IBM System z regularly exchange encrypted files with partners running GNU Privacy Guard. That compatibility is important to us and we will continue to validate our commercial PGP implementation with GPG through interoperability testing.

Patrick

Excerpt from the White Paper "MySQL & VMware - Encryption and Key Management for Developers."

Whether you develop mostly on Linux or Windows, you can achieve a compliant implementation of encryption with the MySQL database and variations of MySQL like MariaDB. This blog looks at some key decisions you will need to make about the encryption approach, and how we help our customers get encryption right.

Using the MySQL Built-in Encryption Primitives

MySQL supports a number of encryption and encoding operations directly from the SQL language. When encrypting a column you can use the ENCRYPT function, AES_ ENCRYPT function, the older DES_ENCRYPT function, or the encoding or compression algorithms. If you want to use this approach to encryption and decryption, I would recommend that you use AES_ENCRYPT and AES_DECRYPT. For this, primitive MySQL uses the industry standard 128-bit AES algorithm, which is considered strong encryption and meets compliance regulations.

While the DES_ENCRYPT support is still a part of recognized industry standards, you will have a performance benefit when using the stronger 128-bit AES support and are not likely to run into the problem of a future deprecation of the Triple DES algorithm used by the MySQL DES_ENCRYPT method.

Here is an example of a MySQL insert statement that uses AES_ENCRYPT with a hex representation of the encryption key:

INSERT INTO t
VALUES (1,AES_ENCRYPT(‘text’,UNHEX(‘F3229
A0B371ED2D9441B830D21A390C3’)));

Of course, hard-coding the encryption key is poor security practice.

Encryption at the Application Layer

Encrypting and decrypting directly in your SQL statements is not always possible or optimal. Don’t worry, you can also implement encryption in your application code if that makes more sense. Our Alliance Key Manager includes several language-specific software libraries for developers. For example, if you are a Java developer you can install and use our Java .jar files for full support for encryption key retrieval and on-device encryption. If you are a Windows C# developer you can add our Windows .NET Client to your Visual Studio project and have full support for key management. Both Java and C# have great support for encryption - you won’t need support from third parties for AES encryption - but you will need to implement encryption key management the right way.

What are some reasons you might want to do encryption at the application layer?

• Minimize the changes to SQL for different databases.
• Take advantage of the stronger 256-bit AES encryption method.
• Use an AES mode of encryption that uses an Initialization Vector such as Cipher Block Chaining (CBC) mode.
• Embed information in the encrypted field about the key used, the version of the key, and the IV.
• Create custom logic for encrypting larger blobs in the database.

Whatever the reason or combination of reasons, implementing encryption at the application layer is an easy choice to make with the Alliance Key Manager language SDKs.

Where are the Encryption Keys?

The single biggest challenge a developer will face when deploying encryption for MySQL is how to properly manage encryption keys. Not getting it right leaves the organization open to security failures, audit failures, and litigation. Here are some ways NOT TO STORE encryption keys:

• As a part of the SQL statement (see above).
• In the application code.
• In a file on the same server.
• In a file on a separate server.
• In a separate table in the MySQL database.

All of these approaches have been the cause of security audit failures for our customers. Don’t let this happen to you.

Summary

Developers are the tip-of-the-spear when it comes to protecting their organizations from data breaches. When they are aware of the critical success factors for an encryption strategy they can dramatically improve the overall security posture of their companies.

At Townsend Security we provide developers with the tools they need to be successful and to get encryption right. Our key management solution, Alliance Key Manager, runs in all of the platform environments that developers need. The applications and software development kits that come with Alliance Key Manager run in VMware, the cloud and everywhere else you might deploy the MySQL database.

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

Mic drop! California leads the way, once again.

California started the data breach notification revolution with SB 1386 back in 2003. Almost all of the other US states and territories followed suit passing their own versions of SB 1386, or passing even stronger protections.

Then California strengthened the original law with several new regulations that more stringently define what qualifies as encryption, and how law enforcement agencies interact with encrypted technologies.

THIS MONTH, the California Attorney General Kamala D. Harris published the “California Data Breach Report, 2012 - 2015”. Citing the California constitution’s guarantee of the “inalienable right” to privacy of its citizens, the report makes a new case for strong data protections.

You can read the entire report here.

Not only does the report make the case for strong data protection, it makes this statement as the first recommendation on about page 27:

Recommendation 1: The 20 controls in the Center for Internet Security’s Critical Security Controls define a minimum level of information security that all organizations that collect or maintain personal information should meet. The failure to implement all the Controls that apply to an organization’s environment constitutes a lack of reasonable security.

That’s right, the highest law enforcement official at the California Department of Justice just said that failing to implement the CIS Critical Security Controls demonstrates a lack of minimum reasonable security. While not intending to be legal advice, you can bet that this language will make its way into every lawyer’s lexicon when litigating a data breach or any failure to protect personally identifiable information (PII). Say this phrase over and over to yourself:

“A lack of reasonable security”

You are going to be hearing this a lot very soon.

There is no doubt that the 20 Critical Security Controls are very important. They encapsulate the best working knowledge of the security community on what you should do to protect your systems. They intentionally reflect the combined wisdom and experience of security professionals on what is effective and what has proven to work to protect systems.

You can read the CIS Critical Security Control here.

There is a lot of helpful documentation and guidance on the CIS web site. You will find practical guides for each of the 20 critical controls, a spreadsheet to help you organize your work, and other backing documentation. It will be a great resource as you start to move forward.

The change in mindset that this report signals won’t happen overnight. But it will happen and you should get prepared now. Here are some practical things you can do right away:

• Read the California Attorney General’s report. It will be old news for you security professionals, but for everyone else it is a great place to start. You can hand it out to your executives, too.
• Read the CIS Critical Security Controls which is now in version 6 (see the link above).
• Download the CIS Critical Security Controls spreadsheet. This will give you a template for the work you will need to do.
• Create a team to take the lead on implementing the security controls. You will need a member from your business leadership, a member of your compliance committee, a security professional, a manager from your application development team, and a manager from your network team. If you are a VMware shop, be sure to add someone from the VMware infrastructure team.
• The team should review and prioritize the security controls as the first task.

Now get to work implementing the controls! Some will be fairly easy to accomplish, and some are going to take some time and additional budget. But as I hinted above, it is going to be cheaper to do this now than to pay litigation costs and then have to do it under the gun.

As Laozi said “A journey of a thousand miles begins with a single step.”

Patrick

As everyone is now aware the Federal Bureau of Investigation has acquired a court order requiring that Apple create a back-door to the iPhone that would allow bypassing the protection provided by strong encryption.

Tim Cook, the CEO of Apple, has strenuously objected to this order on the grounds that providing a back-door will make everyone less safe. You can read Apple’s reasoning and response here.

Like Apple, here at Townsend Security we create encryption products that do not have back-doors or ways to bypass security. We do not hold any encryption keys that would allow us to have access to customer information, and we also believe that this makes our customers that much safer. This approach is strongly supported by the security and cryptographic communities who have noted that law enforcement agencies have many other effective tools to help them prevent crimes.

I am in complete agreement with Tim Cook’s response and support his efforts to quash this initiative on the part of the FBI. Like Tim, we are appalled at the violence that took place in San Bernardino. I grew up close by and have family in the area. I believe that I can understand the fear that people feel. But we are all immensely safer when the technology products we use implement the best possible security.

I also have a great respect and admiration for local, state, and federal law enforcement. They are tasked with an unbelievably difficult and often dangerous job. They work hard every day to keep us safe and I know they want to have all of the tools they need to accomplish that job. In the case of encryption back-doors, we should have a dialogue as a people before handing this tool to law enforcement. The time for that dialogue is now.

It should be clear to everyone that providing back-doors that circumvent strong encryption protections will be the immediate target of cyber-criminals and state sponsored hackers. The risk to to those struggling for freedom against tyrannical regimes is truly frightening. Further, there will be an immediate loss of trust in US products that implement such back-doors. This is not good for Apple’s business or any US business that relies on the trust of its customers across the world. The damage to US commercial interests would certainly be quite large.

There is nothing certain about life and we all must face our many fears. Individually and as a people we do better when we face life from a place of courage and confidence. I strongly support Apple in their efforts to stop this unfortunate attempt to weaken their products and therefore the safety of their customers.

Patrick Townsend

When our customers consider deploying Alliance LogAgent for IBM QRadar on their IBM i (AS/400, iSeries) servers, they often have a number of questions about how the application works. Here are a few of the common questions we encounter:

Can I monitor security events collected in the IBM security audit journal QAUDJRN?
Yes, all of the events in the QAUDJRN security journal are processed by Alliance LogAgent and assigned a severity level that is recognized by QRadar. Be aware that the security event information collected in the QAUDJRN security audit journal depend on system values that you define. Minimally you should configure your IBM i server to collect all *SECURITY level events. See the Alliance LogAgent documentation for more information.

Can I monitor user messages in the security audit journal QAUDJRN?
Yes, Alliance LogAgent for IBM QRadar processes all user-defined events in the security audit journal. If you wish to write user-defined events to QAUDJRN you should be aware of the data format defined for QRadar called the Log Event Extended Format, or LEEF. The LEEF format documentation is available from IBM.

Why is Alliance LogAgent for IBM QRadar better than what I already have?
Alliance LogAgent for IBM QRadar has several security advantages over the native AS/400 DSM definition in QRadar. The most important is that Alliance LogAgent processes security events in real time. This means that QRadar can perform event correlation and alerting more effectively. There is less chance that a security breach will result in the loss of data. Additionally, Alliance LogAgent provides more information for security events. For example, when a user profile is changed all of the granted authorities are reported to QRadar, not just the summary information. Lastly, Alliance LogAgent collects information from a variety of sources including IBM i Exit Points, the system message file QHST, the system operator’s message queue, and user defined messages via a data queue. For all of these reasons Alliance LogAgent for IBM QRadar will improve your IBM i security.

Do I have to make any changes to QRadar?
No, you just need to pull the latest QRadar Device Support Module (DSM) definitions from IBM and you are ready to use Alliance LogAgent for IBM QRadar. If you are automatically updating your DSM definitions you probably already have the DSM support you need. Townsend Security worked with the IBM QRadar team for the DSM definitions. You do not need to do any manual work for IBM QRadar to recognize and process IBM i security events transmitted by Alliance LogAgent for IBM QRadar.

Is Alliance LogAgent for IBM QRadar certified by IBM?
Yes, Townsend Security worked directly with the IBM Security QRadar technical team to certify the security events transmitted by Alliance LogAgent. Out of the box the QRadar SIEM will recognize and process events sent by Alliance LogAgent for IBM QRadar. Townsend Security is validated to the Ready For IBM Security Information program.

What is the performance impact?
Alliance LogAgent for IBM QRadar runs as a low priority batch job on the IBM i platform and will have minimal impact on CPU and other resources. The application uses normal IBM APIs for security event information and does not bypass normal application performance controls. You should not notice any significant impact on interactive user jobs or system resources.

Can I filter messages that are sent to QRadar?
Yes, Alliance LogAgent for IBM QRadar provides several ways to filter messages sent to IBM QRadar including:

• Which QAUDJRN events are reported
• Which QAUDJRN user events are reported
• Which System Values are reported
• Which libraries and objects are included or excluded
• Which IFS directories and files are included or excluded
• Which user profiles are excluded.
• Which IBM i Exit Points are monitored
• Which files and tables are monitored at the field level

As you can see you have many options for filtering which events are transmitted to IBM QRadar.

How much storage does Alliance LogAgent use, and will I need to add storage?
Alliance LogAgent does not make any temporary or permanent copies of security information and will not impact your storage utilization. The only storage you need is for the Alliance LogAgent program objects (about 100 Megabytes) and you will not need to add additional storage.

How are security events transmitted to QRadar, and will I need third party software for this?
Alliance LogAgent provides the communications applications as a part of the base product and you will not need any third party software.

Can I monitor exit points like FTP?
Yes, Alliance LogAgent monitors the FTP exit point and several other critical exit points provided by IBM. These include the exit points for remote data queues, SQL (including ODBC), DB2, FTP and many others. Please contact Townsend Security if you have questions about a specific exit point. New Exit Point monitors are added on a periodic basis.

Can I monitor messages in the system history file (QHST)?
Yes, Alliance LogAgent for IBM QRadar can monitor messages in the QHST system history files. It automatically detects new QHST files created by the operating system and processes messages in near real time.

Can I monitor changes to database files at the field level?
Yes, Alliance LogAgent for IBM QRadar includes a license for the File Integrity Monitoring module. This gives you the ability to monitor access to one or more fields in any database file. There is no limit to the number of fields or files that you can monitor. Monitoring also includes processing file open and close requests so that you have a full picture of user access to a file.

Can I my RPG and CL applications write messages to QRadar?
Yes, Alliance LogAgent can monitor one or more user data queues and transmit messages to QRadar. Your application can write the important security information to the data queue and Alliance LogAgent will add the QRadar headers, convert to the ASCII character set, and transmit the event to QRadar in the appropriate format. There is no limit to the number of data queues you can define or the number of messages.

We use Splunk for log collection, can we use IBM QRadar at the same time?
Yes, many customers use both Splunk and QRadar at the same time. You will find information in the IBM and Splunk documentation on how to implement these solutions together. It is recommended that you send information to QRadar in the native Log Event Extended Format (LEEF) first, and then forward the information to Splunk. This will give you the best security implementation.

How is Alliance LogAgent for IBM QRadar licensed?
Alliance LogAgent for IBM QRadar is licensed on a Logical Partition (LPAR) basis at a flat fee per LPAR. Multiple license discounts are available. Please contact Townsend Security for pricing and support options.

I am using a different SIEM solution, can I use Alliance LogAgent?
Yes, Alliance LogAgent works with all major SIEM solutions including, but not limited to, LogRhythm, Alert Logic, AlienVault, Splunk, McAfee and managed service providers like Dell SecureWorks, NTT/Solutionary and others. If you decide to upgrade to IBM Security QRadar you can easily upgrade to Alliance LogAgent for IBM QRadar.

I need help installing IBM Security QRadar, can you help us?
Townsend Security provides no-charge support for installation and configuration of Alliance LogAgent for IBM QRadar on your IBM i server. If you need assistance with installing, evaluating and using IBM Security QRadar we will provide you with an introduction to a certified IBM QRadar partner company.

Can I try Alliance LogAgent for IBM QRadar on my IBM i server?
Yes. Alliance LogAgent for IBM QRadar can be downloaded and installed on your IBM i server at no charge. During the evaluation period the solution is fully functional and you can integrate it with IBM Security QRadar at no charge for the Townsend Security software (IBM QRadar EPS charges may apply).

How do I get started with Alliance LogAgent for IBM QRadar?
Once you request an evaluation of Alliance LogAgent for IBM QRadar you will receive information on how to download the software and install it on your IBM i server. The Townsend Security customer support team will provide you with training and support at no charge.

If you have any other questions about Alliance LogAgent for IBM QRadar, or other Townsend Security solutions, please contact us.

Now it’s time to take the next step and improve your IBM i security.

Take a victory lap, you deserve it!

You deployed one of the best security applications to help protect your IBM i data - IBM Security QRadar. As a Gartner Magic Quadrant leader in SIEM the QRadar solution is proving a valuable part of your company's’ security strategy. IBM QRadar is easy to deploy, easy to use, easy to manage, and automatically learns about your environment to get better over time. Actively monitoring your network, applications and systems is one of the Top 10 security controls, and QRadar is one of the leading SIEM solutions. You deserve that victory lap!

After you take that victory lap and catch your breath, it is time to take the next step.

The NEXT STEP ???   I thought I was DONE !!!

Not quite. Like all SIEM solutions IBM QRadar works best when it gets information in real-time. When QRadar can see an authority failure, a rogue SQL statement, a change to a system value, or any other critical security event in real time it can correlate that event with all of the others from across your Enterprise. It can evaluate its likely impact and compare it with other events to understand the severity of the event. Real-time monitoring is crucial for good security.

The default Device Support Module (DSM) provided by IBM QRadar provides for a periodic, batch view of basic IBM i security events. Because it is a batch process most IBM i users only collect security events once or twice a day. There is no real-time collection available and your QRadar implementation is not functioning as well as you might like.

Fortunately, it is really easy to fix this. Alliance LogAgent for IBM QRadar from Townsend Security helps you take the next step by providing that real-time monitoring for your IBM i server. Running in the background, Alliance LogAgent collects security events, converts them to IBM QRadar format, and transmits them to QRadar as they happen. Attempted hacks to your IBM i server are captured when they happen, not hours later. And QRadar sees them immediately. You get better security within a few minutes of installing Alliance LogAgent for IBM QRadar.

In addition to real-time monitoring, you also get these critical security functions that are not included in the default QRadar DSM for the IBM i:

• File Integrity Monitoring (FIM) for any DB2 database file on your system. You can monitor access to sensitive data on a field level.
• System history file (QHST) monitoring for critical messages and interactive logon and logoff activity.
• User data queue monitoring so that you can write your own security events from your RPG and CL applications.
• Exit Point monitoring so that you can monitor and record the host server activity and send the information to QRadar.

Active monitoring with IBM Security QRadar is one of the most important things you can do. Deploying Townsend Security’s Alliance LogAgent for IBM QRadar will make you more secure by making QRadar better. It’s affordable and easy to deploy. You can download a fully functional evaluation and see for yourself. Alliance LogAgent for IBM QRadar is certified by IBM and supported by the QRadar DSM.

That next step is not a big one, but it has big benefits.

Patrick

IBM i customers should be aware of a new security issue with IBM i Access for Windows version 7.1. This issue will affect a large number of IBM i users as Access for Windows is very commonly used by IBM i customers. US-CERT/NIST in the NVD database indicates this issue has a base score of 7.2 and an impact score of 10. This means that IBM i customers should give this issue attention as soon as possible.

• The vulnerability ID is CVE-2015-2023 and you can find the details here
• IBM provides a description of this issue on their website here
• A fix from IBM is available with Service Pack SI57907 and can be found here

If you are an IBM security administrator I recommend that you sign up for notifications on the NVD website. While the volume of IBM i issues is relatively small, they do occur from time to time and some of them are severe enough to warrant quick action. You can also review IBM i security notifications on the IBM i website here (but be sure to monitor the NVD site too).

Patrick