Language Classes for Cloud Service Certification Systems

Transcription

1 Language Classes for Cloud Service Certification Systems Philipp Stephanow, Mark Gall Fraunhofer Institute for Applied and Integrated Security (AISEC), Munich, Germany {philipp.stephanow, Abstract Certification of cloud services aims at increasing the trust of customers towards cloud services and providing comparability between cloud services. Applying the concept of certification to cloud services requires systems which continuously detect ongoing changes of the service and assess their impact on customer requirements. In this paper, we propose eight language classes for cloud service certification systems to facilitate research in design and implementation of these systems. To that end, we draw on language classes developed for signature-based intrusion detection systems and apply them to cloud service certification systems. Keywords-cloud services; certification; languages I. INTRODUCTION Using cloud services entails risks for customers. Most prominent are security-related risks [1] but using cloud services involves further risks, such as legal risks, privacy risks, and risks of violating defined business processes. This leads to the question how a customer can control these risks, that is, how can she unfold potential risks while ensuring that her individual requirements are met? Moreover, if a customer may choose among multiple cloud services for a desired purpose, how can she determine which one fits her requirements best? Mapping a cloud service provider s assertions about a service to individual requirements of a customer is usually not trivial, thereby effectively inhibiting comparison between services from different providers. Also, as pointed out by Anisetti et al. [2], if a customer has to solely rely on a provider s assertions about a cloud service, then a customer s trust directly depends on the provider s reputation. To increase a customer s trust and enable comparability of cloud services, a systematic approach is required to assess whether a cloud services adheres to a customer s set of requirements. We refer to this assessment as certification process which is to be carried out by an independent third party. If the defined set of requirements is satisfied, e.g. derived from controls of a standard such as ISO-27001:2013 [3], a certificate, i.e. a report stating compliance of the audited system with the requirements, is produced. Traditionally, executing a certification process is a discrete task producing a certificate valid for a defined interval, e.g. one year. This implies stability of certification process results during the interval, that is, any other audit performed during the interval will produces identical results. In regard to cloud services, the assumption of stability underlying traditional certification does not hold. A cloud service s attributes may change over time where the changes are not predictable or detectable by a customer. Examples are configuration changes, patches applied to service components, and, in case of public cloud services, a notion of geographical independence where the data center used by a provider for service deployment may vary over time. Applying the concept of certification to cloud service therefore requires a different approach capable of continuously detecting ongoing changes and assessing their impact on customer requirements. To that end, recent research proposes incremental certification which aims at verifying security requirements through continuous monitoring and thus produce meaningful certificates to increase the trust of customers towards a cloud service [4][5]. However, it neglects requirements not related to security, falls short on connecting the industry practice of certification to research approaches, and hardly provides orientation on how to implement a cloud service certification system in the wild. In this paper, we identify language classes for cloud service certification systems to facilitate research in design and implementation of these systems. For this purpose, we draw on language classes developed for signature-based intrusion detection systems (IDS). The objective of signature-based IDS is to continuously check whether known attack patterns have manifested within a defined system. The main contribution of this paper is twofold: Identification of concepts from signature-based IDS reusable for cloud service certification systems, and derivation of language classes for cloud service certification systems based on language classes developed for signature-based IDS. Firstly, we describe the similarities of signature-based IDS and cloud service certification systems, and show how they translate to reusable concepts for cloud service certification systems (section II). We then present a conceptual model for cloud service certification systems which adopts and extends the model presented by Cimato et al. [4] (section III). Thereupon, we use language classes originally developed for signature-based IDS to derive language classes for cloud service certification systems (section IV). We map the derived language classes to the components of the conceptual model, and also identify model components not covered by the derived language classes.

2 II. BACKGROUND AND COMPARISON OF CONCEPTS A. Intrusion Detection Systems Intrusion Detection refers to methods to detect intrusions, i.e. a set of related, illegal actions or events which cannot be detected with methods to control information flow, e.g. firewalls. To gather information about security-relevant events, audit functions are required that generate audit records, e.g. access logs to a database [6]. Signature-based methods assume that knowledge on how an attack manifests, i.e. the pattern of an attack is known before the attack occurs. A signature is a set of criteria with which an attack s manifestation can be detected. Naturally, this requires suitable audit functions generating audit data which corresponds to the criteria of a signature. Describing signature-based intrusion detection more formally, let T T be a target system where T is the set containing all applications to which intrusion detection can be applied. Let P P be an attack signature where P is the set containing all available attack signatures. Let A A be a subset of audit records where A is the set that contains all audit records of a target system T. A relation between signatures P and audit records A has to be defined. We use the symbol as a placeholder for this relation. Elements of the defined relation are required to map to the interval [0, 1]. On this basis, we define a signature-based intrusion detection system, i.e. the system that detects misuse of target system according to predefined patterns, as a function DF which takes as input parameters a target system T, an attack signature P to be detected, and point in time t at which the detection is executed. Neglecting the time DF requires to produce an output, DF outputs an Alert for T at t if the relation between the attack signature P and audit records A exceeds a threshold ϕ (0, 1]. { Alert T DF (T, P, t) = t if P A ϕ otherwise In case P A = 0, no attack signature for the given audit records has been detected. For 0 < P A < 1, an incomplete match of the attack pattern has been computed. P A = 1 signals a perfect match resulting in an Alert. If DF is executed at t 0 and an attack manifests at t 1, the attack will not be detected. Because timing of attacks is unknown, execution of DF should ideally be triggered continuously, i.e. the time difference between triggering two successive executions of DF should become infinitesimal small. More formally, let the time difference between triggering two successive executions of DF be t = t n t n 1. Given DF is executed repeatedly within a finite interval, t becomes infinitesimal small, that is t 0, if the number of executions of DF grows to infinity, i.e. n. B. Cloud Service Certification System Cloud services provide infrastructure and platform services, as well as applications to customers. Customers may use a cloud infrastructure exclusively (private cloud), share it with other customers (public cloud), or combine private and public cloud services (hybrid cloud) [7]. Whether a cloud service adheres to a customer s set of requirements can be systematically assessed by a certification process. This process is to be conducted by an independent party and produces a certificate if the defined set of requirements is satisfied by the service. Requirements can be derived from standards or certificates such as ISO :2013 [3], CSA STAR [8] or EuroCloud ECSA [9], stem from laws, e.g. Federal Data Protection Act of Germany [10], or may be user-defined. Whether a requirement is satisfied or not is determined by evaluating evidence [4]. Evidences are observable manifestations of information about a service, e.g. technical information about the system such as server error logs or source code, legal contract documents associated with the system, and business process descriptions in which the service is incorporated. Analogous to our model for signature-based intrusion detection, we formally define a service S S where S is the set containing all available cloud services. Let D D be a subset of requirements where D is the set containing all available requirements under which S can be certified. Let E E be a subset of evidence where E is the set that contains all available evidence of S. We use the symbol as a placeholder for a relation between requirements D and evidence E whose elements are required to map to the interval [0, 1]. We define a certification system, i.e. the system that executes the certification process of a service, as a function CF which takes as input parameters a service S to be certified, a set of requirements D according to which the service certified, and point in time t at which the certification is conducted. CF outputs a certif icate for S in t if the relation between requirements in D and evidence in E exceeds a threshold ϕ (0, 1]. { Certificate S CF (S, D, t) = t if D E ϕ otherwise If D E = 1, then a requirement has been validated by evidence. If D E = 0, a requirement cannot be validated by evidence, i.e. no relation between d i D and e j E exists. If 0 < D E < 1, then evaluation of evidence results in incomplete requirement s satisfaction. Thus choosing a ϕ < 1 allows for temporary incomplete satisfaction of requirements, i.e. not revoking an issued certificate immediately but to tolerate temporary incompleteness. Krotsiani et al. [5] introduce incremental certification which aims at detecting deviations from defined requirements and report them instantaneously to strengthen the trust of a customer towards a cloud service. Assuming it is unknown when a deviation may occur, execution of CF should ideally be triggered continuously. Analogous to signature-based intrusion detection, we formally note that the time difference between triggering two successive

3 executions of CF is t = t n t n 1. Given CF is executed repeatedly within a finite interval, t becomes infinitesimal small, that is t 0, if the number of executions of CF grows to infinity, i.e. n. C. Comparison To reuse concepts from signature-based intrusion detection for cloud service certification, we have to identify similarities between both fields. To that end, we employ the models DF and CF introduced in subsection II-A and II-B, respectively. 1) T versus S: The set T comprises all applications to which a signature-based IDS can be applied. Examples for such systems are network-based applications such as routers, or host-based applications, e.g. a web server. Generally, valid definitions of a target system T T comprise any hardware and software application, as well as combinations thereof, if means are provided that allow to observe intrusions of T. Cloud services are composed of multiple software applications, e.g. hypervisor, scheduler, load balancer, applications installed in a virtual machine, and hardware components, e.g. physical servers, routers, switches, and disks. We note that any given cloud service definition can be transformed into a target system definition for an IDS, so that S T. 2) P versus D: The set P comprises all available attack signatures. A signature describes manifestations of illegal actions within a target system. As an example consider cookie hijacking where session cookies sent over an insecure connection can be sniffed by an attacker. Using stolen session IDs, attackers can impersonate benign users. If a new requests arrives presenting the same session ID but the Client IP or the User-Agent or both differ from those of a historical group of requests, then there is a high probability that a sidejacking attack occurred. Vallentin [11] implements detection of this signature. D comprises all requirements under which a cloud service can be certified. Similar to an attack signature, a requirement D D describes events within a cloud service that can be observed. An attack signature can be used as a requirement under which a cloud service needs to be certified. In this case, the requirement defines that there are no manifestations of an attack. If events that indicate an attack are observed, the evidence does not completely satisfy the requirement. Thus the relation between the requirement and the evidence is D E < 1. Besides attack signatures, requirements also comprise manifestations of permitted events within a cloud service. Consider for example the scenario where within an IaaS, the data partition of a volume allocated to a virtual machine is encrypted, and only mounted and decrypted once a user enters valid credentials. As the user logs out, the partition is encrypted and unmounted. A requirement may specify that An administrator should only access a virtual machine if no other user is logged into the virtual machine to prevent disclosure of sensitive data to unauthorized personnel. A requirement D D under which a cloud service is to be certified either requires manifestations of events or the absence of events, which describe allowed actions and illegal actions respectively. Thus we note that attack signatures are a special case of requirements, that is, P D. 3) A versus E: The set A comprises all audit records of a target system T. Recall the example of session hijacking: Here, audit records are the session ID as well the values stored in the header fields Client IP and the User-Agent of the historical, valid HTTP requests. Analyzing these audit records enables detection of a sidejacking attack. The set E contains all available evidence of a cloud service S. Drawing on the exemplary requirement from the previous section, evidence of access by an administrator, e.g. via SSH on port 22, and other users, e.g. via VNC on port 5900, to a virtual machine running linux, manifests in /proc/net/tcp. In contrast to audit records, not every evidence E E can be collected automatically, i.e. by technical means, based on cloud services components involved in service delivery. Examples for such evidence are legal documents associated with cloud service. We therefore note that audit records are a special case of evidence, that is, A E. 4) Certif icate versus Alert: CF and DF output a Certif icate and Alert, respectively, if the relation between requirements and evidence exceed the given threshold ϕ. If, for some t, C E = P A, whether an output is produced solely depends on ϕ [0, 1]. For CF, choosing ϕ close to 1, e.g. 0.95, appears to be reasonable since it implies that a Certificate is produced if the given set of requirements are close to be completely satisfied by the evidence. For DF, choosing ϕ close to 1 may lead to a high probability for false negatives, i.e. no Alert is produced but an attack actually took place. As stated in II-C2, the absence of an attack may be required to produce a certificate. In this situation, choosing a ϕ close to 1 may also lead to high probability for false negatives, i.e. no Certif icate is produced because some evidence for an attack was observed but actually no attack occurred. Finding an optimal value for ϕ thus requires to carefully examine the relation between between requirements and evidence. III. A CONCEPTUAL MODEL FOR CLOUD SERVICE CERTIFICATION SYSTEMS This section presents key concepts of cloud services certification systems. We adopt the model presented by Cimato et al. [4], outlining its focal ideas. To be able to map languages classes to this conceptual model (see section IV-B), we add necessary detail on how to model and specify requirements, as well as on how to collect evidence. A. Certificate artifact component This component comprises the meta classes target Of certification (TOC), life cycle, and certificate. Different

4 Property component Attribute Certification process component Evidence Audit function Mapping 1..1 Property Assertion 1..1 Certification Model Certificate artifact component TOC 1..1 Certificate 1..1 Life cycle Figure 1. A model for cloud service certification systems (based on [4]) certificate types are supported, such as cloud specific certificates, e.g. CSA STAR [8] or ECSA Certification [9], as well as certificate not specific to cloud services, e.g. based on ISO-27001:2013 [3]. Also, a certificate s requirements can be user-defined. Each certificate has a life cycle that describes states of a certificate, e.g. issuance, expiration, and revocation. The TOC meta class defines cloud service types, e.g. public IaaS as provided by Amazon EC2. Also, service types combining multiple service and deployment models for service delivery are permitted. B. Property component This component comprises the meta classes property, attribute, and mapping. Cimato et al. s proposal focuses on security properties, e.g. confidentiality. We propose an extension to allow for arbitrary definitions of abstract properties, e.g. legal properties, quality properties, and safety properties, can be used to derive property types. A property is detailed by basic or composite attributes. Basic attributes values can directly be observed by audit functions (for further details see III-C). Examples for basic attribute types are legal texts, e.g. a law where instances are certain articles; safety metrics where instances are notifications of failed harddrives; or security mechanisms where instances are deployed cryptographic hash algorithm. Composite attributes cannot directly be observed by audit functions. The value of a composite attribute is the output of a function performing calculations on inputted basic attributes values, e.g. derivation, concatenation, or averaging. We further extend Cimato et al. s model by mappings which describe how a property is represented by its associated attributes. Mappings are functions that take as input attributes selected to model a property and output a property model. Examples for mapping types are logical inference methods such as forward chaining, or statistical inference methods, e.g. Bayesian inference. As a basic example, consider a property of type safety describing the responsiveness of a web server as one exemplary cloud service component. Responsiveness can be described by multiple thresholds using composite attributes, e.g. average AV G and standard deviation SD of sampling multiple round-trip times RT T. Taking AV G and SD as input, the mapping may use a production rule, i.e. IF RT T AV G threshold AV G RT T SD threshold SD THEN webserver responsive. For a complex example, consider a property of type security describing benign behavior of a SSH server, another exemplary cloud service component. To represent benign behavior multiple attributes are selected, e.g. average of data sent on port 22, number of successful and failed logins etc. A mapping then uses these attributes as input parameters to algorithms such as DBSCAN [12] to profile the server s benign behavior and detect deviations. C. Certification process component This component comprises the meta classes certification model, assertion, evidence, actor, and context. An assertion represents a requirement within a cloud service certification system. To specify an assertion, the actor selects desired property types and instantiates them. Properties are represented by attributes using mappings. Thus an assertion specifies a mapping for each selected property. Drawing on the exemplary property responsiveness introduced in the previous section, specifying an assertion consists of binding values to threshold AV G and threshold SD, e.g IF RT T AV G 30ms RT T SD 3ms THEN webserver responsive. Evaluating an assertion translates to evaluating the set of properties specified by the assertion. For evaluation purposes, the meta classes evidence and audit function are required. Evidence types specify what type of information is to be collected to evaluate an assertion. Naturally, evidence types need to be consistent with the attribute types associated with the property to be evaluated. Consider for example the type monitoring-based evidence where instances may be Snort [13] alerts. Instantiated evidence types are called audit records. Snort alerts, for example, are audit records containing string values which hold the actual alert. As another extension to Cimato et al. s model, we propose audit function types which describe methods how specified evidence can be collected. Exemplary types are manual where evidence is collected by a human expert; API based where evidence can be gathered through querying, e.g. the Amazon Monitoring API called CloudWatch [14]; agentbased where daemons are installed on cloud service components to collect evidence on operating system and application level, e.g. Ganglia s gmond [15]; agent-less where no per-

5 sistent installation of applications on service s components is necessary to gather audit records, e.g. connecting to host over SSH and run scripts by the shell; and network-based where network traffic is monitored by tools such as Snort. Cimato et al. distinguish between three certification models: Monitoring-based, test-based, and Trusted Platform Modul (TPM)-based certification. These three models focus on automatic production and collection of audit records. Albeit a plausible approach, Climato et al. neglect the status quo of certification as currently conducted within the industry: Collection and analysis of evidence to evaluate a certificate s requirements are carried out manually, that is, by human experts [16]. These inspect a system s documentation, interview stakeholders and use other, mostly manual tools. Our approach aims at incorporating the status quo of certification and thus connect existing manual procedures with ongoing research approaches to automatically collect and evaluate evidence. This leads to a new type of certification model termed expert-based certification allowing for manual collection and analysis of audit records. IV. DERIVING LANGUAGE CLASSES FOR CLOUD SERVICE CERTIFICATION SYSTEMS This section derives language classes required for cloud service certification systems. It builds on the similarities between signature-based intrusion detection systems and cloud service certification systems described in section II. The next section briefly describes language classes for signature-based IDS introduced by Eckmann et al. [17][18]. Thereupon section IV-B details how these language classes can be reused within cloud service certification systems. A. Language classes for Intrusion Detection Systems 1) Event languages: An event represents data which serves as input to an IDS. Events relevant to an IDS can originate from various sources, e.g. parsing applicationspecific logs, inspecting network packets etc. This input data is described by event languages which specify a data format of event types, and a schematic description of data s structure. 2) Response languages: If an IDS has detected an attack, a response language specifies actions to be taken. Response language may, for example, trigger an alert notifying an administrator. Thus a response language should allow a developer to implement required actions. One design requirement for responses is performance which has to be taken into account when developing a response language. 3) Reporting languages: In case of an alert, reporting languages are used to represent relevant information about a detected attack, e.g. creation time of alert, time of detection, source and target of the attack (node, user, process etc.), as well as execution traces recorded during manifestation of an attack. Furthermore, a reporting language may assume the role of an event language providing alerts as input Language class Event Correlation Detection (policy) Event Detection (policy) Detection (mechanism) Detection (mechanism): Audit function configuration Detection (mechanism): Audit function analysis Certification Model Description (not derived from IDS) Reporting Response Cloud Service Description (not derived from IDS) Response Conceptual model class Attribute Mapping Property Evidence Assertion Audit function Certification Model Certificate Target of Certification (TOC) Life Cycle Table I MAPPING LANGUAGE CLASSES TO CONCEPTUAL MODEL CLASSES to correlation analysis (detailed below). One example for a standard reporting language is the Intrusion Detection Message Exchange Format (IDMEF) [19]. 4) Correlation language: Analyzing different alerts to detect attacks is referred to as alert correlation. Correlation languages to model relationships between alerts can be implemented using, for instance, Java which provides access to data mining tools such as WEKA [20]. 5) Exploit language: An exploit describes specific steps necessary to intrude into a system. An example for an exploit language is Nessus Attack Specification Language (NASL) [21]. Common exploit languages allow exchanging exploits to test detection capabilities of different IDS. 6) Detection language: Detection or attack languages are used to describe both the steps of an attack, i.e. an attack s signature, and mechanisms to detect these attacks. Examples of such languages are STATL [17], ADeLe [22], RUSSEL [23], P-Best [24], IDIOT IDS [25][26], and LAMDA [27]. According to Meier et al. [6] these languages are not only used to describe an attacks signature but also to specify the detection mechanism ([17][25][24][23]) or include concepts of report, correlation, as well as exploit languages ([27][22]). Therefore, signatures are specific to an IDS, as well as more complicated to describe and thus more prone to error. A recent approach by Borders et al. [28] proposes a declarative attack language for network intrusion detection. It explicitly aims at separating description of attack signatures from detection of attacks to provide interoperability of signatures between different network intrusion detection systems. B. Language classes for cloud service certification systems This section derives language classes for cloud service certification systems and describes how these classes map to conceptual model described in section III. Table I provides an overview of the results.

6 1) Event languages: Event languages describe input events, i.e. audit records, to a cloud service certification system. Declarative languages are needed to represent audit records, thereby affecting both the evidence as well as the attribute class of the conceptual model. Audit records are produced by audit functions. To ensure flexibility and reusability, a clear distinction between policy, i.e. what to collect (audit records) and mechanism, i.e. how to collect (audit function) is required. Thus an event language describing audit records must not determine audit functions. Consider for example C code audits to detect vulnerabilities stemming from the lack of memory safety which may lead to remote exploitation. An expert can conduct a manual code review where review s results serve as input events to the certification system. Such manual methods can be supported or replaced by automatic methods such as static code analysis. While code reviews and static code analysis are different methods of code inspection (audit function), both detect memory safety violations which may serve as audit records for a cloud service certification system. 2) Response languages: Responses within a cloud service certification system are specified actions in case assertions are satisfied or dissatisfied. Such actions may comprise triggering generation of a certificate and present it to cloud service customers indicating compliance with requirements, changing a certificate s state from valid to invalid, trigger revalidation, or alert responsible personnel. Response languages are thus relevant to the certificate class of the conceptual model, e.g. executing the revocation of a certificate, and to the life cycle class, i.e. define reactions specific to life cycle types such as revocation on expiration. Note that in contrast to an IDS, responses within a cloud certification system are not limited to react to detected violations, i.e. dissatisfied properties of an assertion, but also can react on the satisfaction of assertions. Thus executing responses within a cloud certification system are the standard case expected to occur frequently and routinely. 3) Reporting languages: Within a cloud service certification system, reports are generated by responses, in particular to generate certificates. A reporting language thus maps to the certificate class of the conceptual model as it has to be able to represent the information of a certificate. Depending on the report s receiver, e.g. cloud service customer, cloud service provider, or certification authority, views on a certificate s information may vary which has to be considered when developing a reporting language. Furthermore, reporting languages are not confined to human-readable certificates. Recent research proposes a machine-readable representation of security certificates [29]. Machine-readable certificates allow for one cloud service intending to use another one to programmatically determine whether this service possesses the required certificate. 4) Correlation languages: Recall the relation between audit records and property attributes described III-C: Audit records, e.g. code review results, have corresponding attributes. These attributes are used as input parameters to a mapping which outputs a model of the property. Correlation languages support modeling properties. In the context of the conceptual model, a correlation language thus defines the internal setup of a mapping, including e.g. the implementation of machine learning and data mining algorithms. A correlation language can be implemented using generalpurpose languages like Java or Python which provide access to libraries such WEKA [20] or pylearn2 [30], respectively. Similar to response and reporting languages, correlation languages for cloud service certification systems need to take into account that correlating audit records is the standard case, i.e. correlation is executed continuously. 5) Exploit languages: Within cloud service certification systems, the concept of exploit language is not applicable. 6) Detection languages: Following the notion to separate policy from mechanism as put forward by Borders et al. [28], we split the detection language class into two classes: This section elaborates on transferring the concept of attack signatures to cloud service certification systems (policy). In the following section, we will explore languages to describe detection mechanisms. Manifestation of assertions (policy): Manifestations of an assertion are observable through evidence artifacts, i.e. audit records. These audit records correspond to basic attributes which represent a property by means of a mapping. To apply the concept of detection languages to a cloud certification system, recall the basic example of an assertion over the property responsiveness given in section III-C: IF RT T AV G 30ms RT T SD 3ms THEN webserver responsive. Specifying an assertion, i.e. specifying a mapping and attribute values, is one goal of the detection language class. To that end, rich declarative languages are needed to define nested constraints, including conjunctions, disjunctions, negations, sequences, and iterations. In this context, Kearney et al. propose SLA*, a syntax enabling machine-readable Service Level Agreements (SLAs) [31] which is used by Krotsiani et al. to model security properties [5]. Other work use the Event Processing Language (EPL), an expressive temporal query language used in the Esper Complex Event Processing (CEP) engine [32], to model (and monitor) compliance requirements for Service-Oriented Architectures [33][34]. Note the difference between the detection and correlation language class: The former serves to specify an assertion, the latter focuses on describing the internals of a mapping. 7) Detection mechanism languages: Another goal of the detection language class is to describe detection mechanisms, i.e. mechanisms to collect and analyze audit records to evaluate assertions. As for the exemplary assertion IF RT T AV G 30ms RT T SD

7 3ms THEN webserver responsive, audit records need to be collected that correspond to the basic attributes composing RT T AV G and RT T SD. Audit records are produced by audit functions to be configured as specified by the assertion. To keep the example simple, consider that RT T AV G and RT T SD are computed on the basis of ten successive traceroute values. Thus audit records can be obtained through, e.g. using ping -c 10 <ip_adress_webserver>. Collection and evaluation of audit records can be separated and distributed among different tools. Recall our simple example which uses ping to collect RT T AV G and RT T SD : The output of ping is a audit record whose data structure is described by an event language (see IV-B1). Using these audit records as input, a simple script can evaluate the assertion RT T AV G 30ms RT T SD 3ms by parsing the last line of the returned result of ping, binding values to RT T AV G and RT T SD, evaluating the expression, and returning true or false, indicating whether the assertion holds. If carried out manually, i.e. by a human experts, the concept of separating collection and evaluation of audit records also applies: The expert collects audit records and subsequently analyses them. Separating collection and analysis mechanisms enables a cloud service certification system to decentralize collection of audit records and centralize analysis, i.e. evaluation of assertions. Hence, detection mechanism languages can be further divided into two subclasses: On the one hand, audit function configuration languages which are strictly declarative languages describing the collection of audit records, that is, which audit functions are to be deployed and their configurations. Foster and Spanoudakis for example propose to automatically configure monitoring mechanisms based on Service Level Agreements (SLA) [35]. On the other hand, audit record analysis languages to describe algorithms to evaluate an assertion. For example, Krotsiani et al. use EVEREST [36] to perform analysis of audit records which uses EC-Assertion formulas, a first-order temporal logic language based on Event Calculus [5]. The last two classes are not derived from signature-based IDS. They cover the yet unaddressed classes of the conceptual model, Target of Certification (TOC) and Certification Model. 8) Cloud service description languages: Defining the scope of a TOC is not trivial. The challenges lie in a consistent definition which of a cloud service s components which themselves can be cloud services are to be considered by the certification process. Recent research has proposed a semantic service registry for cloud services [37]. Aside from deciding what information is relevant about a cloud service, languages are required to describe cloud services types. In the context of certification systems, a consistent approach to describe cloud service will provide one step towards comparability of services. 9) Certification model description languages: This class provides languages to describe different certification model types, e.g. expert-based or monitoring-based certification model. Descriptions of certification models can be exchanged between cloud service certification systems and thus enable a consistent model definition among these systems. This will contribute to comparability between certificates produced by different certification systems. V. CONCLUSION AND FUTURE WORK In this paper, we introduced language classes for cloud service certification systems to facilitate research in design and implementation of these systems. For that purpose, we reused language classes developed for signature-based intrusion detection systems and applied them to cloud service certification systems. It was detailed how similarities between signature-based IDS and cloud service certification systems translate to reusable concepts for certification systems. Furthermore, six language classes were derived (event, response, reporting, correlation, detection (policy), as well as detection (mechanism)) whose concepts are applicable to cloud service certification, and another two classes (cloud service description, certification model description) are proposed to address remaining classes of the conceptual model introduced by Cimato et al. We are currently working on designing a language for the correlation class, i.e. modeling representations of assertions properties based on attributes. To that end, we investigate audit records natively provided e.g. by Amazon CloudWatch and OpenStack, and suitable data mining techniques to evaluate these records. As part of future work, we want to investigate what requirements a cloud service certification system itself needs to satisfy, and how mechanisms to check these requirements have to be designed and implemented. As this work is part of the NGCert research project [38], funded by the Federal Ministry of Education and Research of Germany, we are planning on evaluating our activities with the participating industry partners. ACKNOWLEDGMENT This work was partly funded by the Federal Ministry of Education and Research of Germany, within the project NGCert [38], Grant No. 16KIS0075K. REFERENCES [1] M. Armbrust, A. Fox, R. Griffith, A. D. Joseph, R. Katz, A. Konwinski, G. Lee, D. Patterson, A. Rabkin, I. Stoica, et al., A view of cloud computing, Communications of the ACM, vol. 53, no. 4, pp , [2] M. Anisetti, C. A. Ardagna, and E. Damiani, Security certification of composite services: a test-based approach, in International Conference on Web Services (ICWS 2013), pp , IEEE, 2013.

8 [3] International Organization for Standardization (ISO), ISO/IEC 27002:2013 Information technology Security techniques Code of practice for information security controls. [4] S. Cimato, E. Damiani, F. Zavatarelli, and R. Menicocci, Towards the certification of cloud services, in 2013 IEEE Ninth World Congress on Services (SERVICES), pp , IEEE, [5] M. Krotsiani, G. Spanoudakis, and K. Mahbub, Incremental certification of cloud services, in SECURWARE th International Conference on Emerging Security Information, Systems and Technologies, pp , [6] M. Meier, N. Bischof, and T. Holz, SHEDEL A Simple Hierarchical Event Description Language for Specifying Attack Signatures, in Security in the Information Society, pp , Springer, [7] P. Mell and T. Grance, The NIST Definition of Cloud Computing, NIST Special Publication, vol. 800, no. 145, p. 7, [8] Cloud Security Alliance (CSA), Security, Trust and Assurance Registry (STAR). certification/. [9] EuroCloud Europe (ECE), EuroCloud Star Audit (ECSA). [10] Deutscher Bundestag, Bundesdatenschutzgesetz (Federal Data Protection Act of Germany). 3.html. [11] M. VALLENTIN, Taming the sheep: sidejacking with bro.. taming-the-sheep-detecting-sidejacking-with-bro/, October [12] M. Ester, H.-P. Kriegel, J. Sander, and X. Xu, A densitybased algorithm for discovering clusters in large spatial databases with noise., in Kdd, vol. 96, pp , [13] M. Roesch et al., Snort: Lightweight Intrusion Detection for Networks., in LISA, vol. 99, pp , [14] CloudWatch. [15] M. L. Massie, B. N. Chun, and D. E. Culler, The ganglia distributed monitoring system: design, implementation, and experience, Parallel Computing, vol. 30, no. 7, pp , [16] S. Schneider, J. Lansing, F. Gao, and A. Sunyaev, A Taxonomic Perspective on Certification Schemes: Development of a Taxonomy for Cloud Service Certification Criteria, in 47th Hawaii International Conference on System Sciences (HICSS), pp , IEEE, [17] S. T. Eckmann, G. Vigna, and R. A. Kemmerer, STATL: An attack language for state-based intrusion detection, Journal of computer security, vol. 10, no. 1, pp , [18] G. Vigna, S. T. Eckmann, and R. A. Kemmerer, Attack languages, in Proceedings of the IEEE Information Survivability Workshop, vol. 366, [19] H. Debar, D. A. Curry, and B. S. Feinstein, The intrusion detection message exchange format (IDMEF), [20] M. Hall, E. Frank, G. Holmes, B. Pfahringer, P. Reutemann, and I. H. Witten, The WEKA data mining software: an update, ACM SIGKDD explorations newsletter, vol. 11, no. 1, pp , [21] R. Deraison, The nessus attack scripting language reference guide, Tenable Network Security, Inc, [22] C. Michel and L. Mé, ADeLe: an attack description language for knowledge-based intrusion detection, in Trusted Information, pp , Springer, [23] A. Mounji, Languages and tools for rule-based distributed intrusion detection, Facult es Universitaires Notre-Dame de la Paix, Namur, Belgium Doctor of Science Thesis, [24] U. Lindqvist and P. A. Porras, Detecting computer and network misuse through the production-based expert system toolset (P-BEST), in Proceedings of the 1999 IEEE Symposium on Security and Privacy, pp , IEEE, [25] S. Kumar and E. H. Spafford, A pattern matching model for misuse intrusion detection, [26] S. Kumar, Classification and detection of computer intrusions. PhD thesis, Purdue University, [27] F. Cuppens and R. Ortalo, LAMBDA: A language to model a database for detection of attacks, in Recent advances in intrusion detection, pp , Springer, [28] K. Borders, J. Springer, and M. Burnside, Chimera: A Declarative Language for Streaming Network Traffic Analysis., in USENIX Security Symposium, pp , [29] S. P. Kaluvuri, H. Koshutanski, F. Di Cerbo, R. Menicocci, and A. Maña, A Digital Security Certificate Framework for Services, International Journal of Services Computing, vol. 1, no. 1, [30] I. J. Goodfellow, D. Warde Farley, P. Lamblin, V. Dumoulin, M. Mirza, R. Pascanu, J. Bergstra, F. Bastien, and Y. Bengio, Pylearn2: a machine learning research library, arxiv preprint arxiv: , [31] K. T. Kearney, F. Torelli, and C. Kotsokalis, SLA*: An abstract syntax for Service Level Agreements, in 11th IEEE/ACM International Conference on Grid Computing (GRID), pp , IEEE, [32] Esper. [33] A. Birukou, V. D Andrea, F. Leymann, J. Serafinski, P. Silveira, S. Strauch, and M. Tluczek, An integrated solution for runtime compliance governance in SOA, in Service-Oriented Computing, pp , Springer, [34] E. Mulo, U. Zdun, and S. Dustdar, Monitoring web service event trails for business compliance, in Service-Oriented Computing and Applications (SOCA), 2009 IEEE International Conference on, pp. 1 8, IEEE, [35] H. Foster and G. Spanoudakis, Advanced service monitoring configurations with SLA decomposition and selection, in Proceedings of the 2011 ACM Symposium on Applied Computing, pp , ACM, [36] G. Spanoudakis, C. Kloukinas, and K. Mahbub, The serenity runtime monitoring framework, in Security and Dependability for Ambient Intelligence, pp , Springer, [37] C. Mindruta and T.-F. Fortis, A semantic registry for cloud services, in 27th International Conference on Advanced Information Networking and Applications Workshops (WAINA), pp , IEEE, [38] Next Generation Certification (NGCert). de/.