Strukturanalyse

Visualisierung

"Betrachtungsbereiche

Es gibt in der Strukturanalyse mehrere Sichten, um den User nicht mit einem überdimensionalen und unübersichtlichen Graphen zu konfrontieren. Daher gibt es folgende 4 Betrachtungsbereiche:

• Organisationssicht

Die Organisationssicht stellt die Aufbauorganisation des Unternehmens / Konzerns / Verbandes in den Fokus. Ziel ist es aus dieser Betrachtungsperspektive heraus Antworten auf Fragen, wie "Von welchen Systemen ist die Organisationseinheit am stärksten hinsichtlich Verfügbarkeit abhängig“, „Wie groß ist das Risiko hinsichtlich der Vertraulichkeit für die OrgEh über alle Systeme“ (klassisch die Ergebnisse aus Business Impact Analysen), „Welche Datenarten werden in der Organisationseinheit verarbeitet“, „Welche Verarbeitungstätigkeiten erfolgen in der Organisationseinheit “.

• Systemsicht

Die Systemsicht stellt die Techniklandschaft dar, welche IT-Systeme, Medizinprodukte, Gebäudesicherheit etc. abbildet. Über diese Darstellung erfolgt auch die Risikoanalyse. Hier werden Abweichungen in der Risikobewertung im technischen wie organisatorischen Bereich erkennbar und daraus sind Maßnahmen zur Behebung der Abweichungen zu planen.

• Datensicht

Die Datensicht lässt erkennen in welchen Organisationseinheiten welche Daten verarbeitet werden, wer die Data Owner sind und wie die Daten klassifiziert sind (Datenklassen bzw. Unterscheidung ob personenbezogene oder nicht personenbezogene Daten). Weiters lässt die Darstellung erkennen durch welche Verarbeitungstätigkeiten die Daten laufen und in welchen Applikationen sie verarbeitet werden.

• Prozesssicht

Organisationssicht

---

Der Aufbau der Organisationsstruktur wird in Organisationseinheiten beschrieben.

Ein Unternehmen besteht aus Organisationseinheiten welche sich an den einzelnen Verarbeitungsprozessen beteiligen, die wiederum in einer bis mehreren Organisationseinheiten stattfinden. Das Erstellen und Verarbeiten von Daten erfolgt in diesen Organisationseinheiten während der einzelnen Prozessschritte überwiegend IT gestützt unter Verwendung von IT-Systemen.

Annahme: Je kritischer die Organisationseinheit, desto größer der potenzielle Schaden, umso größer die Anforderungen an Verfügbarkeit, Vertraulichkeit und Integrität der Daten bzw. Systeme.

Daher müssen jedenfalls folgende Informationen erhoben werden:

• Modellierung der Organisationsstruktur (Organisationseinheiten)
• Erhebung des Business Impacts der Business IT-Services auf die tägliche Arbeit des Fachbereichs (Kritikalität einer Organisationseinheit feststellen)

Ressourcensicht

---

Die Sicht auf die IT-Systeme, welche sich in mehrere Kategorien unterteilen lassen, zeigt viele Abhängigkeiten untereinander auf. Weiters sind eventuell nicht alle Komponenten des Systems gleich sicher ausgelegt. Durch die Abhängigkeiten zwischen unterschiedlich sicher ausgelegten Systemen beeinflussen die Systeme einander. Diese Wechselwirkungen sind über eine Risikobewertung zu erheben und können in der Strukturanalyse in Form eines Graphen dargestellt werden.

Beispiel: Ein Krankenhausinformationssystem (KIS) hat eine Schnittstelle ins SAP. SAP ist vom KIS zu einem gewissen Teil hinsichtlich des Schutzziels Verfügbarkeit abhängig (zwar nicht zu 100%, aber z.B. zu 30%) da es ohne die Patientenstammdaten, die es vom KIS mehrmals täglich über die Schnittstelle erhält und die bei der Aufnahme eines Patienten im KIS erfasst werden, keine Abrechnung für diesen Patienten vornehmen kann. Das KIS hingegen ist vom SAP unabhängig.

Das KIS benötigt aber um funktionstüchtig zu sein einen Datenbankserver. Es ist zu 100% von diesem Server abhängig. Ebenfalls benötigt es die Netzwerkinfrastruktur, ohne die es z.B. den Datenbankserver nicht erreichen kann.

Durchführung einer Strukturanalyse

(zu spezifizieren / zu überarbeiten, 28.10.2017) <Das Vorgehen beschreiben … die Texte drunter auf Brauchbarkeit prüfen> <Die Anlage von Modellsegmenten und asset groups beschreiben>

Eine Abteilung bzw. Geschäftsprozesse verwenden Business Applikationen (Business Applications, Communication Services, Datenablage Services, Medizinisch administrative Services oder medizinisch klinische Services). Es werden daher mehrere Applikationen mehreren Organisationseinheiten zugeordnet. Durch die Business Impact Analyse (siehe 5.5.2.2) wird die Beziehung zwischen der jeweiligen Business Area und der Applikation gewichtet (entsprechend der Risikoklassen, z.B. sehr geringes Risiko bis katastrophales Risiko). Die Applikation hat zu unterschiedlichen Geschäftsbereichen unterschiedliche Gewichtungen. Die kritischste Gewichtung gibt vor wie technisch anspruchsvoll die Applikation z.B. hinsichtlich ihrer Verfügbarkeit ausgelegt werden muss. Hinsichtlich der Vertraulichkeit ist die Applikation von den kritischsten Daten abhängig, die durch die Geschäftsbereiche gewichtet wurden. Auf diese Art erhält die Applikation eine Risikoeinstufung je Schutzziel (z.B. Applikationen mit sehr geringem Risiko hinsichtlich der Verfügbarkeit, aber katastrophalem Risiko hinsichtlich der Vertraulichkeit).

• Die Business Applikationen haben Abhängigkeiten untereinander (z.B. über Schnittstellen). Diese Abhängigkeiten werden durch die zuständigen Applikationsbetreuer benannt. Z.B. sind manche Applikationen nicht funktionsfähig oder nur eingeschränkt funktionsfähig bzw. sind teilweise auch bidirektionale Beziehungen vorhanden die berücksichtigt werden müssen. Eine Erläuterung der Beziehungstypen im Detail findet sich nachfolgend unter 5.5.2.2 „Logik der Beziehungen zwischen Entitäten“.
• Business Applikationen benötigen IT-Infrastructure Services, LAN Services und ggf. Medizinprodukte um sie betreiben zu können.
• Auch diese Infrastruktur Services nutzen einander gegenseitig. IT-Infrastructure Services nutzen LAN Services bzw. nutzen Medizinprodukte ggf. IT-Infrastructure Services und/oder LAN Services.
• Die physischen Komponenten wie LAN Komponenten, Server Hardware oder Clients befinden sich an Standorten deren Sicherheitsniveau bzw. deren Verfügbarkeiten unterschiedlich stark ausgeprägt sein können.
• All diese Komponenten werden durch den vorgabekonformen Umgang durch Menschen beeinflusst.

In all diesen Bereichen können detaillierte Strukturanalysen oder Strukturpakete auf abstrakten Niveau geschaffen werden (abhängig vom Reifegrad werden model segments, Asset groups oder assets im Detail anaylsiert), je nachdem ob der Anwender derzeit einen Schwerpunkt auf die Betrachtung dieses Themas legen möchte.

In diesen einzelnen Bereichen können auch Strukturen modelliert werden, die vorweg als „in Planung“ gekennzeichnet werden. So ist es möglich diese Strukturen nicht in Analysen mit auszuwerten oder umgekehrt gezielte Analysen für diese Bereiche durchzuführen.

Logik der Beziehungen zwischen Entitäten

Strukturelemente (Business-Applikationen oder IT-Infrastruktur Services, aber auch asset groups und model segments) können untereinander in Beziehung stehen. Zwischen zwei in Beziehung stehenden Strukturelementen gibt es dabei eine Ausprägung der Beziehung je Schutzziel. Je Schutzziel ist dabei festgelegt welche Richtung die Beziehung hat und wie stark die Abhängigkeit gewichtet ist. Standardmäßig ist die Gewichtung der Beziehung mit 100% zu sehen, aber auch eine andere Gewichtung ist einstellbar. All diese Beziehungen können uni- oder bidirektional sein. Das definiert die Abhängigkeiten der Objekte zueinander.

Beispiel: Ein KIS und eine Laborwertesoftware stehen in Beziehung

Schutzziel Verfügbarkeit: Das Laborwertesoftware ist zu 100% vom KIS abhängig. Wenn das KIS nicht funktioniert kann das Laborwertesystem nicht auf die Patientenstammdaten zugreifen und somit kann daher nicht gearbeitet werden. Das KIS hingegen ist nur zu 10% vom Laborwertesystem abhängig. Wenn dieses nämlich nicht funktioniert, kann das KIS nicht die Blutwerte abrufen, alle anderen Funktionen stehen aber uneingeschränkt zur Verfügung.

Es können folgende Arten von Beziehungen bestehen:

• model segment <-> model segment
• model segment <-> asset group
• asset group <-> asset group
• model segment <-> asset
• asset group <-> asset
• asset <-> asset

Ein asset kann immer nur in eine asset group gehören bzw. kann eine asset group immer nur in ein model segment gehören.

Dieser Schritt kann auch ohne einen vorhergehenden Schritt der Business Impact Analyse erfolgen, indem einfach alle Systeme die betrachtet werden sollen (warum auch immer es zur Auswahl dieser kommt, wie z.B. im Rahmen eines Einführungsprojekts) abgebildet werden.

Oder man beginnt gezielt mit der Risikoanalyse für jene Systeme, die als Analyseergebnis aus den BIAs als kritische Services hervorgegangen sind (bzw. Systeme zu Prozessen / Fachbereichen die kritisch erscheinen). Denn auf Basis der Ergebnisse der BIA ist eine zielgerichtete Risikountersuchung möglich. Die Risikoidentifikation betrachtet dabei die Systeme mit den höchsten Schutzanforderungen aus den Fachbereichs-/Prozessanalysen.

Prozesssicht

Die Verarbeitungstätigkeitssicht (sofern das EU-DSGVO Modul gekauft wurde) zeigt an, welche Daten, aus welchen Organisationseinheiten in welcher Applikation (eigentlich nicht erforderlich lt. Gesetzgebung) verarbeitet werden und die daran hängenden Controls und Maßnahmen (auch nicht notwendig lt. GG) können ebenfalls ausgewertet werden.