Due to a lack of internal resources or expertise, it is still common to see configuration errors, such as a publicly deployed Storage Account or S3 bucket, allowing attackers to access and exfiltrate the data, or Network Security Groups that have not been properly configured to restrict flows, allowing attackers to compromise the cloud account through the exploitation of uncontrolled flows.

These misconfigurations create new surfaces of exposure and provide attackers with new ways to compromise IS.

Ensuring secure and controlled use of cloud services is a major challenge, which requires specific skills and appropriate governance.

What is cloud security posture management?

Cloud security posture management is a set of strategies and tools to reduce the security risks associated with cloud usage. This is achieved by implementing controls on the configuration of resources as well as mechanisms to react in case of detection of a deviation from good practices.

There are 4 main pillars in the management of the cloud security posture:

One of the first steps in managing the cloud security posture is to understand the entire environment; inventory and classification of resources, compliance indicators, risk visualization dashboards, etc. This overview makes it possible to identify the exposed surface of the environment and to prioritize the work to be done.

Effective cloud security posture management relies on several tools that automatically detect resource configurations that do not comply with good security practices. Most of the tools allow companies to assess themselves against standards and norms (CIS, GDPR, HIPAA, …) and thus identify gaps between the current environment and the target to be reached. In addition to the generic security rules proposed by the tools, companies can also integrate rules specific to their context in order to refine the controls carried out and thus build their own security framework.

Cloud environments offer advanced industrialization and automation capabilities that enable the rapid deployment of new solutions to reduce time to market, the time it takes to bring an idea to fruition and deliver a finished product to consumers. In this context of rapid evolution, it is necessary to ensure continuous monitoring of the environment in order to be able to react as quickly as possible when a non-compliant resource is deployed: quarantine of the resource, automatic remediation, etc.

One of the challenges of security is to succeed in integrating it as early as possible in the project cycle, in order to limit the impact of misconfiguration of a resource. To give an example, as part of the management of the security posture, it is possible to integrate compliance controls from the development phase with the integration of Terraform or CloudFormation template analysis in the CI/CD chains. Note that this step requires advanced maturity and mastery of the other three pillars mentioned above.

Focus on CSPM tools: which type of tool for which use case?

CSPM (Cloud Security Posture Management) tools are a range of software that can assist companies in managing their cloud security posture. There are many of them on the market, which we will distinguish into 3 main categories:

• Tools from market publishers (e.g., Prisma Cloud, Cloud Conformity, Cloud Health, CloudGuard, Zscaler, Aquasec…)
• Native tools from cloud providers (e.g., Microsoft Defender for Cloud & Azure policy, AWS config…)
• Open-source tools (e.g., Cloud Custodian, ScoutSuite…).

Although these tools have a common objective, there are many differences, and it is important to study the impacts in order to determine the most appropriate solution for the local context. Some examples of points of attention when selecting a CSPM tool:

Governance and administration of the tool:

What resources are available to facilitate the management of the tool (e.g., available roles and RBAC model, implemented processes, management interface, possible interconnections, etc.)?

Tool coverage:

Is the tool single or multi-cloud? What services are supported? What security rules are implemented in the tool?

Tool features:

What are the dashboard capabilities? Is it possible to set up alerts? Some CSPM tools specialize in one or more of the security posture management pillars mentioned above or are more mature for one cloud provider than for others. It is important to study the features offered by each tool to ensure that it covers all the desired use cases.

Ease of deployment:

How is the tool deployed? How long does it take? Is the tool available in SaaS mode or does it require the implementation of a specific architecture?

Ease of use:

How is the user interface? This criterion is particularly important because some tools, although very flexible, require specific skills (e.g., scripting) and may require detailed knowledge of the subject.

Available support:

Are security standards updated automatically? How long do new cloud services take to implement after they are released? The cloud is a very evolving environment, new services are regularly made available, implying new security risks. The ability of a CSPM vendor to adapt to its customers’ evolutions by proposing new rules and supported services is therefore a major asset.

Pricing:

What is the pricing model? Do we have to pay per resource? How many people are needed to administer the tool? Depending on the tool chosen, prices can vary widely. Particular attention must be paid to the choice of a solution that is well sized in relation to the expectations expressed. 

Based on these criteria, it is possible to observe major trends shared by tools in the same category.

To summarize: CSPM tools from market vendors offer a lot of functionality that is easily deployable but not very customizable.

Native CSPM tools from cloud providers are easily integrated into the existing ecosystem and have cloud provider-specific functionality, which does not always cover all needs.

As for open-source tools, they have the advantage of being very flexible and giving the user a great deal of leeway, but these tools are complex to maintain over time and require specific skills to be deployed and used.

Choosing the most appropriate type of tool therefore requires identifying the challenges specific to one’s context and studying how each type of solution responds according to its characteristics.

Here are some examples of questions an enterprise might ask when selecting a CSPM tool: Is the enterprise’s security posture management maturity appropriate for its current use of the cloud? If not, is the delay in tooling or in the definition of security best practices in a Group framework? Does the company have the internal skills to ensure that the management of the security posture evolves at the same speed as the business needs of cloud usage?

Indeed, the choice of a CSPM tool must be part of a more global process of managing the security posture, in other words, by relying on the company’s local governance and expertise capacities.

CSPM industrialization: the key steps

Implementing an effective security posture management is a long process with several steps. Any company wishing to gain in maturity on the subject must define an industrialization strategy allowing to progressively reach the target. The following chart is an example of an industrialization strategy:

This consists firstly of the initial compliance of the cloud environments to secure them. This phase can be carried out using cloud native CSPM tools or using a tool from the market. The advantage of these tools is that they provide a framework and generic security rules on which a company with little experience in this area can rely. In order to capitalize on the tool’s feedback, a governance and action plan must be put in place to:

• Prioritize the identified projects
• Define indicators for monitoring compliance (e.g., percentage of resource compliance by service and/or by criticality)
• Support projects in bringing their environment into compliance by providing them with the necessary elements to remediate non-conformities

Once the desired minimum level of security has been reached (or in parallel with the initial compliance), one of the next challenges is to ensure that new cloud projects do not create new vulnerabilities. It is therefore necessary to set up a structure to support development teams in their cloud projects. This structure should allow the following:

• Maintain a group cloud security repository that is adapted to the company’s context and evolves with the demands of new business use cases
• The implementation of security validation processes (automated or not) in order to validate the various project stages (cloud eligibility, transition from development environment to production, etc.)
• Security monitoring of cloud services used within the company

The first two steps allow to secure the existing and future evolutions.

The next two steps aim to add a layer of additional validations and controls to perpetuate the use of best practices throughout the organization. In order to implement a generalized continuous monitoring, it is preferable to initially focus on a test perimeter; this test phase allows to:

• Test a new approach in terms of monitoring infrastructure. Technically, this means setting up the CSPM tool(s) needed to ensure both spot audits on a specific perimeter and continuous monitoring of the entire test perimeter. From an organizational point of view, this translates into the implementation of validation processes and specialized teams.
• Define organization-wide control points and mechanisms to ensure their durability: management of the life cycle of security rules, definition of remediation actions per rule, etc.
• Prepare the scaling of continuous monitoring.

Based on the feedback from the previous test phase, the scope of continuous monitoring can then be extended to industrialize the management of cloud security posture within the organization.

The last step corresponds to the last pillar of cloud security posture management, anticipation, and therefore the implementation of advanced features to improve existing practices. Security is integrated upstream of the production launch, i.e., on the left side of this cycle, which is called the “shift-left”.

Synthesis

Managing the cloud security posture within an organization is a major challenge with strong impacts requiring a progressive and incremental implementation.

By relying on the four pillars of security posture management – Visualize, Control, Monitor, Shift-Left; companies are able to ensure the compliance of their cloud environment while following the needs and changes of the business. This objective requires dedicated governance and tools adapted to the local context, all of which evolve with the company’s cloud security maturity.

There are many CSPM solutions available and each one has its own benefits and disadvantages. Particular attention should be paid to the study of the solution that is best suited to the needs expressed and to the future developments envisaged.

Cet article Cloud security posture management: towards an industrialization of the control of its cloud environment est apparu en premier sur RiskInsight.

After having successfully mobilized its executive committee on cybersecurity, having made a realistic and concrete assessment of the situation, you had an agreement in principle to start a remediation program!

A great victory, and the beginning of a multi-year adventure!

Defining ambitions and framing governance

The cybersecurity assessment and its benchmark have enabled us to position the organization’s current level of security. What remains now is to define the target to be reached and the means necessary to achieve it. This involves working with the cybersecurity teams, the IT department and of course the executive committee sponsor! The target can take many forms, but it must in any case respond to clear and concrete business challenges:

“To have an above-average level of security overall to avoid the most frequent attacks”, “To protect the data of large public customers”, “To ensure the resumption of factory production in less than 4 days in the event of a cyber attack”, or for more mature structures “To rationalize cyber investments by saving 20% for the same level of risk”, these are just a few examples of ambitions encountered in the field.

It is at the time of this target definition that we can adopt a risk-based approach, for example with different targets between businesses or entities; a regulatory approach with different levels depending on business constraints or a global approach.

Each target will be the subject of performance or risk indicators (KPI/KRI) to specify how progress will be measured. These ambitions are then translated into a concrete positioning on a cybersecurity benchmark, by theme and by scope. The easiest way to do this is to use the results of the previous benchmark, but it is possible to use another benchmark. Be careful, however, it will be used throughout the program to monitor progress and guide the various teams and entities, so plan on a lifespan of at least 2 years! The definition of the repository and the indicators is a key step in the success of the program, so plan to devote time to it. It is best not to immediately launch a whole series of technical projects without the necessary consistency.

To manage this program, the CISO must know how to surround themselves with people. The IS (Information Security) departments rarely have the experience to carry out such a transformation and budgetary requirements at this level. A good practice is to identify an experienced program director within the organization, who is used to the workings of the organization, and who can work closely with the CISO. The skills of the two profiles will naturally complement each other, on the one hand with security expertise, and on the other with large-scale management expertise. The choice of the binomial is also an important key factor of success, do not hesitate to spend time on it!

Build budgets on clear axes and know how to commit expenses

Once the agreement in principle has been received, the next step is to clearly structure the budgetary commitment. Once again, the major challenge in the relationship with the executive committee will be to make a clear and precise proposal: Acronyms, project codes and other abstruse terms should be avoided. The structure of a simple strategy; “Protecting the digital work environment”, “Encrypting and avoiding critical data leaks”, “Detecting attacks on our key assets” are some examples of terms used successfully.

The structuring of a program should be kept to around 4 or 5 axes and to group about 30 projects  maximum is something to keep in mind. Beyond that, reporting and monitoring will become too complex.

It should be noted that it will be necessary to break with the budgetary exercise obviously on the construction actions (“build”) but also on the additional operating costs (“run”) without that, the beautiful remediation will not last long… The identification also of the HR elements (number of recruitments/mobilities, trainings to be envisaged, salary evolution, evolution of the hierarchical relations in the entities or the subsidiaries…) are key elements to be created in the program to ensure its durability in time. This is clearly the right time to create a real cyber department within the organization and have it managed by a “Chief Operating Officer” like any other major department.

The preparation of these different budgetary elements will also have to consider the difficulty observed for several years now to commit the budgets obtained. The market is in dire need of cyber expertise and many projects have to be postponed. It is a good idea to take some leeway in the planning process to consider this situation, which will continue. The classic program timeline of, year 1 scoping, year 2 implementation, year 3 control, should be reviewed and instead be based on waves of smaller projects that are initiated as they come along. In short, it is better to have 5 waves of 5 projects that come to fruition than to launch 25 scopes simultaneously!

It should also be noted that these budgets and priorities will have to be reviewed annually, as the cyber threat is very dynamic, it is important to keep flexible budget lines to adapt to an unprecedented evolution of threats – as we have experienced in recent years.

Show progress to the executive committee!

Once the program has been launched, the challenge will be to show the executive committee the progress and the effects on risk levels. On a quarterly or even a semi-annual basis there are key points that need to be established: clear reporting, using simple terms that are linked to the reference system used, adding a vision on the progress of the projects and the progression of the risk level.To directly demonstrate the transition to regular reporting mode, it may be useful to add operational indicators linked to the level of security. In the long term, the challenge is to maintain an exchange with the executive committee at least every six months in order to maintain the level of attention on the cyber subject. These long-term exchanges can be structured around two annual meetings, one on risks (evolution of the threat and risks weighing on the organization), the other on investments (effects of projects, budgetary and HR issues for the following year).

Finally, the most advanced structures and those whose core business is based on digital technology can consider using their cybersecurity investments as business differentiators! Today, the cybersecurity requirements of customers, both large public and professional, are increasing rapidly. It is possible, and even desirable, to enhance the value of investments made to show that the subject of cybersecurity is a priority for the organization! For some organizations, cybersecurity may even become a profit centre, which will clearly change the discussions with the executive committee.

Cet article Creating a relationship of trust with your executive committee: step 3, make the transformation a reality! est apparu en premier sur RiskInsight.

ORGANISING A CYBER CRISIS EXERCISE IN A LARGE COMPANY 

There are many reasons to organise a Cyber crisis exercise: evaluating the integration of Cyber security in the crisis management system, improving interactions between the different teams, and testing the capacity of the security division to make itself understood by top management. 

From a simple table-top process test to SOC/CERT training to a large-scale exercise involving dozens of crisis teams and months of preparation, the resources allocated to a crisis simulation vary greatly. This article focuses on the last category. 

WHAT’S A TYPICAL CRISIS EXERCISE? 

Looking at the figures, some of the largest crisis exercises in France have consisted of one day of activity, 150 people mobilised, 10-12 crisis teams in several countries, 30 facilitators, 20 observers and more than 300 stimuli. Being able to make a success of such an event requires both a high level of preparation and a very solid facilitation team on the D-day. 

One of the key issues found in these types of exercises is that there is only one take. It is therefore essential that ALL the actors take part in the game, and that the scenario involves all the participants. Preparation and facilitation are key in such exercises to make sure the time spent on the simulation is worthwhile.  

SIX MONTHS TO PREPARE 

1/ Selecting the attack scenario 

The first months of work are always devoted to the attack scenario. Ransomware, targeted fraud, attacking suppliers… the choice of weapons is large. In ambitious exercises, it is not rare to combine several attacks in one crisis: smoke screen launched by the attackers, identification of a second group during the investigation, etc. Whatever the scenario chosen, the key is to be as precise as possible: 

• What are the attackers’ motives? 
• What path of attack did they take? 
• When was the first intrusion? 

The exercise is long and preparation beforehand is needed, especially when 150 players investigate an attack for several hours. Spear-phishing, water holing, code compromise, privilege escalation: the vulnerabilities used by the fictitious attacker are not real, but they must be plausible and “validated” by technical accomplices throughout the preparation. Similarly, for business impacts, they should be reviewed with business specialists: the level of fraud at which the situation becomes critical, critical activities to be targeted as a priority, most sensitive customers, etc. The choice and involvement of accomplices are essential and they should be integrated into the coordination team on D-day.  

2/ Building the script of the exercise 

The script consists in defining minute by minute the information that will be communicated to the players. The calibration of the exercise rhythm is a complex point. The temptation to impose a strict rhythm is great to “master” the scenario but attention needs to be given to leave enough space for reflection.  

The start of the exercise is another complex point: should the scenario start directly in a crisis situation or on an alert that will test the general mobilization process? Most often than not, the second option is chosen. That way, the technical teams (CERT, SOC, IT…)  can be mobilised for the entire duration of the exercise. ExCom members should have their diary freed up during that day as well.  

3/ Preparation of the stimuli 

Technical reports, fake tweets, messages from worried customers, these are all useful stimuli for the players.  

Videos are often used to captivate. Indeed, nothing is more striking than a fake BBC report relaying the current attack (logo, board, etc. the more realistic the better). For more realism, videos of people “known” in the company (message from the CEO, interview of a factory boss, etc) can be used.  

The same goes for the technical side: the duration of the exercises often does not allow the players to carry out the technical investigations themselves, but they will ask a lot of the facilitators. Everything must be ready to avoid panic: Malware analysis reports, application log extracts, IP address lists, etc. 

As mentioned in the introduction, the most ambitious exercises may require the creation of 300 stimuli to get through the day and remain credible – is represents a lot of work.

D-DAY 

On D-Day, early morning, a meeting is organised with all the animation team and observers for the final adjustments. A few hours later, the observers will go to their crisis cells and start the players’ briefing. 

1/ Starting on a good basis 

For many players, this may be their first exercise. The briefing is therefore essential to avoid confusion between fictional and real-life events:  

• Players call the police in the middle of the exercise

• The players contact a mailing list of 400 people without specifying that it is an exercise

• Real customers be called to be reassured

• A production site is neutralized “by prevention”

To avoid such situations, it is essential to iron out the rules of the game during the briefing: the players must communicate with each other, but they must go through the facilitation unit to contact external stakeholders. Throughout the day, the facilitators and accomplices in each team find themselves in the shoes of a client, a technical expert, a CEO, or a regulator, according to the players’ requests.  

2/ Rely on an efficient facilitation team 

The sequence of events depends on the efficiency of the animation cell. A successful exercise includes a lot of improvisation on the day. Stimuli may have to be readjusted according to the reactions of the players, the score is never fixed and the facilitation cell will be put to the test on the day of the exercise. The largest crisis exercises have particularly professional crisis management teams, including the head of the facilitators, PMO, technical manager, business manager, call management centre, etc.  

We suggest not to take any risks on D-Day and to recreate teams that are used to working together and know each other. Doing so is the best way to gain time that will prevent the organisation team from going into crisis itself. 

Cet article Organise a cyber crisis exercise in a large company est apparu en premier sur RiskInsight.

However, how to model these different FAIR input data?  How to compute with these data? Are there tools to simplify their collection or estimate their quality, and what efforts do they require to be implemented?

Having seen previously how trustworthy the risk quantification method was in its processes, let’s now see how the inevitable part of subjectivity can be isolated, and which facilitators can help to obtain reliable results.

The FAIR fuel: data

The risk analysis proposed by FAIR (according to the standardization document published by openGroup)[3]  is carried out in four stages:

• At first, in a fairly conventional way, it is a question of specifying the scope of the examined risk : what is the asset (subject to risk), what is the threat context (agent and scenario), and what is the loss event (the dreaded event in terms of losses);
• The second step (called Evaluate Loss Event Frequency) aims at collecting all the frequency data related to the loss event (and thus intimately linked to the threat agent). This consists of collecting the values for the left branch of the arborescence below.
• The third one (called Evaluate Loss Magnitude), because it assesses the loss, is focused on the asset. It is then a question of estimating the various primary losses (i.e. the inevitable loss in case of risk occurrence) and secondary (or possible loss, i.e. not occurring systematically when the risk advent). Its goal is to collect the values of the right branch in the tree below.
• Finally, the last step (called Derive and Articulate Risk) consists in merging the collected data as defined in the FAIR tree by the various calculations, to obtain the result in the form of usable outputs.

Link between FAIR analysis and taxonomy

Without detailing more the taxonomy, already discussed in the article presented before2, one can note that the standard analysis of a single risk requires seven data  (corresponding to the elements at the base of the tree):

1. Contact frequency;
2. Possibility of action;
3. Threat capability;
4. Resistance strength;
5. Primary loss magnitude;
6. Secondary loss magnitude;
7. Secondary loss event frequency.

It should be added that FAIR invites to decline losses (primary and secondary) into six categories (in order to ease and accurate estimate of the loss):

• The production losses: related to the interruption of the service produced by the asset;
• The response cost: related to the incident response;
• The replacement costs: related to the replacement of damaged constituents of the asset;
• The fine/judgement costs: related to fines, court fees and legal proceedings;
• The financial impact on competitive advantage: related to the impact on the organization in its sector;
• The reputation costs: related to the impact on the public image of the organization.

How do we correctly model risk uncertainty?

Furthermore, it is good to ask the question of what a FAIR data is actually.

Indeed, it is too reductive to define a data by a single numerical value. For example, lets consider a ransomware attack: it would be incorrect to say that an occurrence of this risk would cost exactly 475k €[4] (illustrated by the blue curve on graph 1).

Graph 1: A distribution, a more realistic model than a single value

However, adding uncertainty to this data by accompanying it with a minimum value (which could be  1€ in our example) and a maximum one (of  300 M€ in the same example), while keeping the most likely value stated above, would allow to model much more accurately the reality (purple curve of graph 1).

A data is then defined by a minimum, a maximum and a most likely value (corresponding to the peak of the distribution). We can also, note that such a probability distribution is independent of the kind of values considered: it may as well be a loss in any currency  (cf. the previous example), than an occurrence (for example, between once a year and once every 10 years, and a value more likely around once every two years), or even a ratio (between  30% and 70%, more likely 45%). Hence, we can use these distributions to model all the  data of the FAIR taxonomy.

Another advantage of predicting uncertainty through distribution is that it is possible to fine-tune the degree of confidence in the most likely value, via the kurtosis coefficient of the curve. The higher it would be, the greater the data will be trusted (corresponding to a very marked peak, see the green curve on graph 2). On the other hand, an unreliable data will be modelled by a much more homogeneous distribution (see the red curve on graph 2).

Graph 2: Reflecting the level of trust through distributions

However, using distributions rather than fixed values is a problem when it comes to combine them, which will necessarily be the case when we will make the computations of the FAIR tree. As we can indeed see on graph 3 (the addition of the green distribution and the red one giving the violet), the addition of two distribution does not allow to obtain a distribution as ‘simple’ as the previous ones (it no longer follows a log-normal distribution). This is also the case in the context of a multiplication (the result of which is also complex).

Graph 3: addition of two distributions.

To obtain a mathematically consistent result, game theory gives us a simple way: The Monte Carlo simulations. It is in fact a matter of dissecting the distributions (the green and the red of the graph 3), in a predefined number of random values (called number of simulations), distributed in such a way as to correspond to the given distribution. We can then combine the distributions thus dissected by performing the calculations on pairs of values of each distribution. The new distribution can then be approximated, and will be all the more precise as the number of simulations will be large.

Hands on toolboxes to automate FAIR…

To make these calculations and obtain a numerical value of risk, solutions have emerged (mainly from the FAIR method). We will therefore address here the pros and cons of these tools, which are also cited in the previous article1.

The OpenFAIR Analysis Tool

The first we can cite hire is the OpenFAIR Analysis Tool[5]. While this tool has a pedagogical purpose, it nevertheless helps to understand how FAIR works. It is thus possible to have a first concrete application of the method, and to obtain simply results (only for the analysis of a single risk). Developed by the University of San José (California) in collaboration with the OpenGroup, this tool relies on an Excel sheet to obtain a risk assessment from a predetermined number of  simulations, scrupulously respecting the FAIR taxonomy.

OpenFAIR Risk Analysis Tool: a tool that is first and foremost educational

Very useful to have a first contact with quantification, this tool remains however very limited in terms of use. Finally, one should note that Excel is needed, and it is only accessible with an evaluation license limited to 90 day.

Riskquant

For a larger scale use, Netflix’s R&D department has developed Riskquant[6] solution. It is a Python programming library, relying more particularly on tensorflow (a specialized python module for massive statistical calculation). Riskquant’s particularity is to propose a quantification of risk inspired by the FAIR taxonomy, but with a great freedom in its approach and its implementation. Developed to facilitate the use on containers, it would allow by its design very fast evaluations from csv files.

Riskquant: an original approach but lacking maturity

However, keeping of FAIR taxonomy only a single loss value and a single frequency makes it not very usable, especially in the context of an organization that would seek to precisely scope its risks. In addition, it provides so far only a few exploitable results and clearly lacks maturity. Finally, it seems to have been dormant since May 1^st, 2020 (the date of the last commit on the GitHub page of the solution).

PyFAIR

To conclude on this paragraph on solutions that can be used for a basic implementation of FAIR, the PyFAIR library is available on the official python repository (downloadable via the pip tool). Now mature, the tool allows a decomposition of risk according to the FAIR taxonomy. It also allows the feed of the FAIR tree with intermediates values, or the aggregation of data that can be used for several risks (e.g. allowing groupings by asset or threats). It is capable of calculating overall and global risks, and provides easily usable distributions (exploitable with other simple python modules), but also gives access to advanced charts and HTML pre-formatted reports.

PyFAIR, a complete and efficient library in Python

Although it remains a programming toolbox, hence requiring an appetence and time to develop and maintain a Python solution, PyFAIR is well-designed. It facilitates the implementation of FAIR by staying very close to the taxonomy, and provides functions facilitating implementation and the exploitation of the results. Suitable to be operated on multiple levels (i.e. using it only to calculate results by influencing the fine settings of FAIR and Monte Carlo, or by exploiting its high-level reporting functions), it makes it possible to envisage a use of quantification technically facilitated and on a large scale.

‘Turnkey’ platforms to make data acquisition easier:

Nevertheless, the main difficulty of FAIR remains, as we have seen before, obtaining the data and their trust level. To deal effectively, the most efficient solution is to rely on a platform that integrates a CTI database.

These platforms provide risk threat statistics (very few company-dependent). They also support in deploying and implementing the quantification method in the organization, which includes a guidance in obtaining the appropriate loss data.

RiskLens

The first of these solutions is the RiskLens[7] platform. This solution, directly derived from the FAIR methodology, was co-founded by Jack Jones. It is used as technical support for the development of the method, linked to the FAIR Institute. Emphasing on a technical approach of the method, it focuses on the respect of the standards of analysis  in general  and the definition of the perimeter (first  step  of FAIR) in particular.

RiskLens, FAIR’s application to the letter

Nevertheless, it should be noted that, on the one hand, this solution requires advanced notions in the FAIR methodology to be easily operable. Indeed, the platform does not provide a consequent help in obtaining data (which, as we have seen, remains the keystone of quantification), on the basis that the definition of the perimeter is enough to define precisely the data, and thus to obtain it easily. On the other hand, it is an American platform, which implies that the interface (quite unintuitive) is only available in that language, and that the data collected is also subject to U.S. regulations.

CITALID

The second platform we will mention here is the French startup CITALID, whose approach is fundamentally different. Indeed, it has been founded by two ANSSI analysts, who wanted to link the CTI to the risk management. Thus, using FAIR as the tool to make this link, it makes its effort on the conception and the maintenance of the database, made of solid figures kept up to date, to closely monitor the local and international cyber geopolitical situation.

CITALID, a high value-added database

The CITALID platform provides real support in the definition and the collection of the FAIR data, thus allowing to identify precisely where is the remaining part of subjectivity undeniably linked to risk. Available in French and English, it facilitates the management of cyber risk by taking into account all the parameters of the organization (location, size, sector of industry, level of maturity, compliance with standards, etc.), to provide data originating from appropriate contexts. Furthermore, and in addition to an interactive explanation of each of the platform’s fields, the startup supports its customers in collecting the needed inner data of their organization.

First step with FAIR…

Anyhow, the difficulty will always be to succeed in the transition from qualitative to quantitative estimation. Even if solutions can facilitate this shift, leaving a controlled qualitative method for a new unassimilated assessment method remains a challenge, despite all the benefits the new method promises.

If three points were to be highlighted to pursue on the quantitative way, they could be:

• First, to make sure the required maturity is reached. Quantification requires a good understanding of the level of security of the concerned IS, and a pre-existing and well-established risk management method. If quantification provides solutions to assess the cost of a risk, provision it or estimate  the  ROI  of a measure, it is however useless  (or even counterproductive) to embark on this path too early (at best it will be a waste of time, at worst it will degrade the existing risk management process).
• Then, to have a gradual approach in the deployment of quantification. In a mature IS with stable risk management, it is preferable to gradually adopt the quantitative method. This allows to gain confidence in the estimates produced (potentially by making it coexist with the elder qualitative estimation method) and to assimilate the methodology, while ensuring its integration into the existing risk management workflow.
• Finally, rely on existing experience in collecting cyber risk data. As the difficulty stays confined in obtaining reliable data, it is crucial (to be confident in the method) to have trusted figures. It then seems appropriate make use of a platform that can provide data of quality, and a support in the collection of our own data. It will furthermore have more experience deploying the methodology to various customers. The quality of the provided results will then be the key element in the confidence that the organization will have in the quantitative method.

[1] https://www.riskinsight-wavestone.com/en/2020/11/quantified-risk-assessment-1-2-a-quantification-odyssey/

[2] https://www.riskinsight-wavestone.com/2020/06/la-quantification-du-risque-cybersecurite/

[3] https://publications.opengroup.org/c13g

[4] https://www.sophos.com/fr-fr/medialibrary/Gated-Assets/white-papers/sophos-the-state-of-ransomware-2020-wp.pdf

[5] https://blog.opengroup.org/2018/03/29/introducing-the-open-group-open-fair-risk-analysis-tool/

[6] https://netflixtechblog.com/open-sourcing-riskquant-a-library-for-quantifying-risk-6720cc1e4968

[7] https://www.risklens.com/

Cet article Quantified risk estimate (2/2): What data, what tools? est apparu en premier sur RiskInsight.

Testing is an important part of operational resilience and can take many shapes and forms, from disaster recovery testing for ensuring service continuity to end-to-end crisis simulations examining decision-making. It enables to proactively manage risk, embed crisis management framework, and allows to continuously improve capabilities such as business continuity (BC), crisis management (CM), disaster recovery (DR), and cyber resilience (CR). Needless to say, training plays an important role in such a testing programme.

“Better awareness nurtures an organisational culture that embraces operational resilience and, as a result, improves the company’s preparedness to deal with adversity.”

From firm to firm, good testing programmes vary in nature, scale and complexity. Depending on how a firm is structured and what it does, testing is addressed at different organisational levels and locations, with involvement of external parties (i.e. critical suppliers). In reality, given little guidance from the regulators on what ‘good’ looks like, programmes are often fragmented and can cause a real headache.

Principles for creating a successful testing programme

2. Start with threats

Every test needs to link to threat(s) resulting in one or several plausible major incident scenarios (and impacts). Anticipate and understand new threats through market watch and leverage audit reports and risk assessments when building or reviewing your programme.

 

3. Focus on Important Business Services (IBS)

Align testing of existing contingency arrangements to important business services and key processes. This ensures preparedness when a situation of high business impact occurs and avoids challenges arising from lack of end-to-end vision.

4. Diversify testing

The most likely and most impactful scenarios should be examined with different stakeholder groups through different types of testing. This ensures that the theory works in practice and different reflexes are embedded in the organisation’s DNA.

To achieve more benefits, go beyond standalone contingency plans and comms tooling testing and examine a combination of them with internal and external, business and technical stakeholders.

 

The radar above is an indicative example of what a good testing programme would consist of. The threat categories considered are random and could be selected differently as long as diversification is maintained (mix-and-match).

 

Crisis simulation

Crisis simulations examine a hypothetical disaster situation with defined parties and multi-cells of stimulus. They allow to rehearse the establishment and communication of recovery requirements and carry out relevant activities effectively. Crisis simulation can be a tabletop exercise (level 1), a hands-on simulation (level 2), a multi-cell hands-on crisis simulation (level 3) or an international hands-on multi-cell multi-party simulation (level 4).

Work area recovery testing

Work area recovery testing checks whether full end-to-end business processes can be run offsite, ensuring that all elements of a process can be completed during a test and not just the technical aspects. They can involve a team (level 2) or a number of geographically dispersed teams (level 3) working from recovery sites or home. Both third parties (i.e. outsourced teams) and internal teams should be considered.

IT disaster recovery plan and cyber range testing

IT DRP and Cyber range testing practically examines each step in a specific disaster recovery plan or tests cyber forensics capabilities. This ensures the possibility to recover data, restore critical IT system after an interruption of its services, critical IT failure or complete disruption due to cyber attacks or IT disruptions. This testing can happen as a standalone (level 2) or as part of a crisis simulation (level 3-4).

Business recovery plan walkthroughs

Business Recovery Plan walkthroughs for group/business divisions/business units are undertaken following a major revision of a plan or team and are designed to increase the understanding of the recovery processes, roles and responsibilities, and question the suitability and completeness of the plan. Normally this would be carried out as a review-and-challenge session with the plan owner and a BC expert (level 1) or to test the efficiency of the specific measures and planned workarounds (level 2).

Communication cascade tests

Communication cascade tests establish whether contact details are accurate, determine whether cascade roles and responsibilities are understood by staff, and establish whether or not the documented procedures are robust. They can be completed in one of three ways – either a standalone live test (e.g. text cascade; level 2), as part of a crisis simulation exercise (level 2-4), or an audit involving review of plans and interview of staff with key responsibilities (level 1).

5. Stay current

Review your testing programme at least once a year in order to adapt to the changing threats landscape and ultimately ensure operational resilience. Make sure your crisis management framework and contingency plans are regularly improved based on the testing outcomes and changes in the business.

6. Engage and drive

Involve different parties in shaping and running your testing programme (e.g. cyber, risk, Ops, DPO, legal, business resilience champions, etc.). Use MI to share progress and alignment with the 3-year operational resilience vision.

 

What next: how do you structure your testing programme?

While it is not possible to prescribe a testing programme without better understanding the organisation of interest and deep-diving into the specifics of a threat landscape, it is clear that investing time and resources is worthwhile from operational resilience and regulatory standpoints.

“Having recently gone through a pandemic, it is a high time to keep the momentum and continue fostering the right culture and correct reflexes for the next major crisis.”

A few concluding tips

• Make it realistic: Where maturity allows, aim for more complex and realistic tests as they are essential to effectively respond to real events and increase end-to-end resilience. This means engaging more internal and external parties in the ‘live’ exercises.
• Leverage internal and market crises: Continuously monitor events happening on the market (major incidents and crises) as well as your internal major incidents to feed your testing program, prioritise your threats and devise your scenarios making it more tangible for your stakeholders.
• Engage early: Share the vision for testing with key stakeholder groups so they understand the journey on which you want to bring the organisation. This will enhance collaboration and, therefore, outcomes.
• Facilitate remotely: Remote working arrangements should not put your whole testing programme on hold – use collaborative solutions or leverage tools from the market for carrying out the exercises. This is especially relevant for cyber range testing and follow-the-sun testing. Experience shows that digital workplace solutions introduce a more democratic participation and is an excellent way to record interactions.
• Continuously improve: Reflect on tests by producing post-test reports and defining an action plan to drive and track improvements. Involve key stakeholders throughout so they understand the gravitas of the outcomes and help with driving positive changes.

Cet article Test, test and increase your Resilience: how to build your testing programme est apparu en premier sur RiskInsight.