Master of Science in Engineering: Computer Security June 2021
Semi-automated hardening of networks based on security classifications
Linus Elwing-Malmfelt Oscar Keresztes
Faculty of Computing, Blekinge Institute of Technology, 371 79 Karlskrona, Sweden
Security. The thesis is equivalent to 20 weeks of full time studies.
The authors declare that they are the sole authors of this thesis and that they have not used any sources other than those listed in the bibliography and identified as references. They further declare that they have not submitted this thesis at any other institution to obtain a degree.
Contact Information:
Authors:
Linus Elwing-Malmfelt
E-mail: lima13@student.bth.se Oscar Keresztes
E-mail: oske15@student.bth.se
University advisor:
Associate Professor (Docent) in Computer Science. Martin Boldt Department of Computer Science
Faculty of Computing Internet : www.bth.se
Blekinge Institute of Technology Phone : +46 455 38 50 00 SE–371 79 Karlskrona, Sweden Fax : +46 455 38 50 57
Abstract
Background. Conducting risk assessments is a vital part of securing information systems. The task of conducting risk assessments is a time-consuming and costly task for organizations. Thus different security control frameworks have been created to assist in the process. These security control frameworks consists of information about what the organization is supposed to implement to achieve a level of security in their information system. To understand what network hardening solution to use and in what part of the system, an analyst needs to manually use the implementation details gathered from the framework. A security control can be split into different security tiers depending on the amount of security the implementation achieves. The security tiers are defined by the authors of the security control framework. An orga- nization can reduce their cost and time spent on implementing the security by having a tool that parses the information system and creates guidelines based on security controls and parsed data.
Objectives. In this research, we will compare different security controls and based on the findings, investigate hardware, software and configurations that are being used when conducting network hardening. We will evaluate to which extent it is possible to generate guidelines that meet the given security tier, whether it is feasible to apply them and present a prototype that is able to generate guidelines.
Methods. The different security controls will be compared by analyzing the con- tents of each control in the frameworks. A comprehensive mapping will be created and based on the information gathered in the mapping, network-hardening imple- mentations will be investigated based on the devices in our experiment environment.
With implementations at hand, a tool will be proposed that parses information sys- tems and outputs guidelines that integrate the implementations in a readable format.
Experts within the field of system hardening then evaluate the created guidelines in terms of achieving defined security levels.
Results. For the comparison, a total of 148 different controls were identified to be related in some way. With 148 controls at hand, the prototype can output 111 dif- ferent guidelines with different security tier associations. According to the comments from the experts, the proposed guidelines were able to satisfy each security tier.
Conclusions. Our prototype displayed that we were able to create guidelines that can meet a given security tier. Although the implementation of each guideline is not automated, identifying what network-hardening implementation should be used is done in an automated fashion and thus allowing organizations to put their spending and time into other organizational interests.
Keywords: Network-hardening, security control framework, guideline generation
i
Sammanfattning
Bakgrund. Att utföra riskbedömningar är en nödvändig process när ett informations- system ska säkras. Uppgiften med att utföra riskbedömningar är för organisationer en tidskrävande och dyr process. Därför har olika ramverk för säkerhetskontroller tagits fram för att underlätta denna uppgift. Dessa ramverk innehåller informa- tion över vad en organisation behöver implementera för att erhålla en specifik nivå av säkerhet i deras informations-system. Den här säkerhetsnivån varierar beroende på hur mycket säkerhet en implementation tillför. De olika nivåerna definieras av ramverksförfattarna. För att förstå vilka nätverkshärdningar organisationen ska an- vända samt för vilken del i systemet dessa härdningar ska appliceras, behöver en analytiker manuellt gå igenom implementerings-lösningar i ramverken tillsammans med systemet och på så vis ta fram korrekt härdningsåtgärd för en specifik del i systemet.
Syfte. Syftet med arbetet är att jämföra olika säkerhetskontroller och baserat på resultatet undersöka hur hårdvara, mjukvara och konfigurationer kan användas för att härda nätverket. Vi kommer att utvärdera i vilken utsträckning det är möjligt att generera riktlinjer, huruvida det är möjligt att applicera riktlinjerna och ta fram en prototyp som kan generera riktlinjer.
Metod. De olika ramverken kommer att jämföras genom att innehållet i deras säk- erhetskontroller analyseras. En omfattande mappning kommer att tas fram baserat på analysen och utifrån mappningen kommer ytterliggare implementationer rörande nätverkshädrning analyseras. Med hjälp av implementationerna kommer ett verktyg att föreslås vilket analyserar ett informations-system och som producerar riktlinjer som integrerar implementationerna till ett läsbart format. Dessa riktlinjer undersöks sedan av experter gällande hur väl riktlinjerna uppnår definerade säkerhetsnivåer.
Resultat. Under arbetet identifierades totalt 148 olika säkerhets-kontroller som påvisade likhet med varandra. Med dessa 148 kontroller tillgodo klarade vår proto- typ av att producera 111 olika riktlinjer tillhörande olika säkerhetsnivåer beroende på systemet som matades in. Enligt kommentarerna ur granskningen som experterna utförde gick följande att konstatera: riktlinjerna som tas fram genom prototypen kunde upprätthålla varje säkerhetsnivå.
Slutsatser. Vår prototyp påvisade att det var möjligt att skapa riktlinjer som up- pnår en efterfrågad säkerhetsnivå. Även om implementering för varje producerad riktlinje inte är automatiserad så kunde vår prototyp automatisera processen av att avgöra vilken nätverks-härdnings implementation som skulle användas för var riktlinje. Detta tillåter organisationer att lägga mer tid och investeringar i andra organisatoriska intressen.
Nyckelord: Nätverkshärdning, säkerhetsramverk, generering av riktlinjer iii
Acknowledgments
We would like to thank our supervisor Dr. Martin Boldt for supporting and provid- ing us with important feedback throughout the course of the thesis. Additionally, we would like to thank our external supervisor Martin Lang of Combitech for his experience and engagement, as well as providing us with resources within the orga- nization.
v
Contents
Abstract i
Sammanfattning iii
Acknowledgments v
1 Introduction 1
1.1 Aim and Objectives . . . . 2
1.2 Research Questions . . . . 3
1.3 Scope . . . . 3
1.4 Thesis Outline . . . . 3
2 Background 5 2.1 Security Frameworks . . . . 5
2.2 Security Requirements for IT Systems . . . . 6
2.3 Access Control . . . . 8
2.3.1 Authentication regarding subjects (SFBK_AUT) . . . . 8
2.3.2 Controls regarding access rights for subjects (SFBK_ÅTK) . . 9
2.3.3 Access control administration security (SFBK_ADM) . . . . . 9
2.4 Security Logging . . . . 9
2.4.1 Registration of security-related events (SFSL_REG) . . . . . 9
2.4.2 Protection regarding modification and destruction (SFSL_SKY) . . . 10
2.4.3 Analysis of security logs (SFSL_ANA) . . . 10
2.5 Intrusion Protection . . . 10
2.5.1 Hardening of system components (SFIS_HRD) . . . 10
2.5.2 Communication protection (SFIS_INT) . . . 11
2.6 Intrusion Detection . . . 11
2.6.1 Information gathering from relevant data sources (SFID_DAT) . . . 11
2.6.2 Detection of intrusion and misuse (SFID_ANA) . . . 11
2.7 Protection Against Malware . . . 12
2.7.1 Management of security updates (SFSK_UPD) . . . 12
2.7.2 Integrity check of software and configuration (SFSK_RIK) . . . 12
2.7.3 Controls regarding executables (SFSK_EXE) . . . 13 vii
3.2 Network Hardening . . . 17
4 Method 19 4.1 Literature Review . . . 19
4.2 Experiment . . . 19
4.2.1 Experiment Setup . . . 19
5 Prototype Implementation 23 5.1 Guideline Generation Tool . . . 23
5.2 System Representations . . . 23
5.3 Guidelines . . . 25
5.3.1 KSF Translations . . . 25
5.3.2 Guideline Structure . . . 26
5.3.3 Content Through Feedback . . . 28
5.3.4 Guideline Output . . . 28
5.4 Evaluation . . . 28
5.4.1 Revised Evaluation . . . 30
6 Results 31 6.1 Security Framework Comparison . . . 31
6.2 Feasibility of Applying the Generated Guidelines . . . 33
6.2.1 Applying Generated Guidelines . . . 33
6.2.2 Scalability . . . 33
6.3 Expert Opinion . . . 34
7 Discussion 37 7.1 Research Question 1 . . . 37
7.2 Research Question 2 . . . 40
7.3 Return of Investment . . . 40
7.4 Risks of Using the Prototype . . . 41
7.5 Limitations . . . 41
7.6 Sustainability Impact . . . 42
7.7 Validity Threats . . . 42
8 Conclusions and Future Work 45 8.1 Conclusion . . . 45
8.2 Future Work . . . 46
A Prototype output 53
viii
Chapter 1
Introduction
Over the past decades, computers have become standard instruments to amuse us in our everyday life and aid while working. Since the end of the last millennium, the march of the Internet has been rampant and today, there are more connected devices around the world than ever before and the numbers are continuously increasing [16].
To this end, terms such as cybercrime and IT security are commonplace words in our vocabulary. In contrast, a hijacked personal online account can range from annoying to severely problematic. For a large organization or a state, any information leakage could spell something much more severe. Due to this fact, organizations need to pay more attention than ever to the security around their systems and devices [9]. There- fore, one can conclude that protecting information is as important today as it has even been. However, as each device may differ, gathering knowledge concerning how to secure said devices is an exhaustive and manual task and even more so, actually securing the system.
As previously mentioned, the task of securing systems is exhaustive. Therefore, several methods and frameworks have been developed throughout the years to assist organizations in developing and creating secure systems. Conducting such a task is often referred to as risk assessment or risk analysis. The structure of conducting a risk assessment can often be split into several parts, such as identifying the scope of the assessment, identifying descriptive sources of threats, vulnerabilities and impact information and identifying likelihood determination factors [26]. Albeit the exis- tence of multiple frameworks to assist in securing systems, it still consumes much organizational time to conduct these assessments. According to the IT-security con- sultant firm URM, they claim that it takes between six to nine months to complete an assessment for a small firm and between nine to eighteen for a large company [35].
The Swedish Armed Forces (SwAF) has created its framework to manage and prevent the risks found during a risk assessment called KSF. The KSF document contains a list of requirements that contains security controls that are needed to be fulfilled by the system to ensure that the risks are reduced or even eliminated. These require- ments are divided into three different security tiers Basic, Extended and High. Each tier corresponds to a set of predefined components to ensure that every device in a system fulfills the criteria for being placed in the correct tier. To be able to use this process, it requires a thorough understanding of the structure of a system and the devices used inside of it. This means that an analyst is required to consider how to implement the KSF controls regarding a single device in the system and how to
1
implement the KSF controls regarding how the entire system is operating [14]. The human factor involved when implementing these security controls is a factor that plays a significant role in the development of computer and information security vul- nerabilities, according to a study performed by S. Kraemer et al. [23].
With that being said, applying the KSF for systems today is both time-consuming and the erroneous human factor is involved in this process. This thesis aims to explore how security controls can be implemented in an automated fashion that ex- cludes the human factor while still providing a sufficient level of security for both an entire system and for each device specified in this system. A prototype is presented that outputs information regarding the security implementations and the information is evaluated whether it is feasible.
1.1 Aim and Objectives
This thesis aims to implement and evaluate to which extent it is possible to automate the process of conducting network hardening in a system based upon a set of pre- defined levels of security and the system’s structure. To implement the automation based on the evaluation and providing automated guidelines to the extent to which the automation of the network hardening process does not fulfill. This aim is to try to fill the research gap identified from existing research in Chapter 3. The aim can then be broken down into the following objectives:
• To conduct a literature review about network hardening in security frame- works, the security frameworks themselves and, if existing, whether automated processes are being used to conduct the network-hardening.
• A comparison of different security controls between different security frame- works and based on the findings investigating hardware, software and software configurations used together with the controls to conduct network hardening.
• Based upon the findings, to evaluate to which extent it is possible to automate the hardening process and the generation of guidelines.
• To evaluate whether it is feasible to apply the generated guidelines.
• To present a prototype that can generate guidelines based upon the results from the earlier objectives.
• To evaluate how effective the generated guidelines are compared to an expert opinion regarding achieving defined security levels.
1.2. Research Questions 3
1.2 Research Questions
The aim and objectives of this thesis can be answered through the following research questions:
RQ1: To what extent is it possible to use computer systems’ network topology, hard- ware and software specifications in order to create computer security guidelines that meet the given security tier?
To form a specific set of guidelines, it is necessary to learn how information from system devices can be utilized for this purpose. To ensure that the guidelines also provide some security, the devices have to be evaluated regarding how security solu- tions can be implemented for the devices.
RQ2: To what extent is it possible to automate the process of applying the guidelines from RQ1?
For the guideline to be as efficient as possible and remove the human factor when implementing the guidelines in a system, it is of utmost interest to evaluate if the guidelines can be applied in an automated way.
1.3 Scope
Our initial scope was to mainly look at a single operative system: Windows, and two pieces of hardware: switches and routers. We ended up also looking at Linux to some degree. Out of the three security tiers present in the KSF document, basic, extended and high, we have decided to only include basic and extended. The rea- soning behind this is firstly due the sheer number of requirements could have been overwhelming. The second reason, which was the deciding factor, was that the high security tier is only prevalent in very few and specific environments which does not reflect on regular organizational networks. In order to keep the focus on networks which properly represents organizational networks, the high security tier had to be excluded. Another component to our initial scope was to research the KSF, and how the processes in KSF could be automated. This is mainly because companies in the industry uses KSF in their processes and thereby were interested in methods that could save their analysts time when conducting work using the KSF framework.
1.4 Thesis Outline
The rest of the thesis will follow this structure:
• Chapter 2 introduces the reader to the research area by explaining all relevant theory.
• Chapter 3 presents previous work that has been done in the research area.
• Chapter 4 explains the method, experiment details and how the literature review was conducted.
• Chapter 5 gives an overview of how the prototype was implemented.
• Chapter 6 presents the result of the experiment.
• Chapter 7 further analyzes and discusses the result, addresses the threats to validity and answers the research questions.
• Chapter 8 concludes the thesis and discusses possible future work.
Chapter 2
Background
This chapter provides a description of the relevant concepts used in the thesis.
2.1 Security Frameworks
To mitigate or limit any leakage of sensitive information, several security standards, frameworks and controls have been developed over the years. Among these are the ISO/IEC 27000 family, NIST Special Publication 800-53 and CIS Controls 7.1. The ISO/IEC 27000 family consists of a dozen standards developed by the International Organization for Standardization (ISO) and the International Electrotechnical Com- mission (IEC). In particular, ISO/IEC 27001, a well-accepted standard [25], is a set of requirements designed to establish, implement and maintain an information secu- rity management system (ISMS). However, studies have shown that the standard has failed to gain the expected traction in adoption rate since its release over a decade ago. In an ISO survey done in 2017, less than 40.000 valid ISO/IEC 27001 certificates were distributed, compared to ISO 9001 and ISO 14001, where ISO had issued over a million and respectively, approximately 360.000 certificates 2017.
On the other hand, the CIS Controls is a set of prioritized actions [4] developed by the Center for Internet Security. The actions are designed to form an in-depth defence against common attacks on networks and systems. However, the CIS Con- trols have been under some scrutiny [17]. In the paper, Groš argues that the controls lack proper evaluation and claims that arguments for CIS controls are made by re- ferring to the high-profile organizations which helped develop the said controls. He argues that proper technology should be based on how it was done, not who it was done by and states that more transparency is needed.
On the other hand, NIST Special Publication 800-53, developed by the National Institute of Standards and Technology, is a well-regarded publication of security controls for organizations and federal agencies [24]. The publication had its initial release in February 2005 and has since then been revised five times. The publication consists of 20 controls, each with a set of subcontrols of sorts. Each control is paired with a discussion and references to more specific NIST documentation regarding the implementation of the specific control.
5
2.2 Security Requirements for IT Systems
With that being said, by working with the mentioned controls, it is relatively easy to spot similarities between them. Rather than the difference in content, it is more com- monly a difference in the quality of the content and implementation details. Mapping between other security frameworks has been made before [34], where similar controls between various frameworks have been mapped together, and this observation is of specific interest. The Swedish Armed Forces (SwAF) has its requirements docu- mented in the publication Security requirements for IT systems (Swedish: Krav på IT-säkerhetsförmågor hos IT-system) [14]. This publication will be denoted as KSF for the remainder of the report. In contrast to the frameworks and publications ear- lier, the requirements described in KSF are split into two distinct categories: SA for security assurance and SF for security functions. The security assurance category is divided into seven classes. Each of these classes targets a specific domain to gain con- fidence that the implemented security functions fulfil the requirements specified in KSF. These seven classes are further divided into a set of requirements, which holds a set of components. Each component describes how to fulfil the requirement. One example of a class is Säkerhetsloggning (SL). This class provides requirements that solves security issues regarding logs in a system. The SL class is composed of four requirements: Registering av händelser (REG), individuellt ansvar (OAV), Säker- hetsloggsförvanskning (SKY), and Analysering (ANA). These requirements aim to provide even further requirement-specific components and an example for how the structure is defined in KSF can be seen in Figure 2.1. In total, there are 275 security assurance requirements described in KSF. Similar to the security assurances, secu- rity functions are divided identically, with a total of 8 classes and 148 requirements spanning these classes.
Category Class Requirement Component
SF SL SKY 1
Events registered in the security log may not be modified.
Figure 2.1: Requirement SFSL_SKY.1 from KSF
There are a couple of aspects that differentiate the requirements defined in KSF from controls in earlier frameworks. Firstly, the requirements are as general as possible to be realizable for any system or system component but formal enough not to be misinterpreted. There are generally no discussions or implementation references in consort with the requirement. Different systems or individual components may need different approaches to reach the desired result, and the result should be objectively verifiable. Secondly, each component in a system or a system as a whole is assigned a security tier. These tiers are derived from two specific factors: consequence level and exposure level. There are five consequence levels, ranging from negligible to extremely severe. The system or component of the system will be assigned a level corresponding to what type of sensitive information it will handle and the severity
2.2. Security Requirements for IT Systems 7 of potential leakage.
Similarly, there are four exposure levels named E1-E4. Each exposure level depends on two factors: the systems physical exposure to people who are not intended users of the system and exposure to other systems through exchanging information. This exposure can include both exchanges through wires as well as through storage media.
By conducting a risk assessment of the system or a system component, it is possible to apply a consequence and exposure level. Three different security tiers are defined inside KSF. They are defined as basic, extended and high. Based on the assigned levels, the system is given its security tier. Figure 2.2 shows how the security tiers correspond to the combinations of exposure and consequence levels.
EXP 4 EXP 3 EXP 2 EXP 1
CON 5 High High High High
CON 4 Extended High High High
CON 3 Extended Extended Extended High CON 2 Basic Extended Extended Extended
CON 1 Basic Basic Basic Basic
Figure 2.2: Security tiers based on consequence and exposure level
The KSF requirements are applied to the operational environment once the risk assessment is done, and the system has been assigned a security tier. Continuing with the previous example of the KSF requirement SFSL_SKY, we can see that the requirements of the class are divided into specific tiers in Figure 2.3, corresponding to the security tiers of the system at hand. In this figure it is possible to observe that to fulfill the basic security tier the three first components needs to be implemented.
For a system or a device to achieve the extended or high security it is required to implement all of the components for the SFSL_SKY requirement. With that being said, in order to reach the high or extended security tier, one would necessarily not need to implement requirements from the basic security tier, as a requirement from a higher tier may fulfil one from a basic tier in addition to cover a wider area of security, unless anything else is specified. In this example, one would need to implement all requirements for the extended and high security tier, but that is not the case in all categories. The distribution between the security tiers is not based on following a pattern.
SFSL_SKY 1 2 3 4 5 6 7
Basic x x x
Extended x x x x x x x
High x x x x x x x
Figure 2.3: Distribution of requirements between the security tiers
1 Events registered in the security log may not be modified.
...
5 A reserved space for storage should be present in the system.
Figure 2.4: Extract of requirements from KSF class SFSL_SKY
Figure 2.4 presents two of seven components that corresponds to the KSF class SFSL_SKY. All components for requirements throughout the KSF are defined as shown in the figure. The philosophy behind the descriptions are that they should provide general descriptions that can be fulfilled for any system or system component.
Depending on the security tier of the system, each requirement corresponding to that tier will be applied to all relevant components of the system. Out of the 23 available classes, 14 classes are of particular interest in this thesis, each of these classes has, as previously mentioned, a set of components for each security tier. The basic and extended security tier is the primary focus here. They are presented in the sections below, and the content is based on the KSF document [14].
2.3 Access Control
Access controls are used to enforce subjects, an entity in an IT system that can act, e.g. a user or a computer. Should only be able to access the system or information in the system, the subjects have allowance to access. The access control consists of parts such as identification, authorization and authentication [38].
2.3.1 Authentication regarding subjects (SFBK_AUT)
This requirement consists of 20 different components regarding the authentication of subjects. This authentication process should make it possible for the system to authenticate subjects with enough reliability for access controls and security logging of the subject’s actions in the system with its correct identity. 13 of the components corresponds to the basic security tier, 17 to extended and 19 to the high tier.
2.4. Security Logging 9
2.3.2 Controls regarding access rights for subjects (SFBK_ÅTK)
This requirement covers a total of seven different components concerning access for subjects. The access requirement prevents unauthorized access to information by controlling one subject access to objects and permitting them to perform actions that they have been assigned. An object is something that a subject can operate on, e.g. access information, functionality or access to a database. Four components are set to fulfill the basic security tier, six to fulfill extended and all seven for high.
The components of this requirement consist of information regarding that a unique identity should be used when giving access to objects, only subjects with proper access rights should be given access to objects, administration functionalities should only be provided after authorization and role-based access control (RBAC) should be available.
2.3.3 Access control administration security (SFBK_ADM)
The requirement SFBK_ADM responds to that administrative controls for access control should be conducted securely. A total of six components is contained in this requirement. The secure way is to provide the necessary administration of the security functions while also not providing possibilities to circumvent the access control, neither should the administration occur in a way that hinders the means of tracking the activity of a subject in the system. One component corresponds to the basic tier, three for extended and five for high. For the requirement to achieve these different security tiers, the components present the following requirements. It should be able to change access rights to objects, separate of administrative functionalities such as accessing security logs, daily administration and assignment of access rights by using access control and the existence of a role in the system that has access to all objects in the system should be removed.
2.4 Security Logging
To be able to trace and detect malicious activity, it is necessary to configure a system to register all security-related events in the system. The possibility of analyzing logs is an essential function necessary for following events through the whole system. As stated in the paper by J. Dwyer and T.M. Truta [13], having security logs provides the ability to detect anomalies inside a system.
2.4.1 Registration of security-related events (SFSL_REG)
This requirement handles the registering of security-related events. Six components are responsible for satisfying this requirement. Four cover the basic security tier, five for extended and all six to achieve the high-security tier. To be able to use security logs for tracking, it is required that all security-relevant events should be registered in the security logs. The date and time should be registered in each event.
A subject’s unique identity should be registered. The events should cover at least authentications, new identities and roles, changes in the subject’s security attributes and denial of access to objects.
2.4.2 Protection regarding modification and destruction (SFSL_SKY)
The means of protecting the security from modification or destruction are the topics covered in this requirement. The requirement is constructed of seven different com- ponents, three covering basic security, while all seven of them needs to be fulfilled to achieve extended and high-security tiers. The goal for the components of this require- ment is to protect against deliberate or accidental modification, loss or destruction of the security logs. It is necessary to provide functions that ensure that the security logs have not been tampered with, sufficient disk space should be available for storing logs, and they should be backed up. To achieve higher tiers of security, it should also exist functions that store security logs separately from operation logs. A dedicated area for storage should be available in the system and disk redundancy should be implemented to ensure that registered events cannot be deleted or overwritten if the security logs are full.
2.4.3 Analysis of security logs (SFSL_ANA)
This requirement covers how the security logs shall be analyzed to detect any in- trusion and misuse. To perform an analysis on the security logs, they need to be available for review. The functionality of this requirement is to provide the system with a tool that can correlate events in logs. It should also be possible to perform analysis inside the environment or in an external environment. Therefore the possi- bility shall exist to export portions of the logs or all logs completely. The requirement is covered through eleven components, eight that suffice the basic security tier and eleven for both extended and high.
2.5 Intrusion Protection
Intrusion protection involves the process of applying authorized communications, denying unauthorized communication through the use of external perimeter protec- tion, protection of communications inside the system, and protection of information flow.
2.5.1 Hardening of system components (SFIS_HRD)
System hardening is provided for the system through this requirement. The require- ment provides security by minimizing the risk that an attack leads to a complete intrusion. The system’s different parts must be configured so that the attack surface they expose is minimized and so that the usage of vulnerabilities is prevented. The requirement compromises seven components: two covers the basic security tier, four extended and all seven to achieve the high-security tier. To be able to fulfill the basic requirements, a system needs to have all functions that do not support its primary purpose turned off. One method to satisfy this component is to apply white-listing solutions to specify what files and software can execute in the system [32]. For a system to also reach the extended and high-security tiers, it must both fulfill the
2.6. Intrusion Detection 11 component regarding removal of security-sensitive functions that constitute an avail- able attack surface, and all software services shall be isolated from each other and the rest of the system.
2.5.2 Communication protection (SFIS_INT)
SFIS_INT is a requirement used to establish protection for the communication against unauthorized access and manipulation. It can be more precise in order to hamper an attacker’s access to communication between distributed components in the system. The communication shall be protected so that the sender is verified, and a third party cannot modify the information that is sent. The components of this requirement can be solved by using different types of encryption to protect the communication between distributed components. Transport Layer Security (TLS) [29] is one such example, and another one is Internet Protocol Security (IPsec) [11].
2.6 Intrusion Detection
This protection consists of security functions that can detect and warn of unau- thorized communication and changes in data. The intrusion detection can use the created security logs to perform signature-based, anomaly-based or reputation-based evaluations. A common method to execute this detection is through a tool that is placed strategic inside a system, often placed at the edge of the network and on end devices. [40]
2.6.1 Information gathering from relevant data sources (SFID_DAT)
Ten different components are presented in the SFID_DAT requirement. They aim to solve the need of having information from relevant data sources available for analysis. This information is used to detect and warn for intrusion and intrusion attempts. Event data needs to be continuously collected by the system. The infor- mation from this requirement’s components can be summarized into: Different types of information should be collected in the system, security logs, traffic data from rele- vant communications, operation logs, application events. The records should include the date, time and if the record is from a subject-related event, it should include its unique identity. For a system to achieve an extended or high-security tier, it is also required for the system to transfer the gathered records to a central analysis and detection system.
2.6.2 Detection of intrusion and misuse (SFID_ANA)
The 14 components available in this requirement aim to solve the need to detect and trace intrusion and misuse. By having all information about events in the system and analyzing them, conclusions can be drawn from correlations between different sources. Analyzing events opens up the possibility of detecting ongoing and already performed intrusions and intrusion attempts. The basic tier of security is achieved
through eight components, extended through 13 and high through all components.
The components of this requirement cover how the log analysis tool should be con- figured so that it is possible to detect different attack patterns, sort and present the data it produces, and anomaly behaviour in user patterns should be detectable.
2.7 Protection Against Malware
Malware refers to a type of computer program designed to infect a legitimate user’s computer and inflict harm on it. The malware can manifest in different forms, such as worms, viruses, trojans, and more. Safeguard measures are needed, both in the perimeter and inside the system, since threats from malware vary between different systems. [20]
2.7.1 Management of security updates (SFSK_UPD)
This requirement serves the purpose of providing components regarding functions for the management of security updates. The components provide an effective way of fixing known security flaws in the system. Functions that inform and support this process shall exist. It is five components that are available to solve the issue. Three of them are used to achieve basic security, four to achieve extended, and four to achieve high security. The main difference between the content of the components is that for a basic tier, the system should be able to report exact versions for all components and software. However, for an extended tier, the system shall compare the installed software with actual versions from the supplier when an authorized administrator requires it. At last, for the system to comply with the high tier, automated controls must exist that ensure all installed software conforms to the actual versions provided by the supplier.
2.7.2 Integrity check of software and configuration (SFSK_RIK)
The SFSK_RIK requirement is responsible for covering the data integrity of soft- ware and configurations. To be able to ensure the system’s integrity and that its functions work as intended, controls shall be made possible to detect unapproved modifications of software or configurations. This requirement contains only four components where two needs to be satisfied to achieve the basic tier of security, three for extended and all four to achieve the high-security tier. The difference be- tween how the components strive to achieve security tiers is by requiring different tiers of integrity validations. The extended and high components require controls to perform automatic verification of software files and configurations. The high tier also requires the verification to occur every time the object is being used or at least every time objects are read from the storage medium, i.e. USB-device or hard-drive.
2.7. Protection Against Malware 13
2.7.3 Controls regarding executables (SFSK_EXE)
This requirement consists of seven different components regarding approved soft- ware’s that can execute in the system. To prevent manipulation of the system’s software components and their functions through malware usage, objects with po- tential executable contents shall be controlled. The basic and extended security tiers are achieved by fulfilling six components while all seven is needed to reach a high security tier. It is possible to summarize the contents of the components to pro- vide the system with anti-malware functionality. Antiviruses and operative-system antiexploitation features are a means to protect devices against malware [39]. It should also be possible for these anti-malware functions to be updated regularly to ensure that they can stop the latest malware from executing. The components also specify that objects should be controlled before they are accepted to be used, and one example of this is the use of USB-devices. In contrast the company might only be accepting one type, and thus the system should only accept these types of USB- devices.
Security Class Summary
SFBK_AUT Authentication of subjects
SFBK_ÅTK Authorization of subjects
SFBK_ADM Security regarding administration of access control
SFSL_REG Logging applicability
SFSL_SKY Protection of security logs
SFSL_ANA Analysis of security logs
SFIS_HRD Hardening of system componenets
SFIS_INT Protection against unauthorized access and manipulation SFID_DAT Processes for making information available for analysis SFID_ANA Functions for detecting and tracing intrusion and misuse SFSK_UPD Functions for management of security updates
SFSK_RIK Checks for data integrity of software and configurations
SFSK_EXE Software approval
Figure 2.5: A brief summary of the classes covered by this chapter
In conclusion, implementing every requirement in the KSF to reach an acceptable risk level for an extensive system is a time-consuming affair. Primarily when the complexity increases and different components handle varying levels of sensitive in- formation or use different types of software. The process of securing large systems is tedious and prone to error. Every step towards aiding professionals in understand- ing and implementing security requirements is necessary. One said step could be
achieved by taking general requirement descriptions and boiling them down to more concrete actions.
Chapter 3
Related Work
This chapter will explain the related works that were identified during the literature review. The related works chapter has been divided into two sections. The first will cover different methods in how security frameworks have been studied and im- plemented in various systems. It will also cover how related security controls in a framework have been used to create different solutions. The second section is going to explain different methods being used to harden active computer systems.
3.1 Security Frameworks
The different security frameworks that are considered as standards and best practice today are similar. These characterizations can overlap between the frameworks. The paper written by D. Sulistyowati et al. [34] analyzes and compare a set of the most common security frameworks available. They compare the differences between NIST, ISO, COBIT [10] and PCI DSS [12]. By evaluating the meaning and content of each security control (characterization) inside each framework, the study can create a ta- ble that lists all of the controls used within the different frameworks. The interesting conclusion of the study is that NIST contain 33.33% of controls that are not related to another framework. All framework contains 28.57% of similar controls. PCI DSS and NIST contains 4.76%, NIST and COBIT 9.52%, and lastly, PCI DSS, ISO and COBIT have 23.81% similar controls.
One of the security frameworks gained focus in Information Systems (IS) research is ISO 27001. In the study conducted by G. Culot et al. [8] a systematic literature review over other works that have been using the ISO 27001 in their topics. By reviewing works over 15 years, the authors are able to identify the main themes and result in 96 different works. The work presents the results in a list with 5 points.
One interesting conclusion for this work is the third point which says that implemen- tation of the framework entails several challenges due to the design of the framework guidelines. Another conclusion of this study is that different standards, frameworks and not-standardized practices may be integrated with the standard.
In the research done by Kiesling et al. [22], the authors discuss how annual informa- tion security spending has risen sharply and that ensuring the security of business- critical systems has become a key management concern. They emphasize that it is a struggling task for a security expert to justify investments in terms that senior man- agers can relate. Therefore, the security experts must create a portfolio of security
15
controls of practical relevance for the organization. The information infrastructure, the exposed threats in such a portfolio, differs between organizations because different organizations have different risk preferences. Based on these statements, the authors researched how security under varying conditions can be assessed and how infrastruc- ture design can be optimized in terms of specific threats, how decision-makers can find the best compromise between costs, risks and benefits of security investments and how a tool-supported security decision process can assist when choosing investments.
Their vision of the method aims to provide an integrated framework for analyzing security issues and facilitating communication between senior management and se- curity professional. The framework was created by combining a knowledge-driven approach with a simulation-optimization architecture. It is necessary to establish a comprehensive knowledge base (KB) to perform a knowledge-driven approach. This KB was divided into one security KB and a system KB. The conclusion based upon using this method was that it was a promising approach, the importance of present- ing the results in a format suitable for the target audience and that building such a comprehensive KB is time-consuming and requires considerable expert knowledge.
The authors conclude their research by stating that their approach necessitates a more collaborative model for security decision making, which means that to be able to implement this approach, a shared understanding of security issues and threats will foster more vital management involvement in security decision making.
The article written by S. Bettaieb et al. [2] discusses the difficulties and impor- tance of the security requirement elaboration task of going through many security controls to determine which one to implement. The authors propose a solution to identifying relevant security controls for specific systems, and machine learning is the suggested approach. The approach leverages data from security assessments over dif- ferent systems in order to recommend controls for the new system. The data gained to conduct the research was from a year-long study at an international central bank.
The data included 320 assessment projects conducted over ten years. Sixty-five were excluded, and 255 used for evaluating the approach. The approach was evaluated through surveys about the usefulness of the suggested controls. Based on the results from the surveys, the conclusions were that using machine learning for assisting an- alysts with the task of deciding security controls would reduce the likelihood that essential controls would be missed. It may have the potential to become a vital prerequisite for the proper elaboration of security requirements in the early stages of development. However, Machine Learning alone is not sufficient in decision making.
By exploring the gathered related works regarding security frameworks, it was pos- sible to conclude that no earlier research regarding the KSF requirements has been conducted. In more specific terms, comparison between security control frameworks has been a research topic as explained by D. Sulistyowati et al. [34]. Methods have been proposed to define implementations based on security controls [2, 22]. Neither of these has had specific controls from KSF in consideration, nor have they proposed any security implementation regarding specific devices.
3.2. Network Hardening 17
3.2 Network Hardening
Only a few studies have automatically assessed an enterprise environment and de- termined mitigations against posing vulnerabilities in an environment. D. Borbor et al. [3] studies how different hardening options can be combined into a heteroge- neous approach to deal with unknown and unpatchable vulnerabilities in a system.
The proposed hardening processes include adding new resources, removing existing resources, relocating resources, changing firewall or access rules and changing ser- vice types through device diversification. Two types of optimization algorithms were used to create a solution: Exact algorithms and meta-heuristic approaches. The conclusion was that the authors could provide a new tool that can further harden a system. The provided solution was validated through simulations which showed that the produced systems had a higher level of security. It should be noted that the proposed method can only work in an environment that is relying on a static network configuration.
It also exists different methods that try to solve similar problems. S. Saha et al.
[31] investigates efficient security control methods for protecting vulnerabilities in networked systems. Attack graphs are used to study the problems, and algorithms are developed with provable approximation guarantees. The researchers conclude that more than half of the leaves in the graph need to be secured to bring the de- fender’s potential damage by half. The potential damage decreases rapidly for a slight increase in hardened leaves. In the conclusion of this research, the authors prove that as the connectivity increases, attack graphs become more challenging to harden. They also insist that their techniques benefit system planners to study trade-offs between hardening cost and potential damage, thereby identifying the most critical nodes.
By reviewing related works in the paragraphs above, it was possible to note that no studies were found regarding choosing a network hardening solution based on a security control for a defined system device. It was also found that no thorough research had been conducted where the proposed hardening solutions have been au- tomatically applied to the system.
Chapter 4
Method
This chapter explains the methodologies that lay the foundation for how the research and experiment were conducted and implemented. To be able to address the research questions, a literature review of network hardening techniques and security frame- works was conducted, followed by an experiment based on the information gathered from this review.
4.1 Literature Review
In order to obtain an understanding of the current research within the field and to be able to answer the research questions, it was necessary to find related works. By having related work at hand, it was possible to make certain decisions for the im- plementation, and it gave this thesis a different point of view of how the researchers solved their issues. A set of keywords were used when scientific databases were queried to find related works. The search engine that was used to query the scientific databases was BTH Summon. When querying, a selection of keywords was Network hardening, Attack-Graphs, Automated hardening, System hardening, Network topol- ogy, Security Frameworks, NIST, CIS, ISO, NIST Implementation. The results were then evaluated based on their title, abstract and conclusions. After evaluation, the research was either considered relevant or not relevant. In the case of a relevant pa- per, it was used as a subject for the Snowballing methodology [42, pp. 45-51]. The papers that were gathered with the snowballing approach was evaluated by the same criterion as mentioned earlier. The papers gathered during the literature review have been used throughout the thesis.
4.2 Experiment
This section describes the experiment setup, the necessary decisions made to ensure that the hardening processes are considered secure, and the implemented functional- ities necessary to create the guidelines for the given system information and security tier.
4.2.1 Experiment Setup
To be able to verify that the implementation outputs guidelines are considered secure, an environment where the guidelines could be applied is necessary. In collaboration
19
with Combitech [7], a network topology was crafted, which was used throughout the thesis and can be seen in figure 4.1. The network topology simulates how a small business might build its network in an office environment. This network was also used in a physical environment to test the feasibility to apply the guidelines. A created guideline was implemented manually and accepted as feasible if the guideline was in line with what action was taken in the device. If an action was taken that was not specified in the guideline, e.g. Utilize a white-list application in the device, and the action in the device was to configure the specific application called AppArmor. Then the original guideline was changed according to the action.
Figure 4.1: The network topology that was used to implement guidelines against.
In a more precise description, the system included the following devices:
• 1 domain containing 2 Windows PC set to the Extended security tier
• 1 domain containing 2 Windows PC set to the Basic security tier
• 1 Linux server set to the Basic security tier named "Internal File Storage"
• 1 Linux server set to the Extended security tier named "File Server"
• 3 Cisco switches (1 acting as a router)
• 1 Firewall
4.2. Experiment 21 By having these types of devices as input, the guidelines created ensures that they can handle multiple different types of devices in a system. Since the prototype in this thesis is such an important part of the method, the rest of the methods used in the experiment have been put together in Chapter 5 which explains in detail how the guidelines were generated and outputted, how an input was designed to represent the devices in a system, how the prototype was improved through the development phase and how the experiment was evaluated. An experiment was used opposed to a case study since using the KSF to harden a system is a closed process and also a process which may take substantial time for more complex systems. Due to the process taking a substantial time it was deemed as inpropriate since the thesis only spans for a couple of months. There is also a possibility that there were no systems being hardened at the time the research started, which would be yet another reason to not use a case study. Finally, as the conducted research tests the extent to which something could be developed and automated, it simply made more sense to do so in an experimental environment rather than trying to extract information from a case study and apply it under the course of the development.
The dependent variable throughout this thesis is the number of pages that the pro- totype generates and the number of unique and identical pages being generated.
The independent variables are the different network systems that have been changed during the experiment. The independent variables consist of five levels. The different levels are systems with 10, 20, 30, 40 and 50 nodes. It is not only the nodes that are changed through the iterations but also their underlying configuration.
Chapter 5
Prototype Implementation
To be able to answer the research questions, an experiment had to be conducted.
By reading the papers found during the literature review step in the thesis, an idea sprung to generate and evaluate a hardening solution, it was necessary to have an input that represents a system and an output that is easy to read and understand.
A tool was developed that takes a system as an input, parses the information and outputs a document containing guidelines for the provided system. Security experts evaluated the guidelines to ensure they provide the necessary hardening to achieve a given security level.
5.1 Guideline Generation Tool
To be able to create guidelines, three main components was necessary to have in place before a security expert could validate if the created guidelines achieve sufficient security for the provided system. These three components consisted of:
1. A way of representing one system so that crucial information in devices can be assessed.
2. Translations from generic KSF controls into device- or domain-specific imple- mentations that satisfy the generic control.
3. An output that is easily accessible, readable and provides users with imple- mentation details in a structured document.
The tool was designed to accept input in the form of a JSON object [19]. In a later iteration, the tool also accepted user input to create this JSON object that contained the system representation automatically. It was developed using Python 3.8 with the operating systems Ubuntu 20.04 and Mac OS 11.
5.2 System Representations
There is an inherent need to automatically read and parse the existing network to create hardening guidelines for an arbitrary network system automatically. In order to fulfill this need, a simple yet thorough structure was designed which describes a single network. The structure is stored in a JSON object and consists of two lists, where one is of end devices, e.g. computers or servers and the other of network
23
devices such as routers and switches. Each device type has distinct parameters, which can be seen in the figure below, where an example of an end device is shown.
Key information Values Sub values
ID PC-1
OS Windows
Type Personal computer
Device SW-1
Domain Workgroup A
Security level Extended
Logging Remote
Count 2
Applications
Name Microsoft Edge
Version 1
Port In 80, 443
Port Out 80, 443
Protocol HTTP, HTTPS
In-going White listed entities
Domain domains to whitelist
List of applications name of applications to whitelist Out-going White listed entities
Domain domains to whitelist
List of applications name of applications to whitelist
Figure 5.1: Structure of an end device in the input
Network devices are fairly similar to end devices, but with slightly fewer over all at- tributes. Network devices also provides insight how the devices are linked together, as network devices are not general purpose machines such as end devices usually are. The reasoning behind the chosen attributes are simple. We wanted to describe a component in a network in the easiest way possible while also ensuring that each attribute would be used to determine whether a guideline should be applied on the component or not. Certain attributes are also used to derive information from for certain guidelines, such as allowed protocols for firewall rules or paths to components or domains for access control lists.
The count field describes whether this device is a single device or multiple iden- tical devices which should serve the same purpose. The reasoning behind this field is to avoid unnecessary replication of devices in the input. This field may also be used to determine whether or not devices should be split into different VLANs, depending
