Security governance as a service on the cloud

Abstract

Small companies need help to detect and to respond to increasing security related threats. This paper presents a cloud service that automates processes that make checks for such threats, implement mitigating procedures, and generally instructs client companies on the steps to take. For instance, a process that automates the search for leaked credentials on the Dark Web will, in the event of a leak, trigger processes that instruct the client on how to change passwords and perhaps a micro-learning process on credential management. The security governance service runs on the cloud as it needs to be managed by a security expert and because it should run on an infrastructure separated from clients. It also runs as a cloud service for economy of scale: the processes it runs can service many clients simultaneously, since many threats are common to all. We also examine how the service may be used to prove to independent auditors (e.g., cyber-insurance agents) that a company is taking the necessary steps to implement its security obligations.

Introduction

Cyber-security is a major concern for today’s economy and society. It is a particular problem for small companies since they can lack the means to defend themselves [16]. First, they might not be technically savvy enough to understand the security problem and understand the measures that have to be taken. Second, small companies might not be able to invest in security solutions from their working capital. Third, their IT infrastructure is often very minimal, for instance, many small companies still manage their client database, containing client personal data and credit card information, with desktop spreadsheet software. This all makes small companies particularly vulnerable to cyber-security attacks.

Compliance, which is the process of respecting government regulation in the operation of business, is another factor of risk for companies. Obviously, compliance regulations are enacted in the interests of consumers and society, but the implementation of compliance within a company is costly, as is the failure to be compliant. The European Union’s General Data Protection Regulation (GDPR) on the protection of personal data is a good example of the challenge. The GDPR applies to all companies, irrespective of their size and business sector, and requires companies to take specific protective measures for client personal data. Repeated failure to adhere to GDPR can incur severe penalties, e.g., up to 4% of annual turnover. Like for security, small companies are struggling to conform to GDPR [6]. It is useful to tackle security and compliance together as both are concerned with controls on information handling.

Security Governance deals with the definition and implementation of processes to mitigate security risks. In an era of zero-day exploits, companies must accept that attacks will happen and some will succeed, so governance processes deal equally with prevention (security software installation, training, etc.), detection (data leaks in the Dark Web, etc.) and recovery (password resets, informing clients of data leaks for GDPR, etc.). Security governance also applies to protection of physical assets from theft or damage [14].

This paper presents the design and implementation of a security governance service. Processes are automated on a cloud service on behalf of client companies. The cloud is chosen since the processes are put in place by a security expert, and processes run in a secure infrastructure independent of the client. Further, for economy of scale, processes may run on behalf of many clients. The model presents a company with a dashboard showing risk for their company. Risk-mitigating processes are manually or automatically started in response to detected threats.

A particular feature of our approach is that processes may request attestation evidence from clients to show that they are following the steps requested by the processes. Evidence is collected at runtime, and can be used by external parties like auditors, insurance providers, etc. Thus, even in the event of a successful security attack at the client site, the client can still show that steps to prevent the attack had been taken.

The remainder of this paper is organized as follows. “Approach to security governance” section motivates the design of the governance model. Some processes are presented in “Governance processes” section, and the model’s implementation in “Implementation” section. Related work is presented in “Related work” section. Conclusions and future work are discussed in “Conclusions” section.

Approach to security governance

The objective of the security governance model is, following the identification of assets, to implement processes to secure these assets. This approach to security is expounded by frameworks like the IEC/ISO 27000 series [5]. In our case:

• The model implements a risk management service that permits a company to track security risks and instructs on actions to take to mitigate risk. The service is managed by a trusted third party. This party can follow risk in real time, and like an asset manager surveying a financial portfolio, trigger processes to alter overall risk.

• We seek to automate governance processes as much as possible – several examples are presented in “Governance processes” section. Process automation in the enterprise environment is known to reduce errors and increase efficiency [7].

• Permit attestation of the implementation of risk-mitigating processes to third parties such as government auditors verifying compliance or to insurance agents verifying that contractual actions are being taken. An example of the latter might be the installation of anti-virus software that is required by a cyber-protection insurance policy.

• Exploit commonalities in risks faced. For instance, all companies face risks relating to malware or reputation, and the remedial actions are the same. This enables the trusted third party to reuse the same processes for many clients.

• Be simple for small companies to use, and require no special technical expertise on their part. Moreover, the processes must represent a range of risks faced by such companies. Many different risks have an equally fatal impact on the company. For instance, for a hair salon we contacted considered risk linked to data loss to be as important as risk linked to malfunction of hair-drying equipment. Small firms appreciate a package solution for risk, rather than having to delegate different risks to different consultants.

Actors

As illustrated in Fig. 1, there are three roles in the model: clients, governance providers and auditors.

Fig. 1

Actors of the governance model. The arrows denote data flows. The governance provider offers a trusted environment in which it tracks risk for the client company and furnishes proof of implementation of risk-mitigating actions to auditors

A governance provider hosts the risk management service for client companies. He is an expert in risk and helps the client to identify assets, threats, vulnerabilities and actions to undertake to mitigate risks. This endeavor is facilitated by the fact that many risks are shared by all clients, e.g., theft, ransomware virus, etc., even if the risk level differs between clients. The provider runs a service that tracks the risk level of the client.

The client is any small or micro company that avails of the provider’s risk management service. He is not assumed to have any expertise in security or compliance. Apart from regular discussions with the provider about the assets, threats and risks, his interaction with the service is limited to receiving alerts and instructions, and filling out Web-forms.

For each client, there may be distinct actors who fulfill different roles within the company, and who therefore execute different tasks. For instance, the office manager has different responsibilities to a security guard. Both execute different tasks of the client: the office manager executes tasks relating to defense (e.g., install anti-virus, etc.), the security guard is responsible for doing rounds, verifying the clean desk policy, etc.

An auditor is any independent party who wishes to see the status of the implementation of risk-mitigating actions by the client. In practice, this role is taken by a government auditor wishing to verify the implementation of compliance actions within the company, or by an agent of a cyber-insurance company who wishes to verify that prescribed risk-mitigating processes were implemented by the client following a claim made on its behalf.

Service components

There are two parts to the service offered by the governance provider. A dashboard front-end presents the client with an overview of the current risk state and actions to execute; a back-end engine automates the risk-mitigating actions for the client.

Dashboard

An example of an initial dashboard defined for a small company is illustrated in Fig. 2. Please note that for reasons of brevity, several assets and risks are omitted. The dashboard has an easy-to-interpret tabular format. Following an ISO 27000 like approach [5], and with the help of the provider, the client defines the assets he wishes to protect in the first column. Identified threats are listed in the second column and vulnerabilities that make these threats credible are listed in the third column.

Fig. 2

Simple dashboard example

A risk level value along with some risk condition that explains the risk level are given in columns 4 and 5. A risk mitigating process, composed of actions, for the threatvulnerability is mentioned in column 6 and the impact of execution of the process on the risk level is given in column 7.

The table is deliberately descriptive in a first step because it represents the level of detail employed in an interaction between a client and governance provider. The trigger conditions and the actions are programmatically defined in a second stage by the provider. The result is shown in Fig. 3 – a screenshot from our service.

Fig. 3

Panel of the Governance Service

The dashboard in Fig. 3 contains the risk variables defined for the client. Two classes of variables can be defined:

• Client-related, e.g., assurance_purchased, data_breach_signaled, etc. These variables can only be updated by processes deployed on the engine.

• Provider variables relating to some service that the provider handles, e.g., ransomware_alert_issued for a service that tracks CVEs for malware. The maintenance of these variables is the responsibility of the provider. He may change the value of these variables which can trigger a process as a consequence.

Engine

The engine runs in an isolated and trusted environment, under the supervision of the provider. The engine executes programmed actions for notification, confirmation by clients or custom tasks. Access control ensures that a process action for a client may only be executed by that client. The environment stores client risk values and these may not be directly modified except through the execution of actions.

A process is composed of a series of actions. The types of process actions in the governance model are the following.

• A notification action alerts the client of some task that needs to be done, and can contain detailed instructions. Concretely, the notification arrives by email or phone, and the action might be the renewal of an insurance contract, a reminder to empty the cash register at the end of the day or instructions on how to patch a CMS application.

• A confirmation action is what a client uses to confirm in a provided Web-form that that he has undertaken a certain manual task. Execution of this task is used for attestation, i.e., to demonstrate whether the client has executed his attributed tasks.

• An inform action is used by a client to communicate with some other user. For instance, this could be used by a manager informing employees about the Internet usage policy. In this way, an employee cannot later claim unawareness in the event of a dispute.

• A burden of proof actionBoP permits a client to provide specific proof of the implementation of some task for attestation. For instance, if the task is the installation of anti-virus software on his PC, the proof might be the screenshot of the folder with the software or the list of running applications containing the anti-virus software.

• A custom action is any other type of action that the provider may care to implement. One example is a service task that scrapes Web sites for indications of a data leak involving the company (e.g., via haveibeenpwned.com). Another example of a custom action is an on-line training course.

• An expression action updates the dashboard’s client variables, e.g., for a process accompanying the round of a security guard, the expression actions updates the time of the guard’s last check.

As mentioned, one objective of the model is to permit attestation of the implementation of governance processes by a auditor. Two classes of information are available for this purpose. First, the status of process execution. This consists of the list and times of processes executed, as well as the state (current action and previous execution times) of currently executing processes. Second, data uploaded through BoP actions also constitutes attestation evidence.

An overview of our architecture is presented in Fig. 4. Governance security processes run on a process server on the cloud. The service can be used simultaneously by different clients, so there is a user management database. The service provider may include other useful services such as a CVE (Common Vulnerabilities and Exposures) feed that is used to trigger client processes when a relevant virus alert is detected. As will be explained in “Implementation”section, programs called compliance agents (CA) are placed within the client IT infrastructure. These are responsible for uploading data to server processes through BoP actions.

Fig. 4

Processes run on engine in a trusted environment

Governance processes

Processes are programmed using the Business Process Model and Notation (BPMN) standard from the Object Management Group [18]. The language is now widely used in industry. The primary purpose of this language is a means of specification that is accessible to all stake-holders of a company, and not just the IT developers. This explains its largely shape-based, non textual, syntax. This argument is particularly relevant to security and compliance since the specification of security policies and their enforcement depend on end-users, IT administrators, management, legal and HR.

BPMN specifications are not just about modeling. Many platforms exist to execute BPMN processes. Open-source BPMN platforms include Bonita BPM [4], Red Hat’s JBoss BPM suite jBPM¹ and Camunda².

The tasks of the BPMN processes do the actual work. Each BPMN platform has its own types of implementation tasks, though they are generally similar. The platform used for our implementation is Camunda, and has the following types of tasks, illustrated in the small process example of Fig. 5.

• The first task, “Email Alice”, is a message task. This is used to implement the Inform action of the governance model.

  Fig. 5

  

  Simple BPMN process

• A service task is an automated work item task. The Camunda platform allows Java or Groovy code to be linked to this task and executed when the task is activated. Our implementation uses this task type to implement notification and custom actions. An example custom action that we developed is a training task that presents video content to users. Expression tasks are also implemented as service tasks.

• The third task in the process of Fig. 5 is a user task. In our implementation, we use this to implement confirm actions within a Web form. These forms are the means by which users may manually update variables. The task is executed by a user logging into the system, loading and submitting the Web form.

Another useful feature of BPMN is the swim-lane concept. This is a row that is drawn over tasks, and to which a user or group of users is assigned. In Fig. 5, user Bob is attributed the three tasks. The swim-lane denotes authorization and responsibility. The owning user or group is the only user allowed to execute tasks in the swim-lane. Swim-lanes are thus the means that access control is implemented, and in particular, how different tasks can be attributed to employees with different roles within a client company.

Returning to the example of Fig. 2, one of the asset-threat pairs identified was theft of the credit card reader. The proposed process is to store the item in the cabinet each night before leaving. The process deployed in our framework is shown in Fig. 6.

Fig. 6

Process for cabinet locking

The start event of this process is a BPMN timer event. This event is programmed to start a process at a designated or at regular intervals. In this case, the process is scheduled each evening. The first task of the process is a notification task. This task type sends a message to the client. The message text and receiver identifier are specified as parameters to the task. The second task is a user task, and represents the action that the client is requested to do. The user task is a Web form with has explicatory text about what the client is requested to do, and a confirm button that the client uses to claim that the task has been done. This is the platform’s manner of noting actions done on the client side.

Sample process portfolio

For a micro or small company, several risks are recurrent. One is loss or theft of passwords. Another is data leakage, where either they are the subject of the leakage, or their client data that they manage gets leaked. In the latter case, the dispositions of the GDPR come into play. Another risk is for micro-companies is a bad on-line review. Though this risk is not traditionally considered a security risk, all micro-companies insist upon this risk since a bad review can have a serious impact on their business. In any case, security is about protecting assets – and reputation, though intangible, is definitely a company asset.

In helping a client company, the governance provider selects process descriptions from a database of processes, and customizes them for the client. Given the aforementioned risks, one process deployed could be a micro-training process, c.f., Fig. 7. Note that this process has a message start event, meaning that the process can be started by another process that sends it a message. The governance provider may also start it manually on the client’s behalf. This process has a custom training task that, in this case, displays a video about password management. This message event approach allows security training to be delivered at the most pertinent moment, e.g., by a process that detects a password leak sending a message to trigger the training.

Fig. 7

Micro-learning process can be triggered by a process managing password leaks

A process that checks for data leaks is shown in Fig. 8. It contains a service task that integrates a call to the REST interface of the haveibeenpwned.com site. The addresses to check for are stored as process variables. In the event of a data leak detection, the end event is a message event that triggers the GDPR process shown in Fig. 9.

Fig. 8

Process watching for Data Leaks

Fig. 9

Process triggered when data leak detected

The GDPR process takes dispositions required under the GDPR. The process has a parallel treatment. In the top part, a sub-process has tasks to inform members of the company about the leak, followed by a sub-process to inform clients. In the bottom part, a timer is triggered which runs for 72 h – the limit within which clients must be informed of the leak.

Other processes developed include a reputation check process that is triggered by a timer event. Currently, this contains a service call to the Google Places API to check for any negative reviews. Obviously, calls to any sentiment analysis site could be integrated. Another class of processes that we are working on are for data backup and restoration. While our server runs processes to explain how backups and restorations can be done, and which inform the client to trigger a backup, the actual backup and restoration are done using scripts within the client IT infrastructure.

Burdens of proof

Recall that a primary goal of our framework is to help demonstrate that processes are being implemented, and consequently security is being enforced. One reason for outsourcing process execution to a trusted third party is that it maintains a trace of process executions. For instance, when the confirm action is executed in the second task of Fig. 6, the server notes that the client handled the cabinet lockup request and notes the time. If ever a theft is signaled, the client can use this process execution history to demonstrate the actions taken prior to the theft.

However, sometimes stronger proofs than client confirmation are required to ensure that an action has been performed by the client. The scenario to implement is demonstrated using BPMN in Fig. 10 using the swim-lanes. The system administrator installs anti-virus software. The next task executed is the responsibility of the auditor whose role is to validate the installation. Only then can the system administrator execute the next step of the process – informing management in this example.

Fig. 10

Requirement for validating action has been performed

Our goal is to automate the role of the auditor. To this end, we extend the BPMN model with annotations called burdens of proof (BoP). These are a form of intermediate event within a process. A BoP acts as a synchronous rendezvous point; process execution can only continue once evidence has been provided to a burden of proof and then validated. Figure 11 shows a simple example with a burden of proof element. A client installs an anti-virus software and then informs management. Before doing so, a proof of installation must be sent to the server. Without this, process execution does not continue to the notification task.

Fig. 11

Anti-virus installation process with BoP

The service provider and company define a policy for a BoP that defines the evidence that must be furnished to the BoP. In our current implementation, this policy is expressed using Decision Model Notation (DMN) [12], and an example is shown in Fig. 12. DMN is a notation for decision modeling from the Object Management Group. Each decision is represented by a table, with input arguments and corresponding outputs. The inputs are taken from a process’ variables at runtime.

Fig. 12

DMN Decision table for antivirus installation process

The simplified example policy in Fig. 12 specifies evidence needed for demonstrating that an anti-virus was installed. The policy is based on a variable count that represents the number of recognized anti-virus applications installed on the client site. This variable is input to the policy object’s decision table. Policies can have any number of input columns and there is a single output column to indicate whether the process can continue or not. In this policy, the BoP allows execution to continue so long as there is at least one recognized anti-virus application. The syntax of the cell expressions is defined by the tools we use in our implementation³.

Implementation

We use Camunda’s community edition⁴ as the process engine of our platform. As shown in Fig. 13, Camunda supports BPMN 2.0 and DMN 1.1. Camunda is an open-source platform and is one of the leading BPMN platform providers around. The platform has a REST interface for manipulating process descriptions, process instances, variables and users. Camunda is packaged as a servlet and we run it over an Apache Tomcat Web server container.

Fig. 13

Process Platform Stack Architecture

For the process platform, the choice was made to use customizable off-the-shelf components. Our process environment runs in parallel to the Camunda/Apache server over a MERN stack (MongoDB, Express, React and Node). This environment manages the process descriptions, c.f., Fig. 14, with a link to an editor for creating and editing descriptions, a deploy and un-deploy function, as well as a start process button. Process deployment and starting are implemented using Camunda’s REST interface for process control. In addition, the portal has a window with the list of currently running processes and active tasks that a user has to execute. Another window offers metrics on process descriptions and instances.

Fig. 14

Screenshot of process descriptions

The portal’s process editor, c.f., Fig. 15, is an extension of Camunda’a open source editor⁵. The extension includes support for burdens of proofs and the customized task types – training task, notification task, etc.

Fig. 15

Screenshot of process editor

As mentioned, compliance agents are deployed on the side of the client organization. We currently run them as protected Ruby scripts, but since they communicate over HTTP, any technology can be used to implement them. The platform runs an agent daemon that receives HTTP calls from compliance agents and forwards them to the pertinent BoP element to trigger evaluation.

A compliance agent used for the anti-virus example is shown in Fig. 16. It is just a Ruby script that verifies the list of installed programs and compares to the recognized list of programs – McAfee and BitDefender in this example and submits the resulting count value. On Mac OS platforms, the list of installed programs is given in the /Library/Receipts/InstallHistory.plist file.

Fig. 16

Compliance agent for antivirus example

Though we have extended BPMN with BoP elements, this extension is actually implemented using other BPMN elements. That is, a process from our framework that contains BoP elements is rewritten in pure BPMN as soon as it gets deployed. This approach has the significant advantage that we did not need to modify the Camunda process engine, and that processes from our library can run on any BPMN 2.0 platform.

In the BPMN process transformation that occurs on deployment, each BoP is transformed into the sub-process task shown in Fig. 17. One of the task types supported by Camunda is a Business Rule Task. This task evaluates a DMN decision table. As mentioned, each BoP has an argument DMN policy decision table and this is what gets linked to the business rule task. The policy outputs true or false, depending on the evidence provided. A negative decision leads to the BoP generating an error event which is caught by the second sub-process in the Figure. Finally, the BoP gets triggered by a receive message event. This is triggered by a message sent to the platform, which is triggered by the HTTP request made by the corresponding compliance agent on the client IT system.

Fig. 17

Implementation of the BoP element

The compliance agent must be protected from tampering so that evidence is not fabricated. Currently, we run them as setuid enabled programs on our POSIX platforms, where the user identity attributed to the programs is that of an administrator of the process platform. The only drawback is this does not handle the threat of a malicious IT administrator. This is the subject of current work. Among the possible solutions, the Intel SGX (Software Guard Extensions) mechanism allows user code and data to be placed within memory enclaves [3]. Enclave memory cannot be directly accessed by code running in kernel mode. This means that we can run code that is safe from manipulation by kernel-level code, and thus, safe from manipulation by malicious administrators. An example of its use for secure databases is presented in [15].

Related work

BPMN has been used on several occasions for modeling security in the context of business processes [8]. The motivation for this is the undoubted success that the language has as a modeling and orchestration tool within industry, but since the language only specifies functional requirements, security needs somehow to be added to the process descriptions. The general approach is to extend BPMN with security features.

Two examples of this are SecBPMN [17] and SecureBPMN [9]. SecBPMN extends BPMN with annotations for accountability, audit, authenticity, availability, confidentiality, integrity, non-repudiation and privacy. The result is a modeling language for secure business processes. In addition, the authors also develop an icon based query language in [17] that is used to verify security properties of a process. A key disadvantage of extending BPMN in this way is that compatibility with BPMN platforms is lost. SecureBPMN is an earlier effort, with fewer annotations. In our work, though we have added a new BPMN element – the BoP – there is a rewriting rule to transform this to pure BPMN. Further, our concern is not to add security to existing BPMN workflows, but to use BPMN to implement many of the security processes that companies need to implement.

In [1], the authors do present BPMN patterns for GDPR, e.g., consent to use data, right to access data, right of portability, right to withdraw, right to rectify, and right to be forgotten. These are extremely useful; in our work, we seek to implement a larger portfolio of security processes.

Another axe of related work is the use of cloud services for security. The Cloud Security Alliance (CSA) provide a definition of Security as a Service (SecaaS): a cloud infrastructure that provides security services such as identity management, data loss prevention, Web and mail security, Business Continuity and Disaster Recovery, as well as security information and event management. This underlines the trend that outsourcing security to third-party providers is now a viable option for companies. Nevertheless, the introduction of a new third-party has an implication on risk, as companies require that the cloud service be secure. In [19], the authors present a security model for securing cloud services. All data objects stored by the cloud server have annotations that can be used to express privacy and access control properties. These permit services to be constructed in a security-by-design approach. Such an approach could be applied to this paper’s service.

Yet confiding security and data to a cloud service can be perceived as risky and many seek better transparency between cloud customers and providers [13]. Notably, while security techniques have improved, techniques aiming at security transparency and mutual accountability have lagged behind. In [11], a model for formalizing the trust relationship with the cloud service is presented. This is important since local IT infrastructures delegate control and pass sensitive data to the service. We could leverage this model for passing burden of proof documents to the process server in future work.

The cloud is often seen as the ideal host for security operation centers [10]. However, these are designed with larger companies in mind. Small companies are often not economically attractive. As a result, they adopt generic solutions like standard anti-virus software and firewalls installed by their telephony provider. Obviously these are important solutions, but security also requires process that are customized for each company. We contend that the high degree of process automation possible and the overlap of risks between companies create the economy of scale needed to make the service a viable one.

Adamant is another framework for security automation [2]. The goal is to be aligned to the ISO 27001 standard. The UML language is used for describing assets in a catalog. A state machine model then describes asset states, e.g., for compliance, and the Spring expression language is used for this. States evolve as actions are reported to the system. Our work complements Adamant by focusing more on the operational processes that must be put in place for governance.

Conclusions

This paper has presented the design and implementation of a model for security governance. Increasingly, it is necessary for companies to demonstrate implementation of security processes so that they do not become liable in the event of an attack leading to a data loss, and so that they can demonstrate compliance with legislation like the GDPR. These requirements led us to a cloud solution where the participation of a trusted independent party is leveraged for its competence in the security domain as well as for proof of process implementation.

The service uses the BPMN language to express security and compliance processes. These are executed in real-time on a process engine on the cloud. BPMN is extended with annotations for burdens of proof. These represent points in the process where evidence must be furnished and validated for execution to continue. These constitute proof of implementation of the process for management and auditors. The BoP elements are implemented in BPMN, so processes from the library can be run on any BPMN platform.

Future work includes investigating implementation techniques for compliance agents that protect their execution in environments where the administrator is hostile.