A Metamodel to integrate Control Objectives into Viewpoints for EA Management Dierk Jugel1,2, Christian M. Schweda1, Christina Bauer1, Jawed Zamani and Alfred Zimmermann1 1 Reutlingen University, Herman Hollerith Zentrum, Böblingen, Germany {dierk.jugel,christian.schweda}@hhz.de {christina.bauer,alfred.zimmermann}@reutlingen-university.de 2 University of Rostock, Rostock, Germany dierk.jugel@uni-rostock.de Abstract. Enterprise Governance, Risk and Compliance (GRC) systems are key to managing risks threatening modern enterprises from many different angles. Key constituent to GRC systems is the definition of Controls that are imple- mented on the different layers of an Enterprise Architecture (EA). As part of the compliance aspect of GRC, the effectiveness of these Controls is assessed and reported to relevant management bodies within the enterprise. In this paper we present a metamodel which links Controls to the affected elements of an EA and supplies a way of expressing associated assessment techniques and results. We complement the metamodel with an expository instantiation in a cockpit for Con- trol compliance applied in an international enterprise in the insurance industry. Keywords: governance, compliance, control, enterprise architecture, cockpit 1 Introduction Modern enterprises are faced with threats that originate from different sources. Differ- ent varieties of cyber security attacks are on the rise, as recent analyses of the threat landscape show [1]. In addition to cyber security-related threats, environmental factors also pose a risk to modern enterprises operating on a global scale. Architectural risks result from the current set-up of the enterprise and its supporting IT. Finally, legal risks arise from the variety of laws and regulations originating from different sources. Reg- ulations differ in target audiences, with the General Data Privacy Regulation (GDPR) [2] with a broad target and the Versicherungswirtschaftliche Anforderungen an die IT (VAIT – insurance-related requirements for the IT) [3] with a narrow target issued by the German regulator for the financial industry. The Enterprise Governance, Risk and Compliance (GRC) [4] system is established in modern enterprises to diligently handle aforementioned types of risks via cultural, organizational, procedural or technical means, so-called Controls. Objectives of these controls [5] are to • avoid a risk by changes in the business model; • reduce the probability of a risk; or to 2 • limit the impact of a risk. All types of risks lead to Controls that operationalize the externally imposed rules and regulations. The Controls are implemented into different ‘elements’ of the enter- prise, amongst others into business processes as additional checks, into business appli- cations as additional logic, and into the technical infrastructure as additional compo- nents. In this sense, the implementation of a control can be seen as attached to the en- terprise as a whole or a relevant element within the Enterprise Architecture (EA). In the GRC system the Controls are not only designed, but the enterprise is regularly assessed with respect to compliance with and effectiveness of these Controls. In larger enter- prises, these assessments are conducted on different levels: detailed for subject matter experts and aggregated to provide high-level indications for the senior management. In this paper, we establish an integrated metamodel for Control assessment related to the EA. This metamodel is based on the foundations of GRC, Control modeling, and Control assessments as revisited in Section 2. In Section 3 we present the requirements that lead to the metamodel along ‘user stories’. We instantiate the metamodel (see Sec- tion 4) for an exemplary application in the context of an enterprise from the insurance industry in Section 5, and display a prototypic Control Compliance Cockpit supporting different viewpoints on Control assessments. In Section 6 we reflect on the status of the ongoing research and elaborate on the link to risk management. 2 Related Work COBIT [6] provides a comprehensive framework for governance and management of support for Enterprise IT. In this context, IT-relevant goals of internal and external stakeholders are considered. COBIT provides a process framework complemented by internationally accepted IT process-related requirements. COBIT is based on five basic principles to ensure optimal value of IT. The key principles are the distinction between governance and management, the comprehensive, holistic approach, and the coverage of the entire enterprise. In the process model, governance processes take top priority. These processes set policies and monitor their compliance. The section below deals with management processes which deal with planning, procurement and implementa- tion. These processes are monitored by other management processes and assessed against the given governance guidelines. These monitoring processes are related to per- formance and compliance, internal control and compliance with external requirements. The ISO 2700x series considers Controls with the focus on information security. ISO 27001 [7] delineates requirements for the evaluation and treatment of information se- curity risks tailored to the needs of businesses. It provides a framework for developing and maintaining an effective information security management system (ISMS). It will provide IT protection goals in terms of confidentiality, integrity and availability of in- formation. An ISMS in practice consists of the governance view(-point), the risk view and the compliance view. These viewpoints are employed to determine the protective measures considering the different concerns of the enterprise’s stakeholders. The gov- ernance perspective relates to the implementation and adherence to objectives, the risk 111 3 perspective on the identification, assessment and treatment of risks and the compliance perspective on the compliance with regulatory, contractual and legal requirements. The MEMO approach [8] for enterprise modeling also considers GRC as a key topic. MEMO addresses different stakeholders of and concerns with respect to the enterprise via an integrated set of modeling languages that cover the concerns and are based on one meta-language. MEMO ControlML [9] provides support to stakeholders in the ef- fective and efficient conduct of an assessment of the internal control system and the surrounding organizational action system. The core of ControlML [9] is the Control Objective, which is a desirable condition for achieving an endangered business objec- tive. Control Objectives can be derived from business goals and aggregated. They also determine Reference Objects that are objects to be controlled according the objective. The Reference Object is an abstract concept and represents any concept to describe an enterprise (e.g. business units, applications or technologies). ControlML is comple- mented by MEMO MetricML [10], which focuses on assessing controls. The Indicator concept described in MEMO MetricML defines the configuration of the indicator as well as the measured values and the date of measurement. The configuration consists of an algorithm for translating attribute’s values of Reference Objects into a measure- ment and the frequency of calculation. The ControlML and MetricML can be combined to cover Control design and Control assessment related in an enterprise model. Innerhofer et al. [11] provide an overview of how IT-related risks in enterprise ar- chitectures can be analyzed and evaluated. This approach provides a detailed process of security management. Because the metamodel of the enterprise architecture does not allow risk analysis and assessment, the metamodel has been enhanced with a security information meta model. This meta-model contains relevant elements that reflect the entire security process. Based on the metatype Model Element, which can accept all elements of any kind of enterprise architecture metamodel, the connection to the enter- prise architecture is ensured. There are also elements for the business security objective, security requirement, threat, threat list, incident, security control, and security solution. Grandy et al. [12] describe the mapping of the metamodel of Information System Security Risks Management (ISSRM) and Enterprise Architecture Modeling Language (EAML) using ArchiMate. They extend EAM to support a security risk-oriented design of an EA. This approach supports the identification of business and information security assets. There is also a proposal to model the treatment of the risk, especially in relation with the value of the risk treatment and with the rationale behind the elements of the architecture. However, there is no support in identifying the threats and vulnerabilities related to the elements of the architecture. It thus provides a mechanism to support the risk model of service companies regarding the security of information systems. The audit on the application of security risk management to service systems is under inves- tigation at the time of this research. Another approach of Gericke et al. [13] describes a situational method that enables the implementation and integration of a GRC solution. It consists 21 methodological fragments that include the conceptual, strategic, organizational, technical and cultural rollout aspects. It also defines method configurations for different stakeholders. This approach involves only the practice descriptions of the methods and not a true GRC implementation, which requires further research on ‘build’ and ‘evaluate’. 112 4 3 Concerns Insurance companies are exposed to a variety of risks through their core insurance and asset management activities. Including underwriting, operational, strategic but also credit, market, business, liquidity and reputational risks. Internal GRC systems as means to actively govern and manage these risks are therefore prevalent in the insur- ance industry. We take the perspective of an internationally operating insurance group to derive requirements for our metamodel based on ‘user stories’ reflecting typical stakeholders within the insurance group. The insurance group has a holding structure with over 60 Operating Entities (OEs) represented in more than 70 countries and serv- ing more than 100 million customers. The IT necessary to support the business of the OEs is partly operated by a captive shared service provider, while certain OEs with special situations reserve the right to maintain a local IT. In this context not only effi- cient and effective but also resilient and above all secure information processing is a key capability for the organization. These demands derived from the company’s busi- ness model and regulatory requirements are translated into harmonized Global Archi- tecture and Global Security Standards which are mandatory for all OEs and governed centrally in the holding. These Standards mirror Controls that are designed specifically to purposefully mitigate the identified risks. In this context different stakeholders raise concerns with respect to the GRC system, subsequently documented as ‘user stories’: Concern 1: Senior management in the holding needs to get an overview of Control compliance and effectiveness throughout the OEs to understand the overall risk expo- sure of the company and to enter into the planning dialogs with OE senior management resulting in OE-specific target setting. Concern 2: Subject matter experts in the holding need to understand the status of Control compliance and effectiveness for a specific control area throughout the Group. The experts use this information perform ‘what-if’ analysis to evolve the Controls and get in touch with OE counterparts to derive means of effective implementation. Concern 3: Senior management of an OE needs to understand the Control compli- ance and effectiveness in their own OE also compared to the aspiration levels and cur- rent levels of assessment as achieved throughout the company. This allows senior man- agement to leverage best-practices from other OEs to improve weak Controls. Concern 4: Subject matter experts in individual OEs need to understand the defined control objective and their threshold values and see current effects of completed or on- going measures in order to control the achievement of the specified goals. 4 Solution The metamodel presented in this section addresses the different concerns and view- points on Control assessments as outlined above based on selected approaches from literature – foremost ControlML [9] and MetricML [10] – adapted to the usage context. The metamodel in particular addresses the need for overview on the Group level (see Section 3) by enabling the Control Compliance Cockpit elaborated on in Section 5. The key concepts of the metamodel are introduced in Fig. 1 and subsequently detailed. 113 5 Fig. 1. Metamodel ControlObjectives – adapted from [9] – represent the functional objectives to control guidelines or regulations. Abstract specifications are operationalized into concrete, ar- chitecture-related objectives. ControlObjectives define what to control, but not how to assess their effectiveness. The AssessmentTechnique – adapted from Indicator as pre- sented in [10] – designates the procedure of assessing and of interpreting the results in terms of ‘good’ and ‘bad’. The Indicator from [10] both represents the assessment pro- cess and the result thereof – represented in our case by the concept Measurement. The AssessmentTechnique also defines necessary calculations, intervals of measurement and thresholds for various effectiveness levels to derive a ‘score’. In our setting the scores range from ‘very good’ to ‘very poor’ with an extra score for missing values. In contrast to [9], we assume that ControlObjectives are hierarchical and, hence, all of them covered by one AssessmentTechnique can be (virtually) grouped to a high-level one. ControlObjectives are represented in Viewpoints according to ISO Std. 42010 [14] to facilitate decision making. This aligns with the understanding of the term technique according to the ISO Std. 42010; each AssessmentTechnique also defines a way of rep- resenting the corresponding Measurements in a viewpoint. We employ the approach outlined in [15] according to which a technique can be applied to a viewpoint in terms of an additional layer adding/changing visual variables of existing symbols. For the Control Compliance Cockpit, we employ color-coding on the different layers. Each Measurement is determined with respect to an element of the EA which is con- trolled by the corresponding ControlObjective. This element of the EA is represented by the concept RefObject – adapted from ReferenceObject [9]. Examples of RefObjects are OEs or business processes. A Measurement is unique for a given combination of RefObject and AssessmentTechnique at a given point in time. Different time-stamped Measurements may nevertheless exist for different points in time. Different types of ControlObjectives can be distinguished: • A DirectControlObjective targets the EA as a whole. • A TypedControlObjective is dependent on EAObject that reflects the facet under consideration. This EAObject is an instance of a previously determined type, e.g. ITDomain. 114 6 The metamodel reflects this distinction by sub-typing ControlObjective (see Fig. 2) Fig. 2. Specializing ControlObjectives AssessmentTechniques can be distinguished by the way their corresponding Meas- urements are determined. In particular for grouped high-level ControlObjectives no di- rect assessments may exist, but their results may be derived from more granular Meas- urements. In line with this we distinguish two types of AssessmentTechniques: • DirectAssessmentTechniques acquire results by self-assessments or using technical tools for measuring. • DerivedAssessmentTechniques calculate results based on the results of already per- formed assessments. For such techniques the individual rules of calculation, e.g. us- ing minimum rule, are specified. The metamodel reflects this by sub-typing AssessmentTechnique (see Fig. 3). Fig. 3. Specializing AssessmentTechniques The different kinds of ControlObjectives and AssementsTechniques can be com- bined independently as we show in the exemplary instantiation in Section 5. 5 Control Compliance Cockpit The metamodel described in Section 4 is the basis for the Control Compliance Cockpit of a company from the insurance industry. This cockpit provides viewpoints giving a comprehensive picture of selected ‘cyber risks’ pertaining to the company – covering cyber security and architecture-related risks. The assessment results with respect to the 115 7 globally mandated Controls mitigating the ‘cyber risks’ are displayed in a web-based cockpit application, whose main user interface is depicted (in an anonymized manner) in Fig. 4. The user interface displays the company’s OE presence as a world map, iden- tifying ‘Country OEs’ with the corresponding countries and adding non-country-spe- cific OEs (‘Global OEs’) to the passe-partout of the visualization. Fig. 4. Control Compliance Cockpit – World Map Viewpoint The World Map Viewpoint serves as entry point for user interactions. The viewpoint allows to add a layer representing a selected ControlObjective via a color-coding. The legend at the bottom of the visualization reflects the scoring system of the respective AssessmentTechnique ranging from ‘very good’ (dark green) to ‘very bad’ (red), adding two more colors for ‘not available’ (dark gray) Measurements and ‘not in focus’ (light gray). Latter color indicates countries in which there is no operating OE. The slider on the right side of the visualization directly influences the thresholds specified in the As- sessmentTechnique. When these thresholds are adapted, the AssessmentTechnique re- calculates the scoring and the color-coding is adapted. Via this mechanism, subject matter experts are supported in ‘what-if’ analyses. The Control Compliance Cockpit presents different ControlObjectives and Assess- mentTechniques, and combinations thereof reflecting the different concerns as intro- duced in Section 3. Table 1 gives an overview of the combinations employed, preclud- ing their detailed discussion in the following. Table 1. Examples for combinations of ControlObjectives and AssessmentTechniques DirectAssessmentTechnique DerivedAssessmentTechnique ExtV DirectControlObjective CSAE IntV ITAge TypedControlObjective ArcDebt ITDebt 116 8 The number of internet-facing vulnerabilities (ExtV) provides a number of vul- nerabilities exposed via internet-facing IP addresses, taking into account the severity of the vulnerability and the time, for which this vulnerability has been exposed. The num- ber of internal vulnerabilities (IntV) provides a corresponding assessment for the vul- nerabilities being exposed on IP addresses being available from the internal network. The assessment techniques are direct, based on a technical vulnerability scanner. IT Ageing and IT Debt relate to structuring concepts of the EA, typing the Control- Objective to the ‘areas’, in which the non-compliance is measured. Examples of such structuring elements are different hierarchical types of ITDomains: • Infrastructure Domains reflect prevalent operating environments for the IT, e.g. data center, workplace and mobile. • Technical Domains reflect typical use cases for ‘commodity’ IT, e.g. operating sys- tem, database management system and application server. The IT Ageing (ITAge) computes the distribution of IT Assets over the releases of a used technology. A ‘left-hanging’ distribution is thereby considered an indication for ageing, a ‘right-hanging’ distribution for actuality of the current IT Asset based with respect to that technology. A technology in turn is assigned to an ITDomain reflecting its prevalent operating environment and use case. The IT Debt (ITDebt) computes the distribution of IT Assets of Standard to non-standard technologies. The IT Debt is ex- pressed in the amount of money needed to migrate from non-standard technologies to their standard counterparts is considered the corresponding IT Debt. The aforementioned AssessmentTechniques are direct in terms of Section 4, i.e. their measurements are results of direct assessment. Based on these values the results of fol- lowing two high-level AssessmentTechniques are derived. Cyber Security Attack Exposure (CSAE) provides a cumulated view on the expo- sure to cyber security related attacks resulting from organizational, procedural and tech- nical vulnerabilities that can potentially be exploited by an attacker. The value of an OE’s measurement is derived from the assessments of constituting control objectives. The score of the measurement is determined by applying a minimum operation to the scores of the constituting AssessmentTechniques, reflecting a worst-case assumption with respect to exposure. The Architectural Debt (ArcDebt) provides a cumulated view on potential costs and disadvantages that result from non-compliance to Global Architecture Standards and missing investments into IT rejuvenation. The value of the OE’s measurement is derived from the assessments of constituting control objectives. The Architectural Debt for an ITDomain combines operating environments (as the top-level) and use cases (at the child-level), e.g. ‘operating system on workplace’. The value is determined by ap- plying a summation over the values of the constituting AssessmentTechniques. The number of internet-facing vulnerabilities, the number of internal vulnera- bilities and the Cyber Security Attack Exposure all consider the OE as a whole, mak- ing them DirectControlObjectives in terms of Section 4. The Architectural Debt and its constituting IT Ageing and IT Debt are conversely TypedControlObjectives bound to the EA concepts ITDomain and Technology and can be assessed for any instance of these concepts, e.g. the aforementioned ITDomain ‘operating system on workplace’. 117 9 Aforementioned ControlObjectives and AssessmentTechniques can be described via a model (see Fig. 5) instantiating the metamodel from Section 4. The TypedControl- Objectives employed reflect their ‘binding’ to ITDomain and Technology, as discussed above, via a parameterization with the corresponding types. This allows to leverage for the actual instances of Architectural Debt, IT Ageing and IT Debt the existing rela- tionships between the related Technology and ITDomain instances from the EA model. Fig. 5. Exemplary instantiation of ControlObjectives and AssessmentTechniques 6 Conclusion In this paper, we addressed the relationship between Governance, Risk and Compliance (GRC) and Enterprise Architecture (EA). We presented typical concerns from a practi- cal setting in Section 3 and used them to derive a metamodel (in Section 5) that is ca- pable of integrating Control Objectives with the structuring concepts of an EA. This metamodel accounts for the relevant pre-work, revisited in Section 2 in particular the work around ControlML [9] and MetricML [10]. The exemplary instantiation of the metamodel in the context of the Control Compliance Cockpit piloted in an insurance company (cf. Section 5) shows applicability and versatility of the developed concepts. The Control Compliance Cockpit with the layers that are built on the Assess- mentTechniques provides evidence that the DerivedAssessmentTechnique very well fits the need of company stakeholders for aggregated measurements with respect to Con- trolObjectives. The use of TypedControlObjectives in turn showed that a parameteriza- tion of control assessments by respective structuring concepts of the EA fits the needs of subject matter experts within the company. In type-theory, a TypedControlObjective is considered a ‘template class’ with one formal parameter bound to a concept from the EA metamodel. Further research is needed to show if and how relationships between concepts from the EA metamodel systematically translate to relationships between AssessmentTechniques. Having mul- tiple formal parameters for TypedControlObjectives might prove of use in this context. 118 10 References 1. European Union Agency for Network & Information Security (ENISA): ENISA Threat Landscape Report 2017. (2017). 2. European Parliament: Regulation 2016/679 on the protection of natural persons with regard to the processing of personal data and on the free movement of such data. Off. J. Eur. Union. L119, 1–88 (2016). 3. Bundesanstalt für Finanzdienstleistungsaufsicht (BaFIN): Versicherungswirtschaftliche Anforderungen an die IT. (2018). 4. Proctor, P.E., Wheeler, J.A., Pratap, K.: Definition: Governance, Risk and Compliance. (2015). 5. Bundesamt für die Sicherheit in der Informationstechnik: BSI Standard 200-3: Risk Analysis based on IT-Grundschutz – Version 1.0. (2017). 6. ISACA: COBIT - A Business Framework for the Governance and Management of Enterprise IT. (2013). 7. International Organization Of Standardization: ISO/IEC 27001: Information technology - Security techniques - Information security management systems - Requirements (2nd edition). (2013). 8. Frank, U.: The MEMO meta modelling language (MML) and language architecture (2nd edition). , Duisburg-Essen (2011). 9. Heise, D., Strecker, S., Frank, U.: ControlML: A domain-specific modeling language in support of assessing internal controls and the internal control system. Int. J. Account. Inf. Syst. 15, 224–245 (2014). 10. Strecker, S., Frank, U., Heise, D., Kattenstroth, H.: MetricM: a modeling method in support of the reflective design and use of performance measurement systems. Inf. Syst. E-bus. Manag. 10, 241–276 (2012). 11. Innerhofer-Oberperfler, F., Breu, R.: Using an Enterprise Architecture for IT Risk Management. In: Proceedings of the ISSA 2006 from Insight to Foresight Conference. pp. 1–12 (2006). 12. Grandry, E., Feltus, C., Dubois, E.: Conceptual Integration of Enterprise Architecture Management and Security Risk Management. In: 2013 17th IEEE International Enterprise Distributed Object Computing Conference Workshops. pp. 114–123. IEEE (2013). 13. Gericke, A., Fill, H.-G., Karagiannis, D., Winter, R.: Situational method engineering for governance, risk and compliance information systems. In: Proceedings of the 4th International Conference on Design Science Research in Information Systems and Technology - DESRIST ’09. p. 1 (2009). 14. International Organization Of Standardization: ISO/IEC/IEEE 42010:2011 - Systems and software engineering -- Architecture description. (2011). 15. Jugel, D.: Modeling Interactive Enterprise Architecture Visualizations: An Extended Architecture Description (submitted paper). Complex Syst. Informatics Model. Q. (2018). 119