The recurring question as to whether regulation is appropriate or obstructive is becoming more and more urgent due to its ever-increasing pressure on businesses in a digitally enabled world. In the year 2017, a decade after the financial crisis, 56,321 regulatory alerts from more than 900 bodies were tracked worldwide. This is highlighted by the chief compliance officer (CCO) of HSBC bank who recently stated that “you have to build an industrial-scale operation just to digest all the regulatory changes” [83].

Certainly, the question if regulation is appropriate or rather obstructive for business is not new. It is valid for many instances in business, with specific attacker models. The attention for business models was first taken care off by the Sarbanes Oxley Act (SOX) of 2002. The so-called SOX paradox describes a situation where the need for compliance and internal controls can reduce the ability of a company to be agile and dynamic in the marketplace. This scenario is paradoxical because the internal controls that must be documented under SOX are meant to help a company perform well and meet its financial goals [196]. The preceding American Patriot Act, which targeted money flowing to terrorists and other perpetrators after the September 11 attacks, had comparable side effects. The question emerged if requirements of costly “Know Your Customer” initiatives were disproportionate to the risk of money laundering and were rather obstructing business with normal bank customers [96]. Similar problems have recently been observed with respect to the General Data Protection Regulation of the European Union (GDPR), by which especially small and mid-sized businesses were overstrained by a plethora of regulatory requirements. Indeed, there are different ways how regulation can obstruct business. The sheer personnel effort and working hours needed for checking and ensuring compliance to regulation, or the burden of keeping track of the abundance of regulations and their implementation are just common examples. However, basic regulatory concepts and control functions in a business, especially internal controls may act obstructive as well. Here, authorization or the assignment of permissions, for instance the right of a process participant to execute a certain process activity, internal control should ideally apply the principle of least privilege. According to this principle, process participants should only have access to the resources that are indispensable to perform their job responsibilities. By this for example access from unwanted staff can be avoided and the risk of fraud can be reduced without being too restrictive. Separation of duties (SoD) is known to be the quintessential internal control practice to avoid fraud. The institute of internal auditors (IIA) calls SoD a fundamental element of internal control for the segregation of certain key duties. The basic idea underlying SoD is that neither one employee nor a group of employees should be in a position to perpetrate or conceal errors or fraud in the normal course of their duties. In general, the principal incompatible duties to be segregated are  [20]  (1) the custody of assets, (2) authorization or approval of related transactions affecting those assets, and (3) recording or reporting of related transactions. For instance, such controls restricting access to business process activities can lead to staff shortages which can directly obstruct behavioral possibilities and restrict the scope of action of a business. Instead of a SoD rule, authorization can also be chosen so restrictively that an SoD conflict cannot occur at all. This however also restricts the flexibility, namely the possible user-task assignments. Hence, both authorization and further rules such as SOD are in control of the process executors. Their utilization expresses the risk a company is willing to take.

Foremost, regulation originates from combating financial crime and fraud. The scale and impact of corporate fraud has increased significantly in today’s digital world. Regulation, fraud and digitization are in a feedback loop in which the latter is the driving force. Its prerequisites are data and processes [152]. Digitization or the digital transformation are often directly connected with the digitization of business processes and (robotic) process automation, i.e., processes are more and more computer-supported. A current McKinsey survey of almost 1,000 top managers supports this. Those surveyed rank “automation and/or improvement of business processes” (besides the digitized integration of customers and digitized innovation processes) among the most prioritized opportunities in the digitized economy. Hence, operations in enterprises are ultimately all attributable to digital representations of processes, be it healthcare, finance, transportation or manufacturing. Therefore, regulation must operate on these processes and the information systems that enact them.

With the digitization and the automation of business processes, it seems as if the “burden” of regulation could be eased if regulation was also automated. Automating the implementation of regulation is seen as the panacea against the ever-pressing regulatory pressure on businesses. In finance it is even reported that today’s “biggest question for bank controllers is how many humans they can replace with bots without compromising compliance” [83]. The idea of also automating the implementation of regulation certainly makes sense in order to keep pace with process automation and make appropriate use of the accumulation of large amounts of data. This development has led to a research focus in the field of business process security at the Department of Telematics of the Institute of Computer Science and Social Studies at the University of Freiburg. Related lectures, research projects, widely published articles and a range of doctoral theses also resulted in the development and publication of the Security Workflow Analysis Toolkit (SWAT) [9, 216]. SWAT is a tool for security analysis of business processes, providing methods for model- and log-based analyses and verification of security properties either from a preventive or a forensic point of view.

Automating regulation can still obstruct the execution of business processes, for instance, when there are no employees authorized to perform a pending process activity at hand. Hence, despite the many benefits of automation, the problem of regulation obstructing business is only shifted to the technical level. Regulation and its related concepts of governance provide ways how to resolve obstructions in order to support business operation. However, such solutions are not easy to find on a technical level. The problem here is that information technology (IT) security aims to remain in a secure state rather than allow the continuation of a business process.

In summary, if a business process violates higher societal or human rights, the process is illegal. Moreover, a business process could also support crime, for instance, money laundering. In both cases, law or regulation is supposed to be enforced in such a way that such processes are detected and stopped. However, as seen above, regulation can also disturb business processes, and its implementation can cause an unjust burden between the owners of the processes or their participants. The automation of the implementation of regulation can finally cause obstructions by inequality and costs. Thus, this thesis does not aim to avoid the legitimate interception of illegal activities but to harmonize the obstructive part of regulation and automated business processes in a security-sensitive way. Here, in particular, the conditions to detect and prevent obstructions in business processes will need to be identified.

This chapter aims to give an in-depth understanding on where these security-related obstructions come from and introduces the context in which to solve them. To motivate the need to automate the application of regulation and show its problems in terms of obstruction, the developments in fraud, regulation and towards process automation will be related in loose chronology to each other. In this way reasons will be identified why regulation acts obstructively and its application needs to be automated. Since big parts of regulation have indeed been automated on the infrastructure and application layer, the focus of this work will be on how to apply regulation on the business layer. It is the layer that allows for an aggregated view on activities that would otherwise appear isolated in the lower layers. In this way, dots can be connected so that fraud schemes can be revealed. In doing so, classic concepts of IT security will be introduced, which, however, can lead to such obstructions on the technical level. The way classic IT security handles obstructions here cannot work in processes, therefore the concept of indicator-based security will be introduced. Based on these findings, the section on the contribution and structure of the thesis will indicate how the problem of obstruction is tackled.

1.1 Fraud in a Digitally Enabled World of Processes

In retrospect, the 2007-08 financial crisis is often seen as the event that brought about today’s plethora of regulatory and compliance measures. The following case of a European Bank involved in the financial crisis represents an exemplary reason for the drastic increase in regulation to fight illegal, criminal, or fraudulent processes after the crisis and also the huge effort and costs needed in solving the case: Roughly a decade after the global financial meltdown, in June 2018, the former CEO of the Anglo Irish Bank (AIB), David Drumm, was found guilty of dishonestly inflating the size of the bank’s deposits by 7.2 billion Euro before its collapse and subsequent bail-out during the financial crisis. He was accused of conspiring to carry out the fraudulent transaction process with his former finance director, his former treasury department manager as well as the former CEO of the Irish Life and Permanent (IL &P) Bank, and others. These men were involved in setting up a circular scheme of billion Euro transactions in which AIB moved 1.2, 2 and 4 billion Euro to IL &P which then sent the money back via their assurance firm “Irish Life Assurance” to AIB (see Figure 1.1).

Figure 1.1
figure 1

Sketch of how the Anglo “Back To Back” fraud process worked

Full size image

The scheme was designed in order to achieve that the deposits come from the assurance company such that they will be treated as customer deposits, which are considered a better measure of a bank’s strength than inter-bank loans. Therefore, it acts as an indicator of the health of the bank, since such deposits show that corporate entities have faith in it [54, 102]. So, in the face of the financial crisis in fall 2008 and the end of the fiscal year on 30th September, the books were faked to mimic achievement of financial goals and palliate the state of the bank to still appear good enough to the government and the European Union (EU) in order to get financial support. Finally, apart from other related legal proceedings, the prosecution that led to the imprisoning of the former CEO of the AIB cost 1.123 million Euro [72] and was one of the longest-running criminal trials in the history of the Irish State.

Still today, “statistics show that economic criminals are increasingly targeting businesses. However, businesses need to be aware that wrongdoing can also come from within.” What the Irish Garda National Economic Crime Bureau conclusively stated on the AIB case is often connected to the notion of “white-collar crime”Footnote 1. Indeed such crime or fraud within the operational procedures in enterprises recorded a tremendous increase in the last decades. Besides the AIB, the Swiss bank UBS suffered from a rogue trader scandal in 2011, which led to an estimated loss of 2 billion US Dollar. Earlier the French Société Générale had a loss of nearly 5 billion Euro caused by shuffling transactions. Similar constellations with inside perpetrators or internal attackers can also be seen in the fraud cases involving the WorldCom, Parmalat or Enron cases, or in more recent scandals, for instance, in the automotive industry or the financial technology industry (FinTech), for example, the “Dieselgate” or “Wirecard”, respectively. Today’s presence of fraud is drastically stressed by the 2018 fraud report of the Association of Certified Fraud Examiners (ACFE), analyzing 2690 cases of occupational fraud that were investigated between January 2016 and October 2017. The total loss caused by the cases in the study exceeded 7.1 billion US Dollars, while these cases only represent a small fraction of the frauds committed against organizations worldwide during that time. The real cost of global fraud is probably significantly higher, especially when the indirect costs are considered, such as reputational harm and the loss of business during the aftermath of a scandal but also simply undetected or unreported frauds. Based on these limitations anti-fraud experts estimate that organizations worldwide lose on average 5% of their annual revenues to fraud (i.e., a total 4 Trillion US Dollars of the Gross World Product in 2017) [41].

One driver for this increase and ever-pressing issue of fraud is digitization. With the digital transformation, the risk of damage, its amount and the velocity of its growth significantly rise, which can be seen from growth in financial processes including private home banking. Clearly, fraud cases would also happen in an analog environment. Indeed, there are records of accounting fraud at Medici Bank dating back to the 15th century [131]. Nevertheless, the increase and size of recent scandals has, at least to some extent, made use of digital technologies, or were only made possible by them. Just by looking at the AIB case, the circular scheme’s high frequency of transactions would not have been possible without the respective digital transaction systems. Even the exchange-traded fund transactions at UBS or the accumulation of transactions at Société Générale that operated directly below the risk threshold would not have been possible to such an extent in an analog system.

1.1.1 Towards Process-Awareness and Process Automation

On a positive side, however, digitization is the driver for comprehension and adaption of business in a process-oriented way. Information systems of organizations are moving more and more from a traditionally data-centric direction that supports business processes, towards a fully process-oriented view. This is because of the necessity to standardize procedures and adapt to changing environments in the course of globalization. The conception of standardized software for steering business processes follows this development. In general, a business process realizes business goals by orchestrating business activities in coordinated sequences. Process-orientation in software-systems already dates back to 1993 when SAP R/3 ERP-System adapted to a process-oriented view by introducing the Business Process Reference Model. However, no explicit control of the process was supported. Since the mid 90s, methods for process automation have created a series of systems, which supported the operation of business processes by an automated execution of partial steps and shaped the notion of “workflow management“. Business process management (BPM) extends workflow concepts with a holistic view on processes in a business context. Workflow and BPM Systems can be subsumed under the notion of process-aware information systems (PAIS). A PAIS is a software system that manages and executes operational processes involving people, applications, and/or information sources on the basis of process models [3]. They include all software systems that support processes and not just isolated activities [82].

Figure 1.2
figure 2

Business process management lifecycle

Full size image

While workflow management can be understood as a supporting technology, BPM is a process-oriented management discipline, which is based on the premise that efficient management and systematic process optimization contribute to the success of an enterprise. Thus, in addition to the (semi-)automated execution of processes, the entire process life-cycle is considered. Figure 1.2 illustrates its different phases. It starts with the specification that includes the modeling of planned process behavior, and contains the implementation in the system landscape of the enterprise, followed by process enactment as the phase in which the process is actually executed. It finalizes with the diagnosis to identify optimization potentials after execution. Along these phases, the process can be captured in different process entities, specifically, the process model, the process execution and the event log. As such, a process is executed by instantiating activities, whereas the resulting activity executions are coordinated. Activities are conducted sequentially or concurrently to each other; their execution is dependent on explicit decisions; and parts of a process may even be repeated multiple times.

Figure 1.3
figure 3

Example of a collateral evaluation workflow (CEW)

Full size image

The following example connects known facts of the AIB investigation to different process entities. Since IL &P was not willing to give unsecured loans because the cash limit of 100 Mio Euro was exceeded, they required a collateral to secure each loan. Therefore, AIB provided cash collateral that usually is safeguarded by several transactions. The involved process defines how a collateral evaluation for a secured loan is handled, with the outcome being the approval of the acquisition. A first activity is to determine the market value of the respective collateral. A decision is then made as to whether the value is correct. If it is correct, the acquisition of the collateral can be approved.

Figure 1.3 illustrates a process model that describes how a collateral evaluation in a financial institution is handled (based on the process description in [24]). It is executed to evaluate, accept, and prepare the safeguarding of the collateral that a borrower pledges in return for a secured loan and originates from the IBM Information Framework on Loans’ process templates on the evaluation of collateral. This model, captured in the Business Process Model and Notation (BPMN), serves for illustration in the further course of this thesis. The execution of the process activities is coordinated within a specific scope, the so-called case. A case represents an instance of the process and is defined by all activity executions that refer to a particular trigger or input for the system whose behavior is described by the process. An event log fulfills the function of a business process tachograph. It records how the process is actually “lived”. Once this process is supported by a PAIS, event data on the execution of this process is collected and may comprise information on the time a particular activity was executed for a case. The latter is related to a user, the requested amount, and the prospective duration of the loan deposit. Each collateral evaluation then represents a case, as part of which the activities of the process are executed. An example of such an event is given in Table 1.1.

Table 1.1 Example event
Full size table

Hence, processes capture the behavioral scope of an enterprise. Figure 1.4 sketches this scope of action. The points schematically symbolize the set of states of a PAIS resulting from performing its business activities, which can involve different users and data and belong to specific processes. The arcs represent these executions of business activities which change the system state. Hence, the arcs correspond to an event or a performed process activity and illustrate possible activity sequences. All combinations of activities, users and involved data are possible here. This could also involve fraudulent behavior.

1.1.2 IT Security Applied on Processes

Hence, in order to also use the potentials of digitization to secure such processes and combat fraud, computer security is applied on processes. Security in business processes represents an interdisciplinary field, which links security mechanisms from the security and business process management research communities [133]. Subsequently, security requirements on business processes are introduced, which allow to be enforced on business processes in an automated manner. Engineering secure processes is a multi-faceted problem, resulting from the different layers and services an enterprise contains. The architecture of an enterprise from an engineering perspective is captured with the so-called enterprise architecture meta-model [176], which can be used to characterize the level of abstraction a PAIS application exhibits [134]. This model divides the support of IT in modern enterprise system architectures in the subsequent inter-layers: The infrastructure layer provides the software and hardware needed to automate the execution of services or business processes respectively. This includes, for example, the required databases, the operating system, virtual machines and protocols (e.g. transport protocols, networks). On top of that, the application layer contains the services and data schemes that are required for the execution of the processes. In this context, service-oriented architectures (SOA) or higher service modes of Cloud and Grid computing are relevant. Although regulatory controls may be implemented on all three layers, such scenarios for the application layer and infrastructure layer have been investigated thoroughly and may be adapted and carried over to new architectures [153]. The upper business layer is the abstraction layer, containing business processes, which codify business goals and its process participants, the business objects and the assets of the company, as well as its organizational structure and guidelines to be followed. It allows for an aggregated view on the enterprise activities such that coherencies and interconnections can be identified, which is eminent for fraud prevention, e.g., to reveal fraudulent schemes. Enforcing the described subsequent notion of regulation and compliance can only be done and justified from this higher business level. Figure 1.5 relates these layers of the enterprise architecture to the unregulated business world, regulation, and its impact on security requirements.

Figure 1.4
figure 4

Behavioral scope of (unregulated) business symbolized as a set of states (points) resulting from performed process activities (arcs)

Full size image
Figure 1.5
figure 5

Enterprise architecture layers and regulation

Full size image

Security requirements are standard principles to enforce security in information systems (IS). Hence, to secure business processes in a PAIS, the security requirements on the business level are subsequently deduced. IT security, or equivalently “computer security”, is basically information security applied to technology. It is based on the three security requirements (tantamount to “security goals” or “protection goals”), which are confidentiality, integrity, and availability. “Control” in classic computer security is basically introduced by access control, consisting of authentication and authorization. An access control mechanism supports confidentiality. It restricts access by authorizing only certain subjects, such as people or (software) agents with the right to access the desired object. An object may be a file, a process or also a process task, activity or transaction. Before authorization, authentication is used to verify integrity, whether the subject is what or who it claims to be. Based on Gollmann, Figure 1.6 depicts this concept, in which a subject, here the user, requests access. After authentication, the reference monitor checks by means of the given access control list (ACL), if the requesting user is allowed to access the desired object [98]. Besides ACL, a further common concept is the Role-Based Access Control (RBAC), which organizes users in groups with well-defined permissions, which is also represented in several NIST standards (cf. RBAC-Level-2 also including SoD). The basis for access control to function properly is, that the corresponding systems and mechanisms are available, such that there is no denial of service (DoS).

A security policy is a statement that partitions the states of a system into a set of authorized (secure) states and a set of unauthorized (no secure) states [33]. It considers all relevant aspects of confidentiality, integrity, and availability. Regarding fraud, unauthorized access may violate integrity. Security policies mostly define safety properties to “keep bad things from happening”, for instance to avoid unauthorized access or that the same person performs two conflicting duties (SoD). In contrast, liveness properties try to “make good things happen”, for example all duties can eventually be performed and required resources are available [13].

Figure 1.6
figure 6

Access control \(=\) authentication \(+\) authorization

Full size image

What is critical to security is the distinction between policy and mechanism. Whereas a security policy is a statement of what is and what is not allowed, a security mechanism is a method, tool, or procedure for enforcing a security policy (e.g., the introduced access control mechanism). Safety properties are typically enforceable, whereas liveness properties are not. Regulation may formulate rules or procedures addressing a range of different aspects and may concern monetary aspects or people authorized to perform specific transactions. To capture these different dimensions and its security requirements, a more fine grained view on processes need to be introduced as well.

The deduction of security requirements on the business process level is structured on the basis of different viewpoints on a business process, namely process aspects. These aspects are connected with security facets defined in several standards, e.g., the ITU-T Recommendation standard for communication security X.810 or ISO/IEC 15816:2002, among which are the more detailed requirements authentication, access control, non-repudiation, confidentiality, integrity, security audit and alarms, and key management, denial of service and availability [154]. Based on the work of Charfi and Mezini [42], relevant process aspects are fourfold. While the behavioral and functional aspect relates to causal and temporal relations between process activities together with structural compositions of processes (often named as the “control flow”), the organizational aspect considers organizational structures and process participants. The informational aspect is about the utilization of data and data flow in processes. Although these aspects are clearly separated by definition, security requirements often comprise several aspects at once.

Based on these aspects, related policies can be classified according to the subsequent general types [153]:

  • Authorization means enforcing access control to ensure that only authorized individuals or roles are allowed to execute activities within a process [180].

  • Usage control expresses conditions that must hold after the access to a resource [179]. Usage control policies can be used to capture regulatory compliance, privacy and data protection requirements.

  • Separation of duties expresses and subsumes constraints associated with the process to limit the abilities of agents to perform activities, eventually reducing risk of fraud [35]. The four-eye rule defines that a critical activity in a business process cannot be carried out by a single subject. Binding of duties (BoD) characterizes the very opposite of separation of duties.

  • Isolation generally says that information must remain confidential during the execution of a process. In other words, there is no information or data leak [11].

Literature of relates to workflows of business processes that encompass authorization and further constraints as “security-aware workflows”.

1.1.3 Security Requirements Obstructing Process Execution

Given these classes of policies and the limitations of their enforceability (depending on whether they encode safety or liveness properties), security can be automated. However, Figure 1.7 partitions the entrepreneurial behavioral space into secure and non-secure states. It shows that the behavioral scope of automated implementation of regulation drastically restricts the behavior. This is because of the identified notion of classic IT security whose policies can only allow authorized and secure or non-secure states of the process execution (the parts on compliance will be explained in detail in Section 1.2).

Figure 1.7
figure 7

Behavioral scope of IT security on processes

Full size image

To illustrate this problem in more depth, the basic means against fraud, namely authorization and SoD, are applied. Figure 1.8 indicates such exceptional situation in a PAIS with authorization. It illustrates how the introduction of security requirements such as authorization and SoD are applied onto a business process and how even further environmental constraints, for example the absence of users due to illness or vacation, significantly minimize the set of users that are able to execute the process.

Figure 1.8
figure 8

PAIS with policies and contextual influences

Full size image

This may finally result in a situation during process enactment, in which no user is authorized to execute a pending activity; the workflow is obstructed. It is key to distinguish between workflow and the overall process here, since a workflow aims at the flow of the process activities, rather than considering all process aspects. Indeed, the obstruction is caused by the organizational process aspect that restricts user access to execute process activities and finally block the workflow. This represents an exceptional situation, in which the process execution, or the respective case, is obstructed because security constraints and user availability block further execution. The enactment or execution of a process becomes impossible because there is a lack of subjects who can execute the process activities and are authorized to do so at the same time. Hence, although the business process security requirements can be automated, their enforcement creates a new kind of obstruction. These requirements can obstruct acting in the behavioral scope of business set by corporate governance (compliant behavior). Figure 1.7 indicates such an obstruction by an arc crossing the border between the secure and the compliant behavior (see obstruction arc), indicating that it would violate security requirements. More specifically, the obstruction arc actually escapes the obstruction. The obstructed state itself is represented by the state preceding the obstruction arc. Similar constellations can also be established with isolation or usage control policies, for example, if no user is available to close an open file. However, due to its common application (e.g., in internal controls), the focus of this work is on security-aware workflows that consider authorization and SoD or BoD constraints, which is sufficient to cause such obstructions.

Etymologically, obstruction means that someone or something is prevented from moving in the direction it is trying to go. The Latin word “obstruere” means blocking an access, to block up, to barricade, or building an obstacle. Interestingly, at the same time this means the object that is obstructed is not totally out of reach.

1.2 Conventional Anti-Fraud Measures

The introduction of IT security on processes can cause an obstruction on the technical level. However, this section shows that regulation itself does not necessarily create such obstructive situations or, if so, offers solutions or ways of circumventing them. This is due to the difference between the digital “world of correctness”, which also embodies classic IT security, and the analog “real world” from which regulation originates (cf. Figure 1.5).

The basic solution to the problem of fraud is clearly that there is a legislation that defines laws and penalizes unwanted deceitful behavior. In Germany, for instance, which has a civil law system (like most of EU countries), fraud and related facts are codified in article 263 and the following of the criminal code (StGB §263 et seq.) that build the foundation for further regulation. On the other hand, U.S. law or further countries with Anglo-Saxon heritage like Ireland developed a law system that originates from the English common law, which is based on precedences.

In the AIB case, the CEO was convicted by unanimous verdict of the two offenses: first, conspiracy to defraud contrary to common law, secondly, false accounting contrary to section 10 of the Criminal Justice (Theft and Fraud Offenses) Act 2001 [16]. The latter consolidates the law relating to dishonesty, theft and fraud in Ireland. Hence, the definition of fraud in law is historically grown and depends on the legislative history of each country. Acts are understood as broad laws that are passed and the regulations are guidelines that dictate how the legal provisions of an act should be applied. Hence, the application of law is regulation.

1.2.1 Post-9/11 and Post-Financial Crisis Regulation

The financial crisis of 2007-08 especially underscores the importance of verifying that organizations operate “within their boundaries’ [3]. Nowadays, enterprises have to face a continuously growing number of regulations and guidelines. Apart from the Basel Accords, which especially address banking regulations, the American federal statue SOX (Sarbanes-Oxley Act) of 2002 probably has the most significant impact. It requires an internal control system (ICS) for billing and external controllers to attest the effectiveness of the system, for example, to preserve the reliability of published financial data. The stir SOX has caused is evident by considering its worldwide adaptions, for example J-SOX (Japan), CLERP (Australia) or the EuroSOX (EU Directive 2006/43/EC on statutory audits of annual accounts and consolidated accounts). Moreover, international standards such as the ISO27k series of the International Organization for Standardization (ISO) have equivalents in SOX and vice versa. Regarding the AIB case, Irish legislation and regulation constantly adapted to the requirements arising from the financial crisis [147]. The offence of intentional falsification of accounts is also captured in EU market-abuse rules (with penalties up to ten years in prison and a fine of up to 10 million Euro) or the American Code of Laws (18 USC Sec. 1005, with penalties up to 30 years in prison and a fine of up to 1 million Dollar). One of the currently most prominently debated regulations is the General Data Protection Law of the European Union (GDPR), which came into force in 2018. It also emphasizes the need for companies to be able to demonstrate compliance with accountability and further principles regarding the handling of information. Enterprises, such as banks, have the duty to act upon these regulations and the governing law relevant in their economic areas and legal space. This means that they also have the duty to take action for themselves to adhere to regulation and ensure that there is no violation of it. They need to integrate it into the way they lead and control their operations. Otherwise, legal action may be taken. In this respect, the increasing regulatory pressure in finance can be stressed as regulators have fined financial firms at least 28.4 billion Dollars for money-laundering and sanctions violations since 2008 and another 9.5 billion Dollars for aiding tax evaders.

Looking at the fraudsters in an enterprise, the ACFE identifies three main aspects that influence a potential perpetrator:

  • Pressure, that is, financial or emotional motivation forcing towards fraud (e.g., AIB has a very negative balance acting as a deterrent for Government and EU),

  • Rationalization, that is, personal justification of dishonest actions (e.g., “I will save the bank (and my position) and keep the Government and EU supporting the bank”), and

  • Opportunity, that is, the ability to execute a fraud scheme without being detected (e.g., the management can override given fraud controls).

Certainly, entrepreneurial measures, for instance fair and proper salaries and a good code of conduct, may lessen financial pressure, strengthen ethics in a company and may make rationalization harder. These two aspects are mainly based on situational or personal reasons. However, the “opportunity” to commit fraud, underlines the need for regulation and its effective implementation in enterprises to establish enough measures and control such that the opportunity to commit fraud is ruled out or at least minimized. Hence, since corporate fraud takes place in the enterprise, regulation provides the following general concepts and controlling functions in business under the overall roof and concept of corporate governance.

1.2.2 Corporate Governance

Governance unifies the regulatory concepts on the entrepreneurial side and sets the frame how fraud measures are established in order to still support business operation. As identified, enterprises not only have an intrinsic interest in security to prevent fraud, but also an extrinsic motivation by given law and regulation. However, enterprises are also keen to comply with accepted standards in industry so they can claim to be compliant. Hence, besides implementing regulation and standards, organizations want to protect themselves and may profit by going beyond what is only “necessary” or “required from outside”.

Figure 1.9
figure 9

Compliance as part of corporate governance

Full size image

Based on Schröder et al. [185], Figure 1.9 shows the bigger context in which subsequently elaborated components can be put, namely corporate governance. In general, corporate governance defines how enterprises and specifically processes are conducted in terms of leadership and control. It is the combination of culture, policies, processes, laws, and institutions that define the structure by which the organization is directed and managed. Compliance management, risk management and the system of internal controls build the three pillars of corporate governance, which aims at an successful supervision of an enterprise. These three pillars are monitored by the board of directors as the senior supervisory body [130]. Moreover, corporate governance requires the board to also establish an audit committee to review and assess the effectiveness of the internal control system, including financial reporting, but also risk and compliance management.

Internal Control Systems play an important role for fraud prevention. The U.S. Committee of Sponsoring Organizations of the Treadway Commission (COSO), which became renowned especially in the course of the SOX, defines: “Internal control is a process — effected by an entity’s board of directors, management, and other personnel — designed to provide reasonable assurance regarding the achievement of objectives in the following categories: (a) reliability of financial reporting, (b) effectiveness and efficiency of operations, and (c) compliance with applicable laws and regulations.” An important component of internal control is the control activities. They represent the specific policies and procedures that shall be applied on or extend business processes. Here, the ACFE report’s set of guidelining questions stresses the procedures and practices of internal control that are key against fraud, indicating especially the importance of authorization and SoD principlesFootnote 2.

The essence of each regulation, the legal semantics of law, is decided through the courts, where regulation goes from theoretical legislation to practical rules for running an enterprise. Compliance means the fulfillment of such rules and obligations, resulting from law and regulation, but also guidelines, norms or corporate governance. Compliance rules initiate the respective policies and procedures resulting from internal controls. For instance, an SoD rule initiates the respective SoD control activity. Regarding the origin of these rules, the “Code of practice for information security controls” from the ISO 27002 standard postulates that it is essential that an organization identifies its security requirements. More specifically, this concerns “the legal, statutory, regulatory and contractual requirements that an organization, its trading partners, contractors and service providers have to satisfy, and their socio-cultural environment.” As with all regulation and compliance requirements, this underlines that organizational compliance is not considered to be an objective, impartial measure. In contrast, it is rather influenced or even biased by different stakeholders, economic interests and, more generally, politics and stems from the context or socio-cultural environment in which the law has evolved.

To assess how to handle the danger of fraud with controls, risk assessment is key. Trust, the (brand) reputation, shareholder value, regulatory compliance (fines, jail time), customer retention, privacy, staff morale or the ability to offer and fulfill business transactions are crucial factors which can be at risk for an enterprise. Risk is commonly understood as the product of the occurrence probability and the impact (or damage) of a given event. The ISO 27002 standard requires “the assessment of risks to the organization, taking into account the organization’s overall business strategy and objectives.” Moreover, “through a risk assessment, threats to assets are identified, vulnerability to and likelihood of occurrence is evaluated and potential impact is estimated.” Identified risk may be accepted (based on minor probability of occurrence or low expected damage), outsourced (for instance by insurance) or handled otherwise. Handled risks are relevant for the system of internal controls. An adequate control to reduce the probability of the risk to occur has to be implemented here, for instance, by adding a respective control activity to a process. The calculation of risks can be done with different methods, such as the failure mode and effects analysis (FMEA).

Auditing has the aim to evaluate enterprises and their processes. Audits are carried out to ascertain the validity and reliability of information about these companies and the associated processes. In this way, it is checked whether the execution of business processes is done within certain boundaries set by managers, governments and other interest groups and stakeholders. Specific rules can be enforced by law or company policies, and the auditor should check whether those rules are being followed or not. Violations of these rules can indicate fraud, misconduct, risk and inefficiency.

Figure 1.10
figure 10

Behavioral scope of enterprise bounded by regulation (circle)

Full size image

Given the concepts of regulation, the behavioral possibilities of an enterprise can be divided into compliant (see the area within the circle in Figure 1.10) and non-compliant behavior. Figure 1.10 indicates this behavioral scope restricted by regulation and complements the explanation on Figure 1.7. Thus, an arc crossing the respective border represents a non-compliant business activity. The German financial regulator, the Federal Financial Supervisory Authority (BaFin), for example, expressly requires the separation of duties in scenarios such as the approval of a loan deposit, for example between activities for calculating and controlling the market value, because assets are affected (cf. IAA SoD Definition). Hence, performing this activity by the same person would represent non-compliant behavior (indicated as arcs crossing the circle). As indicated before, the area of secure behavior is indicated in Figure 1.7. Each obstruction arc indicates a part of a process execution here, in which IT security would block the process execution, whereas corporate governance would allow a solution to continue process in the scope of compliant behavior. Hence, from a compliance perspective, in such an obstruction the process can still be completed by a rational decision, balancing the potential harms of neglecting security against missing the business goals. Hence, an obstruction is the point in the process execution when a decision has to be made whether to stop the process execution or to find a solution based on regulation, risk, and corporate governance to still complete the execution. The frame set for such a solution on the business level is set by corporate governance; it is not about security.

1.2.3 The Need to Support Regulation by Automation

Despite the concepts of regulation to restrict the scope of behavior to avoid fraud, their implementation in businesses is deficient. In other words, the indicated boundary in Figure 1.10 between compliance and non-compliant behavior often does not exist in practice because the intended compliant behavioral scope is often not adequately implemented and controlled. In this respect, the ACFE report states that internal control weaknesses were responsible for nearly half of the frauds that were investigated. In particular, survey respondents were asked for their perspective on the internal control weaknesses at the victim organization that contributed to the fraudster’s ability to perpetrate the fraud scheme. More than 30 percent cited a clear lack of internal controls as the primary issue, another 19 percent stating that internal controls were present but had been overridden by the perpetrator. Here, overriding may set a so called “red flag” indicating a potential suspicious fact for further fraud investigation. In this respect, management review describes the process of management reviewing organizational controls, processes, accounts, or transactions for adherence to company policies and expectations. The other half is led by another 18 percent that were owed to a lack of such management review.

To some extent, this overall lack and override of control and the missing review can be all attributable to the obstructive nature of the implementation and enforcement of regulation in practice. Here, one can differentiate between enforcement from outside the enterprise (e.g., high efforts and costs of law enforcement in the AIB case) or inside the enterprise (e.g., internal audit). The likelihood of regulation obstructing business is even growing with the ongoing digitization. Whereas business processes are more and more automated, regulation is often not. Regulation is frequently still conducted manually or is only partially computer-supported. According to the ACFE, only one percent of the detected fraud is initially detected by IT controls. The majority of fraud schemes is revealed by hints (40 percent), internal audit (15 percent) and management review (13 percent). In practice, internal auditing teams can obstruct operational business for month [92]. Traditionally, auditors can only provide reasonable assurance (cf. ICS) that business processes will be conducted within the specified boundaries. Based on the aims of internal control, they check the controls’ operative effectiveness designed to ensure and maintain reliable processing. If these controls are not in place or otherwise do not work as expected, they typically only check samples of factual data, often in the “paper world” [3]. In this way, they are not able to completely check all relevant process data and therefore do not provide the full picture, such that suspicious activities may not be detected. In automated processes, the manual application of regulation intervenes even more drastically in the otherwise automated business operations. Today, event logs or audit trails, transaction logs, databases or data warehouses record detailed information about processes such that implementations of processes produce event logs of considerable size in practice. For example, around 10,000 loan applications were submitted to a major European bank over a period of 6 months. Because the resulting event log contains more than 200,000 events, a manual analysis of the respective data is no longer possible [40]. Moreover, as the ACFE results propose, the huge amounts of data provided by automation are not adequately used in manual checks. Hence, in the face of process automation, manual fraud controls are too slow, obstructive or simply missing.

The fullness of today’s regulation, automated processes and big data demands the automation of the implementation of regulation in order to use the potentials that lie in automation, for instance to digest all necessary process data. To speed up its application and counteract its obstructive behavior in terms of delaying business operation and demanding high monetary and temporal effort, the logical and necessary step is to automate regulation that acts upon the business processes as well.

1.3 Obstruction by Security?

Despite the deficits identified in the application of IT security on processes, in particular the appearance of obstructions at the technical level (see Section 1.1.3), there is a need for automation of regulation. Because the behavioral space of corporate governance permits more behavior than that of IT security, this should also be taken into account in the automation of regulation.

1.3.1 The Dilemma of Process Security in Following upper Policies

IT security originates from controlling access over data, not process-oriented activities. For instance, if access to data in a database has an error, the transaction is rolled-back. In contrast, unlike in database transaction processing, security policies in processes may not be fully checked before granting access, due to missing information of other related processes such as inter-instance process dependencies or further context specific data, such as user availability. Regarding databases, the ACID criteria (atomicity, consistency, isolation and durability) are not applicable for such long-lived transactions like a business process. Although there are even scenarios and also concepts in transaction processing of rolling back long-lived transactions, this cannot be in the interest of a business process execution.

In analogy to this and the need for a business process to run through, a short excursus is given by means of an example from sports. Since 2018, there has been a video referee at the Tour de France, the Spanish Vuelta and other famous cycle races who can intervene retrospectively. This video commissioner has access to all cameras and can review and evaluate any situation at any time, rewind, zoom in and assess if a first suspicion is justified, for example a rider pushes a rival aside. Of course, you cannot stop the race at the Tour de France. Consequences can only be taken after the race; after crossing the finish line. Then, a team of race control and referees looks at the respective selected material and then, it has to decide what to do. Hence, during the race there is only a suspicion. After the race, the decision is made and consequences can be taken. Ideally, one would like prompt, binding decisions here. Analogously, business processes need to operate and only after “crossing the finish line” or reaching the process goal can the security be fully assessed. However, if there is a problem, one would like to promptly identify it and act accordingly. This could mean to change the process or take further steps after an identified violation. This could clearly also mean that damage already occurred, if for example payments have already been done during the process.

Based on these considerations, the assumption security is based on changes. Indeed security in business processes should not only consider the protection of objects like in classic computer security but also take upper policies set by corporate governance into account. This represents a paradigm shift; moving away from trying to achieve or sustain protection goals, such as confidentiality and integrity, or simply “keeping bad things from happening” towards an end-oriented view on security in business processes where not so much a violation of security is a problem but at the end a compliant result must exist to eventually “make good things happen”. Hence, whereas classic security stresses the safety property, business process security emphasizes the liveness property.

1.3.2 Indicator-Based Process Security

Altogether, the classic understanding of security does not fully apply to the context of business processes. The concept of classic security clearly builds the essential basis for business process security. However, based on the identified reasons, this so far policy-based classic security concept needs to be extended. Common ways of compliance management to resolve obstructive situations are setting red flags or delegation. If there is an obstruction due to an SoD conflict imposed by regulation, it is possible to assign substitutes that do not have the managerial level of the initial assigned users. Then, the delegator indicates an appropriate substitute based on his risk assessment of the delegatee. This represents a compliant solution to resolve an obstruction, for example based on the BaFin regulation (Finanzdienstleistungsaufsicht [94]). Considering best practices of internal auditors, it is a well-known means to set red flags for fraud, for instance when a control is overridden due to an obstruction. Red flags are signs that indicate both the inadequacy of controls in place to deter fraud — in the sense of not being effective but also in obstructing the process — and the possibility that some perpetrator has already overcome these weak or absent controls to commit fraud. These indicators can then be used for detection and prevention and ultimately aim to lessen the risk of the execution of business processes. Hence, indicators allow to reduce the risk of a fraud to happen and at the same time support the completion of the process. This can also be stressed by looking at the etymological meanings of the respective concepts. Etymologically, “to comply” means to fulfill something and originates from completing (lat. complere), i.e., bringing something to its very end. Also the conformity to rules is often named equally to compliance, meaning to be in accordance or strong similarity to something. This notion generally is less strict than the meaning of security, originating from the Latin terms “se-” (engl. without) “cura” (engl. care) and can be translated as “free of care”. In the literal sense, the inherent goal of security is to accomplish a carefree state, i.e., to avoid a state that may cause worries. Hence, whereas security literally tries to avoid risk, compliance tries to keep given rules while allowing to take a certain amount of risk and worries into account to fulfill the overall goal of completion (or “bringing it to its very end”).

Due to the limitations of classic security in processes, the policy-based security concept is supposed to be enhanced with an indicator-based view, thereby allowing to better represent and capture the frame set by corporate governance. The area of secure behavior is supposed to be widened towards the compliant behavior (or shifting the respective border in Figure 1.7). Using indicators in business processes is not uncommon, for example Process Performance Indicators (PPI) or Resource-Behavior-Indicators (RBI). The focus of this work is to use indicators in order to find a security-sensitive solution to obstructions.

Table 1.2 Comparison of Freiburg approaches addressing security before, during and after process execution: addressed, () partially addressed, not addressed
Full size table

Table 1.2 displays different works in the Business Process Security Group in Freiburg that contribute to this perspective on security. For instance, Lowis analyzes compliance based on given rules and workflow models. Stocker [189] provides a way how to reconstruct process models from event logs that are able to indicate rare deviating suspicious behavior. Moreover, Zahoransky [215] uses simulation to investigate if control activities imposed on single core processes are a problem in performance in the context of entire business process architectures (cf. PPI). Syring [193] defines a framework how to decode legal code into (semi-)formal rule that are machine-readable and can be applied in an indicator-based way. Wonnemann [214] proposes a way to check (unwanted) flow of information based on models. All these approaches aim to automate the implementation of regulation to some extent. However, they have so far not addressed the problem of runtime obstructions during process enactment in processes and its practical consequences and how this conflict between business and security goals should be handled.

1.4 Contribution and Structure of Thesis

Automation is no panacea against regulation acting obstructive. Adequate and effective application of regulation builds the basis against fraud. However, there is no way to avoid automation when IT methods are used to generate competitive advantages. An obstruction results from introducing IT security on business processes, particularly authorization and further security policies such as separation of duties. Handling situations that obstruct the business process are key, because, besides the business harm, not handling them in an automated manner would contradict the overall intention of automating security to speed up the secured process. Hence, the aim of this thesis is to specify obstructions on a technical level and provide automated security-sensitive solutions that take the frame set by cooperate governance into account. By learning from obstruction handling in corporate governance, indicators are identified and an indicator-based security is proposed, which allows to benefit from process automation and process event data. In detail, this dissertation provides the following contributions Footnote 3:

  • This work will comprehensively examine the conflict between the goals of IT security and business process executions and present the concept of an indicator-based security in business processes.

  • With the systematic examination of existing literature on security-related obstructability in PAIS concerning the process design, runtime, and auditing phases, requirements to analyze, detect, and handle obstructions will be derived.

  • With the SecANet  approach, an encoding technique that can capture all aspects of a security-aware process into a formal representation and integrate indicators as costs to explore security-sensitive behavior will be systematically developed.

  • The model-based OLive-M  approach represents a SecANet-based technique to revive an obstructed workflow and find a security-sensitive way to complete its execution.

  • With OLive-L, this work presents an approach to handle an obstructed execution trace of events based on a SecANet  and a log containing information on past executions.

Figure 1.11 shows the structure of this work. Chapter 2 examines the state of the art with regard to security-related obstructability in PAIS, such as workflow satisfiability and resilience. Thereby, requirements for analyzing, detecting, and handling obstructions will be derived along the phases resulting from the enforcement of security properties and the BPM lifecycle. Besides introducing the notion of “obstructability” and “completability” of security-aware workflows, various possibilities of how, in particular, logs can be used to obtain indicators will be examined.

Figure 1.11
figure 11

Structure of thesis

Full size image

Chapter 3 builds the central part of the thesis. In addressing the requirements for obstructability analysis (ROA), it is primarily concerned with the modeling of obstructions in security-aware workflows. For this, it will first explore the ways to model processes, in particular, the modeling of the control flow. Based on the selection of an ordinary Petri net model (P/T net) as the method of modeling, a security-aware Petri net representation, the SecANet, will be developed. The general idea of the SecANet  modeling is to “flatten” the organizational aspect of a security-aware process specification that subsumes the process model and the policy specification into the model representing the functional and behavioral aspects. That way, a so-called “obstruction marking” can identify and capture obstructions. Moreover, indicators can be assigned to the task- and policy-related Petri net elements as costs. For the evaluation of the SecANet  approach, its Petri net-specific properties will be investigated. Moreover, the formal correctness of the SecANet  method will be proven by examining the behavioral preservation of the original inputs (i.e., language preservation). To take cyclic workflow behavior into account, the concept of policy re-enactment will add cyclic functionality to the so-far acyclic SecANet  encoding. The developed SecANet  formalism can be regarded as a target metamodel of security-aware process specifications that creates a basis for further analysis. Accordingly, Section 3.2.6 will subsume SecANet-based satisfiability and obstructability checks as SecANet  soundness and show further extensions to facilitate analysis. An experimental evaluation will compare soundness checking runtimes with typical satisfiability-related approaches. The discussion will then examine the computational complexity of the SecANet  encoding and sketch possibilities for extensions. With the introduction of SecANet+, the integration of additional inputs that further constrain the execution of tasks, for instance, counting constraints or user absence (resilience), will be made possible. Chapters 4 and 5 will use the SecANet  encoding to handle and resolve obstructions. Across all these chapters dealing with approaches and solutions within the described problem context, the security-sensitive costing will play a crucial role in enabling the consideration of indicators. In order to address the requirements for specification-based completability (RSC), Chapter 4 proposes a model-based technique to complete obstructions. Thereby, the OLive-M  approach will interpret the question how to complete an obstructed process as an optimization problem. Based on the examination of suitable methods, an integer linear programming model that optimizes the SecANet  marking equation and its security-sensitive costs will realize the OLive-M  approach as a way to deal with obstructions. In contrast to the exhaustive exploration of all possible markings (i.e., computing the marking graph), the experimental evaluation will underline the “lightness” of this technique to resolve obstructions. The discussion will then indicate how the approach can be used to also analyze satisfiability or resilience. Chapter 5 focuses on log-based completability (RLC) and considers the obstruction as an execution trace in the context of process event logs. The realization of the OLive-L  approach will incorporate methods of process mining and machine learning techniques to propose solutions that represent the nearest match of successful executions to escape an obstructed state. To show the applicability of the OLive-L  approach, the evaluation offers experimental results based on event data synthesized from SecANet  execution sequences. In the course of the discussion it will be sketched how logs may be used for the model-based approach and vice versa.

Chapter 6 summarizes the work and explains its significance by considering the contributions and its applicability. The work concludes with extensions that could be envisaged.