Phase

QK-ID

QK-Resultat (Ergebnisobjekt)

Zweck des QK-Resultats

& Link zum Template

Design-Phase / Refinement

QK-Plan-1

Projekt-Voranmeldung
(inkl. Kostenplanung)

Über die Projekt-Voranmeldung werden komplett neue Vorhaben oder größere Changes, für die extra Budget beantragt werden muss, initial beantragt.

Hinweis: Die Rückmeldung enthält eine Entscheidung, ob Vorhaben genehmigt wurden oder nicht.

Eine Genehmigung impliziert die Erstellung bzw. ggfs. Aktualisierung der QK-Resultate der Plan-Phase, inkl. entsprechender Bestätigungen durch den ISB und DSB (über die BCS oder Formblatt Datenschutz).

Hierfür wird das Budget, für die Erstellung der QK-Resultate der Plan-Phase, gemäß   kalkulierte Aufwand in der Projektplanung, freigegeben.

Erst wenn alle Nachweise der Plan-Phase vorliegen, darf das Projekt/Vorhaben final genehmigt und das vollständig beantragte Budget freigegeben werden.

QK-Plan-2

BCS

Bereits in der Planphase muss ein erster Entwurf der BCS mit dem ISB abgestimmt werden. Eventuell noch nicht bekannte Details, wie z. B. der spätere Betriebsdienstleister, werden dann im Rahmen des Phase-Gates RTP aktualisiert.

Die 1. Freigabe des ISB gilt nur für die Plan-Phase.

QK-Plan-2

Schnittstellendokumentation („Grobentwurf“)

effiziente Abstimmung, (Weiter-)Entwicklung, Wartung und Betrieb des Datenaustausches

QK-Plan-3

Beteiligung Betriebsrat (Formblatt)

Mitbestimmung/Kontrolle des Sozialpartners bei Möglichkeiten zur Verhaltens- und Leistungskontrolle (insbesondere bei personenbezogenen Daten)

Zustimmung des Betriebsrats wird zum Rollout eines Systems, das der Mitbestimmung unterliegt, benötigt.

Hinweis: Fehlanzeige erforderlich, weshalb der Betriebsrat immer zumindest angefragt werden muss.

Datenschutzvoranmeldung

Erfüllung der Verpflichtung zur Führung des Verzeichnisses aller personenbezogenen Verarbeitungstätigkeiten gemäß Artikel 30 EU Datenschutz-Grundverordnung (EU DSGVO) und Sicherstellung der Datenschutzkonformität

Hinweis: Im der Design bzw. Refinement-Phase muss die Voranmeldung beim Datenschutz erfolgen.

Im Diaglog mit dem Datenschutz wird entschieden, ob weitere Maßnahmen, wie z.B. Erstellung „Löschkonzept“ notwendig. Die Voranmeldung muss immer erfolgen, auch wenn keine personenbezogene Daten verarbeitet werden. Dies wird dann entsprechend vom DSB bestätigt auf dem Formblatt.

Das Formblatt muss im Rahmen der betrieblichen Abnahme nochmal bestätigt werden, so dass sichergestellt ist, dass sich die Rahmenbedingungen nicht während des Release-Prozesses verändert haben und, z.B. auf Grund neuer, zunächst nicht geplanter Funktionen verändert hat (siehe Datenschutzbewertung).

Hinweis: Die Bewertung findet üblicherweise auf Basis einer „Demonstration der fertigen Lösung“ sowie ggfs. durch Prüfung der ggfs. zu erstellenden Dokumentation statt.

Im Nachgang bestätigt der DSB die Datenschutzbewertung und kreuzt

-        sofern weiterhin keine Datenschutzdokumentation zu erstellen ist oder

-        keine Mängel in der zu erstellenden Dokumentation zu finden war

die „Freigabe“ an.

Falls Mängel vorliegen und/oder sich – auf Grund von GAPs zwischen Planung und Realisierung – doch die Notwendigkeit weiterer Dokumentation ergibt, obliegt es dem DSB zu entscheiden, ob er die „Freigabe mit Auflagen“ erteilt oder „keine Freigabe“ erteilt.

Die „Freigabe mit Auflagen“ kann z. B.  die Erstellung der Dokumentation im Nachgang sein.

RTP-Phase

MUSS

Abschließende Datenschutzbewertung

Zum Übergang RTP muss ein aktuelles Statement des DSB eingeholt werden, in dem die – auf Basis der Projektpläne getroffenen - Entscheidungen (Datenschutzvoranmeldung) erneut überprüft werden, ob sie noch angemessen für die realisierte Lösung ist.

Hinweis: Die Bewertung findet üblicherweise auf Basis einer „Demonstration der fertigen Lösung“ sowie ggfs. durch Prüfung der ggfs. zu erstellenden Dokumentation statt.

Im Nachgang bestätigt der DSB die Datenschutzbewertung und kreuzt

-        sofern weiterhin keine Datenschutzdokumentation zu erstellen ist oder

-        keine Mängel in der zu erstellenden Dokumentation zu finden war

die „Freigabe“ an.

Falls Mängel vorliegen und/oder sich – auf Grund von GAPs zwischen Planung und Realisierung – doch die Notwendigkeit weiterer Dokumentation ergibt, obliegt es dem DSB zu entscheiden, ob er die „Freigabe mit Auflagen“ erteilt oder „keine Freigabe“ erteilt.

Die „Freigabe mit Auflagen“ kann z. B.  die Erstellung der Dokumentation im Nachgang sein.

MUSS/KANN (je nach Entscheidung des DSB im Formblatt)

Löschkonzept

Erfüllung der Löschanforderungen für personenbezogene Verarbeitungstätigkeiten bzw. IT-Systeme

QK-RTP-1

Berechtigungskonzept

Die von der Anwendung bereitgestellten Rollen sowie die damit verknüpften Rechte müssen in einem technischen Berechtigungskonzept beschrieben sein.

Ergänzt wird das Konzept durch die Beschreibung der für den Betrieb notwendigen User/Rechte und Rollen, z. B. technische User für die DB, Schnittstellen-User etc.

Darüber hinaus müssen die Workflows zur Vergabe, Entzug, regemäßige Re-Zertifizierung („Soll-Ist-Ableich“) für die fachlichen Rollen der neuen Applikation beschrieben sein.

Ergebnis Prüfung Open Source License Compliance

Einhaltung der auf dem Einsatz der Open Source basierenden Lizenzpflichten

QK-RTP-1

Betriebsdokumentation sowie ggs. Wartungsdokumentation

Befähigung des Betriebsdienstleisters zur eigenständigen Erbringung der beauftragten Betriebsdienstleistung.

Die Betriebsdokumentation wird – zusammen mit dem späteren Betriebs- und Wartungsdienstleister - noch im Rahmen des RTP erstellt bzw. für das aktuelle Release bei Bedarf aktualisiert und bei der betrieblichen Abnahme geprüft.

Wartungsdokumentation

Befähigung des Wartungsdienstleisters zur Gewährleistung der Wartung des Produktivbetriebs.

Hinweis. Dokument ist nur zu erstellen, wenn der Betrieb der Basissysteme und die Wartung der darauf installierten Applikationen und/oder die Wartung der fachlichen Anwendung durch unterschiedliche Organisationen erfolgt.

Supportdokumentation

Befähigung des Service Desks zur Gewährleistung des Supports des Produktivbetriebs unter Minimierung von Ausfallzeiten.

Hinweis. Dokument ist nur zu erstellen, wenn der Support durch eine andere Organisation als der fachliche und technische Betrieb erfolgt.

QK-RTP-2

Build- und Runtime-Umgebungskonfiguration

Implementierung des IT-Systems. Die Dokumentation wird – zusammen mit dem späteren Betriebs- und Wartungsdienstleister - noch im Rahmen des RTP erstellt bzw. für das aktuelle Release bei Bedarf aktualisiert und bei der betrieblichen Abnahme geprüft.

MUSS/KANN (je nach Entscheidung in BCS)

IT-Sicherheitskonzeption bzw. GAP-Analyse Standardmaßnahmen

Identifizierung und Dokumentation der Informationsrisiken, Informationsaspekte und Schutzanforderungen des IT-Systems zum Erreichen eines akzeptablen Risikoniveaus

Abnahmeerklärung System

Dokumentation der Abnahmetests des IT-Systems sowie darauf basierende Empfehlung des Testmanagers zur Abnahme des Systems; Dokumentation der Systemabnahme durch den Projektleiter.
Betriebliche Abnahme durch den BDL/WDL, basierend auf der Checkliste im Anhang.

Systemarchitektur

Dokumentation der Systemarchitektur

ID

Titel der Maßnahme

Beschreibung

Kontrollfrage mit Antwortmöglichkeit

1.        Sicherheitsaspekte bei der Schaffung/Planung der IT-Infrastruktur sowie beim späteren Betrieb

1.1     

Bestimmung des Schutzbedarfes der IT-Systems

Alle schützenswerte - im IT-System verarbeiteten - Informationen sind vom Verantwortlichen hinsichtlich der Schutzziele

-        „Vertraulichkeit“,

-        „Integrität“ und

-        „Verfügbarkeit“

zu klassifizieren.

Um die Maßnahme zu erfüllen ist für den Geschäftsprozess, welcher durch das IT-System unterstützt wird, eine BCS auszufüllen.

Das IT-System erbt den dort dokumentierten Schutzbedarf der Informationen.

Der Prozesseigner muss dem IT-Verantwortlichen den Schutzbedarf mitteilen.

Anmerkung für IT-Verantwortliche: Sofern das System mehrere Geschäftsprozesse unterstützt, erbt es den Schutzbedarf des schützenwürdigsten Systems.

ITSM-1.1: Ist der Schutzbedarf der im IT-System bzw. in den IT-Applikationen / Anwendung­ssoftware verarbeiteten Informationen dokumentiert?

Wählen Sie ein Element aus.

Hinweis: Beantwortung ausschließlich mit Freitext, ohne Verwendung des DropDown-Auswahlmenüs ist nicht zulässig und wird als „nicht bearbeitet“ inkl. „Schulungsbedarf erkannt“) bewertet! Dies gilt für alle nachfolgenden Antworten.

Bei Verweis auf weitere externe Doku­mentation und/oder eine existierende Ausnahmegenehmigung, dann bitte den Link zum Ablageort sowie „Excemption_ID“ im Freitext vermerken.

1.2     

Identifikation und Befolgung der gesetzlichen Anforderungen und der wesentlichen Regelungen

Die wesentlichen Gesetze und Regularien und deren Anforderungen sind für das IT-System zu identifizieren und zu prüfen. Dies kann in der BCS des Geschäftsprozesses erfolgen, welcher durch das IT-System unterstützt wird.

Die Prüfung beinhaltet neben gesetzlichen und externen vertraglichen Vorgaben (z. B. GoBD, EU DSGVO, PCI-DSS etc.) auch die Identifikation der wesentlichen Regeln, welche sich aus unternehmensinternen Vorgaben ergeben (z. B. IS-Richtlinien der F. X. MEILLER Fahrzeug- und Maschinenfabrik – GmbH & Co KG ).

Sich aus der Prüfung ergebende Maßnahmen  sind abzuleiten und für den weiteren Betrieb zu berücksichtigen.

Der Prozesseigner muss dem IT Verantwortlichen ggfs. die anzuwendenden Regelungen kommunizieren, so dass diese dort Berücksichtigung finden.

ITSM-1.2.1 Wurden die

-        gesetzlichen und

-        regulatorischen Anforderungen sowie alle weiteren

-        internen (z. B. IS-Richtlinien) und

-        externen (z. B. Anforderungen aus Verträgen mit Kunden) Anforderungen

identifiziert und etwaige Maßnahmen, wie z. B. Verschlüsselung von Kommunikationsverbindungen etc. abgeleitet? Wurden die Ergebnisse der Analyse dokumentiert?

Wählen Sie ein Element aus.

ITSM-1.2.2 Wurden den IT-Dienstleistern eventuell einzuhaltende Anforderungen, die sich z. B. aus Vorgaben für das Business ableiten, kommuniziert?

Wählen Sie ein Element aus.

1.3     

Erstellung eines Betriebskonzeptes bzw. einer Betriebsdokumentation

Für jedes IT-System muss es ein Betriebskonzept bzw. eine Betriebsdokumentation geben, aus der ersichtlich wird, wer im Rahmen des Betriebs für die Betriebsprozesse verantwortlich ist.

Dies umfasst konkret:

-        Schutzbedarf des Systems

-        System-Dokumentation
(evtl. als Verweis auf QK-Resultat)

-        Patch und Schwachstellenmanagement (für alle Komponenten)

-        Log-Auswertung

-        Datensicherung

-        Regelmäßige Überprüfung der vergebenen Berechtigungen

-        Release-to-Production-Prozess

-        Vorfall-Management (z. B. Security Incident im IT-System)

ITSM-1.3.1 Gibt es ein zwischen Prozesseigner und IT abgestimmtes Betriebshandbuch für das IT-System bzw. für die IT-Systeme?

Wählen Sie ein Element aus.

ITSM-1.3.2: Sind für den Betrieb der Basissysteme und zur Wartung bzw. zum Support der Applikationen und/oder Software unterschiedliche Dienstleister im Einsatz?

Wenn ja, wurden mit dem Wartungs- und Supportdienst­leistern (WDL/SDL) entsprechende Vereinbarungen, in Form eines Handbuches dokumentiert?

Wählen Sie ein Element aus.

ITSM-1.3.3: Gibt es eine vollständige und aktuelle System-Dokumentation?

Wählen Sie ein Element aus.

ITSM-1.3.4 Ist das Patch und Schwachstellenmanagement (für alle Komponenten) geklärt, also sowohl für die Betriebssystem-Ebene als auch für die eingesetzten IT-Applikationen UND die Software (einschließlich darin verwendeter Libraries)?

Wählen Sie ein Element aus.

ITSM-1.3.5 Wurde zwischen Fachseite/Kunde und dem BDL/WDL die Art und der Umfang der Protokollierung geklärt?

Wählen Sie ein Element aus.

ITSM-1.3.6 Wurde zwischen Fachseite/Kunde und dem BDL/WDL die Art und der Umfang des Betriebs- und Anwendungs­monitoring geklärt und die Vereinbarungen entsprechend dokumentiert?

Wählen Sie ein Element aus.

ITSM-1.3.7 Wurde zwischen Fachseite/Kunde und dem BDL/WDL die Art und der Umfang der Datensicherung geklärt und die Vereinbarungen entsprechend dokumentiert?

Wählen Sie ein Element aus.

ITSM-1.3.8 Wurde der Restore der Datensicherung erfolgreich getestet?

Wählen Sie ein Element aus.

ITSM-1.3.9 Umfasst die Betriebsdokumentation einen Verweis auf die Vereinbarungen zum Change-Management (inkl. Verantwortlichkeiten) und den einzuhaltenden RTP-Prozess?

Wählen Sie ein Element aus.

ITSM-1.3.10 Umfasst die Betriebshandbuch einen Verweis auf den Prozess zur Bewältigung von Sicherheitsvorfällen inklusive der Dokumentation der Verantwortlich­keiten hinsichtlich Eskalation und Meldewege?

Wählen Sie ein Element aus.

1.4     

Dokumentation und Pflege der Systemkonfiguration

Eine Dokumentation des Systems und seiner Konfiguration muss erstellt und auf dem aktuellsten Stand gehalten werden. Die Dokumentation sollte unter anderem Informationen zu folgenden Punkten enthalten:

-        Konfiguration,

-        physische Netzwerkstruktur,

-        logische Netzwerkkonfiguration,

-        Schnittstellen

-        Zugriffsrechte von Benutzern,

-        Backupstatus etc.

Des Weiteren muss für jedes IT-System dokumentiert werden, welche Applikationen in welcher Version verwendet werden und wie die Dateistrukturen angelegt sind.

Die Dokumentation muss so aufbewahrt werden, dass sie jederzeit, insbesondere im Falle eines Notfalls, direkt verfügbar und dabei gleichzeitig vor unbefugten Zugriffen geschützt ist. Die Systemdokumentation muss alle Aktivitäten enthalten, die zum Starten oder Herunterfahren des IT-Systems notwendig sind.

Siehe  ITSM-1.3.3.

1.5     

Erstellung von Konzepten zum Berechtigungs­management

Jedem Benutzer ist eine eindeutige Benutzerkennung zuzuordnen, so dass Tätigkeiten nachträglich zur verantwortlichen Person zurückverfolgt werden können.

Im Rahmen des Berechtigungsmanagements müssen technische und organisatorische Verfahren zur Vergabe und zum Entzug von Zugriffsrechten (optimalerweise auf Rollenbasis) etabliert werden.

Um die unkontrollierte Vergabe von Zugriffsberechtigungen zu vermeiden, müssen hierbei insbesondere die Prozesse zur Beantragung, zur Vergabe sowie zum Entzug von Rechten dokumentiert und in der Praxis akzeptiert sein. Bzgl. der Löschung von Accounts ist sicher zu stellen, dass ein Informationsfluss gewährleistet ist und dass die Löschung bei der Beendigung von Verträgen oder Dienstverhältnissen zeitnah erfolgt. Hierbei empfiehlt es sich, den Account zunächst zu deaktivieren und erst nach ca. 6 Monaten vollständig zu löschen.

Um zu verhindern, dass trotz der etablierten Prozesse nicht benötigte Berechtigungen bestehen bleiben, müssen Zugriffsberechtigungen in regelmäßigen Abständen hinsichtlich ungenutzter oder veralteter Accounts oder zu freizügig vergebener Zugriffsrechte überprüft werden.

ITSM-1.5.1: Gibt es sowohl für die User/Rollen der IT-Ebene, also

-        User am Betriebssystem

-        User in Zusatzsoftware, wie z. B. Middleware oder Oracle Datenbank,

als auch für die

-        User der Fachanwendung

ein Berechtigungs­konzept?

Wählen Sie ein Element aus.

ITSM-1.5.2:  Sind in dem Kontext die Prozesse

-        zur Beantragung,

-        zur Vergabe sowie

-        zum Entzug von Rechten dokumentiert?

Wählen Sie ein Element aus.

ITSM-1.5.3:  Gibt es jeweils eine Beschreibung des einzuhaltenden Workflows samt der erforderlichen Genehmigungswege?

Wählen Sie ein Element aus.

ITSM-1.5.4:   Sind technische und organisatorische Verfahren zur Unterstützung der Workflows hinsichtlich Vergabe und zum Entzug von Zugriffsrechten etabliert?

0- unbearbeitet

ITSM-1.5.5:  Ist jedem Benutzer bzw. Administrator eine eindeutige Benutzerkennung zugeordnet und ist sichergestellt, dass es keine Gruppenaccounts gibt?

0- unbearbeitet

ITSM-1.5.6:  Existiert ein dokumentierter Prozess, welcher sicherstellt, dass vorhandene Accounts hinsichtlich veralteter Einträge regelmäßig überprüft werden?

0- unbearbeitet

Hinweis: Bitte schreiben sie ggfs. im Freitext, wer für die Prüfung verantwortlich ist und wie der Nachweis der Prüfung erbracht werden kann und wo die Ergebnisse der Prüfung dokumentiert sind!

1.6     

Sichere Authentifizierung

Für den Zugriff auf MEILLER-Systeme muss die MEILLER-Passwortrichtlinie eingehalten werden. Wenn mittels des Accounts auf streng vertrauliche Daten oder auf geschäftskritische Prozesse zugegriffen werden kann, dann ist eine Zwei-Faktor-Authentifizierung (2FA) einzuführen.

ITSM-1.6.1: Ist die Passwortrichtlinie unserer Organisation für alle durch den IT-Betrieb genutzten Accounts umgesetzt?

0- unbearbeitet

ITSM-1.6.2: Ist die Passwortrichtlinie unserer Organisation für alle fachlichen Accounts umgesetzt?

0- unbearbeitet

ITSM-1.6.3: Ist eine 2FA notwendig und wenn ja, ist diese vorhanden?

0- unbearbeitet

ITSM-1.6.4: Gibt es einen sicheren PW-Reset-Prozess? Ist sichergestellt, dass keine Passwörter per Mail verschickt werden?

0- unbearbeitet

1.7     

Definition von Test- und Release Prozessen (für Eigenentwicklungen)

Für das effektive und angemessene Testen ist ein Konzept zu entwickeln. Die Prozesse von der Entwicklung über das Testen hin zur Betriebssetzung („Freigabeprozess“) sind entsprechend anzupassen und im Betriebshandbuch zu dokumentieren.

Das Testkonzept sollte hier auch anwendungsspezifische Testfälle umfassen, so dass auch eine unkorrekte Verarbeitung von Daten innerhalb der Applikation erkannt werden kann.

Ferner sollte eine Umgebung eingerichtet werden, die lediglich für Testzwecke genutzt wird. Sofern in dieser Umgebung mit Produktivdaten gearbeitet wird, müssen dort dieselben Sicherheitsmaßnahmen greifen wie in der Produktivumgebung. Dies gilt auch, wenn es sich um veraltete Wirkdaten handelt. Testdaten mit Personenbezug müssen allerdings immer anonymisiert werden.

Die Umgebungen zur Entwicklung, zum Test und zum operativen Betrieb der Systeme müssen voneinander getrennt werden.

ITSM-1.7.1: Existieren dokumentierte Test- und Release-Prozesse?

0 - unbearbeitet

 ITSM-1.7.2:  Existiert eine Testumgebung?

Werden in der Testumgebung personenbezogene Daten nur anonymisiert verwendet, so dass kein Personenbezug mehr gegeben ist?

0 - unbearbeitet

ITSM-1.7.3: 

Ist sichergestellt, dass bei der Testumgebung dieselben Sicherheitsmaßnahmen wie in der Produktivumgebung verwendet werden – sofern mit vertraulichen Echtdaten gearbeitet wird?

0 - unbearbeitet

1.8     

Sicherheitsüberprüfung von im Internet erreichbaren IT-Systemen vor Roll-out / Going live (Eigenentwicklungen)

Neue IT-Systeme sollten sich vor Going live einer technischen Sicherheitsüberprüfung unterziehen. Dies kann entweder mittels einer Quellcodeanalyse oder mittels eines Penetrationstestes erfolgen.

Für Projekte / IT-Systeme mit Schnittstellen in öffentliche Netze ist mindestens eine der Überprüfungen Pflicht.

ITSM-1.8.1:  Hat eine technische Sicherheitsüberprüfung vor dem Roll-out stattgefunden (Penetrationstest / Quellcodeanalyse)?

0 - unbearbeitet

1.9     

Festlegung von Verantwortlichkeiten, Aufgaben und Meldewege bei Sicherheitsvorfällen

Die Verantwortlichkeiten, Aufgaben und Meldewege bei Sicherheitsvorfällen müssen definiert sein und allen beteiligten Mitarbeitern kommuniziert werden.

Siehe hierzu ITSM-1.3.10

2.        Sicherheitsaspekte bei der Zusammenarbeit mit externen Dienstleistern

2.1     

Erstellung von (bzw. Überprüfung der) vertraglichen Regelungen / Vereinbarungen mit externen Firmen

Bei der Zusammenarbeit mit externen Partnern (z. B. Betrieb, Softwareentwicklung) müssen die vertraglichen Regelungen genau überprüft werden. Neben den operativ notwendigen Punkten müssen durch eine vereinbarung auch Vorgaben hinsichtlich Informationssicherheit geregelt werden. Die Vereinbarung sollte eine Prüfung der externen Infrastruktur vorsehen und MEILLER die Befugnis einräumen, sich jederzeit über den aktuellen Stand der Sicherheit zu erkundigen bzw. die ordnungsgemäße Umsetzung von Sicherheitsmaßnahmen zu überprüfen. Dies könnte z.B. durch eine entsprechende Zertifizierung (z.B. ISO 27001, TISAX), durch Audits oder durch Penetrationstests erfolgen.

Weitreichende Änderungen an der Infrastruktur muss MEILLER immer mitgeteilt werden.  Darüber hinaus ist in der Vereinbarung die Einbeziehung von Unterauftragnehmern auf Seiten des externen Dienstleisters zu regeln.

Des Weiteren muss eine Vereinbarung für die Datenverarbeitung im Auftrag“ durch externe Dienstleister aufgesetzt werden. Der externe Dienstleister muss zur Erfüllung verpflichtet werden, sofern personenbezogene Daten verarbeitet werden.

ITSM-2.1.1: Sind in Verträgen mit Dienstleistern auch Vorgaben hinsichtlich Informationssicherheit geregelt?  Wurden alle beteiligten Dienstleister auf die Informations-sicherheits-Richtlinien und -Vorgaben verpflichtet?

Existiert eine Vereinbarung für die „Datenverarbeitung im Auftrag“?

0 - unbearbeitet

ITSM-2.1.2:  Ist vertraglich geregelt, dass die o.g. Anforderungen an etwaige Subunternehmer weitergegeben werden?

0 - unbearbeitet

2.2     

Entwicklung von Alternativplänen bei Ausfall der externen Dienstleister

Es müssen Alternativpläne für den Ausfall der externen Dienstleister (Betrieb / Softwareentwicklung) erstellt werden, so dass ein Betrieb des Verfahrens gemäß den eigenen Anforderungen gewährleistet ist.

Hierzu gehört unter anderem der Abschluss einer Escrow-Vereinbarung bei Nutzung von extern entwickelter Software, um im Bedarfsfall den Zugriff auf den Source-Code zu ermöglichen.

ITSM-2.2.1:  Wurden Alternativplänen bei Ausfall eines externen Dienstleisters erstellt?

Gibt es z.B. einen Escrow-Vertrag?

0 - unbearbeitet

3.        Physische Sicherheit

3.1     

Schutz der Applikation vor physischen Bedrohungen

Die physischen Bedrohungen und der unberechtigte Zugang zu IT-Systemen sind durch geeignete Maßnahmen (Brandverhinderung, Wasserschutz etc.) zu minimieren bzw. zu verhindern.

Optimalerweise kann der Rechenzentrumsbetrieb ein entsprechendes Sicherheitszertifikat (z.B. nach ISO 27001) nachweisen.

ITSM-3.1.1:  Wurden geeignete Maßnahmen zum Schutz gegen physische Bedrohungen und unberechtigten Zugang ergriffen?

0 - unbearbeitet

4.        Applikations- und Netzwerksicherheit

4.1     

Härtung der IT-Systeme und Anwendungen

Unter Härten versteht man in der IT, die Sicherheit eines IT-Systems zu erhöhen, indem nur dedizierte Software installiert und nur Dienste eingesetzt werden, die zum einen für den Betrieb des IT-Systems notwendig sind und für die zum anderen unter Sicherheitsaspekten von einem korrekten Ablauf ausgegangen werden kann.

Sämtliche Prozesse sind hierbei darauf zu überprüfen, dass ihnen nur die für die beabsichtigte Ausführung zwingend erforderlichen Rechte zugewiesen sind. Für jeden Server muss eine Liste der aktivierten Dienste existieren. In einer weiteren Spalte sollte dokumentiert sein, weshalb und zu welchem Zwecke der Dienst benötigt wird. Ferner sind Standardbenutzerkonten von Betriebs- und Anwendungssystemen grundsätzlich umzubenennen oder ihnen jegliche Rechte zu entziehen. Netzwerkprotokolle sowie Ports sind zu beschränken. Freigaben auf IT-Systemressourcen sind einzuschränken. Eventuelle Schwachstellen sind durch verfügbare Patches zu beseitigen, das IT-System sollte den neuesten Patchstand bzw. die neueste Versionierung besitzen.

ITSM-4.1.1:  Wurden die im Kontext des Verfahrens eingesetzten Server speziell gehärtet? Existiert ein dokumentierter Härtungsguide?

0 - unbearbeitet

ITSM-4.1.2:  Existiert eine Liste aller aktivierten Dienste pro Server und warum diese benötigt werden und welche Rechte notwendig sind? Laufen nur die benötigten Dienste?

0 - unbearbeitet

ITSM-4.1.3:  Laufen die Dienste jeweils unter eigenen IT-Systemkonten mit minimalen Rechten?

0 - unbearbeitet

4.2     

Sichere Verwendung von Zusatztools auf den Servern

Sofern Zusatzsoftware auf den Servern betrieben wird, ist dies im Betriebshandbuch bzw. in der Systemdokumentation zu dokumentieren.

Die Software ist in den Patch Management-Prozess zu integrieren. Ferner sollte die Software mit eigenen (minimalen) Userrechten betrieben werden.

ITSM-4.2.1:  Gibt es für jedes IT-System eine Übersicht, welche Dienste bzw. welche Zusatzsoftware in welcher Version darauf betrieben werden?

0 - unbearbeitet

ITSM-4.2.2:  Ist Zusatzsoftware im Patch Management-Prozess sowie im Schwachstellenmanagement integriert?

0 - unbearbeitet

4.3     

Verschlüsselung von streng vertraulichen Informationen

Streng vertrauliche Informationen <<unserer Organisation >> dürfen nur verschlüsselt abgespeichert werden. Dies gilt sowohl für die Speicherung in Datenbanken als auch im Dateisystem oder im Backup.

ITSM-4.3.1:  Ist sichergestellt, dass streng vertrauliche Informationen ausschließlich verschlüsselt abgespeichert werden?

0 - unbearbeitet

ITSM-4.3.2:  Gilt das auch für die Datensicherung?

0 - unbearbeitet

4.4     

Sicherstellung von ausreichender Verarbeitungsleistung

Die IT-Systeme müssen den Sicherheitsanforderungen und Klassifizierungen entsprechend performant implementiert sein, um die gesetzten Ziele bezüglich Antwortzeiten und Kapazitäten ausreichend erfüllen zu können.

Dies bedingt auch eine entsprechende Auslegung der eingesetzten Netzwerkkomponenten und -verbindungen.

ITSM-4.4.1:  Gibt es eine Kapazitätsplanung für das IT-System?  

0 - unbearbeitet

4.5     

Auswahl einer geeigneten Virenschutz-Strategie

Insbesondere Verzeichnisse zum Datenaustausch müssen immer mittels eines Virenschutzprogramms überprüft werden. Darüber hinaus muss sichergestellt sein, dass das Virenschutzprogramm immer aktuell ist.

ITSM-4.5.1:   Sind die Server mit einem Virenschutz geschützt oder findet alternativ eine Prüfung des Datenstroms hinsichtlich Malware statt?

0 - unbearbeitet

4.6     

Segmentierung des Netzwerkes sowie Trennung der Applikationsschichten

Das Netzwerk ist sinnvoll zu segmentieren. So sollte z.B. eine Aufteilung der Software-Schichten auf eigene Netzwerksegmente erfolgen. Ferner sollten Applikationsschichten getrennt werden, so dass pro Server lediglich ein zentraler Dienst betrieben wird.

In der Praxis hat sich eine 3-tier-Architektur bewährt, welche neben einer Präsentations- und Verarbeitungszone zusätzlich eine Persistenzzone vorsieht. Optimalerweise wird hierbei zwischen jeder Zone ein IP-Filter (Firewall) betrieben.

Die Segmentierung kann auch mittels Container realisiert werden.

ITSM-4.6.1:   Wurden die einzelnen Software-Schichten auf eigene Netzwerksegmente / Container verteilt?

0 - unbearbeitet

4.7     

Absicherung von Kommunikationswegen und Schnittstellen

Für das IT-System müssen alle Schnittstellen dokumentiert sein. Für jede Schnittstelle (egal ob IT-basiert oder manuell) ist aufzuzeigen, welche Daten über die Schnittstelle im- bzw. exportiert werden und wie diese klassifiziert sind.

Kommunikationswege und Schnittstellen sind generell durch

-        Einschränkung der Kommunikation,

-        durch Authentisierung der Kommunikationspartner bzw. allgemein durch die Kontrolle des Datenflusses abzusichern. 

Als vertraulich eingestufte Informationen sind hierbei immer zu verschlüsseln, wenn sie das gesicherte Netzwerk (CN) der F. X. MEILLER Fahrzeug- und Maschinenfabrik – GmbH & Co KG verlassen.

Als streng vertraulich eingestufte Informationen sind selbst bei einer Übertragung im lokalen Netzwerk zu schützen.

Bei der gegenseitigen Authentisierung empfiehlt sich der Einsatz von starken Mechanismen, wie z.B. von Zertifikaten.

ITSM-4.7.1:   Existiert eine Liste der  IP-basierten Schnittstellen /  Kommunikationsverbindungen (KV) des hier betrachteten Systems/GP? Enthält die Liste pro Kommunikationsverbindung eine Info …

1.        .. über die genutzte Schnittstelle, z.B. Benennung des Schnittstellen Providers (Server) und der – die Schnittstelle nutzenden – Clients (Consumer).

2.        .. über die Kommunikationspartner (KP) und deren Netzanbindung, inkl. Beschreibung des Kommunikationsaufbau, also z. B. wer die Verbindung initiiert und wie sich die KP gegenseitig authentifizieren.

3.        .. über die jeweils in der KV übertragen Daten (inkl. Verweis auf SBF, CIA),

4.        … über das verwendete technische Protokoll sowie ggfs

5.        über die Absicherung der Verbindung, z. B. Verschlüsselung, Einsatz Loadbalancer, Einsatz Signaturen zur Authentifizierung etc.

0 - unbearbeitet

ITSM-4.7.2:   Sind sämtliche Kommunikationswege und Schnittstellen in Bezug auf die Einstufung der zu transportierenden Daten abgesichert?

0 - unbearbeitet

ITSM-4.7.3:   Ist sichergestellt, dass z. B. über E-Mail keine vertraulichen Daten / Reports unverschlüsselt kommuniziert werden?

0 - unbearbeitet

ITSM-4.7.4:   Erfolgt eine Authentisierung der Kommunikationspartner?

0 - unbearbeitet

5.        Sicherheitsaspekte bei der Administration der IT-Infrastruktur

5.1     

Etablieren eines Patch Management

Es ist ein Patch Management zu etablieren, welches in die Test- und Release Prozesse einzubinden ist.

Das Patch Management ist in der Betriebsdokumentation zu beschreiben. Es muss sowohl für die OS-Ebene als auch für die Applikationsebene (inkl. evtl. Libraries) geregelt sein, wer für die Pflege der Software verantwortlich ist. 

Siehe  ITSM-1.3.4.

5.2     

Regelmäßige Untersuchung des Informationsverbundes auf neu bekannt gewordene Sicherheitsprobleme

Die eingesetzten IT-Systeme sind regelmäßig zu überprüfen, ob Sicherheitsprobleme öffentlich bekannt gemacht wurden.

Quellen zur Informationsbeschaffung können sein:

-        das Bundesamt für Sicherheit in der Informationstechnik,

-        Computer Emergency response teams (CERTs),

-        Hersteller und Distributoren von Software und Betriebssystemen,

-        Hersteller-, IT-System- oder Security-spezifische Webseiten,

-        Mailinglisten oder Newsgroups,

-        Automatisierte Schwachstellenscanner

Sofern ein Sicherheitsproblem identifiziert wurde, sind die im Advisory vorgeschlagenen Maßnahmen zu ergreifen (z. B. Einspielen eines Patches).

Es muss sowohl für die OS-Ebene als auch für die Applikationsebene (inkl. evtl. Libraries) geregelt sein, wer für die Überwachung der Software verantwortlich ist.  

Siehe  ITSM-1.3.4:

5.3     

Datensicherung /Archivierung

Die regelmäßige Sicherung von Daten ist die Voraussetzung, dass bei Verarbeitungsfehlern oder -störungen durch Zugriff auf den letzten Datenbestand eine Fortführung der Verarbeitung mit nur relativ geringen Verzögerungen möglich ist. 

Deshalb sind grundsätzlich alle Daten (gemäß Datensicherungskonzept) in regelmäßigen Abständen zu sichern.

Das Konzept sollte hierbei auch Vorgaben zum regelmäßigen Test der Datensicherungen machen, so dass sichergestellt ist, dass das „Zurückspielen“ des Backups im Ernstfall auch ordnungsgemäß funktioniert.

Über die eigentliche Datensicherung hinaus muss geklärt werden, ob eine Archivierung von Daten notwendig ist. Falls ja, dann ist dies entsprechend zu beauftragen und durchzuführen.

Siehe  ITSM-1.3.7

5.4     

Protokollierung sowie Kontrolle der Protokolldateien

Die Protokollierung der IT-Systeme muss gemäß Protokollierungskonzept erfolgen. Die Protokollierung sicherheitsrelevanter Ereignisse ist als Sicherheitsmaßnahme allerdings nur wirksam, wenn die protokollierten Daten in regelmäßigen Abständen durch einen Revisor oder durch ein dafür geeignetes Tool ausgewertet werden.

Ist es personell oder technisch nicht möglich, die Rolle eines unabhängigen Revisors für Protokolldateien zu implementieren, kann ihre Auswertung auch durch den Administrator erfolgen. Für diesen Fall bleibt zu beachten, dass damit eine Kontrolle der Tätigkeiten des Administrators nur schwer möglich ist.

Siehe  ITSM-1.3.5.

6.        Sicherheitsaspekte bei der Außerbetriebnahme der IT-Infrastruktur und Entsorgung von Informationen

6.1     

Sichere Entsorgung von Medien, welche vertraulichen Informationen enthalten

Alle Medien (Datenträger, papiergebundene Informationen etc.), welche vertrauliche Informationen umfassen, sind gemäß den Anforderungen des Bundesamtes für Informationssicherheit (BSI) zu vernichten.

ITSM-7.1.1: Werden alle Datenträger ggfs. über einen sichereren Weg entsorgt?

0 - unbearbeitet

ITSM-7.1.2: Werden papiergebundene Informationen über die zur Verfügung stehenden Datenschutztonnen entsorgt?

0 - unbearbeitet