Secure Self-Reconfiguring
Services to Mitigate DoS
Attacks
SILVAN ZELLER
KTH ROYAL INSTITUTE OF TECHNOLOGY
Services to Mitigate DoS
Attacks
SILVAN ZELLER
Master in Electrical Engineering Date: September 22, 2019
Supervisor: Daniel Deogun / Omegapoint AB
Supervisor: Narges Khakpour / Linnaeus Universitet Examiner: Peter Sjödin / Kungliga Tekniska Högskolan School of Electrical Engineering and Computer Science Host company: Omegapoint AB
Abstract
Protecting web services from cyber attacks is a complex problem requiring many layers of defense and mitigation strategies. Out of the diverse range of attacks, denial of service (DoS) attacks on the business logic – or the domain – are poorly studied and no widely accepted general-purpose software product to prevent these attacks exists today. At the same time, in light of the grow-ing importance of e-commerce, defense mechanisms should be designed in a way to be self-reconfiguring, as manual reconfiguration does not scale well. In this work, a rule-based intrusion detection system (IDS) is proposed which logs the behaviour of each user and decides upon a service level based on past behaviour. The implementation is achieved by applying runtime verification (RV), a lightweight formal method which can be utilized to observe traces of user behaviour in real time. The applicability of this approach is measured by means of conducting experiments on a web service, a mock-up hotel chain which grants three different service levels for users based on their individual trust rating. Synthetic traces of bookings and cancellations are issued to ac-count for the detection rate of the IDS and the efficacy of its mitigation strategy. The results indicate that RV is a viable approach for creating a rule-based IDS. The IDS may be tuned to attain a high detection rate of more than 95% while preserving a low false positive rates of less than 3%. Furthermore, attacks are mitigated by changing the business rules for users who have been identified as being malicious, resulting in an increased occupancy of the hotel. Lastly, RV is shown to be significantly more scalable and expressive than regular formal methods, such as model checking. Even though the results seem promising, testing the system on real traces and possibly with varying thresholds remains future work.
Key Words:
Rule-Based IDS, Runtime Verification, Domain Attacks, Self-Reconfiguring Systems
Sammanfattning
Att skydda webbtjänster från cyberattacker är ett komplicerat problem som kräver många lager av försvars- och lindringsstrategier. Av det olika utbudet av attacker, denial of service attacker (DoS) på affärslogiken – eller domänen – undersöks sällan och ingen allmän accepterad mjukvara för att förhindra des-sa attacker finns idag. Samtidigt, mot bakgrund av den växande betydelsen av e-handel, bör förvarsmekanismer utformas för att vara självkonfigureran-de, eftersom manuell omkonfigurering inte är skalbart. I detta arbete föreslås ett regelbaserat intrusion detection system (IDS) som loggar varje användares beteende och beslutar om en servicenivå baserad på tidigare beteenden. Imple-menteringen uppnås genom att använda runtime verification (RV), en lättviktig formell metod som kan användas för att observera spår av användarbeteende i realtid. Tillämpningen av denna metod mäts med hjälp av experiment på en webbtjänst, en mock-up hotellkedja som ger tre olika servicenivåer för an-vändare baserat på deras individuella förtroendevärdering. Syntetiska spår av bokningar och avbokningar används för att redovisa IDS:s detektionsgrad och effektiviteten i dess lindringsstrategi. Resultaten indikerar att RV är ett genom-förbart tillvägagångssätt för att skapa ett regelbaserat IDS. Systemet kan vara inställt för att uppnå en hög detektionsgrad på mer än 95% och bevarar samti-digt en låg falsk positiv nivå på mindre än 3%. Dessutom mildras attackerna genom att ändra affärsreglerna för användare som har identifierats som skadli-ga, vilket resulterar i en ökad beläggning hos hotellet. Slutligen visas RV vara betydligt mer skalbar och uttrycksfull än vanliga formella metoder, till exem-pel model checking. Även om resultaten verkar lovande, återstår testning av systemet på riktiga spår och eventuellt med olika trösklar som framtida arbete.
1 Introduction 1
1.1 Background . . . 2
1.1.1 Domain Attacks . . . 3
1.1.2 Domain Driven Design and Security . . . 4
1.1.3 Secure Software Development . . . 4
1.2 Research Question . . . 5
1.2.1 A Motivating Example . . . 6
1.2.2 The Reservation-Cancellation Problem . . . 6
1.3 Purpose . . . 7 1.4 Goals . . . 7 1.5 Delimitations . . . 8 1.6 Structure . . . 8 2 Background 9 2.1 DoS Attacks . . . 10
2.2 Intrusion Detection Systems . . . 11
2.3 Formal Methods . . . 13 2.3.1 Automata Theory . . . 14 2.3.2 Timed Automata . . . 17 2.4 Model Checking . . . 18 2.4.1 Temporal Logic . . . 20 2.5 Runtime Verification . . . 20
2.5.1 Aspect Oriented Programming . . . 21
2.6 Self-Adaptive Systems . . . 22
2.7 Related Work . . . 24
2.7.1 Formal Methods . . . 24
2.7.2 Dynamic Monitoring . . . 26
3 Research Methodology 28
3.1 Research Process . . . 28
3.1.1 Model Checking . . . 29
3.1.2 Web Service and Runtime Verification . . . 29
3.2 Experimental Setup . . . 31
3.2.1 UPPAAL Model Checker . . . 31
3.2.2 Spring Framework . . . 32
3.2.3 Larva RV Framework . . . 32
3.2.4 Test Environment . . . 33
3.3 Data Collection Methods . . . 33
3.3.1 IDS Rule Verification . . . 33
3.3.2 IDS Benchmarking . . . 34 3.4 Evaluation . . . 35 3.5 Ethical Considerations . . . 36 3.5.1 Privacy Concerns . . . 36 3.5.2 Risks . . . 36 4 Implementation of a self-reconfiguring IDS 37 4.1 Rule Definition . . . 37 4.1.1 Domain Rules . . . 37
4.1.2 Rule Based IDS . . . 38
4.2 Static Property Verification . . . 39
4.3 Software Architecture of the Web Service . . . 42
4.3.1 Domain Objects and Repository . . . 42
4.3.2 Web Controller . . . 42 4.3.3 View Resolver . . . 43 4.4 Feedback Loop . . . 43 4.5 Web Client . . . 46 4.6 Experimental Design . . . 48 4.6.1 User Generation . . . 48 4.6.2 IDS Settings . . . 49 4.6.3 Benchmarks . . . 49
5 Results and Discussion 50 5.1 Static Verification . . . 50
5.1.1 State Explosion . . . 51
5.1.2 Expressiveness . . . 53
5.2.1 Experimental Setup . . . 53 5.2.2 Detection Rate . . . 56 5.2.3 False Positives . . . 57 5.2.4 Occupancy . . . 59 5.2.5 Runtime Overhead . . . 62 5.3 Discussion . . . 63
5.3.1 Model Checking of Web Applications . . . 63
5.3.2 Functionality of the RV Framework . . . 64
5.3.3 Attack Time Variation . . . 65
5.3.4 Finding Appropriate User Thresholds . . . 66
5.3.5 Business Rules in the Context of DDSec . . . 66
6 Conclusions 68 6.1 Limitations . . . 69
6.2 Future Work . . . 70
6.3 Reflections . . . 70
Introduction
With the evolution of the Internet and its growing importance on global econ-omy, attacks conducted through the Internet are continuously on the rise. At the time of its inception, computer networks were mainly a subject of research and security concerns were only considered half-heartedly. Lamentably, this is still the often the case in the software development process, as implement-ing new features is usually handled with a higher priority [1]. However, se-curity concerns of companies are growing due to the rising dependency on e-commerce.
Attacks on the domain, i.e. the business logic of a web service pose a distinct challenge to securing web applications: it is a type of attack which aims at exploiting business rules with a malicious intention. Domain attacks do not work on the premise that a large amount of bogus traffic is issued against a victim’s infrastructure or that harmful code is injected into the victim’s sys-tem. Instead, weaknesses in the domain are identified and exploited with the intent of disrupting services offered to legitimate users. A popular application which runs on this premise are auction sniper scripts for online auction plat-forms, which are designed to place the highest bid in the last possible moment of an auction. The behaviour of the malignant user in isolation may be per-fectly legal according to the business rules, but the attack poses a threat against the business model, as sellers might lose profit and might consider moving to-wards services which offer protection against such scripts.
There are many different kinds of domain attacks aimed at depriving benign users from attaining a good or a service by exploiting weaknesses in the busi-ness rules of a web service. Often, the attack may be carried out without the need for automation by e.g. utilizing a script, which is particularly hard to detect for a monitoring program. Detecting and issuing countermeasures in
an unintrusive fashion to prevent domain attacks pose the core of this thesis work.
In the following section, a brief overview on web security measures is given to establish the context of this work. Based on this knowledge, the research question is described in detail as well as the objectives of this work. The de-limitations and the structure of this thesis work conclude this chapter.
1.1
Background
Cyber security is a research field which is constantly evolving due to novel threats, enabled by the emergence of web applications. The first anti-virus software was written to detect malicious software on a victim’s machine in the 1980’s, in an era when the Internet had not been as ubiquitous as it is nowadays [1].
Installing harmful software on a victim’s device is only one of many facets of cyber attacks. Therefore, a large variety of protection mechanisms exist. Packet filters and stateful firewalls are employed to block specific IP addresses, ports, protocols and sessions. Situated above the transport layer, an applica-tion level gateway (ALG) or applicaapplica-tion proxy can further be implemented to filter application-specific packets. It may enforce security policies tailored for the requested service and thus tend to be more secure than a packet filter [2]. To detect suspicious patterns in how packets arrive, an intrusion detection sys-tem (IDS) may be implemented which might be combined with a deep packet inspection (DPI) mechanism to check for malicious code in the payload of the arriving IP packets [3].
Even though detection and prevention techniques of cyber attacks continue to evolve, cyber criminal activities are continuously on the rise and novel protec-tion methods are often developed as a reacprotec-tion to a new sort of attack.
According to Akamai [4], large scale denial of service (DoS) attacks are globally on the rise, specifically the distributed fashion of this type of attack (DDoS). DoS attacks often aim at overwhelming system resources such as link bandwidth, network buffers or CPU processing capacity to prevent regu-lar users from accessing a service by issuing illegitimate traffic. A report from Verisign [5] fortifies this observation. It states that DDoS attacks are grow-ing in volume and that attacks are becomgrow-ing more sophisticated, since many attacks are issued as a combination of various techniques.
Between summer 2017 and summer 2018, an increase of DDoS attacks of 16% had been captured. During the same period, the amount of application layer attacks has been rising by 38%, credential fraud being the most popular
Direct Effects Indirect Effects Service Downtime DoS Mitigation Costs
Scalability Costs Increased Energy or Provider Costs Revenue Losses Loss in Reputation
Table 1.1: Direct and indirect economical effects of DoS attacks in web services and cloud computing, adapted from [6]
type of this sort of attack [4].
We are thus experiencing not only an ever increasing amount of cyber attacks nowadays, but also a growing variety of attack types. Concerns of companies grow, as DoS has been proven costly in terms of loss in revenue and reputation, as examples in Table 1.1 show. Moreover, they become more exposed as cloud applications and software as a service (SaaS) is becoming a commodity.
Another significant challenge is that real traces of DoS attacks are often hard to obtain, since victims often do not want to share their data in fear of bad publicity [7]. It is a plausible assumption that a significant number of DoS attacks remains undetected. Extensive studies in real deployments con-sume system resources and might disturb users. Therefore, research is mostly performed through means of simulation [8].
1.1.1
Domain Attacks
Business logic or business rules are used to define high level system goals of a business. To define the business logic, a clear and concise language is used and can thus be translated from a human-understandable language into machine language, e.g. through means of state machines or a high-level pro-gramming language. For a business rule to be useful in practise, it must be possible to unambiguously decide whether it is satisfied or not, given an input. As this can become a highly complex task, business rules are often divided into subsets [9].
In e-commerce, business rules are often applied to make a service obtainable to a user or for granting rewards. This can take various forms, for example by keeping a session alive before a customer checks out of an online shop, granting a free trial period for a video-on-demand service or giving a discount on the shipping fee if a certain purchase value is exceeded. Obviously, busi-nesses take great care that their services are not exploited in a disruptive way. Items are deleted from the shopping cart after the time is exceeded, a user is
only allowed to try out a service once and will be billed afterwards and free shipping is only granted if the profit is high enough. However, if an attacker can find a way to trick the business rules, it would be classified as a domain attack, or an attack on the business logic. If the attack has the additional effect of preventing other users from attaining a service, the attack also qualifies as a DoS attack.
1.1.2
Domain Driven Design and Security
Domain Driven Design (DDD) is a common architectural pattern for develop-ing commercial software such as web services. It uses a layered design and is based on the principle of developing software around a core business logic, i.e. defining the domain as the main feature of a program. Technical aspects are developed around this business logic to ensure that the software is extend-able. To make the code more accessible, DDD also promotes a unified syntax, called the ubiquitous language and advocates for using a model when access-ing domain objects [10].
By conducting validation inside the domain object, some security measures are already implemented by design. Domain Driven Security (DDSec) elevates the DDD pattern further by integrating security elements from the beginning. In the case of a web service, this may include authentication and encryption concepts, but also tracing user behaviour and comparing it to a rule set depict-ing a desired or expected behavioural patter. Since security concerns usually involve several layers in the software architecture, aspect oriented program-ming (AOP) can be utilized for developing such appliances to avoid cross-cutting concerns, which leads to better maintainability of the production code [11].
1.1.3
Secure Software Development
DDSec is only one out of many puzzle pieces of building secure software, as it aims at preventing attacks proactively by diminishing the attack window. Of-ten, threats arise as novel attacks are discovered and software security has to be achieved using accurate and fast reaction strategies.
Formal methods pose a method to accurately describe systems using an alge-braic notation. There are plenty of notations available and the unambiguous nature of formal methods has made it a popular aid for developing safety-critical software [12]. In practise, formal methods can be applied in static system analysis by checking all possible runs on a system. This poses a very
exhaustive form of testing software and can be accomplished by using simula-tion environments, e.g. model checkers. Formal methods can also be applied at runtime, i.e. in dynamic system analysis. This method is applied in runtime verification (RV), which is applied to monitor the current system execution in real time.
To be able to react fast towards attacks, computer systems should contain au-tomated detection and recovery techniques. Kephart and Chess [13] intro-duce the concept of self-configuring systems in order to overcome the time-consuming and often erroneous process of manual system reconfiguration. Detection alone cannot be considered sufficient to recover from and to mit-igate future attacks. A feedback loop has to be implemented as well to design truly secure software, as e.g. Iglesia and Weyns [14] propose.
1.2
Research Question
There are many established techniques to counteract network based DoS at-tacks, but attacks on the domain – or the business logic – are often subtle and thus hard to detect. Moreover, only little resources on domain attacks are avail-able to this date. The core of the research question is, how domain attacks can be detected and which measures can be taken to mitigate these attacks without the need of human intervention. Furthermore this thesis aims at discovering, whether formal methods are a suitable means to ensure correctness at the de-sign stage and at the running implementation of a web application.
While there exist numerous tools to detect network-based attacks, fewer appli-cations focus on attacks on the application level. Radmin [15] and its successor Cogo [16] are applications which focus on detecting attacks that cause resource starvation and exhaustion on web services. However, they do not target flaws in the business logic specifically and do not formulate measures to mitigate future attacks. One possible reason why there are no well-established, generic appliances designed to counteract the specific problem of exploiting flaws in the business logic might lie in the singularity of the business models behind different instances of web services, which means that detecting mechanisms have to be tailored to fit each individual application.
To put these concepts in a relevant context, a hotel booking service is de-scribed as a realistic application which serves as an example throughout this thesis work.
1.2.1
A Motivating Example
The example depicted in this work is a booking platform hosted by a hotel chain, where users can register with their name and credit card details and book a hotel room – a very common service issued by a variety of providers. The hotel chain wants to offer a service to their customers to engage them to book a room at their chain, being a free cancellation policy until one day before the booking period. The hotel management assumes that more people would be encouraged to book a trip than people would actually cancel the reservation. Unfortunately, this scenario can be exploited by a rival hotel chain. They might book some rooms at the other hotel chain and cancel their reservations shortly before the end of the free cancellation period, of course without the intention of ever paying for the service. This serves at least two purposes of the attacking hotel chain:
1. It damages the business of the competitor
2. Since the supply of hotel rooms in an area decreases, they might be able to raise the prices of their own rooms to maximize profit
1.2.2
The Reservation-Cancellation Problem
The example of the hotel chain may seem like a very specific problem, but in fact it is translatable to a very common problem in networked systems: DoS. In fact, it is a very specific type of DoS, since it does not involve an insider to launch a hardware attack or a lot of resources as in a DDoS attack. For launching such type of attack, knowledge of the domain is required. It deals with blocking resources from regular users by reserving an item without the intention of consuming them. This may happen in various forms, be it pur-chasing an item online and sending it back free of charge, putting items into a shopping cart and waiting for a session to time out or reserving flight, rental car or a hotel room and cancelling the reservation. For a maximized impact, an attacker could even launch a DDoS attack by using several accounts to block resources of a victim maliciously.
The unique feature of this problem is that any user of a service can block a good or a service from other users without any consequences, e.g. being charged a fee or getting privileges removed. To put this into a more memorable term, it is referred to as the reservation-cancellation problem. It is difficult to solve, as it is hard to distinguish between malicious and benign behaviour since not all cancellations can be assumed to be malicious.
To the best of my knowledge, this problem has not been scientifically studied yet and the extent of this problem is unknown. A possible explanation for this is that it is difficult to prove whether a cancellation is malicious or not, since the action itself is allowed by the business rules. It is however clear, that there exists an incentive for launching such an attack. As a matter of fact there have been reports of fake bookings of car rides in India, as Uber accused its local competitor Ola of more than 400,000 fake bookings, using over 90,000 fake accounts and cancelling rides in the last second [17]. Ironically, Uber has been accused of applying the same practise on its competitor Lyft, though in a sig-nificantly smaller scale with around 5,500 fake bookings using less than 200 fake accounts [18].
1.3
Purpose
The purpose of this work on a broad level can be derived from its title: design-ing and testdesign-ing a self-reconfigurdesign-ing IDS which is capable of mitigatdesign-ing DoS attacks, the domain based type in this instance, which aims at exploiting busi-ness rules of a service. Given the high frequency, volume and sophistication of cyber attacks, it is also intuitive that self-adaptive techniques have to be applied to counteract and mitigate them to avoid error-prone and slow human interaction to the largest possible extent. This means in essence, that a system is able to adapt its security settings automatically by means of reconfiguring system settings depending on the current system state.
It is aspired, that the findings of this thesis can be utilized to build custom security applications aimed at protecting from domain attacks using the same principles as depicted.
1.4
Goals
The primary goal of this project is to built a self-reconfiguring, rule-based IDS to detect attacks on the domain of a web service, following the DDSec design principles. The reconfiguration is accomplished by applying a feedback loop, continuously monitoring the user behaviour and issuing necessary changes if malicious behaviour is observed. The proposed IDS shall be able to determine whether a user is malicious with high accuracy and conduct all countermea-sures in an automated fashion, i.e. without the need of human intervention. It shall do so efficiently by detecting all or almost all malicious users, without or with only very few false positives. To ensure the formal correctness of the
IDS, static and dynamic analysis techniques are applied in the form of utiliz-ing model checkutiliz-ing and RV. Finally, the IDS shall mitigate future attacks by changing the business rules in a way that an attack on the business rules is weakened or that the cost for the attacker increases.
As a secondary goal, benign and malicious user behaviour is modelled, as the system is tested against different possible behaviour. This is ultimately used to quantify the capability of the IDS to mitigate DoS attacks as described in section 1.2.2.
1.5
Delimitations
Software security and IDS are complex and evolving topics which touch upon many areas in between software development and computer networks. This work is entirely devoted to the problem of maliciously blocking resources from benign users, a specific kind of application layer DoS. No further kinds of cy-ber attacks will be dealt with in this work, as there is a plethora of research in this field as well as there are a number of widely accepted software prod-ucts. Furthermore, measurements are conducted with an exemplary case study. The quantitative outcome of the experiments are therefore not generic, but can hopefully be applied in other scenarios by deducing their qualitative proper-ties.
1.6
Structure
This thesis work adheres to the following structure. In chapter 2 DoS attacks, IDS and formal methods are introduced. Furthermore, concepts for designing self-adaptive systems are described. Chapter 3 describes the research pro-cess. Formal methods are at the core of this thesis work, therefore the applied concepts and software tools are presented in detail. Following up, the exper-imental setup and the proposed data collection and evaluation methodology are depicted. Ethical considerations conclude this chapter. The actual imple-mentation is then described in chapter 4, with focus on the proposed ruleset to identify malicious behaviour, verification of the system and the depiction of a mock-up hotel service which is tested using a web client script. The re-sults of the experiments are discussed in chapter 5. Limitations and potential of static verification techniques as well as the measured outcomes from the experiments are discussed as well. Lastly, conclusions and future work are presented in chapter 6.
Background
In order to make the methodology of this research understandable, the outcome of the background studies is presented here.
In the first section, DoS attacks are discussed from a formal perspective. The second section is dedicated to IDSs and their different forms. In the third section, formal methods and automata as well as timed automata are depicted more specifically. Following up, model checking as well as RV frameworks are presented as two examples of practical implementations of formal methods. The description of self-adaptive systems is presented in the sixth section and the studies of related work conclude this chapter.
Figure 2.1: CIA Triad, adapted from [3]
2.1
DoS Attacks
The so-called ”Security Triad” or ”CIA Triad” depicted in Figure 2.1 aims at classifying security policies. Its parameters are confidentiality, integrity and availability. From this point of view, DoS attacks generally aim at diminishing the availability of a service [3].
DoS attacks come in various forms and are by no means only network based. Hardware attacks, e.g. maliciously shutting down a load balancer or the cool-ing system of a server rack can be seen as a form of DoS and can be carried out by either an insider or an outsider.
Network specialists are naturally more interested in network based DoS, which often comes in the form of flooding in aim of exhausting network buffers, link bandwidth or CPU processing capacity. Interestingly, issuing such attack is not very difficult, since many orchestration tools are readily available, such as stream2, synhouse, synk7, synsend or hping2 [7]. This sort of attack is en-abled by the stateless design of the Internet Protocol (IP), which follows the end-to-end argument. All sorts of IP packets are forwarded through the In-ternet to their respective destination as long as the IP header information is correct. Therefore, security measures have to be implemented at the commu-nication endpoints.
To increase the volume and at the same time impede the traceability of an attack, an attacker may try to install a trojan horse on a number of network connected computers and control them to launch a DDoS attack.
Since traffic fluctuation is a given in web traffic, static analysis is not sufficient to detect either flavour of DoS attacks [7]. It is thus a hard task to discriminate legitimate from illegitimate traffic, as legitimate traffic may increase drasti-cally as soon as highly popular content gets hosted.
All (malicious) DoS techniques share the goal of deterring legitimate users from receiving a service, be it buying an item online, making a financial trans-action or simply loading a website. This said, DoS does not imply the type of attack but the term rather describes its effects. Domain attacks are a specific instance of DoS, which aim at exploiting business rules to disrupt a particular service. The distinction from a flooding attack is that the attack is specific to a service. Therefore, knowledge about concrete vulnerabilities must by acquired by an attacker prior to launching an attack.
Figure 2.2: Signature based and anomaly based approaches to intrusion detection in contrast, anomaly model adapted from [19]
2.2
Intrusion Detection Systems
An IDS serves multiple purposes. Early detection of system misuse or ma-licious behaviour is essential to avoid system damage and recovery can be achieved more quickly as with reactive methods. An effective IDS can deter malicious behaviour, although some cyber criminals also seek the thrill of a challenge and try to fool security appliances.
By capturing traces of attacks, valuable information can be gathered to build more secure systems and prevent future attacks [2]. There are two main forms of IDS: signature based IDS and anomaly based IDS, schematically depicted in Figure 2.2.
Signature based IDS work on basis of known attacks, i.e. the payload is in-spected for known patterns similar to the functionality of an anti-virus scanner. They are typically connected to a database which gets updated as soon as new attacks are revealed [3].
Anomaly based IDS work on the assumption that there is a quantifiable, ex-pectable use pattern. This implies that a training set is used to establish the
normal use pattern. This set is assumed to be clean, i.e. in absence of mali-cious behaviour, which can be challenging in practise since unknown attacks are not detected [1]. A further challenge in research is that companies often do not want to share their data due to privacy concerns and fear of loss in reputa-tion [7]. A significant deviareputa-tion from the norm will be classified as malicious behaviour and the IDS can e.g. issue the installation of a new rule at the fire-wall. What is considered significant is to be decided by the system architect. There also exists the notation of a rule based IDS, which is triggered when a particular rule is not adhered to. Under closer examination a rule based IDS would fall under the category of an anomaly IDS, where the rule defines the desired behavioural pattern. However, this notation clarifies that a rule is de-fined by a policymaker and not by traces of users. Rules define regular use patterns that are deemed appropriate by system administrators [2].
Figure 2.3: Behavioural patterns, adapted from [2]
To this date, there exists no one-size-fits-all IDS. The obvious advantage of an anomaly based IDS lies in its capacity of detecting unknown attacks but at the same time tuning is challenging as normal and malicious behaviour is often hard to distinguish. It is neither desirable to classify a rare behaviour necessarily as malicious nor to tolerate attacks that operate with slowly in-creasing malicious traffic to fool the IDS. A strict setting of the IDS may yield in a high number of false positives, as the undefined area in Figure 2.3 indi-cates. Therefore, tuning the system is essential. Signature based IDS rely on the accuracy and relevance of its connected database and are thus not capable of detecting novel attacks.
Since IDSs pose a performance bottleneck for a web application, they are often installed at numerous network entry points as a network based IDS (NIDS) or directly at the host machine (HIDS) [20].
Systems may implement different detection features, however it is a desirable feature for an IDS to consume little resources such as memory or processing capacity. Moreover, it should be scalable, since web services are increasingly deployed in cloud environments. Good provisioning is key for any IDS also for a different reason: Ozcelik, Fu, and Brooks [8] found out, that the perfor-mance of anomaly detectors is inversely proportional to network utilization. An IDS may combine different attributes, e.g. by using machine learning tech-niques such as implementing an artificial neural network to detect anomalies and check for signatures at the same time [20]. This might however contradict with the goal of achieving a lightweight detection process, depending on the implementation.
To summarize, traffic patterns can be extracted best with anomaly detectors whereas specific attacks such as SQL injection is identifiable with concrete signatures. Examples of popular NIDS which use rule sets include Snort [21] and Zeek [22]. Tripwire [23] and OSSEC [24] are examples for HIDS, which do file integrity scans.
Figure 2.4: Software Development Cycle and applications of formal methods
2.3
Formal Methods
Formal methods are techniques to describe a system using models and lan-guages which are built upon mathematical expressions. They can be applied in various stages in the software development cycle depicted in Figure 2.4, e.g.
to model a system’s behaviour at an early stage of the development or to test it prior to implementation. They are often applied to test and verify a software against a specification. The application in software engineering ranges from specifying a software over verifying correctness, safety and security properties to formally proving theorems, i.e. the logical soundness of a piece of code. Formal methods are by no means limited to software, also hardware design such as electrical circuits can be formally modelled, specified and tested. That is cheaper than building a prototype in many cases and can be used as a com-plement to simulation [12].
Common to all formal methods is the use of a rigorous mathematical nota-tion with the aim of describing systems unambiguously. The most precise definition can be obtained by using exclusively algebraic expressions. Utiliz-ing human-understandable language usually leads to a less rigorous specifica-tion and more ambiguity in the specificaspecifica-tion. It is desirable to obtain precise descriptions of a system as software is becoming increasingly complex and society is relying on software-controlled systems significantly. Reading and understanding such notation is however a difficult task.
Finite-state systems can be modelled by formulating a transition system, which in the simplest form consists of states and transitions between these states, triggered when a certain system property is met [25]. Common mathematical methods such as composition and abstraction can be used to further simplify a model.
There is a rich variety of notations and formal languages which can be used to model systems. In order to model active, concurrent or communicative sys-tems, automata are often applied [26]. It is a formal language driven by state transitions, opposed to e.g. Markov chains, which are probabilistic and are thus often applied for dependability or safety analysis [27]. They can be for-mally verified by theorem proving or heuristically by applying model checking, i.e. via automation, which may be beneficial since it reduces the risk of human error [25].
2.3.1
Automata Theory
An automaton, sometimes also named as finite automaton or a finite state ma-chine (FSM), is a system which consists of a discrete number of states. System behaviour can be modelled using transitions between these states. Like a Ran-dom Access Machine or a Turing Machine, it can be used as a reference model of computation, but is limited in terms of memory allocation by its number of states.
Figure 2.5: NFA and equivalent DFA. Both Automata accept an input string which ends with 1, accepting a language consisting of {0, 1}
By applying automata, it is possible to check an input sequence – often called string or word – of a regular language for its correctness and may produce dif-ferent sorts of outputs [28]. Automata can either be designed to be determinis-tic or non-determinisdeterminis-tic. Determinisdeterminis-tic finite automata (DFA) always compute the same output for a given input string. Non-deterministic finite automata (NFA) can take more than one transition given the same input (δ-transition) and make a transition given a null-input (-transition). These systems can be used to model loosely defined states, i.e. when a particular transition is un-known. -transitions come handy whenever different DFA shall be combined. The reason why a system designer may choose to construct a NFA is that it is often possible to describe a system with less states and less transitions with a NFA than with a DFA [28]. However, for modelling concrete systems, system designers generally strive for determinism. Luckily, it is always possible to convert a NFA into a DFA, e.g. by merging states. A simple example is shown in Figure 2.5.
Depending on the output of an automaton, it can be defined as a certain type: an acceptor only returns a boolean value, a classifier may return a larger variety of accept states whereas a transducer produces an output sequence, which can be used to concatenate FSMs [28].
Regular expression checkers are a popular example of automata, see e.g. [29]. These can be modelled as a finite set of states and transitions between these states, yet they can check input strings for their correctness irrespective of their length [30]. Compilers are an example of a more complex sort of determin-istic FSM, since they are required to produce the same output given an input sequence. A deterministic automaton can be described as a five tuple A = {Q, Σ, δ, q0, F}, where:
• Q – Finite set of states
• δ : Q × Σ – Transition function; can be defined as a state transition table • q0 Q – Initial state
• F ⊆ Q – Set of accept states [28]
The construction of automata is a manual process, therefore practical lim-itations exist on how complex an automaton should become. Highly complex systems display the state explosion problem. Combining two automata with n states leads to 2nstates in the worst case, which may sometimes be reduced in the aftermath by removing redundant transitions [28].
Figure 2.6: Visualization of the state explosion problem when combining two (simple) automata in parallel composition. The number of states grows exponentially, though less severe if there are less transitions enabled in the initial automata.
Figure 2.6 shows the problem of state explosion when combining automata, which is a major challenge in model checking. As a solution, problems have to be abstracted or divided into sub-problems, should be taken into consideration in the design process. Leaving out irrelevant details allow for justifiable sim-plifications and allow for focusing on the important characteristics of a system. Automata may be enriched with additional information for more advanced tasks. A common approach to model concurrent systems is to add timing in-formation through clocks to an automaton, ultimately constructing a timed automaton.
Figure 2.7: Example of a timed automata network with shared variables, consisting of a train, a gate and a controller acting as a weaver. Taken from [32]
2.3.2
Timed Automata
Real time systems can be modelled and verified using timed automata, first de-scribed by Alur and Dill [31]. A timed automaton can be dede-scribed as a graph containing a finite set of nodes (states), labelled edges (transitions), variables and guards (clocks). It can be constructed as an ω-automaton, which accepts words of unbounded length. Clocks serve as guards which are applied as con-straints and are used to provoke or decline transitions. Clocks are bound to increase monotonically or be reset. A clock value hence always displays the time elapsed since its last reset. A common example for a network of timed automata is given in Figure 2.7.
It is possible for a system to hold multiple clocks, which can be either discrete-valued or use a dense time model for real discrete-valued clocks. Clocks do not need to operate synchronously, i.e. they may be reset independently. This is an important property in modelling distributed systems, since global clock syn-chronization can be a burden in practise.
The transition table in the five-tuple of the automaton is thus enhanced by the set of clocks X, with C(X) being the time constraints expressed in the system. The transition function δ must therefore be rewritten and the timed automaton A = {Q, Σ, X, T, q0, I} forms a six tuple with some modifications
according to the member variables [33]: • Q – Finite set of states
• Σ – Finite alphabet of possible input symbols that represent events • X – Finite set of clocks
• T ⊆ Q × C(X) × 2C
× Q – Transition function; can be defined as a state transition table
• q0 Q – Initial state
• I : Q → C+(X) – associates an invariant with each state
Timed automata are generally computationally more expensive than regu-lar automata, but it is possible to delimit the accuracy of the clocks to achieve faster computation. Measures to reduce the complexity of timed automata in-clude restricting the number of clocks, e.g. one-clock timed automata or using a discrete-time model instead of a real-time model [33].
2.4
Model Checking
There are automation tools for modelling timed automata called model check-ers, such as e.g. the UPPAAL [34] or PRISM [35] model checker. They can be used to check a program for reachability, liveness and safety properties by computing all possible paths [36]. In more understandable terms, these prop-erties mean:
• Reachability: A state can be reached
• Liveness: Some (desired) event will eventually occur • Safety: A certain condition will be satisfied
Moreover, quantitative aspects such as periodicity, bounded response and concrete timing delays can be determined by using timed automata.
It needs to be stressed that formal methods are by no means a panacea. The correctness of an automaton can be verified, but the verification of a system can only be done upon the assumption that the specification is correct. In other words, formal methods can verify correctness of a software according to a given specification.
Figure 2.8: Atomic CTL formulae which can be expressed in UPPAAL. A denotes the always quantifier, E the exists quantifier. The operators [] , <> and –> are translat-able to globally and until respectively. Figure adapted from [36].
2.4.1
Temporal Logic
For verifying properties in a model of a real-time application, temporal logic has to be utilized. It is possible to check for a variety of timed safety, liveness and reachability properties using a precisely defined syntax.
There are two main classes of temporal logic, namely computational tree logic (CTL) and linear time logic (LTL). In short, LTL are verified against a set of linear sequences from the current starting point whereas CTL are computed on all possible runs of a system [37]. This means, that there exists an inter-section between properties which can be verified using both LTL and CTL, but neither is the super- or the subset of the other. There are properties which can be expressed using LTL but not in CTL and vice versa. CTL use the path quantifiers A for always and E for there exists in combination with a temporal operator, which are not available for LTL. Figure 2.8 shows common CTL ex-pressions.
There are some properties which can be expressed using LTL but not in CTL, e.g. that a certain condition will eventually be satisfied globally, i.e. on all possible paths. On close observation, this property can only be approximated using CTL, but the practical definitions are either too strict or too loose at close observation. Finally, both LTL and CTL allow for concatenation using Boolean formulae, which allows for constructing more complex rules.
Vardi [38] argues, that CTL is algorithmically advantageous in comparison to LTL, which might be the reason why many model checkers use CTL. Given a system size n and a temporal logic formula of size m, CTL is computed in O(nm) whereas LTL takes n2O(m) [38]. Indeed, the popular UPPAAL model checker utilizes CTL [36] and sacrifices the ability to check for LTL properties for better performance. LTL properties can be verified using different software tools, e.g. the SPIN model checker [39].
2.5
Runtime Verification
Verifying a system in real time is a hard task and modelling real-world systems is often impossible using model checkers due to state explosion, which may oc-cur even in simple deployments. In order to tackle this problem within model checking, incremental runtime verification [40] and statistical model checking have been proposed [41]. This is however not sufficient for online verification of real-world systems, since the expressive power of model checkers is often limited. Developers are forced to find workarounds using abstractions. RV can be seen as a more lightweight formal method, since only a limited set
of system executions are verified against a set of given specifications. RV is are utilized as a complement or even a replacement to static verification tech-niques such as model checking and can be implemented using timed automata [42].
Since only bounded runs can be verified, RV systems can not always give guar-antees about reachability or liveness properties. However, RV systems can be applied to ensure a system does not reach an unsafe state by defining a fall-back behaviour. By doing so, RV systems contribute to designing secure, self-adaptive systems.
There are numerous RV systems available for different applications and pro-gramming languages. A recent study has been conducted by Falcone et al. [43] to characterize a number of currently available systems. It was observed, that not all RV systems offer means of instrumentation, i.e. monitoring and logging the systems is of primary concern. Within the observed sample, AOP is a commonly used paradigm for applying monitoring and instrumentation, if applicable.
2.5.1
Aspect Oriented Programming
AOP is a popular approach for writing logging or monitoring applications, since it provides a non-invasive solution for dealing with cross-cutting con-cerns, i.e. functionality which is spread across several layers of the software. This is often the case when it comes to security aspects. AOP runs in parallel to the stack and leads to fewer atomic changes in a program when modifica-tions in a service are required compared to solumodifica-tions where AOP was not a applied, as an empirical study shows [44]. However, this comes at the price of developers having to learn a framework with novel concepts and terminology. AOP introduces the concepts of aspects, join points, pointcuts and advices [45], summarized in Table 2.1.
AOP Term Explanation
Aspect AOP equivalent to a class
Join Point Specific point the in the program execution, e.g. a method call Pointcut Collection of Join Points
Advice Code running when a join point is called
Table 2.1: Summary of the most important AOP concepts
re-ferred to as weaving. When implementing aspects using libraries, weaving is typically done at runtime. For weaving at compile time, a dedicated compiler such as the AspectJ compiler (AJC) has to be used.
There are two main ways to implement AOP in Java. The first is using AOP libraries, which run with pure Java code, the second one is using the AspectJ language, which can only be used with the AspectJ compiler [46]. A bench-mark indicates potential performance benefits of using compile time weaving over runtime weaving [47].
2.6
Self-Adaptive Systems
Modern computer systems are becoming increasingly complex, therefore man-ual reconfiguration is becoming unfeasible. It is a desirable property of a soft-ware system to recover from faults or softsoft-ware attacks independently from human interaction. Upon the advantages are faster response towards failure or attacks, higher agility as novel attacks can potentially be mitigated and less operational cost. It is an essential concern for companies to mitigate security threats at runtime, i.e. reconfiguration happens as soon as a fault or an attack is detected without having to reboot the system [48].
In an influential paper, Kephart and Chess [13] foresee the need of autonomic computing as systems are becoming more interconnected and dynamic. It is becoming increasingly difficult to predict future behaviour of a managed sys-tem. At the same time, systems need to be adjusted according to external influences, such as changing workloads, demands or component failure. The concept of autonomic systems can be divided into the following subsets:
• Self-reconfiguring: an automated system following high-level policies • Self-optimizating: performance measurement and tuning of predefined
parameters
• Self-healing: automated detection and mitigation of local hardware and software problems
• Self-protecting: detecting outside attacks at an early stage and configur-ing security parameters automatically
All these terms can also be summarized as self-adaptive or self-* systems [14]. The system can hence be divided into a managed system and an auto-nomic system manager. The managed system is the legacy system which shall
operate as usual.
Iglesia and Weyns [14] argue that a ”separation of concerns” (SoC) must take place. The managed system is commissioned with its domain concerns, such as delivering a service according to its business rules. The manager is con-cerned with the task of adapting to changing externalities and to change pa-rameters when it is required. In order to achieve this, relevant papa-rameters are read from the managed system, such as current throughput or a certain request. The system manager should not have a significant impact on system perfor-mance as it might become a perforperfor-mance bottleneck. This can be achieved through optimizing the monitoring pattern, e.g. through sample based testing [13] or through a well-balanced distributed system design.
On an architectural level, the MAPE-K feedback loop as depicted in Figure 2.9 can be applied, which refers to the different phases in the activation of the system manager:
Figure 2.9: Systematic view of the MAPE-K feedback loop, adapted from [13]
All items refer to a common knowledge base, where system traces and policies are stored. To proof the feasibility of design goals, formal methods are commonly applied. However, there is no standard framework on build-ing formal models and this task is often done from scratch. Methodologies to facilitate this manual process pose a research problem on its own. Timed au-tomata is upon the most popular approaches and can be tested via established model checking tools [14].
The MAPE-K feedback loop serves as a formal template and assist at design-ing self-protectdesign-ing systems. Domain specific aspects such as security policies have to be specified and implemented manually. Another challenge is the lim-ited expressiveness of formal methods, which might lead to complex models. The state explosion problem has to be dealt with as well.
2.7
Related Work
There is a variety of ongoing research in the area of formal verification and self-adaptive systems. It is argued, that formal methods can help system archi-tects to rest assured that their models conform to the system specification and an implementation can be built accordingly. Furthermore, formal methods can be applied to check for violations in the aftermath to learn about a system’s specific behaviour. This is often done offline, since formal verification and model checking is computationally expensive.
Self-adaptive systems are employed reconfigure settings at runtime and often use formal methods, such as timed automata and Markov chains. To be able to run in real time and sometimes on constrained devices, intelligent mechanisms to reduce computational time and power have to be applied. RV does so by only checking a subset of all executions. Furthermore, sample-based testing can be applied to reduce the monitoring overhead.
This section poses an attempt to separate the related work into formal methods, often applied for verifying a system’s safety, reachability and liveness proper-ties, and dynamic monitoring, which is can be applied to build self-adaptive systems.
2.7.1
Formal Methods
Newcombe et al. [49] describe the experience use of formal specification and model checking at Amazon Web Services (AWS). Since AWS needs to operate at high dependability, the correctness of a new function has to be determined with high confidence. Standard verification techniques such as reviews and testing might not detect all bugs, especially if they only appear in rare occa-sions. AWS utilized the TLA+ specification language [50] and the associated TLC model checker on a number of real-world deployments and were able to find bugs or improve confidence, that a system is indeed working as intended. Finally, improving the understanding of a system design was found to be the most striking advantage of using formal methods by the participants.
Marques et al. [51] reason that before the industry adapts a new communi-cation protocol, its formal correctness should be proven as applicommuni-cations depend on its reliability. They test the web service business activity protocol (WS-BA) by applying model checking and found a number of problems: invalid states are entered (safety property), processes may not finish (liveness property). In fact, only a strict FIFO queueing setting grants correct behaviour, at least for a limited amount of messages in the channel. In a realistic scenario channels must be considered in which messages can be reordered, lost or duplicated.
Lucio et al. [52] argue that model driven security (MDS) helps to abstract the domain process. This can be used to integrate security concerns from the beginning of the development process. To avoid error-prone manual recon-figuration, model transformations can be applied. Furthermore, formal verifi-cation techniques such as model checking can be utilized to confirm security requirements. Aspect oriented programming can help in achieving SoC.
Fradet and Ha [53] formulate an aspect oriented language based on timed automata which is able to prove the absence of DoS due to deadlock or starva-tion. This is a possible scenario if the resources of a system are not allocated properly, e.g. when shared resources are accessed concurrently. Following this formal approach, model checkers can be used to verify the properties of a target system. Furthermore, using an aspect oriented approach, weaving can be kept under control. The approach was evaluated using a simple case study of an automated teller machine (ATM) and using timed automata in UPPAAL. Klerx et al. [19] extend timed automata with a probability aspect to detect anomalies in discrete event systems. Discrete event systems are characterized by i) a finite state space, ii) the current state depends on the previous state and iii) state changes are caused by timed events. They formulate probabilis-tic determinisprobabilis-tic timed-transition automata (PDTTA), an extension of proba-bilistic deterministic finite automata (PDFA), which can be derived using the ALERGIA algorithm. This approach allows to check a discrete event system for anomalous events, anomalous timing and as a novelty, anomalous sample paths and anomalous timing sequences. All of these events can potentially be signs of a software attack. The approach was tested with real traces of an ATM and tested against a PDFA algorithm.
These examples show, that there is a variety of ongoing research in the area of formal verification in the context of software development and web services. Furthermore, there exists a demand for secure and reliable web protocols from the industry. However, none of the conducted studies depicted in this section is focusing on verifying user behaviour at runtime.
2.7.2
Dynamic Monitoring
To overcome the issue of real time verification in formally modelled systems, Forejt et al. [40] propose the method of incremental runtime verification. A target system, a dynamic IP network with nodes constantly leaving and joining, is modelled as a Markov decision process, using probabilistic model checking. A monitoring node is employed to constantly sending probes to assess the current system state and a reconficuration module reconfigures subsets of the system. As not the whole system needs to be reconfigured, this method can be up to 10x faster as legacy model checking engines, confirmed on the PRISM model checker. However, checking a deployed system remains at future work. Hammal et al. [54] propose timed automata based modelling to verify the correctness of measurement parameters in wireless sensor networks (WSNs). In their case-study, they describe an autonomic network of IoT devices, which elect a control node to report measurements to an aggregator. This control node is elected based on its battery level. Verification nodes are used to control the monitoring node based on a mathematical model and malicious nodes can be ejected from the WSN.
Fu et al. [55] use a event based approach to detect and report different kind of attacks against constrained IoT networks when an attacker manages to break the encryption. A library classifying normal user behaviour is employed to detect three sorts of attacks in particular, namely: i) replay attack, intercepting a message and issues the same behaviour against the target system, ii) jam attack, sending a lot of messages to clog the network and causing DoS, and iii) fake attack, intercepting messages and injecting malicious code. The approach was conducted using an automata model, focused on the inputs and outputs of the system. It can be applied to detect the aforementioned attacks, but the authors mention that it is still challenging to model complex systems in real time using automata.
A context-aware security framework is presented by Cuadra and Aracil [56]. The authors reason, that it is important to discriminate user behaviour between different times of the day. They present a traffic anomaly detection indicator, which was tested on a campus network in three different time blocks: night, noon and afternoon. This approach is more scalable than utilizing more coarse time frames and allows for choosing the most appropriate algorithm for traffic analysis based on current load. The work is however limited to anomaly detection.
Filieri, Tamburrelli, and Ghezzi [57] present a mathematical approach for probabilistic model checking at runtime using Discrete-Time Markov Chains
(DTMC), which can be further enriched with ”rewards” to account for cost and performance concerns. They use a self-adaptive approach in their algorithm, which iteratively checks for changes in the environment, probes whether the system requirements can still be fulfilled and allows for autonomic configura-tion of system settings. Different failure probabilities are expressed as vari-ables and matrix operations are carried out to update the system state. This approach aims at diminishing the problem of state explosion but is is still not very scalable, as Gaussian elimination has to be applied, which has a time complexity of O(t3).
Pinisetty et al. [42] argue that runtime verification is important for safety critical applications, as it allows for issuing corrective measures in anticipa-tion. It is possible to achieve this if the system behaviour is at least partially known a priori, i.e. that a reasonably accurate system model is available. Then, executions can be expressed as timed strings and checked against the model. In their implementation, they check an input string against a timed automata model in aspiration to produce a verdict before the ending of the sequence. A Python implementation of the UPPAAL model checker was used to conduct the formal verification of their system in a case study of a regular expression checker.
Chimento, Ahrendt, and Schneider [58] apply RV in the context of test driven development (TDD). They argue, that model based testing and RV can help identify system faults which cannot by found using legacy TDD. Formal methods can therefore help in system validation. RV was carried out on a mock-up banking application written in Java, intentionally containing bugs in its implementation. A system monitor was implemented using the Larva RV framework, which was able to detect errors at runtime which were missed by applying assertion tests only.
Dynamic monitoring techniques and runtime verification pose an approach of implementing lightweight formal methods and can be applied in a wide range of applications. To enable self-reconfiguration, monitoring has to be conducted online, i.e. on a running system and with low delay. In many of the presented research works the program output is compared to a model by means of calculating or estimating a value. In none of these works the current user behavior is compared to its past behaviour. Furthermore it is apparent, that most of the presented works emphasize on detecting anomalies at runtime, mitigation strategies are generally treated with less priority and appear to be a blind spot in research. No related work could be obtained which uses changing the business rules as a means to mitigate future attacks.
Research Methodology
In this chapter, the research methodology is described. The core of this work is conducted using a quantitative approach through means of experiments. For deriving a suitable model, an exploratory research strategy is applied as well. The experiments are utilized as a data collection method. This is a viable ap-proach, as the reservation-cancellation problem is not a well-studied topic. More precisely, the data collection is done by conducting a synthetic case study of the example problem mentioned in section 1.2.1, the competing hotel chains. The data analysis is conducted quantitatively, using formal methods and statistics. This hence follows an deductive research approach, as the the-ories are derived from the observations in the case study [59].
With regards to the utilized methods, it is no particular goal of this thesis work to provide a general model but rather to depict a possible solution to the prob-lem at hand. However, as coding and formal notations are applied, the model is reproducible for interested fellow researchers. The proof-of-concept can possibly be utilized to develop more generic models in future.
3.1
Research Process
In this thesis work, RV and self-adaptive techniques are applied to design a rule based IDS. This service is aimed to secure a web service at runtime by adapting business rules depending on the current system state and past user behaviour. Furthermore, the viability of the approach is verified by means of static analysis prior to system deployment.
The service in this research work will be the same as depicted in section 1.2.1, a hotel booking service. As a first step, static verification by means of model checking is conducted to formally verify liveness and safety properties of the
system. Consecutively, online monitoring and reconfiguration is conducted on a web service using a RV framework. The following sections will shed light on what findings are expected from each experimental setup.
3.1.1
Model Checking
For testing the applicability and delimitation of a proposed ruleset to detect malicious user behaviour, model checking is applied as a means of static ver-ification. It is a common method for e.g. formally verifying protocols and hardware circuits. From the various tools available, UPPAAL was chosen be-cause of its graphical user interface, thorough documentation and acceptance from the industry. It allows for programming timed automata using a C-style syntax and checking them against CTL properties. A number of successful case studies can be obtained on the official website [34].
A minimalist version of a web service with encoded benign and malicious user behaviour is modelled as well as a monitoring unit. Since checking all possi-ble executions of a real application is too exhaustive due to the state explosion problem, only the rules to be enforced by the IDS are tested against selected safety and liveness properties as well as for potential blocking behaviour. This shall give confidence, that the rules are enforced without any undesired side effects to benign users. Unfortunately, only very basic user behaviour can be modeled using UPPAAL. This reflects upon the rules which are tested.
3.1.2
Web Service and Runtime Verification
The web service itself will be realized as a RESTful1web service running on an Apache Tomcat server [61], offering a minimalist web browser interface for user interaction.
The primary business logic is implemented in the web service. Users can check for available rooms, register an account, reserve rooms, check their reservations and cancel reservations before the reservation period has elapsed. All of these actions are also accessible through web parsing libraries such as cURL [62] for shell scripts or urllib [63] for the Python programming lan-guage, which makes the application suitable for benchmarking through auto-mated web clients. The web service is developed using the Spring framework
1
Representational State Transfer (REST) is an architectural model commonly used in web applications. It is popular for its simplicity, as it is a stateless architecture. Common HTTP methods such as GET or POST can be implemented using a RESTful architecture. For more theoretical background consult e.g. Fielding et al. [60]
[64] which is aimed at professional Java web applications.
Figure 3.1: Conceptual implementation of the MAPE-K feedback loop. The Larva RV framework is employed to monitor and reconfigure the web service. User interaction is conducted through a REST interface.
The application layer IDS is implemented in parallel to the web service as a MAPE-K feedback loop to monitor the user behaviour and issuing reconfigura-tion parameters in runtime as shown in Figure 3.1. From the user perspective, this happens in the background, i.e. the monitoring process is inconceivable for the user. The IDS is realized as a timed automaton using the Larva RV framework [65], which defines a set of states, their respective transitions and rules triggering them. User behaviour and timing constraints are used to define the rules unambiguously and follow the same logic as the model which was checked with UPPAAL, hence inheriting the formally verified safety and live-ness properties. The timed automaton is realized as a transducer, determining
whether i) the system is in a safe state or under attack and ii) a user should be trusted or not.
A database is used to save booking data and user classification, expressed as a trust level. At the first registration, each user is assumed to be benign, since the hotel chain is willing to offer a free cancellation policy to any newly reg-istered user. If a user is classified as malicious judging prior traces, privileges are being removed.
3.2
Experimental Setup
In this section, the utilized software tools and the test environment are de-picted in more detail. There is a large variety of viable tools and methods to conduct the proposed experiments. Therefore, the choice of software and the experimental setting will be explained in this section as well.
3.2.1
UPPAAL Model Checker
The UPPAAL model checker has been developed in a collaboration between the Department of Information Technology at Uppsala University and the De-partment of Computer Science at Aalborg University [34]. It has been de-signed to test protocols and circuits where timing information is crucial. It provides aid in making system design decisions at early development stages as well as conducting static verification.
Systems can be built as networks of timed automata, where channels and global variables act as means of communication. UPPAAL offers a graphical user interface and operates with a programming language which uses a C-like syntax. This allows for programming (simple) business logic. The supported data types include primitives such as Boolean, (bounded) integers, arrays of these types and real-valued clocks.
The simulator allows for conducting sample executions, which helps at observ-ing design flaws at early design stages. This is a significantly less exhaustive means of testing than model checking and thus provides no guarantees of cor-rectness.
Reachability and invariant constraints can be tested with CTL formulae using the verifier in UPPAAL. If a property is not satisfied, a diagnostic trace is dis-played to the user.
UPPAAL has various extensions, e.g. the UPPAAL SMC statistical model checker which allows for modelling and verifying stochastic behaviour [41].
There are regular updates to the software as well as there are plenty of tutorials, papers and industrial case studies available online.
3.2.2
Spring Framework
Spring [64] is a framework for developing Java Enterprise Edition (EE) appli-cations, such as professional web applications. It allows developers to choose from different toolsets when building applications, such as view generation, communication, persistence or security. Spring Supports an XML-based or annotation style configuration for setting up projects. This allows for a signifi-cant reduction of boilerplate code and hence eases the development of profes-sional applications.
For the application in this work, the Apache Tomcat web server, H2 in-memory relational Database and Thymeleaf dynamic view resolver were chosen. As an integrated development environment (IDE), the open source Eclipse SDK was chosen.
3.2.3
Larva RV Framework
There are a number of RV frameworks available for general purpose program-ming languages such as Java or C [43]. Many of those which offer online RV, i.e. those that monitor the current execution of a program rather than log-files, use an AOP paradigm for monitoring and instrumentation. Examples for RV frameworks which offer this approach are Valour [66], Java MOP [67] and Larva [65]. All of these frameworks are intended to work with the Java programming language. Moreover, they use timed automata as a logical foun-dation and they are built upon AOP concepts.
Out of these, Larva was chosen because of its ability to reuse automata for multiple objects, its thorough documentation [68] and its ease of use.
Larva is built upon an instruction language which can be used to define net-works of timed automata, communicating through defined channels or shared variables. State transitions are enforced using events such as method calls in the monitored program and constraints, which can be timed or based on other properties. A transition may also trigger further actions. Clock objects are supported and may be used to define events, too. Furthermore, it is possible to define common Java methods and import libraries for more complex oper-ations.
At compilation of the Larva script, aspects and Java classes are generated. The aspects serve the purpose of defining join points and calling the
