Cloud risk analysis using OCTAVE Allegro : Identifying and analysing risks of a cloud service

(1)

Linköpings universitet SE–581 83 Linköping

Linköping University | Department of Computer and Information Science

Bachelor’s thesis, 15 ECTS | Information Technology

2021 | LIU-IDA/LITH-EX-G--2021/056--SE

Cloud risk analysis using OCTAVE

Allegro

–

Identifying and analysing risks of a cloud service

Användning av riskanalysmetoden OCTAVE Allegro på ett

teknikföretags molntjänst

Carl Fransson

Lucas Laukka

Supervisor : Marcus Bendtsen Examiner : Marcus Bendtsen

(2)

Upphovsrätt

Detta dokument hålls tillgängligt på Internet - eller dess framtida ersättare - under 25 år från publicer-ingsdatum under förutsättning att inga extraordinära omständigheter uppstår.

Tillgång till dokumentet innebär tillstånd för var och en att läsa, ladda ner, skriva ut enstaka ko-pior för enskilt bruk och att använda det oförändrat för ickekommersiell forskning och för undervis-ning. Överföring av upphovsrätten vid en senare tidpunkt kan inte upphäva detta tillstånd. All annan användning av dokumentet kräver upphovsmannens medgivande. För att garantera äktheten, säker-heten och tillgängligsäker-heten ﬁnns lösningar av teknisk och administrativ art.

Upphovsmannens ideella rätt innefattar rätt att bli nämnd som upphovsman i den omfattning som god sed kräver vid användning av dokumentet på ovan beskrivna sätt samt skydd mot att dokumentet ändras eller presenteras i sådan form eller i sådant sammanhang som är kränkande för upphovsman-nens litterära eller konstnärliga anseende eller egenart.

För ytterligare information om Linköping University Electronic Press se förlagets hemsida http://www.ep.liu.se/.

Copyright

The publishers will keep this document online on the Internet - or its possible replacement - for a period of 25 years starting from the date of publication barring exceptional circumstances.

The online availability of the document implies permanent permission for anyone to read, to down-load, or to print out single copies for his/hers own use and to use it unchanged for non-commercial research and educational purpose. Subsequent transfers of copyright cannot revoke this permission. All other uses of the document are conditional upon the consent of the copyright owner. The publisher has taken technical and administrative measures to assure authenticity, security and accessibility.

According to intellectual property law the author has the right to be mentioned when his/her work is accessed as described above and to be protected against infringement.

For additional information about the Linköping University Electronic Press and its procedures for publication and for assurance of document integrity, please refer to its www home page: http://www.ep.liu.se/.

(3)

Abstract

Cybersecurity is currently an important and relevant issue, as more and more indus-tries are taking advantage of the accessibility of storing information online. To create a secure system one must know the potential risks and attacks on that system, making risk analysis a very potent tool. In this study, we performed such an analysis using the risk analysis method OCTAVE Allegro on a company providing a cloud-based service to find out what risks a cloud service provider might be exposed to, and the usefulness of said risk analysis method in this circumstance. We found that OCTAVE Allegro is suitable to use on smaller companies and applicable to cloud services, and the most severe risks identified were connected to leakage of client data with a consequence of damaging the company’s reputation. Common areas of concern for these risks were third parties hacking the cloud server or other company systems to gain access to sensitive information. Such risks will likely be found at any company providing a cloud service that manages sensitive data, increasing the importance of risk analysis at these companies.

(4)

Acknowledgments

Firstly we would like to thank our supervisor Marcus for helping us by giving valuable input during the project. We would also like to thank everyone at the company who helped us by answering questions and making time for meetings. Additionally, we would like to thank Clara Gallon and Rebecca Södereng for their contribution to this study. Finally, we would like to thank Vilhelm Melkstam, Anton Magnusson, Erik Voldstad, Julia Mineur, and Isabell Öknegård Enavall for all the great feedback given throughout the project.

(5)

List of Figures

2.1 The four phases of OCTAVE Allegro. . . 5

3.1 The analyzed system. . . 8

4.1 Impact area prioritization worksheet . . . 13

7.1 Worksheet 1 . . . 26 7.2 Worksheet 2 . . . 27 7.3 Worksheet 3 . . . 28 7.4 Worksheet 5 . . . 29 7.5 Worksheet 8a . . . 30 7.6 Worksheet 8b . . . 31 7.7 Worksheet 8c . . . 32 7.8 Questionnaire 1 . . . 33 7.9 Questionnaire 2 . . . 34

(8)

List of Tables

3.1 Example table of risk score . . . 10

4.1 Worksheet 1: Risk measurement criteria - Reputation and customer confidence . . 11

4.2 Worksheet 2: Risk measurement criteria - Financial . . . 12

4.3 Worksheet 3: Risk measurement criteria - Productivity . . . 12

4.4 Worksheet 5: Risk measurement criteria - Fines and legal penalties . . . 13

4.5 Adversity for each information asset. . . 14

4.6 Areas of concern for each information asset. . . 16

4.7 Consequences for areas of concern. . . 17

4.8 Risk scores for areas of concern. . . 18

(9)

1 Introduction

1.1 Motivation

With an increasing amount of information being stored digitally comes an advantage of in-formation being readily available at all times. With the help of external cloud services, the stored information becomes even more accessible [16]. An example of such usage is orga-nizations wanting their employees to access the data when working from home. However, being connected to the internet also means an increased vulnerability as it increases the pos-sibility of unauthorized users accessing the stored information [8]. Sensitive information or systems getting accessed by unintended entities can pose a serious risk to the organization. To examine such risks and help decide how to go forward with them, an organization can use risk analysis [14].

1.2 Aim

The purpose of this thesis project is to examine security risks on a company’s cloud- and IoT services using the risk analysis method OCTAVE Allegro. We aim to identify risks for the collaborating company and help them prioritize a course of action. Furthermore, we aim to analyze the applicability of OCTAVE Allegro on a smaller-sized tech company providing a cloud service. Finally, we hope the work can inspire other companies and organizations to perform risk analyses.

1.3 Research questions

This project aims to answer the following questions:

1. What are the risks that can be identified using the risk analysis method OCTAVE Allegro when analyzing a company’s cloud and IoT services?

2. How well fitted is OCTAVE Allegro for a smaller company, when focusing on their cloud and IoT services?

(10)

1.4. Delimitations

1.4 Delimitations

This study was based on a collaboration with a company, making the study dependant on what information the company was willing to share with the project. The collaboration with the company was limited to communication over digital services because of safety measures related to COVID-19. The focus for this study remained solely on the company’s cloud and IoT services and when analyzing the potential risk of these systems we exclusively used the method OCTAVE Allegro.

(11)

2 Theory

2.1 Risk analysis

Many fields contain vulnerabilities that can be exploited and pose a risk to an organization. To identify such vulnerabilities and suggest approaches, risk analysis could be used. There exist many different risk analysis methods but, while their approach may differ, they all identify vulnerabilities and propose a course of action for the company performing them [5].

Risk analysis could be used in many different industries, ranging from hospitals and nu-clear plants to IT companies. These various industries all have different risks and conse-quences, meaning they all demand different things from the analysis, creating a need for different risk analysis methods. When working with IT systems, the general main purpose is to identify how data could be leaked and propose mitigation approaches for the company [21].

2.2 Terminology

In this section, we will describe some of the terminology used in this report. This terminology includes specific terms used in the risk analysis method OCTAVE Allegro and some more general terms used in risk analysis.

Confidentiality, Integrity and Availability

International Organization for Standardization (ISO) describes confidentiality as the property that information only is available for authorized entities [11]. The principle of confidentiality is important in many fields, and an example of its importance is medical privacy, where patient information needs to be kept private [9].

Integrity is then described as "property of accuracy and completeness" by ISO 27000:2018 [11, p. 2]. This means the data should not be altered by any unauthorized entity. For example, the integrity of inflationary statistics is critical for economists, while confidentiality is less important since it is public information [23].

Finally, according to ISO 27000:2018, availability is the property of a resource being acces-sible by intended users when they request it [11]. While some might argue that availability in itself is not a security requirement, it would make confidentiality and integrity of no use

(12)

2.3. Security in IoT and Cloud services

if the resource cannot be accessed [18]. Confidentiality, integrity, and availability together constitute the CIA triad [3].

Terms used in OCTAVE Allegro

Some of the terms used in this report are based on definitions given in the OCTAVE Allegro report [6]. An explanation of these terms is given below.

• An information asset is information considered valuable to an organization. Examples of information assets include salary information and medical journals.

• An information asset container, or simply information container, is the entity storing or processing information. Examples of information containers range from humans knowing the specific information to hard drives storing said information.

• Security requirements details the protection of an information asset in regards to the CIA triad.

• In the context of risk analysis, an actor is an entity breaching an information assets security requirements.

• In OCTAVE Allegro, an Area of Concern is defined as "A descriptive statement that details a real-world condition or situation that could affect an information asset in your organization." [6, s. 46]. This will also be the definition of the term in this report. Note that the acronym AoC will sometimes be used in place of Area of Concern.

Risk, Vulnerability and Threat scenario

In this report, risk is defined as defined by ISO 27000:2018, where risk is the "effect of uncer-tainty on information security objectives" [11, p. 8]. An example of a risk is that an unautho-rized entity could access a sensitive server using stolen credentials.

Vulnerability is an exploitable weakness [11], and in this report the term is mainly be used to describe such weaknesses of information assets. Finally, a threat scenario is a situation in which a vulnerability of an information asset is used to compromise the information asset [6].

2.3 Security in IoT and Cloud services

As companies and industries are becoming more connected to the internet, the need for infor-mation to be stored locally is slowly disappearing. Storing the inforinfor-mation on cloud services can improve accessibility but also opens up the system to attacks through the internet [19]. Examples of such attacks include Man-in-the-Cloud attacks and phishing attacks [12, 13]. By hacking the system, attackers may gain access to sensitive information or disrupt important functions of the system with potentially devastating consequences. These risks exist in IoT devices as well, as they’re also connected to the internet and could be subjected to similar types of attacks. As such, security against these types of attacks is typically the main focus in risk analysis of IT systems and is a very important area to consider when using cloud services and IoT devices [15].

2.4 OCTAVE Allegro

OCTAVE, or Operationally Critical Threat, Asset, and Vulnerability Evaluation, is a risk anal-ysis method created by Carnegie Mellon University in 1999, used to identify and manage information security risks [1]. OCTAVE aims to solve the problem with bad communication between the IT department and the rest of the organization, creating a lack of understanding

(13)

2.4. OCTAVE Allegro

of what to prioritize. By following the OCTAVE framework, the organization can make in-formed decisions regarding the information asset, based on the CIA triad. Therefore OCTAVE gives the organization a structured and systematic way to manage information-security risks [1]. OCTAVE consists of three phases, where the first phase builds security requirements and the second phase identifies vulnerabilities in the system. The last phase develops a strategy for how to handle the identified vulnerabilities.

OCTAVE Allegro is an improved version of OCTAVE, created in 2007 by Carnegie Mellon University. In the introduction report from 2007, the creators said that “The OCTAVE Allegro approach (...) is designed to allow broad assessment of an organization’s operational risk environment with the goal of producing more robust results without the need for extensive risk assessment knowledge” [6, p. 4]. This method, compared to OCTAVE, focuses even more on the information, where it is stored, how it is handled, and then how the information is exposed to different kinds of threats and where vulnerabilities are created. OCTAVE Allegro is more flexible than the previous versions of OCTAVE, which means it can either be used by personnel with extensive knowledge of the system, or by individuals who want to analyze the risks without involvement from the organization [6]. OCTAVE Allegro is done in 4 phases with a total of 8 steps, as seen in Figure 2.1.

Step 1 - Establish risk measurement criteria Step 2 - Develop informa on asset proﬁle Step 3 - Iden fy informa on asset containers

Step 4 - Iden fy areas of concern

Step 5 - Iden fy threat scenarios

Step 6 - Iden fy risks

Step 7 - Analyze risks

Step 8 - Select mi ga on approach

Phase 1 Phase 2 Phase 3 Phase 4

Figure 2.1: The four phases of OCTAVE Allegro.

Phase 1

The first phase of OCTAVE Allegro begins with establishing risk measurement criteria in Step 1. Risk measurement criteria are used to make an organization quantify how it will be affected by each risk in way of ranking impacts in different areas from low to high. More specifically Step 1 begins with identifying these risk measurement criteria and prioritizing them from most to least important with the help of a worksheet template. OCTAVE Allegro contains worksheets for different activities in each step, with each worksheet intended to aid users in the application of the method.

(14)

2.5. Earlier usage of OCTAVE Allegro in the industry

Phase 2

When step one is done, phase 2 begins with developing an information asset profile in Step 2. This is done by first defining the information assets, from which to create the profiles. These are later used to identify threats and risks. Step 3 is then to identify information asset containers. Examples of such containers include hardware, software, networks, and people. These containers are not limited to being internal, as they can also be external to the company.

Phase 3

When Step 3 is done, phase 3 begins. This phase consists of Step 4 and 5 and focuses on identifying threats. Step 4 consists of identifying different areas of concern. These areas are identified by brainstorming. In Step 5, additional AoCs are identified with the help of ques-tionnaires. The identified areas of concern are then developed into detailed threat scenarios.

Phase 4

The last phase, phase 4, is used to identify and mitigate risks. It consists of Step 6 to 8, where the purpose of the first of these steps is to identify risks from the threat scenarios. These risks are measured by identifying what consequences the proposed threat scenarios from step 5 could have on the organization. In Step 7 the risks are analyzed and the impact of the consequences is measured by assigning each risk a score based on factors identified earlier in the risk analysis method, such as risk measurement criteria. The last step selects an approach to reduce or mitigate the risks that have been identified.

2.5 Earlier usage of OCTAVE Allegro in the industry

One example of usage is by Bako Ali and Ali Ismail Awad in the report Cyber and Physical Security Vulnerability Assessment for IoT-Based Smart Homes from 2018. In this report, they use OCTAVE Allegro to assess the security risks of smart homes with a focus on IoT, where the key goal is to find security vulnerabilities and suggest approaches to mitigate the risks. They found a total of 10 critical information assets with a total of 29 risks evenly distributed among the assets in what was considered a successful and comprehensive risk assessment [2]. Since OCTAVE Allegro has been successfully used to identify risks in IoT systems, it indicates that it should be suitable to use in this study as well.

2.6 Additional risk analysis methods

There is no consensus on how to conduct a risk analysis in any given situation. Risk anal-ysis is used in a variety of industries and each company has specific risks for their system, with the risks varying not only between different companies even in the same industry, but also for different areas in the companies [4]. Because of the subjective nature of risk analysis, there have been multiple risk analysis methods constructed during the last century. Sev-eral risk analysis methods have been created specifically with information security in mind, OCTAVE Allegro being one example. Other such methods include CORAS, CRAMM, IS-RAM, MEHARI, and MAGERIT [21, 14]. More general methods, or methods originally in-tended for another area, can also be used for information security risk analysis. Some of these methods, such as FMEA or HAZOP, have previously been used on IT systems with positive results [22, 20]. Most of these methods are structured similarly but with enough differences that using different methods might yield different results [17]. While it would be possible to use any of the aforementioned methods for this project, OCTAVE Allegro was chosen because of its goal to produce results without needing extensive knowledge of risk analysis or major involvement from the organization.

(15)

3 Method

3.1 The system to be analysed

In this study, we conducted a risk analysis on a cloud system connected to 3D printers. We an-alyzed 3D printers that are company property but are rented by clients and located at client locales. By utilizing a specific cloud service, clients can upload existing 3D models to the cloud which are then transmitted to the printers, ready to be printed. The communication between the client’s computer and the cloud server is encrypted by HTTPS, and the infor-mation stored on the cloud server is encrypted as well. The 3D printers are set up to only communicate with authorized servers through a VPN tunnel.

Any updates to the source code of the printers and the cloud service are first pushed to a company-owned server as seen in Figure 3.1, which are then pushed to the cloud server and the printers.

(16)

3.2. Meetings and communication User 3D-printer Cloud server Developer Server 3D-model 3D-model Code Code Code

Figure 3.1: The analyzed system.

3.2 Meetings and communication

Active and productive communication with the company was necessary for a successful anal-ysis, given the limited time to perform the analysis. Despite OCTAVE Allegro being created to be easier for individuals than regular OCTAVE, a deeper understanding of the system was still needed [6]. This study was based on communication with a contact person at the com-pany by way of emails and online meetings. Because of this, relevant and engaging questions were strived for and were especially important considering current distance safety measures due to COVID-19.

3.3 Implementation of OCTAVE Allegro

The main focus of this study was the implementation of the risk analysis method OCTAVE Allegro. In this implementation, we followed the eight steps and four phases previously covered in this paper. These steps can be seen in Figure 2.1.

As any risk analysis method is dependent on the properties of the system to be analyzed, the steps in OCTAVE Allegro was applied with this in mind. The studied assets was limited to the specific system that was analyzed, excluding other unrelated assets at the company.

Step 1

When implementing the first step of the method OCTAVE Allegro we used Worksheets 1 to 7 included in the risk analysis method to help establish the risk measurement criteria. Worksheet 4 was excluded in this case, as we considered it to not be relevant in the risk analysis. The worksheet was about health and safety, which we did not consider as a risk connected to the analyzed system since the system is completely digital. Since these criteria are closely connected to the inner workings of the company, we established them with the help of the contact person at the company through a meeting. The focus of the meeting was

(17)

3.3. Implementation of OCTAVE Allegro

to fill in Worksheets 1 to 6, while Worksheet 7 was planned to be answered later as a follow-up. The reason for this was to give enough time to consider the impact of each area enough to give a well-thought-out answer. Any other follow-up questions related to the worksheet or the criteria were asked via email. Examples of follow-up questions include any unanswered question in the meeting or any question of which the contact person needed to consult other colleagues at the company.

Step 2

As in Step 1, Step 2 was largely based on utilizing worksheets. The worksheet used in this step was Worksheet 8, critical information asset profile. As we had more than one information as-set, we used a copy of the worksheet for each asset. We regarded this step as partly answered in a previously done meeting where the system and its assets were presented. Because of this, we brainstormed any complementary information and then confirmed the correctness of this information through an e-mail communication with the company.

Step 3

In the next step we identified information containers. To do this we utilized Worksheets 9a, b, and c, in conjunction with questions sent to the company. We formulated questions based on the worksheets such as Where is the information located?, and Who is the owner of this container?. The answers to these questions were then used to fill in the worksheets. If the answers did not give enough relevant information the connected worksheet was then excluded from the rest of the analysis.

Step 4

In the fourth step, we came up with different areas of concern by using the creativity tech-nique brainstorming. During this step, we discussed questions such as How could this informa-tion get disclosed?, Who inside or outside the organizainforma-tion could cause harm in this specific scenario? and How would anyone cause harm in these scenarios?. The goal was to identify as many areas of concern as possible and their respective properties in form of an actor, the means the actor takes, the actors motive, the outcome if an information asset is affected in some way, and the security requirements taken by the organization to prevent these threats.

To ensure that the areas of concerns documented were not influenced by prior biases in the company, this step was initially performed without external involvement. Afterward, we held a meeting where we discussed potential areas of concern that we had missed.

Step 5

This step revolved around identifying threats, to help discover additional areas of concern. Our first activity was centered around creating questionnaires about areas of concern for the analyzed system, basing them on existing ones given in OCTAVE Allegro. Each question-naire contains some scenarios intended to induce creative thinking to identify critical con-sequences. Only scenarios considered relevant to the information assets and system to be analyzed were included. For example, Questionnaire 3 in OCTAVE Allegro only contains scenarios concerning people acting as information containers, which was seen as irrelevant given our delimitation and was therefore excluded from the analysis.

The questionnaires we included in the analysis revolved around people getting access to information stored in physical or technical containers. A technical container could for exam-ple be an active server, while a physical container might be the hardware in that server. The scenarios tried to identify what actors could in some way access, destroy, interrupt or modify one of the analyzed information assets. These questionnaires were sent to the company and were then discussed to find out if there were any areas of concern which was not previously

(18)

3.3. Implementation of OCTAVE Allegro

documented. We also asked additional questions about specific system attributes and the company, to further help identify potential threats.

The activity to document probability in Step 5 was actively excluded from the analysis, as this was an optional step and the probability for most of the identified threats was considered difficult to quantify.

Step 6

In Step 6 we held a meeting with the company to help determine the potential consequences for each area of concern. The primary goal was to quantify each area of the potential sequence, which would help in later steps of the analysis. An example of a potential con-sequence is that the company loses around 20 percent of their customers due to a damaged reputation, while also having to pay a fine of SEK 200 000. The consequence for every area of concern was documented in the respective worksheet.

Step 7

Based on the results of the previous step we calculated impact values that were divided into low, moderate, and high for each area of concern. Each part represents a separate value, low being equal to 1, moderate being equal to 2, and high being equal to 3. The impact values are also based on the risk measurement criteria created in activity 1 of Step 1. Using these impact values together with the prioritization made earlier, we calculated a score for each impact area. This was repeated for every area of concern. The score was calculated by multiplying the represented value of the impact area, with a value connected to the prioritization of the same area. When the score for each impact area was calculated, they were added together to create a total risk score for the respective area of concern. An example of this can be seen in Table 3.1.

Impact Area Ranking Impact Value Score

Reputation 2 High (3) 6

Financial 3 High (3) 9

Productivity 1 Moderate (2) 2

Fines/Legal 4 Low (1) 4

Total: - - 21

Table 3.1: Example table of risk score

The first row in Table 3.1, reputation, has a score of 6. This value is given by multiplying Ranking (2) with Impact Value (3). Adding all the scores together gives a total risk score of 21 for this example area of concern.

Step 8

In the final step of OCTAVE Allegro, we divided the areas of concern into three pools, decided by their risk scores. We decided to split the areas of concern evenly into these pools, with every pool having a different course of action. The areas of concern with a score high enough to need consideration about whether to mitigate or defer were placed in the first pool. Areas of concern that could either be deferred or accepted were placed in the second pool and the third pool consisted of areas of concern with risks small enough to be accepted. The decision to split the areas of concern evenly into the pools was based on a recommendation in the method OCTAVE Allegro. The purpose of the final activity of Step 8 was to develop a strategy to reduce risk scores for different AoCs. We considered this activity as being outside the scope of the analysis and therefore excluded it.

(19)

4 Results

4.1 Results of Step 1

When performing Step 1, several worksheets were filled during a meeting with the company. As this step was executed by following the instructions in Step 1 of OCTAVE Allegro, the related worksheets (1-7) were used. All filled worksheets used in the study can be found in the appendix, see chapter 7. As mentioned in section 3.3, Worksheet 4 was regarded as irrelevant and therefore excluded. Similarly, Worksheet 6 was excluded due to there not being any user-defined risk measurement criteria. As the information documented in the worksheets was gathered in a meeting with the company, the information is based on an interpretation of the answers given.

The first worksheet that was filled was about reputation and customer loss, and the impact on the company that would follow. As seen in Table 4.1, around a 5 percent loss in customers was considered to have a low impact on the company. A moderate impact was considered to be from 5 percent to 50 percent reduction in customers, meaning more than 50 percent lost customers would be considered having a high impact on the company. In this worksheet, there are predefined criteria for how damaged reputation impacts the company. These criteria can be seen in Figure 7.1.

Impact Area Low Moderate High

Customer loss Less than 5 percent reduction in customers due to loss of confidence. 5 to 50 percent reduction in customers due to loss of confidence. More than 50 percent reduction in customers due to loss of confidence. Table 4.1: Worksheet 1: Risk measurement criteria - Reputation and customer confidence

In the second worksheet, the criteria for the financial impact on the company were deter-mined. In Table 4.2 one can see that the operating cost and one-time financial cost had very similar low impact criteria of below SEK 120 000 and SEK 100 000 respectively. They were however increasingly differentiating when the impact is increasing. This led to operating costs being 50 percent larger than one-time financial losses when considering high-impact

(20)

4.1. Results of Step 1

scenarios. The last impact area of the worksheet was revenue loss, expressed in percentage. This criterion was ranging from below 5 percent to above 20 percent, distributed on the three impact values.

Operating Costs Increase of less than SEK 120 000 in yearly operating costs. Yearly operating costs increase by SEK 240 000 to SEK 600 000. Yearly operating costs increase by more than SEK 600 000.

Revenue Loss Less than 5 percent yearly revenue loss.

5 to 20 percent yearly revenue loss.

Greater than 20 percent yearly revenue loss. One-Time Financial Loss One-time financial cost of less than SEK 100 000.

One-time financial cost of SEK 100 000 to SEK 400 000.

One-time financial cost greater SEK 400 000.

Table 4.2: Worksheet 2: Risk measurement criteria - Financial

The third risk measurement criteria worksheet, productivity, only contains the impact area staff hours. The three impact values were measured in increased staff hours in percentage over a chosen period of 14 days. The range in percentage from low to high impact ranged from 12.5 percent to 25 percent, as can be seen in Table 4.3.

Staff hours Staff work hours are increased by less than 12.5 percent for 1 to 14 days.

Staff work hours are increased between 12.5 percent and 25 percent for 1 to 14 days.

Staff work hours are increased greater than 25 percent for 1 to 14 days.

Table 4.3: Worksheet 3: Risk measurement criteria - Productivity

Since Worksheet 4 was excluded from the analysis, the next worksheet processed was Work-sheet 5, about fines and legal penalties, and can be seen in Table 4.4. This table includes the impact areas fines and lawsuits, measured in monetary value. These impact areas shared the same costs in the three impact values, and the costs were the same as the one-time financial cost seen in Table 4.2 ranging from SEK 100 000 to SEK 400 000.

(21)

Fines Fines less than SEK

100 000 are levied.

Fines between SEK 100 000 and SEK 400 000 are levied.

Fines greater than SEK 400 000 are levied.

Lawsuits Non-frivolous

lawsuits or lawsuits less than SEK 100 000 are filed against the organization, or frivolous lawsuit(s) are filed against the organization.

Non-frivolous lawsuits or lawsuits between SEK 100 000 and SEK 400 000 are filed against the organization.

Non-frivolous lawsuits or lawsuits greater than SEK 400 000 are filed against the organization.

Table 4.4: Worksheet 5: Risk measurement criteria - Fines and legal penalties

After the documentation of risk measurement criteria followed a ranking of impact area pri-oritization. As Worksheets 4 and 6 were excluded from the analysis, they were also excluded from the ranking. The areas were given scores from 1 to 4, where 1 is the least important criteria and 4 is of most importance. As can be seen in Figure 4.1 the company prioritized reputation above anything else for the analyzed system.

(22)

4.2 Results of Step 2

The first activity of Step 2 resulted in three different information assets. The first of these assets, 3D models, was given as an information asset at the beginning of the analysis, as it was a big part of the system to be analyzed. After studying the system and with the help of the creativity method brainstorming, the other two information assets were identified. One of these assets was the source code for the 3D printers and cloud service, as well as everything connected to the two. The other identified information asset was information stored on the client’s IT system.

After the identification of the information assets, the next step was to identify in which way the data was critical to the company. Assets having adverse consequences when dis-closed, modified, lost, destroyed or when having interrupted access were considered critical to the company and was analyzed further. As seen in Table 4.5, all three information assets identified in activity 1 of Step 2 were considered to have an adverse impact on the company if they were to be disclosed. Furthermore, both the assets source code and the client’s IT system were considered to have an adverse impact if they are lost or destroyed. Finally, the only asset which was critically impacted by being compromised in any way was information stored on the client’s IT system.

The reason that 3D models stored on the cloud were not considered adversely impacted by being modified, lost, destroyed, or having interrupted access was that the models were only stored temporarily on the cloud system and the models were originally stored in the client’s system as well. While interrupted access to the models might be frustrating to the clients wanting to use the 3D printing system, the impact was not severe enough to be considered adverse. In the same way, interrupted access to the source code would be frustrating for the company, but probably only a temporary obstacle as the printers and cloud service could be updated at a time of convenience. In the analyzed system, the company ran several tests before pushing the code to the printers making sure that the code works as intended, which lessened the probability of modification to the source code. However, if the code were to be changed and pushed to the cloud service it could prove to have adverse consequences. For this reason, we decided to classify modification to the source code as adverse in this step.

3D-models stored on cloud Source code connected to cloud and printers Information on Clients IT-system

Disclosed adverse adverse adverse

Modified adverse adverse

Lost or destroyed adverse adverse

Interrupted access adverse

Table 4.5: Adversity for each information asset.

In activity 6 of Step 2, the owners and the people responsible for the information assets were identified. For every information asset, the person ultimately responsible was the head of software for the company, especially if the software security could be proven to be inade-quate. The owners of the information assets were either the company, owning the source code, or the client who owned the 3D models and the information stored on their system.

After the responsible people had been identified, security requirements for each asset needed to be defined from the perspectives of confidentiality, integrity, and availability.

The information stored on the client’s IT system belonged to and was processed entirely by the client. It naturally followed that no personnel at the company had, or needed, access to the information in any way. In contrast to this, the source code connected to the printers was handled entirely by the software developers at the company and these developers needed to

(23)

be able to view and modify the source code at any time to properly do their jobs. The third information asset was processed by both the client and the company, which means that the results were a bit more mixed. While some software developers at the company had admin-istrative rights to access information stored on the cloud server, no one at the company was supposed to view, access, or modify the models stored on the cloud. For both the 3D models and the source code, confidentiality was considered the most important security requirement. Because the information stored on the client’s IT system may vary, there was no clear choice on which security requirement was most important.

4.3 Results of Step 3

The information assets were stored in containers which could be divided into three different categories, namely technical, physical, and people. The technical containers owned by the company were the cloud service storing the 3D models, the server storing the source code and the 3D printers temporarily storing the 3D models. The only technical container not owned by the company was the client’s IT system. As for the physical containers, two were identified. The first was laptop hard drives, owned by the company but handled by personnel, and the second was hard drives on the server storing the source code. There were no identified cases of people carrying sensitive information in this step.

4.4 Results of Step 4 and 5

In Step 4, identify areas of concern, there were a total of sixteen different areas identified. Ten of these concerns were connected to the source code, four to the 3D models, and two to the client’s IT system. The AoCs that were identified included hacking, theft, and accidents. Most of the identified AoCs were the result of using the creativity method brainstorming, with some additional AoCs added through the result of using questionnaires together with a meeting.

The areas of concern related to information stored on the client’s IT system were excluded from the rest of the analysis, as well as half of the AoCs related to the source code. These AoCs were removed because there was either not a big enough probability for the concern-ing event to occur, a mitigation process connected to the risk was already in progress, or the consequence was considered small enough to not be a concern. Because of the removal of all concerns related to information stored on the client’s IT system, this information asset was excluded from the rest of the analysis. The removal of seven different AoCs left nine remain-ing. These nine would be the basis of the rest of the analysis and can be seen in Table 4.6. Every area of concern was given an index referred to as AoC index in this study.

(24)

AoC index Asset Area of concern

1 3d model Someone gets access to the cloud

server the company uses, and gets access to the models stored there.

2 3d model The printer gets hacked and the

model gets accessed by an unauthorized actor.

3 3d model The model is accessed by an

unauthorized third party in the connection between the client and the cloud storage.

4 3d model Someone gets access to the model

when its sent between the server and the 3D-printer.

5 Source code An unauthorized actor gets access

to the GIT-server and the source code.

6 Source code The internal server breaks down

and needs to be replaced.

7 Source code Third party steals the physical

server or its hard drives.

8 Source code Work computer gets hacked,

leading to leaked source code and/or credentials.

9 Source code Work computer gets stolen, and its

local content gets leaked to unauthorized people. Table 4.6: Areas of concern for each information asset.

4.5 Results of Step 6

The purpose of Step 6 was to identify consequences for each area of concern from the results of steps 4 and 5. The consequences were discussed in a meeting with the company and while the consequences for every area of concern were fairly easily identified, most of the consequences were difficult to quantify. While it was clear that some consequences were more significant than others, AoC 1 compared to AoC 6 in Table 4.7 for example, there were no quantified costs in most cases.

(25)

AoC index Consequences

1 Company loses most customers due to damaged reputation. Opens the company to lawsuits if the client can prove insufficient security measures.

2 Sensitive prototypes for Client get leaked. Company loses some customers due to damaged reputation.

3 Sensitive prototypes for Clients get leaked. For MITM to exist, the client needs to be at fault. No consequences for the company. Might lose client.

4 No consequences for the company. Follow the Industry standard. Can’t happen except if major certificate failure happens. If data gets leaked, small potential for damaged reputation.

5 Source code gets leaked. Potential for the hacker to access other services. The person tries to extort the company, but probably won’t succeed. Competitors may try to use code for their own business.

6 Needs to set up the server again, leading to more work hours. Small cost to replace the server.

7 Source code gets leaked, with similar consequences. Server needs to be set up again (with new hard drives/server). Thief tries to blackmail the company. Probably won’t succeed.

8 Hacked laptop gives access to source code, Cloud server and client models, leading to lost customers due to damaged reputation. Staff needs to work overtime to fix security hole, need to identify how it happened.

9 Potential for information stored on PC to be accessed by unauthorized third parties. Laptop needs to be replaced. Thief tries to blackmail the company.

Table 4.7: Consequences for areas of concern.

4.6 Results of Step 7

In this step, the consequences from Step 6 were translated to risk scores. As the consequences identified in Step 6 were not quantified consequences, the risk scores were estimates based on the placement of consequences in the worksheets from Step 1. For example, AoC 1 was given the highest reputation score, placing the consequence in the ’high’ category of the customer loss impact area even though there were no exact numbers on how big the customer loss would be. On the contrary, AoC 3 had a productivity score of 1, since the consequence led to no extra work for the employees. A summary of all the different risk scores can be found in Table 4.8.

As seen in the same table, the consequence with the highest risk score was the area of concern regarding a work computer getting hacked, AoC 8, with a risk score of 20. This area of concern was seen as having a high impact on reputation and productivity, mainly contributing to its high score. AoC 1, a third party getting access to the cloud server, also had a high risk score with a score of 18. This area of concern was considered to have a high impact on reputation as well, but only a low impact in every other impact area. No other area of concern was considered to have a high impact in any area, but there were three areas of concern given the lowest score possible with a score of 10.

(26)

AoC index Reputation score

Financial score

Productivity score

Fines score Risk score

1 12 3 1 2 18 2 8 3 1 2 14 3 4 3 1 2 10 4 4 3 1 2 10 5 4 3 2 2 11 6 4 3 1 2 10 7 4 6 1 2 13 8 12 3 3 2 20 9 4 6 1 2 13

Table 4.8: Risk scores for areas of concern.

4.7 Results of Step 8

The nine different areas of concern were divided into three pools with different actions, whether to mitigate or accept the risks for example. The three areas of concern with the highest risk scores (AoC 1,2, and 8) were placed in the first pool with the action to mitigate or defer, as seen in Table 4.9. Three of the areas of concern had a small enough risk score to be considered acceptable and were placed in pool 3. Finally, the rest of the areas of concern was placed in pool 2, where the risks could either be accepted or looked closer upon.

Pool AoC indexes Action 1 1, 2, 8 Mitigate or Defer

2 5, 7, 9 Defer or Accept

3 3, 4, 6 Accept the risks Table 4.9: Areas of concern for each information asset.

(27)

5 Discussion

5.1 Results

From the results gathered in this study, we can deduce that the security of the system was well thought out and, according to our risk analysis, there were no risks that need immediate action. There were however some areas of concern that needed to be analyzed further, as seen in section 4.7. With this study being performed by people outside the analyzed company, the results were based on whatever information that the company was willing to share. As such, the legitimacy of the results is dependant on how accurately the information was interpreted and conveyed. In the same way, the system being analyzed from an outside perspective could give a more honest result, with there being less bias in the interpretation of the results. An ex-ample of such dependency is when we were discussing the potential issue of an unauthorized person with access to the source code blackmailing the company. According to the company, this was not a big issue as the company would probably refuse to pay any money, referring to how the source code only was a part of the company and there are no guarantees that the code would not get leaked anyway. This thought process significantly lowered the risk scores of certain areas of concern because of the consequences not being considered severe enough. However, the severity of the consequences and whether or not the company would be willing to pay can be difficult to determine as such an occasion has not yet occurred.

An observation when working with the system is that while the company had taken many precautions against digital unauthorized access to the information containers, they had not taken the same measures against physical threats. For example, some hard drives storing potentially sensitive information were not encrypted, making them vulnerable to physical theft.

The risks identified carried significant consequences if they occur, but this study did not include the probability of the risks occurring. Some risks with high enough risk scores to be placed in the first pool might not have been as prioritized when also factoring in the proba-bility. For example, a work laptop getting hacked had a high risk score of 20. However, this might have had a lot lower probability of happening than the laptop getting stolen, which had a lower risk score of 13. Factoring in probability could result in some risks being prior-itized differently. Our approach, without factoring in probability, might be favorable when ranking the risks with the most severe consequences to identify the worst-case scenarios.

(28)

5.2. Method

5.2 Method

All risks were identified in this study by using the risk analysis method OCTAVE Allegro. By only having performed a single analysis using a single risk analysis method, there exists a possibility of unidentified risks which might have been found if using another risk analysis method [17]. However, this does not necessarily imply that the chosen risk analysis method is sub-optimal, but could simply be the result of the subjective nature of risk analysis. The method OCTAVE Allegro seems to be very thorough by documenting large quantities of data in all steps, making the results feel substantiated. However, putting too much trust in the data could create a false sense of security since the quantity of the data says nothing about its quality.

Though the method seems to be a good choice for the analyzed system, we had cer-tain limitations when choosing information assets and concer-tainers. Without such limitations, OCTAVE Allegro might yield different results. The risk analysis was focused on a subsection of the company’s IT system, primarily the printers and their related data. This means that some parts of the system were not considered when identifying risks, parts that might have had some impact on the analyzed system. However, focusing on a subsection of the system allowed us to analyze it more thoroughly, potentially resulting in more specific risks having been identified. Being limited to a digital collaboration might also have had an impact on the results, as physical meetings at the company site could give an even better understanding of the analyzed system.

When considering the consequences for each risk, the decision was made to assume the worst outcome. For example, a work laptop getting hacked could result in local files getting stolen which might be more or less harmless. The same situation could also result in much more severe consequences of credentials being leaked or the entire network getting hacked. To make sure that we included all consequences, we decided to look at the worst outcomes regardless of the probability.

The decision to exclude Worksheet 4 could mean that there exist some risks that were not identified related to Safety and Health. It is unlikely that including this impact area would have significantly changed the results of the analysis since the analyzed databases were completely digital and did not store any personal information. With no time constraint, this impact area could be worth including to be as thorough as possible, even if the results would not change.

Performing the last activity in Step 8 would be of value to any organization performing a risk analysis on their system using OCTAVE Allegro since it would help determine how to treat the identified risks. However, in the performed risk analysis the aim was to identify risks and help the company prioritize which risks to mitigate. Deciding treatments were therefore considered outside the scope of this analysis, but treating the risks should still be considered in future risk analyzes. Including the last activity in Step 8 would be a good continuation of the risk analysis, but it would not have changed the results of this study.

All information that this analysis was based on was collected through meetings with a contact person at the company. Early meetings consisted of interviews with live questions and no preparation for the company beforehand. This proved to yield answers that might not have been fully thought through, and through a mutual agreement with the company, we decided that any future questions would be sent by way of email before a meeting. This seemed to be a better approach, with the company giving more detailed answers. For any future analysis, on-site interviews and meetings would be preferable given the possibility, in hopes of getting another perspective. A disadvantage of using a single contact person to re-lay information is that all information is based on that person’s perspective. For example, the contact person might have assumed that the security policies at the company were followed thoroughly by employees, but earlier studies show that this is not always the case [10]. By interviewing several different employees at the company we could have gotten a better

(29)

un-5.3. The work in a wider context

derstanding of how security policies were actually followed and potentially identified more risks.

The analysis resulted in nine identified risks. Whether or not there were additional unidentified risks could depend on a number of factors. It could be that OCTAVE Allegro is not a thorough enough method, or risks might have been missed during the execution of the analysis. There is also a possibility that the analyzed system was secure enough that there only existed nine risks. If there were any unidentified risks then results indicating that the system is secure could lead to a false sense of security at the analyzed organization [7].

It was deemed difficult to find relevant and up-to-date sources in the analyzed area, de-spite its relevance in today’s IT world. The sources in this report focus on peer-reviewed articles, but because of the difficulties, relevant books were included as well.

5.3 The work in a wider context

The results of this study indicate that the method OCTAVE Allegro is a suitable method to use when analyzing cloud services processing sensitive information. A specific example is the usage of information containers in the method, making it simple to identify areas of concern related to the cloud service.

Using cloud servers to store sensitive information can be very accessible, and can be a se-cure way of handling critical data if one trusts the provider. However, cloud service providers processing a lot of clients’ sensitive data can be a focal point for hacking and other forms of cyberattacks. Because of this, a potential security fault can have large consequences for many companies at once. A targeted attack against a company providing the service might lead to the attacker gaining access to sensitive information belonging to multiple clients using the service [24]. This means that the service provider likely needs to have a good reputation and strong security, in order for customers to feel secure enough to use the service. An aspect of this can be seen in the analysis with reputation having been considered the most important impact area, see Figure 4.1. This would likely be the same for other companies offering sim-ilar services when analyzing this particular area. One way to increase this trust would be by offering the latest standard in security, HTTPS for example.

A security risk found through the analysis which might be more general and could apply to most companies working with sensitive data is the usage of work computers connected to the internal network. These computers can act as an access point to the entire network for hackers trying to access sensitive information.

(30)

6 Conclusion

The purpose of this study was to find out what risks could be identified at a company by using OCTAVE Allegro when focusing on their cloud and IoT services and to find out if OCTAVE Allegro was a fitting risk analysis method to use when analyzing said services.

After performing the risk analysis we found that the analyzed system was very secure, with a total of nine possible risks identified. The identified risks with the highest prioriti-zation were connected to a damaged reputation as a consequence. An example of a high prioritized risk is the cloud service getting accessed by an unauthorized third party, which could lead to customers losing trust in the service. This seems to be connected to the spe-cific company but could be the same for most other companies working with sensitive client data. Other identified risks with high prioritization include risks that could apply to almost any company working with digital systems. An example of such a risk is a work computer getting hacked, leaking sensitive information and credentials.

Despite not having access to the analyzed system and being constrained in terms of time and resources, the performed analysis identified several risks to be mitigated or deferred. This could be considered as a successful analysis, suggesting OCTAVE Allegro is a good choice of method in similar circumstances. The identification of information containers in OCTAVE Allegro was surprisingly well suited for cloud analysis, considering the method was created in 2007. The results of this analysis show that OCTAVE Allegro works well on smaller systems, as the risk analysis method is very thorough and creates a lot of data dependant on the size of the system. Since the data is used to identify risks, more data could help identify more risks. However, processing a lot of data requires more resources and too much data might be difficult to utilize. Smaller systems are likely to be found at smaller companies, making the method appropriate for such companies. Applying OCTAVE Allegro on a larger system could demand a lot of time and resources, and larger companies may therefore want to use this risk analysis method on a subsection of their system.

To further analyze how fitting the method OCTAVE Allegro is for a smaller company, another risk analysis method could be used to perform a simultaneous analysis with OCTAVE Allegro to give a better indication. In the same way, it would be interesting to analyze the whole company with their entire IT system, comparing the results. This would give a better indication of the importance of delimitations when analyzing a system. Using the method at a larger company could also be helpful to determine how important the company size is for the method.

(31)

Bibliography

[1] Christopher Alberts, Sandra Behrens, Richard Pethia, and William Wilson. Operationally Critical Threat, Asset, and Vulnerability Evaluation (OCTAVE) Framework, Version 1.0. Tech. rep. CMU/SEI-99-TR-017. Pittsburgh, PA: Software Engineering Institute, Carnegie Mellon University, 1999. URL: http : / / resources . sei . cmu . edu / library / asset-view.cfm?AssetID=13473.

[2] Bako Ali and Ali Ismail Awad. “Cyber and Physical Security Vulnerability Assess-ment for IoT-Based Smart Homes”. In: Sensors 18 (Mar. 2018), p. 817.DOI: 10.3390/ s18030817.

[3] Michael Aminzade. “Confidentiality, integrity and availability – finding a balanced IT framework”. In: Network Security 2018.5 (2018), pp. 9–11.ISSN: 1353-4858.DOI: https:

/ / doi . org / 10 . 1016 / S1353 - 4858(18 ) 30043 - 6. URL: https : / / www . sciencedirect.com/science/article/pii/S1353485818300436.

[4] T. Aven. Risk Analysis. Wiley, 2015. ISBN: 9781119057796. URL: https : / / books . google.se/books?id=41V%5C_BwAAQBAJ.

[5] Terje Aven. “Foundations of risk analysis”. In: Foundations of Risk Analysis. John Wi-ley & Sons, Ltd, 2012. ISBN: 9781119945482. DOI: https : / / doi . org / 10 . 1002 /

9781119945482.fmatter.URL: https://onlinelibrary.wiley.com/doi/ abs/10.1002/9781119945482.fmatter.

[6] Richard Caralli, James Stevens, Lisa Young, and William Wilson. Introducing OCTAVE Allegro: Improving the Information Security Risk Assessment Process. Tech. rep. CMU/SEI-2007-TR-012. Pittsburgh, PA: Software Engineering Institute, Carnegie Mellon Univer-sity, 2007.URL: http://resources.sei.cmu.edu/library/asset-view.cfm?

AssetID=8419.

[7] B. Chess and G. McGraw. “Static analysis for security”. In: IEEE Security Privacy 2.6 (2004), pp. 76–79.DOI: 10.1109/MSP.2004.111.

[8] Te-Shun Chou. “Security threats on cloud computing vulnerabilities”. In: International Journal of Computer Science & Information Technology 5.3 (2013), p. 79.

[9] Bradley H Crotty and Arash Mostaghimi. “Confidentiality in the digital age”. In: BMJ 348 (2014).DOI: 10.1136/bmj.g2943.URL: https://www.bmj.com/content/ 348/bmj.g2943.

(32)

Bibliography

[10] Stephen Hinde. “Security surveys spring crop”. In: Computers & Security 21.4 (2002), pp. 310–321.ISSN: 0167-4048.DOI: https://doi.org/10.1016/S0167-4048(02) 00404- 2.URL: https://www.sciencedirect.com/science/article/pii/ S0167404802004042.

[11] Information technology — Security techniques — Information security management systems — Overview and vocabulary. Standard. Geneva, CH: International Organization for Stan-dardization, Feb. 2018.

[12] Raja Mohamed Jabir, Salam Ismail Rasheed Khanji, Liza Abdallah Ahmad, Omar Al-fandi, and Huwida Said. “Analysis of cloud computing attacks and countermeasures”. In: 2016 18th International Conference on Advanced Communication Technology (ICACT). 2016, pp. 117–123.DOI: 10.1109/ICACT.2016.7423296.

[13] Sheetal Kalra and Sandeep K. Sood. “Secure authentication scheme for IoT and cloud servers”. In: Pervasive and Mobile Computing 24 (2015). Special Issue on Secure Ubiqui-tous Computing, pp. 210–223.ISSN: 1574-1192.DOI: https://doi.org/10.1016/ j . pmcj . 2015 . 08 . 001.URL: https://www.sciencedirect.com/science/ article/pii/S1574119215001510.

[14] Bilge Karabacak and Ibrahim Sogukpinar. “ISRAM: information security risk analy-sis method”. In: Computers & Security 24.2 (2005), pp. 147–159. ISSN: 0167-4048.DOI: https : / / doi . org / 10 . 1016 / j . cose . 2004 . 07 . 004.URL: https : / / www . sciencedirect.com/science/article/pii/S0167404804001890.

[15] Xingwei Liang and Yoohwan Kim. “A Survey on Security Attacks and Solutions in the IoT Network”. In: 2021 IEEE 11th Annual Computing and Communication Workshop and Conference (CCWC). 2021, pp. 0853–0859.DOI: 10.1109/CCWC51732.2021.9376174. [16] Allan Liu and Ting Yu. “Overview of Cloud Storage And Architecture”. In: SSRN (Dec. 2018).URL: https://papers.ssrn.com/sol3/papers.cfm?abstract_id= 3649074#references-widget.

[17] M. Modarres. Risk Analysis in Engineering: Techniques, Tools, and Trends. Manufacturing and industrial engineering. Taylor & Francis, 2006.ISBN: 9781574447941.URL: https:

//books.google.se/books?id=ErjFzRWSne8C.

[18] Suhail Qadir and S. M. K. Quadri. “Information Availability: An Insight into the Most Important Attribute of Information Security”. In: Journal of Information Security 07.03 (Feb. 2016), pp. 185–194.DOI: 10.4236/jis.2016.73014.

[19] S. Subashini and V. Kavitha. “A survey on security issues in service delivery mod-els of cloud computing”. In: Journal of Network and Computer Applications 34.1 (2011), pp. 1–11.ISSN: 1084-8045.DOI: https : / / doi . org / 10 . 1016 / j . jnca . 2010 . 07 . 006.URL: https://www.sciencedirect.com/science/article/pii/ S1084804510001281.

[20] A. P. Subriadi, N. F. Najwa, B. D. Cahyabuana, and V. Lukitosari. “The Consistency of Using Failure Mode Effect Analysis (FMEA) on Risk Assessment of Information Tech-nology”. In: 2018 International Seminar on Research of Information Technology and Intelli-gent Systems (ISRITI). 2018, pp. 61–66.DOI: 10.1109/ISRITI.2018.8864467. [21] Sardar Muhammad Sulaman, Kim Weyns, and Martin Höst. “A Review of Research on

Risk Analysis Methods for IT Systems”. In: EASE ’13. Porto de Galinhas, Brazil: Associ-ation for Computing Machinery, 2013, pp. 86–96.ISBN: 9781450318488.DOI: 10.1145/ 2460999.2461013.URL: https://doi.org/10.1145/2460999.2461013.

[22] U. Tariq, A. O. Aseeri, M. S. Alkatheiri, and Y. Zhuang. “Context-Aware Autonomous Security Assertion for Industrial IoT”. In: IEEE Access 8 (2020), pp. 191785–191794.DOI: 10.1109/ACCESS.2020.3032436.

(33)

Bibliography

[23] Rossouw von Solms and Johan van Niekerk. “From information security to cyber se-curity”. In: Computers & Security 38 (2013). Cybercrime in the Digital Economy, pp. 97– 102. ISSN: 0167-4048. DOI: https : / / doi . org / 10 . 1016 / j . cose . 2013 . 04 . 004. URL: https : / / www . sciencedirect . com / science / article / pii / S0167404813000801.

[24] Marcus Willett. “Lessons of the SolarWinds Hack”. In: Survival 63.2 (2021), pp. 7–26.

DOI: 10.1080/00396338.2021.1906001.URL: https://doi.org/10.1080/ 00396338.2021.1906001.

(34)

7 Appendix

(35)

(36)

(37)

(38)

(39)

(40)

(41)

Questionnaire 1 T ekniska behållare Scenario 1 Betr akta personal på för

etaget. Kan det uppstå en situation på för

etaget där personal kan komma åt en eller fler

a tekniska behållar e (ex. ser ver), a vsiktligt eller oa vsiktligt, som får en följd a v att information:

Läcks eller avslöjas för obehöriga personer

Nej

Ja (Oavsiktligt)

Ja (A

vsiktligt)

Modifieras så att den inte fungerar på det sätt det är tänkt

Nej

Ja (Oavsiktligt)

Ja (A

vsiktligt)

A

vbryts så att den inte kan nås eller användas som den är tänkt

Nej

Ja (Oavsiktligt)

Ja (A

vsiktligt)

Permanent förstörs eller temporärt förloras så att den inte kan användas för sitt avsedda ändmål

Nej

Ja (Oavsiktligt)

Ja (A

vsiktligt)

Scenario 2

Betrakta nu personer utanför företaget, detta kan inkludera personer som har en legitim af

färsrelation till ert företag eller ej. Finns det en situation där en utomstående kan komma åt en eller flera tekniska behållare (ex. server), avsiktligt eller oavsiktligt, som får en följd av att information:

Nej

Ja (Oavsiktligt)

Ja (A

vsiktligt)

Nej

Ja (Oavsiktligt)

Ja (A

vsiktligt)

A

Nej

Ja (Oavsiktligt)

Ja (A

vsiktligt)

Nej Ja (Oavsiktligt) Ja (A vsiktligt) Figur e 7.8: Questionnair e 1

(42)

Questionnaire 2

Fysiska behållare

Scenario 1

Betrakta personal på företaget. Kan det uppstå en situation på företaget där personal kan komma åt en eller flera

fysiska

behållare (ex. extern hårddisk), avsiktligt eller oavsiktligt, som får en följd av att information:

Nej

Ja (Oavsiktligt)

Ja (A

vsiktligt)

Nej

Ja (Oavsiktligt)

Ja (A

vsiktligt)

A

Nej

Ja (Oavsiktligt)

Ja (A

vsiktligt)

Nej

Ja (Oavsiktligt)

Ja (A

vsiktligt)

Scenario 2

Betrakta nu personer utanför företaget, detta kan inkludera personer som har en legitim af

färsrelation till ert företag eller ej. Finns det en situation där en utomstående kan komma åt en eller flera

fysiska

behållare (ex. extern hårddisk), avsiktligt eller oavsiktligt, som får en följd av att information:

Nej

Ja (Oavsiktligt)

Ja (A

vsiktligt)

Nej

Ja (Oavsiktligt)

Ja (A

vsiktligt)

A

Nej

Ja (Oavsiktligt)

Ja (A

vsiktligt)

Nej

Ja (Oavsiktligt)

Ja (A

vsiktligt)

Scenario 3

Betrakta övriga situationer som på något vis kan påverka fysiska behållare som innehåller känslig information. Kan något av följande ske för att denna information på något sätt ska bli oåtkomlig, läcka, modifieras, eller förstöras:

Annan tredje-parts problem uppstår

Nej

Ja (läckt)

Ja (modifierad)

Ja (förstöras)

Ja (oåtkomlig)

Natur- eller människoorsakad olycka (brand, explosion, storm, osv) uppstår

Nej Ja (läckt) Ja (modifierad) Ja (förstöras) Ja (oåtkomlig) Figur e 7.9: Questionnair e 2

Cloud risk analysis using OCTAVE Allegro : Identifying and analysing risks of a cloud service

Linköping University | Department of Computer and Information Science

Bachelor’s thesis, 15 ECTS | Information Technology

2021 | LIU-IDA/LITH-EX-G--2021/056--SE

Cloud risk analysis using OCTAVE

Allegro

Identifying and analysing risks of a cloud service

Användning av riskanalysmetoden OCTAVE Allegro på ett

teknikföretags molntjänst

Carl Fransson

Lucas Laukka

Upphovsrätt

Copyright

Acknowledgments

Contents

List of Figures

List of Tables

1

Introduction

1.1

Motivation

1.2

Aim

1.3

Research questions

1.4

Delimitations

2

Theory

2.1

Risk analysis

2.2

Terminology

Confidentiality, Integrity and Availability

Terms used in OCTAVE Allegro

Risk, Vulnerability and Threat scenario

2.3

Security in IoT and Cloud services

2.4

OCTAVE Allegro

Phase 1

Phase 2

Phase 3

Phase 4

2.5

Earlier usage of OCTAVE Allegro in the industry

2.6

Additional risk analysis methods

3

Method

3.1

The system to be analysed

3.2

Meetings and communication

3.3

Implementation of OCTAVE Allegro

Step 1

Step 2

Step 3

Step 4

Step 5

Step 6

Step 7

Step 8

4

Results

4.1

Results of Step 1

4.2

Results of Step 2

4.3

Results of Step 3

4.4

Results of Step 4 and 5

4.5

Results of Step 6

4.6

Results of Step 7

4.7

Results of Step 8