Townsend Security Data Privacy Blog

John Earl

Recent Posts

Introducing Alliance Key Manager for SQL Server

Posted by John Earl on Aug 22, 2011 10:01:00 PM
encryption key management hsm sql
Alliance Key Manager for SQL Server

Today we are excited to announce the availability of our new Alliance Key Manager for SQL Server (AKMSS). AKMSS is a certified Hardware Security Module (HSM) that manages and protects access to your encryption keys.

Our new HSM is focused on providing mid-market Microsoft SQL Server customers and their technology partners with an affordable, easy to deploy, solution for meeting data privacy compliance requirements in PCI-DSS, HIPAA/HITECH, FFIEC and other data privacy regulations. Unlike other HSMs on the market, AKMSS is built, tuned and priced specifically for small and mid-size SQL Server customers who need to protect sensitive data in their databases.  AKMSS comes with a standard Windows interface so it is easy to configure, deploy, and operate.  AKMSS is based on proven technology that is already successfully used by thousands of customers worldwide.

Townsend Security built this HSM with the idea that cost should not be a barrier to data privacy compliance.  We know that small and midsize companies are increasingly feeling the pressure to meet data privacy compliance requirements, and at the same time many are being targeted by data thieves.  Our AKMSS HSM will help small and medium-sized businesses meet data privacy requirements for encryption key management with FIPS 140-2 certified appliance.

Some of the features and benefits of our AKMSS HSM include:

  • Out-of-the-box integration with SQL Server 2008
  • Utilizes Microsoft’s Extensible Key Management (EKM) interface to support Transparent Data Encryption (TDE) on SQL Server 2008
  • Based on our FIPS 140-2 certified AKM software
  • Reduces cost as a barrier for a professional data privacy compliance
  • Built to be integrated - the product is ready for partner integration

If you need key management for the Microsoft SQL Server world, please take a moment to contact us and see how you can add industrial strength compliance to your encryption project.

You can learn more about the solution here.  Additionally, we have a webinar titled "Encryption Key Management with Microsoft SQL Server 2008" that shows just how easy encryption key management can be on your SQL server.

John Earl, President & CEO

Click me

Topics: Encryption, SQL, Encryption Key Management

Data Encryption vs. Data Scramble

Posted by John Earl on May 31, 2011 7:40:00 AM
IBM i Encryption with FieldProc For most organizations, the entire impetus to encrypt is closely tied to the need to be compliant with one regulation or another.  There is the PCI regulation, the HITECH act of 2009, HIPAA, Sarbanes-Oxley, and a whole host of state privacy laws.  If you are going through the due diligence of database encryption, you sure as heck want to get it right the first time.

A big part of getting it right is using the right encryption tool.  There are plenty of tools on the market that claim to do encryption, and you probably know a clever programmer or two who thinks he can come up with a nifty little data scrambling algorithm that no-one has ever seen before. But encryption — real encryption — demands that we reach for a higher standard.

The U.S. Department of Commerce publishes the definitive encryption standard on its National Institute of Standard and Technology (NIST) website and to date, hundreds of cryptographic providers have achieved this high standard.  As of this writing, NIST has certified over 1,300 AES encryption implementations.

A Fundamental Truth
Cryptographers do not suffer fools lightly.  Their science is mathematically based and their algorithms are well known and well vetted.  A fundamental truth of cryptography is that real encryption cannot rely on keeping the algorithm secret.  Instead the secret that protects the data is the encryption key, and only the encryption key.  Anyone who says different may find themselves on the receiving end of an extra-long mathematical dissertation on the mathematical correctness of accepted encryption algorithms.

encryption-keysWhen you stop to think about it, this makes perfect sense.  If the world used a secret algorithm to encrypt data, if that algorithm were ever to be discovered then all the world’s data would be at risk.  But if the key is the one-and-only secret that unlocks the data, then a compromised key only puts the data at risk that was encrypted with that particular key.  All the other data that has been encrypted with other keys is still safe.  This demonstrates both the wisdom of strong (and open) algorithms, but also the essential importance of strong key protection.

Another benefit of open algorithms is that they are peer reviewed and extremely well vetted.  The AES standard that is the de-facto standard for encrypting data at rest is well known in cryptography and mathematical circles and is recognized the world over as the most effective method for encrypting business data.  Its modes of encryption are well known and proven. And there is a strong body of knowledge about how to correctly implement the AES standard.  From the perspective of a cryptographic (encryption) provider, encryption libraries are not easy to write, but they are known to be solid when implemented according to accepted standards.

Homegrown Encryption
Unfortunately, some software providers seemed to have taken a different road. AES encryption must have seemed too difficult, or too cumbersome, so instead they found loopholes and/or shortcuts to simplify their implementation.  Some software providers use untested software, or unique and un-vetted methods of encryption.  These data scrambling methods aren’t (and never could be) NIST or FIPS certified, but if their customers never ask about certification or independent validation, those providers are not likely to raise the topic.

So we are seeing a raft of uncertified, and un-vetted cipher methods introduced in the market place.  Some, like OMAC, CS, and CWC have languished on the NIST list of “Proposed Modes” for years, while others like CUSP have never even been submitted as a proposed standard.  And while it is possible that one or more of these upstart modes could be better than one of the current, standard modes, there is no way to know this because these new modes have not been properly tested and crypto-analyzed.  Without testing and peer review, each of these modes is just another premature idea that is statistically more likely to be a bad encryption method than a good one.

Show Me the Cert!
Ask for NIST ValidationMany software vendors are beginning to recognize the value of certifications.  Some claim certifications they don’t actually have (HINT: PCI does not certify encryption software) and some will use confusing language to infer they have achieved levels of certification they haven’t.  Recently I visited a website that claimed (I’m paraphrasing):

Our stuff uses FIPS 140-2 certified algorithms to ensure the highest level of data security.

The NIST AES website displays no record of this company ever having received a certification for any encryption software.  Clearly they recognize the value of certification, but have not yet knuckled down to do the hard work to make it so.  And if you don’t check their supposed “facts,” it’s likely that you’ll soon regret it.

My advice?  When someone claims to be certified for any type of encryption, ask a simple question: “Can you show me the cert?”  It ought to be available on the web, or in paper form that they can show to you so that you know this software has passed an independent evaluation.  If they have a cert, then you can dig down deeper and find out whether the software will fit your needs.  But if they are claiming a certification that they cannot prove, my advice is to keep your hand on your wallet and then run.

For more information on encryption and key management, download our white paper titled "AES Encryption and Related Concepts."
 
IBM i Encryption with FieldProc  

Topics: Encryption, Encryption Key Management, White Paper, AES, AES Encryption

COMMON 2011 - Encryption, Customers, and Education

Posted by John Earl on May 12, 2011 12:43:00 PM
COMMON 2011 User GroupWe're just recently back from the COMMON 2011 conference in Minneapolis.  What a great experience for Townsend Security and our IBM i customers.  The encryption and key management sessions that Patrick and I presented were well received and well attended.  Many of the attendees were interested in the mechanics of encryption, and many of those were pleasantly surprised to learn that there is now a way to encrypt database fields without doing massive application program changes.  

At COMMON we announced our new Automated Encryption capability that is now embedded in our benchmark AES/400 product.  Automated Encryption allows you to insert encryption at a database level, rather than at the application programming layer, and that greatly simplifies the task of encryption.  Automated Encryption increases the efficacy of encryption too.  By enforcing encryption at the database level, you eliminate the chance that an application program might be unwittingly introduced that might not follow your encryption standard.  Encryption at the database level ensures that every credit card, or every social security number, is encrypted in the database - without the need for additional application programming.

Another bright spot at COMMON was the number of customers that were either already at IBM i V7R1, or were planning to get there in the next few months.  With the status of OS version V5R4 uncertain (it's End-of-Support date has been extended by IBM at least twice), there was a lot of discussion about what the right upgrade path is.  V7R1 has been out in the market for over a year, and with great new features like the database FieldProc (Field Procedures) It was encouraging to see how many customers were either already on V7R1, or had immediate plans to move there.  A number of customers that currently on OS version V5R4 were planning to move directly to V7R1 without stopping at V6R1.  While they don't avoid the problems of program conversion at V6R1, they do get to the stable, current release in one step rather than two.

Finally, it was great to talk to all of the people that stopped by our booth during the conference.  We spoke to over 300 people during the two and a half day expo.  For those of you that asked questions or made data requests, we are in the process of going through our notes and providing the requested feedback - someone will reach out to you soon.  Most everyone else will have gotten an invitation to follow us on LinkedIn, FaceBook or Twitter - that's a great way to keep up with what is happening in the encryption world and to stay on top of data privacy trends.  We're always producing new educational material about encryption, keymanagement, and data protection, so it's a great way to stay current on those topics.

And for those of you that couldn't make it to the COMMON conference, you can still follow us on social media, and we hope to see you at a tradeshow in the future!

jte

Topics: COMMON, IBM i, Trade Shows

The Magical Encryption Tour

Posted by John Earl on Mar 7, 2011 2:23:00 PM

Automatic Encryption PresentationIt's user group time and I am hitting the road!

This month I have agreed to speak to 5 IBM i user groups in a seven day swing that will start in Seattle and then take me across the heart of the midwest.  It starts Thursday, March 10th at lunch in Seattle (a place I have spoken a lot, as you can imagine) at the Pacific Midrange Systems Association, and ends at a dinner engagement on St Patrick's day in Chicago at the OMNI user group. In between, I'll stop in Toledo Ohio then move on to Michigan, visiting user groups in Southfield, Lansing, and Kalamazoo. To see a complete list of cities and times, follow this link.

The flag ship presentation on this tour is a new creation called "Automated Encryption with V7R1."  As you can imagine, we're pretty excited about the new automated encryption capability that IBM has put in DB2/400.  Townsend Security customers who use our AES/400 encryption solution will be able to select sensitive fields in their databases and turn on encryption with just a menu option.  Townsend Security's AES/400 encryption then works with DB2/400 to automatically encrypt, and (based on rules you can specify) automatically decrypt data on your IBM i.  If you have been contemplating encryption on the IBM i, your encryption project just got a whole lot easier.

So if you're in the neighborhood of any of these user groups, be sure to stop by and say hello.  We love to meet and talk with our customers and learn how they are using our software.

Do you belong to a user group in another part of the country?
Drop us a line to see these presentations at your next meeting. Patrick or myself would enjoy coming out to your group and showing you how cool automated encryption is.

 

John Earl

Topics: IBM i, AES Encryption, User Groups

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