+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

Encrypting Data In Amazon Web Services (AWS)

Posted by Patrick Townsend on Aug 28, 2014 9:31:00 AM

Amazon Web Services is a deep and rich cloud platform supporting a wide variety of operating systems, AWS services, and third party applications and services. It is a bewildering array of capabilities with lots of places to store sensitive data. Let’s explore some of the ways that our Alliance Key Manager solution helps AWS customers and partners protect this data. This is a bird’s eye view, and we’ll dive into this in more depth in future blogs:

Amazon AWS Services

Encrypting data in AWS - What You Need to KnowAmazon Relational Database Service (RDS)
Alliance Key Manager provides encryption key retrieval and an on-device encryption service to make it easy for your applications to encrypt data in RDS. Townsend Security SDKs can easily be used to provide encryption at the application layer.

Amazon Simple Storage Service (S3)
Alliance Key Manager lets you retrieve 256-bit AES keys in Base64 encoded format ready for use with RDS customer supplied encryption key services. You can easily deploy an AKM dedicated key management service to support encrypting and decrypting files in S3 storage.

Amazon Elastic Block Storage
Amazon Machine Instances (AMIs) provide access to EBS for simple unstructured storage requirements. Townsend Security SDKs can easily be used to provide encryption at the application layer.

Amazon DynamoDB (NoSQL)
The AWS NoSQL implementation does not provide encryption services, but you can easily implement encryption at the application layer using the Townsend Security SDKs. With support for many programming languages you can implement the encryption and key management services you need to meet compliance regulations.

Application Databases:

Microsoft SQL Server
Alliance Key Manager includes a license for Townsend Security’s Key Connection for SQL Server application that supports Transparent Data Encryption (TDE) and Cell Level Encryption for Enterprise edition. This EKM provider installs in your Windows SQL Server environment and enables encryption without any programming. For SQL Server Standard and Web Editions Alliance Key Manager includes a license for the Townsend Security Windows Client for snap-in encryption support.

Oracle Database
Oracle Database encryption support is provided through SDKs that are free of charge with Alliance Key Manager. Java, Perl, PHP, Python, Ruby and C# SDKs and sample code enable rapid deployment of encryption in Oracle environments. Sample PL/SQL code is also available for Oracle Linux platforms.

MySQL, SQLite, PostgreSQL, etc.
Open source database encryption support is provided through SDKs that are free of charge with Alliance Key Manager. Java, Perl, PHP, Python, Ruby and C# SDKs and sample code enable rapid deployment of encryption in these environments.

Software SDKs for Amazon Web Services:

A rich set of application SDKs are available for many programming languages. These SDKs provide support for Java, Microsoft .NET languages (C#, VB.NET, etc.), Perl, Ruby, Python, PHP, and others. These SDKs are provided at no charge to Alliance Key Manager customers.

Application Plugins for Amazon Web Services:

Drupal Encryption and Key Management
Alliance Key Manager integrates naturally with the Drupal web CMS using the Drupal Encrypt module and Townsend Security’s Key Connection for Drupal module available on Drupal.org. Drupal users can retrieve encryption keys for use with local encryption, or use the Alliance Key Manager Encryption Service to encrypt and decrypt data in the key manager with NIST-validated AES encryption.

SQL Server Transparent Data Encryption
Alliance Key Manager integrates directly into the Microsoft SQL Server Enterprise edition database to provide Transparent Data Encryption (TDE) support using the Townsend Security Key Connection for SQL Server application.

SQL Server Cell Level Encryption
Alliance Key Manager integrates directly into the Microsoft SQL Server Enterprise edition database to provide Cell Level Encryption support using the Townsend Security Key Connection for SQL Server application.

Encryption & Key Management in AWS

Topics: Alliance Key Manager, Encryption, Key Management, Amazon Web Services (AWS)

Encryption: Do I Need Key Storage or Key Management?

Posted by Michelle Larson on Aug 4, 2014 11:48:00 AM

Is there more to encryption key management than just storing my encryption keys?

There is far more to encryption key management than just storing the encryption key somewhere… as it turns out, there is a whole encryption key lifecycle that is (or should be) handled by a certified encryption key management solution. Generally, a key storage device only provides storage of the encryption key, and you need to create the key elsewhere. Also, just storing your encryption keys “somewhere” doesn’t work very well for compliance regulations. With an encryption key manager, there is a whole set of management capabilities and a suite of functions that provide dual control, create separation of duties, implement two factor authentication, generate system logs, and perform audit activities, along with managing the key life cycle (including storage). There is a very real need, and very specific guidelines that require you to store and manage your encryption keys away from the data that they protect.

The Encryption Key Life Cycle

key lifecycle

Beyond storing the encryption key, a cryptographic key manager manages the entire key life cycle. Some of the most important functions the key management administrator performs are the actual creation and management of the encryption keys. The keys are generated and stored securely and then go through the full cycle to become active, go into use, expire, retire (post-activation), and then be backed up in escrow, and then deleted (the “destruction” phase). Let’s take a closer look at the phases of a key life cycle and what a key management solution should do during these phases:

Key Generation & Pre-Activation:
First, the encryption key is created and stored on the key management server (which can be a hardware security module (HSM), virtual environment (VMware) or a true cloud instance). The key can be created by a sole administrator or through dual control by two administrators. The key manager produces the AES key through the use of a cryptographically secure random bit generator and stores the key, along with all it’s attributes, into the key storage database (which is also encrypted). The attributes stored with the key include its name, activation date, size, instance, the ability for the key to be deleted, as well as its rollover, mirroring, and key access attributes. The key can be activated upon its creation or set to be activated automatically or manually at a later time. The key manager should also be able to create keys of three different sizes: 128, 192, or 256-bit. The encryption key manager should also track current and past instances, or versions, of the encryption key. You can also choose whether or not the key can be deleted, mirrored to a failover unit, and by which users or groups it can be accessed. Your key manager should allow the administrator to change many of the key’s attributes at any time.

Key Activation through Post-Activation:
The key manager should allow an activated key to be retrieved by authorized systems and users for encryption or decryption processes. It should also seamlessly manage current and past instances of the encryption key. For example, if a key is rolled every year and the version is updated, then the key manager should retain previous versions of the key but dispense only the current instance for encryption processes. Previous versions can still be retrieved in order to decrypt data encrypted with such versions of the key. The key manager should use transport layer security (TLS) connections to securely deliver the encryption key to the system and user requesting it, which prevents the key from being compromised. The encryption key manager will also expire the key either through a previously established schedule or manually by an administrator.

Key Expiration & Revocation (Escrow):
An administrator should be able to use the key manager to revoke or deactivate a key so that it is no longer used for encryption requests. In certain cases the key can continue to be used to decrypt data previously encrypted with it, like old backups, but even that can be restricted. A revoked key can, if needed, be reactivated by an administrator, although this would be more an exception to the rule than common practice.

Key Destruction:
If a key is no longer in use or if it has somehow been compromised, an administrator can choose to delete the key entirely from the key storage database of the encryption key manager. The key manager will remove it and all its instances, or just certain instances, completely and make the recovery of that key impossible (other than through a restore from a backup image). This should be available as an option if sensitive data is compromised in its encrypted state. If the key is deleted, the compromised data will be completely secure since it would be impossible to recreate the encryption key for that data.

Crypto Period:
This encryption key life cycle, which is defined by the National Institute of Standards and Technology (NIST), also requires that a crypto period be defined for each key.  A crypto period is the length of time that a key should be used and is determined by a number of factors based on how much data is being protected and how sensitive that data is. While NIST has defined and provided some parameters on how to establish crypto periods (see special publications 800-57 - there are 3 parts) and provided guidance on best practices. Each key management administrator needs to determine how long a particular encryption key should be actively used before it is rotated or retired.

These are a few of the factors that go into establishing the crypto period for a key (which maybe a few days or weeks or longer up to one or two years it really depends on the data that you're trying to protect):

  • How is the data being used
  • How much data is there
  • How sensitive is the data
  • How much damage will be done when the data is exposed or the keys are lost

You can see that there is a significant difference between a key storage device and an encryption key management solution. Remember to always look for NIST validated and FIPS 140-2 compliant solutions to meet compliance requirements and follow security best practices!

To learn more about encryption key management download our ebook on Encryption Key Management Simplified.

Encryption Key Management Simplified eBook 

Topics: Alliance Key Manager, Key Management, eBook, Encryption Key Management

Would You Pass a Data Security Audit? - Part 2 - Q&A

Posted by Michelle Larson on Dec 27, 2013 9:28:00 AM

Still Have Questions About Meeting Compliance Requirements?

The question “Would You Pass An Audit?” was posed in our last blog and companion webinar series.  We discussed compliance regulations and how protecting sensitive information was more than just a good security strategy. While the webinar title is directed at IBM i users, the content is really applicable to most all platforms! Hopefully you were able to watch the webinar resource provided (if not, you can request it HERE).  After the webinar, we had a number of questions asked by attendees and answered by security expert Patrick Townsend.  Here is a recap of that Q&A session:How-to-Guide Key Management Best Practices eBo

Q: If I have my sensitive data stored off site with a hosting company or in the cloud am I responsible if they have a data breach?

A: The short answer is yes you are. When you have sensitive data and are moving it into a cloud solution you are still ultimately responsible for protecting that data. This can be confusing because cloud vendors make a lot of statements about encryption and compliance, however you are responsible for your overall data protection strategy.  

When looking for a hosting vendor or to move applications outside of your environment, a part of the process should be assessing their ability to meet PCI or other compliance regulations. As part of your due diligence, ask for a QSA letter of attestation from a qualified QSA auditor to confirm the security of the infrastructure of that hosting company and that they are:

  • Securing the data center to PCI standards
  • Securing racks properly
  • Placing proper controls and vulnerability scans in place for their own infrastructure

It is your responsibility to make sure your data security meets compliance regulations. Any loss will also be your responsibility, so it is worth the time to make sure you have a strong strategy in place and are using industry standard encryption and proper key management to protect your data wherever it resides. 

Q: A vendor told me that tokenizing data will make us PCI compliant is this true?

A: This is a more complex question to answer. Tokenization is a great technology and there has been a lot of work done in this field the past few years.  Personally, I believe it can be done well and can help you meet compliance regulations.  If you are planning to generate non-recoverable tokens (when the original data does not need to be recovered) using a separate token server, that can eliminate the need to store the original data in an encrypted format. Non-recoverable tokens can help minimize the impact of regulations such as HIPAA, PCI, HITECH , GLBA and individual state privacy laws by taking the server out of scope for compliance.  However if you plan to recover the data and are consolidating sensitive information into the tokenization solution, you must make sure the tokenization solution itself is PCI compliant and using industry standard encryption such as AES when using recoverable tokens. The basic concept for tokenization is that you replace the data in your database with a token that has no value; however, sensitive data (for retrieval) has been transferred into the tokenization solution.  Because all of this sensitive information has been consolidated into one place, it becomes even more of a high value target.  Tokenization is very effective as long as you are using industry standard encryption within that solution and also using best practices for encryption key management.  Make sure you are using a tokenization solution that integrates with a NIST validated and FIPS 140-2 compliant key management solution that will properly store your encryption keys on a designated hardware security module (HSM) and not in the same server as the pool of data. 

Q: A vendor we are considering for key management advertises an integrated key management solution, would this be PCI compliant?  

A: Only a QSA auditor can determine PCI compliance of vendor solutions, however being educated on industry best practices is very important.

Storing the key within the same server where the data is located is not a defensible practice, and security best practices recommend using an HSM to store encryption keys away from the data you are protecting. Best practices for encryption key management also recommend that you implement separation of duties and dual control.  I highly recommend that you look for NIST validations and make sure the approach to encryption and key management has been done correctly.

To help you plan your data security strategy, we’ve created a great How-to-Guide on Encryption Best Practices and you can download your complimentary copy by clicking on the link below.   

Request the Key Management Best Practices How-to-Guide

As always, we welcome your questions and comments!


Topics: Key Management, eBook, Best Practices, Encryption Key Management, Webinar

Q&A: Secure Managed File Transfer and PGP Encryption

Posted by Michelle Larson on Nov 22, 2013 11:26:00 AM

Great Q&A session from the latest webinar from Townsend Security!

As we discussed in the blog on Secure Managed File Transfer and PGP Encryption, using the core components of a total encryption strategy can help you meet compliance requirements, and improve your data security posture!Click to view Secure Managed File Transfer Webinar for IBM i users

Hopefully you were able to watch the webinar resource provided (if not, you can request it HERE). After the webinar, we had a number of questions asked by attendees and answered by security expert Patrick Townsend.  Here is a recap of that Q&A session:

Q: Is there any reason why I can’t just transfer my file from my IBM i platform to Windows and then PGP encrypt it there.

Patrick: That is a great compliance question.  Transferring unencrypted data from your IBM i to a Windows platform and then encrypting it and moving it from there will put you out of compliance for PCI DSS.  You should not transfer unprotected data to any system or across any network that’s not fully protected.  If you move it from the IBM i platform to Windows platform, it’s going to land in an unencrypted format and that will put you out of compliance.  That kind of unprotected transfer will also put you out of best practices alignment in terms of just pure security.  The security principle here that comes into play is always encrypt at the source, decrypt at the target or the destination, and don’t let the data be unprotected in-between.  Remember, data should never be moved “in the clear”.

Q: Can manage file transfer software be used on just one side, or do all sides of the transfer have to have the same software?

Patrick:  Partners/customers would certainly want a managed file transfer solution to be based on open standards.  You would not want to install proprietary software to process file transfers and then expect your partners to have to install it as well.  We base all of our secure transfer encryption components on open standards like a SSL FTP and Secure Shell sFTP and PGP encryption.  This means is that right out-of-the-box you will interoperate with all the major financial institutions and insurance agencies.  

Q: Does the Alliance FTP Manager solution run on the IBM i or Windows server?

Patrick:  Alliance FTP Manager is a fully native IBM i application.  It runs strictly on the IBM i platform and uses industry standard protocols. So there is no proprietary component on Alliance FTP Manager where you would have to distribute special software to someone who is receiving the files in order to process them.  We use industry standard pipeline encryption SSL FTP and Secure Shell sFTP.  No matter who you’re transferring data to, whether its Windows, Linux, UNIX ,or IBM Mainframe, there are multiple readily available solutions that support those secure file transfer protocols.  The commercial PGP that we provide is fully compatible with industry standards, it interoperates seamlessly, and we test it against multiple other PGP solutions as well as open PGP solutions.  Your customers and vendors (the people you’re transferring the data to) will appreciate that they do not need special software to process PGP encrypted files or your Alliance FTP Manager transfers.

Q: We occasionally need to create encrypted zip files to transfer files to our customers, can FTP manager do this?

Patrick:  We certainly do provide a command based zip file encryption and zip file decryption (compression and decompression) that implements 256-bit AES encryption.  It will process with wildcards and so if you have multiple files in an IFS directory you can compress all those into one zip archive.  Our directory scan automation component will automatically process data right into your application. So yes, there is an implementation of secure encrypted zip in FTP Manager.  

Q: A public/private key pair is needed for SSH and sFTP transfers. Does FTP Manager exchange keys with the destination server?

Patrick:  Secure Shell sFTP supports a number of authentication and privacy mechanisms, the most common is using a public and private key pair.  You do have to execute a key exchange with your training partner/bank before exchanging encrypted data. We have developed utilities and interactive options to help you load your trading partners public key on the IBM i platform.  For example, a menu option will allow you to put in the DNS name for that particular server, then it will find, retrieve, and install that key in your system.  Normally these steps are time and labor intensive, but we have automated the exchange to simplify that particular administrative setup function.
Very important: Typically sFTP transfers use public and private keys, just be sure that the solution you choose can also handle password authentication. Alliance FTP Manager CAN do that!

To learn more, view the complete webinar - Secure Managed File Transfer on the IBM I -which examines the security principles, compliance requirements, and technical challenges for secure FTP transfers on the IBM i platform with the following objectives:

  • Automatically transfer files using Secure Shell sFTP or Secure SSL FTP
  • Protect data using strong PGP encryption
  • Review your total encryption strategy
Webinar: Secure Managed File Transfer on IBM i

 

If you have further questions, please list them here in the comment section and we will be sure to get you an answer!

Topics: Encryption, Alliance FTP Manager, Key Management, Secure Managed File Transfer, FTP Manager for IBM i, SFTP

What is Encryption Key Management?

Posted by Victor Oprescu on Jul 15, 2013 2:46:00 PM

Key Lifecycle & Rotation Explained

Encryption key management refers to the ability of a system to administer an encryption key through the length of its crypto-cycle. From the creation of a key, through it’s use, and eventually to its deletion, an encryption key management system needs to be able to securely and efficiently handle the encryption keys. I will talk a little about each major part of the encryption key lifecycle and how our Alliance Key Manager manages and administers the key throughout the lifecycle.

eBook - Encryption Key Management Simplified

Key Creation: First, the encryption key is created and stored on the key manager server. The key can be created by a sole administrator or through dual control by two administrators. Townsend Security’s Alliance Key Manager creates the AES key through the use of a cryptographically secure random bit generator and stores the key, along with all it’s attributes, into the key database (which is also encrypted). The attributes stored with the key include its name, activation date, size, instance, the ability for the key to be deleted, as well as its rollover, mirroring, and key access attributes. The key can be activated upon its creation or set to be activated automatically or manually at a later time. Alliance Key Manager can also create keys of three different sizes: 128, 192, or 256-bit. The encryption key manager also tracks current and past instances, or versions, of the encryption key. You can also choose whether or not the key can be deleted, mirrored to a failover unit, and by which users or groups it can be accessed. Alliance Key Manager also allows the change of many of the key’s attributes at any time.

Key Use and Roll: Alliance Key Manager will allow an activated key to be retrieved by authorized systems and users for encryption or decryption processes. It also manages current and past instances of the key. For example, if a key is rolled every year and the version is updated, then the key manager will retain previous versions of the key but will dispense only the current instance for encryption processes. Previous versions can still be retrieved in order to decrypt data encrypted with such versions of the key. Alliance Key Manager also uses transport layer security (TLS) connections to securely deliver the encryption key to the system and user requesting it, which prevents the key from being compromised. The encryption key manager will also roll the key either through a previously established schedule or manually by an administrator.

encryption key managementKey Revocation: An administrator can use Alliance Key Manager to revoke or deactivate a key so that it is no longer used for encryption requests. In certain cases the key can continue to be used to decrypt data previously encrypted with it, like old backups, but even that can be restricted. A revoked key can, if needed, be reactivated by an administrator, although this would be more an exception to the rule than common practice.

Key Deletion: If a key is no longer in use or if it has somehow been compromised, an administrator can choose to delete the key entirely from the key database of the encryption key manager. Alliance Key Manager will remove it and all its instances, or just certain instances, completely and make the recovery of that key impossible (other than through a backup). This is also an option if sensitive data is compromised in its encrypted state. If the key is deleted, the compromised data will be completely secure since it would be impossible to recreate the encryption key for that data.

To learn more about encryption key management, download our ebook, "Encryption Key Management Simplified.”

Encryption Key Management Simplified eBook

Topics: Alliance Key Manager, Key Management, eBook, Encryption Key Management

Data Gets Out. Encrypt It!

Posted by Michelle Larson on Jul 1, 2013 7:43:00 AM

What exactly is data security and encryption & key management, and why care about it? 

Interesting conversation this morning as I walked from the parking lot to my office building.  Another person from one of the eight companies that occupy this building and I walked in together and chatted... first it was just “looks like the weather is getting better”... then it moved to “what floor are you on?  what company?” and when I told her ‘Townsend Security’, she said “oh, I’ve always wondered what you folks do”...

Data Gets Out

As the newest staff member, I wasn’t sure I had perfected my 30 second elevator pitch, but I told her that we were a data encryption company and design the software (and provide hardware) that almost everyone needs to protect themselves from a data breach. At first her response was “oh, we don’t need that, we have a guy that takes care of our computers”. Then we talked about how high the statistics are for people who would experience a data breach ("In 2010, if you received a data breach notification, your odds of being a fraud victim were one in nine. Last year, that jumped to one in four."), and after asking if they had a database and if they kept any records that held personally identifiable information (PII) or credit cards, it quickly became “I think we need that!”.

It reminded me that when I started working here, I wasn’t fully aware of many of the reasons or regulations that make data encryption so important.  I’m not sure I will ever have a complete technical understanding of all the nuances, but I’m working on it... Luckily I work with incredibly brilliant people who daily do all of the hard programming work and are very passionate about encryption.

I am lucky enough to be working with a company that I believe in, doing work that I know is important and can really make a difference in peoples lives. One of the main reasons I love this job... all the wonderful people that I work with, people so passionate about data security and the positive impact we can have on other people’s lives!

Key Management Kit

The founder, Patrick Townsend, impressed me so much at our last staff meeting when he reminded everyone to really think about why we are here, why we do what we do.  “It isn’t about selling a product.  It isn’t about the bottom line.  It is about protecting people from the devastation that a data breach can have on their individual lives.  It is about making sure we help companies protect their customers and clients.  It is about stopping the bad guys from wrecking havoc by making it impossible for them to get what they are after.  That is why we are here, remember that”.

Think about what your company does with the data you collect.  Is it encrypted and secure when it is “data at rest” (just sitting on your server)? How about when it is “data in motion” (being transferred to someone else)?  Look into what is happening with your information, and if you depend on someone else to take care of it, make sure they are doing it right.

Data gets out. Period. Either by accident or by design (someone hacking into your information). Make sure that when it does get out (and unfortunately it is “when”, not “if”) that it can’t be read.  You can make that data useless by encrypting it.   Remember to keep the encryption key stored in a different location than the data (encryption key management 101) because you wouldn’t lock up your house and then tape the key to the front door or leave it under the welcome mat!...  Would you?

If you aren’t sure what encryption or key management is all about.  We have a wonderful resource section on our website, and I’ve gathered a collection of some great Key Management resources right here.

 Request Resource Kit Here

Check out the information we have on data security and encryption key management and then contact us with questions, we are here to help!

Topics: Encryption, Key Management, Best Practices, Encryption Key Management, Business Risk

Three Most FAQs About Encryption Key Management on the IBM i

Posted by Michelle Larson on Jun 18, 2013 2:10:00 PM

The way organizations are managing encryption keys is falling under more scrutiny by Payment Card Industry (PCI) Qualified Security Assessor (QSA) auditors.  Companies must demonstrate they are enforcing dual control and separation of duties in order to protect sensitive data. eBook - Encryption Key Management Simplified

Here are the answers to three of our most frequently asked questions about encryption key management on the IBM i:

Is it still effective to use an integrated key management solution that stores encryption keys in the same partition as the encrypted data?  
The short and simple answer is No. There are many reasons why storing an encryption key on the same server that contains protected data is not advisable. This is not just an IBM i issue - it spans all of the current major operating systems. Let's explore this a bit more in the following sections.

How do IBM i users manage encryption keys according to PCI requirements with an encryption key manager?
Payment Card Industry - Data Security Standards (PCI DSS) requirement states the following requirements for encryption key management:

  • Dual Control means that at least two people should be required to authenticate before performing critical key management tasks.

  • Separation of Duties means that the individuals managing encryption keys should not have access to protected data such as credit cards, and those that have access to protected data should not have the authority to manage encryption keys.

How are the “dual control” and “separation of duties” requirements achieved on IBM i?
On the IBM i you simply can't achieve these PCI requirements if you store the encryption key in the same partition as the protected data.  

The QSECOFR user profile (and any user profile with *ALLOBJ authority) will always have complete access to every asset on the system.  An *ALLOBJ  user can circumvent controls by changing another user's password, replacing master keys and key encryption keys, changing and/or 
deleting system logs, managing validation lists, and directly accessing database files that contain encrypted data.  

From the perspective of PCI, an integrated key management system puts too much control into the hands of any one single individual.
The only way to comply with PCI requirements for key management is to store the encryption keys off of the IBM i.  Take users with *ALLOBJ authority out of the picture completely.  When you use a separate appliance to manage encryption keys you can grant a user access to the protected data on the IBM i and deny that same user access to the key manager.  Now you have enforced separation of duties.  And with the right key management appliance you can require TWO users to authenticate before keys can be managed, and have dual control of encryption keys.

Now it’s time to ask yourself a few questions!

  • Is your organization encrypting data on IBM i?  

    • If so, how are you managing the encryption keys?

  • If you store the keys on a separate partition, have you had a recent PCI audit?  

    • What did your auditor say?

Download the eBook: Key Management SimplifiedIf you aren’t sure of the answers, or if this still seems foreign to you, take a few minutes to download our eBook "Encryption Key Management Simplified”.

Whether you are an IT administrator or a business executive, this resource will help you learn the fundamentals of:

  • What is encryption key management

  • Key management best practices

  • How to meet compliance regulations (PCI-DSS, HIPAA/HITECH, GLBA/FFIEC, etc.) with encryption key management

  • How encryption key management works on every platform including Microsoft SQL Server '08/'12, Oracle, and IBM i

  As always, we welcome your comments and suggestions!  Let us know what you think of the eBook! 


Topics: Key Management, Separation of Duties, IBM i, Encryption Key Management, Dual Control

.NET Encryption and Key Management

Posted by Patrick Townsend on Aug 13, 2012 10:29:00 AM

Key Management in the Multi-Platform Environment

encryption key management white paper

Download the white paper "Key Management in the Multi-Platform Environment"

Click Here to Download Now

If you have Microsoft SQL Server with Extensible Key Management (EKM), the implementation of encryption and key retrieval with Alliance Key Manager, our encryption key management Hardware Security Module (HSM) is easy. Our HSM comes with the Windows EKM Provider software that you install, configure and deploy.  Problem solved.

But what if you have a significant investment in Microsoft applications that don’t support EKM?

For example, you might have applications built on SQL Server 2005 or SQL Server 2008/2012 Standard Edition which do not support EKM. You could upgrade to SQL Server 2008 R2 or SQL Server 2012, but there might be application roadblocks that prevent the upgrade right now.

Or, you might have applications written in a .NET language that update non-Microsoft databases, or which work with unstructured data.

These technical hurdles won’t stop you from using our encryption key manager to meet compliance requirements for protecting encryption keys. We provide a .NET Assembly and DLL that you can add to your .NET project to retrieve encryption keys from the HSM. A few lines of C# code and you are retrieving the encryption key from the HSM, and the problem is solved.

The sample code on the product CD will get you up and running quickly. There are C# sample applications with source code that you can use as a starting point in your projects. The Alliance Key Manager .NET Assembly works with any .NET language including C#, C, and C++.

The Alliance Key Manager .NET Assembly also works with the Common Language Runtime (CLR) environment, and with Stored Procedures. And you can mix and match your .NET languages, databases, and OS platforms.

The combination of automatic encryption (EKM, TDE, Cell Level Encryption) with the Alliance Key Manager .NET Assembly code means that you won’t have any gaps in your coverage of your Microsoft platforms.  Download our white paper "Key Management in the Multi-Platform Environment" for more information on securing your encryption keys.

Happy coding!

Patrick

Click me

Topics: Alliance Key Manager, Encryption, Key Management, Extensible Key Management (EKM), C#, Microsoft, .NET, SQL Server

Data Privacy for the Non-Technical Person Part 1

Posted by Luke Probasco on Aug 26, 2011 3:54:00 PM

data privacyAs I attend industry events, it is surprising how many times we hear questions like “what constitutes personal information that needs to be protected?”  I recently sat down with Patrick Townsend, our Founder and CTO to discuss data privacy for the non-technical person. 

When speaking about data privacy, the conversation often turns technical with common questions like “How do we implement encryption and encryption key management?”  This time, we intentionally kept our conversation focused on data privacy topics that can be understood from a high-level. 

I have created a series of blog posts from this conversation that will be posted in the next couple weeks.  Hopefully this blog series will answer any questions that you might have.  If you still have questions, feel free to send us an email.

What constitutes personal information that needs to be protected?

The first thing that everyone thinks of are credit cards numbers.  We know that we don’t want our credit card numbers escaping into the wild and having to go through the process of replacing them.  I think that by now, most people have experienced getting a call from their bank, being alerted to potential fraud, and going through the process of having to replace a card.  So credit card numbers are obviously personal information that people need to protect.

There are also other things that I think are important – financial bank account numbers.  We are all doing a little bit more now in terms of online banking.  Those bank account numbers carry value and we need to be very careful about that.  There are also some other items that tend to be used to commit financial fraud, such as social security numbers, driver’s license numbers, birthdate, etc.  In fact, information like your passport number, military ID, or health ID – all of those are examples of information that you should try and protect and make sure you are not sending them around or leaving them in places that can be easily picked up.

Other things like maiden name or previous addresses are also important.  Think about the types of questions your bank asks you when you give them a call.  They are using that information to identify you and the fraudsters will use that information to impersonate you.  These are all examples of sensitive information that we should be protecting.  For people who are interested, the technical term for this type if information is Personally Identifiable Information or PII.

Stay tuned for our next installment in this series.  Download our podcast “Data Privacy for the Non-Technical Person” to hear more of this conversation.


Click me

Topics: Encryption, Key Management, Data Privacy

10 Questions to Ask Your Key Management Vendor

Posted by Luke Probasco on Mar 29, 2011 8:14:00 AM

key managementThe modern Enterprise deploys a variety of server platforms, operating systems, and programming languages.  A major barrier to deploying encryption has been the challenge of accessing encryption keys from these widely divergent environments.  Encryption key management solutions have the primary goal of managing and protecting encryption keys, and making them available to authorized applications in a secure fashion.


Key management solutions vary greatly in the complexity of the key retrieval process. The more complex the key retrieval interface, the greater the challenge for the Enterprise IT team in deploying key retrieval in applications. Understanding this fact can help IT decision makers assess different vendor solutions and the likely costs of deploying a solution in their enterprise.  Below is a list of questions that you should ask your key management vendor when assessing their solution.


Key Management Vendor Checklist

1.  Is your key manager FIPS 140 certified?  What is the certificate number?

2.  How would you describe the encryption key payload as retrieved from the key server?  Is it simple or complex?

3.  Is there a common key retrieval application interface on all platforms?  What are the differences?

4.  What platforms do you support for key retrieval?  (Note any gaps in platform coverage for your company)

5.  Do you provide working sample code for the platforms I need? (Windows, Linux, UNIX, IBM i, IBM z)

6.  Do you supply binary libraries for all Enterprise servers?

7.  Do you have a Java key retrieval class and examples? Is it standard Java or JNI?

8.  Do you charge separate license fees for each client operating system?

9.  Do you require that we purchase consulting services from you?  Why?

10.  I am an independent software vendor (ISV), can you brand the solution and certify the solution for us?
 
Once you have the answer to the above questions, it should be easier to choose the right key management vendor for your Enterprise. If you have any questions, click here and we will call you right back.


 Click me

Topics: Alliance Key Manager, NIST, Key Management, encryption key

Blog-CTA-VMware-CSP
 
The Definitive Guide to AWS Encryption Key Management
 
Definitive Guide to VMware Encryption & Key Management
 

 
 

Subscribe to Email Updates

Recent Posts

Posts by Topic

see all