Townsend Security Data Privacy Blog

The OpenSSL Heartbleed security vulnerability is arguably the biggest security exposure in the history of the Internet. While IBM i (AS/400, iSeries) customers may be somewhat isolated from the larger impacts of this vulnerability, there are good reasons not to take this event lightly.

First, a disclaimer: Only IBM can comment in a definitive way on any Heartbleed vulnerabilities in the IBM i. The following are my opinions based on several years of work on the platform.

[UPDATE: IBM has issued a Security Bulletin stating that the IBM i is not effected by CVE-2014-0160 (Heartbleed)]

The first important fact to know is that OpenSSL is not commonly used in traditional IBM i network applications. IBM has an SSL/TLS library named GSKit and a certificate management application named Digital Certificate Manager. The underlying secure TLS implementation is not based on OpenSSL for these IBM-supplied applications. They probably do not pose a security issue for IBM i customers.

IBM does use OpenSSL in some of their IBM i open source applications. For example, the SSH implementation on the IBM uses OpenSSL. On a V7R1 system I started an SSH session and looked at the output:

OpenSSH_4.7p1, OpenSSL 0.9.8m 25 Feb 2010OpenSSH_4.7p1, OpenSSL 0.9.8m 25 Feb 2010

As you can see in the first log message, OpenSSL version 0.9.8m is used in SSH. Fortunately this version of OpenSSL is not vulnerable to Heartbleed. You should check your implementations of SSH, Apache, Websphere, Perl, PHP, and other open source applications to verify that they do not use a version of OpenSSL with the Heartbleed vulnerability.

Most third party vendors use the IBM i SSL/TLS library for secure communications. These applications will not be vulnerable to this new Heartbleed issue. All of the Townsend Security applications are based on the IBM library and not on OpenSSL. However, there are third party IBM i applications that embed OpenSSL or which use the OpenSSL application in the PASE environment. You should immediately contact your application vendors to determine if there are any exposures in their applications.

It is important to understand that while the IBM i platform may not be directly vulnerable to the Heartbleed problem, you may have lost IBM i User IDs and passwords over VPN or other connections which are vulnerable. An exploit of Heartbleed can expose any information that you thought was being protected with session encryption.

Once you know that your IBM i and all of your network services are patched or are not vulnerable to Heartbleed, you should immediately force a password change for all of your users. Don’t take a chance on missing this vulnerability at some point in your network infrastructure and exposing your IBM i data to loss.

Patrick

Security researchers have discovered a vulnerability in certain versions of the very popular OpenSSL application that can lead to the loss of critical sensitive information. The vulnerability is called Heartbleed because if affects the TLS heartbeat function in secure, connections. Because OpenSSL is used by so many web applications, and because this vulnerability can be exploited, the severity is very high.

Townsend Security does not use the affected version of OpenSSL for TLS session security in any of its products, and is not affected by the Heartbleed vulnerability.

For more information about the Heartbleed security vulnerability and what you can do, please visit the following site:

http://heartbleed.com/

While Townsend Security applications are not subject to this vulnerability, it is very important that you address other applications that are vulnerable. The loss of sensitive information in one application can lead to the compromise of an otherwise unaffected application. For example, the loss of passwords in one application can lead to the compromise of another application if the same password is used. And personally identifiable information lost from one application can be used for fraudulent impersonation in another application or web service.

Patrick

Securing data with encryption and protecting the encryption keys with proper key management is addressed in many compliance regulations and security best practices.

For Drupal developers who need to protect sensitive data in their (or their clients) content management system (CMS), storing the encryption keys within the Drupal CMS puts that data at risk for a breach. Security best practices and PCI DSS compliance regulations call for sensitive data to be protected with encryption and that data-encrypting keys (DEK) be physically or logically separated from the sensitive data and protected with strong key-encrypting keys (KEK).  Depending on what type of information is being stored and what industry guidance your project/company falls under, compliance regulations in addition to PCI DSS may apply.

For any company that accepts credit card payments, the Payment Card Industry Data Security Standards (PCI DSS) issues 12 requirements that must be met in order to be compliant. It can seem overwhelming at first, but the PCI council that issues PCI DSS also provides detailed reference guides and instructions on each requirement. Let’s take a high level look at all twelve items:

Build and Maintain a Secure Network and Systems

Requirement 1: Install and maintain a firewall configuration to protect cardholder data
Requirement 2: Do Not use vendor-supplied defaults for system passwords and other security parameters

Protect Cardholder Data

Requirement 3: Protect stored cardholder data*
Requirement 4: Encrypt transmission of cardholder data across open, public networks

Maintain a Vulnerability Management Program

Requirement 5: Protect all systems against malware and regularly update anti-virus software or programs
Requirement 6: Develop and maintain secure systems and applications

Implement Strong Access Control Measures

Requirement 7: Restrict access to cardholder data by business need-to-know
Requirement 8: Identify and authenticate access to system components
Requirement 9: Restrict physical access to cardholder data

Regularly Monitor and Test Networks

Requirement 10: Track and monitor all access to network resources and cardholder data
Requirement 11: Regularly test security systems and processes

Maintain an Information Security Policy

Requirement 12: Maintain a policy that address information security for all personnel

Within the latest documentation by the PCI Security Standards Council (v3.0 released November 2013) specific testing procedures and guidance is given for Requirement 3 on pages 34-43. The PCI Security Standards Council (PCI SSC) website contains this documentation along with a number of additional resources to assist organizations with their PCI DSS assessments and validations. PCI SSC also issues Cloud Computing Guidelines and additional information around virtualization of data protection solutions so you can be PCI compliant with a cloud-based solution for encryption and key management.

Requirement 3 addresses the need for encryption and key management, stating:

“Protection methods such as encryption, truncation, masking, and hashing are critical components of cardholder data protection. If an intruder circumvents other security controls and gains access to encrypted data, without the proper cryptographic keys, the data is unreadable and unusable to that person. Other effective methods of protecting stored data should also be considered as potential risk mitigation opportunities. For example, methods for minimizing risk include not storing cardholder data unless absolutely necessary, truncating cardholder data if full PAN is not needed, and not sending unprotected PANs using end-user messaging technologies, such as e-mail and instant messaging.”

In order to address PCI DSS Requirement 3: Protect stored cardholder data; the security experts at Townsend Security partnered with Chris Teitzel, CEO of Cellar Door Media and Drupal developer to create Key Connection for Drupal in connection with the existing Drupal Encrypt module. In order to provide secure key storage and retrieval options, Key Connection for Drupal provides a secure key management system (Alliance Key Manager) outside of the Drupal installation. Now when cardholder information is collected or stored in a database it can easily be encrypted and the encryption keys properly managed. Key Connection for Drupal allows developers and users to choose whether they need to retrieve a key and encrypt/decrypt locally or to send the data to Alliance Key Manager to perform on board encryption.

Other compliance requirements for protecting information go beyond cardholder data (PCI focuses on PAN or the Primary Account Number specifically) and also require that personally identifiable information (PII) such as names, birthdates, email address, zip codes, usernames, or passwords be protected with encryption and key management. Check back as future blogs will cover additional data privacy compliance regulations and security best practices that impact developers and users of the Drupal CMS open source platform in regards to protected health information (PHI).

For more information on PCI Compliance, download the Whitepaper: "Meet the Challenges of PCI Compliance"

Two Factor Authentication (2FA) and a look at the compliance regulations that require identity verification for remote access.

The use of two factor authentication provides an added layer of security beyond just a username and password. Because passwords can be guessed, stolen, hacked, or given away, they are a weak layer of security if used alone. Since frequent access happens from outside of the network, remote login is considered high-risk and requires additional steps to confirm user identity. Protecting access with two factor authentication adds identity assurance and significantly reduces risk of unauthorized access in the retail, healthcare, and financial industries.

Payment Card Industry Data Security Standards (PCI DSS)

The PCI Security Standards Council has stated that they will continue to change and evolve compliance regulations over time as attacks change. In PCI DSS section 8.3 the requirement states that organizations must “incorporate two factor authentication for remote access (network-level access originating from outside the network) to the network by employees, administrators, and third parties.”  The objective of this requirement is to ensure that merchants implement strong access control measures so that authorized individuals with network and computer access can be identified, monitored, and traced.

Requirement 8: Assign a unique ID to each person with computer access. Assigning a unique identification (ID) to each person with access ensures that each individual is uniquely accountable for his or her actions. When such accountability is in place, actions taken on critical data and systems are performed by, and can be traced to, known and authorized users.

Note: These requirements are applicable for all accounts, including point-of-sale accounts, with administrative capabilities and all accounts used to view or access cardholder data or to access systems with cardholder data.

Requirement 8.3: Incorporate two factor authentication for remote access (network-level access originating from outside the network) to the network by employees, administrators, and third parties.

Note: Two factor authentication requires that two of the three authentication methods (something you know - something you have - something you are) be used for authentication. Using one factor twice (for example, using two separate passwords) is not considered two factor authentication.

Health Insurance Portability and Accountability Act (HIPAA) and the Health Information Technology for Economic and Clinical Health (HITECH) Act

HIPAA was an act signed in 1996 by President Bill Clinton, meant to improve the efficiency of the healthcare system by encouraging the use of Electronic Data Interchange (EDI) when accessing Protected Health Information (PHI). Covered entities must develop and implement policies and procedures for authorizing PHI access in accordance with the HIPAA Security Rule Administrative Safeguards 164.308(a)(4) [Information Access Management: Access Authorization] and Technical Safeguards 164.312(d) [Person or Entity Authentication] and the HIPAA Privacy Rule at §164.508 [Uses and disclosures for which an authorization is required].

The HIPAA Security Rule requirements have most recently been expanded via the HITECH Act, which establishes mandatory federal security breach reporting requirements with expanded criminal and civil penalties for non-compliance. To remain HIPAA compliant and avoid fines for HITECH Act non-compliance, strict control over access to patient records must be demonstrated.

HIPAA/HITECH requirements regarding the transmission of health-related information include adequate encryption [164.312(e)(2)(ii) when appropriate, and 164.312(a)(2)(iv)], authentication [164.312(d)] or unique user identification [164.312(a)(2)(i)] of communication partners. By selecting Two Factor Authentication (2FA), users would be required to combine something they know, something they have, or something they are; thereby providing more secure access to PHI files. Protected Health Information can be account numbers, medical record numbers and geographic indicators among other private consumer information. It is important that only those health care workforce members who have been trained and have proper authorization are granted access to PHI.

Gramm-Leach-Bliley Act (GLBA) & Federal Financial Institutions Examination Council (FFIEC)

The Federal Financial Institutions Examination Council (FFIEC) is charged with providing specific guidelines for evaluating financial institutions for GLBA (Gramm-Leach-Bliley Act) regulations compliance. The FFIEC also provides guidance around the use of two factor authentication to strengthen systems in the financial industry and strengthen banking websites against financial fraud with the document, “Authentication in an Internet Banking Environment” (v.3). For banks offering internet-based financial services, the guidance document describes enhanced authentication methods that regulators expect banks to use when authenticating the identity of customers using online products and services, as follows:

• Financial institutions offering internet-based products and services to their customers should use effective methods to authenticate the identity of customers using those products and services. Furthermore, the FFIEC considers single-factor authentication (as the only control mechanism) to be inadequate for high-risk transactions involving access to customer information or the movement of funds to other parties.
• The implementation of appropriate authentication methodologies should start with an assessment of the risk posed by the institutions’ Internet banking systems. The authentication techniques employed by the financial institution should be appropriate to the risks associated with those products and services.
• Account fraud and identity theft are frequently the result of single-factor (e.g. ID/password) authentication exploitation.
• Where risk assessments indicate that the use of single factor authentication is inadequate, financial institutions should implement multi-factor authentication, layered security, or other controls reasonably calculated to mitigate those risks.

The FFIEC is a government agency which works with many other government agencies to unify how financial institutions should be supervised. The guideline documents recommend banks treat the FFIEC as baseline compliance for safe online authentication and transaction verification. Since all single factor authentication techniques can be easily compromised, financial institutions should not rely solely on any single control for authorizing high risk transactions, but rather institute a system of layered security with multi-factor authentication.

Although there are varying levels of enforcement, guidelines vs. laws vs. fines, it is clear that two factor authentication plays a critical security role in both compliance and following best practices. This trend will only grow within various industries and throughout the overall data security environment.

Townsend Security offers Easy to Deploy, Cost Effective Two Factor Authentication Solution for the IBM i Platform

Alliance Two Factor Authentication brings mobile SMS and voice verification to the IBM i platform. The solution was built to solve large scale problems in a cost-effective manner and appropriately addresses the concerns raised in the various guidelines and standards listed above. Remote access to networks containing critical payment, patient information, or financial records can be protected with the Alliance 2FA solution using your mobile phone to receive authentication codes.

For more information, request our 2FA Resource Kit! 

In light of the recent, massive Target data breach, and the fact that Target had passed a PCI DSS audit yet lacked proper security controls, many organizations are searching for stronger data security. Using encryption to protect sensitive data should be considered a top priority for organizations that want to protect themselves from a potential data breach. Strong, defensible encryption used in conjunction with strong key management and a system logging solution can enable a business to catch a breach in real time when it happens, and know that any sensitive data that has been accessed is undecipherable by the attacker. Even with sophisticated and expensive malware detection software, the only way to secure the breach and avoid breach notification is with encryption and encryption key management.

Few organizations are aware of the extreme criticality of encryption and key management, and for the ones that are aware, many still consider encryption a last-effort solution and grapple with its reputation for being difficult and costly. Encryption and encryption key management can be difficult and costly; however, it doesn’t need to be. Different encryption key management vendors offer varying features and applications as well as pricing structures, and finding a solution that can integrate easily into your IT infrastructure is an achievable task. The key is to look for specific features that increase ease of use while decreasing costs.

1. Easy to use client side applications - A security expert and developer once said to me, “People say a lot of things aren’t ‘rocket science,’ but encryption key management is like ‘rocket science’. This is why businesses very rarely develop their own encryption and key management solutions internally. How easy an encryption key management vendor makes their solution to use is a major factor of a purchasing decision. If encryption is going to become as widely used as it needs to be, the client-side applications that manage encryption keys must be usable and intuitive to the average security administrator.
2. Scalable pricing structure - Scalability results in affordability. Not every company can invest in millions of dollars of malware detection and security consultants, and we’ve found out that the companies who can afford those services still have data breaches. Data breaches don’t discriminate, which is why encryption and key management solutions must be affordable for organizations, regardless of size. Five years ago, the only encryption key management solutions available were very expensive hardware solutions. Many vendors charge extra fees per network connection, which is neither an easy or scalable solution for companies that are growing. These hardware security modules (HSMs) are still widely used and preferred by businesses with a low tolerance for security risk, but many are turning to newer cloud solutions that offer the same certified technology with a lower price tag.
3. Cloud compatibility - Moving applications and data centers to the cloud is a natural step for organizations attempting to consolidate their IT infrastructures and lower operational costs. Security, however, remains the number one concerned for the cloud--a multi-tenant environment that shares resources with other users. Encryption and key management is essential to protecting any sensitive data processed or stored cloud applications or databases, and cloud-based or hosted solutions are readily available. Just remember that your key management solution must be FIPS 140-2 compliant and not share services with other users in order to be compliant with most data security regulations.

Encryption and encryption key management are essential, proactive technologies that help organizations remain intact in the event of a data breach. Look for these three features in a certified solution to protect yourself and your customers.

Townsend Security’s FIPS 140-2 compliant “one-click” ready-to-use key management solutions enable cloud users to easily protect their data in the cloud or data center at an affordable price. Learn more by viewing the webinar, “Encryption & Key Management Everywhere Your Data Is,” featuring data security expert Patrick Townsend.

As we discussed in the webinar and latest blog on Encryption & Key Management Everywhere You Need It, sensitive data needs to be protected wherever it resides!  

Proper encryption & key management can help you meet compliance requirements, and improve your data security posture across multiple platforms or environments. After the webinar, we had a number of questions asked by attendees and answered by security expert Patrick Townsend. Here is a recap of that Q&A session:

Q: Is there any limit to the number of servers that I can hook up to your encryption key manager?

Patrick: There are no restrictions, and no license constraints on our encryption & key management solution. We don't meter or count the number of client-side platforms that connect to our Alliance Key Manager, so you can hook up as many client side applications, servers, and processors as you need to. This is one of the things I think is different about how we approach encryption and key management with our customers. We also know the applications you are running today may not be the applications you need to be running tomorrow and we really want you to deploy encryption to all your sensitive data and scale up when & where you need it.

Q: With the various platforms that I can deploy an encryption key manager in, how do I know which one is right for me?

Patrick: There are several factors that will come in to play when deciding where you deploy your key management:

Compliance regulations that you need to meet can be a factor in whether you deploy an Hardware Security Module (HSM) or a cloud HSM or a virtualized instance. If you are working with an auditor or going through a QSA audit, you'll want to have a conversation with them to understand their expectation from a compliance point of view around where you deploy your encryption key manager.

Risk tolerance will also come into play. You may have a security group within your organization with strong feelings about how to deploy encryption key management and how to mitigate risk. If you have large amounts of sensitive data to protect you might decide to deploy an HSM in your secure data center. If you're dealing with a very small amount of data and you do not process credit cards or personally identifiable information, your risk assessment may indicate a cloud deployment.

Budget is certainly always a factor to consider. It is important to consider the cost benefits of security however, we all understand that leaving our data in the clear is no longer an option. It is a matter of understanding your industry regulations and risk assessment, then deciding what encryption and key management to deploy.

While they are generally the most secure solution, Hardware Security Modules (HSMs) can be more expensive than a virtual environment, dedicated cloud instance, or virtual private cloud. Once you look at all the factors that affect your company, we will be there with the right solution that will work for your needs.

Q: Does Townsend Security provide guidance on how to get the best performance with my operating environment?

Patrick: Because every enterprise operational environment is different, we provide guidance around performance with our encryption key management solution. With every one of our solutions we offer complimentary 30-day product evaluations and encourage our customers to do proof of concepts with their applications. We are serious about making this process simple, and our customers can download the actual instance in evaluation mode, run it with their applications, test the actual solution, and truly evaluate performance in their specific environment. Performance metrics will be moderated by a number of factors within your specialized environment, your network, and your processing platform.

Q: I have data that needs to be encrypted in a cloud other than Amazon or Windows Azure, can your product help me with this?

Patrick: Yes, we can. First of all, following best practices, you want to keep your encryption keys separate from the data they are protecting. You may have data in a cloud platform, but choose to run your encryption key management solution in a different location or a virtual private cloud. Let’s say you want to run the key manager in a dedicated cloud HSM or even in your data center. Most top-tier cloud vendors truly support multiple environments for running key management, and we find that our solutions work well for customers who are running in the cloud.  We suggest you contact us and have a conversation about options and we can provide guidance about how to deploy a secure solution.

Q: How is Alliance Key Manager Priced?

Patrick:  We have a wide set of options for our customers, and are dedicated to helping find affordable solutions. We have perpetual license or subscription options for classic HSMs, Cloud HSM, and virtualized environments. Our cloud offerings are true usage-based subscriptions, so if you're used to deploying in Amazon Web Services or Windows Azure, our encryption & key management solutions will fit that same strategy for pricing.  

We really believe that the encryption should go everywhere you need it to go! Your key management should work across a wide set of application environments, and it must be affordable, so that we can all get where we need to be in terms of protecting sensitive data. Regardless of where your data is or what platform you are using, there's a solution that can work for you!

View the complete webinar - Encryption & Key Management Everywhere - to learn about:

• Deploying encryption and key management with an HSM, cloud HSM, virtual appliance or in the cloud
• How protecting data  properly is now easier and more affordable than ever
• Factors to consider when deciding which option is right for your organization
• What compliance regulations (PCI DSS etc.) say about the different options
• Challenges for applications running in the cloud or virtual environments

If you have further questions, please list them here in the comment section and we will be sure to get you an answer!

Wherever your sensitive data resides - client side applications, secure data centers, or in the cloud - Encrypt it!

“Sensitive data” is not just credit card numbers and expiration dates anymore.  Because of recent data breaches, we know that loyalty information like names, e-mail, physical addresses, phone numbers; personal data like birthdate, social security number... so much information today... now constitutes what we call personally identifiable information (PII) and must be properly protected with encryption no matter it is stored.

When it comes to protecting data, look to well-defined industry standards for an encryption algorithm that is reviewed and vetted by cryptographers around the world. Advanced Encryption Standard or AES is the most commonly used encryption algorithm to protect sensitive data. Validated by the National Institute of Standards and Technology (NIST), this standard is referenced in a wide variety of compliance regulations either as a requirement or as a recommendation. However, the AES algorithm is not the secret that we have to defend. Think of encryption as the lock that you put on your front door, and the encryption key is your house key. You don’t tape your house key right next to the lock when you leave in the morning, you take it with you and you protect it from loss or theft. Your unique encryption key is THE secret that you must protect, which can be accomplished using a secure, certified key management solution. Getting encryption key management right is in fact the biggest challenge customers and organizations run into when they start their encryption projects.

When you look at what it takes to properly protect sensitive data with encryption, you immediately find standards (NIST) & best practices for key management, and industry compliance regulations (PCI DSS, HIPAA/HITECH, FFIEC, and state privacy laws) that require proper key management. They all say the same thing: “Do Not Store the Encryption Key on the Same Server as the Encrypted Data”.

Encryption key management is a well-defined process with standards and best practices around managing encryption keys and a formal definition of the encryption key lifecycle.  

When an encryption key is first generated, or established, it may not be used for some time so it waits in a pre-activation status until it is being actively used.  The key will expire after use or based on a set definition and then will go into escrow after post-activation. After that period, the key is generally destroyed.

One way to destroy data is to destroy the encryption key that's protecting it, because if the key is not recoverable neither is that data. Auditors will want to know if you have a process for managing the encryption key through the entire lifecycle, and this is one of the things that a key management solution does for you in a provable way.  Beyond the encryption key lifecycle, the key management solution provides access controls for users and groups, in-depth audit trails and system logging with the ability to integrate across multiple platforms, and they must implement a mechanism for dual control and separation of duties to really meet compliance regulations as well as defensible security best practices.

It is also very important for an encryption key manager to provide the option of onboard encryption. The core function of the encryption key management solution is to generate, protect, and distribute encryption keys to authenticated users. If you have a web application or a more exposed cloud environment, retrieving an encryption key may seem risky to you in terms of having that key in your operating environment. With an onboard encryption solution you can send your data to the key manager, name a key, and get that data encrypted or decrypted strictly within the confines of that key management solution. Avoiding the risk of losing encryption keys in a more exposed environment is an important component in a compliance strategy.

Even 10 years ago, encryption key management solutions were very expensive specialized hardware devices and very difficult and time consuming projects. Thankfully, encryption and key management is no longer the development or cost headache it once was. Since IT infrastructures have become very complex environments using different technologies and platforms (60% of Microsoft SQL Server customers are also running Oracle someplace in the organization), a key management solution also needs to address these complexities and protect data wherever it may be. There are still hardware security modules (HSMs) and now there are new options for deployment of cloud-based HSMs, virtual appliances, and true cloud instances of encryption and key management.

Hardware Security Module (HSM) is a physical appliance or security device that is protected and tamper evident. Built for high resiliency and redundancy it has hot swappable rated disc drives, dual power supplies, dual network interfaces, and is deployed in your IT data center.

Cloud HSM is a physical appliance hosted in a secure cloud with real-time encryption key and access policy mirroring.  Dedicated HSMs are hosted in geographically dispersed data centers under an ITIL-based control environment and are independently validated for compliance against PCI DSS and SOC frameworks. No access is available to the cloud vendor or any unauthorized user.

Virtual Appliances are the exact same key management solution - the same binary software that runs inside the hardware HSM - available as a VMware instance.

In the Cloud - If you're running on Microsoft Windows Azure or vCloud, the encryption key manager can run as a true cloud instance in a standard cloud or deploy in a virtual private cloud for added data protection for sensitive applications.

Because encryption and key management is so important, we offer all of the options listed above as NIST validated and FIPS 140-2 compliant solutions. We also want to make sure encryption is available everywhere you need it, so at Townsend Security we have a very different philosophy and approach:

• We think that when you buy an encryption key manager, you should be able to easily deploy the solution, get all your encryption projects done properly, and have very affordable and predictable costs.

• We understand that we live in a world where budget matters to our customers, so we do not charge client-side fees.  

• We understand that IT resources are limited and have done a huge amount of work to make our solutions easy with out-of-the-box integrations, simplified deployments, and also provide along with our solution ready-made client-side applications, encryption libraries, source code samples, as well as SDKs for developers who need them to get their projects done very quickly.

To learn more about key management and how to properly encrypt sensitive data anywhere you store it, download our latest webinar featuring data security expert Patrick Townsend:

One of the big fears that companies have as they deploy encryption of sensitive data is that they might lose their encryption key and never be able to decrypt and recover their data. Having spent some of my career in IT management I certainly understand where this comes from. There is nothing like a corrupted backup to turn a good day into a bad one. The same is true if you lose your encryption key.

So how do we help make sure that our Alliance Key Manager solution running in Windows Azure protects you from this potential problem? Let’s look at all of the things we do in our key management solution, and the things you can do in Windows Azure:

Backup / Restore
The first line of defense is always to have a backup of your encryption keys and key access policies. Alliance Key Manager provides you with an option to securely back up your encryption keys, security policies, and server settings and to move this backup out of Windows Azure to your own secure storage. You can do a manual backup at any time, and you can automate the backups on a schedule that you define. You can even automate the transfer of the backups to an external FTP server using secure, encrypted transfer methods. Don’t have an FTP server to receive your backups? Don’t worry, we can provide you with one in our secure cloud facility.

Key and Policy Mirroring
The next line of defense is to implement real-time key and security policy mirroring from your primary Alliance Key Manager cloud instance to a failover key manager instance running in Windows Azure or to a key manager running outside of Windows Azure. Alliance Key Manager fully implements key mirroring over a secure, encrypted connection to one or more secondary key servers. The secondary key servers will contain exact copies of the encryption keys and their access policies, and will always be ready in the event your primary key server stops working. Alliance Key Manager supports Active-Active mirroring so that you will always have a full set of your encryption keys available to you even after a failover.

Windows Azure Availability Sets
Do you know about Windows Azure Availability Sets? This is a feature of Windows Azure to help you avoid unplanned outages due to failures of the cloud infrastructure or planned Windows Azure maintenance activities. We encourage our Windows Azure users to take advantage of Availability Sets when deploying a second Alliance Key Manager instance. It provides one more way to get the best reliability for your key management infrastructure in the Windows Azure cloud.

Mirroring Outside the Windows Azure Cloud
Lastly, if you are still worried about losing your encryption keys, you can always mirror the keys to a key manager located outside the Windows Azure cloud. You could mirror your keys to a physical key manager HSM located in your data center or the hosting provider of your choice. Or, you could mirror your encryption keys to a dedicated key manager in our cloud data center (see Alliance Key Manager Cloud HSM). Or, you can mirror your keys to a VMware or Hyper-V instance of Alliance Key Manager in your data center or the hosting provider of your choice.

Alliance Key Manager in Windows Azure goes the distance to help ensure that you never lose an encryption key. You might be losing sleep over your move to the cloud, but you shouldn’t lose sleep over your encryption strategy.

Patrick

With V7R1 IBM introduced FIELDPROC (field procedure) exit points which Alliance AES400 for IBM i uses to encrypt database files at a field level. Since the cryptographic process is called by the database directly upon access, rather than by the application, this means that the process will work regardless of what type of application uses it. No application changes are needed, which is something our customers really like to hear.

These are five frequently asked questions we get around FIELDPROC encryption.

1. What type of fields are supported with FIELDPROC?

Surprisingly, virtually every field type is supported, whether it is character (even binary character), numeric (zoned, packed or binary) date, time, timestamp, Double Byte Character Set (DBCS), and hex. Some fields have certain restrictions, for example in order to implement fieldproc encryption on date, time, and timestamp fields you must specify a default value that is not ‘current date and time’.  You can define this in DDS or structured query language (SQL), and there is an option in the DB2/400 FIELDPROC encryption menu that will do this for you.

FIELDPROC will also handle blank fields by not encrypting them at all. This helps us achieve better results from certain SQL operations. FIELDPROC encryption however does not support fields with NULL values and they should be avoided or changed if necessary.

2. Will I need to make any changes to my applications?

As I mentioned above, it is not necessary to make application changes, but here is more detail as to why: In V7R1, AES/400 can create FIELDPROC exit points that tie to individual fields in a DB/2 file. When a file is opened for any operation, read, update, insert, or delete, the exit point calls one of our FIELDPROC applications, which calls our encryption or decryption APIs. It does this regardless of which application is accessing the file, thus creating application independent encryption.

A few things to consider are: when you backup your file you will need to also backup the FIELDPROC applications, and make sure you restore them at the same time as well. It is also important to remember that if the file is accessed through FTP it will be transferred in the clear.

3. Can I encrypt index fields?

In short, yes. However, encrypting index fields will affect the performance of your SQL operations, and the more indexes you encrypt, the more your performance will be affected. This happens primarily for the following reason: For faster performance DB/2 looks up records based on their encrypted values. This means that when you tell DB/2 you are looking for the record with social security number 111223333, and that field is encrypted, it will encrypt the search string and then retrieve the matching record for you. This is done as a performance enhancement especially when working with logical files on the IBM i. However for some SQL operations it decrypts all the records in order to read the index fields, so rather than encrypting single values to look up, it needs to decrypt a multitude of records.

4. What kind of performance can I expect?

In our test environment, which consists of a single processor IBM i platform, model 515, approximately 3500 CPW, V7R1 of the operating system with TR5 installed, we can process about 16,000 records per second. Systems with higher processing power should see better performance. This means that if we have a file with one million records and one field encrypted we can read the entire file in about 60 seconds. If they are 2 fields encrypted it will take us about 120 seconds because we are handling two million decryption calls.

5. Does using external key management affect performance?

In short, no. The time it takes AES/400 to retrieve a symmetric encryption key from our Alliance Key Manager server is approximately 0.0116 seconds. And this is through a secure TLS connection. There are network infrastructures in which this time may be slightly affected, firewalls, routers, switches, distance, however it should never create a noticeable difference in performance.

To learn more about automatic encryption on IBM i V7R1 using FIELDPROC, download the podcast "FIELDPROC Encryption on the IBM i" to hear IBM i security experts Patrick Botz and Patrick Townsend discuss encryption, key management, and meeting compliance regulations on the IBM i.

Alliance LogAgent is a product designed with the intent of reading your security audit journal event entries, then formatting and forwarding those events to any SIEM or LEM device, but LogAgent provides several significant features and functions that you may not be aware of.   In this article I will discuss five of these highly valuable features of the Alliance LogAgent product that you may not know about.

1. Exclude trusted users to reduce volume. In addition to allowing system administrators to filter out various event types from reporting, Alliance LogAgent will also allow you to filter out all events created by specified user profiles through the use of an “Excluded Users” list.  System admins may occasionally find it necessary to filter out all audit events created by implicitly trusted system user profiles.  Alliance LogAgent allows you to configure this ability at the IBM i level so that you can block those events from reaching your SIEM, thus reducing the volume of events that the SIEM must filter from reports.
2. Secure communications between agent and SIEM. While most SIEM solutions provide support for TCP and/or UDP connections to agents, Alliance LogAgent also supports the use of SSL/TLS secure connection for customers who need to protect the privacy of the communications between the agent and the SIEM.  With the simple addition of certificates to the IBM i Digital Certificate Manager and configuration of an Application ID tied to the certificate, Alliance LogAgent can be quickly configured to use SSL/TLS communications to protect your communications with the SIEM.
3. Exit Point monitoring. In the IBM i environment many IBM applications provide Exit Points that can be used to trigger flags for reporting or launching other processes.  Alliance LogAgent has the ability to monitor these Exit Points and create audit events that get reported to the SIEM so that system administrators can use the SIEM to monitor many of those functions.  Providing Exit Point monitoring within Alliance LogAgent allows the SIEM to provide administrators with valuable reporting of the use of many of these systems within the IBM i.
4. File Integrity Monitoring. File integrity monitoring is recommended under PCI DSS and other regulations.  Even in other environments it is often highly desirable to be able to verify and monitor the integrity of data within database files.  Alliance LogAgent has an add-on module that provides this highly valuable File Integrity Monitoring (FIM) function.  Database Monitor allows the admin to determine which files and which fields within those files need to monitored for access and integrity.  Database Monitor will record the original field data and also the new values recorded in the field, as well as application and user information for how and when the data was changed.  This integrity monitoring allows you to also set alerts to administrators if unauthorized users, or applications alter data, or if data changes violate configurable thresholds. 
5. Simplified formatting for event reporting. In the world of event management there are many possible SIEM and LEM systems and services available.  Some of these SIEM and LEM systems use Common Event Format (CEF) for handling event data, while others use the Syslog (RFC3164) format.  Alliance LogAgent provides configuration options to support either of these two formats and is compatible with a wide range of SIEM and LEM devices and services without any need for additional IBM i support or programming.  Simply select a couple of collector and formatting options in the product configuration panels, specify the destination address of the SIEM device, and start the system.  You can begin seeing your IBM i audit events at the SIEM in a matter of minutes from initial installation of the product.

With the importance of event monitoring becoming more critical for system administrators, it is important to choose a logging solution that will meet your needs.  Alliance LogAgent’s wide range of features, combined with the ease of setup and configuration, allows system administrators great flexibility while still allowing for rapid deployment with nearly zero impact on daily operations.