Deckblatt
| Unnamed: 0 | Unnamed: 1 | Unnamed: 2 | Unnamed: 3 | Unnamed: 4 |
|---|---|---|---|---|
| Anhang 3.1: Anforderungskatalog | ||||
| zu Anlage 3 Informationssicherheit | ||||
| Ansprechpartner | Angaben zum Auftragnehmer / zur ausgelagerten Leistung | |||
| Helaba - Information Security Management | Name: | Bitte einfügen | ||
| Hr. Christian Talmon | is-governance@helaba.de | Ansprechpartner (inkl. E-Mail-Adresse): | ||
| Kurzbeschreibung der Leistung: | Bitte einfügen Beipieltext: Weiterentwicklung / Customizing der DV-Anwendung SAP/ABAKUS sowie Projektmanagement-, Schulungs-, IT-Beratungs- , IT-Supportleistungen und konzeptionelle Leistungen. | |||
| Schutzbedarfsklassifizierung | Bitte einfügen | |||
| Vertraulichkeit (C): | Bitte einfügen | |||
| Integrität (I): | Bitte einfügen | |||
| Verfügbarkeit (A): | Bitte einfügen | |||
| Einleitung | Dieser Anhang ist vom Auftragnehmer zu befüllen und wird Vertragsbestandteil. Er enthält neben dem Rahmenvertrag und der Anlage weitere allgemein gültige Regelungen zur Informationssicherheit. Die Regelungen finden Anwendung auf alle im Rahmen der ausgelagerten Prozesse und Aktivitäten durch die Helaba bereitgestellte und vom Auftragnehmer eingesetzte Informationstechnik (IT), IT-Systeme (alle technischen Anlagen, die der Informationsverarbeitung dienen und eine abgeschlossene Funktionseinheit bilden), Infrastruktur (die für die Informationsverarbeitung und IT genutzten Gebäude, Räume, Energieversorgung, Klimatisierung und die Verkabelung) und sonstige Zielobjekte. Grundsätzlich ist bei allen relevanten Fragestellungen der Informationssicherheit der Rahmenvertrag, diese Anlage zum Rahmenvertrag und die Detailregelungen in den Einzelabrufen/Einzelaufträgen zu berücksichtigen. Abweichungen von diesen Regelungen müssen nachvollziehbar dokumentiert werden und bedürfen der schriftlichen Zustimmung des Auftraggebers. Bei Widersprüchen zwischen den Regelungen des Rahmenvertrages und dieser Anlage, haben die Regelungen dieser Anlage Vorrang vor denen des Rahmenvertrages. Die vorliegende Anlage 3 soll sicherstellen, dass ein Sicherheitsniveau aufgebaut, implementiert und während der Laufzeit des Rahmenvertrages aufrechterhalten werden kann, das dem durchschnittlichen Sicherheitsniveau der in Deutschland angesiedelten Kreditinstitute entspricht. | |||
| Regulatorische Grundlage des Dokuments | o Mindestanfoderungen an das Risikomanagement (MaRisk) o Bankaufsichtliche Anforderungen an die IT (BAIT) o EBA Guidelines on Outsourcing |
Bearbeitungshinweise
| Unnamed: 0 | Unnamed: 1 | Unnamed: 2 |
|---|---|---|
| Hinweise an den Auftragnehmer zur Bearbeitung des Tabellenblatts "Anforderungskatalog" | ||
| Der Anforderungskatalog ist von links nach rechts zu bearbeiten. | ||
| Wenn die Sicherheitsvorgabe für die Auslagerung bzw. Dienstleistung relevant ist, werden die Felder Referenzdokumente und der Erfüllungsgrad zu Pflichtfeldern. | ||
| Wenn eine Sicherheitsvorgabe für Sie relevant ist, geben Sie bitte die passenden Referenzdokumente an. Bei der Referenzierung der Nachweisdokumentation, achten Sie bitte darauf, dass diese für Dritte nachvollziehbar ist und sich genau auf die vorgegebene Sicherheitsvorgabe bezieht. | ||
| Beim Erfüllungsgrad tragen Sie bitte vollständig erfüllt, teilweise erfüllt oder nicht erfüllt ein. Sollte der Erfüllungsgrad nur teilweise erfüllt oder nicht erfüllt sein, erläutern Sie bitte die Abweichung in der darauffolgenden Spalte. | ||
| Bei der Bewertung des Erfüllungsgrades beachten sie bitte die Umsetzungen der Mindestanforderungen. |
Anforderungskatalog
| Kapitel | Titel | Inhalt | Relevant für den Auftragnehmer | Begründung bei "teilweise relevant" oder "nicht relevant" | Erfüllungsgrad des Auftragnehmers | Erläuterung der Abweichungen bei "teilweise erfüllt" oder "nicht erfüllt" | Ergänzende Bemerkungen des Auftragnehmers | Referenzdokumente des Auftragnehmers | Ergänzende Bemerkungen des Auftraggebers |
|---|---|---|---|---|---|---|---|---|---|
| Generell gilt: Bei der Schutzbedarfsklasse (SBK) 4 können durch den Auftraggeber weitere - über die bestehenden Sicherheitsvorgaben hinaus - Sicherheitsmaßnahmen beauftragt werden. | |||||||||
| 4.0 | R.0400 - Change- und Patchmanagement | ||||||||
| 4.1 | Zielsetzung | Der Auftragnehmer stellt durch das Change- und Patchmanagement für die im Rahmen der Leistungserbringung verwendeten Informationen, IT-Anwendungen und IT-Systeme sicher, dass der ordnungsgemäße und sichere Betrieb von informationsverarbeitenden Einrichtungen erfolgt. Zu den relevanten Verfahren gehören dabei Definition, Planung, Priorisierung, Test, Freigabe, Durchführung und Dokumentation der Änderung. | relevant | ||||||
| 4.2 | Kontrolle und Formalisierung von Änderungen | Es sind dokumentierte Prozesse zu implementieren, über die Änderungen zu kontrollieren und freizugeben sind. Es ist sicherzustellen, dass Änderungen dokumentiert und evaluiert sind. Changes sind zu planen, priorisieren, testen, implementieren und dokumentieren. Der zu etablierende Prozess für IT-Systeme und Anwendungen, die Einfluss auf die Sicherheit der Assets haben, muss die folgenden Mindestanforderungen erfüllen: • Ein formelles Antrags- und Genehmigungsverfahren für vorgeschlagene Änderungen ist vorzugeben. | relevant | ||||||
| 4.2 | Kontrolle und Formalisierung von Änderungen | [SBK 4 - CIA]: Der Auftraggeber ist vor Umsetzung von Änderungen mit Auswirkungen auf das Informationssicherheitsniveau des Auftraggebers bzw. das Informationssicherheitsniveau der vertragsgegenständigen Dienstleistungen immer vorab zu informieren. | relevant | ||||||
| 4.3 | ISO-Referenz Annex A | 5.10 Acceptable use of information and other associated assets 8.9 Configuration management 8.32 Change management | nicht relevant - Hinweistext | ||||||
| 5.0 | R.0500 - Schwachstellenmanagement | ||||||||
| 5.1 | Zielsetzung | Der Auftragnehmer stellt durch das Schwachstellenmanagement für die im Rahmen der Leistungserbringung verwendeten Informationen, IT-Anwendungen und IT-Systeme sicher, dass Schwachstellen transparent und Gegenmaßnahmen zur Ausnutzung dieser Schwachstellen zielgerichtet umgesetzt werden. | relevant | ||||||
| 5.2 | Schwachstellenmanagement | Es ist ein dokumentierter Prozess zum Management technischer Schwachstellen unter Vermeidung von Interessenkonflikten zu etablieren. Dieser muss mindestens die folgenden Aspekte umfassen: • Informationsquellen zur Identifikation relevanter technischer Schwachstellen und zur Aufrechterhaltung des entsprechenden Bewusstseins für Software und Anwendungen (z.B. Hersteller, CVE-Datenbanken). Hierbei muss mindestens die Anbindung an ein CERT erfolgen. Informationen über Schwachstellen, z. B. über Meldungen des angebundenen CERTs, müssen anhand eines dokumentierten Prozesses analysiert und bewertet werden. Dieser muss mindestens die folgenden Anforderungen erfüllen: • Angemessene Fristen zur Schließung einer Schwachstelle sind von der IT verbindlich festzulegen. Zur Behebung von technischen Schwachstellen müssen die entsprechenden Maßnahmen unter Berücksichtigung der Sicherheitsvorgabe „R.0400 - Change- und Patchmanagement“ durchgeführt werden, um Anwendungen und IT-Systeme unter Sicherheitsaspekten möglichst aktuell zu halten. Automatisierte Schwachstellenanalysen sind als grundlegende Überwachungsmaßnahmen zur Gewährleistung der Sicherheit im internen Netzwerk zu etablieren. Darüber hinaus ist ein geeignetes Verfahren zu implementieren, mit dem die sicherheitsrelevanten Systemeinstellungen der zentralen IT-Systeme gegenüber einer definierten Soll-Konfiguration überprüft werden (Health-Check). Der Soll/Ist-Abgleich muss grundsätzlich auf Basis eines automatisierten Verfahrens quartalsweise erfolgen, durch welches Abweichungen möglichst unverzüglich identifiziert werden. Server, die aus dem Internet erreichbar sind (z. B. Frontend-Server für aus dem Internet erreichbare Web-Anwendungen), sind in einem wöchentlichen Turnus zu scannen (Vulnerability-Scanning und Health-Check). | relevant | ||||||
| 5.3 | Überprüfung der Einhaltung von technischen Vorgaben im Rahmen des Schwachstellenmanagements | Penetrationstests sind ergänzend zu automatisierten Schwachstellenanalysen durchzuführen, um die etwaige Verwundbarkeit der IT-Systeme gegenüber durchgeführten Hackerangriffen und insbesondere gegen Angriffe aus dem Internet (Cyber Angriffe) feststellen und zusätzliche Härtungsmaßnahmen umsetzen zu können. Die Penetrationstests sind risikoorientiert mit einem Planungshorizont von drei Jahren vorauszuplanen. Ergebnisse von vorhergehenden Penetrationstests sind bei der Planung zu berücksichtigen. Der Testplan ist schriftlich zu fixieren und anlassbezogen, mindestens aber regelmäßig fortzuschreiben. Penetrationstests müssen durch Dienstleister oder interne Einheiten durchgeführt werden, die nicht an der Konzeption, der Entwicklung, Umsetzung oder dem operativen Management/Betrieb des Analysegegenstandes beteiligt sind. Die jeweils mit den Analysen Beauftragten müssen spätestens nach 3 Jahren gewechselt werden. Penetrationstests sind unter Berücksichtigung der Regelungen aus „R.1300 – Überprüfung der Informationssicherheit durch Fachbereiche oder Prüfer“ mindestens in folgenden Intervallen durchzuführen: • Für alle im Internet exponierten Systeme/Anwendungen gelten die Fristen gem. "R.2500 - Sicherheit in der Anwendungs- und Systementwicklung". | relevant | ||||||
| 5.3 | Überprüfung der Einhaltung von technischen Vorgaben im Rahmen des Schwachstellenmanagements | [SBK 4 - CIA]: Penetrationstests sind mindestens alle zwei Jahre unter Berücksichtigung der Sicherheitsrichtlinie „R.2500 - Sicherheit in der Anwendungs- und Systementwicklung“ durchzuführen. Die entsprechenden Nachweise sind zur Verfügung zu stellen. | relevant | ||||||
| 5.4 | ISO-Referenz Annex A | 5.7 Threat intelligence 5.10 Acceptable use of information and other associated assets 5.36 Compliance with policies, rules and standards for information security 8.8 Management of technical vulnerabilities | nicht relevant - Hinweistext | ||||||
| 6.0 | R.0600 - Security Incident Management | ||||||||
| 6.1 | Zielsetzung | Der Auftragnehmer stellt durch das Security Incident Management für die im Rahmen der Leistungserbringung verwendeten Informationen, IT-Anwendungen und IT-Systeme sicher, dass eine konsistente und wirksame Herangehensweise für die Handhabung von Informationssicherheitsvorfällen einschließlich der Benachrichtigung über Sicherheitsereignisse und Schwächen erfolgt. Für das Melden von Schwachstellen, die Meldung von Security Events sowie die Reaktion auf Security Incidents sind Prozesse einzurichten. | relevant | ||||||
| 6.2 | Umsetzung eines Security Incident Management-Prozesses | Das Security Incident Management (SIM) beschreibt eine organisierte und standardisierte Reaktion in Bezug auf einen potenziellen Verstoß gegen die Informationssicherheit. Security Incidents (Informationssicherheitsvorfälle) sind Ereignisse, die zu einer Beeinträchtigung der Schutzziele in Verbindung mit den Geschäftsprozessen und Informationen sowie den zugeordneten informationsverarbeitenden Systemen führen können oder bereits geführt haben. Das SIM hat zum Ziel, die Auswirkungen von Security Incidents zu begrenzen, zu beheben und aus diesen Vorfällen zu lernen, um diese künftig vermeiden zu können. Der Auftragnehmer muss bei der Definition des Security Incidents Management mindestens die folgenden Ausprägungen von Ereignissen: Allgemeiner Störfall, Security Event (Potenzieller Security Incident) und Security Incident berücksichtigen. • Ein Allgemeiner Störfall bezieht sich auf im Tagesbetrieb auftretende Einschränkungen, die keine Auswirkungen auf die Vertraulichkeit und Integrität von Informationen haben und die Verfügbarkeitseinschränkung von Informationen noch nicht dazu geführt hat, dass das Ausrufen eines Notfalls und das Business Continuity Management/Notfall- und Krisenmanagement initiiert werden muss. • Ein Security Event (Potenzieller Security Incident) ist ein unbewertetes Ereignis (Abweichung vom operativen Normalbetrieb), das die Verfügbarkeit, Vertraulichkeit oder Integrität von Informationen, unabhängig von der Verarbeitungsform (elektronisch oder papierhaft), beeinträchtigen könnte und den allgemeinen Störfall überschreitet. • Ein Security Incident ist ein bewertetes Ereignis, das über den Security Event hinausgeht und bei dem davon auszugehen ist, dass eine Beeinträchtigung der Verfügbarkeit (auch wenn die Bearbeitung der BCM-Organisation obliegt), der Vertraulichkeit oder der Integrität von Informationen und damit der Informationssicherheit sehr wahrscheinlich vorliegt oder eine erfolgreiche Kompromittierung bereits eingetreten ist. Im Prozess zur Behandlung von Incidents müssen Verantwortlichkeiten und Abläufe festgelegt werden, um eine schnelle, wirksame und ordnungsgemäße Reaktion auf Security Incidents sicherzustellen. Dieser muss mindestens folgende Vorgaben erfüllen: • Ein Verfahren zur Überwachung, Erkennung, Analyse, Behebung sowie zur Berichterstattung über Security Incidents und Security Events. • Ein Verfahren zur Analyse, Bewertung/situativen Neubewertung und Entscheidung der Security Incidents nach zu definierenden Kriterien und unter Berücksichtigung des Schutzbedarfs; | relevant | ||||||
| 6.3 | Bewertung von und Entscheidung über Security Events und Security Incidents | Im Prozess zur Behandlung von Incidents müssen Verantwortlichkeiten und Abläufe festgelegt werden, um eine schnelle, wirksame und ordnungsgemäße Reaktion auf Security Incidents sicherzustellen. Dieser muss mindestens folgende Vorgaben erfüllen: • Es muss definiert sein, welche Rollen und Verantwortlichkeiten zur Umsetzung des Security Incident Managements bestimmt sind. • Ein Verfahren für die Meldung von Security Incidents. • Ein Verfahren für die Planung, Vorbereitung und Durchführung von Abhilfemaßnahmen bei Vorfällen. • Ein Verfahren zur Überwachung, Erkennung, Analyse, Behebung sowie zur Berichterstattung über Security Incidents und Security Events. • Regelungen zur Initiierung forensischer Analysen sowie zur Protokollierung von Security Incidents. • Ein Verfahren zur Analyse, Bewertung/situativen Neubewertung und Entscheidung der Security Incidents nach zu definierenden Kriterien und unter Berücksichtigung des Schutzbedarfs. • Ein Reaktionsverfahren einschließlich jener zur Eskalation und kontrollierten Wiederherstellung nach einem Security Incident sowie zur Kommunikation an relevante, interne und externe Personen oder Organisationen (z. B. an die BaFin zur Meldung schwerwiegender Zahlungssicherheitsvorfälle). Ein Security Incident ist zu dokumentieren, sobald er erkannt oder vermutet wird. | relevant | ||||||
| 6.3 | Bewertung von und Entscheidung über Security Events und Security Incidents | Die Ergebnisse der Bewertung und Klassifizierung sind ausführlich zu dokumentieren, um die Nachvollziehbarkeit zu gewährleisten. | relevant | ||||||
| 6.4 | Erkenntnisse aus Security Incidents | Die aus den Security Incidents und deren Analyse gewonnene Erkenntnisse sind zu nutzen, um die Wahrscheinlichkeit des Eintretens oder die Auswirkungen zukünftiger gleichartiger Ereignisse wirksam zu verringern ("Lessons Learned") sowie eine schnelle Wiederherstellung zu ermöglichen. | relevant | ||||||
| 6.5 | Sammeln von Beweismaterial | Zur Sicherung von Beweismaterial bei der Ermittlung von Ursachen von Security Incidents muss ein dokumentierter Prozess definiert und implementiert werden. | relevant | ||||||
| 6.7 | ISO-Referenz Annex A | 5.7 Threat intelligence 5.10 Acceptable use of information and other associated assets 5.24 Information security incident management planning and preparation 5.25 Assessment and decision on information security events 5.26 Response to information security incidents 5.27 Learning from information security incidents 5.28 Collection of evidence 6.8 Information security event reporting 8.8 Management of technical vulnerabilities 8.16 Monitoring activities | nicht relevant - Hinweistext | ||||||
| 33.0 | R.1000 Geistige Eigentumsrechte | ||||||||
| 33.1 | Zielsetzung | Der Auftragnehmer stellt sicher, dass alle relevanten gesetzlichen und vertraglichen Anforderungen an Assets und das Unternehmen selbst, die nicht als Sicherheitsvorgabe aus dem ISMS hervorgehen, bestimmt, dokumentiert und eingehalten werden. Hierzu zählen der Schutz geistiger Eigentumsrechte, der Schutz von Aufzeichnungen, der Schutz personenbezogener Daten sowie die Regelungen bezüglich kryptographischer Verfahren. | relevant | ||||||
| 33.2 | Geistige Eigentumsrechte | Es sind Prozesse zu dokumentieren und zu etablieren, um die Einhaltung gesetzlicher, regulatorischer und vertraglicher Anforderungen mit Bezug auf geistige Eigentumsrechte und die Verwendung urheberrechtlich geschützter Software sicherzustellen. | relevant | ||||||
| 33.3 | Schutz von Aufzeichnungen | Aufzeichnungen (z. B. Dokumente, Sprachaufzeichnungen) sind durch angemessene Maßnahmen gegen Verlust, Zerstörung, Verfälschung, unautorisierten Zugriff und Veröffentlichung zu schützen. Dabei sind die jeweiligen nationalen Gesetze und andere vertragliche Verpflichtungen zu beachten. | relevant | ||||||
| 33.4 | Datenschutz | Es muss ein Prozess für die Umsetzung der jeweiligen nationalen Gesetze zum Schutz personenbezogener Informationen entwickelt, dokumentiert und umgesetzt werden. | relevant | ||||||
| 33.5 | Regelungen bezüglich kryptographischer Verfahren | Beim Einsatz kryptographischer Verfahren sind die jeweiligen nationalen Gesetze zu beachten, sofern Assets im Hoheitsbereich der jeweiligen Nation eingesetzt werden. Des Weiteren sind vertragliche Verpflichtungen zu beachten. Beim Einsatz von digitalen Signaturen muss ein dokumentierter Prozess zum Einsatz etabliert und umgesetzt werden. Dieser muss mindestens die folgenden Aspekte umfassen: • Es dürfen ausschließlich digitale Signaturzertifikate verwendet werden, die zentral bereitgestellt werden. • Eine Kopie des digitalen Signaturzertifikats muss zentral vorgehalten werden. • Digitale Signaturzertifikate dürfen ausschließlich zum festgelegten Anwendungszweck genutzt werden." | relevant | ||||||
| 33.6 | ISO-Referenz Annex A | 5.10 Acceptable use of information and other associated assets 5.29 Information security during disruption 5.30 ICT readiness for business continuity 8.14 Redundancy of information processing facilities | nicht relevant - Hinweistext | ||||||
| 11.0 | R.1200 - Personalsicherheit | ||||||||
| 11.1 | Zielsetzung | Der Auftragnehmer stellt durch die Personalsicherheit für die im Rahmen der Leistungserbringung verwendeten Informationen, IT-Anwendungen und IT-Systeme sicher, dass die internen und externen Beschäftigten des Auftragnehmers ihre Verantwortlichkeiten bezüglich der Informationssicherheit verstehen, diesen nachkommen und für die für sie vorgesehenen Rollen geeignet sind. Ein angemessenes Bewusstsein für Informationssicherheit muss bei Führungskräften und Mitarbeitern geschaffen und aufrechterhalten werden. Der Schutz der Interessen des Auftraggebers ist auch nach der Beendigung des Vertragsverhältnisses sichergestellt. Dabei sind sowohl die Verantwortung der Führungskräfte als auch die adäquate personelle Abdeckung für die Ausstattung der Tätigkeiten in Verbindung mit der Umsetzung der Informationssicherheitsvorgaben, insbesondere in der Informationstechnologie und Benutzer-/Berechtigungsverwaltung, zu berücksichtigen. | relevant | ||||||
| 11.2 | Personaleinstellungsprüfung | Um im Vorfeld der Einstellung Personen mit betrügerischen Absichten zu erkennen, sind Hintergrundüberprüfungen vorzunehmen. Dazu muss der Hintergrund von allen Bewerbern, die zur Einstellung vorgesehen sind, im Einvernehmen mit einschlägigen Gesetzen, Verordnungen und ethischen Grundsätzen geprüft werden. Die Hintergrundüberprüfungen müssen alle Rechtsvorschriften zum Schutz der Privatsphäre einhalten und folgende Kontrollen einschließen: • Vorhandensein von Leumundszeugnissen (z. B. geschäftsbezogene Arbeitszeugnisse). • Vollständigkeit und Richtigkeit des Lebenslaufs des Bewerbers. • Bestätigung angegebener akademischer und beruflicher Qualifikationen (z.B. Zeugniskopien, Zertifizierungen). • Unabhängige Identitätsüberprüfung (z. B. Reisepass oder ähnliches Dokument). • Überprüfung des aktuellen Führungszeugnisses. Die Kriterien und Einschränkungen zur Überprüfung von Nachweisen müssen in festen Prozessen definiert werden. Diesbezüglich ist zu regeln, wer berechtigt ist, Bewerber zu überprüfen, sowie wie, wann und warum Nachweise überprüft werden sowie wie die Prüfung dokumentiert wird. | relevant | ||||||
| 11.3 | Beschäftigungs- und Vertragsbedingungen | Die Mitarbeiter und Auftragnehmer sind auf die Einhaltung der Leitlinie zur Informationssicherheit des Unternehmens zu verpflichten, sofern die Leistungserbringung bzw. die Verarbeitung der Informationen ausschließlich innerhalb des Unternehmens (auch im Rahmen der Telearbeit) erfolgt. Mitarbeiter und Auftragnehmer sind darüber zu informieren, dass ggf. disziplinarische- bzw. strafrechtliche Maßnahmen bei vorsätzlichen oder (grob) fahrlässigen Handlungen eingeleitet werden. Alle Mitarbeiter und Auftragnehmer, die Zugang zu nicht öffentlichen Informationen erhalten, müssen eine Vertraulichkeitserklärung unterzeichnen, bevor sie Zugang zu Einrichtungen zur Informationsverarbeitung erhalten. | relevant | ||||||
| 11.4 | Schulungen zur Informationssicherheit | Mitarbeiter und Auftragnehmer sind entsprechend dem jeweiligen Bedarf zu schulen, um • an sie gestellte Informationssicherheitsanforderungen zu kennen und zu beachten; • Informationssicherheitsprobleme und -vorfälle zu erkennen und • im Einklang mit den Erfordernissen ihres Aufgabengebiets reagieren zu können. Schulungen sind bei Aufnahme der Tätigkeit, regelmäßig sowie bei Bedarf durchzuführen und zu dokumentieren. | relevant | ||||||
| 11.5 | Disziplinarprozess | Es muss ein Prozess vorhanden sein, der disziplinarische bzw. arbeitsrechtliche Maßnahmen für Mitarbeiter initiiert, die gegen Vorgaben der Informationssicherheit verstoßen haben. | relevant | ||||||
| 11.6 | Zuständigkeiten bei Beendigung oder Wechsel der Anstellung | Die vertraglich vereinbarten Vertraulichkeitserklärungen müssen auch bei internem Stellenwechsel sowie über den Zeitraum der Beschäftigung hinaus Gültigkeit besitzen. | relevant | ||||||
| 11.7 | ISO-Referenz Annex A | 5.4 Management responsibilities 5.10 Acceptable use of information and other associated assets 6.1 Screening 6.2 Terms and conditions of employment 6.3 Information security awareness, education and training 6.4 Disciplinary process 6.5 Responsibilities after termination or change of employment 8.6 Capacity management 8.12 Data leakage prevention | nicht relevant - Hinweistext | ||||||
| 15.0 | R.1700 - Informationsübertragung | ||||||||
| 15.1 | Zielsetzung | Der Auftragnehmer stellt durch die Sicherheitsvorgaben zur Informationsübertragung für die im Rahmen der Leistungserbringung verwendeten Informationen, IT-Anwendungen und IT-Systeme sicher, dass die Vertraulichkeit, Integrität und Verfügbarkeit übertragener Information, sowohl innerhalb einer Organisation als auch mit jeglicher externer Stelle, aufrechterhalten wird. Dazu sind Vorkehrungen zur Sicherheit bei der Verwendung von Cloud-Services von Dienstleistern, zur Sicherheit in der Telefonie, zur Sicherheit in Mailsystemen, zu Vereinbarungen zur wiederkehrenden technischen Informationsübertragung an Externe sowie zu Vertraulichkeits- oder Geheimhaltungsvereinbarungen zu treffen. | relevant | ||||||
| 15.2 | Policies und Prozesse zur Informationsübertragung | Die Anforderungen bei Nutzung von allen Kommunikationseinrichtungen oder der Übertragung von Informationen müssen dokumentiert sein. Folgende Angaben sind mindestens zu definieren: • Verantwortlichkeiten von Mitarbeitern und Auftragnehmern bei Übertragung unternehmenseigener Informationen; • Erlaubte Kommunikationskanäle und -einrichtungen; • Zugehörige Maßnahmen, um eine sichere Informationsübertragung zu gewährleisten. Bereitgestellte Kommunikationsmittel dürfen nur in der vorgesehenen und genehmigten Art und Weise genutzt werden. Es müssen Prozesse und Maßnahmen etabliert werden um sicherzustellen, dass bei einer Informationsübertragung kein unberechtigtes Abfangen, Kopieren, Verändern, Umleiten oder Zerstören erfolgen kann. Die Übertragung von Informationen des Auftraggebers (auch an Dritte) ist nur unter Berücksichtigung der folgenden Punkte zulässig: • Nach vorheriger Zustimmung des Auftraggebers mindestens in Textform, sofern keine aufsichtsrechtlichen oder gesetzlichen Anforderungen zur Übermittlung von Kundeninformationen bestehen (z.B. Meldungen von Security Incidents im Rahmen der KRITIS-Verordnung), • unter Nutzung abgestimmter Kommunikationsmittel und -kanäle, • nach Etablierung angemessener technischer Sicherheitsmaßnahmen. | relevant | ||||||
| 15.3 | Elektronische Informationsübertragung | [SBK 3 - CI]: Bei Übertragung von Informationen über nicht vertrauenswürdige Netze (z.B. E-Mail, Webschnittstelle, VoIP) müssen kryptographische Verfahren verwendet werden, um die Integrität und die Vertraulichkeit elektronisch übermittelter Informationen sicherzustellen. | relevant | ||||||
| 15.3 | Elektronische Informationsübertragung | [SBK 4 – CI]: Bei Übertragung von Informationen über interne Netze müssen kryptographische Verfahren verwendet werden, um die Integrität und die Vertraulichkeit elektronisch übermittelter Informationen sicherzustellen. | relevant | ||||||
| 15.4 | Sicherheit in Mail-Systemen | Für den Einsatz von Systemen für den externen E-Mail-Verkehr über das Internet, gelten folgende technisch zu unterstützende Anforderungen: • Es ist zu festzulegen, welche Dateitypen aus sicherheitsrelevanten Gründen von den Benutzern unmittelbar als Anlagen versendet / empfangen werden dürfen. Generell ist das Einspielen ausführbarer Programme in die internen Netze via E-Mail zu unterbinden. Nicht zugelassene Anhänge müssen unter Berücksichtigung der Sicherheitsvorgaben „R.2400 - Malwareschutz“ abgehängt, gelöscht oder in Quarantäne gestellt werden. In Quarantäne gestellte Anhänge dürfen erst nach Prüfung durch eine zentrale Stelle dem Empfänger nachträglich zugestellt werden, sofern die Inhalte aus betrieblichen Erfordernissen verwendet werden müssen. • Die Regeln zum Umgang der Mitarbeiter mit dem Mailsystem sind in einer Arbeitsanweisung zu dokumentieren. | relevant | ||||||
| 15.5 | Sicherheit bei der Verwendung von Cloud-Services von Dienstleistern | Stellt die Dienstleistung selbst einen Cloud-Service dar oder wird die Dienstleistung unter Verwendung eines Cloud-Service erbracht, ist vom Auftragnehmer folgendes zu gewährleisten: • Eine Systembeschreibung mit nachvollziehbaren und transparenten Angaben zum bezogenen Cloud-Dienst, die folgende Aspekte beinhaltet: - Art und Umfang der erbrachten Cloud-Dienste erfolgt gemäß Service Level Agreement (SLA) - Beschreibung der eingesetzten Infrastruktur-, System- und Netzwerkkomponenten - Rollen und Zuständigkeiten des Cloud Anbieters und des Unternehmens - Funktionen, die an Subdienstleister weiterverlagert sind - Umgang mit Vorkommnissen und Situationen, die vom Regelbetrieb abweichen, wie z. B. Ausfall von kritischen IT-Systemen. • Bei einem (kurzfristigen) Vertragsende (z.B. auch bei Insolvenz) muss sichergestellt sein, dass der Cloud-Anbieter dem Unternehmen alle in der Cloud gespeicherten Daten in einem weiterverarbeitbaren elektronischen Format (z. B. CSV, XML) zur Verfügung stellt. Der Zugriff auf den Cloud-Service muss unter Berücksichtigung der Sicherheitsvorgaben „R.2000 - Passwortmanagement und Authentisierung“ über eine starke Authentifizierung oder die Authentifizierung aus dem Unternehmensnetz (SSO) abgesichert sein. Je nach gesetzlichen Anforderungen muss der Ort der Datenspeicherung eingeschränkt werden (z. B. Cloud-Dienst in Deutschland oder der Europäischen Union). Sofern es sich nicht um Kopien von Dateien handelt, die in dem Online-Speicher abgelegt werden, muss ein Backup dieser Dateien sichergestellt werden. | relevant | ||||||
| 15.5 | Sicherheit bei der Verwendung von Cloud-Services von Dienstleistern | [SBK 3 – CI]: Die Übertragung (Transport) und Speicherung von Informationen müssen mit sicheren Verschlüsselungstechniken unter Berücksichtigung der Sicherheitsvorgaben „R.1800 - Kryptographische Verfahren“ abgesichert werden. | relevant | ||||||
| 15.5 | Sicherheit bei der Verwendung von Cloud-Services von Dienstleistern | [SBK 4 – CI]: In der Cloud gespeicherte Informationen müssen vor der Übertragung lokal mit sicheren authentifizierten Verschlüsselungstechniken abgesichert werden. Die Hoheit über das Schlüsselmaterial muss dabei immer bei dem Unternehmen verbleiben, so dass der Dienstanbieter die Daten nicht unberechtigt entschlüsseln kann. | relevant | ||||||
| 15.6 | ISO-Referenz Annex A | 5.10 Acceptable use of information and other associated assets 5.14 Information transfer 5.23 Information security for use of cloud services 6.6 Confidentiality or non-disclosure agreements 8.10 Information deletion 8.12 Data leakage prevention | nicht relevant - Hinweistext | ||||||
| 18.0 | R.2000 - Passwortmanagement und Authentisierung | ||||||||
| 18.1 | Zielsetzung | Der Auftragnehmer stellt durch das Passwortmanagement für die im Rahmen der Leistungserbringung verwendeten Informationen, IT-Anwendungen und IT-Systeme sicher, dass Informationen durch befugte Benutzer nur nach Identitätsprüfung eingesehen und verarbeitet werden können. Bei Anwendungen sind die Kennwörter getrennt von den Nutzdaten der Anwendung zu speichern | relevant | ||||||
| 18.2 | Passwortkomplexität | Bei der Verwendung von Benutzerkonten (Standardbenutzer, technische Benutzer, privilegierte Benutzer, etc.) zur Anmeldung an IT-Systeme und Anwendungen oder bei der Verschlüsselung von Dateien ist die Passwortkomplexität wie folgt auszugestalten: • Das Passwort muss mindestens 3 von 4 der Zeichentypen Großbuchstaben, Kleinbuchstaben, Ziffern und Sonderzeichen (z. B. !$%&) enthalten. • Bei der Verwendung von Passwort-Containern muss das Masterpasswort 4 von 4 Zeichentypen enthalten (Großbuchstaben, Kleinbuchstaben, Ziffern und Sonderzeichen (z. B. !$%&). • Die Mindestlänge des Passworts ist abhängig vom Typ des Benutzerkontos. Die Mindestlänge beträgt - bei Benutzerkonten von Standardbenutzern 10 Zeichen - bei Benutzerkonten technischer Benutzer 14 Zeichen und - bei Benutzerkonten von privilegierten Benutzern 12 Zeichen. • Mindestlänge des Passworts bei der Verschlüsselung von Dateien (z.B. Office-Dokumente, ZIP-Archive): 12 | relevant | ||||||
| 18.3 | Passwortübermittlung | Vorläufige (Initial-)Passwörter müssen individuell und zufällig erzeugt sowie dem Benutzer auf sichere Art und Weise übergeben werden, sodass unberechtigte Dritte keinen Zugriff auf die (Initial-)Passwörter erhalten. Es muss ein dokumentierter Prozess zur eindeutigen Identifizierung des Empfängers implementiert sein. Es ist sicherzustellen, dass die Nutzer das Initial-Passwort bei der ersten Verwendung ändern. | relevant | ||||||
| 18.4 | Passwortänderung | Passwörter sind in den folgenden Fällen zu ändern: • Standardpasswörter/Initialpasswörter von IT-Systemen und Anwendungen • Bei (Verdacht auf) Kenntnisnahme des Passwortes durch einen unberechtigten Dritten | relevant | ||||||
| 18.5 | Sperrung/Freigabe von Benutzerkonten | Benutzerkonten sind zu sperren, wenn • fünf ungültige Passworteingaben erfolgt sind, • das Benutzerkonto zur Anmeldung am Unternehmensnetz seit 90 Tagen inaktiv ist, • ein Initialpasswort für den Zugriff auf das interne Unternehmensnetzwerk innerhalb von 14 Tagen nicht verwendet wird. | relevant | ||||||
| 18.5 | Sperrung/Freigabe von Benutzerkonten | [SBK 3 – CIA]: Es muss sichergestellt sein, dass ein abgestimmtes Verfahren bzgl. der Freischaltung von gesperrten Benutzerkennungen etabliert ist, um in einem abgestimmten Zeitraum gesperrte Benutzer wieder zu entsperren. | relevant | ||||||
| 18.6 | Technische Passwortverarbeitung | Passwörter dürfen in IT-Systemen nicht im Klartext abgelegt, zwischengespeichert oder übertragen werden. | relevant | ||||||
| 18.7 | Authentisierungsmechanismus | Der Zugang zum internen Netzwerk des Unternehmens ist über einen zentralen Authentisierungsmechanismus (z.B. Benutzername und Passwort) abzusichern. | relevant | ||||||
| 18.8 | Passwortaufbewahrung | Wird ein Passwort dokumentiert ist sicherzustellen, dass das Passwort keinem Unberechtigten zur Kenntnis gelangt. Insbesondere dürfen Passwörter nicht: • an andere Personen weitergegeben werden, • elektronisch im Klartext gespeichert werden (z.B. in einem Textdokument), • auf Funktionstasten hinterlegt werden, • eingegeben werden, wenn man von Dritten beobachtet wird, • schriftlich und unverschlossen am Arbeitsplatz aufbewahrt werden. | relevant | ||||||
| 18.9 | Sichere Anmeldeverfahren | [SBK3 - CIA] Die Anmeldung an Anwendungen und IT-Systemen, die über öffentliche Netze aufrufbar sind, hat mittels einer starken Authentifizierung oder einer Authentifizierung aus dem Unternehmensnetz (SSO) zu erfolgen. | relevant | ||||||
| 18.9 | Sichere Anmeldeverfahren | [SBK 4 - CI]: Die Anmeldung an Anwendungen und IT-Systemen hat mittels starker Authentifizierung zu erfolgen, sofern die Anmeldung am Unternehmensnetzwerk nicht bereits über eine starke Authentifizierung erfolgt. | relevant | ||||||
| 18.1 | ISO-Referenz Annex A | 5.10 Acceptable use of information and other associated assets 5.17 Authentication information 8.5 Secure authentication | nicht relevant - Hinweistext | ||||||
| 19.0 | R.2100 - Systemhärtung | ||||||||
| 19.1 | Zielsetzung | Der Auftragnehmer stellt durch die Systemhärtung für die im Rahmen der Leistungserbringung verwendeten Informationen, IT-Anwendungen und IT-Systeme sicher, dass die vorhandenen Angriffsflächen durch die Grundkonfigurationen minimiert werden. | relevant | ||||||
| 19.2 | Härtung von IT-Systemen | Der Auftragnehmer stellt durch die Systemhärtung für die im Rahmen der Leistungserbringung verwendeten Informationen, IT-Anwendungen und IT-Systeme sicher, dass die vorhandenen Angriffsflächen durch die Grundkonfigurationen minimiert werden. IT-Systeme (z. B. Server, Arbeitsplatz-PCs, Mobile Endgeräte), die Informationen des Unternehmens verarbeiten oder speichern, sind vor produktiver Inbetriebnahme mindestens nach den folgenden Kriterien zu härten: • Systemeigene Sicherheitsparameter sind grundsätzlich zu aktivieren. • Sämtliche aktivierten Dienste bzw. Komponenten, sind auf ihre Notwendigkeit hin überprüft und zu deaktivieren, sofern sie für den Betrieb nicht benötigt werden (z.B. talk, uucp, finger, Windows-Installer, Telnet, FTP). • Alle nicht benötigten Softwareprogramme und –tools müssen entfernt werden. • Alle nicht benötigten Netzwerkprotokolle sind zu deaktivieren. • Alle nicht benötigten Netzwerkadapter sind zu deaktivieren. • Nach Stand der Technik unsichere Dienste müssen, durch sichere Varianten ersetzt werden (z. B. ssh statt telnet, sftp oder ftps statt ftp). • Schreibende Zugriffe der Standardbenutzer auf die Systempartitionen müssen unterbunden werden. • Berechtigungen zur Änderung sicherheitsrelevanter Einstellungen sind auf Administratorkonten zu beschränken. Die Härtungsmaßnahmen sind nachvollziehbar zu dokumentieren (z. B. pro Konfigurationstyp (Standard-Arbeitsplätze, Anwendungs-Server, Telearbeitsplätze, etc.)). | relevant | ||||||
| 19.2 | Härtung von IT-Systemen | [SBK 2 – CIA]: Ergänzend sind für die IT-Systeme folgende Härtungsmaßnahmen umzusetzen: • Alle nicht benötigten, vom Hersteller vorgegebenen Benutzer müssen entfernt werden. Sofern ein Löschen nicht möglich ist, sind diese zu deaktivieren. • Sicherheitsempfehlungen der Hersteller müssen geprüft und risikoorientiert umgesetzt werden. • Geräte mit Diagnose- und Konfigurationsports (z. B. Managementport bei aktiven Netzwerkkomponenten) sind gegen einen unberechtigten Zugang abzusichern. | relevant | ||||||
| 19.2 | Härtung von IT-Systemen | [SBK 3 – CIA]: IT-Systeme, die über einen Webservice erreichbar sind, dürfen über diesen keine Informationen über die verwendeten IT-Systeme und Softwarekomponenten geben. [SBK 3 – CIA]: Verwendete Dienste sind so zu konfigurieren, dass Zusatzinformationen, die nicht für betriebliche Zwecke erforderlich sind (z.B. über Versionsstände, Hardware, Software), nicht über die Dienste ausgelesen werden können. | relevant | ||||||
| 19.3 | ISO-Referenz Annex A | 5.10 Acceptable use of information and other associated assets 8.9 Configuration management | nicht relevant - Hinweistext | ||||||
| 22.0 | R.2400 - Malwareschutz | ||||||||
| 22.1 | Zielsetzung | Der Auftragnehmer stellt durch den Malwareschutz für die im Rahmen der Leistungserbringung verwendeten Informationen, IT-Anwendungen und IT-Systeme sicher, dass Information und informationsverarbeitende Einrichtungen vor Schadsoftware geschützt sind. | relevant | ||||||
| 22.2 | Schutz vor Schadsoftware | Alle IT-Systeme sowie Schnittstellen zu nicht vertrauenswürdigen Netzen, die einer Bedrohung durch Malware unterliegen, sind im Rahmen eines dokumentierten und strukturierten Vorgehens (z.B. Malwareschutzkonzept) durch den Einsatz von Malwarescannern abzusichern. Es ist sicherzustellen, dass IT-Systeme, die einer Bedrohung durch Malware unterliegen auf Malwarefreiheit überprüft werden. Dabei sind mindestens folgende Kriterien zu berücksichtigen: • Die Malwarescanner müssen alle transferierten Daten auf Malwarefreiheit prüfen. • Es ist sicherzustellen, dass bei jedem Benutzerzugriff auf Dateien bzw. Daten eine unmittelbare Prüfung derselben auf Malwarefreiheit stattfindet („On-Access-Scanning“). Der Malwarescanner muss die Ausführung infizierter Dateien unterbinden, sie z.B. löschen oder in Quarantäne stellen. Infizierte E-Mails bzw. Dateianhänge müssen gelöscht oder in Quarantäne gestellt werden. Wird eine Malware bei ausgehenden E-Mails identifiziert, ist dieser zu blocken. | relevant | ||||||
| 22.2 | Schutz vor Schadsoftware | [SBK4- CIA] Wird Schadsoftware auf Anwendungen oder IT-Systemen dieser Schutzbedarfsstufe identifiziert, sind auch die relevanten Datensicherungen und zugreifbare Backups auf das Vorhandensein von Schadsoftware spätestens bei der Wiederherstellung/Wiederverwendung zu überprüfen. | relevant | ||||||
| 22.3 | Systeme zum Schutz vor Schadsoftware | Systeme zum Schutz vor Malware müssen über Methoden verfügen, die grundsätzlich bekannte und bislang unbekannte Schadsoftware erkennen können (z. B. über patternbasierte und merkmalbasierte (heuristische) Erkennungstechnologien) und das unerlaubte Einbringen von ausführbaren Dateien unterbinden. Die Software zur Erkennung von Malware ist zentral und auf Basis toolgestützter Verfahren automatisiert zu aktualisieren und zu überwachen. Neue Versionen von Software zur Erkennung von Malware sind im Rahmen des Change-Managements zu installieren. Software zur Erkennung von Malware darf nicht über den definierten Software-Lifecycle des Herstellers hinaus betrieben werden. | relevant | ||||||
| 22.4 | ISO-Referenz Annex A | 5.7 Threat intelligence 5.10 Acceptable use of information and other associated assets 8.7 Protection against malware | nicht relevant - Hinweistext | ||||||
| 24.0 | R.2600 - Einsatz von Software | ||||||||
| 24.1 | Zielsetzung | Der Auftragnehmer stellt durch die Vorgaben zum Einsatz von Software für die im Rahmen der Leistungserbringung verwendeten Informationen, IT-Anwendungen und IT-Systeme sicher, dass die korrekte Funktionalität der im Unternehmen eingesetzten Software sichergestellt ist und Anforderungen an die Installation von Software auf IT-Systemen im Rahmen geregelter Prozesse definiert sind. Dies beinhaltet die Einschränkung von Softwareinstallation inkl. IDV/EUC. | relevant | ||||||
| 24.2 | Gebrauch von Hilfsprogrammen mit privilegierten Rechten | Die Verwendung von Dienst- oder Hilfsprogrammen, die in der Lage sein könnten, System- und Sicherheitsfunktionen zu umgehen, ist ausschließlich für administrative Zwecke in der IT-Organisation zulässig. Die Nutzung ist auf den berechtigten Personenkreis einzugrenzen. | relevant | ||||||
| 24.3 | Installation von Software auf Systemen im Betrieb | Bei der Installation von Software auf Systemen im produktiven Betrieb müssen mindestens die folgenden Anforderungen umgesetzt werden: • Software und Anwendungen müssen vor Installation unter Berücksichtigung der Sicherheitsvorgaben zur Anwendungsentwicklung getestet werden. • Eine Neuinstallation oder ein Update von einer Software, einer Anwendung oder einer Programm-Bibliothek darf nur durch einen geschulten Administrator vorgenommen werden. • Die Software ist so abzusichern, dass das automatisierte Ausführen oder Nachladen von Code aus nicht zugelassenen Quellen (z.B. Externes Office Dokument mit Makros) verhindert wird. | relevant | ||||||
| 24.3 | Installation von Software auf Systemen im Betrieb | [SBK 3 - CIA]: Anwendungen dieser Schutzbedarfsstufe dürfen in folgenden Umgebungen grundsätzlich nicht mit anderen Anwendungen, welche niedrigere Schutzbedarfsstufen haben, installiert und betrieben werden: • innerhalb einer virtuellen Umgebung; • bei direkter Installation auf einem physischen IT-System. Sofern dies aus z. B. wirtschaftlichen Gründen nicht sinnvoll ist, ist sicherzustellen, dass der gemeinsame Betrieb keine negativen Auswirkungen auf Anwendungen der höheren Schutzbedarfsklassen nach sich zieht. | relevant | ||||||
| 24.3 | Installation von Software auf Systemen im Betrieb | [SBK 4 - CIA]: Entwicklungen im Rahmen von IDV/EUC sind untersagt. | relevant | ||||||
| 24.4 | ISO-Referenz Annex A | 5.10 Acceptable use of information and other associated assets 8.18 Use of privileged utility programs 8.19 Installation of software on operational systems | nicht relevant - Hinweistext | ||||||
| 30.0 | R.2700 – Mobile Endgeräte | ||||||||
| 30.1 | Zielsetzung | Der Auftragnehmer stellt durch die Vorgaben den Einsatz mobiler Endgeräte für die im Rahmen der Leistungserbringung verwendeten Informationen, IT-Anwendungen und IT-Systeme sicher, dass alle relevanten Informationssicherheitsaspekte bei der Ausgabe, Nutzung und Rückgabe von mobilen Endgeräten gewährleistet werden. Dies betrifft auch die Sicherheit der auf mobilen Endgeräten gespeicherten Informationen. | relevant | ||||||
| 30.2 | Ausgabe, Nutzung und Rücknahme von mobilen Endgeräten | Die Anforderungen und Prozesse bei einer Nutzung von mobilen Endgeräten müssen dokumentiert sein. Die folgenden Regelungen sind bei der Verwendung von mobilen Endgeräten mindestens zu berücksichtigen und in Prozessen zu dokumentieren: • Der grundsätzliche betriebliche Umgang mit mobilen Endgeräten sowie der darauf gespeicherten Daten. • Der Austausch von Daten sowie die regelmäßige (verschlüsselte) Synchronisation. • Der Zugangs- und Zugriffsschutz unter Berücksichtigung der Sicherheitsvorgaben „R.0300 - Berechtigungsmanagement (Zutritt, Zugang, Zugriff)“ sowie „R.2000 - Passwortmanagement und Authentisierung“. • Die Verschlüsselung von Daten unter Berücksichtigung der Sicherheitsvorgaben „R.1800 - Kryptographische Verfahren“. • Der Malwareschutz unter Berücksichtigung der Sicherheitsvorgaben „R.2400 – Malwareschutz“. • Regelung zur Wartung (inkl. Softwareaktualisierung), Weitergabe und Verwaltung von mobilen Endgeräten unter Berücksichtigung der Sicherheitsvorgaben „R.2800 - Sicherheit von Geräten und Betriebsmitteln“ und „R.2600 - Einsatz von Software“. • Mindestens müssen die Identitäten des Nutzers und des Geräts sowie Ausgabe- und Rückgabezeitpunkte nachvollziehbar dokumentiert sein. • Die Verbindung mit Netzwerken unter Berücksichtigung der Sicherheitsvorgaben „R.2200 - Netzwerk- und Systemmanagement“. • Mobile Endgeräte sind unter Berücksichtigung der Sicherheitsvorgaben „R.2100 – Systemhärtung“ (S.21.01.01/0100) abzusichern. • Es ist sicherzustellen, dass Informationen, die auf mobile Endgeräten oder daran angeschlossene Wechselmedien gespeichert sind, bedarfsweise aus der Ferne sicher gelöscht werden können (remote wipe). • Mobile Endgeräte sind bei Feststellung eines Sicherheitsverstoßes (z.B. unerlaubter Zugriff mittels administrativer Berechtigungen (root etc.)) mindestens zu sperren, eine Verbindung mit dem unternehmensinternen Netz zu unterbinden und im Rahmen des Incident Managements zu behandeln. • Die Vernichtung von mobilen Endgeräten unter Berücksichtigung der Sicherheitsvorgaben „R.0200 - Assetmanagement“. • Grundsätzlich ist das Drucken außerhalb des Unternehmensnetzes in Verbindung mit mobilen Endgeräten nicht zulässig. Die Nutzung von privaten mobilen Endgeräten ist unter Risikogesichtspunkten zu bewerten und separat zu entscheiden. Speichermedien von mobilen Endgeräten (Notebooks, Smartphones etc.) sind unter Berücksichtigung der Sicherheitsvorgaben „R.1800 - Kryptographische Verfahren“ vollständig zu verschlüsseln. | relevant | ||||||
| 30.2 | Ausgabe, Nutzung und Rücknahme von mobilen Endgeräten | • [SBK 3 - C]: Vor Weitergabe oder Entsorgung mobiler Endgeräte ist zusätzlich durch eine zentrale Stelle sicherzustellen, dass sämtliche Daten auf dem mobilen Endgerät sicher gelöscht oder unlesbar gemacht sind. Entsprechende Nachweise sind dem Auftraggeber bei Bedarf zur Verfügung zu stellen. | relevant | ||||||
| 30.3 | Aufbewahrung und Transport von mobilen Endgeräten | Die Nutzer von mobilen Endgeräten sind unter Berücksichtigung der Sicherheitsvorgaben „R.2800 - Sicherheit von Geräten und Betriebsmitteln“ dahingehend zu verpflichten, die ihnen überlassenen Endgeräte unter Verwendung der dienstlich gelieferten Hilfsmittel (z. B. Blickschutzfolien, Zubehör zum Diebstahlschutz) sowohl innerhalb als auch außerhalb der Geschäftsräume ausreichend vor unbefugtem Zugang, Zugriff, Beschädigung und Diebstahl zu schützen. Detaillierte Ausführungen dazu müssen dokumentiert sein. Dabei sind mindestens die Punkte zu regeln: • Beaufsichtigung der mobilen Endgeräte während der Nutzungszeiten und des Transports • Aufbewahrung der mobilen Endgeräte außerhalb der Nutzungszeiten • Endgeräteschutz bei temporärer Abwesenheit (Zugangssperre, Diebstahlschutz) | relevant | ||||||
| 30.4 | Zugriffsschutz und Verschlüsselung von mobilen Endgeräten | • Der Zugriff auf Laptops, Notebooks etc. ist mindestens durch Identifizierung (z.B. Benutzername) und Authentifizierung (z.B. Passwort) zu schützen. • Der Zugriff auf Endgeräte ohne Benutzerverwaltung, wie z. B. Mobiltelefone und Smartphones ist durch eine Authentifizierung (z.B. PIN, Passwort) zu schützen. • Nach Ablauf einer definierten Zeit, ohne dass Eingaben über die Benutzerschnittstelle erfolgen, unter Berücksichtigung der Sicherheitsvorgaben „R.2800 - Sicherheit von Geräten und Betriebsmitteln“ in einen gesperrten Modus (Ruhezustand oder Stand-By mit Bildschirmsperre) wechseln, der durch eine Authentifizierung aufzuheben ist. Informationen, die auf einem mobilen Endgerät oder Datenspeicher abgelegt oder potenziell auf das Gerät übertragen werden (z. B. wenn das Gerät mit dem zentralen E-Mail-Postfach synchronisiert wird), sind unter Berücksichtigung der Sicherheitsvorgaben „R.1800 - Kryptographische Verfahren“ verschlüsselt zu speichern. | relevant | ||||||
| 30.5 | ISO-Referenz Annex A | 5.10 Acceptable use of information and other associated assets 7.9 Security of assets off-premises 8.1 User endpoint devices 8.10 Information deletion | nicht relevant - Hinweistext | ||||||
| 25.0 | R.2800 - Sicherheit von Geräten und Betriebsmitteln | ||||||||
| 25.1 | Zielsetzung | Der Auftragnehmer stellt durch die Vorgaben zur Sicherheit von Geräten und Betriebsmitteln für die im Rahmen der Leistungserbringung verwendeten Informationen, IT-Anwendungen und IT-Systeme sicher, dass der Umgang mit diesen so gestaltet ist, dass das Risiko von Verlust, Beschädigung, Diebstahl oder die Gefährdung von Informationswerten des Auftraggebers minimiert ist. Dies beinhaltet ergänzende Vorgaben zur Sicherheit von Geräten und Betriebsmitteln außerhalb des Unternehmens sowie zu Vorkehrungen für unbeaufsichtigte Benutzergeräte. | relevant | ||||||
| 25.2 | Instandhaltung von Geräten und Betriebsmitteln | Die Geräte und Betriebsmittel müssen entsprechend den empfohlenen Serviceintervallen und Spezifikationen des Herstellers gewartet werden. Anlassbezogene Fernzugriffe Externer bzw. Externer Dienstleister zu Wartungszwecken sind von innerhalb des Unternehmensnetzwerkes zu autorisieren, d.h. ein Zugriff darf nicht ohne interne Freigabe erfolgen (z.B. im Rahmen eines Change Requests). Bei betrieblich notwendigen kontinuierlichen Fernzugriffen Externer bzw. Externer Dienstleister (z.B. im Rahmen des Supports) sind diese mit dem Unternehmen abzustimmen. Fernzugänge sind technisch unter Berücksichtigung der R.2200 - Netzwerk- und Systemmanagement zu protokollieren. Die Fernadministration von Servern, PCs, Netzwerkkomponenten und vergleichbarer Ausstattung muss über sichere Verbindungen und unter Berücksichtigung der Sicherheitsvorgaben „R.1800 - Kryptographische Verfahren“ durchgeführt werden. Alle Fernzugriffe müssen eine Zwei-Faktor-Authentifizierung nutzen. | relevant | ||||||
| 25.2 | Instandhaltung von Geräten und Betriebsmitteln | [SBK 3 – CI]: Vertrauliche Informationen sind vor externer Wartung (z. B. bei Einsenden einer defekten Komponente an den Hersteller) von den Geräten und Betriebsmitteln zu entfernen. [SBK 3 – CI]: Bei Fernzugriffen sind die durchgeführten Aktivitäten des Wartungspersonals technisch zu protokollieren. | relevant | ||||||
| 25.2 | Instandhaltung von Geräten und Betriebsmitteln | [SBK 4 - CIA]: Die Protokollierung von Fernzugriffen ist auszuwerten um evtl. vorgenommene Manipulation erkennen zu können, sofern der Externe bzw. der externe Dienstleister nicht ununterbrochen bei der Durchführung der Wartungsaktivitäten überwacht wurde. | relevant | ||||||
| 25.3 | Mitnahme von Geräten, Betriebsmitteln und Dokumenten | Die Mitnahme von Geräten und Betriebsmitteln vom Unternehmensstandort ist ausschließlich für betriebliche Zwecke zugelassen. Die Mitnahme von Geräten und Betriebsmitteln, die nicht für den mobilen Einsatz vorgesehen sind, muss durch den Vorgesetzen autorisiert werden. | relevant | ||||||
| 25.3 | Mitnahme von Geräten, Betriebsmitteln und Dokumenten | [SBK 4 - CIA]: Für die Mitnahme von Dokumenten sind folgende Anforderungen zu regeln: • Die zeitlichen Grenzen für die Mitnahme sind festzusetzen und die Rückgaben auf Konformität zu überprüfen. • Die Mitnahme der Dokumente ist von der Führungskraft zu genehmigen und Rückgabe zu kontrollieren. | relevant | ||||||
| 25.4 | Sichere Entsorgung oder Weiterverwendung von Geräten und Betriebsmitteln | Alle Geräte und Betriebsmittel die Datenträger enthalten, auf denen Informationen des Auftraggebers gespeichert sind/waren, sind über einen definierten Prozess zu entsorgen. Das Löschen von Informationen auf Datenträgern muss mit geeigneten Löschtechniken erfolgen, die dem aktuellen Stand der Technik entsprechen, zertifiziert sind und das Risiko einer Wiederherstellung der Daten minimieren. | relevant | ||||||
| 25.5 | Clear Desk-Vorgabe | Die Anforderungen für eine aufgeräumte Arbeitsumgebung (Clear Desk) und Bildschirmsperren (Clear Screen) müssen dokumentiert sein. | relevant | ||||||
| 25.5 | Clear Desk-Vorgabe | [SBK 4 - C]: Streng vertrauliche Informationen sowohl auf Papier als auch in elektronischen Speichermedien sind unter Verschluss zu halten (z. B. in einem Safe oder Schrank oder anderen Sicherheitsmöbeln), wenn sie nicht benötigt werden, insbesondere dann, wenn das Büro nicht besetzt ist. | relevant | ||||||
| 25.6 | ISO-Referenz Annex A | 5.10 Acceptable use of information and other associated assets 7.7 Clear desk and clear screen 7.9 Security of assets off-premises 7.10 Storage media 7.13 Equipment maintenance 7.14 Secure disposal or re-use of equipment 8.1 User endpoint devices 8.10 Information deletion | nicht relevant - Hinweistext | ||||||
| 31.0 | R.2900 – Telearbeit | ||||||||
| 31.1 | Zielsetzung | Der Auftragnehmer stellt durch diese Richtlinie sicher, dass alle relevanten Informationssicherheitsaspekte bei der Verarbeitung von Informationen, auf die von Telearbeitsplätzen aus zugegriffen wird, gewährleistet sind. Bei der Telearbeit stellt der Auftragnehmer seinen Mitarbeiter dienstliche Hard- und Software in seinen privaten Räumlichkeiten bereit, um hierüber auf das interne Unternehmensnetz zuzugreifen und für dienstliche Zwecke zu verwenden. Die Nutzung eines Fernzugriffs (z. B. im Rahmen von Homeoffice) ist hierunter nicht zu verstehen. | relevant | ||||||
| 31.2 | Anforderungen an die Telearbeit | Für die Telearbeit sind ausschließlich dienstlich bereitgestellte Endgeräte zu verwenden. Die Kommunikationssicherheit ist unter Berücksichtigung der Notwendigkeit für Fernzugang zu unternehmensinternen Ressourcen sicherzustellen. Kommunikationssicherheit und Softwareaktualität sind zu gewährleisten. Mit den Mitarbeitern, die Telearbeit nutzen, sind mindestens Vereinbarungen zu treffen, die die physische Sicherheit des Telearbeitsplatzes gewährleisten und die Art und Ausgestaltung des Telearbeitsplatzes unter Berücksichtigung der Schutzbedarfsklassifizierung der verarbeiteten Informationen berücksichtigt. Unbefugten Dritten darf keinen Zugang zu Informationen und Ressourcen des Auftraggebers gestattet werden. | relevant | ||||||
| 31.3 | ISO-Referenz Annex A | 5.10 Acceptable use of information and other associated assets 6.7 Remote working | nicht relevant - Hinweistext |
Dokumentenmanagement
| Titel | Informationssicherheitsvorgaben bei Dienstleistungen | Unnamed: 2 |
|---|---|---|
| Betreff | Informationssicherheitsanforderungen und Gap-Analyse | |
| Dateiname | 05 - Anhang 3.1 - Anforderungskatalog - SAP-ABAKUS.xlsx | |
| Unternehmen | ||
| Autor | ||
| Vertraulichkeit | C1 öffentlich (Vorlage), C3 vertraulich (ausgefülltes Dokument) | |
| Zusammenfassung / Gegenstand / Abstract | Das Dokument stellt die Informationssicherheitsanforderungen bei Dienstleistungen in einer auswertbaren Struktur zusammen. | |
| Versionshistorie | ||
| aktuelle Version | 0.0 | Datum eintragen |
| 0.0 | Datum eintragen | Leere Vorlage |
Historie der Vorlage
| Titel | Informationssicherheitsvorgaben bei Dienstleistungen ("Redbook") | Unnamed: 2 |
|---|---|---|
| Betreff | Informationssicherheitsanforderungen und Gap-Analyse | |
| Verantwortlich | Informationssicherheit | |
| Versionshistorie | ||
| aktuelle Version | 1.9.1 | |
| 1.2 | 2019-06-28 00:00:00 | Initiale Erstellung des Dokuments auf Basis der Informationssicherheitsrichtlinien in der Version 1.2. |
| 1.3 | 2019-09-30 00:00:00 | Titel: Erweiterung des Titels auf Dienstleistungen R.0300; 3.6: Löschung des Abschnitts 3.6 „Entzug oder Anpassung von Berechtigungen“, da redundant zu 3.3 R.0500; 5.2 und 5.3: Konkretisierungen zu technischen Schwachstellen und Penetrationstests R.0600; 6.3: Konkretisierung zur Meldung von Schwachstellen R.0900; 9.2: Konkretisierung zur Aktualisierung von Prozessen R.1100; 10.2: Entfernung des konkreten Adressaten des Auftragnehmers R.1300; Zielsetzung: Konkretisierung auf die Vermeidung von Unterbrechungen des Geschäftsbetriebs durch Überprüfungen R.1500; Zielsetzung: Konkretisierung auf relevante Empfänger von Dokumentationen R.1900; Zielsetzung: Konkretisierung der Wiederherstellung von Informationen R.2100; 19.2: Entfernung einer Vorgabe zu Schnittstellen, da redundant R.2200; 20.3: Konkretisierung zur Netzwerksegmentierung R.2500; 23.7: Konkretisierung der Vorgabe zu Entwicklungstätigkeiten bei Dritten R.8000; 28.2: Entfernung einer Vorgabe zur Stromversorgung von Kommunikationsleitungen |
| 1.4 | 2020-03-31 00:00:00 | Ergänzung von Abschnitt 7.3 zur Störungserfassung, -dokumentation und -behandlung im Incidentmanagement. |
| 1.5 | 2020-09-30 00:00:00 | R.0300; 3.2: Konkretisierung der Anforderungen zur Funktionstrennung R.0500; 5.2: Ergänzung des Ziels aktuell zu haltender IT-Systeme R.0500; 5.2: Ergänzung, dass Soll/Ist-Abgleiche auch bei Inbetriebnahme durchzuführen sind R.2200; 20.2: Verallgemeinerung von "öffentliche Netze" auf "nicht vertrauenswürdige Netze" R.2300; 21.3: Konkretisierung der Protokollierung („Netzverbindungen“ statt „Netzverkehr“) R.2400; 22.2: Konkretisierung der zu schützenden Systeme |
| 1.6 | 2021-10-01 00:00:00 | Überführungen aus LBVK V. 1.6 |
| 1.7 | 2022-02-02 00:00:00 | Qualitätssicherung / Review |
| 1.8 | 2023-02-01 00:00:00 | Ergänzung der Version 1.7 um die Inhalte der Schutzbedarfsklasse 4 sowie Einbezug folgender Richtlinien: - R.1600 Dienstleister/Lieferanten - R.2700 Mobile Endgeräte - R.2900 Telearbeit R.0500; 5.2: Anpassung R.0900; 9.3: Verallgemeinerung der Begriffe "Redundanzkonzept" und "Verfügbarkeitsliste" Übernahme von Änderungen aus LBVK 1.8, damit Anpassungen in den Vorgaben 3.4, 13.2, 29.1, 29.2, 29.2, 15.4, 17.2, 18.3, 18.3, 27.1, 28.1. - Ergänzung der Bearbeitungshinweise und des Deckblatts |
| 1.9 | 2023-03-31 00:00:00 | Übernahme von Änderungen aus LBVK 1.9, damit Anpassungen in den Vorgaben 3.4, 5.3, 6.3, 9.2, 13.2, 15.2, 26.2, 27.2. Anpassung der Vorgabe 10.2 zur Informationssicherheit in Projekten. |
| 1.9.1 | 2023-09-30 00:00:00 | Übergreifende Anpassungen nach Gap-Analyse zwischen SSMK und Redbook. |