Spezifikation Operationaler Sicherheitsarchitekturen in Mittelständischen Organisationen (SoSo Club Deutschland)

Transkript

1 Spezifikation Operationaler Sicherheitsarchitekturen in Mittelständischen Organisationen (SoSo Club Deutschland) SoSo Club Beauftragter: Jan demeer, smartspacelab.eu GmbH, in Partnerschaft u.a. mit Club R2GS de Reflexion et de Recherche en Gestion - Operationnelle de la Securite, ETSI Industrial Specification Group on Information Security Indicators, GI/ACM Regionalgruppe Berlin-Brandenburg. Diese Initiative zur Gründung eines Sicherheits-Spezifikations-Clubs (kurz, SoSo-Club) in Deutschland, mit dem Zweck Cyber Security Architectures für den Dienstleistungs-Mittelstand (Logistik, Finanz, Verkehr, Elektrogewerbe, aber auch Smart Grid/Metering, Cloud Computing (CC) Dienstleistungen, Technische Messtechnik (RFID) usw.) zu empfehlen, geht auf den Europäischen Normungsbedarf der European Telecommunication Standardization Institute (ETSI), nationalen Normungsinstituten, wie DIN u.a. und auf die bereits in Frankreich und anderen Ländern etablierten Operational Security Management Thought and Research Clubs (R2GS) zurück. Bild 1: SoSo CSA Stakeholders 1

2 SoSo Club Ziele (SoSo Objectives) Der SoSo-Club fühlt sich und seinen Mitgliedern folgenden konkreten Zielen (objectives) verpflichtet: 1. Entwicklung eines CSA-Teilhabermodells (stakeholder model) für Mittelstand und Industrie 2. Spezifikation einer ITIL-prozeßkonformen Sicherheitsreferenzarchitektur für Unternehmen, im Rahmen der Normenserie ISO/IEC 270nn (nn=00 bis 37); 3. Übernahme der Empfehlungen Security Information and Event Management (SIEM) in die Konzipierung der SoSo Cyber Security Architecture (CSA); 4. Verteilung und Anpassung der SoSo-CSA an die Bedürfnisse des Dienstleistungsmittelstands; 5. Konkrete Spezifikation der 11 Kontrollfelder der Cyber Security Alliance zur Anwendung durch Dienstleister; 6. Übernahme und Bearbeitung von Anforderungen aus dem Mittelstand an eine adäquate SoSo-CSA SoSo Teilhabermodell (SoSo stakeholder model) Wir betrachten es gegenwärtig als hinreichend vollständig aus den grundsätzlichen Ansichten folgender 3 Teilhaber -Gruppen, bzw. Klassen (s. Bild 1 SoSo Cyber Security Stakeholders) zu benennen. Somit lassen sich die Rahmenbedingungen, für die Entwicklung einer umfassende SoSo Sicherheits-Referenzarchitektur mit der Menge der Anforderungen aus 3 Sichten der oben genannten Teilhaberklassen (Stakeholder), am besten beschreiben, 1. aus Sicht der Dienstleister, d.h. Kommunikations- und Dienstleistungs-Plattformen (Anforderungs- Modell) 2. aus Sicht der Aufsichtsbehörden, z.b. EU Richtlinie 2000/31/EG, ISO/IEC SC38 Normen etc. (Rechts-/Geschäfts- Modell) 3. aus Sicht der CSA-Technologie, z.b. Verschlüsselungstechniken, sichere Protokolle etc. (Technisches/Implementierungs- Modell) Innerhalb jeder Teilhaberklasse können weitere Teilhaber spezifiziert werden, z.b. werden w.u. im sog. Kontrollfeld 9 1 zur Erzielung von Komplianz, d.h. im Rechtsmodell, 4 weitere Teilhaber genannt. Wie in Bild 1 dargestellt, liefert das Teilhabermodell für die beteiligten Teilhaber 4 Kooperationsbereiche: 1. der SoSo-Kernbereich, der alle Teilhaber betrifft, repräsentiert den Bedarf zur Einrichtung eines betrieblichen Security Operation Centers (SOC) 2. der die Dienstleister, Regulierungs- und Normung-Organisationen betrifft, stellt den Bedarf zur Erzielung der Dienstleistungs-Komplianz dar; 3. der die Dienstleister und Industrie, zur Bereitstellung der erforderlichen technologischen CSA Plattform, betrifft; 4. der die Industrie und Gesetzgebungsbehörden betrifft, zur Erlangung der erforderlichen Garantien, Zertifikate und Gütesiegel. 1 Alle quantitativen Angaben, orientieren sich am Stand der aktuellen Diskussion, von November 2012, aus. 2

3 SoSo-CSA Kontrollfeldspezifikationen (SoSo Control Areas) Aus den Vorbetrachtungen wollen wir eine Methodik zur Gestaltung der SoSo CSA entwerfen, bestehend aus Kontrollfeldern, die jeder Dienstleister m.o.w. reflektieren, bzw. anbieten muß. Bild 2: SoSo CSA Kontrollfelder Die Kontrollfeldspezifikationen der Cloud Controls Matrix [CSA-CCM] kategorisieren sich in 11 (sicherheits-, man auch sagen, qualitätsrelevante) Thematiken, sog. Kontrollfeldern (control areas), wie es im Bild 2 SoSo CSA Kontrollfelder, w.u. dargestellt ist. Jede notwendige Eigenschaft, die sich aus der Beschreibung eines Kontrollfeldes ergibt, muß durch entsprechende Maßnahmen in der Implementierung, z.b. bei der Instanziierung von Prozessen (Objekten) und der Durchsetzung von Strategien (policies) nachgewiesen, bzw. hinreichend getestet werden und ggf. per Audit bestätigt werden können. 3

4 1. Das Feld Informationssicherheit (Information Security) umfaßt 34 Spezifikationen, wie z.b. Vor Nutzung der Datenverarbeitungsanglage soll ein Programm für das Management zur Informationssicherheit (ISMP) eingerichtet werden, um die Unternehmenswerte vor Verlusten, Mißbrauch, unberechtigem Zugriff und Nutzung, unberichtigter Offenlegung, Veränderung oder Zerstörung, zu schützen. 2. Das Feld Personalsicherheit (Human Resources Security) umfaßt 3 Spezifikationen. Bzgl. einer zu vorzunehmenden Sicherheitsklassifikation, ist jeder Kandidat einer entsprechenden Hintergrundüberprüfung, bzgl. lokaler Gesetzgebung, Regulierungen, ethischer und vertraglicher Fragen etc., zu unterziehen. Die zugewiesen Rollen und Verantwortlichkeiten bei Veränderungen müssen dargestellt und dokumentiert werden. 3. Ebenfalls 8 Spezfikationen umfaßt die Gerätesicherheit (Facility Security). Die Gerätesicherheit umfaßt alles, was sicheres Arbeiten im Büro und um das Büro herum, bedeuten mag, z.b. der (phyikalische) Zutritt zu den datenverarbeitenden Werten (information assets), komplexe Benutzerfunktionen, beratendes Personal etc. Pysikalische Schutzräume (Phsyical Security Perimeters), samt Zugänge und Abgänge, um die sensiblen datenverarbeitenden Systeme zu schützen Spezifikationen sind der Datenüberwachung (Data Governance) gewidment. Die Überwachung von Daten umfaßt Maßnahmen zur Einhaltung der Eigentumsrechte. Jedes Datenpaket ist mit entsprechenden Metadaten zu klassifizieren, die die Zuständigkeiten, Daten zu nutzen, beinhalten müssen (Stewardship). 5. Das Feld Widerstandsfähigkeits-Management (Resiliency Management) umfaßt 8 Spezifikationen. Alle Strategien und Verfahren, die den geschäftlichen Fortgang garantieren, als auch die Manöver, sich von einer Krise zu erholen, müssen aktiviert werden, um die Auswirkungen eines möglichen Risikos, zu minimieren. Die Widerherstellung verletzter Datenbestände soll in einem vertretbarem Aufwand möglich und allen Teilhabern bekannt sein. Pläne die dem geschäftlichen Fortschritt dienliche sind, sollen in kurzen Abständen Belastungstests unterworfen werden. 6. Das Feld Risiko-Management (Risk Management) umfaßt 5 Spezifikationen. Dazu gehören Formale Prozeduren, Maßnahmen zur Risikoeinschränkung, die Verwendung neuer Erkenntnisse bei der Festlegung der Sicherheitsstrategien, die Überwachung und Einschätzung von Risiken in Geschäftsprozessen, wo Dritte mitwirken müssen. 7. Das Feld Operatives Management (Operations Management) umfaßt 4 Spezifikationen, d.h in erster Linie die autorisierte Dokumentation von Benuzter- und Administrator-handbüchern, Struktur-Diagrammen, etc. Die Verfügbarkeit von Qualität und ausreichender Kapazitäten der erforderlichen informationsverarbeitenden Ressourcen, soll geplant, zur Verfügung gestellt und die Nutzung vermessen werden, im Einvernehmen mit entsprechenden Regularien und Vereinbarungen. 8. Das Feld Versions-Management (Release Management) umfaßt 5 Spezfikationen. Systematische Qualitätsbewertungen und Kriterien zum Einverständnis über die Ergebnisbeurteilung von datenverarbeitenden Systemen, Upgrades, Neue Versionen werden für das Versions-Management benötigt. 9. Das Feld Legale/Offizielle Angelegenheiten (Legal Affairs) umfaßt 2 Spezifikationen, die z.b. die Anforderungen an Maßnahmen zur Offenlegung, Geheimhaltung im Unternehmen bei gleichzeitiger Wahrung des Unternehmensinteresses an den Informationswerten regelt und dokumentiert. 4

5 Verträgen mit Dritten, die direkt oder indirekt die Informationswerte des Unternehmens müssen der Prüfung unterzogen werden, inwieweit sie die dokumentierten Sicherheitsanforderungen erfüllen. 10. Das Feld Sicherheits-Architektur (Security Architecture) umfaßt 15 Spezifikationen. Die Sicherheitsarchitektur gibt Auskunft über Fragen nach a. Den Anforderungen über den Zugriff externer Kunden zum System (Customer Access), b. der Handhabung der Benutzer-ID-Kreditive (User Id Credentials), der Integrität der Daten und Geheimhaltung der Kommunikation (Data Security), der Sicherheit von Anwendungen (Application Security), c. der Trennung zwischen Informationsverarbeitenden und verwaltenden Stätten, um unbeabsichtigte Veränderungen an Informationswerten oder nicht autorisierten Zugriff darauf zu vermeiden, d. der Handhabung von Mehrfach-Authentifizierungen für Entfernte Benutzer, e. der Einrichtung von Sicherheitsmaßnahmen für alle Kommunikationskanäle und -Netzwerke, f. der physikalischen Trennung zwischen Geschäfts-, Kunden-, Sicherheits-, und Komplianz- (regulatische) Komponenten, g. Maßnahmen zur Sicherheit der drahtlosen Kommunikationskanäle, zur Sicherheit der Netzwerke, die mit Dritten gemeinsam benutzt werden, Maßnahmen zur Taktsysnchronisation, indem man sich auf eine externe Uhrenquelle, die für alle Geräte verbindlich ist, einigt, h. Maßnahmen zur automatischen Kennzeichnung aller Gerätschaften, z.b. indem man die sog. Methode der Verbindungs-Authentifizierung, verwendet, Maßnahmen, die Logdateien bzgl. aller Aktivitäten und Ereignisse privilegierter Benutzer zu untersuchen (auditieren), bzgl. autorisiertem und nicht-autorisiertem Zugang, System-Fehlverhalten, Datensicherheit, ob sie den anzuwendenden Regularien und Strategien entsprechen, i. Maßnahmen zur Autorisierung von mobilem Programmkode, um ihn installieren, benutzen und konfigurieren zu können. Der mobile Agent soll dann in der Lage sein, alle Sicherheitsanforderungen einer Unternehmensstrategie erfüllen zu können Spezifikationen in der CCM-Tabelle sind der System-Komplianz (System Compliance) gewidmet. Komplianz besteht bzgl. Eigentums- und Nutzungsrechten von proprietärer Software und inbezug auf vertragliche Bedingungen, die von involvierten Unternehmen einzuhalten sind. Jedes Teil eines datenverarbeitenden Systems (Daten, Objekte, Anwendungen, Infrastrukturen, Hardware etc.) kann u.u. gesetzgeberischen Regularien oder bindenden Verträgen unterliegen. Dienstleistungen Dritter unterliegen ebenfalls der Komplianz-Nachweispflicht, z.b. mittels eines Audits. Sog. geplante Audits, die von beteiligten Teilhabern (stakeholder) geplant und geführt werden, um Unterbrechungen (Disruptions) der Geschäftsprozesse zu minimieren; sog. unabhängige Audits sollen durchgeführt werden, um sicherzustellen, dass das betroffene Unternehmen relevante Regularien, Standards (Normen), Prozeduren, etc. einzuhalten in der Lage ist. 5