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

Patrick Townsend

Recent Posts

Splunk, Alliance LogAgent, and the LEEF data format

Posted by Patrick Townsend on Apr 18, 2017 7:09:08 AM

We have a lot of Enterprise customers deploying our Alliance LogAgent solution for the IBM i server to send security events to Splunk. On occasion a customer will deploy Alliance LogAgent and send data in the Log Event Extended Format (LEEF) to Splunk. The LEEF format is the preferred log data format for the IBM Security QRadar SIEM, so I’ve always found this a bit puzzling.

IBM i Security: Event Logging & Active MonitoringThe light finally came on for me this week.

Security event information in syslog format (see RFC 3164) is largely unstructured data. And unstructured data is hard for SIEM solutions to understand. Here is an example from an Apache web server log:

[Wed Oct 11 14:32:52 2000] [error] [client] client denied by server configuration: /export/home/live/ap/htdocs/test

An SIEM administrator would have to do a fair amount of work configuring the SIEM to properly understand the importance of this message and take the proper action. If only the data was in some type of normalized format!

It turns out that the IBM Security QRadar LEEF format normalizes the system log information. A message like the above might look something like this in LEEF format:

date=20001011 time=143252 ipAddress= violation=client denied severity=5 path=/export/home/live/ap/htdocs/test

With field definitions like “date” and “time” the Splunk SIEM can easily digest the message and the Splunk query tools work great. It is easy to create reports and dashboards with this type of normalized data. The LEEF format is really good about this and Alliance LogAgent supports the LEEF definition.

What most Splunk administrators do not realize is that our Alliance LogAgent solution normalizes all IBM i security events in this type of normalized fashion. That is, this format is the default data format for security events. This is already what Alliance LogAgent does for IBM i security events!

When we started the development of Alliance LogAgent more than 10 years ago we understood at the outset that system log data would be hard for a SIEM to parse. So from the first release of our solution we provided data in this normalized format. Whether you are using Splunk, LogRhythm, Alert Logic, or any other SIEM we make it really easy for the SIEM to digest and act on the information. And forensic, query, and dashboards are easy to create.

So, Splunk users - listen up! The default system log format in Alliance LogAgent is exactly what you need to make Splunk work really well. You can use the LEEF format if you really want to, but you have all of the benefits of normalized data with the default format.

Here at Townsend Security we are vendor neutral when it comes to SIEM solutions. Our customers deploy a wide range of solutions including Splunk, IBM QRadar, LogRhythm, Alert Logic, SolarWinds, McAfee, and lots more. And they can move from one SIEM to another without changing their Alliance LogAgent configurations. We believe that actively monitoring system logs in real time is one of the most important security steps you can take. Early detection of a problem is so much better than trying to remediate a breach after the fact.



Topics: Alliance LogAgent, Splunk

Microsoft SQL Server Encryption - Key Management Security Best Practices

Posted by Patrick Townsend on Apr 12, 2017 7:48:32 AM

This is part 7 in a series focusing on critical aspects of SQL Server encryption. In the previous part of this series we looked at encryption key management business recovery topics. In this part we look at encryption key management security best practices. Protecting encryption keys from loss is the most important part of an encryption strategy and there is good documentation on security best practices for encryption key management. Security best practices for key management also appear in many compliance regulations such as the Payment Card Industry Data Security Standard (PCI-DSS) and others.

Separating Encryption Keys from the Data They Protect

Encryption-Key-Management-SQL-ServerOne of the core best practices for encryption key management is to separate the storage of encryption keys away from the data that they protect. Using a key management system designed for the creation and storage of keys is central to this security best practice. The separation of encryption keys away from protected data makes the compromise of sensitive data much harder. Compromising and retrieving locally stored encryption keys is usually a simple task, and this is true for SQL Server locally stored keys.

These common practices are weak security for SQL Server encryption keys:

  • Encryption keys stored in application programs
  • Encryption keys stored in a SQL Server table
  • Encryption keys stored in folders on a local or remote Windows server
  • Encryption keys stored with password protection
  • Encryption keys stored locally by SQL Server Transparent Data Encryption (TDE)

Separating encryption keys from protected data substantially raises the bar for attackers, and largely eliminates the threat of loss from replaced hard drives, stolen virtual machine or cloud images, and lost backup images.

Separation of Duties

Separation of Duties (SOD), sometimes called Segregation of Duties, is a core security principle in financial, medical and defense applications. In the context of protecting sensitive data separation of duties is important to minimize accidental or intentional loss of sensitive data by insiders. As applied to Information Systems separation of duties requires that those who create and manage encryption keys should not have access to sensitive data, and those who manage databases (database administrators) should not have access to encryption keys.

Organizations should assign encryption key management duties to specific security administrators who do not have database administration duties, and not assign key management duties to DBAs. In modern key management systems this is managed by the assignment of user-friendly names to encryption keys. The user-friendly names for encryption keys, sometimes call key aliases, are exchanged between the security administrator and the SQL Server DBA. This avoids sharing the actual encryption keys.

Dual Control

The NIST guide for Key Management Best Practices defines the encryption key management role as critical part of the security strategy. Management of encryption key systems should implement Dual Control. This means that two or more security administrators should authenticate to the key server before any work is performed. Requiring a quorum of security administrators to authenticate minimizes the threat of insider damage or theft of critical encryption key secrets.

Split Knowledge

Because encryption keys are critical to the security of protected data, this security best practice requires that no one person sees or takes possession of an encryption key that is visible in the clear. Modern key management systems minimize this threat by not exporting or displaying encryption keys to administrators or users, and not using passwords as a part of the key creation process. If you use a key management system that generates or exports keys based on passwords, or which exposes encryption keys in the clear to administrators or users, you should implement split knowledge controls. SQL Server protects Transparent Data Encryption keys by never storing them in the clear on the SQL Server instance.

Minimum Number of Key Administrators

Another security best practice designed to reduce insider threats and the loss of administrative credentials is to keep the number of people who manage your key management system to the smallest reasonable number. The fewer administrators who have access to the key management system the fewer opportunities for accidental or intentional loss of encryption keys.

Multi-factor Authentication

Like any critical component of our information management system, encryption key management systems should implement multi-factor authentication, sometimes called two factor authentication, to reduce the threat of the theft of administrative credentials. Cyber criminals use a number of techniques to capture important administrative credentials including phishing, social engineering, memory scraping, and other types of attacks. Multi-factor authentication is an important security control and best practice for encryption key management systems.

Physical Security

Physical security controls are also an important security best practice for encryption key management and similar security applications and devices. Physical controls in the data center include keyed access to server rooms, locked cabinets and racks, video monitoring and other controls. While physical security of key management hardware security modules (HSMs) is fairly easy to accomplish, it is also necessary to insure physical controls for virtual environments that use VMware and Hyper-V, and for cloud environments. In cloud environments you may have to work with your cloud service provider to insure proper protection of virtualized key management server instances.

Data Encryption Key Rotation

Periodically changing the data encryption key (DEK) of your protected data is also a security best practice and required by some compliance regulations like PCI-DSS. This is sometimes referred to as “key rotation” or “key rollover”. Your key management system may help in this area by allowing the specification of the crypto-period of the key and automatically changing the key for you. Of course, the retention of the older key is needed to insure that encrypted data can be decrypted. Changing encryption keys and re-encrypting sensitive data is a security best practice.

Key Encryption Key Rotation

In proper key management systems the data encryption keys (DEK) are protected by separate key encryption keys (KEK). Key encryption keys are only used to protect DEK and are never used to directly protect sensitive data. Key encryption keys reside only on the key management system and must not leave that system except as a part of a secure backup. KEK rotation is generally less frequent than DEK rotation, but should be a part of your key management system.

Administrator and User Authentication

Key management systems are designed to generate strong encryption keys and protect them from loss. Of course, it must also enable the use of encryption keys to protect sensitive data. The key management system should implement strong authentication controls for access to the key server, and further should implement strong authentication for the use of specific encryption keys. This is normally implemented using PKI infrastructure and mutual authentication between clients and servers. This exceeds the typical authentication that you might encounter using a web browser with a secure session. A key management system should insure that a secure session is negotiated by a known and trusted client. To insure this most key management systems incorporate a private certificate authority and do not rely on public certificate authorities to insure the highest level of trust in the authentication.

Network Segmentation

As critical security systems it is a best practice to use network segmentation of key management systems and of the applications that access the key management systems. Network segmentation can be accomplished through normal IT infrastructure, through virtualized network management as implemented by VMware, and in cloud platforms using cloud service provider network segmentation rules. Further network access controls can often be implemented in the key management system using firewall rules.

Auditing and Logging

Lastly, all security devices including key management systems should collect and transmit audit and system logs to a log collection server or SIEM monitoring solution. Active monitoring of critical application and security systems is an important security control and best practice. Key management systems should fully implement support for active monitoring.

In summary, security best practices for key management systems used for SQL Server data protection should reflect well-understood and documented best practices for security devices. The core source of these best practices is the National Institute for Standards and Technology's Special Publication 800-57, “Recommendation for Key Management.” Your key management solution for SQL Server should implement these best practices.


Encryption and Key Management for Microsoft SQL Server

Topics: SQL Server, SQL Server encryption

Microsoft SQL Server Encryption and Key Management Business Continuity

Posted by Patrick Townsend on Apr 4, 2017 8:33:26 AM

This is part 6 in a series focusing on critical aspects of SQL Server encryption. When a SQL Server customer deploys Transparent Data Encryption (TDE) or Cell Level Encryption (CLE) and protects encryption keys on an encryption key management solution, it is important that the key manager implement reliable business continuity support. Key managers are a part of the critical infrastructure for your applications and should be resilient in the face of common business continuity challenges such as data center damage or destruction (fire, hurricanes, flood, earthquake, etc.), network failures, and hardware failures. Let’s review some aspects of key management resilience.

Key Management Hardware Resilience

Encryption and key management for SQL ServerKey management systems come in many form factors including network attached hardware security modules (HSMs), virtual machines for VMware and Hyper-V, cloud instances for Microsoft Azure, Amazon Web Services (AWS), IBM SoftLayer, Google Compute Engine, and other cloud platforms, and as multi-tenant key management solutions such as AWS Key Management Service (KMS) and Azure Key Vault.

When a key manager is deployed as a hardware solution it should implement a number of hardware resiliency features including:

  • RAID protected hard drives
  • Hot swappable hard drives
  • Redundant power supplies
  • Independent Network Interfaces (NICs)
  • Audible alarms

To the greatest extent possible a key management hardware system should be able to protect you from common hardware failure issues.

Key Substitution or Corruption

Key management systems store encryption keys in different types of data stores on non-volatile storage which is subject to key corruption through attack or hardware failure, or subject to key substitution through attack. Key management systems should use common integrity techniques such as hash-based message authentication code (HMAC) or similar technologies to detect this type of failure. Encryption keys should not be returned to a user or application in the event integrity checks fail, and all integrity check failures should be reported in audit and system logs. Additionally the integrity of the key database and application should be checked when the key manager initially starts processing. Early detection and quarantine of bad encryption keys helps prevent data corruption and gives the security administrator the ability to restore proper operation of the key manager.

Real-time Key Mirroring and Access Policy Mirroring

Because key management systems are a part of an organization’s critical infrastructure, they should implement real-time mirroring of encryption keys and access policies to one or more secondary key servers. The real-time nature of key mirroring is important to prevent the loss of an encryption key after it is provisioned but before it has been copied to a secondary system.

Real-time mirroring should also be able to recover from temporary network outages. If keys cannot be mirrored because the connection between the primary and secondary servers is interrupted, the key mirroring facility should automatically recover and resume mirroring when the network is operational again. This reduces the chance that keys are lost due to latency in mirroring.

Many organizations deploy complex distributed networks that require multiple secondary key servers. While most key management installations involve just one production and one secondary key server, good key management mirroring should involve the ability of a primary key server to mirror to multiple secondary key servers.

Active-Active Key Mirroring

Expanding on the topic of encryption key and access policy mirroring, it is important that key management systems fully support role-swap system recovery operations and this involves the dynamic change in roles between a primary and secondary key server. When a primary key server is unavailable a secondary key server automatically steps in to serve various encryption key functions. In this situation it is important that the secondary key server now becomes the primary key server for a period of time. New encryption keys may be created, the status of existing keys may change, and access policies may also change. A good key mirroring architecture will allow for these changes to migrate back to the original primary key server when it becomes available. This is the central feature of Active-Active mirroring implementations.

Key Management Monitoring

Because key management systems are critical infrastructure it is important to deploy monitoring tools to insure a high service level. Key management systems should generate and transmit system log information to a monitoring solution, and the key management system should enable monitoring by external monitoring applications. In the event a key server becomes unavailable it is important to identify the outage quickly.

Key Management System Logging and Audit

Another important aspect of key management business continuity is proper system logging of the key management server. Key management systems are high value targets of cyber criminals and active monitoring of key management system logs can detect an attack early in the cycle.

Additionally, key management systems should audit all management and use of encryption keys and policies. A good key management solution will audit all actions on encryption keys from creation to deletion, all changes to key access policies, and all access to keys by users and applications. These audit logs should be transmitted to a log collection or SIEM monitoring solution in real time.

Key Management Backup and Restore

As critical systems key managers must implement backup and restore functions. In the event of a catastrophic loss of key management infrastructure, restoring to a known good state is a core requirement. Good key management systems enable secure, automated backup of the data encryption keys, key encryption keys, server configuration, and access policies.

Key management systems differ from traditional business applications in one important aspect - data encryption keys should be backup separately from key encryption keys. You should be able to backup data encryption keys automatically or on demand, but you should take care to separately backup and restore key encryption keys. This is a core requirement for key management systems.

In summary, key management systems need all of the major business continuity components that you would expect in mission-critical business applications.


White P

Topics: SQL Server, SQL Server encryption

Microsoft SQL Server EKM Providers Implementation Topics

Posted by Patrick Townsend on Mar 28, 2017 11:14:29 AM

This is the fifth in a series looking at the architecture and implementation of SQL Server Transparent Data Encryption (TDE) and Cell Level Encryption (CLE). In this series we look specifically at EKM Provider software architecture and features.

Encryption-Key-Management-SQL-ServerExtensible Key Management (EKM) Provider software can involve several components that include installation of the EKM Provider software, configuration of encryption and key management options, installation of credentials for the key server, and of course the EKM Provider software itself. The EKM Provider software is provided by your encryption key management vendor. In some cases this software may be an extra charge feature from your vendor, and in other cases there may be no charge for the EKM Provider. In any case, the EKM Provider software is specific to the encryption key management solution you are using.

Installation of an EKM Provider

The EKM Provider software that is responsible for direct integration of SQL Server with your key manager and is installed on the actual server where SQL Server is running. While different vendors approach the installation process in different ways, you can expect that a standard Windows MSI installation application will be used to install the software and perform initial configuration of the EKM Provider options. In order to support flexible system administration of your SQL Server environment, the installation of the EKM Provide software usually does not immediately start the encryption process, but this varies from one EKM Provider to another.

Configuration of an EKM Provider

Once the EKM Provider software is installed you must configure usage options. These options may include:

  • The hostname or IP address of a key server
  • The hostname or IP address of one or more failover key servers
  • The name of the SQL Server instance being protected
  • The Windows account under which the EKM Provider software will operate
  • The location of credentials for the key server
  • The fingerprint of the HSM certificate used to protect the TDE key, or a password
  • The state of application logging options
  • License codes for the EKM Provider
  • And possibly other configuration options

The configuration of the EKM Provider may be initiated by the installation process, or may be available from a Windows menu or command line facility. Properly configuring the EKM Provider software is a necessary first step for activating SQL Server encryption through the SQL Server management console.

Installing and Protecting Key Server Credentials

The protection of the credentials used to access the encryption key server is crucial to your security strategy. The method used to protect those credentials is left to the EKM Provider and varies from one vendor to the next. You should carefully review this strategy to insure that credentials and certificates are properly protected in the SQL Server context. Cyber attacks often attempt to compromise the credentials for a key server in order to compromise the protected data. The compromise of key server credentials should be considered a compromise of protected sensitive data.

In many cases the credentials for an encryption key server are based on PKI certificates. These can be stored in the Windows Certificate Store to achieve the added security and access logging provided by the Windows operating system. Take care to avoid storing certificates, passwords or other credentials in user directories or in areas that are commonly accessed by Windows administrative accounts.

Encryption Software Libraries

When you implement SQL Server Transparent Data Encryption (TDE) the encryption of the database is performed by SQL Server itself. The EKM Provider protects the symmetric encryption key used by TDE, but encryption (usually AES) is performed by SQL Server using Microsoft encryption libraries. When using AES encryption for TDE the performance is generally quite good. While Triple DES (3DES) is an option with SQL Server TDE I would recommend avoiding it. AES performs better and is expected to have a longer life as an industry standard.

When you implement SQL Server Cell Level Encryption (CLE) the encryption is performed by the EKM Provider software, and not by SQL Server. It is therefore important to understand how the vendor of the EKM Provider software has implemented encryption and which encryption library is used. Options for encryption include:

  • Use of native Windows .NET encryption libraries
  • Use of vendor encryption libraries that meet industry standards such as AES and 3DES
  • Use of vendor non-standard encryption libraries (not recommended)
  • Use of home-grown encryption libraries (not recommended)

While the native Microsoft .NET encryption libraries have good performance, you should attempt to understand the performance of any non-Microsoft encryption libraries. Additionally, the use of non-standard encryption algorithms should be avoided in order to avoid non-compliance with regulatory frameworks.

Configuring EKM Provider Key Server Failover

The use of an encryption key manager requires careful attention to business continuity including high availability failover. Again, support for high availability failover is a vendor-dependent feature, but should be included in your EKM Provider architecture. Key server failover can be triggered by a number of events:

  • Network failure
  • Key server hardware failure
  • Distributed Denial of Service (DDos)
  • Failure of a SQL Server cluster
  • And other events

Because lack of access to the key server will result in the inability of SQL Server to process information requests, it is critical that the EKM Provider software automatically respond to network or server failures in a timely fashion. Note that for some EKM Providers the failure of a network segment or a key server does not mean the immediate interruption of the SQL Server application. For example, SQL Server TDE encryption interacts with the key server when SQL Server is first started. If the SQL Server instance remains active a temporary failure of a network connection will not interrupt the normal operation of SQL Server. Likewise, if the EKM Provider implements secure key caching there may not be an interruption related to Cell Level Encryption.

EKM Provider Audit Logging

Access logs for SQL Server and EKM Providers are a critical component of a security posture for SQL Server. All components of your SQL Server implementation should generate access and usage logs that can be sent to log collection or SIEM server in real time. The EKM Provider software should log all activity to the encryption key server. Active monitoring with a SIEM solution is one of the best security protections available. The EKM Provider software should support that aspect of threat detection.

EKM Provider Software Resilience

Lastly, EKM Provider software should be as resilient as possible. Software should automatically recover in the event of a SQL Server database restart, the failure of a connection to a key server, and other unexpected events. Manual intervention by a Windows network administrator or database administrator should not be necessary.

Encryption and Key Management for Microsoft SQL Server

Topics: SQL Server, SQL Server encryption

Microsoft SQL Server Encryption Key Management

Posted by Patrick Townsend on Mar 20, 2017 2:01:48 PM

The hardest part of an encryption strategy is the proper management of encryption keys. Failing to protect encryption keys puts protected data at risk, and fails to meet security best practices and compliance regulations. For Microsoft SQL Server customers who have already implemented Transparent Data Encryption (TDE) or Cell Level Encryption (CLE) the biggest cause of an audit failure is the lack of good encryption key management.

Encryption-Key-Management-SQL-ServerThis is the fourth in a series on the topic of Microsoft SQL Server encryption. Let’s look at some of the characteristics of good encryption key management for SQL Server.

Extensible Key Management (EKM) Providers
As we’ve discussed previously it is the responsibility of key management vendors to provide the Extensible Key Management (EKM) Provider software that is installed and registered to the SQL Server database enabling either TDE or CLE encryption. The software from the key management vendor is installed on the SQL Server instance and provides both encryption and key management services. The SQL Server database administrator does not need to be involved in the actual retrieval of an encryption key - that is the job of the EKM Provider software.

EKM Provider software must handle the encryption and decryption of the database key for Transparent Data Encryption, and must handle the retrieval of a symmetric key for Cell Level Encryption. Key retrieval should be performed in a manner that protects the encryption key from loss on the network, protects the key while in memory, and should properly log the key retrieval event in a system log repository. Encryption key retrieval is normally protected through the use of a secure TLS network connection between the EKM Provider software on SQL Server and the key manager hardware or virtual machine. There are many other critical aspects of EKM Provider key management implementations, and these will be discussed in a future series.

Enterprise Key Management Solutions
The proper generation, storage, protection and management of encryption keys is the core purpose of professional encryption key management solutions. As security devices an encryption key manager is responsible for creating strong encryption keys that meet industry standards, and protecting those keys from loss during the lifecycle of the keys. Encryption key managers may be hardware security modules (HSMs), virtual servers (VMware, Hyper-V, etc.), or multi-tenant or dedicated cloud instances. In addition to implementing industry standards for encryption key management, key servers will provide a variety of authentication, systems management, and audit functions to meet security best practices and compliance regulations. Microsoft SQL Server customers who want to achieve compliance with common regulations should look to deploy a professional, certified and validated key management solution.

Key Management Industry Standards
Encryption key management systems are cryptographic modules that perform a variety of functions. As a cryptographic module they fall under the standards of the National Institute of Standards and Technology (NIST) and key managers should provably meet NIST standards. The relevant NIST standard for encryption key management is the Federal Information Processing Standard 140-2 (FIPS 140-2), “Security Requirements for Cryptographic Modules”. Key management solutions which implement FIPS 140-2 standards will insure the generation of strong encryption keys, the protection of those keys from corruption or substitution, and the implementation of encryption that provably meets NIST cryptographic standards.

In addition to provide standards for encryption key management NIST also provides a method for vendors to validate that their solutions meet the standard. Encryption key management solutions are tested by chartered security testing laboratories and solutions are then approved directly by NIST. NIST publishes the solutions that have passed FIPS 140-2 testing and Microsoft SQL Server customers should look for FIPS 140-2 validation of any key management solution used to protect the database.

Migrating Locally Stored Keys to Key Management
Many Microsoft SQL Server users start their encryption projects by using the option to locally store the database encryption key on the local SQL Server instance. While this is not a security best practice, it is a common way to start an encryption project.

Fortunately, it is easy to migrate a locally stored encryption key to a proper key management solution. The migration involves the protection of the SQL Server database key to key management protection and does not require the decryption of the database. The database key which is currently protected by local keys and certificates is placed under the protection of the key manager. The EKM Provider software of your vendor then becomes responsible for unlocking the database key (TDE) or retrieving the symmetric key for Cell Level Encryption (CLE).

OASIS Key Management Interoperability Protocol (KMIP)
Many SQL Server customers ask about the KMIP standard for integrating with key managers. While KMIP is important for many reasons, it does not apply to the Microsoft EKM Provider interface. The EKM Provider interface leaves it to the key management vendor to perform the needed cryptographic functions on the key server. These functions do not map to KMIP operations and attributes. While it is advisable to deploy key management solutions that meet KMIP standards, it is not required for SQL Server encryption.

To this point we have defined the SQL Server encryption architecture, options for implementing SQL Server encryption (TDE and CLE), and basic requirements for encryption key management. In the next part of this series we will look at EKM Provider implementation topics as well as business continuity topics.

Encryption and Key Management for Microsoft SQL Server

Topics: SQL Server, SQL Server encryption

Microsoft SQL Server Automatic Encryption - Cell Level Encryption

Posted by Patrick Townsend on Feb 21, 2017 9:11:00 AM

In this third part of the series on Microsoft SQL Server encryption we look at Cell Level Encryption, or CLE, which is Microsoft terminology for Column Level Encryption. With CLE the manner and timing of SQL Server’s call to the EKM Provider software is quite different than for Transparent Data Encryption. It is important to understand these differences in order to know when to use CLE or TDE. Let’s look at some aspects of the CLE implementation:

Encrypted Columns
Encryption-Key-Management-SQL-ServerCell Level Encryption is implemented at the column level in a SQL Server table. Only the column you specify for encryption is protected with strong encryption. You can specify more than one column for CLE in your tables, but care should be taken to avoid performance impacts of multiple column encryption (see below).

With Cell Level Encryption you may be able to minimize some of the encryption performance impacts on your SQL Server database. Because the EKM Provider is only called when the column must be encrypted or decrypted, you can reduce the encryption overhead with careful implementation of your database application code. If a SQL query does not reference an encrypted column, the EKM Provider will not be invoked to perform decryption. As an example, if you place the column Credit_Card under CLE encryption control, this query will not invoke the EKM Provider for decryption because the credit card number is not returned in the query result:

SELECT Customer_Number, Customer_Name, Customer_Address FROM Orders ORDERBY Customer_Name;

You can see that judicious use of SQL queries may reduce the need to encrypt and decrypt column data.

SQL Application Changes
Unlike Transparent Data Encryption you must make a change to the SQL statement in order to implement Cell Level Encryption. The SQL Server functions “encryptbykey” and “decryptbykey” are used on SQL statements. Here is an example of a SQL query that encrypts a CLE-encrypted column:

select encryptbykey(key_guid('my_key'), 'Hello World');

Implementing CLE encryption in your SQL Server database requires modifications to your applications, but may be well worth the additional work.

Encryption and Key Retrieval
The EKM Provider software is called for each column value to perform encryption and decryption. This means a larger number of calls to the EKM Provider compared to Transparent Data Encryption. Because the number of calls to the EKM Provider may be quite large it is important that the encryption and key management functions of the EKM Provider are highly optimized for performance (see the next section).

The EKM Provider software from your key management vendor is responsible for performing encryption of the data. From a compliance point of view it is important to understand the encryption algorithm used to protect data. Be sure that the EKM Provider software uses a standard like the Advanced Encryption Standard (AES) or other industry recognized standard for encryption. It is common to use 128-bit or 256-bit AES for protecting data at rest. Avoid EKM Providers which implement non-standard encryption algorithms.

Encryption Key Caching
When deploying CLE it is important that the EKM Provider software optimize both encryption and key management. The number of calls to the EKM Provider software can be quite high. Good EKM Providers will securely cache the symmetric key in the SQL Server context rather than retrieve a key on each call. The retrieval of an encryption key from a key server takes precious time and multiple calls to retrieve a key can have severe performance impacts. Secure key caching is important for CLE performance. The use of the Microsoft Windows Data Protection Application Program Interface (DPAPI) is commonly used to protect cached keys.

Performance Considerations
When properly implemented Cell Level Encryption can reduce the performance impact of encryption on your SQL Server database. For very large tables with a small number of columns under encryption control, the performance savings can be substantial. This is especially true if the column is used less frequently in your applications.

CLE Vendor Note
Note that each vendor of EKM Provider software implements encryption and key management differently. Some EKM Providers only implement Transparent Data Encryption (TDE). If you suspect you will need Cell Level Encryption be sure that your key management support includes this capability.

In the next part of this series we will look at encryption key management in SQL Server.


Encryption and Key Management for Microsoft SQL Server

Topics: SQL Server, Cell Level Encryption, SQL Server encryption

Microsoft SQL Server Automatic Encryption - Transparent Data Encryption

Posted by Patrick Townsend on Feb 14, 2017 8:33:00 AM

In this second part of the series on Microsoft SQL Server encryption I want to focus on Transparent Database Encryption, or TDE. Most Microsoft customers who implement encryption in SQL Server use Transparent Data Encryption as it is the easiest to deploy. No code changes are required and enabling encryption requires just a few commands from the SQL Server console. Let’s look at some of the characteristics of TDE implementation.

Database Encryption
Encryption and key management for SQL ServerTDE involves the encryption of the entire database space in SQL Server. There is no need or ability to select which tables or views are encrypted, all tables and views in a database are encrypted at rest (on disk). When data is read from disk (or any non-volatile storage) SQL Server decrypts the entire block making the data visible to the database engine. When data is inserted or updated the SQL Server database encrypts the entire block written to disk.

With TDE all of the data in your database is encrypted. This means that non-sensitive data is encrypted as well as sensitive data. There are advantages and disadvantages to this approach - you expend computing resources to encrypt data that may not be sensitive, but you also avoid mistakes in identifying sensitive data. By encrypting everything at rest you are also protected from expansion of regulatory rules about sensitive data protection.


Protection of the Symmetric Key
When you enable Transparent Data Encryption on your SQL Server database the database generates a symmetric encryption key and protects it using the EKM Provider software from your key management vendor. The EKM Provider software sends the symmetric key to the key server where it is encrypted with an asymmetric key. The encrypted database key is then stored locally on disk in the SQL Server context.

When you start a SQL Server instance the SQL Server database calls the EKM Provider software to decrypt the database symmetric key so that it can be used for encryption and decryption operations. The decrypted database key is stored in protected memory space and used by the database. The encrypted version of the database key remains on disk. In the event the system terminates abnormally, the only version of the database key is the encrypted version on disk.

Starting the SQL Server Instance
During normal operation of SQL Server there is no invocation of the EKM Provider software and therefore no communication with an external key manager. Every normal restart of the SQL Server database instance will cause the EKM Provider software to be called to unlock the database key on the key server.

It should be noted that it is the responsibility of the EKM Provider software to handle network or key server failure conditions. SQL Server itself has no visibility on the connection to an encryption key management solution. If the EKM Provider software is unable to retrieve an encryption key, the SQL Server start request will fail. We will discuss business continuity issues in more detail later in this series.

Protecting Database Logs
SQL Server logs may contain sensitive data and therefore must also be encrypted. Transparent Database Encryption addresses this by fully encrypting database logs along with the database itself. It is important to remember that encryption of the logs will only start after TDE is activated AND after you stop and restart the database log. If you neglect to restart logging sensitive data may be exposed in the SQL Server log files.

Table and Index Scanning
Certain SQL operations on indexes require that the SQL Server database have visibility on the entire index of a column. An example of a SELECT statement would be something like this:

SELECT Customer_Name, Customer_Address FROM Orders WHERE Credit_Card=’4111111111111111’;

To satisfy this SQL query the database must inspect every row in the table Orders. With TDE this means that the column Credit_Card must be decrypted in every row. Similar operations with the ORDERBY clause can cause table or index scans.

Performance Considerations
Transparent Data Encryption is very optimized for encryption and decryption tasks and will perform well for the majority of database implementations. Microsoft estimates the performance impact of TDE of 2% to 4% and we find this accurate for most of our customers. However, Microsoft SQL Server customers with very large SQL Server databases should use caution when implementing TDE. Be sure that you fully understand the impact of TDE on your application use of large tables. It is always recommended that you perform a proof-of-concept project on very large databases to fully assess the performance impact of encryption.

In the next part of this series we will look at the other option for SQL Server encryption - Cell Level Encryption, also called column level encryption.


White P

Topics: SQL Server, Transparent Data Encryption (TDE)

Microsoft SQL Server Encryption - An Introduction

Posted by Patrick Townsend on Feb 6, 2017 2:33:16 PM

In 2008 the Payment Card Industry Data Security Standard (PCI-DSS) was gaining serious traction and Microsoft released SQL Server 2008 with built-in support for encryption. This was no coincidence. In addition to the PCI standard which mandated encryption of credit card numbers, numerous states in the US had also adopted data breach notification laws with strong recommendations for encryption. The compliance environment was changing dramatically and the SQL Server group at Microsoft provided a path to meet those new compliance regulations. This was a prescient and crucially important enhancement for Microsoft customers - the security threats have increased over time and compliance regulations have become more stringent.

Encryption and key management for SQL ServerIn this multi-part series I want to talk about how Microsoft implemented encryption in SQL Server, how you can leverage this capability to achieve better security and compliance, and the critical issues involved in getting encryption right with SQL Server. I hope you will find this series helpful as you negotiate your SQL Server encryption projects.

Many Microsoft applications and services implement a “Provider” interface. This is the term that Microsoft uses to describe a standardardized, pluggable architecture for third party software companies to integrate and extend the capabilities of Microsoft solutions. With Provider architectures Microsoft enables a method for third parties to register their software to the Microsoft application, and the Microsoft application will then call that software as needed. The third party software must obey rules about the data interface and behavior of their applications. If done correctly the Provider interface provides powerful extensions to Microsoft applications.

Starting with SQL Server 2008 the database implements a Provider interface for encryption and key management. This is named the “Extensible Key Management” Provider interface, or the “EKM Provider”. EKM Provider software performs encryption and key management tasks as an extension to the SQL Server database. The EKM Provider architecture opened the door for third party key management vendors to extend encryption to include proper encryption key management.

From a high level point of view the EKM architecture looks like this:


Every version of SQL Server since 2008 has fully implemented the EKM Provider architecture. This has provided a stable and predictable interface for Microsoft customers and encryption key management vendors.

EKM Architecture - Column and Database Encryption
The EKM Provider architecture supports two different methods of database encryption:

  • Cell Level Encryption
  • Transparent Database Encryption

Cell level encryption is also known as column level encryption. As its name implies it encrypts data in a column in a table. When a new row is inserted into a table, or when a column in a row is updated, the SQL Server database calls the EKM Provider software to perform encryption. When a column is retrieved from the database through a SQL SELECT or other statement the EKM Provider software is called to perform decryption. The EKM Provider software is responsible for both encryption and key management activity. Implementing cell level encryption requires minor changes to the SQL column definition.

Transparent Database Encryption, or TDE, provides encryption for the entire database and associated log files. All tables and views in the database are fully encrypted. Data is encrypted and decrypted as information is inserted, updated, and retrieved by users and applications. As its name implies, transparent data encryption requires no changes to applications, SQL definitions, or queries. The database works seamlessly after encryption is enabled.

Transparent Data Encryption is the easiest of the two encryption methods to implement. In a following part of these series I will discuss when it makes sense to use TDE and when Cell Level Encryption is a better choice.

Activating the EKM Provider
After installing the EKM Provider software from a third party, the SQL Server database administrator uses the SQL Server management console to activate the EKM Provider and place the database or columns under encryption control. The activation of the EKM Provider software causes the database to be immediately encrypted and all further data operations on the database will invoke the EKM Provider software.

Microsoft EKM Provider for Locally Stored Encryption Keys
Recognizing that some SQL Server customers wanted to encrypt data but did not have the resources or time to implement a key management solution, Microsoft provided a built-in EKM Provider that performs encryption but which stores encryption keys locally in the SQL Server context. Understanding that this was not a security best practice, Microsoft recommends that customers use a proper encryption key management solution that separates encryption keys from the SQL Server database. That was good advice - locally stored encryption keys can be recovered by cyber criminals and the use of external key management systems provides better security and compliance.

EKM Provider Software
EKM Provider software is usually provided by your encryption key management vendor. This means that the features and functions of the EKM Provider software can vary a great deal from one vendor to another. Be sure that you fully understand the architecture and capabilities of the EKM Provider before you deploy SQL Server encryption.

SQL Server Versions That Support EKM
EKM Provider support is available in all Enterprise editions of SQL Server including Data Warehouse and Business Intelligence editions. EKM provider support is not available in Standard, Web, or Express editions of SQL Server.

In the following series I will go into more detail on the EKM Provider interface, transparent data encryption, cell level encryption, business continuity, compliance, and other topics.


White P

Topics: Encryption, SQL Server

Fixing the TDE Key Management Problem in Microsoft SQL Server

Posted by Patrick Townsend on Jan 10, 2017 7:31:56 AM

Many Microsoft SQL Server users have taken the first step to protect sensitive data such as Personally Identifiable Information (PII), Protected Health Information (PHI), Primary Account numbers (PAN) and Non-Public Information (NPI) by encrypting their databases with Transparent Data Encryption (TDE). It is extremely easy to implement TDE encryption as it does not require program changes.

Encryption and key management for SQL ServerA common cause of audit failures might not be so obvious and that is the failure to properly protect the SQL Server key encryption key once you activate encryption in SQL Server. With Transparent Data Encryption you have the choice of storing the service master key within the SQL Server context itself, or protecting the master key with a key management system using the SQL Server Extensible Key Management (EKM) interface. Why is it important to do this?

It turns out that it is easy for cyber criminals to recover the SQL Server master key when it is stored within SQL Server itself. (Examples: https://blog.netspi.com/decrypting-mssql-credential-passwords/ and http://simonmcauliffe.com/technology/tde/#hardware)

Simon McAuliffe provides the clearest explanation I’ve seen on the insecurity of locally stored TDE keys in SQL Server. I don’t agree with him on the question of using a key manager to improve security. Given that there is no perfect security, I believe that you can get significant security advantages through a properly implemented key management interface.

If your TDE keys are stored locally, don’t panic. It turns out to be very easy to migrate to a key management solution. Assuming you’ve installed our SQL Server EKM Provider called Key Connection on your SQL Server instance, here are the steps to migrate your Service Master Key to key management protection using our Alliance Key Manager solution. You don’t even need to bring down SQL server to do this (from the Alliance Key Manager Key Connection manual):

Protecting an existing TDE key with Alliance Key Manager

First create a new asymmetric key pair within the AKM Administrative Console using the “Create EKM Key” and the “Enable Key for EKM” commands.

Then return to SQL Server and call the following command to create the asymmetric key alias for the new KEK that you created on the AKM server:

use master;

create asymmetric key my_new_kek from provider KeyConnection with provider_key_name = ’NEW_TDE_KEK’, creation_disposition = open_existing;

In this example, NEW_TDE_KEK is the name of the new key on AKM, and my_new_kek is the key alias.

Then use the ALTER DATABASE statement to re-encrypt the DEK with the new KEK alias assigned in the previous statement:



   {  ASYMMETRIC KEY my_new_kek}

Note that you do not have to take the database offline to perform this action.

Of course, there are other steps that you should take to secure your environment, but I wanted to demonstrate how easy it is to make the change.

The SQL Server DBA and the network administrator will have lots of other considerations in relation to SQL Server encryption. This includes support for clustering and high availability, automatic failover to secondary key servers, adequate support for separation of duties (SOD) and compliance, and the security of the credentials needed to validate SQL Server to the key manager. All of these concerns need to be addressed in a key management deployment.

For SQL Server users who deploy within a VMware or cloud infrastructure (AWS, Azure), Alliance Key Manager can run natively in your environment, too. It does not require a hardware security module (HSM) to achieve good key management with SQL Server. You have lots of choices in how you deploy your key management solution.

It turns out not to be difficult at all to address your SQL Server encryption key insecurities!


White P

Topics: SQL Server, Transparent Data Encryption (TDE)

OpenSSH on the IBM i and Your Security

Posted by Patrick Townsend on Jan 3, 2017 7:45:48 AM

Lately I’ve seen some criticism of the OpenSSH implementation on the IBM i platform which seems to imply that using a third-party implementation of the Secure Shell (SSH) file transfer application is better without the IBM no-charge licensed OpenSSH implementation. I disagree with that opinion and think there are good security and implementation reasons to stick with the IBM OpenSSH implementation.

Here are some reasons why I like OpenSSH:

OpenSSH is supported by an global open source community

Tatu Ylönen founded SSH Communications in 1995 and produced the first versions of an open source SSH implementation. Since 1999 the OpenSSH application has been maintained by the OpenBSD Project which is funded by the OpenBSD foundation and managed by Theo de Raadt. OpenSSH is available on a wide variety of operating systems including the IBM i where it is deployed as a no-charge licensed product and maintained by IBM.  OpenSSH continues to be actively developed and new encryption algorithms have been added recently.

OpenSSH is a widely used by large and small organizations

By some estimates the OpenSSH implementation of the SSH protocol and applications commands a 97 percent market share for SSH implementations. This means that OpenSSH is in wide use by large and small organizations to securely manage their eCommerce needs. This also means that OpenSSH receives a lot of scrutiny by compliance and security experts. Widely deployed solutions tend to get more scrutiny from security experts, and this is true for OpenSSH.

OpenSSH is secure

No application is immune to security challenges. However, OpenBSD and the OpenSSH application in particular have a stellar record for security. With security products, deep expertise and commitment matter. OpenSSH started with security as a leading goal by its developers and it shows. Over the last few years there have been fewer than a dozen security issues, and most were unlikely to be exploited and all were patched rapidly through updates by IBM. The OpenBSD set of applications that include OpenSSH have a great record on security. If you think the IBM i platform has a good security record, take a look at OpenSSH.

IBM provides technical support for OpenSSH

We have all developed a deep appreciation for IBM’s commitment to security over the years. It is one of great values of the IBM i platform. As new vulnerabilities are discovered you need to have a reliable and timely source of patches and enhancements and IBM has stood behind this critical application. Security notifications are managed by IBM so that you know when you need to do an update. By making OpenSSH a no-charge licensed program IBM i customers get patches through the normal PTF update process. Do you know any third-party IBM i vendor with an equal commitment to notification, maintenance and patching? IBM has earned our trust through this process.

OpenSSH is PCI compliant

PCI Qualified Security Assessors (QSAs) like Coalfire, TrustWave and others recognize that a properly patched implementation of OpenSSH meets PCI Data Security Standards (PCI-DSS) compliance, and IBM also tracks OpenSSH for PCI compliance. This again reflects IBM’s and OpenBSD’s commitment to security. If you are using a third-party IBM i solution for SSH how well is it tracked by the PCI audit community?

SSH is a complex protocol

Bruce Schneier said “Complexity is the enemy of security.” SSH is a complex protocol and this means that extra care needs to be taken in its development, deployment and maintenance. No third-party SSH solution rises to the level of care taken by the OpenSSH community and by IBM. Almost every business depends on secure file transfer for daily business operations. Deploying the most secure SSH solution is a critical security step.

OpenSSH does not use OpenSSL or Java JSSE

We’ve read a lot over the last few months about security issues in OpenSSL and Java. Many IBM i customers are confused about the relationship between OpenSSH and OpenSSL. In fact, OpenSSH does not use the OpenSSL library for communications. This means that OpenSSH was not subject to the HeartBleed and other OpenSSL vulnerabilities. We are all also now painfully aware of the security issues in Java. Most browsers no longer allow Java plugins for this reason. Third-party SSH products may or may not use OpenSSL or Java for communications. If you are running a third-party IBM i SSH solution, do you know if it uses OpenSSL or Java?

Third-party SSH solutions provide no significant advantage over OpenSSH

OpenSSH is a secure, reliable, and resilient implementation of SSH for secure data transfer that is backed by IBM and a worldwide community of users and developers. Our Alliance FTP Manager solution fully integrates with the IBM i OpenSSH application for secure, automated and managed file transfer. Our solution automates the OpenSSH transfer of hundreds of thousands of file transfers every day without compromising security.

My opinion? You probably don’t need more IT risk in your life. Stick with OpenSSH for your security needs. You will be in good company.


Webinar: Secure Managed File Transfer on IBM i

Topics: IBM i, Secure Managed File Transfer

Subscribe to Email Updates

Posts by Topic

see all