Managed Security vs. Security Management

Beschreibung

Die Themen

Tools zur Durchsetzung von Sicherheitszielen spielen eine wachsende Rolle besonders im Zusammenhang mit der Erfüllung von Sicherheitsnormen wie BS7799 oder dem GSHB. Die Vielzahl verschiedener Tools und Ansätze ist dabei groß. Im Workshop soll anhand von drei Fallbeispielen geklärt werden, was Tools leisten und was sie nicht leisten können.

Zwei Hauptvorträge (mit ausführlicher Diskussion) zum Thema "Managed Security vs. Security Management" oder "wieweit helfen Tools und automatische Abprüfungen".

Bericht zum Workshop und Details zu den Vorträgen

Zum 5.ten mal wurde die Fachgruppe von DB Systems komfortabel eingeladen. Die ca. 30 Teilnehmer haben einen Doppelraum erfordert, der kurzfristig zur Verfügung gestellt wurde. Die von die DB Systems gebotene perfekte Infrastruktur haben wieder einmal eine entspannte Atmosphäre für ausführliche Diskussionen geboten. Tools zur Durchsetzung von Sicherheitszielen spielen eine wachsende Rolle besonders im Zusammenhang mit der Erfüllung von Sicherheitsnormen wie BS7799 oder dem GSHB. Die Vielzahl verschiedener Tools und Ansätze ist dabei groß. Vielfältigen Versprechungen stehen immer wieder auch Schwierigkeiten im praktischen Einsatz gegenüber. Im Workshop wurde anhand dreier Fallbeispiele diskutiert, was Tools bzw. IT-Unterstützung im Allgemeinen leisten können und wo ihre Grenzen sind.

Heinz Sarbinowski/ Fraunhofer SIT:
Der elektronische Sicherheitsinspektor: Unterstützung für eine kontinuierliche Überprüfung von IT-Sicherheitsmaßnahmen in Unternehmensnetzen

Herr Sarbinowski berichtete über den Stand eines abgeschlossenen Forschungsprojekts mit dem Schwerpunkt, technische und organisatorische Vorgaben für Systemkomponenten, wie aus dem GSHB bekannt, automatisch abfragbar und überprüfbar zu machen. In einem Netzwerk müssen dazu aus den verschiedenen Komponenten Informationen zusammengestellt werden. Für Einzelinformationen stehen durchaus schon vielfältige Tools zur Verfügung, die aber geeignet kombiniert werden müssen. Ausserdem müssen zusätzliche Tools zum Auslesen von Prüf-Informationen je nach Bedarf der betroffenen IT-Installation hinzugefügt werden können. Der eSI-Ansatz erlaubt dabei beliebige Tools mit cmd-line-Schnittstellen einzubinden. SNMP-Schnittstellen werden natürlich, wo vorhanden, genutzt. Die Architektur beinhaltet neben der Kommunikationsschiene eine Datenbank, einen Scheduler und ziemlich frei programmierbare Auswerter.

Die Entwicklung eines Tools der vorgestellten Art, aber auch seine Pflege erfordert ein hohes Maß an Sicherheits-Know-How. Routine-Überprüfungen können aber dann automatisiert erfolgen. Eine generelle Regel, wann sich ein solches Vorgehen lohnt, kann noch nicht gegeben werden. Anwender mit einem hohen Prüfaufkommen werden von der Automatisierung profitieren ebenso wie Anwender, die bisher aus Kostengründen auf eine umfassende Prüfung verzichten müssen. Die Interpretation von bei der Inspektion erkannten Abweichungen war eines der Hauptdiskussionspunkte. Derzeit liegen die individuellen Ergebnisse sowohl auf einem hohen Abstraktionsniveaus ("rot-gelb-grün") als auch auf einem technischen Detailniveau vor. Das Thema - Aggregation von Ergebnissen, Gewichtung von Findings etc., liegt derzeit noch nicht im Fokus des Projektes. Die Zielgruppe für ein solches Tool wird zunächst bei Unternehmen mit sicherheitssensitiven Anwendungen gesehen. Die Integration des Tools in System-Management-Tools wird als ein noch zu bearbeitender Punkt gesehen.

Referenzen: www.ske-projekt.de, www.sit.fraunhofer.de 
[  Präsentation als PDF]

Stichworte aus der Diskussion (Mitschrift Hr. Berlich):

• Umsetzung von Überprüfungsprozessen erfordert einen sauberen QM/Verbesserungsprozess. Ein "Big Bang" wird nicht funktionieren.
• Sicherheit des Tools selbst? (Unterscheidung von Systemlese- und Kontrollzugriffen), Werkzeug baut hauptsächlich auf bereits vorhandene Agenten in Netzwerkkomponenten auf. Sicherung gegen Zugriffe auf die Schnittstellen kann u.U. selbst problematisch sein.
• Der Wert des Werkzeugs liegt hauptsächlich in der Benutzerschnittstelle und Datenhaltung/-verwaltung.
• Entwicklung seit zweieinhalb Jahren, bereits einige Kunden. Eindruck: vorwiegend technologieorientiert. Meinungsbildung über Fortschreibung (Open Source oder wie auch immer) noch offen, ebenfalls wie Vertrieb und Marketing. 

Christian Wahl/ Atsec:
Automatisiertes Sicherheitsmanagement - Möglichkeiten und Grenzen

Herr Wahl berichtet über ein vor ca. zwei Jahren erstmals vorgestellte Projekt von Vodafone Information Systems (VIS), das zur Unterstützung der Zertifizierung nach BS7799 ins leben gerufen worden war und mittlerweile im Scope der Zertifizierung enthalten ist.

Beim Security Monitor wurden bereits bei VIS vorhandene Tools (IDS, System management Umgebung etc.) um weitere Werkzeuge (z.B. CERT-Info und Scan-Profile) erweitert und bestehende Verfahren weiterhin genutzt. Ein Ergebnis des erfolgreich etablierten automatisierten Sicherheitsmanagements ist, dass alle sicherheitsrelevanten Ereignisse über den 2nd-Level Support und Trouble-Tickets verfolgt werden und ihre Behandlung damit in einer zentralen Ablage dokumentiert und nachvollziehbar sind.

Zentraler Ansatz des Konzeptes für eine adäquate Abstraktionsebene ist die Nutzung des Tivoli-Risk-Managers als Correlation Engine, um verschiedene Ereignisse zu korrelieren und ggf. zu filtern. Auf diese Weise werden z.B. die vielen "false positives" des IDS auf ein erträgliches Maß zurückgeführt. Das eingeführte Regelwerk musste so in den letzten 2 Jahren nur um wenige Regeln erweitert werden. In mindestens einem Fall wurde ein schwerer Angriff erkannt und ein Host rechtzeitig heruntergefahren. Zusätzliches Personal wurde - obwohl nun auch alle Sicherheits-Events über den 2nd-Level Support geschleift werden - nicht benötigt. Die neue Arbeitsteilung hat die wenigen Leute mit echtem Sicherheits-Know-How von Routine-Tätigkeiten befreit, so dass sie zur Behandlung von Sicherheitsproblemen zur Verfügung stehen.

Der erfolgreiche Einsatz in der Vergangenheit heisst allerdings nicht, dass das System perfekt ist und nicht noch verbessert werden könnte. Eine Erweiterung durch Prüferkenntnisse, wie sie bei einem Einsatz des oben geschilderten "Sicherheitsinspektors" möglich würden, könnte hierzu z.B. effizient beitragen.

Die abschliessende Diskussion war von technischen Detailfragen geprägt, die Melanie Wahl, als maßgeblich am Projekt Beteiligte, beantwortete.

Referenzen: www.projekt.de 
[  Präsentation als PDF]

Stichworte aus der Diskussion (Mitschrift Hr. Berlich):

• Installationsaufwand: Ca. 8 Monate für die gesamte Installation. Pflegeaufwand skaliert mit den Komponenten, das Gesamtsystem reduziert durch die Reduktion der False Positives den Pflegeaufwand.
• Das System ist reaktiv auf Verletzung der "Controls" fokussiert, und stellt sicher, das alle "Controls" betreffenden Ereignisse über den Dokumentationsserver nachvollziehbar sind.
• Das System ist "problemlos" erweiterbar, z. B. (laut Aussage des Vortragenden). (Dabei stellt sich allerdings die Frage, wieweit das über die Nutzung der Workflow Engine des Trouble Ticket Systems hinausgeht, welche Aufwände im Tivoli Risk Manager entstehen etc., in Summe, wie effektiv eine solche Verknüpfung ist) Weitere denkbare Erweiterungen gehen in Richtung Patch-Management. 

Frank Damm/ DB Systems:
Halbautomatische Bewertung des Sicherheitsstandes von IT-Systemen in der Praxis

Ein Überblick über die Praxis der Überprüfungen bei DB Systems zeigt, dass hier nur ein geringer Teil "automatisiert" werden kann. Das augenblickliche Vorgehen basiert noch völlig auf manueller Zulieferung der Information durch Betroffene und Verantwortliche. Die Analyse zeigt, dass wesentliche Daten auch durch eine automatisierte Erfassung nicht erfassbar wären. Automatisiert ist die Verteilung der Fragebögen und deren Ablage, wodurch allerdings schon ein wesentlicher Beitrag für einen "ordnungsmäßigen" Betrieb gegeben ist. Die Datenerfassung erfolgt in Anlehnung (auch Verlinkung) an das GSHB, spezifisch erweitert und detailliert für die aktuelle Umgebung. Die Bewertung erfolgt durch organisatorisch unabhängiges Personal über ein Punkte-System und individuelle Gutachten - im Dialog mit den Verantwortlichen.

Die Analyse von Sicherheitsproblemen der Vergangenheit hat ergeben, dass die jeweiligen Risiken durch die vorhandenen Daten jeweils richtig eingeschätzt und vorhergesagt worden waren. Im Rückblick hat sich also gezeigt, dass sowohl die Datenerfassung als auch die manuelle Bewertung angemessen korrekt und vollständig arbeiten (>"90%"), und dass in Summe das sehr wirtschaftlich arbeitende System trotz der geringen Automatisierung eine angemessene Sicherheit bietet. (Tool-Unterstützung und Automatisierungsgrad wird natürlich trotzdem gemäß dem Stand-der-Technik laufend verbessert.)

Beispiele für die verwendeten Formulare und Bewertungen wurden den Zuhörern zur Einsicht gegeben, können aber nicht im Web frei zugänglich gemacht werden. Ein Überblick über das Sicherheitsmanagement bei DB Systems war auf der GI-Jahrestagung gegeben worden.

Referenz: Vortrag der Herren Damm und Jakoby im Workshop auf der GI-Jahrestagung 2003. 

Peer Reymann/ itqs:
Aktuelles zum "Datenschutz-Gütesiegel"

Herr Reymann stellte ein aktuelles Tagesthema vor, um anzuregen hier ggf. noch gestalterisch mitzuwirken. Die Gruppe hat zwar insgesamt dazu keine Legitimität, einzelne können aber ggf. in ihrem Umfeld aktiv werden. Das Thema der Querbeziehungen zwischen Datenschutz und Management von Informationssicherheit soll allerdings weiterverfolgt werden.

Stichworte (Mitschriften Herr Berlich):

• Übergangsfristen des BDSG 2001 laufen am 23.5.2004 ab;
• Alle relevanten Verfahren müssen in einem Register hinterlegt werden (außer Verarbeitung von "unschädlichen" Daten);
• Erhebung von Daten nur bei den Betroffenen. Keine automatisierten Einzelentscheidungen. §6c: "mobile, personenbezogene Speicher";
• Gütesiegel vs. Datenschutzaudit.