In this example, we will assume that you are a coffee machine manufacturer. Your current project is to build a connected coffee machine for your corporate customers. You have identified multiple use cases for this IoT machine. For instance, it automatically orders new coffee capsules when the stock falls below a certain threshold. A second option would be that the coffee machine, sends automatic alerts to your servers when maintenance management such as cleaning, repairs, etc. is needed. Finally, it offers your clients functionalities for monitoring consumption.

How can you choose the right network for your needs? What questions should you ask yourself? How do you make a good choice while considering the overall security of your system?

First Step – Define your business requirements and perform a risk analysis

First, you must identify the requirements for your IoT network which are twofold: business and security requirements. We characterize these requirements with levels 0 to 3, 0 being the lowest and 3 being the highest level.

For the business requirements, you must answer questions such as:

1. How far should the object’s signal reach?
2. How much bandwidth do you need?
3. What is the autonomy of your object?

In our example, we assume that your connected coffee machines will be distributed to corporate customers operating over a large geographical area (i.e. over 100 km radius). Therefore, you will need a wide coverage to enable your customers’ widespread machines to communicate with your Information System.

Two business cases are outlined here: If your customer agrees to connect your machine to its existing local network, you will then only need a short-range wireless network between the machine and the internet router. If they refuse to do so, you will then need to set up a long-range network as you will deploy your service and machines over a wide area.

For the bandwidth, a small/short amount will be needed as it solely requires to be able to send small data packages a few times a day at most (capsule orders, alerts, general status, …).

In regard to energy consumption, a coffee machine is traditionally connected to a power supply to perform its tasks; henceforth, power does not constitute an issue in terms of IOT, i.e. the object autonomy is therefore not constraint. There is no energy consumption requirement per se as it is already covered by the coffee machine’s connection to the power grid.

We summarize the levels for business requirements as follows:

• Range (R) = 3 or 1
• Bandwidth (B) = 1
• Energy consumption (E) = 0

Having defined your business requirements, a risk analysis must be conducted to formulate the security requirements of your project for availability, integrity, confidentiality, and traceability purposes.

A loss of availability would occur in the event of a dysfunction on the connected coffee machine that would render it unusable for a customer. A loss of access to the network or unavailability of backend servers should never result in the machine being unavailable: it must remain working off-network. However, if a dysfunction of the machine occurs, we assume that you would want it to be reported back as quickly as possible through the network in order for maintenance actions to be triggered.

How long can this last? The answer would be several hours rather than several days, as we wouldn’t want to deprive employees from their coffee breaks! Therefore, 4 to 24 hours is an acceptable window of unavailability which can be translated into an availability requirement level of 2.

A loss of integrity would result in data corruption. For example, a potential excess order of coffee capsules may occur by altering the messages sent by the coffee machine or by replacing the same order multiple times. In both cases, this would result in a financial loss for your client. Data on the network needs to be communicated rigorously and exactly. Hence, we can conclude this is a requirement level of 3.

A loss of confidentiality would result in data being divulged; orders quantities are rather sensitive data that shouldn’t be shared with external parties. It needs to be ensured that data is communicated securely on the network and is not accessible by externals parties.  Hence, we conclude that confidentiality has a requirement level of 2.

For traceability, and for simplification reasons, we choose to leave this aspect aside assuming that it is already accounted for by the study of the first 3 criteria.

In a nutshell, risk analysis concludes to the following security requirements:

• Availability (A) = 2
• Integrity (I) = 3
• Confidentiality (C) = 2

For more details about risk analysis methodology for smart objects, you can refer to this article.

At the end of this analysis, you obtain for both of your business cases a radar chart of your requirements.

Business case 1: your customer connects your coffee machine to its local network

Business case 2: your customer does not connect your coffee machine to its local network

Though not discussed in this article, financial aspects are also important and depend on various factors such as the network operator pricing model. Same goes for geographic constraints as some networks may not be available on some regions.

Eventually, the ease of configuration of the network may be included in your business requirements, especially if your connected object targets a B2C audience.

Second step – Choose your IoT Network

Building on business and security requirements, we developed a methodology to choose the right network that will be optimal to meet your business and security needs: range, bandwidth, energy consumption, availability, integrity, confidentiality.

The three business requirements are mandatory, the network you choose must fulfil them, otherwise, it will be eliminated.

For security requirements, the assessment requires pre-emptive analysis. Between two networks that cover the same business requirements, you should choose the one that offers the best level of security with the minimum cost.

If a network doesn’t cover one of the security requirements, you will have to implement some additional security feature as a part of your project backlog, consequently raising your costs.

You should also be vigilant that the additional implementation doesn’t impact the system’s performance. For instance, if you implement data encryption at the application layer, increasing processing times would negatively impact your maximum data rate or could be constrained by the hardware capabilities of the device, with a potential financial impact in case of a hardware upgrade. Consequently, one of your business requirements may no longer be met.

In case high availability is required (A=3), you ought to choose a robust network by design that will meet your real-time needs.

In fact, spread spectrum (like Bluetooth or ZigBee) or frequency hopping modulated protocols (like Sigfox or Bluetooth) are more resistant to radio jamming or radio interferences.

These types of networks are particularly recommended when availability is an important requirement, such as on an industrial production line.

Moreover, mesh protocols are known to be more reliable and scalable than point to point protocols. However, for them to achieve efficiency, they need to be used in a context where multiple connected devices are linked together. Mesh protocols like WirelessHART can also guarantee real-time communications. Their usage is especially adapted to an industrial context.

A simple methodology to choose the right network is to confront your business requirements to the network’s business and security offerings.

In the following radar charts, we present different types of IoT networks providing different levels of business and security offerings, and we compare each one of them to our business requirements.

Business case 1: your customer connects your coffee machine to its local network

Business case 2: your customer does not connect your coffee machine to its local network

Let’s apply the previous methodology to your connected coffee machine. First, we use our previous radar charts to see which networks comply with our business requirements.

Business case 1: your customer connects your coffee machine to its local network

For your first business case, Bluetooth and Wi-Fi are two viable short-range options if your customer connects the machine to its local network. On the one hand, Bluetooth meets all the security requirements, but it is less straightforward to implement compared to Wi-Fi. On the other hand, Wi-Fi meets all of them except for availability but that is something we can work out with SLA agreements.

Business case 2: your customer does not connect your coffee machine to its local network

For your second business case, Zigbee, BLE and Wi-Fi are clearly out of the equation because they do not meet the range requirements. However, LoRa, LTE-M and Sigfox are still in the mix.

We use the radar charts again, this time to assess these three candidate’s compliance with the security requirements.

Sigfox does not meet one of your security requirements (confidentiality) whereas LoRa complies with all security requirements. LTE-M is the best offering as it meets all your requirements, but it is also the most expensive. We conclude that LoRa is a relatively good candidate.

In conclusion, we have one good candidate: LoRa which will require the deployment of a new network and an alternative using a pre-existing Wi-Fi network. It should be noted that you may refuse to connect to the Wi-Fi network on company premises for security reasons.

We will undertake a new scenario in a next article: a customer company buys the machine and discusses what payment options to use.

Cet article Connecting your connected coffee machine: yes, but how? est apparu en premier sur RiskInsight.

What is a cyber risk analysis?

Did you ever wonder what would happen if a device your company developed and sells leak the data it collects? Or if that data were corrupted or suddenly made unavailable? What would be the most detrimental? What if your solution was vulnerable to a cyberattack? Could the consequences be a takeover of device(s) which leads to a safety hazard such as a building taking fire or even a human casualty? Or maybe it could “just” be a pivot attack onto your customer’s network that leads to a full incapacity for your and your customer’s businesses to operate.

If you are currently developing an IoT solution and are not having a nervous breakdown when considering such possibilities, you are probably wondering though how your CISO (Chief Information Security Officer) is not having one.

Well it is probably because your CISO has a method: they consider every risk from an unbiased perspective and in a comparable manner. Ensuring each risk is correctly evaluated (i.e. not overestimated or underestimated) and sharing the outcome of this evaluation with all project stakeholders is the first important step. Once all stakeholders agree upon every risk your company has the right basis to decide control measures.

This approach does not mean you should address every risk to the point that your solution is virtually unhackable. Frankly, this is not technically possible, and your budget would vanish far before achieving a so called zero cyber risk solution. Each control measure must be prioritized and proportional to the risk likelihood and severity.

What we described above is known as a risk analysis methodology. Cybersecurity professionals use this methodology as the baseline to their company’s cybersecurity initiatives. The professionals evaluate risk scenarios (often tied to service availability, data integrity, confidentiality and/or traceability of actions) and the impacts on their company’s brand image, legal liabilities, safety consequences and of course financial outcomes. The higher the risk is evaluated, the higher the priority is set to lower the likelihood of the risk occurring (e.g. add barriers to an attack, reduce the attack surface, etc.) or the severity of outcomes if the risk occurs (e.g. apply segmentation to reduce the spread of an attack).

If you want to learn more about the existing risk analysis methodologies you should start with ISO27005 which has a wide scope of adoption and understanding across various industries.

Be reassured that talking about risks will not increase the likelihood of the problem occurring (if you ever feared that), however not talking about them puts the project at great risk.

What makes an IoT Project risk analysis different?

Hopefully we have convinced you that doing a risk analysis of your project is an important task; we will touch upon how you can get started quickly in the next chapter. Before we get there, we will detail what makes the exercise specific for an IoT project: what are the characteristics of such projects and what makes the risk analysis more difficult or simpler?

Let us start with the common characteristics that should be considered for a risk analysis. First of all, an IoT initiative often relies on a very decentralized network of hardware (sensors, gateways, servers, etc.). These devices can be spread over a large geographical area, sometimes all over the world, and are meant to remain in the field for a long time with little to no onsite maintenance. It is common to see B2B IoT devices that aim for a lifetime of more than 10 years (e.g. a water metering project for utility companies). B2C devices can also aim for such lifetimes – think of connected vehicles for instance. It is also noteworthy that IoT devices usually have limited user interfaces such as a screen and keyboard. Despite this, the buttons, LED and mobile applications allow the necessary interactions or customizations to the IoT device for you to collect data from the field. Remember, the data collected from connected devices is where the value resides. Thus, whether that data is critical or not is essential in the risk evaluation. Finally, we need to remind ourselves that an IoT project is still an IT project. If the devices are not typical laptops, the application servers and storage remain central in most cases. This is where a large part of the risk remains, but fortunately, there are many best practices for this portion of the solution as well.

From a cybersecurity perspective such characteristics can make IoT projects riskier. For instance:

• The physical security of a decentralized network is very hard to enforce. Where are the devices located? Are the devices accessible to the public? Can someone easily steal, damage or tamper the devices? For example, a tracker installed on a pallet travels outside trusted premises and can be damaged or removed – intentionally or not. Of course, this risk is amplified by a wider geographical footprint.
• Given the limited user interactions and the longer device lifetime, it can become very costly and time-consuming to maintain the devices, especially if you must physically dispatch technicians. Hands-on intervention can be simply unrealistic, but even firmware upgrades have a failure rate. Because of all this, the controls must be relevant for the long run.
• In any IoT project, the sensitivity of the data is a factor that must be considered. Is it critical for your company? For consumer projects the sensitivity of the data can be perceived as very high because the devices will collect data from the “real” world.
• IoT solutions consist of many different technologies and vendors. This is a challenge for us: what are the security practices followed by each of these vendors and do these practices sufficiently cover my risks?
• Finally, the security controls that can be applied are dependent on the capacities of the devices and softwares. For example, many sensors run on 8-bits MCU and thus cannot run complicated encryption algorithms.

Fortunately, all these characteristics also play a role in reducing the cyber risks for IoT projects.

• With very decentralized deployments, the level of effort required by an attacker to access a large number of devices is burdensome. Compromising a single device is one thing but compromising the entire fleet of devices is an entirely different task. This is especially true if physical tampering or proximity is required.
• The application of the IoT devices are rarely handled directly by a user and there are limited user interactions after installation. Thus, attackers have limited opportunities to trick the user into misusing the application.
• Depending on the context, the value of the data can be very limited for attackers (e.g. room temperature monitoring used to control AC systems). What is more, the value can also decrease sharply with time. Production data can be critical for real-time control of processes, but it becomes a lot less valuable a few minutes after.
• The architecture of IoT solutions is usually segregated from the IT systems including servers or data centers. This segregation enables companies to easily define and protect integration points.
• Finally, the limited capacities of the device play a role in preventing any harmful attempt. Attackers simply cannot access, implant malware or effectively control sensors with 8-bit MCUs.

So now, how can I get started?

Well, take a deep breath and involve your CISO.

The CISO must identify and evaluate applicable regulations, decide what level of risks is acceptable, provide policies to follow and tools to implement security measures. Perhaps you should appoint Product Security Officer to specifically address IoT security in your company or even a given IoT product’s security if the stakes require it.

Getting to an acceptable level of security will require expertise on the various areas of the IoT solution. If you are that expert, then you should probably be ready to get involved. This will drive the whole team to consider the:

• End-to-end security on the technology stack: from hardware to cloud including embedded software, network connectivity, mobile apps, etc.
• End-to-end security from a device lifecycle perspective. When you design your device, think about all phases: from manufacturing to distribution; from initial use to normal usage; resell, refurbish, recycle or trash.
• Partners involvement: make sure not to forget them and assess their maturity. You might need to take measures to support them or upskill them (hint: ask your CISO or PSO for it).
• Audit of your device and the whole technology stack. Do this regularly because your software may not have changed but the threats and known vulnerabilities may have.
• Long-term security updates and maintenance: define for how long you will update and deploy your devices.
• Incident response organization: define how you can be notified of vulnerabilities or breaches and how you can plan to respond (from a technical and a communication point of view).

IoT cybersecurity is not impossible. It actually provides methodologies and tools to help achieve a secure landscape.

Project stakeholders and customers are seeking and pressuring for secure products. Regulation to enforce security are imminent and frameworks to help align every actor regarding its duties will continue to be applied. It is time to get ahead now if you are looking to make cybersecurity an asset for your product on your market!

Cet article Risk analysis and IoT: a marriage of love or reason? est apparu en premier sur RiskInsight.

Lately, strong attention is being paid to risk quantification, and rightly so. However, it remains a very complex topic. There are two obvious reasons for this: we are sorely lacking in precise information and feedback; but also because cyberattacks generate many intangible impacts (reputation, internal disorganization, strategic damage, shutdown of operations); or indirect costs (drop in sales, contractual penalties, drop in the company’s market value, etc.).

We can see promising avenues for quantifying risk, and solutions able to automate this quantification are been released.

Why cyber risk should be quantified?

Whether it is for communicating with senior management, business units, or even insurers, there is a real need to assess cyber risks as objectively as possible. The challenge is twofold: to gain relevance and legitimacy. One way forward is to treat cyber risk through a financial prism, like all other business risks, to make them meaningful to decision-makers.

One of the real challenges in quantifying cyber risks lies in building trust with executive committees over the long term. The first step is to adopt a clear posture to convince them and secure the investments needed to launch structuring security programs. Then, it should help proving the effectiveness of the investments made, and thus sustain the relationship with the executive committees over time, through the demonstration of the risk reduction in a quantified way and the evolution of risk over several years. This is key, particularly in the wake of the COVID crisis, as it will lead to a reduction and optimization of cyber security budgets within companies. It will therefore be essential to quantify the cyber risk for a stronger control on the ROI of cyber security investments.

The process of securing a company’s information system cannot be carried out without the implementation of Security by Design. Hence, it cannot be carried out without involving the business units. Speaking the same language is therefore necessary.

Finally, in order not to find themselves at the foot of the wall in the event of an attack, it is essential for companies to anticipate the potential costs of an attack in order to adapt provisions and insurance. This quantification allows them to do this.

What are the main difficulties encountered?

Given their intangible nature, it seems complex to objectively assess the impacts of cyberattacks. This is the case, for example, of the impact on a company’s image and reputation, or strategic damage and internal disorganization. Other risks are indeed tangible but indirect, which further complicates the task of companies that wish to quantify their risks, for example a loss of market share, a drop in the company’s market value, etc.

There is no universal formula for calculating the impact of an attack on a company. It depends on several parameters: the size of the company, the level of complexity and openness of the information system, the cyber maturity, etc. A company’s level of exposure depends essentially on its level of cyber security maturity. There are frameworks such as NIST, ISO, CIS, etc. for estimating the level of maturity in cyber security, but few companies manage to implement them or use them at their full extent.

Companies willing to quantify their cyber risks are faced with a lack of statistical databases on the cost of cyberattacks. Of course, most companies communicate little or nothing about it, probably to avoid scaring their customers and partners. And yet, collaboration would be key in the face of increasingly clever attackers: both to increase their cyber-resilience and to facilitate risk quantification. For example, Altran and Norsk Hydro have been affected by similar ransomwares from the same group of attackers!

Some first clues for quantifying cyber risk

IMF President Christine Lagarde has already taken up the issue and published a bill and a methodology for quantifying cyber risks in the banking sector, used within the IMF. So how can we extend quantification to other sectors?

Prerequisites for optimal risk quantification

The FAIR methodology is one of the most widely used to quantify risks. Effective risk quantification induces:

• A good knowledge of its most critical risks. Indeed, given the complexity of FAIR, it is better not to spread out and focus on the most important risk scenarios. You still have to know them! A risk mapping exercise is to be expected, in which the mobilization of the business units will be needed;
• A good understanding of existing security measures to ensure their ability to resist attacks and to estimate the residual impacts;
• A first draft of a repository of typical costs (legal fees, communications fees, etc.), which will be completed over time, and which requires business expertise to identify and estimate costs.

Also, estimating the cost of risk, due to its cross-functional nature, calls for the collaboration of many stakeholders in the company (HR, legal, etc.), which can be complex to set up.

The FAIR methodology, an approach that specifies certain phases of risk analysis and treatment

Introduction to the FAIR (Factor Analysis of Information Risk) methodology

In 2001, Jack Jones was the CISO for Nationwide Insurance. He was confronted with persistent questions from his senior management asking for figures on the risks to which the company was exposed. Faced with the dissatisfaction caused by the vagueness of his answers, Jack Jones set up a methodology to estimate, in a quantified way, the risks weighing on his business: the FAIR methodology.

Concretely, how does this differ from a risk analysis methodology, such as EBIOS in France?

The FAIR methodology is not a substitute for risk analysis: FAIR is a methodology for assessing the impacts and probabilities of a risk more reliably. The impacts are always translated into financial terms in order to make the evaluation tangible. The contributions made are illustrated in the diagram below.

Diagram 1: FAIR, an approach that specifies certain phases of risk analysis and treatment

Usually, cyber risk assessment results in several types of impact (image, financial, operational, legal, etc.). The particularity of the FAIR methodology is to transpose each impact to a financial cost (direct, indirect, tangible and intangible costs). For example, if a risk scenario has an impact on the company’s image, FAIR translates this risk into a financial risk by evaluating the cost of the communication agency that will be mobilized to improve the company’s image. If a company’s CEO is mobilized as part of crisis management, then it will be necessary to estimate the time spent managing this crisis and monetize it.

How to apply the FAIR methodology?

A risk quantified in euros is the factor of the frequency of successful attack (loss event frequency) and the cost of the successful attack (loss magnitude). The diagram below shows the approach used by the FAIR methodology to estimate these two characteristics.

Diagram 2: the criteria taken into account by the FAIR methodology to estimate risks

• « Loss Event Frequency » computation

The “contact frequency” represents the frequency at which the threat agent meets the asset to be protected. For example, it may be the frequency at which a natural disaster occurs at a given location.

The “probability of action” is the likelihood that the threat will maliciously act on the system once contact is made. This applies only when the threat agent is a living being (does not apply in the case of a tornado, for example). This is deducted from the gain, effort and cost of the attack and the risks.

The “threat event frequency” is derived from these two parameters.

The “threat capability” consists of estimating the capabilities of the threat agent both in terms of skills (experience and knowledge) and resources (time and materials).

The “resistance strength” is the company’s ability to withstand this attack scenario. The resistance threat is calculated based on the level of cyber maturity of the entity, for example with a gap analysis at NIST.

From these two parameters come the “vulnerability” and the “loss event frequency”.

• « Loss Magnitude » computation

“Primary losses” are the cost of direct losses. This includes: interruption of operations, salaries paid to employees while operations are interrupted, cost of mobilizing service providers to mitigate the attack (restoring systems, conducting investigations), etc.

“Secondary losses” are indirect losses, resulting from the reactions of other people affected, and are more difficult to estimate. For example, secondary loss can cover the loss of market share caused by the deterioration of the company’s image, the costs of notifying an attack through a communication agency, the payment of a fine to a regulator or even legal fees, etc. This is calculated by multiplying the “secondary loss event frequency” and the “secondary loss magnitude” for each of the indirect costs.

A solution that accompanies companies in the implementation of this methodology

Beyond the theoretical description of the methodology, solutions are being developed to enable companies to apply the methodology in a concrete way. This is the case of the French start-up Citalid, for example, which offers a platform for quantifying cyber risks based on the FAIR methodology. This enables the CISO to refine and make the quantification of risks consistent thanks to threat intelligence (for monitoring attackers over time). To use the solution, the company must fill in elements relating to its context and, for each of the risk scenarios to be quantified, complete a NIST questionnaire (50 questions for the most basic or 250 for a finer level of granularity) and the rest is calculated automatically.

What are the advantages and limitations of the FAIR methodology?

The FAIR methodology mainly provides the following elements:

• It allows the company to identify and evaluate more precisely the most important risks. For each of the selected risk scenarios, the methodology allows an estimate of average and maximum financial losses and an estimated frequency. For example: “the probability of losing 150 million euros due to the propagation of a destructive NotPetya type ransomware exploiting a 0-day Windows flaw is 20%”.
• It allows to estimate the cost-benefit of the risk reduction action plan. By playing with “resistence strength”, it is possible to estimate the return on investment (ROI) of the security measures to be put in place.
• It transposes all cyber risks into a financial risk which allows a better understanding of the risk by the company’s managers.

However, the FAIR application is not without constraints because it requires resources that are sometimes significant (both in terms of man-days and knowledge of the company’s context). Moreover, risk quantification only covers a limited scope (1 risk scenario). Also, risk quantification using the FAIR methodology needs to be refined with standard cost charts associated with a cyber impact. This can be done, for example, by capitalizing on post-mortem analyses of a cyber crisis, which can often provide a real illustration of the financial impacts.

Thus, the FAIR methodology is a promising approach that still needs to be fully understood and adapted to companies’ context in order to derive concrete benefits.

Cet article Cyber risk quantification : understanding the FAIR methodology est apparu en premier sur RiskInsight.

Bien que les principes fondamentaux d’identification des enjeux, des risques et des actions de remédiation demeurent, la méthode s’illustre par son appel à des scénarios d’attaque complexes tirant partie de vulnérabilités multiples, à la manière d’attaques réelles comme celle contre les systèmes de connexion à SWIFT de la Banque Centrale du Bangladesh en 2016 ou contre Sony Pictures en 2014… Autre évolution majeure, l’apparition d’une analyse approfondie des attaquants potentiels, de l’écosystème et des parties prenantes du périmètre étudié.

Ce changement de posture permet à EBIOS RM de répondre spécifiquement aux problématiques posées par des attaquants toujours plus professionnalisés qui étudieront méthodiquement les vulnérabilités d’une cible ainsi que l’ensemble de son écosystème pour parvenir à leurs fins. Elle vient ainsi remplir une zone de vide dans l’espace des méthodologies d’analyse de risques.

Néanmoins, malgré cette approche réellement innovante et comme nous allons l’étayer ci-dessous, EBIOS RM ne doit pas forcément être considérée comme la nouvelle démarche globale d’analyse des risques mais plutôt comme une nouvelle corde à l’arc méthodologique du RSSI pour traiter les scénarios d’attaque les plus complexes.

S’appuyant sur nos premiers retours d’expérience de l’application concrète de cette méthode, nous présenterons en détail les évolutions qu’elle apporte ainsi que leurs implications sur la gouvernance plus générale des risques SSI.

EBIOS RM, une nouvelle méthodologie pour mieux appréhender les risques complexes de cybersécurité

Depuis bientôt 10 ans, EBIOS 2010 propose une méthode centrée sur la notion de menaces unitaires tirant partie de vulnérabilités et de prévention de leurs impacts sur des processus métiers. Cette méthode, qui remettait à l’époque le métier au centre de l’analyse de risques, n’est cependant pas conçue pour identifier et traiter des menaces complexes. Ces menaces, composées de rebonds de l’attaquant d’une vulnérabilité à une autre pour atteindre ses fins, constituent pourtant aujourd’hui une part majeure de l’univers des risques SSI et ont été mises à l’ordre du jour de nombreux comités exécutifs à la suite des dernières attaques majeures comme NotPetya ou WannaCry.

EBIOS RM vise à compléter ce manque par une approche intégrant dans un premier temps de l’étude poussée des intentions des attaquants potentiels, puis la prise en compte formelle de l’écosystème et enfin l’identification de scénarios d’attaque complexes de type kill chain. L’objectif final de cette étude n’est plus l’alignement des mesures de sécurité à des failles unitaires comme pour EBIOS 2010 mais bien la capacité à maîtriser des risques aux facettes multiples.

En préalable, mener un travail préparatoire concernant les vulnérabilités

EBIOS RM propose dans un premier temps la mise place d’une étude structurée du niveau de sécurité du périmètre analysé par une revue de conformité. Cette vérification permet d’identifier un premier panel de vulnérabilités, comme le ferait un attaquant en testant par exemple la version des infrastructures ou les vulnérabilités de l’OWASP.

Contrairement à ce qui est proposé dans la méthode EBIOS 2010, la principale finalité de cette approche n’est pas de remédier à des vulnérabilités unitaires mais bien d’alimenter la définition des scénarios d’attaque complexes en identifiant les potentiels points de rebond de l’attaquant.

Ensuite, mieux prendre en compte l’écosystème et les sources d’attaque

Par ailleurs, afin d’adapter l’analyse des risques à la réalité des SI contemporains et de l’univers de menace, EBIOS RM intègre une innovation majeure sous la forme de la revue systématique de l’écosystème du périmètre étudié, depuis les tiers de confiance connectés à celui-ci jusqu’aux tiers présumés hostiles tels que des concurrents, des états voire des activistes.

L’étude des tiers de confiance met en lumière leurs interactions avec le périmètre étudié, trop souvent acquises comme sûres, qui constituent un vecteur d’attaque idéal pour un attaquant contournant ainsi les défenses périmétriques voire les mesures de gestion des accès internes.

L’étude des tiers hostiles place quant à elle la notion d’intentionnalité de la malveillance au cœur de l’étude. EBIOS RM propose donc de les identifier précisément et d’analyser les objectifs possiblement visés. Ce changement d’angle de vue sert de base au développement de scénarios d’attaque complexes dans la suite de la démarche.

Cette nouvelle approche vise notamment à faire face aux attaques par water-holing ou encore des conséquences de la compromission d’un SI tiers comme les fuites de données de l’enseigne américaine Target en 2013.

Enfin, un travail itératif de construction des scénarios d’attaque

Sur la base de cette connaissance approfondie du contexte, la démarche EBIOS RM vise à réaliser une étude préliminaire et plus fonctionnelle des évènements pouvant survenir sous la forme de scénarios stratégiques, puis un zoom plus technique sous la forme de scénarios opérationnels détaillés. L’objectif est que ces deux visions s’alimentent tout au long de l’étude dans une réflexion itérative.

EBIOS RM demande tout d’abord de définir de 3 à 5 scénarios stratégiques combinant source d’attaque, objectif visé et principaux moyens utilisés pour atteindre cet objectif. Cette vision de haut niveau et aux aspects techniques très limités, atout clef pour présenter les risques cyber aux métiers voire aux instances dirigeantes d’une organisation, permet également de préciser le périmètre de la réflexion plus technique qui sera réalisée au travers de 10 à 15 scénarios opérationnels.

Ces scénarios opérationnels racontent un fil détaillé d’évènements qui, combinés, mènent à un impact majeur. EBIOS RM structure ce cheminement au travers de quatre phases. Tout d’abord, la prise de connaissance par l’attaquant du SI ciblé, de son fonctionnement et de ses acteurs. Ensuite, la phase d’entrée dans ce SI au travers d’actions comme le phishing ou l’exploitation d’une backdoor. Puis vient la phase de recherche des données ou du SI critique que l’attaquant souhaite compromettre. Enfin, c’est la phase d’exploitation de cette cible via par exemple l’exfiltration de données ou l’implantation d’une bombe logique.

Chaque scénario d’attaque opérationnel aura donc sa propre histoire à raconter, sa propre kill chain, dont la vraisemblance sera déterminée. Cette spécificité est une des forces de l’étude, facilitant sa restitution, mais lui permettant également d’alimenter la réflexion d’un SOC concernant la définition de scénarios de corrélation à implémenter dans un SIEM.

Cette hauteur d’analyse en fait d’ailleurs un outil de choix pour l’étude des risques des périmètres les plus critiques d’une entreprise, comme par exemple les SI d’importance vitale.

Un outil ambitieux dont il faut cadrer l’utilisation

EBIOS RM présente des atouts séduisants par la prise en compte des motivations et méthodes des attaquants, de l’étude approfondie des tiers de confiance comme potentiels vecteurs d’attaque ou encore par sa capacité à produire des scénarios d’attaques complexes mais capables de convaincre des publics non-initiés.

L’une des principales qualités d’EBIOS RM, imposer réflexion et créativité pour définir les scénarios stratégiques et opérationnels pertinents, a néanmoins un revers notable : EBIOS RM ne pourra ainsi pas, exception faite de l’étude du socle et des acteurs menaçants, faire l’objet d’une industrialisation poussée des outils associés sans craindre une perte de créativité et donc une perte de qualité dans ses résultats. Cette logique s’écarte donc de celle en vigueur pour EBIOS 2010 qui rendait par exemple possible une revue exhaustive des menaces, permise par la complexité très souvent limitée de celles-ci.

En l’absence de cadre largement outillé et afin d’éviter que la subjectivité des participants n’y fasse son lit, EBIOS RM va ainsi exiger de son pilote un éventail de compétences qui reste rare sur le marché : des connaissances techniques pointues et orientées test d’intrusion pour déterminer ce que serait capable de réaliser un attaquant selon son niveau d’expertise, de la créativité, une capacité au story telling, à la synthèse et à la pédagogie, afin de définir des scénarios d’attaques qui auront à la fois suffisamment d’impact et de pertinence pour convaincre à la fois les équipes métiers et techniques tout en illustrant avec justesse et moins de quinze scénarios opérationnels toutes les facettes remarquables de la situation étudiée.

Ces différentes qualités renforceront par ailleurs la légitimité du pilote de l’étude, indispensable pour animer et recadrer efficacement les différents groupes de travail demandés par la méthodologie, afin d’éviter les discussions sans fin qu’elle peut risquer d’entraîner par ses aspects subjectifs. Il faut en outre garder à l’esprit que par son aspect itératif et les nombreux groupes de travail qu’elle implique, EBIOS RM sera une démarche significativement plus coûteuse en temps qu’EBIOS 2010. De plus, ses résultats seront difficilement réutilisables d’une étude à l’autre, en cela qu’elle se concentre justement sur les spécificités des périmètres étudiés.

Les sources accidentelles écartées

Dernier point d’attention, EBIOS RM, en plaçant l’intentionnalité au cœur de sa démarche, écarte les sources accidentelles. Pourtant, celles-ci se produisent régulièrement, qu’il s’agisse d’un coup de pelleteuse, d’une corruption d’une base de données ou de l’erreur d’un administrateur. Par ailleurs, le cœur de la démarche EBIOS RM, en générant un nombre limité de scénarios opérationnels, ne vise pas à l’exhaustivité qui était une des forces d’EBIOS 2010. La réponse de la démarche à ce biais méthodologique est l’étape d’étude du socle, mais celle-ci n’est qu’une revue de conformité. Si on imagine appliquer la démarche à un périmètre existant présentant de nombreux axes d’améliorations et qu’on utilise un référentiel de conformité suffisamment exhaustif (les 42 règles de l’ANSSI ou ISO27002), on pourra se retrouver avec une liste à la Prévert des mesures correctives à mettre en œuvre, sans moyen rigoureux de les prioriser, sauf à faire appel à EBIOS 2010 qu’EBIOS RM visait à remplacer…

Vers une refonte de la gouvernance de la gestion des risques

EBIOS RM est donc une démarche qui nécessite un temps de mise en œuvre certain ainsi que des expertises à la disponibilité souvent déjà limitée, et dont les résultats seront difficiles à réutiliser. En tenant également compte de ses priorités méthodologiques, nous pensons préférable de concentrer l’application de cette démarche aux systèmes présentant des enjeux forts et dont le niveau de sécurité a déjà un certain niveau de maturité, par exemple parce qu’ils seront passés par l’étape EBIOS 2010. Il nous semble également préférable d’utiliser EBIOS RM pour des ensembles cohérents de SI (exemple : une voiture ou les activités marketing) afin de conserver un périmètre d’étude suffisamment important pour permettre des attaques avancées. Enfin, sur des ensembles cohérents de SI appartenant à des acteurs différents, il est possible d’appliquer la méthode jusqu’aux scénarios stratégiques afin de fixer des priorités d’étude pour les analyse de risques plus détaillées qui seront mises en œuvre par chaque entité sur ses périmètres propres. EBIOS RM sera dans ces cas d’autant plus pertinente qu’elle se concentrera uniquement sur des scénarios au plus proche des pratiques métiers.

EBIOS RM, une brique dans l’offre de services d’analyse de risque

L’arrivée d’EBIOS RM, démarche novatrice quoique à utiliser avec mesure, et qui finalement complète plus qu’elle ne remplace EBIOS 2010, participe donc à créer ce qu’on pourrait appeler une offre de service EBIOS. Les ressources et les compétences nombreuses qu’elle nécessite pour être mise en œuvre la réserveront ainsi à des périmètres spécifiques, fortement exposés ou porteurs d’enjeux majeurs comme par exemples les SI d’importance vitale, ayant déjà fait l’objet d’un socle de mesures d’hygiène SSI.

Tout ceci plaide en faveur de la mise en œuvre, en amont des projets, d’une démarche de gouvernance des risques, transverse à l’entité, qui permettra de déterminer rapidement les enjeux, l’exposition et la maturité sécurité de ses périmètres fonctionnels et applicatifs, puis de décider en fonction quelle méthodologie de sécurisation mettre en place : simple revue de conformité à un socle minimal de règles de sécurité, étude EBIOS 2010 plus ou moins approfondie ou enfin, sur les périmètres à la fois sensibles et matures, étude EBIOS RM.

Cet article EBIOS (2010) est mort, vive EBIOS (RM) ? est apparu en premier sur RiskInsight.

Under the French Military Programming Act (MPL), certification is a mandatory procedure that applies to Vitally Important Operators (VOI). It helps to manage the issues and security levels for all Vitally Important Information Systems (VIIS)

Certification is a core issue to the MPL compliance strategy, because it provides a concrete and operational means of breaking down the MPL’s requirements while reducing security risks.

ANSSI—The French National Cybersecurity Agency—has produced a guide that describes the key steps in certification. These steps are:

• Defining a certification strategy (a scoping document describing how to achieve certification)
• Performing a risk analysis on a VIIS
• Conducting a certification audit
• The certification decision
• Post-certification monitoring

The approval decision must be made by the Certification Authority (CA), which is the legal entity responsible for certifying VIIS. It is assisted by the Certification Commission, an internal group of experts responsible for doing the preparatory work for the certification decision.

The information required to make the decision is compiled in the certification file. This allows the Certification Commission to attest to the level of security and accept the residual risks. Ultimately then, it is the Certification Commission that attests to the fact that the risks are being properly managed.

An approach to quickly assess existing VIIS

Retro-certification: how to certify VIIS already in production

For existing VIIS, the certification model is different, although the objectives remain the same. An assessment of existing VIIS is the starting point for certification, and performing a dry-run audit (or using a previous audit report) serves to speed up the gathering of information and the identification of risks.

Conversely, the security measures have to be applied to a history that can be challenging to transpose. Compensatory measures therefore have to be identified, prioritized, and implemented.

This retrospective certification, or retro-certification, must enable the business to consider the risks in an exhaustive fashion, and prioritize the actions, in order to reduce them to an acceptable level by making the necessary investments.

While it’s important to design the certification process such that it has the capacity to process future VIIS, it is mostly for existing VIIS that VOI are actually busy with, and retro-certification is, therefore, a priority.

Adopting a test & learn approach

In order to define and deploy a certification procedure within the framework of the MPL, VOI can define an initial pilot stage to test and refine the process before using it—at full scale—on a VIIS.

The objective of this pilot phase is to compare the methodology and the reality on the field, with the aim of validating the approach and the steps defined (procedures, people who need to be involved, etc.). Taking such approach highlights areas of difficulty (related to IS administration, partitioning, patch management, etc.), and enables a concrete and achievable remediation plan to be put together.

The choice of pilot VIIS is essential in anticipating the problems that will be encountered. It makes sense to choose a pilot VIIS that is representative of all the other VIIS (typical size, limited interactions, etc.).

Demonstrating the security level generated by the MPL

Among the various work streams and projects triggered by the MPL, it’s the certification program that enables security to be strengthened effectively. This can be achieved not just by highlighting security at high level both internally (with senior management and those with accountability for certification) and externally (with ANSSI and the government), but also by quantifying the degree of risk reduction required (through risk analysis) and achieved (through audit).

Achieving certification enables actual risks to be communicated, and the players involved to be made responsible and aware (particularly senior management—as a result of interactions with those accountable for certification).

All the activities undertaken for MPL compliance are compiled in a certification file, which gives them a practical reality. This includes observations about security, obstacles encountered, and an overview of the complexity involved in compliance.

The certification file must be made available to ANSSI. The file represents a showcase for ANSSI with respect to the VOI’s compliance with the MPL—and it pays not to cut corners! The VOI must demonstrate the gains made in security and the clear validation of the theoretical responses to compliance.

Maintaining a high level of security over time

Creating a certification mindset

Certification doesn’t end when the certification decision has been made and the system put into production. This only marks the start of the risk-management process. It’s then a question of maintaining momentum, increasing visibility, and ensuring the ongoing management of security. Certification must be renewed at least every three years, or during periods of major change to the VIIS, something that forces a reconsideration of whether the VIIS is actually secure in the way described in the risk analysis.

Therefore, for an existing VIIS, a process needs to be set up to monitor and identify security-related changes to it. This must be carried out in the context of an organizational structure, for example with a named person holding the responsibility to identify and assess any changes. This person, can, in particular, establish a list of key events, for example: changes to the level of exposure of the VIIS, the arrival of new Service Providers, functional developments in the VIIS, or modifications to infrastructure or operational management); these will provide a basis for assessing any requirements for the system to be overhauled.

The establishment of a certification governance committee ensures a degree of momentum in the certification process. Updating the methodology for integrating security into projects enables new projects to be taken into account, risk management to be applied from the beginning, and advance preparation for VIIS compliance.

Providing a clear and understandable framework for application owners

Application owners are key players in maintaining security and certification over time. This is not just because they have a good overview of their VIIS, but also because they are aware of developments to it. If their attitude is one of fear of the MPL, this can lead to a poor approach to security. Conversely, a good understanding of MPL issues, certification, and continuous improvement, can enhance VIIS security.

Special attention should be paid to supporting application owners, and raising their awareness about security in general, and the certification process in particular. To achieve a win-win approach, and improve security over time, you must bring application owners together and get their buy-in.

Security certification: an approach that enhances risk management over time

Beyond essential regulatory requirements, the MPL has to be seen as a catalyst that can enhance risk management within a VOI: from operational level, through application owners, right up to the senior management.

After taking the first step of overhauling and implementing risk-reduction measures on an existing VIIS, certification ensures that levels of security are maintained right across it. Given this, it’s vital that the players involved remain engaged over time to ensure that the initial momentum is maintained.

Cet article Security certification: the key to complying with the french military programming Law (MPL) est apparu en premier sur RiskInsight.

En effet, le processus de souscription constitue le pilier fondateur d’un transfert de risques réussi. Il est donc primordial pour toute entreprise désirant franchir le pas de la cyber-assurance de connaître toutes les caractéristiques d’une telle opération.

Quels sont les acteurs majeurs de ce processus ?

Les acteurs du processus de souscription sont peu nombreux et bien définis. Participent aux négociations :

• Le client : il s’agit d’une organisation ou d’une entreprise souhaitant disposer d’une prestation (généralement financière) en cas de survenance d’un incident. C’est lui qui exprime le besoin, que ce soit par ses Risk Manager, ses RSSI, sa Direction Générale ou encore ses acteurs métiers.
• Le courtier : il est l’intermédiaire entre le souscripteur et l’assureur, et joue de ce fait un rôle central tout au long du processus. Il base son travail sur une excellente connaissance du marché et du besoin remonté par son client.
• L’assureur : il crée les polices d’assurances, en définissant leurs périmètres de couverture, leurs plafonds de garanties ainsi que leurs primes ou franchises. Ces paramètres sont toutefois largement négociés et fortement corrélés avec la maturité du client.

Comment se déroule le processus de souscription à une cyber-assurance?

En premier lieu, le client doit faire le point sur son besoin et confronter les risques résiduels identifiés comme nécessaires à couvrir avec ceux déjà couverts par une assurance. Pour ce faire, une analyse de risques récurrente et un bilan assurantiel (évaluation de la couverture actuelle et des manques) impliquant toutes les parties de l’entreprise sont nécessaires.

Dans un second temps, il convient de choisir le courtier le mieux à même de répondre aux attentes du client. Dans le contexte de grandes entreprises, il sera jugé sur son expertise sur le sujet cyber, sa capacité à offrir une couverture multi-assureurs et des modalités de son accompagnement au cours des différentes étapes, du choix à la vie du contrat.

Courtier et client échangent alors sur la nature même des risques à traiter, ainsi que sur la maturité de ce dernier. Le courtier identifie ensuite, grâce à sa connaissance poussée du marché, les assureurs les plus à même de répondre au besoin.

Le client et le courtier présentent ensuite à l’assureur leurs exigences en termes de périmètre de couverture et de plafond de garantie. Dans le cas de montants très élevés, le courtier peut mettre en place des montages d’assurances qui permettent d’atteindre des plafonds plus élevés que ceux proposés dans les offres standards. En réponse, l’assureur évalue la maturité du client, par l’intermédiaire de questionnaires ou par une analyse de risques. L’assureur propose alors un montant de prime d’assurance en fonction de la maturité observée chez le client. Ce montant, qui varie généralement entre 1 et 5% du plafond de la garantie, est ensuite négocié entre les différents partis.

Le périmètre de couverture, le plafond de garantie et le montant de la prime constituent la police d’assurance.

Comment faire vivre le contrat ?

Le contrat reposant essentiellement sur le code des assurances français, le client est tenu à certaines obligations vis-à-vis de l’assureur, notamment sur le devoir d’information en cas de modification significative des risques sur son système d’information. Cette obligation se concrétise généralement par des réunions annuelles entre l’assureur, l’assuré et le courtier dans le but d’établir un bilan de l’évolution de la maturité du client et d’adapter le contrat en conséquence.

La souplesse dans l’évolution du contrat a deux principaux intérêts. Pour le client, il est de faire baisser le montant des primes en améliorant sa sécurité. Pour l’assureur, il est d’adapter le montant des primes en fonction de l’évolution du risque. Cette démarche encourage et valorise donc les travaux effectués en faveur de la sécurité du SI.

Comment déclencher les garanties ?

Les délais de notification en cas d’attaque constituent l’élément central du déclenchement. Le code des assurances rappelle : «L’assuré est obligé de donner avis à l’assureur, dès qu’il en a eu connaissance et au plus tard dans le délai fixé par le contrat, de tout sinistre de nature à entraîner la garantie de l’assureur. Ce délai ne peut être inférieur à cinq jours ouvrés » (Article L113-2). En cas de faute vis-à-vis de cette règle, le client peut se voir refuser ses garanties. L’enjeu est donc d’alerter au plus tôt l’assureur, même s’il n’y a que suspicion d’intrusion, mais aussi de cadrer les preuves à recueillir pour l’indemnisation – et ce dès l’établissement du contrat. Le déclenchement des garanties et le déblocage des fonds ne peuvent se faire que si  l’assureur a été notifié dans les délais, et l’évaluation du sinistre réalisée.

En fonction des assureurs, la mise à disposition d’experts peut relever d’une option ou ne pas être proposée. Le souscripteur doit par ailleurs veiller à bien préciser les modalités d’intervention de ces experts (obligation d’utiliser les prestataires de l’assureur, …).

Le processus de souscription est donc bien identifié et cadré. La connaissance la plus fine possible du marché ainsi que de ses propres risques sont des atouts indispensables pour bien choisir sa cyber-assurance. Cette dernière gagne considérablement en souplesse de négociation (périmètre, plafond, prime) de par la nouveauté de son marché, de son évolution rapide et de la concurrence naissante.

Retrouvez tous nos articles sur le secteur de l’assurance sur Insurance speaker, le blog assurance des consultants Solucom

Cet article Souscrire une cyber-assurance : mode d’emploi est apparu en premier sur RiskInsight.