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

Paul Taylor

Recent Posts

Securing FieldShield Encryption Keys with Alliance Key Manager

Posted by Paul Taylor on Dec 13, 2019 10:28:00 AM

The article below originally appeared on IRI's blog and is being re-published here to show Townsend Security's blog readers how Alliance Key Manager integrates with IRI FieldShield.

In a previous article, we detailed a method for securing the encryption keys (passphrases) used in IRI FieldShield data masking jobs through the Azure Key Vault. There is now another, even more robust option for encryption key management available, thanks to API-level integration between FieldShield and the Alliance Key Manager (AKM) platform from Townsend Security.

AKM provides the security of authenticated access to FieldShield passphrases from five different server options (below). They assure that only authorized users can access the AKM key server and obtain the keys to decrypt FieldShield-encrypted field data (column values).

But beyond authentication, AKM provides a complete encryption key management solution which includes: key server setup and configuration, key lifecycle administration, secure key storage, key import/export, key access control, server mirroring, and backup/restore. AKM also supports compliance audit logging of all server, key access and configuration functions.

How AKM Works with FieldShield

AKM is leveraged directly in FieldShield data masking jobs through field syntax that specifies the use of AKM. This syntax is “AKM:KeyName”, where “AKM:” invokes the use of the Alliance Key Manager, and “KeyName” (an example key name created by AKM but could be anything) is the name of a key created by AKM from which the value you want will be accessed.

In a FieldShield decryption job, key retrieval from AKM is performed via a secure TLS connection to the AKM server. Both the client (FieldShield user) and server (AKM) end-points are authenticated via TLS.

AKM can be deployed in: 1) VMware; 2) a cloud server in Microsoft Azure; 3) Amazon Web Services; 4) a privately managed Hardware Security Module (HSM); or, 5) a dedicated cloud HSM.

Setting Up

Prerequisites for using AKM to manage encryption key passphrases in FieldShield are:

  • A compatible Linux OS (a Windows version is planned)
  • A licensed IRI FieldShield installation for Linux under /usr/local/cosort
  • An AKM instance with connectivity to the Linux OS
  • A .conf file configured with the proper details to connect to AKM from the Linux OS
  • The Alliance Key Manager Linux SDK

To run FieldShield, obtain and install license keys from IRI. To run AKM, obtain a license from Townsend Security.

You will need to create a configuration (.conf) file to provide the connection information for AKM. The file includes the locations of certificates, logging options, and AKM connection properties.

The configuration file must be specified correctly, placed in the /usr/local/cosort/etc directory, and called keyclient.conf in order for key retrieval to succeed. Once that’s done, AKM will be accessible and work properly from any of the 5 deployment methods listed above.

You will also need to download the AKM Linux SDK. It contains the packages used to install the Linux libraries for AKM key retrieval used in FieldShield, and a sample keyclient.conf file (shown later).


The AKM Linux SDK

FieldShield makes use of shared libraries provided by Townsend Security to integrate with AKM. More specifically, FieldShield uses the Linux C SDK, which provides tools for integrating C applications with AKM in Linux.

There are debian (or rpm, depending on Linux distribution) packages within the packages directory of the Linux directory of the Linux SDK that must be installed on your system for the FieldShield-AKM integration to work. Confirm (or put) the shared object library (.so file) in the /usr/lib directory.

The AKM Linux SDK contains packages for the following Linux platforms:

  • RHEL/CentOS 4, 5, 6, 7
  • SLE 11 SP2, SP3, SP4
  • Ubuntu 12.04, 14.04, 16.04

The Ubuntu 16.04 package in the AKM Linux SDK was tested and confirmed to work on Ubuntu 18.04.

Configuring AKM for FieldShield Use

AKM can be deployed in a variety of ways, including through cloud computing providers and local virtual machines. To setup AKM initially, follow the instructions in the documentation and log-in to the administrative menu to initialize AKM and create and manage certificates for user authentication.


The AKM instance has a key server at port 6001, a port for key retrieval at port 6000, and a web interface at port 3886. This information must be put into the .conf file so that FieldShield can find the AKM and retrieve the key at decryption time.

After logging in to AKM, the IP address of the AKM instance can be found by typing ifconfig:


Again, the default port is 6000 for AKM key retrieval. This should be written in the .conf file like this:




Where IP is the IP address of the AKM, and Port is the port number used for key retrieval. For example:





A complete .conf file could look something like this:


; Configuration file for Universal Key Retrieval API
[log] Syslog=2 ; syslog output enabled StdErr=2 ; stderr output enabled
ConnectTimeoutSecs=5 ; timeout value in seconds
ConnectTimeoutMSecs=0 ; timeout value in milliseconds
VerifyDepth=1 ; certificate verify depth
; CA Signed Cert directory
TrustedCACert=/home/devon/Downloads/AKMPrimary_user_20191021/PEM/AKMRootCACertificate.pem ;
CA Signed Cert (root cert)

; Client Private key
; Client Signed certificate


AKM Web Interface (webmin)

The AKM Server web interface (or webmin) monitors AKM performance and login or access attempts, and allows access to the AKM file browser. Many settings can be modified through a secure web interface:

webmin_AKMDashboard menu in the AKM ‘webmin’ web interface

From the file manager in the web interface, full file system access to AKM is available. In the /home/admin/downloads directory, all certificates and private keys should be available in zipped folders.

The certificates and private key should be in the .pem format and stored in the pem folder within the zip folder with the name of the user (rather than the admin1 or admin2 folders). The date value is the day of the month that the folder was created during initialization of the AKM server.

There is also the ability to access logs from AKM, set logging options and IP access control for the web interface, start/stop AKM, enable two-factor authentication for the web interface, check running processes in AKM, and more, all from within webmin.

Creating and Using FieldShield Keys

AKM provides options for creating, securing, and managing encryption keys through the AKM Administrative (Admin) Console app for Windows. Consult the AKM Crypto Officer documentation for current information on creating keys through the AKM Admin console app.

FieldShield only supports 256-bit symmetric keys from AKM, known as AES256 keys. This provides the best combination of security and performance.


Otherwise, select the rest of the options as desired and click the submit button to generate an encryption key. The output should be similar to this:


Alternatively, when initializing AKM, a set of encryption keys can be automatically generated. A prompt appears at AKM initialization asking if an initial set of encryption keys should be generated or not.

The encryption keys you create in AKM at initialization, or through the AKM Admin Console application, will serve as passphrase values in FieldShield target /FIELD specifications that encrypt or decrypt values at the field or column level. For example, this statement:

/FIELD=(Encrypted_CCN=enc_aes256_fp_alphanum(CCN, AKM:AES256), TYPE=NUMERIC, POSITION=12, SEPARATOR=”|”, ODEF=CCAcctNum)


will encrypt the CCAcctNum in the 12th column of the source database table with 256-bit AES alphanumeric format-preserving encryption using the key created inside AKM under the name AES256.

What’s actually happening? FieldShield will use a base64-encoded stream of characters (a key value) retrieved (derived) from AKM that are associated with that AKM key name. That stream then gets used by FieldShield as a new passphrase value. 

It’s that new passphrase value that is then used by FieldShield (like before AKM) to derive the actual encrypt/decrypt key used at FieldShield runtime. So in other words, AKM involves a double derivation.  

If you want to use a different AKM key name in another /FIELD statement to differentiate your encrypt/decrypt keys, use the AKM Admin Console to create another key under a different name. Reflect that new name into your FieldShield job script in the appropriate /FIELD statement.

To decrypt in this case, a corresponding decryption statement in a subsequent FieldShield job script would need to specify the dec_aes256_fp_alphnum function with the same passphrase to restore the original CCAcctNum value. This method will work with any FieldShield-included encryption or decryption algorithm.

Example Operation

Here is a look at the FieldShield encrypt (left) and decrypt (right) job scripts used:



Note the syntax for specifying AKM use, which is “AKM:KeyName”. Make sure that the key name is properly spelled. Key names that do not exist on the connected AKM instance will result in a Tcpconnect error. 

AKM will attempt to retrieve the key 5 times, each with a timeout of 5 seconds, as specified in the default .conf file. If the key is ultimately unable to be retrieved, then the job will not run. 

Here is an image of data from this example that FieldShield encrypted using AKM:


Here is an image of the data after running FieldShield and the key in AKM to decrypt it:



The bottom line: Using AKM to store the passphrases used for decrypting data in FieldShield dramatically enhances encryption key security and industry compliance levels for data masking operations. Through key authentication and secure key management facilities, AKM can help FieldShield users close off more potential gaps in enterprise data security.

Topics: Alliance Key Manager, IRI FieldShield

Why You Should be Continuously Delivering Drupal Updates - All the Time

Posted by Paul Taylor on May 9, 2016 7:35:00 AM

This is a special blog post written for Townsend Security by the Drupal Drop Guard team.

While developing a system to automate Drupal updates and using that technology to fulfill our Drupal support contracts, we ran into many issues and questions about the workflows that integrate the update process into our overall development and deployment cycles. In this blog post, we’ll outline the best practices for handling different update types with different deployment processes – as well as the results thereof.

The general deployment workflow
Most professional Drupal developers work in a dev-stage-live environment. Using feature branches has become a valuable best-practice for deploying new features and hotfixes separately from the other features developed in the dev branch. Feature branches foster continuous delivery, although it does require additional infrastructure to test feature branches in separate instances. Let us sum up the development activity of the different branches.

Drop guard workflow

This is where the development of new features happens and where the development team commits their code (or in a derived feature branch). When using feature branches, the dev branch is considered stable; features can be deployed forward separately. Nevertheless, the dev branch is there to test the integration of your locally developed changes with the code contributions of other developers, even if the current code of the dev branch hasn’t passed quality assurance. Before going live, the dev branch will be merged into the stage branch to be ready for quality assurance.

The stage branch is where code that’s about to be released (merged to the master branch and deployed to the live site) is thoroughly tested; it’s where the quality assurance happens. If the stage branch is bug-free, it will be merged into the master branch, which is the code base for the live site. The stage branch is the branch where customer acceptance happens.

The master branch contains the code base that serves the live site. No active changes happen here except hotfixes.

Hotfix branches
Hotfixes are changes applied to different environments without passing through the whole dev-stage-live development cycle. Hotfixes are handled in the same way as feature branches but with one difference: whereas feature branches start from the HEAD of the dev branch, a hotfix branch starts from the branch of the environment that requires the hotfix. In terms of security, a highly critical security update simply comes too late if it needs to go through the complete development cycle from dev to live. The same applies if there’s a bug on the live server that needs to be fixed immediately. Hotfix branches need to be merged back to the branches from which they were derived and all previous branches (e.g. if the hotfix branch was created from the master branch, it needs to be merged back to the master to bring all commits to the live site, and then it needs to be merged back to the stage and dev branch as well, so that all code changes are available for the development team)

Where to commit Drupal updates in the development workflow?
To answer this question we need to consider different types of updates. Security updates (including their criticality) and non-security updates (bug fixes and new features).

If we group them by priority we can derive the branches to which they need to be committed and also the duration of a deployment cycle. If you work in an continuous delivery environment, where you ship code continuously,the best way is to use feature branches derived from the dev branch.

Drupal Drop Guard

Low (<=1 month):
- Bug fix updates - Feature updates

These updates should be committed by the development team and analysed for side effects. It’s still important to process these low-prio updates, as high-prio updates assume all previous code changes from earlier updates. You might miss some important quality assurance during high-prio updates to a module that hasn’t been updated for a long time.

Medium (<5 days):
- Security updates that are not critical and not highly critical

These updates should be applied in due time, as they’re related to the site's security. Since they’re not highly critical, we might decide to commit them on the stage branch and send a notification to the project lead, the quality assurance team or directly to you customer (depending on your SLA). Then, as soon as they’ve confirmed that the site works correctly, these updates will be merged to the master branch and back to stage and dev.

High (<4 hours):
- Critical and highly critical security updates

For critical and highly critical security updates we follow a "security first" strategy, ensuring that all critical security updates are applied immediately and as quickly as possible to keep the site secure. If there are bugs, we’ll fix them later! This strategy instructs us to apply updates directly to the master branch. Once the live site has been updated with the code from the master branch, we merge the updates back to the stage and dev branch. This is how we protected all our sites from Drupalgeddon in less than two hours!

Updates automation options
There are only a few ways to ensure the updates will be applied just in time and when it’s really needed, depending on the type of update. Any of those have positive and negative sides, and it’s only up to you to choose what suites you the best:

  1. Monitoring for updates manually or via one of available services or custom scripts, and once the security update is detected, process it according to the workflow defined in your organization. This approach works in most cases, but it requires someone to be ready to take action 24/7;
  2. Building a completely custom solution, which will not only detect updates, but also take care of applying them when it’s time. The only obvious drawback of this is that you have to spend a lot of time building and maintaining your custom tool.
  3. Using the updates automation service, such as Drop Guard, which will integrate seamlessly in your workflow and process updates in exactly the way you want. You don’t have to worry about being alerted all the time, or spending too much time on building your own solution, but be prepared to spend a few dollars on the 3rd party solution.

Requirements for automation
If you want to automate your Drupal security updates with the Drop Guard service, all you need is the following:

  • Code deployment with GIT
  • Trigger the update of an instance by URL using e.g. Travis.ci, Jenkins CI, DeployHQ or other services to manage your deployment or alternatively execute SSH commands from the Drop Guard server.

Also to keep in mind:

  • Know what patches you’ve applied and don't forget to re-apply them during the update process (Drop Guard helps with its automated patch detection feature)
  • Automated tests reduce the time you spend on quality assurance

Where to commit an update depends on its priority and on the speed with which it needs to be deployed to the live site. Update continuously to ensure the ongoing quality and security of your project and to keep it future-proof. Feature and bug fix updates are less critical but also important to apply in due time.

There are many ways of ensuring the continuous security for your website, and it’s up to you whether to go with a completely manual process, try to automate some things, or opt-in for a fully automated solution such as Drop Guard.

Topics: security, Drupal

Mainframe Myth-Busting: File Integrity Monitoring is Only for Windows/UNIX Security Systems

Posted by Paul Taylor on Feb 16, 2016 8:41:00 AM

"This article was originally posted on CorreLog's blog. CorreLog is a high performance correlation, search and log management company and Townsend Security partner."

That’s the thing about myths: they’re only partly true.

IBM z/os MainframeYes, File Integrity Monitoring (FIM) has been part of the distributed computing landscape for a few years now. And yes, real-time enterprise security monitoring is harder to accomplish in a mainframe environment. But as attacks become more sophisticated, FIM needs to be a key component of the entire network, including your mainframe.

There’s a well-known software vendor that has an antivirus “sandbox” that is used to explode viruses in much like a police bomb squad would do with a suspicious package at a crime scene. After said software suspicious package is exploded, the software vendor adds the footprint to its database and the next time that package comes through the network, if it was clean the first time, it gets let through; if not, it’s blocked.

The tricky part of this story is that hackers are now smart enough to detect when they are about to be put into one of these sandboxes. When the A/V program starts to sandbox, the suspected virus, the virus goes into a cloaking mode to evade the sandbox. The A/V tool gives the executable a passing grade and there you have it; virus enters network.

Infosef Myths Debunked

Chances are you won’t have to worry about mainframe viruses anytime soon (though anything is possible these days). The point of the story here is the sophistication at which hackers are attempting to compromise corporate and government IP. For it is a much faster path to market to steal technology than it is to develop it. The same could be said for nation-state attackers who lack the subject matter expertise to develop their own IP, be it leading-edge technologies or schematics for nuclear reactors.

Having a Security Information & Even Management (SIEM) system with Data Loss Prevention (DLP), supported with antivirus detection and Identity/Access Management Systems (IAMS), gives you a fighting chance. Having a means for File Integrity Monitoring, especially on z/OS where the most strategic global banking and government data resides, further fortifies your security strategy and arms your information security team with another data point to determine the level of risk to your data.

FIM protocols are well established on the distributed side, but if you were to ask a mainframe sysprog (system programmer) if they have some type of FIM protocol in place for z/OS, they would look at you like you were speaking a foreign language. FIM on mainframe, or MFIM, must be addressed, at a minimum, to facilitate the Payment Card Industry Data Security Standard (PCI DSS) requirements 10.5.5; 10.6.1; 11.5; and 12.10.5. The standard and corresponding requirements can be found here, and we should note that this blog is not a review of the requirements. The takeaway in today’s blog is to understand that FIM is important to the Payment Card Industry Security Standards Council (and HIPAA, and FISMA, and IRS Pub. 1075, and others). PCI DSS lists FIM in four different requirements and it does not say “do this just on your Windows and UNIX systems.” The requirement says do this for all systems in your datacenter.

The key to MFIM is to look at the mainframe counterparts to the Microsoft Windows install folder. One of these, SYS1.PARMLIB, or the PARMLIB concatenation, is the most important set of datasets on z/OS, listing system parameter values used by nearly every component of z/OS. You can’t just take a checksum "snapshot" of these files, as a SIEM would do with distributed systems, because they’re simply too big for that to be a practical approach.

The details of tracking mainframe event messages are far too many to get into here. Essentially, you need a way of connecting the mainframe and your distributed SIEM system for notifications in real time, and you need a software tool that will convert mainframe events to a distributed event log format — RFC 3264 syslog protocol — so your SIEM system can interpret the data as actionable information.

You can learn more about MFIM and its relevance to PCI DSS from CorreLog’s complementary whitepaper titled “InfoSec Myths Debunked: FIM is only for Windows/UNIX.”

Topics: IBM z, File Integrity Monitoring (FIM), Mainframe

Oracle, SQL Server, and Encryption Key Management

Posted by Paul Taylor on Aug 22, 2012 10:59:00 AM

I often speak with organizations that need to employ encryption and external key management for multiple relational databases they are using to store encrypted data.  Often this is a combination of Oracle and Microsoft SQL Server databases.   

Transparent Data Encryption (TDE) is used within both the Microsoft SQL Server and Oracle Database universes to provide encryption services at the tablespace level.  Many companies employ TDE and external encryption key management to meet the concept of "Separation of Duties" as required by PCI DSS and other compliance regulations.  Also, TDE is often easier to implement than column level encryption that may require programming changes to your application layer.  

key management sql serverIn Microsoft's SQL Server Enterprise edition 2008/2012 you have access to Extensible Key Management (EKM).  When EKM is enabled, SQL Server users can use encryption keys stored on external key managers, as opposed to accessing local key stores, which doesn't line up with compliance requirements.  Also, another benefit of using EKM is that you can easily take advantage of TDE as your database encryption approach.  

If you're running versions of Microsoft SQL server that don’t support EKM, don't worry.  You can still take advantage of the added features and security of using an external key manager with our encryption key management HSM, Alliance Key Manager (AKM).  AKM fully supports the entire Microsoft SQL Server product line.  You’ll just have make some programming changes to your application code to perform the necessary API calls to the key manager and you'll be set up to do key retrieval.   To help you with the process, we provide sample code and the .Net key retrieval assemblies to add to your project.  Additionally, we have C# and VBNET sample code that shows how to retrieve a key from the key server.

Much like Microsoft SQL Server, in the land of Oracle you need to be running Oracle Enterprise Edition with the Advanced Security option.  This can often be a pricey upgrade and I find that quite a few organizations would rather do column level encryption due to this fact.  oracle key managementAKM fully supports the path to column level encryption within the Oracle 10g and 11g environments.  Again your approach will include making coding changes to your application layer to perform key retrieval from AKM.  To help you with this on the Oracle front we provide some PL/SQL sample code for you to work from.

For more information on the importance of encryption key management, download our white paper "Key Management in the Multi-Platform Envrionment" and learn how to overcome the challenges of deploying encryption key management in business applications.

Click me

Topics: Oracle, Encryption Key Management, SQL Server

What are HIPAA Encryption Best Practices?

Posted by Paul Taylor on Jul 10, 2012 8:02:00 AM

HIPAAThe Health Insurance Portability and Accountability Act (HIPAA) of 1996 establishes and governs national standards for electronic health care transactions.  According to the website of the U.S. Department of Health and Human Services: 

The HIPAA Privacy Rule provides federal protections for personal health information held by covered entities and gives patients an array of rights with respect to that information.... The Security Rule specifies a series of administrative, physical, and technical safeguards for covered entities to use to assure the confidentiality, integrity, and availability of electronic protected health information.  www.hhs.gov

The protections under HIPAA have been expanded by the Health Information Technology for Economic and Clinical Health Act (HITECH).  Again, according to the Department of Health and Human Services:

HITECH requires healthcare organizations to take more responsibility for protecting  patient records and health information. The Act widens the scope of privacy and security protections available under HIPAA, increases potential legal liability for non-compliance and provides more enforcement of HIPAA rules. The HITECH Act seeks to streamline healthcare and reduce costs through the use of health information technology, including the adoption of electronic health records.

HITECH defines a data breach of protected health information (PHI) as any unauthorized use, access or disclosure of PHI that violates the HIPAA Privacy Rule and poses significant financial, reputational or other harmful risks to an individual.

Should SMBs be concerned about a data breach of PHI?  A recent study found that only 5 percent of data breaches are caused by malicious cyber attacks, while almost 55 percent are linked to human error. 

To determine whether a PHI data breach has occurred, HHS looks at various factors, some within your control, some not.  A key question the Department will ask in the event of a data breach is:  Was the PHI safeguarded by encryption?

What level of HIPAA encryption is recommended?  What are the HIPAA encryption best practices?  The key, as the Practice Management Center of the American Medical Association points out, is to "...render electronic personal health information (ePHI) unusable, unreadable or indecipherable to unauthorized individuals...".  If you follow the specific technologies/methodologies prescribed, you increase the likelihood of being relieved of the potentially burdensome and expensive notification requirements established by the HITECH for a data breach.

Best practices for HIPAA encryption include:

  1. Ensuring your encryption is certified by the National Institute of Standards and Technology (NIST). 
  2. Using an encryption key management appliance that is FIPS 140-2 certified. Federal information processing standards codes (FIPS codes) are a standardized set of numeric/alphabetic codes issued by the National Institute of Standards and Technology (NIST).  They are designed to establish uniform identification of geographic entities through all federal government agencies. 
  3. Encrypting any and all systems and individual files containing ePHI including medical records (and related personnel records), scanned images, your practice management systems and any emails that contain ePHI.
  4. Encrypting data that is published on the Internet.  
  5. Encrypting data on your computers, including all laptops.
  6. Encrypting data that leaves your premises.
  7. Encrypting all sessions during which your data was accessed remotely.  This last one requires diligence supervision to ensure that it is followed every single time.  It should become a habit, something each staff member with access offsite does as a matter of course. 

HIPAA encryption protects not only the personal health information of employees and patients from unauthorized disclosure and use, it protects SMBs from the potentially significant costs (i.e., financial, administrative and via damage to the organization's reputation) that result from such disclosure. 

View our webcast “Protecting PHI and Managing Risk – HIPAA/HITECH Compliance” to learn how your organization can manage their risk of a data breach and achieve breach notification safe harbor status.

Click me

Topics: Encryption, Best Practices, HIPAA

What Types of Encryption are Available on the IBM i?

Posted by Paul Taylor on Jun 18, 2012 8:49:00 AM

AES Encryption & Related Concepts

AES White Paper

Download the white paper "AES Encryption & Related Concepts"

Click Here to Download Now

It seems like every day the media reports another data breach—a stolen laptop that contains patients’ private information, credit cardholders’ names and social security numbers hacked. Not only do the headlines prove to be public relations nightmares for the companies involved—especially if the stolen or hacked data isn’t encrypted—but they come with severe financial penalties, often reaching into millions of dollars.

When data is encrypted, companies can assure those whose data has been stolen or hacked that there is no reason to worry. Thieves may have the files containing the data, but the thief will be unable to access the data itself. This minimizes the public relations hit and reduces liability with compliance regulators. In today’s highly regulated business world, there is no excuse for not having encryption on your IBM i. Here are two types of encryption to make sure your data is secure:

NIST-Certified AES Encryption for Data at Rest
NIST sets non-military government standards for a wide variety of technologies including data encryption. Because NIST uses an open and professional process to establish standards, the private sector usually adopts NIST standards for commercial use. NIST is one of the most trusted sources for technology standards.

Since AES was introduced, it has been adopted by all U.S. government agencies as the gold standard for protecting sensitive data, and many software companies have made it available to consumers through encryption software. When selecting a data security service, looking for one that has NIST certification should be at the top of your list.

PGP Encryption for Data in Motion
In today’s world, data moves faster and further than ever. That’s why it’s important to ensure it’s secure whether it’s in a database, on a laptop, or sent via email.

PGP encryption is ideal for exchanging data with trading partners, banks, insurance companies, benefits providers, and many other external partners. It’s ability to run on any computing platform makes it ideal for this type of secure data exchange.

Data breaches and associated fines don't have to be a reality of doing business. By properly encrypting your sensitive information you remove the risk of seeing your name in the headlines, being fined millions of dollars, and trust of your brand by your customers.  Download our white paper "AES Encryption and Related Concepts" to learn more about industry best practices for securing your data.


Click me

Topics: Encryption, IBM i, AES, PGP

Data Breach Risk Management with AES Encryption

Posted by Paul Taylor on Jun 6, 2012 12:25:00 PM

data breachIt is common knowledge in the IT world that the threat of a data breach is now greater than any other time in the history of technology. Since late 2007, the amount of personal information that has been exposed through data breaches is alarming. According to the Identity Theft Resource Center, over 30 million Americans have been victims of data breaches. This is not withstanding the fact that these statistics only count breaches that have been reported.

However, this problem is not unique to the United States. No business organization is immune to risk no matter its size and regardless of the industry or location. Governments all over the world have instituted laws and regulations aimed at protecting the privacy of its citizens. Businesses have now realized the importance of keeping their sensitive data (PCI DSS, HIPAA, SOX, FFIEC) safe and secure. They have come to realize that protecting their sensitive and critical data protects not only their reputation and profitability, but also aids business objectives. Storing and moving unencrypted sensitive data means taking risks that may result in brand damage, loss of customers, heavy litigation expenses, and possibly millions of dollars in fines. These are some of the dilemmas that an organization would not want to find itself needing to mitigate.

Encryption and key management are a critical part of the solution.

Data encryption is now the primary control helping organizations meet security standards and comply with regulatory guidelines such as the PCI DSS, HIPAA, SOX, and GLBA/FFIEC.

What factors and threats drive companies to use encryption key management to mitigate their risk of a data breach?

  • An increase in the amount of sensitive data being stored
  • Risk of data loss by employees mishandling data
  • Increased sharing of authorized data with external users
  • Emerging markets for stolen data
  • Stringent regulatory requirements

Current NIST standards have rendered old security technologies ineffective in dealing with IT security risks. Effective encryption key management protects your customers data from potential threat. Encryption will help:

  • Protect your data and sensitive information regardless of the location
  • Meet compliance and regulatory requirements and therefore pass your audits
  • Protect your business, avoid brand damage and  increase profitability

If your business wishes to protect its information from all the above risks, data encryption is necessary to achieve your data security goals and objectives.

Download our white paper "AES Encryption Strategies - A White Paper for the IT Executive" to learn more about key issues in data security, how to choose the right data security partner, and how to develope a strategy that insures early successes.

Click me

Topics: Encryption Key Management, Data Breach

SQL Server Compliance: Top 5 Things You Can Do to Pass an Audit

Posted by Paul Taylor on May 30, 2012 1:50:00 PM

SQL encryption key managementIt is important for businesses of all sizes running on SQL servers to encrypt any sensitive data that they store or move. Although business size can determine specific compliance requirements that need to be met, all companies handling sensitive data are vulnerable to the major risk of failing a security audit if their data isn’t properly secured on their SQL servers.

Here are the 5 steps you can take to ensure you pass your next audit:

1. Test applications to address vulnerabilities

Continually test and re-test your applications including payment applications and firewalls  to look for vulnerabilities and address them from the start.

2. Protect information transmission

Protect data in motion by offering secure authentication features, logging application activity, using secure payment applications, and protecting wireless transmissions.

3. Protect your data

Ensure stored cardholder or PII/PHI data is protected with encryption; this information should never be stored on a server that is connected to the internet.

4. Encrypt sensitive traffic over public networks

Any transfer of data over public networks should be encrypted, whether this is cardholder information or PII/PHI data. Encrypting sensitive information guarantees that if it is intercepted that it is unusable without the encryption key.

5. Separate the encryption key from encrypted data

Separating the encryption keys from the data ensures the safety of the data in the event of an outside breach. It also allows internal separation of duties, thereby preventing unauthorized access to the the SQL Server data. This is a best practice for encryption management when dealing with sensitive information.

Taking theses steps in order to pass a security audit will proactively prevent data breaches. Even if data becomes compromised, properly encrypted data will guarantee that the data can not be used or accessed.  With a comprehensive data security plan, your company can easily meet state and national compliance regulations. Using proper encryption and key management on SQL Server will make encrypting your data quick and painless, and will help ensure you pass your next audit.

Download our White Paper “Encryption Key Management with Microsoft SQL Server 2008/2012” to read more about encryption key management, meeting compliance regulations with a certified HSM, and how to utilize about TDE and EKM on your SQL server.

Click me

Topics: Compliance, Encryption Key Management, SQL Server

HIPAA Security: Healthcare Data Breaches on the Rise

Posted by Paul Taylor on May 29, 2012 9:32:00 AM

HIPAA SecurityIn a highly digitized environment, identity theft poses a great risk if the necessary safeguards are not utilized. It is paramount that businesses and consumers are made aware of the massive repercussions a data breach of patient info can result in--such as identity theft of patients, as well as financial damage to and reputation loss of healthcare organizations. Current HIPAA regulations mandate that if a data breach occurs, then the organization responsible for that breach must reported it to Health and Human Services (HHS), pay thousands or millions of dollars in fines, and may have to report the breach to the media.  However, if your organization’s data is securely encrypted, you will be exempt from these repercussions.

Despite Health Insurance Portability and Accountability Act (HIPAA) security laws, healthcare data breaches are on the rise. According to the Ponemon Institute, the healthcare industry has lost more than $6.5 billion dollars due to data breaches.

Ponemon also identifies the three most common culprits of healthcare data breaches: stolen or lost equipment, third-party mistakes, and employee errors, indicating that many data breaches stem from unintentional mistakes. Storing health information on mobile devices is also a common practice among health care organizations. However, 49% of the respondents reportedly do not take any steps to secure patients' information on those devices.

medicaid breachA great example of an accidental data breach recently took place in South Carolina where a Medicaid employee transferred several spreadsheets of sensitive patient data to a personal email account. This kind of data breach could have exposed hundreds of thousands of patients to possible theft of Social Security numbers, Medicaid ID numbers, addresses, phone numbers, and birthdates.

Another alarming example took place at an Emory Healthcare storage facility where 10 back-up disks for an old computer were found missing. These disks contained protected health information (PHI) of more than 300,000 patients including patients' names, doctors' names, diagnoses, medical procedures and other privileged information protected under HIPAA.

As healthcare organizations face greater challenges in protecting massive amounts of patient data, the US federal government continues to strengthen security laws, regulations, and best practices. Due to the HITECH act of 2009, HIPAA compliances now requires more stringent steps to ensure full security of patient information.

As the CTO, IT Manger or System Administrator of your healthcare company, you have a critical task to accomplish. You cannot afford to waste time and money on legal battles that you can avoid in the first place. If you do experience a data breach, the emotional toll on your patients could result in lost clients and a tarnished company image.

Here is the good news: NIST-certified encryption and FIPS 140-2 certified encryption key management is at your fingertips!  Townsend Security’s encryption solutions offer affordable possibilities that will fully protect your patients' records and allow you to avoid a breach notification in accordance with HIPAA/HITECH. You need a security technology with a strong encryption solution that is NIST certified and suitable to your server environment. If data is securely encrypted, data breaches don’t need to be reported and you and your patients are assured peace of mind.

For more information, download our podcast "Protect PHI and Manage Risk - HIPAA Compliance" and learn more about achieving Safe-Harbor status in the event of a breach and what is considered a data breach.  Additionally, learn what to be aware of when selecting an encryption or key management solution.

Click me

Topics: HIPAA, Healthcare, Data Breach

Transparent Data Encryption on SQL Server 2008/2012 – Where are Your Keys?

Posted by Paul Taylor on May 25, 2012 8:51:00 AM

ekm encryption keysAny way you look at it, 2011 was a very bad year for database security. From the high-profile (and highly embarrassing) series of attacks on Sony's PlayStation Network, to the less-publicized Epsilon breach which was described by the Privacy Clearinghouse as the worst data breach in history, there was a huge upswing in attacks targeting private user data. In fact, according to a recent Verizon PCI Compliance Report (PCIR), "about 42 percent of organizations have trouble implementing a proper encryption key management strategy to keep information safe."

In short, hacking has become a goldmine for criminals looking to steal and exploit personal information, and you need to be doing everything you can to avoid being their next victim. For database administrators, this means making sure your encryption keys are as secure as possible.

Key Management in SQL Server 2008/2012

In previous years, encryption security was difficult because the keys were almost always stored locally on the same computer as the data. However, with the SQL Server 2008/2012 Enterprise Edition encryption key management became much more robust thanks to the introduction of Extensible Key Management (EKM).

EKM works alongside the Microsoft Cryptographic API to create a system where SQL server key management is significantly more secure. They can now easily be stored in an external Hardware Security Modules (HSM) that store the encryption keys securely, away from the data they protect. This makes it far more difficult for hackers to gain access to your secure private information.

The Advantages of a Hardware Security Module (HSM)

Alliance Key Manager, Townsend Security's encryption key management HSM provides a number of significant benefits for secure encryption key management.

  • Direct Integration With SQL 2008/2012: SQL Server 2008/2012 natively supports HSMs, requiring only a small tweak to the configuration files to enable their usage and disable local key storage.
  • True Key Security: With TDE, the key to your encryption never actually leaves the HSM. It cannot be captured through packet-sniffing or at the end user's machine.
  • Robust Standards Compliance: A properly-configured HSM setup gives you robust compliance with most of the major public and private security standards, including PCI DSS, HIPAA, SOX, and the Gramm-Leach-Bliley Act.
  • End User Simplicity with TDE: EKM also allows for Transparent Data Encryption (TDE), meaning that it's invisible to the end user. Your employees can continue to use their applications as they normally did, with the Hardware Security Module being queried as necessary, behind the scenes.
  • Cell Level Encryption: Through EKM, each individual column of cells can be encrypted separately, making large-scale data breaches far more difficult to pull off.
  • Easy Implementation: Once the hardware is installed, the key management software only needs to be installed on your server machine. End user access to it is managed through software licenses rather than requiring time-consuming individual installations.

A Smart Choice for Server Security

While encryption and key management are not the only elements necessary for robust data security, they are a major component of it. By implementing a HSM, your business can quickly and easily give its security a shot in the arm, telling your customers and investors that you're serious about protecting private personal information on your servers.

Don't let 2011 be a sign of things to come; take steps now to make 2012 the year of data protection.

Download our White Paper “Encryption Key Management with Microsoft SQL Server 2008/2012” to read more about encryption key management, meeting compliance regulations with a certified HSM, and how to utilize about TDE and EKM on your SQL server.

Click me

Topics: SQL Server 2008, Encryption Key Management

The Definitive Guide to AWS Encryption Key Management
Definitive Guide to VMware Encryption & Key Management


Recent Posts

Posts by Topic

see all