In 2026, Active Directory remains at the heart of the now hybrid identity infrastructure of most large companies and is still widely used as an on-premises identity provider, even when organisations migrate to the cloud. 

Wavestone incident response teams note that 38% of attacks begin with identity compromise (vs. 20% in 2024). More broadly, attackers frequently exploit on-premises identities to move laterally into cloud environments (Microsoft Digital Defence Report 2025 [1]). 

In a context where the hybridisation of identities increases an already vast attack surface, companies must be able to understand the challenges and equip themselves effectively. 

Through this new 2026 overview of Active Directory security tools, we offer you: 

1. An updated map of Active Directory security tools 
2. An overview of major market trends (consolidation, transition to platforms, cloud hybridisation) 
3. Feedback on operational implementation challenges and key success factors 

An overview of AD 2026 security tools, which has been further enhanced  

By analysing the market, we have identified four main use cases for these tools: 

1. Analysis and audit 
2. Hardening and maintaining security  
3. Detection 
4. Response and reconstruction 

A listing of publishers and tools offering features that meet one or more of these four use cases was conducted. It was designed to be as comprehensive as possible, including tools from the best-known and most widely used players on the market as well as those from lesser-known players, proprietary tools and open-source tools, tools with a wide range of features and tools offering a more limited set of features. All relevant tools were thus included in a list, with various information for each one (reputation, description of the tool and use cases covered, hosting, etc.). 

The following overview selected a number of publishers from this list, for the functional coverage they offer and their large use within organisations. 

The Microsoft Entra ID logo is added to tools that offer the possibility of integrating it into their operations in addition to on-premises AD coverage. This is a strong trend in the market. 

1. A dynamic market undergoing consolidation 

The Active Directory market has undergone several changes since 2022, with different major transactions. The aim is most often for publishers to complement their offering or to cover a new need for Active Directory security. 

Among other things, we can note : 

Acquisition of PingCastle by Netwrix [2] : PingCastle, renowned for its expertise in AD security auditing, strengthens Netwrix’s offering. This acquisition enables Netwrix to expand its portfolio with a lightweight, quick-to-deploy tool that is popular with technical teams, while reaffirming its commitment to providing a unified platform covering the entire AD security lifecycle. 

Acquisition of Attivo by SentinelOne [3] : Attivo, a specialist in identity security and lateral movement detection, strengthens SentinelOne’s offering by integrating advanced AD protection capabilities into a unified platform combining EDR, XDR and identity security. 

Acquisition of BrainWave by Radiant Logic [4] : Radiant Logic strengthens identity and governance analysis capabilities. By combining BrainWave’s detailed rights mapping with Radiant Logic’s identity federation, the offering becomes more comprehensive in addressing AD challenges. 

Integration of Stealthbits by Netwrix [5] : By merging with Stealthbits, Netwrix has integrated historical Active Directory auditing and detection components (StealthAUDIT, StealthDEFEND, etc.), strengthening its offering in the protection of identities and sensitive data and moving towards a unified platform focused on AD security. 

2. From specific tools to centralised platforms 

In 2022, our overview of Active Directory security tools mentioned “specialised tools, each addressing part of the equation.” [6]. In 2026, we are seeing the emergence of centralised platforms capable of covering several needs around Active Directory and, often, Entra ID. This dynamic is primarily driven by publishers seeking to broaden their value proposition and differentiate themselves with comprehensive platforms rather than specialised tools offering specific features. 

Some publishers build their platforms through successive acquisitions, such as Netwrix (AD auditing, data protection, vulnerability discovery, PingCastle, etc.) or SentinelOne (EDR/XDR enhanced by Attivo on identity), while others are gradually enhancing their existing offerings to provide modular suites, whether they are administration/monitoring tools such as ManageEngine ADAudit Plus or Quest Change Auditor, which add AD auditing, hardening and detection components across the entire Active Directory ecosystem. 

The promises made by publishers are clear: 

• Centralisation of data (accounts, groups, rights, security events) 
• Unified view of attack paths between AD and Entra ID 
• Simplified management for security, infrastructure and IAM teams via consolidated consoles and dashboards 

From the customer’s point of view, the benefits are obvious, but the reality may be more nuanced: 

• Consolidation can reduce the number of tools and simplify integrations, but it does not eliminate the need for AD expertise or specialised tools (e.g. for post-incident reconstruction). 
• Environments often remain multi-vendor, with a mix of global platforms (XDR, CNAPP, Identity Security) and targeted AD tools, particularly in large groups or organisations that are already heavily equipped. 

In this context, the challenge is not simply to “choose a platform”, but rather to put together a coherent whole, ensuring that: 

• The AD/Entra ID scope is well covered throughout the entire lifecycle (prevention, detection, response, reconstruction). 
• The tools can feed existing processes (SOC, crisis management, PRA, IAM). 
• Dependence on a single publisher is assessed and controlled. 

3. Cloud hybridisation 

With the rise of Entra ID and SaaS applications, identity hybridisation has become the norm: AD accounts and groups are synchronised to the cloud, and the same credentials are used to access on-premises and cloud resources. Numerous recent incidents show that attackers are exploiting these hybrid architectures to pivot between AD and Entra ID, taking advantage of poor configurations or weak alignment between the two worlds. [7] 

This translates into several concrete needs: 

• Joint supervision of AD and Entra ID: ability to correlate signals from the on-premises directory (changes, anomalies, lateral movement attempts) and the cloud (Entra ID Protection signals, connection anomalies, conditional access, etc.).  
• Security policy alignment: hardening of AD (configuration, delegation, privileged accounts) in line with conditional access policies, MFA and Zero Trust requirements.  
• Hybrid reconstruction capabilities: in the event of AD compromise, reconstruction and restoration must integrate Entra ID dependencies (synchronisation, service accounts, applications) to avoid side effects on the cloud, and vice versa. 

Publisher are gradually positioning themselves on this hybridisation. Some are expanding their AD audit engines to include Entra ID (on-premises to cloud) and offer a unified view of identity vulnerabilities: Netwrix Auditor now allows Entra ID to be monitored in parallel with Active Directory with a single view of hybrid threats. Tenable Identity Exposure extends its exposure indicators to specific Entra ID risks, and Semperis Directory Services Protector correlates AD and Entra ID changes in a single console to reduce the hybrid attack surface. 

Other tools start in the cloud (Entra ID, SaaS) and move down to on-premises AD (cloud to on-premises), using a hybrid identity threat detection and response approach: Microsoft Defender for Identity provides a consolidated inventory of AD and Entra ID identities and new detection capabilities on hybrid components (Entra Connect, AD FS, etc.), while CrowdStrike Falcon Identity Threat Protection analyses hybrid accounts present in both AD and Entra ID/Azure AD. 

Operational implementation still has room for improvement 

The Active Directory security market is seeing growing and structured adoption of sophisticated tools. In many organisations, functional coverage is now adequate, or even advanced, across the various aspects of AD security (auditing, hardening, detection, backup). 

However, technological maturity contrasts with operational implementation that is still incomplete. AD disaster recovery plans (DRPs) often remain theoretical, untested, or disconnected from the backup and reconstruction tools deployed. Regular reviews (of privileges, delegations, approval relationships) are still rarely industrialised: they often depend on a few experts, with a limited level of automation. 

The effectiveness of implementation is also impacted by the constant evolution of the ecosystem, between the platformisation of tools and the hybridisation of identities. The challenge for the coming years will therefore be to align tools (both existing and future) with robust, documented and tested processes: 

1. Clarify responsibilities between infrastructure, IAM, security and SOC teams, 
2. Formalise and automate recurring controls (rights reviews, configuration validation, restoration tests). 

Only then will investments in Active Directory security tools, both on-premises and in the cloud, enable true resilience to be achieved. 

Methodology overview 

We have identified four main categories for grouping tools: 

Analysis and audit: 

• Account and Privilege: Inventory of accounts, groups and associated rights to detect excessive or non-compliant privileges. 
• AD Discovery: Exploration of the AD structure (OUs, GPOs, objects) to deduce the architecture, relationships and dependencies. 
• Vulnerability Discovery: Identification of security vulnerabilities (configuration, obsolete accounts, weak passwords, etc.). 
• Attack Path Discovery: Modelling potential attack paths to privileged accounts. 

Hardening and management: 

• Password Management: Management of password policies, synchronisation, password auditing (strength, reuse, compromise, etc.). 
• Rights & Privilege Management: Delegation, access control, role and permission management. 
• GPOs Management: Creation, analysis, modification of group policy objects. 
• Change Management: Change tracking, traceability, change management and migration tools. 

Monitoring: 

• Threat Detection: Proactive detection of suspicious behaviour, privilege escalation, lateral movement. 
• Security Incident Detection: Identification of security incidents, real-time alerts, event correlation. 
• Backup and Recovery: 
• AD Backup & Recovery: Partial or complete backup of AD objects, rapid disaster recovery. 
• Investigation & Forensics: Post-incident analysis, traceability of malicious actions, evidence collection. 

For each of the tools classified, a badge (Microsoft Entra ID logo) is added when the tool offers the possibility of integrating Microsoft Entra ID into its operation. 

Conclusion

The 2026 overview is based on an analysis of 180 tools, compared to 150 in 2022. It was constructed using a similar approach to that of 2002. It is based on a listing of tools on the market. On this basis, and in line with recurring themes in Active Directory security, a categorisation has been established to facilitate reading. 

The list of tools mentioned is not intended to be exhaustive, as the list of tools that can contribute directly or indirectly to Active Directory security is vast. This overview is therefore a summary of the main existing tools, particularly those that Wavestone consultants encounter most often in large organisations (considered, studied, tested or deployed). 

References

[1] Microsoft Digital Defense Report 2025 | Microsoft 

[2] Netwrix Acquires PingCastle | Netwrix 

[3] SentinelOne, Inc. – SentinelOne Completes Acquisition of Attivo Networks 

[4] Radiant Logic Signs Definitive Agreement to Acquire Brainwave GRC – Radiant Logic | Unify, Observe, and Act on ALL Identity Data 

[5] Netwrix annonce sa fusion avec Stealthbits | Netwrix 

[6] Radar des outils pour renforcer la sécurité d’Active Directory – RiskInsight 

[7] Microsoft Incident Response lessons on preventing cloud identity compromise | Microsoft Security Blog 

Cet article Overview of Active Directory security tools – version 2026  est apparu en premier sur RiskInsight.

Your company is currently dealing with a major ransomware crisis. Given its central role in managing access, authentication, and network resources within any organisation, cybercriminals have compromised the Active Directory in 100% of these crises.  

Your systems are now encrypted if the attackers have activated the malicious payload. They might otherwise be isolated and unavailable. In either case, your company no longer has the necessary resources to function properly, and your activity has either ceased or has been significantly slowed! 

In this case, trust in your information system has been broken. Your teams begin to feel business pressure, and one question persists: when will we be able to reopen our services? Your goal then becomes clear: you must restore Active Directory with a high enough level of trust to reopen services as soon as possible. 

Rebuilding an Active Directory is a difficult step in crisis management. If poorly executed, your organisation exposes itself to two major risks: exacerbating the operational impacts for the business or introducing a new threat to your environment.

The ANSSI has recently published three very comprehensive guides on this subject [1], which we recommend you read. 

In this article, we will go over some of the items that stood out to us during crisis management. Our teams were able to overcome numerous obstacles during their interventions. What are the main issues that have arisen? How can they be fixed?

From compromise to reopening: advice to overcome obstacles

Start remediation efficiently with a proven organization

Time lost due to poor crisis organisation can exacerbate the consequences of an Active Directory compromise. Teams are frequently unsure of what to do, who to involve, and what goals to pursue. A delayed response will increase remediation costs, revenue losses, and have an impact on the company’s reputation.

Before the crisis…
It is necessary to identify all the key players to involve in the reconstruction of the Active Directory:

The executive committee will resolve fundamental issues. For example, do we prioritise reopening critical services quickly for business reasons or slowly and securely? There are several possible postures, each with advantages and disadvantages [1 – Strategic Dimension]. The entire remediation plan is based on this decision, so the executive committee must make a decision to begin work immediately.  

Business teams will identify and prioritise the most critical services for restoration. The Active Directory compromise affects the majority of the company’s services, and your teams will be unable to handle all requests at once. 

Intervention teams (technical and security) will be formed to define and implement the remediation strategy. Because of the expertise and human efforts required to rebuild an Active Directory, temporary reinforcement of your teams is required to handle the remediation: mastering configuration review tools (PingCastle, Purple Knight, etc.), prioritising detected vulnerabilities, deployment and control of measures, and so on. 

It is critical to define processes and reflex cards in order to optimise each actor’s reaction time. Simulations and regular exercises should be organised in addition to their writing to train your teams to react effectively. 

During the crisis… 

Rapidly implement a project monitoring system that includes regular reports, action tracking, and coordination among the various teams involved. Too often, a lack of communication and information leads to a slowdown in remediation. It is not uncommon for administrators to take initiatives without taking the time to communicate them, such as opening more network ports than necessary, parallelizing two tasks from the remediation plan, and so on. These well-intended initiatives can have a significant impact on remediation, ranging from complicating the work to a distorted view of the true security level following the security work, and thus an increased risk of new lightning compromise. 

Ensure the resilience of backups by defining a robust strategy   

When dealing with an Active Directory compromise, the unavailability of backups (corrupted or compromised) is a major challenge. Attackers frequently target and disable backups or disrupt backup servers. This complicates and lengthens Active Directory restoration and recovery. 

Before the crisis…

Create a resilient backup strategy that takes best practices and recommendations into account (backup on disconnected media, immutable or in the cloud) [2]. There is currently a significant gap between state-of-the-art and implemented backup strategies (for example, Active Directory authentication of backup infrastructures, unsecured domain controller backups, and so on). 

During the crisis… 

Consider performing Active Directory remediation from a compromised domain controller. This “double bascule” method can assist in recovering and securing critical data in order to restore the Active Directory service without the use of a backup. When backups are unavailable and the strategy does not include rebuilding Active Directory from scratch, this scenario is selected. 

Anticipate technical problems such as DNS Active Directory configuration by maintaining your environment 

The vast majority of Active Directory environments have accumulated technical debt over time (complex network architecture, roles such as DHCP carried out by domain controllers rather than dedicated servers, and so on). Furthermore, Active Directory environments are now synchronised with Azure Active Directory, establishing new technological dependencies that may complicate remediation in the event of an Active Directory compromise (Active Directory/Azure Active Directory synchronisation). These two elements can cause an array of technical issues on the day of the crisis (loss of synchronisation with Azure Active Directory, unavailability of the DHCP service carried by a domain controller that must be turned off, and so on).

Before the crisis… 

Maintain Active Directory technical documentation and inventories (infrastructure, Azure Active Directory synchronisation, etc.). It often proves too difficult to obtain a clear view of the environment and the perimeter to be remediated. Up-to-date inventories will significantly improve remediation work and ensure the establishment of a consistent remediation plan. Additionally, this will allow you to identify and correct bad practises that could cause major issues on the day of the crisis (DNS service configuration, DHCP, and so on). 

During the crisis… 

After 30 days of desynchronization with the Active Directory, Azure Active Directory services may become unavailable, resulting in a ticking time bomb. Make sure to assess the consequences of losing Azure Active Directory services and avoid relying on them to handle critical tasks (email communication, for example).  

The crisis will highlight numerous technical flaws (Active Directory configuration report via audit tools, network issues, and so on). Make sure to only deal with problems that are related to the remediation plan’s objectives (see Advice No. 5 – Set a course and stick to it during remediation!). 

Optimize the reinitialization of secrets through processes adapted to your context 

Active Directory compromise results in a loss of trust in all of its secrets. As such, a reset of these is required to achieve the level of security required to reopen services while avoiding another quick compromise. Resetting a large number of user passwords and service accounts can have significant operational consequences in large environments with several thousand users and more than a hundred applications. To provide the new password for service accounts, you must first understand how the application uses the account. For users, you must devise a secure method of distributing new passwords on a large scale. 

Before the crisis… 

It is critical to have a clear understanding of the process of assigning new passwords to users. Several methods are available, depending on the environment studied, such as summoning users with the presentation of an identity card, transmitting the new username/password via physical mail, email, SMS, and so on. Regardless of the method chosen, the user must be required to reset his password on the next connection. Users may also be able to reset their own passwords using solutions that rely on two-factor authentication, for example. 

To carry out service account work, it is essential to create an inventory by identifying the associated applications and password reset methods for each of them. Obtaining this inventory by remediation teams is frequently complicated (unavailable, not maintained, etc.) and thus necessitates devoting significant time to tasks that can be completed outside of the crisis. Aside from remediation work, this exercise will help you manage your service accounts on a daily basis. One of the best practices is to change the passwords on these accounts on a regular basis. 

During the crisis… 

Once the passwords have been reset, it is necessary to ensure that the security measure has been implemented throughout the environment. This is easily accomplished with a PowerShell script, and it ensures that the attacker no longer has a valid account to exploit. 

Set a course and stick to it during the remediation! 

During an Active Directory reconstruction, it is frequently difficult to strike the right balance between exposing oneself to risks by reopening too quickly and incurring significant financial losses by reopening too slowly. Take care not to fall into the common pitfalls of managing a ransomware crisis.[3] 

Before the crisis… 

It is necessary to consider the various remediation postures: quickly restoring vital services, regaining control of the information system, or seizing the opportunity to prepare for long-term control of the information system. [1] 

Beyond defining the posture, ensure that you understand your Active Directory trust core, which is made up of the most critical assets (Tier 0). The remediation actions begin with these components (domain controllers, for example) in order to restore Active Directory’s vital services and to ensure a level of security that does not allow the attacker to compromise the entire environment again. 

During the crisis… 
Make sure that your teams stay on track. As the remediation plan is carried out, new issues will emerge (unavailability of the domain controller carrying one of the required FSMO roles for remediation, network problems, and so on). It will be necessary to question the short-term relevance of its remediation in relation to the set objectives (the answer being dependent on the executive committee’s posture: quick reopening or slower and more secure).  

Consider the opportunities presented by the crisis. For example, if the DHCP service was managed by a domain controller, take advantage of the opportunity to set up a dedicated DHCP server, thereby decoupling the service from the domain controller. 

Our lessons  

The improvement of the reconstruction process before the compromise of Active Directory ultimately rests on three main axes: 

1. The drafting of functional processes and reflex cards to be able to: 
   1. Mobilize the right people in a timely manner. 
   2. Focus on the main objectives. 
   3. The maintenance of the Active Directory environment, which requires: 
2. Defining and maintaining an architecture in accordance with best practices. 
   1. Having up-to-date inventories. 
   2. Ensuring the resilience of backups. 
3. The performance of tests to: 
   1. Validate the applicability of theoretical processes in real conditions. 
   2. Improve the reactivity and efficiency of your teams in a crisis situation.

[1] https://www.ssi.gouv.fr/actualite/lanssi-publie-pour-appel-a-commentaires-un-corpus-documentaire-sur-la-remediation/

[2] https://www.riskinsight-wavestone.com/en/2023/02/approaches-to-quick-active-directory-recovery/

[3] https://www.riskinsight-wavestone.com/en/2023/01/successful-ransomware-crisis-management-top-10-pitfalls-to-avoid/

Cet article Surviving an Active Directory compromise: Key lessons to improve the reconstruction Process  est apparu en premier sur RiskInsight.

If 10 years ago, building your SOC meant asking yourself which scenarios to monitor, which log sources to collect and which SIEM to choose, recent developments in the IS have brought new challenges: how to set up monitoring in a partially on-premise and/or multi-cloud environment? Indeed, in 2021, having an IS hosted by several IaaS providers is closer to being the rule than the exception; and while AWS remains the most popular player, Azure and GCP offerings are of increasing interest to IT teams.

How to build a detection strategy? Where to position the SIEM? How to centralize logs and alerts? In fact, do we need logs or alerts? And how to take advantage of the managed solutions offered by cloud providers?

In this article, we will discuss best practices: using a bottom-up detection strategy, optimizing via the choice of the most relevant cloud native services, simplifying the collection architecture; always based on feedback from building multi-cloud monitoring strategies.

(Re)thinking your detection strategy for the multicloud

The first question the SOC team should ask itself is the detection strategy. In other words, what scenarios will be monitored?

A good cyber reflex is to use a “top-down” approach: start with a risk analysis to identify the alerts to prioritize, formalize them and then translate them technically into the SIEM. In practice, three factors demonstrate that this approach is insufficient:

• Few teams have risk analyses that are sufficiently exhaustive, up to date and pragmatic to allow the breakdown of threat scenarios into monitorable scenarios, especially for complex scopes such as the public cloud;
• There is no guarantee that the scenarios obtained by this method can actually be put under supervision, whether the limitations are related to the solutions deployed or to the need for SOC teams to have business knowledge.
• This approach defines some attack paths according to the criticality of the assets but does not cover all the attack paths that an attacker could take.

Therefore, an efficient multi-cloud detection strategy will be obtained by completing the risk-based approach with a “bottom-up” approach: starting from the logging capabilities of the solutions available to identify the alerts that the SIEM will have to raise, and finally prioritize based on their interest in terms of risk coverage. Starting with the existing solutions guarantees the pragmatism and efficiency of the approach.

At Wavestone, we are increasingly solicited by clients who want to be supported in this new approach. The scope concerns the main solutions used in multicloud: Microsoft 365 (SaaS) and the managed solutions of the IaaS offers of the 3 main market players: Amazon Web Services, Microsoft Azure and Google Cloud Platform.

Set up the supervision of the Microsoft 365 infrastructure

On paper, the SOC team has all the keys in hand to monitor its cloud infrastructure:

– Raw logs for Office 365 services (Teams, SharePoint Online, Exchange Online, etc.)

– Raw logs, security reports, alerts and Identity Secure Score for Azure AD

– Raw logs, alerts, Microsoft Secure Score and Azure recommendations for security tools like ATP, AAD Identity Protection, Intune, AIP, etc.

In practice, navigating between the logs and all the tools available (and their consoles) can quickly become a headache. And if we regularly hear that there are too many logs or administration interfaces to master, in the field the difficulties are accentuated:

– By the poor customization capabilities of the native tools offered,

– By the lack of scenarios available with the purchased license,

– By the 90-day retention period for logs,

– By the general lack of Office 365 or AzureAD skills in the SOC teams.

To avoid getting lost, we recommend simplifying the playing field as much as possible. The best practices consist in thinking about alerts, not logs collection, and then centralizing their management in the SIEM using connectors like those of Security Graph API. As an example, it is possible to arrive at a model like the one given below:

Once the architecture has been identified, configure a log retention period adapted to your needs (within Azure or outside) and start adapting the SOC processes to the specificities of M365 according to the choices made in the previous step.

Set up the supervision of other clouds in IaaS

To draw the architecture of collection on these clouds, it is necessary to distinguish the different types of logs made available by the CSPs.

System logs

The case of system logs generated by VMs and network flows can be dealt with first; it is possible to collect them in the same way as on-premise, with syslog agents, for example. CSP infrastructures provide building blocks such as Log Analytics in Azure to facilitate reporting.

Infrastructure administration logs

It is also possible to supervise the administration of “sensitive” infrastructure components (VPN, FW, vulnerability scanners, etc.) in the same way as on-premise solutions. Indeed, most of these solutions have their IaaS counterpart in the cloud providers: they can be obtained via the Marketplace and have a web administration console or interface directly with the CSP’s management console (this is the case for the Qualys scanner appliance, for example).

API call logs

Finally, API calls made by processes/accounts on the cloud infrastructure and by administration operations generate logs that are easily retrievable via the following managed services:

– CloudTrail at AWS

– Activity Log & Monitor at Azure

– Audit Logging at GCP

To avoid getting lost, let’s learn the lesson: “Use and abuse cloud-native services”. After all, who better than the provider to offer services that are adapted and integrated into the environment? In practice, we see that implementing log management and cloud alerts in an on-premise SIEM is expensive (even if we try to limit storage costs in the monitoring solution) and time-consuming.

The use of the cloud implies a shift to the cloud philosophy: let’s adopt its codes and tame its services and tools. This is an opportunity to strengthen the synergies between the cloud teams and the SOC!

In summary, an example of monitoring architecture on AWS is proposed below. It shows several ways to perform monitoring, using native services for logs and alerts (NB: all flows to S3 and other services have not been shown for readability reasons).

Define the architecture for centralizing multi-cloud alerts

This is one of the questions we are asked the most: what SIEM architecture should be considered in the multi-cloud? While each context is different, because each IT infrastructure has its own legacy and history, the presence of so many resources and tools should lead an SOC team to consider adopting a central cloud SIEM (such as Azure Sentinel, Splunk SaaS, etc.; AWS and Google’s Chronicle do not offer an equivalent solution to date).

To help SOC teams choose the right scenario, our recommendations are as follows:

– Prefer the scenario with a single central SIEM

– Limit the number of cloud monitoring consoles as much as possible

– Maximize the number of alerts that have already been analyzed by the native services studied above

– Take advantage of possible synergies between products from the same supplier: Azure Sentinel for monitoring Microsoft 365 infrastructure, for example

– Take advantage of the numerous connectors made available by cloud SIEM providers

– Study the impact of each scenario on the organization of the SOC (team size, technological skills, etc.) and the associated costs (necessary developments, volume and ingestion costs, etc.)

An example of an architecture that includes all the recommendations of this article is proposed below, it uses Azure Sentinel as a central cloud SIEM.

Summary: Key principles to keep your head above the clouds

In summary, the SOC team wanting to adapt its detection strategy to the multicloud should:

– Complement its classic top-down approach with the bottom-up approach, which is particularly well-suited to the complex context of the multicloud,

– Use native services provided by vendors whenever possible to take full advantage of the cloud,

– Simplify the collection architecture and centralize as much as possible the alerts pre-analyzed by the cloud native services,

Once the head is out of the cloud, the strategy formalized and the collection architecture deployed, the SOC is back in its place as the IS control tower: the proliferation of services in the cloud no longer scares it!

The next steps may be to look at automation possibilities, with the implementation of a SOAR, for example. We will be sure to discuss this topic in a future article.

Cet article Adapting your detection strategy to the multi-cloud without getting lost in the cloud est apparu en premier sur RiskInsight.

Fifteen years ago, when we first started working on SOC implementations for our clients, defining a roadmap was simple: set up a tool, then collect and analyze the logs of security equipment and critical/exposed assets.

However, new challenges linked to the IS decentralization, the evolution of an ever-evolving threat and the crisis we are going through (teleworking, reduction in cybersecurity budgets…) must make us realize that the SOC must reinvent itself.

Involve (really) everyone!

By rewriting the story from the beginning, the SOC is managed by the cybersecurity population, which has therefore set up monitoring mechanisms on cybersecurity equipment with cybersecurity use-cases. The result is mixed, it works quite well, and the figures from our CERT benchmark are there to prove it: 167 days on average to detect an incident!

The first detection strategies were obviously defined, challenged and validated by the cybersecurity industry. Their objective was to increasingly extend the surveillance perimeter by collecting more and more logs (firewalls, WAF, …) and setting up new surveillance equipment (SIEM, probes, …).

This first observation was inevitably found in the majority of our SOC audit conclusions: objectives are poorly defined and not aligned with the expectations of SOC clients (CISOs, CIOs, business functions), leading to a loss of trust and credibility.

Striking examples can explain this feeling: lack of SLAs, poorly defined perimeter, too raw reporting that is too raw, non-contextualized and containing erroneous information.

If you do not want to redefine your SOC strategy once again in a one-sided way, organizing a seminar is the right exercise to establish a new starting point. All the stakeholders must be present (cybersecurity teams, CIOs, SOC clients, …) and the goal is to address the main issues:

• Redefining objectives: concentrating surveillance on much smaller perimeters that are both technically and humanly feasible
• Clarifying governance: redefining the positioning and role of the SOC in the organization
• Redesigning reporting: sharing customer misunderstandings in order to provide the right level of information.

We have seen that this step, which is essential to the renewal of the SOC, enables an entire ecosystem to be federated around a common target.

Give priority to quality over quantity!

Paradoxically, although the attack area of the IS has significantly increased, the priority is indeed to restrict the surveillance scope to focus on what is really valued.

Firstly, once the functional perimeter of surveillance has been redefined and validated by all, the SOC mission is to technically translate these new objectives into detection scenarios in the tools. There is no need to reinvent the wheel, because new frameworks such as MITRE ATT&CK now allow the different types of attacks to be clearly identified and materialized (techniques used, examples/references and suggestions for detection). The objective is obviously not to be able to cover all the techniques that can be used (330 in total) but to prioritize the efforts on what will allow the objectives to be achieved.

In addition, an HR observation was also raised in most of our audits: teams lack motivation, experience and autonomy to bring added value to operations.

This leads to a high turnover because some tasks are considered uninteresting. The objective is to concentrate human effort on what really brings added value. We have assisted many customers in the implementation of SOAR (Security Orchestration, Automation and Response) tools to automate repetitive tasks of the teams in charge of analysis and reaction. These tools are extremely effective in automating the processing of common, very annoying attacks (ransomware, phishing…) which account for a large proportion of alerts.

Once these measures are in place, the teams can then be mobilized on activities with higher added value such as the implementation of automation tasks or Threat Hunting activities.

And now, improve and challenge each other continuously!

Once all the foundations are in place to breathe new life into your SOC, how do you stay up to date?

The answer to this question would have been complex 5 years ago, but many recognized standards now allow us to assess the maturity of the SOC in a continuous improvement process. SOC CMM is the perfect example, as this framework enables self-assessment based on a set of precise questions addressing all the issues in terms of tools and organization. This methodology has enabled us to support customers on many before/after comparisons.

Red Team or Purple Team operations are also excellent ways to challenge the systems put in place in relation to the defined objectives. These exercises highlight concrete examples of vulnerabilities as well as precise recommendations to remedy them. In addition, the MITRE ATT&CK Framework can be used to consolidate the tests carried out by type of attack, as well as their results.

These various initiatives do not provide an exhaustive overview of the problems that SOC are currently facing, but they do highlight our main findings: an isolated SOC, poorly configured tools and demobilized teams.

The exercise of redefining a SOC strategy is a great opportunity to re-mobilize an entire ecosystem under the same banner. This initiative helps to give new meaning to both operational teams and all the stakeholders in the SOC activity. So… let’s do it!

Cet article The SOC died of boredom, fatigue and poor positioning? Find out how to resuscitate it! est apparu en premier sur RiskInsight.

However, they are also facing increasingly stringent measures under new regulations such as the General Data Protection Regulation (GDPR), which covers all personal data, or the various new regulations on the protection of critical national infrastructures. France is in the vanguard of this activity with its Military Programming Act which applies to the organizations classed as “most critical” in terms of the country’s functioning.

But how can you put in place increasingly sophisticated detection systems, while, at the same time, complying with an ever-stricter regulatory framework?

SOCs ARE BEING STANDARDIZED AT THE EUROPEAN LEVEL—AND GLOBALLY

In the mid-2000s, the implementation of the first SOCs consisted, for the most part, of deploying log collectors based on geographical hubs and the setting up of a central alert management system. However, recent regulatory changes may require modifications to architecture. In France, in particular, within the context of the Military Programming Act, the requirement to set up a “system of log correlation and analysis” (i.e. a SOC equipped by a SIEM system) has been accompanied by a strict regulatory framework, which is set out in its PDIS (Security Incident Detection Service Providers) Requirements Reference Document.

In terms of standardization, this addresses three points in particular:

• First, the framework for surveillance: there is now an obligation to detect certain types of common attacks and implement controls, following recommendations made through audits carried out by qualified bodies, in accordance with the PASSI (Cybersecurity Audit Service Providers) Reference Document. Companies must also put in place a permanent surveillance unit to notify ANSSI (the French national agency for information system security) in the event of an IS being critically compromised.
• The second area addresses the securing of the SOC’s assets: new security measures described in the PDIS Requirements Reference Document demand, in particular, more robust measures for SOC operators and administrators (two-factor authentication, limitations on internet access, etc.). These security measures will be verified by ANSSI through audits, or retrospectively, following the compromise of an IS being notified to it.

Finally—the architecture—where there’s a requirement for greater complexity: partitioning into trust zones and an enlargement to the perimeter of the monitored network are introduced (going beyond the traditional scope of equipment under security surveillance: business servers and handheld devices must also now be monitored). Information related to security incidents (events, analysis reports, and their associated notifications) must also now be retained for as long as the service is provided.

STRONG SECURITY AND CAREFUL HANDLING OF PERSONAL DATA: INCOMPATIBLE GOALS?

To carry out retrospective analyses and, in particular, to determine the origin of cyber-attacks, a good deal of personal and critical data must be collected, stored, and exploited. However, this data is covered by the GDPR, which tends to limit its collection and use.

Google’s recent fine by the AGPD (Spain’s personal data protection authority) highlights the types of issue that a SOC may encounter regarding the processing of personal data:

• Google’s obligations in the processing of personal data and the user’s right to be forgotten were the prime causes of Google’s penalty. In fact, the GDPR intends to offer European citizens the option to access, modify, or delete their data wherever it is stored (including in the cloud). This means that, in practice, companies must know exactly what data is being collected by their SOC, so that they can inform their customers, employees, etc. accordingly—and offer them the option of having it removed at any time. Having said that, the GDPR seems to indicate that preservation of some data is acceptable, where this is necessary for the protection of companies. The details of exactly how this provision will operate are expected to be worked out over the next few years.
• An obligation of transparency with respect to the exploitation of data is the second issue that the AGPD’s action raises. Yet, for PDISs, the obligation to monitor a wide range of equipment gives rise to the collection of a large and varied amount of data. The content of logs will therefore have to be addressed to ensure that only the data needed for security-monitoring activity is collected.
• Finally, the GDPR imposes a requirement to justify the preservation of the data. Yet, PDIS requirements are for data to be kept for at least six months, in order to have the ability to carry out long-term or retrospective analysis; this creates regulatory uncertainty: how far can a company go in ensuring the protection of its IS?

Looking beyond the example of Spain, it’s instructive to compare the different legislative approaches to the notification of incidents. Those dedicated to the protection of personal data target rapid notification in order to limit the impacts on people’s lives; while legislation concerning the protection of critical infrastructure requires limited and highly confidential notifications in order to allow sufficient time for incidents to be correctly managed, without revealing to an attacker the fact that they have been discovered. In the end, the GDPR took into account this type of scenario, but that’s not to say that other texts won’t result in contradictory obligations.

A STRICT—BUT BENEFICIAL—REGULATORY FRAMEWORK

The tightening of the regulatory framework for SOCs, whether direct (via PDIS requirements) or indirect (through the GDPR), will result in a transformation of the IS ecosystem. New types of profiles could thus be integrated into teams, such as the Data Privacy Officer (DPO), which the SOC could consider as a key player in maintaining its long-term compliance.

In addition, these regulations will raise maturity levels among the players who have to comply with them, as well as among those who draw inspiration from them. Already, there are numerous moves toward compliance involving SOC architecture, as well as its processes and governance.

In complying with the regulations, tools also count—and that means looking at innovations such as data-based surveillance (with Data Leakage Prevention [DLP] tools), which can help ensure compliance with respect to the protection of sensitive data.

TOWARD MORE REALISTIC REGULATIONS…

The value of the requirements for many organizations, both as standards and objectives to be met, cannot be disputed.

While the bar may seem high, and regulatory inconsistencies remain, one thing is for sure: the next round of regulatory updates will provide a solid framework for the design and improvement of SOC.

Cet article The SOC – a department undergoing a full regulatory overhaul est apparu en premier sur RiskInsight.

Un besoin de défense active …

Aujourd’hui, des attaques de plus en plus sophistiquées touchent tous les secteurs d’activité et ciblent des organisations spécifiques en utilisant des techniques toujours plus complexes. Ces attaques visent à contourner le périmètre de défense existant, mais également à persister sur le SI cible sans déclencher immédiatement l’attaque. Ainsi, l’attaquant améliore sa connaissance de la cible depuis l’intérieur pour lancer ensuite une attaque aux conséquences importantes pour les métiers (vols de données, destruction du SI, usurpation d’identité…).

L’exemple le plus marquant reste l’attaque Carbanak/Anunak, qui a visé plus d’une centaine d’établissements bancaires. Les attaquants se sont introduits discrètement dans le système via du spear phishing (mail malveillant ciblé et personnalisé) puis une série de rebonds. Ils s’y sont ensuite maintenus sur le long terme, observant patiemment les actions des opérateurs bancaires pendant plus d’un mois et demi. Les systèmes de surveillance des banques n’ont pas repéré les traces de persistance laissées par les attaquants, qui ont veillé à rester en dessous des seuils de détection. Une fois les procédures internes des banques identifiées, les attaquants ont pu détourner lentement mais sûrement plusieurs dizaines de millions de dollars.

Les stratégies traditionnelles de défense passive inspirées du modèle du château fort, c’est à dire visant à se protéger (fermeture des flux, antivirus, IPS, etc.), ne suffisent plus à elles seules, et ne sont pas adaptées pour répondre à ce type de menaces.

Il est ainsi devenu nécessaire d’accepter le caractère inévitable de l’intrusion et se préparer à y faire face. Dans cette optique, la défense active vise à détecter puis réduire l’efficacité ou supprimer une attaque.

… pour 3 niveaux d’intervention

En fonction de la portée des moyens utilisés par l’attaquant, on peut identifier plusieurs niveaux de réponse active :

1)     Répondre avec les moyens propres de l’entreprise

Les actions de réponse active visent ici à tromper l’attaquant ou encore le désinformer et collecter des informations sur ses méthodes.

Dans un premier temps, pour analyser les actions des attaquants de façon proactive on pourra utiliser des serveurs honeypot, qui simulent des serveurs d’importance accessibles afin d’y attirer les attaquants et de les surveiller, ou encore des clients honeypot, des clients volontairement vulnérables pour détecter les tentatives d’attaques telles que le waterholing ou le drivebydownload en les faisant naviguer sur les sites visités par les collaborateurs de l’entreprise.

Dans un second temps, pour duper et/ou ralentir l’attaquant on pourra renvoyer de fausses informations sur le système d’exploitation lorsque l’attaquant lance des scans, ou encore simuler de faux services (en utilisant Portspoof par exemple pour simuler des ports ouverts et des services factices capables d’interagir avec l’attaquant).

L’augmentation du temps de réponse de certains services par l’utilisation de techniques de type « tarpit » (seau de goudron) permet de gêner l’attaquant sans impacter les utilisateurs légitimes. De plus, on peut réduire la fenêtre d’attaque en restaurant régulièrement les serveurs web dans un état propre connu (SCIT server) de sorte à réduire la fenêtre de temps durant laquelle l’attaquant peut compromettre le serveur.

Dans le but d’épuiser les ressources et la motivation de l’attaquant, on pourra le tromper avec de fausses vulnérabilités sur un serveur web. Enfin, bloquer les adresses IP tentant d’appeler des ports inhabituels (Artillery) jugulera ses manœuvres d’expansion dans le réseau.

La défense active permet ainsi de comprendre les attaques, de les ralentir et d’épuiser les ressources de l’attaquant. Les informations ainsi obtenues permettent d’adapter et d’optimiser les moyens de défense traditionnels pour bloquer les attaques plus efficacement.

2)     Intervenir sur les moyens entre la cible et l’attaquant

Dans la chaîne de communication utilisée par les attaquants se trouvent un certain nombre d’acteurs : des FAI, des tiers compromis par l’attaquant, des hébergeurs, des noms de domaines malveillants, etc.

Il est possible d’intervenir sur les moyens intermédiaires utilisés par l’attaquant pour juguler l’attaque, en prenant contact avec les acteurs en charge de ces moyens. On pourra par exemple contacter les FAI en cas d’attaque DDoS, pour filtrer le trafic avant l’arrivée sur le SI de l’entreprise ou encore faire saisir les noms de domaines par décision de justice (par exemple pour démanteler un botnet).

On pourra également contacter un hébergeur pour faire fermer un site malveillant ou faire disparaitre le trafic en amont avec du DNS Sinkholing (faire pointer le trafic malveillant vers un domaine inexistant).

Ces actions permettent à la fois d’obtenir des informations de façon indirecte sur l’attaquant (compte utilisé pour acheter un nom de domaine malveillant, etc.) mais aussi de le ralentir et de le contrarier dans ses plans. De plus, elles doivent être anticipées – si possible – en créant des réseaux de contacts auprès des principaux fournisseurs ou équipes de réponse à incident, en particulier pour pouvoir agir rapidement à l’étranger.

3)     Contre-attaquer directement chez l’attaquant

Il est à noter que ce type de réponse est identifié comme illégal en France par la loi Godfrain de 1988 et plus particulièrement par les articles 323-1 et suivant du Code pénal traitant des atteintes aux systèmes de traitement automatisé de données.

Il est cependant intéressant de mentionner ces méthodes car elles peuvent être utilisées par d’autres pays où elles sont autorisées mais également par les forces de l’ordre dans un certain nombre de cas bien particuliers.

On peut distinguer deux types de réponse dans ce troisième niveau :

• les actions de réponse visant à recueillir des informations sur l’attaquant ;
• les actions de réponse visant à rendre inopérant les systèmes d’attaque directement chez le cybercriminel.

Dans le premier type de réponse on pourra mentionner l’envoi de fichiers « piégés », des fichiers balisés, capables de renvoyer un beacon dès lors que celui-ci est ouvert/copié dans un endroit inhabituel ou utiliser des failles de sécurité chez l’attaquant pour prendre le contrôle du serveur de commande et de contrôle (C&C) et identifier les données exfiltrées.

Dans le second type de réponse on peut penser à injecter du code malveillant dans un fichier exfiltré par l’attaquant et par la suite détruire logiquement ses systèmes, ou encore tenter de viser sa bande passante par un DoS ciblé. Finalement on peut envisager autant de scénarios que de canaux d’attaques.

Ces méthodes doivent être manipulées par les autorités compétentes afin de se conformer aux exigences légales.

Pour conclure, les mesures de défense active ne se résument pas uniquement à contre-attaquer directement mais bien à se doter de moyens permettant de mieux comprendre, détecter et réagir aux attaques. En complément des stratégies traditionnelles de défense, l’importance de la réponse active se révèle aujourd’hui un sujet en plein développement dans les équipes de réponse à incident les plus avancées. Le paradigme à garder en tête reste inchangé : toujours avoir un coup d’avance !

Cet article Défense active : répondre activement aux attaques cybercriminelles est apparu en premier sur RiskInsight.

Peu voire pas de surprises dans les nouvelles fonctionnalités offertes, car elles sont intimement liées à iOS 7 déjà présenté en juin dernier.

Mais cette annonce avant tout matérielle fait la part belle à la sécurité…

Des améliorations qui restent incrémentales

Apple n’a pas cédé à l’appel du low cost : l’iPhone 5C vient remplacer l’iPhone 5 tandis que l’iPhone 5S porte les innovations, et l’iPhone 4S reste au catalogue en prix d’appel.

Outre sa coque plastique, l’iPhone 5C reprend en effet la majorité des caractéristiques de l’iPhone 5. Il élargit cependant sa compatibilité 4G en supportant les gammes de fréquences utilisées par les opérateurs français.

Les nouveautés sont à chercher sur l’iPhone 5S, avec 3 points mis en avant par Apple.

En premier lieu, une amélioration des performances de l’appareil, à laquelle Apple nous a habitués à chaque nouvelle version. Le nouveau processeur A7 est en 64 bits, une première dans un smartphone.

Celui ci se voit par ailleurs assisté d’un contrôleur de mouvement dédié, dont le stockage des données et les possibilités de désactivation sont à suivre du point de vue de la protection des données personnelles.

Deuxième domaine touché par l’amélioration incrémentale : l’appareil photo et ses optiques.

Et si Apple mettait la sécurité à la mode ?

La véritable nouveauté réside dans le troisième point mis en avant : un bouton d’accueil faisant office de lecteur d’empreintes digitales, appelé TouchID.

Apple prétend répondre avec ce dispositif à l’absence de mot de passe sur une grande partie des iPhone. Ce point est moins critique pour les flottes d’entreprises disposant de MDM à même d’imposer des contraintes de robustesse sur le code ou mot de passe de verrouillage. Reste que la fonctionnalité permettra de faciliter grandement la vie des utilisateurs, et par là même de faciliter leur consommation sur différents Stores ou magasins en ligne, l’empreinte digitale valant acceptation de paiement.

Pour les entreprises, si l’on rapproche cette annonce de la fonctionnalité de SSO d’Entreprise annoncée pour iOS 7, et s’il est possible forcer l’utilisation de TouchID par MDM, l’iPhone pourrait constituer une solution robuste d’accès au SI. Il reste néanmoins à éprouver la fiabilité du lecteur en terme de faux positifs et de facilité d’enrolement.

Selon Apple la confidentialité est garantie car toute la reconnaissance d’empreinte s’effectue hors ligne sur l’iPhone, et aucune donnée d’authentification n’est envoyée vers le Cloud. Ces données seraient stockées dans une partie dédiée du processeur A7, sorte de TPM intégré au SoC.

Si TouchID tient ses promesses en termes de fiabilité et d’ergonomie, il pourrait constituer un nouveau standard et embrasser de multiples usages : signature électronique, paiement mobile, signature à valeur probante. Apple attendra probablement à son habitude de valider l’adoption par les utilisateurs avant de donner les clefs de TouchID aux développeurs pour en étendre les usages.

Cet article Et si Apple mettait la sécurité entre toutes les mains avec l’iPone 5S ? est apparu en premier sur RiskInsight.

Chercher dans la bonne direction

À quoi peut servir une campagne ? Deux objectifs se dégagent principalement des campagnes que nous avons réalisées : soit mesurer le niveau de sécurité sur un échantillon de thèmes et cibles techniques, à consolider ensuite en risques à destination des métiers, soit à l’inverse évaluer à partir des processus métier les vulnérabilités techniques pouvant porter atteinte à leurs enjeux.

Deux objectifs distincts qui induisent des approches différentes lors du cadrage : soit basée sur les cibles techniques, soit sur les actifs et processus métier à protéger.

La phase de cadrage se révèle alors clé dans l’efficacité de la campagne et l’atteinte de ses objectifs. Afin de donner de l’intérêt et du relief aux constats, les périmètres à enjeux forts doivent être privilégiés. D’un point de vue plus pragmatique : il s’avère important d’aller dans les détails dès le pré-cadrage, pour identifier non seulement la charge à prévoir, mais aussi valider l’intérêt de la cible, et s’intégrer le cas échéant dans le cycle projet de la cible.

Il faut trouver l’aiguille et non pas brasser du foin ! La tendance actuelle est de raccourcir la durée des audits, dans le but de livrer une synthèse des points les plus saillants, par opposition à un rapport exhaustif de 200 pages…

Enfin, une campagne d’audit demande de rester flexible pour faire face à l’imprévu : il faut conserver une marge de manœuvre afin d’absorber les extensions de périmètre ou les demandes de dernières minutes justifiées par l’actualité ou les incidents.

Savoir faire preuve de souplesse et d’efficience dans la recherche

Si le cadrage doit être précis, le savoir-faire des auditeurs ne se limite pas à dérouler un plan prédéfini !

Il leur incombe de faire preuve d’agilité par rapport au périmètre défini, pour passer moins de temps sur les parties peu vulnérables ou peu critiques, et se concentrer sur les sujets intéressants (présence de vulnérabilités ou criticité élevée).

Un autre aspect où la souplesse est de mise : la gestion des ressources. Le démarrage de la campagne, focalisé sur le cadrage, nécessite une forte présence du pilotage mais peu de réalisation d’audits. Une réduction des ressources peut par ailleurs être anticipée sur les périodes creuses.

Enfin, le pilotage doit s’assurer de remonter en temps réel les alertes relatives aux vulnérabilités les plus critiques mises en évidence.

Les objectifs ont-ils été atteints ?

En fin de campagne, le bilan doit être fait sur 2 aspects. En premier lieu sur la forme : intérêt a posteriori des cibles choisies ? Améliorations à apporter au déroulement de la campagne ? Mais également sur le fond : quels sont les principaux risques identifiés ? Quels sont les périmètres en danger, les enjeux ou processus à renforcer ?

C’est bien lors de la consolidation de l’ensemble des résultats que la campagne prend son sens, et la restitution finale doit apporter des réponses aux objectifs fixés lors du cadrage.

La préparation de la campagne suivante peut ainsi s’envisager après identification des axes d’amélioration, et en capitalisant sur les périmètres d’audit intéressants identifiés tout au long des audits : la prochaine fois, on trouvera l’aiguille plus vite !

Cet article Campagnes d’audit de sécurité : comment trouver une aiguille dans une botte de foin ? est apparu en premier sur RiskInsight.