A few days ago I noted here that the IBM i (AS/400) did not have a Heartbleed vulnerability, and I shared a link to an IBM statement about this. It looks like IBM got a little ahead of themselves. You need to be aware of the new IBM Heartbleed security advisory for Power Systems.
The advisory only applies to selected IBM i platforms, so be sure to read the entire advisory to understand if you are affected.
This advisory includes the Hardware Management Console (HMC) which is widely used by IBM i customers with multiple logical partitions (LPARs). Even if you use the HMC to manage a single LPAR, you are probably affected by this advisory. Almost everyone enables HMC terminal access services in such a way that they would be exposed to the Heartbleed vulnerability.
If you do have a vulnerable IBM i system, you should follow IBM’s advice and force your IBM i users to change their passwords. If you’ve already done this before applying the recommended updates, you should do it again (after you put on your teflon suit, of course).
Don’t forget to ask your third party vendors about any Heartbleed vulnerabilities in their software.
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.
Today, cloud resellers need to know that companies searching for a cloud provider to host their information technology have several good options. Microsoft Azure and Amazon Web Services (AWS) are two popular and trustworthy cloud platforms, and there are many other smaller cloud and private cloud platforms that can meet specific technological needs. However, when moving to the cloud, organizations must also consider the security options provided by that cloud service in order to address their own concerns about data security. This can be an issue for cloud resellers whose customers need good security in order to move to the cloud.
Finding good security on a cloud platform can be difficult when cloud security seems to be far more expensive than the cloud solution itself. Many companies need to encrypt sensitive data such as cardholder data, protected health information (PHI), and other personally identifiable information (PII), as well as manage their own encryption keys to meet compliance regulations.
This is why third-party cloud encryption and key management solutions are becoming more and more popular with cloud resellers who need to provide their customers easy and cost-effective encryption and key management. Third-party security can help a company choose the cloud provider they want without having to compromise their data security due to cost.
Cloud resellers for Azure, AWS, and other cloud providers should consider these concerns their customers’ may have about data security on cloud platforms:
Since it is shared by many users, the cloud is inherently less secure than a hardware solution. Cloud solutions utilize shared resources such as disk space and RAM, which is why the cloud is much less expensive than purchasing your own hardware; however, this means you have less control over who has access to your data. This is why encryption is critical to organizations who are storing sensitive data in the cloud.
2. Standards-Based Encryption
Many organizations attempt “in-house” or do-it-yourself encryption in an attempt to avoid difficult or costly third-party encryption solutions. However, these DIY projects tend to be difficult and rarely result in strong, defensible security. They can lead to huge problems down the road, especially when it comes to meeting compliance regulations, and it is common for these solutions to fail data security audits.
One major reason a DIY approach to encryption often fails is a lack of strong cryptography and and encryption key management. The management and documentation of encryption key lifecycle, rotation, creation, and deletion is mandated by many regulations such as the Payment Card Industry Data Security Standards (PCI DSS). Anyone handling sensitive data must meet specific encryption and key management requirements set forth by the industry or government regulations they fall under.
For these reasons, most organizations chose a certified third-party encryption and key management vendor to help them meet compliance as well as centralize and streamline the encryption and key management of all of their sensitive data in the cloud.
3. Encryption Key Management
Encryption key management is a major concern for cloud users. Even if their cloud vendor offers a native encryption option, how that vendor manages encryption keys can be a barrier for organizations who need to manage their own encryption keys in order to meet compliance. In accordance with many compliance regulations, businesses must document how they manage their encryption keys away from their encrypted data. This can be very difficult if your encryption keys are being stored in the cloud and accessible by the cloud provider. Some cloud providers offer encryption key management; however, they do so at a cost that makes using the cloud an unattractive choice. Cloud resellers must be aware that this, too, can be a barrier to cloud adoption.
Cloud resellers need to know that security is a barrier for many companies who wish to move to the cloud. Building a toolbox of certified cloud encryption vendors can help them win these customers and gain new revenue.
To learn more about encryption key management for the cloud, view our webinar, “Encryption & Key Management Everywhere Your Data Is,” featuring data privacy expert Patrick Townsend.
Securing data with encryption and protecting the encryption keys with proper key management is addressed in many compliance regulations and security best practices.
Let’s take a look at the Security Rule and Omnibus Rule (update to HIPAA/HITECH compliance regulations) that cover Protected Health Information (PHI) and the data security requirements that affect Drupal developers or users. When dealing with the healthcare industry, Personally Identifiable Information (PII) is a subset of PHI, and refers to information that is uniquely identifying to a specific individual. Protected Health Information is specific to medical and health-related use and generally refers to demographic information, medical history, test and laboratory results, insurance information and other data that is collected by a healthcare professional to identify an individual and determine appropriate care. To better understand the recent changes in HIPPA/HITECH regulations, here are a few key rules that provide guidance:
The Security Rule
The Department of Health and Human Services (HHS) and the Centers for Medicare & Medicaid Services (CMS) provide guidance around the protection of sensitive data and PHI based on a security series of seven papers, each focused on a specific topic related to the Security Rule. The rule is officially titled “Security Standards for the Protection of Electronic Protected Health Information” (45 CFR Part 160 and Part 164, Subparts A and C) but is commonly known as the Security Rule.In the Security Rule standards on Technical Safeguards [164.304 as “the technology and the policy and procedures for its use that protect electronic protected health information and control access to it.”], encryption and decryption requirements regarding the transmission of health-related information are covered in sections 164.312(a)(2)(iv) and 164.312(e)(2)(ii).
HHS offers the following guidance to render Protected Health Information as unusable, unreadable, or indecipherable to unauthorized individuals:
Electronic PHI has been encrypted as specified in the Security Rule by “the use of an algorithmic process to transform data into a form in which there is a low probability of assigning meaning without use of a confidential process or key” (45 CFR 164.304 definition of encryption) and such confidential process or key that might enable decryption has not been breached. To avoid a breach of the confidential process or key, these decryption tools should be stored on a device or at a location separate from the data they are used to encrypt or decrypt.
The Omnibus Final Rule
On January 25, 2013, the Office for Civil Rights (OCR) of the U.S. Department of Health and Human Services published the Omnibus Final Rule, entitled “Modifications to the HIPAA Privacy, Security, Enforcement, and Breach Notification Rules under the Health Information Technology for Economic and Clinical Health (HITECH) Act and the Genetic Information Nondiscrimination Act (GINA); Other Modifications to the HIPAA Rules” (Omnibus Rule), 78 Fed. Reg. 5566. The Omnibus Rule was effective on March 26, 2013, with a compliance period of 180 days, requiring compliance as of September 23, 2013.
The Omnibus Rule Summary:
- Finalizes modifications to the Privacy, Security, and Enforcement Rules to implement the Health Information Technology for Economic and Clinical Health (HITECH) Act, proposed in July 2010
- Finalizes modifications to the Privacy Rule, proposed in July 2010, to increase the workability of the Privacy Rule
- Modifies the Breach Notification Rule, adopted by interim final rule in August 2009
- Finalizes modifications to the Privacy Rule to implement the Genetic Information Nondiscrimination Act of 2008 (GINA), proposed in October 2009
Within the Omnibus Rule, HHS makes it clear that certain provisions of the HIPAA Rules are now applicable to business associates. HHS has expanded the definition of “business associate” (45 C.F.R. § 160.103) to include patient safety organizations (PSOs), health information organizations (HIOs) and subcontractors. Also included as business associates are health information entities, e-prescribing gateways, other persons that provide data transmission services or facilitate access to health records, and vendors of personal health records provided on behalf of covered entities. HHS considers this subcategory to encompass data transmission services requiring routine access to PHI and services that provide personal health records access on behalf of a covered entity. Also, subcontractors (or agents) that perform services for a business associate are also considered business associates to the extent their services require access to PHI. For example, a vendor providing data storage would be considered a business associate if the data included PHI. This would require subcontractors to have HIPAA compliant business associate agreements in place and under the Omnibus Rule, business associates are now directly liable for compliance with the Security Rule. This means they must comply with the Security Rule’s requirements for (1) administrative, physical and technical safeguards; (2) policies and procedures; and (3) documentation in the same manner as covered entities. The protection of PHI falls on a wider set of requirements and more businesses and organizations will be affected by the Security Rule and Omnibus Rule for HIPPA/HITECH compliance.
“This final omnibus rule marks the most sweeping changes to the HIPAA Privacy and Security Rules since they were first implemented,” said HHS Office for Civil Rights Director Leon Rodriguez. “These changes not only greatly enhance a patient’s privacy rights and protections, but also strengthen the ability of my office to vigorously enforce the HIPAA privacy and security protections, regardless of whether the information is being held by a health plan, a health care provider, or one of their business associates.” [excerpt from 2013 HHS press release]
Another important change should be clarified around Safe Harbor. The Omnibus Rule eliminates the Safe Harbor Status, which previously protected a covered entity from a HIPAA violation based on misconduct by a business associate, now holding all parties liable. This is very different from Safe Harbor for Breach Notification that is still in effect if you encrypt sensitive data. As documented by the HHS “We encourage covered entities and business associates to take advantage of the safe harbor provision of the breach notification rule by encrypting limited data sets and other protected health information pursuant to the Guidance Specifying the Technologies and Methodologies that Render Protected Health Information Unusable, Unreadable, or Indecipherable to Unauthorized Individuals (74 FR 42740, 42742). If protected health information is encrypted pursuant to this guidance, then no breach notification is required following an impermissible use or disclosure of the information."
To address these changes, 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 protected health 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 NIST validated on board encryption.
Stay tuned for our next look at data privacy compliance regulations and security best practices that impact developers and users of the Drupal CMS open source platform in regards to protection of financial and educational information. For more information about encryption and key management, download our eBook Encryption Key Management Simplified.
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.
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:
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.
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).
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.
- 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.
- 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.
- 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: