RSLingo4Cybersecurity:

Rigorous and Reusable Requirements Library in Cybersecurity

Domain
Luís Gonçalves, 173949
luiscpgoncalves@ist.utl.pt

Advisor: Prof. Alberto Manuel Rodrigues da Silva

Co-Advisor: Prof Sofia Azevedo
Department of Computer Science and Engineering (DEI)
Instituto Superior Técnico - Universidade de Lisboa

Abstract. Requirements Engineering is the process that bridges the gap between the
vague idea of what we want a system to do and the task of building the system that will
actually work and perform the way we want. RSLingo a rigorous requirements
specification approach based on linguistic patterns, is a long-term research initiative in
the Requirements Engineering area that want to that process more efficient and reliable.
With the on growing concerns about cybersecurity we want to extend RSLingo with
security concerns that will meet the current security specification needs of the system
designers
In this report we propose to extend the language of RSLingo with
RSLingo4Cybersecurity research which is a security requirement specification
approach that shall explore and deal with the phenomenon of specifying and
documenting security-related requirements with the goal of producing security
requirements specifications in a more systematic and rigorous way. We also propose to
define reusable security requirements specification libraries to be used in real case
scenarios and test both solutions in terms of correctness and consistency.

Keywords: RSLingo; Cybersecurity; Requirements engineering.

1
 Table of Contents
1 Introduction ..................................................................................................... 3
2 Research Methodology .................................................................................... 4
3 Background...................................................................................................... 5
3.1 Requirements Engineering ...................................................................... 5
3.2 RSLingo .................................................................................................. 6
3.2.1 RSL Language ........................................................................................ 6
3.2.2 RSLingo Tools ........................................................................................ 6
3.3 Cybersecurity .......................................................................................... 7
4 Related Work ................................................................................................... 7
4.1 Search Query........................................................................................... 8
4.2 Search for Relevant Papers ..................................................................... 8
4.3 Screening the Papers ............................................................................... 9
4.4 Analyzing the Full Document ................................................................. 9
4.5 Publications Analysis ............................................................................ 11
5 Solution Proposal ........................................................................................... 15
5.1 Security Requirements Background ...................................................... 15
5.2 Language – RSLingo4Cybersecurity .................................................... 16
5.2.1 Threat Specification ............................................................................. 16
5.2.2 Misuse Cases......................................................................................... 18
5.2.3 Security Requirements Specification .................................................... 18
5.2.4 Security Relations ................................................................................. 19
5.3 Library .................................................................................................. 20
6 Evaluation ...................................................................................................... 21
7 Conclusion ..................................................................................................... 21
References .............................................................................................................. 22
1 Introduction

In recent years reports of security failures in software have statistically increased.

Statistics from the Software Engineering Institute’s CERT Coordination Center 1, a
center of Internet security expertise, show that the number of reported application
vulnerabilities rose from 171 in 1995 to 5,990 in 2005, with this substantial increase in
vulnerabilities, the attacks to those applications also increased. The Utah Department
of Technology Services2 reported that in 2011 they faced one million malicious attacks
per day while in 2015, they faced 20 million attacks every day. One source of these
security problems is the way security is approached in the design and conception of
these systems. It is widely accepted that designing secure computer systems is a
difficult problem. When choosing security measures, the security system designer must
consider the design of the entire system, and not incorporate security technologies at
random. One security vulnerability in a company system can cost up to 15 million
dollars a year to that same company3. Bruce Schneier states that “Security is a chain;
it’s only as secure as the weakest link. Security is a process, not a product” [1].
Designing system security is best done by utilizing a systematic engineering approach.
Methods and techniques have been developed to protect data, programs, and networks,
from attacks or other infringements through mechanisms such as access controls and
firewalls. However, most techniques were developed for earlier generations of
computing environments that were largely within a single, closed jurisdictional control,
such as a single enterprise with a well-defined boundary. The open Internet
environment, together with new business and organizational practices, has increased
the complexity of security and privacy considerations dramatically. Traditionally
system designer only incorporates security after the system is produced or when an
attack occurs leading to elevated costs. When designing a system, we have to be
concerned about security from the first approach of the system design.
This dissertation proposes – RSLingo4Cybersecurity - an extension to RSLingo [2],
a rigorous requirements specification approach based on linguistic patterns, and intends
to meet the current security specification needs of the system designers. RSLingo was
originally based on two languages and the mapping between them: RSL-PL, an
extensible language for dealing with information extraction from requirements written
in natural language; and RSL-IL, a rigorous language with a fixed set of constructs for
representing and conveying RE-specific concerns. However, recently RSL-IL evolved
to a new language, called RSLingo’s RSL[3] or just RSL for the sake of brevity. This
language was created with the purpose of improving the quality of system requirement
specifications [4]. With RSLingo4Cybersecurity we intend to explore and deal with the
phenomenon of specifying and documenting security-related requirements. We also
want to create one or more security libraries to be used in real case scenarios as a
solution to recurring problems since security requirements are highly reusable. Finally,
we want to evaluate both solutions in terms of correctness and consistency. In figure 1,

1- https://www.cert.org/
2- https://dts.utah.gov/
3- http://money.cnn.com/2015/10/08/technology/cybercrime-cost-business/index.html
we can see an overview of our work objectives and how this project shall be developed.
It shall be developed in two semesters: in the first, we shall research, propose a solution
and elaborate a report. In the second, we shall implement the solution, evaluate it and
elaborate the final thesis.
This report is organized as follows: the research methodology adopted through the
project is presented in section 2. Section 3 introduces the background on the topics of
cybersecurity, requirements engineering and RSLingo. In section 4 the related work
regarding Requirements Engineering (RE) and cybersecurity. Section 5 formalizes a
solution proposal regarding RSLingo4Cybersecurity approach. Section 6 outlines the
methodology for the evaluation of the proposal and lastly the section 7 draws some
conclusions about the work that was carried out and overviews the follow-up steps.

Fig. 1- RSLingo4Cybersecurity work objectives

2 Research Methodology

Considering the number of publications available and the complexity of those, our
research method aimed at analyzing and identifying the available literature on security
requirements research and categorizing it in a systematic way. We followed a
systematic literature review (SLR) [5] that has been defined as “a means of identifying,
evaluating, and interpreting all available research relevant to a particular research
question, or topic area, or phenomenon of interest” [5]. With this approach to the
problem, we gathered several publications that were relevant to our work.

3 Background

In this section we shall introduce the concepts and the terminology that will be
approached in the later sections.

3.1 Requirements Engineering

Requirements engineering is the process that bridges the gap between the vague idea
of what we want a system to do and the task of building the system that will actually
work and perform the way we want. Normally stakeholders (an individual or
organization who may affect or be affected by the system), want a system that will solve
a very broad problem, for example, for flight reservation portal that the system will help
them sell more tickets. In seeking to describe the purpose of a system, we need to look
beyond the system itself, and into the human activities that it will support. The purpose
of the flight reservation portal is not in the technologies that will be used but how the
system will let customers buy more tickets in a more easy and convenient way. Such
problems can be quite complex since it involves many different types of people that
may have conflicting interests. Requirement Engineering helps dealing with that
complexity by systematically breaking down complex problems into simpler ones, so
that we can understand them better.

When designing a system there are two main activities, the business requirements
and the system requirements. The business requirements are criteria for the software to
be successful in meeting the user needs. Generally, they focus on the “what” not the
“how”. In the example of the flight reservation portal, someone could state that the
system shall increase the tickets sold by 20%, while for system requirements, that
addresses the “how” of the system, it could be that the portal is implemented using a
certain programming language. For those two types of requirements we can have many
styles to describe them:

• Goals describe an observable and measurable end result having one or more
objectives to be achieved within a more or less fixed timeframe;
• Functional requirements describe a particular behaviour or function of the system
when certain conditions are met;
• Quality requirements describes how a system should behave and what limits there
are on its functionality;
• Constraints describe a limitation or restriction that a system has in order to achieve
its objective;
• Use cases describe a specific set of interactions between an actor (e.g., end-user) and
the system under study;
• User stories describe a set of needs that some stakeholders (e.g., end-users) may
have regarding the system under study

5
3.2 RSLingo
The RSLingo name [2] appears from a paronomasia on “RSL” and “Lingo”. “RSL”
stands for Requirements Specification Language that emphasizes the purpose of
formally specifying requirements. The language that serves this purpose is RSL-IL, in
which “IL” stands for Intermediate Language. RSLingo, is a linguistic approach for
improving the quality of requirements specifications, which is based on two languages
and the mapping between them: RSL-PL, an extensible language for dealing with
information extraction from requirements written in natural language; and RSL-IL, a
rigorous language with a fixed set of constructs for representing and conveying RE-
specific concerns. Originally, RSLingo approach considered two distinct stages:
definition at process-level and usage at project-level. In the process-level, there was
produced a mapping from RSL-PL to RSL-IL and in the project-level is focused in
writing the requirements specifications document in natural language. However, to a
technical user already familiar with the concepts of RE, the Natural Language
Processing (NLP) phase can be omitted, as there is already a much better understanding
of the RE concerns and of its documentation process.

3.2.1 RSL Language

“RSLingo's RSL” (or just “RSL” for brevity) is a language that was created based on
the design of the former languages, i.e., ProjectIT-RSL [6],RSL-IL [7] and RSL-PL
[6] but also others such as Pohl [19] XIS*[8] and SilabREQ [9]. This language was
developed with the purpose of creating a pattern language to improve the quality of use
cases specifications [4].
RSL is a language that includes a rich set of constructs logically arranged into views
according to multiple RE-specific concerns that exist at business and system abstraction
levels. Conceptually, RSL is a process and tool independent language, meaning it can
be used and adapted by multiple users and organizations with different
processes/methodologies and supported by multiple types of software tools, namely an
Excel spreadsheet template and an Eclipse and XText-based tool.

3.2.2 RSLingo Tools

RSLingo features two tools: RSLingo-Studio and RSL Excel Template. RSLingo-
Studio is a tool that is implemented using an Integrated Development
Environment (IDE) called Eclipse1 and Xtext2 which is a framework for development
of programming languages and domain-specific languages. This tool aims to improve
and speed up the process of validating a project’s System Requirements Specifications
(SRS) by making this an automatic step. It also features the ability to produce UML
Diagrams from these SRS documents after being properly validated. RSLingo also
features an excel template with cells and parameters that allows the specification of the
requirements and then to be imported to RSLingo-Studio, which will automatically
generate the RSL specification. The RSLingo-Studio also allows to export the RSL
specification to the excel template.

1- http://www.eclipse.org/
2- https://www.eclipse.org/Xtext/
3.3 Cybersecurity

Cybersecurity is a set of technologies, processes and practices designed to protect

computer systems and networks from attacks, which includes theft, damage or
disruption. Cybersecurity is an on growing concern as systems and networks have been
increasing in complexity and value. With this increase in value, there are more attackers
interested in causing damage and robbing the systems and with the increase of
complexity in these systems there is also an increase in attack surfaces, which is the
sum of vulnerabilities1 (weaknesses that expose risk) of a given system, and in attack
vectors, which is the “route” that an attack is carried out (i.e. Internet, Bluetooth). By
adding these two factors together and we have an increase in threats to these systems,
that is, the probability that an attack will occur on an existing vulnerability.

4 Related Work

Several publications have been released in books, conference tracks and workshops,
in the area of Security Requirement Engineering (SRE). Particularly in the last decade,
there has been a substantial increase in those publications, revealing a steady interest
of both researchers and practitioners. Unfortunately, it is difficult to position our
research to available practices to choose the most appropriate one because these SRE
issues are addressed by different communities with different interests and backgrounds,
namely by the communities of requirements engineering, software engineering,
information systems and computer security.
Our research aimed to identify and analyze the available literature on security
requirements research with respect to the specification of those requirements. The data
was mainly obtained using the Google Scholar search
engine(https://scholar.google.pt/). We follow the example of Souag et. Al mapping
study [10]. This publication follows the Systematics Literature Review (SLR)[5]
method and was a great help since it already had a study and research of the state-of-
the-art on the topic of security requirements engineering.

The main processes of this study involved the following tasks: defining the
keywords, conducting the search for relevant papers; screening the papers by reading
the title, abstract and keywords and analyze the full article definition.

1- https://www.checkmarx.com/glossary/owasp-top-10/
2- https://www.paloaltonetworks.com/cyberpedia/what-is-cyber-security
 1 2 3 4

Fig. 2 - The four different stages that compose the research methodology

4.1 Search Query

Task-1: We define the relevant keywords and the respective search query. In this
scope we intended to make the research more accurate and decrease the number of less
relevant results. The keyword defined were: “security”; “specification”;
“requirements”; “engineering”. To filter the date of the results, we had to convert a
normal calendar date to Julian1 format. The equivalent date in Julian format of the date
1 January 1999 to 31 December 2017: 2451180.24252 - 2458119.24252. With these
keywords and a combination of them, we made the following search query:
“security requirement specification” OR “security requirements engineering” OR
“security requirements” daterange: 2451180.24252- 2458119.24252

4.2 Search for Relevant Papers

Task-2: With the keywords and query defined, we used the Google Scholar search
engine, to search for papers matching the query and the keywords. Only publications
written in English and published after the year 1999 were considered. We got
approximately one million hits on Google scholar but after the third results page we
noticed that the publications were not related to the topic, so they were ignored. We
then started following the citations and related papers that the search engine suggested
to gather more relevant results. We also used, “ResearchGate”, “ISI Web of
Knowledge” with no additional relevant hits. After the searching stage, we obtained a
set of 37 publications.

1- http://aa.usno.navy.mil/data/docs/JulianDate.php
4.3 Screening the Papers

Task-3: We had to make a screening to try to filter the papers that were not relevant
to our research. We did this by reading the title, the keywords and then the abstract.
The filtering was mainly done by checking if the abstract referred to the specification
of security requirements and methods or frameworks to support the specification of
security requirements. After this task, we restricted our selection set to 11 publications
to be considered in the next task.

4.4 Analyzing the Full Document

Task-4: We took into consideration a set of 11 publications in our repository. Those

papers were then fully analyzed and visual study of their metadata was created. In the
figure 3, we have a graph that shows the distribution of selected publications per year
of publication. In the table 1, we have a table that shows for each type of publication,
the type of research. The papers were classified into:

• Solution proposal: papers that discuss new or revised techniques.

• Evaluation research: papers that investigate a practice or an implementation in
practice and report the lessons learned.
• Validation research: papers that investigate the properties of a solution proposal
that has not yet been deployed in practice.
• Opinion papers: papers that contain the author’s opinion about a research or
practice subject.
• Tool Proposal: papers that present a tool to be implemented in a specific problem
• Evaluation paper: papers that evaluate a specific tool or solution.

Some papers covered more than one category.

In the figure 4, we have a graph that shows where the publications were published,
showing that the majority of the publication were released in conferences and journals.

9
 Selected publications per year
3

0
1999 2004 2005 2008 2009 2012 2014 2016 2017

Fig. 3 - Selected publications per year (1999-2017)

Selected papers
6

0
Conference Doctoral Thesis Journals

Selected papers

Fig. 4 - Relative share of the various paper types in the selected set (Doctoral
Thesis, Conferences and Journals)
 Table 1 - Type and number of selected publications

Solution Evaluation Tool Solution + Solution +

Proposal validation + validation
tool
Journal 1[11] 1[10] 1[12] 2[13][14] -
Conference 1[15] 2[16][17] 1[3] 1[1]

Doctoral - - - 1[18] -
Thesis
Total 2(18.18%) 1(9.01%) 3(27.27%) 4(36.36%) 1(9.01%)

4.5 Publications Analysis

In this section we go through each of the selected publication that were relevant to
our work and make a summary with the main ideas and proposals of the authors.

Eliciting security requirements with misuse cases [12] Sindre et al. extends the
traditional use case approach to also consider misuse cases, which represent behaviour
not wanted in the system to be developed. Misuse cases are initiated by misusers. A
misuser is an actor that initiates misuse cases, either intentionally or inadvertently. They
have two representations: a graphical diagram and a textual specification. Misuse cases
were initially developed without relying on any kind of knowledge repositories.
However, Sindre et al. defined an approach based on a repository of generic misuse
cases (generic threats and generic security requirements). Sindre et al. represent the
reused knowledge using generic misuse cases. Each misuse case has a name, summary,
preconditions, misuser interactions, systems interactions, and postconditions. Authors
suggest two main reusable artefacts: Generic threats (e.g., spoofing, i.e., a misuser
gaining access to the system by pretending to be a regular user) and generic security
requirements (e.g., access control) described independently of particular application
domains. Authors provide a way to use/reuse this repository through some guidelines.
These guidelines are important for research on misuse cases because they are starting
points for evaluating misuse cases empirically. These guidelines are composed of five
steps: identify critical assets in; define security goals; identify threats; identify and
analyze risks and define security requirements.

Modelling Reusable Security Requirements based on an Ontology Framework

[13] Lasheras et al. framework allow detecting the incompleteness and inconsistency
in requirements to achieve semantic processing in requirements analysis. They defined
some reusable knowledge encapsulated in ontologies. They defined two kinds of
ontologies: a risk analysis ontology and a requirements ontology. The risk analysis
ontology is based on MAGERIT, the information systems risk analysis and

11
management method of the Spanish public administration. This ontology includes five
types of risk elements: Asset, Threat, Safeguard, Valuation dimension, and Valuation
criteria. The concepts, meta-information, and relationships included in this
requirements ontology have been mostly taken from the authors’ experience of
requirements reuse-based method SIREN (Toval, Nicolás, Moros and García, 2002a;
Toval et al, 2002b). The ontology organizes requirements into software requirements
and system requirements. The authors rely on semantic queries on the ontology to verify
the correctness of the requirements.

A catalogue of security requirements patterns for the domain of cloud

computing systems [16] Beckers et al. propose a catalogue of security and privacy
requirement patterns that support software engineers in eliciting security requirements.
A security pattern is a general reusable solution to a commonly occurring problem in
software design. They show how security requirements can be classified according to
cloud security and privacy goals. For that purpose, they use a framework called
ClouDAT, that allow them to elicit security requirements with little effort, as it includes
a structural meta-model of a cloud system and a corresponding context-pattern and
templates. With the security requirements elicited, they propose patterns for the
solutions and also templates for new solutions. This patterns and templates have the
purpose to decrease the risk of underspecifying security requirements for a given cloud
scenario and to align the requirements to the required documentation for an ISO 27001
certification[cite].

Inferring Security Requirements from Natural Language Requirements

Artefacts. [18] Maria et al. proposes a process to support secure software development
by systematically identifying and specifying implied security requirements of a system
using empirically-developed security requirements patterns, it takes as input existing
natural language requirements artefacts and produces a set of candidate security
requirements for the system as output. A security pattern is a general reusable solution
to a commonly occurring problem in software design. This process automatically
identifies security properties implied by sentences in the input and suggest applicable
security requirements patterns for that scenario. The analyst is then able to select and
instantiate appropriate patterns to specify security requirements for the system. To
automatically identify the security properties, they manually defined a labelled corpus
of requirement sentences with security properties implied by those sentences (such as
confidentiality, integrity, availability, accountability, and privacy) using a classification
guide. To support the specification of security requirements based on the implied
security properties, they have empirically developed a set of 35 security requirements
patterns such as “prevent unauthorized access to information”, “detect unauthorized
disclosure of information” and “analyze audit records to detect malicious activity”.

Using Abuse Case Models for Security Requirements Analysis [17] McDermott
et al. [17] propose a specification of interactions between a system and one or more
actors, where the results of these interactions are harmful to the system, one of the
actors, or one of the stakeholders in the system, called “Abuse case”. An abuse case is
described using the same strategy as a use case: use case diagrams and use case text.
Both are represented by the same symbols this allows to create abuse case specifications
in the standard notation such as UML and to use design. Both concepts are
distinguished by keeping them separate and labelling the diagrams. This modelling
technique has a significant benefit since many developers who work on the security
features of software do not understand mathematical security models. Abuse cases are
also more easily understood by other project engineering personnel who are not familiar
with such models.

Specifying Reusable Security Requirements [11] Firesmith, et al. suggests using

textual security requirements templates in order to make security requirements highly
reusable, unlike typical functional requirements that are not. An example of a reusable
parameterized template for specifying an integrity security requirement is followed:
‘‘The [application center/business unit] shall protect the data it transmits from
corruption (e.g., unauthorized addition, modification, deletion, or reply) due to
[unsophisticated/somewhat sophisticated/sophisticated] attack during execution of [a
set of interactions/use cases] as indicated in [specified table].’’
Users of these templates can manually replace the brackets according to their
different applications.
The author provides an asset-centered and reuse-based procedure for requirements
and security teams to analyze security requirements containing 13 steps, starting by
identifying the valuable assets, identifying threats, and estimating vulnerabilities. The
steps end by specifying requirement through the instantiation of templates based on the
parameters from the previous steps.

Security Requirements Engineering: A Framework for Representation and

Analysis [14] Haley et al. presents a framework for security requirements elicitation
and analysis called security requirements engineering framework (SREF). This
framework is based on constructing a context for the system, representing security
requirements as constraints, and developing satisfaction arguments for the security
requirements. The system context is described using a problem-oriented notation, then
is validated against the security requirements through the construction of a satisfaction
argument. The satisfaction argument consists of two parts: a formal argument that the
system can meet its security requirements and a structured informal argument
supporting the assumptions expressed in the formal argument. The construction of the
satisfaction argument may fail, revealing either that the security requirement cannot be
satisfied in the context or that the context does not contain sufficient information to
develop the argument. In this case, designers and architects are asked to provide
additional design information to resolve the problems.

Threat Modelling as a Basis for Security Requirements [1] Myagmar et al.

published a document where they investigate how threat modelling can be used as
foundations for the specification of security requirements. They try to make their work
differ from all other publications by creating a model that is more integrated and with
a more systematic approach toward threat modelling for a complex system. In order to

13
have a good a reliable threat model, it cannot be created by simply brainstorming an
adversary’s possible intentions. This approach is not systematic and is likely to leave
large portions of the attack-space uninvestigated. An attacker only has to find one
security flaw to compromise the whole system. Thus, it is important to be systematic
during the threat modelling process to ensure that as many possible threats and
vulnerabilities are discovered by the developers, not the attackers. The threat model
process proposed by the authors has three high-level steps: characterizing the system,
identifying assets and access points, and identifying threats. In the first step, we must
characterize the system preferably by a Data Flow Diagram (DFD) which dissects the
application into its functional components and indicates the flow of data into and out
of the various parts of system components. Unfortunately, not all systems can be easily
modelled using a DFD. Some systems are so complex that it is impossible to know all
software components that may be present and thus no assumptions can be made about
data flow paths. This is especially true for networked systems such as large-scale
commodity clusters. Networked systems can be viewed via a Network Model, which
allows analysts to examine communication between computers with different roles. In
the second step, we Identify assets and access points by answering the 3 questions:
(i)Who are my potential adversaries?; (ii)What’s their motivation, and what are their
goals?; (iii)How much inside information do they have?
In the last step, we identify the threats, the goal of this step is to identify threats to
the system using the information gathered so far. A threat is the adversary’s goal, or
what an adversary might try to do to a system. After these steps, the security
requirements for the system can be defined.

Deriving Security Requirements from Crosscutting Threat Descriptions [15]

Haley et al. illustrates how representing threats as crosscutting concerns aids in
determining the effect of security requirements on the functional requirements. Assets
are first enumerated, and then threats on these assets are listed. The points where assets
and functional requirements join are examined to expose vulnerabilities to the threats.
Security requirements, represented as constraints, are added to the functional
requirements to reduce the scope of the vulnerabilities. These requirements are used
during the analysis and specification process, thereby incorporating security concerns
into the functional requirements of the system. To describe the threats, they use a
composition of threat description with functional requirements to derive security
requirements. A threat description is a descriptive phrase of the form performing action
X on/to asset Y could cause harm Z. A threat description is represented by a tuple
(threat, asset), where the tuple element ‘threat’ is itself a tuple (action, harm). The first
threat description example is shown in tuple form below: ( ( exposing, loss of revenue,
business plan) )
The action in a threat description is the inversion of some common security goal,
such as confidentiality. The action is not intended to describe an attack, which is an act
(or sequence of acts) of an attacker carried out to exploit a vulnerability and therefore
carry out a threat.
5 Solution Proposal

The stakeholders naturally want to protect their assets from any harm. The difficulty
is to determine, from these security goals, clear security requirements that respond to
the needs of a system. Our project aims to facilitate the security requirements
specification with a formal and rigorous approach. In this section we discuss how
security requirements have traditionally been specified and then we will present our
solution in a way that can improve it.

5.1 Security Requirements Background

Security requirements have traditionally been classified as “non-functional” or
“quality” requirements. Like any other quality requirements, such as usability and
performance, it tend to be measured, instead of just check if the system has that specific
quality [14]. But security requirements add additional challenges on top of the ones that
exist for traditional quality requirements.
When security requirements are being elicited people tend to express security
requirements in terms of “bad things” to be prevented such as misuse cases. This proves
very challenging as it entails proving a negative, i.e. that there is no situation that
violates this statement. For security requirements we must guarantee that they are
satisfied without a doubt, we cannot say that a system is probably secure, or we are
taking a risk of suffering an attack because of unknown vulnerabilities.
The amount of resource that the stakeholders might be willing to allocate to that
specific requirement depends on the value of the asset, the likelihood of the attack and
the impact on the system in case of the attack.
Another aspect to consider is the context since a system context can profoundly
change the security requirements. A system is not isolated and it operates in an
environment that dictates which requirements the system shall have. As an example, in
a text editor software [14], if the software has a confidentiality requirement, it shall
have an authentication and encryption mechanism. But we should also consider that if
this text editor shall have a feature that reads the information aloud, that might break
that same confidentiality requirement, since if its user works in an office with multiple
people, then every time this reading aloud feature is used, other people in the room will
listen to the sensitive information. As a second example, in normal situations we would
not think that the air could be part of a problem, but thinking of a data center, an attacker
could increase the air temperature to a point of equipment failure, which could lead to
denial of service. Going back to the text editor example, that same air doesn't need to
be taken into account. With that in mind, we have to decide which parts of that
environment we will include in our analysis. The analyst must choose a subset of
domains (real-world elements) that she/he considers relevant. By so, the analyst defines
the system context.
When considering security, one factor influencing an analyst’s choice about whether
or not a domain is relevant, is the system set of trust assumptions. Trust assumptions
are explicit or implicit choices to trust a domain to behave as expected and can have a
significant impact on the security of a system. We can have unlimited trust, like when
we have two processes in the same organization or trust in a limited way like when we

15
have an “OpenId-Provider” that can be accessed by users with a valid email address
and that authenticates users based on a user-definable password, this kind of trust is
quite low.
In our work, we consider as a starting point, the framework proposed by Haley et al.
[14], that facilitates the production of security requirements, as it will help to
understand the place of security requirements within the development of a software
application, along with the relationships between the security requirements and other
artefacts produced during the software development.
According to this framework, there are 4 general stages in which the authors produce
an artefact in relation to the previous. They start with a functional requirement and
finish with a satisfied security requirement. We want to follow this kind of methodology
in a way that we specify a threat and reach a valid security requirement.

Fig. 5 – Haley et .al framework [14]

5.2 Language – RSLingo4Cybersecurity

RSLingo4Cybersecurity will extent the original RSL language with concerns of

cybersecurity. In the next sub-sections, we discuss the new concepts and the
modifications of already existing ones to fit the needs of current security concerns.

5.2.1 Threat Specification

As security requirements protected assets from harm, so we must first specify the
threats to those assets. In our threat specification, we must start by defining a unique
identifier(Id) and a name. When identifying a threat, it is helpful to think of various
attacks in terms of some general classes, so we may classify each threat into one of
these six types [1]:

• Spoofing: Using someone else’s credentials to gain access to otherwise inaccessible

assets.
• Tampering: Changing data to mount an attack.
• Repudiation: Occurs when a user denies performing an action, but the target of the
action has no way to prove otherwise.
• Information disclosure: The disclosure of information to a user who does not have
permission to see it.
• Denial of service: Reducing the ability of valid users to access resources.
• Elevation of privilege: Occurs when an unprivileged user gains privileged status.

A threat can also be composed by other threats, so we shall allow a “partOf” relation,
as well as a “isA” relation, in the case a threat is derived from another more general or
abstract threat.

We specify the asset correspondent to the current threat. And for a threat to exist, a
vulnerability must exist, so we also specify it.

The previous attributes were about the description of the thread, now we must
specify how much risk this threat holds to the asset in cause. We calculate the risk of
the threat in several categories as suggested by Myagmar et al. [1] where we rank them
in a 0 to 10 scale, where 0 is no risk and 10 is maximum risk, and the categories are the
following:

• Number of affected users: The number of users that would be affected by the
attack.
• Damage potential: The damage that would result from the attack.
• Level of skills needed: The level of skill needed by the attacker to make the attack
happened.
• Cost of attack: The cost for the attacker to make the attack possible
• Reproducibility: How easy it is to make the attack happen again
• Discoverability: How easy it is to discover that our system is vulnerable to that
attack
• Total Risk: After all the other parameters are filled, this parameter would auto-
complete with an average of the other parameters, indicating how serious is the
threat.
With the risk of each threat calculated, we can more easily choose how will the
system manage the risk. When we are specifying a security of a system, normally we
want to have no risk on our system, but is often impossible to mitigate every threat, and
even if this could be done, it would almost certainly take place at the cost of decreased
usability. This happens because security limits the options that a system can have, a
good example would be of password requirements: a simple password of four numbers,
is easy to input and to remember but would offer low security since a computer using a
brute-force approach(test all combinations possible) it would take two hundred
nanoseconds to match the password, while a password with one symbol, one number,
twelve letters with one in caps lock, would take two hundred and four million years,
but at the cost of low usability since you are restricting the options of the user.

17
 Securing systems is about trade-offs, when we implement a security mechanism we
have to spend time and money and it does not make sense to have a million euro vault
to protect a 5 euro bill, but it would make sense to protect a ton of gold bars. Finding
an ideal balance is often quite a challenge since security measures should be employed
only up to the point where the cost to implement them does not exceed the expected
risk. Risk management addresses this issue and for that we consider four treatment
strategies to address a risk [1]:

• Accept the risk: The risk is so low and so costly to mitigate that it is worth
accepting.
• Transfer the risk: Transfer the risk to some other entity via insurance, contracts etc.
• Remove the risk: Remove the system component or feature associated with the risk
if the feature is not worth the risk.
• Mitigate the risk: Reduce the risk with countermeasures, such as a long password,
an encrypted communication etc.

The last two attributes for the threat specification are the risk treatment, where we
briefly specify what will be the solution for the threat, and the description of that same
threat. The purpose of this description is to provide a brief clarification of the threat.

5.2.2 Misuse Cases

Use cases have become increasingly common during requirements engineering but they
offer limited support for eliciting security threats and requirements. Having that in
consideration, we will be using a complementary alternative called Misuse Cases. A
misuse case is a sequence of actions, including variants, that a system or other entity
can perform, interacting with misusers of the entity and causing harm to some
stakeholder if the sequence is allowed to complete [12].
A misuse case will be represented the same way that use cases are already
represented in RSLingo: Id, Name, Type, DataEntity View, Actors, Actions,
Conditions, Includes, Extends, Extension Points, Description and Priority.
We will distinguish them by the label (Use case/Misuse case) and by the relationship
that they will have among them and other entities. A misuse case will threaten other
entities and will be mitigated by them.

5.2.3 Security Requirements Specification

Since we already have defined threats to the system, we can now more easily specify
security requirements that will mitigate those threats. A security requirement will have,
like any other entity, a unique identifier(id) and a name. Each security requirement will
have a type [11] :
• Authentication: is the degree to which the system verifies the identities of its
externals before interacting with them.
• Authorization: is the degree to which access and usage privileges of authenticated
externals are properly granted and enforced.
• Identification: is the degree to which the system identifies (i.e., recognizes) its
externals before interacting with them.
• Attack/Harm Detection: is the degree to which attempted or successful attacks (or
their resulting harm) are detected, recorded, and notified.
• Nonrepudiation : is the degree to which a party to an interaction (e.g., message,
transaction, transmission of data) is prevented from successfully repudiating (i.e.,
denying) any aspect of the interaction.
• Confidentiality: is the degree to which sensitive information is not disclosed to
unauthorized parties (e.g., individuals, programs, processes, devices, or other
systems).
• Physical Protection: is the degree to which the system protects itself and its
components from physical attack.
• Recovery: is the degree to which a system can recover from an attack.
• Anonymity: is the degree to which the identity of users is prevented from
unauthorized storage or disclosure.
• Integrity: is the degree to which components are protected from intentional and
unauthorized corruption.
• Auditing: is the degree to which security personnel are enabled to audit the status
and use of security mechanisms by analysing security-related events.
• Anonymity: is the degree to which the identity of users is prevented from
unauthorized storage or disclosure.

Security requirements will also have a “PartOf” parameter where is specifies another
security requirement, from where it is decomposed from. They will have a description
to clarify the requirement and finally will have a priority field where it describes it’s
importance (Must, Should, Could and Won’t).

5.2.4 Security Relations

Adapting from RSLingo, we will have relations between the security entities, for
example, threats with security requirements, use cases with misuse cases, misuse cases
with security requirements. These security relations will be specified like normal
relations with some addition relationships. There will be an id and name for the source
and the target entity, a “DependsOn Type” and a description. On the “DependsOn
Type” we will have the following options: Requires; Supports; Obstructs; Conflicts;
Identical; Relates; Threaten; Mitigates; Other

19
 Fig. 6 - RSLingo4Cybersecurity entities and relations

5.3 Library

The library of RSLingo4Cybersecurty will be an instantiation of security

requirements specifications on a real case scenario. Since security requirements are
highly reusable, we can have catalogued solutions to problems that occur frequently.
One approach that we shall adopt is the use of security patterns. A security pattern is a
well-understood solution to a recurring information security problem[19] that includes
a catalogue of security requirements. There are many repositories of security patterns,
but our main reference will be the Common Criteria for Information Technology
Security Evaluation 1(Common Criteria or CC). The Common Criteria is
an international standard for computer security certification which provides assurance
that the process of specification, implementation and evaluation of a computer security
product has been conducted in a rigorous, standard and repeatable manner at a level
that is commensurate with the target environment for use. Using the standards of CC in
our work, we insure that the security patterns used are vastly tested, secure and reliable.

1- https://www.commoncriteriaportal.org/
2- http://re2017.org/pages/submission/data_papers/
6 Evaluation

In order to properly evaluate the proposed solution, two evaluation dimensions must
be considered. Regarding the correctness and consistency of RSLingo4Cybersecurity
language extension, this process will consist in validating the specification of the
security requirements. This will be done using RSLingo-Studio automatic verification
which will ensure that the language extension will be well defined and in accordance
with the original RSL language.
For the evaluation of the library we will use a dataset from a conference2, to have a
complex case in which to test the solution ourselves. Then we will make tests with pilot
users, on a real case scenario, which will make use of the RSLingo-Studio with a more
focused approach on the new security library. The immediate feedback that these tests
will give are of the uttermost importance since we can perceive if the library is easy to
learn, easy to use and useful.
After these tests, the users will have to fill a questionnaire to give their evaluation,
that will include their suggestions, problem reports and general opinions.

7 Conclusion

Cybersecurity is an on growing concern that must be approached since the very

beginning of the design of a system. Through the revision of the related work on using
the “Systematic Literature Review” methodology in RE and Cybersecurity, we
identified a set of problems regarding the rigorous security requirements specification
such as, late in the project security specification, the lack of formal and rigorous
security requirements specification. We propose a solution to these problems with an
extension to RSLingo, RSLingo4CyberSecurity, that will add security concerns to the
requirements specification. In this report part of the solution is already proposed and in
the future we intend to improve that solution, implement it in RSLingo-Studio and
validate it.

21
References

[1] S. Myagmar, A. J. Lee, and W. Yurcik, “Threat Modeling as a Basis for

Security Requirements,” Symp. Requir. Eng. Inf. Secur, 2005.
[2] De Almeida Ferreira and A. R. Da Silva, “RSLingo: An information extraction
approach toward formal requirements specifications” 2012 2nd IEEE Int.
Work. Model. Requir. Eng. MoDRE 2012 - Proc. 2012.
[3] A. Rodrigues, I. S. Técnico, and U. De Lisboa, “Linguistic Patterns and
Linguistic Styles for Requirements Specification ( I ): An Application Case
with the Rigorous RSL / Business-Level Language”, 2017.
[4] A. Rodrigues, D. A. Silva, I. S. Técnico, and U. De Lisboa, “A Pattern
Language For Use Cases Specification” , 2015.
[5] B. Kitchenham and S. Charters, “Guidelines for performing Systematic
Literature reviews in Software Engineering Version 2.3,” Engineering, vol. 45,
2007.
[6] De Almeida Ferreira and A. R. Da Silva, “RSL-PL: A linguistic pattern
language for documenting software requirements,” 2013 3rd Int. Work. Requir.
Patterns, RePa 2013 - Proc., 2013.
[7] De Almeida Ferreira and A. R. Da Silva, “RSL-IL: An interlingua for formally
documenting requirements,” 2013 3rd Int. Work. Model. Requir. Eng. MoDRE
2013 - Proc., 2013.
[8] A. R. Da Silva, J. Saraiva, R. Silva, and C. Martins, “XIS - UML profile for
eXtreme modeling interactive systems,” Proc. - Fourth Int. Work. Model.
Methodol. Pervasive Embed. Software, MOMPES 2007, 2007.
[9] A. Rodrigues and D. Silva, “SilabMDD - A Use Case Model Driven Approach
SilabMDD - A Use Case Model Driven Approach,” , 2015.
[10] A. Souag, R. Mazo, C. Salinesi, and I. Comyn-Wattiau, “Reusable knowledge
in security requirements engineering: a systematic mapping study,” Requir.
Eng., vol. 21,2016.
[11] D. Firesmith, “Specifying reusable security requirements,” J. Object Technol.,
vol. 3, 2004.
[12] G. Sindre and A. L. Opdahl, “Eliciting security requirements with misuse
cases,” Requir. Eng., vol. 10, 2005.
[13] J. Lasheras, R. Valencia-Garcia, J. T. Fernandez-Breis, and A. Toval,
“Modelling reusable security requirements based on an ontology framework,”
J. Res. Pract. Inf. Technol., vol. 41, 2009.
[14] C. B. Haley, R. Laney, J. D. Moffett, and B. Nuseibeh, “Security requirements
engineering: A framework for representation and analysis,” IEEE Trans. Softw.
Eng., vol. 34, 2008.
[15] C. B. Haley, R. C. Laney, and B. Nuseibeh, “Deriving security requirements
from crosscutting threat descriptions,” Proc. 3rd Int. Conf. Asp. Softw. Dev. -
AOSD ’04, 2004.
[16] K. Beckers, I. Côté, and L. Goeke, “A catalog of security requirements patterns
for the domain of cloud computing systems,” Proc. 29th Annu. ACM Symp.
Appl. Comput. - SAC ’14, 2014.
[17] J. McDermott and C. Fox, “Using abuse case models for security requirements
analysis,” Proc. 15th Annu. Comput. Secur. Appl. Conf.,1999.
[18] M. Riaz, “Inferring Security Requirements from Natural Language
Requirements Artifacts,” 2016.
[19] D. M. Kienzle, M. C. Elder, D. Tyree, and J. Edwards-Hewitt, “Security
patterns repository version 1.0,” DARPA, Washingt. DC, 2002.

Appendix A: Dissertation Work Scheduling

Ref. Title Authors Year of Venue

publication
[17] Using abuse case models for McDermott 1999 ACSAC'1999
security requirements analysis et al. (Conference)
[11] Specifying reusable security Firesmith, 2004 Object Technology
requirements (Journal)
[15] Deriving security requirements Haley et al. 2004 AOSD 2004
from crosscutting threat (Conference)
descriptions
[12] Eliciting security requirements Sindre et al. 2005 Requirements
with misuse cases Engineering (Journal)
[1] Threat Modeling as a Basis for Myagmar et 2005 SREIS (Conference)
Security Requirements al.
[14] Security requirements engineering: Haley et al. 2008 IEEE Transactions on
A framework for representation Software Engineering
and analysis (Journal)
[13] Modelling reusable security Lasheras et 2009 Research and Practice
requirements based on an ontology al. in Information
framework Technology (Journal)

[16] A catalog of security requirements Beckers et 2014 SAC 2014

patterns for the domain of cloud al. (Conference)
computing systems
[18] Inferring Security Requirements Riaz 2016 Doctoral thesis
from Natural Language
Requirements Artifacts
[10] Reusable knowledge in security Souag et al. 2016 Requirements
requirements engineering: a Engineering (Journal)
systematic mapping study
[3] Linguistic Patterns and Linguistic Rodrigues et 2017 EuroPLOP’2017
Styles for Requirements al. (Conference)
Specification (I): An Application
Case with the Rigorous RSL /
Business-Level Language

23
 Appendix B: Dissertation Work Scheduling

Month Work
September Background investigation of the RSLingo Approach and the RSL
Language.
October Experimentation of the RSL Language and its used technologies
(Xtext, RSLingo-Studio Tool).
November Background investigation of the Security Requirements
Specification.
December Experimentation and creation of prototypes with RSL Language
with security libraries. Thesis project report writing.
January Finish the thesis project report and presentation.
February Extend RSL Language with security requirements
March Extend RSLingo-Studio Tool with security requirements
April Solution evaluation with test case
May Solution evaluation with real case and pilot users
June Review feedback from users and eventual improvements
July Starting of thesis writing
August Complete the thesis writing
September Complete the thesis writing