What’s new: Microsoft Sentinel Deception Solution

Updated 6/Feb/2023 - the solution has moved to be maintained by the community; we invite everybody to contribute to it.

 

 

The art of deception

Among the most successful and well used techniques the adversary has in their toolbox is an attack which involves some form of deception, knowing full well the human vulnerability and ease of which it can be exploited. Whether it’s social engineering or spear phishing, deception plays a major part in most cyber-attacks impacting our customers today. But deception is a two-way street and defenders can use it to their advantage. By planting decoy resources in strategic locations and with heightened monitoring, defenders can lure an attacker in, forcing them to reveal their presence when they would otherwise remain undetected. 

 

Traditional approaches to deception, often referred to as ‘honeypots’, involved provisioning dedicated infrastructure including servers, databases, and other resources to mimic existing workloads. Security monitoring would trigger an incident for any activity detected as this infrastructure should never be accessed under normal circumstances. Deployment of dedicated infrastructure is costly, both in terms of the assets deployed and associated management overheads. Furthermore, unless significant efforts are made to make the environment look convincingly real, signals giving away the synthetic environment are easy to spot.

 

Yet we know there are tangible security benefits with the use of deception. As our customers continue to shift workloads to Azure, using cloud native capabilities to digitally transform their business, we wanted to offer a solution which can help customers fully leverage the potential this brings in terms of visibility, manageability and reduced cost of ownership.

 

Introducing the Microsoft Sentinel Deception Solution

We are excited to announce the Microsoft Sentinel Deception Solution which is is now a community supported product and we invite you to participate in extending it. This solution moves away from traditional approaches and uses the concept of ‘honeytokens’ by injecting decoy objects into existing workloads. Detection principles remains the same, because there is no legitimate reason to access a honeytoken, any activity indicates the presence of a user who is not familiar with the environment, and could potentially be an attacker.

 

Because no dedicated infrastructure is required, overall costs to the customer are reduced. Additional benefits include wider detection coverage since honeytoken objects are embedded throughout the environment. Manageability is improved using simple UI driven controls to allow deployment at scale and planted honeytokens blend in with existing environment making it hard to differentiate between a honeytoken and its real counterpart.

 

Starting today, the solution is based on Azure Key Vault keys and secrets. Key Vault is a highly sensitive resource, designed to protect materials which are of high value to an attacker. Information they store such as passwords, connection strings, and cryptographic keys are often used for API level access and could be used for privilege escalation and lateral movement if a Key Vault is breached.

 

 

One of the keys in the screenshot above is a honeytoken, can you guess which one?

Now let’s look at some of the key components of the solution so you can start preparing to evaluate it further.

 

Detecting honeytoken activity

We include out-of-box analytics rules which help you monitor honeytoken activity in your environment. These rules will detect events associated with Key Vault actions such as retrieving key or secret values and other sensitive operations like decryption. Because this monitoring relies upon Key Vault and Azure activity diagnostics logs, we’ll also trigger an incident if the logging configuration is modified.

 

 

You can test these rules by revealing a key or secret for a Key Vault honeytoken, which results in a new security incident being generated.

 

Each alert contains entity mapping data, such as the user account and IP address as well as custom entities representing the affected Key Vault and corresponding honeytoken key or secret and operation type.

 

Investigate honeytoken incidents

You can investigate honeytoken incidents using a pre-defined workbook. The Incident Investigation workbook displays all the information needed to respond to an alert, along with data points to pivot on during an investigation. You can examine data within the workbook and from here, launch the entity pages to reveal even more detail.

 

 

 

 

 

Deployment at scale and camouflaging

To ensure optimal detection capability, it’s necessary to reach full coverage of Key Vaults with deployed honeytokens. In many organizations this presents a challenge because the SOC generally doesn’t have any access to Key Vaults (and rightly so!).

 

In response, we’ve made this task super easy. Using the power of Azure workbooks, SOC analysts can share a honeytoken management workbook with Key Vaults owners, offering a range of deployment options from custom manual honeytoken additions to one-click, deployment at scale to all Key Vaults within the scope of management.

 

As shown in the screenshot below, the Management workbook provides a simple user interface to deploy honeytokens across the enterprise.

 

 

Honeytokens are maintained inside a watchlist along with other properties and tags which help identify and categorize. These entries are added automatically during deployment using an Azure Function App which is executed from the Management workbook.

 

 

 

Deception is key, so we’ve also taken steps to make it hard to spot a honeytoken against the existing keys or secrets. We make sure any honeytoken key or secret is indistinguishable from the others by deriving the name from existing keys and secrets. Further to this, customers can use their own keyword prefixes, for example, based on common organization naming standards.

 

Enterprise-wide visibility through Azure Security Center integration

To get the best possible detection coverage, honeytokens should be deployed as widely as possible throughout the enterprise. The role of the SOC is to monitor honeytokens but they have no access to the Key Vault resources themselves. The Key Vault owner is responsible for adding and managing honeytokens, and to ensure full coverage of all Key Vaults within their scope of control.

 

We’ve helped customers reduce the friction in getting honeytoken coverage across the environment by providing custom Azure Security Center recommendations which give customers enterprise-wide visibility of Key Vaults not covered by the solution. Through this experience, Key Vault owners can launch the Management workbook directly from Azure Security Center to complete the task and update the Key Vault management status with compliance.

 

 

 

 

 

Getting started

You’ll find this solution in the Azure Sentinel Marketplace and to extend it by contributing to Sentinel GitHub Account.  

As a community solution, it is not maintained or supported by Microsoft.