Townsend Security Data Privacy Blog

Companies deploy our key management system for a number of reasons - meeting security best practices, meeting compliance requirements, ransomware protection, and so forth. Encryption with proper encryption key management is a crucial part of a defense in depth strategy. In addition to providing proper protection for encryption keys, did you know that your key management system (KMS) can play a bigger role? 

Let’s explore some ways you can leverage that KMS system!

With your encryption keys protected by the KMS there are opportunities to leverage the KMS for early warning of an attack. (I am using our own Alliance Key Manager as the basis for these points, if you use a different KMS there might be variations in how to accomplish these tasks.) Here are some suggestions:

Monitor the KMS audit logs

Almost all KMS systems produce audit logs of user and administrator activity. When an attacker attempts to get access to protected data this can produce unusual activity in the audit log. Watch for the anomalies - for example, an unusual user account making a key retrieval attempt, an unusual time of day or day of week for activity, and so forth. And you can watch for unusual key management functions being performed. For example, it is rare that you would decrypt your database. So, an attempt to perform a database decryption at 1am on a Saturday night should raise an alarm. All of this assumes that you have a SIEM or other tool to automate the monitoring and alerting. You can leverage the KMS audit log to help raise an alarm.

Monitor the KMS exception logs

Similar to the previous item, some KMS systems provide a separate exception log. Hackers probably don’t have access to KMS exception logs and you can use this to your advantage. Forward your exception logs to your SIEM or monitoring system and give KMS exceptions a high level of priority.

Monitor the KMS system logs

Your KMS probably runs in its own operating system environment. As an example, our Alliance Key Manager is delivered as a self-contained virtual machine that includes the Linux operating system. That means there are Linux system logs available for monitoring, too. If an attacker is attempting a brute force attack on the KMS, the system logs will have valuable real-time information to help identify the attack. Send the system logs to your SIEM for monitoring and alerts.

Monitor client-side certificates

Most KMS systems use client-side certificates to create a secure TLS session to the key manager. This often involves a CA certificate, client certificate and private key. Attackers may try to access these credentials using a non-standard user account. You can use this to your advantage, too. Restrict access to client-side credentials and monitor for access failures. If your system is humming along and you suddenly see access failures on KMS credentials you should send up a flare! This is almost certainly an indicator of an attack.

Monitor Windows Certificate Manager

If you are protecting data in a Windows environment the KMS credentials may be stored in the Windows Certificate Store. This gives you another ability to detect an attacker’s attempt to gain access to KMS credentials. Monitor activity on the Windows Certificate Store and raise an alert on unusual activity.

Monitor SQL Administrator functions and commands

If you are an attacker and you can get elevated DBA privileges you might try to decrypt the database before exfiltrating it. That would require activity on the KMS to retrieve or unlock the encryption key. You can catch this by monitoring SQL administration commands. (And you can monitor this on the KMS side for unusual key retrieve or unlock activity - A Twofer!). Consult with your database administrator on how SQL administrative commands are logged. All modern databases log this kind of activity.

Monitor privileged database accounts

Database engines often run under special privileged accounts. These accounts usually do not have authority to log onto a system and are restricted to database functions only. Monitor all of your privileged database user accounts for unusual activity. For example, attempting to assign a password to this kind of account is a big red flag. Use this to your advantage.

Monitor client side software changes related to the KMS

You are probably already monitoring the installation of suspect software on your systems. Consider monitoring any client-side KMS software changes, too. For example, the Microsoft SQL Server database makes calls to an Extensible Key Management provider program when you activate Transparent Data Encryption. Most KMS vendors deliver this EKM Provider software as a DLL. You should monitor any unexpected changes to this software and raise an alert.

As you can see there are lots of ways you can leverage your KMS system to improve your security posture. Most of the techniques described here are easy to implement and don’t require programming or changes to your applications. A very easy win!

Patrick

Our customers often ask about encryption key management for the Microsoft SQL Azure Database on the Azure cloud. SQL Azure Database is the Microsoft Azure Database-as-a-Service offering based on SQL Server. It is a natural question because SQL Server has a convenient interface for plugging in a key management solution through their Extensible Key Management (EKM) interface. And our Alliance Key Manager has supported this for more than a decade and is available in the Azure marketplace. 

Here’s the rub: 

Unlike normal SQL Server, the Azure SQL Database offering does not support the normal SQL Server key management interface. It does support encryption of the database, but only by using the Microsoft Key Vault service. So Azure customers are locked out of managing and controlling the encryption keys when using SQL Azure Database. 

This is not a problem with Azure itself! We have customers who have deployed SQL Server in a virtual machine on Azure and use our Alliance Key Manager in Azure with no problems! Microsoft does not allow the use of a key manager and only allows the Azure Key Vault or a Bring Your Own Key (BYOK) option..

Is there anything you can do? 

Sure! Let me describe one approach you can use in a web application that uses SQL Azure Database that gives you exclusive control and access to your encryption keys, and supports a real time mirroring of encryption keys to a key server outside of the cloud. And a bonus is that if you are mirroring data out of the cloud to an on-premise SQL Server database, the key management synchronization and failover will be automatic.

Here is what to do in Azure:

First, deploy Alliance Key Manager right from the Azure Marketplace. It will automatically license for a 30 day no-cost evaluation period (Azure charges may apply). When you access the key manager in Azure Marketplace you will have a link to documentation, and you will be eligible for technical support. Create an AES key to use for encrypting data in SQL Azure Database. Here is the quick start guide to help you get started:

https://docs.townsendsecurity.com/akm_for_microsoft_azure_quick_start_guide

Then, modify your Windows .NET application to make a call to Alliance Key Manager to encrypt or decrypt information using the AES key you created before you insert or update data in a column. Alliance Key Manager provides a simple Windows .NET SDK to make this easy. There is no charge for the SDK and you can download it from the Townsend Security website. Here is the link to the Windows .NET SDK:

https://docs.townsendsecurity.com/akm_guide_for_windows_dot_net_developers

Backups of the Azure SQL Database and all data you copy out of Azure will now be encrypted and under your control. 

What to do in your data center:

You can easily mirror encryption keys from Azure to your own data center. Download Alliance Key Manager for VMware, launch it in your VMware environment, and set up mirroring between Alliance Key Manager in Azure and Alliance Key Manager in your data center. Keys are mirrored in real time and your on-premise applications can use the same logic as in the cloud to decrypt data as needed. Here is the VMware quick start guide:

https://docs.townsendsecurity.com/akm_for_vmware_quick_start_guide

Your applications in your on-premise deployment can now use the same Windows .NET SDK as mentioned above to do decryption when needed.

Voila!

You now have your data encrypted in SQL Azure Database, in your on-premise SQL Server database, and you have full control of your encryption keys! You also have a lot more flexibility about your choice of Cloud Service Providers. 

A few more thoughts:

Triggers, UDFs and Stored Procedures

If modifying your applications is not feasible or costly, consider adding Triggers and Stored Procedures to the database to achieve encryption and decryption tasks. This can be much easier to implement than making code changes. See the resources below to get started.

How to implement User Defined Functions and Stored Procedures in Azure SQL Database:

https://bookshelf.erwin.com/bookshelf/public_html/2020R1/Content/User%20Guides/erwin%20Help/Define_SQL_Azure_Stored_Procedures.html

And

https://www.sqlshack.com/executing-stored-procedures-from-data-pipelines-in-azure-data-factory/

And Alliance Key Manager provides guidance on Triggers and Stored Procedures:

https://docs.townsendsecurity.com/akm_guide_for_windows_dot_net_developers

Mirroring keys in the cloud

Sometimes you are not mirroring SQL Azure Database data to your on-premise database. If you have a backup strategy that involves failover to another Azure availability zone be aware that you can run a second copy of Alliance Key Manager in that zone. Alliance Key Manager will mirror encryption keys across any availability zones and regions.

Mirroring keys to AWS

If you really want to mirror your encryption keys out of the Azure cloud, but don’t want to bring the keys in-house, you can mirror them to AWS! Alliance Key Manager is also available in AWS and fully supports cross-cloud key mirroring.

Cyber-attacks are executing at much faster speeds now. In the past you might find that an attacker waited weeks or months after gaining access to your system before stealing sensitive data. Those days are mostly gone. An attacker now can execute in a few minutes or hours. Early detection is critical for interrupting an attack. And a fast response is crucial to stopping the attack.

There is a good chance that you are already encrypting your sensitive data to prevent it from being used for extortion by a ransomware attacker. If you are already encrypting your data, you are also probably using a key management system (KMS) to store your encryption keys. That is a security best practice, and the right thing to do.

Are you ready for the next step?

Did you know that your KMS can play an important part in early detection of an attack? Your key management system should be collecting key retrieval activity into real-time logs. For example, our Alliance Key Manager logs every single action that takes place including key creation, retrieval, deletion, and so forth. Why not use these logs to help detect an attack? After all, the attacker is going to try to steal the data, and that means there will likely be activity on the key manager. And that means a KMS log can help you thwart an attack.

How can we implement this in a real environment?

Our Alliance Key Manager solution comes with log forwarding capability already built in. It is easy to start forwarding the KMS activity log to your SIEM solution using the common syslog-ng protocol. All SIEMS can ingest the KMS activity log, so just start forwarding them.

Next, train your SIEM to detect anomalies. A good SIEM is really good at anomaly detection! So let’s put it to work. Here are some KMS events that should be early warning signs of an attack in progress:

• Retrieving an encryption key at an unusual time of the day.
• Retrieving an encryption key on an unusual day.
• Failure to retrieve a key for an extended period of time.
• Unusually high level of key retrieval requests.
• Unexpected user attempts to retrieve a key.
• Attempts to retrieve a key that does not exist.
• Failed TLS negotiation to retrieve a key.
• Key retrieval request from an unusual IP address.

As you can see there are many events or patterns that can indicate the activity of an attacker. And KMS logs are likely to show this activity early in the attack. Training your SIEM to alert on this activity is usually pretty easy to do, but that depends on the functions of the SIEM.

Another big bonus for integrating the KMS with your SIEM is that many SIEMS can now take pro-active and automatic steps to thwart an attack. In addition to alerting the IT staff of a potential attack, some SIEM solutions can execute scripts that take a database off-line, or even take the key manager off-line. You can get very creative with the automatic responses to a cyber-attack.

Your KMS can be your “canary in a coal mine”. The features are there ready to be put to use.

If you are running our Alliance Key Manager solution just raise a problem ticket with our support team to get some pointers on how to forward logs to your SIEM. It will be easy to do.

Patrick