Townsend Security Data Privacy Blog

Townsend Security recently hosted a webinar titled “Protecting PHI and Managing Risk – HIPAA/HITECH Compliance” that focused on how members of the healthcare industry can achieve a breach notification safe harbor if they are properly encrypting their Protected Health Information (PHI).  PHI can be stored in many different places – from Electronic Medical Records (EMR) in a database to healthcare claims stored on a laptop by a health insurance company.  With fines for data breaches averaging into the millions of dollars, it is more important than ever to protect your PHI.  We received some great questions during the webinar that we would like to share with our blog readers.

How is encryption used to protect PHI?

Encryption solutions are used in a variety of places.  Basically those of us that are encryption vendors tend to think of encryption in two ways.  The first is encryption of data in motion.  For example, if you open a web browser and go to a website that uses HTTPS and the “lock” comes on, you are encrypting your data as it is “in motion.”   Typically, SSL or TLS encryption is being used.  These technologies protect any information that flows between your web browser and that endpoint – making it safe to send PHI like a social security number or medical records online.

Second, we think about securing data at rest.  This typically means data that is in a database. When you go to the doctor and he interviews you and puts his results into the computer, that data is landing in a database and it needs to be protected.  AES encryption and proper key management are necessary to protect this data.

Our database software has encryption options.  Why would we need a third party software?

Lets start with an example.  Encryption is part of the package when you purchase Microsoft SQL Server 2008 Enterprise Edition or Oracle 11g with Advanced Security.  So you might say to yourself, “Why do I need something else if Microsoft offers encryption?”  In these cases, you are sitting in a good place for the cryptographic portion, but still need encryption key management to meet any compliance regulation.

To line up with industry standards for encryption best practices, you need to have dual control and separation of duties.  To do this you need to physically separate the encryption keys from where the protected data lives (Your SQL Server or Oracle database).  It is great when a vendor provides encryption as part of their database software, but it only gets you halfway to where you need to be.  An encryption key management Hardware Security Module (HSM) will bring you in line with best practices for dual control and separation of duties, allow you to pass your audit, and achieve safe harbor status in the event of a breach.

View our webcast “Protecting PHI and Managing Risk – HIPAA/HITECH Compliance” to learn how your organization can manage their risk of a data breach and achieve breach notification safe harbor status.

IBM announced recently the end of support date for V5R4. This has prompted many IBM i shops running this older OS to upgrade to a newer release - either V6R1 or V7R1. Traditionally, we have seen that most IBM i administrators upgrade just one release forward. In this particular case, we recommend going to V7R1. Not only is upgrading to V7R1 a fully supported path by IBM, there are security reasons. I recently sat down with Patrick Townsend, Founder & CEO, to discuss IBM i V7R1 and how Townsend Security can help organizations take advantage of FIELDPROC, a new feature that allows companies to encrypt their sensitive data without changing their applications.

You said recently that upgrading your IBM i to V6R1 is a bad idea. Can you explain why?

Security today is more important than it was even two or three years ago. We live in an evolving world around security and organizations of every size - from small companies to global companies - really have been under severe attack. The bad guys are getting much better at what they do and we are faced with highly sophisticated attacks. Even mid-sized companies are now under pressure to protect their data. So we live in a world that is far more sensitive and insecure, and we really have to put more attention on protecting sensitive data.

IBM gave us FIELDPROC in the latest release of the operating system (V7R1), which allows encryption with no application changes. FIELDPROC is really attractive for mid-sized and large customers. It makes the usually very difficult task of encrypting data in our systems much easier. I think that customers who are on older versions of the operating system (V5R4, for example) and who might in the past have just moved up one level, should really move up to V7R1. From a security perspective, it is time to jump a level from V5R3 or V5R4, past V6R1, which would be the next release, to V7R1 and get the benefits of FIELDPROC encryption.

What would an organization need to do to take advantage of FIELDPROC once they upgrade? They still need third-party encryption, right?

Yes, FIELDPROC is the ability to do encryption, but IBM relies on third-party vendors like us to actually provide the encryption libraries and appropriate encryption key management. When customers deploy our FIELDPROC encryption solution on V7R1, they are getting our NIST-certified encryption libraries, as well as seamless integration with Alliance Key Manager, our encryption key manager. Alliance Key Manager is FIPS140-2 certified, and when used with our encryption, lines up perfectly with best practices for encryption across all compliance regulations. Whether it is PCI/DSS with Credit Cards, HIPAA/HITECH in the Healthcare industry, FFIEC in the financial industry, DICAP if you are a civilian company working with the federal government, or if you are a federal agency where it is a mandate that you must have a FIPS140-2 solution.

Our FIELDPROC solution installs into an IBM i customer’s environment, provides both our optimized and certified AES encryption libraries, and the key management you need to be compliant. IBM has done the hard work of making this capability available and we do the work of snapping in proper encryption and key management.

Download a free 30-day evaluation of our Alliance AES/400 encryption, built specifically for IBM i V7R1. Alliance AES/400 is the only NIST-certified FIELDPROC encryption available.

We have been talking a lot recently about the benefits of FIELDPROC as being the main reason to upgrade to IBM i 7.1 (V7R1). Since IBM recently announced the end of support date for IBM i 5.4 (V5R4), we are seeing many shops planning upgrade projects and discussing whether to move their systems to V6R1 or V7R1. Without a doubt, V7R1 is the correct choice – it is even a fully supported V5R4 upgrade  path from IBM.  So, aside from FIELDPROC, what other security reason is there to skip V6R1?  Simply, the updates to Secure Shell sFTP.  I recently sat down with Patrick Townsend, Founder & CEO, to discuss how these updates can help further secure your data.

Another key security feature in V7R1 is a new version of the Secure Shell sFTP application. How is it different and better?

IBM has been making Open SSH available on the IBM i for quite some time. We had the ability to install it back on V5R3. It has become a very popular secure file transfer mechanism, especially for financial institutions. We are seeing large commercial banks across the board moving to Secure Shell sFTP for encrypted file transfers. IBM brings the latest version of SSH to each new release and V7R1 is no exception. The latest version has picked up new security features since the V5R4 release, some of which are quite important. I think moving to V7R1 and getting the latest version of Secure File Transfer (sFTP) is really important. We are learning from security professionals at the NSA, NIST, and SANS just how important it is to make sure the patches to our systems are up-to-date. So again, having the latest version of any security technology is imperative, which re-emphasizes skipping V6R1 when upgrading from V5R4.

Download our podcast “IBM i Security: Skip V6R1 and Upgrade to V7R1” for more information on the security reasons that you should go straight to V7R1. Additionally, we will discuss how Townsend Security can help you take advantage of FIELDPROC, a new addition to V7R1, which allows companies to encrypt their sensitive data without changing their applications.

Your CIO told you that you need to meet compliance regulations around data in motion on your IBM i (AS/400).  It’s not just a good idea, but customers and trading partners are starting to demand it.  So what do you look for when selecting which Managed File Transfer vendor to trust your sensitive data to?  What separates one solution from another?  I recently sat down with Patrick Townsend, Founder & CEO, to discuss what to look for when selecting a Managed File Transfer vendor.  Here is what he had to say:

There are some common business issues that I would look at when selecting a Managed File Transfer product. First, look at the providence of the vendor you are buying from. Have they been around for a substantial amount of time? Are they committed to security? If security is not their core mission, it’s very likely that they are NOT going to get it right, and a Managed File Transfer solution really has to get security right.

I think that looking for solutions that are committed to independent certification of their products is paramount. For example, our commercial PGP product, which in partnership with Symantec, has been through multiple certifications. As a company, we have been through NIST certifications many times. We have a FIPS 140-2 certified encryption key manager as well. If I were looking for a Managed File Transfer solution, I would really want the confidence of knowing that the vendor knows security, is committed to security, and is comfortable with putting their product out there for independent review. That is how I would look at this from a business point of view.

Managed File Transfer and security in general is about building confidence so that your company can move forward, start new initiatives and build confidence with new customers and trading partners. You want to be sure you are deploying a solution from an established security company committed to NIST standards. Looking at a vendor or a solution, I would look deeper than the feature set of the particular Managed File Transfer product and ask myself, am I comfortable with this companies’ security posture and their mission, and do their actions really support what they say is their mission.

Download our podcast “Secure Managed File Transfer on the IBM i – An Introduction” for more information on how your organization can save time and money by securely automating file transfers.

In today’s environment, most organizations fall under multiple compliance regulations. If you are taking credit cards, you need to meet PCI data security standards. If you are in the health care industry, you have HIPAA and HITECH to work on. If you are in the banking industry or any financial segment, you have the Graham Leech Bliley Act (GLBA) and FFIEC requirements to meet. All of us have to deal with state and federal privacy regulations about protecting data.

A secure Managed File Transfer solution with NIST validated PGP encryption can help meet compliance regulations for securing data in motion.

Compliance regulations come full bore on all of us - whether you are in the business, Federal, or non-profit world. PCI DSS and a number of other regulations require encryption of data in motion. Townsend Security has partnered with Symantec to offer the only commercial and fully supported version of PGP encryption on the IBM i (AS/400).

Maintaining proper audit trails is also a very clearly defined requirement of compliance regulations. I think as we see compliance regulations evolve, making sure that your Managed File Transfer solution is based on well accepted standards is very important. For example, the commercial version of PGP encryption that we offer has been through multiple certifications with the National Institute of Standards and Technology (NIST). We have seen fines given to companies using non-standard implementations, so having those certifications and having the confidence that you’re using a solution that provably meets industry standard is really important.

Compliance regulations are still evolving and we continue to see new regulations being brought forward. For example there is a new federal data privacy regulation coming through Congress. There is also a clear evolution of compliance regulations requiring solutions to meet defined industry standards (such as NIST). I know our certifications give our customers confidence that they are meeting compliance regulations and that they are using the right kind of encryption.

Townsend Security’s FTP Manager has been helping IBM i (AS/400) users meet compliance regulations by securing and automating their data in motion to trading partners, customers, employees, and internal systems. Download our podcast “Secure Managed File Transfer on the IBM i – An Introduction” for more information on how we can help your organization save time and money by securely automating your file transfers.

Today, data security is more important than ever. We live in world now where organizations of every size - from small companies to large global companies – need to make sure their sensitive data is safe. The bad guys are getting much better with more sophisticated attacks. Even mid-sized companies are now targets. So, with the most up-to-date security features included in IBM i 7.1 (V7R1), why would you still be using or consider using the V6R1 release?  I recently sat down with Patrick Townsend, Founder & CEO, to discuss the latest IBM i OS and the security reasons a company who is on an upgrade path from V5R4 should bypass V6R1 and install V7R1.

What do you have to say to the company who traditionally moves up just one release? For example the company that would just upgrade to V6R1 because they feel that it has all the kinks worked out.

Well, I understand that motivation and I have been in that seat before. OS upgrades are always something you want to be very cautious about - whether you are talking about your IBM i or even your Linux, UNIX, and Windows servers. You know that a certain number of bugs will get worked out after a new release has come into the market and you tend to be a little cautious about applying the latest release upgrade. Having been released for over a year, V7R1 is now pretty mature and I haven’t heard of any significant upgrade problems.

IBM i users that are on V5R4 know that IBM recently announced the end of support date for that release (which means maintenance and support will stop in about a year) and people will need to upgrade. There are two reasons it is a good idea to jump past V6R1 straight and to V7R1. First, it is a fully supported path by IBM. Second, there are security benefits to making that jump. You are getting significant new security features in V7R1 that you won’t see in V6R1. I know that there are external factors that sometimes influence moving forward on releases. Some software vendors may not be ready for V7R1 and this can represent a significant barrier in terms of getting to the latest release of the operating system. If you have not yet begun a discussion with your software vendors on whether they have certified their software on V7R1, now is the time to do that. IBM makes it very easy for a software vendor to test their software on a pre-release version of the operating system. We do that, and your other software vendors should be doing that too, well before IBM releases a new version of the operating system. This is one time that you should balance the security benefits of V7R1 against the cautionary approach of going only to V6R1, which will be just one step for many people.

Download our podcast “IBM i Security: Skip V6R1 and Upgrade to V7R1” for more information on the security reasons that you should go straight to V7R1. Additionally, we will discuss how Townsend Security can help you take advantage of FIELDPROC, a new addition to V7R1, which allows companies to encrypt their sensitive data without changing their applications.

As more and more organizations are falling under compliance regulations, IT managers are being tasked with finding a secure Managed File Transfer solution to secure and automate data in motion with their trading partners, customers, employees and internal systems.  There are a few out there, but how do you decide which is the best for your organization?  I recently sat down with Patrick Townsend, Founder & CEO to learn more about the core components of a Managed File Transfer solution.  Here is what he has to say:

First, you must have security built-in with your solution. Our Alliance FTP Manager uses a number of secure encrypted mechanisms for transferring files. We use SSL FTP, Secure Shell sFTP, PGP encryption and decryption. That security component is absolutely crucial to the product. I’m really happy with our security, and we have a great partnership with Symantec around their PGP product. Our enterprise customers really expect the highest level of solution when it comes to encryption. We have partnered with Symantec on the PGP product and it carries the proper certification and the depth of support that customers want.

Automation is another core component. If you are dealing with a lot of files, you need to have automation to be efficient. You don’t want to have to do a lot of manual intervention. There should also be a centralized management environment so that configurations can be set up and managed from a central location.

Additionally, notification is another core component. For example you may have files that you’re sending to a customer or your bank. You may only do that transfer once a month, but wouldn’t it be nice if after you transferred the file you sent the customer an email telling them your file is transferred and is ready for processing. With Alliance FTP Manager, we can notify your customer or an entire email list of recipients when a file transfer is complete. Or if there is a failure in a transfer, maybe a customer turned off their FTP server, we can notify that too.  We can do both success and failure notifications in our Managed File Transfer product.

Finally, to meet compliance regulations, you need to have full audit capabilities. We can create audit trails of all the transfers, which is really important from a compliance point of view.

View a recording of our webinar Secure Managed File Transfers: Meeting Compliance Regulations for more information on meeting data in motion requirements of PCI DSS, HIPAA/HITECH, and other compliance requirements on your IBM i.

Managed File Transfer is an easy way to meet business requirements and comply with data privacy regulations.  With a solution like Alliance FTP Manager, businesses can meet compliance regulations by securely transmitting files from their IBM i (AS/400) to their trading partners and customers. Additionally, a Managed File Transfer solution can help your organization save time and money by automating processes that traditionally have eaten into IT manpower. I recently sat down with Founder & CEO Patrick Townsend to discuss how Managed File Transfer can help businesses assure their customers and partners that their sensitive data is secure and in compliance with data privacy requirements such as PCI DSS, HIPAA/HITECH, FFIEC and other regulations.

Can you walk us through a typical business problem that Managed File Transfer Solves?

If you’re a mid-sized or large company, security is absolutely crucial in today’s environment. We all hear over and over again about data losses by large companies and the damage that causes to both the business and the reputation of those companies. Business executives around the world are trying to protect their data, their customer data, and supplier information so they can have the confidence to go forward with their business plans. A managed file transfer solution provides a start-to-finish mechanism for securing data in motion.

If you are using a Managed File Transfer solution like our Alliance FTP Manager, you can have the confidence that you are doing things right, that you are meeting best practices in the industry and that you are less likely to  wake up one day and find yourself in a headline in the New York Times about some large data loss.

Can you explain how a Managed File Transfer works?

Managed File Transfer solutions, like our Alliance FTP Manager, need to meet a number of core requirements. Obviously, they need to protect data in motion and we use SSL session encryption and PGP encryption, which are the industry standards. Automation is also very important. Most of our customers are transferring multiple files everyday to banks, trading partners and suppliers. You don’t want to burn resources by having someone manually transfer files any time it needs to be done.

Additionally, policy driven configuration and reporting by exception are extremely important. Some of our customers are sending tens of thousands of files every day to their trading partners, which can be a lot to manage. You need to be sure that you can manage by exception if there is a problem.

Finally, a Managed File Transfer Solution not only automatically picks up and transfer files, but provides additional controls to make the process efficient - not only from a human resource point of view, but also from a cost point of view. You don’t want to be spending valuable human resources, picking up files and processing them. This should all be an automatic process and that is really the core idea behind Managed File Transfer – automation and security. 

Download our podcast “Secure Managed File Transfer on the IBM i – An Introduction” for more information on how we can help your organization save time and money by securely automating your file transfers.

Tokenizing sensitive data delivers an outstanding return on investment (ROI) to businesses by providing a risk-reduction of losing sensitive data.  By tokenizing data, organizations can reduce the chance of losing sensitive information – credit card numbers, social security numbers, banking information, and other types of PII.  In some cases tokenization can take an entire server or database application out of scope for compliance regulations.  This blog will discuss how tokenization can reduce risks in customer service departments, with outside services, and in BI and Query environments.

Tokenization for Customer Service

Tokenization can reduce risk in the customer service department by removing sensitive data from customer service databases.  For out-sourced operations you should tokenize data before sending it to the outside service.  A customer service worker can still accept real information on the phone from an end customer, but there is no need to store the actual information in a database that can be stolen.  Tokenization services will associate real information with tokenized information for data retrieval.  While using tokenization in a customer service environment can’t completely remove the risk of data loss, but it can dramatically reduce the amount of data at risk and help you identify potential problems.

Tokenization for Outside Services

Many retail companies send their Point-Of-Sale transaction information to analytics service providers for trend and business analysis.  The service provider identifies trends, spots potential problems with supply chains, and helps evaluate the effectiveness of promotions.  In some cases, service providers consolidate information from a large number of companies to provide global trends and analysis.  You can avoid the risk of data loss by replacing the sensitive data (names, credit card numbers, addresses, etc.) with tokens before sending the data to the service provider.

Tokenization for Business Intelligence and Query

Many IT departments help their business users analyze data by providing them with business intelligence (BI), query reporting tools, and databases of historical information. These tools and databases have empowered end-users to create their own reports, analyze business trends, and take more responsibility for the business.  This practice has decreased workloads and increased efficiency in IT departments.

Unfortunately, these tools and databases open a new point of loss for sensitive information.  A database with years of historical information about customers, suppliers, or employees is a high value target for data thieves.  Criminals aggregate this type of information to provide a complete profile of an individual, making it easier to steal their identity.  When tokens replace names, addresses, and social security numbers, this makes the BI database unusable for identity theft, while maintaining the relational integrity of the data.  Tokenizing business intelligence data is an easy win to reduce your risk of exposure.

Download our white paper “The Business Case for Tokenization: Reducing the Risk of Data Loss” to see how tokenization is helping organizations meet their business goals without exposing their sensitive data to loss. 

Tokenization is a technology that helps reduce the chance of losing sensitive data – credit card numbers, social security numbers, banking information, and other types of Personally Identifiable Information (PII). Tokenization accomplishes this by replacing a real value with a made-up value that has the same characteristics.  The made up value, or “token”, has no relationship with the original person and thus has no value if it is lost to data thieves.  As long as a token cannot be used to recover the original value, it works well to protect sensitive data.

Tokenization in Development and QA Environments

Tokenization is an excellent method of providing developers and testers with data that meets their requirements for data format and consistency, without exposing real information to loss.  Real values are replaced with tokens before being moved to a development system, and the relationships between databases are maintained.  Unlike encryption, tokens will maintain the data types and lengths required by the database applications.  For example, a real credit card number might be replaced with a token with the value 7132498712980140.  The token will have the same length and characteristics of the original value, and that value will be the same in every table.  By tokenizing development and QA data you remove the risk of loss from these systems, and remove suspicion from your development and QA teams in the event of a data loss.

Tokenization for Historical Data

In many companies, sensitive data is stored in production databases where it is actually not needed.  For example, we tend to keep historical information so that we can analyze trends and understand our business better.  Tokenizing sensitive data, in this case, provides a real reduction of the risk of loss.  In many cases it may take an entire server or database application out of scope for compliance regulations.  In one large US company the use of tokenization removed over 80 percent of the servers and business applications from compliance review.  This reduced the risk of data loss and it greatly reduced the cost of compliance audits.

Download our white paper “The Business Case for Tokenization: Reducing the Risk of Data Loss” to see how tokenization is helping organizations meet their business goals without exposing their sensitive data to loss.