Joona Lepola

APPLICABILITY OF IEC 62443-4-1

BASED SECURE DEVELOPMENT
LIFECYCLE (SDL) TO CLOUD
APPLICATIONS

Master’s thesis
Faculty of Information Technology and Communication Sciences
Marko Helenius
Ari Vakkuri
November 2021
 i

ABSTRACT
Joona Lepola: Applicability of secure development lifecycle (SDL) based on IEC 62443-4-1 to
cloud applications
Tampere University
Master's Programme in Information Technology
Master’s Thesis
November 2021

Secure Development Lifecycle (SDL) is a great way to increase the security of product during
its lifetime. This work researches how well the industrial automation SDL, defined by IEC 62443-
4-1, fits for applications developed for cloud environment. IEC 62443-4-1 based SDL is widely
used in industrial companies and the use of it could be spread to the cloud development, after
which companies could use the existing tools and policies. This would make transition to cloud-
based development a bit easier.
The work is divided into four parts. The literature review chapter presents previous similar
studies on the compatibility of IEC 62443-4-1 and the cloud environment, studies on the
compatibility of IEC 62443-4-1 and agile methodologies, as well as mapping work related to the
security of a secure cloud application. It was found in the work that there are no previous studies
between IEC 62443-4-1 and the cloud environment, since most only mention one of them, whilst
the focus of the work itself is only on another topic. One study about agility was found and used
for this work. The literature review also found one good work related to a safe cloud environment
that will be used as references in later chapters. The suitability is then mapped using an example
project. The example project is an application running in a cloud environment to which IEC 62443-
4-1 based SDL is applied. The work firstly presents the project in detail and compares it against
the Cloud Security Alliance Security Guidance v4.0 book and previous studies on the cloud
security. The security features and deficiencies found will be utilized in later stages. After the
presentation of the project, all the processes required by the IEC 62443-4-1 SDL are reviewed
one by one and justified how they apply to the example project. Finally, the work analyses how
well the existing processes of SDL adapt to the project and how well the security features and
deficiencies found, have been considered in SDL, and suggests possible additional processes.
When SDL processes are adapted to the example project, it is noticed that most of them are
suitable directly to the project and total of four processes are left unselected. The analysis phase
shows that the non-selected processes are suitable for the cloud environment and were not
selected for the project because it lacked certain features required by these processes. Thus, the
analysis shows that all the processes are suitable for the cloud environment, but the work still
highlights 21 processes where it is good to keep certain things in mind when applying them to the
cloud environment. For example, agile development methods are often involved in cloud
development, which requires a different approach to a few processes. The second is the defining
the user, which is not necessarily easy in every case.
Research shows that IEC 62443-4-1 is also suitable for use in cloud environments if a few
things are remembered when it is implemented.

Keywords: IEC 62443-4-1, SDL, Secure Development Lifecycle, Cloud, Cloud development,
Cloud Environment

The originality of this thesis has been checked using the Turnitin OriginalityCheck service.
 ii

TIIVISTELMÄ
Joona Lepola: IEC 62443-4-1:een pohjautuvan turvallisen kehityksen elinkaaren soveltuvuus
pilvisovelluksille
Tampereen yliopisto
Tietotekniikan tutkinto-ohjelma
Diplomityö
Marraskuu 2021

Turvallisen kehityksen elinkaari (engl. Secure Development Lifecycle, SDL) on erittäin hyvä
keino parantaa kehitetyn tuotteen turvallisuutta sen koko elinkaaren ajan. Tässä työssä tutkitaan,
kuinka hyvin teolliselle automaatiolle kehitetty IEC 62443-4-1 -standardin määrittelemä SDL
soveltuu pilviympäristöön kehitetyille sovelluksille. IEC 62443-4-1 -pohjainen SDL on laajasti
käytössä teollisuuspuolen yrityksissä ja sen käyttöä voitaisiin mahdollisesti myös laajentaa
pilvikehitykseen, jolloin yritykset voivat hyödyntää jo olemassa olevia työkaluja ja toimintatapoja.
Tällöin yritysten siirtyminen pilvipohjaisten sovellusten kehittämiseen voisi olla hieman
helpompaa.
Työ jakautuu neljään osaan. Kirjallisuustutkimusosa esittelee aiempia vastaavia tutkimuksia
IEC 62443-4-1 -standardin ja pilvikehityksen yhteensopivuudesta, ketterän kehityksen
menetelmien ja IEC 62443-4-1 -standardin yhteensopivuutta käsitteleviä töitä, sekä kartoittaa
turvalliseen pilvisovellukseen liittyviä töitä. Työssä havaittiin, että aiempia IEC 62443-4-1 ja
pilvikehityksen välisiä tutkimuksia ei ole lainkaan, vaan useimmissa vain mainitaan jompikumpi,
koska itse tutkimuksen pääpaino on vain toisessa aiheessa. Tutkielmassa löydettiin yksi
ketterään kehitykseen ja IEC 62443-4-1 -standardiin liittyvä työ, jota käytetään lähteenä tässä
työssä. Kirjallisuustutkimuksessa löydettiin yksi turvalliseen pilviympäristöön liittyvä työ, jota
käytetään viitteenä myöhemmissä osissa. Tämän jälkeen soveltuvuutta lähdetään kartoittamaan
esimerkkiprojektin avulla. Esimerkkiprojektina on pilviympäristössä toimiva sovellus, johon
sovelletaan IEC 62443-4-1 mukainen SDL. Työssä esitellään ensiksi projekti ja vertaillaan sitä
Cloud Security Alliancen Security Guidance v4.0 -kirjaa ja aiempia pilviympäristön turvallisuutta
käsitteleviä tutkimuksia vasten. Löydettyjä turvallisuusominaisuuksia ja puutteita käytetään
hyödyksi myöhemmissä vaiheissa. Projektin esittelyn jälkeen työssä käydään läpi yksitellen kaikki
IEC 62443-4-1 SDL:n vaatimat prosessit ja perustelen miten ne soveltuvat esimerkkiprojektiin.
Lopuksi työssä analysoidaan miten hyvin SDL:n olemassa olevat prosessit sopeutuvat projektille
ja miten hyvin löydetyt tietoturvaominaisuudet ja puutteet on huomioitu SDL:ssä ja ehdotetaan
mahdollisia ylimääräisiä prosesseja.
Kun SDL prosesseja sovitetaan esimerkkiprojektiin, huomataan että niistä suurin osa käy
projektiin ja valitsematta jää yhteensä neljä prosessia. Analyysivaiheessa käy ilmi, että vaikka
osa prosesseista ei sopinut esimerkkiprojektiin, ne kaikki ovat silti sopivia pilvikehitykseen. Tämä
johtui siitä, että esimerkkiprojektissa ei ollut tarvetta näille prosesseille. Työssä nostetaan esille
21 prosessia, joita sovellettaessa on pidettävä tiettyjä asioita mielessä, jotta ne soveltuisivat hyvin
pilvikehitykseen. Esimerkiksi ketterien kehitysmetodien mukana tuleva nopeatempoinen
ohjelmistojen julkaisu asettaa muutamille prosesseille erityisvaatimuksia. Mikäli jokaisen julkaisun
yhteydessä tehtäisiin kaikki SDL:n vaatimat prosessit, ohjelmistokehityksen ketteryys voisi kärsiä
huomattavasti. Toinen on käyttäjän määrittäminen, joka ei välttämättä ole kovin helppoa jokaisen
prosessin yhteydessä.
Tutkimus osoittaa, että IEC 62443-4-1 soveltuu myös pilvikehityksessä käytettäväksi, kunhan
sitä sovellettaessa muistetaan edellä mainitut asiat.

Avainsanat: IEC 62443-4-1, Turvallisen kehityksen elinkaari, pilvi, pilvikehitys, pilviympäristö

Tämän julkaisun alkuperäisyys on tarkastettu Turnitin OriginalityCheck –ohjelmalla.

 iii

PREFACE
This master’s thesis has been done while I was working in Insta Digital Oy and the thesis
was done for a customer company. I would like to thank all the companies and personnel
involved in this thesis, since they all have been proved to be a great help for me to be
able to finish this. I would like to especially thank Henry Haverinen for proving me
invaluable security and secure development lifecycle information, Ari Vakkuri for helping
me to understand the architectures related to this project and guiding me through this
thesis, and finally my family for supporting me to follow my dreams.

Tampere, 11 November 2021

Joona Lepola
 iv

CONTENTS
1. INTRODUCTION .................................................................................................. 1
1.1 Problem layout ..................................................................................... 1
1.2 Delimitations ........................................................................................ 1
1.3 Research Method................................................................................. 2
1.4 Structure of the Diploma Thesis ........................................................... 2
2. LITERATURE RESEARCH ................................................................................... 3
2.1 Literature Research Method ................................................................. 3
2.2 Scientific Documents Related to IEC 62443-4-1 and Cloud.................. 3
2.3 Scientific Documents Related to IEC 62443-4-1 and Agile ................... 6
2.4 Scientific Documents Related to Security and Cloud Infrastructure .... 10
2.5 Literature Research Results ............................................................... 11
3. USED RESOURCES .......................................................................................... 12
3.1 IEC 62443-4-1.................................................................................... 12
3.1.1 General Principles....................................................................... 12
3.1.2 Maturity Model ............................................................................ 12
3.1.3 Security Levels ........................................................................... 13
3.1.4 About Practices and Security Processes..................................... 13
3.2 Cloud Security Alliance (CSA) ............................................................ 16
3.2.1 Security Guidance V4.0 .............................................................. 16
3.3 Center for Internet Security (CIS) ....................................................... 17
3.4 AWS Security Hub ............................................................................. 17
3.5 The Open Web Application Security Project® (OWASP) .................... 19
3.6 National Institute of Standards and Technology (NIST) ...................... 20
4. APPLICATION OF SDL TO CLOUD APPLIATION PROJECT ............................ 21
4.1 Project Introduction ............................................................................ 21
4.1.1 What is Cloud Computing ........................................................... 21
4.1.2 Management Plane ..................................................................... 22
4.1.3 Cloud Infrastructure .................................................................... 24
4.1.4 Identity, Entitlement, and Access Management ........................... 35
4.1.5 Data Security and Encryption ...................................................... 37
4.1.6 Application Security .................................................................... 41
4.2 Selecting SDL Processes to the Project ............................................. 45
4.2.1 Practice 1 – Security management ............................................. 45
4.2.2 Practice 2 – Specification of Security Requirements ................... 48
4.2.3 Practice 3 – Security by Design .................................................. 49
4.2.4 Practice 4 – Secure Implementation ........................................... 51
4.2.5 Practice 5 – Security Verification and Validation Testing ............. 51
4.2.6 Practice 6 – Management of Security-related Issues .................. 52
4.2.7 Practice 7 – Security Update Management ................................. 54
4.2.8 Practice 8 – Security Guidelines ................................................. 55
4.3 Summary of Selections ...................................................................... 57
 v

5. ANALYSIS OF IEC 62443-4-1 SUITABILITY FOR CLOUD SOFTWARE

DEVELOPMENT......................................................................................................... 58
5.1 How IEC 62443-4-1 Practises and Processes Fit to the Cloud Computing
58
5.1.1 Practice 1 – Security Management ............................................. 58
5.1.2 Practice 2 – Specification of Security Requirements ................... 59
5.1.3 Practice 3 – Security by Design .................................................. 59
5.1.4 Practice 4 – Secure Implementation ........................................... 60
5.1.5 Practice 5 – Security Verification and Validation Testing ............. 60
5.1.6 Practice 6 – Management of Security-related Issues .................. 60
5.1.7 Practice 7 – Security Update Management ................................. 60
5.1.8 Practice 8 – Security Guidelines ................................................. 61
5.2 Fitting Project’s Security Findings to the SDL Processes ................... 61
5.2.1 Management Plane ..................................................................... 61
5.2.2 Cloud Infrastructure .................................................................... 62
5.2.3 Identity, entitlement, and access management ........................... 64
5.2.4 Data Security and Encryption ...................................................... 64
5.2.5 Application security ..................................................................... 66
5.3 Compatible IEC 62443-4-1 Processes with Cloud Computing ............ 67
6. CONCLUSIONS.................................................................................................. 68
7. REFERENCES ................................................................................................... 70
 vi

LIST OF FIGURES

Figure 1 Cloud infrastructure ...................................................................................... 26

 vii

LIST OF TABLES
Table 1 Service types available in the cloud ............................................................... 24
Table 2 Cloud infrastructure stages ............................................................................ 25
Table 3 CloudFront routing table................................................................................. 27
Table 4 Project deployment stages in Jenkins ............................................................ 42
Table 5 Selected IEC 62443-4-1 processes for the example project ........................... 57
Table 6 How does the IEC 62443-4-1 cover the infrastructure security findings .......... 63
Table 7 How does the IEC 62443-4-1 cover the data security findings ....................... 65
Table 8 How does the IEC 62443-4-1 cover the application security findings ............. 66
Table 9 Compatible IEC 62443-4-1 Processes with Cloud Computing ........................ 67
 viii

LIST OF SYMBOLS AND ABBREVIATIONS

Entities
AWS Amazon Web Services
BOS Back Office System
CIS Center for Internet Security
CSA Cloud Security Alliance
EU European Union
IEC International Electrotechnical Commission
ISO International Organization for Standardization
NIST National Institute of Standards and Technology
NIST National Institute of Standards and Technology
OWASP Open Web Application Security Project
OWASP Open Web Application Security Project
PO Product Owner
TUNI Tampere University
U. S United States

Secure Development Lifecycle

4-1 IEC 62443-4-1
CLASP Comprehensive, Lightweight Application Security Process
DM Management of Security-related Issues
OWASP SAMM Open Web Application Security Project Software Assurance
Maturity Model
PCI DSS Payment Card Industry Data Security Standard
S²C-SAFe Security Standard Compliant Scaled Agile Framework
SD Security by Design
SDL Secure Development Cycle
SDP Secure Design Principles
SG Security Guidelines
SI Secure Implementation
SL-A Security Level Achieved
SL-C Security Level Capability
SL-T Security Level Target
SM Security Management
SR Security Requirements
SUM Security Update Management
SVV Security Verification and Validation Testing

Cloud
ACL Access Control List
Azure AD Azure Active Directory
CMK Customer Managed Keys
DB Database
dev Development
EC2 Elastic Computing 2
IaaS Infrastructure as a Service
IaC Infrastructure as Code
IAM Identity and Access Management
KMS Key Management Service
MFA Multi-Factor Authentication
PaaS Platform as a Service
prod Production
 ix

RDS Relational Database Service

SaaS Software as a Service
SAML Security Assertion Markup Language
SSO Single Sign On
testdepl Test Deployment
WAF Web Application Firewall
VPC Virtual Private Cloud
VPN Virtual Private Network

Software
API Application Programming Interface
BOM Bill Of Materials
CD Continuous Delivery
CI Continuous Integration
CLI Command Line Interface
DevOps Development and IT Operations
HTTP Hypertext Transfer Protocol
HTTPS Hypertext Transfer Protocol Secure
IIoT Industrial Internet of Things
IoT Internet of Things
IP Internet Protocol
IPv4 Internet Protocol version 4
IT Information Technology
NPM Node Package Manager
REST Representational State Transfer
SAFe Scaled Agile Framework
SDK Software Development Kit
SQL Structured Query Language
SSH Secure Shell
SSL Secure Sockets Layer
URL Uniform Resource Locator

Other
COTS Commercial Off-The-Shelf
EAL Evaluation Assurance Level
ICS Industrial Control Systems
IMDSv2 Instance Metadata Service Version 2

.
 1

1. INTRODUCTION

Industrial automation systems are often designed to be in use for a long time, meaning
that they can be in use for tens of years before they are replaced with newer
ones/updated. Some industrial automation systems are connected to the Internet and
can be updated remotely, yet many systems stay offline and are updated irregularly or,
in some cases, never. This increases the need of proper security features for those
systems. Secure Development Lifecycle (SDL) is a one way to increase the security of
the industrial automation product and the suitability of the IEC 62443-4-1 based SDL for
a cloud development is analysed in this thesis.

1.1 Problem layout

The research question is “How well does the Secure Development Lifecycle process
based on IEC 62443-4-1 fit as a cloud application development method and how it should
be developed from the perspective of cloud applications”. There are multiple existing
SDL frameworks i.e., IEC 62443-4-1, Microsoft SDL, ISO 27034, OWASP SAMM, PCI
DSS, and possibly more. IEC 62443-4-1 is an SDL that addresses industrial automation
and control system security. This SDL is mainly used SDL framework in Insta Digital Oy
because some of their customers happen to operate in the field of the industrial
automation. Now that cloud computing is more popular than ever, we are eager to see
how well the IEC 62443-4-1 fits for cloud development and if it does not, how we need
to change it. If this SDL does fit well for cloud development, the existing IEC 62443-4-1
based tools could be used for upcoming cloud projects.

1.2 Delimitations

IEC 62443 standard family contains multiple standards, 13 to be exact, and covering
even two of those is a big task. Therefore, this thesis will only cover the standard IEC
62443-4-1, and everything related to the other standards, within the same family, will be
left outside of the scope. Another big entity is cloud security. It will be covered only with
the scope that fits the example project that is presented within this thesis.
 2

1.3 Research Method

The SDL process is first applied cloud development project and the functionality of the
SDL process in this project is observed. In addition, the cloud side security
recommendations are mapped from various sources. The sources are previous research
related to this subject, Cloud Security Alliance (CSA), The Open Web Application
Security Project ® (OWASP), Amazon Web Services (AWS) Security Hub. Then the
applicability of existing SDL practices and processes to cloud environment is analyzed
and new processes are created if there are some missing from cloud security
perspective.

1.4 Structure of the Diploma Thesis

Chapter 2 goes through previous research related to this subject. Chapter 3 is a definition
of most common resources used to do this work. In chapter 4 the project will be
presented in detail, the current security status of the project will be covered, and an
attempt to apply SDL processes to the existing project. Chapter 5 will cover the analytical
part of the work, wherein the processes will be analysed for suitability for cloud
computing. New processes will be presented, if necessary, based on security findings
on chapter 4.
 3

2. LITERATURE RESEARCH

This thesis was made by applying IEC 62443 based SDL to the existing cloud project.
Literature research was used to map existing scientific documents, that deals with the
same subject as this thesis. Also, literature research is used to map the works that can
be used as a reference for this work.

2.1 Literature Research Method

The main search engine used for literature research was Andor that is managed by
Tampere University’s (TUNI) library. At the time of writing TUNI’s Andor searches from
420 different.

The method for searching information was pearl growing [1, p. 571], in which the search
is started with limited knowledge. The search and search terms are updated with the help
of the search results. This means that the references and citations used by search results
can be used to find new resources and search terms, hence the term pearl growing.
Andor searches gives a lot of documents that are not peer reviewed and those
documents are avoided with this literature research.

2.2 Scientific Documents Related to IEC 62443-4-1 and Cloud

The search was started with simple keywords, “IEC 62443 AND (cloud OR pilv*)” and it
gave only around 38 results that were peer reviewed. After a while it was clear that many
of these documents do not contain anything about IEC 62443-4-1, which is the basis of
this thesis. Many of these documents used other IEC 62443 standard family standards
as a source. Next the search term was updated to form of “IEC 62443-4-1 AND (cloud
OR pilv*)” that consists the standard name (also tried without IEC part, but it gave the
same results) and the environmental name, cloud in Finnish and English. This gave only
4 results, so the search term was updated once again to consist words that can be used
instead of cloud, like Amazon Web Services (AWS), Azure, Google. The final search
term used was “IEC 62443-4-1 AND (cloud OR pilv* OR aws OR azure OR google OR
amazon OR web service)” and it produced 7 results. It turned out that there is not that
much scientific material available for this thesis. The results and their applicability to this
thesis, which Andor gave, will be discussed next.
 4

Using Process Models to Understand Security Standards

This article mentions that some standards can be a bit hard to read text and this work
tries to address that issue with a proposed tool-supported approach. Even though it is
good to verify security related questions from security specialist, it can be problematic
and slow with today’s need of increasing velocity in continuous software engineering.
This work “propose a tool-supported approach to make security standards more precise
and easier to understand for both non-security as well as security experts by applying
process models.” There is also a case study that has been done with 16 industry
practitioners that demonstrates how this approach improves communication between
development and security compliance practitioners. [2]

This work presents a way for regular developers to implement IEC 62443-4-1 processes
and practices easier with agile methodologies, without the constant need of security
expert’s support. Even though this is great information related to the IEC 62443-4-1 this
does not give any intel related to the research question at hand, which asks how well
these processes and practices fits cloud environment.

Security Issues and Software Updates Management in the Industrial Internet of

Things (lIoT) Era

This article gives guidelines for how to implement IEC 62443 industrial security standard
concerning the security maintenance of IIoT systems and component. The lifetime of IIoT
device might be even decades and during that time it is necessary to update the device
to keep it secure. [3]

Subject of this article does not match the research question well enough, and cloud is
mentioned only once in this article, in the reference list. The conclusion is that the article
does not have enough information about a cloud environment, which is why it does not
support the research question of this thesis.

Sifu – a Cybersecurity Awareness Platform With Challenge Assessment and

Intelligent Coach

This work introduces a cyber security learning platform called Sifu, that has Cyber
Security Challenges that combine serious game techniques with cybersecurity and
secure coding guidelines, to raise secure coding awareness of software developers.
Platform performs automatic assessments of challenges and uses artificial intelligence
to give users hints to help them solve the challenges. [4]
 5

IEC 62443 is not reviewed in this work, but it is mentioned in this work: “addresses
security from a high-level perspective and are not specific enough about
recommendations and policies to be followed in software development”. After this it is
not mentioned anymore, and alternative methods are considered. AWS is mentioned
once as it is the platform used to launch Sifu. Since this work does not have a usable
information about the IEC 62443 or a cloud, it does not support the research question of
this thesis.

Cyber Security Threats and Incident in Industrial Control Systems

This research did a survey study to test the knowledge of Secure Design Principles
(SDPs) among participants who have experience in developing/designing different types
of software. This study also explores if the demographic variables (age, gender,
experience, education) effect the participants knowledge about SDPs and discovered
some misconceptions of SDPs among participants. [5]

In this book, IEC 62443-4-1 standard is mentioned only once when the life cycle
requirements of Industrial Control Systems (ICS) are mentioned. Within this chapter it is
mentioned that some vendors and developers use secure development lifecycle to tackle
security issues with ICS components that have life cycle of 10-20 years. Since this work
does not have a usable information about the IEC 62443 or a cloud, it does not support
the research question of this thesis.

Security Requirements Engineering in Safety-Critical Railway Signalling Networks

This report tells the writers experience when they developed security architecture for
railway signaling systems that starts from the bare safety-critical system that requires
protection. They are using German pre-standard DIN VDE V 0831-104 for security in
railway signaling networks. This is a guideline for applying IEC 62443 framework for
industrial control system security to railway signaling, while considering the relevant
railway safety standards. [6]

IEC 62443-4-1 is mentioned twice in this report when it is noted that “DIN VDE V 0831-
104 assumes that IT security products purchased on the market already have IEC 62443
compatible certification and the ISASecure’s interpretation of IEC 62443-4-1 suggests
that Commercial Off-The-Shelf (COTS) operating systems should at least be certified to
Common Criteria (CC) Evaluation Assurance Level 3 (EAL3)”. References were only
found to IEC 62443-4-1 but not to other search term and I am not sure why did this
 6

showed up on the search. This work does not cover IEC 62443-4-1 or have any
references to a cloud, therefore it does not support the research question of this thesis.

Cybersecurity Awareness Platform with Virtual Coach and Automated Challenge

Assessment

This work presents platform for software developers in the industry that helps them to
increase awareness of secure software development. This also introduces and
interactive game component, a virtual coach. This is extension for the “code entry”
challenge type that was introduced in the Sifu – a cybersecurity awareness platform with
challenge assessment and intelligent coach that was another find from Andor. [7]

This mentions IEC 62443-4-1 almost in a same way as did the Sifu document. IEC62443-
4-1 or ISO 27001 addresses security from high-level perspective and thus are not
specific enough about recommendations, policies, and best practices to be followed in
software development. Since this work does not have a usable information about the IEC
62443 or a cloud, it does not support the research question of this thesis.

Application of IEC 62443 for IoT Components

This paper reuses IEC 62443 approach, where system is broken down into zones and
conduits bases on required security levels, in small scale to show that the same concept
can be used with mixed-criticality IoT components to improve the security on component
level. [8]

IEC 62443-4-1 is mentioned once in this paper under component requirements, where it
is noted that the standards 62443-4-1 and 62443-4-2 belong within component section
of IEC 62443 standard family and what they defines/specifies. Cloud is mentioned once
within introduction, where it is mentioned to be one of the components that IT integrates
with and is built on. Since this work does not have a usable information about the IEC
62443 or a cloud, it does not support the research question of this thesis.

2.3 Scientific Documents Related to IEC 62443-4-1 and Agile

Agile helps teams to deliver results to their customer faster and easier by approaching
project management and software development with iterative mindset. Instead of
creating everything at once into a big release, with agile, teams tend to deliver work in
small, but consumable, increments. This means that requirements, plans, and results
 7

need to be evaluated continuously which gives teams a natural mechanism for

responding to change quickly. [9]

This project uses agile methodologies and according to the Stack Overflow Development
Practices survey [10]. From this survey we can see that agile is popular in software
development project.

Since there were no good documents found related to the IEC 62443-4-1 and cloud, the
decision was made to widen the scope of searches. According to the Stack Overflow’s
polls, it is quite common that development projects use Agile software development
frameworks [10]. This is the case with the used example project also, so widening the
literature research to check if there is any works related to the IEC 62443-4-1 and Agile
seems to be logical. The research question does not include the Agile methodologies,
yet they are commonly used with cloud development and might have common pitfalls
with cloud development. Found works are used to gather some insights on how problems
associated with the agile and the SDL are handled.

Search was done in TUNI’s Andor service and the used search term was “IEC 62443-4-
1 AND Agile”. This search resulted five peer reviewed documents that will be covered
next.

How to Integrate Security Compliance Requirements with Agile Software

Engineering at Scale?

This work presents an extension for Scaled Agile Framework (SAFe) that is compliant
with IEC 62443-4-1 called Security Standard Compliant Scaled Agile Framework (S²C-
SAFe). This work presents the framework and its evaluation by agile and security experts
within Siemens’ large-scale project ecosystem. The benefits and limitations are
discussed as well as challenges from practitioners’ perspective. Results indicate that
S²C-SAFe contributes to successfully integrating secure compliance with lean and agile
development in regulated environments. [11]

The subject and contents of this work are perfect match for what was searched for and
the text seems to be easy to understand. This work presents new extension for SAFe
that we are not that interest in, but this work also presents some pitfalls they have fixed
with it from agile and IEC 62443-4-1 synergy, which could be usable for this thesis. There
were three practices that were problematic with product development and they are
covered in the following chapters.
 8

Security requirements (SR) are made part of the backlog as any other task. “Security
Experts facilitate analysis but are not primarily responsible. Instead, Product
Management, Business Owners, and Systems Architects are in charge so they become
aware of threats. Similarly, the Product Owner requires adequate training to be able to
prioritise and approve security requirements” [11, p. 72].

For Secure Implementation (SI), the secure coding standards are made part of the
Definition of Done, and agile teams as well as product owners are trained accordingly.
Security Verification and Validation Testing (SVV) requires the independence of testers,
this is achieved by independence rules during the formation of agile teams. S²C-SAFe
defines “criteria to keep resource allocation efficient and ensure continuous security
testing, placing security functionality testing at team level and conducting all testing
activities on program level before every System Demo” [11, p. 73].

These findings are somewhat useful for this thesis. Security requirements are placed in
the backlog in the example project and there is one responsible to organize those for the
following sprints. Secure coding standards are used, which are enforced with training
and third-party applications that observe the code. Possible security testing is added to
the existing pipelines and will be run automatically. Yet this does not cover all the open
questions this thesis has, i.e., the possible issues of releasing of the application versions
with fast pace and version documentation, continuous design process with agile, threat
modelling interval and managing security issues with fast pace version releasing.

An Assessment Model for Continuous Security Compliance in Large Scale Agile

Environments

This works research combability of IEC 62443-4-1 and agile development

methodologies. During agile development, it can be hard to define whether the security
requirements are fulfilled and when the changes of IEC 62443-4-1 assessments, or other
secure development activities need to be applied. This work contributes a novel
assessment model that contains a baseline process for secure agile software
engineering compliant to IEC 62443-4-1. This work also contains goals and metrics that
allow the evaluator to provide the appraisal with a precise ’shopping list’ of where to
invest to achieve compliance. [12]

The subject of this work is extension for the previous work, and it completes S2C-SAFe
and covers the searched subject in a bit higher level. This thesis is analysing how well
does IEC 62443-4-1 fit for cloud development process by process, yet this work is
covering the subject in a much higher level, meaning that it does not cover individual
 9

practices and processes, which is why it does not support the research question of this
thesis.

Integration of Security Standards in DevOps Pipelines: An Industry Case Study

Applying the DevOps is particularly challenging for industrial control systems that support
critical infrastructures and obey rigorous requirements from security regulations and
standards. Existing research on security compliant DevOps present open caps for this
domain. This work presents a systematic way to integrate standard-based security
activities into DevOps pipelines and highlight their automation potential. [13]

This work is covering mostly DevOps, while agile methodologies were searched.
Therefore, it does not support the research question of this thesis.

Using Process Models to Understand Security Standards

This is the same research [2] that was previously covered under 2.2. This is the reason
why this article will not be covered under this chapter.

A Light-Weight Tool for the Self-assessment of Security Compliance in Software

Development – An Industry Case

Companies are often challenged to modify their existing development processes to make
them compliant with security standards. This makes it difficult to practitioners to validate
and foresee the effort required for compliance assessments. Performing analyses when
processes are not yet mature enough is costly and involving auditors in early stages is
often inefficient. This work presents a light-weight tool to perform early compliance
assessments for processes with security standards before entering an in-depth audit.
[14]

This work does not support the research question of this thesis, because it targets the
projects in the early stages of their lifecycle, yet the example project is well past the early
stages and thus cannot use the tools mentioned within the article.
 10

2.4 Scientific Documents Related to Security and Cloud

Infrastructure

This research concentrates only on cloud infrastructure and security. The reason is that
with agile, this is only major thing that differs from traditional industrial automation project
that uses IEC 62443-4-1. If a project is not using agile methodologies or cloud
infrastructure, then possible difference with industrial automation project is the used
coding languages and some other minor things. The point of this chapter is to find reliable
resources to use as a source to define secure cloud infrastructure. When this thesis
presents the example project and checks whether it is secure or not, these resources
are used. The cloud infrastructure security information is used to analyse how well does
the SDL note these security features/shortcomings.

The TUNI’s Andor was used to find suitable works to use with this thesis. First search
used the search term “Cloud AND Infrastructure AND Secur*”, but this resulted to 50
thousand peer reviewed results. Search term was updated to “"Cloud Infrastructure"
AND Secur*” which resulted over five thousand peer reviewed works. The search term
used was updated to “ "secure cloud infrastructure" “ which only resulted 30 peer
reviewed results. Shortly after going through these works it was clear that these were
not suitable for this thesis since some of those works dealt with problems that had
solutions only on a theoretical level, and some were used in a wrong scope.

Now the decision was made to change the search string once more to “Cloud
Infrastructure Security” and the perfect conference publishment was found, until it
became clear that this document was around 10 years old. Yet the fundamental idea of
the cloud is still the same and this document is peer reviewed. This document will be
used as an information source for this thesis. To keep this thesis within a reasonable
length, only this one conference publishment will be covered in the following chapters.

Cloud Infrastructure Security

This paper discusses problems of providing the infrastructure security of a cloud. The
data and its security are being given a special attention during this work. Main
components of cloud infrastructure security are defined, and the corresponding issues
and recommendations are given. [15]

This paper firstly defines the cloud computing and different deployment models that can
be used. Then there is some risk and security concerns listed. The most valuable this for
 11

this thesis is the cloud security principles and infrastructure security chapters that have
usable security information that will be used as source during this thesis.

2.5 Literature Research Results

After reviewing all the results that Andor gave, it turns out that usable scientific
documentation related to this thesis was hard to come by. This can be because the
subject is quite new, meaning that industrial automation companies have not introduced
their automation systems to the cloud for that long, which would make this work as a
forerunner on this subject. For works that deals with the subjects agile and SDL, there
were some useful findings that were already mostly implemented within the example
project, but some questions were left unanswered. Works related to the cloud
infrastructure security were a bit hard to come by, since most of the research seems to
be targeting a specific application or system that runs within cloud environment. One
work was found and is used as a source during this thesis. Overall, the literature research
was quite successful and managed to give some scientific basis for this thesis.
 12

3. USED RESOURCES

Following chapters go through the resources that will be used with this work. IEC 62443-
4-1 describes practices and processes of the Secure Development Lifecycle (SDL) that
is applied to the example project, presented under chapter 4. The following sub-chapters
describe the resources that are used to define what is secure cloud computing and they
will be referenced during the thesis.

3.1 IEC 62443-4-1

IEC 62443-4-1 is a part of IEC 62443 standard family that addresses the safety of
industrial automation and control systems. Part 4-1, Secure product development
lifecycle requirements, does address the SDL practices and processes that help users
to secure their devices and applications.

This thesis uses IEC 62443-4-1:2018 Edition 1.0. IEC 62443-4-1 is not a free standard
and it cannot be citated nor distributed freely with this work. Only publicly available
information (process & practice names) and small insights about them can be used with
this thesis. The document used with this thesis is only allowed to be used by Insta Digital
Oy employees.

3.1.1 General Principles

The main goal of these practices and processes are to make products and systems
secure by design and include defense in depth approach to designing, building,
maintaining, and retiring. By applying these practices and processes to the project, they
are intended to provide confidence that the component, product, or system has security
at intended level throughout the product’s lifecycle (start off, designing, implementation,
delivery, maintenance, and decommissioning). [16, p. 17]

3.1.2 Maturity Model

Standard does present usable maturity model that can be used with projects. Idea with
maturity model is that practices and processes, in this standard, are split into different
levels. When the practices and processes are implemented to the product, they should
be implemented in maturity level order. Maturity levels allow easier tracking of product’s
current state of security. [16, p. 19]
 13

Although this is important step for IEC 62443-4-1, it does not fit in the scope of this thesis
because the research question is asking that how well does the processes fit for a cloud
application and not how to do them.

3.1.3 Security Levels

There are three different security levels defined in the IEC 62443 standard family, target
security levels (SL-T), capability security levels (SL-C), and achieved security levels (SL-
A). These levels and their requirements are described in the IEC 62443-3 standard that
is a separate one from IEC 62443-4-1, which also is not free. Security requirements of
these levels were compared against the example project and many of them are valid,
but they were designed for industrial application and might not apply that well to cloud
computing. For example, there are authentication requirements for each security level
that are nicely applicable to cloud environment, but there are also requirements for
wireless devices and networks that does not fit in cloud environment. However, security
levels do not fit the scope of this thesis and they will be replaced with something that will
fit web applications and cloud environment possibly better.

3.1.4 About Practices and Security Processes

There are eight different practices that each cover different section of products secure
lifecycle. Each of these practices include multiple processes, but not all the processes
are mandatory. Processes are tasks that are required to make a product more secure,
whilst the practices are the subjects that combine these processes together.

It is worth to mention that the detailed information about the practices and processes
should not be freely available anywhere, thus following catalogue will only present the
name of the practices and the processes. Description of all practices and processes can
be found from chapter 3, where they are applied to the example project. This way the
information is not duplicated and is located only where it is needed. More accurate
description about all the practices and the processes can be found from standard [16]
IEC 62443-4-1:2018.

Practice 1 – Security Management

- SM-1: Development process

- SM-2: Identification of responsibilities

- SM-3: Identification of applicability

 14

- SM-4: Security expertise

- SM-5: Process scoping

- SM-6: File integrity

- SM-7: Development environment security

- SM-8: Controls for private keys

- SM-9: Security requirements for externally provided components

- SM-10: Custom developed components from third-party supplier

- SM-11: Assessing and addressing security-related issues

- SM-12: Process verification

- SM-13: Continuous improvement

Practice 2 – Specification of Security Requirements

- SR-1: Product security context

- SR-2: Threat model

- SR-3: Product security requirements

- SR-4: Product security requirements content

- SR-5: Security requirements review

Practice 3 – Security by Design

- SD-1: Secure design principles

- SD-2: Defence in depth design

- SD-3: Security design review

- SD-4: Secure design best practices

Practice 4 – Secure Implementation

- SI-1: Security implementation review

- SI-2: Secure coding standards

 15

Practice 5 – Security Verification and Validation Testing

- SVV-1: Security requirements testing

- SVV-2: Threat mitigation testing

- SVV-3: Vulnerability testing

- SVV-4: Penetration testing

- SVV- 5: Independence of testers (Not a process itself, but the standard does
include a table that defines who can perform what tests. This way the reliability
of the test will not be affected by the persons performing them)

Practice 6 – Management of Security-related Issues

- DM-1: Receive notifications of security-related issues

- DM-2: Reviewing security-related issues

- DM-3: Assessing security-related issues

- DM-4: Addressing security-related issues

- DM-5: Disclosing security-related issues

- DM-6: Periodic review of security defect management practice

Practice 7 – Security Update Management

- SUM-1: Security update qualification

- SUM-2: Security update documentation

- SUM-3: Dependent component or operating system security update

documentation

- SUM-4: Security update delivery

- SUM-5: Timely delivery of security patches

Practice 8 – Security Guidelines

- SG-1: Product defence in depth

- SG-2: Defence in depth measures expected in the environment

 16

- SG-3: Security hardening guidelines

- SG-4: Secure disposal guidelines

- SG-5: Secure operation guidelines

- SG-6: Account management guidelines

- SG-7: Documentation review

3.2 Cloud Security Alliance (CSA)

CSA is an organization that was founded in the late 2008 due to the increasing interest
surrounding the cloud computing within the information security community [17].
Currently they are a leading organization at defining and raising awareness about best
practices to help ensure a secure cloud computing environment. They can offer cloud
security-specific research, education, certification, events, and products by harnessing
the knowhow of industry practitioners, associations, governments, and corporate and
individual members. [17]

CSA top 11 Threats to Cloud Computing

This list is used as a replacement for the security requirements presented in the IEC
62443-4-1 standard. This is a list created by the Cloud Security Alliance that consists of
the top 11 threats to a cloud computing [18]. CSA did a case study about these threats
by investigating nine real world attacks and breaches by checking how well these threats
fits for real world applications and found out that a lot of these threats were found from
those systems. [19]

3.2.1 Security Guidance V4.0

Security Guidance for Areas of Focus in Cloud Computing V4.0 is a free book created
by CSA “to provide both guidance and inspiration to support business goals while
managing and mitigating the risks associated with the adoption of cloud computing
technology”. [20, p. 3]

This book covers cloud best practices in multiple chapters, that are:

- Cloud Computing Concepts and Achitectures

- Governance and Enterprice Risk Management

- Legal Issues, Contracts and Eletronic Discovery

 17

- Compliance and Audit Management

- Information Governance

- Management Plance and Business Continuity

- Infrasturcture Security

- Virtualization and Containers

- Incident Response

- Application Security

- Data Security and Encryption

- Identity, Entitlement and Access Management

- Security as a Service

- Related Technologies

The book will be covered only with the scope that fits the example project. This means
that there might be some cloud security related insights left outside the analytical part of
this thesis and not included to the final SDL processes. This book is used as a basis for
what safe cloud computing is, and the example project will be compared against the
practices defined in this book to check the security state of the example project. This
book is free, and it can be obtained from Cloud Security Alliance’s website. [21]

3.3 Center for Internet Security (CIS)

CIS is community-driven non-profit organization whose mission is to make connected

world safer place. They have created globally recognized best practices for securing IT
systems and data that help developers, businesses, and governments to protect
themself against the cyber threats. [22]

AWS Security Hub (explained in next chapter) uses benchmarks that CIS has made for
Amazon Web Services to find possible issues from a cloud environment. These
benchmarks [23] are public information and can be downloaded from their website.

3.4 AWS Security Hub

Security Hub gives comprehensive understanding about the overall security situation of
AWS account. Security Hub does include multiple powerful tools, such as Amazon
GuardDuty, Amazon Inspector, Amazon Macie, AWS Identity and Access Management
(IAM) Access Analyzer, AWS Systems Manager, and AWS Firewall Manager. Security
 18

issues are scanned from environment with automatic security test that are based on
AWS best practices. All the found issues are shown in Security Hub web page under
given account. [24] Security findings will be covered in the project chapter. All the
Security Hub security tools were enabled in this project and more detailed explanation
about them are below.

Amazon GuardDuty

GuardDuty is a threat detection service that protects AWS accounts, workloads, and data
stored in Amazon S3 by continuously monitoring for malicious activity and unauthorized
behaviour. This is possible with the help of machine learning, anomaly detection, and
integrated threat intelligence that can identify and prioritize potential threats. [25]

Amazon Inspector

This helps to improve the security and compliance of applications that are deployed on
AWS by doing automated security assessments. Application exposure, vulnerabilities
and deviations from best practices are automatically assessed. After assessments are
performed, a detailed list of security findings is produced. [26]

Amazon Macie

Macie is a fully managed data security and data privacy service that discovers and
protects sensitive data in AWS with the help of machine learning and pattern matching.
Macie discovers sensitive data automatically from all Amazon S3 buckets (unencrypted,
public, and shared) in the account. [27]

AWS Identity and Access Management (IAM) Access Analyzer

IAM Access Analyzer monitors, and analyses policies applied to AWS resources.
Identifying and removing unintended external or unused permissions is easier when IAM
Access Analyzer helps with review of existing accesses. [28]
 19

AWS Systems Manager

This is the operations hub for AWS. With Systems Manager it is possible to track and
resolve operational issues across AWS applications and resources. Operations can be
automated for EC2 and RDS instances through the System Manager i.e., software
updates. [29]

AWS Firewall Manager

This enables the centrally configuring and managing the firewalls across AWS accounts
and applications [30]. Examined project currently has only one firewall and this service
is not needed.

CIS AWS Foundations Benchmark v1.2.0

Security hub service use this benchmark to find problems from the cloud environment.
This benchmark has satisfied the requirements of Center for Internet Security (CIS)
Certification. [31]

AWS Foundational Security Best Practices v1.0.0

This is an AWS Security Hub benchmark used to analyse the example project’s state of
security. This is used to detect when deployed accounts and resources deviate from
security their best practices. [32]

3.5 The Open Web Application Security Project® (OWASP)

OWASP is a well-known non-profit foundation that offer multiple security-related tools,

technologies, articles to help people with web application security. The following sub-
chapters presents the works of OWASP, which will be used during this thesis.

Comprehensive, Lightweight Application Security Process (CLASP)

CLASP is used as a basis for IEC 62443-4-1. This is over 500-page free eBook that can
be downloaded from OWASP website. “CLASP is an activity driven, role-based set of
process components whose core contains formalized best practices for building security
 20

into your existing or new-start software development lifecycles in a structured,

repeatable, and measurable way.” [33]

OWASP top 10 Web Application Security Risks

This list is used as a replacement for the security requirements presented in the IEC
62443-4-1 standard. This is a standard awareness document that represents the most
critical security risks to web applications, and it is aimed for developers and web
application security. OWASP recommends that companies would adopt this document
to minimize these risks on their web applications. [34]

OWASP top 10 Cloud-Native Application Security Top 10

This list is used as a replacement for the security requirements presented in the IEC
62443-4-1 standard. This list [35] is still under development yet the items on the list can
still be used to improve the security of cloud applications.

3.6 National Institute of Standards and Technology (NIST)

NIST is mainly known in the field of cyber security for developing cybersecurity
standards, guidelines, best practices, and resources to meet the needs of U.S. industry,
federal agencies, and the broader public. NIST is also known for working closely with
organizations in the public and private sectors to make their outputs fit the need of users
better. [36]
 21

4. APPLICATION OF SDL TO CLOUD APPLIATION

PROJECT

4.1 Project Introduction

Project, that the SDL was implemented to, is a simple platform for distributing software
and configuration files for users. Platform can contain multiple products which can
contain multiple packages (downloadable items). Users can browse through products
they have access to, add packages to a cart, and finally download everything they want
to their computer. Packages they download are transferred in compressed zip-like format
that can be used in the end systems. Product owners (PO) can add new product/package
versions and disable unwanted ones from views that only POs/administrators can
access. This project does not contain any payment options at this state. Project
description is intentionally greatly simplified to protect the project from leaking.

4.1.1 What is Cloud Computing

Before we can describe project cloud infrastructure accurately, we need to inspect the
traditional IT infrastructure and the cloud computing first. The characteristics of these
computing models are described in following sub-chapters.

Traditional IT infrastructure

Traditional IT infrastructure is built around a physical hardware, meaning that it can be

just a regular desktop computer or a server that is used to host different kinds of services.
These traditional systems do not usually have a separate data storage, but instead data
can be stored to the same system that hosts the infrastructure, which can increase the
cost of a system failure. Businesses that use this IT model, need to handle regular and
essential software updates by themselves, and if physical hardware is their own, then
also the system updates. Designing the systems to be fail-safe are also much bigger
responsibility for the business that use this IT model.

Cloud computing

“Cloud computing is a model for enabling ubiquitous, convenient, on-demand network

access to a shared pool of configurable computing resources (e.g., networks, servers,
 22

storage, applications, and services) that can be rapidly provisioned and released with
minimal management effort or service provider interaction.” [37]

Where in traditional IT infrastructure servers are bound to a physical hardware, they are
not in cloud computing. For example, there are multiple different ways to store data in
cloud computing, and each of them can be a separate instance running on a separate
hardware. Software updates can be handled automatically, and system updates are
under the responsibility of the service provider in many cases. Designing a fail-safe
system with cloud computing is much easier than with traditional IT infrastructure, and
with some cloud services it can even be automatic.

Essential Characteristics for cloud computing are resource pooling, broad network
access, rapid elasticity, and measured services [20, p. 10]. This means when the cloud
services are not bound on a physical hardware they can be scaled easily. Cloud provider
does have a huge pool of physical devices that are linked to each other, and when user
wants to use some services (resources from that pool), they are automatically allocated
a small portion of it in the form of a service. Cloud computing offers three main types of
service models: Infrastructure as a Service (IaaS), Platform as a Service (PaaS), and
Software as a Service (SaaS) where each of them provides different levels of control,
flexibility, and management [38].

Infrastructure as a Service allows consumers to provision processing, storage, networks,

and other fundamental computing resources. This form of computing enables consumer
to run their own arbitrary applications and operating systems in the service. [39]

Platform as a Service differs from IaaS by not letting consumers to control network,
servers, operating systems, or storage. Consumers still have control over the deployed
applications and possibly configurations done to the application-hosting environment.
[40]

Software as a Service does not give consumer any access to underlying network,
servers, operating systems, storage, or even individual application capabilities.
Consumer can only use the software as is and change some limited user-specific
application configuration settings. [41]

4.1.2 Management Plane

This is the most significant difference between traditional IT infrastructure and cloud
computing. Management plane is the interface to connect with the meta-structure and to
configure much of the cloud. It centralizes all the cloud systems and tools under single
Application Programming Interface (API) and web console. Although all of this is
 23

accessible with a single set of authentication credentials, this is not loss from the security
point of view i.e., there are no more hidden resources, and you can see how everything
is configured from one place. [20, p. 67]

Responsibilities

Cloud provider is responsible for management plane’s safety, and that all security
features are visible for users i.e., granular entitlements to control of what users can do in
management plane. User responsibility is to properly configure their use of the
management plane, and security and management of their credentials. [20, p. 68]

Accessing the Management Plane

APIs and web consoles are the way how the management plane is accessed. Usually,
web console provides a visual interface that uses same API that users can use through
Software Development Kits (SDKs) and Command Line Interfaces (CLIs). APIs are
typically Representational state transfer (REST) for cloud services and run over
Hypertext Transfer Protocol Secure (HTTPS) thus making it more secure across diverse
environments. [20, p. 70]

Configuration in the Project

Management plane is split into tree user levels, root user, administrator, and developer.
All the accounts require multi-factor authentication (MFA), and users store their
passwords within password manager vaults. To gain access to the production
management plane, it is mandatory to request proper access level for personal Azure
AD account from the customer company. If permission to use management plane is
granted, access right will be added to the existing Azure AD user. Developer accounts
are mainly used for configuring the cloud environment, but if the developer account
permissions fall short, the administrator accounts can be used to control the cloud when
needed. Administrator accounts are used to mitigate the need to use the root account.
Administrator accounts does have full access to almost all services except the ones
relating to security, meaning that even the administrators cannot remove logs or security
issues from the cloud. Developers act like day-to-day administrators that does have a
full access to multiple services but not nearly to all i.e., they cannot change their own
access levels or modify anything logging or security related items. This all is aligning with
 24

the Security Guidance V4.0 [20] chapter 6.1.1.2 Securing the Management Plane and
with the chapter of Identity Security from Cloud Infrastructure Security paper [15, p. 114].

4.1.3 Cloud Infrastructure

In this chapter the cloud infrastructure of the example project is described in detail. The
last sub-chapter will compare the infrastructure to the Security Guidance’s [20] security
instructions.

Cloud Security and Responsibilities

All the traditional security domains still exist with cloud computing, but the nature of risks,
roles and responsibilities, and implementation of controls change, sometimes
dramatically. Cloud computing is a shared technology model, where different
organizations are responsible from different parts of the stack, this means that as security
responsibilities are spread across the stack, they are also spread across organizations
involved. This is often called shared responsibility model. The Table 1 describes high-
level security responsibility of the service types.

Service type Security responsibilities

Software as a Service Cloud provider is responsible for nearly all

security. Consumer may only be
responsible of authorization and
entitlements. [15, p. 145]

Platform as a Service Cloud provider is responsible for the

security of the platform. Consumer is
responsible for everything they implement
on the platform. This service type might
offer some provider-maintained security
features. [15, p. 145]

Infrastructure as a Service Cloud provider is responsible for

foundational security. Consumer is
responsible for everything the build on the
infrastructure. [15, p. 145]

Table 1 Service types available in the cloud

 25

Stages

Examined project does use multiple stages to ease the testing before deploying the
project to the production environment. Each stage does have a special purpose and they
are explained in the Table 2 below.

Name (stage) Description

testdepl Used for testing deployment when there are changes in the
infrastructure. Both infrastructure and code are updated by
hand

dev Used for testing the development version of the web

application. Infrastructure is updated by hand and code is
updated automatically by the Jenkins

staging Testbed for all the infrastructure and code changes before
deploying them to the production. This stage is identical to the
production stage. Infrastructure is updated by hand and code
is updated automatically by the Jenkins

prod Production environment that the end users mainly use.

Infrastructure is updated by hand and code is updated
automatically by the Jenkins. Code deployment required some
manual interaction to prevent the accidental deployments

Table 2 Cloud infrastructure stages

 26

Cloud Infrastructure Drawing

The Figure 1 is an infrastructure drawing from the example project. The infrastructure is
split up to use multiple cloud provided services to share the responsibilities. The used
services will be covered below, each within its own sub-chapter.

Figure 1 Cloud infrastructure

CloudFront

CloudFront is a content delivery network which purpose is to bring together multiple

services under one URL. CloudFront does have a static URL and when user tries to
access different paths, the request will be forwarded to specific service i.e.,
https://example.com/ would be directed to the Front end static content while
https://example.com/api/ would be redirected to the API Gateway. This way we can use
only one URL for the website that contains multiple services. CloudFront can also use a
Web Application Firewall (WAF) to monitor all traffic that goes through a CloudFront. [42]
 27

Project currently has five path patterns that are redirected to some service. Generic URL
https://example.com is used for following Table 3 to prevent the leakage of the real
project.

Path Used service

https://example.com/resources/* Private S3 bucket that contains the files

that can be downloaded with the web
application

https://example.com/documents/* Private S3 bucket that contains user

documents for the web application

https://example.com/api/* API Gateway (Explained below)

https://example.com/assets/* Public S3 bucket that contain publicly

available pictures and documents about
the products and the packages in the web
application

https://example.com/* Public S3 bucket that contains the web

application itself

Table 3 CloudFront routing table

Web Application Firewall (WAF)

With WAF users can protect their web applications or APIs against common web exploits
and bots that may affect the availability, compromise security, or consume excessive
resources. AWS has defined multiple managed rulesets for the WAF to use and filter the
traffic that goes through it. There are multiple free rules sets available that can spot SQL
injection or cross-site scripting attempts, and some rulesets that cost money like OWASP
Top 10 – The Complete Ruleset [43]. This project does currently have the following
rulesets enabled:

- WAF-IpReputationList

o To block known “bad” IP addresses

- WAF-Allow-Zip

o To allow zip items to flow through the WAF

 28

o This was required since there were multiple false positives created by the
WAF

- WAF- CommonRuleSet

- WAF-KnownBadInputsRuleSet

S3 Buckets (Front end static content & Product assets bucket)

Amazon simple storage service S3 is and object storage service. This means that it can
be used to store and protect any amount of data i.e., data lakes, websites, mobile
applications, backup and restore, archive, enterprise applications, IoT devices, and big
data analytics [44]

Buckets can be either private, partially public, or public. Private buckets restrict all access
to the files withing, except from those who own the bucket (creator of bucket) or have
been given the rights to access it. Public buckets allow everybody to get (read) the
contents of a given bucket, but the modification and deletion of items can only be done
by the owner or users with the right permissions. Partially public buckets are private
buckets that contain public items.

Signed URL is a way to share data to certain entities from a private bucket without giving
them too broad access rights. It contains the location of the data, information about the
signer and signature done by the entity who has the proper access rights for the given
data. When a user, who does not have rights for given data in bucket, clicks the Signed
URL, the request will be checked in a CloudFront for the validity of a signature, if
everything is correct the user will be redirected to the resource. The problem with Signed
URLs is to prevent their unapproved distribution. This can be partially mitigated by
making URLs time dependant, meaning that they are valid only for a short period of time.

To protect the buckets most of them are set to be private, yet there are couple
exceptions. Front end static content contains the web application itself, so it needs to be
public bucket to make the web application publicly available. Publicly available assets
are also stored within the public bucket, to make sharing of them a bit easier. Turns out
that this is not the best way to do this, instead buckets should be made private and allow
public access through a CloudFront to them. This way we would have partially private
buckets that can be accessed through the CloudFront and with this we would also have
a centralized logging for buckets.

All the valuable assets that are available in the platform are stored in the private buckets
to protect them from unauthorized access. When a authorized user needs something
 29

from the private buckets, backend software creates Signed URL that is signed with the
CloudFront’s private key. Now when the user uses the link, signature will be
automatically checked and if everything is correct, the user can access the files from the
bucket.

Security Hub findings for S3 Buckets are following:

- S3 buckets should prohibit public read access.

- S3 Block Public Access setting should be enabled

- S3 Block Public Access setting should be enabled at the bucket-level.

- S3 buckets should require requests to use Secure Socket Layer

o Currently both HTTP and HTTPS connections are possible

- S3 buckets should have server-side encryption enabled

o It was decided that there is no need for server-side encryption for file that
are stored in S3

Lambda

Lambdas are serverless compute service that run code without provisioning or managing
servers, creating workload-aware cluster scaling logic, maintaining event integrations, or
managing runtimes. Lambdas enable running almost any type of application or backend
service and requires almost no administration. Lambdas can scale automatically based
on how much requests are done. [45]

This project consists several dozen lambdas that together constructs the backend of the
example project. Each API endpoint is a separate Lambda that can be requested by a
user or another application. The beauty of Lambdas is that they can each be individually
configured, meaning that each of them can require different access level from callers
and have different access levels to resources.

Security Hub findings for Lambdas are following:

- Lambda functions should have a dead-letter queue configured

- Lambda functions should use latest runtimes

o Latest runtime cannot be used yet, due the deployment infrastructure

dependencies outside the cloud environment.
 30

API Gateway

API Gateway collects all the Lambdas that are publicly accessible and brings them under
one API. This way one URL can be used to access all the Lambdas [46]. As mentioned
under the CloudFront chapter, some requests done to a CloudFront are redirected to the
API Gateway. API Gateway can also be accessed with a publicly accessible URL, but
that is not a desired way in this project. To prevent the API Gateway direct access and
thus possibly bypassing the CloudFront’s WAF and logging, an API key can be
implemented. This means that a random and rotating key is automatically added to the
request headers when it goes through the CloudFront. When request finally reaches the
API Gateway it does expect this header to be in place, and if it is not, the request will be
dropped. WAF can also be implemented directly to the API Gateway, but the example
project only uses one WAF to have a centralized logging and configuration.

Security Hub findings for API Gateway are following:

- API Gateway REST API stages should be configured to use SSL certificates for
backend authentication

o We are using Lambdas in our project and they work within AWS with the
API Gateway, this means that there is no other easy way to call the
Lambda than through the API Gateway and through the Management
Plane, thus making certificates redundant.

- API Gateway should be associated with a WAF Web ACL

o We decided that one WAF for the example project is a better solution.
This way we don’t have to keep two identical WAFs up to date.

CloudFormation

With the help of CloudFormation the project infrastructure can be written in YAML (data
serialization language) and be deployed with ease, this is referred as Infrastructure as
Code (IaC). This way multiple services like, databases, Lambdas, API Gateway, EC2
(Elastic computing), and other services can be linked to each other before deploying and
then deployed to cloud together where they act as a unit. This helps tremendously with
deploying, maintaining, updating, and deleting different stacks (deployed unit). [47]

In this project, infrastructure and code are deployed with the help of a CloudFormation.
The infrastructure is deployed by hand and the code is normally deployed (can also be
deployed by hand) by the Jenkins during the normal deployment pipeline.
 31

EC2 Bastion Host

Amazon Elastic Compute Cloud (Amazon EC2) is a compute capacity in the cloud. User
can choose processor, storage, networking, operating system, and purchase model of
their liking when deploying the instance. [48]

To prevent Relational Database Service (RDS) instance from being exposed to the
Internet, a publicly available EC2 instance can be used to manage the RDS instance
while RDS is kept in a private network within the AWS. To make an EC2 secure it uses
a hardened image that is created with the AWS EC2 Image builder. Images build with
this tool are automatically updated by build-in automation and does include AWS-
provided security settings. Images are updated by creating a new image and testing it
against AWS-provided tests, new instance is created, and the old instance is replaced
with the new one [49]. Hardening is “a process intended to eliminate a means of attack
by patching vulnerabilities and turning off nonessential services” [50].

In the example project, at first the EC2 was reachable through SSH connection that had
IP-whitelisting in use. The problem was that IP-addresses can change and it was publicly
reachable, so the connection method was changed. Now the only way to connect the
EC2 instance is through the AWS Session manager (explained below). Security Hub
findings for the EC2 are following:

- EC2 instances should use Instance Metadata Service Version 2 (IMDSv2)

- EC2 instances should not have a public IPv4 address

- Amazon EC2 should be configured to use VPC endpoints

Session Manager

AWS Systems Manager Session Manager allows users to connect their EC2 instances,
on-premises instances, and virtual machines through AWS webpage with browser, or
with AWS Command Line Interface (CLI). [51]

Session Manager can be used with private EC2 instances, but we still have SSH
connection remnants in our infrastructure and that is why our EC2 is located within a
public subnet that has Security Group blocking all the inbound traffic. With the help of a
Session Manager, a SSH connection does not need to be exposed to the Internet.
Another benefit from this is that users need to use their own credentials to connect the
instance and not shared password/key that is commonly used with SSH connections,
and with this comes better logging capabilities.
 32

Regions and Availability Zones

Regions are physical locations around the world where Amazon clusters the data
centres. Each region consists multiple, isolated, and physically separated availability
zones within a given geographic area. Each availability zone has independent power,
cooling, and physical security. [52]

This project is hosted in one of the EU regions that has three availability zones available.
All these availability zones are used with networking and most of the other services that
are covered in this thesis. Cloud Infrastructure Security paper [15, p. 147] states that
availability of public facing (and internal) services should be ensured, which is made
easier with regions and availability zones.

Virtual Private Cloud (VPC), Subnetworks and Security Groups

VPC is a logically isolated network in cloud that is user-defined. Virtual networking

environment is completely under user control and user must configure IP address range,
creation of subnets, and configuration of route tables and network gateways if necessary.
[53]

Security groups acts as a virtual firewall for service instance to control inbound and
outbound traffic [54]. Almost all the services have their own security group defined to
allow specific inbound and outbound traffic. All security groups implement default deny
when they are created.

This project uses one VPC that does have four subnetworks defined under it. Three of
these subnetworks are private, which are not able to connect the Internet. There are
three private subnetworks because all of them are in a different availability zone,
meaning if one or two of the availability zones go down for unknown reason, there are
still one or two more to handle the networking between the services. The last subnetwork
is a public one, and it is a remnant from the time when connections to EC2 instance were
handled through SSH-connections, but its connection to the Internet is blocked by
Security Group rules.

Security Hub findings for VPC are following:

- The VPC default security group should not allow inbound and outbound traffic

- VPC flow logging should be enabled in all VPCs

 33

Relational Database Service (RDS)

Amazon Relational Database Service is an easy to set up, operate, and scale relational
database in the cloud. It does automate traditional administration tasks such as hardware
provisioning, database setup, patching and backups. [55]

In this project there is one database that is used to save information about the projects,
the packages, and some statistics. The database is automatically backed up with daily,
weekly, and monthly cycle. The RDS is connected to couple private subnetworks which
are the only way to connect the database. The database is not visible to the Internet and
Lambdas can access it because they are within the same private subnetwork as is the
EC2 instance which can be accessed through Session Manager. EC2 instance is used
to modify database during deployment.

Security Hub findings for RDS are following:

- Database logging should be enabled

- RDS instances should not use a database engine default port

- Enhanced monitoring should be configured for RDS DB instances

o This would provide real-time metrics from the operating system that RDS
instance runs on

Microsoft Azure Active Directory (Azure AD)

Azure AD is enterprise identity service that enables single sign-on and multi-factor
authentication [56]. Customer, to which the example project is made to, currently has
their own Azure AD set up that contains all their user accounts. These accounts can be
used in this project with the help of Cognito (explained below).

Cognito

Cognito lets users to add sing-up, sign-in, and access control to web and mobile apps.
It does support sign-in with multiple social identity providers such as Apple, Facebook,
Google, and Amazon, and enterprise identity providers via SAML and OpenID Connect
[57].

Cognito is used to handle sing-ins in this project. When user wants to log in to the
example project, they enter the login page of the web application. From there, they are
redirected to the Azure AD login screen. When they enter proper credentials, the Azure
 34

AD generates message that is sent to the AWS Cognito, and that message contains
information about the user, groups linked to the account, and roles for the user. Cognito
parses this information into token format. After all this, the token will be sent to the user
and with that token, the user can use this web application, with the rights given by Azure
AD. Cognito can be used to change the account privileges if necessary, yet it is not
recommended nor allowed to do so in the example project.

Back Office System (Gray cylinder at the bottom)

BOS contains all the master data for products in the example project. BOS sends this
data to the example project and it the BOS cannot be connected from the example
project’s side.

CloudTrail and CloudWatch (logging)

CloudTrail does provide event history about AWS account activity of AWS management
console, AWS SDKs, command line tools, and other AWS services [58]. With this it is
possible to notice all the changes done to cloud infrastructure.

In the example project, CloudTrail events are saved on a separate account making it
impossible to change them from the account that contains the infrastructure.

CloudWatch is monitoring and observation service that collects monitoring and

operational data from logs, metrics, and events providing unified view of AWS resources,
applications, and services. [59]

In this project, CloudWatch gathers all the logs that are printed from the application or
services within the infrastructure. Security Hub findings for CloudTrail are following:

- CloudTrail should have encryption at-rest enabled

- CloudTrail log file validation should be enabled

- Ensure CloudTrail logs are encrypted at rest using Key Management Service
(KMS) Customer-managed Keys (CMKs)

- Ensure CloudTrail log validation is enabled

- Ensure that log metric filters and alarms exist for anything that is not allowed to
be changed
 35

Parameter Store

This provides a secure storage for secrets and configuration data. Values stored in here
can be automatically encrypted, have length up to 4096 characters, and be referenced
by CloudFormation [60]. With the help of this, services and application can have shared
secrets and configurations without the need of hard coding them to the code.

Infrastructure Security

According to Security Guidance V4.0 [20] networking should be split into multiple
subnetworks, which is done in this project, Security Groups should be used for each
service and have default deny implemented which are also done in this project. Remote
access has been removed from all the services (except the Session Manager one), used
images are hardened and constantly updated and tested by AWS. Important logs are
stored to external account and AWS Security Hub is scanning the interface and services.
With this it is safe to say that infrastructure security of this project is on par with Cloud
Security Alliance’s Security Guidelines V4.0.

4.1.4 Identity, Entitlement, and Access Management

Managing Users and Identities for Cloud Computing

Organizations that manage cloud environment should develop a comprehensive and

formalized plan and processes for managing identities and authorizations with cloud
services. If connections to external cloud providers are used, federation should be used
if possible, to extend existing identity management. It is good to try to avoid silos of
identities in cloud providers that are not tied to internal identities. Create entitlement
matrix for each cloud provider and project that defines the access to the meta-structure
and/or management plane. Prefer Role Based Access Control over Attribute-Based
Access Control. [20, p. 139]

User and identity management is something that Insta Digital Oy, the developer of this
project, is not responsible. Cloud account is owned by a company which is responsible
for maintenance of the project and creating and maintaining access roles within that
account. Access roles has been decided in collaboration with developers. To gain access
to the production account, one firstly needs account to the customer system and after
that the account needs to be granted proper rights to be able to use Single Sign On
 36

(SSO) to access the production account. Cloud environment uses federated SSO to
enable users with Azure AD accounts to log in Amazon Cloud.

Authentication and Credentials

For cloud environments there is a great need for strong authentication using multiple
factors. This is because cloud services are always accessible over the network, and often
over the Internet. If credentials were to be stolen, the attacker could access everything
under the account. If Federation has been used, that means one set of credentials could
be used to access greater number of cloud services [20, pp. 136-137]. To mitigate this,
an MFA is one of the strongest options to reduce account takeovers. [20, pp. 136-137]

Accounts used with the production cloud environment are managed by the customer and
are forced to be used with MFA. Developers stores their password with password
manager. Passwords are required to be changed twice a year. Security Hub findings for
Identity and Access Management (IAM) are following:

- Hardware MFA should be enabled for the root user

- IAM principals should not have IAM inline policies that allow decryption actions
on all KMS keys

- IAM customer managed policies should not allow decryption actions on all KMS
keys

- IAM users' access keys should be rotated every 90 days or less

- Password policies for IAM users should have strong configurations

- IAM authentication should be configured for RDS instances

- IAM users should not have IAM policies attached

- IAM customer managed policies that you create should not allow wildcard actions
for services

- Ensure access keys are rotated every 90 days or less

- Ensure hardware MFA is enabled for the “root” account

- Ensure proper password policy (uppercase, lowercase, symbol, number, length

>14, no reuse, expires in 90days)

- Ensure IAM policies are attached only to groups and roles

 37

State of Identity, Entitlement, and Access Management in this project

Best practices in Security Guidance 4.0 are mostly followed in this chapter. Although we
are not responsible for managing users and identities in the cloud environment it was
easy to verify that the current environment is enforcing the MFA for each account, role-
based access control, federated SSO, and there are no multiple or unnecessary account
defined directly under AWS account. These configurations also follow the Identity
Security recommendations from Cloud Infrastructure Security [15, p. 145]

4.1.5 Data Security and Encryption

Policies

At the beginning, define the policies for which data types are allowed and where they are
allowed. After this you must tie these to your baseline security, meaning that you have
datatypes that is allowed for certain services only if it meets the certain encryption and
access control requirements [20, pp. 120-122]. This project currently does not have a
written data security policy that defines the previously mentioned.

Data Migrations

Monitor data repositories for large migrations/activity to give an early warning from large
data transfer. This can help to detect major data breaches or misuse scenarios. Cloud
environments usually have their own tools that can be used to monitor data repositories
[20, pp. 120-122]. This project does not have migration/activity alerts at the given
moment.

Data Delivered Through the Application

The example project does include a web application from where users can download
items to their own computer, also product owners/administrators can upload new items
to the web application. The data is secured in transit with HTTPS that provides encrypted
transfer of files. When data is being sent to the bucket behind the web application, the
frontend code calculates MD5 message-digest of the package which is used to check
that the correct file got uploaded to the bucket. These all are aligning with the
recommendations in Cloud Infrastructure Security paper [15, p. 147]
 38

Securing Data in the Cloud

Access control to cloud data should be implemented with a minimum of three layers.
management plane (user access right to data through management plane), public and
internal sharing controls (if user does not have direct access to the data), and application-
level controls (self-defined controls to manage access) [20, pp. 122-123]. Security
Guidance [20] also suggest that entitlement matrix should be done to define which
access levels should have access rights to what data along with setting up alerts if new
public shares are created or existing shares are turned into public.

The example project’s management plane access rights prevent developers from
deleting a bucket or a RDS instance. Developers can use the Session Manager to
connect the EC2 instance which is connected to the RDS. Developers have full access
rights to the database if the database passwords are known.

Connections that are coming from outside of the management plane are handled with
signed URLs. These URLs are handed through the web application to those who have
proper access rights to given files.

Some lambdas in this project needs to connect some buckets, but they are defined with
custom roles that they only possess, leaving all the other lambdas without permission to
access the buckets. Database and backend application are within the same subnetwork,
which allows application to connect database with predefined credentials whilst
restricting all other accesses attempts to the database.

Storage (at-rest) Encryption and Tokenization

Encryption, a mathematical algorithm that “scrambles” the data, and Tokenization,

replace data with token and store data within secure database, are two ways how data
can be protected in storage. While there are multiple ways how data can be encrypted
i.e., by client before storage, during transit with proxy, with application, using encrypted
storage, etc. the best way must be selected based on the threat model for the data,
business, and technical requirements. [20, pp. 123-125]

This project does not use encrypted or tokenized data storage. The trust for AWS
compound security is high and data is always secured during the transit, which is why
encryption or tokenization was not implemented.
 39

Data Backup

Database is automatically backed up daily, weekly, and monthly to make sure latest data
is always backed up. Buckets does have a replica bucket that is perfect clone of the
given bucket. This will prevent the data loss if the bucket is deleted completely, because
the replica bucket is running in its own instance. Buckets also use versioning, that make
them work GIT-like, meaning that each version of the files are stored separately, while
only the latest versions is shown for the users. With this, accidentally deleted/modified
files, or intentionally encrypted files (ransomware) can be recovered by returning file
version to the previous one.

Key Security

The cloud provider key management services are used with this project to secure
symmetric keys, CloudFront key-pair, and certificates. There are four potential ways for
handling keys in a cloud environment [20, pp. 125-126].

- Hardware security module (HSM)/appliance-based key manager that typically

need to be on-prem and deliver keys to the cloud.

- Virtual appliance/software-based key manager in the cloud.

- Cloud provider key management service.

- Hybrid that can be combination of the previously mentioned methods.

Data Security Architectures

By using cloud provider features the attack surface can be reduced, but strong meta-
structure security must be demanded. Using cloud storage or a queue service that
communicates on the provider’s network, and not within cloud virtual network, the
network can be gapped. This forces attackers to either compromise the cloud provider
or just attack the application level. [20, p. 126]

In AWS each bucked does have their own URL and are hosted within their own network.

Data Loss Prevention (DPL)

Databases have backups enabled and buckets does have replica buckets and versioning
in use (explained above, under Data Backup). Databases and buckets cannot be deleted
 40

directly and require proper access rights and disabling safety measures from AWS
account.

Test Data Generation

Integration tests uses custom database entries that are generated before the tests are
run. The data used in the tests are random data that resembles the real data without
revealing anything.

Data Location

Data can be stored in multiple regions with cloud environments. With the example project
the production data is located within Europe to fulfil the GDPR requirements.

State of Data Security and Encryption

Comparing this project’s current data security and encrypting to Security Guidance v4.0
recommendations this project is on a right track, yet there are still some best practices
to be implemented. Also, when comparing data security to Cloud Infrastructure Security
[15, p. 144] some things are missing, like data encryption at rest. Otherwise, the
recommendations from the paper are executed well.

- Cloud provider security tools are used instead of building own.

- Entitlement matrix for determining access controls is something that have not
been done yet and might not be mandatory with this small project.

- This project does not use Cloud Access Security Broker (CASB) to monitor the
data that goes between users and cloud.

- Data is always encrypted during transit by HTTPS, yet it is not encrypted at-rest
because that is not seen as a threat for used data.

- Cloud provided services are used to store keys.

- Cloud architecture is used to improve data security.

- Data is stored within Europe to fulfil possible GDPR requirements.

- Access and API logging are implemented.

- Data is backed up.

 41

4.1.6 Application Security

Deployment Pipeline Security (Jenkins)

Jenkins is open-source automation server that can be used as Continuous Integration

(CI) server and extended to be Continuous Delivery (CD) hub. It supports multiple plugins
that can be used to integrate multiple tools to CI/CD pipeline. [61]

Deployment pipeline can increase security of project through support of immutable

infrastructure, automated security testing, and extensive logging or application and
infrastructure changes. The pipeline needs to be properly secured, it should be hosted
in a dedicated cloud environment with very limited access to cloud or the infrastructure
hosting the pipeline components. [20, pp. 113-115]

Jenkins is hosted in the customer’s network, and it can only be accessed through
customer’s VPN with proper credentials. Credentials that Jenkins use are strictly limited
to have only mandatory privileges. Jenkins does have a web interface where developers
can check the state of the pipeline and it can be accessed without credentials with
customer’s VPN, but any changes to the pipeline requires the use of credentials. Table
4 will describe all the stages Jenkins currently have, if any of these stages give an error
the deployment will be stopped.
 42

Stage Description

Build Node Package Manager (NPM) install. All

the packages of the project are installed

Static code analysis Project is checked with linting against

predefined rules

Dependency analysis Jenkins will create Bill of Materials (BOM)

that is sent to vulnerability assessment
server (explained below)

Unit tests Developer defined unit tests will be ran

Integration tests Developer defined integration tests will be

ran

Deploy If everything is fine up until this point, the

project will be deployed to the cloud

Robot Framework tests (Frontend only) After frontend has been deployed, robot
tests will be run against it to check basic
functionalities

Deploy SQL After project is deployed any possible

changes to the database will be deployed

Deployment test This stage will automatically generate

tests for each of the API endpoint. The
test will call each API endpoint with
different level credentials to check that the
access control is working properly.

Table 4 Project deployment stages in Jenkins

 43

Product Deployment and Update

Jenkins handles the deployment and the update of the product, but this requires human
interaction in order it to happen for production environment. To update the production
environment, developer needs to select updates that are wanted for production and
update them to the staging environment. If those updates work properly in the staging
environment, developer can trigger Jenkins to update the production environment with
the same updates. This deployment does have couple Jenkins gates (deployment stops
to wait for human interaction) to prevent accidental deployment.

Ownership

With cloud technologies it is possible to spread the responsibilities across entities. For
example, in this project Insta Digital Oy is responsible for developing this project for the
customer. Product is hosted in Amazon cloud on an account that is owned by another
company, which is accountable for operating and maintenance of the product in the
production environment. With cloud computing, companies can easily outsource the
product’s operating and maintenance responsibilities to a company that has a lot of
experience from it.

Web Application Technologies

This project uses technologies that heavily rely on JavaScript and Node Package
Manager (NPM). With the NPM it is possible to install third-party packages to a project.
These packages need to be monitored in case of a vulnerability (explained below) by
creating a Bill of Materials (BOM) that contains a list of packages used within a project.

Vulnerability Assessment

This is required by Cloud Infrastructure Security paper [15, p. 146], it demands

component-level security with vulnerability-assessment and change-management. This
server is managed by our customer and we only send BOMs to it and receive information
about the security stage of our used packages. If any vulnerabilities have been found, all
developers involved to this project will receive an email that will explain the vulnerability
and possible fixes for it. Also, the Jenkins deployment pipeline will stop if any
vulnerabilities have been found.
 44

Training

Developers, operations, and security should receive training on cloud security

fundamentals and cloud provider specific technical security training [20, p. 112]

All the developer has gone through the company’s SDL training, but we did not have any
cloud specific security training which is a shortcoming.

Secure Design

The focus for security in cloud is on architecture, the cloud provider’s baseline
capabilities, cloud provider features, and automating and managing security for
deployment and operations, during the application design process. [20, p. 112]

For cloud environments (secure)design tends to come in phases, like the example
project is built in phases. The current design of the project does follow multiple best
practices for the cloud environment which it did not a while ago. Cloud environments and
the used serverless technology is still a fairly new thing and new best practices pop up
time to time. We just must implement them to the project in a timely manner, if they are
useful for us, after which the design will be secure enough.

Development

Sometimes developers need administrative access to development environment and

cloud management plane, to configure networks, services, and other setting. This should
never be production environment or hold production data. [20, pp. 112-113]

Developers mostly use the development environment with higher access rights to test
their code. Last place to test code is the staging environment that is identical to the
production environment, yet it does not include any production data. When everything is
working as intended in the staging, updates will be pushed to the production. The testing
is already done with other stages and deployments are handled manually or with Jenkins,
therefore developers does not need to access the production environment often

Code Review

Code review doesn’t change much for cloud environment, but there’s some specific
areas that need additional attention. Any changes that can change infrastructure, make
API calls cloud service, includes encryption or authentication should be examined
carefully. [20, p. 113]
 45

This is required by Cloud Infrastructure Security paper [15, p. 146] by demanding

component-level security with vulnerability-assessment and change-management. This
project uses pull reviews (code review) for all the changes in the project. This means that
the other developers need to approve your changes to the project in order them to be
added to the project. Developers could use a bit more security and cloud training to make
code reviews a bit sturdier on that behalf.

Code Testing

Testing should be implemented to be automatic and work in cloud environment and

integrate security testing to the deployment pipeline [20, p. 118]. Project does include
unit tests, integration tests, deployment tests, and robot framework tests. All the changes
to the code must be tested by hand and with code if they are any way testable. Tests run
automatically within Jenkins’ environment.

4.2 Selecting SDL Processes to the Project

In this chapter all the SDL processes will be checked for their suitability to the project.
Processes will be covered in same order they were presented in chapter 2.1.

4.2.1 Practice 1 – Security management

The purpose of this practice is to make sure that the security-related activities are
properly planned, documented, and executed throughout the product’s lifecycle [16, p.
20]. Processes included to this practice are handled in the following sub-chapters.

SM-1: Development Process

Product’s development, maintenance and support process should be documented and

is required to be consistent and integrated with other development processes [16, p. 21].
Documentation is always useful for any kind of project and this project does not differ.
Documenting is already well organized and shared across other similar development
processes, so there’s no reason not to include this process in this project.

SM-2: Identification of Responsibilities

Personnel responsibilities and organizational roles shall be identified for each of the
processes in these practices [16, p. 21]. This process is mandatory every time with the
 46

SDL, since without personnel that are responsible of these processes, the SDL
implementation will not make any progress within the project.

SM-3: Identification of Applicability

Only take products, or parts of the products, that requires securing to apply these
practises and processes [16, p. 21]. This process as well is pretty much mandatory for
all the projects. There is no point to increase security of the parts of the project that does
not require it. This will only bring unnecessary costs.

SM-4: Security Expertise

All the personnel assigned in process SM-2 should have proper security expertise for
the given role or responsibility. Trainings shall be offered if any lacks in expertise are
noticed. [16, p. 22]

All personnel should have proper training for their role. This project does have mandatory
SDL training, but cloud and other security related trainings are missing. Without proper
training the product security may decline drastically so this is considered as mandatory.

SM-5: Process Scoping

Identify what parts of these practices and processes are applicable to the project [16, p.
22]. This chapter of the thesis is covering this process, deciding what processes should
be used with the project. There is no point trying to do processes that are not suitable for
the project, therefore this is mandatory.

SM-6: File Integrity

File integrity checking mechanism should be implemented for all scrips, executables and
other important files that are included in the project or delivered through it [16, p. 23]. As
mentioned before in the Application Security chapter, there are files that need file
integrity checks, making this process mandatory for this project.

SM-7: Development Environment Security

Securing the development environment to protect the product or product update during
design, implementation, testing, and release [16, p. 23]. If there is some development
 47

involved with the project, as this does, this process is required to make development
environment as secure as it can be.

SM-8: Controls for Private Keys

Securing the private keys from unauthorized access or modifications in store and during
transit [16, p. 23]. As mentioned previously under the Application Security chapter, there
are some file integrity requirements for files that can be downloaded from the example
project’s web application. This file integrity requirement will be handled with public-key
cryptography, along with the content signing, in the future, therefore this process is
required.

SM-9: Security Requirements for Externally Provided Components

Monitor the vulnerabilities of third-party components that are used within products, or
product parts, if they can have an impact on product’s security [16, p. 24]. This project
uses a lot of externally developed packages with JavaScript related technologies, making
this process required. Also, Cloud Infrastructure Security [15, p. 146] indirectly requires
this.

SM-10: Custom Developed Components from Third-party Supplier

Specific purpose custom components that are developed by third-party supplier which
can have an impact on security must also follow IEC 62443-4-1:2018 [16, p. 24]. There
are none custom developer components in this project at the time of writing, thus this
process is not required.

SM-11: Assessing and Addressing Security-related Issues

Product or patches should not be released if they have security-issues that have not
been fixed, analysed, or accepted [16, p. 25]. This process is pretty much always
mandatory and furthermore this product is a web application that will be available on the
Internet and will receive multiple updates during its lifetime. Because of these reasons,
this process is necessary, but this needs to be changed a bit for a cloud environment.
Cloud/agile development can have fast pace releases that can update something as
small as one letter from the view. So, this needs to be done a bit differently and it will be
covered in the analytical chapter.
 48

SM-12: Process Verification

It should be verified that all the security-related processes/issues that are applicable to
the product are completed and documented prior each product release [16, p. 25]. Like
the previous one, this is always required process for the SDL, but this needs to be
changed a bit for a cloud environment. Cloud, or agile, development can have fast pace
releases that can update something as small as one letter from the view. So, this needs
to be done a bit differently and it will be covered in the analytical chapter.

SM-13: Continuous Improvement

SDL process should be continuously improved, meaning that every security defect that
has escaped to the field should be analysed to improve the SDL process [16, p. 25]. Not
like other most of the other processes that you can mark done, but more like never ending
process to make SDL process as good as it can be. There are no reasons to leave this
one out since this will only have benefits in the long run.

4.2.2 Practice 2 – Specification of Security Requirements

The purpose of this practice is to document the product’s security capabilities and
expected security context [16, p. 26]. Processes included to this practice are handled in
the following sub-chapters.

SR-1: Product Security Context

Document the security context of the product. Document the minimum requirements of
the environment for the product to get the security level for which the product was
designed. [16, p. 27]

Even though cloud security context can differ a lot from traditional IT infrastructure it is
still necessary to document it. The user, in this case not the end user but the company
that manages this application in the cloud, can use this document to configure the cloud
to have security context developers expect it to have. This process is required.

SR-2: Threat Model

Threat models are used to identify, communicate, and understand threats and
mitigations within the project. It is a structured representation of all the information that
affects the security of the project. [62] This process simply requires that threat models
 49

are created from the products. Standard also requires that it is reviewed at least once a
year for possible updates. [16, p. 27]

Since this project is a public web application it can have vulnerabilities and the threat
modelling is good way to find the possible threats and mitigations for this application,
making this a required process.

SR-3: Product Security Requirements

Define and document all product security requirements that also includes privileges
required to install, operate, maintain, and decommissioning the product [16, p. 28].
Project management plane does have couple different access levels and users also have
different access levels to the web application. Therefore, it is required to document
required privileges, so the developers and users have a clear view about required
privileges for each action. This project does not have any predefined security
requirements therefore those will not be documented.

SR-4: Product Security Requirements Content

Check that the security requirements does contain the scope & boundaries of the
component or system (Physical & logical) and required capability security level (SL-C) of
the product [16, p. 29]. There are no predefined security requirements for this project.

SR-5: Security Requirements Review

Security requirements should be reviewed, updated as necessary, and approved to

ensure clarity, validity, and alignment with threat model, and lastly it should be verified
[16, p. 29]. There were no security requirements defined for the example project, but the
example project does have security context documentation, threat model, and
documented privileges for different scenarios required by SR-3 and these all is good to
be kept up to date, thus making this required, yet with a bit different scope.

4.2.3 Practice 3 – Security by Design

The purpose of this practice is to ensure that the product is secure by design including
defence in depth [16, p. 30]. Processes included to this practice are handled in the
following sub-chapters.
 50

SD-1: Secure Design Principles

Develop and document a secure design that identifies and characterizes each interface
of the product, including physical and logical interfaces [16, p. 30]. This process is
mandatory, since without secure design this web application could have some drastic
vulnerabilities.

SD-2: Defence in Depth Design

Defence in depth is layering security measures to common attack vectors to ensure that
attacks that are missed by one technology are caught by another. [63] Using the threat
model as a base for a risk-based approach, design the implementation of multiple layers
of defence (defence in depth). [16, p. 31]

Defence in depth is possible to do within a cloud environment, for example a web

application frontend, a Web Application Firewall, a web application backend could all
have some security restriction on data. If defence in depth is possible to do it should be
done and that is why this process is required.

SD-3: Security Design Review

Periodically review the design and update it to handle all the security requirements,
threats, security-related issues, and security design best practices, if some of those were
not included to the design already [16, p. 32]. Periodically done security design update
that is required if there is some security design documents and since this project does
have them, this process is required.

SD-4: Secure Design Best Practices

Periodically review that secure design best practices are properly documented and
applied to the design process and update if necessary [16, p. 32]. This is required since
if there is some security design involved, this process is mandatory to review those
designs and keep them up to date.
 51

4.2.4 Practice 4 – Secure Implementation

The purpose of this practice is to ensure that product features are implemented securely
[16, p. 33]. Processes included to this practice are handled in the following sub-chapters.

SI-1: Security Implementation Review

Implementation reviews are performed while addressing the secure design, security
requirements, and implementation best practices [16, p. 33]. This project already implies
code reviews and static code analysis, yet periodic manual implementation and design
reviews are still missing but can be implemented quite easily. This process is crucial step
to secure the project, therefore it is required.

SI-2: Secure Coding Standards

Use security coding standards that are reviewed and updated periodically [16, p. 34].
This project uses linting to check for possible security issues in code, and we are
following the secure coding standards defined by the customer company. This process
is required.

4.2.5 Practice 5 – Security Verification and Validation Testing

The purpose of this practice is to document the security testing required to ensure that
all the security requirements have been met [16, p. 34]. Processes included to this
practice are handled in the following sub-chapters.

SVV-1: Security Requirements Testing

Ensure that product security functions meet the security requirements, and the errors
and invalid inputs are handled properly. Test should include functional testing,
performance and scalability testing and boundary/edge condition, stress, and
malformed/unexpected input tests. [16, p. 35] There were no security requirements for
this project.

SVV-2: Threat Mitigation Testing

Threats that have been identified and fixed needs to be tested to have full knowledge
that it has been mitigated properly [16, p. 35]. If there can be threats in the product, and
 52

there will be if the product is a web application, there needs to be tests that validate the
mitigations have been implemented correctly, thus making this process required.

SVV-3: Vulnerability Testing

Tests that try to identify and characterize potential security vulnerabilities from the
product [16, p. 36]. This project is using vulnerability assessment to scan the packages
used within the project and linting to check the rest of the code. This is an important step
for a web application that can have multiple vulnerabilities during its lifetime. This is
required process.

SVV-4: Penetration Testing

Tests that try to identify and characterize potential security-related issues from the
product by exploiting security vulnerabilities [16, p. 36]. This step is also considered to
be required, since this can bring a lot of insight about the current state of the security of
the example project.

4.2.6 Practice 6 – Management of Security-related Issues

The purpose of this practice is to manage the found security-related issues that of
product that has been configured to employ its defence in depth strategy [16, p. 38]. If
the product can have security-related issues, all the following processes should be
required. This project is a web application that uses a lot of 3rd party packages and is
accessible on the Internet, so this project almost bound to have some security issues
during its lifetime. Therefore, all the following processes in this chapter are required.
Processes included to this practice are handled in the following sub-chapters.

DM-1: Receive Notifications of Security-related Issues

Have a way how the security-related issues can be reported by personnel within your
organization or even from outside of your organization and then tracked to closure [16,
p. 38]. Required. This project does have contact person at the customer side and Jira is
used to record the issues.
 53

DM-2: Reviewing Security-related Issues

Reported security-related issues should be investigated in a timely manner determine

their applicability to product, verifiability and threats that trigger the issue [16, p. 38]. This
process is required.

DM-3: Assessing Security-related Issues

Assess the impact, severity, and identify other products/parts that have same security
related issue, root cause, and related security issues caused by given security-related
issue [16, p. 39]. This process is required.

DM-4: Addressing Security-related Issues

Supplier should determinate acceptable level of residual risk for the security-related
issue when deciding the proper way to address each issue. Following actions can be
taken, fix the issue, create remediation plan, defer the issue, leave it unfixed. [16, p. 40]
This process is required.

DM-5: Disclosing Security-related Issues

Users should be informed about reportable security-related issues in timely manner.

Following information should be delivered to users: issue description, vulnerability score,
affected product versions, and description of the resolution. [16, p. 41] This process is
required.

DM-6: Periodic Review of Security Defect Management Practice

Security-related issue management process should be reviewed periodically. This

should at least examine security-related issued that have went through the process since
the last review and determine was the process complete, efficient and did it lead to the
resolution of each issue. [16, p. 42] This process is required.
 54

4.2.7 Practice 7 – Security Update Management

The purpose of this practice is to ensure that each product security update is tested for
regressions and made available to product users in a timely manner [16, p. 42]. Before
addressing these processes, it is wise to define the term user here. User can mean the
end user, system user or other companies that manage this project in the cloud. With
this definition it is much easier to decide whether the processes in this practice should
be required in this project. Processes included to this practice are handled in the
following sub-chapters.

SUM-1: Security Update Qualification

Each update should address the intended security vulnerability and not introduce any
regression. This process should include confirmation that the update is not contradicting
other operational, safety or legal constraints. [16, p. 42]

This process is required. All the updates should, as the definition mentions, address only
the intended security vulnerability and as mentioned previously, web applications are
likely candidates to have vulnerabilities during their lifetime.

SUM-2: Security Update Documentation

Product update documentation should be made available for product users [16, p. 42].
In the case of web applications, the regular update documents are not normally shared
with end users. This project does have a third-party company that manages this project
in the cloud and the customer company also wants to know what has been updated and
when. This project already has properly written update documentation and it will be used
to include security update documentation when needed. This task should be required if
there are some security updates involved with the product and this indeed does, so this
process is required.

SUM-3: Dependent Component or Operating System Security Update

Documentation

Dependant component or operating system security updates documentation should be

made available to the users [16, p. 43]. There are no direct operating system or
components that would affect users in this project. With cloud infrastructure most of the
services are either PaaS or SaaS where operating systems are not in our hands. This
 55

project includes one IaaS (EC2) but that does not concern users in any way, and it is
hardened and automatically updating instance. Responsibility of this process in
transferred to the AWS, because they are responsible for the dependent components
and OS updates for the used services.

SUM-4: Security Update Delivery

Security updates should be delivered to the users with a manner that facilitates
verification so that the users can be sure of the authenticity of the patches [16, p. 43].
Web application does not have same kinds of update delivery problems to users that
traditional software’s might have. Traditional software like Google Chrome runs on user’s
computer, where web applications are fetched from some server and user will always
get the latest version available. This means that users could receive updated web page
each time they update the page, this is of course highly unlikely, but possible. Now only
requirements are that the web page is delivered securely to the user and therefore
HTTPS is used. Update delivery to the cloud can be also secured and that has been
covered under the Application Security chapter. Secure delivering of the content to the
users and secure deployment of the project are covered under different processes so
this process is not required.

SUM-5: Timely Delivery of Security Patches

Define a policy that specifies the timeframes and qualifications for delivering the security
updates to the users [16, p. 44]. If there can be security-related issues, there must be
security patches and therefore it is wise to define a policy how fast security patches
should be delivered. In this case though, patches will not be delivered to the end users,
but just deployed as an update to cloud environment to fix the security issues. This is
required since this project most likely will have security issues in future.

4.2.8 Practice 8 – Security Guidelines

The purpose of this practice is to specify processes that provide user documentation that
describes how to integrate, configure, and maintain the defence in depth strategy of the
product in the security context it is meant to be used [16, p. 44]. Processes included to
this practice are handled in the following sub-chapters.

Before addressing these processes, it is wise to define the term user here. User can
mean the end user, system user or other companies that manage this project in the
 56

cloud. By defining the user like this, all the following processes are now suitable for the
example project.

SG-1: Product Defence in Depth

Create user documentation for the product that describes the security defence in depth
strategy for the product installation, operation, and maintenance [16, p. 44]. This process
is required.

SG-2: Defence in Depth Measures Expected in the Environment

Create user documentation for the product that describes the security defence in depth
measures that are expected to be provided by the external environment where the
product is to be used [16, p. 45]. This process is required.

SG-3: Security Hardening Guidelines

Create user documentation for the product that includes guidelines for hardening the
product during the installing and maintaining process [16, p. 45]. This process is required.

SG-4: Secure Disposal Guidelines

Create user documentation for the product that includes guidelines for removing the
product from use [16, p. 46]. This process is required.

SG-5: Security Operation Guidelines

Create user documentation for the product that includes guidelines for secure operations
for users and administrators [16, p. 46]. This process is required.

SG-6: Account Management Guidelines

Create user documentation for the product that defines recommendations associated
with the use of the product and user account requirements [16, p. 47]. This process is
required.
 57

SG-7: Documentation Review

Review the user manuals and the security guidelines to identify, characterize, and track
to closure errors and omissions [16, p. 47]. If there is some documentation done in this
practice, this step is required to keep the documents updated.

4.3 Summary of Selections

This chapter will summarize all the selected and not selected processes. The selected
and not selected processes are presented in the Table 5 below.

Practice name Selected processes Not selected processes

Security Management SM-1, SM-2, SM-3, SM- SM-10

4, SM-5, SM-6, SM-7,
SM-8, SM-9, SM-11, SM-
12, SM-13,

Specification of Security SR-1, SR-2, SR-3, SR-5 SR-4

Requirements

Security by Design SD-1, SD-2, SD-3, SD-4

Secure Implementation SI-1, SI-2

Security Verification and SVV-2, SVV-3, SVV-4 SVV-1

Validation Testing

Management of Security- DM-1, DM-2, DM-3, DM-

related Issues 4, DM-5, DM-6,

Security Update SUM-1, SUM-2, SUM-4, SUM-3

Management SUM-5,

Security Guidelines SG-1, SG-2, SG-3, SG-4,

SG-5, SG-6, SG-7

Table 5 Selected IEC 62443-4-1 processes for the example project

 58

5. ANALYSIS OF IEC 62443-4-1 SUITABILITY FOR

CLOUD SOFTWARE DEVELOPMENT

5.1 How IEC 62443-4-1 Practises and Processes Fit to the Cloud
Computing

In this chapter each of the practices of IEC 62443-4-1 are analysed in its own sub-chapter
for suitability to cloud computing. The sub-chapters will use intel gathered from previous
chapters to decide the suitability of the practices and the processes.

5.1.1 Practice 1 – Security Management

All these processes fit the cloud environment quite nice, there are some details that
needs to be told though. SM-10 was left out of the project just because it did not have
any components that was supplied by a third-party company. If there are any third-party
supplied components present, this process should be applicable to cloud environment
as is. With SM-7: Development environment security process, there needs to be extra
keen eye for test data generation, since it can sometimes resemble the production data
too much or be a direct copy of it, and this increases the disclosure risk of production
data.

SM-11/SM-12 cannot be used as is since, as mentioned, the product releases can

happen in a fast pace and contain even one letter change to application interfaces. Now
if every security issue/process needs to be analysed or implemented before any release,
this could easily clog the development agility. So there needs to be different way to
handle this. One way could be to use semantic versioning with major, minor, and patch
releases. With the help of this versioning, the patch releases could ignore whole SM-
11/12 processes. Minor releases could include SM-11, by requiring that all the security
issues are analysed, yet the implementation of processes/issues are not mandatory (SM-
12). Lastly the major releases require SM-11/12. With this, it is required that security
issues and processes are added to the project backlog, as they were required in the
previous research [11, p. 72], and are done during the sprints in a timely manner, so the
completion of security issues/processes is not tied to slow pace major releases.
 59

5.1.2 Practice 2 – Specification of Security Requirements

Security context (SR-1) can be documented, and threat model (SR-2) can be created for
the example project, making these processes applicable to a cloud environment. SR-3
can be applied at least partly, but the security requirements that are part of SR-3 and
SR-4 are not covered in this thesis. However, if security requirements are not considered
to be ideal for a cloud environment, they can be replaced with OWASP top 10 web
application security risks, OWASP top 10 cloud security risks and with CSA top 11
threats to cloud computing security checklists. These common web application
vulnerabilities are required to be noted by Cloud Infrastructure Security paper [15, p.
147], which makes this replacement a bit more logical. All these three lists should be
covered in the project with the necessary scale that is applicable to the project.

Compared to traditional IT infrastructure or industrial automation, cloud environment can

be quite different. There can be some IT / automation systems that will have security
context and threat model defined once during its lifetime, where cloud environments can
be constantly evolving and expanding, and because of this the security context and the
threat models needs to be updated constantly. The original SR-5 required the periodic
check of security requirements, but with a cloud environment it should require periodic
check of security context, threat models, documented user privileges, and novelty of
used security checklists.

5.1.3 Practice 3 – Security by Design

If the IEC 62443-4-1 standard creators would not have been far sighted, this practice
could have backfired when tried to be implement on a cloud environment. Meaning that
processes under this practice are defined quite loosely i.e., “develop, and document a
secure design”, which impose responsibility fully to the implementor. This practice does
include processes that are used to keep designs up to date and that is mandatory for
cloud applications that can evolve quite a lot during its lifetime. It is absolutely important
that the implementor understands the diversity of cloud computing when implementing
these processes. The best practices for traditional IT computing or for industrial
automation are not best practices for cloud computing. But when implementor does have
a good understanding about the cloud environment, there should be no problems to
implement all the processes under this practice to a cloud environment. If security
requirements are replaced with security checklists, then SD-3 needs to be altered to take
these security checklists into account.

One thing that example project was missing that cloud have been covered with this SD-
1 process is monitoring data repositories for large migrations. With this, it is possible to
 60

give warnings from large data transfers, and this will help to mitigate the risk of large data
leaks that are much too common these days.

5.1.4 Practice 4 – Secure Implementation

Both processes under this practice were selected for the project. SI-1 implementation
reviews should address security requirements, but if security requirements are not used
with the project, they can again be replaced with security checklists mentioned previously
(OWASP top 10’s and CSA top 11). Otherwise, this practice should be fully
implementable for cloud applications.

5.1.5 Practice 5 – Security Verification and Validation Testing

Like in other practices, if security requirements have been replaced with security
checklists, they can be used in place of security requirements for SVV-1 testing. Other
tests in this practice should be feasible to implement for cloud environment. Yet cloud
environment can evolve and expand during its lifetime, so the testing needs to evolve
with the cloud, meaning that all the tests should be updated and ran periodically.

5.1.6 Practice 6 – Management of Security-related Issues

Managing security-related issues is not platform dependant, which means that the
applicability of this practice is not affected by a cloud environment. All the processes
within this practice are fully applicable to a cloud environment as is.

5.1.7 Practice 7 – Security Update Management

As it was mentioned under 4.2.7, the user related to the processes under this practice
might need some definition to make assessing these processes bit easier. This definition
is “User can mean the end user, system user or other companies that manage this project
in the cloud.”

SUM-1, SUM-5 are clear and applicable to cloud environment as is. SUM-2 that require
making update documentation available for product users. With web applications it is not
that common to share update documents with end users, and with the example project
the update documentation is shared with the customer company and third-party company
that manages the cloud. But whatever is decided, and whom to receive the update
documents, this process is applicable to the cloud environment. SUM-3 was not required
for the example project, because with the used services the responsibility have been
transferred to the AWS. Yet Cloud computing can use dependant components and even
 61

IaaS based services where OS is implementor’s responsibility and because of this SUM-
3 is applicable to the cloud environment.

SUM-4 suggests that there should be a way for the users to verify delivered security
update’s authenticity. As mentioned, this is not required for web applications, since the
security updates are not delivered to the users, but the cloud application is updated, and
it is delivered securely to the end user’s browsers. But this does not mean that this will
not ever be required with cloud environments. If i.e., cloud environment is used as a
backend for desktop application or automation system, then the security updated
possibly needs to be delivered to the users once again.

5.1.8 Practice 8 – Security Guidelines

As it was mentioned under 4.2.8, the user related to the processes under this practice
might need some definition, to make assessing these processes bit easier. This definition
is “User can mean the end user, system user or other companies that manage this project
in the cloud.”

In the example project, user is a third-party company that is managing the cloud
environment on behalf of us or the customer company. All the documents required by
this practice are addressed to that company, to make their job easier to manage this web
application in the cloud. But it does not matter who is the cloud operator, since cloud
environment can be bit complex and cumbersome, these documents will help users to
use the cloud environment more securely. These documents need to be periodically
updated as cloud environment evolves and expands, errors are found, or other
improvements are discovered. All these processes are applicable to the cloud
environment.

5.2 Fitting Project’s Security Findings to the SDL Processes

This matter is settled by going through the whole project introduction and covering how
well all the security-related findings have been covered with current SDL processes.
When some security-related findings do not fit any of the current SDL processes, new
process will be proposed.

5.2.1 Management Plane

Under management plane chapter there was not that many security-related findings. The
cloud provider is responsible for management plane’s safety, but user is responsible for
configuring the management plane properly, and security and management of their
 62

credentials. The management plane best practices could be part of the SG-3: Security
hardening guidelines, since the management plane configuration can be in the hands of
the third-party company that manages the application in the cloud.

5.2.2 Cloud Infrastructure

The Cloud Infrastructure chapter did have a much more security-related findings and
they are reviewed in this chapter. IEC 62443-4-1 did have process about defence in
depth design, and this covers many of the infrastructural security-related findings. Even
though it’s bit loosely described process, it covers at least CloudFront, WAF, API
Gateway, security groups, and networking. Then there is processes SD-1 and SD-4 that
cover secure design and best practices that handles almost all the rest infrastructural
security-related findings. Table 6 shows which of the SDL process handle which security
requirement/problems.
 63

Security-related findings Covered by

Use provided services SD-1

Use multiple stages SD-1, additional details below

Usage of CloudFront & configuration SD-1 & SD-2 & SD-3

Usage of WAF & Configuration SD-1 & SD-2 & SD-3

Bucket encryption, separation, and SD-1

publicity

Data transfer (Signed URLs & SD-1

encryption)

Lambda configuration SD-1

Usage of API Gateway & configuration SD-1 & SD-2 & SD-3

Usage of CloudFormation SD-1

Usage of EC2 & hardened images SD-1 & SD-2

Remote connection configurations SD-1

Availability & Regions SD-1 & SD-2

Secure networking SD-1 & SD-2

Database configuration SD-1

Usage of identity services & SD-1

Authentication

Logging SD-1

Secret handling SD-1

Table 6 How does the IEC 62443-4-1 cover the infrastructure security findings
 64

One thing that might not be that obvious for a somebody used to industrial automation
or traditional IT. Cloud environment can be published in multiple stages, with this it is
possible to test the application in a production like environment before deploying it to the
production environment. This is something that falls under SD-1, yet the designer must
know of this option.

5.2.3 Identity, entitlement, and access management

This is something that might be bit unique for cloud environment, compared to the
industrial automation. Cloud environment can use federated connection and one project
can be separated to multiple accounts. It is mandatory that there are some designs that
handle this. This chapter also had multiple security findings, which can be handled, along
with other account settings, under SG-6: Account management guidelines, this can be
used by the entity who oversees the production account that holds the end-product.

5.2.4 Data Security and Encryption

Multiple security-related findings within this chapter fall under the existing SDL
processes, for example data policies (who can access what and how), HTTPS
implementation, role definitions, key security, data loss prevention, use of cloud provider
tools, and backups are all covered with existing processes. The Table 7 will show each
security-related finding and what process will handle it.
 65

Security-related findings Covered by

Data policies SD-1 & SG-5 & SG-4

Data migrations monitor SD-1 & SG-5

Data delivered through SD-1

Securing data in the cloud (access & SD-1 & SG-5 & SG-6
encryption)

Data backup SD-1 & SG-5

Key security SD-1 & SG-4 & SG-5 & SM-8

Data security architectures SD-1

Data loss prevention SD-1 & SG-4 & SG-5

Test data generation SM-7 & SI-1 &

Data location SD-1 & SG-5

Table 7 How does the IEC 62443-4-1 cover the data security findings

There is one problem that require some extra attention, the data location. With cloud
environment, user data can be stored in some country, yet it can be also copied to an
edge location if that data is needed often there. This behaviour is something that can
unexpectedly break the GDPR or some other regulations in some cases, thus it is
mandatory to have good plan for data storage. This is something that needs to be
handled with production version of the product, and since it can be managed some other
entity, the data location requirements can be written into SG-5: Security operation
guidelines.
 66

5.2.5 Application security

Most of the security-related findings under this chapter does fit the existing processes.
The Table 8 will go through each of the security findings and map them to the existing
SDL processes.

Security-related findings Covered by

Deployment pipeline security SD-1 & SM-7

Product deployment and update SM-1 & SM-7

Ownership of the product and SM-1 & SG-5 & SG-6

accounts used to handle it

Vulnerability tracking SVV-3

Training SM-3

Secure design SD-1-4

Development security SM-7

Code review & Testing SI-1 & SI-2 & SVV-1 & SVV-2 & SD-1

Table 8 How does the IEC 62443-4-1 cover the application security findings

There were two findings that might need some extra attention. Adding human gates for
production deployment is something that was used in the example project and this is just
to prevent automatic, unintended, deployments. Another one was the ownership of the
product and its parts. With a cloud environment it is easy to share the ownership of a
product. I.e., in the example project, the account that the product is being hosted on in
AWS, is owned by a third-party company. It might be even possible to split big projects
into multiple parts and spread the maintenance responsibility over multiple companies,
thus it requires documentation that who is responsible for what. This can be documented
into SG-5: Security operation guidelines.
 67

5.3 Compatible IEC 62443-4-1 Processes with Cloud Computing

Table 9 shows what IEC 62443-4-1 processes are compatible with a cloud computing. It
also shows what should be kept in mind if they are not fully compatible.

Practice name Fully compatible Compatible, with cautions to

Security management SM-1, SM-2, SM-3, SM-4, SM-7: Test data

SM-5, SM-6, SM-8, SM-9,
SM-11, SM-12: Fast pace
SM-10, SM-13
deployment

Specification of SR-1, SR-2, SR-5 SR-3, SR-4: Security

Security requirements
Requirements

Security by Design SD-1, SD-2, SD-4 SD-3: Security requirements

Secure SI-2 SI-1: Security requirements

Implementation

Security Verification SVV-1: Security requirements

and Validation Testing
SVV-1, SVV-2, SVV-3, SVV-4:

Testing frequency

Management of DM-* (all)

Security-related
Issues

Security Update SUM-1, SUM-3, SUM-5 SUM-2: Who is user

Management
SUM-4: Not applicable for web
applications

Security Guidelines SG-* (all): Who is user

Table 9 Compatible IEC 62443-4-1 Processes with Cloud Computing

 68

6. CONCLUSIONS

IEC 62443-4-1 (4-1) is a widely used standard with industrial automation in many
companies. Many companies that use 4-1 do have some operating models and tools
already defined for this standard, and with this thesis we are trying to find out if those
tools and models can be used with a cloud developing, which will widen the future options
for these companies.

There were no remarkable findings from scientific literature that would investigate the
combability of 4-1 and cloud development. This could be because the cloud computing
is a relatively recent invention, and the industrial automation often demands the reliability
which cannot be guaranteed with new services.

Scientific literature was also searched to find good resources for a cloud infrastructure
security, yet they were a bit hard to come by, since many of these works are targeting
some specific area of a web application or a cloud, and not a cloud infrastructure. One
document was found and used during this thesis. The literature research could be a bit
broader, but it was left to be a stub to keep the thesis within a reasonable length.

The literature research was extended to also cover works that handle 4-1 and agile, since
a modern cloud development is often combined with agile development methodologies.
There was one notable work that is used with this thesis, which required adding the SDL
processes to the backlog, making testing continuous, and to ensure proper training.

The combability of 4-1 to cloud development was explored with the help of the example
project. The example project is a simple platform for distributing software and
configuration files that has quite simple access management. To know whether 4-1 is
suitable for a cloud development or not, firstly the project is fully presented and the
project is compared against couple resources to check its current state of security. After
this, the 4-1 processes are applied to the example project and the suitability of each
process is described. Finally, the applicability of existing 4-1 processes to cloud
development is analyzed and the application’s current state of security is analyzed
against the 4-1 processes, to check whether there are some processes missing from the
4-1.

Original 4-1 processes are suitable to the example project for the most parts. There are
some processes that needs some redefining to make them a bit more understandable in
a general and for a cloud development. For example, test data generation should be
done carefully to not imitate the production data too closely, which could leak some
 69

sensitive information. Security-related issues/processes cannot be

completed/analyzed/accepted for each release, since with cloud/web/agile development
the releases can be as small as one letter update for the view, and by checking each of
the security issue/process before the deployment cloud diminish the agility of the
development. Alternative way to handle this is presented in chapter 5.1.1.

Some 4-1 processes include security requirements that are completely different standard
to go through, and this was skipped to keep this thesis within a reasonable length. They
were lightly analyzed to not be that suitable for a cloud development and the alternative
route was suggested. Some literature suggests [15] that common web vulnerabilities
should always be considered with cloud applications, so some security checklists were
suggested to replace the security requirements. These security checklists are popular
and well known OWASP top 10 web application security risks, OWASP top 10 cloud
security risks and CSA top 11 threats to cloud computing.

Updating the application can be a bit different with a cloud computing than with an
industrial automation, and especially with web applications. With web applications the
updates are done to the cloud environment and not to end users’ systems. This means
that an update documentation is not often made available to end users at all, but to a
system user/customer who operates a cloud environment. The same goes with Security
guidelines documentation, which is not targeted to end users but often for a system
user/customer who operates a cloud environment.

Other observations during this work were that testing should be automated with a cloud
development and done on a regular basis. Testing is required by 4-1, but the agile/cloud
development demands much faster pace for a testing than traditional IT/industrial
automation.

So how well does the IEC 62443-4-1 fit for the cloud computing? Really well, if the
implementor remembers a couple important things. The cloud development usually
revolves around the agile methodologies, which means that some of the processes
cannot be implemented as is, they require some light alterations. Also, the diversity of a
cloud environment versus the traditional IT/industrial automation is a quite severe, and it
must be kept in mind when implementing 4-1 to a cloud environment. Lastly, the user
mentioned in multiple processes needs to be defined, since it is not always the traditional
end user.

The work turned out to be fine and answered well to the research question. The possible
follow up research could be comparing security levels mentioned in 4-1 versus security
checklists presented in this thesis for cloud/web applications.
 70

7. REFERENCES

[1] R. W. Schlosser, O. Wendt, S. Bhavnani and B. Nail-Chiwetalu, "Use of information-

seeking strategies for developing systematic reviews and engaging in evidence-based
practice: the application of traditional and comprehensive Pearl Growing," International
journal of language & communication disorders, vol. 41, no. 5, pp. 567-582, 2006.
[2] F. Moyón, D. Méndez, K. Beckers and S. Klepper, "Using Process Models to
Understand Security Standards," in SOFSEM 2021: Theory and Practice of Computer
Science, 2021-01-11, Vol.12607, Cham: Springer International Publishing, 2021, pp.
458-471.
[3] I. Mugarza, J. L. Flores and J. L. Montero, "Security issues and software updates
management in the industrial internet of things (Iiot) era," Sensors (Basel, Switzerland),
vol. 20, no. 2020-12-02, pp. 1-22, 2020.
[4] T. Espinha Gasiba, U. Lechner and M. Pinto-Albuquerque, "Sifu - a cybersecurity
awareness platform with challenge assessment and intelligent coach," Cybersecurity,
vol. 3, no. 2020-12-15, pp. 1-23, 2020.
[5] J. Mehrfeld, "Cyber Security Threats and Incidents in Industrial Control Systems," in
HCI for Cybersecurity, Privacy and Trust, 2020-07-10, Vol.12210, Cham: Springer
International Publishing, 2020, pp. 599-608.
[6] M. Heinrich, T. Vateva-Gurova, T. Arul, S. Katzenbeisser, N. Suri, H. Birkholz, A.
Fuchs, C. Krauß, M. Zhdanova, D. Kuzhiyelil, S. Tverdyshev, C. Schlehuber and D.
Megias, "Security Requirements Engineering in Safety-Critical Railway Signalling
Networks," Security and communication networks, vol. 2019, no. 2019-07-14, pp. 1-14,
2019.
[7] T. Gasiba, U. Lechner, M. Pinto-Albuquerque and A. Porwal, "Cybersecurity
Awareness Platform with Virtual Coach and Automated Challenge Assessment,"
Computer Security, vol. 12501, no. 2020-12-17, pp. 67-83, 2020.
[8] A. M. Shaaban, E. Kristen and C. Schmittner, "Application of IEC 62443 for IoT
Components," in Computer Safety, Reliability, and Security, 2018.
[9] "Agile," Atlassian Corporation Plc, [Online]. Available:
https://www.atlassian.com/agile. [Accessed 3 November 2021].
[10] "Development practices," Stack Overflow, [Online]. Available:
https://insights.stackoverflow.com/survey/2018#development-practices. [Accessed 3
November 2021].
[11] F. Moyón, D. Méndez, K. Beckers and S. Klepper, "How to Integrate Security
Compliance Requirements with Agile Software Engineering at Scale?," in Product-
Focused Software Process Improvement, Cham: Springer International Publishing,
2020, pp. 69-87.
[12] S. Dännart, F. M. Constante and K. Beckers, "An Assessment Model for Continuous
Security Compliance in Large Scale Agile Environments: Exploratory Paper," in
Advanced Information Systems Engineering, 2019-05-29, 2019.
[13] F. Moyón, R. Soares, M. Pinto-Albuquerque, D. Mendez and K. Beckers, "Integration
of Security Standards in DevOps Pipelines: An Industry Case Study," in Product-
Focused Software Process Improvement, Cham: Springer International Publishing,
2020, pp. 434-452.
[14] F. Moyón, C. Bayr, D. Mendez, S. Dännart and K. Beckers, "A Light-Weight Tool for
the Self-assessment of Security Compliance in Software Development – An Industry
Case," in SOFSEM 2020: Theory and Practice of Computer Science, Cham: Springer
International Publishing, 2020, pp. 403-416.
[15] D. Velev and P. Zlateva, "Cloud Infrastructure Security," in Open Research Problems
in Network Security, 2011.
 71

[16] International Standard, IEC 62443-4-1, Security for industrial automation and control
systems – Part 4-1: Secure product development lifecycle requirements, 2018.
[17] "Cloud Security Alliance," Cloud Security Alliance, [Online]. Available:
https://cloudsecurityalliance.org/. [Accessed 3 November 2021].
[18] "CSA 11 top threats to cloud computing," Cloud Security Alliance, [Online]. Available:
https://www.meritalk.com/articles/cloud-security-alliance-releases-11-top-threats-to-
cloud-computing/. [Accessed 3 November 2021].
[19] S. Bhat, J.-M. C. Brook, B. Calguner, T. Eliyahu, A. Getzin, V. Hargrave, E. Osime,
M. Roza, J. Yeoh and N. Yosif, Top Threats to Cloud Computing: Ergegious Eleven Deep
Dive, Cloud Security Alliance, 2020.
[20] R. Mogull, J. Arlen, F. Gilbert, A. Lane, D. Mortman, G. Peterson and M. Rothman,
Security Guidance - For Critical Areas of Focus In Cloud Computing v4.0, Cloud Security
Alliance, 2021.
[21] "Security Guidance v4.0," [Online]. Available:
https://cloudsecurityalliance.org/research/guidance/. [Accessed 3 November 2021].
[22] "Center for Internet Security (CIS)," Center for Internet Security, [Online]. Available:
https://www.cisecurity.org/about-us/. [Accessed 3 November 2021].
[23] "CIS Benchmarks," Center for Internet Security, [Online]. Available:
https://learn.cisecurity.org/benchmarks. [Accessed 3 November 2021].
[24] "Amazon Security Hub," Amazon Web Services, [Online]. Available:
https://aws.amazon.com/security-hub. [Accessed 3 November 2021].
[25] "Amazon GuardDuty," Amazon Web Services, [Online]. Available:
https://aws.amazon.com/guardduty/. [Accessed 3 November 2021].
[26] "Amazon Inspector," Amazon Web Services, [Online]. Available:
https://aws.amazon.com/inspector/. [Accessed 3 November 2021].
[27] "Amazon Macie," Amazon Web Services, [Online]. Available:
https://aws.amazon.com/macie/. [Accessed 3 November 2021].
[28] "AWS Identity and Access Management (IAM) Access Analyzer," Amazon Web
Services, [Online]. Available: https://aws.amazon.com/iam/features/analyze-access/.
[Accessed 3 November 2021].
[29] "Amazon Systems Manager," Amazon Web Services, [Online]. Available:
https://aws.amazon.com/systems-manager/. [Accessed 3 November 2021].
[30] "AWS Firewall Manager," Amazon Web Services, [Online]. Available:
https://aws.amazon.com/firewall-manager/. [Accessed 3 Novemer 2021].
[31] "CIS AWS Foundations Benchmark v1.2.0," Amazon Web Services, [Online].
Available: https://docs.aws.amazon.com/securityhub/latest/userguide/securityhub-
standards-cis.html. [Accessed 3 November 2021].
[32] "AWS Foundational Security Best Practices v1.0.0," Amazon Web Services, [Online].
Available: https://docs.aws.amazon.com/securityhub/latest/userguide/securityhub-
standards-fsbp.html. [Accessed 3 November 2021].
[33] "OWASP Comprehensive, Lightweigth Application Security Process (CLASP)," 31
March 2006. [Online]. Available: https://owasp.org/www-pdf-archive//Us_owasp-clasp-
v12-for-print-lulu.pdf. [Accessed 3 November 2021].
[34] "OWASP Top Ten," OWASP, 2021. [Online]. Available: https://owasp.org/www-
project-top-ten/. [Accessed 3 November 2021].
[35] "OWASP Cloud-Native Application Security Top 10," [Online]. Available:
https://owasp.org/www-project-cloud-native-application-security-top-10/. [Accessed 4
November 2021].
[36] "NIST," National Institute of Standards and Technology, [Online]. Available:
https://www.nist.gov/cybersecurity. [Accessed 3 November 2021].
[37] P. Mell and T. Grance, "The NIST Definition of Cloud Computing," National Institute
of Standards and Technology, September 2011. [Online]. Available:
https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-145.pdf.
[Accessed 3 November 2021].
 72

[38] "What is cloud computing?," Amazon Web Services, [Online]. Available:

https://aws.amazon.com/what-is-cloud-computing/. [Accessed 3 November 2021].
[39] "Infrastructure as a Service," National Institute of Standards and Technology,
[Online]. Available: https://csrc.nist.gov/glossary/term/infrastructure_as_a_service.
[Accessed 3 November 2021].
[40] "Platform as a Service," National Institute of Standards and Technology, [Online].
Available: https://csrc.nist.gov/glossary/term/platform_as_a_service. [Accessed 3
November 2021].
[41] "Software as a Service," National Institute of Standards and Technology, [Online].
Available: https://csrc.nist.gov/glossary/term/software_as_a_service. [Accessed 3
November 2021].
[42] "AWS CloudFront," Amazon Web Services, [Online]. Available:
https://aws.amazon.com/cloudfront/. [Accessed 3 November 2021].
[43] "AWS Web Application Firewall," Amazon Web Services, [Online]. Available:
https://aws.amazon.com/waf/. [Accessed 3 November 2021].
[44] "S3," Amazon Web Services, [Online]. Available: https://aws.amazon.com/s3/.
[Accessed 3 November 2021].
[45] "Lambda," Amazon Web Services, [Online]. Available:
https://aws.amazon.com/lambda/. [Accessed 3 November 2021].
[46] "APIGateway," Amazon Web Services, [Online]. Available:
https://aws.amazon.com/api-gateway/. [Accessed 3 November 2021].
[47] "CloudFormation," Amazon Web Services, [Online]. Available:
https://aws.amazon.com/cloudformation/. [Accessed 3 November 2021].
[48] "EC2," Amazon Web Services, [Online]. Available: https://aws.amazon.com/ec2/.
[Accessed 3 November 2021].
[49] "Image Builder," Amazon Web Services, [Online]. Available:
https://aws.amazon.com/image-builder/. [Accessed 3 November 2021].
[50] "Image Hardening," National Institute of Standards and Technology, [Online].
Available: https://csrc.nist.gov/glossary/term/hardening. [Accessed 3 November 2021].
[51] "Session Manager," Amazon Web Services, [Online]. Available:
https://docs.aws.amazon.com/systems-manager/latest/userguide/session-
manager.html. [Accessed 3 November 2021].
[52] "Regions and Availability Zones," Amazon Web Services, [Online]. Available:
https://aws.amazon.com/about-aws/global-infrastructure/regions_az/. [Accessed 3
Novermber 2021].
[53] "Virtual Private Cloud (VPC)," Amazon Web Services, [Online]. Available:
https://aws.amazon.com/vpc. [Accessed 3 November 2021].
[54] "Security Groups," Amazon Web Services, [Online]. Available:
https://docs.aws.amazon.com/vpc/latest/userguide/VPC_SecurityGroups.html.
[Accessed 3 November 2021].
[55] "Relational Database Service (RDS)," Amazon Web Services, [Online]. Available:
https://aws.amazon.com/rds/. [Accessed 3 November 2021].
[56] "Azure Active Directory," Microsoft Azure, [Online]. Available:
https://azure.microsoft.com/en-us/services/active-directory/. [Accessed 3 November
2021].
[57] "Cognito," Amazon Web Services, [Online]. Available:
https://aws.amazon.com/cognito/. [Accessed 3 November 2021].
[58] "CloudTrail," Amazon Web Services, [Online]. Available:
https://aws.amazon.com/cloudtrail/. [Accessed 3 November 2021].
[59] "CloudWatch," Amazon Web Services, [Online]. Available:
https://aws.amazon.com/cloudwatch/. [Accessed 3 November 2021].
[60] "AWS Systems Manager Parameter Store," Amazon Web Services, [Online].
Available: https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-
manager-parameter-store.html. [Accessed 3 November 2021].
 73

[61] K. Kawaguchi, "Jenkins," Open source, [Online]. Available: https://www.jenkins.io/.

[Accessed 3 November 2021].
[62] "Threat modeling," OWASP, [Online]. Available: https://owasp.org/www-
community/Threat_Modeling. [Accessed 4 November 2021].
[63] "Defense in Depth," National Institute of Standards and Technology, [Online].
Available: https://csrc.nist.gov/glossary/term/defense_in_depth. [Accessed 4 November
2021].
[64] "Source Code Analysis Tools," OWASP, [Online]. Available: https://owasp.org/www-
community/Source_Code_Analysis_Tools. [Accessed 3 November 2021].