Townsend Security Data Privacy Blog

Data security doesn’t need to be a challenge! 

Whether your data is stored within your database files or transmitted to your trading partners, using the right tools can mean the difference between meeting compliance and security best practices or suffering a data breach. 

Townsend Security is well known for providing security solutions for a wide variety of platforms (IBM i (AS400, iSeries), IBM mainframe, VMware, Windows, Linux). Recently, our founder and CEO produced an excellent webinar on “Securing Your IBM i Using the Right Tools”. Many of our IBM i customers are under multiple compliance requirements including PCI, HIPAA, SOX, GLBA, and others which require securing data-at-rest and data-in-motion, real-time security event logging, file integrity monitoring, and two-factor authentication. The webinar covers encryption and key management as well as a number of our other auxiliary products specifically for the IBM i (AS400, iSeries) platform.

There were a number of excellent questions asked after the presentation, and the following is a brief recap of that Q&A session with links to additional information:

Q:  Can I use FieldProc to protect multiple fields in a file?

A:  The short answer is yes, encrypting multiple fields is a fully supported capability. FieldProc does allow, from both DB2 and from our solution, protecting multiple columns or fields in a DB2 file. You can define multiple fields and then enable FieldProc with one command on all those fields within our solution. People often ask if indexes can also be encrypted and yes, that is fully supported as well. There are a few limitations in legacy RPG applications, while with a native SQL application there are no limitations.

To learn more about Field Procedures on the IBM i, check out this blog:  5 Common FAQs About IBM i Encryption Using FIELDPROC 

Q: Can’t I just transfer my file from IBM i to Windows and then PGP encrypt it there?

A:  This is a great compliance question and comes up often with QSA Auditors. Yes, of course you can move a file from one machine to another using operations navigator. The problem is that it exposes data in the clear during the movement, either across the network if it is an unsecured connection or when the data lands on the other side of the transfer. Any of these exposures will likely result in an audit failure.

Good security practice, regardless of the platforms involved is:

•   Encrypt at the Source
•   Decrypt at the Destination

Make sure to securely move it in encrypted form and don’t let it get loose anywhere in between!

Learn more about the core components of a total encryption strategy in this blog: Secure Managed File Transfer and PGP Encryption

Q: How does key management work with older back-up copies of data that was secured with earlier keys?

A:  Any Enterprise key management solution should maintain encryption keys under policy for as long as they are needed. As you generate new keys, the older keys are retained and made available for decryption purposes, until you retire those keys. Our solution will maintain multiple versions, and doesn’t have a limit on how many keys or generations you can have of master or key encryption keys. If you have a loss or need to delete data that is out of your control, you can then delete the key. 

For more information on the full life cycle of keys, check out this blog: Why Key Management is So Critical in the Life Cycle of an Encryption Key

Q:  Your two-factor authentication product is supported in which countries?

A:  Since our 2FA solution is through TeleSign, a global company, it has a broad presence in more than 200 countries around the world and in 87 languages.  By leveraging an individual's mobile phone, a reliable means of authentication has become readily available for the IBM i platform. For example, instead of tokens, businesses can simply send an SMS or voice message that contains a one-time authentication code to the individual user’s phone. This means cyber criminals cannot log into the IBM i without physical control of the actual phone. 

This blog will outline Making a Case for Two Factor Authentication: Taking Security Beyond Usernames and Passwords

In this age of “Bring Your Own”, we see the acronyms BYOD (device), BYOE (encryption), and BYOK (key) showing up all over the blog-o-sphere. BYOK is a cloud computing security model that allows cloud service customers to use the provided server-side encryption software and (bring) manage their own encryption keys.

The idea of encryption (cryptography) is almost as old as the concept of written language: if a message might fall into enemy hands, then it is important to ensure that they will not be able to read it. Most typically, encryption relies on some sort of "key" to unlock and make sense of the message it contains, and that transfers the problem of security to a new level – now the message is secure, the focus shifts to protecting the key. In the case of access to cloud services, if we are encrypting data because we are worried about its security in an unknown cloud, then why would we trust the same cloud to hold the keys without using a key management solution?

BYOK can help an organization that wishes to take advantage of cloud services to address both regulatory compliance and data privacy concerns in a third-party multi-tenant environment. This approach allows a customer to use the encryption technology that best suits the customer's needs, including the cloud provider's underlying IT infrastructure. For example, Amazon’s Simple Storage Service (S3) is about protecting data-at-rest using server-side encryption with customer-provided encryption keys (SSE-C) or “BYOK”. With the encryption key you provide as part of your data request, Amazon S3 then manages the encryption (as it writes to disks) and decryption (when you access your data). You don't need to maintain any code to perform data encryption and decryption in S3. The only thing you do is manage the encryption keys you provide to the Amazon Simple Storage Service. When you upload an object, Amazon S3 uses the encryption key you provide to apply AES-256 encryption to your data and then removes the encryption key from memory. When you retrieve data, you must provide the same encryption key as part of your data request. Amazon S3 first verifies that the encryption key you provided matches, and then decrypts the data before returning it to you.

Important to Note: Amazon S3 does not store the encryption key you provide. Instead, they store a randomly salted HMAC value of the encryption key in order to validate future requests. The salted HMAC value cannot be used to derive the value of the encryption key or to decrypt the contents of the encrypted object. That means, if you lose the encryption key, you lose the object.

Any time a company decides it wants to host its applications in the cloud, or use a SaaS application where the company’s data will be stored in the cloud, their IT security professionals have to ask a series of questions.

• Can we encrypt the data? If so, who will have access to the keys?
• How will we perform key rotation and manage the lifecycle of the encryption keys?
• Is the cloud vendor using a proprietary encryption technology that prevents us from moving our data to another vendor?
• If we use 10 SaaS applications, will we have to administrate 10 different key management solutions?

These questions are tough enough to answer when the data and encryption technologies are in a company’s own data center where it has complete control over everything. In many cases, if encryption is provided, the cloud provider holds or has access to the keys, which creates another set of problems for the end user. For one thing, a third-party having access to data in the clear is a violation of regulations such as PCI-DSS, HIPAA, GLBA and others. Also, customers have yet to establish trust in cloud platforms or SaaS providers to protect their data. There have been many high profile data breaches that make end-users nervous. Customers also fear the U.S. government will subpoena access to their data without their knowledge or permission. For companies outside the U.S. that choose to use a U.S.-hosted cloud or app, there are data privacy and residency concerns. Instinctively it feels a lot more secure to manage your own key and use BYOK instead of leaving it to the cloud provider.

A few things have become crystal clear:

1. You need to know where your sensitive information is. Period.
2. You need to know who has access to it. Not who you think has access to it, but who really has access to it.
3. Wherever you put your sensitive information, you need to protect it. The most critical thing you need to do is to apply a strong defense in depth approach to data security, including the use of encryption and access controls.
4. You need to be able to document, through audit logs and reports, who has actually accessed your information. This is true (and important) for sensitive data, as well as for compliance-regulated data.
5. If you think that having your cloud service provider encrypt your data provides adequate security for your information, you probably need to rethink this.

It all boils down to this: When encrypted data is stored or processed in the cloud, the data and the keys must be kept separate and only the end-user should control the encryption keys.

Cloud storage options bring new economies and business efficiencies, but security can’t be ignored, and it can’t be simply outsourced to some other party. We believe that it is fundamental to good security to control all access to your data, including managing your own encryption keys. Managing encryption keys may sound daunting, but it doesn’t need to be. Our technology makes data security and encryption key management simple and straightforward. Our key management solution addresses all of the issues described above and can protect your data everywhere you have it stored.

Real-time, Low-cost, Business Integration When and Where You Need It! 

Do you need a complete and affordable solution for implementing XML web services on your IBM i? Need a solution that won’t disrupt your existing applications and database so you can easily implement web services without complicated API programming or the deployment of external servers? Our Alliance XML solution includes all of the communications, XML parsing, data translation, and application integration components that you need. You can create XML documents from your existing database files and securely send them to remote web servers, and you can receive XML documents directly on your IBM i and process the data into your applications. 

QSA auditors and other security professionals focus on the protection of sensitive data after it traverses the Internet and then lands in a database on a hard disk drive. You need a solution that provides security at every level of processing and protects data in transit using session encryption. When sending or receiving XML documents Alliance XML can use the Transport Layer Security (TLS) protocol for strong encryption of the transferred data. The Alliance XML TLS support is based on the IBM Digital Certificate Manager and related IBM APIs for TLS sessions. This gives you an implementation that is compatible with native IBM i security. As an additional layer of security the Alliance XML HTTP servers provide IP address controls so that only known clients can use the servers.

When receiving XML documents with sensitive data you can enable field level encryption to protect the data. For example, if you receive a document with a credit card number or social security number, you can use strong encryption of the data to protect it before it is written to your database table. User APIs provide a means of decrypting the data so that it can be used in your RPG and Cobol applications.

The web protocols HTTPS and FTPS provide for the ability to encrypt the data in transit, and Secure Shell SSH also provides strong encryption. But after the data reaches the end point of its journey it lands in a database somewhere, and it is often exposed to loss at that point. I believe that’s why security auditors put emphasis on making sure that data is encrypted when it hits it’s destination.

Many companies have implemented web services in combination with the XML data standard to take advantage of low cost, real time integration with their customers and vendors. When you combine the ubiquity of the web HTTPS protocol with the W3C XML standard you get a powerful incentive to use this platform for business integration.

Care should be given to what happens to data when it leaves the realm of encrypted transit and lands on server hard drives. The right thing to do is encrypt sensitive data at the very beginning. This means that the tools you are using have to support encryption as a natural part of the process of converting XML data. Standard XML processing tools such as Xerces and Xpath do not have built-in encryption. The same is true for XML toolkits and APIs provided by IBM, Microsoft, and others. This leaves it to developers to try to intercept data after it is transformed from XML and before it lands in a database table or on a hard drive. That’s a real challenge.
 

In our Alliance XML/400 web services product on the IBM platform we built encryption right into the data transformation process. Alliance XML/400 customers can protect sensitive data by enabling the encryption option on a translation map. The solution does the rest. The data is encrypted before insertion into the database and there is no exposure as the data lands in the database on the hard drive. Our customers are taking advantage of this feature to meet PCI and other compliance regulations.

Encryption can help protect against another common threat, too. At the annual PCI SSC standards council meeting a few years ago, forensics expert Chris Novak of Verizon talked about how more than 75 percent of data loss events begin with a well known weakness that hasn’t been patched, and half of these are based on SQL injection attacks, this is still true today. With SQL injection, the attack on your servers starts with bad data inserted into a database in the clear, leaving open a later exploit. There are ways to prevent SQL injection through programming techniques, but encryption will also help defeat them.

Will encrypting your data provide all of the security protection you need? No, but it should be a major part of your defense-in-depth strategy to protect sensitive data.  

To view a replay of a webinar we presented on XML & Web Services, click below

 

Beyond meeting compliance regulations, it is the right thing to do!

In the past, encryption has had a reputation for being difficult to do, complex, and time consuming, we hope to show you how that has changed. If you are new at protecting data in Microsoft SQL Server environments, generally compliance regulations are what drive an encryption project.    

Since it wasn’t thought of as something that improved the “Bottom line” by increasing revenue or decreasing expenses, encryption has historically been a project solely driven by the need to meet compliance regulations. There are a large variety of compliance regulations that most, if not all, businesses fall under. One common misconception about compliance regulations is that they don’t equally apply to both private and public companies. To clarify, these regulations apply to all companies, of all sizes, whether they are privately-held or publicly-owned. 

For example, if you take credit cards for any reason, you fall under Payment Card Industry - Data Security Standards (PCI-DSS). Other common regulations are:

• HIPAA Data Security & HITECH Act of 2009 which applies to Medical Providers and the healthcare industry.
• GLBA/FFIEC apply to banks, credit unions, credit reporting agencies, and anyone in the financial industry.
• FISMA is for Federal US Government Agencies.
• The Federal Trade Commission (FTC) also gets involved with anyone who issues a privacy statement.

More than 45 states also have their own privacy rules, in addition to the ones listed above, that strongly recommend encryption of any personally identifiable information (PII).

So, beyond compliance with regulations, why should you care about encryption… and what is it anyways? First of all, your customers, clients, and suppliers all expect you to protect their sensitive data. Hackers and data thieves are targeting mid-sized companies because, as larger companies get better at securing sensitive information, the hackers see smaller companies as better targets. Financial fraud and data breaches become more common in those businesses that might not be as prepared without the resources to have an internal security team. Data loss can have a big impact on a company's reputation as well as their financial health.

AES encryption is a mathematical formula for protecting data.  It is based on a proven, well-known algorithm and standards published by NIST. Since that formula is a open and vetted standard use, it is not the mathematical algorithm that is the big secret. It is what happens with the “Key” that locks and unlocks the data that all the fuss is about.

Key management is so important because the encryption keys are THE secret that must be protected. Without access to the key, a hacker that accesses encrypted data has no way to read it. Industry standards and best practices for encryption key management, as well as compliance regulations that require proper encryption key management, all state that storing encryption keys on the server with the protected data is a poor security practice. Encryption keys are unique and cryptographically secure, and once created, protecting the key is the core practice that will protect the sensitive data. It will not be defensible in the event of a data breach if the keys were stored in the same server as the data. This would be like leaving the key to your house in the door lock and being surprised that someone entered uninvited!

Our solutions help Microsoft SQL Server customers really protect their data. Alliance Key Manager, our encryption key management solution, is NIST FIPS 140-2 compliant. This means it meets Federal standards that private enterprises expect around key management. We provide encryption key management solutions for every version and edition of SQL Server starting with SQL Server 2005. In addition, you can choose between a hardware security module (HSM), Cloud HSM, VMware virtual appliance, or a cloud instance in AWS or Azure. Easy. Efficient. Cost-Effective.

Please join our founder and data security expert, Patrick Townsend, in this 30-minute webinar that will cover encryption and key management best practices with Microsoft SQL Server!

As always, your comments and feedback are appreciated! 

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:

Two Factor Authentication (2FA) adds a critical layer of security to protect user accounts and prevent fraudulent access that goes beyond password logins.

Have you made time to watch our most recent webinar on Two Factor Authentication? If not, click here to learn more about how 2FA enables companies to increase their security without the high cost of hardware & software integration by using a technology that is already a part of every user’s life, offering a better user experience with little-to-no training required. Also by leveraging your mobile phone as an authentication device, Alliance Two Factor Authentication improves the security of user account access while reducing operating costs typically associated with traditional multi factor authentication methods.  

Here is a summary of the questions asked after the 2FA webinar:

Q: Does two factor authentication integrate into an already existing single sign-on environment?

A: Yes, you can deploy two factor authentication in a single sign-on environment. Alliance Two Factor Authentication runs natively on the IBM i platform, which allows you to use a SSO solution in the IBM i environment and still deploy two factor authentication to the end-user. We implement the second factor authentication on the IBM i platform, which means that we’re not linked to the actual SSO application that might be running on Windows or using an LDAP or active directory implementation. This provides you with better security for those users who are accessing your IBM i platform as it is not possible to then hijack the authentication requests in a PC environment.

Q: What company did you partner with to deliver 2FA messages?

A: Having customers all over the globe, we were very selective in choosing to partner with another company familiar with terms of network availability of two factor authentication. We chose the TeleSign Corporation. Their infrastructure has the ability to detect when SMS text messages may not be delivered, and they will fail-over to other options and take action in other routes. With guaranteed enterprise-level uptime and industry-leading deliverability rates, TeleSign has conducted more than 2.5 billion phone-based authentications and voice verifications around the globe.

Q: In which countries is two factor authentication available?

A: Our partner TeleSign has a strong, mature infrastructure in the European zone, Latin America, Asia, and delivers authentication codes to over 200 countries and that supports 87 languages. They are constantly testing network connections and performance and they've had time to build this very powerful global infrastructure for our Alliance Two Factor Authentication solution.

Q: How long does it take to deploy Alliance Two Factor Authentication?

A: We suggest you test drive our Alliance Two Factor Authentication solution which is available to download from our website. We typically turn around requests for an evaluation license very quickly and can have you up and running the same day. With our complimentary trial, we also provide TeleSign credentials so that customers can actually evaluate two factor authentication on their own systems. We provide you a fully functional 30-day evaluation, yet proof of concept for this application can be done very quickly.

Request your complimentary 30-day evaluation here

We look forward to hearing about how our 2FA solution works for you!

Defend your data by adding another step to your security process!

With increased losses of sensitive data from websites, retailers, and covered entities in the medical segment, we are hearing about data breaches on an almost daily basis now.  Are we as concerned as we should be, or are we getting jaded to the inevitability of data loss? When it seems like everyone is getting hacked, what kind of things can we do to help prevent access to our sensitive data?

After the recent Target data breach (and a number of other ‘holiday’ breaches), more information is surfacing on how attacks happen through unsecured websites, phishing emails, memory scraping, and keyboard logging malware that can get installed on individual user PCs. Once the hackers have usernames and passwords they can work their way through a network to where the sensitive information is stored.

For those of you on the IBM i platform, it might interesting to note that the IBM i is not immune from attacks and data loss. IBM i has a well-earned reputation as a secure platform, yet we are seeing keyboard logging attacks get past that great security as users log-in to the IBM i from their PC. IBM i platforms are typically great reservoirs of sensitive information; credit card numbers, social security numbers, personally identifiable information of all types make the IBM i platform a clear target for attackers.

In addition to the basics: encrypting your data and properly managing your encryption keys, you can immediately improve your security posture in relation to log-in security, as well as application level security by using two factor authentication (2FA) to prevent unauthorized access.  

The goal is to reduce fraud and actual theft of sensitive information by implementing something much harder to defeat. Combining something the person knows (password) with something they have, or something they are, which can then be used for two factor authentication.

• Something you know - a password

Security administrators can set system values for rules on passwords, require certain length passwords, characters and numbers, uppercase characters... but end-users are quite adept at creating passwords that can be easily remembered, yet meet the criteria of the strong password from the systems point of view. Even “strong” passwords can still be fairly weak from an attacker's point of view. With malware that easily detects them, passwords alone are a weak defense in relation to log-in security if that's all you have.

• Something you have - a mobile phone

Mobile phones that support SMS text or voice verification are something we all have and carry with us. It is now becoming quite common for companies to leverage what everyone already has in the way of the mobile phone or standard phone, and use that device as a mechanism for two factor authentication. There are some immediate benefits to this technology:

• Companies don't have to buy expensive additional servers and hardware
• Users generally have a mobile phone already, and even if they replace their mobile phone, their phone number remains the same
• Reduced cost of administrative expenses

• Something you are - biometric authentication options (iris pattern or fingerprint)

By using 2 of those 3 things you can authenticate more securely to the system.

Here are a couple examples of things that are not two factor authentication:

• Requiring two passwords: using one factor twice is not 2FA!
• Using shield questions of which are actually fairly easy in our social world to determine (Just the other day I received a message on a social media site that said “Hey!  We might be related… what is your mother’s maiden name?”)

We're seeing Google, Facebook, Yahoo, and almost all large commercial banking websites implementing a two factor authentication system based on SMS text and or voice verification to give additional security to their users accounts.

Cell phones that support SMS text or voice verification are something we all have and carry with us. It is now becoming quite common for companies to leverage what everyone already has in the way of the mobile phone or standard phone, and use that device as a mechanism for two factor authentication. There are some immediate benefits to this technology:

Earlier this year we introduced Alliance Two Factor Authentication for the IBM i, which fully implements 2FA using SMS text or a voice verification call to your mobile phone.  In case you don't have a mobile phone, or are in a location where you can't get cell service, we allow the user or system administrator to record up to five mobile and voice phone numbers per user. This gives you a lot of flexibility for putting in phone numbers for home, work, cell with either the text or voice option. In the rare chance you may be someplace without access to any type of phone, Alliance Two Factor Authentication provides up to 5 one-time codes for use when the phone services are not available. These are randomly generated numeric PIN codes a user has access to, that gives them the ability to authenticate even if they don't have a phone with them at the time.

Developers are also able to improve the security posture of IBM i platforms at the application level as well as during the log-in process with Application Program Interfaces (API). Alliance Two Factor Authentication does full logging of authentication and changes to the configuration files into the IBM security audit journal QAUDJRN. For anyone running our Alliance LogAgent solution to capture information from QAUDJRN into your SEIM solution or your log collection server, this will automatically integrate 2FA in that environment. Developers can use two factor authentication for certain critical functions in the application environment such as sensitive operations about patient information, specific financial transactions, critical system functions (like powering down the system or doing a restore) that you might want to protect with 2FA. We provide a complete API set to our IBM i customers so that they can use a simple application program interface (API) structure to initiate a two factor authentication sequence within the application. IBM i web applications can use Java, RPG, or other web languages to call the APIs and fully implement web-based 2FA within the context of the IBM i system where our two factor authentication application is running. The APIs then return to the program the result of the two factor authentication request as either succeeded or failed, and you can take actions at the level of the application to record the event or to deny or allow a particular operation.

For a more in depth technical discussion, please check out this great webinar on two factor authentication by security expert Patrick Townsend:

Still Have Questions About Meeting Compliance Requirements?

The question “Would You Pass An Audit?” was posed in our last blog and companion webinar series.  We discussed compliance regulations and how protecting sensitive information was more than just a good security strategy. While the webinar title is directed at IBM i users, the content is really applicable to most all platforms! Hopefully you were able to watch the webinar resource provided (if not, you can request it HERE).  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: If I have my sensitive data stored off site with a hosting company or in the cloud am I responsible if they have a data breach?

A: The short answer is yes you are. When you have sensitive data and are moving it into a cloud solution you are still ultimately responsible for protecting that data. This can be confusing because cloud vendors make a lot of statements about encryption and compliance, however you are responsible for your overall data protection strategy.  

When looking for a hosting vendor or to move applications outside of your environment, a part of the process should be assessing their ability to meet PCI or other compliance regulations. As part of your due diligence, ask for a QSA letter of attestation from a qualified QSA auditor to confirm the security of the infrastructure of that hosting company and that they are:

• Securing the data center to PCI standards
• Securing racks properly
• Placing proper controls and vulnerability scans in place for their own infrastructure

It is your responsibility to make sure your data security meets compliance regulations. Any loss will also be your responsibility, so it is worth the time to make sure you have a strong strategy in place and are using industry standard encryption and proper key management to protect your data wherever it resides. 

Q: A vendor told me that tokenizing data will make us PCI compliant is this true?

A: This is a more complex question to answer. Tokenization is a great technology and there has been a lot of work done in this field the past few years.  Personally, I believe it can be done well and can help you meet compliance regulations.  If you are planning to generate non-recoverable tokens (when the original data does not need to be recovered) using a separate token server, that can eliminate the need to store the original data in an encrypted format. Non-recoverable tokens can help minimize the impact of regulations such as HIPAA, PCI, HITECH , GLBA and individual state privacy laws by taking the server out of scope for compliance.  However if you plan to recover the data and are consolidating sensitive information into the tokenization solution, you must make sure the tokenization solution itself is PCI compliant and using industry standard encryption such as AES when using recoverable tokens. The basic concept for tokenization is that you replace the data in your database with a token that has no value; however, sensitive data (for retrieval) has been transferred into the tokenization solution.  Because all of this sensitive information has been consolidated into one place, it becomes even more of a high value target.  Tokenization is very effective as long as you are using industry standard encryption within that solution and also using best practices for encryption key management.  Make sure you are using a tokenization solution that integrates with a NIST validated and FIPS 140-2 compliant key management solution that will properly store your encryption keys on a designated hardware security module (HSM) and not in the same server as the pool of data. 

Q: A vendor we are considering for key management advertises an integrated key management solution, would this be PCI compliant?  

A: Only a QSA auditor can determine PCI compliance of vendor solutions, however being educated on industry best practices is very important.

Storing the key within the same server where the data is located is not a defensible practice, and security best practices recommend using an HSM to store encryption keys away from the data you are protecting. Best practices for encryption key management also recommend that you implement separation of duties and dual control.  I highly recommend that you look for NIST validations and make sure the approach to encryption and key management has been done correctly.

To help you plan your data security strategy, we’ve created a great How-to-Guide on Encryption Best Practices and you can download your complimentary copy by clicking on the link below.   

As always, we welcome your questions and comments!

Are You Confident You Are Meeting Compliance Requirements?

Why do we have so many different compliance regulations that affect our companies and our need to protect data? The fact is that there are people out there trying to access that sensitive information and devastating data breaches happen on a regular basis. While breaches are very difficult for companies that suffer the loss of customers, brand damage, and stiff financial penalties, it is the consumers and individuals who are most impacted by the loss of personal information, credit card numbers, or bank account numbers. Because these breaches happen and have such a catastrophic effect on individual people, state and federal and private regulations have been necessary to help motivate companies to try to protect that sensitive information and keep it out of the hands of those who would use it to commit the financial crime and fraud.

Since most companies fall under a number of compliance regulations, here is recap of the most predominant points:

PCI Data Security Standard (PCI DSS) applies to merchants, public or private, who take credit cards for payment. While PCI DSS applies to payment cards, credit cards, and debit cards (anything to do with electronic payments) there are some core components of section 3.5 and 3.6 that require encryption and proper key management:

• You must encrypt credit card numbers
• You must use an industry standard encryption (AES)
• You must provide proper management of encryption keys
• You must have dual control, split knowledge, separation of duties

PCI section 10 requires logging:

• Tracking user access to core resources
• Collecting security events in an un-modifiable log
• Consolidate the logs across all of our servers
• Monitor them for potential breaches

HIPAA/HITECH Act covers the medical segment and any partner entity under thefederal law has to comply with data protection for protected health information (PHI) of patients and must meet requirements about protecting patient information and PHI. The most recent meaningful use guidance was very clear that organizations who fall under HIPAA/HITECH must protect patient health information and we must use proper key management as a part of any encryption strategy. They were quite blunt when they said ‘don't store encryption keys on the device with protected data’... there is no gray area there!

GLBA/FFIEC applies to the financial industry (bank, credit union, trading organization, credit reporting agency). Gramm Leach Bliley Act sets standards for protecting information and consumer information. The FFIEC is responsible for publishing guidance, actually performing audits, and enforcing the standards set by GLBA around encryption and key management best practices.

Sarbanes-Oxley (SOX) applies to public traded companies (section 404 - information technology and data protection for stakeholders). SOX provides detail around data protection, guidance around cryptographic key management, and security requirements for data management. They issue very strong guidance for encrypting sensitive data of personally identifiable information (PII) that is being managed by a publicly traded company. SOX closely mirrors the National Institute of Standards and Technology (NIST) which publishes best practices guidance for encryption key management, key management lifecycles, and logging.

In the United States we have a number of state privacy laws, some of them mandate encryption, others strongly recommended it. These laws apply to both public and private organizations of all sizes and provide guidance for breach notification and penalties around data loss. There is a wide recognition that protecting data using industry-standard encryption and proper key management is a basic common safe harbor from having to do breach notification. Additionally there is a proposed federal privacy law that will eventually replace the individual state laws.

What elements do all of these regulations have in common?

• All are expecting organizations to secure personally identifiable information (anything that can be actually used to individually and specifically identify somebody) with encryption or tokenization and actively monitor their systems
• Laptops, mobile devices, removable storage, tape archives, or backup archival files must be encrypted
• Requirements that vendors, business associates, and service providers must meet the same regulations of the industry they are serving
• Multiple regulations may apply to one company (ie: a doctors office that takes credit card payments would fall under PCI DSS and HIPAA/HITECH)

One of the biggest points of audit and compliance failure is around the encryption key management strategy. While compliance regulations do not mandate FIPS 140-2 validation on a key management solution, auditors will red flag encryption or key management that's not industry-standard. They're looking for certifications like NIST validation of AES libraries or other encryption components and FIPS 140-2 validation of key management solutions. Once you encrypt your data with AES, encryption keys are the secret that you must protect. The nature of an encryption key is that it is unique to you.  It cannot be easily detected or reverse engineered from the data itself. Look to NIST for recommendations about how to manage the creation and lifecycle of an encryption key (when it should be rotated or changed).

What do auditors look for in certifications and standards?

• Standards-based encryption (AES)
• FIPS 140-2 validated key management
• Security best practices of dual control, separation of duties, and split knowledge
• Policy based security

In terms of developing a data protection strategy, apply the best and strongest data protections provably based on industry standards and security best practices to all sensitive data and remember:

• Regulations are getting more stringent and specific… not less!
• Fines and penalties are getting steeper… not cheaper!
• Define personally identifiable information (PII) broadly…not narrowly!

Also crucial when you begin to consider a data protection strategy and your data is moving across multiple operating systems, databases, and platforms is to look for a common approach to encryption and key management, it will be very helpful in reducing costs and maintenance over the long-term.

I’ve included a link to our recently recorded webinar, which focuses on the IBM i system, but is applicable across most platforms.  There is a great deal of detail and information on how we can help you address compliance regulations and the four core components of a data protection strategy (on the IBM i, or Windows, or Oracle, or a number of other platforms) for which Townsend Security provides solutions:

• Encryption
• Data at rest – AES Encryption
• Whole file encryption with PGP
• Tokenization
• Encryption Key Management
• Secure System Logging

Please request the webinar download!