+1.800.357.1019

+1.800.357.1019

Feel free to call us toll free at +1.800.357.1019.

If you are in the area you can reach us at +1.360.359.4400.

Standard support
6:30am - 4:00pm PST, Monday - Friday, Free

Premium support
If you own Townsend Security 24x7 support and
have a production down issue outside normal
business hours, please call +1.800.349.0711
and the on-call person will be notified.

International customers, please dial +1.757.278.1926.

Townsend Security Data Privacy Blog

Why Encrypt Data in Your Drupal Websites?

Posted by Liz Townsend on Oct 3, 2014 10:44:00 AM

The internet has become a portal for the transmission and storage of sensitive data. Most websites today gather information from potential or current customers, clients, and users. From credit card numbers to email addresses and passwords, few websites exist today that don’t collect some sort of personal data. Therefore, website developers are becoming more and more interested in learning how to build websites that can easily encrypt sensitive data that their client’s website may be collecting. Drupal Developer Program

Encryption isn’t as widely used at the application and module level in websites as it probably should be. Protecting sensitive data using strong encryption from the moment a website accepts a customer’s information, and throughout transmission and storage of that data is the only method to ensure that data is never compromised. This is critical for websites using commerce modules or forms that collect a person’s health information, financial information, or other personally identifiable information (PII); and for businesses who wish to avoid a data breach.

As Drupal grows and more Drupal developers are beginning to interact with larger clients, the need to provide strong security to those businesses grows as well. The need for encryption will continue to grow as potential clients ask Drupal developers for standards-based security solutions that will help them meet compliance regulations and mitigate risk.

  • Government websites, for example, will need to pass FISMA regulations around encryption.
  • Large retail websites will need to pass Payment Card Industry Data Security Standards (PCI DSS).
  • Colleges and Universities have multiple compliance requirements, as well as FERPA, to adhere with.

Helping clients meet compliance regulations will also require, in some cases, the need for encryption key management. Historically, developers only had three choices for encryption key storage: they could store the key in a file protected on the server, in the Drupal database, or in Drupal’s settings file. None of these options are secure, and would not meet several compliance regulations and general security best practices.

Encryption key management is more than a “key storage” solution. An encryption key manager protects encryption keys on a separate server (located in the cloud or as a physical Hardware Security Module (HSM) or in a (VMware) virtual environment) that implements control layers such as dual control and separation of duties. An encryption key manager manages encryption key creation, deletion, lifecycle, rollover, and archival. Key managers that are FIPS 140-2 compliant have undergone NIST validation and are based on industry standards. Choosing an encryption and key management solution based on standards will ensure your solution will stand up to scrutiny in the event of a breach.

If you are a Drupal developer, you can now join the Townsend Security Drupal Developer Program, work with our encryption and key management technology free of charge, and learn how to secure sensitive data in Drupal for your clients concerned with security.

Using Key Connection for Drupal, the first encryption & encryption key management module, Drupal developers can now build NIST compliant AES encryption and FIPS 140-2 compliant encryption key management into their Drupal websites.  

Just click below to sign up:

Developer Program Encryption  

Topics: Encryption, NIST, Developer Program, Encryption Key Management, FIPS-140, Drupal

Dreamforce to You: Protecting Sensitive Information

Posted by Luke Probasco on Jan 17, 2012 8:04:00 AM
Dreamforce to YouAs the social revolution moves into the business world, protecting your data is more important than ever.  This was a key takeaway for attendees of the recent “Dreamforce to You” event in Seattle, WA, hosted by Salesforce.

Similar, yet smaller in scale to the Dreamforce conference held annually in San Francisco, this event brought together sales and marketing professionals who use Salesforce.com (a cloud-based Customer Relationship Manager) to see what is new with the CRM, how it can help you do your job better, as well as allow attendees to network with peers.  Additionally, Peter Coffee, an IT visionary who acts as the VP and Head of Platform Research at Salesforce.com, delivered an inspirational keynote titled “Toward the Social Enterprise: Trust; Vision; Revolution”.

The focus of both Dreamforce and “Dreamforce to You” is that by and large  business is embracing the social revolution.  Whether you are Bank of America and helping your customers find the nearest ATM or are collaborating with co-workers internally using social tools, businesses are migrating to the social world.  During the keynote, Peter Coffee presented a slide titled “Social is a model, not an app.”  By being social, businesses are able to work more efficiently and reach more customers in ways that were never thought possible.  “Salesforce is not just using social tools but instead is driven and formed by the social network.”

As Peter Coffee continued to discuss cloud computing, the future of IT platforms, and how businesses are “going social”, he conveyed a key concept – companies need to protect their sensitive information.  

Insist on NISTWe couldn’t agree more.  As a security company, this is something we have been saying since the beginning.  We have offered NIST-validated AES encryption for all the major enterprise platforms for over ten years, been securing managed file transfers with PGP encryption, and recently stepped up our game with a FIPS 140-2 compliant encryption key management HSM.  Simply put, we are helping organizations protect their sensitive information and meet compliance regulations with certified encryption solutions.

Occasionally we hear “I don’t need encryption, nothing can get inside my network” (De-Perimeterization concept). The truth is, no matter how many of the latest and greatest network security devices you implement, there is still nothing as fail-safe as properly encrypting your data.  As keynote speaker Peter Coffee would say about investing in the wrong technology, “doing it better is still doing the wrong thing.”

For more information on data privacy, download our podcast Data Privacy for the Non-Technical Person.  Patrick Townsend, our Founder & CTO, discusses what PII (personally identifiable information) is, what the most effective methods for protecting PII, as well as the first steps your company should take towards establishing a data privacy strategy.

Click me

Topics: NIST, De-Perimeterization, Data Privacy, Trade Shows, FIPS-140, AES Encryption

FIPS-140 Certified Encryption and the "Aha" Moment

Posted by Patrick Townsend on Jun 16, 2011 8:28:00 AM

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.

NIST EncryptionWhen 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?

FIPS certifiedWell, 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

Click me

Topics: Encryption, NIST, FIPS-140

AES Encryption Performance

Posted by Luke Probasco on Apr 12, 2011 8:48:00 AM

AES Encryption Performance: Avoid the High Cost of Poorly Performing Encryption Solutions

AES EncryptionAES encryption has become the de facto standard for protecting data at rest in databases and unstructured data such as flat files, messages, EDI, and XML documents.  As enterprises deploy data security solutions to meet compliance requirements, they are frequently surprised by the performance impacts of encryption. Inadequate attention to encryption performance can lead to increased costs, delayed or failed projects, compliance failure, reduced flexibility to meet competitive challenges, and exposure to legal liability.

Whether you're evaluating an encryption solution or already encrypting data, these tips about encryption and performance will help ensure you have the right solution in place. 

Encryption - A Resource Hungry Application

By its very nature, encryption and decryption are resource intensive processes. Encrypting a simple credit card number requires many thousands of computer instructions. These instructions merge the input data with an encryption key using a large number of computer instructions to produce the secured data (called the “cipher text”). Because of the large number of computer instructions, an enterprise customer will experience increased utilization of computer resources and a need to consider adding additional capacity.

Ask for performance metrics

Armed with the knowledge that encryption performance is important, you can take action to avoid potential problems. Before acquiring an encryption solution, ask your data security vendor to provide performance metrics for their solution. How long does it take to encrypt one million credit card numbers? Can they provide you with source code and demonstrate this performance on your server?

The Hidden Costs of Encryption

Poorly performing encryption solutions can come with steep price tags as you secure more data in more places. You may have to add additional memory and increase the number of processors to handle the demands of encryption. As you upgrade your server hardware, the operating system vendor and application software vendors may increase the license fees they charge for their software. These cost increases may ripple through your backup and high availability systems. On top of increased hardware and software, your human resource costs also increase as you deploy larger and more powerful servers.

Are Network Encryption Devices a Good Idea?

Some security vendors provide encryption solutions on an external server as an encryption appliance. Each time your application needs to encrypt or decrypt data, a connection to the server is created and the data is transferred to the server for the encryption operation. Be sure to understand the maximum encryption rate of these types of appliances when doing a large number of operations. if it takes 5 milliseconds to transfer data to a server for encryption,
and 5 milliseconds to return the encrypted data, that 10 milliseconds can represent a performance problem.

Test Drive - not all AES encryption solutions are the same

Townsend Security's proven AES encryption solution encrypts data 94x times faster than the competition.   Request a free 30-day trial of our popular Alliance AES Encryption and see for yourself.

But don't just take our word for it, read what Staples has to say about their experience with our AES encpryption solution.

Case Study

AES PerformanceA large multi-brand retailer, that sells its products online and in traditional retail outlets needed to meet PCI Data Security Standards for protecting customer credit card information. After evaluating several different vendors for performance they decided on AES Encryption from Townsend Security.  They deployed the Alliance AES/400 Encryption solution to protect sensitive data in DB2 database files and in a variety of unstructured data files and were able to achieve PCI compliance in record time.

Townsend Security Can Help

The best way to secure sensitive information is with strong encryption and key management. Townsend Security provides NIST validated encryption and logging solutions for the enterprise. Our encryption, key management, tokenization, and logging solutions protect sensitive data from loss, whether it is at rest or in motion.  With NIST validated and FIPS 140-2 compliant certified solutions, Townsend Security meets or exceeds the standards in PCI, HIPAA/HITECH, and state privacy laws.  Click here to download a free 30-day trial of our popular Alliance AES Encryption.

Topics: NIST, Alliance AES/400, Encryption Key Management, Case Study, Performance, FIPS-140, AES Encryption

Non-Standard Encryption – Now That Bites

Posted by Patrick Townsend on Feb 11, 2011 1:33:00 PM

CUSP EncryptionIn our encryption practice we often help customers integrate the exchange of encrypted data between different applications within the organization, and between their own applications and a vendor’s or customer’s application. It is truly amazing to me how often we encounter non-standard encryption that makes this integration very difficult. The problem is not the lack of standards for encryption. Most compliance regulations provide clear guidance and references to encryption standards. Here is what the PCI Data Security Standard (PCI DSS) Navigation Guide says about encryption (my emphasis):

The intent of strong cryptography (see definition and key lengths in the PCI DSS and PA-DSS Glossary of Terms, Abbreviations, and Acronyms) is that the encryption be based on an industry-tested and accepted algorithm (not a proprietary or "home-grown" algorithm).

Strong Encryption:
Cryptography based on industry-tested and accepted algorithms, along with strong key lengths and proper key-management practices. Cryptography is a method to protect data and includes both encryption (which is reversible) and hashing (which is not reversible, or “one way”). Examples of industry-tested and accepted standards and algorithms for encryption include AES (128 bits and higher), TDES (minimum double-length keys), RSA (1024 bits and higher), ECC (160 bits and higher), and ElGamal (1024 bits and higher). See NIST Special Publication 800-57 for more information.

The problem seems to be a general lack of knowledge about encryption. And this applies to some vendors of encryption solutions. Here are a couple of examples:

One of our customers was having trouble decrypting a field with our software that was encrypted on a Windows server with “256-bit AES using CBC mode”. That seemed to be a pretty straight-forward task. Yet we couldn’t get the data decrypted properly. The output just looked like garbage. We spent a fair about of time with the customer verifying that they had the right decryption key, that the initialization vectors for the decryption were specified correctly, and that our software was being used correctly. But nothing was working. We then asked the third party software vendor to share their AES source code with us.  In this case the vendor was very accommodating and let us review their source code implementation of AES encryption.

Voila! The source code showed that the implementation was using a 256-bit block size for the encryption algorithm. The AES standard (FIPS-197) requires the use of 128-bit block sizes. The use of the larger block size meant that this was not even AES encryption according to the industry standard. The vendor fixed their implementation and the project was successful. But our customer spent a lot of time and money resolving the problem.

Another example of getting into trouble occurred with a customer who deployed an AES encryption solution that used the CUSP mode of encryption. This rang alarm bells right away.  We knew that CUSP was not one of the NIST approved modes of encryption, and we had never encountered it before. We quickly learned that CUSP stood for “Cryptographic Unit Service Provider” and was implemented by IBM in a couple of their server products. This customer had a couple of problems. CUSP mode was not a standard mode of encryption, and data encrypted with CUSP was not going to be decrypted by any of the standard open source or commercial products in the market. So this customer was locked into an incompatible encryption strategy.

The second problem is that the CUSP mode of encryption is a proprietary protocol.  The PCI DSS clearly states that strong encryption must be based on industry standards and not proprietary protocols (see above).  As I interpret the PCI DDS requirements for encryption, a customer using CUSP mode would be out of compliance. That’s going to hurt the next time a QSA takes a hard look at your encryption implementation.  We recently published a white paper on the weaknesses of the CUSP mode of encryption.  Click here to download it.

One way to insure that your AES encryption software is compliant is to look for a NIST certification. A NIST AES Validation certificate, or a NIST FIPS-140 certificate, is pretty good assurance of compliance. The FIPS-140 certification process requires AES Validation, so that certification is incorporated by reference. That’s why either certification will give you the assurance that AES encryption is being done according to the standard. Lacking certification, you are relying on the promises of a vendor or developer who may be ignorant, or have a motivation to be less than forthcoming. Not a good situation to find yourself in.

Both of these customers spent a fair amount of money fixing the problem.  An entirely avoidable expense.

Patrick

Topics: Encryption, NIST, CUSP, PCI DSS, AES, PCI, FIPS-140

Encryption Key Management: Top IT Initiative

Posted by John Earl on Feb 11, 2011 1:13:00 PM

encryption key managementI just returned from a trip to Europe and Encryption Key Management was a very hot topic.  This is a topic I very much like to speak about, given our recent release of Alliance Key Manager.  It still surprises me how many conversations I had with technology companies who understood the need to have a proper key manager either embedded within or integrated from the outside of their program or appliance.  There are, I think, a couple of reasons for this phenomena.  

First, many organizations are taking the step to encrypt sensitive data that used to be stored in the clear.  Protecting data is an important IT initiative these days, and one of the absolute best ways to protect data is to encrypt that data.  But as IT teams take on their encryption initiatives, somewhere in the middle of their first encryption project an important realization dawns upon them: After you encrypt the data, the data is only safe if you protect the encryption key.  At this point some organizations will put a temporary fix in place and "hide" the keys as best they can on the same server as the data, but they know this is wholly unsuitable and that a more secure and more permanent solution must be found.

The second reason that I think key management has become such a hot topic on this trip is because of the increased number of compliance regulations around encryption key management.  In October of 2010 the PCI-DSS 2.0 standard was released and in it is call for organizations that store credit card information to use a certified key management solution that is separated from the data, includes robust auditing capability, and supports separation of duties and dual control (more on those topics perhaps in another blog post).

From my perspective then, we appear to have just the right solution at just the right time.  Having recently received our FIPS-140-2 certification for Alliance Key Manager in the U.S. Mail, we're in a celebratory mood here at Townsend Security and it is good to hear all our friends in Europe endorse the time and effort our team has put into this fabulous offering.

John Earl

Topics: Alliance Key Manager, Separation of Duties, PCI DSS, Encryption Key Management, FIPS-140, Dual Control

PCI DSS 2.0 and Encryption Key Management

Posted by Patrick Townsend on Feb 11, 2011 11:46:00 AM

2014 UPDATE:
No Significant Changes around Key Management in PCI DSS v3.0

PCI DSS 2.0 encryption

The new PCI Data Security Standards (PCI DSS v2.0) are here and I’ve gotten a lot of questions about the changes related to encryption key management. Because we work with a lot of companies going through PCI compliance audits and reviews, the new standards just confirm the trends we’ve seen over the last few months on how QSA auditors and security professionals view encryption key management, and what they see as the minimum requirements for managing keys.  The clear trend is to require that encryption keys be stored separately from the data they protect, and to make sure that the people who manage encryption keys are not the people who manage the protected data. Let’s look at why this is happening.

PCI DSS Encryption Key Management Compliance While most of the largest merchants in the Level 1 category are already using professional key management solutions to protect encryption keys, the trend over the last 12 months is to require smaller merchants in the Level 2 and Level 3 categories to also use better key management practices, too. So, what are the parts of PCI DSS that are driving this change?  It all has to do with industry best practices for encryption key management, and the concepts of Dual Control, Separation of Duties, and Split Knowledge. These best practices and concepts work together to form the basis for determining if your approach to key management will pass muster.

First, what is the source of industry best practices for key management? Here in the US, the National Institute for Standards and Technology (NIST) is the most common source for guidance on best practices. The NIST special publication SP-800-57 provides specific pointers on how best practices for both procedurally managing encryption keys, and what to look for in key management systems. In these documents you will find the genesis of most standards regarding encryption key management, including the concepts in PCI DSS 2.0 Section 3.

Next, it is important to understand Dual Control, Separation of Duties, and Split Knowledge. These are all clearly defined in the PCI DSS standard and in the accompanying PCI DSS glossary. I’ve extracted the exact definitions below, but I’ll recap them here from the point of view of key management.

Dual Control means that no one person should be able to manage your encryption keys. Creating, distributing, and defining access controls should require at least two individuals working together to accomplish the task.

Separation of Duties means that different people should control different aspects of your key management strategy. This is the old adage “don’t put your eggs in one basket”. The person who creates and manages the keys should not have access to the data they protect. And, the person with access to protected data, should not be able to manage encryption keys.

Split Knowledge applies to the manual generation of encryption keys, or at any point where encryption keys are available in the clear. More than one person should be required to constitute or re-constitute a key in this situation.

What are the practical implications of these best practices and core concepts?  One of the practical implications follows from a common fact of system administration. On all major operating systems such as Linux, Windows, and IBM System I (AS/400) there is one individual who has the authority to manage all processes and files on the system. This is the Administrator on Windows, the root user on Linux and UNIX, and the security officer on the IBM System i platform. In fact, there are usually multiple people who have this level of authority. In one study by PowerTech, the average IBM System i customer had 26 users with this level of authority!

That’s why storing encryption keys on the same system where the protected data resides violates all of the core principles of data protection, and that’s why we are seeing auditors and payment networks reject this approach. If you haven’t faced this issue yet, your day is probably coming. Now is the time to start planning on how to deal with the problem.

Over two years ago we saw this trend developing and took action to help merchants be prepared for proper key management. We created the Alliance Key Manager solution and released it to our partner channel in 2009. This year we released it for direct sale, and last week we received our FIPS-140-2 certification from NIST. Over 1,000 customers are now using AKM to protect their encryption keys with a solution that provably meets industry standards.  Our encryption products have been updated to use this new key management solution, and we are moving customers forward to compliance. It’s been a long, hard slog to NIST FIPS-140 certification, but I think our customers will benefit from the effort.

I hope this has been helpful in clarifying key management best practices. For more information on PCI and key management, download our podcast titled "Key Management Best Practices: What New PCI Regulations Say." Please let us know if you have any questions.

Click me

---

From the PCI DSS version 2.0 Glossary:

Dual control
“Process of using two or more separate entities (usually persons) operating in concert to protect sensitive functions or information. Both entities are equally responsible for the physical protection of materials involved in vulnerable transactions. No single person is permitted to access or use the materials (for example, the cryptographic key). For manual key generation, conveyance, loading, storage, and retrieval, dual control requires dividing knowledge of the key among the entities. (See also Split Knowledge).”


Separation of Duties
“Practice of dividing steps in a function among different individuals, so as to keep a single individual from being able to subvert the process.”

Split knowledge
“Condition in which two or more entities separately have key components that individually convey no knowledge of the resultant cryptographic key.”

Source documents are available online at www.pcisecuritystandards.org

Topics: Compliance, Encryption, Key Management, PCI DSS, PCI, FIPS-140


Subscribe to Email Updates

Posts by Topic

see all