Poster Support for an Obeya-Like Risk Management Approach

Abstract

Lean management is trendy. This trend is also reaching risk management. It has become very concrete in France following the EBIOS-Risk Manager method publication by the French National Agency for cybersecurity (ANSSI) in October 2018. However, if the new method fosters an agile approach of risk management, it does not provide the tools to support the mandated brainstorming workshops. In this paper we propose a set of A0 posters (and A5 cheat-sheets) to support the efficient and user-friendly organisation of the EBIOS-Risk Manager brain-storming sessions. The workshop participants are given sticky notes and felt pens to actively contribute to the data collection work. A facilitator helps organise the emergence of contributions. This approach is inspired from the Japanese Obeya form of project management, with the goal of making risk management simple, dynamic and attractive, or in one word, fun!

Appendixes

These appendixes provide the template of some posters which were only rapidly discussed in the main part of this paper, as well as multiple examples of filled in posters from two case-studies. To allow for a better understanding of the posters, we first provide an overview of the two case-studies.

1.1 Overview of the Case-Studies

The A0 posters were designed and validated using a running example of a Thales internal cybersecurity course and two real business case-studies. These case-studies are presented below.

IFE case-study. The In-Flight Entertainment (IFE) case-study was constructed for a Thales Learning Hub (TLH) adult professional training course on cybersecurity. Therefore, by contrast to the other two case-studies, the IFE case-study does not claim to provide a comprehensive framing of the system. This case is a toy case built to support educational goals.

According to the specifications given in the cybersecurity course, the IFE must provide free games, music and films to the airline passengers. “Free” means that there is neither credit card nor financial issues. The scope limited to games, music and films means that there are no connections with the avionics (and thereof limited safety-related issues), and no connections to the internet. It is therefore a very basic IFE. There is however a performance requirement: IFE availability should be above 99%.

VLLAM/UTM case-study. The poster templates presented in this paper were used to run a Very Low Level Airspace Management (VLLAM) and Unmanned Traffic Management (UTM) case-study. This case-study, run during the first semester of 2018, was very useful to raise the maturity of the workshop n°1 to workshop n°3 poster templates. Indeed, the workshops 1 to 3 were run twice: once for the overall system of systems, and once for the geofencing capability. The outputs of this case-study are not shown in this paper.

SCADA IoT case-study. Thales Ground Transportation intends to introduce Internet of Things (IoT) devices in its Metro Supervisory Control And Data Acquisition (SCADA) system. This obviously raises some questions about IoT cybersecurity. This case-study, run during the second semester of 2018, was very useful to raise the maturity of the workshop n°4 and workshop n°5 poster templates. The results of this case-study are extensively showed in the appendixes of this paper.

1.2 A Bit More About Logistics

As mentioned in the core part of this paper, EBIOS brainstorming sessions typically involve between 2 and 4 persons, in addition or including the facilitator. When paper versions of posters are used, this means that the sessions can (and should) be organised in relatively small rooms, with at least one wall where posters can be hanged, at a reasonable distance (i.e. 2 to 4 m) from the workshop participants.

Before each session, the facilitator should hang the set of A0 posters required for the session (see next sections for details), and distribute to each participant: (i) a single A5 cheat-sheet that recalls the workshop objectives and provides some hints as to how the session is going to be run; some cheat-sheets also provide tips, or knowledge bases, such as a list of classical threat sources; (ii) a set of colour sticky notes; the choice of colours depends on the workshop, as explained in the core part of this paper; and (iii) a felt pen; we recommend a different colour felt pen per participant, so that it authenticates the contributor; we also recommend a medium-sized felt pen tip, so that the writing remains readable up to a distance of 4 m.

1.3 Complementary Poster Templates in Support of Workshop n°1

A feared event is the negation of a security need on a primary asset. The proposed poster template allows for the study of up to ten feared events, represented by the pink sticky notes. Below the feared events, the impacts of the event may be listed, using orange sticky notes, against a severity scale represented by a vertical arrow, spanning from low severity (in green) to high severity (in red). As for the security need scale on the first poster (cf. Fig.2), it is important to capture here the relative severity of the impacts, rather than their absolute severity value. Figure 14 shows an extract of this poster filled in for the IFE case-study.

The poster template in Fig. 11 supports the assessment of the implementation status of security controls. The poster is split in three sections corresponding to fully implemented controls, partially implemented controls and controls not implemented (from bottom-up).

In addition, the poster is split in three columns to allow for the classification of security controls. Thus, one would need three poster instances to cover the 7 families of functional requirements defined in IEC 62443-3-3 [13] … but we do not recommend dealing with too many details with the poster-based approach. An exhaustive analysis of hundreds of security controls will best be managed using some dedicated electronic tool.

1.4 Examples of Posters Produced During Workshop n°1

Figure 12 shows the first poster supporting workshop n°1 as it was filled in for the SCADA IoT case-study. To begin with, the study objectives were capture: (i) Identify and manage IoT-related risks, in particular to help design the future IoT devices in a secure manner; (ii) Establish a risk assessment baseline; and (iii) Establish an IoT migration strategy.

On this poster, we can see here that quite a large number of stakeholders have been captured, including regulatory bodies and public services.

In terms of primary assets, we can clearly see two large groups: on the right side of the security need axis, a group of assets with very strong integrity and availability needs to ensure the core mission of the system; on the left side, non-critical services and data. On the latter, the integrity and availability needs remain predominant, but some confidentiality and privacy needs also appear.

Upon starting the study, we were given one important input. The SCADA currently complies and should continue to comply with Security Level 2 (SL2) of the IEC 62443 standard [14]. This regulatory constraint was registered at the bottom left of the poster.

Figure 13 presents an example of the second poster supporting workshop n°1, applied this time to the IFE case-study. The IFE case-study is focused on the operational exploitation of the IFE, i.e. it excludes the development and installation parts of the system’s lifecycle. Thus, we have only identified the IFE maintenance operator(s) as organisational supporting assets. For IT supporting assets the list is more extensive. To keep the story short, let us just focus here on the supporting assets of the copyrighted content, i.e. films, music and games. In the IFE case-study, copyrighted content is a primary asset with obvious confidentiality needs. The copyrighted content exists physically in many forms, e.g.: (i) as an enciphered file in the USB stick that the IFE maintenance operator carries to perform content update; (ii) as a file in clear on the disk of the IFE data server; (iii) as a datagram in the cables and switches between the IFE data server and the Visual Display Units (VDUs); and (iv) as pixels and sound on the VDUs. Last but not least, we have identified three physical supporting assets: the aircraft seat, the electronic bay in the aircraft hold, and the airport perimeter.

The fifth and last section of the poster relates to existing or already specified security controls. In the IFE case-study, the NIST SP 800-53 standard [15] has been used, therefore the poster shows the NIST identifiers of the security controls, e.g. Device Identification and Authentication (IA-3), and Transmission confidentiality and integrity (SC-8).

For some controls, the poster also shows how these controls are/will be implemented. For example, IA-3 will be ensured using a classical Remote Authentication Dial-In User Service (RADIUS), whilst Transmission Confidentiality and Integrity (SC-8) will be ensured using the (now obsolete) domain-specific WAEA 0395 standard [16], and a diode on the USB connector of the IFE server.

The identification of supporting assets is important to later identify how the security needs of the primary assets may be breached. Each supporting asset has its vulnerabilities and may be attacked in its own way. If we stick to the example of the copyrighted content it is possible to: (i) mug the maintenance operator and snatch the USB key with the enciphered files of the copyrighted content during a maintenance operation; (ii) to steal the removable disk in the IFE data server with the copyrighted content in clear; (iii) to sniff the network; or (iv) film the VDU with a smart phone, whilst recording the sound via the jack plug.

The existing or already specified security controls are also important to later assess the likelihood of the aforementioned security breaches. For example, the existence of a RADIUS makes it a bit less likely for an attacker to spoof a VDU with its own recording device.

Figure 14 shows an extract of the workshop n°1 optional poster, filled-in for the IFE case-study. This cropped poster illustrates five feared events. For example, if we consider that copyrighted content needs to be confidential in the IFE case-study, then “loss of the confidentiality of the copyrighted content” or “a first-window feature films becomes freely accessible on the Internet” make two perfect examples of feared events. It can be seen here that the most severe feared event impacts relate to the violation of the confidentiality of the copyrighted content (1^st column) and to the violation of the confidentiality of the IFE developer’s know-how (5^th column). This is because the corruption of the content or the service leading to a safety event, e.g. the display of a malicious message such as “All passengers, please move to the rear of the aircraft” with its probable dramatic effect on the aircraft balance, is considered out of scope of this study, as it is normally already covered by the safety case. Following this work, the IFE system has been categorized as “Moderate” according to the NIST SP 800-53 standard [15]. This categorisation pulls a significant set of security controls, some of which are listed on the poster discussed above (cf. Fig. 13).

1.5 Complementary Poster Template in Support of Workshop n°2

Figure 15 shows the extra poster for workshop n°2. This poster extends the main workshop n°2 poster (cf. Fig. 4) to cope with additional risk sources. This poster may be used as often as required, however, up to now, in all our case-studies, a single instance of this extra poster proved sufficient.

1.6 Example of Poster Produced During Workshop n°2

Figure 16 shows the main poster for workshop n°2 filled in for the SCADA IoT case-study. It can be seen here that the most relevant risk sources are malevolent ones, essentially external, but the internal rogue employee is also highly considered. In the lower part of the poster, the objectives of the latter even appear as the most relevant adverse objective, i.e. Vengeance through sabotage and/or Denial of Service (DoS), and the self-creation of maintenance workload.

The poster also shows that two risk sources have been rejected: the competitor because he would have easier ways of acting, and the meteorological conditions, because of past experience with ruggedized equipment. As a consequence, the objectives of the competitor have been listed but obviously rejected.

1.7 Complementary Poster Template in Support of Workshop n°3

Figure 17 proposes a poster template to register all risks, as identified during workshop n°3. The main objective of this register is to allow for the referencing of risks by their number, under the format Rxx, rather than pull the often long description of the scenarios. In addition, the template allows capturing additional comments for each risk, which is something that was very much restricted with our poster-based approach up to now.

1.8 Example of Poster Produced During Workshop n°3

Figure 18 shows the first poster of workshop n°3 filled in for the SCADA IoT case-study. On the upper part of the poster, it can be seen that there are no critical stakeholders: when stakeholders have high privileges on the system, they are trustworthy, and if they are untrustworthy, then they do not have special privileges. Still, attention is called upon the local maintenance operators, third-party suppliers, direct sub-contractors, physical security services and company executives. The latter was commented as being particularly difficult to cope with, as it is often difficult to refuse access rights to one’s boss, even if he does not need it.

The lower part of the poster is used to capture how the risk sources will proceed to reach their objective(s), at a very gross-grain level, e.g. in the SCADA IoT case-study, “Mafia installs ransomware on an IoT device connected to the trusted network using spearfishing targeted at the maintenance operator”. It can be seen here that there are quite a few risks with a pretty high severity. Risks that relate to both integrity and availability are located astride the severity axis.

It should be reminded here that ultimately the criticality of a risk depends on both the severity of its impacts and the likelihood of its occurrence. At this stage the likelihood has not yet been studied.

1.9 Example of Poster Produced During Workshop n°4

Figure 19 shows a Cyber Kill Chain created for our SCADA IoT case-study. The upper part of the poster shows a full blown scenario, in which the attacker has significant cybersecurity knowledge to reverse-engineer the IoT device and exploit some communication vulnerability. The lower part of the poster shows an alternative path, in which social engineering is used to benefit from the collusion of a rogue employee. The social engineering path has been assessed as more likely.

1.10 Example of Poster Produced During Workshop n°5

Figure 20 presents the risk treatment poster filled in for the IFE case-study. It can be seen here that:

• risks R5 and R6 are accepted;

• risks R1 and R2 are treated by proposing the perform some media control and by changing the obsolete WAEA standard by its newest edition, i.e. WAEA 0403;

• risk R3 is treated by proposing some media protection;

• risk R4 is shared by contracting an insurance.

We can also see that the event of finding a first-window feature film on internet can be avoided by not showing any first-window feature film. Here, the airline may not agree with the treatment option and plan.