CACLE - Automated Mitigation for Misconfiguration Vulnerabilities in Cloud Systems

“Shift-left” security is a relatively recently-coined phrase popularized by the DevOps community recommending that security should be embedded into the earliest phase of the development process possible [1]. It signifies a commercial acceptance of security issues that have been known in academia for over a decade [2] that identifying and mitigating vulnerabilities in the earlier phases of the development cycle is both faster and more effective. There are an increasing number of causes of such vulnerabilities: poor or incomplete requirements, inadequate requirements engineering, and poor design being the most common and well-known. In the past few years, a new cause of security vulnerabilities for cloud computing systems has emerged - User Misconfiguration Errors (UMEs) [3]. This paper introduces the Configuration Analysis and Checking Logic Engine (CACLE) which provides a new mechanism for dealing with such errors. It also demonstrates the use of the engine on a publicly available data set.

The key to the flexibility of the cloud is the use of Infrastructure as Code (IaC) [4]. IaC has also led to the process management methodology known as DevOps [5] by providing a mechanism to automatically configure system depen- dencies and provision local and remote instances. This in turn has engendered a dependency on configuration files and mechanisms which has led to the rise of automated configuration tools such as Apache Brooklyn, Chef, Puppet, and similar applications. In many ways, these tools are double-edged swords in that they introduce new avenues for security vulnerabilities (through UMEs) as well as providing a potential channel for identifying and mitigating such vulnerabilities. Utilizing this latter aspect is the focus of this research.

One of the drivers for the increase in UMEs is the changing nature of the System Development Life Cycle [6]. The transition from more traditional paradigms such as waterfall and spiral, through agile models to modern DevOps approaches has heralded a move to ever greater automation in the development life cycle. However, along with this increase has been a commensurate decrease in the informal communication processes highlighted by [6], and that has meant a reduction in both the formal and informal security checks that such communication engenders. A study [7] of the practices and issues involved in configuration design and management summarises both the impact of UMEs on large, international companies such as Facebook and Google, as well as highlighting the critical improvements required to reduce UMEs at a systemic level. Although Zhang et al. [7] do not focus on security, there are three recommendations from their research that are appropriate to and align with the objectives of our paper:

• the provision of proactive parameter value checking and validation - we focus specifically on security
  
• the provision of security checks in early execution phases
  
• the ability to generate up-to-date security configuration use cases in the documentation.
  

This paper provides a motivating example in the form of Apache Brooklyn [8]. Brooklyn is one of the earliest automated configuration management tools that are now widely used by cloud engineers and designers. It is also one of the most flexible in that not only can be it used to configure cloud functions, storage, and infrastructure but it can also be used to orchestrate and deploy configurations to multi-cloud or hybrid cloud systems. Brooklyn clearly segregates configuration parameters (stored in YAML files) from the implementation and deployment scripts (which ultimately constitute a curated set of templates known as blueprints) that are recommended as starting points for new systems and applications. This separation was one of the motivating factors behind this research. It also led to additional important questions for this paper: how secure are the blueprints as starting points, and how susceptible are they to user misconfiguration errors?

The paper presents related work in Section 2 before presenting an overview of the solution in Section 3. The solution is evaluated against some real cloud application templates in Section 4 leading to discussion and final conclusion in Sections 5 and 6.

Cloud computing has evolved over the past twenty years from a model that fused together the cost benefits of virtualisation, the service-based flexibility of on-demand utility computing, and the always-on, high-availability network access of the internet to create a new paradigm [9]. As cloud services became more popular, both the cloud service providers (CSPs) and various third parties created tools to make designing and managing cloud applications easier, and to encourage new adopters. Apache Brooklyn, as well as being one of the earliest configuration automation tools also offers a combination of features not found in the other common configuration managers such as Chef and Puppet(ref). It is particularly suited as the focus of this research because of how it clearly segregates the configuration from the implementation and deployment stages. It also utilises standardised YAML-based specification languages from the Organisation for the Advancement of Structured Information Standards (OASIS) [10]. There have been numerous studies concerning where security vulnerabilities are introduced into the system life cycle. The publication by [11] discusses the issues of security vulnerabilities in requirements management, while Lamport introduced Temporal Logic of Actions (TLA+) [12] which was a formal specification language that he recommended (and used) to ensure that systems were designed and implemented in a more formal manner. Lamport himself argues that making proofs easier to understand requires only structure and naming [13]. More recently, Behaviour Driven Development (BDD) [14] built on the concept of structure and naming by introducing Cucumber and Gherkin. These are a combination of unit-test software and specification language, respectively, used for requirements gathering and verification. Unlike TLA+, the specification language (Gherkin) is more English-like and allows agile idioms such as user stories to be used to form BDD scenarios which can be directly used in Cucumber as unit tests. In this way, acceptance tests become executable andpart of the automated testing suite. There are also automated tools available for checking code quality, and dynamic and static execution, not to mention security.

User misconfiguration errors (UMEs) are the latest in a long line of security vulnerabilities that need to be addressed. UMEs, according to [3] (using concepts from Amazon Web Services) can be categorized into 6 groups: IAM (identity and access management) misconfiguration; S3 bucket (i.e. storage) misconfiguration; Access key misuse; Cognito (access token) misconfiguration; Elastic Block Store (EBS - i.e. storage) encryption misconfiguration; and security group misconfiguration (i.e. not restricting traffic to open ports).

Although recent technologies provide engineers with infrastructure-as-code (IaC) security testing tools [15] that can detect these types of vulnerabilities in IaC templates, such as Terraform and Cloud Formation code, fixing such errors in the implementation and/or deployment phases of the system development lifecycle is not ideal for a number of reasons. Firstly, research by [16] reported that "requirements and architecture design defects make up approximately 70% of all defects" but "80% of these defects are discovered late in the development life cycle" with a commensurate increase in software costs required to fix said errors in the later phases [16]. Secondly, a study published by Unit 42, an arm of Palo Alto Networks [17] found almost 200,000 IAC templates with the types of errors described herein, validating the research by [16] and demonstrating how easily such errors can be missed. Thirdly, fixing these errors in the later phases of the development lifecycle may lead to the fixes being subsequently overwritten if unpatched designs and/or source code are redeployed. Finally, fixing such errors using late-phase automatic checking tools misses an opportunity to improve developer knowledge, education, and documentation by failing to point out the errors they made in their initial configurations, as the research by [7] reported.

In recent years, configuration and orchestration tools such as Apache Brooklyn [8] have added an element of modeling to the conceptualization phase, supplemented by specification modeling languages from OASIS, such as CAMP and TOSCA [20]. However, as discussed above, the (unintended) consequence of the facilitation of cloud system design is an increase in cloud security vulnerabilities attributable to UMEs, for the most part [21]. This work investigates the use of automated tools to help detect and ameliorate the effects of such UMEs while also attempting to improve the security knowledge and education of users. It does so by building a system termed CACLE - a knowledge-based security verification system, using security principles implemented as logic rules applied as part of an inference engine.

3.2 System Description

The verification system starts with a script written in Python that extracts the pertinent security parameters from functional blocks within the YAML specification scripts. This approach was based on functional decomposition. These parameter sets are then passed on to the inference engine, which checks the parameters for security errors using a set of logic clauses. A schematic of the system is shown in Figure 1.

Schematic of the CACLE system showing how a YAML file is parsed, blocks extracted and verified by the logic engine.

3.3 Graphs and Algorithms

The TOSCA and CAMP specification and modeling languages are good examples of a standard that can be used to provide platform-agnostic designs. However, they tend to have too much ‘syntactic sugar’ [26], especially from the perspective of security verification. To perform a security evaluation of a cloud specification, the system under consideration requires only the details of the functional blocks that will form the constituent parts of the proposed system. This solution was designed to parse the configuration files and decompose them into their constituent elements. The components of each element were then reviewed by the rules-based inference engine which made decisions based on a set of security rules, which in turn generated a report that enumerated the existing security vulnerabilities found in the templates and recommended potential mitigations. A graph representing the data flows is given in Figure 2.

A control flow graph of the CACLE engine showing the possible paths the engine can follow when analysing a parameter block.

The security rules utilized as part of CACLE are represented in an easily comprehensible, executable format that allows inferences to be made based on a security policy. These were based on previous research (eg. [27]) that posited the use of first-order logic statements (FOL) as a suitable mechanism in which to implement security rules as part of a knowledge-based inferencing system. To demonstrate the principle, this project implemented a subset of the rules detailed in Table 1, namely least privilege and work factor. These clauses were implemented using Maude rewriting logic rules, as a more modern and flexible alternative to more traditional formats such as Prolog and Datalog.

Table 1. Security Principles and Clauses

Principle	Logic Clause
Least Privilege	User(X) ∉ (SuperUser)
Separation of Privilege	GoodPW(X) ∧ Goodtoken(Y)
Work Factor	(X ∉ (BadList) ∧ $Length( X ){\rm{ }} \ge N)$
Bell LaPadula	Check (UP, FP)

The initial premise of this research was to investigate whether testing the security of system design at the conceptual- ization phase of the system development life cycle could help reduce the number of UMEs found in modern systems, which ultimately lead to significant security errors. From that perspective, and in comparison with the results published by [17], the results suggest that testing of the configuration phase detects the same degree of security issues as testing at later phases. The differences in the results have been discussed above and can be attributed to variations in the test parameters and the scope of the design encapsulated by the specification template. TOSCA, ultimately, did not live up to the promise of its definition which, as with many other standards created by committees, was poorly supported by actual users of the templates. The result of this was that this research used an older standard as the subject of its tests. More importantly, the lack of standardization in TOSCA templates means that a much more sophisticated - and complex - decomposition application would be required to do similar research.

Another limitation encountered during this study was the Brooklyn blueprint templates. While these files may well be suitable for inexperienced users from a technical/infrastructure perspective, this research clearly shows that they do not meet even the most basic security requirements. Therefore, it is the authors’ opinion that this is a serious omission because the typical user of such templates is often the same inexperienced cloud designer that is the subject of this research. Many blocks did not specify a username or a password. Even when they did specify a name, it was usually the superuser - a selection that countermands the most basic security tenet of least privilege. Additionally, even when a password was specified, it was either in the blocked list of most common passwords [31] or it was too short to meet modern accepted standards (such as those utilized by Unit 42 [17]). In fact, the only passwords that passed the test were the ones included to verify the system by the researchers. Finally, the last test concerned exposed ports. This research tested for any exposure of system ports because they both expose the services available and also provide a route for privilege escalation via published exploits - this is in the same vein as the security group UME discussed by [3]. Ultimately, the two sub-questions raised by the research, namely how secure are blueprints as starting points, and how susceptible are they to user misconfiguration errors, have been addressed by the results above. The default position of the templates is insecure, and because there is no checking or filtering between the configuration files and the blueprints used to create cloud (or IOT) systems, the eventual state is insecure as well. This would indicate a need for a checking solution (such as CACLE) to be interposed between the source files and the deployed files. This would be relatively easy to accomplish in the Brooklyn environment.

Another major omission of both the TOSCA and CAMP templates was the lack of support for roles and access control. This constituted another limitation of the proposed ‘standard’ because, as this research reveals, the limited amount of security information contained in the current templates severely restricts the amount and type of security validation tests that can be carried out on these files. Some work around adding additional security features to TOSCA has already been carried out by [24].

For the final stage - delivering messages to the user - the Maude-based inference engine assessed the security posture of the design specification and encoded it into a character representation. This resulting tag pattern was passed to a Python-based system that provided the user interface and also interpreted the results, producing feedback message(s) that could be read and acted on by the designer. This delivery system leverages the SWIG-based Python- Maude language bindings [32] to transfer the recommendations created by logic in Maude over to Python. In this way, the solution makes use of the best of both systems: using Maude to process logic and perform the inference, and using Python to store and process the text (and take advantage of libraries such as Babel for localization and internationalization), as well as implementing the delivery system to the user via built-in web components such as Flask. Further research is recommended, possibly using groups of users, to identify the best way of expressing and delivering the recommendations.

As discussed in the introduction, this research was designed to achieve three objectives:

• the provision of proactive parameter value checking and validation - focusing specifically on security
  
• the provision of security checks in early execution phases
  
• the ability to generate up-to-date security configuration use cases in the documentation.
  

The findings (see Table 2) indicate that validating at the conceptual design stage finds a very similar percentage of security defects to solutions that detect faults at a much later phase of the system development life cycle (such as those described by [15] or [17]). The results also show that the approach developed by the researchers has the potential to check for errors and produce recommendations much more quickly than existing solutions. Additionally, this could be further accelerated, if required, by the use of parallel processing due to the fact that parameters are checked independently and the recommendation section is the only place the results need to be combined and aligned. As discussed previously, the limitations of the TOSCA ‘standard’ (and in particular the lack of security parameters) restrict the number and type of tests that can be performed at the moment.

Additionally, the use of logic statements to represent security rules means that the range of rules that could be included can be easily expanded and the system is easily extended by the use of standard import functions in the Maude System. It is beyond the scope of this paper to investigate how effective the recommendations produced were. That will be left to subsequent research.