Projektbericht zu Umsetzung der EU-DSGVO

Toolgestützt oder mit der Hand am Arm?

Aron Mildemann, Datenschutzbeauftragter, Internationales Bankhaus Bodensee AG

 

 

 

 

 

 

Martin Wiesenmaier, Geschäftsführer, FORUM Gesellschaft für Informationssicherheit mbH

 

 

 

Im Zuge der Umsetzung der Anforderungen aus der EU-DSGVO sowie dem BDSG-neu war die Internationales Bankhaus Bodensee AG (IBB AG) auf der Suche nach einem Tool, um die erforderlichen Dokumentationen revisionssicher, effizient und nachhaltig umzusetzen. Nach Sichtung mehrerer Lösungen fiel die Wahl auf die Software ForumDSM. Nicht zuletzt auch, weil bei der IBB AG bereits andere Tools aus der ForumSuite im Einsatz sind und somit die bereits erfassten datenschutzrelevanten Stammdaten wie Geschäftsprozesse, Datenklassen oder IT-Anwendungen als „Vorlage“ effizient genutzt werden können.

SEMINARTIPPS

Datenschutz Kompakt, 21.11.2019, Frankfurt/M.

Informationssicherheit & Datenschutz – Prozesse effizient gestalten, 05.12.2019, Frankfurt/M.

Datenschutz bei der Verarbeitung/Nutzung von Beschäftigtendaten, 01.04.2020, Berlin.

Informationssicherheit & Datenschutz: Spannungsfeld & Schnittmengen, 02.04.2020, Berlin.

Ausgangssituation

Bis zur Einführung von ForumDSM wurden sämtliche Dokumentationen und Tätigkeiten aus dem alten BDSG mittels Word, Excel sowie anderen „Insellösungen“ umgesetzt. Da die neuen Anforderungen der EU-DSGVO erhöhte Anforderungen an eine aktuelle und vollständige Dokumentation des Datenschutzmanagements stellen, wurde entschieden, künftig Tool-basiert möglichst sämtliche Vorgänge in einer zentralen Lösung zu erfassen.

Projektumsetzung

Die größte Herausforderung im Projekt war sicherlich die Umsetzung der zahlreichen zusätzlichen Dokumentationserfordernisse aus der EU-DSGVO wie z. B. das Verzeichnis der Verarbeitungstätigkeiten, die Datenschutz-Folgenabschätzung, die Risikobewertung sowie die zahlreichen Prüfungshandlungen.

BUCHTIPP

Göhrig/Maull/Petersen (Hrsg.), Managementleitfaden Datenschutz, 2019.

 

Gemeinsam mit den Prozessverantwortlichen wurde das Verzeichnis der Verarbeitungstätigkeiten in der Anwendung ForumDSM angelegt und um die erforderlichen Angaben (Zweckbestimmung, Rechtsgrundlage, Datenkategorien, Datenherkunft, Betroffene, Empfänger, Löschfristen sowie die Risikobewertung) ergänzt.

Des Weiteren wurden die Dienstleister, die eine Auftragsverarbeitung für die IBB AG erbringen, in der Anwendung angelegt und mit Hilfe der in ForumDSM hinterlegten Checkliste eine Vertragsprüfung aller Auftragsverarbeiter durchgeführt.

Diese und viele andere Funktionen (Datenschutzfolgenabschätzung, Schulungskalender, Auditkalender) in der Anwendung werden genutzt, um der Rechenschaftspflicht nach Art. 5 Abs. 2 DSGVO nachkommen zu können.

Besonders hilfreich bei der Umsetzung waren die in ForumDSM enthaltenen Vorschläge zum Datenschutzmanagement. Nach einer ersten Sichtung und geringfügigen Anpassungen an die Gegebenheiten bei der IBB AG konnten diese weitgehend in den Produktivbereich übernommen werden.

ForumDSM unterstützt zugleich den Datenschutzbeauftragten, um seinen Aufgaben nach Art. 39 EU-DSGVO nachkommen zu können. Anhand der dokumentierten Angaben in ForumDSM, z. B. zum Verzeichnis der Verarbeitungstätigkeiten, können verschiedene Auswertungen erstellt und darauf aufbauend risikoorientierte Prüfungshandlungen abgeleitet werden, wie z. B.:

  • Einhaltung der hinterlegten Löschfristen
  • Überprüfung der Rechtmäßigkeit der Verarbeitung
    • Liegen Einwilligungserklärungen vor?
    • Entsprechen die Einwilligungserklärungen den Bedingungen gem. Art. 7 EU-DSGVO?
    • Dokumentation bei der Verarbeitung zur Wahrung des berechtigten Interesses.
  • Überwachung der Durchführung von Datenschutz-Folgenabschätzungen gem. Art. 35 EU-DSGVO
  • Überprüfung der Auftragsverarbeiter
    • Liegen Verträge vor?
    • Entsprechen die Verträge den Anforderungen gem. Art 28 EU-DSGVO?
    • Überprüfung der erforderlichen Maßnahmen gem. Art. 32 EU-DSGVO beim Auftragsverarbeiter.

Fazit

Die hohen Dokumentationserfordernisse aus der EU-DSGVO konnten mithilfe der Anwendung ForumDSM strukturiert durchgeführt werden. Die Anwendung ForumDSM, unterstützt die IBB AG die Vorgaben der EU-DSGVO revisionssicher, effizient und nachhaltig einzuhalten und gleichzeitig der Rechenschaftspflicht nach Art. 5 Abs. 2 EU-DSGVO nachzukommen.

 

PRAXISTIPPS

  • Versuchen Sie das Verzeichnis der Verarbeitungstätigkeiten möglichst prozessorientiert aufzubauen und mehrere gleichgelagerte Geschäftsprozesse zu einem Verfahren zusammenzufassen.
  • Machen Sie eine Bestandsaufnahme aller Auftragsverarbeiter und überprüfen Sie die Verträge, ob diese den Anforderungen gem. Art. 28 EU-DSGVO genügen.
  • Ein toolbasiertes Datenschutzmanagementsystem kann hilfreich sein, die hohen Dokumentationserfordernisse zentral vorzuhalten.

 

Beitragsnummer: 87176

Synergien im Beauftragtenwesen



Chancen für Banken bei der Erstellung von Risikoanalysen und Kontrollplänen im Datenschutz, der Informationssicherheit, dem Business Continuity Management und Auslagerungsmanagement .

Christian Maull, Datenschutzbeauftragter, Compliance, TeamBank AG

I. Zunehmende Regulatorik

Das Beauftragtenwesen und die Compliance sind mittlerweile, u. a. aufgrund zunehmend schärfer werdender regulatorischer Vorgaben, essenzieller Bestandteil des Internen Kontrollsystems von Banken. Dennoch nehmen die Aufgaben und Funktionen innerhalb der Second-Line-of-Defense stetig zu. Neue oder verschärfte Themenfelder und teils auch neue Beauftragte beschäftigen Banken, und nur teilweise ist die Bündelung dieser Funktionen in Personalunion aufgrund möglicher Interessenskonflikten zulässig. Umso wichtiger ist deshalb eine effektive Abstimmung und Zusammenarbeit der Beauftragten. Häufig liegt die Herausforderung jedoch nicht ausschließlich in der Kommunikation zwischen Beauftragten, sondern an den durch die Bank geschaffenen Rahmenbedingungen, auf welche die Beauftragten zurückgreifen. Im Folgenden soll beschrieben werden, welche Aufgaben und Ausrichtungen die Beauftragten der Informationssicherheit, des Datenschutzes, des Business Continuitiy Managements und des Auslagerungsmanagements innehaben. Des Weiteren soll aufgezeigt werden, wie Banken Rahmenbedingungen schaffen können, um Synergien zu nutzen, langfristig Kosten zu sparen und damit ein effektives und effizientes Beauftragtenwesen zu etablieren.

II. Fachliche Abgrenzung der Beauftragten

1. Informationssicherheit

Ziel der Informationssicherheit ist die Sicherstellung der Vertraulichkeit, Integrität und Verfügbarkeit von ...


Weiterlesen?


Dies ist ein kostenpflichtiger Beitrag aus unseren Fachzeitschriften.

Um alle Beiträge lesen zu können, müssen Sie sich bei meinFCH anmelden oder registrieren und danach eines unserer Abonnements abschließen!

Anmeldung/Registrierung

Wenn Sie angemeldet oder registriert sind, können Sie unter dem Menüpunkt "meinABO" Ihr aktives Abonnement anschauen oder ein neues Abonnement abschließen.

Datenschutz-Grundverordnung vs. Telemediengesetz



Verhältnis der Datenschutzgrundverordnung (DSGVO) zum Telemediengesetz (TMG) und daraus abgeleitete Handlungsnotwendigkeiten.

Susanne Seitz, Datenschutzbeauftragte, TeamBank AG

Christian Maull, Referent Datenschutz, TeamBank AG.

I. Einleitung

Durch die DSGVO wurden viele bisherige Regelungen auf den Prüfstand gestellt, neu ausgelegt und teilweise sogar grundsätzlich überarbeitet. Das alte Bundesdatenschutzgesetz (BDSG-alt), welches als Auffanggesetz fungierte, behandelte ausschließlich Themen, die durch andere Gesetze nicht abgedeckt wurden. Parallel setzte das BDSG-alt Vorgaben europäischer Richtlinien in nationales Recht um. Die DSGVO geht dem gegenüber neue Wege. Als europäische Verordnung gilt sie unmittelbar in allen Mitgliedstaaten, erfordert daher keinen formellen Umsetzungsakt in nationales Recht. Um nationale Normen an die veränderten Vorgaben der DSGVO anzupassen, wurde im Dezember 2018 der Entwurf des 2. Datenschutz-Anpassungsgesetzes (2. DSAnpUG-EU) beschlossen. Dieser Entwurf sieht Änderungen in bis zu 154 Bundesgesetzen vor. Nicht betroffen davon ist bislang jedoch das TMG. Dieses enthält in Abschnitt 4 eigene Regelungen zum Datenschutz, die als Spezialnormen dem BDSG-alt vorgingen. Bislang ungeklärt war, wie das Verhältnis zwischen den Regelungen des TMG und der DSGVO zu bewerten ist.

II. Verlautbarung der Datenschutzkonferenz

Ende April 2019 äußerte sich die Datenschutzkonferenz (DSK), das Gremium der deutschen Datenschutzaufsichtsbehörden, in einem Rundschreiben zu dieser Rechtsfrage. ...


Weiterlesen?


Dies ist ein kostenpflichtiger Beitrag aus unseren Fachzeitschriften.

Um alle Beiträge lesen zu können, müssen Sie sich bei meinFCH anmelden oder registrieren und danach eines unserer Abonnements abschließen!

Anmeldung/Registrierung

Wenn Sie angemeldet oder registriert sind, können Sie unter dem Menüpunkt "meinABO" Ihr aktives Abonnement anschauen oder ein neues Abonnement abschließen.

Auftragsverarbeitung, Risiko im Datenschutz?



Ulrike Seip, Senior Referentin Datenschutz, DZ BANK AG Deutsche Zentral-Genossenschaftsbank

Definition von Auftragsverarbeitung

Maßgeblich für das Vorliegen einer Auftragsverarbeitung i. S. d. Art. 28 der Datenschutzgrundverordnung (DSGVO) ist, dass:

  • die Verarbeitung der personenbezogenen Daten den Mittelpunkt und Zweck des Auftragsverhältnisses darstellt
  • der Auftragnehmer an die Weisungen des Auftraggebers gebunden ist. Dies bedeutet, dass die Entscheidungsfreiheitsgrade für den Auftragnehmer bei der Art und Weise der Durchführung des Auftrags begrenzt sind.

Eine datenschutzrechtliche Auftragsverarbeitung liegt vor, wenn beide oben genannten Kriterien erfüllt werden. Die Weisungsgebundenheit spiegelt sich auch in Art. 29 DSGVO (Verarbeitung unter der Aufsicht des Verantwortlichen oder des Auftragsverarbeiters) wider. Die Dauer der Verarbeitung spielt dabei keine Rolle. Ebenfalls keine Rolle spielt, ob der Auftragnehmer ein Unternehmen des gleichen Konzerns ist. Wenn ein rechtlich selbstständiges Unternehmen innerhalb einer Unternehmensgruppe oder eines Konzerns bei der Verarbeitung personenbezogener Daten Auftragnehmer ist, kann auch von einer Auftragsverarbeitung ausgegangen werden.

Für jede Auftragsverarbeitung ist ein dem Art. 28 DSGVO entsprechender Vertrag zu schließen, Verantwortlichkeiten sind klar zu regeln und dem Risikogehalt der Datenverarbeitung angemessene Datenschutzmaßnahmen müssen bestehen.

Typisches Beispiel für die Beauftragung der Verarbeitung von personenbezogenen Daten ist die Einschaltung eines Dienstleisters, welcher ...


Weiterlesen?


Dies ist ein kostenpflichtiger Beitrag aus unseren Fachzeitschriften.

Um alle Beiträge lesen zu können, müssen Sie sich bei meinFCH anmelden oder registrieren und danach eines unserer Abonnements abschließen!

Anmeldung/Registrierung

Wenn Sie angemeldet oder registriert sind, können Sie unter dem Menüpunkt "meinABO" Ihr aktives Abonnement anschauen oder ein neues Abonnement abschließen.

Individuelle Datenverarbeitung mit Excel – Best Practice



Test- und Freigabeverfahren standardisieren und erfolgreich einsetzen[1]

Annika Rüder, M. Sc., Spezialistin Risikocontrolling, comdirect bank AG

Noel Boka, M. Sc., Abteilungsleiter Controlling, VR Bank Niederbayern-Oberpfalz eG[2]

I. Einleitende Worte

Erscheinen die Anforderungen der MaRisk und der BAIT zum Management von IDV-Dateien in der Institutspraxis angekommen zu sein, so stellt sich unmittelbar hierauf aufbauend die Frage der Standardisierung und der Übertragbarkeit eines Best-Practice-Ansatzes. Sei die formale Integration in den Risikomanagement-Kreislauf als abgeschlossen zu beurteilen[3], stellt sich gleichwohl die Frage, ob auch für die Test- und Freigabeverfahren Standards und Qualitätsvorgaben bestehen. Der nachfolgende Beitrag greift diesen Gedanken auf und stellt verschiedene Wege zu Test- und Freigabeverfahren vor. Es soll als Ziel formuliert werden, eine Best Practice-Standardisierung aufzuzeigen und hiermit den Grundstein einer effizienten, betriebswirtschaftlich sinnvollen und ressourcenschonenden Vorgehensweise beizutragen.

II. Regulatorisches

Insbesondere durch die neuste MaRisk- und BAIT-Novelle hat die Bank bei der Anwendungsentwicklung Rahmenbedingungen zu schaffen, die betreffend

  • der Auswahl und Beschaffung,
  • der Entwicklung und Pflege,
  • der Test- und Freigabeverfahren, sowie
  • der Verfahrensdokumentation und Archivierung

geeignete Regelungen enthalten[4]. Dies umschließt auch Mustervorgehen und harmonisierte Antrags- und Zulassungsverfahren. Weitergehend kann eine Unterscheidung ...


Weiterlesen?


Dies ist ein kostenpflichtiger Beitrag aus unseren Fachzeitschriften.

Um alle Beiträge lesen zu können, müssen Sie sich bei meinFCH anmelden oder registrieren und danach eines unserer Abonnements abschließen!

Anmeldung/Registrierung

Wenn Sie angemeldet oder registriert sind, können Sie unter dem Menüpunkt "meinABO" Ihr aktives Abonnement anschauen oder ein neues Abonnement abschließen.

Security Awareness

Zentrale Grundlage für die Umsetzung der Risikokultur-Anforderungen nach den neuen MaRisk

Andreas Hessel, Informationssicherheitsbeauftragter und Referent, SaarLB

Ohne die Unterstützung der Mitarbeiter kann sich heutzutage kein Unternehmen wirksam vor Cyberangriffen schützen. Als IT-Revisor kennen Sie die täglichen Meldungen über großflächige Angriffe auf Unternehmen. Immer neue Trojaner oder Ransomware kommt zum Einsatz, ganze Netzwerke kommen zum Erliegen, weil Kriminelle die Server mit millionenfachen Anfragen zum Stillstand bringen. Millionen Nutzerdaten werden bei Facebook gestohlen.

SEMINARTIPP

Hackerangriffe & Cyber-Attacken: Reaktion und Prävention, 25.09.2019, Frankfurt/M.

 

Mangelnde Sensibilität führt dazu, dass ein Mitarbeiter eine Phishing-Mail öffnet oder Opfer eines Social Engineering-Angriffs wird. So öffnet der Mitarbeiter den Hackern die Tür in das Unternehmen.

Das sagt die BaFin

Die BaFin bezeichnet Risiken in der Informationssicherheit als wesentliche operationelle Risiken. Die § 44iger-IT-Prüfungen in den letzten Jahren haben gezeigt, dass die Informationssicherheit bei vielen Instituten eher nachrangig behandelt wurde. Die BaFin hat in der Informationsveranstaltung IT-Aufsicht bei Banken in 2018 erneut auf diese Risiken hingewiesen.

Quelle BaFin (Auszug aus einem Vortrtag der BaFin)

Security Awareness. Das müssen Sie jetzt wissen

Als IT-Revisor ist es Ihre Aufgabe die Ordnungsmäßigkeit des Geschäftsbetriebes risikoorientiert zu prüfen. Aktuelle Studien zeigen, dass Cyberangriffe in der Regel nur mit aktiver Unterstützung der Mitarbeiter erfolgreich sind. Wobei das bloße Anklicken eines Links in einer Mail bereits eine aktive Unterstützung darstellt.

Informationssicherheitsrisiken sind heutzutage ohne Sensibilisierung und Schulung der Mitarbeiter nicht zu reduzieren. Schulungen sind jedoch nur ein Baustein von vielen. Eine Security Awareness-Kampagne schafft Aufmerksamkeit für IT-Security und ist das Fundament, auf dem mit weiteren Bausteinen eine Sicherheitskultur in Ihrem Unternehmen aufgebaut werden kann. Ohne eine solche Sicherheitskultur können wesentliche Risiken nicht minimiert werden und bleiben technische Sicherheitsmaßnahmen unwirksam.

BUCHTIPPS

Janßen/Schiwietz (Hrsg.), Risikokultur in Kreditinstituten, 2018.

Weimer (Hrsg.), Bearbeitungs- und Prüfungsleitfaden: Datenschutz, IT-Sicherheit & Cyberrisiken, 4. Aufl. 2017.

Security Awareness wird seit vielen Jahren als Allheilmittel zur Verbesserung der Informationssicherheit propagiert. Unternehmen sollten sich jedoch, zunächst darüber im Klaren sein, welche Ziele sie verfolgen und mit welchen Methoden sie diese Ziele erreichen können. Awareness-Kampagnen sind meist sehr zeitintensiv und in der Regel nicht ohne die Unterstützung externer Berater umzusetzen. Das kann sehr schnell sehr teuer werden.

FILMTIPPS

Umsetzung und Überprüfung einer angemessenen Risikokultur

Risikokultur & Unternehmensethik

 

Erfolgreiche Awareness-Kampagnen haben gezeigt, dass sensibilisierte und motivierte Mitarbeiter nicht nur Informationen benötigen. Sicherheitsbewusstsein erfordert auch die Vermittlung von Lösungen. Mitarbeiter wollen klare Regelungen und klare Vorgaben für bestimmte sicherheitskritische Verfahren. So reicht es nicht aus, Mitarbeitern die Gefahren von Phishing-Angriffen aufzuzeigen. Mitarbeiter wollen wissen, wie Sie sich konkret verhalten müssen, wenn eine solche E-Mail in ihrem Postfach liegt. Es müssen also Richtlinien mit konkreten Vorgaben erstellt werden, die im gesamten Unternehmen verbindlich sind. Mitarbeiter fordern nämlich insbesondere, dass sich auch Führungskräfte an solche Richtlinien halten. Als Datenschutzbeauftragter wissen Sie, dass gerade Geschäftsleiter gerne Sicherheitsrichtlinien in Frage stellen oder gar umgehen.

Security Awareness. Das ist konkret zu tun

Eine Awareness-Kampagne kann nur erfolgreich sein, wenn die Ziele konkret definiert sind. Andernfalls wird bei den Mitarbeitern das Gefühl von Beliebigkeit erzeugt, aber die Mitarbeiter werden nicht begeistert sein. Ohne konkrete Ziele ist der Erfolg einer Awareness-Kampagne auch nicht messbar. Konkret können die Mitarbeiter für die folgenden Themen sensibilisiert werden:

  • Social Engineering
  • Trojaner und Ransomware
  • E-Mailsicherheit

Als IT-Revisor sollten Sie den Erfolg der Awareness-Kampagne messen und nachhaltige Maßnahmen zur Etablierung einer Sicherheitskultur vorschlagen.

Sie sollten wissen, welche Faktoren die Wirksamkeit einer Awareness Kampagne beeinflussen. Denn nur so können Sie einschätzen, ob die ergriffenen Maßnahmen sachgerecht sind. Zudem müssen Sie wissen, wie der Erfolg einer Kampagne objektiv gemessen werden kann. Denn prüfen können Sie nur das, was Sie „messen und wiegen“ können.

Praxistipps

  • Der Mitarbeiter ist der größte Risikofaktor für die Informationssicherheit.
  • Sicherheitsrisiken können ohne wirksame Awareness-Maßnahmen nicht reduziert werden.
  • Die Wirksamkeit von Awareness-Maßnahmen muss auf der Basis nachvollziehbarer Messungen überprüft werden.

 

Beitragsnummer: 60982

Quo vadis, Datenschutz?



Rückblick auf die Einführung der DSGVO und aktuelle Entwicklungen im Datenschutz.

Christian Maull, Spezialist Compliance, FCH Compliance GmbH.

     

Seit dem 25.05.2018 ist die Datenschutz-Grundverordnung nun in Kraft und die ersten Wogen sind so langsam geglättet. Doch der Schein trügt, denn laut einer Studie der Bitkom konnten Ende September erst 24 % der Unternehmen die Anforderungen der DSGVO, eigenen Angaben zufolge, erfolgreich umgesetzten.

Der mangelnde Fortschritt basiere dabei hauptsächlich auf einer explosiven Mischung aus Rechtsunsicherheit der verantwortlichen Stellen und mangelnden Umsetzungshilfen. Unternehmen beklagen ebenso den Mangel an ausreichend qualifizierten Mitarbeitern und die Schwierigkeit der technischen Umsetzung.

I. Sensibilität hat zugenommen

Trotz aller Kritik über die DS-GVO gibt es positive Erkenntnisse zu vermelden. Der Datenschutz führte bislang ein Schattendasein in der allgemeinen Wahrnehmung, denn Kontrollen der Aufsichtsbehörden waren selten und Bußgelder fielen bei Verstößen noch seltener und v. a. gering aus. Um diesem Missstand entgegenzuwirken, trug die Einführung der DS-GVO zurecht zu einer erhöhten Sensibilität bei, teilweise mit fragwürdigen Folgen.

Unternehmen arbeiteten nun mit Hochdruck daran Dokumentations- und Informationspflichten zu erfüllen und ...


Weiterlesen?


Dies ist ein kostenpflichtiger Beitrag aus unseren Fachzeitschriften.

Um alle Beiträge lesen zu können, müssen Sie sich bei meinFCH anmelden oder registrieren und danach eines unserer Abonnements abschließen!

Anmeldung/Registrierung

Wenn Sie angemeldet oder registriert sind, können Sie unter dem Menüpunkt "meinABO" Ihr aktives Abonnement anschauen oder ein neues Abonnement abschließen.

Grundlagen für SIEM- und SOAR-Einführung: Praxisbericht SIEM und SOAR: BAITmen für den Bankbetrieb

Compliance möglichst einfach handhaben: Systeme für Security Incidence und Event Management sind gut geeignet, um sämtliche IT-Prozesse im Unternehmen abzusichern. Dank angepasster Regelwerke funktionieren diese auch in der Weise, Compliance-Vorgaben überwachen und dokumentieren zu können.

Swer Rieger, Senior Consultant Security und Produkte, Consist Software Solutions GmbH

 

 

 

 

Auf Bankbetriebe prasseln jede Menge gesetzliche Regelwerke ein, was die IT-Sicherheit betrifft. In Standards und Normen sind deren genaue Anforderungen definiert. Die resultierenden Compliance-Vorgaben setzen sich zusammen aus:

  • Mindestanforderungen an das Risikomanagement (MaRisk)
  • BAIT (Bankaufsichtliche Anforderungen an die IT herausgegeben von BaFin)
  • KAMaRISK (Mindestanforderungen an das Risikomanagement von Kapitalgesellschaften)
  • Datenschutzgesetze (DSGVO, TMG, TKG)
  • ISO/IEC-Standards der 2700x-Reihe,
  • BSI IT-Grundschutz,
  • ISF Standard of Good Practice for Information Security 2018,
  • Common Attack Pattern Enumeration and Classification (CAPEC),
  • NIST SP800 R.x,
  • SANS Whitepaper

Systeme für Security Information and Event Management (SIEM) und SOAR (Security Orchestration, Automation and Response) sind neben ihrer eigentlichen Aufgabe, die IT Security zu gewährleisten, auch in der Weise nutzbar, die Einhaltung gesetzlicher und interner Regelungen zu dokumentieren, beziehungsweise bei deren Nichteinhaltung die ergriffenen Maßnahmen.

Denn es reicht heutzutage nicht mehr, IT-Security nur noch an technischen Komponenten festzumachen, wie Firewalls, Intrusion Detection, Schwachstellen-Scanner, Virenscanner, Anti-Viren-Software oder Web-Filter. In Sicherheitskonzepte müssen immer auch Prozesse und Mitarbeiter einbezogen werden, damit sie funktionieren. Mit einem SIEM lässt sich eine hohe Transparenz über die Aktivitäten auf den genutzten Systemen herstellen. Man erkennt auf einen Blick, wo sicherheitskritische Aktivitäten ablaufen, kann diese nachverfolgen, die Bearbeitung dokumentieren und über die aktuelle Lage berichten. Ein SOAR ermöglicht die automatisierte Abarbeitung von Verdachtsfällen: bei heutigen komplexen Systemumgebungen eine große Hilfe.

I. SIEM und SOAR im Einsatz

Das SIEM wird mit Log-Daten (Events) von Servern, Datenbanken, Netzwerkkomponenten, des Active Directory und Anwendungen gefüttert, zusätzlich können aus externen Quellen Listen (Indicators of Compromise), mit potenziellen und bekannten bösen IPs, URLs und anderen Mustern (Pattern) genutzt werden, um über geeignete Auswertungen (Regeln) verdächtige Sachverhalte und Angriffe (Incidents) zu erkennen.

Sicherheitsvorfälle werden vom SIEM an die SOAR-Plattform weitergeleitet und dort geclustert (Automation). So kann der Case Load erheblich reduziert werden. Mit der Weiterleitung an die eingebundenen Security Tools wird der Response-Prozess gestartet (Orchestration and Response).

1. Wie werden aus Events Incidents?

In der Praxis hat sich gezeigt, dass es umfangreiche Regelsammlungen zur Eventauswertung gibt, die als Muster gut geeignet sind, aber die spezifischen Regeln für eine Firma doch ein erhebliches Feintuning (Projekt) erfordern, um die relevanten Incidents zu generieren, die auch wirklich einer Nachbearbeitung bedürfen. Bei deren Nachbearbeitung kann durch Automatisierung mit einem SOAR, wie beschrieben, viel Effizienz gehoben werden.

Über ein Vorgehensmodell zur bedrohungsbezogenen Systemauswahl,

werden die Anforderungen auf Protokollebene identifiziert und daraus Überwachungsfälle (Controls) entwickelt. Die Überwachung erfolgt dann mit automatisierten Analysen (Regeln) der Logdaten im SIEM und generiert Incidents. Dank des automatisierten Regelfilters werden aus sehr vielen Events wenige wirklich relevante Incidents.

Die Analyse, ob ein Incident Maßnahmen erfordert, um die Sicherheit zu erhalten oder wieder herzustellen erfolgt i. d. R. manuell durch Spezialisten (Security-Analysten). Bei größeren Organisationen sind diese Spezialisten in einem Security Operation Center (SOC) organisiert. Definierte Prozesse zur Incident-Bearbeitung mit Einbindung der weiteren Firmenorganisation sind ein weiterer Bestandteil eines SOC.

2. SOAR ergänzt SIEM

Die Incidents aus einem SIEM müssen bearbeitet werden. Incident-Management-Systeme sind dazu grundsätzlich geeignet und die meisten SIEMs können auch Incidents in solche Systeme überführen, worin dann die weitere Bearbeitung manuell erfolgen müsste. Am Markt gibt es einige gute SIEM-Systeme. Consist setzt beispielsweise Splunk ein, das der aktuelle Gartner-Report als führendes SIEM-System ausweist (https://www.splunk.com/en_us/form/gartner-siem-magic-quadrant.html). In jedem Fall ist es wichtig, das SIEM genau an die individuellen Unternehmensgegebenheiten anzupassen. Ziel ist es in diesem Zusammenhang, die Anzahl der zu pflegenden Regeln möglichst klein zu halten, aber dennoch den Anforderungen zu genügen.

In der Praxis schnappt sich heute ein Security-Analyst den Incident und analysiert weiter. Je nach Incident wird geklärt, ob einzelne Systeme betroffen sind, spezielle User involviert sind, aktuelle Bedrohungen eine Rolle spielen oder Ähnliches. Die Events im SIEM werden unter verschieden Blickwinkeln analysiert. Da der Rückgriff auf das SIEM oder andere Sicherheitssysteme notwendig ist, wäre es eine erhebliche Arbeitserleichterung, wenn dies gleich aus dem Incident Management heraus erfolgen könnte, zumal dann auch leicht die Dokumentation der Analyse automatisch erfolgen kann.

Hier setzt ein SOAR ein, es ist verknüpft mit Sicherheitssystemen, primär einem SIEM, es können aber auch andere Systeme, wie ein IDS oder Schwachstellenscanner direkt sein. Das SOAR nimmt deren Incidents auf und arbeitet diese in vordefinierten Prozessen (Playbooks) ab. Es reichert diese mit Informationen an, kann aber auch Incidents final bearbeiten, wenn Playbooks dies vorsehen. Die Praxis in Security-Teams hat gezeigt, dass eine große Zahl der Incidents schnell mit Standardüberprüfungen (Analysen) abgearbeitet werden können und so nur noch die Dokumentation für spätere Auswertungen wichtig ist. Bei anderen Incidents fallen immer gleiche Analysen an, die schon automatisiert ablaufen können und dann dem Security-Analysten helfen, Incidents schneller zu bearbeiten. Mit der Fähigkeit eines SOAR, auch aktiv mit Infrastrukturen interagieren zu können (Orchestration), können Maßnahmen aus dem SOAR direkt ausgeführt werden. Die Sperrung einer IP, eines Ports, Initialisierung ergänzender Schwachstellenscans oder das Herunterfahren von Systemen kann direkt aus dem SOAR erfolgen.

 

SEMINARTIPPS

7. Fachtagung Informationssicherheit, 20.-21.03.2019, Berlin.

(Un-)Abgestimmte Informationssicherheits- und Datenschutz-Tätigkeiten, 21.03.2019, Frankfurt/M.

FCH Innovation Days 2019, 24.-25.06.2019, Berlin.

 

II. Compliance und die IT-technischen Hürden

Geschäftsprozesse laufen heute in Anwendungssystemen ab und es ist eine Herausforderung, nachzuweisen, dass diese Systeme sicher und regelkonform genutzt werden. Anwendungssysteme verfügen über rollenbasierte Rechtesysteme, die Funktionalitäten für User frei schalten oder sperren. Im laufenden Betrieb sind privilegierte User notwendig. Administratoren für Datenbanken und Basissysteme seien hier genannt. Deren Tätigkeiten erfordern privilegierte Berechtigungen, die jedoch nicht bei der Ausführung der normalen Geschäftsprozesse genutzt werden dürfen. Gleichzeitig sind privilegierte User immer auch Einfallstore für die Kompromittierung von Systemen und Daten. Es ist also unbedingt notwendig, privilegierte User, auch in ihrem eigenen Interesse zu überwachen und permanent zu prüfen, ob deren Privilegien missbräuchlich genutzt werden. Die Heraufstufung von Usern zu privilegierten Usern ist eines der Überwachungsziele.

Füttert man die Logs (Ereignisprotokoll eines Programms) von Anwendungssystemen, speziell Audit- und Securitylogs, können in vielen Systemen die Aktivitäten privilegierter User überwacht werden. In der Praxis hat sich jedoch gezeigt, dass Logs oft nicht ausreichen – weitere Datenquellen müssen genutzt werden. Beispielsweise reicht auch bei SAP die Analyse der Audit- und Security-Logs nicht aus, hier muss auf weitere Informationen zurückgegriffen werden.

Die Entwicklung der Überwachungsfälle (Controls) muss für jedes Anwendungssystem erfolgen, damit Regeln definiert werden können. Ein Überwachungsfall entsteht auch, wenn ein privilegierter User die Berechtigung für einen Mitarbeiter erweitert, so dass dieser Transaktionen mit höheren Werten ausführen kann.

Die Entwicklung von Controls und deren Überwachung in Logs kann sehr aufwändig sein, insbesondere, wenn die Anwendung ungeeignet ist oder gar nicht protokolliert.

Eine Alternative sind Protokolle aus User-Sicht, die mittels Session-Überwachung (früher Session-Recording) gewonnen werden. Consist setzt hier ObserveIT (www.consist.de/observeit) ein, ein Werkzeug zur Aufzeichnung von Sessions, das sehr granular gesteuert werden kann, so dass die Aktivität des Users nur bei Nutzung kritischer Anwendungsteile mit privilegierten Rechten aufgezeichnet wird. Die Aufzeichnung kann ein Video sein, das aber schlecht auswertbar ist, oder ein Transskript (Log) der Useraktivitäten.

III. Compliance mit SIEM und SOAR

SIEM und SOAR generieren automatisch die Dokumentation der aktuellen Sicherheitslage – genauer: Protokolle zu Sicherheitsvorfällen, die sich aus der Überwachung relevanter Controls ergeben. Die eingeleiteten Maßnahmen sind in den Protokollen enthalten, sofern diese systemgestützt erfolgen. Bei manuellen Eingriffen müssten diese bei der Incident-Bearbeitung händisch im System ergänzt werden.

Die Compliance-Überwachung erfolgt primär über eine Dokumentation, die das Monitoring der privilegierten User enthält. Bei definierten kritischen Systemzugriffen, beispielsweise: SAP-Notfall-User führt Buchungen aus, technischer User meldet sich im Dialog an oder Datenbankadministrator ändert Tabelleninhalte eines Anwendungssystems, sollen Alarme ausgelöst werden.

Die Bearbeitung der generierten Incidents lässt sich in einem SOAR so steuern, dass alles dokumentiert wird und damit auch auswertbar ist. Die reine Dokumentation kann automatisiert erfolgen. Kritische Incidents (Alarme) bedürfen weiterer Analysen und Maßnahmen, die ebenfalls dokumentiert werden. So bieten Analysen, ob bestimmte Überwachungen in bestimmten Systemen mit zunehmender Häufigkeit anschlagen, wesentliche Hinweise, hier genauer hinzusehen.

 

BUCHTIPPS

Held/Kühn (Hrsg.): Praktikerhandbuch IT- und Informationssicherheitsbeauftragter, 2018.

Weimer (Hrsg.): Bearbeitungs- und Prüfungsleitfaden: Datenschutz, IT-Sicherheit & Cyberrisiken, 4. Aufl. 2017.

 

 

IV. Aus einem konkreten Projekt bei einer Bank


1. Die Aufgabe

Privilegierte User und Admins sollen beim Zugriff auf Anwendungssysteme und deren Komponenten überwacht werden. Ein zentrales unabhängiges Sicherheitsinformationsmanagement sollte hierfür in Betrieb gehen.

2. Die Herausforderung

Mehr als 40 heterogene bankfachliche Anwendungssysteme mit sehr hohem Schutzbedarf, einschließlich eines SAP-Systems mussten datentechnisch (Logs und Protokolle aus Systemdatenbanken und Anreicherungen aus den Anwendungssystemen) an ein SIEM (Splunk) angebunden werden.

3. Die Lösung

Anhand aktueller Standards und Normen (siehe oben) wurden die Überwachungsanforderungen definiert, die Systeme in Risikogruppen eingestuft und bei den „hoch“ eingestuften Anwendungssystemen der Transfer in Überwachungsregeln (Auswertungen auf den Logs mit Ergänzungen) definiert.

Der Start erfolgte mit einem Proof of Concept, in dem das Monitoring des SAP-Systems getestet wurde. Im Projektteam hatte die Bank dann die Projektleitung inne und steuerte das Know-how zu Fachanwendungen über ihre Fachanwendungsbetreuer bei. Consist übernahm mit seinen Splunk- und Security-Consultants die Konzeption und Umsetzung mit Splunk.

Das SIEM ist für das in der Bank übliche Staging (Entwicklungs-, Test- und Produktivstage) ausgelegt, wobei der Transfer von Apps, Dashboards, Konfigurationen und Suchen (Regeln) von einer zur nächsten Stage des SIEM weitgehend automatisiert erfolgt.

Alerts und Dokumentation sind wesentliche Bestandteile des Systems. Das Projektteam übergab das System nahtlos in die Betreuung der Managed Services von Consist. Der laufende Betrieb mit allen notwendigen Anpassungen des SIEM an alle Datenanbindungen und Regeln wird dort ausgeführt.

Die Bank arbeitet mit den Auswertungen aus dem System und prüft bei Alarmen, ob Maßnahmen ergriffen werden müssen. Da das System die bankfachlichen Anwendungen umfasst und nicht die Basissysteme, ist die Alarm/Incidentbearbeitung durch die Fachanwendungsbetreuer und die Verantwortlichen der Fachabteilungen möglich. Eine übergreifende Kontrolle erfolgt durch die Security-Abteilung der Bank.

4. Kundennutzen

Die Einbindung privilegierter User ins kontinuierliche Monitoring senkt Risiken und vermindert die Bedrohungsfläche, weil Kompromittierungen schneller entdeckt werden können. Die Aufdeckung von Insider Threats wird erleichtert.

Durch systemübergreifende Normierungen der Datenhaltung des SIEM (bei Splunk als Common Information Model (CIM) bekannt), ergänzend zu den Rohdaten, ist das System auch künftig gut erweiterbar und robust gegen Änderungen in den Anwendungssystemen.

Das System speichert alle Daten revisionssicher im Rohformat. Die Incidentbearbeitung dokumentiert das System automatisiert und bietet Auditfunktionalitäten für die Incidentbearbeitung und den Betrieb des Systems.

BSI-, EZB- und BaFin-Sicherheitsanforderungen werden so erfüllt[1].

PRAXISTIPPS

  • Security-Know-how und -Erfahrung sind die Basis für SIEM- und SOAR-Projekte.
  • SIEM und SOAR sind ein starkes Gespann.
  • Ziel muss es sein, die Zahl der Regeln im SIEM zu minimieren.
  • SOAR ist der Schlüssel zur Effizienzverbesserung in Security-Teams.
  • Anwendungssysteme liefern häufig ungeeignete Logs, Abhilfe kann selektives Sessionrecording sein.

Weitere Informationen:

Über Consist: www.consist.de

Presse-Service: www.consist.de/presse

 

 

 

Beitragsnummer: 55353

Cloud Computing nach den BAIT

Aufsichtsrechtliche Anforderungen und Prüfungserfahrungen

 

Maria Lodhi, Senior IT-Revisorin, Interne Revision, KfW Bankengruppe

Cloud Computing beschreibt einen internetbasierten Entwicklungsansatz, bei dem ein Anbieter komplexe Leistungen aus Soft- und Hardware in Form eines abstrakten Dienstes bereitstellt. Cloud ist die Basis für digitalisierte Geschäftsmodelle und -prozesse, wie sie Unternehmen in Zukunft prägen werden. Durch das Cloud Computing ist zwar nach wie vor die Kostensenkung eines der wichtigen Ziele der Unternehmen, jedoch treten wesentliche Aspekte wie Sicherheit der Applikation und Daten sowie Fragen nach dem Prozess-Know-how immer stärker in den Vordergrund. Zudem müssen die Anforderungen der MaRisk und BAIT nach wie vor erfüllt werden. Die BAIT verlangt eine Risikobewertung und eine Analyse der Wesentlichkeit der Auslagerung. Ferner sind klare Verantwortlichkeiten für die Steuerung und Überwachung der ausgelagerten Tätigkeiten vertraglich festzustellen.

Auslagerung in die Cloud – Wie identifiziere ich meine Risiken?

Die Einstufung der Wesentlichkeit einer Auslagerung in die Cloud ist auf Grundlage der Risikoanalyse durchzuführen. Die Intensität der Analyse ist von Art, Umfang, Komplexität und Risikogehalt der ausgelagerten Aktivitäten und Prozesse abhängig. Auch bei jedem Bezug von Software sind die damit verbundenen Risiken angemessen zu bewerten (vgl. AT 7.2 Tz. 4 Satz 2 MaRisk). Wegen der grundlegenden Bedeutung der IT für das Institut ist auch für jeden sonstigen Fremdbezug von IT-Dienstleistungen vorab eine Risikobewertung durchzuführen (vgl. Ziffer 8. Tz. 53 BAIT).

SEMINARTIPPS

Digitalisierung im Konten-/Zahlungsverkehr: Praxis & Prüfung, 08.04.2019, Frankfurt/M.

Konto & ZV Spezial: Digitale Authentifizierung, 09.04.2019, Frankfurt/M.

Blockchain: Formen & Einsatzmöglichkeiten, 10.04.2019, Frankfurt/M.

Digitales Kreditgeschäft, 11.04.2019, Köln.

Neue aufsichtliche Vorgaben für Cloud-Nutzungen, 11.04.2019, Frankfurt/M.

 

Für die Erhebung von internen und externen Anforderungen sollten die folgenden Fragestellungen vorab geklärt werden:

  • Welche fachlichen, funktionalen und nicht-funktionalen Anforderungen gibt es?
  • Welche internen Anforderungen habe ich an Informationssicherheit, Datenschutz, Weiterentwicklung und Betrieb von Anwendungen und Identity- und Access-Management (Berechtigungen)?
  • Welche Anforderungen aus der Unternehmens- und IT-Strategie bzgl. Risikoneigung, Innovationsfreudigkeit, Programmiersprachen und Datenhaltung muss ich berücksichtigen?
  • Was muss ich bzgl. Providersteuerung schriftlich festlegen und beachten? (Service Level Agreements, Prüfrechte, Reporting)

Risiken lassen sich nicht auslagern – Wie kann ich den Dienstleister steuern?
Risiken wesentlicher Auslagerungen sind angemessen zu steuern und die Ausführung der ausgelagerten Aktivitäten und Prozesse ordnungsgemäß zu überwachen.

Dies umfasst auch die regelmäßige Beurteilung der Leistung des Auslagerungsunternehmens anhand vorzuhaltender Kriterien. Für die Steuerung und Überwachung wesentlicher Auslagerungen hat das Institut klare Verantwortlichkeiten festzulegen.

Prüfrechte beim Dienstleister (ISAE 3402 Typ B Bescheinigung/IDW PS 951 Typ 2)

Ein Service Level Agreement (SLA) enthält in der Regel die folgenden Informationen:

  • Beschreibung der Cloud Computing-Leistungen
  • Angaben zum Ort der Leistungserbringung und Rechtsrahmen
  • Angaben zu den angewendeten Standards und Normen
  • Beschreibung der Verantwortung des Dienstleisters und des Kunden
  • Angaben zur Verfügbarkeit (Zeiten) der Leistung und zur max. Ausfallzeit
  • Angaben zum Eskalationsprozess und zum Notfallprozess mit Ansprechpartnern
  • Definition von IKS-Maßnahmen und KPIs sowie deren Messung
  • Angaben zur Wartung und Weiterentwicklung
  • Angaben zur Preisgestaltung und Abrechnung
  • Reaktionszeiten und Wiederanlaufzeiten
  • Angaben zu regelmäßigen Audits/Zertifizierungen

PRAXISTIPPS

  • Erstellen Sie je Cloud-Computing-Anwendung eine Analyse der spezifischen Risiken und Anforderung.
  • Etablieren Sie eine Cloud Computing Strategie und stellen Sie sicher, dass diese mit der Unternehmens- und IT-Strategie im Einklang steht.
  • Erstellen Sie übergeordnete Richtlinien und Überwachungsprozesse und legen Sie Ihr Risikoprofil fest.
  • Erstellen Sie Regelungen und Prozesse zur Einführung, zum Betrieb und zur Beendigung von Cloud Computing.
  • Identifizieren Sie Risiken und implementieren Sie angemessene und wirksame Kontrollen, um die Risiken auf das gewünschte Niveau zu mitigieren.

FCH Consult Logo

 

Beitragsnummer: 47492

Anforderungen an die IDV je nach Schutzbedarfsklasse

Welche Standards, wie z. B. ISO 2700x und BSI-Standard, können den praktischen Anforderungen gerecht werden?

Frank Lutter, Abteilungsleiter IT-Management, Volksbank Bigge-Lenne eG

Beide Standards kommen grundsätzlich den aufsichtsrechtlichen Anforderungen nach.

ISO 2700x
Die ersten drei Teile vermitteln einen allgemeinen Überblick über die Vorgehensweise. Die weiteren Punkte der ISO 2700x beschäftigen sich mit verschiedenen Einzelthemen. Die Richtlinie zur Anwendungssicherheit befindet sich in der ISO 27034. Sie beschreibt das Ziel, dass die IDV dem Sicherheitsniveau der Bank entspricht. Ein weiteres Ziel ist die Wiederverwendbarkeit.

BSI-Standards
Auch hier wird zunächst ein Überblick über die Vorgehensweise gegeben. Das IT-Grundschutz-Kompendium des BSI ist im Internet frei verfügbar. Es enthält thematisierte Bausteine und Umsetzungshinweise. Im Bereich der IDV sind die Bausteine „APP.1.1 Office Produkte“ und „CON.5 Entwicklung und Einsatz von allgemeinen Anwendungen“ maßgebend.

Ziel des Bausteins CON.5 ist es, aufzuzeigen, welche grundlegenden Sicherheitsanforderungen bei Planung, Beschaffung, Inbetriebnahme, regulärem Betrieb und Außerbetriebnahme einer Fachanwendung zu berücksichtigen sind.

Die ISO 2700x, als auch das BSI-Grundschutzkompendium, sind keine „Blaupause“ zu den gesetzlichen Anforderungen der MaRisk/BAIT – sie geben jedoch Orientierung.

1. Interne Dokumentation der Schutzbedürftigkeit von Daten und Objekten

Der Schutzbedarf der IDV entspricht dem Schutzbedarf des zugeordneten Geschäftsprozesses (GP). Der Schutzbedarf des Prozesses (CIN) wird dabei aus der höchsten Datenklasse übernommen.

Die Dokumentation der Datenklassen sollte neben der Bezeichnung folgende Merkmale berücksichtigen:

  • Eigenschaften der Daten (personenbezogen, rechnungslegungsrelevant, steuerungsrelevant)
  • Schutzbedarf (Vertraulichkeit C, Datenintegrität I und Verbindlichkeit N)

Eine Abstufung der Datenklassen könnte in vier Kategorien erfolgen:

  • Öffentliche Daten (Web-Auftritt/Social Media/sonstige öffentliche Daten)
  • Interne Daten (interne Informationen)
  • Vertrauliche Daten (Personendaten, Bezug zum Bankgeschäft, rechnungslegungsrelevant, Banksteuerungsparameter, Systemdaten, Kartenbezogene Informationen)
  • Streng vertrauliche Daten (Personaldaten, kryptographische Informationen, MaSI)

Um ein mögliches GAP zu analysieren, muss das Schutzniveau der IDV zunächst ermittelt werden. Die Schutzziele Verfügbarkeit (A), Vertraulichkeit (C), Integrität (I) und Authentizität (N) der Schutzobjekte können in die 4 Stufen „niedrig“, „mittel“, „hoch“ und „sehr hoch“ eingeordnet werden.

Die Erläuterungen für die Einstufung (niedrig, mittel, hoch, sehr hoch) müssen dokumentiert werden. Die Verfügbarkeit (A) wird z. B. prozentual bezogen auf einen Zeitraum x angegeben. Bei der Authentizität wird beispielsweise eine Abstufung von „keine Verbindlichkeit“ bis hin zum „4-Augen-Prinzip“ hinterlegt.

Ist das so ermittelte Schutzniveau der IDV niedriger als der Schutzbedarf aus dem zugeordneten Prozess, liegt ein GAP vor. Daraufhin erfolgt eine Risikoanalyse der Sicherheitslücke.

 

 SEMINARTIPPS

Identifizierung & Prüfung von IDV, 26.03.2019, Köln.

InformationsRisikoManagement: Zusammenspiel ISB, Compliance & Revision, 27.03.2019, Köln.

Brennpunkt Schutzbedarfsanalyse, 18.03.2019, Berlin.

Pflichten des ISB: Prüfungs- und Praxiserfahrungen, 07.05.2019, Frankfurt/Offenbach.

BAIT – Prüfungs- und Praxisfragen am 06.05.2019, Frankfurt/Offenbach.

IT-Risikomanagement aktuell, 08.05.2019 in Frankfurt/Offenbach.

 

Die Dokumentation kann durchaus in einer Tabelle erfolgen, die nachfolgende Felder enthalten sollte: Dateiname, Speicherort, Beschreibung, Abteilung, Version, Datum, Fremd-/Eigenentwicklung, verantwortliche Mitarbeiter, Trägersystem, zugeordneter Geschäftsprozess inkl. Schutzbedarf und Schutzniveau der IDV.

2. Inwieweit sind proportionale Erleichterungen/Spielräume möglich?

Die gängigen Standards (BSI, ISO) sehen durchaus Spielräume je nach Schutzniveau vor (z. B. CON.5.A4 oder CON.5.A8), die jedoch durch die Vorgaben der BAIT oftmals aufgehoben werden.

Eigenentwicklungen unterliegen normalerweise einem Entwicklungsprozess. Mit steigendem Entwicklungsgrad muss auch das Schutzniveau überprüft und ggf. angepasst werden.

PRAXISTIPPS

  • Identifizieren Sie vorhandene Eigenprogrammierungen im File-System und bilden aus der Gesamtmenge eine händelbare Stichprobe von z. B. 10 %.
    Beispiel einer Abfrage nach Excel-Tabellen auf dem Laufwerk O:
    for /f “delims=” %i in (‘dir o:*.xl* /s /b’) do @echo %~ti;%~zi;%~dpi;%~nxi >> C:Scanlauf_xls-lw-o.txt
  • Besprechen Sie das Ergebnis der Stichprobe mit den Fachverantwortlichen. Evtl. können auch IDV-Anwendungen gelöscht werden.
  • Erfassen Sie die bestehenden Anwendungen mit ihren Grunddaten wie oben beschrieben (Dateiname, Speicherort, Beschreibung, usw.).
  • Ermitteln Sie das Schutzniveau jeder einzelnen Anwendung Anhand der dokumentierten Einstufung (niedrig, mittel, hoch und sehr hoch)
  • Ordnen Sie die Anwendung den Geschäftsprozessen zu und ermitteln so evtl. Sicherheitslücken.
  • Führen Sie eine Risikoanalyse der GAP durch und leiten ggf. entsprechende Maßnahmen (z. B. „Blattschutz“ oder „Änderungen nachverfolgen“ in Excel) ein, um das Schutzniveau der Anwendung zu erhöhen.

 

 

 

Beitragsnummer: 47239