A quiet revolution is underway in European SOCs. Faced with ever-growing volumes of security events and a persistent shortage of skilled experts, a new generation of AI-powered security tools is emerging, designed to identify correlations that human teams can no longer process alone. AI is not replacing analysts but accelerating and enhancing their work. Between ambitions of hyper‑automation, challenges around model transparency, and the growing push for European digital sovereignty, the landscape of detection and incident-response solutions is rapidly evolving.  

To support this ongoing market transformation, the French National Cybersecurity Agency (ANSSI) and the French National Cyber Coordination Center (NCC‑FR), hosted by ANSSI, have launched an ambitious initiative to provide a detail overview of how IA is used for SOC by conducting a thorough study [1] with major European players specializing in SOC‑oriented security solutions. 

The study had two main objectives: 

1. Identify European players developing solutions for SOCs that integrate AI-based features [2]. 
2. Build an overview of the use cases available on the market, including those offered by leading US vendors operating in Europe. 

This article summarises the key insights drawn from our study conducted among 48 detection and response solution vendors. 

Geographical distribution of the vendors interviewed

A booming European market undergoing consolidation  

The study covered 48 vendors. Among them, 34 are European companies (out of an initial pool of 72 European actors identified), while the remaining 14 are major US‑based vendors firmly established in Europe.  

The market shows clear signs of consolidation, marked by numerous acquisitions, most often involving European companies being acquired by US firms. These acquisitions primarily aim at reinforcing detection and response capabilities, expanding protection coverage, or, more marginally, integrating AI components directly dedicated to detection. Thus, vendors are converging towards a unified platform approach capable of addressing the full spectrum of SOC needs. 

 
Some European initiatives, such as the OPEN XDR alliance, aim at providing a collective response to platform‑related challenges without relying on acquisition strategies between vendors. 

Meetings held with vendors revealed several key insights. 

First, GenAI, or Generative AI (AI capable of generating original content from instructions), is starting to appear within SOC solutions, primarily through chatbots integrated into analysis interfaces; however, their capabilities remain highly limited and inconsistent. These chatbots almost always rely on external technologies, particularly LLMs provided by a small group of major players such as OpenAI, Google, Meta, Anthropic, or Mistral AI, who largely dominate the market. This reliance on third‑party solutions, which often involves transferring data to the environments of these providers, raises significant concerns regarding the protection of sensitive information handled within SOCs. 
To reduce this dependency, several vendors are now considering adopting open‑source LLMs that can be deployed directly within their own environments, enabling greater control over their data and keeping sensitive flows internally.

Overview of the LLMs used by the vendors 

Besides, the use of PredAI, or Predictive AI (AI capable of predicting or classifying an input based on “knowledge” acquired during a training phase), is considerably more mature. Some European vendors have been relying on such approaches for more than 15 years to support use cases ranging from behavioral detection to alert prioritization, demonstrating genuine maturity and established expertise. Most of these use cases focus on the detection phase, where predictive models are widely used, well mastered, and most relevant. 

In addition, several vendors are beginning to explore agentic approaches, with the ambition of gradually delegating part of the repetitive or time‑consuming tasks, particularly the initial qualification of alerts and some steps of the investigation process. 

Finally, these findings should be interpreted with caution: the vendors included in the study represent only a sample of this fast-evolving market.  

Overview of European vendors in Detection & Incident Response solutions using AI  

Overview of AI use cases in detection and incident response tools  

Overview of AI use cases in the SOC operations chain 

The study identified around 50 use cases that can fall under 2 main categories:  

• Use cases based on Predictive AI models, primarily designed for incident detection; 
• Use cases relying on Generative AI, which focus mainly on investigation and incident response tasks. 

Even though the use cases are diverse and hard to list exhaustively, several major categories can nonetheless be identified. Each of these categories is designed to address similar challenges and support the same objective.  

For incident detection, the following AI use case categories can be identified: 

• Detection of abnormal behaviour from users or assets; 
• Detection of anomalies in network traffic; 
• Detection of events suggesting a possible attack; 
• detectionof phishing attempts; 
• and detection of malicious files. 

A new category, regrouping usecases fully addressed by Generative AI, is currently emerging and often addressed by chatbot assistant. Vendors are currently concentrating most of their efforts on these analyst‑oriented assistants, into which they are progressively integrating a wide range of use cases. Their priority is to simplify access to documentation and provide answers to operational questions, as well as extend these capabilities towards more advanced qualification or investigation tasks. 

To achieve this, nearly all vendors follow the same approach by: 

• leveraging a third-party foundation model; 
• applying prompt engineering to make the best use of the model’s capabilities by guiding it towards specific topics; 
• and using RAG (Retrieval‑Augmented Generation), which customizes and enriches the model’s output by supplying it with an authoritative documentation base to create its responses. 

Last, some agentic use cases, based on autonomous agents, are beginning to appear even if they still remain limited. They are currently being addressed by the most advanced and mature vendors in the sector, as well as by start-ups seeking to disrupt the market. 

Unlike most vendors, who are gradually integrating AI use cases into an existing cybersecurity platform, these newcomers are betting on specialized AI-driven solutions designed to address a specific cybersecurity task. Among these use cases are agents dedicated to threat hunting, advanced malware analysis (including automated reverse engineering), as well as the initial qualification of alerts.  

Agentic use cases, however, remain only marginally deployed to date.  

To go deeper… 

ANSSI has published a comprehensive report detailing all the results of the study: https://cyber.gouv.fr/enjeux-technologiques/intelligence-artificielle/etude-de-marche-lia-au-service-de-la-detection-et-de-la-reponse-a-incident/ 

This document now serves as a key reference for understanding current trends and the future evolution of AI’s role in detection and incident response.  

Ultimately, the study highlights a European cybersecurity market that is undergoing rapid restructuring, driven by the rise of AI but also marked by a strong consolidation dynamic. Within this shifting landscape, AI continues to gain maturity across SOC tooling: from Predictive‑AI‑based detection use cases, to GenAI‑powered analytical assistants, all the way to early but promising agentic approaches. This trajectory confirms that intelligent automation will become a major lever for increasing operational efficiency and strengthening organizations’ ability to defend against tomorrow’s threats. 

References

[1] Study conducted from October 2024 to July 2025 – https://cyber.gouv.fr/enjeux-technologiques/intelligence-artificielle/etude-de-marche-lia-au-service-de-la-detection-et-de-la-reponse-a-incident/ 

[2] Artificial intelligence-based features : Set of features using machine learning models (ML, deep learning, LLM) capable of learning from data and producing new analyses, predictions or content.

Cet article Integrating AI into SOC tools: Global overview and current trends in the European market  est apparu en premier sur RiskInsight.

Keeping Responder Relevant: The Hidden Potential of Name Resolution Poisoning

Speaker: Quentin Roland

Quentin Roland’s talk revisited a set of techniques that are often dismissed as “old-school”: poisoning local name resolution protocols like LLMNR, NBNS, or mDNS. While these attacks are usually thought of as a way to quietly capture SMB authentications, the presentation showed that Windows’ built-in behaviors can turn them into a much more serious threat. In particular, the WebDAV fallback and Kerberos relaying can be combined to turn routine network noise into a pathway for domain compromise.

In a typical Windows environment, SMB authentication is everywhere. Poisoning SMB requests with tools like Responder can capture credentials, but most of the time these are machine accounts or authentications that can’t be relayed because SMB enforces strict integrity checks. As a result, many captured authentications are effectively useless for attackers.

The talk highlighted an often-overlooked behavior: Windows will sometimes retry failed SMB connections over HTTP using the WebDAV protocol. This happens through the WebClient service, which is installed by default on most machines. The trick lies in how Windows interprets different error codes. By default, when an SMB login fails, the server responds with a “STATUS_ACCESS_DENIED” status. Windows stops at that point. But if the server responds with a “STATUS_LOGON_FAILURE” instead, the operating system interprets this as a problem with the protocol rather than with the credentials. It retries the connection using WebDAV, effectively transforming an SMB authentication into an HTTP authentication.

This fallback opens a surprising avenue for attackers. HTTP authentications do not enforce signing by default, which means they can be relayed to services like LDAP without being blocked by the protections that make SMB less useful. A poisoned SMB request that would otherwise be wasted suddenly becomes a live, relayed authentication that can be used to enumerate Active Directory, spray passwords, or even create new machine accounts.

The main limitation is that the WebClient service must be running. While it is installed by default, it isn’t always active unless the user or a process has accessed a WebDAV share. Still, where it is enabled, this fallback represents a subtle but powerful way to pivot within a network.

Hacking a Metro Ticket

Speaker : Raphael Attias (rapatt)

This talk was a dive into something both fun and a bit worrying: how easy it can be to hack metro tickets with a Flipper Zero.

For those not familiar, the Flipper Zero is a pocket-sized multi-tool that can interact with various radio protocols, RFID, NFC, and more. While it can’t read every NFC type, it works with a lot of common ones — including the MiFare Ultralight cards used in many metro systems, festivals, and even hospitals.

The speaker started by walking through the evolution of metro tickets: first punched paper, then magnetic stripes, and now RFID/NFC. In his city, the tickets use MiFare Ultralight, which comes with between 48 and 144 bytes of memory and a 7-byte UID. Pretty small and simple compared to more modern cards.

The key detail: when a ticket is validated at a metro gate, the system simply updates one byte on page 3 of the card to mark it as “used.” That means if you can read and write to that sector, you can basically reset the ticket back to “unused” and ride again. The speaker spent nine months analyzing his card, dumping the data before and after validation, and mapping which bytes controlled what. Eventually, he managed to modify the data in a way that gave him unlimited rides.

It didn’t stop there. He was even able to clone the ticket onto his Flipper Zero, use it directly at metro gates, show it to inspectors, and even recharge it at official machines. All because the system trusted the data stored on the card rather than handling everything server-side.

Of course, the attack has its limits. It depends heavily on the ticketing system — not all cities use MiFare Ultralight, and more advanced implementations would catch this. Also, handling things like transfers and expiration dates requires modifying additional fields, which complicates the hack. Still, in this particular case, the weak design made unlimited metro travel possible.

The fix seems straightforward: keep only the UID on the card and move all ticket logic to the backend. That way, even if someone rolls back or clones their card, the server-side system knows whether it’s valid or not. As of now, though, the city in question hasn’t corrected the issue — meaning free rides are technically still on the table.

Speaker: Yassine OUKESSOU

A new tool called AsRepCatcher has been developed by the SOC Team Leader of the ITrust team. As the author is required to perform regular internal audits, he is faced with the following problem: How can a valid domain account be compromised without credentials?

Although there are many techniques for gaining initial access, environments are becoming increasingly secure and remedies are being more and more applied:

• EternalBlue / PrintNightmare / ZeroLogon: patched machines
• LLMNR / NBT-NS / mDNS Poisoning: protocols disabled
• AsRep Roasting: pre-authentication enabled by default on all accounts
• Kerberoasting: SPNs placed only on service accounts and use of gMSA
• Network shares: reading disabled with anonymous or guest accounts
• Brute force weak passwords: strong password policy
• Relays: signed protocols
• Phishing: users made aware

Although the list is not exhaustive, it represents the majority of tests performed by an internal auditor.

However, what the author noticed is that network access is always provided to the auditor, usually in the area reserved for standard users: the user VLAN. In this VLAN, if a user captures the traffic, he will see packets related to authentication, in particular with NTLM or Kerberos protocols.

It turns out that with the Kerberos protocol, a derivative of the user’s password is used (called a hash) to create the KRB_AS_REP request (in the session key).

Thus, an attacker who can retrieve this request could then attempt to crack the user’s password. This is exactly what the AsRepCatcher tool attempts to do (hence the name).

To retrieve the KRB_AS_REP request, the tool uses a well-known technique called ARP Spoofing:

An article by Veracode explains what ARP spoofing is and how to protect yourself from it: https://www.veracode.com/security/arp-spoofing/

AsRepCatcher modifies the ARP table of legitimate VLAN users, who will now send KRB_AS_REQ requests to the attacker, who can modify them on the fly by changing the source IP to his own and also modifying the encryption algorithms used to create the hash.

This information is important because it allows the attacker to retrieve hashes encrypted with a weak algorithm (in this case RC4, provided the KDC authorizes its use), which will greatly facilitate password cracking (a few seconds with RC4 versus several days with AES).

The tool also has features to be more quiet on the network, such as the option (—disable-spoofing) to reset the ARP tables of users whose hash has already been captured.

To protect against the tool, it is therefore recommended to implement remedies against ARP Spoofing and not to allow the RC4 encryption algorithm on the domain.

Tool link: https://github.com/Yaxxine7/ASRepCatcher

Speaker: Nidhal BEN ALOUI

Every year, 580,000 people are registered in the Wanted Persons File (in french: Fichier des Personnes Recherchés). Each person has a file containing information about their identity (surname, first name, age, etc.), a photograph, the reason for the search, and the action to be taken if the individual is found.

In order to classify the files more easily, categories have been created, including:

• AL: mentally ill;
• IT: banned from the territory;
• M: runaway minors;
• PJ: judicial police searches;
• R: opposition to residence in France;
• S: state security;
• T: debtor to the Treasury;
• V: escapees;
• X: missing persons
• etc.

The French gendarmerie police force is often called upon to search for people on this list as part of investigations. In order to find these individuals, the gendarmerie will then use a combination of open source intelligence (OSINT) and closed source intelligence.

For the OSINT part, the use of social networks, tools, and public websites is widely favored. A particular attention is paid to the results of public tools, which are never considered certain by the police force. With regard to closed sources, the gendarmerie has internal tools, databases, and shared national registers that they can consult during the investigations.

It is also possible for judicial police officers (OPJ) to request access to private information stored by companies via “derogatory requests”. Or even to communicate online with potential suspects via a “pseudonymous investigation.”

However, laws very precisely regulate the actions authorized by the gendarmerie, typically:

• Derogatory requests are permitted in the context of criminal investigations.
• Investigations conducted under pseudonyms require a certification from the Cyber Defense Command (ComCyber)
• Each pseudonym and avatar used in the context of an investigation under a pseudonym is unique and recorded in a list accessible to all judicial police officers in order to avoid investigating each other
• It is not permitted to incite someone to commit a crime (for example, asking a potential suspect to purchase illegal goods)

During the conference, two real-life stories were shared to illustrate these concepts.

Purple Team: Methodology and tooling

Speaker: Mael Auzias

This talk, given by Naval Group, tackled the problem of creating a methodology and tooling in order to perform Purple Teams and include them in a larger audit plan to monitor the evolution of the security level and compare different audited scopes.

Indeed, as a part of the missions an internal audit team have, it is important to have defined audit frameworks in order to properly conduct assignments and compare their different results.

To do so, a member of the Red Team worked with the Blue Team of Naval Group to define a specific framework of testing and results reporting, that will ultimately be used to evaluate the detections and responses of each audited party.

Purple Team presentation

A Purple Team is an exercise during which Red Team and Blue Team work hand in hand, by freely sharing both malicious actions that are executed and detections made. The ultimate goal being to improve both detection capacities and responses made.

To properly prepare a Purple Team, it is thus important to define:

• What kind of attacker profile is to be simulated?
• What TTPs to focus on during the exercise?
• What are the targets of the assignment?
• What are the expected detections and responses?

Once those points are taken care of, the Purple Team assignment can start.

Methodology and tooling dedicated to the internal Purple Team exercises

Perform tests

First, the methodology put in place by Naval Group leverages VECTR, a tool destined to automatize testing and measure detection effectiveness by offering a space to both Red and Blue Teams to collaborate. In this case, it is only used as a wrapper to automatically launch specific attacks and collect responses results.

Grading system

Once the attacks are performed and the detection are determined, the actions are classified in the following table:

Indeed, four cases can be differentiated:

• If an observed detection matches the expected one, the tested malicious action gets the higher rating (here, 7)
• If an observed detection is “lower” than the expected one, it gets a poor rating (between 1 to 3 here)
• If an observed detection is slightly higher (for example a the initiation of an incident investigation instead of a simple event), it gets a rather high rating (between 5 and 6 here)
• Finally, if an observed reaction is disproportionate regarding its expected one, it gets a low rating: triggering a global cyber crisis for an action that should not raise an alert can be incapacitating for an information system.

PS: here, the different categories do not exactly match the ones that were presented during the event.

Final grade

Finally, once every attack categories are tested, a specific math formula computes the final grading of the audited scope in the following graph:

This final grading will allow to deduce the performance of the Blue Team, but also monitor the evolution of this of metric over time.

Conclusion

Thus, by defining a clean audit frame to perform Purple Team, it ensures Naval Group to properly assess the performance of the detections made in the different scopes of the company, compare them and monitor the evolutions over time.

This will assurely be proven efficient the more Purple Team exercise are conducted.

Post-Incident Lessons from an Industrial Cyber Breach

Speakers: Hack’im et Antxine

This talk was given by two speakers regarding a post-incident feedback.

Indeed, one of their client contacted them after plugging in an USB flash drive on a standard workstation where an EDR triggered an alert. It was suspicious in that case because this flash drive did not raise alerts before, and was only used to update a standalone server separated form the rest of the network.

Beginning of the investigation

Thus, the focus was made on the server, likely to be infected by a malicious program which propagated to the flash drive.

Using classic tools to retrieve the 900GB of the server and analyze the filesystem and evtx files, they discovered a hidden suspicious program in the %APPDATA% folder called aL4N.exe. Indeed, an unkown executable such as this one should not be in this folder, raising the interest of the investigators.

aL4N.exe

Using VirusTotal to evaluate the dangerousness of the executable, it showed a detection index of 52/94, being concerning and then driving the investigators to continue their assessment in this direction.

Following this lead, they discovered that this malwere has been present on the server from the mastering of the latter, back in 2016, and was brought up by a flash drive.

Traces of earlier in-house investigations were found, with a file mentionning the presence of aL4N.exe found by employees.

Written in AutoIT, this malware establishes a communication tunnel to a C2 (Command & Control) server. However, in the case of this malware, when configured, the malicious actor set the remote server address to localhost, denoting a lack of knowledge from the initiator of the attack.

The replication system of this malware is however less classic. As soon as an external storage of more of 1GB is attached to an infected target, aL4N.exe will create a My Pictures folder and hide it, copy itself in it and create a shortcut for My Pictures that will execute aL4N.exe upon clicking.

Conclusion

The main takeout of this talk is to install detection mechanisms on every components of an IS, even if they are separated for the main network. It is also possible to put in place efficient detection and cleaning stations for flash drives to sanitize removable storage devices, even if the ones of this company did not detecte aL4N.exe.

Cet article Barb’Hack : What to Remember 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.

Indeed, not all companies have the necessary means (or the will) to develop this type of technology internally, and thus turn themselves to market solutions facing a major problem: how to succeed in quickly choosing and integrating an effective solution in my context?

Why use Machine Learning in Cybersecurity?

The static nature of current detection solutions (antiviruses using signature bases, alert thresholds in a SIEM…) no longer allows to face more and more numerous and varied attacks. In addition, security teams are overloaded by the volume of data to be analyzed.

As explained in the article « Which tools do you need for your SOC? » (Part 2 & Part 3), Machine Learning provides an answer to these problems encountered by the SOC by using behavioral analysis methods to detect advanced attacks and prioritize the alerts to be analyzed.

Principle of anomalies detection in a SOC

While these types of solutions provide real added value, they do not completely eliminate the need for current detection methods and are rather used to complement existing tools.

Moreover, their level of complexity (deployment, alerts processing) requires a sufficient level of maturity in terms of detection and reaction (organization, tools, resources, data centralization) before it is relevant to launch a project based on Machine Learning. This will facilitate the scoping phase and speed up deployment.

In advance of phase: defining the specifications

Which use case do I wish to address?

During our various interventions with our clients, we have supported the integration of numerous solutions and we can highlight four main types of use cases on which companies invest:

• Fight against fraud: tools for detecting deviation(s) in user’s behavior(s)
• Email monitoring: prevention tools against phishing or information leakage (DLP)
• Network threat detection: «Next-Gen » probes
• Endpoint threat identification: « Next-Gen » anti-viruses

The choice of a solution (and therefore of a use case) should not be defined unilaterally by the ISS branch, but should be discussed with various stakeholders (ISS, CIO, businesses, etc.). This exchange will enable the target to be specified and the technical and organizational prerequisites to be validated (accessibility of logs, resources to be mobilized, size of teams, etc.) in order to best prepare for its integration and use.

What kind of solution to choose?

Depending on the tools already in place and according to the need, several solutions are possible:

• Choosing to implement a turnkey solution allowing to treat very precise use cases that are not specific to business issues (EDR, behavioral biometrics…). This choice generally suits an immediate need rather than a long-term strategy.
• Activate a Machine Learning module on a tool already in place (SIEM, log sink…) in order to extend its detection perimeter. This choice allows to quickly test use cases and to free oneself from the phases of integration of a new equipment within the IS.

Finally, it is essential to remember that there is no miracle solution and that each type of solution responds to specific needs.

In front of the editor : challenging the essential points

Testing the solution and think about scalability

Once all these prerequisites are defined, it is usual to realize with the editor a Proof of Concept (PoC). However, in the specific case of a Machine Learning solution, the PoC will answer several specific questions:

• Do my currently collected data allow me to have quickly satisfactory results? Machine Learning solutions require the analysis of a very large amount of data potentially enriched by repositories that can be cross-referenced from several sources. It is therefore necessary to make sure in advance with the editor that the data currently collected already allows to obtain first results.
• How long will the learning phase last in my context? Some Machine Learning solutions produce results only after several months or even years because the learning phases can be extremely long due to the specific context of each company. The possibility to use a log history for tests would allow you to free yourself from a significant learning period.

Specific questions will also have to be addressed in order to anticipate the longer term:

• Will it be possible to enrich the analyses with other types of data? Machine Learning solutions allow you to perform analyses on many types of data that may have heterogeneous formats, so it is necessary to be able to ensure that the analyses can be enriched with new types of data collected.
• Will it be possible to implement new detection algorithms? The possibility of being able to customize these solutions by adding new types of algorithms (and potentially independently) is not negligible.
• How can I be sure that my publisher is always at the cutting edge of technology? Given the exponential evolution of techniques on this subject, it is important to ensure that the publisher continues to be at the forefront of technology in order to offer new means of defense against attacks that are becoming increasingly complex.

Preparing to protect the data life cycle

Detection methods based on behavioral analysis require the collection and processing of sensitive/personal data. Thus, especially in the case where the solution is hosted by the editor, issues related to the use of the data will have to be addressed as soon as possible. On the one hand, contractual security requirements will of course need to be reinforced, and on the other hand it may be useful to use upstream solutions that enable more secure processing of the data lifecycle.

For example, startups like SARUS are working on masking personal data, allowing data scientists to perform Machine Learning without accessing source data. Startups like HAZY are working on generating synthetic data that keeps the statistical value of the useful data, but loses its sensitive nature. This type of solution also allows to artificially enlarge the sample provided, and to obtain an almost unlimited amount of data, which can be very useful in the context of a PoC where currently available data is limited.

Once the relevance of the solution is validated, the adventure is just beginning!

Through our various experiences, we have been able to forge a conviction: the market is mature enough to provide interesting results, especially on the four use cases mentioned above. The implementation of such tools will be effective if the solutions are connected to a rich ecosystem and meet a specific need. Indeed, the implementation of one solution can be a success or a failure in two different contexts. The result will depend on the clarity of the need, the scope targeted, the expertise available (Cybersecurity and Data Science), and the availability of the data (quality and quantity).

While choosing a Machine Learning solution is not easy, the best way to get an idea quickly is to realize a PoC that can be quick and involving little engagement: we have seen with some of our customers that solutions were already showing interesting results after only two weeks of PoC.

Keeping in mind that the PoC is only the beginning of the adventure. It will result in the launch of an exciting project lasting several months (analysis of new types of alerts, discovery of new techniques …), bringing a real added value in security (detection of new events …), boosting a new breath within the operational security teams (prioritization of efforts, possibility of optimizing redundant tasks …).

Cet article Machine learning for its cybersecurity: how to find your way in the jungle of products est apparu en premier sur RiskInsight.

En effet, toutes les entreprises n’ont pas les moyens nécessaires (ou la volonté) de développer en interne ce type de technologie et se tournent alors vers des solutions du marché en se confrontant à une problématique majeure : comment réussir à choisir et intégrer rapidement une solution efficace dans mon contexte ?

Pourquoi utiliser du Machine Learning en cybersécurité ?

Le caractère statique des solutions de détection actuelles (antivirus utilisant des bases de signatures, alertes seuils d’alerte dans un SIEM…) ne permet plus de faire face à des attaques de plus en plus nombreuses et variées. En outre, les équipes de sécurité sont surchargées par le volume de données à analyser.

Comme expliqué dans l’article « La saga de l’été sur les nouveaux outils du SOC » (Partie 2 & Partie 3), le Machine Learning permet de répondre à ces problématiques que rencontre le SOC en utilisant des méthodes d’analyse comportementale pour détecter des attaques avancées et prioriser les alertes à analyser.

Principe de détection d’anomalies dans un SOC

Si ces types de solutions apportent une réelle plus-value, elles ne permettent pas de totalement s’affranchir des moyens de détection actuels et sont plutôt utilisées pour compléter les outils en place.

Par ailleurs, leur niveau de complexité (déploiement, traitement des alertes) requiert en prérequis d’avoir déjà atteint un niveau de maturité suffisant en termes de détection et réaction (organisation, outillage, ressources, centralisation de la donnée) avant qu’il soit pertinent de se lancer dans un projet basé sur du Machine Learning. La phase de cadrage n’en sera que facilitée et le déploiement accéléré.

En avance de phase : définir le cahier des charges

Quel est le cas d’usage que je souhaite adresser ?

Lors de nos différentes interventions chez nos clients, nous avons accompagné l’intégration de nombreuses solutions et nous pouvons faire ressortir quatre grands types de cas d’usages sur lesquels les entreprises investissent :

• La lutte contre la fraude: outils de détection de déviation(s) dans le(s) comportement(s) d’un utilisateur
• La surveillance des emails: outils de prévention contre le phishing ou la fuite d’informations (DLP)
• La détection de menaces sur le réseau: sondes « Next-Gen »
• L’identification des menaces sur les endpoints: anti-virus « Next-Gen »

Le choix d’une solution (et donc d’un cas d’usage) ne devra pas être défini de manière unilatérale par la filière SSI mais devra être réfléchi avec les différents acteurs concernés (SSI, DSI, métiers…). Cet échange permettra de préciser la cible ainsi que de valider les prérequis techniques et organisationnels (accessibilité des logs, ressources à mobiliser, taille des équipes…) pour préparer au mieux son intégration et son exploitation.

Quel type de solution choisir ?

Selon les outils déjà en place et en fonction du besoin, plusieurs solutions sont envisageables :

• Choisir d’implémenter une solution clé en main permettant de traiter des cas d’usages très précis et non spécifiques à des problématiques métiers (EDR, biométrie comportementale…). Ce choix convient généralement à un besoin immédiat plutôt qu’à une stratégie à long terme.
• Activer un module de Machine Learning sur un outil déjà en place (SIEM, puits de logs…) dans le but de pouvoir étendre son périmètre de détection. Ce choix permet notamment de pouvoir tester rapidement des cas d’usages et de s’affranchir des phases d’intégration d’un nouvel équipement au sein du son SI.

Enfin, il est essentiel de se rappeler qu’il n’existe pas de solution miracle et que chaque type de solution répond à des besoins précis.

Devant l’éditeur : challenger les points essentiels

Tester la solution et réfléchir à son évolutivité

Une fois que tous ces prérequis sont définis, il est d’usage de réaliser avec l’éditeur un Proof of Concept (PoC). Cependant, dans le cas spécifique d’une solution de Machine Learning, le PoC permettra de répondre à plusieurs interrogations spécifiques :

• Mes données actuellement collectées permettent-elles d’avoir des résultats rapidement satisfaisants ? Les solutions de Machine Learning requièrent l’analyse d’un très grand nombre de données potentiellement enrichies par des référentiels permettant de croiser plusieurs sources. Il est donc nécessaire de s’assurer en avance de phase avec l’éditeur que les données actuellement collectées permettent déjà d’obtenir des premiers résultats.
• Combien de temps la phase d’apprentissage durera-t-elle dans mon contexte ? Certaines solutions de Machine Learning produisent des résultats qu’à partir de plusieurs mois voire années car les phases d’apprentissages peuvent-être extrêmement longues du fait du contexte particulier à chaque entreprise. La possibilité d’utiliser un historique de logs pour les tests permettrait de s’affranchir d’une période d’apprentissage conséquente.

Des questions spécifiques seront également à traiter afin d’anticiper le plus long terme :

• Sera-t-il possible d’enrichir les analyses avec d’autres types de données ? Les solutions de Machine Learning permettent de pouvoir effectuer des analyses sur de nombreux types de données pouvant avoir des formats hétérogènes, il est donc nécessaire de pouvoir s’assurer que les analyses pourront être enrichies avec de nouveaux types de données collectées.
• Sera-t-il possible de mettre en place de nouveaux algorithmes de détection ? La possibilité de pouvoir personnaliser ces solutions en y ajoutant de nouveaux types d’algorithmes (et potentiellement de manière indépendante) est non négligeable.
• Comment suis-je assuré que mon éditeur soit toujours à la pointe de la technologie ? Au vu de l’évolution exponentielle des techniques sur ce sujet, il est important de s’assurer que l’éditeur poursuive sa course à l’avancée technologique afin de proposer de nouveaux moyens de défense contre des attaques qui ne cessent de se complexifier.

Se préparer à protéger le cycle de vie de la donnée

Les méthodes de détection basées sur de l’analyse comportementale nécessitent la collecte et le traitement de données sensibles/personnelles. Ainsi, particulièrement dans le cas où la solution est hébergée chez l’éditeur, les problématiques liées à l’usage des données devront être adressées au plus tôt. D’une part les exigences contractuelles de sécurité devront bien sûr être renforcées, et d’autre part il pourra être utile de faire appel en amont à des solutions permettant un traitement plus sécurisé du cycle de vie de la donnée.

Par exemple, des startups comme SARUS travaillent sur le masquage des données personnelles, permettant aux data scientists d’effectuer du Machine Learning sans accéder aux données sources. Des startups comme HAZY travaillent elles sur la génération de données synthétiques gardant la valeur statistique des données utiles, mais perdant leur caractère sensible. Ce type de solution permet également d’agrandir artificiellement l’échantillon fourni, et d’obtenir une quantité quasiment illimitée de données, ce qui peut être très utile dans le cadre d’un PoC où les données actuellement disponibles sont en quantité limitées.

Une fois que la pertinence de la solution est validée, la partie ne fait que commencer !

Au travers de nos différentes expériences, nous avons pu nous forger une conviction : le marché est assez mature pour fournir des résultats intéressants, notamment sur les quatre cas d’usages mentionnés ci-dessus. La mise en place de tels outils saura être efficace si les solutions sont connectées à un écosystème riche et qu’elles répondent à un besoin spécifique. En effet, la mise en place d’une même solution peut être une franche réussite ou un échec dans deux contextes différents. Le résultat dépendra notamment de la clarté du besoin, du périmètre visé, de l’expertise présente (Cybersécurité et Data Science), et encore de la disponibilité de la donnée (qualité et quantité).

Si le choix d’une solution de Machine Learning n’est pas simple, le meilleur moyen de se faire rapidement une idée est de réaliser un PoC pouvant être rapide et peu engageant : nous avons pu constater chez certains de nos clients que des solutions remontaient déjà des résultats intéressants après uniquement deux semaines de PoC.

Tout en gardant en tête que le PoC n’est que le début de l’aventure. Il résultera sur le lancement d’un projet de plusieurs mois passionnant (analyse de nouveaux types d’alertes, découvertes de nouvelles techniques…), apportant une réelle plus-value sécurité (détection de nouveaux évènements…), impulsant un nouveau souffle au sein des équipes opérationnelles de sécurité (priorisation des efforts, possibilité d’optimisation des tâches rébarbatives…).

Cet article MACHINE LEARNING POUR SA CYBERSECURITE : COMMENT SE RETROUVER DANS LA JUNGLE DES PRODUITS 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.

Several topics must be addressed when securing Office 365  including the need to be able to track actions to detect illicit behaviour or trace the cause of an incident.

In France, however, many companies have difficulty consolidating logs and defining supervision use cases. Mastering logging must be at the heart of this approach.

Supervision of administrative actions is a necessity

For this logging decryption, let’s take the case of the platform administrators.

As with other SaaS solutions (Google Cloud Platform, Salesforce, etc.), the breach of data integrity or confidentiality following an error or malicious action by a company administrator is one of the major risks identified by our customers.

By definition, Office 365 administrators have high privileges:

• Configuration of the various services – or workloads – and APIs;
• Managing permissions on OneDrive and user mailboxes;
• Management of the life cycle of collaboration spaces.

It is easy to imagine the disastrous consequences that could result from the malicious or uncontrolled use of these privileges. Indeed, settings such as SharePoint Online external sharing, API permissions or email configuration could become significant data leakage vectors.

On-premise IT best-practices (lifecycle, least privilege principle, rights segmentation, strong authentication, just-in-time access, etc.) must also be applied in the Cloud. The Cloud must be mastered and controlled.

However, the implementation of good practices, although necessary, is not enough. Indeed, they do not guarantee that  administrators won’t carry out actions that compromise the level of security. One can therefore naturally wonder how it would be possible to audit the actions carried out and raise alerts if necessary.

What are the means provided by Microsoft? How can we prevent a malicious person from covering his tracks (which would make an attack more difficult to detect and reconstruct)?

To illustrate the different possibilities, we will follow the four examples below:

Figure 1 – Examples of configuration changes that may affect safety

What logs are available?

For historical and technical reasons, Office 365 inherently has several log sources: Unified Audit Logs, Exchange Logs and Azure Logs. These sources are complementary and must be analysed together in order to have an exhaustive view of the administrative actions performed.

Unified Audit Logs: unified logging of the different services

The most commonly cited and used source of logs is the “Unified Audit Logs”. These logs centralise the traces of users and administrators for all the platform’s services: SharePoint Online, Azure AD, Exchange Online, Teams, Power Platforms. Microsoft is progressively integrating the different sources and continues to add new logs.

To come back to our concrete examples, the interesting logs are:

• SharePoint Online External Sharing Policy Change: SharingPolicyChanged
• Assigning rights to a One Drive: SiteCollectionAdminAdded
• Assigning rights to a mailbox: AddMailboxPermission
• Changing an Administration Role: AddMembertoRole

These logs are accessible and exportable via the Compliance and Security Centers, the Office 365 Management and PowerShell APIs (via the Search-UnifiedAuditLog cmdlet). Note that logging must be enabled via the Compliance Center or PowerShell to be able to log and search.

It is possible to directly configure alerts related to the occurrence of certain logs in the Security and Compliance Centers.

Exchange Logs: logging of the messaging infrastructure

The second interesting source of logs is the “Exchange Logs“. These logs provide information about usage and administrative actions performed on the Exchange Online service as well as on personal or shared mailboxes. Two types of logs can be distinguished:

• Administrator Audit Logs: Service or mailbox administration logs (e.g. changing a user’s permissions, changing the retention time of a mailbox log etc.).
• Mailbox Audit Logs: Logs of use of a mailbox by the main user, a delegated user or a service administrator (e.g.: accessing the mailbox, sending an email in place of the main user, moving an item into a folder, permanent deletion, etc.).

To come back to our concrete examples, the logs that will interest us here are:

• Assigning rights to a mailbox: AddMailboxPermission
• Access to a folder or a mailbox: FolderBind (not enabled by default):
• Access to a mail: MailItemAccessed (only for users with an E5 license)

To go further with Administrator Audit Logs

Administrator Audit Logs are generated for any Exchange administration action that can be linked to a PowerShell cmdlet other than Get, Search or Test. These logs are linked to the Unified Logs and can be used in the Exchange Administration Center, Security and Compliance Centers, Office 365 Management and PowerShell APIs.

To go further with Mailbox Audit Logs

Mailbox Audit Logs are the only category of logs to be configurable (perimeter and granularity). These logs allow tracing of the actions performed by an owner, a delegate (user with permissions) and an admin (access via eDiscovery tools).

Since January 2019, the logging of Mailbox Audit Logs is enabled by default for all Office 365 tenants. To date, if logging is enabled by default, all mailboxes are audited (even if the “-AuditDisabled” parameter is set to “True”). The only way not to log the actions of a mailbox is to implement a by-pass rule with “Set-MailboxAuditBypassAssociation”.

However, it should be noted that some actions are not audited by default, such as the access of a delegate or an admin to a user’s mailbox. It is therefore essential to analyse the logs to be activated, during the initial configuration of the service.

Depending on the license level and configuration, these logs can be linked to the Unified Logs and be used in the Exchange Administration Center, the Office 365 Management and PowerShell APIs or the Security and Compliance Centers.

Azure Logs and Reports: Azure Active Directory Logging

The last, but not least important source of logs are the “Azure AD logs”. These logs provide complete traces of the Office 365 identity brick and the associated administration actions. Several categories of logs and reports are available:

• Azure Audit Logs: Logs for the administration of the identification brick or modification of items (e.g. assigning the “SharePoint Administrator” role, creating a security user or group, authorising an API, configuring guest users, etc.).
• Azure Sign-in Logs: Logs for connecting to an Office 365 service (or to applications / APIs based on Azure AD) with information regarding the connection chain (e.g. protocol, IP address, terminal, etc.).
• Risky Sign-in: Connection reports with indicators related to suspicious connections.

These logs and reports are accessible and exportable via the Azure portal, the Graph or Azure Management and PowerShell APIs. Some of the logs directly related to Office 365 are also found in the Unified Audit Logs.

To come back to our concrete examples, the interesting logs are:

• Modification of an administration role: AddMembertoRole

Figure 2 – Summary of Office 365 Logs Features

In summary, the Unified Audit Logs provide a consolidated view of the different services of Office 365, but some information may be missing. It will be necessary to ensure that the required logs are present, and then to investigate further into the logs and reports of Exchange or Azure.

What is the retention period for the various Office 365 logs?

Once the proper logs have been identified, the challenge of retention arises. How can you be sure that the logs are well preserved without being altered, for as long as is required by the company’s security policy and various regulations, such as the anti-terrorist law or the GDPR?

By construction, and contrary to Exchange and SharePoint on-premise solutions, all the logs mentioned above are unalterable – that is to say, they cannot be modified or deleted by the company administrators. Furthermore, the default retention periods defined by default cannot be modified (i.e. 90 days for Office 365 and 7 logs or 30 days for Azure logs with standard licenses). With one exception, an Exchange administrator has the ability to delete the logs from mailboxes by changing the associated retention time.

If we go back to our examples, we could imagine a malicious administrator giving himself rights to access a mailbox, then look at the mails and erase the access logs by setting a zero-retention time. In this case, only the privilege elevation made in the Administrator Audit Logs would be retained.

In order to comply with security or regulatory requirements, it may also be necessary to ensure that the logs of the various departments are kept for more than 7, 30 or 90 days.

3 steps to implement relevant logging within Office 365

1. Definition and activation of the necessary logs: Unified Audit Logs may not be sufficient (monitoring of the Office 365 and Azure AD APIs, logging of administrator access to mailboxes, etc.);
2. Configuration of an automatic export of the identified logs to an external storage or an independent SIEM (via PowerShell or the API Management);
3. Monitoring the status of the tenant: implementing a dashboard of the tenant’s settings configuring alerts related to a change in log configuration (via the Security or Compliance Center, the Office 365 Management or PowerShell APIs), such as disabling Unified logs or a change in the retention of mailbox logs.

Figure 3 – Good Practices for Office 365 Logging

After carrying out these three actions, the company will have the necessary information to audit the tenant’s use and administration actions. However, this does not yet address the larger need for supervision of administrators. It may be useful to set up alerts (via the Security or Compliance Center or specialised third-party tools).

1. (To go further) Implementation of basic supervision: definition of general security detection scenarios, identification of the logs concerned, activation of the associated alert in the Security or Compliance Centers;
2. (To go even further) Setting up advanced supervision: identification of scenarios related to a business context, implementation, definition of the associated governance, continuous improvement.

What tools should be used to analyze the logs? Which detection scenarios should be prioritised? What governance should be put in place to define, implement and monitor alerts? These are all questions that need to be addressed in the implementation of the collaboration platform supervision.

It will also be necessary to take into account the regular changes made by Microsoft on these services, as well as on the structure of logs and APIs, especially since the preview and general availability functionalities coexist.

Cet article Logging of Office 365: a Case Study with Administrators est apparu en premier sur RiskInsight.

Building a Smart City project with Cybersecurity

It is essential to integrate cyber security aspects from the start of a Smart City project. Indeed, carrying it out later in the project may prove to be more complex and expensive, with the risk of not dealing with it / not being able to deal with all the risks.

This requires rethinking the organization of the project regarding data and security governance: security principles must be defined at the global project level and considered by each of the sub-projects composing the Smart City, depending on their constraints. This is particularly true as Smart Cities involve many actors with different core businesses, means and cybersecurity maturity. A global and shared vision is essential to ensure that each element processes the data with the appropriate level of security.

It is then necessary to define the main principles of architecture and interoperability, according to the constraints inherent to the Smart City, related to Edge Computing and the deployment of objects in a hostile environment. System resilience must be at the heart of safety requirements, as the fall or compromise of one element should not cause the entire system to fall.

To this end, common standards must be adopted, based on specific frameworks such as ETSI or OneM2M. These increase the chances of maintaining scalable interoperable systems. More generally, the NIST or the ISO 27002 standard are proven Cybersecurity frameworks on which it would be interesting to rely.

The development mode must be agile, integrating a long-term vision to anticipate new use cases, and with short milestones in order to quickly deliver the first services. Cybersecurity must be included in the development process, by defining Evil User Stories, enabling risks to be identified and considered each time services or the information system evolves, and by appointing cybersecurity experts in a support and validation role.

Defining and maintaining a satisfactory level of security will, more than ever, require the rigorous integration of security in all phases of the project, which may lead to greater but necessary human and technological investments.

Protecting critical and regulated data

Given the propensity of the Smart City to collect and process large amounts of data, their protection will primarily involve identifying critical data and assets.

Most of the services offered by the Smart City are aimed at citizens. Therefore, personal and potentially sensitive data will be collected. Furthermore, a loss of availability or integrity of certain services could have serious repercussions since some components of the IS have a direct hold on the physical world. Smart Cities are not exempt from regulations, in particular the General Data Protection Regulations (GDPR), but also, depending on usage, from the General Security Regulations (GSR), the Military Programming Law (MPL) or the Network and Information Security (NIS) directive, whose data protection requirements will have to be integrated into the programs.

Levels of data sensitivity classification must therefore be formalized in order to enable the prioritization of actions and the setting up of an appropriate framework for the processing of critical data such as encryption and anonymization.

The problem of access to data should also be raised. There are many actors in the Smart City and it will be necessary to segment the “vision” they may have of the IS. This will involve a preliminary phase of defining the authorization profiles, necessary to respect the principle of least privilege, combined with a regular review of their assignments to ensure that they are still legitimate.

Operating in trusted environments

The Smart City project will necessarily rely on different technical and organizational foundations. If these bases are to the Information System what foundations are to a house, it is easy to understand that it will be difficult to build anything if this base is fragile.

As always, these technical bases must be covered by fundamental security measures: implementation of trust bubbles, hardening of systems, patch management, securing of privileged accounts and their use, etc.

Furthermore, an information system with a large attack area such as the Smart City will necessarily have to break with the traditional security model known as “castle security”, by relying more on aspects of partitioning and access control of the data itself. The conformity of assets within the information system will have to be continuously evaluated using common configuration and hardening frameworks. Exposed systems and applications must be subject to controls and audits, particularly during the development phase, but also during the operational phase.

In addition, business continuity and disaster recovery will have to be at the heart of the security strategy. Plans will have to be formalized, but also tested, including both technical considerations such as the resilience of different systems, with the ability to restore systems independently of each other, and organizational considerations through crisis management exercises.

Finally, as Smart City involves many players, all stakeholders should ensure the implementation of significant means in the protection of the information systems involved and comply with the requirements of the project’s security policy. To do this, they will have to be contractually committed, at the very least by including security requirements in contracts, but also by formalizing and implementing security assurance plans, particularly for the most critical service providers. Regular controls may be commissioned to ensure that the security level is maintained over time and to address future risk scenarios.

Detecting, reacting and sharing

The Smart City cannot do without a service to detect and deal with security incidents.

It will be necessary to collect traces of activity on the systems and look for weak signals. In view of the large number of events to be processed, it will be essential to define the risks to be guarded against and to rely on correlation solutions to facilitate these searches. The use of automation tools will allow a first sorting of false positives, facilitating the work of analysts in the qualification of security alerts.

The detection and response service can be built using the PDIS and PRIS standards. Qualified external suppliers may be used for these two services as required.

The use of Cyber Threat Intelligence services will bring a significant efficiency gain in the creation and enrichment of SOC detection rules. Indeed, it will be possible to adopt a proactive detection posture by monitoring attacks that have targeted Smart Cities and the operating modes used. This will also have the advantage of improving the efficiency of the response service by saving precious investigation time.

Finally, the process of handling significant and major security incidents cannot be carried out without the formalization of a crisis management unit, composed of actors with well-defined roles and trained for this exercise. Particular attention will be paid to the external communication system, since the “severity” of a crisis depends as much on the event that caused it as on how it is perceived by the outside world.

In conclusion, and as we have seen through these two articles, the Smart City is a self-evident development in an era where demographic, ecological and economic issues are all intertwined. Its promises are seductive, but the implementation framework may give rise to some fears.

As with any digital transformation, ensuring a level of security in line with the challenges of the project will necessarily involve identifying the vulnerabilities and security risks it generates.

In the era of cyber-warfare and cyber-threats, the Smart City should be considered as a Digital Service Provider, within the meaning of the NIS directive, and be protected by security measures adapted to this status.

The provision of secure services, respectful of their users’ data, is a sine qua non condition for the success of a Smart City project, the benefits of which will only be matched by the magnitude of the impact of a successful cyberattack.

Cet article Cybersecurity issues around Smart City (2/2) est apparu en premier sur RiskInsight.

From static detection methods to behavioral analysis

As attacks evolve more and more rapidly and in an increasingly sophisticated way, the SOC (Security Operations Center) is forced to review its approach and existing tools as static detection mechanisms become obsolete:

• The historical approach uses the recognition of known behaviors and footprints (e.g. malware signatures). This method, called misuse-based, provides explicit alerts that are easy to analyse for operational staff, but only attacks that have already occurred and been detected can be recognized.
• The new approach aims to analyse actions that deviate from the behavior normally observed, without having to explicitly and exhaustively define a malicious act (e.g. the behavior of an individual who deviates from that of his colleagues). This anomaly-based approach makes it possible to detect attacks that are not directly run through the tools but require high volumes of data.

The anomaly-based approach exploits the correlation capabilities of unsupervised learning algorithms that highlight links between unlabeled data (i.e. not categorized as normal or abnormal).

Recipe: detection of anomalies on a machine learning bed

To know if Machine Learning is appropriate for its context, the best solution is to create a PoC (Proof of Concept). How do you implement it? What are the key points to look out for? Here are the key steps in our development.

Starter, main or dessert: define the use case

Doing Machine Learning is good, knowing why is better. Defining a use case is like answering the question ‘What do you want to observe?’ and determining the means available to respond.

In our context, a use case is a threat scenario involving one or more groups of accounts (malicious administrators, exfiltration of sensitive data, etc…). To evaluate them, several criteria must be taken into consideration:

• Utility: what would be the impact if the scenario were to happen?
• Data availability: what are the available sources of useful data?
• Data complexity: is the available data structured (numbers, tables) or unstructured (images, text)?

We have chosen to work on the compromising of service accounts: some may have important rights, and their automated actions generate relatively structured data. In the context of a PoC, a limited scope, and homogeneous and easily accessible data sources are essential to obtain concrete and exploitable results, before considering more ambitious use cases.

Ingredient weighing: determine the data model

In order to make the best use of the data, it is necessary to define a behavior to be modeled based on available information. This is where business expertise comes in: can an isolated action be a sign of compromise or should a series of actions be considered for detecting malicious behavior?

First, we defined a model based on the analysis of unit and family logs (e.g. connections, access to resources, etc.) to evaluate the overall functioning. However, a model that is too simple will ignore weak signals hidden in action correlations, while a representation that is too complex will add processing time and be more sensitive to modelling biases.

Selection of tools: choose the algorithm

Several types of algorithms can be used to detect anomalies:

• Some try to isolate each point: if a point is easy to isolate, it is far from the others and therefore more abnormal.
• Clustering algorithms creates groups of points that look alike and from this it calculates the center of gravity of each one to create the average behavior: if a point is too far from the center, it is considered abnormal.
• Less common, auto-encoders are artificial neural networks that learn to recreate normal behavior with fewer parameters: behavior reproduction errors can be considered as an anomaly score.

Other approaches still exist, including the most exotic artificial immune systems that mimic biological mechanisms to create an evolving detection tool. However, it should not be forgotten that a simple and well optimized tool is often more effective than an overly complex tool.

The k-means clustering algorithm was selected in our case: used in the detection of bank fraud, it simplifies re-training which allows the tool to remain adaptable despite changes in behavior.

All these algorithms can also be enhanced, depending on the chosen behavior model, to consider a series of actions. Thus, convolutional or recurrent neural networks can be added upstream to take into account time series.

Preparation of ingredients: transforming data

Once the algorithm has been selected, the raw data must be processed to make it usable. This process is carried out in several steps:

• Cleaning: correction of parsing errors, removal of unnecessary information and addition of missing information.
• Enrichment: adding data from other sources and reprocessing fields to highlight information (e. g. indicate if a date is a public holiday…).
• Transformation: creation of binary columns for qualitative data (e.g. account name, event type, etc.) that cannot be directly transformed into numbers (one column for each unique value, indicating whether the value is present or not).
• Normalization: reprocessing the values so that they are all between 0 and 1 (to prevent one field from taking over from another).

Due to the variety of possible events and the complexity of the logs, we have chosen to automate this process: for each field, the algorithm detects the type of data and selects the appropriate transformation from a predefined library. The operator can then interact with the tool to modify the choice before continuing the process.

Seasoning: test and optimize the tool

Once the model has been defined, the algorithm chosen and the data transformed, the tool developed should be able to raise alerts on anomalies. Do these alerts make sense or are they false positives?

In order to evaluate the performance of the tool, we performed two types of tests:

• Intrusion simulation by performing malicious actions to check if they are detected as abnormal (this approach can also be handled by directly adding “false” logs to data sets).
• Analysis of anomalies by checking whether the alerts raised actually correspond to malicious behavior.

Many parameters can be adjusted in the algorithms to refine detection. Performance optimization is achieved through an iterative process; changing parameters and observing the effect on a set of validation data. Manually time-consuming, it can be improved by the AutoML approach which seeks to automate certain steps by using optimization algorithms.

However, parameter optimization is not enough: the results of our PoC have shown that the quality of detection based on behavioral analysis depends largely on the relevance of the behaviors defined before the algorithm is developed.

ML or not ML: that may not be the question

Despite its undeniable advantages, Machine Learning is a tool to be used in a rational way: frameworks are becoming increasingly accessible and easy to use, but the definition of the use-case and the behavior model are still crucial steps that exist. These choices, where business expertise is essential, will irreversibly influence the choice of data, the selection of the detection algorithm and the tests to be performed.

The question is no longer ‘Where can I put Machine Learning in my SOC? ‘, but rather ‘Of all the approaches available, which is the most effective to address my problem?’.

To find out, there’s only one solution: light the fires!

To go further…

… here are the tools used during our PoC:

• IDE
  • Pycharm: clear and practical development environment with efficient library management
• Language
  • Python: a language widely used in the field of Data Science with many powerful libraries
• Libraries
  • Scikit-learn: complete Machine Learning library (supervised, unsupervised…)
  • Pandas: complex processing of data tables
  • Numpy: handling of matrices and vectors
  • Matplotlib, Seaborn: display of graphics for visualization

Cet article Detect cyber incidents with machine learning: our model in 5 key steps! 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.

Against a backdrop of an acute shortage of cybersecurity skills, these issues cannot be addressed solely by increasing the size of SOC teams. The use of new tools, based on four strategic areas, is essential in enabling SOCs to stay ahead of threats.

Here, extending the scope of detection enables the protection of new areas of the IS that are not sufficiently secure (such as the cloud) and of resources that are increasingly being chosen as targets (through ransomware attacks on terminals, targeted attacks using ADs, etc.).

At the same time, new approaches need to be adopted to detect targeted attacks (0-day, “low signal”, etc.), whose increasing sophistication is undermining existing security measures.

In addition to these new detection tools, an advanced knowledge of threats and attackers can improve existing detection capabilities, help prioritize incidents to be dealt with, and increase the effectiveness of the response.

But SOC teams are already struggling to process the events generated by existing tools. As a result, it’s essential to standardize and automate interactions between teams and systems, and, wherever possible, the sequence of analysis and response.

Follow our series on the topic and learn how to tool up in these four strategic areas!

Extending the scope of detection to new perimeters

A unique solution to secure all clouds: CASB

Cloud Access Security Brokers (CASBs) address an area of the IS that is poorly served by traditional security measures: the cloud. The very nature of the cloud means that protection in this area requires a different approach to that used for a conventional IS; there is little or no control of resources (infrastructure, OSs, or applications—depending on the type of offering), assets are located outside the IS, etc.

CASBs aim to centralize and ensure that security policies are applied. Some cloud providers offer their own CASB security services (for example, Microsoft’s Cloud App Security); but, depending on the needs, it may be preferable to use third-party solutions, even though there is a cost to adding in another player. While CASBs aim to ensure security levels in the cloud, relying on the cloud service providers to perform this monitoring role can be counterproductive: it’s preferable to make use of a “trusted third party”.

In all cases, CASBs offer a diversity of solutions that can include a very large number of services—their degree of maturity depending on the solution’s publisher, the cloud provider, and the type of hosting (IaaS, PaaS, SaaS, etc.).

On the one hand, CASB solutions make it possible to deal with specific cloud issues, by addressing the lack of visibility in these environments (through shadow IT detection, usage statistics, etc.) and ensuring that they are compliant (verification of configurations, etc.).

On the other hand, they play a part in the application of traditional security measures in this cloud. In particular, data security issues (such as DLP and encryption measures, which are of special concern to regulators) and threat detection (centralization of cloud logs for transmission to SIEM, detection of abnormal behavior using UEBA (see our dedicated article on this), etc.) are parts of a CASB traditional capabilities. In addition, some stakes associated with IAM can also be addressed by these solutions (SSO, access contextualization, etc.).

There are two main modes of deployment when putting these features in place, each with its advantages and disadvantages. Proxy-type solutions are placed between users and the cloud service.

In contrast, when using API-type solutions, which are sometimes called “out-of-band”, the cloud service’s consumers communicate directly with it. Each time it’s accessed, the service queries the CASB’s APIs to evaluate the risks and authorize (or prohibit) the consumption of the service. However, to operate, API solutions rely on the interfaces offered by the cloud provider, which may limit the options.

At present, CASBs are relatively new and immature solutions, and their deployment is limited. However, given the increasingly broad adoption of cloud services (already well advanced), CASBs undoubtedly have a bright future. They’ll enable SOC teams to extend their surveillance to this area, which will soon represent a large proportion of any IS.

Examples of CASB publishers:

The new Swiss army knife for securing terminals: endpoint detection and response (EDR)

Endpoint Detection and Response (EDR) solutions are set to enhance SOC’s detection and response capabilities for terminals (PCs, servers, etc.).

As the name implies, EDRs play a part in detecting attacks. In fact, they are plugging the gaps in anti-virus solutions (and other HIPSs) which make use of specific attack signatures and are therefore unsuited to detecting certain attack types—in particular advanced attacks (APTs). EDRs are based on other detection methods, with publishers generally offering a combination of techniques commonly used elsewhere.

Among these techniques, a large number of solutions detect the exploitation of known vulnerabilities or attack patterns (the opening of suspicious ports to dubious addresses, etc.), the analysis of files using a sandbox (local emulation, submission in the cloud, etc.), and behavioral approaches based on Machine Learning (in particular UEBA solutions—see the dedicated chapter on this). Depending on the SOC’s needs, the alerts produced can be integrated as SIEM sources, or made available directly from the solution management console.

In addition to their advanced detection capabilities, EDR solutions also result in a considerable increase in visibility on devices: lists of processes and services launched, lists of files in certain system directories, as well as other information that facilitates investigation in cases where an alert is raised. Some solutions go beyond mere recovery of the state of the terminal at the time of the request, enabling its history to be recovered too: generation of logs, recovery of deleted files, etc.

But EDRs’ features don’t end at the detection and analysis phase. In fact, these solutions enable remote remediation actions to be performed, and the complexity of these depends on the publisher: deleting or quarantining files, ending processes, quarantining the terminal from the network, modifying registry keys, etc.

EDRs, thus, are comprehensive solutions that come into play at every stage of the process: from detection, through analysis, to response. However, they are not intended to replace anti-virus solutions: it’s always more effective to block known attacks, even though publishers are increasingly offering solutions that combine these two types of functionality.

For more details on EDR solutions, read our dedicated article here.

Examples of EDR publishers:

Protecting the keys to the kingdom: Active Directory supervision

Directories are among an IS’s most critical components. They provide the authentication and authorization functionality for almost all IS resources—both technical and business function—including the most critical ones. It’s therefore not surprising that compromising the AD is one of the most frequent attack methods used, since it opens numerous doors to an attacker.

Despite this criticality, and the fact that AD architectures are well known and have evolved little in recent years, their security has scope to improve. This is due, in particular, to their specific mode of operation (OUs, domains, trees, forests, users, etc.), which renders traditional protection and surveillance methods ineffective; a significant concern given that any vulnerability can represent a major risk for the rest of the IS.

AD surveillance solutions aim to overcome this problem by supervising (in real time, or during an audit) the specificities of directories (configuration, status of accounts, etc.) and detecting vulnerabilities that could result in them being compromised. To do this, AD supervision solutions have a highly detailed knowledge of how ADs function, and, in particular, the associated security issues.

When the solution detects a vulnerability, it raises an alert (via the SIEM, or directly) and can provide remediation advice to facilitate the work of the teams responsible for rectifying the problem.

AD supervision tools also enable the SOC to detect any changes in configuration (legitimate, accidental, or malicious) and continuously assure security levels for these critical components. In doing so, they make the task of numerous attackers decidedly more complex.

In addition to directly strengthening the AD’s security levels, such solutions can also be used to ensure compliance with standards or regulatory requirements (for example PCI DSS, etc.).

These solutions are not widely applied today, and their use is generally limited to one-off audits. However, given the considerable security improvements associated with the provision of detection and remediation advice, and their ease of use, such solutions have strong potential and are likely to find their place among the tools used by SOCs.

Examples of AD supervision publishers:

You can find our second article in the series here.

Cet article SOAR, UEBA, CASB, EDR and others: which tools do you need for you SOC? (1/3) 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.

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.

À quelles difficultés font face ces équipes au quotidien ? Comment rester efficace alors que les attaques des cybercriminels deviennent extrêmement élaborées ?

Le SIEM : un pilier du SOC… à condition d’être bien implémenté !

L’apparition d’outils comme le SIEM (Security Information and Event Management), il y a environ 10 ans, a permis aux équipes de sécurité opérationnelle d’industrialiser la surveillance en simplifiant l’analyse de multiples sources d’événements de sécurité (console antivirus, proxy, Web Application Firewall…). Cet outil a également rendu possible la corrélation de nombreux événements provenant d’équipements ou d’applications hétérogènes pour détecter des scenarii de menace avancés.

Cependant, la mise en place d’un SIEM doit être le résultat d’un projet ayant un investissement proportionnel à la complexité du système d’information surveillé. En effet, la pertinence d’un SIEM repose à la fois sur :

• La présence de contrôles contextualisés au système d’information (notamment au travers de l’exploitation de la sensibilité des assets surveillés).
• L’étude et l’implémentation de scénarii de menaces avancés et adaptés aux enjeux du métier de l’entreprise.

Concernant le périmètre de surveillance, les premiers équipements habituellement intégrés sont les équipements de sécurité car ils sont nativement configurés pour laisser des traces exploitables pour les équipes opérationnelles. Il est néanmoins souvent constaté que leur intégration se limite à une simple retranscription des contrôles déjà existants ; ce qui ne permet pas de tirer parti de la corrélation d’évènements proposé par un SIEM.

En revanche, l’intégration d’applications métiers est plus délicate en raison notamment des besoins différents entre les équipes métiers et sécurité : la principale préoccupation pour le métier se résume généralement à l’indisponibilité de son application (ou de certaines de ses fonctionnalités), alors que la sécurité adresse un éventail de risques plus complet, que ce soit de l’indisponibilité, de la compromission de l’intégrité de données ou encore de la fuite d’informations confidentielles.

Il s’avère donc primordial de sensibiliser les métiers aux enjeux sécurité dans leur ensemble pour pouvoir déterminer des scenarii de menace réalistes et propres à chaque périmètre. De plus, ces applications n’ont traditionnellement pas de fonctionnalités avancées en termes de sécurité. Par conséquent, il est difficile de disposer d’un système de surveillance efficace (configuration d’envoi de logs complexe, fichiers de logs très peu verbeux…).

De manière générale, l’implémentation trop simpliste de contrôles dans un SIEM rend l’activité du SOC inefficace. Les équipes de surveillance se voient alors noyées de « faux positifs » et les évènements de sécurité sont traités unitairement au lieu d’être analysés dans leur ensemble afin de détecter de réels scenarii de menace (par exemple : une authentification non autorisée sur un serveur puis la désactivation de son antivirus devra être traité comme un seul incident à investiguer).

Des équipes pas assez intégrées dans l’organisation de la sécurité

Outre les problématiques liées à une mauvaise implémentation du SIEM évoquées ci-dessus, on constate également des problématiques d’ordre organisationnel.

En effet, le SIEM est souvent perçu comme une « boîte noire » par les analystes de niveau 1 et 2 au sein des équipes du SOC. Cela est généralement dû à la méconnaissance des problématiques réelles de production (identification des assets critiques, des interactions entre les différents systèmes…). Les incidents détectés par le SIEM se retrouvent alors tous traités au même niveau sans aucune priorisation et identification en amont des éléments les plus sensibles.

Pour maintenir un niveau de compétence suffisant au sein des équipes de sécurité opérationnelle, de la veille technologique doit être réalisée par les investigateurs niveau 3 pour ensuite être communiquée aux analystes niveau 1 et 2. Des sujets tels que la présentation de nouveaux IOC (Indicator Of Compromise) venant compléter des règles de détection permettront aux équipes de gagner en efficacité dans leur manière d’appréhender les incidents. Ces types d’initiatives contribueront à l’amélioration continue du service en évitant sa dégradation dans le temps.

De plus, les équipes doivent participer en continu aux nombreuses initiatives sécurités initiées par la DSI tels que des projets de sécurisation des infrastructures ou applications. Par ailleurs, des exercices de gestion de crises doivent être organisés afin d’éprouver les différents processus et outils mis en place et de permettre aux interlocuteurs métiers et sécurité de pouvoir échanger sur leurs rôles respectifs en cas de crise.

Dans un contexte où la cybercriminalité ne cesse de se réinventer (comme le démontre l’attaque sur les systèmes Swift récente), les équipes opérationnelles sont de plus en plus sollicitées pour intégrer de nouveaux périmètres. Cette pression constante exercée notamment par les décideurs accentue les phénomènes de mauvaise implémentation des contrôles et de méconnaissance des scénarii de menace réels. Une bonne surveillance nécessite plus qu’un simple envoi de logs dans un SIEM ; les équipes projet doivent s’efforcer de respecter et faire respecter le processus complet d’intégration de nouveaux périmètres : identification des scénarii d’attaques, mise en place des mécanismes de collecte, création des règles de détection, tests et mise en production. L’oubli d’une de ces étapes risque de rendre la collecte des logs du périmètre inutile.

Quel avenir pour les SOC ?

De nombreux facteurs vont venir bouleverser l’écosystème des prestataires de la sécurité opérationnelle.

En effet, la LPM (Loi de Programmation Militaire) va exiger de tous les OIV (Opérateur d’Importance Vitale) de choisir des prestataires certifiés PDIS (Prestataires de Détection des Incidents de Sécurité), pour ceux qui font appel à de telles prestations externes. De nombreux prérequis seront nécessaires afin de pouvoir être certifié, tels que le cloisonnement des données des clients ou la mise en place de zones d’administrations (enclaves), uniquement accessible par le prestataire, par lesquelles les logs seront récupérés pour ensuite être transmis au SIEM. Ces facteurs vont entraîner de nombreux changements au sein des organisations et infrastructures mises en place actuellement.

Par ailleurs, la part grandissante du cloud dans les systèmes d’information des entreprises amène une nouvelle complexité : celle de la collecte des logs auprès des fournisseurs. De nouveaux acteurs sont donc apparus dans le marché de la sécurité : les CASB (Cloud Access Security Brokers). Leur promesse : répondre aux problématiques de sécurité pour le cloud. Ces entités se situent entre les utilisateurs et les divers services cloud et proposent de nouvelles briques de sécurité telles que l’utilisation d’API pour détecter directement des scenarii de menaces (création de fichiers de journalisation des accès aux applications, implémentation de ces données dans un SIEM…).

L’objectif de demain : gagner en maturité

La sécurité opérationnelle a encore de nombreux défis à relever. La plupart des entités assurent actuellement l’hygiène minimum du système d’information et la maturité des équipes leur permet de se prémunir des menaces diffuses (virus, spam…). Cependant, le dispositif actuel doit se renouveler afin de répondre aux nouveaux enjeux liés à la cybersécurité pour pouvoir lutter contre les menaces opportunistes (hacker isolé) et ciblées (cyber-mafia, gouvernement), plus complexes à détecter.

Dans ce contexte et face aux obligations légales, les SOC ont (et auront) un rôle très important à jouer nécessitant une expertise technique approfondie ainsi qu’une intégration avec la sécurité dans les projets.

Cet article Cybersécurité : l’heure du bilan pour les SOC est apparu en premier sur RiskInsight.

Beaucoup ont donc entamé au cours des 18 derniers mois un projet visant à exploiter les logs (ou journaux d’évènements) afin d’anticiper, détecter et diagnostiquer des actes malveillants.

L’objectif est ambitieux : on parle d’abord de log management, puis de corrélation des logs à l’aide d’un SIEM (security information and event management) . Quelle réalité derrière ces principes ? Comment les mettre en place ?

Étape 1 : centraliser les journaux

Une grande majorité de machines (équipements réseau, serveurs, postes de travail), bases de données ou applications d’un SI peuvent aujourd’hui générer des logs. Ces fichiers contiennent, pour chaque machine, la liste de tous évènements qui se sont déroulés : réussite ou échec d’une connexion utilisateur, redémarrage, saturation de la mémoire…

Pour les exploiter, il est possible de se connecter unitairement à chacun des équipements afin d’y observer l’historique. Cette tâche fastidieuse, encore souvent observée sur le terrain, est irréaliste sur des systèmes d’information complexes. Elle est par ailleurs inefficace pour prévenir un incident ou détecter les impacts en temps réel.

La construction d’un « puits de log » est une première brique de réponse : il s’agit de collecter, à l’aide d’un outil automatisé du marché, l’ensemble des journaux d’équipements dans un espace de stockage unique. L’un des critères de sélection de cet outil est justement sa capacité à reconnaître différents formats de logs (syslog, traps SNMP, formats propriétaires…).

Le volume d’information centralisée peut vite exploser : il est important d’éviter la collecte de données inutiles. Par ailleurs, le système peut également être gourmand en puissance de calcul en fonction des périmètres de recherches effectuées.

On parle de log management à partir du moment où les données contenues dans ce puits sont traitées et exploitées, par exemple pour retrouver un élément dangereux (virus, problème de sécurité…), ou un comportement malveillant (fuite d’information, suppression de données…). Il est nécessaire de cadrer en amont les finalités du projet,  qui peuvent être multiples :

• Vérifier que les règles du SI sont appliquées
• Détecter les attaques ou les utilisations frauduleuses du SI
• Permettre les analyses post-incidents (forensics)
• Répondre aux contraintes légales ou de conformité avec la capacité de fournir des éléments de preuve

Pour démarrer, une bonne pratique consiste à s’orienter principalement vers des logs de sécurité et réseau. Certaines applications métiers sensibles pourront ensuite être ajoutées.

Une fois l’espace de stockage cadré, l’archivage amène son lot de contraintes :

• D’un point de vue légal et réglementaire, il faut s’assurer de la licéité des traitements en fonction des informations archivées et de leurs durées de rétention. Une déclaration à la CNIL est à prévoir dans de nombreux cas.  En fonction de leur origine (e-mail, proxy, applications), les périodes de rétention ne sont pas soumises aux mêmes règles. À titre d’exemple, on considère aujourd’hui qu’une durée raisonnable pour l’historique des accès des utilisateurs à internet est de 12 mois.
• En fonction des traitements et du cadre juridique existant dans l’entreprise (par exemple charte incluant la surveillance…), les collaborateurs doivent potentiellement être informés des mesures mises en place. Dans ce cadre la mobilisation des ressources humaines et des instances représentatives du personnel sont à prévoir.
• La gestion des identités et des accès au puits de logs  est, enfin, un sujet crucial. Le volume et la sensibilité des informations qui y sont stockées nécessite d’identifier précisément les personnes habilitées à en faire usage, et de limiter strictement leurs droits au périmètre qui leur incombe. Toute modification des traces doit être interdite (même aux administrateurs),  afin que celles-ci puissent avoir une valeur probante le cas échéant.

Étape 2 : faciliter l’analyse, du SIEM au Big Data

Si des recherches manuelles sont toujours possibles dans un puits de logs, elles ne répondent qu’à un besoin précis et ponctuel.

Pour obtenir une analyse en temps réel avec des remontées d’alertes automatiques, il est nécessaire de passer à l’étape supérieure : le SIEM. Il s’agit à la fois d’une extension et d’une industrialisation de la première étape, souvent offerte par le même outil du marché.

Il s’agit ici de rechercher, à travers les traces, des liens entre des évènements unitaires ayant lieu sur différents éléments du SI, afin d’anticiper, bloquer (en temps réel) ou comprendre une action malveillante.  On parle alors de corrélation de logs.

Pour cela, il est important de définir les types de comportement anormaux à identifier. C’est la principale difficulté : un niveau de sensibilité trop élevé génèrera beaucoup d’alertes sans intérêt, tandis qu’un niveau trop faible ne permettra pas de lever les alertes pertinentes. Cette étape comporte donc une phase d’ajustement et apprentissage qui peut durer plusieurs mois.

Aujourd’hui le marché des SIEM se renouvelle : les solutions sont de plus en plus performantes, utilisent de nouvelles techniques de détection d’attaque, et exploitent de plus en plus la puissance de calcul du Cloud pour la corrélation d’évènements.

Le marché voit également arriver des outils utilisant les principes du Big Data. Plutôt que de rechercher des scénarios connus, l’idée est alors de détecter des anomalies statistiques dans la masse d’information. Cette approche séduisante doit encore être mise à l’épreuve du terrain.

 Ne pas négliger les aspects organisationnels

Enfin, il est nécessaire de s’assurer que les alertes seront traitées par les équipes compétentes. Les procédures et l’organisation associées doivent donc embarquer les équipes sécurité (SOC/CERT), réseau et système et le RSSI. Des réflexions autour de l’externalisation ou de l’internalisation de ces fonctions de surveillance et des liens avec les entités en charge de la gestion des incidents de sécurité sont également essentielles.

Cet article Surveillance sécurité : passer du puits de logs au SIEM (security information and event management) est apparu en premier sur RiskInsight.

Un apport des DLP complémentaire à la lutte contre l’intrusion et au contrôle d’accès

Une fuite d’information peut provenir de trois sources différentes. L’attaquant externe est souvent celui qui vient à l’esprit en premier. Cependant, l’expérience montre que ce sont les utilisateurs internes, autorisés ou non, qui font fuir le plus d’information.

Suivant la position de celui qui fait fuir l’information, trois grandes étapes peuvent être enchaînées : intrusion, accès à l’information, diffusion de l’information – dont la nécessité dépend des accès initiaux de l’acteur à l’origine de la fuite d’information. À chacune de ces étapes, des solutions de sécurité permettant de réduire le risque existent.

Il convient d’agir à toutes les étapes d’une fuite d’information en s’appuyant sur des mesures allant de la sécurité physique aux solutions de Digital Right Management (DRM), en passant par le chiffrement de flux, le cloisonnement, ou encore la gestion des accès et des habilitations…

Si de telles mesures sont déjà mises en œuvre, les outils de DLP permettent alors essentiellement de se prémunir contre des erreurs ou malveillances d’utilisateurs ayant un accès légitime à l’information. En ce sens, ils permettent d’apporter une protection au plus proche de la donnée.

Des solutions fonctionnellement matures

Les mécanismes de contrôle des DLP sont mis en œuvre à travers des règles ou politiques centralisées permettant d’analyser les traitements faits sur la donnée quelle que soit sa nature ou son support.

Grâce à des agents déployés sur le réseau et/ou sur les postes de travail, le DLP va pouvoir empêcher la copie d’un fichier sur un périphérique externe, l’envoi d’un document sensible par email, l’impression d’un document ou encore la publication d’une information confidentielle sur les réseaux sociaux.

Après analyse et filtrage des données par la solution DLP, différentes mesures de prévention peuvent être prises, avec un impact plus ou moins élevé pour l’utilisateur : alertes, demande de justification, blocage…

Enfin, il convient de noter que les acteurs du marché mettent de plus en plus l’accent sur le contexte d’utilisation de la donnée. Certains éditeurs proposent ainsi des fonctionnalités de gouvernance au sein de leur solution de DLP permettant par exemple de savoir exactement où se trouvent les données sensibles et qui y a accès.

Le marché des DLP est donc de plus en plus mature : la couverture fonctionnelle proposée est élevée et évolutive, la gestion de l’impact sur les collaborateurs de plus en plus souple. Néanmoins, les retours d’expérience restent limités par rapport à ce que l’on pourrait attendre.

La raison de ce paradoxe vient du fait que les métiers sont trop souvent insuffisamment impliqués dans les projets de DLP, alors même que ces projets n’ont que peu de chance d’aboutir sans eux, en particulier vu le volet RH nécessairement associé.

Adopter une approche par les résultats pour mobiliser les métiers

Il est illusoire de vouloir protéger toutes ses données dans tous les cas d’usage imaginables. Une approche purement technique visant un périmètre exhaustif n’a que peu de chance de convaincre, particulièrement dans la conjoncture économique actuelle.

Une approche par les résultats mêlant ciblage précis, démarche outillée, accompagnement et visibilité est donc à favoriser dès la sélection de la solution. Une fois les objectifs atteints sur un périmètre prioritaire, on peut envisager de l’élargir.

La première étape, primordiale, est donc la définition du périmètre prioritaire de données à protéger et des cas d’usage fonctionnels à traiter. Identifier les dix données les plus critiques, s’appuyer sur des situations fonctionnelles avérées, commencer par un nombre limités de supports pour réduire les aléas techniques sont autant de facteurs clés de succès.

La définition des processus de surveillance (politiques d’interaction avec les utilisateurs, processus en cas d’alerte…) ne doit également pas être négligée. Sur ce volet, et dès le début du projet, il est important de mobiliser les fonctions RH de l’entreprise pour valider le mode de mise en œuvre de la démarche DLP (alerte, blocage, journalisation…), construire les processus de gouvernance associés et au final envisager un passage devant les instances représentatives du personnel.

Lorsque le cadrage global du périmètre fonctionnel est effectivement achevé, la phase de sélection de la solution peut être entamée. Une démarche outillée impliquant la réalisation d’une maquette est indispensable pour s’assurer de l’adéquation de la solution aux cas d’usages fonctionnels identifiés et évaluer les résultats envisageables.

En cas de résultats satisfaisants, un déploiement progressif est à envisager avec un leitmotiv : la sensibilisation des utilisateurs.

Enfin, en mode récurrent, l’intégration à un SOC (Security Operation Center) peut permettre de bénéficier de la maturité de la gestion opérationnelle de la sécurité pour optimiser la surveillance d’une part et l’accompagnement et la visibilité fournis aux métiers d’autre part.

Cet article Le paradoxe des projets de Data Leak Prevention (DLP) : une problématique clé, des solutions matures… mais une mise en œuvre qui fait encore peur est apparu en premier sur RiskInsight.