====== Sicherheitskonzept ====== ++++ Dokumentation im Sicherheitsprozess | Zur Erstellung des Sicherheitskonzepts gibt {[BSI2001]}, S. 32ff. folgende Schritte vor: * Klassifikation von Informationen * Informationsfluss im Informationssicherheitsprozess * Auswahl einer Methode zur Risikoanalyse * Klassifikation von Risiken bzw. Schäden * Risikoanalyse * Entwicklung einer Strategie zur Behandlung von Risiken * Auswahl von Sicherheitsmaßnahmen ++++ {{ :komponenten:sicherheitskonzept:sicherheitskonzept.svg |}} ===== Klassifikation von Informationen ===== ++++ Hintergrund: Klassifikation von Informationen | Die im Unternehmen verfügbaren und verarbeiteten Informationen lassen sich nach Vertraulichkeit, Verfügbarkeit und Integrität bewerten (siehe {[BSI2002]}, S. 52: * Die **Vertraulichkeit** wird in der Praxis oft abgestuft zwischen: offen, intern, vertraulich und streng vertraulich * Bei der **Verfügbarkeit** wird die tolerierbare Zeit zur Wiederherstellung bewertet: z.B. eine Stunde, ein Tag, eine Woche, ein Monat * Bei der **Integrität** kann bspw. unterschieden werden in: essenziell, wichtig und normal ++++ Im Unternehmen klassifizieren wir Informationen wie folgt: * Vertraulichkeit: FIXME offen, intern, vertraulich und streng vertraulich * Verfügbarkeit: FIXME eine Stunde, ein Tag, eine Woche, ein Monat * Integrität: FIXME essenziell, wichtig und normal Im Unternehmen erstellte Dokumente werden immer in der Fußzeile bzgl. ihrer Vertraulichkeit gekennzeichnet. Für die Speicherung und Weitergabe von Dokumenten entsprechend der Vertraulichkeitsklassifikation wird wie folgt definiert: * Stufe "offen": FIXME Dokumente dieses Bereiches dürfen auch veröffentlicht werden, eine Weitergabe ist daher problemlos möglich. Für die Ablage werden keine Vorgaben gemacht. * Stufe "intern": FIXME Interne Dokumente dürfen nicht veröffentlicht werden. Eine Ablage in nicht zum Unternehmen gehörenden Cloud-Speicherdiensten ist nicht erlaubt. Die unternehmensinterne Dateiablage muss nicht zugriffsgeschützt erfolgen, da sie von allen Mitarbeitenden eingesehen werden kann. Interne Dokumente dürfen nicht an Externe weiter gegeben werden, es sei denn hierfür wurden spezielle Vereinbarungen getroffen. Diese Vereinbarungen sind im Vorfeld mit dem ISB abzustimmen und dürfen dann nur entsprechend der Vereinbarungen weiter gegeben werden. * Stufe "vertraulich": FIXME Vertrauliche Informationen haben einen begrenzten Adressatenkreis. Dies können bspw. ein Projektteam, eine Abteilung oder einzelne Personen sein. Die Vertraulichkeit ist entsprechend des Adressatenkreises einzuhalten. Dies betrifft sowohl die Weitergabe von Informationen als auch die Speicherung von Dateien. Bei der Speicherung der Dateien ist sicherzustellen, dass nur der Adressatenkreis auf diese Informationen Zugriff hat. Dies ist durch entsprechende Berechtigungskonzepte in den jeweiligen Anwendungen sicherzustellen. * Stufe "streng vertraulich": FIXME Bei dieser Stufe sind zusätzliche Sicherheitsmaßnahmen zu treffen. So ist bspw. eine Speicherung streng vertraulicher Daten auf lokalen Geräten (Laptop etc.) nur dann gestattet, wenn eine Festplattenverschlüsselung aktiviert ist. Eine Weitergabe innerhalb des vorab zu definierenden Adressatenkreises ist nur über signierte/verschlüsselte Mails und Datenspeicherorte zu realisieren. ===== Informationsfluss im Informationssicherheitsprozess ===== Der Informationsfluss im Informationssicherheitsprozess umfasst nach {[BSI2002]}, S. 54 ff. die folgenden Punkte: * Berichte an die Leitungsebene * Technische Dokumentation und Dokumentation von Arbeitsabläufen * Anleitungen für Mitarbeiter * Gesetze und Regelungen * Informationsfluss und Meldewege ==== Berichte an die Leitungsebene ==== Die Leitungsebene ist generell für die ordnungsgemäße und sichere Aufgabenerfüllung verantwortlich, auch wenn einzelne Aufgaben delegiert werden können. Die Gesamtverantwortung für die Informationssicherheit verbleibt bei der Leitungsebene. In unserem Unternehmen ist das FIXME. Um diese Verantwortung übernehmen zu können sind regelmäßige Berichte an die Leitungsebene notwendig. FIXME Jeweils zum Jahresende wird daher ein Statusbericht für die Umsetzung des Informationssicherheitskonzeptes durch den ISB vorgelegt. Für den Bericht wird in unserem Unternehmen folgende Gliederung mit nachfolgenden inhaltlichen Erläuterungen festgelegt: - Management Summary * Umfang max. 1 Seite - Überblick über sicherheitrelevante Vorfälle und abgeleiteter Maßnahmen * tabellarische Auflistung aller Vorfälle inkl. Bewertung des Schadens * Darstellung der Wirksamkeit der abgeleiteten Maßnahmen - Überblick über den aktuellen Umsetzungsstand * Grafische Auflistung der Komponenten des ISMS mit Ampeldarstellung (grün = umgesetzt/laufend, gelb = in Umsetzung, rot = bisher ungeplant/keine Aktivitäten) * textuelle Beschreibung zum aktuellen Stand - Fokus der Aktivitäten im laufenden Jahr * welche Maßnahmen wurden geplant * wie ist der Umsetzungsstand - Fokus der geplanten Aktivitäten * welche Maßnahmen wurden für das kommende Jahr priorisiert * inkl. Kosten-/Aufwandsabschätzung Die Leitungsebene hat darüber hinaus jederzeit die Möglichkeit sich in diesem Wiki über den aktuellen Umsetzungsstand zu informieren. Daher werden alle Aktivitäten die Informationssicherheit betreffend hier transparent und zeitnah dokumentiert. Bei kritischen Vorfällen die Informationssicherheit betreffend ist die Leitungsebene unverzüglich durch den ISB inkl. einer Einschätzung zu informieren. FIXME Die Kritikalität eines Vorfalls wird entsprechend der Risikobewertung für die Stufe "mittel" und darüber hinaus gehend festgelegt. Handelt es sich um ein Risiko der Stufe "klein" so kann - sofern keine Mittelfreigabe durch die Leitungsebene - zunächst mit der Einleitung von Maßnahmen durch den ISB begonnen werden. Die Leitungsebene kann dann im Nachgang der Erledigung informiert werden. Vorfälle die Informationssicherheit betreffend sind von den involvierten Mitarbeitenden unverzüglich telefonisch an die IT-Abteilung und den ISB zu melden. Der ISB entscheidet zusammen mit der IT über die notwendigen Schritte. Betroffene Mitarbeitende melden den Vorfall zusätzlich über unser FIXME Meldeformular, der ISB ergänzt anschließend die Dokumentation mit eingeleiteten Maßnahmen. ==== Technische Dokumentation und Dokumentation von Arbeitsabläufen ==== ++++ Hintergrundinfos zur Technischen Dokumentation inkl. Arbeitsabläufen | Die technische Dokumentation inkl. Arbeitsabläufen richtet sich an die Zielgruppe der mit IT-Sicherheit befassten Experten im Unternehmen, also den ISB und die IT-Abteilung. Nach {[BSI2002]}, S. 56 gehören dazu die nachfolgenden Punkte: * Installations- und Konfigurationsanleitungen * Anleitungen für den Wiederanlauf nach einem Sicherheitsvorfall * Dokumentation von Test- und Freigabeverfahren * Anweisungen für das Verhalten bei Störungen und Sicherheitsvorfällen ++++ Nachfolgend ist aufgelistet, welche Dokumentationen in unserem Unternehmen dazu gehören und wie der aktuelle Umsetzungsstand hierzu aussieht. Die eigentliche Dokumentation erfolgt unterhalb des Bereiches [[..:prozesse:start|Prozesse & Abläufe]] und ist in nachfolgender Tabelle direkt verlinkt. ^ Kategorie ^ Prozesse/Dokumentation ^ Umsetzungsstand ^ | Installations- und Konfigurationsanleitungen Anleitungen für den Wiederanlauf nach einem Sicherheitsvorfall | Hardwarespezifische Installationsanleitungen (inkl. Netzwerkkomponenten) werden in der Bestandsaufnahme zur jeweiligen [[bestand:hardware:start|Hardware]] beschrieben. | offen | | ::: | Installationsanleitungen für die jeweilige Software wird in der Bestandsaufnahme zur jeweiligen [[bestand:software:start|Software]] beschrieben. | offen | | ::: | Installationsanleitungen für die verschiedene Zertifikate sind in der Bestandsaufnahme zumvjeweiligen [[bestand:zertifikate:start|Zertifikate]] beschrieben. | offen | | ::: | Die Anleitung zur Wiederherstellung des Betriebs nach einem Zwischenfall sind übergreifender Natur und ergänzen die spezifischen Anleitungen für Hard- und Software, Zertifikate und Netzwerkkomponenten und geben vor allem eine priorisierte Reihenfolge bei einem größeren Zwischenfall vor. | offen | | Dokumentation von Test- und Freigabeverfahren | Hier wird beschrieben, wie wir im Unternehmen generell mit dem Testen neuer Hard- und Software oder Netzwerkkomponenten umgehen, bevor diese in den Live-Betrieb überführt werden. | offen | | Anweisungen für das Verhalten bei Störungen und Sicherheitsvorfällen | Eine allgemeine Verhaltensrichtlinie dokumentiert den Prozess bei Störungen im IT-Ablauf oder bei Sicherheitsvorfällen. | offen | ==== Anleitungen für Mitarbeiter ==== Im Bereich [[..:prozesse:start|Prozesse &Abläufe]] sind für die Zielgruppe der Mitarbeitenden folgende Punkte * [[..:prozesse:arbeitsablaeufe-ma|Arbeitsabläufe und organisatorische Vorgaben]] mit Bezug zur Informationssicherheit * [[..:prozesse:sicherheitsvorfälle|Verhalten bei Sicherheitsvorfällen]] * unter [[..:regeln:start|]] sind darüber hinaus allgemeingültige Richtlinien zusammengestellt ==== Gesetze und Regelungen ==== Für den Bereich "Informations- und IT-Sicherheit" sind verschiedene Gesetzte und Regularien gültig. Nachfolgend sind diese aufgelistet und hinsichtlich ihrer Relevanz für unser Unternehmen bewertet. === Zentrale EU-Vorgaben === * [[https://dejure.org/gesetze/DSGVO|Datenschutz‑Grundverordnung (DSGVO)]]: Regelt Schutz personenbezogener Daten; Art. 32 verlangt „geeignete technische und organisatorische Maßnahmen“ (TOM) wie Verschlüsselung, Sicherstellung von Vertraulichkeit, Integrität, Verfügbarkeit und Verfahren zur regelmäßigen Wirksamkeitsprüfung. => die DSGVO ist vollumfänglich relevant und wird im Unternehmen durch eine [[..:regeln:datenschutzrichtlinie|Datenschutzrichtlinie]] umgesetzt * [[https://eur-lex.europa.eu/legal-content/DE/TXT/?uri=CELEX:32022L2555|NIS2-Richtlinie]] / [[https://www.recht.bund.de/bgbl/1/2025/301/VO.html|NIS2‑Umsetzungsgesetz]]: Weitet die Sicherheits‑ und Meldepflichten für „wesentliche“ und „wichtige“ Einrichtungen in vielen Sektoren (u.a. Energie, Gesundheit, digitale Dienste, Verkehr, Produktion) aus; beinhaltet Vorgaben zu Risikomanagement, Incident‑Handling, Business Continuity, Supply‑Chain‑Security und Meldefristen. => für unser Unternehmen ist NIS2 nicht anzuwenden ​ === Nationale Gesetze Deutschland === * BSI‑Gesetz (BSIG) und IT‑Sicherheitsgesetz / [[https://www.bgbl.de/xaver/bgbl/start.xav?startbk=Bundesanzeiger_BGBl&jumpTo=bgbl121s1122.pdf#__bgbl__%2F%2F*%5B%40attr_id%3D%27bgbl121s1122.pdf%27%5D__1724678641788|IT‑Sicherheitsgesetz 2.0 (IT‑SiG 2.0)]]: Bilden den Kern der gesetzlichen Anforderungen an IT‑Sicherheit, insbesondere für Betreiber Kritischer Infrastrukturen (KRITIS) und bestimmte Unternehmen im besonderen öffentlichen Interesse (UBI). => ist für unser Unternehmen nicht relevant * [[https://www.gesetze-im-internet.de/bsi-kritisv/|KRITIS‑Verordnung]]: Präzisiert, welche Betreiber und Anlagen als Kritische Infrastrukturen gelten und damit direkt an die strengeren Pflichten aus BSIG/IT‑SiG 2.0 gebunden sind. => ist für unser Unternehmen nicht relevant * [[https://www.bmi.bund.de/DE/themen/verfassung/datenschutz/bundesdatenschutzgesetz/bundesdatenschutzgesetz-node.html|Bundesdatenschutzgesetz (BDSG)]]: Ergänzt und konkretisiert die DSGVO in Deutschland, insbesondere für öffentliche Stellen, Beschäftigtendaten und Aufsichtsbefugnisse. => ist vollumfänglich relevant und wird im Unternehmen durch eine [[..:regeln:datenschutzrichtlinie|Datenschutzrichtlinie]] umgesetzt * [[https://www.gesetze-im-internet.de/ddg/BJNR0950B0024.html|Digitale‑Dienste‑Gesetz]] (DDG, Nachfolger des TMG): Regelt u.a. Pflichten von Online‑Diensten und Plattformen (Transparenz, Nutzer‑Information, Umgang mit rechtswidrigen Inhalten), was indirekt auch Anforderungen an Sicherheits‑ und Meldeprozesse betrifft. => ist hinsichtlich der Gestaltung eines Impressums für digitale Dienste (Webseite, Social Media Kanäle) für unser Unternehmen relevant ​ === Relevante Normen und Best Practices === * nicht gesetzlich, aber faktisch Pflichtmaßstab * [[https://www.dinmedia.de/de/norm/din-en-iso-iec-27001/370680635|ISO/IEC 27001]] ff.: Internationaler Standard für Informationssicherheits‑Managementsysteme (ISMS); wird von Aufsichtsbehörden und Gerichten oft als Maßstab für „angemessen“ bzw. „Stand der Technik“ herangezogen. * BSI‑Grundschutz (IT‑Grundschutz‑Kompendium): Deutsches Referenzwerk des BSI, das konkrete Maßnahmen‑Bausteine für systematische Informationssicherheit beschreibt und gerade im öffentlichen Bereich und bei KRITIS als Referenz genutzt wird. * Branchenspezifische Normen (z.B. IEC 62443 für OT/Industrieanlagen): Werden im Umfeld von KRITIS, Industrie 4.0 und OT‑Security als Stand der Technik angesehen. ​ ==== Informationsfluss und Meldewege ==== In unserem Unternehmen arbeiten der ISB und die IT-Abteilung Hand in Hand. In quartalsweise anberaumten Abstimmungsterminen werden aktuelle Themen der Informationssicherheit erörtert und die Umsetzung von beschlossenen Maßnahmen vorangetrieben. Einmal jährlich (im letzten Quartal) erfolgt eine Neubewertung des aktuellen Umsetzungsstands und die Erstellung des Berichtes für die Leitungsebene. Dieser wird nach Fertigstellung an die Leitungsebene übergeben. Die im Bericht festgehaltenen und budgetierten Maßnahmen werden von der Leitungsebene - ggf. nach Rücksprache - freigegeben und in der Budgetplanung für das folgende Jahr verankert. Im ersten Quartal findet die gemeinsame Sitzung zwischen Leitungsebene, ISB und IT-Abteilung statt, in der sowohl der Bericht aus dem Vorjahr besprochen wird als auch eine Priorisierung für das laufende Jahr für die angedachten Maßnahmen abgestimmt wird. Die Mitarbeitenden werden im Rahmen der jährlichen Arbeitsschutzunterweisung auch für die aktuellen Themen der Informationssicherheit sensibilisiert. Die Verantwortung für die Durchführung der Schulung obliegt dem ISB. Bei auftretenden IT-Sicherheitsvorfällen und/oder Datenschutzverletzungen ist eine sofortige Meldung an den ISB und das IT-Team festgelegt. Dieser ist unter FIXME beschrieben. Darin ist auch der Information der Leitungsebene geregelt. Aus aufgetretenen Vorfällen abzuleitende externe Meldungen bei Behörden sind im Prozess FIXME XYZ geregelt. ===== Methode zur Risikoanalyse ===== ++++ Hintergrund Methoden zur Risikoanalyse | Das Informationssicherheitsmanagement muss eine Methode zur Risikoanalyse auswählen, die für die Art und Größe des Unternehmens angemessen ist. Verschiedene Methoden zur Risikobeurteilung sind in den Standards [[https://www.vde-verlag.de/normen/0090101/din-en-iec-31010-vde-0050-1-2024-12.html|ISO/IEC 31010]] und [[https://www.dinmedia.de/de/norm/din-en-iso-iec-27005/382852970|ISO/IEC 27005]] beschrieben. Das BSI hat ein zweistufige Vorgehensweise nach IT-Grundschutz entwickelt {[BSI2003]}. ++++ Unser Unternehmen hat sich zunächst nur für eine Basis-Absicherung entschieden, für die eine Risikoanalyse noch nicht vorgesehen ist. Vorausschauend für eine zukünftig angestrebte Standard-Absicherung wurde jedoch für unser Unternehmen die vom BSI entwickelte Vorgehensweise nach IT-Grundschutz {[BSI2003]} ausgewählt. ===== Klassifikation von Risiken bzw. Schäden ===== Für unsere Risikoklassifizierung wurden im Unternehmen die nachfolgenden Dimensionen ausgewählt und die Ausprägungen definiert. * Eintrittswahrscheinlichkeit: * selten: maximal alle 5 Jahre * mittel: alle 5 Jahre bis jährlich * häufig: jährlich bis monatlich * sehr häufig: mehrmals im Monat * Potenzielle Schadenshöhe: * vernachlässigbar: geringe Schäden * begrenzt: überschaubarer Schaden * beträchtlich: sehr umfangreicher Schaden (z.B. finanziell >20.000 Euro, Reputationsverlust, Stillstand mehrere Tage) * existenzbedrohend: katastrophales Ausmaß für das Unternehmen (z.B. finanziell >200.000 Euro, Stillstand mehrere Wochen) * Aus der Kombination von Eintrittswahrscheinlichkeit und Schadenshöhe lässt sich anschließend eine Risikokategorie mit folgenden Ausprägungen ableiten: * gering: bestehende/definierte Sicherheitsmaßnahmen bieten ausreichenden Schutz oder Aufwand-Risiko-Abschätzung unwirtschaftlich * mittel: bestehende/definierte Sicherheitsmaßnahmen reichen möglicherweise nicht aus * hoch: bestehende/definierte Sicherheitsmaßnahmen bieten keinen ausreichenden Schutz * sehr hoch: bestehende/definierte Sicherheitsmaßnahmen bieten keinen ausreichenden Schutz oder sind noch gar nicht geplant {{ :komponenten:sicherheitskonzept:risikomatrix.svg |}} Matrix zur Einstufung von Risiken nach {[BSI2003]}, S. 27 ===== Risikoanalyse ===== Eine Risikoanalyse ist erst ab Standard-Absicherung relevant. Vorausschauend zur künftigen Erreichung einer Standard-Absicherung wurden für die Risikoanalyse die nachfolgenden Punkte bereits definiert. Die Risikoanalyse wird einmal jährlich durchgeführt und ggf. nach erneuter Einschätzung aktualisiert. Innerhalb der Risikoanalyse ab Standard-Absicherung folgen wir dem vom BSI vorgeschlagenen Schritten ({[BSI2002]}, S. 34): * Identifikation zu schützender Informationen und Prozesse * Ermittlung aller relevanten Bedrohungen für diese * Analyse von bedrohten Schwachstellen * Benennung und Einschätzung der möglichen Schäden * Untersuchung der potenziellen Auswirkungen auf die Geschäftstätigkeit * Bewertung des Risikos Die eigentliche Risikoanalyse findet sich im Wiki unter [[..:risikobewertung:start|]]. ===== Entwicklung einer Strategie zur Behandlung von Risiken ===== :FIXME: ===== Auswahl von Sicherheitsmaßnahmen ===== :FIXME: