1

University of Manchester

School of Computer Science

Year 2013-14

Methodology to Articulate the Requirements for Security - Progress Report

Submitted by:

Tanaya Gopal

Under the supervision of

Dr Daniel Dresner

2

Table of Contents

Abstract ............................................................................................................................................... 4

Chapter 1 ................................................................................................................................................. 5

Introduction ........................................................................................................................................ 5

Chapter 2 ................................................................................................................................................. 7

Background Research and Literary Review ......................................................................................... 7

Terms and Definitions .................................................................................................................... 7

Literary Review ............................................................................................................................... 8

1. Security Quality Requirements Engineering Methodology (SQUARE) ................................. 8

2. UMLSec ................................................................................................................................. 10

3. Secure Tropos (Mouratidis et al.) ........................................................................................ 11

4. CORAS ................................................................................................................................... 12

Non-Functional Requirements ..................................................................................................... 14

Supervisory Control and Data Acquisition systems (SCADA)...................................................... 15

Chapter 3 ............................................................................................................................................... 17

Project Progress ................................................................................................................................ 17

Comparison of the Methods ........................................................................................................ 17

ARCHITECTURE ............................................................................................................................. 18

Asset Document ........................................................................................................................... 19

Risk assessment Results ............................................................................................................... 20

Sample Document ........................................................................................................................ 21

Research Methodology ..................................................................................................................... 22

Background Research ................................................................................................................... 22

Implementation Phase ................................................................................................................. 22

Evaluation Phase .......................................................................................................................... 22

CHAPTER 4 ............................................................................................................................................ 24

Project Plan ....................................................................................................................................... 24

References ........................................................................................................................................ 25

3

List of Tables

Table 1: List of methodologies ............................................................................................................... 8

Table 2: SQUARE ................................................................................................................................... 10

Table 3: List of organisations working for SCADA security ................................................................. 16

Table 4: Comparison table ................................................................................................................... 17

Table 5: Sample Asset Document ........................................................................................................ 19

Table 6: Sample Risk Document .......................................................................................................... 20

List of Figures

Figure 1: Secure Dependency ..................................................................................................... 12

Figure 2: Secure entities ............................................................................................................. 12

Figure 3: Symbols from the CORAS risk modelling language......................................................... 13

Figure 4: SCADA Architecture ..................................................................................................... 15

Figure 5: Architecture ................................................................................................................. 18

Figure 6: Sample Security Requirements Document .................................................................... 21

4

Abstract The need to provide security to SCADA systems is increasing with increased connectivity between these systems as well as with internet. However, there has not been much research in the area of security requirements for such systems. This report presents a detailed analysis of some of the existing security requirements methodologies like SQUARE, UMLSec, CORAS, Secure Tropos and Common Criteria. It tries to evaluate these on well-defined parameters. Then it studies how Non-functional requirements are defined in these requirements process and how they fit in with other requirements of the system. It then devises a security requirements methodology that takes few points from each of the reviewed methodologies. The architecture of the methodology is presented in this report. The report also shows that such a methodology can be applied in Supervisory Control and Data Acquisition (SCADA) systems for electricity supply.

5

Chapter 1

Introduction Requirements engineering is an important part of software engineering but organisations often fail to gauge its importance. Poor requirements in projects lead to problems like [1]:

Budget exceeds the set limit

Project goes beyond the decided schedule

System produced is of poor quality

The scope of the project is reduced

System is not used after deployment

Many reports have come out which cite poor requirements as top three causes of it failure [10]. However, security requirements are relatively less among requirements engineering processes and even if they are, they are considered in an ad-hoc manner [10]. Therefore, there is a need to make security requirements an integral part of requirements engineering. In this report I study the concept of security requirements engineering and present an architecture of a security requirements methodology.

A system is only as secure as its weakest part [6] therefore it is very important to look into all the aspects of the security requirements of the system. According to M. Gasser and R Anderson, adding security as an afterthought often leads to problems [6]. Therefore, it should be included at the time of requirements engineering along with the functional and non-functional requirements. We need a requirements methodology that will consider the need for security and make security an important aspect at later stages too. Still a proper security requirements elicitation is not part of the best practice, today [2], which often leads to failure of projects. Therefore, there is a need to formulate precise, complete and testable security requirements at the early stages of software development.

The modern society depends on critical infrastructures like electricity and water supply, waste management, oil and gas supply systems. They form an important backbone of the society. These systems when they were developed were not interconnected and functioned aloof. However, with time these systems have started to become interconnected which has exposed it to many types of cyber and malware attacks [6]. It is therefore, very important to keep them protected against such attacks. These systems mostly known as SCADA systems are critical for the functioning of the economy and need high security measures to be implemented for their smooth functioning. Unfortunately, security of these systems was not considered very important until few years ago. It is only recently that people have realised that these systems need strong security measures.

Electric power production and supply is an important example of SCADA systems. The earlier SCADA systems were very basic and consisted of lamps and switches [3]. Nowadays the systems are much more sophisticated and complicated due to the advancement in communication systems. They can be controlled by equipment similar to desktop computers and it does not need to be situated at the same site as the system. That is, it can be controlled by a remote site. This ability has made these systems more prone to security attacks. These attacks can cause significant disruptions if successful [3]. The August 2003 northeast blackout in US which also affected Canada [4] shows how important SCADA systems are for an economy. This report will focus on the SCADA systems for electricity supply.

In chapter 2, Background Research and Literary review, I will study different types of security requirements engineering methods which have been selected based on a criteria. Then I will study how non-functional requirements are defined in the requirements engineering world. Then I will focus on SCADA systems and their security in today’s world. I will also explain the emergence of

6

smart grids and their importance in relation to SCADA systems in a brief manner. I will then focus the efficiency of the methods for critical infrastructure based SCADA systems for electricity supply. In chapter 3, I will present a comparison of the four security requirements methodologies. Then I will present an architecture of the new methodology that I will create as a result of the literary review. Some examples are provided of the documents that will be created during the process. Next, the research methodology will be explained in a brief way which includes the background research, implementation and evaluation phase. Lastly in Chapter 4, I will present a detailed project plan, enlisting my plans for the upcoming months.

7

Chapter 2

Background Research and Literary Review Terms and Definitions Before delving into the research and literary review, I would list some basic terminologies which have been used in the report. These terminologies have been taken from the BS ISO/IEC 27000:2014[11] and ISO/IEC 12207:2008[14]:

Acquisition: process of obtaining a system, software product or software service

Attack: attempt to destroy, expose, alter, disable, steal or gain unauthorized access to or make unauthorized use of an asset.

Access control: means to ensure that access to assets is authorized and restricted based on business and security requirements.

Authentication: provision of assurance that a claimed characteristic of an entity is correct.

Availability: property of being accessible and usable upon demand by an authorized entity.

Confidentiality: property that information is not made available or disclosed to unauthorized individuals, entities, or processes.

Contract: binding agreement between two parties, especially enforceable by law, or a similar internal agreement wholly within an organization

Event: occurrence or change of a particular set of circumstances.

Information security: preservation of confidentiality, availability and availability of information.

Information system: applications, services, information technology assets, or other information handling components.

Integrity: property of accuracy and completeness.

Non-repudiation: ability to prove the occurrence of a claimed event or action and its originating entities.

Organization: person or group of people that has its own functions with responsibilities, authorities and relationships to achieve its objectives.

Project: endeavour with defined start and finish dates undertaken to create a product or service in accordance with specified resources and requirements

Requirement: need or expectation that is stated, generally implied or obligatory. “Generally implied” means that it is custom or common practice for the organization and interested parties that the need or expectation under consideration is implied. A specified requirement is one that is stated, for example in documented information.

Risk: effect of uncertainty on objectives.

Risk acceptance: informed decision to take a particular risk.

Risk analysis: process to comprehend the nature of risk and to determine the level of risk.

Risk assessment: overall process of risk identification, risk analysis and risk evaluation.

Risk evaluation: process of comparing the results of risk analysis with risk criteria to determine whether the risk and/or its magnitude is acceptable or tolerable.

Risk identification: process of finding, recognizing and describing risks.

Risk treatment: process to modify risk.

Security: protection of information and data so that unauthorized persons or systems cannot read or modify them and authorized persons or systems are not denied access to them

Software product: set of computer programs, procedures, and possibly associated documentation and data

Stakeholder: individual or organization having a right, share, claim or interest in a system or in its possession of characteristics that meet their needs and expectations

System: combination of interacting elements organized to achieve one or more stated purposes

8

Validation: confirmation, through the provision of objective evidence, that the requirements for a specific intended use or application have been fulfilled.

Literary Review For the background research I studied various security requirements methodologies in use today. I studied four kinds of methodologies and selected one from each kind of methodology types for the background research. The selection was made by comparing the amount of research on the methodology done so far. I selected on two parameters. Firstly, it was analysed whether the methodology would work for a security critical system such as SCADA. This was decided by considering whether the methodology could be applied on a large scale machine or system. After that the second method was to decide by the amount of interest the methodology generated in the academic world. This was done by looking at the number of citations of the articles or book that introduced the methodology. Then the final selection of the methodology was made. The methodologies that were considered are shown in the table below:

Serial Number

Types Methodologies Number of Citations

1 Multilateral Approaches

1. Multilateral security requirements analysis (MSRA)

23

2. Security Quality requirements engineering methodology (SQUARE)

195

2 UML Based approaches

1. Misuse Cases 65

2. SecureUML 555

3. UMLSec 637

3 Goal-oriented approaches

1. KAOS + Anti-models 19

2. Secure i* 54

3. Secure Tropos (by Mouratidis) 132

4 Risk analysis based approaches

1. CORAS 117

2. Tropos Goal risk framework 49

3. Model-based information system security risk management (ISSRM)

41

Table 1: List of methodologies

Out of these methodologies I selected one from each of the category. This selection was made on the basis of the results of the first two parameters.

The methodologies selected are in Bold in Table 1 above.

I explain each of the selected methodologies in detail and compare them.

1. Security Quality Requirements Engineering Methodology (SQUARE) SQUARE is a security requirements methodology that consists of nine steps to elicit and finalise security requirements for a system. The methodology aims to produce clear, precise, non-conflicting and validated security requirements for a system. Each of the steps require an input, the techniques for performing that step, participants for the step and the output of the step. Generally the set of

9

output for one step act as input for the next step. The authors claim that the methodology is most effective when conducted with a team of requirements engineers with security expertise and stakeholders of the project [1]. The nine steps involved in the process are given in the Table 2.

S No. Step Input Techniques Participants Output

1. Agree on definitions

Candidate definitions from IEEE and other standards

Structured interviews, focus group

Stakeholders, requirements team

Requirements definition

2. Identify security goals

Definitions, Candidate goals, business drivers, procedures and policies, examples

Facilitated work sessions, surveys, interviews

Stakeholders, Requirements team

Goals

3. Develop artefacts to support security requirement definitions

Potential artefacts (e.g. scenarios, misuse cases, templates, forms)

Work session Requirements engineers

Needed artefacts (Scenarios, misuse cases, templates, forms, models)

4. Perform risk assessment

Misuse cases, scenarios, security goals

Risk assessment method, analysis of anticipated risk against organisational risk tolerance including threat analysis

Requirements engineers, stakeholders, risk experts

Risk assessment results

5. Select elicitation techniques

Goals, definitions, candidate techniques, expertise of stakeholders, organizational style, culture, level of security needed, cost benefit analysis, etc.

Work session Requirements engineers

Selected elicitation techniques

6. Elicit security requirements

Artefacts, risk assessment results, selected techniques

Joint Application Development (JAD), interviews, surveys, model-based analysis, checklists, lists of reusable requirements types, document reviews

Stakeholders facilitated by requirements engineer

Initial cut at security requirements

7. Categorize Initial requirements, Work session Requirements Categorised

10

requirements as to level (system, software, etc.) and whether they are requirements or other kinds of constraints

architecture using a standard set of categories

engineers, other specialists as needed

requirements

8. Prioritise requirements

Categorised requirements and risk assessment results

Prioritisation methods such as Triage and Win-Win

Stakeholders facilitated by requirements engineers

Prioritised requirements

9. Requirements Inspection

Prioritized requirements, candidate formal inspection technique

Inspection methods such as Fagan, peer reviews

Inspection team

Initial selected requirements, documentation of decision making process and rationale

Table 2: SQUARE

Conclusion SQUARE was developed keeping in mind that most of the systems do not focus on security requirements in the early stages and hence it is made for those systems where security is added as an afterthought and add-ons to the system’s functional requirements [1]. The method considers that a system has only one business goal and multiple security goals derived from that business goal. The method is well-defined and easy to understand and establishes clear and precise goals between stakeholders and developers. There is no mention of asset management and vulnerabilities to the system [2]. The issue of conflicting requirements and validation of the elicited requirements is addressed properly.

2. UMLSecThis approach is based on the Unified Modelling Language (UML) for establishing security in critical infrastructure systems [6]. The method focusses on the development of design models which include security in it along with other features. It aims to help in reducing implementation costs. It extends the already existing UML for the inclusion of security features and makes use of the fact that UML can be applied any type of software systems be it object-oriented or not [6].

UMLSec uses different diagrams like Misuse cases, activity diagram, state chart diagrams, sequence diagram, class diagram, deployment diagram and subsystems diagram to model different aspects of the system for security requirements. UMLSec introduces three extensions to UML diagrams, stereotypes, tagged values and constraints. Before introducing the main concept some the semantics and definition useful for understanding the methodology are introduced.

Stereotypes are new modelling elements that extend the existing classes in the model. It is denoted by << >>. Tagged values are name, value pairs that can define either data values or references to

11

other model elements. It is denoted by {tag = value}. Constraints are added to the diagram to force them to fulfil the constraint [6].

The formal semantics of UMLSec introduce a set called Events which consists of the set of messages being exchanged between system components. A set called expressions (Exp) consists of the set of arguments sent with the message. An input and output queue are used for sending and receiving messages. The concept of an adversary is introduced who can harm the system and threats for a subsystem introduced by an adversary are also modelled. Threats like delete, read, insert and access can be modelled. Important security properties like secrecy, integrity, authenticity, secure information flow, freshness are defined using the UMLSec notations.

UMLSec methodology explains the types of stereotypes, tagged values and constraints used in greater detail. It explains how to model the types of threats using the terminologies and definitions for each stereotype. One unique thing that the methodology involves is the checking of secure principles in the system design like fail-safe defaults, economy of the mechanism, separation of privilege, least privilege etcetera. A tool suite is provided for the implementation of UMLSec.

Conclusion UMLSec was developed for the security and safety of critical infrastructure systems in mind. It aims to create a secure environment for the interconnection and smooth functioning of the security-critical systems. The methodology analyses the system at a fairly low-level and is suitable for an operational analysis [5]. Most of the security issues are addressed. The methodology does not focus on elicitation of security requirements, completeness and validation of functional, non-functional and security requirements [2].

3. Secure Tropos (Mouratidis et al.) Secure Tropos extends the Tropos methodology which enable developers to consider all the stages of software methodology. The paper defines security requirements as a manifestation of a high level organisational policy into the detailed requirements of a specific system. It claims that adding security as an afterthought leads to problems as the requirements have to be fitted into the existing system and may create new problems.

Tropos adopts the i* modelling framework which introduces the notion of actors, goals, tasks, resources and soft goals. The notion of dependency between two actors is there when one actor depends on another for the fulfilment of a task or a goal or to deliver a resource. The depending actor is called depender and the actor on whom the other actor depends is called the dependee. The methodology covers five stages namely, early and late requirements, architectural design, detailed design and implementation which has also been adopted in secure tropos.

To allow developer to clearly model security requirements, a concept of constraints is introduced and actors, goals, tasks, resources and soft goals are also extended with security in mind [5]. Three things which will help in modelling security are introduced [2]:

Constraint and security constraint – a restriction related to security issues like confidentiality, integrity, privacy etc.

Secure Dependency – a secure dependency between one or more actors.

Secure Entities - Any secure goal, task, resource of the system.

12

Figure 1: Secure Dependency

(Source: [5])

Figure 2: Secure entities

(Source: [5])

The concept of positive and negative contribution link is added. The positive contribution is added when a node supports the other and negative is added when a node denies the other. All these concepts are added as security concepts in each of the five phases of the development process mentioned earlier.

Conclusion Secure Tropos is a well-defined process which allows the developers to consider security issues at every stage of system development [5]. This method has an advantage that it can be applied to all the stages of software development. Attacker and threat analysis is possible with the help of the diagrams [2]. Models can be validated based on which one deals with the attacks in the best possible way [2]. Risk assessment and assets are not mentioned specifically.

4. CORAS The authors define CORAS as the security risk analysis method. It uses Unified Modelling Language (UML) for modelling the target system. The CORAS method provides a computerised tool designed

13

to support documenting, maintaining and reporting analysis results through risk modelling, table-based documentation, consistency checking and more [8]. It consists of seven detailed and well-defined steps. CORAS does not focus specifically on security requirements but using the risk assessment and treatment, the developers can understand what security requirements may be needed for the risk treatment. Every step defines who should be involved in the step and what the outcome of the step is. The seven steps are explained below:

1. Introductory meeting The long-standing credo of requirements engineering reads: ‘‘If you don’t know what you want, it’s hard to do it right.’’[2].The first step in COARS tries to achieve that. The introductory meeting tries to create a common ground between the stakeholders and the system analysts. The clients present their goals and target of the analysis, what the assets are, what is the scope of the system and what terminologies are to be used.

2. High level Analysis In this step the analysts produce their side of the system (Target). They present the concepts they understood about the target. The clients and the analysts together identify the assets that need protection as well as the high level analysis of the system. This step produces and asset diagram and a UML diagram for the target description.

3. Approval This step is the final step of the preparatory stage. Both sides decide on the asset and rank it based on their importance. The consequence and likelihood values for the asset is also defined. A consequence value determines what level of damage can be done to the assets. The likelihood values decides how likely is it to cause damage to the assets. It is very important for all the stakeholders to be present in this meeting because this step sets the stage for the next four steps.

4. Risk identification

Figure 3: Symbols from the CORAS risk modelling language

(Source: [8])

This step starts with “Structured Brainstorming” [8]. In this the stakeholders, all with different backgrounds and level of experience, decide what the risks to the target are. The risks identified are documented and a risk evaluation matrix is created. The final product is the threat diagram with identified threats, vulnerabilities and threat scenarios.

14

5. Risk estimation In this step, all the threat diagrams are extended with likelihood and consequence estimates. The likelihood estimate decide how much damage can be caused to the asset if the threat is realised. The consequence estimate relates the asset to an unwanted incident. To achieve this every stakeholder puts forward a possible threat scenario. For those scenarios that are difficult to estimate, help of the analysis leader is taken. This step should involve the technical experts, users and experienced stakeholders.

6. Risk evaluation In this step, the extended threat scenario is used to put all the risks into a risk matrix which helps in deciding which risk should be treated and which is acceptable. After this process, the risk matrix is presented to the client for inspection. A risk diagram containing all possible risks that may need treatment is produced at the end.

7. Risk treatment In the last step of this process, the risks that cannot be accepted into the system are evaluated and countermeasures for the risk reduction is decided. Also the economic feasibility of the countermeasures is estimated. According to the economic feasibility the countermeasures are finalised. The end result is a treatment and treatment overview diagram.

Non-Functional Requirements In the requirements engineering world, there is a broad consensus on what the functional requirements are and how they should be defined. However when it comes to non-functional requirements everyone has different notions and definitions regarding that [9]. Different authors define non-functional requirements in a different way.

Robertson and Robertson [16] define it as “A property, or quality, that the product must have, such as an appearance, or a speed or accuracy property.”

Kotonya and Somerville [17] define it as “Requirements which are not specifically concerned with the functionality of a system. They place restrictions on the product being developed and the development process, and they specify external constraints that the product must meet.”

IEEE definition states non-functional requirements as a software requirement that defines not what the system will do but how the software will do it, for example, software performance requirements, software external interface requirements, design constraints etc.

As we can see, different publications define non-functional requirements in a different perspective. This makes non-functional requirements ambiguous to understand and deter proper research related to non-functional requirements. Hence, there is a need to have a standard definition for non-functional requirements. This will help in making better requirements and design decisions and will ultimately lead to a better software product and less project failures. Also, while documenting functional and non-functional requirements, some methods define them separately while others which define, don’t make a strict separation [9]. Traditionally security requirements fall into the category of non-functional requirements but can be included as functional requirements [10]. A security requirement can be described as “The system shall prevent any unauthorised access to the customer data.” But if you describe it as “The database shall grant access to the customer data only to those users who have been authorised” it becomes a functional requirement [9]. Therefore it depends on how you define the requirement. Also non-functional requirements can also be divided into various types such as performance, usability and security requirements. The notion of dividing functional and non-functional requirements into strict and separate boundaries needs to change. It creates an illusion that functional and non-functional requirement cannot overlap and are completely different from each other which is not the case. The

15

requirement should be defined and documented into multiple specific categories that is not as vague and vast as non-functional requirements.

Supervisory Control and Data Acquisition systems (SCADA) SCADA systems are widely used for industrial processes such as electric power production and distribution, water treatment and supply, gas and oil production and distribution, telecommunications, chemistry, nuclear fusion [4], [12]. Kang, Lee, Kim and Hur [13] describe it as a twin package of software and network infrastructure into a supervision system that is used to acquire data, analyse it and send control actions. These are not full control systems but they focus on the supervisory level [12]. Earlier these systems communicated using serial networks and complied with normal standards. The protocols supported minimal functionality and data was sent without encryption or authentication [4]. This is a surprising thing as these systems supported critical infrastructures. This shows that there was little concern for the security of data sent through SCADA systems during that time. However, these days SCADA systems are connected to the internet and are no longer isolated. SCADA systems have become more or less like an enterprise software system as can be seen in Fig. 6 [4]. Earlier the SCADA security issues were primarily about physical security but nowadays the security concerns are more about network and communication infrastructures [15]. The integration of SCADA systems with IT systems is also under way which further increases the security risks to these systems [13].There is a need for proper security measures to be put in place for the protection of these systems. Putting all the security measures at once may not be possible and may hinder the proper functioning of such systems but slowly increasing security measures is a necessity. Too much of security measures should also not be applied as it may slow down the exchange of data between terminals.

Figure 4: SCADA Architecture

(Source: [4])

16

As expected there are many organisations working for the protection of SCADA systems. Some of the major ones are shown in Table 3 [4]:

Organisations Objective

National Infrastructure Advisory Council Cyber security Of SCADA and process control systems

National Communication Systems Security of Communication systems including SCADA

National Infrastructure Protection Plan Risk assessment of all cyber systems including SCADA and DCS

Sandia National Laboratory – Centre for SCADA security

SCADA research, training and development

Table 3: List of organisations working for SCADA security

Smart Grids and SCADA

Nowadays, the conventional grid is being replaced by the intelligent, efficient and distributed grids. These grids are known as smart grids and are being anticipated as the next revolution in the industry of power supply [19]. They can be situated at each substation in the system and connected through sensors to transmit their environment data and signals to other smart grids [19]. These smart grids can greatly enhance transmission efficiency and capability. However this also increases the need for security of these systems [18]. The security of these smart grids is related to the security of SCADA as SCADA is the central control system which sends control and data signals to all the substations while smart grid are situated as every substation to receive and send signals. One important part of electricity supply infrastructure are smart grids. Smart grids are the advanced and improved electricity grids used to increase the efficiency of electricity distribution and generation. These use the SCADA systems for their working. Hence, there is a great need to protect them from security attacks.

The first step in increasing the security of these systems should be to formulate clear and precise security requirements for the system. In this project I will create a methodology that will try to minimise the security risks to SCADA electricity supply systems by identifying risks and vulnerabilities to those systems and cresting a set of security requirement based on those risks and vulnerabilities. There are various ways to assess and reduce risks to SCADA systems. Authors Ralston, Graham and Hieb [4], list out tools and researches published on SCADA risk assessment. Some of the tools mentioned are OCTAVE and CORAS [8]. I have chosen CORAS as the risk assessment method in my methodology because it focusses more on security requirements and defines clearly what methods are being used for security assessment [4].

17

Chapter 3

Project Progress Comparison of the Methods In this section I will present a comparison between the four methodologies I reviewed. The comparison is based on specific parameters. Those parameters were decided based on their relevance and applicability to the Supervisory Control and Data Acquisition systems (SCADA). The parameters on which the methodologies were evaluated are

Criteria 1: Are the security triad Confidentiality, Integrity and Availability covered?

Criteria 2: Is the methodology applicable on a system, machine or both?

Criteria 3: Are the views of stakeholders considered?

Criteria 4: Is the concept of asset identification applied?

Criteria 5: Which stage of software development does the methodology apply to?

S. no Methodology Criteria 1 Criteria 2 Criteria 3 Criteria 4 Criteria 5

1. SQUARE Yes Both Yes No Requirements Phase

2. UMLSec Yes Machine No Yes Design Phase

3. Secure Tropos

Yes Both Yes No Requirements, design and implementation

4. CORAS Yes Both No Yes Requirements Phase

Table 4: Comparison table

All the methods have some positive and negative points. Methods like SQUARE are very general and can apply to any system. Also you can use your own methods for risk assessment, requirements elicitation, requirement categorisation and prioritisation. It recommends some methods for each of the processes except risk assessment. The concept of asset identification is left upon the risk assessment method chosen by the stakeholders. It only applies to requirements phase.

UMLSec mainly applies to design phase of the systems and can be used to identify various attack scenarios and vulnerabilities to the system being developed. There is not much emphasis on how the stakeholders will resolve conflicts and validate the requirements. Secure Tropos applies to all stages of software development and considers actors, goals, resources and tasks for modelling. This is particularly useful for systems like SCADA which can be modelled in a similar way. CORAS can be applied to SCADA systems because it provides an automated tool and clearly defines the type of risk analysis like fault tree analysis, vulnerability tree, attack trees to model risks. The concept of asset identification is included in the methodology.

All these methodologies have few positive points and combining them into a single methodology can create an efficient and effective methodology.

The final artefact that I will produce will be a well-defined security methodology that will take a security need and turn into a clear, implementable and testable requirement. The methodology aims to bridge the gap between the clients, system analysts and developers of the system or product and to apply it on SCADA electricity supply systems and smart grids. It will set the security requirements

18

straight between the parties and remove any conflicts regarding requirements among them. This will prevent any future project failures and losses.

ARCHITECTURE After studying the four selected methodologies I created an architecture of the final artefact. I created an architecture that will take some parts from the four methodologies studied above and create a new methodology. The architecture is shown below:

Figure 5: Architecture

The methodology will take four phases to complete. In the first phase, the stakeholders will conduct a meeting and decide upon the definitions of basic and important terms of methodology. The clients, analyst and developers are the stakeholders. The terminologies and definitions can be decided by choosing well established definitions from standard documents like IEEE or ISO/IEC. After this step, the business goals of the system are identified. Business goal is something that when achieved will fulfil a need of the organisation in terms of their business. All the stakeholders must be present for this phase. The business goals documented can be one or multiple. The aim of the first phase will clear all ambiguities and reduce the differences between the stakeholders.

In the next phase, the assets of the system are identified. An asset register is created. The main actors and resources in the system are also documented and explained. This concept has been borrowed from the Tropos methodology which is a goal-oriented approach [7]. Based on the business goals, assets, resources and actors, the security goals are identified. This completes the second phase. The second phase tries to create a clear picture of the system to be built.

In the third phase, based on the actors, security goals and resources the analysts and security experts will create UML diagrams which have security extensions. UMLSec is recommended here for

19

its specific details and applicability on critical infrastructure systems like SCADA. It produces detailed diagrams which depicts possible threat scenarios and attacks. After the diagrams are complete, a risk assessment will be completed which will list all the possible risks to the system and how can these risks be treated. This will be accomplished by creating a threat diagram, risk diagram and treatment diagram as in CORAS [8]. This will end the third phase. This will phase will make the stakeholders clear about the system functionalities and security issues. They can also discuss about the possible treatment measures for each security threat.

In the fourth phase, the security requirements will be elicited based on the risk assessment results and UML diagrams. The first set of security requirements document is created by the system analysts and developers. The document is validated and the completeness of the requirements is checked by discussing it with the client. After validation and resolution of the conflicts the final product is generated. The final product as shown in the figure is a security requirements document.

This is the basic architecture if the final artefact and each step will later be elaborated. Next I present some sample document after the steps in the methodology are carried out.

Asset Document The table below is an example of the asset document that will be created during the methodology. The table lists some assets of an electricity supply system that includes a SCADA system. The importance is ranked on the scale of 1-5 with 5 being the most important and 1 the least. Type of asset can specify physical or logical asset.

ASSET IMPORTANCE TYPE

Communication Infrastructure

4 Physical

Communication network

4 Logical

Process and control signal data

5 Logical

Data Acquisition Server 3 Logical

Human-machine interface

4 Physical

Substations 4 Physical

Data Acquisition Server 3 Physical

Table 5: Sample Asset Document

20

Risk assessment Results The risk assessment will generate a threat diagram, risk matrix and a risk assessment document. Here I will present an example of the risk assessment document that will help generate the final security requirements document. The document will show few examples of the possible threats to the assets of SCADA electricity supply system. The risk column shows the types of risk to the asset. The likelihood column shows the likelihood of that risk occurring on the scale of 1-5. The value of 1 will mean the risk may rarely occur and 5 means the risk has a high possibility of occurring. The impact on system will present what could go wrong with the system if the risk occurs.

ASSET IMPORTANCE RISK LIKELIHOOD VALUE

IMPACT ON SYSTEM

Communication Network

4 Intercept data being sent between substations or between master station and substation.

4 Replay attacks can impact system functioning.

Disclosure of confidential data.

Communication Infrastructure

4 Damage the communication infrastructure physically.

3 The system will be unable to send data on time.

Process and Control signal data

5 Loss of integrity and confidentiality

4 The system will send wrong command to the substations.

Replay attacks can make the system malfunction.

Table 6: Sample Risk Document

21

Sample Document This is an example of the final security requirement document that will contain the final set of

security requirements.

Figure 6: Sample Security Requirements Document

22

Research Methodology The research methodology for the project can be divided into three sections, background research,

implementation and testing phase. I will explain the work done under the background research and

the future work to be done in the implementation and testing phase.

Background Research In the background research I studied the following things:

Some of the security requirements methodologies which are used today. Four of them were

selected for further study.

How the non-functional requirements are defined and documented

SCADA systems in general and why network security has become as important as physical

security for electricity supply systems.

Implementation Phase This phase deals with the implementation of the final artefact that has to be produced for this

project. The implementation will be carried out by further readings on the methodologies used to

create the architecture of the artefact. In this phase, some the activities done are

Comparison of the four methodologies on some criteria based on applicability on SCADA

systems.

An initial architecture of the methodology that will be created for the final artefact.

The remaining work needed for implementation of the artefact is listed below:

Detailed study of SCADA electricity supply system in detail including its working, security issues,

threats and vulnerabilities in the electricity supply system.

Create a practical and working methodology that will be applied on the system.

Evaluation Phase After the artefact is ready, it needs to be tested. The test will confirm whether the artefact produces

expected results. The various evaluation methods that I am considering are:

1. Delphi testing: This method of testing involves presenting your artefact to a peer or an

experienced person in the related field. The peer will evaluate the artefact and give

feedback. The feedback can then be used for improving the artefact.

2. Interview: Interviews can be a good way to evaluate a methodology. Interviewing an

organisation which uses a similar methodology can give produce valuable feedback on how

the methodology can be practically useful for the organisation.

3. Comparison with other methodologies: There are numerous existing methodologies for

security requirements elicitation. Comparing the methodology with the already existing ones

can give a clear picture of where the method stands.

4. Practical implementation: One way to evaluate the methodology is to practically implement

the methodology in an organisation. After the methodology is complete, the results can be

simulated and compared with the results from the previously used methodologies. This can

establish whether the methodology is as effective, better or not as god as the previously

23

used ones. This is one of the most effective methods but it takes a lot of time to establish

the validity of the methodology.

These are some of the evaluation techniques that I can use. The fourth one cannot be carried

out due to time constraints. The first, second and third seem practical. I will carry out one or two

of these methodologies for the evaluation of my artefact. The evaluation results will then be

used to refine and improve the methodology.

24

CHAPTER 4

Project Plan

25

References 1. Mead, N., Hough, E., Stehney, T., Security Quality Requirements Engineering (SQUARE)

Methodology, Carnegie Mellon Software Engineering Institute, Technical Report CMU/SEI,

(2005).

2. Fabian, B., Gurses, S., Heisel, M., Santen, T. and Schmidt, H., A comparison of security

requirements engineering methods, Requirements Engineering, Vol. 15, pp 7 – 40, (2010).

3. Poulsen, K., Cyber-attacks caused power outages in Brazil, Wired Magazine, (2009).

4. Ralston, P.A.H., Graham, J.H. and Hieb, J.L., Cyber Security risk assessment for SCADA and

DCS networks, Elsevier publications, ISA Transactions, Vol. 46, pp 583-594, (2007).

5. Mouratidis, H. and Giorgini, P., Secure Tropos: A Security-Oriented Extension of the Tropos

Methodology, International Journal of Software Engineering and Knowledge Engineering

Vol. 17, No. 2, 285–309, (2007).

6. Jürjens, J., Secure systems development with UML, Springer, New York (2003).

7. Fuxman, A., Liu, L., Mylopoulos, J., Pistore, M., Roveri, M. and Traverso, P., Specifying and

analysing early requirements in Tropos. Requirements Engineering, 9:132-150, (2004).

8. Braber, F., Hogganvik, I., Lund, MS., Stølen, K. and Vraalsen, F., Model-based security

analysis in seven steps—a guided tour to the CORAS method. BT Technology Journal Vol. 1,

pp 101–117, (2007).

9. Glinz, M., On non-functional requirements. In: Proceedings of 15th IEEE international

requirements engineering conference, pp 21–26, (2007).

10. Johnstone, M. N., Security Requirements Engineering- The reluctant Oxymoron, Australian

Information Security Management Conference, (2012).

11. BSO ISO/IEC 27000: Information Technology – Security Techniques – Information security

management systems- Overview and Vocabulary, 2014.

12. Daneels, A., Salter, W., What is SCADA? , International Conference on Accelerator and large

experimental physics control systems, (1999).

13. Kang, D.J., Lee, J.J., Kim, B.H. and Hur, D., Proposal strategies of key management for data

encryption in SCADA network of electric power systems, International Journal of Electrical

Power and Energy systems, Vol.33(9), pp.1521-1526, (2011).

14. BSO ISO/IEC 12207: Systems and software engineering - Software life-cycle processes, 2008.

15. Igure, V.M., Laughter, S.A. and Williams, S.D., Security issues in SCADA networks, Computer

& Security, Elsevier Publications, Vol. 25, pp 498-506, (2008).

16. Robertson, S. and Robertson, J., Mastering the requirements process, ACM press, (2006).

17. Kotonya, G. and Somerville, I., Requirements Engineering: Processes and Techniques, John

Wiley & Sons, (1998).

18. Metke, A.R. and Ekl, R.L., Security technology for Smart Grid Networks, IEEE Transactions on

smart grids, Vol. 1, pp 99-107, (2010).

19. Amin, M.S. and Wollenberg, B.F., Toward a smart grid, IEEE power and energy magazine, pp

34-41, (2005).

26