Simultaneously, we are moving towards Information Systems that are built on an ever-increasing diversity of environments, thanks in particular to the Cloud, which is now an integral part within corporate Information Systems. This enables corporations ) to expand their capabilities, however it is also the surface area  for risk of attacks.   

Conventional intrusion detection and protection techniques already exist and are developing exponentially. These are effective against the most common attacks, however are not always adapted to the specificities of the Cloud.   

This raises questions about the use of proactive strategies, such as Deceptive Security, to stay one step ahead of attackers. Particularly in the context of Cyber-Resilience; how can this kind of technology be used in both a traditional and a cloud environment?   

When should Deceptive Security techniques be used? Are Deceptive Security solutions in the Cloud being developed today? Are there any specific strategies to consider in a Cloud environment as opposed to a traditional one?  

We will answer these questions in a mini-series of 2 articles. In the first article, we showed how to develop and evaluate your decoy strategy. In the second article, we’ll present a practical example of deceptive security in AWS.  

Initial assumptions and choice of scenario     

Thanks to Wavestone’s expertise and the resources shared by our CyberLab, we have designed a simple scenario to illustrate the use of decoys in an AWS Cloud environment. The example detailed below is inspired by a CTF (Capture The Flag) scenario designed by the CyberLab team to illustrate the lateral propagation of an attacker.  

As in the previous scenarios, where we used Deceptive Security for the detection of attackers already introduced into the IS, the aim is once again to avoid attracting opportunistic attackers to our network with a “search” Deceptive Security approach. We therefore assume an initial infection of some kind, which is highly probable (all the more so in poorly controlled Cloud environments), and concentrate on detecting the intruder as it is being deployed into the network. 

Applying this approach to an AWS environment is no innocent matter. One of the benefits of the Cloud lies in its simplified identity management and easy delegation of access, but this asset can turn to the advantage of attackers in the event of unintentional exposure of resources, or the creation of dangerous links between zones of different security levels. There is no shortage of hardening and prevention measures, generously promoted by Cloud providers themselves, but these vulnerabilities remain in poorly hardened accounts and subscriptions, whose administration too often obeys rules that are still informal.   

The attack scenario and associated luring will therefore be based on the principle of linking two AWS accounts, here conceived as a production environment and a less critical development environment. We’ll place ourselves in a scenario where an approval relationship is used to propagate from the development account to the production account, via the endorsement of a cross-account role. 

Luring scenario  

Description of the scenario   

Let’s assume that an unauthorized user has gained access to an EC2 machine (domainIntegrated-EC2) within the test account (initial infection). After an initial successful connection,  they attempt to access commonly used resources such as Amazon Simple Storage Service (Amazon S3), or tries to elevate their privileges by assuming other roles (role chaining) related to the role to which they have access.  

This lateral propagation scenario is a common attack technique in cloud environments due to the nature of their architecture and the cloud computing responsibility model, where the customer is responsible for securing their applications, data and access control (while the provider ensures the security of the underlying infrastructure). 

As illustrated below, lateral propagation attacks take advantage of weaknesses in the customer’s security controls, such as misconfigured authorizations or the application of too-weak authentication mechanisms, to gain unauthorized access to other resources in the environment. 

Scenario from the attacker’s point of view 

0. After compromising a “domainIntegrated” EC2 machine, the attacker discovers that it has a role associated with it (“Semi-Admin-role”):  

 
Enumeration of EC2 machine domainIntegrated 

It then lists the rights of the “Semi-Admin-Role”: 

 
Enumeration of Semi-Admin-Role rights 

First, this role has modification privileges on a resource in the “AWS – SHARED” account: it can assume (sts:assumeRole) and modify (iam:UpdateRole) a role called “LambdaAuto”. He can then assume (by “role chaining”, step 5 in the diagram above) another role called “SecurityAudit” in a different account, called AWS MASTER.  

The attacker also realizes that they can directly assume another role (“IAM-RO-Role”) in the AWS – MASTER account. This latter role attracts particular attention, as the MASTER account’s name suggests a much greater scope of action than the simple SHARED account, and the IAM-RO-Role role suggests an extended scope of vision over the account’s resources. 

1. The attacker assumes the “SemiAdmin-role”, which then allows them to assume the “IAM-RO” role and attempt other actions that will enable them to analyze their field of vision. 
2. Indeed, after assuming the “IAM-RO” role, he proceeds to an IAM enumeration where they becomes aware of the roles and users in their field of vision: 

List of roles in the field of view of the IAM-RO role  

List of users in the field of view of the IAM-RO role  

The “SecurityAudit” role in particular attracts their attention thanks to the privileges that this name suggests and the role description, which provides information on these privileges:  

SecurityAudit role description 

However, the attacker only has read access to the resources listed. They will therefore look to see if any of these resources can be written to from the SHARED account, where they have high privileges. For example, if certain MASTER account roles can be endorsed by SHARED account roles:   

List of roles that can be assumed from an external account (here the SHARED account) 

The attacker investigates the approval relationship of the “SecurityAudit” role, which authorizes an endorsement by the “LambdaAuto” role of the SHARED account. 

0. Back on the SHARED account, all the attacker has to do is check that the other counterpart of this approval relationship, i.e. that the “LambdaAuto” role does indeed authorize the “SecurityAudit” role’s endorsement in its approval policy. This is not the case, but the “SemiAdminRole” role allows it to configure this authorization. 

1.Once the “LambdaAuto” role approval policy has been modified, it can now assume the “LambdaAuto” role. 

2. Then they take on (by role-chaining) the role of “SecurityAudit”, the real decoy. 

Role chaining of the attacker 

After attempting to take on the “SecurityAudit” role, from which they hope to gain the privileges of a security auditor (announced in step 1), the attacker in reality finds themself without any real powers, for example : 

Example of denied access from the SecurityAudit  

Creating lures 

The diagram below shows how decoys are added at different stages of the attack and how they are configured by the defender: 

Scenario from the defender’s point of view  

0.The “Semi-Admin-Role” is the entry point into the decoy scenario. It can therefore be associated with any resource likely to be compromised (here the EC2 “domainIntegrated”) to redirect the attacker to the decoys. 

No alerts are configured at this level, as the Semi-Admin role’s connection to all SHARED account resources makes it likely that unintentional endorsements will be triggered, resulting in false-positive alerts. 

1. Once the IAM-RO role has been assumed, the attacker is then invited into an account entirely dedicated to luring and familiarising themselves with the surrounding resources, gaining a complete overview of all the account’s roles and users.   
2. By populating the attacker’s field of vision not only with the main “SecurityAudit” decoy, but also with other dummy roles and users, we ensure that the account’s appearance appears credible and that our key decoy, the SecurityAudit role, is not isolated.   

We thus add to the account :   

• Users : different user names attracting the attacker.  
• The “LambdaFunction” role: this role is created to simulate a Lambda function that calls on AWS services.  
• The “LogsAndS3Bucket” role: a role created to facilitate access to logging services and S3 storage resources within the account.  
• The “taskExecutionRole”: the task execution role that can be used for different purposes and services associated with the account.  

3.  The “SemiAdminRole” role has deliberately been configured with permission (iam:UpdateRole) on the “LambdaAuto” role, enabling it to modify this role and thus add the approval relationship to the “SemiAdminRole” role. For monitoring purposes, an initial alert can be triggered at this level when the “LambdaAuto” approval relationship is updated, enabling the “SemiAdminRole” to assume it.   

4. The “LambdaAuto” role is deliberately created as the gateway to the “SecurityAudit” role, once its approval relationship has been modified using the privileges of the “SeminAdminRole” role. 

5. The “SecurityAudit” role is deliberately configured with an approval relationship authorizing the “LambdaAuto” role of the SHARED account to assume it. 

6. At this stage, the attacker had assumed that they would be granted security auditor rights. However, a very restrictive Security Control Policy (SCP) was applied, granting them no privileges on the account. 

The policy prohibiting all actions from the Security-Audit-Role 

Alerting chain 

An alerting chain in the AWS cloud refers to a means of communicating notifications or alerts generated by AWS services to users or teams responsible for managing these services, enabling them to take rapid action to resolve problems and minimize service interruptions.   

To set up an alerting chain, you first need to configure AWS services to generate alerts when certain events occur, such as, a server down or an application exceeding a specific CPU usage threshold. Once these alerts have been generated, they can be sent to the appropriate alerting chain according to the notification preferences configured by the user or the team responsible for managing the service.   

In order to detect the attacker, we use the following AWS services to create the alerting chain: 

• CloudTrail l to track actions performed on the compromised AWS account; 
• EventBridge to detect any “AssumeRole” event of the “SecurityAudit” role and trigger an alert ; 
• Simple Notification Service (SNS) to send the alert by e-mail with the information gathered during the attack.  

Illustration of the alerting chain 

Alerting chain creation steps :  

Cloudtrail configuration  

The first step in creating an alerting chain on AWS is to enable CloudTrail (if not already activated) in your AWS account. CloudTrail logs all activity and API calls in your account, which can be useful for security, compliance and troubleshooting purposes.   

Based on the logs generated in CloudTrail, we’ve created an EventBridge rule that sends notifications to the SNS service whenever the “SecurityAudit” role is assumed (event type: AssumeRole). 

Creation of an EventBridge rule 

A rule monitors specific types of events, and when a corresponding event occurs, it is routed to the service associated with the rule and handling the event (in this case, the SNS service).  

The event model detects all events of the “AssumeRole” type occurring in the account used and triggers the alert. In order to avoid false positives when triggering alerts, we have refined the event model to be as accurate as possible for the events we are interested in.   

This means including relevant fields, such as event source, detail type or specific values, to refine the matching criteria. This reduces the risk of unrelated events triggering the rule. 

The event model detecting all “AssumeRole” events on the “SecurityAudit” role 

The Eventbridge service must therefore first be linked to the SNS target.   

The target related to the EventBridge rule 

SNS rubric configuration  

At this stage, an SNS topic is created and linked to a subscription of an e-mail endpoint authenticated later. The SNS topic will be the target of the EventBridge rule. Once the topic has been created, the e-mail subscription is carried out by selecting the e-mail address as the protocol (endpoint) where the alerts are to be received. 

Other targets than e-mail could be considered for receiving alerts (ServiceNow, SIEM, etc.). 

Details of the SNS rubric 

Alert customization  

EventBridge’s Input Transformer function was used to customize the content of the alert, so that only the most important elements were displayed.   

It allows you to customize the text of an event before it is transmitted to the target.  This is achieved by defining JSON variables to reference values in the original event source. 

Input transformer configuration  

In our case, the variables listed below will constitute the alert message: 

Input transformer creation 

Input model 

The input model will use the variables defined previously within the final alert message:    

Input model creation 

Once the “SecurityAudit” role has been endorsed, an alert is sent to the endpoint created: 

Example of e-mail alert content 

Cost of the AWS services used  

AWS offers a pay-per-use approach to pricing its cloud services. With AWS, you only pay for the services you need, as long as you continue to use them, without a long-term contract. You only pay for the services you use, and if you stop using them, you won’t be charged any additional costs or termination fees.  

The services deployed in this scenario are not intended to be used except in the event of an intrusion or security incident. The associated costs are therefore negligible.   

Decoy evaluation with the PARCS matrix 

Several criteria can be used to evaluate a lure, and here are the results of our analysis based on the PARCS matrix:   

• Pertinence (efficiency) : 4/4 

«  Various approaches can be adopted to effectively spot the initial compromise of an EC2 instance and the lateral propagation of an attacker. In our context, depending on the resources at our disposal, one possible strategy is to monitor operations by analyzing logs, which will enable malicious actions to be detected. These observations could then be used to generate alerts for administrators. For example, an alert could be triggered in the event of an intrusion attempt via a brute force attack on the RDP service of EC2 instances within our AWS environment, thanks to GuardDuty.  

In addition, it would be possible to use a combination of AWS services such as CloudTrail and EventBridge to establish detection rules and automate interventions in response to specific activities, including those related to cross-account access, and create detection rules that monitor all endorsement events to trigger actions in the event of corresponding events. » 

• Attractivité (attractiveness): 4/4 

« The decoy is distinguished by a dedicated account, significantly increasing its power of attraction. By having access to the metadata of all the resources within their reach, the attacker can also verify various levels of privilege, which substantially enhances credibility. Thanks to the ability to visualize the dates and times of the last uses of resources in their field of vision, they can deduce that these resources are rarely used. With this in mind, a lambda function is implemented to automate the execution of various resources or their authentication, thus guaranteeing proof of recent use.  » 

• Risque (risk): 4/4 

« The authorization granted to the IAM-RO role only confers IAM privileges to the attacker in the context of a purely fictitious account. Thanks to appropriate configuration of the upstream SCP, any attempted actions by the Security-Audit role will also be thwarted. The only elements deliberately introduced in a real environment are the Semi-Admin and Lambda-Auto roles, which are subject to stringent policies preventing any assignment of rights or privileges in the event of attempted malicious use. These policies include read-only access (IAMReadOnlyAccess) and a restriction preventing any modification of account role authorizations, as defined by the SCP. » 

• Crédibilité  (credibility): 3/4 

« The credibility of the decoy may be called into question by the resources available to it and potential limitations, such as an Inline Policy that restricts permissions and possible actions. It’s important to take these factors into account, as they can create doubts in attackers and compromise the decoy’s effectiveness. It is therefore crucial to put in place measures that make the decoy as realistic and convincing as possible, ensuring that it has access to the relevant resources and authorizations to create a credible scenario. » 

• Scalabilité (scalability) : 3/4 

« Depending on the size of an infrastructure, it may be possible to implement fluid deployment and maintenance of components, thanks to the use of automated scripts empowered to perform operations on resources. However, careful monitoring of all resources is essential to consolidate security in the face of possible attacks, and to ensure rapid reaction to defend an extended perimeter.»  

In conclusion, implementing such a Deceptive Security scenario in the Cloud, offers an approach to improving its overall security. It helps restrict an attacker’s ability to explore and propagate across the network, by presenting deceptive paths, delaying their progress and enabling faster detection and response. Decoys, which resemble attractive targets, divert attackers’ attention and resources away from real assets, increasing the chances of early detection.  

In addition, alert mechanisms play a crucial role in providing rapid information on potential intrusions to security teams, enabling rapid incident response and limiting the impact of attacks.  

Combining these defence strategies strengthens the overall security posture of Cloud environments, improves their resilience in the face of constantly evolving cyber threats, and guarantees the integrity and confidentiality of sensitive data.   

By using these deceptive security measures, companies can strengthen their defence against cyberattacks. However, it is important to note that Deceptive Security does not replace existing standard cybersecurity solutions, and that protection against cyberattacks requires the use of complementary security techniques for optimal defense. 

ANNEX – AWS Services  

Definitions from source : AWS documentation → docs.aws.amazon.com. 

SCP – Service control policies : Service control policies are a type of policy that enable central control of authorizations. This ensures that broad guidelines are followed for all AWS accounts in the organization.  

EC2 – Elastic Compute Cloud : AWS EC2 allows you to rent servers (EC2 instances) to best meet your workload needs.  

STS – Security Token Service : AWS STS enables you to request temporary security credentials for AWS resources. This makes it possible to grant temporary access to resources via API calls, the AWS console or the AWS CLI (Console Line Interface).  

Please note: Each STS token has a lifecycle, defined when it is created, of between 15 minutes and 36 hours.  

CloudTrail : AWS CloudTrail is a service that records the actions performed by an AWS user, role or service. 

Fonction Lambda : The Lambda function is a service for executing code. 

SNS – Simple Notification Service : Amazon SNS is a web service for managing the sending of messages (SMS, e-mail, HTTP.S, etc.). 

Thanks to Charles BULABULA  for his contribution to this article. 

Cet article Deceptive Security: the solution for effective detection in the cloud? – Deceptive use example in AWS cloud  est apparu en premier sur RiskInsight.

Today, cyber-attacks are part of our daily lives, and are becoming increasingly numerous and sophisticated.  

Simultaneously, we are moving towards Information Systems built on an ever-increasing diversity of environments, thanks in particular to the Cloud, which is now an integral part within corporate Information Systems. This enables corporation to expand their capabilities, however it also the surface area and risks of attack.  

Conventional intrusion detection and protection techniques already exist and are developing exponentially. These are effective against the most common attacks, however are not always adapted to the specificities of the Cloud.  

This raises questions about the use of proactive strategies, such as Deceptive Security, to stay one step ahead of attackers. Particularly in the context of Cyber-Resilience: how can this kind of technology be used in both a traditional and a cloud environment?  

When should Deceptive Security techniques be used? Are Deceptive Security solutions in the Cloud being developed today? Are there any specific strategies to consider in a Cloud environment as opposed to a traditional one? 

We will answer these questions in a mini-series of 2 articles. In the first article, we will show you how to develop and evaluate your decoy strategy. In the second article, we’ll present a practical example of deceptive security in AWS. 

Develop and evaluate your deceptive strategy  

Ambitions of Deceptive Security 

Deceptive Security in a nutshell 

“Deceptive Security” (referred to as “Deceptive” in the rest of this article), or “digital decoying“, is a cyber-defense technique that deals with the intrusion of attackers into an IS (Information System). It works by setting up traps and/or decoys in an IS. These are designed to imitate legitimate technology, so as not to be identified as security systems/measures.  

This method makes it possible to detect intrusions by generating alerts, to prevent damage to the actual infrastructure and to observe the practices used by the attacker.  

Before delving into the details of this subject, we recommend reading the article “Deceptive Security : comment arroser l’arroseur ? “, which describes the main concepts of “Deceptive Security“.  

The main objectives of Deceptive 

The use of Deceptive on an IS can have several objectives:  

•  Detect an intrusion  
•  Distract the attacker  
•  Analyze the techniques used in the attack 

This technology can be used at different levels of maturity, depending on the needs identified.   

The technology can be used to meet many of the needs mentioned above, but the key is to determine our requirements for this technology in advance. If we restrict the needs for detection, it should be noted that the configuration, deployment and maintenance of Deceptive will be far less complex than if we push the possibilities of this technology to the maximum (e.g. setting up complex scenarios to lure the attacker and strategic analysis of his actions).

The benefits of Deceptive 

Why Deceptive ? 

As discussed in the introduction, today’s cybersecurity challenges are fueled by the need to detect and react to growing attacks.  

Deceptive does not replace existing standard cybersecurity solutions. Being a more complex tool, it acts as a complement to cover all types of attack, including the most sophisticated.  

This technology is not designed to prevent an attack, but to alert security teams, minimize the effects of the attack and observe the intruder’s modus operandi (“Detect, Distract & Analyze”). 

Honeypot VS Honeytoken 

Presentation of concepts 

Depending on the needs and how they are to be used, different types of decoys exist. Whatever the case, they take on the appearance of attributes that make up our Information System.  

The best-known decoys are “honeypots”. These are servers or workstations that imitate real machines on the network. There’s also what’s known as a “honeynet”: a network of servers.   

Another type of decoy is of growing in popularity. This is a decoy that hides directly on a system. These are generally represented by documents or other files whose role is to trigger an alert when someone comes to interact with them. Finally, we have “honeytokens”, which are data, information, often secrets or keys used to access a dummy resource on the IS (a honeypot, for example). 

A fundamental difference 

Traditionally, honeypots enable the observation and understanding of an attacker’s actions, as well as detecting an intrusion. The difficulty in this case is to configure a decoy that is attractive and credible enough for the attacker to fall into the trap, without delivering information that could compromise a component of our real infrastructure.  

However, honeytokens can be more complex and enable the creation of a finer and more credible decoy. Without honeytokens, the probability of trapping an attacker is lower, and analysis results are not always reliable. The honeytoken’s dependence on its environment makes it more attractive in comparison to a honeypot, which represents no more than a trap with no possibility of subsequent escalation. For honeypots to be effective, we recommend deploying one or more complete honeynets, however it is important to consider the cost of such an infrastructure.  

Cloud technology development 

Today, the challenge for the most mature Deceptive solution vendors is to develop specific services in the Cloud.  

Indeed, companies are increasingly using the Cloud to extend their storage, deploy virtual machines, containers and so on. This provision of services is very popular and effective, but at the same time, the interest of cyber-attackers is growing. Templates, or default configurations, make life easier for businesses, but can increase cybersecurity risks. Even though many Cloud providers are making great strides in this area, default configurations don’t always comply with IT security guidelines.  

The Cloud is therefore a new playground for cyber-attackers. That’s why we’re focusing today on adapting our knowledge of Deceptive to protect Cloud environments and services too.  

Overview of the main publishers on the market 

It’s important to note that Deceptive is not reserved for overly complex applications. There are all kinds of offers on the market. Some companies offer services that enable you to obtain a complete off-the-shelf tool, while others focus on customization, lure quality and therefore the possibility of using their tool to create your own lures (configuration and maintenance not managed by the solution itself).  

Here’s an overview of the main publishers and their solutions:   

For some, the current trend is to join forces with other tools or integrate their solution with an EDR (Endpoint Detection and Response) to increase the effectiveness of the technology and meet market needs.  

As mentioned above, the challenge that some have chosen to tackle is to adapt to a Cloud environment. For example, solutions such as “Attivo Networks”, acquired by SentinelOne, are developing Cloud AWS offers that propose the creation of decoys linked to the service (e.g.: EC2, S3, AWS access keys, etc.).  

How to build and place decoys? 

Deceptive strategies 

Once you’ve familiarized yourself with this technology and all the possibilities it offers, it is worth asking yourself the question, what strategy or strategies you should adopt with regard to the number of traps and/or decoys to be implemented, and where they should be placed in the IS.  

To adapt to different use cases, 3 strategies stand out, responding to distinct needs: 

Indeed, the Deceptive strategy to be adopted is often tailor-made according to the IS infrastructure and, above all, according to the priorities and objectives defined beforehand.  

By way of example: if you need to enrich your detection technologies within your IS, it may be worthwhile to study the strategy of “mass deployment” of decoys. The aim is to create a phantom IS, thereby increasing the likelihood of the cybercriminal falling into a trap that will trigger an alert to the security teams.  

PARCS matrix 

The challenge when talking about Deceptive, and more specifically about lures, is to answer the questions: What is a good lure? How do you create a good lure? Where to place it? How many to place? etc.  

The article “ HoneyWISE : stratégie d’exploitation d’honeytokens en environnement Active Directory ”, written by Augustin TOURNYOL-DU-CLOS and Nathan FAEDDA, proposes a decoy strategy against certain attacks in a specific context: AD (Active Directory). We’ll also look at honeytokens in comparison with honeypots in the rest of this article.  

The objective of this study was to simply test the implementation of decoys within the AD and to measure their effectiveness using the “PARCS” matrix.  

PARCS was born on the basis of 5 criteria, originally conceived in the context of an AD environment but applicable to all environments:  

When designing a decoy, it’s a good idea to prepare a PARCS to check your thinking and ensure that it matches your expectations. It is also important to take into consideration minimum requirements illustrated by these 5 criteria: Relevance, Risk, Credibility, Attractiveness and Scalability.  

The objective of this matrix is to determine a balance between importance and priority based on these criteria’s (Is the lure’s attractiveness important in my use case? Do I need a scalable solution? How scalable? etc.).  

Example of PARCS use: Kerberoasting scenario “Stealing or falsifying Kerberos tickets” 

Perhaps the best way to illustrate the PARCS matrix presentation is with an example from the “ HoneyWISE ” article.  

The AD attack called Kerberoasting is, “[…] in synthesis, the offline brute force (no logon failure) of a Kerberos ticket receiving the secret of a service account, without having to send a single packet to this service or even being the local administrator of the compromised workstation”.  

“Kerberoasting […] hijacks the native operation of Kerberos in order to carry out an attack. This hijacking takes place on steps 3 and 4 of the Kerberos authentication process, as shown in the following diagram”: 

For this attack case, Augustin TOURNYOL-DU-CLOS and Nathan FAEDDA propose in their article to deploy a honeytoken against Kerberoasting (see part 2.3 “Description of detection scenarios” – scenario 2).  

Here is the result, through PARCS, of the study of this type of honeytoken in the context of a Kerberoasting scenario (16/20): 

• Pertinence (efficiency): 4/4 
  • «  The alerts generated by this honeytoken are reliable. In fact, as soon as a TGS ticket is requested to access an unused and non-existent service, it becomes clear that a malicious action is underway. » 
• Attractivité (attractiveness): 3/4 
  • «  The attractiveness of this token lies in the fact that carrying out the attack does not require any privileges, and can potentially gain privileges while being silent (generation of traffic deemed legitimate). Provided that the account chosen to lure the attacker appears privileged and managed by a user (so that the password is likely to be simple), this honeytoken is highly attractive. » 
• Risque (risk): 4/4 
  • « In our example, a 64-character password has been defined, which cannot be broken in a reasonable time. » 
• Crédibilité (credibility): 3/4 
  • «  Subject to the choice of account name and attributes according to the production context in which it is deployed, since the attack is based on normal Kerberos operation, it should come as no surprise that it can be carried out. Credibility is therefore high. » 
• Scalabilité (scalability): 2/4 
  • «  The decoy account can be deployed automatically on several domains using scripts. However, for an effective lure, contextualization remains essential and will be the major obstacle to effective mass deployment. The cost of providing this contextualization and keeping it up to date must therefore be taken into account.  » 

To conclude, Deceptive Security solutions must be considered on a case-by-case basis. It is imperative to determine in advance the objectives to be prioritized, the strategy to be adopted, the scope to be covered, and so on.  

In certain situations, especially for companies with mature IT security systems, it may be appropriate to implement Deceptive Security solutions. This is to be applied in addition to standard minimum security tools such as firewalls, antivirus, intrusion detection and/or prevention systems, etc. The aim is to cover all types of cyberattack (“0-day” type, with no known pattern).   

This technology can be difficult to implement for smaller companies, as they may not have the essential security tools in place by default, nor the resources to configure (e.g., design decoys, create strategies and scenarios) and maintain such a solution (e.g., dedicated maintenance teams).  

Today, the market is expanding, mainly around detection thanks to Deceptive, but not exclusively. For the time being, however, vendors’ interest in building deceptive solutions is focused on traditional environments. Solutions for Cloud AWS, Azure, etc., are still underdeveloped. 

Thanks to Augustin TOURNYOL DU CLOS for his contribution to this article.

Cet article Deceptive Security: the solution for effective detection in the cloud? – your luring strategy.  est apparu en premier sur RiskInsight.

Enhancing detection with new approaches

Think identity to detect suspect behaviors: UEBA

User and Entity Behavioral Analysis (UEBA—previously known as UBA) technologies are among the latest tools being used to enhance SOC’s detection arsenals. As their name suggests, they take a specific approach—leaving aside the technical considerations of current solutions (SIEM, etc.), and, instead, analyzing the behavior of users and entities (including terminals, applications, networks, servers, connected objects, etc.).

The principle is simple, but its implementation much less so. To be effective, UEBA approaches require a diversity of sources, and a variety of data formats. Traditional sources, such as SIEM and log manager(s), are employed and, in addition, certain resources (such as ADs, proxies, BDDs, etc.) are often used directly.

But, to perfect their detection capabilities, UEBA solutions also draw on new sources: information on users (HR applications, badge management, etc.), exchanges between employees (chats, video exchanges, emails, etc.), or any other relevant sources (business applications that need to be monitored, etc.).

Taking all this information together, UEBA solutions analyze the behavior of users (and entities) to identify potential threats. They can use static rules, in the form of signatures to be detected (which are often already implemented in SIEM solutions): simultaneous connections from two different locations, or unusual times of use, etc.

But the real strength of UEBA lies in the use of Machine Learning algorithms to detect changes in the behavior of users or services: suspicious business-function operations, access to critical, previously unused applications during holidays, unusual data transfers, etc.

Although UEBA was initially conceived to counter fraud, its role has gradually broadened to cover some areas that typically pose problems for SIEM: data theft, compromise or loan of application accounts, terminal or server infection, privilege abuse, etc.

Thus, today, UEBA is positioning itself as complementary to SIEM, adding to the latter’s “technical” approach by providing “user” visibility, and bringing an additional layer of intelligence to the analysis.

The market’s view is that, in the coming years, UEBA solutions will probably cease to exist in their present form. Instead, they’ll be integrated into existing solutions (SIEM, EDR, etc.), changing their form from products to functionalities.

Examples of UEBA publishers:

Trapping attackers: deceptive security

Deceptive Security can be considered as a move to a higher form of the Honey Pot approach. Here, decoys, in the form of data, agents, or dedicated environments, are distributed widely throughout all, or part of, the IS.

Depending on the needs and solutions, Deceptive Security tools can serve two purposes. By diverting the attention of attackers away from real resources and leading them down false trails, they can act as a means of protection.

But above all, monitoring these decoys can detect threats that are spreading within the IS. In fact, the decoys have no other use than to lure potential attackers or to provide false information; any communication with them is then, by definition, suspect.

This type of solution isn’t a replacement for existing measures but addresses very specific use cases where conventional detection approaches are ineffective: APTs, which are specially designed to circumvent them, and, more broadly, horizontal movements within the IS.

For more detail on Deceptive Security solutions, read our dedicated article here.

Examples of Deceptive Security publishers:

Detecting weak signals on the network: machine learning sensors

Traditional detection sensors (IDPSs), based on traffic analysis and comparisons with known attack signatures, are not particularly effective when it comes to detecting subtle attacks (APTs, etc.) or unknown threats (0-day, etc.). To overcome this problem, new-generation IDPSs integrate Machine Learning capabilities (sometimes presented as Artificial Intelligence) into their detection arsenals.

Depending on the solution, two types of use for Machine Learning can be distinguished. On the one hand, the use of these algorithms in supervised mode to learn to recognize the behavior of certain attacks, or phases of attack (during the active phases): command and control, scans, lateral movements, data leakage, etc.

On the other, once the sensor has been deployed, adjustment of the detection thresholds to the client context is also based on Machine Learning algorithms (something already used by many traditional IDPS solutions).

This mode of operation enables rapid deployment (solutions that can be used out-of-the-box with shorter learning phases), and a better ability to detect previously characterized attacks. Conversely, the detection of attacks that have not been subject to learning, or are completely unknown, remains difficult.

In contrast to this approach, some solutions rely on unsupervised learning to detect attacks. Here, during deployment, sensors are positioned on the network to observe the traffic and learn how to recognize what constitutes legitimate traffic.

Once the learning phase is over, the sensors can detect anomalies and raise alerts when suspicious behavior occurs. This approach enables the detection of unknown attacks, but generally requires a longer learning phase if it is to be effective and achieve an acceptable false alert rate.

In both cases, the “Machine Learning“ sensors make it possible to enhance an SOC’s arsenal (which, today, is mostly aimed at detecting known attacks) through detection capabilities that can discern complex, unknown attacks, or those designed to circumvent conventional security approaches.

Initial feedback from the field shows that these technologies can indeed detect threats that bypass conventional security measures. False positives, however, are very common (the learning curve varies widely, depending on solutions and contexts), and it remains difficult to judge how comprehensively threats are being detected.

“Machine Learning” sensors therefore have a definite future among SOC tools, even if they need to further mature to reach their full potential.

Examples of Machine Learning sensor publishers:

You can find our third, and final, article in this series here.

Cet article SOAR, UEBA, CASB, EDR and others: which tools do you need for you SOC? (2/3) est apparu en premier sur RiskInsight.

Aux origines : les Honeypots

Le principe de Deceptive Security est basé sur l’utilisation de Security Decoys (ou « leurres » en français), inspirés des Honeypots (pots de miel). Le principe est simple : des leurres sont répartis aux points stratégiques du SI et toute activité y est tracée. Ces leurres n’ayant d’autres utilités que d’appâter de potentiels attaquants, toute communication avec l’un d’entre eux est nécessairement suspecte. Leur analyse permet donc de détecter et d’étudier de potentielles menaces.

Aujourd’hui, les Honeypots demeurent peu répandus, les principaux cas d’usage restant cantonnés à des cas de recherche ou de récupération d’informations (notamment de Threat Intel). Ainsi, des « pots de miel » sont exposés publiquement afin d’observer le trafic reçu sur Internet, et d’en extraire des informations : observation de nouvelles menaces (ransomware, chevaux de Troie…), identification d’IP suspectes ou compromises (SPAM, botnet…) … On peut cependant noter le regain d’intérêt pour les honeypots suite à l’attaque WannaCry, pendant laquelle nombre d’entre eux ont été utilisés pour récupérer et analyser le ransomware.

Dans les SI des entreprises, leur utilisation est encore plus marginale, et – en plus des cas cités précédemment – majoritairement limitée à des besoins bien spécifiques de gestion de crise ou de réponse à incident. Dans ces cas, les Honeypots sont utilisés pour contenir la menace dans un périmètre défini (afin de protéger les ressources critiques), étudier son comportement et en déduire son objectif.

Ainsi, aujourd’hui, les Honeypots sont principalement utilisés dans des buts d’observation et de compréhension de la menace.

Les difficultés que les Honeypots rencontrent pour se démocratiser reposent principalement sur deux limites : ceux-ci sont généralement trop facilement détectés par les attaquants, et le passage à l’échelle d’un SI relève de l’impossible, notamment par manque d’industrialisation des solutions.

Suivre le rythme : wider, faster, stealthier

Le principe de Deceptive Security vise justement à adresser ces deux problématiques, et repose sur la capacité à déployer des leurres de manière industrielle et sur des périmètres étendus. Le déploiement de ces honeypots peut être réalisé de deux façons : par le déploiement d’environnements leurres dédiés, ou par l’ajout de leurres (agents…) installés sur des environnements existants (serveurs de production, de transfert de fichier…). La stratégie de certaines solutions de Deceptive Security repose sur le déploiement de leurres à une échelle telle que ceux-ci créent un « second SI » dans le SI (ou une partie de celui-ci), similaire à une toile d’araignée dans laquelle l’attaquant vient s’emmêler.

Même si cette industrialisation représente un progrès majeur en soi, ce qui justifie la création d’une nouvelle catégorie d’outils (plutôt que de parler de simple évolution), c’est surtout la capacité à mieux dissimuler les leurres. Terminés les serveurs vulnérables avec des mots de passe par défaut : le piège est évident, l’attaquant n’y croit plus. Aujourd’hui, les solutions de Deceptive Security les plus avancées racontent une histoire à l’attaquant afin de le guider peu à peu vers leurs pièges.

La recette : remonter les miettes jusqu’au pot de miel

Pour cela, des informations (généralement appelées “miettes”) sont disséminées sur les environnements existants : serveurs de productions, AD… Bien entendu, l’industrialisation du déploiement de ces miettes est lui aussi un des enjeux principaux mis en avant par les solutions les plus avancées. Une miette représente un brin d’information : la mention d’un serveur hébergeant un middleware obsolète, des identifiants de connexion à un serveur, l’existence d’un compte possédant des droits d’administration…

Selon les solutions, ces miettes peuvent poursuivre deux buts distincts. Elles peuvent être utilisées comme un mécanisme de protection, en guidant les attaquants vers de fausses pistes, ralentissant leur progression et les encourageant à jeter l’éponge et à changer de cible.

Mais surtout, elles peuvent aussi permettre la détection des attaquants. Dans ce cas, chacune des miettes représente un indice, que les attaquants peuvent récolter en explorant les différentes ressources du réseau. Une fois récoltés, interprétés et corrélés, ces indices guident petit à petit les attaquants vers des leurres. Et c’est ici qu’est le réel enjeu, et la rupture par rapport au positionnement classique, de la Deceptive Security : comment créer des scénarios plausibles -et variés- pour piéger les attaquants ?

Ainsi, là où les Honeypots se contentent de circonscrire l’attaquant dans un périmètre défini afin de comprendre le fonctionnement et l’objectif de l’attaque, les Security Decoys visent à être déployés sur un maximum de ressources, afin d’augmenter les chances de détection, et doivent donc savoir rester discrets.

Une fois le contact avec le leurre établi, l’attaquant est repéré. Son comportement peut être alors étudié ou son accès bloqué. Dans les cas les plus poussés, de fausses informations peuvent aussi être mises à disposition pour exfiltration, permettant de faire croire à l’attaquant que sa tentative est réussie, ou de le déstabiliser lui ou son employeur : faux secrets de fabrication ou projets de brevets, fausses stratégies de rachat…

Une nouvelle approche aux nombreux avantages

Au vu de son fonctionnement, la Deceptive Security présente certains avantages par rapport aux solutions existantes.

• La transparence pour les utilisateurs et les applications : la mise en place de leurres n’ajoute aucune contrainte aux équipes IT et utilisateurs finaux : pas d’ouverture de flux, de blocage de communication ou de fichiers légitimes… ;
• Un faible taux de fausses alertes: un leurre n’étant pas supposé être utilisé de manière légitime, tout contact a de forte chance d’être lié à une menace ;
• L’absence de connaissance des attaques pour être efficace : la protection apportée par la Deceptive Security n’est pas basée sur une connaissance préalable de la menace à détecter ou bloquer (pas de signatures…). Elle est donc à même de détecter certaines menaces inconnues (0-days sur des dispositifs de sécurité ou des middlewares…) et ne nécessite pas de mise à jour continue pour être efficace. Cependant, pour détecter de cas spécifiques – sur un type d’attaque ou une ressource ciblée par exemple -, une bonne connaissance des vecteurs d’attaques reste une nécessité pour la création de miettes convaincantes et pertinentes pour le scénario souhaité ;
• L’absence de phase d’apprentissage : la détection ou le blocage d’une menace ne repose pas non plus sur l’apprentissage du réseau (seuils, patterns…), même si une connaissance de celui-ci reste nécessaire. L’outil est donc opérationnel dès son déploiement, et n’est pas vulnérable pendant cette phase de définition de la « normalité » du réseau. Ainsi, la Deceptive Security évite les principaux inconvénients des approches par signature et par apprentissage ;
• L’absence de besoin de corrélation avec d’autres ressources: même si la corrélation avec d’autres ressources reste un plus, une simple connexion sur un leurre suffit à lever une alerte nécessitant d’étudier le cas plus en détail ;
• La possibilité de couvrir des périmètres généralement difficiles à protéger: des leurres peuvent être déployés sur de nombreux périmètres (IoT, legacy…) avec une complexité limitée, et donc apporter une nouvelle protection à ces ressources souvent non-couvertes par les dispositifs classiques.

Des cas d’usage bien spécifiques

Si la Deceptive Security permet de détecter certaines attaques classiques (malwares, scans…), le réel intérêt de ce type de solution n’est pas là, ces menaces pouvant être adressées plus efficacement par les dispositifs existants (antivirus…).

Le meilleur cas d’usage de la Deceptive Security est la détection des tentatives d’explorations fines et d’installation au sein du réseau, permettant ainsi -quand le niveau de sophistication des miettes est suffisamment important- de détecter certaines APT. Plus généralement, ce type de solution permet de détecter les mouvements latéraux au sein du réseau, et ce même avec un niveau limité de personnalisation des miettes.

Ce type de dispositif n’est donc pas destiné à remplacer les mesures existantes, mais peut agir comme complément, dans le but de détecter ces types de menaces échappant communément aux dispositifs classiques.

Et pour la suite ?

Concernant l’évolution de ces solutions, certains travaux cherchent à appliquer ce principe (déguiser les leurres en environnements de production) … mais dans l’autre sens ! En faisant passer les environnements de production pour des leurres, cette démarche à contrepied permettrait d’éviter à ces ressources d’être ciblées par les attaquants !

Les éditeurs

Une liste -non exhaustive- d’éditeurs de solution de Deceptive Security est renseignée à titre indicatif ci-dessous.

Cet article Deceptive Security : comment arroser l’arroseur ? est apparu en premier sur RiskInsight.