Issues related to intellectual property laws and the source of data used to train LLMs, which is sometimes confidential or personal, as well as potential biases in the data, intentional or otherwise, are regularly debated in the press and within technology communities. However, the current focus is on the race between LLM providers, who are competing to develop faster, more efficient models, in search of the ‘wow’ factor that will temporarily propel them to the rank of global AI leader.

Meanwhile, organisations are integrating these technologies into their daily activities at their own pace. Implementation is driven both by employees keen to improve their individual productivity, often based on their experience using AI tools in their personal life, and by business leaders and managers, who see an opportunity to optimise efficiency of low-value-added tasks.

At OVHcloud, we have launched an ‘AI Labs’ initiative, which is responsible for centralising projects and experiments using LLM tools. This team now supervises over a hundred projects, and new ones are added every week. The approach aims to catalyse ideas and provide a framework for efficiently implementing effective production tools.

From a data security perspective, the proliferation of experimentation and proof-of-concept (POC) projects creates numerous additional risks that need consideration. Modelling interactions between each component is necessary to understand these risks, as many configurations are possible.

In this article we will take a look at some example use cases, identify the main risks and provide suggestions for how to address them using a risk reduction logic model. We will focus on simple use cases where a user accesses an application for their work. These applications are accessible from their work context, and each have access management mechanisms that verify the user and grant them access to the relevant data and functions associated with their business profile.

The introduction of LLM technologies fits into the usual operating mode of an information system to enrich the user experience and offer additional features. Let’s take a look at the examples.

Conversational agents (without third-party integration)

Most professionals working on a computer regularly use conversational agents to ‘enhance’ their work, often without acknowledging it, for example when writing an email, summarising a document, finding a complex Excel formula, answering a legal or technical question, etc.). As these agents are not connected to the company’s information system,  the risks are limited and depend on the attitude and practices of the user, for example with regards to uploading data, copying and pasting confidential data into the agent, etc.

In this context, the user is the go-between managing the information transfer between the company application and the third-party agent. The agent only has access to information voluntarily sent by the user, typically via the service interface that allows prompts to be entered. These services are rapidly extending their capabilities, allowing file upload, and microphone or camera access, but we remain in a classic responsibility framework in terms of security, with the human in the loop by design.

Examples

• Public AI services (Mistral, Openai, Grok, Omissimo, etc.)
• AI services contracted by the company from public service publishers or specialised players
• Internal chatbot

Associated security risks

• Sending sensitive data (documents, confidential data, personal data, etc.) to the AI service and losing control over this data.
• Training models on confidential data sent by users, which can lead to leaking this data to a user who should not have access to it.

Measures to implement

• User awareness
• AI charter
• Blocking services accessible from the company’s information system
• Contract with suppliers including security and confidentiality clauses for user-transmitted information
• Traffic inspection and identification of confidential data using regular expressions
• Dedicated instance for the company, fine-tuned or enriched by a RAG with company data (not very sensitive), allowing the LLM to be contextualised to the user’s context.

“AI Augmented” Application

The various editor solutions, in SaaS or deployed internally, are gradually enriched with functions based on LLMs, i.e. an agent on the application side that consumes an LLM with prompts designed by the editor on the data processed by the application. The editor enriches its solution within its own security model. On the user side, there is no change in usage, the application is simply enriched with new functions, for example synthesis, intelligent suggestions, translation, etc.). LLM processing can be done locally or consumed on external services.

In this use case, the publisher or application manager is responsible for data security and processing via the LLM; the user has no control and the use of these features is integrated into their usual usage. We remain in a classic security management framework, the application manager (internal or external) is the guarantor of the security of the data they process in the application. The application is enriched with new features and complexity increases, but the security model is preserved.

Examples

• Messaging and video conferencing service with AI features, for example real-time translation, discussion synthesis, automatic meeting minutes etc.
• Any ‘AI wizards’  in SaaS application

Associated security risks

• Insufficient segmentation of access rights to data in the application, allowing bypassing of usual application access controls. This is the case when the agent has a high-privilege account (to simplify and accelerate the development of features) or when access restriction is not implemented at data level.
• Prompt injection into the application
• Dependence on an uncontrolled supply chain
• Data leakage to a subcontractor

Measures to implement

• Security clauses in contracts
• Security insurance plan for application provider
• Review of subcontractor dependency chains
• Disabling unnecessary AI functions
• Deep isolation of sensitive applications

Agentic IA

We will now look at actual ‘Agentic AI’. In these cases, the agent is at the centre of the workflow. The agent becomes an orchestrator of resources. It has several roles, in particular:

• Capturing user expectations and triggering the sequence of actions
• Retrieving the necessary data to contextualise and process the request
• Sending data and instructions to a LLM to find the sequence of actions to be performed
• Managing iterations with available services and LLMs to best handle the request
• Triggering actions on accessible services
• Obtaining (eventually) user validation to validate actions
• Providing visibility to the user on actions performed and results obtained

To properly understand the risks, it is necessary to look at different types of agent implementations.

Agents integrated into local applications

Applications are gradually being enriched with the ability to connect to an LLM service. Generally, this is done via APIs to LLM services or locally on the machine. In this case, the application will integrate an agent and incorporate its use into the usual application experience. The framework is equivalent to that of an enriched SaaS application, but the configuration and calls to the LLM are made from the user’s workstation. The functionality can be native or installed in the form of a plugin.

Examples

• Microsoft Copilot AI agent
• AI function in office applications (OnlyOffice, Joplin, email client, etc.)
• Apple intelligence

Associated security risks

• Loss of control over data processed by adding connectivity functions to third-party services (be careful with default tool configurations)
• Risks are similar to “cloud” functions in applications, allowing cloud storage or sharing, often configured by default
• Leakage of LLM authentication secrets (Bearer Token)

Measures to implement

• User awareness
• Application configuration controls
• Validation of applications on workstations and smartphones
• Monitoring and inspection of network and application flows
• Local management of secrets

Generalist or Specialized Local Agents

Unlike the previous use case where the application is simply enriched with LLM functions, agents are applications whose primary goal is to integrate LLM functions into a workflow. The risk model is similar, but by nature, the functionalities are much richer and focused on optimising the consumption of LLM services. For example:

• Configuration of multiple LLM services in parallel
• Personalisation of system and user prompt templates by the user
• Integration of local or remote MCP services to enrich the data accessible to the agent
• Cost control function
• Optimisation of requests and context management

These agents can be generalist or specialised. In particular, this type of agent is widely used by developers within their IDE . In this context, security management relies on the user and the local configuration of tools. Capabilities may be extended with marketplace, like plugins to add connectors to external services or capabilities. The complexity of configurations, the lack of proven and hardened standards due to the relative novelty of these tools generates many risks, on an application directly run on user workstation, with all their rights.

Examples

• Generalist agents: Goose
• Specialised agents: Claude desktop, Cursor, Shai, Github Copilot, Continue, Kilo Code

Associated security risks

• Connection to third-party services without controls via marketplace (MCP connector for third-party services)
• Uncontrolled access to local file system
• Sending confidential data to third-party services (business data, secrets, .env file, etc.)
• Management of local secrets (Bearer token)
• Sharing credentials with third-party services (via OAuth mandate, etc.)

Measures to implement

• User awareness
• Application configuration controls
• Software testing and validation
• Sandboxing of agents
• Protection of secrets (environment file in development directories)

Remote Agents

Remote agents, like local agents, are applications that connect different resources (LLM, RAG, third-party services), packaged within a web application, accessible to the user through their browser. All chatbot services are gradually integrating these capabilities to enrich their service by connecting to third-party services. The operation is similar to local agents, but outside the user’s workstation.

In this case, the main challenge is managing access to third-party services and the resulting secrets. Since the agent is the focal point of the architecture, entrusting its management to a third party requires granting them access rights to third-party services to capitalise on the agent’s functionality.

In the example above, the user must grant the agent an access mandate to consume the MCPs that allow access to application services. Today, most of these mandates are managed by OAuth2 delegations, with the user authorising the agent to use these technical delegations to access applications.

Examples

• ChatGPT, MistralAI
• Agents deployed internally

Associated security risks

• Leakage of authentication secrets to sensitive applications of data
• Centralisation of secrets to access remote services
• Opening of network flows between sensitive applications and agent services

Measures to implement

• Architecture to limit network exposure
• Network inspection
• Application monitoring
• Authorisation and access control management
• Restriction of access rights to need-to-know for each task

Workflow agents

Workflow agent tools are designed to build AI workflows. They may be local or remote. While all wrong behaviours listed above remain possible in this model, the workflow structure  splits the workflow into small manageable parts, allowing:

• Limit of each agent’s access rights to the required sub-set of data for performing its tasks
• More deterministic approach for human control over the process
• Unitary testing for each parts
• Repeatability of the process (workflows are defined ‘as code’)

In this case, the workflow is built and operates as an automation under the control of a project team in charge of aligning the workflow with business processes. The configuration of the workflow management tools is the key to controlling the process. The orchestration platform manages the secrets and flow to resources, so it need to be managed with proper attention as any orchestration platform.

Examples

• N8N, Langchain, Zapier, Flowise AI

Associated security risks

• Increase in complexity of the workflows and interconnection
• Configuration issues
• Leak of access token
• Exposure of sensitive resources
• Shadow orchestration platforms deployed by users
• Access to temporary artifacts by platform administrators

Measures to be implemented

• Architecture to limit network exposure
• Network inspection
• Application monitoring
• Authorisation and access control management
• Secrets management
• Restriction of access rights to need-to-know for each task

Perspectives and problems to be solved

MCP and secret management

Secret management is at the heart of the problem of deploying agent-based AI. Since LLMs are not deterministic, it is necessary to constrain access rights in terms of scope and duration for LLMs, in order to limit their access to only the data and functions required to perform tasks. It is essential to identify the reliable blocks that will act as intermediaries to grant access, particularly for MCP servers. One of the challenges is to rely on existing access rights matrices without re-implementing an additional layer of rights management for MCP servers and agents, but instead implementing mechanisms to limit access dynamically as needed.

Existing or emerging standards (OAuth2, JWT, SAML, SPIFFE/SPIRE, OPA, Cedar, etc.) partially address some of these challenges, but at the cost of high management complexity, without a reference implementation compatible with all current solutions, and in a rapidly evolving market.

Human in the loop

Beyond secret management, LLMs are unpredictable because they are non-deterministic. One of the questions to be resolved is how to include humans in the decision-making chain of an agent-based process to ensure that this inherently unpredictable behaviour does not generate risks for organisations. Today, this control, known as ‘human in the loop’, is based on the agent’s internal mechanisms and the limitation of secrets shared with it by the user. Obviously, this mode of operation is not compatible with sensitive processing.

In the future, it will be necessary to build agents that offer a high level of trust, provided by trusted editors or communities, auditable and audited, ideally open-source, to entrust these agents with performing operations on a company’s information system. In parallel, it will be necessary to develop independent agent control mechanisms that ensure sandboxing, filtering, access management, and traceability functions, allowing the responsible user to master their interaction with the information system.

Towards the end of the web browser as a access vector to the information system

For about 15 years, the web browser has been the user’s entry point to information systems. While the functional richness of browsers is immense, the attack surface they expose is just as great. Browser security, even if it is perfectible, is one of the pillars of modern security, and browser editors and communities devote a significant part of their development and maintenance efforts to maintaining the level of security and managing threats.

AI agents are changing this access paradigm to the information system by providing users with dynamic and adaptive interfaces, enriched with high-value contextual functions, which is already causing a revolution in usage and the daily lives of users. It is likely that tomorrow’s browser will be an AI agent, and even more likely that current browsers will gradually become AI agents, integrating all identity and authorisation management standards under user control.

The story of this backdoor deserves a deep analysis which is out of topic here, but it raises a lot of questions for open-source communities and all the IT sector.

What systems are impacted?

Since the vulnerability has been detected in a relatively short time, no major distribution has already integrated those versions of the XZ library.

Only the distributions with a very fast pace of software integration (Rolling releases, testing, so-called “unstable”) had integrated the corrupted version at detection time.

As an OVHcloud customers, what are the risks?

No Linux image provided by OVHcloud to customers for automated installation are impacted. So no customer should be vulnerable to this backdoor using images provided by OVHcloud.

In some corner cases, the backdoor might have been installed on your system:

• If you installed a vulnerable distribution yourself, in the timespan where the compromission was not yet discovered, outside of the OVHcloud automated installation process (for instance, Linux distribution in “rolling release” mode)

• If you activated edge repositories on your system (for instance, “experimental”, “unstable” or “testing” for Debian, “edge” for Alpine, “update-proposed” for Ubuntu)

• If you installed a software that is  packaging the vulnerable version of the library

• If you use an alternative package manager (for instance Homebrew)

The backdoor is quite complex, so even in such case, you might have deployed the corrupted version of the XZ library, without your system being actually vulnerable. Refer to your distribution/software security advisory page to get more information.

How can I check if I use a backdoored version of the library?

Check your active version of XZ library:

debian@lab:~$ strings `which xz` | grep "(XZ Utils)"
xz (XZ Utils) 5.2.5

Note: The command “xz -V” would provide a similar output. However, It is not a good practice to execute a binary that might be compromised.

Ensure the active version of XZ library is not part of the known vulnerable ones (5.6.0 and 5.6.1). If you have a compromised version of XZ, follow the security recommendations from your distribution. In some cases, a patch has been released to correct the vulnerability, in other cases, backporting to an older version of the library is recommended.

In any case apply the following recommendations:

• Reduce the exposure of administration interfaces of your server, filter at network level what source IP is allowed to connect to SSH.

• Use a bastion to connect to your server for administration (for instance: https://github.com/ovh/the-bastion)

• Perform regular backup of your data and system configurations, and regularly test your ability to rebuild your service from backups

External references:

https://www.openwall.com/lists/oss-security/2024/03/29/4

https://www.cisa.gov/news-events/alerts/2024/03/29/reported-supply-chain-compromise-affecting-xz-utils-data-compression-library-cve-2024-3094

https://lists.debian.org/debian-security-announce/2024/msg00057.html

https://news.opensuse.org/2024/03/29/xz-backdoor/

https://access.redhat.com/security/cve/CVE-2024-3094#cve-cvss-v3

https://archlinux.org/news/the-xz-package-has-been-backdoored/

https://boehs.org/node/everything-i-know-about-the-xz-backdoor

https://gynvael.coldwind.pl/?lang=en&id=782

https://www.wiz.io/blog/cve-2024-3094-critical-rce-vulnerability-found-in-xz-utils

https://research.swtch.com/xz-timeline

All AMD Zen2 CPUs, including EPYC Rome processors, are vulnerable:

• AMD Ryzen 3000 Series Processors
• AMD Ryzen PRO 3000 Series Processors
• AMD Ryzen Threadripper 3000 Series Processors
• AMD Ryzen 4000 Series Processors with Radeon Graphics
• AMD Ryzen PRO 4000 Series Processors
• AMD Ryzen 5000 Series Processors with Radeon Graphics
• AMD Ryzen 7020 Series Processors with Radeon Graphics
• 2nd Gen AMD EPYC “Rome” Processors

Impacts on OVHcloud products

In response to that event, we immediately reviewed the security bulletin and technical information and determined the following potential impact on our products.

How to mitigate the vulnerability:

Customer-initiated mitigation

Loading a patched microcode at boot with a firmware package update

This solution will trigger the update of the processor microcode through an operating system update (the linux-firmware package for instance). You might do it as soon your OS editor or community distribute the updated package. This method is dependent on your distribution or Operating system editor and will only work if the appropriate microcode has been provided by AMD. As of today, only “Zen2 Rome” and “Zen2 Castle Peak” are covered by this method.

Mitigation with an updated Kernel

When an update of the microcode is not available via a firmware update package, you may update the Kernel with a version that implements a mitigation by configuring a so-called “chicken bit” to deactivate the faulty processor feature. It might impact the performance of the system. This solution will be included by OS editors when they backport a new version of the Linux kernel. We recommend our customers to follow this mitigation strategy in priority since it is the most efficient as it doesn’t depend on whether an updated microcode is provided by the hardware vendor.

As an alternative, you might set the chicken bit manually without relying on the kernel update. However, we do not recommend this solution that may be risky for your system.

OVHcloud-initiated mitigation

OVHcloud teams are working to implement transparent solutions that will ensure the patched microcode is updated in a transparent way for our customers. Those solutions will be deployed progressively on our servers. Two main options are being evaluated.

Using OVHcloud iPXE

The microcode update may be loaded by the bootloader when the standard OVHcloud netboot is used by customers (the most common configuration). Once it is available, rebooting the server through the OVHcloud customer interface will cause it to load the updated microcode before booting to disk, which will mitigate the vulnerability. However, if you’re booting on disk without using the OVHcloud netboot system, the mitigation will not be applied and you should consider relying on the Operating-System-level mitigation.

Using UEFI

The UEFI firmware update may update the CPU microcode at boot. UEFI firmware updates including the patched microcode will likely be made available by motherboard manufacturers within the next months. Once available, OVHcloud will include this patched microcode on the UEFI for any new delivered server. Customers will then be able to request an UEFI firmware update by contacting the support.

As an administrator of a potentially vulnerable server, what should I do?

The first action is to check if your server is impacted by the vulnerability using the following tool (Linux-only) developed by our team:

# wget https://raw.githubusercontent.com/speed47/spectre-meltdown-checker/master/spectre-meltdown-checker.sh
# sh spectre-meltdown-checker.sh --variant zenbleed --explain

If the tool says “NOT VULNERABLE”, then you are already safe and no further action is needed.

If the tool says “VULNERABLE”, you should then evaluate your exposition to the threat.

It is necessary to determine if the server context allows to run code from an untrusted origin. If the server is used to provide services to untrusted end-users that can execute code (VPS, Container, mutualized hosting, etc.), or is used as a desktop in the cloud browsing the Web (hence possibly running 3rd party Javascript payloads), then your server might be at risk. If the server is used only by trusted users and/or does not allow to run untrusted code, the risk of exploitation is probably quite low. Please note however that this vulnerability might allow an attacker to gain extra privilege in a chained attack, it could be used for persistence or lateral movement in a complex kill chain.

Based on this evaluation, you should determine the emergency to trigger a mitigation and choose the most appropriate one.

What OVHcloud is working on:

Our technical and support teams are working to ensure the risk is lowered for every of our customer impacted by the vulnerability. We mostly focus on:

• Informing impacted customers to ensure they take the risk into account in their operations and implement mitigation appropriately
• Developing and integrating updates in our automation to cover the risk in a transparent way for our customers.
• Security watch of the vulnerability exploitation in the wild to define the appropriate extra mitigations we can implement to protect our customer infrastructures

External references

https://www.amd.com/en/resources/product-security/bulletin/amd-sb-7008.html

https://lock.cmpxchg8b.com/zenbleed.html

https://www.openwall.com/lists/oss-security/2023/07/24/1

https://github.com/torvalds/linux/commit/522b1d69219d8f083173819fde04f994aa051a98

https://github.com/speed47/spectre-meltdown-checker/

https://lists.debian.org/debian-security-announce/2023/msg00151.html

https://packages.debian.org/bullseye/amd64/amd64-microcode

https://ubuntu.com/security/CVE-2023-20593

https://almalinux.org/fr/blog/zenbleed-patch-call-for-testing/

https://access.redhat.com/security/cve/cve-2023-20593

https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/commit/amd-ucode?id=0bc3126c9cfa0b8c761483215c25382f831a7c6f

https://github.com/google/security-research/tree/master/pocs/cpus/zenbleed

These attacks are detected globally. According to experts from the ecosystem as well as authorities, the malware is probably using CVE-2021-21974 as compromission vector. Investigation are still ongoing to confirm those assumptions.

Our technical teams are working to identify the detailed characteristics of the attack all the while coordinating with our peers from other CERTs and security teams.

Update 07/02/2023

We continue our investigations and to provide support to our customers.
We prioritize our efforts:

• to identify our impacted customers on our networks to provide the most accurate and appropriate information to help them to recover from the attack.
• to identify potentially vulnerable customers to ensure they mitigate the risks appropriately as soon as possible in the case of on an other wave of similar attack.

Several security researchers may have found a link between the Babuk Ransomware source code leaked in September 2021. The encryption cipher (Sosemanuk) is used in the both cases but the code structure seems to be slightly different.

In addition to the recovery procedure described earlier, we noted that the encryption process is only impacting a small amount of data within the file. Depending of your VM OS and file system type, you might be able to recover data with data revery tools, at least partially. Be carefull, this tools might have irreversible action on the file so, We recommend to copy the VM files on an other location to protect the data before trying any recovery operation.

We are referencing a list of companies that can assist you to recover your data and reconstruct your systems. The list of companies will be available at OVHcloud support.

We also remind to our customers acting as Data Controller that they might have legal requirements to notify autorities in case of security incident. Ensure you declared the incident to the appropriate autorities within the right timeframe.
You will find below the Data Protection Autorities procedures for databreach violation for mainly impacted countries and CERT websites as well. Check with your legal department or counsel to ensure you notify the right organisation according to your status.

For PII data controllers:

• France: https://www.cnil.fr/fr/notifier-une-violation-de-donnees-personnelles
• Italy: https://servizi.gpdp.it/databreach/s/
• Belgium: https://www.autoriteprotectiondonnees.be/professionnel/actions/fuites-de-donnees-personnelles
• Spain: https://www.aepd.es/es/derechos-y-deberes/cumple-tus-deberes/medidas-de-cumplimiento/brechas-de-datos-personales-notificacion
• Poland : https://uodo.gov.pl/pl/501/2278
• UK: https://ico.org.uk/for-organisations/report-a-breach/
• Germany: https://formulare.bfdi.bund.de/lip/form/display.do?%24context=E72B6A6366642AE42118
• Portugal: https://www.cnpd.pt/databreach/
• Quebec: https://www.cai.gouv.qc.ca/incident-de-confidentialite-impliquant-des-renseignements-personnels/aviser-commission-et-personnes/

CERT:

• France: https://www.cert.ssi.gouv.fr/les-bons-reflexes-en-cas-dintrusion-sur-un-systeme-dinformation/
• Italy: https://cert-agid.gov.it/contatti/
• Belgium : https://www.cert.be/fr/signaler-un-incident
• Spain: https://www.ccn-cert.cni.es/gestion-de-incidentes/notificacion-de-incidentes.html
• Poland: https://incydent.cert.pl/#!/lang=en
• UK: https://report.ncsc.gov.uk/
• Canada: https://www.cyber.gc.ca/en/incident-management
• Germany: https://www.bsi.bund.de/DE/Themen/Unternehmen-und-Organisationen/Cyber-Sicherheitslage/Reaktion/CERT-Bund/Kontakt/kontakt_node.html
• Portugal: https://www.cncs.gov.pt/pt/certpt/

Additionnal references:
https://www.bleepingcomputer.com/news/security/
https://www.bleepingcomputer.com/forums/t/782193/esxi-ransomware-help-and-support-topic-esxiargs-args-extension/massive-esxiargs-ransomware-attack-targets-vmware-esxi-servers-worldwide/
https://blogs.vmware.com/security/2023/02/83330.html
https://members.loria.fr/MMinier/static/papers/sosemanuk_08.pdf

Update on 05/02/2023

We continue to work on the technical analysis in coordination with authorities and security community to determine IOCs and understand how the malware is behaving after the initial compromission.

So far we identified the following behavior:

• The compromission vector is confirmed to use a OpenSLP vulnerability that might be CVE-2021-21974 (still to be confirmed). The logs actually show the user dcui as involved in the compromission process.
• Encryption is using a public key deployed by the malware in /tmp/public.pem
• The encryption process is specifically targeting virtual machines files (“.vmdk”, “.vmx”, “.vmxf”, “.vmsd”, “.vmsn”, “.vswp”, “.vmss”, “.nvram”,”*.vmem”)
• The malware tries to shutdown virtual machines by killing the VMX process to unlock the files. This function is not systematically working as expected resulting in files remaining locked.
• The malware creates argsfile to store arguments passed to the encrypt binary (number of MB to skip, number of MB in encryption block, file size)
• No data exfiltration occurred.

In some cases, encryption of files may partially fail, allowing to recover data. Enes Sönmez (@enes_dev), a turkish security researcher has documented the procedure for recovery of VMDK files. The procedure is described on his blog (https://enes.dev/). We tested this procedure as well as many security experts with success on several impacted servers. The success rate is about 2/3. Be aware that following this procedure requires strong skills on ESXi environnements. Use it at your own risk and seek the help of experts to assist.

In the previous version of the post, we made the assumption the attack was linked to the Nevada Ransomware which was a mistake. No material can lead us to attribute this attack to any group. Attribution is never easy and we leave security researchers to make their own conclusions.

ESXi OS can only be installed on bare metal servers. We launched several initiatives to identify vulnerable servers, based on our automation logs to detect ESXI installation by our customers.
We have limited means of action since we have no logical access to our customer servers. For identified bare metal hosts:

• We sent emails on Friday’s afternoon to warn customer of the risk and provide them information on to mitigate the risk
• We blocked the OpenSLP port (427) between internet and the servers with ESXI installed. Customer can deactivate the filtering rule in their management interface if the use of port 427 is required for whatever reason.

We launched scan to identify compromised hosts, by testing the presence of the web page and/or the ssh banner specifying the host has been compromised to notify impacted customers.

Our support team is fully mobilized to help our customers to protect their systems and to help them to recover if they are impacted by the attack.

Additionnal references:
https://www.cert.ssi.gouv.fr/alerte/CERTFR-2023-ALE-015/
https://enes.dev/
https://straightblast.medium.com/my-poc-walkthrough-for-cve-2021-21974-a266bcad14b9

First response action items on 03/02/2023

The attack is primarily targetting ESXi servers in version before 7.0 U3i, apparently through the OpenSLP port (427).

To check your version of ESXi, please refer to your server page in your customer interface to identify wich version has been deployed on the server or to the ESXi interface on the system itself.

So far, we can identify the following recommendations regarding our services:

For Bare Metal customer using ESX-i we strongly recommend in emergency :

• to deactivate the OpenSLP service on the server or to restrict access to only trusted IP addresses (https://kb.vmware.com/s/article/76372)
• to upgrade you ESXi on the latest security patch

In a second time, ensure:

• your data are backed up (on immutable storage?)
• only necessary services are active and filtered with ACL to only trusted IP adresse
• monitor your system for any abnormal behaviour.

Our clients using VMware Private Cloud are not impacted. By design, the SSL gateway prevent this typology of attack by blocking the external access to this port (OpenSLP 427). 

For our Public Cloud customers, there is no dependency to ESXi so no risk are identified.

No other product among OVHcloud’s portfolio is threatened by this ransomware campaign.

We will update this blog post with any information that could help to reduce the risk associated with this threat.

Additionnal references:

• https://kb.vmware.com/s/article/76372
• https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-21974

Update 22/12: 2 new vulnerabilities have been identify. Those vulnerabilities are also impacting the initial patchs (2.15.0 and 2.16.0):

• CVE-2021-45105 : Risk of Denial of Service (DOS)
• CVE-2021-45046 : Risk of information leak and remote code execution in some environments and local code execution in all environments

Update 22/12: Updated table assessing the risks at OVHcloud products:

On December 10th, a group of security researchers published a security notice regarding a vulnerability in Log4j, referenced as CVE-2021-44228. This vulnerability has been named “Log4Shell” since it leverages remote code execution through a log entry on a targeted system which enables the attacker to gain remote access to the system.

Log4j is an open-source project that delivers a library used in Java environments to manage logging activities. Log4j is not the default logging library of Java, but since it provides developers a set of interesting logging features accessible directly in the code, the library is widely used in production systems and embedded in a very large number of off-the-shelve software solutions. Unless you are a Java developer you might never have heard about it but it is safe to bet that we will discover within the next few months that this library is used in a lot of unsuspected places.

The vulnerability is linked to JNDI (Java Naming and Directory Interface). JNDI allows to implement within the logs a variable that can be used to request an external resource, accessible over the network. While it might be convenient for a lot of use cases to enrich logs with external information, this feature also allows to execute code locally with the same rights than the application calling it. The attack protocol widely observed consists in injecting a variable within the logs which includes an URI to a java object served by a LDAP server. If you control the LDAP server, you may execute arbitrary code on the target. Log4j vulnerable versions are 2.0.X to 2.14.x.

As of today, we observed that the vulnerability is used to deploy malware used to mine crypto-currencies. However, since the exploitation is simple, we have all reasons to believe the vulnerability is used to leverage other types of attacks. There are many realistic scenarios you should consider, including ransomware deployment, exfiltration of data or pivot to other systems.

Update 22/12: 2 new vulnerabilities have been identify. Those vulnerabilities are also impacting the initial patchs (2.15.0 and 2.16.0):

• CVE-2021-45105 : Risk of Denial of Service (DOS)
• CVE-2021-45046 : Risk of information leak and remote code execution in some environments and local code execution in all environments

The right versions of Log4J to use are 2.17.0 (java 8), 2.12.3 (Java 7) and 2.3.1 (Java 6). Those 3 versions are correcting the 3 vulnerabilities.

How to identify vulnerable systems?

Identifying your vulnerable systems will be a complicated task, and you should structure your investigation approach to lower the risks in a prioritized way.

Publicly exposed systems check

You should start immediately to investigate all systems with a public IP address. Any vulnerable systems directly exposed to internet is at high risk. Even if your application is not written in Java, it might use some Java components using Log4j. Consider every behavior that might generate a log entry in your applications. Focus first on everything that is logged pre-authentication, like HTTP requests or login form. When done, dive into the post-authentication behaviors especially on systems where you cannot trust every user.

In-house developed applications crawling

When you have access to the source code, look in your code repository to identify precisely where log4j library is included in the code. By doing it you might even identify what types of logs are used and what are the attack entry points. If your organization is managing a very large number of projects in Java, it might be a good idea to look for the string “import org.apache.log4j“  in your code repository. You will see very quickly all the applications using the library. It will help you to narrow the search in the emergency phase.

Operating systems level check

Having a vulnerable version of log4j installed on your system does not mean your server is vulnerable since it must be used by a legitimate application to trigger the vulnerability. Log4j is included in most Linux distribution package management system, so if your SysAdmins are not following a strict hardening policy and a very strict software control on systems, you might have the package installed. Checking the presence and the version of log4j on all your systems is a reasonable check to do. The library can be installed manually or can be packaged within an application, so check for any jar file including “log4j” in the file name on your systems, it may help you to measure how this library is used and identify some systems you need to closely work on.

Open-Source and off-the-shelve software

Checking the security announcement pages of the software editors should be next on your list. Community and security researchers are also publishing web pages to track applications packaging a vulnerable version of Log4j. It’s neither perfect nor exhaustive but it will help you spot Log4j presence on your systems. As you may expect, the information from editors is not always sufficiently detailed to know exactly if you are at risk, but it will help you to identify some area for further investigations.

Other systems

Finally, for all the other pieces of software or devices with no active community to track the issue, you unfortunately have no easy way to determine if the systems is vulnerable. Any black box system might use a vulnerable version of Log4j without any way for you to find out. This is a scary perspective for a lot of security incidents to come.

Damage control recommendations

As you may start to understand, Log4shell will be a burden for all IT people in the coming days, months, and years. It’s quite probable that some security researchers will identify new vulnerabilities of the same kind and new attack protocols soon. So, we recommend working on safety hygiene to lower the risks and you shall consider the following best practices:

• Patch, patch, patch and re-check that you patched everything
• Maintain an up-to-date inventory of all software assets
• Implement a security watch to monitor new attack vectors and editor’s announcements
• Segregate your systems to narrow the impacted scope in case of successful attack
• Run your applications under unprivileged user accounts when possible
• Block any egress connection from your servers to external untrusted resources
• Avoid any unnecessary secrets and credentials on production servers
• Block IP and domain names that are known to host payloads for Log4Shell attack
• Implement WAF and filtering to drop all requests including attack pattern (starting with the string “jndi” is a good start)
• Monitor the logs of your systems to detect any abnormal behavior and egress connections
• Backup your systems and perform regular recovery tests

Assessing the risks at OVHcloud

At OVHcloud, as soon as the vulnerability has been published, we started to launch investigations to identify vulnerable systems and started to push patch or mitigation. We have been facing 3 different cases:

• The vulnerability is present on our customer systems under their responsibility. We have no means to detect the vulnerability since we do not access our customer systems. We invite our customers to follow the recommendations above as soon as possible.
• The vulnerability is present on a production system used in support for production of the product and service we provide to customers. Those systems are our top priority and we put most of our efforts on those systems.
• The vulnerability is present on internal systems, but not publicly exposed and not directly in support of our services. We prioritize the treatment of those systems taking into account their criticality and information we receive from editors.

We continue to investigate our systems for vulnerable Log4j library. The actual status of our investigations is detailed below and will be updated if necessary.

Product	Investigation results	Update 22/12 CVE-2021-45105 CVE-2021-45046	Recommendation	Status
Dedicated Servers	No vulnerable version of Log4j is used in support of these products.	N/A	We invite our customers to perform a deep review of their servers configurations following the above guidelines.
Storage and Backups	No vulnerable version of Log4j is used in support of these products.	N/A	N/A
Nutanix	Several Nutanix products are impacted by the vulnerability. Platform delivered by OVHcloud might be vulnerable. OVHcloud has no mean to check the platform since we do not have access to the infrastructure once delivered. Mitigation have been implemented in collaboration with customers to restrict exposition at network level.	N/A	We recommend to our customers to follow editors recommendations on their Nutanix infrastructure (See link below) We invite our customers to perform a deep review of their virtual machines configurations following the above guidelines. We also recommend to limit network exposition of vulnerable services.
Logs Data Platform	This platform was using a vulnerable version of Log4j. All vulnerable versions have been patched.	All customers instances have been patched with 2.17.0 version of Log4J	N/A
Hosted Private Cloud powered by VMware	Several VMware products are impacted by the vulnerability. No patch is available, however VMware published workarounds for each impacted products. We are deploying the workarounds over our infrastructure. Those workarounds might have impact on production systems, so we are deploying them according to our change management process. By default, access to administration interfaces is restricted to IP addresses defined by the customer. The exposition of vulnerable systems is consequently very limited.	Workarounds for the new vulnerabilities are being deployed.	We invite our customers to perform a deep review of their virtual machines configurations following the above guidelines. We recommend to our customers to ensure the Access Control List is limited to trusted IP addresses only.
Veeam, Zerto	No vulnerable version of Log4j is used in support of these products.	N/A	N/A
Hosted Private Cloud powered by Anthos	No vulnerable version of Log4j is used in support of these products.	N/A	N/A
Public Cloud Instance, Object storage, Block storage, VPS	No vulnerable version of Log4j is used in support of these products.	N/A	We invite our customers to perform a deep review of their instance’s configurations following the above guidelines.
Containers & Orchestration	No vulnerable version of Log4j is used in support of these products.	N/A	We invite our customers to perform a deep review of their containers configurations following the above guidelines.
Collaborative solutions (Exchange, Email pro, MXplan, Sharepoint)	No vulnerable version of Log4j is used in support of these products.	N/A	N/A
Cloud Databases	No vulnerable version of Log4j is used in support of these products.	N/A	N/A
Web Hosting	No vulnerable version of Log4j is used in support of these products.	N/A	N/A
Data processing	This platform was using a vulnerable version of Log4j. All vulnerable versions have been patched.	All vulnerable versions have been patched with Log4J 2.17.0	N/A
AI Training	No vulnerable version of Log4j is used in support of these products.	N/A	N/A
ML serving	No vulnerable version of Log4j is used in support of these products.	N/A	N/A
VoIP	No vulnerable version of Log4j is used in support of these products.	N/A	N/A
www.ovh.com api.ovh.com	No vulnerable version of Log4j is used in support of these management interfaces.	N/A	N/A
OVHcloud Internal systems	We continue to investigate to identify any use of the vulnerable Log4j library versions and applicable mitigations. Vulnerable systems identified so far have been patched when the patch is available or mitigation is being deployed. A deep review of all software assets is being performed to ensure the vulnerable library is not embedded in the software solutions we use to operate our information system.	Action plan includes the new vulnerabilities. Mitigation implementation are still being deployed as editors are providing patches.	N/A

External references

• https://cve.mitre.org/cgi-bin/cvename.cgi?name=2021-44228

• https://logging.apache.org/log4j/2.x/index.html

• https://greenlock.ghost.io/log4j-ou-log4shell-la-javapocalypse-cve-2021-44228

• https://www.vmware.com/security/advisories/VMSA-2021-0028.html

• https://hosted-private-cloud.status-ovhcloud.com/incidents/y6x1h3bls5rb

• https://gist.github.com/SwitHak/b66db3a06c2955a9cb71a8718970c592

• https://download.nutanix.com/alerts/Security_Advisory_0023.pdf

• https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-45105

• https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-45046

Log4j versions 2.0 to 2.14.1 are affected by a vulnerability that may lead to remote code execution (RCE). Older versions of Log4j (1.X) might also be vulnerable if the configuration explicitly loads JDNI components, which is not the standard behavior. Please also note that a lot of softwares available on the market are using Log4j.

This vulnerability is actively exploited. Several softwares to exploit this vulnerability are available publicly and easy to use.

How to mitigate

• Patch and deploy Log4j 2.15.0 version as soon as possible when you manage the software stack
• For all applications you use, check editor websites for security announcements and mitigation options
• Restrict software exposure to limit the risk of attack
• Filter egress network flows to limit exploit capability to access other resources

References:

• Mitre security announcement: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-44228
• ANSSI security announcement: https://www.cert.ssi.gouv.fr/alerte/CERTFR-2021-ALE-022/
• https://logging.apache.org/log4j/2.x/security.html
• https://gist.github.com/SwitHak/b66db3a06c2955a9cb71a8718970c592

On March 2^nd, Microsoft published a security patch for 4 vulnerabilities on Microsoft Exchange Server. Security researchers detected that those vulnerabilities are actively exploited for targeted attacks.

The vulnerable version are:

• Microsoft Exchange Server 2010
• Microsoft Exchange Server 2013
• Microsoft Exchange Server 2016
• Microsoft Exchange Server 2019

All OVHcloud Exchange managed services have been patched in emergency by Wednesday end of day. Exchange Web Service and Exchange Control Panel were temporarily deactivated between the vulnerability disclosure and the end of patching operations, as Veloxcity researchers described in their blog that the RCE was triggered using Exchange Web Service.

OVHcloud recommend to all customers operating Exchange servers on their own to patch those systems urgently.

References:

• https://www.microsoft.com/security/blog/2021/03/02/hafnium-targeting-exchange-servers/
• https://www.cert.ssi.gouv.fr/alerte/CERTFR-2021-ALE-004/
• http://travaux.ovh.net/?do=details&id=49352

OVH est officiellement en cours de qualification pour son offre Private Cloud. Cette première étape formelle dans le projet de qualification est l’occasion de faire un point sur le dispositif mis en place pour aligner son offre avec les exigences élevées du référentiel SecNumCloud dans l’objectif de fournir un cloud de confiance reconnu comme tel par l’ANSSI.

La confiance de nos clients et des clients de nos clients est au cœur de nos préoccupations. L’expertise technique et le professionnalisme de nos équipes sont la base d’une sécurité pragmatique et efficace. C’est sur celle-ci que nous construisons, chaque jour, la confiance du marché dans nos produits, solutions et services.

Cependant, cette confiance ne suffit pas. Les mesures mises en œuvre doivent être transparentes et produire des résultats mesurables et démontrables. Elles doivent s’adapter à l’évolution des menaces et être comparables entre les fournisseurs. Dans cet objectif, nous avons lancé il y a sept ans des démarches de certification de nos produits et services selon les normes de sécurité les plus exigeantes. ISO 27001, ISO 27017, ISO 27018, SOC 1, SOC 2, PCI DSS, HDS font désormais partie intégrante des feuilles de route de nos produits cloud et de nos datacenters. Au sein des équipes OVH, plus de 50 personnes sont dédiées à la gouvernance de la sécurité, à la mise en place et au maintien des dispositifs techniques logiques et physiques, à l’amélioration des systèmes et à la veille réglementaire en sécurité.

Aujourd’hui, dans un jeu économique à l’échelle mondiale, la souveraineté numérique est un enjeu politique critique comme le souligne le rapport Gauvain remis le 26 juin au Premier Ministre. Les régulateurs et les administrations des différents pays multiplient les dispositifs incitatifs ou contraignants. Ceux-ci visent à conserver une maîtrise sur la protection des données des citoyens et des entreprises, dans leur migration vers les clouds mondiaux.

Dans ce contexte, l’ANSSI a publié en 2017 le référentiel SecNumCloud et une procédure de qualification pour les « prestataires de service d’informatique en nuage », sur le modèle de ceux existants pour les prestataires de service de confiance (certification électronique, détection d’incident, horodatage, audit de sécurité, etc.). Son objectif est d’orienter les autorités administratives, les organismes d’importance vitale (OIV) et tous les acteurs économiques français et européens vers des prestataires cloud de confiance.

Le référentiel SecNumCloud, issu du « Plan Cloud », l’un des 34 plans du programme « Nouvelle France industrielle » de 2014, et d’un dialogue avec les industriels, est aligné sur la norme ISO 27001. Il précise les mesures de sécurité à opérer pour livrer un service cloud hautement sécurisé pour les traitements critiques. Le service Private Cloud d’OVH visant également cet objectif, l’alignement de nos pratiques avec le référentiel a donc été pris en compte dès la parution des premières versions de travail.

Le référentiel d’exigence a été mis à jour en juin 2018. Dans la nouvelle version, les niveaux « Essentiel » et « Avancé » ont été supprimés pour ne laisser qu’un seul niveau de qualification. Par ailleurs, des exigences relatives à la protection de la vie privée ont été ajoutées afin de prendre en compte le Règlement General de Protection des Données (RGPD) applicable depuis le 25 mai 2018.
Le référentiel SecNumCloud définit un ensemble complet de pratiques exigeantes visant à assurer un hébergement cloud sécurisé, résilient, protecteur de la confidentialité des données et protégé contre les dispositifs légaux extraterritoriaux pesant sur les services de cloud américains.

La qualification s’impose progressivement sur le marché. A ce jour, seul un fournisseur de solution SaaS a été au bout de la démarche et décroché la qualification. Mais certains décideurs français et européens intègrent déjà le référentiel dans leurs grilles d’évaluation des services externalisés et notamment pour les services d’Infrastructure as a Service. OVH étant officiellement en cours de qualification, il nous semble important d’expliciter les mesures que nous avons mises en place sur notre offre Private Cloud ainsi que celles en cours de mise en place sur la plateforme dédiée SecNumCloud visant à assurer un niveau de sécurité cohérent avec les exigences du référentiel. Cette auto-évaluation issue des démarche de cadrage du projet de qualification n’a pas vocation à se substituer aux conclusions de l’audit de l’organisme d’évaluation ni à l’évaluation de l’ANSSI. Elle vise toutefois à apporter un premier niveau d’assurance et de transparence à destination de nos clients sur l’utilisation de l’offre Private Cloud pour l’hébergement de projets dans un cloud de confiance.

L’évaluation suit le plan du référentiel SecNumCloud disponible sur le site de l’ANSSI : https://www.ssi.gouv.fr/uploads/2014/12/secnumcloud_referentiel_v3.1_anssi.pdf

Politiques de sécurité de l’information et gestion du risque

OVH dispose depuis 2014 d’une politique de sécurité des systèmes d’information (PSSI), applicable à l’ensemble du groupe. Pour les offres disposant d’un niveau de sécurité renforcé, comme Private Cloud, nous complétons cette politique générale par une politique de sécurité produit. Celle-ci définit les règles et principes de sécurité mis en œuvre pour aligner le niveau de sécurité avec les engagements de sécurité spécifiques à l’offre et aux cas d’usage de nos clients.

Tous les thèmes liés à la sécurité sont précisés dans le contexte du produit. Ce document est la référence pour tous les personnels impliqués dans l’exploitation de l’offre Private Cloud, dans le cadre des opérations quotidiennes et dès qu’une décision pouvant avoir un impact sur la sécurité doit être prise.

Dans cette PSSI, OVH matérialise également son engagement à respecter les réglementations applicables et à déployer une approche par les risques, en s’appuyant sur des méthodologies éprouvées comme ISO 27005 et EBIOS. Le comité des risques est consulté pour tout changement important sur le produit et s’assure de la mise en place des plans d’actions.

La politique de sécurité et les appréciations des risques sont mises à jour régulièrement. Lors de tout changement important dans le cadre de processus formels, le suivi implique des membres de la direction d’OVH.

Organisation de la sécurité

OVH a nommé un responsable de la sécurité des systèmes d’information (RSSI), garant du respect de la PSSI. Ce rôle global pour le groupe OVH est complété par un responsable dédié à l’offre Private Cloud et des personnels affectés aux processus de gestion de la sécurité (gestion des risques, gestion des mesures de sécurité, gestion des incidents, amélioration continue, etc.). Chaque ensemble de mesures de sécurité est sous la responsabilité d’un référent au sein de l’équipe Private Cloud, en charge de la mise en place des plans d’actions, de la documentation et des indicateurs de suivis. Ces référents assurent la prise en compte des principes de sécurité dans les projets et la gestion des changements, ainsi que dans toutes les activités quotidiennes de production de l’offre Private Cloud.

Au sein du périmètre Private Cloud, nous avons mis en œuvre une politique de séparation des tâches formelles. Elle permet de limiter les risques d’erreur ou de malveillance, en systématisant l’utilisation de workflows avec plusieurs validateurs pour toutes les actions risquées en matière de sécurité.

La sécurité est aussi prise en compte dans la gestion des projets d’évolution de l’offre et de tous les services d’OVH sous-jacents. Une approche par les risques intégrée au processus de gestion des risques du système de management de la sécurité de l’information (SMSI) est mise en place. Toute évolution du service ayant un impact potentiel sur le niveau de sécurité est mise en œuvre en suivant un processus d’information des clients systématique.

Sécurité des ressources humaines

La gestion des équipes est également réalisée en prenant en compte la sécurité de l’offre. Nous mettons en œuvre des processus de sélection poussés et de vérification des antécédents pour les personnels ayant des accès aux systèmes en charge de gérer les infrastructures ou disposant d’accès physiques aux équipements, permettant de limiter les risques de malveillance interne. Les salariés sont sensibilisés et responsabilisés dès l’embauche aux problématiques de sécurité. Une politique de formation et de sensibilisation renforcée pour les personnels en charges de Private Cloud complète ces dispositifs, par des actions de formation et de sensibilisation adaptées aux risques et aux métiers de chaque collaborateur. À titre d’exemple, tous les développeurs sont formés au développement sécurisé.

Les collaborateurs signent une charte de bonnes pratiques adaptée à leur poste et des sanctions formelles sont prévues pour tout manquement aux règles définies.

Gestion des actifs

Nous avons mis en place un inventaire complet de tous les actifs permettant de produire Private Cloud : serveurs, applications, postes de travail, logiciels, équipements réseau, énergie, système de refroidissement, conteneur, espace isolé, personnels, documents. Tout le périmètre est inventorié et géré de manière fine. Des procédures d’entrée et de sortie permettent d’assurer un inventaire exhaustif, condition sine qua non d’une gestion précise de la sécurité. C’est aussi l’assurance que chaque actif est maîtrisé dans l’ensemble de son cycle de vie.

La sensibilité des actifs est définie formellement selon une classification priorisant la protection des données de nos clients.

Contrôle d’accès et gestion des identités

La plupart des accès et interventions sur les systèmes de production sont réalisés par des scripts et des procédures applicatives, déclenchés depuis des applications internes gérant l’authentification ainsi que celle des personnels. Pour l’administration des systèmes de gestion du service ou des plateformes mises à disposition des clients, les accès sont systématiquement réalisés via des bastions gérant l’identification, l’authentification et la traçabilité de toutes les actions. Les bastions sont gérés par une équipe indépendante, afin de garantir la confidentialité et l’intégrité des traces. Les accès aux fonctions sensibles utilisent des authentifications à deux facteurs et ne peuvent être réalisés que depuis des postes de travail dédiés « durcis ».

Des processus formels de création, de modification et de suppression des comptes utilisateur sont mis en place, sur la base d’une base d’authentification centralisée. Les droits d’accès, basés sur la notion de rôles définis sur la base des fonctions des salariés, sont revus régulièrement pour s’assurer de leur adéquation aux besoins fonctionnels et techniques.

Concernant les accès des clients, ils sont gérés par des outils automatisés mis à leur disposition (espace client OVH, api.ovh.com, interface sécurisée). Le client peut activer des fonctions de sécurité complémentaires, comme l’authentification à plusieurs facteurs, des ACL réseau, la validation des actions sensibles par jeton SMS, etc. Il est responsable des droits d’accès attribués à ses utilisateurs, OVH garantissant la fiabilité des processus mis en place pour gérer les droits d’accès techniques des clients aux plateformes.

Si les environnements techniques mis à disposition des clients sont dédiés au niveau matériel (serveurs hôtes et datastores), de nombreuses briques mutualisées sont utilisées pour mettre en œuvre le service. Les robots, les équipements réseau, l’API, les serveurs de stockage des datastores et les serveurs de coordination sont des équipements mutualisés entre plusieurs clients. La segmentation entre les différents clients est gérée par la combinaison de l’utilisation de matériels dédiés et de configuration logique des équipements mutualisés, afin d’assurer l’étanchéité complète des environnements client les uns par rapport aux autres.

Les environnements bureautiques, les environnements techniques d’administration du service et les environnements d’exécution des infrastructures client sont fortement segmentés, physiquement ou logiquement. Les mécanismes de segmentation font l’objet de mesures de contrôle strictes.

Cryptologie/chiffrement

Par défaut, le stockage des données est protégé via une segmentation logique entre les clients par des ACL et des droits d’accès sur les systèmes, ainsi que par l’utilisation de médias de stockage dédiés. Le chiffrement du stockage est une fonctionnalité proposée par OVH. Elle permet la mise en place d’un mécanisme de chiffrement/déchiffrement des machines virtuelles au niveau des hyperviseurs, qui assure la protection des données client. L’activation et la configuration de ces mécanismes et la gestion des clés de chiffrement est sous la responsabilité du client mais la configuration des infrastructures pour utiliser ces fonctionnalités est réalisée par OVH.

L’utilisation de protocoles de communication réseau chiffrés (SSH, HTTPS, SFTP, etc.) est systématique au sein des infrastructures. Toute exception à ce principe doit être justifiée par une contrainte technique forte et donner lieu à une analyse de risque formelle, ainsi qu’à la mise en place de mesures de sécurité compensatoires permettant d’assurer un niveau de sécurité équivalent.

Sécurité physique et environnementale

L’accès physique des sites OVH repose sur une sécurité périmétrique restrictive dès l’entrée. Tous les locaux sont classifiés : les zones de circulation privées, les bureaux internes accessibles à tous les employés et visiteurs enregistrés, les bureaux internes confidentiels qui ont une politique d’accès restreinte à certains personnels, les zones d’équipement de datacenters, les zones datacenters confidentielles et les zones datacenters critiques qui hébergent notamment les infrastructures de l’offre Private Cloud.

Les accès à ces zones critiques sont limités à une liste de personnels réduite, avec une traçabilité renforcée et une couverture de vidéosurveillance complète. Ils sont réalisés par des sas unipersonnels, incluant plusieurs contrôles (détecteur de présence, pesée, vidéosurveillance). Un contrôle d’accès à deux facteurs pour les salles d’hébergement critiques est en cours de mise en place pour assurer la conformité au référentiel sur les zones d’hébergement destiné aux environnements SecNumCloud. Ces mécanismes seront étendus progressivement à tous les datacentres OVH.

Des mesures de sécurité sont aussi mises en œuvre afin de contrôler l’accès et éliminer toute menace, comme une politique des droits d’accès physiques, des murs ou dispositifs équivalents entre chaque zone, des caméras situées aux entrées/sorties des installations et dans les salles serveurs, des accès sécurisés contrôlés par badgeuses ou un système de détection de mouvement.

Les entrées/sorties des datacenters sont protégées par des dispositifs anti-effraction. Des mécanismes de détection d’intrusion en dehors des heures de présence du personnel et un gardiennage 24/7/365 sont aussi mis en place sur tous les sites d’hébergement. Les locaux sont surveillés en permanence par un réseau dense de caméras de vidéosurveillance.

Les ouvertures de portes d’entrée et de sortie sont contrôlées et signalées à un centre de surveillance continu.

Des règles spécifiques sont appliquées pour la gestion des accès des tiers.

En matière de gestion des risques naturels et environnementaux, les mesures suivantes sont mises en place :

• situation géographique des locaux d’OVH dans des zones non inondables ;
• situation géographique des locaux d’OVH dans des zones sans risques sismiques ;
• alimentation sans interruption ;
• transformateur de secours avec basculement automatique de la charge ;
• basculement automatique sur des groupes électrogènes avec autonomie de 24 heures minimum ;
• batteries permettant de gérer les périodes transitoires ;
• unités HVAC de maintien de la température et du niveau d’humidité ;
• système de détection d’incendie ; des exercices anti-incendie sont réalisés tous les six mois dans les datacenters.

Sécurité liée à l’exploitation

L’administration des plateformes Private Cloud est massivement automatisée. Les équipes d’exploitation n’interagissent directement avec les plateformes qu’en cas de gestion d’incident. Certaines procédures impliquent cependant des actions humaines et ne sont pas toujours automatisables. Elles sont formalisées et suivie de manière obligatoire par les personnels concernés.

Un processus de gestion des changements est mis en place. Il s’assure que toute évolution du système est cohérente, fait l’objet d’une analyse de risque et d’impact, est implémentée en respectant des règles prédéfinies et suit le processus de validation avant la mise en production.

Tous les systèmes exposés aux menaces virales sont protégés par des antivirus monitorés par les équipes d’exploitation. Différents types d’antivirus sont utilisés en fonction du rôle de l’équipement. Des dispositifs de contrôles d’intégrité ainsi que des systèmes de détection d’intrusion sont déployés sur les systèmes. Ces derniers sont monitorés en permanence par les équipes d’exploitation.

Tous les systèmes utilisés pour produire le service sont sauvegardés selon un planning adapté (type de sauvegarde et durée de rétention). La sauvegarde des environnements client est, elle, sous la responsabilité du client. OVH propose des solutions optionnelles lui permettant de déployer sa politique de sauvegarde. Le client est cependant libre d’utiliser les outils de sauvegarde de son choix.

Une politique de traçabilité extensive est mise en œuvre. Tous les équipements et systèmes génèrent des traces centralisées et gérées par les équipes d’exploitation. Les logs sont protégés par la mise en place d’une stricte séparation des tâches. Les logs des actions des clients et des interventions des équipes OVH sur leurs systèmes sont mis à la disposition des clients via l’interface d’administration de la plateforme.

La corrélation des événements et la détection des événements sont gérées par les plateformes d’administration développées en interne par OVH.

Un processus de gestion des vulnérabilités formel vise à s’assurer de l’application des correctifs de sécurité pour toutes les vulnérabilités critiques. Un planning d’application des correctifs est géré selon leur importance. En fonction des cas, ils sont appliqués durant des phases de maintenance planifiées ou en urgence pour les failles les plus critiques.

Les administrateurs des équipes d’exploitation utilisent des postes de travail dédiés, distincts des postes de travail bureautique. Ils sont contraints de se connecter à un réseau de gestion sécurisé via une passerelle VPN, permettant ensuite d’accéder aux bastions d’administration intégrant des mécanismes d’authentification à deux facteurs. Ces postes de productions sont durcis et protégés par des mécanismes de sécurité stricts (antivirus, chiffrement, filtrage réseau, etc.) et gérés par une équipe indépendante. Les administrateurs ne disposent pas de droits d’administration sur leurs postes de travail. Tous les flux d’administration sont chiffrés.

Sécurité des communications

Une cartographie du système d’information de Private Cloud est maintenue. Elle regroupe l’inventaire des actifs, ainsi que des schémas d’architecture fonctionnelle, applicative et réseau de tous les systèmes mis en place.

L’ensemble des flux réseau et des mécanismes de segmentation sont cartographiés et maintenus à jour automatiquement par rapport à l’existant. Toutes les règles d’ouverture de flux réseau sont documentées, justifiées et revues régulièrement.

La segmentation des réseaux est gérée par la combinaison de réseaux dédiés physiques et virtuels. La configuration des équipements chargés d’assurer cette segmentation est revue régulièrement. Le client est responsable de la configuration du réseau de son infrastructure virtuelle et de la connectivité de ses machines virtuelles à Internet, en adressage public ou au sein du vRack (réseau virtuel privé alloué au client). OVH fournit les interfaces d’administration de ces réseaux.

Acquisition, développement et maintenance des systèmes d’information 

Une politique de développement sécurisée est mise en œuvre au sein d’une plateforme de développement maîtrisée. Le cycle de vie des développements intègre la sécurité à toutes les étapes. Des règles d’écriture des codes sources sont définies et des processus de revue, de validation et de mise en production sont appliqués, avec des principes de séparation des tâches forts.

L’utilisation de données de production client est strictement interdite dans les activités de développement et de test. Le déploiement des évolutions logicielles sur les infrastructures de production suit le principe « 1-10-100-1 000 », permettant d’assurer un déploiement maîtrisé et incluant des procédures de retour arrière à chaque étape.

Les développements de la plateforme sont exclusivement réalisés en interne. OVH ne recourt pas à l’externalisation pour le développement des produits.

Relations avec les tiers

OVH recourt à des sociétés tierces pour les activités de gardiennage des datacenters, ainsi que pour la maintenance des équipements assurant les services essentiels en datacenter comme l’électricité et le froid. Les sous-traitants sont soumis aux mêmes règles que les salariés OVH. Elles sont imposées contractuellement à ces sociétés, ainsi qu’à chaque intervenant individuellement. Leur respect est contrôlé de façon opérationnelle et lors d’audits annuels.

Gestion des incidents liés à la sécurité de l’information

Un processus de détection des incidents de sécurité est mis en place pour s’assurer de la remontée de l’ensemble des événements sur toutes les briques du système. Les personnels sont sensibilisés et formés à la détection des anomalies. Un processus de remontée et de traitement des alertes est également mis en œuvre.

Toute atteinte à la disponibilité du service, à l’intégrité et à la confidentialité des données client ou à la traçabilité des actions sur les systèmes entraîne obligatoirement la création d’un incident de sécurité. La communication des incidents de sécurité dans les meilleurs délais est assurée dans le cadre du processus de gestion des incidents.

Une cellule de crise est mise en place pour les incidents ayant des conséquences importantes en matière de disponibilité ou d’intégrité, ainsi que pour tous ceux affectant la confidentialité des données client.

Le processus de gestion des incidents est formel. Il donne lieu à des plans d’actions de correction des causes racines et alimente le processus de gestion des risques de sécurité.

Continuité d’activité

La continuité d’activité des infrastructures est assurée par différents dispositifs garantissant la disponibilité des équipements, des applications et des processus d’exploitation : la continuité du refroidissement, la continuité de l’approvisionnement en électricité et sa redondance, la gestion de la capacité pour les équipements sous la responsabilité d’OVH, le support technique du service réparti sur plusieurs sites géographiques, la redondance des équipements et serveurs utilisés pour l’administration des systèmes et la gestion du service.

En complément, des mécanismes visant à assurer la reprise en cas d’incident sont mis en place : la sauvegarde des configurations des équipements réseau, la sauvegarde des systèmes et des données des serveurs chargés du management du service.

La continuité du système d’information du client s’appuyant sur des ressources OVH est de sa responsabilité et s’appuie sur les mécanismes proposés par OVH dans le cadre du service. Le client doit s’assurer que les dispositifs standards mis en place par OVH, les options souscrites et les dispositifs complémentaires qu’il met en œuvre lui-même permettent d’atteindre les objectifs de continuité de son système d’information.

OVH propose à ses clients de souscrire aux solutions Veeam Backup et Zerto PRA, qui offrent des dispositifs renforcés pour les sauvegardes et la reprise d’activité en cas d’incident.

Conformité

Private Cloud fait l’objet d’un programme d’audit interne et externe à trois ans, visant à couvrir les besoins relatifs aux certifications ISO 27001, ISO 27017, SOC 2 Type II, PCI DSS et certification HDS. Les activités de revues sont les suivantes :

• audit interne du SMSI annuel ;
• tests d’intrusions internes et externes annuels et ad hoc ;
• scan de vulnérabilités internes et externes trimestriel ;
• audit de certification et surveillance ISO 27001 et ISO 27017 annuel ;
• audit SOC 1 & 2 type II annuel ;
• audit PCI DSS annuel (PSP Level 1) ;
• audit de certification et surveillance HDS ;
• audit PASSI ;
• Bug Bounty OVH.

Un audit annuel par une société qualifiée PASSI a été ajouté au programme d’audits pour assurer la conformité au référentiel SecNumCloud et assurer une revue en profondeur des configurations, du codes sources et de l’architecture du service dans le cadre de notre audit interne.

Exigences supplémentaires

Une convention de service alignée sur les exigences du référentiel sera proposée à la fourniture du service qualifié, le cas échéant. Elle précisera en particulier le statut qualifié de la prestation et la possibilité pour les clients de mandater un auditeur qualifié PASSI pour auditer le service.

La localisation de l’hébergement des serveurs et des données est choisie par le client à l’initialisation du service. Dans l’optique d’assurer la conformité au référentiel, seules les infrastructures Private Cloud hébergées dans les datacenters OVH localisés dans l’Union européenne seront concernées. Le support technique au client est fourni en langue française ainsi que les interfaces d’administration du service.

OVH assurera un support du service et des astreintes 24 heures/24, 7 jours/7 par des équipes localisées en Union Européenne.

Enfin, OVH s’engage à respecter les plus hauts standards en termes de protection des données à caractère personnel, aussi bien pour les données utilisées par OVH pour la fourniture du service qu’en tant que sous-traitant en accompagnant les clients dans l’utilisation du service pour assurer un niveau de protection des données hébergées aligné avec leur sensibilité.