Aus Sicht der IT-Sicherheit ist Risikomanagement der Prozess, Faktoren zu verstehen und darauf zu reagieren, die zu einer Verletzung der Vertraulichkeit, Integrität oder Verfügbarkeit eines Informationssystems führen können. Risiko ist eine Funktion der Wahrscheinlichkeit, dass eine Bedrohungsquelle eine spezifische potenzielle Schwachstelle ausnutzt, und der daraus resultierenden Auswirkungen bzw. Kritikalität eines solchen Ereignisses für die Organisation. Eine Bedrohung stellt das Potenzial einer Bedrohungsquelle dar, eine spezifische Schwachstelle auszunutzen (unbeabsichtigt oder absichtlich auszulösen). Eine Bedrohungsquelle ist entweder ein Versuch oder eine Methode, die auf die absichtliche Ausnutzung einer Schwachstelle abzielt, oder eine Situation oder Methode, die eine Schwachstelle unbeabsichtigt auslösen könnte. Eine Schwachstelle ist eine Schwäche, ein Defekt oder ein Fehler in den Sicherheitsverfahren, dem Design, der Implementierung oder den internen Kontrollen des Systems, der ausgelöst werden kann (unbeabsichtigt oder absichtlich ausgenutzt) und zu einer Sicherheitsverletzung oder einem Verstoß gegen die Sicherheitsrichtlinien des Systems führen kann. Es existieren zahlreiche Methoden zur Risikoanalyse und zum Risikomanagement, und die Wahl der Methode hängt von spezifischen organisatorischen Faktoren ab. Es lässt sich jedoch ableiten, dass diejenigen Methoden, die die Entwicklung von auf die Märkte und Profile von Organisationen zugeschnittenen Sicherheitsprinzipien ermöglichen, von größerem Interesse und höherer Akzeptanz sind. Ebenso erscheint es äußerst vorteilhaft, alle Mitglieder der Organisation als Teilnehmer einzubeziehen, beispielsweise durch die Einrichtung spezieller Meetings.

OCTAVE-Risikobewertungsmethodik. Entwicklung der
OCTAVE-Methoden. OCTAVE (Operationally Critical Threat, Asset and Vulnerability Evaluation) ist eine Methodik zur Verbesserung der Entscheidungsfindung im Zusammenhang mit dem Schutz und der Verwaltung der Ressourcen einer Organisation sowie ein Instrument zur Risikoanalyse. Es lassen sich zwei Hauptmethoden von OCTAVE unterscheiden: eine für große Unternehmen mit 300 oder mehr Mitarbeitern und OCTAVE-S für Organisationen mit weniger Mitarbeitern (z. B. KMU). Im Juni 1999 veröffentlichte die Carnegie Mellon University das OCTAVE-Framework, Version 1.0. Im September 2001 erschien die OCTAVE-Methode, Version 2.0, und im Dezember 2001 die OCTAVE-Kriterien, Version 2.0 – alle für große Organisationen mit mehrstufigen Hierarchien. Im September 2003 wurde OCTAVE-S Version 0.9 veröffentlicht, gefolgt von OCTAVE-S Version 1.0 im März 2005. Diese Versionen eigneten sich für kleinere Organisationen (mit 20 bis 80 Mitarbeitern) mit flacher Hierarchie. Im Juni 2007 erschien OCTAVE Allegro Version 1.0, die die Möglichkeiten der Organisation zur Durchführung von Risikoanalysen erweiterte. Stehen beispielsweise Informationswerte im Mittelpunkt der Sicherheitsrisikoanalyse, werden andere damit verbundene Werte als Informationsspeicher betrachtet, die Informationswerte speichern, verarbeiten oder transportieren. Informationsspeicher können Personen, Objekte (Dokumente) oder Technologien (Datenbanken) sein. Bedrohungen für Informationswerte werden analysiert, indem deren Speicherort berücksichtigt und die Anzahl und Art der in den Prozess einbezogenen Werte eingeschränkt werden.

Die Hauptaspekte von OCTAVE lassen sich wie folgt zusammenfassen: (i) Es ist selbstgesteuert; die Mitarbeiter der Organisation führen die Bewertung durch und kennen die Anforderungen und Abläufe der Organisation. (ii) Es konzentriert sich auf organisatorische Risiken, strategische Fragestellungen und damit verbundene Praktiken. (iii) Es nutzt ein kleines Team von Mitarbeitern aus den operativen (Geschäfts-)Einheiten und der IT-Abteilung. (iv) Der Ansatz basiert auf Sicherheits- und operationellen Risikopraktiken; Technologie wird nur im Zusammenhang mit Sicherheitspraktiken untersucht. OCTAVE schafft somit ein Gleichgewicht zwischen drei Aspekten: operationellem Risiko, Technologie und Sicherheitspraktiken. OCTAVE ermöglicht unterschiedliche Start- und Endpunkte in den Risikomanagementaktivitäten einer Organisation; es kann ad hoc oder periodisch durchgeführt werden.

Zu den wichtigsten Unterschieden gegenüber anderen Methoden gehören: (a) Sie ermöglicht die Bewertung von Organisationen, während andere Methoden lediglich das System bewerten. (b) Sie konzentriert sich auf Sicherheitspraktiken, während andere Methoden sich ausschließlich auf die Technologie konzentrieren. (c) Sie behandelt strategische Fragestellungen, während andere Methoden sich ausschließlich mit taktischen Fragestellungen befassen. (d) Sie ermöglicht Selbststeuerung, während andere Methoden ausschließlich von Experten durchgeführt werden.

OCTAVE zeichnet sich durch drei Kernmerkmale aus: (i) Ein interdisziplinäres Team, das sogenannte Analyseteam, führt die Bewertung durch. (ii) Bei der Charakterisierung des Gesamtbildes des Informationssicherheitsrisikos im Unternehmen werden zwei wichtige Perspektiven berücksichtigt: die Geschäfts- und die IT-Perspektive. (iii) Es handelt sich um einen ressourcenorientierten Bewertungsansatz. Die Risikobewertung von OCTAVE basiert auf drei grundlegenden Sicherheitsmanagementprinzipien: Vertraulichkeit, Integrität und Verfügbarkeit. Durch eine einfache Klassifizierung kritischer Informationen wird ein Schutzplan für diese Informationen erstellt. OCTAVE definiert einen systematischen, unternehmensweiten Ansatz zur Bewertung von Informationssicherheitsrisiken.  

Der OCTAVE-Ansatz definiert sich durch eine Reihe von Kriterien, darunter Prinzipien, Attribute und Ergebnisse: (1) Prinzipien. Dies sind grundlegende Konzepte, die die Art der Evaluation bestimmen. Sie konstituieren den Ansatz und bilden die Grundlage für die Evaluation. Selbststeuerung ist beispielsweise eines der OCTAVE-Prinzipien. Selbststeuerung bedeutet, dass die Mitarbeitenden der Organisation am besten geeignet sind, die Evaluation und Entscheidungsfindung zu leiten. Die Evaluationsanforderungen sind in den Attributen und Ergebnissen enthalten. (2) Attribute. Dies sind charakteristische Merkmale der Evaluation. Sie definieren, was eine erfolgreiche Evaluation ausmacht. Sie sind die Anforderungen, die die grundlegenden Elemente des OCTAVE-Ansatzes definieren. Sie legen fest, was für eine erfolgreiche Evaluation aus prozessualer und organisatorischer Sicht notwendig ist. Die Attribute leiten sich von den Prinzipien ab. Ein Beispiel für ein OCTAVE-Attribut ist, dass ein multidisziplinäres Team, das sogenannte Analyseteam, bestehend aus Mitarbeitenden der Organisation, die Evaluation leitet. Das Prinzip, das der Bildung eines Analyseteams zugrunde liegt, ist Selbststeuerung. (3) Ergebnisse. Dies ist das geforderte Resultat jeder Phase. Es werden keine einzelnen Aktivitäten festgelegt, da zur Erreichung der OCTAVE-Ergebnisse mehrere Aktivitäten durchgeführt werden können. Die Ergebnisse definieren die Resultate, die ein Analyseteam während der Evaluierung erzielen muss.

OCTAVE-Risikobewertungsphasen:
Der OCTAVE-Ansatz ermöglicht es Organisationen, ihre Informationssicherheitsrisiken aus organisatorischer Sicht zu verstehen, zu bewerten und zu adressieren. OCTAVE ist kein Produkt, sondern eine prozessorientierte Methodik zur Identifizierung, Priorisierung und zum Management von Informationssicherheitsrisiken. OCTAVE ermöglicht Organisationen die Durchführung folgender Funktionen: (i) Entwicklung qualitativer Risikobewertungskriterien auf Basis der operativen Risikotoleranz. (ii) Identifizierung unternehmenskritischer Assets. (iii) Identifizierung von Schwachstellen und Bedrohungen für kritische Assets. (iv) Ermittlung und Bewertung potenzieller Konsequenzen für die Organisation im Falle des Eintritts von Bedrohungen. (v) Einleitung von Korrekturmaßnahmen zur Risikominderung und Entwicklung einer auf Best Practices basierenden Schutzstrategie.

Im OCTAVE-Prozess lassen sich die folgenden drei Risikobewertungsphasen identifizieren, die als aufeinander aufbauende Workshop-Reihe umgesetzt werden: (1) Phase 1 (Organisationsvision – Bewertung). Hierbei werden Bedrohungsprofile auf Basis der Assets erstellt. Wichtige Assets werden identifiziert, zusammen mit den erforderlichen Schutzmaßnahmen und den jeweiligen Sicherheitsanforderungen. Das Analyseteam ermittelt kritische Assets und die aktuell getroffenen Schutzmaßnahmen. Für jedes kritische Asset werden Sicherheitsanforderungen definiert. Abschließend werden organisatorische Schwachstellen auf Basis bestehender Praktiken ermittelt und das Bedrohungsprofil für jedes kritische Asset definiert. (2) Phase 2 (Technologische Vision – Bewertung). Das Analyseteam identifiziert Netzwerkzugriffspfade und die zugehörigen IKT-Komponentenklassen für jedes kritische Asset. Anschließend wird ermittelt, inwieweit die einzelnen Komponentenklassen gegen Netzwerkangriffe resistent sind, und die technologischen Schwachstellen, die kritische Assets gefährden, werden identifiziert. Dies beinhaltet die Identifizierung von Schwachstellen in der technischen Infrastruktur. Netzwerkzugriffspfade und IKT-Komponentenklassen für jedes Asset werden untersucht und die Widerstandsfähigkeit gegen Netzwerkangriffe bestimmt. (3) Phase 3 (Entwicklung von Sicherheitsplänen und -strategien). Das Analyseteam ermittelt und bewertet die Risiken für die kritischen Anlagen des Unternehmens auf Basis der gesammelten Informationen und legt die geeigneten Maßnahmen fest. Es entwickelt eine Schutzstrategie und Maßnahmenpläne zur Risikominderung. Darüber hinaus definiert das Team die nächsten Schritte für die Implementierung und die Genehmigung des gesamten Prozesses durch die Geschäftsleitung. Die Analyse baut auf den Ergebnissen der vorherigen Phasen auf und identifiziert Risiken für kritische Anlagen, entwickelt Schutzstrategien und Maßnahmenpläne.

Risikobewertungsphasen mit OCTAVE-S und OCTAVE-Allegro.
Im OCTAVE-S-Prozess lassen sich für kleine Organisationen die folgenden vier Prozesse identifizieren: (1) Prozess 1 (Organisationsinformationen ermitteln). Hierbei werden das Wissen des Top-Managements, das Wissen des operativen Bereichsmanagements und das Wissen der Mitarbeiter ermittelt. (2) Prozess 2 (Asset-basierte Bedrohungsprofile erstellen). Hierbei wird das Bedrohungsprofil erstellt, d. h. die Schwachstellen der Organisation und die aktuellen Bedrohungen für jedes kritische Asset werden identifiziert. (3) Prozess 3 (Infrastrukturschwachstellen identifizieren). Hierbei werden Schlüsselkomponenten identifiziert und ausgewählte Komponenten aus der Technologiebewertung evaluiert. Das Analyseteam untersucht die IT-Infrastruktur, um Komponenten zu identifizieren, die mit kritischen Assets und bekannten Technologieschwachstellen zusammenhängen. (4) Prozess 4 (Schutzstrategie und Risikominderungsplan entwickeln). Hierbei werden die Risiken analysiert und der Risikominderungsansatz ausgewählt.

Im OCTAVE-Allegro-Prozess lassen sich die folgenden acht Prozesse in vier Phasen unterteilen: (1) Phase 1 (Treiber definieren). Die Organisation entwickelt Risikobewertungskriterien, die mit ihren Treibern übereinstimmen. Dies umfasst Prozess 1, der Risikomanagementkriterien festlegt. (2) Phase 2 (Asset-Profile erstellen). Kritische Informations-Assets werden identifiziert und Profile erstellt. Dieser Profilierungsprozess definiert klare Grenzen für das Asset, identifiziert seine Sicherheitsanforderungen und alle Orte, an denen das Asset gespeichert, transportiert oder verarbeitet wird. Dies umfasst die Prozesse: (i) Prozess 2, Informations-Asset-Profil entwickeln. (ii) Prozess 3, Informations-Asset-Container identifizieren. (3) Phase 1 (Bedrohungen identifizieren). Bedrohungen für kritische Informations-Assets werden im Kontext der Orte identifiziert, an denen das Asset gespeichert, transportiert oder verarbeitet wird. Dies umfasst die Prozesse: (i) Prozess 4, Interessensbereiche identifizieren. (ii) Prozess 5, Bedrohungsszenarien identifizieren. (4) Phase 4 (Risiken identifizieren und minimieren). Risiken für Informationswerte werden identifiziert und analysiert, und Strategien zur Risikominderung werden entwickelt. Dies umfasst die folgenden Prozesse: (i) Prozess 6: Risiken identifizieren. (ii) Prozess 7: Risiken analysieren. (iii) Prozess 8: Strategie zur Risikominderung auswählen.

Prozess zur Bedrohungsmodellierung und -analyse. Microsoft. STRIDE- und DREAD-Kategorien.
Der Microsoft-Prozess zur Bedrohungsrisikomodellierung, der für die Sicherheit der Webanwendungsentwicklung konzipiert wurde, umfasst fünf Phasen: (i) Sicherheitsziele identifizieren. Anwendungssicherheitsziele lassen sich in folgende Kategorien unterteilen: (a) Identität. Prüfen, ob die Anwendung die Identität des Benutzers vor potenziellem Missbrauch schützt. (b) Finanzieller Verlust. Hoch, wenn es sich um eine Banking-Anwendung handelt. (c) Reputationsverlust, falls die Anwendung missbraucht oder angegriffen wird. (d) Schutz der Benutzerdaten (Datenschutz, Einhaltung gesetzlicher Bestimmungen). (e) Verfügbarkeitsgarantien. Die Anwendung benötigt eine Service-Level-Vereinbarung (SLA). (ii) Architektur und Design der Anwendung analysieren. UML-Komponenten, Datenflüsse und Vertrauensgrenzen überprüfen. (iii) Die Anwendung in Module (z. B. das Authentifizierungsmodul, die Validierung der Dateneingabe und die Annahmen des Moduls) und Funktionen zerlegen. (iv) Bedrohungen und Schwachstellen identifizieren und STRIDE/DREAD anwenden, dann zu Punkt (ii) zurückkehren. Eine mögliche Liste von Bedrohungen umfasst: Ein Angreifer kann die Nachrichten anderer Benutzer lesen; Der Benutzer kann sich nicht von einem gemeinsam genutzten PC abmelden; mangelhafte Datenvalidierung kann SQL-Injection ermöglichen; die Autorisierung kann fehlschlagen und unbefugten Zugriff ermöglichen; der Browser-Cache kann Nachrichteninhalte enthalten. Gegenmaßnahmen umfassen: Implementierung von Datenvalidierung; Implementierung von Autorisierungsprüfungen; Implementierung von Anti-Caching-Direktiven in HTTP-Headern; und Verwendung von SSL/TLS/SSH bei hohem Abhörrisiko. Mögliche Angreifer auf eine Anwendung sind: zufällige Entdeckung durch einen normalen Benutzer aufgrund eines Funktionsfehlers in der Anwendung; automatisierte Malware (Skripte/Programme, die nach Sicherheitslücken suchen); neugierige Angreifer; missverstandene Betrüger; professionell motivierte Angreifer; organisierte Kriminalität usw.   

STRIDE ist ein Klassifizierungsschema zur Charakterisierung bekannter Bedrohungen anhand der verwendeten Exploits oder der Motive der Angreifer. Das Akronym STRIDE setzt sich aus den Anfangsbuchstaben der folgenden Kategorien zusammen: (1) Identitätsdiebstahl (S). Dies stellt ein zentrales Risiko für Anwendungen mit vielen Benutzern dar, die jedoch nur einen einzigen Ausführungskontext auf Anwendungs- oder Datenbankebene bereitstellen. Benutzer sollten sich nicht als andere Benutzer ausgeben oder deren Attribute annehmen können. (2) Datenmanipulation (T). Benutzer können die ihnen übermittelten Daten verändern, zurücksenden und dadurch potenziell clientseitige Validierungen, GET- und POST-Ergebnisse, Cookies, HTTP-Header usw. manipulieren. Die Anwendung sollte keine Daten wie Zinssätze oder Laufzeiten an den Benutzer senden, die nur innerhalb der Anwendung selbst abgerufen werden können. Die Anwendung sollte die vom Benutzer erhaltenen Daten sorgfältig prüfen und deren Korrektheit und Anwendbarkeit vor der Speicherung oder Verwendung bestätigen. (3) Transaktionsverweigerung (R). Benutzer können Transaktionen anfechten und widerrufen, wenn ihre Aktivitäten nicht ausreichend protokolliert werden. Wenn ein Benutzer beispielsweise angibt: „Ich überweise kein Geld auf dieses externe Konto“, und seine Aktivitäten nicht über die Anwendung nachverfolgt werden können, muss die Transaktion höchstwahrscheinlich als Verlust verbucht werden. Daher sollte geprüft werden, ob die Anwendung Kontrollmechanismen zur Beweissicherung benötigt, wie z. B. Webzugriffsprotokolle, Audit-Logs auf jeder Ebene oder die Verwendung desselben Benutzerkontexts von Anfang bis Ende. Idealerweise sollte die Anwendung ausschließlich mit den Benutzerrechten ausgeführt werden, was jedoch bei vielen Anwendungsplattformen nicht möglich ist. (4) Offenlegung von Informationen (I). Benutzer sind verständlicherweise vorsichtig, wenn es darum geht, private Daten an ein System weiterzugeben. Wenn ein Angreifer Benutzerdaten in großem Umfang, anonym oder als autorisierter Benutzer öffentlich machen kann, führt dies zu einem sofortigen Verlust der Vertraulichkeit und einem erheblichen Reputationsschaden. Anwendungen müssen daher strenge Kontrollmechanismen enthalten, um das Erfassen und den Missbrauch der Benutzerkennung zu verhindern, insbesondere wenn sie einen einzigen Kontext für die Ausführung der gesamten Anwendung verwenden. Es ist außerdem wichtig zu prüfen, ob der Webbrowser des Benutzers möglicherweise Informationen preisgibt. Manche Webbrowser ignorieren oder verarbeiten Anweisungen zum Deaktivieren des Caching in HTTP-Headern fehlerhaft. Jede sichere Anwendung ist verpflichtet, die vom Webbrowser gespeicherte Datenmenge zu minimieren, da Angreifer diese Informationen nutzen könnten, um Details über die Anwendung und den Benutzer zu erfahren oder im Falle eines Datenlecks sogar selbst zum Benutzer zu werden. Bei der Implementierung persistenter Werte ist zu beachten, dass die Verwendung versteckter Felder grundsätzlich unsicher ist. Solche Speicher sollten keine sensiblen, vertraulichen Informationen enthalten und keine ausreichenden Schutzmaßnahmen für die Privatsphäre bieten. (5) Denial-of-Service (D). Anwendungsentwickler sollten sich bewusst sein, dass ihre Anwendungen Denial-of-Service-Angriffen ausgesetzt sein können. Daher sollten ressourcenintensive Anwendungen wie große Dateien, komplexe Berechnungen, umfangreiche Suchvorgänge oder lange Abfragen authentifizierten und autorisierten Benutzern vorbehalten und anonymen Benutzern nicht zur Verfügung gestellt werden. Anwendungen, die diese Möglichkeit nicht haben, sollten in jeder Hinsicht so konzipiert sein, dass sie möglichst wenig Arbeit verrichten, wenige und schnelle Datenbankabfragen verwenden und den Zugriff auf große Dateien oder eindeutige Links pro Benutzer vermeiden, um einfache Denial-of-Service-Angriffe zu verhindern. (6) Rechteausweitung (E). Wenn eine Anwendung separate Administrator- und Benutzerrollen bereitstellt, ist es unerlässlich sicherzustellen, dass ein Benutzer seine Rolle nicht auf eine höhere Berechtigungsstufe ausweiten kann. Insbesondere reicht es nicht aus, lediglich Links zu privilegierten Rollen auszublenden. Stattdessen sollten alle Aktionen über eine Autorisierungsmatrix gesteuert werden, um sicherzustellen, dass nur autorisierte Rollen auf privilegierte Funktionen zugreifen können.

DREAD ist ein Klassifizierungsschema zur Quantifizierung, zum Vergleich, zur Rangfolge und zur Priorisierung des Risikos jeder bewerteten Bedrohung. Der Risikowert wird nach folgender Formel berechnet: DREAD-Risiko = (Potenzieller Schaden + Reproduzierbarkeit + Ausnutzbarkeit + Betroffene Benutzer + Auffindbarkeit) / 5. Das Akronym DREAD setzt sich aus den Anfangsbuchstaben der folgenden Kategorien zusammen: (1) Potenzieller Schaden (D). Bestimmt, wie viel Schaden die Bedrohung im Falle ihres Eintretens verursachen würde. Bezieht sich auf das Konzept der Auswirkung. Eine Möglichkeit zur Quantifizierung dieser DREAD-Kategorie ist: Kein Schaden = 0; Daten einzelner Benutzer betroffen oder kompromittiert = 5; Vollständige Zerstörung von Daten oder System = 10. (2) Reproduzierbarkeit (R). Bestimmt, wie leicht die Bedrohung ausgenutzt werden kann. Bezieht sich auf das Konzept der Wahrscheinlichkeit. Eine Möglichkeit zur Quantifizierung dieser DREAD-Kategorie ist: Sehr schwierig oder unmöglich, selbst für Anwendungsadministratoren = 0. (3) Ausnutzbarkeit (E). Bestimmt, was zur Ausnutzung dieser Bedrohung erforderlich ist. Bezieht sich ebenfalls auf das Konzept der Wahrscheinlichkeit. Eine Möglichkeit zur Quantifizierung dieser DREAD-Kategorie ist: Fortgeschrittene Programmier- und Netzwerkkenntnisse mit fortgeschrittenen oder benutzerdefinierten Angriffswerkzeugen = 0; Malware ist im Internet vorhanden oder ein Exploit kann mit verfügbaren Angriffswerkzeugen leicht durchgeführt werden = 5; Nur ein Webbrowser = 10. (4) Betroffene Benutzer (A). Bestimmt die Anzahl der betroffenen Benutzer. Bezieht sich auch auf das Konzept der Auswirkung. Eine Möglichkeit zur Quantifizierung dieser DREAD-Kategorie ist: Keine = 0; Einige Benutzer, aber nicht alle = 5; Alle Benutzer = 10. (5) Auffindbarkeit (D). Bestimmt, wie einfach es ist, diese Bedrohung zu entdecken. Bezieht sich auch auf das Konzept der Wahrscheinlichkeit. Eine Möglichkeit zur Quantifizierung dieser DREAD-Kategorie ist: Sehr schwierig oder unmöglich, erfordert Quellcode oder Administratorzugriff = 0; Kann durch Überwachung von Netzwerkspuren entdeckt werden = 5; Details zu solchen Fehlern sind bereits öffentlich zugänglich und können leicht mit einer leistungsstarken Suchmaschine wie Yahoo/Google gefunden werden = 9; Die Informationen sind in der Adressleiste des Webbrowsers oder in einem Formular sichtbar = 10.

Schlussbetrachtungen
Unsere Forschungsgruppe arbeitet seit über zwanzig Jahren im Bereich der Risikoanalyse, -bewertung und des Risikomanagements auf Netzwerk-, Technologie-, Organisations-, Geschäftseinheits- sowie Ökosystem- und Umgebungsebene, in denen IKT und Wirtschaft in irgendeiner Form interagieren. Dabei wurden verschiedene Methoden und Ansätze angewendet.

Dieser Artikel ist Teil der Aktivitäten des thematischen Netzwerks LEFIS.

Bibliographie

– Areitio, J. „Information Security: Networks, Computing and Information Systems“. Cengage Learning-Paraninfo. 2012.
– Areitio, J. „Identity Management, Strategic Privacy to Minimize Information Security Risks“. Conectrónica Magazine. Nr. 146. April 2011.
– OCTAVE: http://www.cert.org/octave/
– Landoll, D. „Risk Assessment Handbook: A Complete Guide for Performing Security Risk Assessments“. 2. Auflage. CRC Press. 2011.
– Pertier, TR „Information Security Risk Analysis“. 3. Auflage. Auerbach Publications. 2010.
– Norman, TL „Risk Analysis and Security Countermeasure Selection“. CRC Press. 2009.
– Vose, D. „Risk Analysis: A Quantitative Guide“. Wiley. 3. Auflage. 2008.
– Tipton, HF „Information Security Management Handbook“. 6. Auflage. Band 1. 3. Auerbach Publications. 2009.
– Gollmann, D. „Computersicherheit“. 3. Auflage. Wiley. 2011.

Autor:

Prof. Dr. Javier Areitio Bertolín – E-Mail: Diese E-Mail-Adresse ist vor Spambots geschützt. Sie benötigen aktiviertes JavaScript, um sie anzuzeigen.
Professor an der Fakultät für Ingenieurwissenschaften.
Leiter der Forschungsgruppe Netzwerke und Systeme. Universität Deusto.

Weitere Informationen oder ein Angebot