deriving and modelling compliance requirements …explicit modelling analysis of laws and texts lead...

Software Engineering for Business Information Systems (sebis)

Department of Informatics

Technische Universität München, Germany

wwwmatthes.in.tum.de

Deriving and Modelling Compliance

Requirements from Legal Audits Bernhard Waltl, 18. November 2014

http://wwwmatthes.in.tum.de

http://wwwmatthes.in.tum.de

Agenda

1. Introduction and Motivation

2. Research Questions

3. Risk Assessment Areas of IT Architectures in Legal Audits

4. Modeling of Compliance Requirements

ArchiMate

Implicit vs. Explicit Modeling

5. Example: User Authorization ArchiMate Model

6. Conclusion

© sebis141118 Waltl Bernhard - Deriving and Modelling Compliance Requirements from Legal Audits 2

Regulation

Basel II: a legal regulation in the financial sector

• Obligatory guidelines for supervision and controlling of banks

„The supervisory review process of the framework is intended […] to encourage

banks to develop and use better risk management techniques in monitoring and

managing their risks.” [1, §720]

Basel II as a driver for national legal regulations

• The Banking Act (KWG)

• Minimum Requirements for Risk Management (MaRisk)

• Journals of BaFin

• Federal Financial Supervisory Authority


Legal Obligations arising from the Banking Act

Banking Act

“A proper business organization encompasses, in particular, appropriate and

effective risk management, which includes the definition of an adequate

contingency plan, especially for IT systems.” [2, §25a.1]

Principle of double proportionality

“The risk management structure shall depend on the type, scope, complexity and

risk content of the business operations performed.” [2, §25a.1]

Banking Act (Auditing)

“An institution […], shall, upon request, provide information about all business

activities and submit documentation to BaFin, […].

BaFin may perform inspections at the institutions and superordinated enterprises,

with or without a special reason.” [2, §44.1]

© sebis 4141118 Waltl Bernhard - Deriving and Modelling Compliance Requirements from Legal Audits

Risk Management in IT systems

Risk management in IT systems

• “appropriate” and “effective”

• Assessment (auditing) as the supervisory measure (BaFin)

• Requirements depend on business operations

• Type

• Scope

• Complexity

• Content:

• Staff

• Technical-organization equipment

• Emergency plans


http://w

ww

.welt.d

e/p

rint/

welt_kom

pakt/

print_

wir

tscha

ft/a

rtic

le130

6540

96

/Ruege

n-v

on

-der-

Fin

an

zaufs

icht.

htm

l, l

ast

access

14.1

1.2

014

http://www.welt.de/print/welt_kompakt/print_wirtschaft/article130654096/Ruegen-von-der-Finanzaufsicht.html

• Software Engineers (SE) and Enterprise Architects (EA) like to have

• clear,

• well formulated,

• concrete,

• unambiguous, and

• deterministic requirements

• Dealing with indeterminate (vague) legal terms does not belong to their core

competence, which is

• Software Engineering: Design and development of software applications

• Managing Enterprise Architecture: Plan, design, development, control, and

transform of an enterprise architecture


Current State in Computer Science

Attention

© sebis7141122 Waltl Bernhard - Deriving and Modelling Compliance Requirements from Legal Audits

http://w

ww

.welt.d

e/p

rint/

welt_kom

pakt/

print_

wir

tscha

ft/a

rtic

le130

6540

96

/Ruege

n-v

on

-der-

Fin

an

zaufs

icht.

htm

l, l

ast

access

14.1

1.2

014

http://www.welt.de/print/welt_kompakt/print_wirtschaft/article130654096/Ruegen-von-der-Finanzaufsicht.html

Research Questions

I. How can requirements be derived from legal audits, respectively regulations?

II. What are risk assessment areas of IT Architectures in legal audits?

III. What requirements can be derived and how can they be represented?

IV. Can modeling support the audit process and how can normative models look

like?


Idea

• Extracting requirements arising from laws, comments, and journals

• Analyzing the assessment (auditing) of IT systems and architectures

• Associating legal requirements with concrete IT objects

• Creation of a common language by harmonizing terms from the legal domain with the

terms from the IT domain

• Support the audit process (auditor and auditee) by providing normative

models representing the „should-be“ state

• „blueprints“

• Supporting the implementation (creation and changes) of compliant processes in

the financial sector


Identification of IT requirements arising from law

© sebis 10

• Identification is challenging

• Legal texts lack concreteness and interpretation is not uncontroversial

• Principle of double proportionality

• Analytical: Objective artifacts (e.g. legal texts, comments, reports etc. )

• Empirical: Subjective experiences (e.g. interviews, examination questions etc.)

Enhancement of existing EA models with legal requirements

141118 Waltl Bernhard - Deriving and Modeling Compliance Requirements from Legal Audits

EA [models] (including legal

requirements)

empirical

EA and IT architects, software engineers, legal experts, …

Artifacts (e.g., reports, official recommendations,…)

Experiences (e.g., examination questions, method,…)

Laws, reports,

literature, …analytical

IT audit

IT-, business-, legal experts,

….

Core examination areas

• BaFin states out seven significant examination areas [8]:

I. IT strategy

II. IT risk management

III. IT revision

IV. IT outsourcing

V. Emergency management

VI. Application development

VII. User authorization

• Analysis of laws and texts lead to legal obligations

• Implicit: EA objects (processes, functions etc.) as described in the normative source

• Explicit: concrete requirement as „requirement“, „principle“ and „goal“ element


Modeling IT architecture and legal requirements

ArchiMate 2.1 [7]

• Open and independent modeling languages for enterprise architectures

• Business objects (process, role, service etc.)

• Application objects (interface, component, data object etc.)

• Technology objects (artifact, system software, device etc.)

• Provides a motivation extension

• Requirements, principles and goals representing the intentions of the model

• Can be used for modeling risks and counter-measures [5]

• Tool-support: Archi –The Free ArchiMate Modelling Tool, Version: 2.7.1

• Negative aspects

• Not that easy to understand (variety of different elements, colors and arrows)

• Not very common in the IT of financial industry

• Not used by auditors


ISSRM

• ISSRM: Information System Security Risk Management (Nicolas Mayer, 2009)

• Risk treatment related concepts (Green)

• Risk related concepts (Orange)

• Asset related concepts (Yellow)


ArchiMate Motivation Concept

ISSRM Compliance Element

Control ↔ Goal

Security requirement ↔ IT principle

Risk treatment ↔ IT requirement


• Goal

The general idea of requirements is that they - if fulfilled - lead to “better”

systems and the materialization of improvements can be specified in goals.

• Principles

… are generalizations of requirements. Based on those principles it is possible

to derive relationships between requirements.

• Requirements

… can be assigned to objects and elements. Those represent the original idea

of software requirements.

Implicit Modelling

Analysis of laws and texts lead to legal obligations

• Implicit

EA objects (processes, functions etc.) as model elements


Right Identification

Process

Right Assignment

Process

Assignment

Tracking

Explicit Modelling

Analysis of laws and texts lead to legal obligations

• Explicit

EA objects (processes, functions etc.)

as model elements


Provide Temporal

Resolution of User Rights Requirement

Temporal

Historization

!Principle

Increased

Transparency in IT Goal

Right Assignment

Process

Assignment

Tracking

Right Identification

Process

Separate Identification

and Assignment of

Rights

User Authorization Management


Critical remarks

1. Provision of normative models for IT assessments may be irritating

• No blueprint of the „correct“ solution

• Acceptance and usability of models

2. Modeling with respect to the level of granularity

• At which stage should the modelling end?

• E.g. User Authorization

• No operational user should have root rights!

• How could this be prevented?

3. A more structured way to extract requirements needs to be developed

• Considering the empirical and the analytical approach


Conclusion

• Drawbacks

• the level of granularity provided by normative models

• the blueprint character of the models

• the compliance as process not as static state

• Interpreting legal texts and associating obligations with real-world objects

is a relevant problem (not only for the financial sector!)

• Modelling languages with proper elements can help

• Legal audits can serve as an information source for concretization of

requirements based on legal texts

• Requirements can either be analytically or empirically derived

• Existing EA models can be enhanced with proper elements and objects


Technische Universität München

Department of Informatics

Chair of Software Engineering for

Business Information Systems

Boltzmannstraße 3

85748 Garching bei München

Tel +49.89.289.

Fax +49.89.289.17136

wwwmatthes.in.tum.de

Bernhard Waltl

M.A, M.Sc.

17124

[email protected]

Thank you for your attention!

http://wwwmatthes.in.tum.de/

mailto:[email protected]

References

[1] Basel Committee on Banking Supervision. International Convergence of Capital Measurement and Capital Standards: A Revised Framework Comprehensive Version, June 2006.

[2] Deutsche Bundesbank. Banking Act, 2009.

[3] Federal Financial Supervisory Institution. Minimum requirements for risk management (MaRisk). 2012.

[4] Klaus Schmidt and Dirk Brand. IT-Revision in der Praxis: Nach den Grundsätzen einer ordnungsgemäßen IT. Carl-Hanser Verlag, Munich, 2011.

[5] Gerben Wierda. Mastering ArchiMate: A serious introduction to the ArchiMate Enterprise Architecture Modeling Language. R&A, Heerlen, 2012

[7] The Open Group. ArchiMate 2.1 Specification. 2013.

[8] Jörg Bretz. Prüfung IT im Fokus von MaRisk und Bundesbank: Verstärkter IT-Fokus in Sonderprüfungen. Finanz Colloquium Heidelberg, 2012.

[9] Marc Lankhorst. Enterprise Architecture at Work: Modelling, Communication, and Analysis, Berlin, Springer 2005.

[10] Eric Yu, Markus Strohmaier, and Xiaoxue Deng. Exploring Intentional Modeling and Analysis for Enterprise Architecture. 10th IEEE International Enterprise Distributed ObjectComputing Conference Workshops, 2006.


deriving and modelling compliance requirements …explicit modelling analysis of laws and texts lead...

Documents