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

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!


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

Key Management Best Practices: What New PCI Regulations Say

Posted by Luke Probasco on Mar 24, 2011 1:25:00 PM
key managementThe new PCI Data Security Standards (PCI DSS v2.0) are here and we’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. I recently sat down with Patrick Townsend, Founder & CTO of Townsend Security, to discuss the new PCI regulations in regards to encryption key management.  To hear an expanded podcast of our conversation, click here.


What is the source of industry best practices for key management?


The NIST special publication SP-800-57 provides specific pointers on 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.

Also, key management solutions are certified to the FIPS-140-2 standard for cryptographic modules. So FIPS-140 is a source of best practices and standards.


Dual control, separation of duties, and split knowledge have been buzz topics in the key management world lately.  What do they mean?


Well, 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.


Split knowledge is defined in the PCI DSS version 2.0 glossary as a “condition in which two or more entities separately have key components that individually convey no knowledge of the resultant cryptography key.”


Are there any standards or best practices regarding “integrated key management?”


“Integrated key management” is a term of art, and not a standard.  If “integrated key management” means “we store our encryption keys on the server where the data is,” then that is a bad thing, from a compliance and security point of view. 


So, what are the best practices for encryption key management?


First you should follow the key life-cycle and be able to document it.  You should always separate the keys from the data.  If you follow the PCI guidelines, you are in excellent shape.  Finally, I would recommend only using a FIPS 140 certified key management solution.


What are the practical implications of these best practices and core concepts such as “dual control” and “separation of duties?”


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 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 high level of authority! You just can’t meet PCI and other industry standards for proper key management by storing the encryption keys on the same platform as the data you are trying to protect.


To download an expanded podcast of our conversation, click here.


Topics: Key Management, PCI DSS, Best Practices

Data Privacy in a De-Perimeterized World

Posted by Patrick Townsend on Feb 25, 2011 8:33:00 AM
De-perimeterizationI just listened to a discussion of database security hosted by Oracle that was very well done. At one point the discussion turned to current threats and how the Enterprise has lost the ability to use perimeter protection for sensitive data. This has been a topic of much discussion in the security area for the last few months. Perimeter protection is based on the use of Firewall and similar technologies to keep the bad guys out, but this approach is failing with the advance of more sophisticated attacks, the use of social media by large organizations, the advance of mobile technologies, insider threats, and the migration of applications to cloud platforms. The trend is called “de-perimeterization” and represents a bit of a challenge to organizations that need to protect sensitive data.

Vipin Samir and Nishant Kaushik did a great job of describing the how the process of de-perimeterization has forced companies to fall back on user access controls to protect data. But user access controls are notoriously weak.  Weak passwords and sophisticated password cracking routines make it almost impossible to properly secure a database. So what is a security administrator to do?

Here are the suggestions from the panel that are a part of a defense-in-depth strategy:

Use Encryption to Protect Data:
Companies should use encryption at the database level or column level to protect data. This will secure data at rest on backup tapes and on disk in the event a drive is replaced. Encryption is an important part of the data protection strategy, but it needs to be combined with other techniques.

Use Good Key Management:
Protecting encryption keys is the most important part of the encryption strategy. Good key management techniques are needed, and the keys must be separated from the data they protect. Without this separation from protected data it is impossible to implement separation of duties and dual control – important parts of the key management strategy. See our Alliance Key Manager solution for more information about securing encryption keys.

Separation of Duties:
Because the threat from insiders is rising, it is important that the management of encryption keys be separate from the management of databases. Database administrators responsible for our relational databases should not have access to encryption key management, and security administrators should not manage databases. This is a core principal in data security regulations such as PCI DSS, but is often overlooked.

Context Sensitive Controls and Monitoring:
The last important step is to be sure that data access controls are sensitive to the data and its context. Bill in shipping has access to the order database, but should he really be decrypting the credit card number? Does your encryption solution detect and block this type of event? How will you monitor this security event? Or, Sally is authorized to view HR data from the accounting application, but should she really be using FTP to transfer this data? Normal encryption functions would not provide adequate protection from these types of data access. Context sensitive controls are needed to augment encryption.

When we started planning for automatic encryption in our Alliance AES/400 product two years ago, we took care to implement context sensitive controls right in the decryption APIs. That is now available in V7R1 of the IBM i operating system. We avoided the error of basing these controls on user account authorities and native OS security. Just because the operating system says you have read access rights to a database table, doesn’t mean you should be decrypting the social security number or using FTP to transfer the file. I’m happy with our implementation that is based on explicit authorization by a security administrator, and application white lists.

You can get more information and request an evaluation version of our Alliance AES/400 solution here.

You can find the Oracle presentation here. Look for “How secure is your Enterprise Application Data?”


Topics: Key Management, De-Perimeterization, Oracle, Separation of Duties, Alliance AES/400, Encryption Key Management, Defense-in-Depth, automatic encryption, AES Encryption

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