DE102013200159A1

DE102013200159A1 - Management von Sicherheitsrichtlinien unter Verwendung einer Störungsanalyse

Info

Publication number: DE102013200159A1
Application number: DE102013200159A
Authority: DE
Inventors: Christopher Young-Soo Choi; Neil Ian Readshaw
Original assignee: International Business Machines Corp
Current assignee: International Business Machines Corp
Priority date: 2012-01-09
Filing date: 2013-01-09
Publication date: 2013-08-22
Also published as: US20130179938A1; US20130179936A1; CN103198259A

Abstract

Ein Sicherheits-Analytiksystem empfängt Störtfalldaten (von einem Störfall-Managementsystem) und Sicherheitsrichtliniendaten (von einem Sicherheitsrichtlinien-Managementsystem). Das Sicherheits-Analytiksystem vergleicht diese Daten untereinander, vorzugsweise unter Verwendung einer regelbasierten Analysemaschine. Als Ergebnis stellt das Sicherheits-Analytiksystem fest, ob eine bestimmte Sicherheitsrichtlinien-Konfiguration (die durch das Sicherheitsrichtlinien-Managementsystem aufgestellt wird) geändert werden muss (oder sollte), z. B. um die Anzahl von Störfällen, die durch eine Fehlkonfiguration bewirkt werden, zu vermindern, um ihre Wirksamkeit auf irgendeine Weise zu verbessern, oder dergleichen. Als Ergebnis der Bewertung kann das Sicherheits-Analytiksystem bewirken, dass eine Richtlinie automatisch aktualisiert wird, ein Administrator über die Notwendigkeit der Änderung (und die Empfehlung) benachrichtigt wird, oder eine andere Aktion unternommen wird, um eine oder mehrere Sicherheitsrichtlinien zu entwickeln, die durch das Sicherheitsrichtlinien-Managementsystem durchgesetzt werden.

Description

HINTERGRUND DER ERFINDUNG
Technisches Gebiet
Diese Offenbarung bezieht sich allgemein auf das Management von Sicherheitsrichtlinien für Informationstechnologie-(IT-)Systeme.
Hintergrund der verwandten Technik
Informationssicherheit ist der Prozess des Bereitstellens einer Reihe von Steuerungsinstrumenten (a set of controls), um Gefahren unter Kontrolle zu halten (to manage risk), wobei letztendlich die Konformität mit einem Satz von Vorschriften aufgezeigt werden soll. Sicherheitsrichtlinien legen fest, wie eine Reihe von Steuerungsinstrumenten eingesetzt werden sollen und somit, in welchem Umfang Gefahren unter Kontrolle gehalten werden können. Die spezifischen Werte für Attribute in einem Schema von Sicherheitsrichtlinien können modifiziert werden, und diese Modifikationen können die Wahrscheinlichkeit sowohl eines positiven Einflusses (Wirksamkeit beim Verwalten von Gefahren) als auch eines negativen Einflusses (unzufriedene Benutzer, Verlust der Produktivität) auf die Umgebung, die die Richtlinien schützen sollen, ändern.
Informationssicherheitsprofis und ihre geschäftliches Auftraggeber haben stets die Befürchtung dass Änderungen an Sicherheitsrichtlinien in Produktionsumgebungen negative Auswirkungen haben könnten. Eine geringe Benutzerakzeptanz durch eine große Anzahl von Benutzern oder aber eine kleine Anzahl von einflussreichen Benutzern wie etwa den Führungskräften eines Unternehmens kann häufig die Stilllegung eines IT-Sicherheitssystems oder die Verminderung seiner Wirksamkeit auf eine niedrige symbolische Ebene (durch einen begrenzten Umfang oder eine begrenzte Konfiguration) zur Folge haben. Mit der Zeit ist dieses Problem eher sozialer als technischer Natur. Daher verwenden Teams, die die Sicherheitsrichtlinien in praktischen IT-Systemen festlegen, gewöhnlich einen Ansatz, der mit geringem Umfang beginnt und mit der Zeit allmählich erweitert wird.
Die Erweiterung eines Sicherheitssystems sollte im Idealfall mit einem definierten Unternehmensziel verknüpft sein. Dieses Ziel wird jedoch häufig infolge mehrerer Faktoren nicht erreicht. Ein typischer Faktor besteht in der Schwierigkeit, das Team oder die Infrastruktur zu finanzieren, was erforderlich ist, um das Unternehmensziel zu erreichen. Ein weiterer Faktor ist die Erkenntnis, dass der ursprüngliche geschäftliche Antrieb möglicherweise von außen kam wie etwa ein Konformitäts-Regelwerk, bei dem es sich im Laufe der Zeit erwiesen hat, dass eine Nicht-Konformität ohne Konsequenzen blieb. Daher wird in der Praxis häufig ein IT-Sicherheitssystem angetroffen, das sein Potenzial schleppend erreicht und häufig in einem reaktiven Betriebsmodus ist.
Es ist nach dem Stand der Technik bekannt, automatisierte Systeme bereitzustellen, die eine dynamische Einstellung auf Sicherheitsrichtlinien anhand von Ereignissen oder Zustandsänderungen, die in dem geschützten System auftreten, gewährleisten. Ein Nachteil dieses Ansatzes besteht darin, dass die Entscheidung zum Anpassen von Sicherheitsrichtlinien auf Ereignisse in dem IT-System und ein Verständnis eines gewünschten Sicherheitszustands beschränkt ist und nicht auf die Fähigkeit der Organisation gerichtet ist, die Störfälle, die aus der Verwendung von bestimmten Sicherheitsrichtlinien entstehen, effektiv zu verwalten. Eine weitere bekannte Technik gewährleistet eine automatisierte Gefahrenbewertung durch Abgleichen eines gewünschten Zustands von Sicherheitsrichtlinien mit einer Sicherheitskonfiguration in einem tatsächlichen IT-System.
Nach dem Stand der Technik besteht ein Bedarf an Techniken, in einer Organisation Verantwortliche für das Management von Richtlinien in die Lage zu versetzen, die Entwicklung eines auf Richtlinien beruhenden IT-Sicherheitssystems zu optimieren.
Diese Offenbarung ist auf diesen Bedarf geachtet.
KURZE ZUSAMMENFASSUNG DER ERFINDUNG
Diese Offenbarung stellt ein Verfahren und ein System zum Optimieren von Richtlinienänderungen in einem IT-Sicherheitssystem bereit, vorzugsweise durch Integrieren von Informationen des Störfall-Management, die mit der Verwendung des IT-Sicherheitssystems verbunden sind. Nach diesem Ansatz werden Störfalldaten (über das IT-Sicherheitssystem), die durch ein Störfall-Managementsystem gesammelt werden, zu einem ”Sicherheits-Analytiksystem” zurückgeführt (oder anderweitig bereitgestellt) und von diesem verwendet, wobei das System diese Störfalldaten in Bezug auf Sicherheitsrichtlinien-Informationen (bereitgestellt durch ein Richtlinien-Managementsystem) analysiert. Auf der Grundlage dieser Analyse bewirkt (oder empfiehlt) das Sicherheits-Analytiksystem Änderungen an einer oder mehreren Sicherheitsrichtlinien, die durch das Sicherheitsrichtlinien-Managementsystem verwaltet werden. Durch die Verwendung einer Rückkopplung von einem Störfall-Managementsystem, das das IT-Sicherheitssystem unterstützt, ermöglichen die beschriebenen Techniken einem Administrator, die wahrgenommene oder gemessene Auswirkung und die Kosten des negativen Einflusses von einer oder mehreren Richtlinieneinstellungen besser zu verstehen und zu entscheiden, welche Änderungen (oder empfohlene Änderungen) an dem Satz von aktuell verwendeten Richtlinien ausgeführt werden sollten.
Gemäß dieser Offenbarung empfängt somit ein Sicherheits-Analytiksystem Störfalldaten von einem Störfall-Managementsystem und Sicherheitsrichtlinien-Informationen von einem Sicherheitsrichtlinien-Managementsystem. Das Sicherheits-Analytiksystem vergleicht diese Datensätze untereinander, vorzugsweise unter Verwendung einer regelgestützten Analysemaschine. Als ein Ergebnis kann das Sicherheits-Analytiksystem feststellen, ob eine bestimmte Sicherheitsrichtlinien-Konfiguration (aufgestellt durch das Sicherheitsrichtlinien-Managementsystem) geändert werden muss (oder sollte), z. B. um die Anzahl von Störfällen zu reduzieren, die durch eine Fehlkonfiguration bewirkt werden, um seine Effektivität in einer Weise zu verbessern oder dergleichen. Als ein Ergebnis der Bewertung kann das Sicherheits-Analytiksystem bewirken, dass eine Richtlinie automatisch aktualisiert wird, ein Administrator über die Notwendigkeit einer Änderung (und die Empfehlung) informiert wird oder eine andere Maßnahme ergriffen wird, um eine oder mehrere Sicherheitsrichtlinien, die durch das Sicherheitsrichtlinien-Managementsystem durchgesetzt werden, zu entwickeln.
Indem ein Störfall-Managementsystem auf diese Weise integriert wird, werden Störfall-Managementdaten verwendet, um die Analyse von positiven und negativen Auswirkungen von Sicherheitsrichtlinien zu ermöglichen, wodurch ein besseres Sicherheitsrichtlinien-Managementsystem bereitgestellt wird.
Das Vorhergehende hat einige der vielen innewohnenden Merkmale der Erfindung hervorgehoben. Diese Merkmale sollten als rein veranschaulichend ausgelegt werden. Viele weitere nützliche Ergebnisse können durch Anwenden der offenbarten Erfindung auf andere Weise oder durch Modifizieren der Erfindung wie beschrieben wird erreicht werden.
KURZE BESCHREIBUNG DER ZEICHNUNGEN
Für ein vollständigeres Verständnis der vorliegenden Erfindung und ihrer Vorteile erfolgt eine Bezugnahme auf die folgende Beschreibung, die in Verbindung mit den angefügten Zeichnungen erfolgt, worin:
1 ein beispielhaftes Blockschaltbild einer verteilten Datenverarbeitungsumgebung darstellt, in der beispielhafte Aspekte der veranschaulichenden Ausführungsformen umgesetzt werden können;
2 ein beispielhaftes Blockschaltbild eines Datenverarbeitungssystems ist, in dem beispielhafte Aspekte der veranschaulichenden Ausführungsformen umgesetzt werden können;
3 ein Richtlinien-Managementsystem veranschaulicht, in dem die Techniken dieser Offenbarung umgesetzt werden können;
4 veranschaulicht, wie das Sicherheits-Analytiksystem dieser Offenbarung einerseits mit einem Sicherheitsrichtlinien-Managementsystem, das zum Definieren und Verwalten von Sicherheitsrichtlinien für ein geschütztes System verwendet wird, und andererseits mit einem Störfall-Managementsystem, das Sicherheitsereignisse sammelt, die dem geschützten System zugehörig sind, zusammengeführt wird;
5 ein Blockschaubild der funktionellen Komponenten des Sicherheits-Analytiksystem dieser Offenbarung veranschaulicht; und
6 ein Prozessablauf ist, der eine Muster-Störfallanalyseregel veranschaulicht, die durch die Störfallanalysemaschine des Sicherheits-Analytiksystems dieser Offenbarung einer Syntaxanalyse unterzogen wird.
GENAUE BESCHREIBUNG EINER VERANSCHAULICHENDEN AUSFÜHRUNGSFORM
Unter Bezugnahme auf die Zeichnungen und insbesondere unter Bezugnahme auf die 1 und 2 werden beispielhafte Schaubilder von Datenverarbeitungsumgebungen bereitgestellt, in denen veranschaulichende Ausführungsformen der Offenbarung umgesetzt werden können. Es sollte klar sein, dass die 1 und 2 lediglich beispielhaft sind und nicht vorgesehen sind, eine Beschränkung in Bezug auf die Umgebungen, in denen Aspekte oder Ausführungsformen des offenbarten Gegenstands umgesetzt werden können, zu erklären oder anzudeuten. Viele Modifikationen an den dargestellten Umgebungen können ausgeführt werden, ohne vom Erfindungsgedanken und Umfang der vorliegenden Erfindung abzuweichen.
In den Zeichnungen stellt 1 eine bildliche Darstellung eines beispielhaften verteilten Datenverarbeitungssystems dar, in dem Aspekte der veranschaulichenden Ausführungsformen umgesetzt werden können. Das verteilte Datenverarbeitungssystem 100 kann ein Netzwerk von Computern enthalten, in dem Aspekte der veranschaulichenden Ausführungsformen realisiert werden können. Das verteilte Datenverarbeitungssystem 100 enthält wenigstens ein Netzwerk 102, bei dem es sich um das Medium handelt, das verwendet wird, um Datenübertragungslinks zwischen verschiedenen Einheiten und miteinander verbundenen Computern in dem verteilten Datenverarbeitungssystem 100 bereitzustellen. Das Netzwerk 102 kann Verbindungen wie etwa leitungsgestützte, drahtlose Datenübertragungslinks oder Lichtwellenleiterkabel enthalten.
In dem dargestellten Beispiel sind ein Server 104 und ein Server 106 mit einem Netzwerk 102 sowie einer Speichereinheit 108 verbunden. Außerdem sind Clients 110, 112 und 114 ebenfalls mit dem Netzwerk 102 verbunden. Diese Clients 110, 112 und 114 können z. B. Personal Computer, Netzwerkcomputer oder dergleichen sein. In dem dargestellten Beispiel stellt der Server 104 den Clients 110, 112 und 114 Daten wie etwa Boot-Dateien, Betriebssystem-Abbildungen und Anwendungen bereit. Das verteilte Datenverarbeitungssystem 100 kann zusätzliche Server, Clients und andere Einheiten (die nicht gezeigt sind) enthalten.
In dem dargestellten Beispiel handelt es sich bei dem verteilten Datenverarbeitungssystem 100 um das Internet, wobei das Netzwerk 102 eine weltweite Ansammlung von Netzwerken und Gateways repräsentiert, die die Transmission-Control-Protocol/Internet-Protocol-(TCP/IP-)Programmfolge verwenden, um untereinander Daten auszutauschen. Im Mittelpunkt des Internet befindet sich ein Hauptstrang von schnellen Datenübertragungsleitungen zwischen Hauptknoten oder Rost-Computern, die Tausende von kommerziellen, staatlichen, Bildungs- und anderen Computersystemen enthalten, die Daten und Nachrichten lenken. Das verteilte Datenverarbeitungssystem 100 kann natürlich in der Weise realisiert werden, dass es eine Anzahl von unterschiedlichen Typen von Netzwerken enthält wie z. B. ein Intranet, ein Lokalbereichs-Netzwerk (LAN), ein Weitbereichs-Netzwerk (WAN) oder dergleichen. Wie oben angegeben ist 1 als ein Beispiel vorgesehen, nicht als eine Begrenzung der Architektur für unterschiedliche Ausführungsformen des offenbarten Gegenstands, und deswegen sollten die einzelnen Elemente, die in 1 gezeigt sind, in Bezug auf die Umgebungen, in denen die veranschaulichenden Ausführungsformen der vorliegenden Erfindung umgesetzt werden können, nicht als einschränkend betrachtet werden.
In 2 ist ein Blockschaltbild eines Datenverarbeitungssystems gezeigt, in dem veranschaulichende Ausführungsformen umgesetzt werden können. Das Datenverarbeitungssystem 200 ist ein Beispiel eines Computers wie etwa eines Servers 104 oder eines Client 110 von 1, in dem sich computernutzbarer Programmcode oder Befehle, die die Prozesse umsetzen können, für die veranschaulichenden Ausführungsformen befinden kann. In diesem veranschaulichenden Beispiel enthält das Datenverarbeitungssystem 200 eine Datenübertragungsstruktur 202, die Datenübertragungen zwischen der Prozessoreinheit 204, dem Speicher 206, dem permanenten Speicher 208, Datenübertragungseinheiten 210, der Eingabe/Ausgabe-(E/A-)Einheit 212 und der Anzeige 214 bereitstellt.
Die Prozessoreinheit 204 dient zum Ausführen von Befehlen für Software, die in den Speicher 206 geladen werden kann. Bei der Prozessoreinheit 204 kann es sich um eine Gruppe von einem oder mehreren Prozessoren oder in Abhängigkeit von der speziellen Umsetzung um einen Mehrprozessorkern handeln. Des Weiteren kann die Prozessoreinheit 204 unter Verwendung von einem oder mehreren heterogenen Prozessorsystemen ausgeführt sein, in denen sich ein Hauptprozessor mit sekundären Prozessoren auf einem einzigen Chip befindet. Bei einem weiteren veranschaulichenden Beispiel kann es sich bei der Prozessoreinheit 204 um ein symmetrisches Mehrprozessorsystem (SMP) handeln, das mehrere Prozessoren des gleichen Typs enthält.
Der Speicher 206 und der permanente Speicher 208 sind Beispiele von Speichereinrichtungen. Eine Speichereinheit ist jeder Hardware-Abschnitt, der Daten entweder vorübergehend und/oder dauerhaft speichern kann. Der Speicher 206 kann in diesen Beispielen z. B. ein Direktzugriffsspeicher oder jede andere geeignete flüchtige oder nichtflüchtige Speichereinheit sein. Der permanente Speicher 208 kann in Abhängigkeit von der speziellen Umsetzung verschiedene Formen annehmen. Der permanente Speicher 208 kann z. B. eine oder mehrere Komponenten oder Einheiten enthalten. Der permanente Speicher 208 kann z. B. ein Festplattenlaufwerk, ein Flash-Speicher, eine wiederbeschreibbare optische Platte, ein wiederbeschreibbares Magnetband oder eine Kombination aus dem Vorhergehenden sein. Die von dem permanenten Speicher 208 verwendeten Medien können außerdem entnehmbar sein. Ein Festplattenwechsellaufwerk kann z. B. für den permanenten Speicher 208 verwendet werden.
Die Datenübertragungseinheit 210 gewährleistet in diesen Beispielen Datenübertragungen mit anderen Datenverarbeitungssystemen oder -einheiten. In diesen Beispielen ist die Datenübertragungseinheit 210 eine Netzwerk-Schnittstellenkarte. Die Datenübertragungseinheit 210 kann Datenübertragungen durch die Verwendung von physischen und/oder drahtlosen Datenübertragungslinks bereitstellen.
Die Eingabe/Ausgabe-Einheit 212 ermöglicht den Eingabe/Ausgabe-Datenverkehr mit anderen Einheiten, die mit dem Datenverarbeitungssystem 200 verbunden sein können. Die Eingabe/Ausgabe-Einheit 212 kann z. B. eine Verbindung für die Benutzereingabe über Tastatur und Maus bereitstellen. Die Eingabe/Ausgabe-Einheit 212 kann ferner eine Ausgabe zu einem Drucker senden. Die Anzeige 214 stellt einen Mechanismus bereit, um Daten für einen Benutzer anzuzeigen.
Befehle für das Betriebssystem oder Anwendungen oder Programme befinden sich auf dem permanenten Speicher 208. Diese Befehle können für eine Ausführung durch die Prozessoreinheit 204 in den Speicher 204 geladen werden. Die Prozesse der verschiedenen Ausführungsformen können durch die Prozessoreinheit 204 ausgeführt werden, wobei auf einem Computer ausführbare Befehle verwendet werden, die sich in einem Speicher wie etwa dem Speicher 206 befinden. Diese Befehle werden als Programmcode, computernutzbarer Programmcode oder computerlesbarer Programmcode bezeichnet, der durch einen Prozessor in der Prozessoreinheit 204 gelesen und ausgeführt werden kann. Der Programmcode in den verschiedenen Ausführungsformen kann auf verschiedenen physischen oder materiellen computerlesbaren Medien wie etwa der Speicher 206 oder der permanente Speicher 208 verkörpert sein.
Programmcode 216 befindet sich in funktionsfähiger Form auf computerlesbaren Medien 218, die selektiv entnehmbar sind, und kann zur Ausführung durch die Prozessoreinheit 204 in das Datenverarbeitungssystem 200 geladen oder zu diesem übertragen werden. Der Programmcode 216 und die computerlesbaren Medien 218 bilden in diesen Beispielen ein Computerprogrammprodukt 220. In einem Beispiel können die computerlesbaren Medien 218 in einer materiellen Form vorliegen, z. B. eine optische oder magnetische Platte, die in ein Laufwerk oder eine andere Einheit, die Teil des permanenten Speichers 208 ist, eingesetzt oder darin angeordnet wird, für eine Übertragung zu einer Speichereinrichtung wie etwa ein Festplattenlaufwerk, das Teil des permanenten Speichers 208 ist. In einer materiellen Form können computerlesbare Medien 218 außerdem die Form eines permanenten Speichers wie etwa eines Festplattenlaufwerks, eines USB-Stick oder Flash-Speichers annehmen, das mit dem Datenverarbeitungssystem 200 verbunden ist. Die materielle Form von computerlesbaren Medien 218 wird auch als computeraufzeichnungsfähige Speichermedien bezeichnet. In einigen Fallen können computeraufzeichnungsfähige Medien 218 nicht entnehmbar sein.
Alternativ kann der Programmcode 216 von den computerlesbaren Medien 218 über einen Datenübertragungslink mit einer Datenaustauscheinheit 210 und/oder über eine Verbindung mit einer Eingabe/Ausgabe-Einheit 212 zum Datenverarbeiturigssystem 200 übertragen werden. Der Datenübertragungslink und/oder die Verbindung können in den veranschaulichenden Beispielen physisch oder drahtlos sein. Die computerlesbaren Medien können außerdem die Form von nichtmateriellen Medien wie etwa Datenübertragungslinks und/oder drahtlose Übertragungen, die Programmcode enthalten, annehmen. Bei den verschiedenen Komponenten, die für das Datenverarbeitungssystem 200 dargestellt sind. Ist nicht beabsichtigt, dass sie Beschränkungen der Architektur an der Weise darstellen, wie unterschiedliche Ausführungsformen realisiert werden können. Die unterschiedlichen veranschaulichenden Ausführungsformen können in einem Datenverarbeitungssystem realisiert sein, das Komponenten zusätzlich zu den für das Datenverarbeitungssystem 200 gezeigten oder anstelle von diesen enthält. Andere Komponenten, die in 2 gezeigt sind, können von dem gezeigten veranschaulichenden Beispielen abweichen. Ein Beispiel einer Speichereinrichtung in einem Datenverarbeitungssystem 200 ist jede Hardware-Vorrichtung, die Daten speichern kann. Ein Speicher 206, ein permanenter Speicher 208 und computerlesbare Medien 218 sind Beispiele von Speichereinheiten in einer materiellen Form.
In einem weiteren Beispiel kann ein Bussystem verwendet werden, um die Datenübertragungsstruktur 202 zu realisieren, und es können ein oder mehrere Busse enthalten sein wie etwa ein Systembus oder ein Eingabe/Ausgabe-Bus. Das Bussystem kann natürlich unter Verwendung jedes geeigneten Architekturtyps realisiert werden, der eine Übertragung von Daten zwischen unterschiedlichen Komponenten oder Einheiten, die an das Bussystem angeschlossen sind, bereitstellt. Außerdem kann eine Datenaustauscheinheit eine oder mehrere Einheiten enthalten, die verwendet werden, um Daten zu senden oder zu empfangen wie etwa ein Modem oder ein Netzwerkadapter. Des Weiteren kann es sich bei dem Speicher z. B. um den Speicher 206 oder einen Cache-Speicher handeln, wie er z. B. in einer Schnittstelle oder einem Speichersteuereinheiten-Hub vorkommt, der in der Datenübertragungsstruktur 202 vorhanden sein kann.
Computerprogrammcode zum Ausführen von Operationen der vorliegenden Erfindung kann in jeder Kombination aus einer oder mehreren Programmiersprachen geschrieben sein, darunter eine objektorientierte Programmiersprache wie Java^TM, Smalltalk, C++ oder dergleichen und herkömmliche prozedurale Programmiersprachen wie etwa die Programmiersprache ”C” oder ähnliche Programmiersprachen. Der Programmcode kann nur auf dem Computer eines Benutzers, teilweise auf dem Computer eines Benutzers, als ein eigenständiges Software-Paket, teilweise auf dem Computer eines Benutzers und teilweise auf einem fernen Computer oder nur auf dem fernen Computer oder Server ausgeführt werden. In dem zuletzt genannten Szenario kann der ferne Computer mit dem Computer des Benutzers durch einen beliebigen Netzwerktyp verbunden sein, darunter ein lokales Netzwerk (LAN) oder ein Weitverkehrsnetz (WAN), oder die Verbindung kann zu einem externen Computer (z. B. über das Internet unter Verwendung eines Internet-Dienstanbieters) hergestellt werden.
Für einen Fachmann ist klar, dass die Hardware in den 1 und 2 in Abhängigkeit von der Umsetzung variieren kann. Andere interne Hardware oder periphere Einheiten wie etwa ein Flash-Speicher, ein gleichwertiger nichtflüchtiger Speicher oder optische Plattenlaufwerke und dergleichen können zusätzlich zu oder anstelle der in den 1 und 2 gezeigten Hardware verwendet werden. Außerdem können die Prozesse der veranschaulichenden Ausführungsformen auf ein Mehrprozessor-Datenverarbeitungssystem, das von dem oben erwähnten SMP-System verschieden ist, angewendet werden, ohne vom Erfindungsgedanken und Umfang des offenbarten Gegenstands abzuweichen.
Es wird gezeigt werden, dass die hier beschriebenen Techniken in Verbindung mit der üblichen Client-Server-Anordnung wie in 1 dargestellt angewandt können, bei der Client-Maschinen mit einem über das Internet zugänglichen auf dem Web beruhenden Portal, das auf einer Gruppe aus einer oder mehreren Maschinen ausgeführt wird, Daten austauschen. Endbenutzer betreiben mit dem Internet verbindbare Einheiten (z. B. Desktop-Computer, Notebook-Computer, internetfähige mobile Einheiten oder dergleichen), die auf das Portal zugreifen und mit ihm zusammenwirken können. Üblicherweise ist jede Client- oder Server-Maschine ein Datenverarbeitungssystem wie das in 2 dargestellte, das Hardware und Software aufweist, und diese Entitäten tauschen über ein Netzwerk wie etwa das Internet, ein Intranet, ein Extranet, ein privates Netzwerk oder ein beliebiges anderes Datenübertragungsmedium oder ein beliebiges anderes Datenübertragungsmedium oder einen -Link Daten miteinander aus. Ein Datenverarbeitungssystem enthält gewöhnlich einen oder mehrere Prozessoren, ein Betriebssystem, eine oder mehrere Anwendungen und eine oder mehrere Dienstprogramme. Die Anwendungen in dem Datenverarbeitungssystem stellen eine systemspezifische Unterstützung für Web-Dienste bereit, darunter u. a. ohne Einschränkung Unterstützung für HTTP, SOAP, XML, WSDL, UDDI und WSFL. Informationen in Bezug auf SOAP, WSDL, UDDI und WSFL stehen vom World Wide Web-Konsortium (W3C) zur Verfügung, das für Entwicklung und Unterhaltung dieser Standards zuständig ist; weitere Informationen in Bezug auf HTTP und XML sind von Internet Engineering Task Force (IETF) verfügbar. Es wird vorausgesetzt, dass diese Standards allgemein bekannt sind.
Wie beschrieben werden wird, verwendet diese Offenbarung Daten einer ”Störfallanalyse” (die z. B. durch ein Störfall-Managementsystem bereitgestellt werden), um ein Sicherheitsrichtlinien-Management zu verbessern. Systeme zum Sicherheitsrichtlinien-Management sind nach dem Stand der Technik bekannt. 3 veranschaulicht ein repräsentatives System 300 zum Sicherheitsrichtlinien-Management, in dem die nachfolgend beschriebene Technik umgesetzt werden kann. Wie allgemein bekannt kann das System 300 mittels einer oder mehrerer Maschinen, die in einer Datenverarbeitungsumgebung wie etwa die in 1 gezeigte betrieben werden, realisiert werden. Das System weist üblicherweise einen Richtlinienadministrationspunkt (PAP) 302, einen Richtlinienentscheidungspunkt (PDP) 302 und einen Richtliniendurchsetzungspunkt (PEP) 306 auf. Der Richtlinienadministrationspunkt 302 wird im Allgemeinen verwendet, um eine Richtlinie zu definieren, die als ein Satz von XACML-Richtlinienausdrücken spezifiziert sein kann. Diese Richtlinie verwendet Subjektattribute, die von einer Benutzer-Datenablage 308 bereitgestellt werden, sowie Laufzeit- als auch Umgebungsdaten, die vom Richtlinieninformationspunkt (PIP) 310 empfangen werden. Der Richtlinienentscheidungspunkt (PDP) 304 empfängt ähnliche Informationen und antwortet auf eine XACML-Richtlinienabfrage, die von dem Richtliniendurchsetzungspunkt (PEP) 306 empfangen wird, um die Richtlinie an einem Subjekt und in Bezug auf eine bestimmte Aktion, die durch das Subjekt ausgelöst wird, durchzusetzen. Bei einer kommerziellen Umsetzung dieses Ansatzes wird der PAP 302 durch eine IBM^® Tivoli^® Security Policy Manager-(TSPM-)Richtliniendienst/Konsole umgesetzt, der PDP 304 wird in dem TSPM-Laufzeit-Sicherheitsdienst umgesetzt, und der PEP wird als ein TSPM Plug-in to WebSphere^® Anwendungsserver umgesetzt.
Eine ”Richtlinie” kann eine einzelne Richtlinie oder einen Satz von Richtlinien (einen ”Richtliniensatz”) bezeichnen.
Ein System zum Sicherheitsrichtlinien-Management wie das oben beschriebene und in 3 veranschaulichte System ist üblicherweise mit einem ”geschützten System” verbunden, das das System bezeichnet, das Gegenstand bestimmter Sicherheitsrichtlinien ist, die durch das System zum Sicherheitsrichtlinien-Management konfiguriert und durchgesetzt werden. Ein hier verwendetes ”geschütztes System” kann durchaus variiert werden und bezeichnet alle Dienste, Produkte, Maschinen, Gruppen von Maschinen, Geräte, Einheiten, Datenspeicher, Datenbanken und dergleichen, die Gegenstand von Sicherheitsrichtlinien sind. Deswegen kann das geschützte System ein Datenbank-Verwaltungssystem, ein Gerät mit dienstorientierter Architektur (SOA), ein Endpunkt mit Datenverlust-Verhinderung (DLP) usw. sein. Es gibt keine Beschränkung in Bezug auf den Typ des geschützten Systems, das durch Sicherheitsrichtlinien geschützt wird, die durch das System zum Sicherheitsrichtlinien-Management erzeugt werden. Wie allgemein bekannt kann ein System zum Sicherheitsrichtlinien-Management wie das in 3 gezeigte System mit dem geschützten System eng oder lose gekoppelt sein.
Ein geschütztes System kann ein ihm zugeordnetes Störfall-Managementsystem aufweisen, das Systeme für eine rationale Störfall- und Problemverwaltung bereitstellt. Störfall-Management ist ein eindeutig definierter Geschäftsvorgang, der typischerweise einen ”Dienstschaber” (”service desk”) und das zugehörige System und Ressourcen beinhaltet, die verwendet werden, um Probleme in einer Datenverarbeitungs-Infrastruktur sowie an IT-fremden Datenpunkten zu sammeln und zu lösen. Bekannte Störfall-Managementsysteme wie z. B. IBM Tivoli Service Request Manager (TSRM) sind handelsüblich, und diese Systeme können einen einzigen Kontaktpunkt in einem Unternehmen bereitstellen, um die Verwaltung von Störfällen und Problemen zu bewerkstelligen. Diese Typen von Systemen führen üblicherweise Störfälle von mehreren Quellen zusammen wie etwa Endbenutzern, Servicetechnikern, IT-fremden Datenpunkten und Anwendungen zum Management/Überwachung von Netzwerksystemen. Ein Störfall-Management dieses Typs stellt üblicherweise eine Anzahl von Funktionen und Diensten bereit, z. B. – ohne darauf beschränkt zu sein – Self-Service-Support für Endbenutzer, eine Wissensbasis zur Unterstützung von Help-Desk-Agenten, automatische Antworten auf bestimmte Tickettypen oder Ereignis-Klassifizierungen, Echtzeit-Leistungsbetrachtungen, Änderungs- und Freigabe-Verwaltungskapazitäten, Verfolgung von Dienstgütevereinbarungen, integrierte Bewertungsverwaltung und dergleichen.
Sicherheitsereignisse, die dem geschützten System zugehörig sind, werden an das Störfall-Managementsystem in bekannter Weise und unter Verwendung bekannter Schnittstellen bereitgestellt (von diesem gesammelt).
Management von Sicherheitsfestlegungen unter Verwendung einer Störfallanalyse
Mit dem oben genannten Hintergrund wird im Folgenden der Gegenstand dieser Offenbarung beschrieben.
Gemäß dieser Offenbarung und in Bezug auf 4 empfängt ein Sicherheits-Analytiksystem vorzugsweise Informationen sowohl von einem Sicherheitsrichtlinien-Managementsystem (PMS) 400 wie das oben in Bezug auf 3 beschriebene System als auch von einem Störfall-Managementsystem (IMS) 406. Wie oben festgestellt ist das Störfall-Managementsystem 406 üblicherweise eine Unternehmenslösung, die Störfälle verfolgen kann, die in einer Störfall-Datenbank 408 gespeichert werden. Das Sicherheitsrichtlinien-Managementsystem 400 speichert Sicherheitsrichtliniensätze in einer Sicherheitsrichtlinien-Datenbank 402. Einer oder mehrere dieser Sicherheitsrichtliniensätze weisen Sicherheitsrichtlinien auf, die auf ein geschütztes System 404 angewendet werden. Gemäß diesem Ansatz und wie dargestellt empfängt das Sicherheits-Analytiksystem 410 Störfalldaten von dem Störfall-Managementsystem 406, und es empfängt Sicherheitsrichtlinien-Informationen von dem Sicherheitsrichtlinien-Managementsystem 400. Das Sicherheits-Analytiksystem 410 vergleicht im Allgemeinen diese Datensätze (in einer Weise, die im Folgenden beschrieben werden soll), um eine oder mehrere Sicherheitsrichtlinien-Änderungen oder Empfehlungen zu erzeugen, die wieder an das Sicherheitsrichtlinien-Managementsystem 400 bereitgestellt werden (oder in diesem angewendet werden). Auf diese Weise werden eine oder mehrere Sicherheitsrichtlinien entwickelt, indem Störfalldaten, die dem geschützten System zugehörig sind, berücksichtigt werden. Die Integration von Störfalldaten (durch das Sicherheits-Analytiksystem) einerseits und von Sicherheitsrichtlinien-Informationen andererseits gewährleistet erhebliche Vorteile, wie beschrieben werden wird.
Das Sicherheits-Analytiksystem kann ohne Einschränkung als ein Typ einer Datenverarbeitungs-Entität z. B. in einem Datenverarbeitungssystem wie in 2 dargestellt, als ein Datenverarbeitungssystem auf der Grundlage von Clients und Servern wie in 1 dargestellt oder in jeder anderen Weise umgesetzt sein. Eine weitere Alternative setzt das Sicherheits-Analytiksystem als einen cloudgestützten Dienst (in einer Cloud-Datenverarbeitungsumgebung) um. Noch eine weitere Alternative ist ein eigenständiges Software-System. Das Sicherheits-Analytiksystem kann eine Komponente des Sicherheitsrichtlinien-Managementsystems oder aber des Störfall-Managementsystems, des geschützten Systems oder jedes anderen Systems sein. Das Störfall-Managementsystem kann als Produkt, Dienst, Maschine, Gruppe von Maschinen, ein oder mehrere Server, ein oder mehrere Prozessoren, ein oder mehrere Programme oder dergleichen umgesetzt sein. Das Störfall-Managementsystem enthält üblicherweise Management-Schnittstellen (wie etwa eine auf dem Web fußende grafische Benutzerschnittstelle (GUI), eine Befehlsleitungs-Schnittstelle (CLI) oder dergleichen) zur Administration, Konfiguration und Verwaltung. Das Sicherheits-Analytiksystem kann in einem Middleware-Gerät umgesetzt sein. In einer Ausführungsform wird das System in einer auf dem Web fußenden Datenverarbeitungsumgebung betrieben werden und ist über ein Netzwerk wie etwa ein privates Netzwerk, das öffentliche Internet oder dergleichen zugänglich. Das System kann in einer Datenverarbeitungsumgebung oder über mehrere Umgebungen betrieben werden.
Somit kann das Sicherheits-Analytiksystem 410 von 4 in einer Vielfalt von Nutzungsszenarien umgesetzt werden. Wenn das Sicherheitsrichtlinien-Managementsystem 400 in einem Ansatz eine eigenständige Lösung ist, kann das Sicherheits-Analytiksystem 410 als eine Komponente hiervon umgesetzt sein. Wenn das Störfall-Managementsystem 406 eine eigenständige Lösung ist, kann das Sicherheits-Analytiksystem 410 als eine Komponente hiervon umgesetzt sein. In einem Kontext Professionelle Dienste (PS) kann das Sicherheits-Analytiksystem als ein eigenständiges System umgesetzt sein, das vorzugsweise mit dem Störfall-Managementsystem und auch dem Sicherheitsrichtlinien-Managementsystem lose gekoppelt ist. Für einen Fachmann ist klar, dass andere Umsetzungen und Verwendungsfälle für das Sicherheits-Analytiksystem ebenfalls im Umfang dieser Offenbarung liegen.
5 ist ein Blockschaubild, das ein Sicherheits-Analytiksystem 500 darstellt. Zu den verschiedenen funktionalen Komponenten dieses Systems gehören eine Störfalldatenzugangskomponente 502, eine Störfallnormierungskomponente 504, eine Störfallanalyseregelkomponente 506, eine Störfallkorrelationskomponente, eine Richtlinienlesekomponente 510, eine Störfallparserkomponente 512 und eine Störfallanalysekomponente 514 sowie eine Richtlinienschreibkomponente (oder Meldekomponente) 516. Eine oder mehrere dieser Komponenten (oder ”Funktionen”) können mit einer anderen kombiniert werden und die hier verwendete Nomenklatur ist lediglich für Erläuterungszwecke vorgesehen. Jede derartige Komponente ist üblicherweise als Software, als ein Satz von Computerprogrammbefehlen, die auf einem oder mehreren Prozessoren ausgeführt werden können, umgesetzt, um eine spezielle Datenverarbeitungs-Entität oder Maschine aufzuweisen. Alternativ ist eine bestimmte Komponente als Maschine, Einheit, System, Prozess, Programm oder Ausführungs-Thread umgesetzt. Eine Komponente enthält üblicherweise oder weist einen oder mehrere Datensätze auf. Derartige Komponenten und Daten werden üblicherweise im Computerspeicher oder einer oder mehreren Datenspeichereinrichtungen gespeichert.
Die Störfalldatenzugangskomponente 502 ruft Daten über Sicherheitsstörfälle ab, die die Sicherheitsrichtlinien und geschützte Systeme, die durch das Sicherheitsrichtlinien-Managementsystem unter Verwendung des Sicherheits-Analytiksystems verwaltet werden, betreffen. Die Techniken zum Abrufen der Daten sind abhängig von dem verwendeten Störfall-Managementsystem; zu diesen Techniken gehören üblicherweise – ohne darauf beschränkt zu sein – eine Datenbankabfrage (JDBC/JPA/ADO), ein auf SOAP/HTTP fußender Web-Dienst, ein Fernprozeduraufruf (PRC) oder eine andere Anwendungsprogrammierschnittstelle (API).
Die Störfallnormierungskomponente 504 übersetzt Störfalldaten zur Verwendung in der Störfallanalysekomponente 514. Im Einzelnen und in Abhängigkeit vom Schema der Störfalldaten von dem externen System beinhaltet diese Funktion üblicherweise eine oder mehrere der folgenden Operationen: Filtern bestimmter Datenelemente, Kombinieren von Datenelementen, Anreicherung (von anderen Datenquellen), Abbildung (für ein bestimmtes Datenelement) von einer Aufzählung zu einer anderen oder jeden anderen Typ von Datentransformationen. Die Störfallnormierungskomponente 504 transformiert im Allgemeinen die Störfalldaten bei Bedarf, um sicherzustellen, dass die Störfalldaten den Richtlinien von dem Sicherheitsrichtlinien-Managementsystem zugeordnet werden können und ferner Datenelemente, die von der Störfallanalyseregelkomponente 506 gefordert werden, vorhanden sind.
Die Störfallnormierungskomponente 504 filtert vorteilhaft Unregelmäßigkeiten und andere Artifakte aus, die andernfalls die Analyse nachteilig beeinflussen könnten. Die Störfallnormierungskomponente ist hauptsächlich zuständig für das Zusammenfassen und Zusammenführen von Störfalldaten. Dieser Komponente müssen nicht alle Festlegungen und auch nicht, wie sie die Erzeugung von Störfällen beeinflussen können oder beeinflussen, bekannt sein. Die Komponente 504 ist üblicherweise zuständig für das Ausführen einer rudimentären Datenverarbeitung, um sicherzustellen, dass komplette und exakte Informationen an die Störfallanalyse geliefert werden. In einem Störfallbericht kann es z. B. Daten geben wie etwa die Telefonnummer eines Benutzers, die für die Störfallanalyse irrelevant sein können (im Unterschied zu anderen Daten, wie die Rolle des Benutzers, Standort und Texte (wie etwa ”Anmeldefehler”), die helfen können, den Satz von Richtlinien, die den Störfall betreffen, zu identifizieren. Die Normierungskomponente könnte dann so konfiguriert sein, dass sie die Telefonnummer ausfiltert.
Dieses Beispiel ist natürlich lediglich repräsentativ für den Typ der ”Normierungs-”Verarbeitung, die durch die Störfallnormierungskomponente ausgeführt wird und sollte nicht als einschränkend betrachtet werden.
Das Störfallanalyseregelmodul 506 stellt eine oder mehrere Regeln und andere Konfigurationsinformationen bereit, um zu steuern, wie Ausgaben von dem Störfallanalysemodul 514 auf der Grundlage der verschiedenen Eingaben in dieses Modul abgeleitet werden oder abgeleitet werden sollten. Das Störfallkorrelationsmodul 508 korreliert Störfälle gemäß einem oder mehreren Attributen wie etwa Systemkennungen, Benutzeridentitätsattributen, Rollen und zugehörigen Richtlinien und dergleichen als ähnlich. Das Störfallkarrelationsmodul 508 stellt Eingaben in das Störfallanalysemodul 514 bereit, das als eine Verarbeitungsmaschine an diesen Daten (anhand der Störfallanalyseregeln) zum Berechnen von Richtlinienänderungen (oder vorgeschlagenen Richtlinienänderungen) wirkt. Die Störfallanalysekomponente kann an einer einzelnen Sicherheitsrichtlinie oder einem Satz von Sicherheitsrichtlinien wirken. Die Feinteiligkeit, die eine einzelne Sicherheitsrichtlinie ausmacht, variiert üblicherweise bei verschiedenen Sicherheitsrichtlinien-Managementsystemen.
Das Richtlinienlesermodul 510 erhält den aktuellen Zustand von Sicherheitsrichtlinien von dem Sicherheitsrichtlinien-Managementsystem wie das in 3 gezeigte System. Die Techniken zum Abrufen der Daten sind von dem verwendeten Sicherheitsrichtlinien-Managementsystem abhängig; zu den Techniken gehören ohne darauf beschränkt zu sein – eine Datenbankabfrage (JDBC/JPA/ADO), ein auf SOAP/HTTP fußender Web-Dienst, ein Fernprozeduraufruf (PRC) oder eine andere Anwendungsprogrammierschnittstelle (API).
Das Richtlinienparsermodul 512 wird von dem Richtlinienlesermodul 510 verwendet, um Daten zwischen einer internen Darstellung einer Richtlinie (z. B. Java^TM oder Microsoft^TM. Net-Objekte) und dem Format einer Richtlinie (z. B. XML-Dokument), das üblicherweise von einer Schnittstelle zu dem Sicherheitsrichtlinien-Managementsystem erhalten wird, umzuwandeln.
Die Funktion des Richtlinienschreibmoduls 516, das ebenfalls bei Bedarf mit dem Richtlinienparsermodul 512 über eine Schnittstelle verbunden wird, besteht darin, die Sicherheitsrichtlinien-Änderungen in dem Sicherheitsrichtlinien-Managementsystem zu speichern. Die Techniken zum Schreiben der Daten sind abhängig von dem verwendeten Sicherheitsrichtlinien-Managementsystem; zu Techniken gehören üblicherweise – ohne darauf beschränkt zu sein – eine Datenbankabfrage (JDBC/JPA/ADO), ein auf SOAP/HTTP fußender Web-Dienst, ein Fernprozeduraufruf (PRC) oder eine andere Anwendungsprogrammierschnittstelle (API). Bei einer alternativen Umsetzung kann das Richtlinienschreibmodul 516 anstelle des Zurückschreibens einer Richtlinie zu dem Sicherheitsrichtlinien-Managementsystem eine Benachrichtigung an einen Administrator über eine empfohlene Änderung an einer oder mehreren Sicherheitsrichtlinien bereitstellen. In diesem Fall kann jeder Standard-Nachrichtenübermittlungsmechanismus verwendet werden wie etwa eMail über SMTP. Wenn das Sicherheitsrichtlinien-Managementsystem vorläufige Richtlinien oder die Fähigkeit zu Speicherung mehrerer Versionen der gleichen Richtlinie unterstützt, kann das Richtlinienschreibmodul 516 geeignete Aktualisierungen an dem Sicherheitsrichtlinien-Managementsystem bereitstellen, um die gewünschten Änderungen zu bewirken. In noch einer weiteren Alternative kann die Richtlinienschreibeinrichtung einfach eine bestimmte Richtlinie oder einen Satz von Richtlinien als eine neue Version (oder eine vorhandene Richtlinie) mit einer anderen Gefahrenbewertung kennzeichnen.
Wie oben beschrieben steuern die Störfallanalyseregeln, wie die Störfallanalyseausgaben erzeugt werden. 6 veranschaulicht einen Prozessablauf für eine repräsentative Störfallanalyseregel für den Bereich Datenverlustverhinderung (DLP). Eine Störfallanalyseregel wird üblicherweise an einem definierten Satz von Eingaben (Eingabedaten) ausgeführt, die von dem Sicherheitsrichtlinien-Managementsystem in Bezug auf einen Störfall (oder eine Gruppe von Störfällen) bereitgestellt werden. In diesem DLP-Beispiel können diese Eingaben eine oder mehrere der folgenden Eingaben enthalten: Anzahl von Störfällen für einen vorgegebenen Störfalltyp, System, von dem der Störfall stammt, zugehörige Benutzer und Benutzerrollen, zugehörige Richtlinien, Störfallklassifikation und Auflösung (z. B. falsch-positiv, falsch-negativ, ungültige Richtlinie und dergleichen), Störfalldauer und Verlaufsdaten von Auftreten und Auflösung des Störfalls. Die Regel spezifiziert dann einen Entscheidungsbaum zum Erzeugen einer Ausgabe, die spezifiziert, wie die Sicherheitsrichtlinien-Konfiguration geändert werden muss, um entweder die Anzahl von Störfällen, die durch Fehlkonfiguration bewirkt werden, zu verringern oder ihre Wirksamkeit zu verbessern. Wenn die Richtlinie (oder ein Satz von Richtlinien) automatisch aktualisiert werden müssen, weist die Ausgabe vorzugsweise einen Satz von Richtlinienattributen auf wie etwa ”neue Durchsetzungsaktion” (mit den Werten zulassen, auditieren und verweigern) gemeinsam mit den durch die Änderung ”betroffenen Benutzern” auf.
6 veranschaulicht diese Regelverarbeitung (für eine beispielhafte Regel). Die Routine beginnt im Schritt 600. Im Schritt 602 werden die verschiedenen Eingaben für die Regel erhalten. Die Routine wird dann im Schritt 604 fortgesetzt, um zu prüfen, ob eine Anzahl von Störfällen für einen vorgegebenen Störfalltyp (die Anzahl von ”Ereignissen”) einen vorgegebenen Wert ”n” übersteigt. Wenn das nicht der Fall ist, endet die Verarbeitung der Regel im Schritt 606. Wenn das Ergebnis der Prüfung im Schritt 604 jedoch positiv ist, wird die Routine im Schritt 608 fortgesetzt, um zu prüfen, ob die Ereignisse einen Wert falsch-positiv repräsentieren. Wenn das der Fall ist, endet die Routine ebenfalls. Wenn jedoch die Anzahl von Ereignissen überschritten wurde und die Ereignisse keinen Wert falsch-positiv repräsentieren, wird eine Änderung der Sicherheitskonfiguration durchgeführt. Das erfolgt im Schritt 610. Anschließend endet der Prozess.
Jede Störfallanalyseregel legt ihren eigenen Prozessablauf aus einer Gruppe von im Voraus definierten Entscheidungen, Datenelementen und gerichteten Übergangslinien fest. Die bestimmten Einzelheiten einer bestimmten Regel liegen außerhalb des Umfangs dieser Offenbarung. Eine typische Realisierung stellt vorzugsweise einen Mechanismus bereit, um eine vorhandene Gruppe von Regelbestandteilen über Scripting- oder reguläre Ausdrücke zu erweitern. Die Störfallanalyseregeln können als XML oder in einer Datenbank oder einem anderen Datenspeichermechanismus gespeichert werden. Das Sicherheits-Analytiksystem kann außerdem eine auf dem Web fußende grafische Benutzerschnittstelle (GUI) oder dergleichen bereitstellen, damit Störfallanalyseregeln verfasst werden können. Zu kommerziellen Systemen, die verwendet werden können, um diese Möglichkeit der Regelverfassung bereitzustellen, gehören – ohne darauf beschränkt zu sein – IBM Classification Workbench^TM oder IBM Security Manager^TM.
Die bestimmten Regeldefinitionen können durchaus variiert werden und hängen häufig von den Sicherheitsbedürfnissen der Organisation ab, unabhängig von dem Bereich der Sicherheitstechnologie, der verwaltet wird. Das Folgende sind trotzdem repräsentative Szenarien und Regeldefinitionen.
Wenn das IT-System einen stabilen Zustand in Bezug auf das Eintreffen neuer Störfälle und den Abschluss vorhandener Störfälle erreicht hat, kann ein strengerer Satz von Richtlinien eingesetzt werden, die dann abgeschwächt werden, wenn sich das Verhalten der Benutzer ändert. Dieser Zustand wird von dem Zustand unterschieden, der sich aus einer ineffektiven Sicherheitskonfiguration ergibt, wobei ein anfänglicher Spitzenwert der Ankunftsrate festgestellt wird, kurz nachdem ein neuer Satz von Richtlinien eingesetzt wurde. Die Annahme besteht darin, dass die aktuelle Sicherheitskonfiguration das Benutzerverhalten das diese Sicherheitsstörfälle zur Folge hat, effektiv beeinträchtigt.
Wenn die Ankunftsrate neuer Störfälle unerwartet gering ist, kann das eine Anzeige dafür sein, dass die Richtlinien nicht wirkungsvoll sind. Wenn z. B. ein sehr kleiner Inhalt als sensitiv klassifiziert wird, ist entweder der Klassifizierungsprozess unzureichend oder die Richtlinie wird auf keine ausreichende Anzahl von Zielen angewendet.
Wenn eine große Anzahl von falsch-positiven Störfällen für Benutzer mit einer bestimmten Rolle berichtet werden, ist die Abbildung Richtlinie-Rolle gegebenenfalls nicht korrekt.
Wenn eine mittlere Lebensdauer eines Störfalls sehr lang ist, kann ein Kapazitätsproblem vorhanden sein (z. B. mit einem Operationsteam). In diesem Fall sollte die Störfallanalyse empfehlen, entweder die Belegschaftskapazität zu vergrößern oder einen weniger strengen Satz von Richtlinien zu verwenden, bis das Kapazitätsproblem gelöst wurde.
Der beschriebene Ansatz ermöglicht im Allgemeinen, dass Störfalldaten verwendet werden, um eine Störfallanalyseregel zu definieren, die eine vorgegebene Richtlinie abschwächt, z. B. da die Richtlinie zu viele Störfälle bewirkt, oder die Richtlinie strenger macht, z. B. da die Anzahl (oder Rate) von Störfällen unter einem erwarteten (oder konfigurierbaren) Wert liegt.
Ein Richtlinienmanagement unter Verwendung einer Störfallanalyse gemäß dieser Offenbarung erbringt beträchtliche Vorteile. Es verbessert die Art und Weise der Abläufe in einer Organisation oder lässt die Umgebung unverändert, die durch ein Sicherheitsrichtlinien-Managementsystem geschützt wird. Es ermöglicht dem Operator, die Entwicklung eines auf Richtlinien beruhenden IT-Sicherheitssystems effektiver zu optimieren. Insbesondere ermöglicht die Technik durch Kombinieren einer Rückkopplung von einem Störfall-Managementsystem (das das IT-Sicherheitssystem unterstützt) mit der wahrgenommenen oder gemessenen Effektivität (oder dem negativen Einfluss) eines oder mehrerer Richtliniensätze Änderungen (oder empfohlene Änderungen) an der aktuellen Sicherheitsrichtlinie oder den aktuellen Sicherheitsrichtlinien. Der Ansatz der Verwendung einer Störfallanalyse zum Verwalten einer Sicherheitsrichtlinie schließt explizit die Schleife zwischen funktionalen Aspekten und Richtlinienmanagement-Aspekten eines IT-Sicherheitssystems. Der Ansatz beschleunigt das Ansteigen der Effektivität und des positiven Einflusses eines IT-Sicherheitssystems. Des Weiteren hilft der Ansatz sicherzustellen, dass das Einführen eines Sicherheitssystems die Stellenbesetzung eines funktionsfähigen Teams, das für seine Unterstützung erforderlich ist, nicht verschlechtert. Schließlich gewährleistet die Technik einen faktengestützten Mechanismus zur Verbesserung von Sicherheitsrichtlinien, die vorzugsweise in das eigentliche IT-System integriet sind.
Die bestimmte Technik kann verwendet werden, um ein Management jedes Typs von Richtlinien zu ermöglichen, darunter – ohne darauf beschränkt zu sein – eine Sicherheitsrichtlinie, eine Zugangsrichtlinie, eine Datenverlust-Verhinderungsrichtlinie (wie etwa in einem DLP-System), eine Identitätsbereitstellungsrichtlinie, eine Web-Zugangssteuerungsrichtlinie und dergleichen.
Wie oben angemerkt kann die beschriebene Funktionalität als ein eigenständiger Ansatz umgesetzt werden, z. B. als eine softwaregestützte Funktion, die durch einen Prozessor ausgeführt wird, oder sie kann als ein verwalteter Dienst zur Verfügung gestellt werden (darunter ein Web-Dienst über eine SOAP/XML-Schnittstelle). Die hier beschriebenen Einzelheiten der bestimmten Hardware- und Software-Umsetzung dienen lediglich erläuternden Zwecken und sollen keine Beschränkung des Umfangs des beschriebenen Gegenstands darstellen, Allgemeiner gesagt sind die Datenverarbeitungseinheiten im Kontext des offenbarten Gegenstands jeweils ein Datenverarbeitungssystem (wie in 2 gezeigt), das Hardware und Software aufweist, und diese Entitäten tauschen Daten über ein Netzwerk wie etwa das Internet, ein Intranet, ein Extranet, ein privates Netzwerk oder jedes andere Datenübertragungsmedium oder jeden anderen Datenübertragungslink aus. Die Anwendungen in dem Datenverarbeitungssystem stellen eine systemspezifische Unterstützung für Web-Dienste und andere bekannte Dienste und Protokolle bereit, darunter – ohne darauf beschränkt zu sein – eine Unterstützung für HTTP, FTP, SMTP, SOAP, XML, UDDI und WSFL. Informationen in Bezug auf SOAP, WSDL, UDDI und WSFL stehen vom Word Wide Web-Konsortium (W3C) zu Verfügung, das für die Entwicklung und Unterhaltung dieser Standards zuständig ist; weitere Informationen in Bezug auf HTTP, FZP, SMTP und XML stehen von der Internet Engineering Task Force (IETF) zur Verfügung. Es wird vorausgesetzt, dass diese Standards und Protokolle allgemein bekannt sind.
Das hier beschriebene Schema kann in oder in Verbindung mit verschiedenen serverseitigen Architekturen umgesetzt werden, darunter einfache n-stufige Architekturen, Web-Portale, Verbund-Systeme und dergleichen. Die hier verwendeten Techniken können in einer lose gekoppelten Server-Umgebung (darunter eine ”cloud-” gestützte Umgebung) praktiziert werden.
Noch allgemeiner kann der hier beschriebene Gegenstand die Form einer reinen Hardware-Ausführungsform, einer reinen Software-Ausführungsform oder einer Ausführungsform, die sowohl Hardware- als auch Software-Elemente enthält. In einer bevorzugten Ausführungsform wird die Funktion in Software umgesetzt, die Firmware, residente Software, Mikrocode und dergleichen enthält, jedoch nicht darauf beschränkt ist. Des Weiteren kann die hier beschriebene DLP-Richtlinienzuordnungsfunktionalität wie oben beschrieben die Form eines Computerprogrammprodukts annehmen, auf das von einem computernutzbaren oder computerlesbaren Medium zugegriffen werden kann, das Programmcode zur Verwendung durch oder in Verbindung mit einem Computer oder einem Befehlsausführungssystem bereitstellt. Für die Zwecke diese Beschreibung kann ein computernutzbares oder computerlesbares Medium jede Vorrichtung sein, die das Programm zur Verwendung durch oder in Verbindung mit dem Befehlsausführungssystem, einer Vorrichtung oder einer Einheit zur enthalten oder speichern kann. Das Medium kann ein elektronisches, magnetisches, optisches, elektromechanisches, Infrarot- oder eine Halbleitersystem (oder Vorrichtung oder Einheit) sein. Zu Beispielen eines computerlesbaren Mediums gehören ein Halbleiter- oder Festkörperspeicher, Magnetband, eine entnehmbare Computerdiskette, ein Direktzugriffsspeicher (RAM), ein Festwertspeicher (ROM), eine starre Magnetplatte und eine optische Platte. Zu gegenwärtigen Beispielen von optischen Platten gehören Compactdisk-Festwertspeicher (CD-ROM), Compactdisk-Lese/Schreib (CD-R/W) und DVD. Das computerlesbare Medium ist ein materielles Element.
Das Computerprogrammprodukt kann ein Produkt mit Programmbefehlen (oder Programmcode) sein, um eine oder mehreren der beschriebenen Funktionen umzusetzen. Diese Befehle oder dieser Code können in einem computerlesbaren Speichermedium in einem Datenverarbeitungssystem gespeichere sein, nachdem sie bzw. er von einem fernen Datenverarbeitungssystem über ein Netzwerk heruntergeladen wurden. Diese Befehle oder dieser Code können alternativ in einem computerlesbaren Speichermedium in einem Datenverarbeitungssystem gespeichert sein und eingerichtet sein, um über ein Netzwerk zu einem fernen Datenverarbeitungssystem für eine Verwendung in einem computerlesbaren Speichermedium in dem fernen System heruntergeladen zu werden.
In einer repräsentativen Ausführungsform sind das Sicherheits-Analytiksystem oder eine oder mehrere seiner Komponenten-Teilsysteme in einem Spezial-Computer vorzugsweise in Software, die durch einen oder mehrere Prozessoren ausgeführt wird, umgesetzt. Die Software wird in einer oder mehreren Datenspeichereinrichtungen oder Speichern gespeichert, die dem einen oder den mehreren Prozessoren zugehörig sind, und die Software kann als ein oder mehrere Computerprogramme umgesetzt sein. Diese spezielle Hardware und Software weisen eine vorhandene Richtlinienmanagement-Lösung auf oder ergänzen diese wie beschrieben wurde.
In einer repräsentativen Ausführungsform stellt die Management-Konsole des Sicherheitsrichtlinien-Managementsystems eine oder mehrere auf dem Web fußende Schnittstellen bereit, die verwendet werden können, eine Störfallanalyseregel in der beschriebenen Weise zu erzeugen und/oder zu modifizieren.
Wie angemerkt kann die beschriebene Sicherheitsanalysefunktionalität (d. h. die Verwendung einer Störfallanalyse zum Verbessern des Sicherheitsrichtlinien-Managementsystems) als eine Ergänzung oder Erweiterung einer vorhandenen Richtlinienmanagement-Lösung, eines Störfall-Managementsystems, eines geschützten Systems oder dergleichen umgesetzt sein.
Während das Obige eine bestimmte Reihenfolge von Operationen beschreibt, die durch bestimmte Ausführungsformen der Erfindung ausgeführt werden, sollte klar sein, dass diese Reihenfolge beispielhaft ist, da bei alternative Ausführungsformen die Operationen in einer anderen Reihenfolge ausgeführt werden können, bestimmte Operationen kombiniert werden können, sich überlappen können und dergleichen mehr. Verweise in der Beschreibung auf eine gegebene Ausführungsform geben an, dass die beschriebene Ausführungsform ein bestimmtes Merkmal, eine Struktur oder eine Eigenschaft enthalten kann, jedoch muss nicht jede Ausführungsform zwingend das bestimmte Merkmal, die Struktur oder die Eigenschaft enthalten.
Obwohl die vorgegebenen Komponenten des Systems einzeln beschrieben wurden, ist einem Fachmann klar, dass einige der Funktionen in vorgegebenen Befehlen, Programmsequenzen, Codeabschnitten und dergleichen kombiniert oder gemeinsam genutzt werden können.
Jede Anwendung oder Funktionalität, die hier beschrieben sind, können als systemspezifischer Code umgesetzt werden, indem Hooks in einer anderen Anwendung bereitgestellt werden, die Verwendung des Mechanismus als ein Plug-in ermöglicht wird, durch Verknüpfen der Mechanismen und dergleichen.
Wie angemerkt kann die Funktion des oben beschriebenen Sicherheits-Analytiksystems in jedem System, jeder Einheit, jedem Portal, jeder Site oder dergleichen verwendet werden, bei denen es erwünscht ist, Daten zum Verwalten von Sicherheitsrichtlinien zu analysieren.
Nachdem die Erfindung beschrieben wurde, beanspruchen wir nun das Folgende.

Claims

Verfahren zum Verwalten von Richtlinienänderungen in einem Informationstechnologie-(IT-)System, wobei das Verfahren aufweist: Empfangen von Störfalldaten, die einem oder mehreren Sicherheitsstörfällen zugehörig sind, die in dem IT-Sicherheitssystem auftreten; Empfangen von Sicherheitsrichtliniendaten, die einer Sicherheitsrichtlinie zugehörig sind, die in dem IT-Sicherheitssystem gültig ist; Anwenden einer Störfallanalyseregel auf die empfangenen Störfalldaten und die empfangenen Sicherheitsrichtliniendaten, um eine Änderung an einem oder mehreren Attributen einer neuen Sicherheitsrichtlinie für das IT-Sicherheitssystem zu berechnen; und Zuordnen des einen oder der mehreren Attribute der neuen Sicherheitsrichtlinie zu dem IT-Sicherheitssystem.
Verfahren nach Anspruch 1, wobei die Störfalldaten von einem Störfall-Managementsystem empfangen werden, das das IT-Sicherheitssystem unterstützt.
Verfahren nach einem der vorhergehenden Ansprüche 1 bis 2, wobei die Störfalldaten enthalten: eine Anzahl von Störfällen oder eine Anzahl von Störfällen für einen vorgegebenen Richtlinientyp oder eine Kennung eines Systems, von dem ein Störfall stammt, oder ein Benutzer oder eine Benutzerrolle, die dem Störfall zugehörig ist, oder eine Störfallklassifizierung und Auflösung oder eine Störfalldauer oder Verlaufsdaten von Ankunft und Auflösung eines Störfalls.
Verfahren nach einem der vorhergehenden Ansprüche 1 bis 3, wobei die Regel eine Wirksamkeit der Sicherheitsrichtlinie quantifiziert.
Verfahren nach einem der vorhergehenden Ansprüche 1 bis 4, wobei die Regel den Einfluss einer Änderung der Sicherheitsrichtlinie quantifiziert.
Verfahren nach Anspruch 1, wobei das eine oder die mehreren Attribute der neuen Sicherheitsrichtlinie automatisch zugeordnet werden.
Verfahren nach Anspruch 1, wobei das eine oder die mehreren Attribute der neuen Sicherheitsrichtlinie zugeordnet werden, indem eine Benachrichtigung an einen Administrator bereitgestellt wird.
Verfahren nach einem der vorhergehenden Ansprüche 6 bis 7, wobei die neue Sicherheitsrichtlinie eine Richtlinie ist, die die Sicherheitsrichtlinie ersetzt, die in dem IT-Sicherheitssystem gültig ist, oder eine Variante der Sicherheitsrichtlinie ist, die in dem IT-Sicherheitssystem gültig ist, oder eine Aktualisierung der Sicherheitsrichtlinie ist, die in dem IT-Sicherheitssystem gültig ist.
Vorrichtung, die aufweist: einen Prozessor; Computerspeicher, der Computerprogrammbefehle speichert, die ein Verfahren zum Verwalten von Richtlinienänderungen in einem Informationstechnologie-(IT-)Sicherheitssystem ausführen, wenn sie durch den Prozessor ausgeführt werden, wobei das Verfahren aufweist: Empfangen von Störfalldaten, die einem oder mehreren Sicherheitsstörfällen zugehörig sind, die in dem IT-Sicherheitssystem auftreten; Empfangen von Sicherheitsrichtliniendaten, die einer Sicherheitsrichtlinie zugehörig sind, die in dem IT-Sicherheitssystem gültig ist; Anwenden einer Störfallanalyseregel auf die empfangenen Störfalldaten und die empfangenen Sicherheitsrichtliniendaten um eine Änderung an einem oder mehreren Attributen einer neuen Sicherheitsrichtlinie für das IT-Sicherheitssystem zu berechnen; und Zuordnen des einen oder der mehreren Attribute der neuen Sicherheitsrichtlinie zu dem IT-Sicherheitssystem.
Vorrichtung nach Anspruch 9, wobei die Störfalldaten von einem Störfall-Managementsystem empfangen werden, das das IT-Sicherheitssystem unterstützt.
Vorrichtung nach einem der vorhergehenden Ansprüche 9 bis 10, wobei die Störfalldaten enthalten: eine Anzahl von Störfällen oder eine Anzahl von Störfällen für einen vorgegebenen Richtlinientyp oder eine Kennung eines Systems, von dem ein Störfall stammt, oder ein Benutzer oder eine Benutzerrolle, die dem Störfall zugehörig ist, oder eine Störfallklassifizierung und Auflösung oder eine Störfalldauer oder Verlaufsdaten von Ankunft und Auflösung eines Störfalls.
Vorrichtung nach Anspruch 9, wobei die Regel eine Wirksamkeit der Sicherheitsrichtlinie und/oder einen Einfluss einer Änderung der Sicherheitsrichtlinie quantifiziert.
Vorrichtung nach Anspruch 9, wobei das eine oder die mehreren Attribute der neuen Sicherheitsrichtlinie automatisch und/oder durch das Bereitstellen einer Benachrichtigung an einen Administrator zugeordnet werden.
Vorrichtung nach Anspruch 13, wobei die neue Sicherheitsrichtlinie eine Richtlinie ist, die die Sicherheitsrichtlinie ersetzt, die in dem IT-Sicherheitssystem gültig ist, oder eine Variante der Sicherheitsrichtlinie ist, die in dem IT-Sicherheitssystem gültig ist, oder eine Aktualisierung der Sicherheitsrichtlinie ist, die in dem IT-Sicherheitssystem gültig ist.
Computerprogrammprodukt, das vom Computer ausführbare Befehle aufweist, um die Verfahrensschritte nach einem der vorhergehenden Verfahrensansprüche auszuführen.