Townsend Security Data Privacy Blog

A little over a year ago Mastercard sent a shot over the bow of Level 2 Merchants when they informed them that they would have to undergo a PCI DSS audit by a qualified QSA auditor, or send internal IT staff to ISA training given by the PCI Security Standards Council. Level 2 merchants had been completing a Self-Assessment Questionnaire (SAQ) each year, and this represented a big step-up in the requirements.

Merchants scrambled to prepare for this new requirement which was due to take effect on June 30, 2011. A number of Level 2 merchants signed up early for the ISA training, and several training sessions were held in the US and Europe. Annual training and certification seemed more attractive than an on-site QSA audit to many merchants, probably because of the cost associated with an on-site audit. But I am guessing that the demand for ISA training out-stripped the availability of classes.

Mastercard just announced a postponement of the SDP ISA requirement:

“In June, 2011, MasterCard announced revisions to the SDP Program mandate by postponing the implementation date of the Level 1 and Level 2 merchant internal audit staff training and certification requirements until 30 June 2012. MasterCard has postponed the implementation date of the Level 1 and Level 2 merchant internal audit staff training and certification requirements to accommodate for the PCI SSC’s global rollout of the ISA Program and to provide Level 1 and Level 2 merchants in all regions with the opportunity to attend the ISA Program and pass the associated accreditation examination.”

The full announcement is here.

I believe that this announcement is a good faith action on the part of Mastercard to help merchants meet the requirement. We saw a similar action on the part of the State of Massachusetts when they delayed the implementation of their mandatory encryption requirements for consumer privacy. These requirements were eventually placed into effect and are now law. Level 2 merchants should not interpret this as a reprieve from having to meet these requirements. If you aren’t scheduled for ISA training, get registered now and don’t put it off!  You are going to need to meet these requirements and the sooner you get the training done the better off you are going to be.

By the way, I’ve heard great reports on the training! It is practical and effective, and Level 2 merchants are reporting a lot of benefits from the training.

Be sure to follow us on Facebook, Twitter, and LinkedIn to stay up to date on the latest technology and news about data protection.

Patrick

 

   

DOWNLOAD WHITE PAPER Download our AES Encryption Strategies: A White Paper for the IT Executive and learn more about deploying an encryption solution. Click Here to Download Now

Many IT executives are now faced with the urgent need to secure sensitive data on their computing systems in a very short period of time.  Decisions need to be made on what data security solutions to use, which projects need priority, and how to make the best use of available resources. The need to deploy better data security has arisen quickly and many IT executives feel the need for more information.

The data security solutions you select now will be in use for many years to come.  Over time, these solutions will be integrated into almost every major application in your IT environment.  Selecting the right solution now is an important first decision, whether that decision is to develop data encryption capability in-house, or to work with a data security solutions provider.

Here are some key questions to consider when making this decision:

• Who will be able to provide us with mature guidance on the appropriate use and implementation of encryption?
• Encryption is a complex technology - do we have the expertise and resources to do this on our own?
• Data security is incorporated into a number of regulations that control our Enterprise, are we using the right technology to satisfy these regulations? And will our solution help us minimize legal liability?
• Will our data security solutions easily extend to new requirements? We need to secure credit card numbers today. What about tape encryption, spool file reports, and IFS files? Will our data security technology lend itself to new uses?
• We transfer data between diverse systems in our internal network, and between customers, suppliers, and employees. Will our solutions meet all of these needs?

For further information and strategies for beginning and encryption project, download our White Paper titled AES Encryption Strategies: A White Paper for the IT Executive.

DOWNLOAD WHITE PAPER Download our Encryption Key Management and PCI DSS 2.0 Compliance Matrix white paper and learn more about ensuring the data you are protecting meets PCI compliance. Click Here to Download Now

We are now past the half-way mark between PCI DSS version 1.2 and PCI DSS version 2. During this year of 2011 merchants have the option of qualifying under either version of the data security standard. Starting on January 1 of 2012, the only option will be to meet the version 2 standard. So, what trends have we observed?

Level 1 merchants are doing pretty well meeting the data security requirements because they’ve been through several cycles of on-site QSA audits. With the basic security controls in place, they are focusing on implementing better real-time monitoring and learning to react quickly to new threats. We still see breaches among large retailers because the bad guys are getting better, but the larger merchants have really stepped up their game.

The picture is not so bright with Level 2 and Level 3 merchants. Level 2 merchants now have to undergo an on-site QSA audit, or do annual training with a PCI SSC certified trainer. This is having a big impact on a lot of these merchants whose security controls were not up to par. They are having to deploy better monitoring systems, and meet industry best practices for encryption and key management. And key management is turning out to be a problem area from many of these mid-tier merchants.

What are the key management problems that I am hearing about? Here are some examples:

• A retailer with an eCommerce web site running on a Windows platform is encrypting data in a SQL Server database, but the key is stored on another server in the clear. A QSA auditor required that the merchant deploy better key management practices.
• A large manufacturer runs a user group and collects membership fees from a web site which are then processed on an IBM System i (AS/400) platform. The encryption keys were stored in encrypted format on the same server. A QSA auditor at their payment processor required that they institute better key management practices by storing the keys in an HSM on a physically separate server.
• A division of a large home improvement retail chain accepted customer orders from a web site, and processed the authorization transactions on a Linux server. The encryption keys were stored on a removable storage device. The payment processor rejected their self-assessment questionnaire on the basis of key management practices. The division migrated to the corporate key management solution to mitigate the issue.
• A software vendor who provides web hotel reservation portals uses both a Windows application and a Linux application to process reservation requests and payments. PCI standards require that credit card numbers be encrypted as data moves through both server environments. This software developer had good advice and chose a defensible key management strategy from the start.

I think you get the idea. Starting with a good key management solution is going to save you some grief later. We helped each of these companies meet PCI DSS compliance for key management, and in most cases it really didn’t take that much time or effort. But better to get it right from the start!

To learn more, download our white paper on encryption key management requirements for PCI.

Many of you have asked me about encryption and key management requirements for HIPAA and HITECH Act. I can understand why there is a fair amount of confusion about this. The US Department of Health and Human Services (HHS) has not issued the final rules, but they have indicated that the current Interim Final Rules are unlikely to change very much. The final rules are due to be published later this year, and may be updated on an annual basis.

The current IFRs indicate that encryption is an accepted method of protecting patient health information. However, there is no mandate for encryption, and medical providers (Covered Entities, in HHS regulatory speak) can use other methods to protect data. However, the guidance about breach notification is very explicit on the question of encryption. A medical provider can only avoid breach notification if the data is encrypted. In the event of a data loss where the data is not encrypted, the medical provider must report the breach to HHS and to the patients affected by the loss. The breach event is published on a public web site maintained by HHS. There may be penalties for the loss of unprotected information, and HHS has already started levying fines on medical providers. Here is what HHS says about encryption and breach notification:

“Protected health information (PHI) is rendered unusable, unreadable, or indecipherable to unauthorized individuals if one or more of the following applies:

1. Electronic PHI has been encrypted as specified in the HIPAA 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 encryption processes identified below have been tested by the National Institute of Standards and Technology (NIST) and judged to meet this standard.“

This is how proper key management is discussed in the HHS documentation. Note that it explicitly states that encryption keys must NOT be stored on the same device as the protected data. This is very similar to the PCI DSS requirement. The HHS documentation makes reference to NIST publications, and those publications recommend the use of FIPS 140-2 key management solutions.

It is important to note that tokenization is not mentioned by the HHS guidelines at all. Tokenization vendors will probably argue that tokenized data is not patient information, so can be used to avoid breach notification. But that is a vendor claim, and is not addressed by HHS. It should be noted that like PCI DSS, the tokenization solution must also meet the HHS guidelines for encryption and key management.

The bottom line?

The only way to avoid a breach notification is through the use of industry standard encryption such as AES, and appropriate encryption key management technologies. Encryption keys must not be stored on the same device (server) as the protected data. NIST best practices recommend that key management systems should be FIPS 140-2 certified. Our Alliance Key Manager solution meets these guidelines and will help you get to the land of HIPAA and HITECH Act Nirvana.

For more information, download our white paper titled "Achieve Safe-Harbor Status from HITECH Act Breach Notification with NIST-Certified Data Encryption."

 

Last week we posted part one of our two-part series covering XML & Web Services.  This second half covers how organizations are currently using web services, how the technology can increase revenue, and how the technology can reduce costs.  For even more information, we have made a recorded webinar available titled "XML & Web Services - How to Win More Business."

How are organizations currently using web services?

There are lots of ways web services are being used to help companies do business and make business work well.  Definitely in back-office processing, we see orders being placed via web services -- shipment requests, notification of order status, all types of business transactions that you can imagine are quite easily implemented as a web service.  So, sort of that fundamental day-to-day operational side of web services are there.  And then you see some really creative kind of things.  You see things like Microsoft SharePoint which provides a web service based collaboration tool that helps people share information and collaborate on documents.  These are powerful technologies that can really be used in a number of different ways.  So, really, almost any interaction that you have that involves information is quite susceptible to being engineered through web services. 

How can the technology increase revenue?

View Recorded Webinar Now

Well, think of new business.  Sometimes, when you want to bring onboard a new customer there is going to be some data interchange that you have to do with that customer.  Web services can make that really easy and fast to do.  Web services can really be an enabling technology to on-board entirely new sets of customers – perhaps in lateral opportunities.  In terms of increasing revenue, that is probably the main way we see XML and web services being deployed.

You mentioned that this technology can also reduce costs.  Can you explain?

In today’s world there can still be a lot of manual work as we move data through our various applications.  Web services can automate that.  We can gain efficiency within our own organizations by automating a lot of these processes.  So, again, XML and web services can be the transport mechanism or the enabling technology for these processes to happen automatically.  We push out inefficiencies, we automate processes, we make data flow faster, which then can improve customer service.  So XML and web services can be an important efficiency tool within an organization as well.

Are there any specific cost savings for our listeners who implement a SharePoint server?

A SharePoint server is a Microsoft server based product that is a collaboration tool and it really lets people in geographically different locations share information in real-time.  So you can push a document up to a SharePoint server, someone else can get notified that the document is available, and then immediately take a look and work on it. This is all done with a web services type of implementation.  Or imagine you are on an IBM Mainframe where you are running back-office applications. What if your daily reports could automatically be published to a SharePoint server and made immediately available to the people who need them?  You can now reduce printing costs, time for the information delivery, and you make that information much easier to share.   So this technology is really helpful for pushing cost out of an organization.

Are there any companies we might recognize using your XML?

Sure!  PotteryBarn is using the RightNow CRM and they needed a way to do bulk data transfers to a SharePoint server hosted by RightNow.  Our Alliance XML/400 was able to do that.  In this case, the payload was an Excel CSV file that had to be shared between PotteryBarn and RightNow.  Our technology made this sharing take place.

How complex is the implementation of XML and web services technology?

That’s a good question.  Let me take that in two parts.  XML and web services technologies have a fair amount of complexity in them.  You have issues of security with HTTP/HTTPS implementations and you have the complexities of dealing with XML payloads - they have to be parsed properly to extract data and make it useable. 

Encryption and encoding becomes an integral part of this technology, so there are a fair amount of really complex technologies integrated into a web services solution.  However, the actual solutions that get deployed don’t have to be complex. 

For example, in Alliance XML/400 we make the implementation of the client and server applications very simple.  They are natural native interfaces on the IBM i that any developer can use if they wish.  So in our solution we tried to hide the complexities of all these technologies in the solution itself, so that our customers don’t have to deal with that.  I think that deploying XML and web services with our product is a very straightforward and easy thing to do. 

We have had people in a very short period of time get up and running with integration with their customers – in as little as a couple of days.  This is something that can be deployed quickly.  Good solutions hide those complexities so that people can get on with doing business and not spend their time fussing around with the technology itself. 

This has been some great information.  Is there anything else you would like to say before we are done?

XML and web services are really enabling tools.  We are living today in a difficult economic time and yet the most successful companies are moving forward.  They are working to engage new opportunities, to reduce cost out of their organizations, and XML and web services technologies can help with this process.  So, being positive and looking for opportunities and being sure to look at the payback for web services as part of the whole picture is really important.

For more information on XML & Web Services, view our webinar titled "XML & Web Services - How to Win More Business."

 

XML and web services are tools that can help your organization respond faster to opportunities, win more business, and reduce costs.  Recently I was able to sit down with Patrick Townsend, Founder and CTO of Townsend Security, to discuss XML & web services.  One thing became crystal clear – using XML and web services does NOT have to be a hard project, in fact it can be relatively easy.

How can XML and Web Services improve an organization’s bottom line?

View Recorded Webinar Now

XML and web services are really designed to help make integration within an organization and between organizations a lot easier.  This technology is designed for the Internet and is an easy to implement integration strategy.  Companies can begin putting applications together within the organization and then start to work to integrate with their customers and service providers.  XML and web services makes business a lot easier to do.  And XML is a great technology for making this happen very quickly.  XML is a very light-weight technology, easy to implement, and very platform agnostic.  So anyone, with the right set of tools, which are not expensive, can begin doing this kind of integration very quickly.

Can you give me a brief overview of how XML and web services work together?

Well, there are several components to web services.  The first is you have a communications layer, which is based on HTTP and HTTPS – the same communications technology we have in our browsers on our PCs.  So the internet HTTP technology is the backbone of web services.  Communications are one big chunk of what web services are all about.

Next you have data that you are pushing between a client and a server, or between yourself and a customer.  This payload is usually in XML format -- which is again, an industry standard well adapted for the Internet.

Then you typically have client and server backend processes.  If I send an order to a customer over the internet in XML format, there needs to be a backend process that can receive that XML document, process it into the back-end order system, and properly handle the data.

So these are the fundamental components – communications, XML payload, and processing capability on both ends – that really make web services go.

What essential components would an organization need?

Since most of the web services are automated, you need a good client application and a good server communications application.  Where as you are browsing on your PC with Internet Explorer or Firefox, you are using a pre-packaged client going to a web server.  In web services between businesses, the client is usually an application, so you need some kind of client application capability that can perform the communications automatically.  In other words, there is not a human being there who is going to initiate a browser session.  It is going to be an automated process.  Likewise, on the receiving end, or the server end of the process, you need a server capable of receiving an XML web services request and invoking the backend application.  And almost always that means something that can parse an XML payload and make that information useable within the backend application.

What can you tell us about Townsend Security’s XML product?

Alliance XML/400 is an IBM i solution and it provides all of the components that a customer needs to really deploy web services on the IBM i platform.  It provides the communications transport – both the client and the server side, it provides the ability to form XML documents out of standard database information, and it provides easy mapping so that complex programming is not required.  It gives the IBM i enterprise customer that ability to easily and quickly deploy web services and take advantage of the technology.

 

This concludes part one of Gaining Efficiency & Business with XML & Web Services.  We will post the second half at the beginning of next week.  Until then, we have made a recording of our webinar "XML & Web Services - How to Win More Business" available for further information.

 

The color silver symbolizes glamor and distinction. This year, the color silver symbolizes accomplishment for those of us at Townsend.  We have recently obtained Silver Business Partner status in Microsoft’s business partner program and the company just celebrated its 25th Silver anniversary.

Earlier this month we announced that we became a silver level business intelligence partner with Microsoft.  This new alliance will help us with the launch of our encryption key management solution for Microsoft SQL Server 2008, later this quarter.   We just returned from Microsoft’s Worldwide Partner Conference where we met with several different partners about this opportunity.   We talked with many companies who had similar interests in compliance and data protection, it was a great introduction into a new community that is very important to us.

July 14, 2011 marked Townsend’s silver anniversary – what a milestone! We owe this accomplishment to our customers, partners and our dedicated team. The company has evolved a lot over the last 25 years; we have undergone a few name changes (Patrick Townsend & Associates, Patrick Townsend Security Solutions and now Townsend Security) and a few different logos.  Our name and our look may have changed over the years, however, our mission and vision have remained the same - Townsend Security creates, sells and supports professional encryption solutions that protect data and simplify compliance.

The solutions we have introduced into the market over the years, AES Encryption, FTP Manager, Key Manager, LogAgent, XML/400 and TokenManager align with our vision. Our commitment to provide world-class support to our hundreds of customers worldwide will always be our number one priority.  And we are proud to say that a few members of the Townsend team have been with the company for over 10 years and several more are quickly approaching their 10 year anniversary, not many companies can say that in today’s economy.  As we pour that glass of bubbly and toast our silver anniversary we will be sure to thank our customers, partners and ourselves for an incredible 25 year run and set our sights on the next 25 years.  I can’t wait to see what it holds!

Be a part of our next 25 years, follow us on Facebook, Twitter, and LinkedIn.

   

Microsoft’s Worldwide Partner Conference just wrapped up and it was truly an International conference. There were partners from every corner of the world. Microsoft has invested a lot in this conference and they are doing a great job of helping companies meet new partners through the on-line WPC Connections web site.

It is clear to me that Microsoft is converging a wide range of products onto the SQL Server platform for data management. The many business applications under the Microsoft Dynamics label including Dynamics NAV (the ERP system), Dynamics CRM (customer relationship management), and Dynamics AX (global ERP management) are all based on the latest version of SQL Server.  The very popular SharePoint collaboration tool now fully supports and exposes SQL Server Enterprise edition. All of the Business Intelligence solutions have been based on SQL Server for some time. And this pattern repeats through other products.

Why is this important? In SQL Server 2008 Microsoft introduced a new database security architecture with Extensible Key Management (EKM). EKM enables database encryption and the use of Hardware Security Modules (HSM) to store and manage encryption keys. Encryption and good key management are crucial to regulatory compliance, and the EKM architecture makes this all possible. The EKM architecture extends forward to the new version of SQL Server code named Denali.

You will be hearing more from Townsend Security about Microsoft SQL Server encryption key management next month.

The Cloud is the other big topic at this conference. Microsoft is moving almost everything to the Cloud at full speed. Microsoft Dynamics, SharePoint, SQL Server, and many other products are getting Cloud-based versions. Microsoft may be a bit late to the game on the Cloud, but they are “all in” now. And they’ve made a lot of room for partners to play in this arena, too. There are a really large number of new and existing Cloud providers at WPC.

Of course, the biggest concern on the part of end customers is the security of the Cloud. After many discussions with Microsoft partners, I know that they have heard this concern. But there is still quite a bit of confusion and ignorance about how to mitigate risk in Cloud environments. I can see we have our work cut out for us in helping to educate the Microsoft partner community about how they can use our solutions to encrypt and protect customer data. It won’t be as hard, painful, and expensive as they think.

Be sure to follow us on Facebook, Twitter, and LinkedIn to hear more about what we are doing with Key Management for SQL Server 2008 and  stay up to date on the latest trends in data protection.

Patrick

 

   

As I talk to Enterprise customers I’m finding a lot of confusion about when to use encryption or tokenization, and how to think about these two data protection technologies. Once you understand how each of these technologies work, you understand that there are no easy answers to which is best for you, or when one is better than another. I want to talk about some general guidelines I’ve developed to help with this conundrum.

Encryption is well known technology, has clear standards, and has been in use for data protection for a long time. Most of the compliance regulations (PCI, HIPAA/HITECH, state privacy regulations, etc.) make clear reference to encryption and widely accepted standards. So it is a no-brainer to use encryption. When done correctly, it is going to meet compliance regulations and your security goals.

But encryption has a nasty side-effect. When you encrypt fields in your database that are indexes or keys, you disrupt the indexing capability of the field and you introduce unacceptable performance burdens on your system. Encrypting an index or key field often means re-engineering the application and this is costly and time consuming.

Enter the new kid on the block – Tokenization.

When you tokenize data you replace the sensitive data with a surrogate, or token, value. The token itself is not sensitive data, but it maintains the characteristics of the original sensitive data. It walks like a duck, it quacks like a duck, but from a compliance point of view, it is NOT a duck. Tokenizing data lets you maintain those precious index and key relationships in your databases, and minimizes the number of changes you have to do to your applications.

So, why not use tokenization for everything? Is this the magic bullet we’ve been searching for?

Hold on there, Cowboy. There are some things you should think about.

Tokenization solutions typically work by creating a separate database to store the token and the relationship to the original sensitive data. This means that every time you need to register a new token, retrieve the attributes of the token, or recover the sensitive data, you have to make a request to the tokenization solution to do this work for you. Got 10 million records in your database? This is going to have a major impact on performance. Applications that need high performance may not be the best for a tokenization approach – you might really want to use encryption in this environment.

Then there is the question of compliance. Tokenization is new technology. At this point there are no standards for tokenization solutions, and no reference to tokenization in the published regulations. So, are you really compliant if you tokenize sensitive data? I think so, but you should be aware that this is an unsettled question.

When you tokenize data, you are creating a separate repository of information about the original sensitive data. In most cases you will probably be using a solution from a vendor. Since the tokenization solution contains sensitive data, it will itself be in scope for compliance. Has the vendor used encryption, key management, and secure communications that meet compliance regulations? How do you know? If you are going to deploy a tokenization solution you will want to see NIST certification of the solution’s encryption and key management so that you are not just relying on the claims of the vendor.

Most Enterprise customers will probably find uses for both encryption and tokenization. Encryption is great for those high-performance production applications. Tokenization is great for maintaining database relationships, and reducing risks in the development, test, QA and business intelligence databases. Both can help you protect your companies’ sensitive data!

For more information on tokenization, view our recorded webcast titled "Tokenization and Compliance - Five Ways to Reduce Costs and Increase Security."

Much like going to the gym, not many people wake up in the morning and say that they want to start an encryption project.  It can take a little knowledge and some hard work to be done correctly.  But the results of both provide benefits far beyond their initial investment.

First, like a proper workout, there are two parts.  There is the encryption process and the often after-thought of key management.  You need both for a successful and compliant data privacy solution.  This is much the same as hitting the gym.  You need to do your weights as well as run on the treadmill for a comprehensive workout.  Just because you are encrypting, doesn’t mean that you are doing it correctly, or will pass any sort of audit for that matter.

Next comes the personal trainer, or in the case of data privacy, regulatory compliance regulations (PCI DSS, HIPAA/HITECH, FFIEC, etc). Privacy regulations show you proper form.  They spell out exactly what you need to be doing to meet compliance regulations.  Check out the concepts in PCI DSS Section 3 for encryption and key management requirements.  Not only are privacy regulations helpful for providing best practices, but also in most cases apply directly to your business (PCI DSS, state privacy laws, etc.). 

Sometimes difficult to meet, compliance regulations are a good thing.  They are what protect your and my personal information.  One good way to ensure you are going down the right path is to use NIST-certified AES encryption and FIPS 140-certified encryption key management.  These certifications assure that the solution is proven and validated by a third-party.  It is a very expensive and time intensive process, but ultimately assures the encryption and key management solutions can meet the most stringent privacy regulations.  Only the very best encryption and key management offerings can do this.

Why make your workout harder than it needs to be?  Start your workout right from the beginning and you won’t be throwing your back out later (did you know an average data loss costs a company over $200 per record?).  Believe it or not, there are still some “encryption” solutions that aren’t NIST-certified.  Some companies say “we meet the standards of NIST and FIPS regulations”, but have nothing to prove it.  If you dig a little deeper you’ll see NIST has no record of them.  It’s kind of like trusting an infomercial that says all you need to do is use their contraption for three minutes a day and you’ll look like a body-builder.  I’d rather spend my time and efforts sticking to a proven method for getting in shape.

For more information on encryption and key management, download our white paper titled “AES Encryption and Related Concepts.”