Townsend Security Data Privacy Blog

Web site and application data security can be greatly enhanced by encrypting sensitive data. An encryption strategy is only as good as the protection of the encryption keys. Poor protection for encryption keys will lead to compliance audit failures, regulatory failures, and brand damage due to poor security practices.

The following topics discuss how encryption and key management improves web application security:

Separation of Encryption Keys from Data
The separation of encryption keys from the data they protect is a core security best practice. Cybercriminals may steal sensitive data, but if that data is encrypted and the keys are not readily available, the data remains protected. The separation of keys from the data they protect is also fundamental to implementation of Separation of Duties and Dual Control. Townsend Security's Alliance Key Manager provides the mechanism by which keys are separated from the data they protect.

Separation of Duties
For critical systems, security is always improved by dividing responsibility among multiple administrators. In data protection, this concept means that people who have access to the data (users, DBAs, etc.) should not be the people who have access to the encryption keys. And the reverse is true. In order to achieve Separation of Duties you must separate the system, network, and database functions from the encryption key management functions. This is a core concept in PCI-DSS, HIPAA, GLBA/FFIEC, and other regulations. Alliance Key Manager provides for Separation of Duties by allowing different people to manage the web application data and the management of the encryption keys.

Dual Control
All critical business operations that can impact the health and existence of an organization should be managed with Dual Control. Dual Control means that it takes two individuals to perform the critical operation. Because encryption keys are the crucial secret that must be protected, Dual Control means that at least two people must authenticate to create and manage encryption keys. Alliance Key Manager implements Dual Control in the security console to meet this security best practice and regulatory requirement.

Limited Access
Security best practices require that as few people have access to encryption keys as possible to minimize the risk of loss. Be managing encryption keys in a key manager designed for this purpose, keys can be used by the applications that need them, but managed by a small number of security administrators. Alliance Key Manager allows you to grant access to only those security administrators who have the need to manage the encryption keys.

Secure Key Retrieval
Encryption keys and the Encryption Services available with Alliance Key Manager are always accessed via encrypted TLS connections. Secure connections help prevent capture of encryption keys across public and private networks, memory scraping routines, etc. Unencrypted access to Alliance Key Manager is not allowed.

Authenticated Key Retrieval
Unlike normal web servers which provide access to anyone with a certificate signed by a public certificate authority, Alliance Key Manager creates its own private CA unique to you, creates client-side certificates and private keys signed by that CA, and restricts access to only those clients who present a known certificate. This prevents outsiders from accessing the key server using publicly available certificates and keys.

Protection of Credentials
Because certificates and private keys are used as credentials for access to Alliance Key Manager, they must be protected in the Web application server. Credentials should be stored outside of the web root directory and access permission should only be granted to the web application user. For a Drupal installation, the same precautions should be taken.

Active Monitoring
Active monitoring is a core security requirement and applies to all encryption key management activity. Alliance Key Manager provides real-time audit and system logging off all key retrieval, encryption services, and key management tasks. This helps meet regulatory requirements and security best practices for all key management activity.

For more information on encryption, download the eBook:

VMware is hands-down the virtualization choice of large and small organizations. And it is easy to see why. Not only is it a highly reliable and scalable platform, but VMware provides a complete set of tools you need to deploy, manage, monitor, and protect virtual machines. And did I mention that it totally rocks the scalability challenge?

Let’s look at how VMware customers who run Microsoft SQL Server applications can enable encryption and key management to protect sensitive data and meet compliance regulations.

First Step:

We have to solve the encryption key management challenge. As we like to say around here, the hardest part of security is encryption, and the hardest part of encryption is key management. We have to store the encryption keys separate from the protected data, and use industry standard practices to protect them. With our Alliance Key Manager for VMware solution we make this problem easy to solve. Our key manager comes in a ready-to-deploy OVA format and VMware customers can just launch the key manager with standard VMware tools. Of course, there are some security best practices on how to properly deploy a security application like a key manager in VMware (see the resources section below). With Alliance Key Manager’s Ready-To-Use options you can have your VMware key management problem solved in just SECONDS.

Of course, some of our VMware customers want to protect encryption keys in traditional Hardware Security Modules (HSMs). No problem, Alliance Key Manager can be deployed as a rack-mounted HSM or as a vCloud instance.

The Second Step:

Now we want to enable encryption in SQL Server and protect the encryption keys with Alliance Key Manager. Thanks to Microsoft’s Extensible Key Management (EKM) interface, this is incredibly easy. Alliance Key Manager comes with EKM Provider software that plugs right into SQL Server to enable encryption and protect your encryption keys. We call this our Key Connection for SQL Server application and it installs on your SQL Server VMware instance using a standard MSI install process. Key Connection for SQL Server runs in all SQL Server environments including VMware, hardware, vCloud, and cloud platforms so hybrid environments are fully supported. Install the credentials, select the SQL Server instances you want to protect, answer some questions, type a few commands and you have a fully protected SQL Server database using Transparent Data Encryption (TDE). Again, this takes just minutes to accomplish.

SQL Server also supports column level encryption, which Microsoft calls Cell Level Encryption. It can provide better performance for some SQL Server databases. Yes, that’s also supported through the same Key Connection for SQL Server software.

The beauty of the Microsoft EKM architecture is that you don’t need to modify your SQL Server applications to deploy encryption. Your DBA and security team can get your data protected very quickly without a development project. Anybody got budget for that these days?

Hint

Already encrypting SQL Server but aren’t protecting your encryption key? That’s easy – you can install Key Connection for SQL Server, issue a few commands, and the problem is solved!

The Third Step:

What about high availability, business recovery, clustered configurations, and system logs? We’ve got all of that covered, too. Using the same Key Connection for SQL Server EKM Provider (did I mention that it’s free?) you can configure one or more secondary key servers that function as high availability failover servers for business recovery? Key Connection for SQL Server will automatically failover to secondary key servers if the primary key server is unavailable.

Alliance Key Manager also fits nicely into your active monitoring strategy. You can easily enable forwarding of all key access, key management, encryption, and system activity logs to your log collection server or SIEM solution.

Celebrate Victory and Do It Again!

Alliance Key Manager protects Oracle, IBM, MySQL and other databases as well as web applications and unstructured data. You get to deploy one key management solution to protect everything. And do you know how much it will cost you to do your next project? Nothing, zilch, zed, nada! Alliance Key Manager does not force you to license and pay for client-side applications.

Hint

I’ll talk more in future posts about how to protect other databases and applications in VMware environments. Stay tuned if you run SharePoint, Microsoft CRM or ERP applications, Oracle, or open source databases like MySQL and SQLite.

How Much Better Can This Get?

You can evaluate Alliance Key Manager and Key Connection for SQL Server in your own VMware environment free of charge. Just visit our Alliance Key Manager for SQL Server page and request a free 30-day evaluation.

Encryption and key management? We can get this done right!

Resources:

PCI SSC Virtualization Guidelines

VMware Solution Guide for Payment Card Industry (PCI)

Securing Alliance Key Manager for VMwar

Alliance Key Manager for VMware Solution Brief

Today was one of the most inspiring days of my life.

Tim Cook’s beautiful and courageous and inspiring coming out as a gay person will be noted as one of the significant events of our lifetimes. In one simple act Tim Cook took Apple Computer from a company that makes wonderful things, to a wonderful company; from a company known for its ability to make stuff, to a company known for its ability to inspire and lead humanity. He blazed a path for all of us, and changed how we will relate to the LGBT community forever. It was a beautiful and courageous act in itself, and it advanced us all towards a more humane, towards a more morally sane, future.

We are all deeply in Tim Cook’s debt.

We should not forget that behind every CEO is a board of directors, and a management team, and a large group of employees. Let’s recognize that every part of Apple Computer stands behind Tim Cook today. No one works alone, or leads alone, or can succeed alone. This was truly a day for everyone at Apple Computer to be proud of.

We honor you all.

Apple didn’t invent cool, but under Steve Jobs they came to make the most cool stuff. And they appropriated coolness as a part of their brand. Now, for the first time, with Tim Cook’s leadership, they really ARE cool.

It’s not what you make, it’s who you are.

Good Lord, for the first time in a long time I just want to buy something that Apple makes.

Well done Tim Cook, and well done everyone at Apple! This day belongs to you.

Patrick

The academic cryptographic community has been very inventive lately and we are seeing some promising new encryption technologies start to emerge. Format preserving encryption is moving through a standards track at the National Institute of Standards and Technology (NIST) and I think we will see one or more of the proposed FFX modes of encryption achieve standards status soon.

Homomorphic encryption is also a promising encryption approach that allows for various operations on encrypted (ciphertext) values without having to first decrypt the value. That’s pretty cool. There are a number of cryptographers working on approaches to homomorphic encryption, but at this point there is no clear consensus on the right approach. I suspect that some consensus on the best approach will emerge, but it may take some time for this to happen. Cryptography is hard, and it needs time for proper examination and analysis of both mathematical and implementation strengths and weaknesses before its adoption in commercial systems. We need to give the cryptographic community time to do their work.

If homomorphic encryption is cool, why not use it?

It has not achieved wide review and acceptance
While there is promising work on homomorphic encryption, there is no clear consensus on the best method or implementation approach. Typically a new cryptographic method will not get a full review from the cryptographic community until there is some consensus, and not until a standards body takes up the new method in a formal review process. There are a large number of potentially good encryption methods that have been thoroughly reviewed by the professional cryptographic community but which have not achieved the status of an approved standard.

Homomorphic encryption has not yet been through this process and it is too early to trust any current proposals or implementations.

It is not a standard
Standards are important in the encryption world. Standard encryption algorithms receive the full scrutiny of the professional cryptographic community and we all benefit from this. Weaknesses are discovered much faster, weak implementations are identified, and we all have much more confidence in encryption based on standards. The Advanced Encryption Standard (AES) has stood the test of time since its adoption by NIST in 2001.

Homomorphic encryption has not yet achieved the status of an accepted and published standard.

Note: Mathematical proofs do not a standard make. They are required as a part of the standards review and adoption process, but mathematical proofs alone do not rise to a level of an accepted standard. Claims to the contrary are false.

It cannot be certified by a standards body
Since homomorphic encryption is not a standard, there is no independent standards body process to validate a vendor’s implementation. This is important - in an early study by NIST of encryption solutions submitted for validation, nearly 37% of the solutions contained errors in the implementation and failed validation. The failure rate for implementations of homomorphic encryption are likely as high and unknowable. All serious vendors of encryption technology have validated their AES implementations to FIPS 197 standard through the NIST AES validation process.

No such similar standards validation process exists for homographic encryption.

It cannot achieve FIPS 140-2 validation
Encryption key management solutions are cryptographic modules and can be validated to the FIPS 140-2 standard. NIST has established a validation process through a number of chartered test labs. All serious vendors of encryption and key management solutions validate their products through this process. One of the first steps in key management FIPS 140-2 validation is validation of the encryption methods used by the key manager. The approved encryption methods are documented in Annex A of FIPS 140-2.

Homomorphic encryption is not an approved encryption method and cannot be validated to FIPS 140-2 at this point. Any representation that homomorphic encryption or key management systems implemented with it are “FIPS 140-2 compliant” is false.

Intellectual property claims are not resolved
Organizations large and small are rightfully concerned about violating patents and other intellectual property claims on information technology. At the present time there are multiple vendors claiming patents on homomorphic encryption techniques. Most encryption methods that have been adopted as standards are free of these types of IP claims, but homomorphic encryption is not free of them.

Organizations would be wise to be cautious about deploying homomorphic encryption until the patent and intellectual property issues are clearer.

Compliance regulations prohibit its use
Many compliance regulations such as PCI-DSS, HIPAA/HITECH, FISMA, and others are clear that only encryption based on industry standards meet minimal requirements. Standards bodies such as NIST, ISO, and ANSI have published standards for a variety of encryption methods including the Advanced Encryption Standard (AES).

Homomorphic encryption is not a standard and it is difficult to imagine that it could meet the minimum requirements of these and other compliance regulations.

Summary
Homomorphic encryption is a promising new cryptographic method and I hope that we will continue to see the cryptographic community work on it, and that we will see its future adoption by standards bodies with a proper validation processes. We just aren’t there yet.

Amazon Web Services is a deep and rich cloud platform supporting a wide variety of operating systems, AWS services, and third party applications and services. It is a bewildering array of capabilities with lots of places to store sensitive data. Let’s explore some of the ways that our Alliance Key Manager solution helps AWS customers and partners protect this data. This is a bird’s eye view, and we’ll dive into this in more depth in future blogs:

Amazon AWS Services

Amazon Relational Database Service (RDS)
Alliance Key Manager provides encryption key retrieval and an on-device encryption service to make it easy for your applications to encrypt data in RDS. Townsend Security SDKs can easily be used to provide encryption at the application layer.

Amazon Simple Storage Service (S3)
Alliance Key Manager lets you retrieve 256-bit AES keys in Base64 encoded format ready for use with RDS customer supplied encryption key services. You can easily deploy an AKM dedicated key management service to support encrypting and decrypting files in S3 storage.

Amazon Elastic Block Storage
Amazon Machine Instances (AMIs) provide access to EBS for simple unstructured storage requirements. Townsend Security SDKs can easily be used to provide encryption at the application layer.

Amazon DynamoDB (NoSQL)
The AWS NoSQL implementation does not provide encryption services, but you can easily implement encryption at the application layer using the Townsend Security SDKs. With support for many programming languages you can implement the encryption and key management services you need to meet compliance regulations.

Application Databases:

Microsoft SQL Server
Alliance Key Manager includes a license for Townsend Security’s Key Connection for SQL Server application that supports Transparent Data Encryption (TDE) and Cell Level Encryption for Enterprise edition. This EKM provider installs in your Windows SQL Server environment and enables encryption without any programming. For SQL Server Standard and Web Editions Alliance Key Manager includes a license for the Townsend Security Windows Client for snap-in encryption support.

Oracle Database
Oracle Database encryption support is provided through SDKs that are free of charge with Alliance Key Manager. Java, Perl, PHP, Python, Ruby and C# SDKs and sample code enable rapid deployment of encryption in Oracle environments. Sample PL/SQL code is also available for Oracle Linux platforms.

MySQL, SQLite, PostgreSQL, etc.
Open source database encryption support is provided through SDKs that are free of charge with Alliance Key Manager. Java, Perl, PHP, Python, Ruby and C# SDKs and sample code enable rapid deployment of encryption in these environments.

Software SDKs for Amazon Web Services:

A rich set of application SDKs are available for many programming languages. These SDKs provide support for Java, Microsoft .NET languages (C#, VB.NET, etc.), Perl, Ruby, Python, PHP, and others. These SDKs are provided at no charge to Alliance Key Manager customers.

Application Plugins for Amazon Web Services:

Drupal Encryption and Key Management
Alliance Key Manager integrates naturally with the Drupal web CMS using the Drupal Encrypt module and Townsend Security’s Key Connection for Drupal module available on Drupal.org. Drupal users can retrieve encryption keys for use with local encryption, or use the Alliance Key Manager Encryption Service to encrypt and decrypt data in the key manager with NIST-validated AES encryption.

SQL Server Transparent Data Encryption
Alliance Key Manager integrates directly into the Microsoft SQL Server Enterprise edition database to provide Transparent Data Encryption (TDE) support using the Townsend Security Key Connection for SQL Server application.

SQL Server Cell Level Encryption
Alliance Key Manager integrates directly into the Microsoft SQL Server Enterprise edition database to provide Cell Level Encryption support using the Townsend Security Key Connection for SQL Server application.

Security is the biggest barrier to cloud adoption, and encryption of sensitive data is the hardest part of security. Once you decide to encrypt your sensitive data, getting encryption key management right is the biggest challenge. Storing an encryption key in the same cloud instance with the protected data is faux security, and won’t pass the sniff test in any audit or review of security best practices. So, where do you store the encryption keys?

In Amazon Web Services (AWS), you now have a new key management option that perfectly fits the AWS architecture and usage model, enables security best practices such as Separation of Duties and Dual Control, and provably meets industry standards such as FIPS 140-2.

Alliance Key Manager for AWS extends our Cloud Service Provider support to the popular Amazon platform alongside our existing cloud support for Microsoft Azure, IBM Cloud, and VMware vSphere cloud platforms. For cloud users who need dedicated key management HSMs, our existing Alliance Key Manager Cloud HSM solution will serve AWS customers.

Alliance Key Manager for AWS uses the same FIPS 140-2 compliant technology as our network-attached hardware security module (HSM) solution. You can deploy the Alliance Key Manager AMI directly from the AWS Marketplace, and have a functional encryption key management solution dedicated to you and ready to use in SECONDS with an automatic 30-day evaluation license. You do not share any part of your key management with anyone else, and you have exclusive management of encryption keys. There is no aspect of key management administration that is under the control of Townsend Security, the cloud provider, or anyone else. There is no part of your encryption key that is shared with Townsend Security, and no dependence on any encryption service outside of your key management AMI.

Customers who register with Townsend Security get access to our encryption applications, SDKs, customer support, extended documentation, developer program, and optional Premium support. It’s the perfect AWS key management solution for both small organizations and large enterprises who want to deploy an affordable key management solution based on industry standards and certifications.

In addition to traditional key management, Alliance Key Manager for AWS implements Encryption-as-a-Service. You don’t have to retrieve an encryption key, perform encryption in your application, and then zero the encryption key. To minimize the chance of exposing the encryption key to loss, you can directly send data to the key manager and have it encrypted and returned to your applications. You leverage Alliance Key Manager’s NIST-validated AES encryption and the key never leaves the key manager.

Until now Amazon Web Service customers had no access to simple, affordable, and compliant encryption key management solutions. All of that has changed with Alliance Key Manager for AWS.

Enjoy.

Patrick

Security can be hard, expensive, complicated, aggravating, confusing, and did I mention expensive?

As a security company, we hear this perception from new customers all the time. But there is one thing you can do for your IBM i that breaks all of these stereotypes. You can get an immediate boost in system security without much expense and without a big headache. And your users are already using this security technique on their favorite web sites.

Increase Security with Two Factor Authentication (2FA)

Almost every day a phishing email gets through our spam filters and lands in my inbox. Some of these emails are very nicely crafted and look like the real thing. The graphics are professional, the English is excellent and matches my expectations. The terminology is appropriate. Really nice work. And the links in the email are pure poison. Just waiting for that unsuspecting click to start installing malware on my PC to capture my IBM i user profile and password information.

Yup, that’s how it started at Target.

The great thing about Two Factor Authentication is that it gives businesses a lot of additional security for very little upfront cost. The aggravation factor has almost gone away. You no longer need large, expensive servers and tokens that always seem to get lost at just the wrong time. Your IBM i can do exactly what Google, Yahoo, Facebook, your bank, and many other Internet companies are doing to make security better. And your users already have the device they need - their mobile phone!

Alliance Two Factor Authentication uses the same network services and infrastructure that the big boys use for 2FA. This security solution leverages the Telesign global network to deliver PIN codes right to your mobile phone. No servers to rack up and maintain. No lost tokens.

I know, you have some reservations:

I don’t always have signal to my cell phone.

That’s OK, just send the PIN code to your voice phone. A nice lady will read you the code.

I’m in a hurry, I can’t wait for a PIN code.

PIN codes are often delivered in under a second. If you’ve got a mobile provider with a slow network, just have the PIN code delivered to your mobile phone as a voice call.

I left my cell phone home!

Right, just use one of your One Time Codes. No phone of any kind needed!

My IBM i is in Restricted State, it won’t work for me.

Alliance Two Factor Authentication does work in restricted state with a couple of steps.

I don’t want to have to enter a PIN code every time I log on, that’s just way too much work.

Don’t worry, your security administrator can configure Alliance Two Factor Authentication to only ask you once a day to authenticate, or at a user-defined interval. And if an attacker tries to access the IBM i from another device or IP address, they will have to authenticate. And that’s going to be hard to do when you have your mobile phone in your possession.

We’ve made Alliance Two Factor Authentication easy to evaluate and deploy on your IBM i. You can request a free 30-day evaluation from our web site and be up and running within an hour. You can start slowly with a few users, and then roll it out to everyone in your organization. They’ll get it right away.

You don’t have to be the next Target. Get cracking (so to speak).

Patrick

Public and private organizations want to take advantage of cloud-based solutions to reduce costs and improve business performance. Organizations understand that the ultimate responsibility for the security of their data remains with them. Justifiable concerns about the security of cloud-based applications continue to worry security professionals and business executives.

The following list of nine guidelines is intended to serve as a baseline indicator of the maturity and adequacy of the security of a cloud platform and cloud application offering. They are not intended to be exhaustive, but only serve as a set of key indicators. Additional security review of any cloud provider and cloud application should be performed before deployment or migration.

Security professionals (CIOs, CISOs, compliance officers, auditors, etc.) and business executives can use the following set of key indicators as a way to quickly assess the security posture of a prospective cloud provider and cloud-based application or service. Significant failures or gaps in these nine areas should be a cause for concern and suggest the need for a more extensive security review.

The sources for these guidelines include the Cloud Security Alliance, Payment Card Industry Data Security Standards (PCI DSS), the National Institute of Standards and Technology (NIST), the SANS Institute, and others.

The nine key indicators:

1) Inventory of Sensitive Data

All sensitive data processed and stored by the cloud application and service should be properly inventoried and published to stakeholders. Data retention policies should be published for all sensitive data.

2) Data Protection

The use of industry standard encryption for data at rest should be implemented for all sensitive information such social security numbers, credit card numbers, email addresses, and all other personally identifiable information. Encryption keys used to encrypt sensitive data should be protected by appropriately strong key encryption keys, and encryption keys should be stored away from the sensitive data and managed according to industry best practices (separation of duties, dual control, split knowledge, key rotation, etc.). Minimally, encryption key management systems should be validated to the FIPS 140-2 standard.

3) Business Continuity Plan

The cloud and application providers should have a published business continuity plan (BCP) that meets the minimum baseline needs of your organization. The business continuity plan should address backup and recovery, geographic redundancy, network resilience, storage redundancy and resilience, and other common components of a BCP.

4) Incident Response Plan

Both the cloud provider and the application provider should have a current incident response plan available to stakeholders. The plan should cover how incidents are discovered, the response plan for breaches, staff training, and management. All stakeholders should understand that security events are a matter of “when”, not “if”.

5) Active Monitoring

Actively monitoring of all aspects of the cloud and application environment is a core security principal. Real time log collection and monitoring is a minimum component of active monitoring. Additionally application and operating system configuration changes and access to decrypted sensitive data should be monitored (File Integrity Monitoring). Cloud provider infrastructure monitoring should be in place as well as stakeholder access to critical event information.

6) Multi-tenancy Data Isolation

Cloud-based applications and services inherently share computing resources across multiple customers. Proper segregation of your data from other customers using the application is crucial for your security posture. The cloud and application provider should provide credible assurance that there is adequate logical or physical separation of your data from all others sharing computing resources.

7) Vulnerability Assessment and Penetration Testing

Periodic vulnerability and penetration testing should be performed on the cloud provider infrastructure as well as the application environment. Any identified weaknesses should be addressed in a timely manner and disclosed to you and other stakeholders.

8) Independent Security Assessment

The cloud provider’s infrastructure used to host the application should be independently assessed for security compliance and best practices on a periodic basis, and no less than annually. The results should be available to you and other stakeholders. Examples would include SOC 2, SOC 3, SSAE 16, PCI assessment and letter of attestation, etc.

9) Contractual and Legal

Cloud and application providers should provide you with proper legal agreements including a Service Level Agreement (SLA) that defines mutual obligations. Be sure that you understand where you data will be stored and processed and that you understand geographic boundary controls. Additionally, be sure that the agreement between you and your cloud and application provider apply to any third parties who may have access to your data, or who may take possession of your data. Lastly, be sure that you receive prior notification before your data is released to law enforcement or any other governmental agency.

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

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

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

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

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

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

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

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

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

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

Patrick

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

What are the core requirements for active monitoring and what are the special challenges for the IBM i platform? Some core requirements include:

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

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

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

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

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

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

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

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

 
Patrick