Sicherheit im Prozessmanagement

Transkript

1 Sicherheit im Prozessmanagement Rafael Accorsi Business Process Security Group Universität Freiburg Freiburg i.br., 29. Mai 2013 Zusammenfassung Ziel der Sicherheit in Geschäftsprozessmanagement ist es, auf der Ebene der Prozessspezikationen und Geschäftsziele fundierte Garantien bezüglich Sicherheit und regulatorischer Compliance zu erlangen und die hierfür benötigten Verfahren in den Lebenszyklus des Geschäftsprozessmanagement zu integrieren. Dieser Beitrag stellt dieses praktisch sehr relevante Forschungsgebiet vor, seinen aktuellen Stand und die anstehenden praktischen Herausforderungen. 1 Einleitung Über 70% der Geschäftsprozesse werden in IT-gestützten Managementsystemen (BPMS) abgebildet, zumindest teilweise automatisiert ausgeführt und verwaltet [24]. Diese Umsetzung ermöglicht die exible, adäquate Anpassung von Prozessen an geschäftliche Veränderungen und die bedarfsgerechte Einbindung und Verteilung externer Ressourcen. Allerdings stehen den geschäftlichen Chancen des Prozessmanagements erhebliche Risiken bzgl. der Einhaltung von Sicherheitsrichtlinien und gesetzlichen Vorschriften gegenüber. Wollen Unternehmen bspw. ihre Prozesse automatisiert ausführen oder in die Cloud auslagern, müssen sie über Garantien verfügen, dass entsprechende Vorgaben nicht verletzt werden bzw. dass Mechanismen vorhanden sind, die solche Verletzungen zeitnah detektieren [14]. Dies betrit insbesondere den Aspekt der Kontrolle und Audit der Sicherheit [18]: es muss gewährleistet sein, dass verarbeitete Informationen wie Kundendaten, nanzielle Transaktionen und geschäftliche Interna geschützt bleiben und die eigenen Prozesse von fremdem Einuss oder internen Angreifern abgeschottet sind. Das Vertrauen in bestehende Lösungen ist bislang gering. Mangelnde Sicherheits- und Compliance-Garantien werden derzeit in der Industrie als das gröÿte Hemmnis für den betrieblichen Einsatz automatisierter Prozesse angesehen [21, 17]. Dieser Artikel stellt das Gebiet der Sicherheit im Geschäftsprozessmanagement vor und ordnet dieses in den Stand der Forschung im Bereich der Enterprise Security ein. Erscheint in digma Zeitschrift für Datenrecht und Informationssicherheit 1

2 2 Abstraktionsebenen Der Forschungsbereich der Enterprise Security kann auf unterschiedlichen Abstraktionsebenen betrachtet werden. Eine Abstraktion liefert das Enterprise Architecture Metamodel [23], welches die IT-Unterstützung moderner betrieblicher Systemarchitekturen in drei aufeinander aufbauende Schichten unterteilt. Die Business-Schicht deniert die Geschäftsprozesse, -objekte und -ziele, und die Assets des Unternehmens, ebenso wie dessen organisationale Struktur und einzuhaltende Vorgaben. Die Anwendungsschicht beinhaltet Dienste und Datenschemen, die für die Ausführung der Prozesse benötigt werden. In diesem Zusammenhang sind Dienstorientierte Architekturen (SOA) oder hohe Service-Modi des Cloudbzw. Grid-Computings von Relevanz. Die Infrastrukturschicht stellt die Software und Hardware zur Verfügung, anhand derer Dienste ausgeführt werden können. Dies umfasst bspw. benötigte Datenbanken, das Betriebssystem und virtuelle Maschinen. Mechanismen der Enterprise Security müssen Sicherheits- und Compliance- Anforderungen auf allen Schichten berücksichtigen und diese kompositionell durchsetzen. Während jedoch Verfahren für die Anwendungs- und Infrastrukturschicht weitgehend untersucht sind und auf neue Systemarchitekturen übertragen werden können, ist die Berücksichtigung der Business-Schicht ein relativ neues, herausforderndes und praktisch sehr relevantes Forschungsgebiet der IT- Sicherheit. Dieses Gebiet wird Sicherheit in Prozessmanagement genannt. Ziel dieses Gebiets ist es, auf der Ebene der Prozessspezikationen und Geschäftsziele fundierte Garantien bezüglich der Sicherheit, des Datenschutzes und regulatorischer Compliance zu erlangen und die hierfür benötigten Kontrollmechanismen in den Lebenszyklus des Geschäftsprozessmanagements (BPM) zu integrieren. 3 Anforderungen Die Anforderungen der Sicherheit in BPM vereinen übliche Sicherheitseigenschaften mit organisationalen Richtlinien und regulatorischen Auagen, die je nach Fachjargon als einzuhaltende Policies oder Kontrollen bezeichnet werden [10, 16]. Man geht hierbei von folgenden Anforderungsklassen aus: Autorisierung regelt, welche Subjekte oder Rollen auf welche Ressourcen zugreifen können. In betrieblichen IT-Landschaften wird dies oft anhand des rollenbasierten Zugriskontrollmodells formalisiert. Solche Modelle können selbst in kleinen Unternehmen bzw. Systemen über komplexe, hochdynamische Rollenmodelle mit über 500 Rollen verfügen. Nutzungskontrolle drückt Bedingungen aus, die nach der Autorisierung des Zugris auf eine Ressource deren Nutzung regeln [19]. So kann zum Beispiel die maximale Zugriszahl auf ein Datenobjekt festgelegt werden oder die Verpichtung, dass jedem Zugri auf ein Datum die entsprechende Löschoperation folgen muss. Generell beziehen sich diese Anforderungen auf 2

3 das Zusammenspiel mehrerer Aktivitäten im Prozess (sog. Kontrolluss), welche als Patterns erfasst werden können. Interessenkonikt zielt darauf ab, unzulässige Ausnutzung von Insiderwissen zu unterbinden. Erfasst werden solche Anforderungen anhand des Chinese Wall-Modells in Anlehnung an die Metapher, dass objekt- und subjektspezische Zugris-beschränkungen wie Mauern um Schutzobjekte aufgebaut werden [13]. Funktionstrennung bedeutet, dass bestimmte Aufgaben in einem Geschäftsprozess nicht durch ein und dieselbe Organisationseinheit (z.b. Subjekt, Rolle oder Abteilung) durchgeführt werden sollen. Diese Kontrolle soll kriminelle Handlungen und Betrug unterbinden [12]. Aufgabenbindung bezeichnet das Gegenteil von Funktionstrennung. Dies verlangt, dass bestimmte Aufgaben in einem Geschäftsprozess durch eine Organisationseinheit durchgeführt werden müssen. Mehr-Augen-Kontrolle besagt, dass eine kritische Aktivität im Prozess nicht von einer einzelnen Person durchgeführt werden soll. Ziel dieser eng mit der Funktionstrennung verwandten Kontrolle ist es, den Eintritt von Fehlern und Missbrauch zu reduzieren. Isolation drückt aus, dass innerhalb eines oder zwischen mehreren Prozessen keine Informations- oder Datenlecks auftreten können. Damit soll die Vertraulichkeit von Informationen oder Daten gewährleistet werden [9]. Konkrete Spezikationen dieser Anforderungen können in verschiedener Art und Weise an unterschiedlichen Prozessentitäten entlang des BPM-Lebenszyklus überprüft bzw. ihre Verletzung kann diagnostiziert werden. 4 BPM-Lebenszyklus und Kontrollmechanismen Grundsätzlich gibt es drei Zeitpunkte für die Analyse von Prozessen: vor, während oder nach deren Ausführung. Dieser Abschnitt fasst die bestehenden Kontrollmechanismen entlang dieser zeitlichen Einteilung zusammen und ordnet diese Einteilung in den BPM-Lebenszyklus [22] ein. Vor der Ausführung. Die Designzeitanalyse ndet ex-ante, also vor der Ausführung des Prozesses statt und bezieht sich auf die Phase Design and Analysis des BPM-Lebenszyklus. Die zu betrachtende Prozessentität ist das Prozessmodell, dessen Spezikation mit einer industriellen Sprache wie BPEL oder BPMN erfolgt. In diesem Zusammenhang werden derzeit hauptsächlich zwei Forschungsrichtungen angegangen, die die Policies bzw. die Struktur des Prozesses betreen. Zum einen wird nach optimalen Rollenzuweisungen gesucht, die übergeordnet das Prinzip der Least Privilege approximieren [11]. Dieses besagt, dass Rollen nur diejenigen Aktivitäten durchführen sollen, die sie für einen ordnungsgemäÿen Ablauf des Prozesses benötigen, und verbietet alle darüber hinausgehende. Die Herausforderung hierbei ist, dies bei sich dynamisch ändernden Prozessspezikationen und Rollenmodellen durchzusetzen. 3

4 Zum anderen wird nach strukturellen Schwachstellen im Prozess gesucht, die zur Verletzung einer oder mehrerer Policies führen [17]. Diese Art von Analyse setzt voraus, dass die Prozessspezikationen auf eine formale Sprache, meistens Petrinetze, abgebildet werden. In diesem Zusammenhang können anhand bestehender Werkzeuge Garantien bezüglich Isolations- [3] und Compliance- Eigenschaften [4] automatisiert gegeben werden. Die exakte Umsetzung des Prozessmodells in dem BPMS, d.h. auf der Anwendungs- und Infrastrukturschicht stellt jedoch eine Herausforderung für die Einhaltung der Garantien während der Ausführung dar. Während der Ausführung. Die Laufzeitanalyse wird in der Regel mittels Monitoring-Ansätze durchgeführt, die den Fortschritt des Prozesses überwachen. Die zu betrachtende Prozessentität ist die Prozessinstanz, d.h. ein instanziiertes Modell hinsichtlich bspw. der Rollenzuordnung und Datenobjekte. Im BPM-Lebenszyklus entspricht dies der Enactment-Phase, in der die Prozesse von der Workow-Engine in der BPMS umgesetzt und ausgeführt werden. Monitore können präventiv vor der Verletzung einer Policy intervenieren oder detektiv eine Verletzung signalisieren. Die Modalität präventiv vs. detektiv hängt einerseits von der Art der zu überwachenden Anforderungen ab, andererseits vom architektonischen Aufbau des Systems, der die Betrachtungsreichweite des Monitors charakterisiert. Präventive Ansätze stoppen die Ausführung eines Prozesses, wenn seine unmittelbare Fortführung mit der Verletzung einer Policy einhergeht [20]. Dies ist jedoch betriebswirtschaftlich nicht immer sinnvoll, da die Nicht-Terminierung eines Prozesses womöglich ebenfalls bedeutet, dass Transaktionen nicht zustande kommen und dadurch auch kein Wert für das Unternehmen generiert wird. Detektive Ansätze hingegen signalisieren die Verletzung einer Policy [5]. Dies kann in Form einer Meldung an den zuständigen Leiter oder eines Eintrags in eine Log-Datei erfolgen. Während diese Modalität die zeitnahe Reaktion auf einen Vorfall ermöglicht, verhindert sie nicht die Verletzung einer Policy. Dies kann insbesondere bei Policies, welche die Vertraulichkeit von Daten betreen, von Nachteil sein. Generell weisen Monitoring-Ansätze durch ihre Funktionsweise einen sehr hohen Overhead bezüglich der Performanz auf, was den Ansatz insbesondere für Anwendungen im Bereich des High Frequency Trading oder des ereignisintensiven Prozessmanagements unattraktiv macht. Nach der Ausführung. Die ex-post Analyse zur Audit-Zeit ndet auf Basis aufgezeichneter Prozessausführungen (sog. Event Logs) statt. Bezogen auf den BPM-Lebenszyklus wird die ex-post Analyse der Evaluation-Phase zugeordnet, in der die funktionelle Performanz des Prozesses und seine Fähigkeit, Geschäftsziele bei Einhaltung der Policies zu erreichen, gemessen wird. Die für die Analyse herangezogene Prozessentität ist die aufgezeichnete Prozessausführung, die Case genannt wird. Methoden des Process Mining [8] liefern einen Werkzeugkasten, anhand dessen Logs auf die Einhaltung von Policies überprüft werden können. Unter der Annahme, dass Logs authentisch sind [1, 2], stehen hierfür grundsätzlich zwei Klassen von Verfahren zur Verfügung. 4

5 Process Discovery rekonstruiert aus Logdateien die Struktur des Prozesses und bildet sie in einem oder mehreren Modellen ab. Diese entsprechen den tatsächlichen Prozessausführungen und können daher von den ursprünglich spezizierten Modellen abweichen. Diese Abweichungen können visualisiert und mit Verfahren der ex-ante Analyse auf die Einhaltung von Policies überprüft werden. Ähnlich können neben der Prozessstruktur auch das Rollenmodell und das aus Logles ausgehende soziale Netz approximiert werden. Diese Strukturen erlauben die anschlieÿende Prüfung auf Policy-Einhaltung [7]. Conformance Checking ermöglicht es, Diskrepanzen zwischen dem modellierten und dem aufgezeichneten Verhalten aufzuzeigen. Dabei können nicht übereinstimmende Elemente in Log und Modell lokalisiert und visuell hervorgehoben werden. Zudem ist eine Bestimmung des globalen Grads der Übereinstimmung (engl. tness) mit Hilfe spezieller Metriken und entsprechender Verfahren möglich. Werden Prozessvorgaben wie beispielsweise Sicherheitsanforderungen in Form von Policies über Prozesseigenschaften modelliert, kann ihre Einhaltung automatisiert überprüft und von den Vorgaben abweichende Fälle aufgezeigt werden [6]. Ergebnisse der ex-post Analyse dienen als Eingabe für zwei weitere Phasen des BPM-Lebenszyklus: das Redesign führt inkrementelle, lokale Änderungen an einem Prozess durch, so dass bspw. eine fehlende Aktivität hinzugefügt bzw. eine überüssige Aktivität gelöscht wird. Dabei kann die Einhaltung der Policies sichergestellt werden. Bei dem Reengineering handelt sich hingegen um eine fundamentale Reorganisation der ganzen Prozessarchitektur. Dies umfasst nicht nur die rein technische Betrachtung, sondern vielmehr den betriebswirtschaftlichen und gesamtorganisationalen Aspekt. 5 Aktuelle Themen Generell stellt die Entwicklung moderner betrieblicher Systeme und Architekturen groÿe Hürden für die oben genannten Verfahren und Werkzeuge dar. Insbesondere aufgrund exibler Prozessspezikationen, groÿ angelegter, hoch verwobener und verteilter Prozessarchitekturen und der Entstehung von Big Data bei der Prozessausführung. Exemplarisch können folgende Themen hervorgehoben werden: Formalisierung von Anforderungen. Die Extraktion, Strukturierung und Formalisierung von Anforderungen ist für die Analyse essenziel, birgt jedoch eine Reihe von Problemen. Derzeit wird an systematisch aufgebauten Sammlungen von Mustern gearbeitet, die Eigenschaften erfassen können und für die Analyse lediglich instanziiert werden müssen. Während dies für rein strukturelle Charakteristiken erfolgen kann, ist die Erfassung der Zeitkomponente und involvierten Datenobjekte nicht trivial. Korrektive Durchsetzung. Monitore, wie oben aufgeführt, weisen einen detektiv präventiven Betriebsmodus auf. Aktuell werden Ansätze erforscht, wie Monitore auch korrigierend auf die Prozessausführung einwirken können. Das sog. corrective enforcement ist insofern herausfordernd, als die 5

6 modizierte Ausführung weiterhin die für den Prozess vorgesehenen Ziele erreichen muss. Data-aware Rekonstruktion. Verfahren der Process Discovery betrachten derzeit einzelne Perspektiven des Prozesses (Kontrolluss, Datenuss, Rollen) separat voneinander. Für eine Analyse hinsichtlich der Sicherheit sind gerade die Wechselwirkungen zwischen diesen Perspektiven relevant. Ein aktuell wichtiges Forschungsthema fokussiert auf die simultane Erkennung von Kontroll- und Datenüssen, die vor allem die Aufspürung und Behebung von Datenlecks unterstützen kann. Resilientes BPM. Mit Resilienz bezeichnet man die Zusammensetzung zweier Eigenschaften von Systemen: Robustheit einerseits, Anpassungsfähigkeit bei Störungen andererseits. Gegenwärtige Arbeiten untersuchen die Übertragung und Realisierung dieser Eigenschaften auf Prozesse in sog. Process-aware Information Systems, zu denen AristaFlow, SAP R/3 und IBM Websphere zählen [15]. 6 Forschungsgebiet in ux Die systematische Betrachtung der Sicherheit in Geschäftsprozessmanagement ist ein junges, sich in Entwicklung bendendes Forschungsfeld mit einer sehr aktiven, schnell wachsenden Forschungsgemeinschaft. In den letzten Jahren fanden zahlreiche Tagungen zu diesem Thema statt. Ferner wenden sich etablierte Konferenzen zunehmend diesem Thema zu, eine Entwicklung, die sich mit einer steil ansteigenden Anzahl von Publikationen nachweisen lässt. Des Weiteren werden derzeit zahlreiche Europäische und nationale Projekte zu diesem Thema gefördert. Die Anstrengungen setzen sich weiter fort: in 2013 nden neben dem Workshop on Security in Business Processes auf der BPM Konferenz in Beijing auch ein Dagstuhl-Seminar zu diesem Thema statt, ebenso wie der Track Modellierung und Management sicherer Geschäftsprozesse auf der MKWI und Sonderhefte in mehreren Journals. Insgesamt betrachtet fällt trotz der Relevanz des Themas die Integration der bereits erzielten Resultate in das übergeordnete Gebiet der Enterprise Security jedoch noch sehr nüchtern aus. Entsprechend machen sich Bemühungen seitens der Industrie und Wirtschaftswissenschaften bemerkbar, diese Integration innerhalb der Business Process Intelligence und des Enterprise Architecture Managements zu vollziehen. Auch das Interesse, groÿ angelegte Fallstudien durchzuführen, ist ein Indikator für diese Bemühungen. Dies ist neben den strikt technischen Entwicklungen auch der Trend, der in den nächsten Jahren beobachtet wird. Literatur [1] R. Accorsi. Safe-keeping digital evidence with secure logging protocols: State of the art and challenges. In O. Goebel, R. Ehlert, S. Frings, D. Günther, H. Morgenstern, and D. Schadt, editors, Proceedings the IEEE Con- 6

7 ference on Incident Management and Forensics, pages IEEE Computer Society, [2] R. Accorsi. BBox: A distributed secure log architecture. In J. Camenish and C. Lambrinoudakis, editors, European Workshop on Public Key Services, Applications and Infrastructures, number 6711 in Lecture Notes in Computer Science, pages Springer, [3] R. Accorsi and A. Lehmann. Automatic information ow analysis of business process models. In A. P. Barros, A. Gal, and E. Kindler, editors, Conference on Business Process Management, volume 7481 of Lecture Notes in Computer Science, pages Springer, [4] R. Accorsi, L. Lowis, and Y. Sato. Automated certication for compliant cloud-based business processes. Business & Information Systems Engineering, 3(3):145154, [5] R. Accorsi, Y. Sato, and S. Kai. Compliance monitor for early warning risk determination. Wirtschaftsinformatik, 50(5):375382, October [6] R. Accorsi and T. Stocker. On the exploitation of process mining for security audits: The conformance checking case. In ACM Symposium on Applied Computing, pages ACM Press, [7] R. Accorsi, T. Stocker, and G. Müller. On the exploitation of process mining for security audits: The process discovery case. In ACM Symposium on Applied Computing, pages ACM Press, [8] R. Accorsi, M. Ullrich, and W. M. P. van der Aalst. Process mining. Informatik Spektrum, 35(5):354359, [9] R. Accorsi and C. Wonnemann. InDico: Information ow analysis of business processes for condentiality requirements. In J. C. et al., editor, Security and Trust Management, volume 6710 of Lecture Notes in Computer Science, pages Springer, [10] V. Atluri and J. Warner. Security for workow systems. In M. Gertz and S. Jajodia, editors, Handbook of Database Security, pages Springer, [11] D. A. Basin, S. J. Burri, and G. Karjoth. Optimal workow-aware authorizations. In V. Atluri, J. Vaidya, A. Kern, and M. Kantarcioglu, editors, ACM Symposium on Access Control Models and Technologies, pages , [12] R. Botha and J. Elo. Separation of duties for access control enforcement in workow environments. IBM Systems Journal, 40(3):666682, March [13] D. Brewer and M. Nash. The Chinese-wall security policy. In Proceedings of the IEEE Symposium on Security and Privacy, pages ,

8 [14] R. Chow, P. Golle, M. Jakobsson, E. Shi, J. Staddon, R. Masuoka, and J. Molina. Controlling data in the cloud: Outsourcing computation without outsourcing control. In Proceedings of the ACM Workshop on Cloud Computing Security, pages ACM, [15] S. Fenz, T. Neubauer, R. Accorsi, and T. Koslowski. FORISK: Formalizing information security risk and compliance management. In Annual IEEE/I- FIP International Conference on Dependable Systems and Networks [16] G. Herrmann and G. Pernul. Viewing business-processes security from dierent perspectives. International Journal of Electronic Commerce, 3(3):89 103, [17] L. Lowis and R. Accorsi. Finding vulnerabilities in SOA-based business processes. IEEE Transactions on Service Computing, 4(3):230242, August [18] G. Müller, R. Accorsi, S. Höhn, and S. Sackmann. Sichere Nutzungskontrolle für mehr Transparenz in Finanzmärkten. Informatik Spektrum, 33(1):3 13, February [19] J. Park and R. Sandhu. The UCON ABC usage control model. ACM Transactions on Information and System Security, 7(1):128174, February [20] F. Schneider. Enforceable security policies. ACM Transactions on Information and System Security, 3(1):3050, February [21] Statistisches Bundesamt. Unternehmen und Arbeitstätten. Nutzung von Informations- und Kommunikationstechnologien in Unternehmen (in German). Statistisches Bundesamt, [22] M. Weske. Business Process Management: Concepts, Languages and Architectures. Springer, [23] R. Winter and E. J. Sinz. Enterprise architecture. Inf. Syst. E-Business Management, 5(4):357358, [24] C. Wolf and P. Harmon. The state of business process management. BPTrends Report, Available at 8