Townsend Security Data Privacy Blog

With the growing demand for regulatory compliance and concern for data privacy, organizations are taking advantage of encryption as a way to provide a "defense in depth" solution.  This approach is often impractical using only database encryption management tools alone.  Townsend Security has addressed this with their Alliance Key Manager Hardware Security Module (HSM).  Alliance Key Manager is a FIPS 140-2 certified solution that stores encryption keys on a hardware appliance.  This is a more secure approach and better meets compliance requirements because encryption keys do not reside with the encrypted data.

So what does an organization need to look for when selecting an encryption key management HSM?

1) Cost Effective
Cost should not be a barrier to compliance.  Townsend Security's encryption key management HSM is an affordable solution that can scale from small and medium sized organizations to the largest Enterprise.

2) Meet Compliance Requirements
Compliance regulations require encryption keys to be stored separately from the encrypted data to meet Separation of Duties and Dual Control best practices.  It is important to enforce separation of duties if you are trying to meet PCI-DSS.  This means preventing administrators from having access to both the encrypted data and the encryption keys.

3) Invest in a FIPS 140-Certified Solution
This gives you assurance that your encryption key management solution is certified to the highest standard for regulatory compliance.

4) Easy Integration
It is important that your encryption key management solution connects effortlessly to your applications and databases.

5) Automated Key Management Process
Your organization can save time and money when addressing compliance requirements by choosing an encryption key management HSM that automates all of your essential key management tasks - including rotation, retrieval, and generation - from one server or man, in a central location.

Want to learn more?  You can view a pre-recorded webinar titled "Encryption Key Management Simplified" and learn how encryption key management can be easy, why encryption key management is important, and what the barriers are to good encryption key management.

 

Companies of all sizes feel the increasing pressure to protect sensitive customer information to meet PCI-DSS Standards.  Here are five ways to help ensure your database meets PCI requirements: 

1) Use certified encryption solutions to protect cardholder data

A standards-based encryption solution safeguards information stored on databases. Encryption methods approved by the National Institute of Standards and Technology (NIST) provide assurance that your data is secured to the highest standards.  

2) Encrypt cardholder data that is sent across open, public networks
Transmit sensitive files over the internet using trusted encryption technologies. (AES, SSH, SSL, and PGP).

3) Store encryption keys from your encrypted data on a certified encryption key management appliance
The most important part of a data encryption strategy is the protection of the encryption keys you use. Encryption keys safeguard your encrypted data and represent the keys to the kingdom. If someone has access to your keys, they have access to your encrypted data.

4) Enforce dual controls and separation of duties for encrypted data and encryption keys
Make sure people who have access to your encrypted data are restricted from accessing the encryption keys and vice versa. If someone can access your encrypted data and access the keys, your data is compromised.  You shouldn’t lock your door and leave the key under the mat for easy access to your home, the same precautions should be taken with your sensitive data.

5) Use tokenization to take servers out of the scope of compliance
Tokenization replaces sensitive data with a token. The token maintains the original data characteristics but holds no value, reducing the risk associated sensitive data loss. When you store tokens on a separate token server it eliminates the need to store the original data in an encrypted format, and may take the server out of scope for compliance.

Download the whitepaper Meet the Challenges of PCI Compliance and learn more about protecting sensitive data to meet PCI compliance requirements.

 

Smart phone payment systems have exploded over the last few months offering the specter of turning every street vendor into a walking, talking, credit-card accepting, free-spirited merchant. In some cases smart phone payment vendors are giving away free card readers just by signing up. Some people saw this as the welcome exuberance of democratic capitalism with innovation driving new opportunities. Others saw this as the apocalypse for credit card security.  Is there some middle ground here?

Last November the PCI Security Council took the unprecedented step of suspending all Payment Application Data Security Standard (PA-DSS) certifications of smart phone payment applications, and refused to accept new applications based on that platform. That sent a signal to all established merchants that the council had serious concerns and would be issuing new guidance. Established vendors of payment solutions were left in limbo, and new startups who wanted into this field found themselves stalled. Nerve wracking to say the least.

Today the PCI Security Council removed some of the uncertainty about smart phone payment systems by issuing some preliminary guidance.  You can read the press release here.

In the press release you can find initial guidance on what smart phone applications might qualify for PA-DSS certification, and which applications will likely be excluded from the process.  You can find that guidance here.

This guidance is bleak for almost all of the smart phone applications currently in the market.  In regards to applications that will NOT be considered for certification, this item stands out:

 

13. Does the application operate on any consumer electronic handheld device (e.g., smart phone, tablet or PDA) that is not solely dedicated to payment acceptance for transaction processing?

 

Does this mean that a merchant can’t use a smart phone application for payment processing? Nope, the council addresses that, too. If you want to accept payments using smart phone technology, you must include the smart phone application as a part of your normal PCI DSS review process. So, as a merchant, that is your path to PCI compliance. But I don’t think it is time to pop the cork quite yet.

A normal PCI DSS review looks at all of the systems that process credit card information, and the systems they connect to. A payment application that has connectivity to another system generally puts that system into scope for PCI compliance. Your average smart phone connects to hundreds of millions (billions?) of servers on the Internet. That’s a scope of compliance from your worst nightmare.  So I don’t think we will see a rush by merchants to include smart phones in their PCI DSS plans.

Where is all of this going?

I think some smart phone vendors will move towards dedicated devices for payments. Some vendors of WiFi payment systems may incorporation solutions based on the less expensive smart phone platform. We might also see the emergence of alternative payment technologies that don’t directly involve credit card swipes (think something like PayPal?). Things look bad for those smart phone payment applications that got into the market early. If you are the Balloon Man working the local flea markets, don’t throw away that donation hat just yet.

For more data privacy news and tips, follow us on Facebook, Twitter, and LinkedIn.

    
   

Townsend Security is heading to LA in July to attend Microsoft’s Worldwide Partner Conference (WPC).   Our attendance at the conference will support the release of a new security appliance (coming later this summer) that seamlessly integrates with Microsoft SQL Server 2008 R2 to manage encryption keys.

While at WPC we will meet with Microsoft Business Partners who focus on selling and supporting Microsoft SQL Server to discuss an exciting revenue generating opportunity. We will introduce the companies to our Microsoft Business Partner Program and show how our new security appliance will help boost new sales and upgrades to SQL Server 2008 R2 and enable Microsoft Business Partners to help their customers comply with PCI-DSS, HIPAA/HITECH and other regulations.

Companies of all sizes feel the increasing pressure to comply with data security requirements and protect sensitive customer information.  We have listened to small and mid-size companies and heard from Microsoft that the biggest challenge these companies face is access to a cost-effective comprehensive solution. 

In August, we will release a hardware security module (HSM) that will enable Microsoft Business Partners to provide their mid-market SQL Server 2008 R2 customers with an external key management appliance that is cost-effective and comprehensive.  The HSM easily integrates with SQL Server 2008 R2 and leverages existing data protection functionality, transparent data encryption (TDE) and extensible key management (EKM).

We want to talk to partners who serve the SQL Server mid-market, so let us know if you are attending WPC this year and would like to schedule a meeting to discuss this opportunity.  If you aren’t going to be at the conference and this sounds like a business objective for your organization, let us know and we will arrange a time to discuss the opportunity in more detail.

Click here to learn more and contact us.

 

 

Last week we hosted a well-attended webinar titled "Encryption Key Management Simplified - Removing Complexity and Cost."  The focus was on meeting compliance regulations for managing encryption keys and that it doesn't need to be complex or costly - as long as you are using the correct tools.  Patrick Townsend, founder and CTO, received a lot of great questions during the webinar and wanted to share a few of them in our blog.  If you missed the webinar and would like to view it now, click here.

My PCI auditor told me that I need to separate my encryption keys from sensitive data.  Will a key management solution help with this?

Yes.  Absolutely.  That is typically what auditors expect you to do - to use a key management solution to separate the keys from the data that they protect.  So, within the PCI DSS world, for example, there are the concepts of dual control and separation of duties.  You accomplish separation of duties through procedural controls after you deploy a key management server.  You will find references in the navigation guide for PCI DSS around proper encryption key management.  There is a clear recommendation in Section 3 of the PCI DSS that people use professional encryption key management solutions and Alliance Key Manager is exactly that kind of solution.  By the way, it is just impossible on any platform to achieve best practices for key management by having the encryption keys on the same platform as the protected data - whether it is an IBM AS/400 where you have a security officer who has all control, or Windows with an Administrator Account that has high authority, or Linux and UNIX where you have root authority users.  It's just not possible to practically achieve they type of separation of duties and dual control that you need.  In almost all cases, Compliance Auditors are really looking to find proper key management and systems in place like Alliance Key Manager to meet that requirement.

On the IBM i, IBM has implemented a key store.  Why wouldn't I just use the IBM key store?

Well, the IBM i key store is, as it's name implies, is not an encryption key management system at all.  It's a place to store encryption keys.  I think like any platform where you have one or more very highly authorized users you have the problem of achieving dual control and separation of duties.  I'm not picking on the IBM i platform here, I think that platform has generally speaking good security, but you cannot achieve dual control or separation of duties on that platform.  Not only does the security administrator have all authority to any database and the key store, but also any user with All Object Authority has the same level of security.  In a typical IBM AS/400 shop, there are a lot of people who have that authority.  So the key store on the IBM i platform just won't give you the ability to achieve these compliance requirements for separation of duties and dual control.  You really need to deploy a solution that is specifically designed to manage keys through the entire life cycle.

How do you keep system administrators from getting at the data and the keys at the same time?

Through the use of an encryption key management system, you would have a security administrator responsible for creating encryption keys, and a different database administrator responsible for granting access and setting up tables and that person would have access to the data.  But if the data is encrypted properly, and you are using proper encryption key management techniques, that database administrator will not have encryption keys and the encryption key management administrator will not have data access.  This is the whole concept of separation of duties - that you have different people.  To achieve that kind of compliance or security architecture, it means you have to have technology and procedure controls around this deployment.  So you have to have some people who are responsible for the data who never see encryption keys and some people who are responsible for encryption keys who never see data - so there is a combination of technologies and procedures that are required.  If you don't have the right technology, then you can't prevent these two from interacting - so that is why encryption key management is such an important part of a data protection strategy.  You really need to be able to have that separation of duties to achieve that.

To view the webinar "Encryption Key Management Simplified - Removing Complexity and Cost" in it's entirety, click here and be sure to let us know if you have any further questions.

 

I believe that every individual or company that attempts to bring encryption products to market experiences an “Aha” moment. This is the moment when you realize how very difficult it is to get encryption right, and how many ways there are to get it wrong.

It’s not just that encryption is complicated (it is; to a non-mathematician the algorithms can be mind-boggling). It’s that there are so many aspects to doing an encryption implementation correctly that the likelihood of errors is high even for the best-intentioned and most knowledgeable developers. This “Aha” moment can be dramatic. It happens when you see all of your limitations clearly and you know that you are facing a crucial challenge.

However, what a person or company does after this “aha” moment says everything about their character and the quality of the products they bring to market.

When I had this “Aha” moment years ago, I realized that our company had to radically change how we approached the development of our encryption and key management products. I knew that we had to step up to much higher standards, and change how we looked at our own products. But where does one go to figure out how to do encryption right? Fortunately, our company had several good enterprise customers who helped point the way. Enterprise security architects directed us to the National Institute of Standards and Technology (NIST) web site and the FIPS-140 certification process. The NIST and FIPS-140 certification outline the proper standards and best practices for encryption, decryption, key management, and logging.  So began the complete transformation in how we bring Townsend Security encryption products to market.

It wasn’t long, however, before the “Aha” moment was followed by an “Oh no” moment.

It quickly became clear that there was a large body of published guidance on the standards and best practices for encryption and key management. This stuff would fill a small library. And it was intense reading. This was not “Dick and Jane” beginning level stuff. It assumed that you started at a pretty advanced point in your knowledge of encryption and cryptographic module implementation. Not only are there published standards, but there are well-defined test and certification protocols.  And these tests were not going to be easy to pass. These tests are only conducted by a small number of certified labs (See NVLAP), the tests are detailed, complex, and designed to detect even the most minute errors that could cause encryption algorithms to fail.  Certification also means that you must undergo a stringent review of the encryption source code and your development practices.

This was the “Oh no” moment. This process was going to hurt.  It was going to be expensive, time consuming, and mentally taxing. And (at least initially) it was going to slow down our release schedule and increase our time to market.  There was also the concern that some competitors would rush to market faster with whiz-bang features that impressed customers in the demonstration process, but were of less importance to encrypting data.

This was going to be a huge undertaking.  I huddled with our development team. I huddled with our sales and marketing team. I took a long walk.

It was clear to me that this was a decision that would define who Townsend Security would be as a company, and it would illuminate how we really feel about taking care of our customers.  Were we really committed to doing security right and providing complete solutions to our customers?  Or were we willing to scrape along the bottom with inferior products that could be sold to less sophisticated customers?

Well, you already know how this came out. In the end I could come to no other conclusion.  We would either do the right thing, or get out of the security market altogether. We’re still in, so you know that we made that commitment and investment in NIST certification of our correctly implemented encryption solutions. We did learn a lot about encryption development processes and best practices. And I must say our products are so much better for it.

As you know, we made a substantial investment in the certification effort (we still do), and we do have some competitors, especially in the IBM System i (AS/400) marketplace, who claim to have jumped ahead of us.  But I know how dramatically our certification efforts improve our products, and I know how much better off our customers are because of it. Customers who have a NIST certified solution will be protected from harsh regulations, those who put their trust in non-certified solutions will find themselves at the mercy of ever evolving regulating standards.  As these compliance regulations evolve and incorporate standards and independent assessment in their guidelines, our customers will benefit from our efforts. And as the attacks on our protected data get ever more sophisticated, we will see poorly crafted encryption and key management products easily broken with heartbreaking losses for the companies involved.

So, I am a converted believer in the independent certification process.  No one believes that independent NIST certification is a guarantee of perfect security. But no one who has been paying attention believes anymore that a security product should be trusted without it.  We believe the encryption and key management you trust to protect your entire Enterprise database should be equally (if not more stringently) proven and validated.  Click here download a free 30-day evaluation of our NIST-certified AES encryption - available for all Enterprise platforms (Windows, UNIX, Linux, IBM i, IBM z).

Patrick

As you probably know “Phishing” is the security term used for email that looks perfectly valid, but which contains links or attachments that can infect your PC. Really good phishing email looks like it came from someone you know, or from a business that you work with and trust. A well-crafted Phishing scheme lowers your defenses. You say to yourself, “I’m glad John got back to me on that financial plan.” Or, “I wonder why Wal-Mart is having trouble with my invoice.” And a click or two later and you’ve fallen victim to a phishing attack.

Sometimes you know right away when you’ve fallen victim. Your PC goes bonkers or acts oddly and perhaps disturbing messages appear. However, the worst infections can go undetected for a long time. The malware may be snooping for your on-line banking account password, or trying to steal other valuable information. These are probably the worst types of malware infections as you don’t know you are infected.

Small and mid-sized businesses are now under increasing attack from this type of security threat. Organized criminals are looking at these companies as more vulnerable and easier targets. They may have smaller bank accounts, but it may be easier to drain them. So don’t think being a small company will not make you a target.

Here are some thoughts on simple things you can do:

• Be sure all of your PCs and Macs are running the latest anti-virus protection software. Nothing should be connected to your network that does not have the best possible protection.
• Be sure you use strong and unique passwords for financial accounts. We human animals like to minimize the number of complicated things we have to remember. If you use the same password for Facebook and your company bank account, you are in a lot of danger.
• If you are a small company, consider dedicating a small laptop to do your on-line banking. You could load Linux (Ubuntu is my favorite) and a web browser like Firefox, and only use the laptop for that one function.
• Use two-factor authentication for all of your high value transactions. The better banks will help you implement this, and it is one thing that can be helpful.
• Be sure to remind your colleagues on a regular basis to be careful. Being alert is one of the strongest deterents.

One of the biggest mistakes you can make is to feel you are immune from this type of attack. Those of us who work in IT or in the security area begin to think we are bullet-proof. Not so! I found myself shocked recently after clicking on a Facebook posting that looked like it came from my daughter, and watching Microsoft Security Essentials quarantine a nasty virus. My shields were down and I suffered an attack. But this is the characteristic of a really good phishing attack. You relax into a state of trust right at the wrong time.

Now, where’s that email from my new business partner in Nigeria?

For more data privacy news and tips, follow us on Facebook, Twitter, and LinkedIn.

   

When encrypting data, the most widely accepted cryptographic standard is the Advanced Encryption Standard (AES).

AES is defined by the National Institute of Standards and Technology (NIST) in the FIPS-197 standards document. AES supports nine modes of encryption, each of them having been extensively tested and vetted for security, recovery, and durability. When compliance regulations make reference to “industry standard encryption”, they are referring to the encryption modes identified in the NIST documents on AES.

Other modes used in AES are not NIST certified and are not even certifiable. Some products offer only the CUSP mode of encryption, which is not NIST certified and not certifiable. CUSP mode encryption is only implemented on IBM i and IBM z platforms and is not interoperable with other encryption modes. The CUSP mode of encryption has not been proposed or adopted as a NIST standard, and has not been generally reviewed or accepted by the professional security community.

Modes of encryption are recommended by NIST after they have been extensively reviewed by the professional cryptographic community. This is an international group of cryptographers whose long experience and analytic work are important to the vetting of proposed modes of encryption. In some cases it takes years of work before a mode is approved by NIST; many mode submissions are never approved for use.

There are several potential problems related to the use of the CUSP mode of AES encryption.

The CUSP mode of encryption is not included in the NIST list of recommended modes, and has not been submitted to NIST for consideration. It is therefore not a part of the NIST standards, or of any other generally accepted body of standards, and has not been formally reviewed by the cryptographic community. Therefore, the use of CUSP mode would be outside the scope of most data security regulations.

Further, there is no NIST certification protocol for the CUSP mode of encryption. It is not possible to claim that an encryption product using CUSP has been certified by NIST, or that it is in anyway compliant with the NIST standard.

Organizations contemplating the CUSP mode of encryption should be aware that their data protection mechanism could fail to provide “safe harbor” from breach notification requirements, and may not limit their legal liability in the event of a data loss.

The solution?  Most software vendors choose to certify just one or two modes of encryption, and on one key size. The Townsend Security Alliance AES Encryption products are NIST-certified on the five commonly used modes for data encryption, and all three key sizes for all major Enterprise platforms (Windows, Linux, UNIX, IBM i, and IBM z).  Townend Security Alliance AES Encryption is certified, compatibile, and complete.

Download a free 30-day evaluation of our Alliance AES Encryption now.

I’ve always liked those Holiday Inn Express commercials with the theme of “Stay Smart.” The commercials portray an “expert” stepping in to save the day. In one, a “nuclear expert” takes charge of a reactor about to melt down. In another a “doctor” arrives to deliver a baby just in the nick of time. The tag line is funny because the so-called expert turns out not to be a nuclear scientist or a doctor, but just an average person who stayed at a Holiday Inn Express. That made them “smart.” Don’t worry; I’ll bring this discussion back to encryption momentarily.

A while back, reports surfaced of broken encryption security for some Kingston, Verbatim, and SanDisk secure USB storage devices. Not all of the vendor’s devices were affected, but some of their most popular products were. All these products were NIST-certified, causing some industry commentators to erroneously question the certification process. Being a big believer in independent certification, I’d like to weigh in on this controversy and set the record straight.

As it turns out, the weakness, in these devices, was not in the actual AES encryption, but in the key management processes. All the affected vendors quickly released replacements or patches to fix the problem, which is the right thing to do. But it was fascinating to watch some of the responses to this problem. Many commentators complained that the FIPS-140 testing was faulty, or that FIPS-140 testing was irrelevant. The implication is that FIPS-140 does not really give you any assurance of security, and therefore, also by implication, that it is not important.

This is really the wrong conclusion. Let me talk a little about FIPS-140 certification and what is does mean.

First, FIPS-140 certification is not a guarantee of security. It is an assurance that encryption and related security algorithms have been implemented in compliance with published standards, that an application uses good practices in exposing it’s operational interfaces, that start up tests validate that the application has not been modified or corrupted, that cryptographic material is not exposed in application logs or leaked to memory, and that an independent expert has reviewed the source code. Going through a FIPS-140 certification is a grueling process for an encryption vendor and almost always results in finding some issues that need to be addressed to make the product more secure. Companies that engage in FIPS-140 certifications produce better products, and become better security designers in the process.

Is the FIPS-140 testing and certification process perfect? Of course not. That’s not a standard anyone can meet. In fact, NIST is working on a project right now to enhance the process. Believe me, the new certification process (probably to be named FIPS-140-3, for version 3) will not be weaker than the current process, it will be better.

The lesson from the encrypted USB problem is not that FIPS-140 certification is meaningless. It’s that doing encryption right is really difficult. If you want a secure USB storage device, you would NEVER consider using a product that was not FIPS-140 certified. We have plenty of experience of broken security on non-certified products. Problems with certified products are rare, but do happen. Usually you will find that a problem with a FIPS-140 certified product is with some aspect of the application that was out of scope for the certification. That’s the case for the encrypted USB devices that had problems.

To bring us back full circle, I just want to say that no responsible Enterprise should trust a non-certified USB device, anymore than you or I should trust a “doctor” to perform surgery because that “doctor” stayed at a Holiday Inn Express. The sad fact is that many large corporations today are putting their trust in encryption vendors who have not FIPS-140 certified their products. The management of these companies would never consider using a $100 secure USB device without certification, but do entrust the protection of huge amounts of sensitive data to non-certified vendors. In this age where too many try to pass themselves off as experts, it often takes an organization like NIST to certify the expertise behind something as important as encryption.

I’m proud of our NIST certifications – we will never back down from our commitment to provide you with the best security products and our commitment to independent certification. You can learn more about FIPS-140 certification on our web site, or directly from NIST at www.NIST.gov.

For more information, download our white paper "AES Encryption and Related Concepts" and learn about how proper encryption and encryption key management work together to secure your data.

System logging has become one of the most essential tasks of contemporary corporate IT.  Several IT standards and regulations, primarily in the interest of traceability (e.g.: PCI-DSS, SOX, etc.) now require it.

Like other IT projects, the implementation of up-to-date logging also requires careful planning.  For example: systems need to be monitored and the parameters related to security and archiving need to be defined.  Apart from the pure technical aspects it is also recommended to take into consideration several other factors that can not only make a log management system more cost-effective, but can also prevent organizations from having to face difficulties in the future.

With many years of system logging under our belt, we bring you the six fundamentals of system logging:

1) Invest in a Reliable Logging Solution

There are differences among logging solutions in respect of reliability.  The traditional and well-spread protocols were not developed for secure message transferring; therefore the devices applying them do not comply with the needs of organizations governed by different regulations.  If your organization is under any compliance regulations (PCI, SOX, HIPAA, etc.) it is highly recommended to ensure that your central logging infrastructure is reliable.

2) Make sure your logging solution has customized alarms and reports

Alarming and report-making modules are features of a good logging management system because they provide the tangible “end-products” of log management that have to support both the work of operators and the execution of the tasks of specialists responsible for security.  The exhaustiveness of the reports and the sensitivity of the alarms always have to be adjusted to the available quantity of the human resources processing them.

3) Define what to collect, what to analyze, and what to archive

Compliance regulations play an essential role in defining the exhaustiveness of system logging.  For example, section 10.3 of PCI DSS states that all events of all system components – at least data referring to the users identity, the type of event, the data and time of the event, and the origin of the event, name, successfulness or refusal have to be registered.  A huge amount of time and money can be saved if the irrelevant pieces of information can be successfully eliminated before analysis and archiving.

4) The infrastructure providing the time stamps and certificates is a critical point

When setting up a logging infrastructure due to critical business processes or meeting compliance regulations (e.g.: PCI-DSS), it is important to ensure privacy and confidentiality, and the high availability and security of the sub-system providing certificates and timestamps for strict sequence numbering.  Forging the time or the certificate means a fundamental attack against the logging infrastructures; therefore the corruption of these sub-systems questions the authenticity of the whole system itself.

5) Sensitive data needs to have regulated accessibility

All components of the logging system have to be handled as critical systems – including the log files themselves, which could entail such sensitive data as passwords and personal data.

6) Constantly be logging

In the case of each and every logged business process, consider carefully whether it is essential or not for them to be operating without logging as well.  The developers of syslog-ng have taken several steps in order to ensure uninterrupted logging.  The syslog-ng Premium Edition saves the messages on the local hard disk when the central logging server or network connection becomes inaccessible.

Summary

Logging is a must.  Download a free 30-day evaluation of syslog-ng Premium Edition now.