IT-Grundschutz-Kompendium Edition 2021
Dieses Dokument ist Teil der Anfrage „Sicherheit des Bürgerportals“
OPS.1.1: Kern-IT-Betrieb OPS.1.1.4 6 IT-Grundschutz-Kompendium: Stand Februar 2021
OPS.1.1.5 OPS.1.1: Kern-IT-Betrieb OPS.1.1.5: Protokollierung 1 Beschreibung 1.1 Einleitung Damit ein verlässlicher IT-Betrieb gewährleistet ist, sollten IT-Systeme und Anwendungen entweder alle oder zumin- dest ausgewählte betriebs- und sicherheitsrelevante Ereignisse protokollieren, d. h. sie automatisch speichern und für die Auswertung bereitstellen. Eine Protokollierung wird in vielen Institutionen eingesetzt, um Hard- und Soft- wareprobleme sowie Ressourcenengpässe rechtzeitig entdecken zu können. Aber auch Sicherheitsprobleme und Angriffe auf die betriebenen Netzdienste können anhand von Protokollierungsdaten nachvollzogen werden. Ebenso können mit solchen Daten durch forensische Untersuchungen Beweise gesichert werden, nachdem ein An- griff auf IT-Systeme oder Anwendungen bekannt wurde. In jedem Informationsverbund werden lokal Protokollierungsdaten von einer Vielzahl von IT-Systemen und Anwen- dungen generiert. Um jedoch einen Gesamtüberblick über einen Informationsverbund zu erhalten, können die von verschiedenen IT-Systemen und Anwendungen generierten Protokollierungsereignisse an eine dedizierte Protokol- lierungsinfrastruktur gesendet und dort zentral gespeichert werden. Nur so lassen sich die Protokollierungsdaten an einer zentralen Stelle auswählen, filtern und systematisch auswerten. 1.2 Zielsetzung Der Baustein enthält Anforderungen, die zu erfüllen sind, damit möglichst alle sicherheitsrelevanten Ereignisse pro- tokolliert werden können. Ziel ist es, alle hierfür relevanten Daten sicher zu erheben, zu speichern und geeignet für die Auswertung bereitzustellen. 1.3 Abgrenzung und Modellierung Der Baustein OPS.1.1.5 Protokollierung ist auf den Informationsverbund einmal anzuwenden. Im vorliegenden Baustein werden ausschließlich übergreifende Aspekte betrachtet, die für eine angemessene Pro- tokollierung erforderlich sind. Die Protokollierung spezifischer IT-Systeme oder Anwendungen wird hier nicht be- handelt, sondern in den jeweiligen Bausteinen des IT-Grundschutz-Kompendiums beschrieben. In vielen Betriebssystemen oder Anwendungen sind Protokollierungsfunktionen bereits vorhanden oder können dort mittels Zusatzprodukten integriert werden. Um diese Funktionen und die gespeicherten Protokollierungsdaten abzusichern, muss das zugrundeliegende Betriebssystem geschützt sein. Das ist jedoch nicht Bestandteil dieses Bausteins. Dafür sind die betriebssystemspezifischen Bausteine umzusetzen, z. B. SYS.1.2.2 Windows Server 2012. Im Vorfeld der Protokollierung von sicherheitsrelevanten Ereignissen ist es wichtig, dass Zuständigkeiten und Kom- petenzen klar definiert und zugewiesen werden. Es sollte insbesondere auf den Grundsatz der Funktionstrennung geachtet werden. Dieses Thema ist nicht Bestandteil dieses Bausteins, sondern wird im Baustein ORP.1 Organisation behandelt. Auch ist dieser Baustein abzugrenzen von der Detektion von sicherheitsrelevanten Ereignissen (siehe DER.1 Detek- tion von sicherheitsrelevanten Ereignissen) sowie der Reaktion auf Sicherheitsvorfälle (siehe DER.2.1 Behandlung von Sicherheitsvorfällen). Beide Aspekte werden im vorliegenden Baustein nicht oder nur am Rande behandelt. Ebenfalls an anderer Stelle beschrieben werden die Auswertung von Protokollierungsdaten sowie deren langfris- tige, sichere, unveränderbare und reproduzierbare Speicherung (siehe DER.1 Detektion von sicherheitsrelevanten Ereignissen bzw. OPS.1.2.2 Archivierung). Vorgaben, wie mit personenbezogenen Daten umzugehen ist, werden im Baustein CON.2 Datenschutz beschrie- ben. IT-Grundschutz-Kompendium: Stand Februar 2021 1
OPS.1.1: Kern-IT-Betrieb OPS.1.1.5 2 Gefährdungslage Folgende spezifische Bedrohungen und Schwachstellen sind für den Baustein OPS.1.1.5 Protokollierung von be- sonderer Bedeutung. 2.1 Fehlende oder unzureichende Protokollierung In einem Informationsverbund gibt es häufig IT-Systeme oder Anwendungen, bei denen die Protokollierung in der Grundeinstellung nicht aktiviert wurde. Auch können einzelne IT-Systeme oder Anwendungen manchmal gar nicht protokollieren. In beiden Fällen können wichtige Informationen verloren gehen und Angriffe nicht rechtzeitig er- kannt werden. Das ist auch dann möglich, wenn die Protokollierung bei einzelnen IT-Systemen oder Anwendungen zwar genutzt wird, aber die Protokollierungsdaten nicht an einer zentralen Stelle zusammengeführt werden. In In- formationsverbünden ohne zentrale Protokollierung lässt sich schwer sicherzustellen, dass die relevanten Protokoll- informationen aller IT-Systeme und Anwendungen erhalten bleiben und ausgewertet werden. Weiterhin müssen Protokollierungsdaten aussagekräftige Informationen enthalten. Welche Ereignisse protokolliert werden, hängt unter anderem auch vom Schutzbedarf der jeweiligen IT-Systeme oder Anwendungen ab. Wird die- ser missachtet, indem beispielsweise bei der Protokollierung nur auf Standard-Einstellungen der IT-Systeme bzw. Anwendungen zurückgegriffen wird, kann dies dazu führen, dass besonders relevante Sicherheitsereignisse nicht protokolliert werden. Somit werden Angriffe eventuell nicht erkannt. 2.2 Fehlerhafte Auswahl von relevanten Protokollierungsdaten Protokollierungsdaten liefern oft wichtige Informationen, die dabei helfen, Sicherheitsvorfälle zu erkennen. Eine besondere Herausforderung ist es, die relevanten Meldungen aus der großen Menge der verschiedenen Protokollie- rungsereignisse herauszufiltern. Denn viele Protokollierungsereignisse haben nur informativen Charakter und len- ken von den wirklich wichtigen Meldungen ab. Werden zu viele Protokollierungsereignisse ausgewählt, lässt sich die Fülle an Informationen nur schwer und mit hohem Zeitaufwand auswerten. Des Weiteren können Protokollierungsereignisse verworfen oder überschrieben werden, wenn der Arbeitsspeicher oder die Festplattenkapazität des IT-Systems bzw. der Protokollierungsinfrastruktur nicht ausreichen. Werden da- durch zu wenige oder nicht ausreichend relevante Protokollierungsereignisse aufgezeichnet, dann könnten sicher- heitskritische Vorfälle unerkannt bleiben. 2.3 Fehlende oder fehlerhafte Zeitsynchronisation bei der Protokollierung Wenn in einem Informationsverbund die Zeit nicht auf allen IT-Systemen synchronisiert wird, können die Protokol- lierungsdaten eventuell nicht miteinander korreliert werden bzw. kann die Korrelation eventuell zu fehlerhaften Aussagen führen. Grund dafür ist, dass die unterschiedlichen Zeitstempel von Ereignissen keine gemeinsame Basis aufweisen. Eine fehlende Zeitsynchronisation erschwert es somit, erhobene Protokollierungsdaten auszuwerten, insbesondere, wenn diese auf einem zentralen Logserver gespeichert werden. Weiterhin kann eine fehlerhafte oder fehlende Zeitsynchronisation dazu führen, dass die Protokollierung nicht zur Beweissicherung herangezogen wer- den kann. 2.4 Fehlplanung bei der Protokollierung Wird die Protokollierung nicht ausreichend geplant, dann kann dies dazu führen, dass IT-Systeme oder Anwendun- gen nicht überwacht und sicherheitsrelevante Ereignisse somit nicht erkannt und angemessen behandelt werden. Datenschutzverstöße könnten ebenfalls nicht nachvollzogen werden. 2.5 Vertraulichkeits- und Integritätsverlust von Protokollierungsdaten Einige IT-Systeme in einem Informationsverbund generieren Protokollierungsdaten wie Benutzernamen, IP-Adres- sen, E-Mail-Adressen und Rechnernamen, die konkreten Personen zugeordnet werden können. Solche Informatio- nen lassen sich kopieren, abhören und manipulieren, wenn sie nicht verschlüsselt übertragen und gesichert gespei- chert werden. Dies kann dazu führen, dass Angreifer auf vertrauliche Informationen zugreifen oder dass, durch manipulierte Protokollierungsdaten, Sicherheitsvorfälle bewusst verschleiert werden. Ebenso können Angreifer, wenn sie an eine größere Menge von Protokollierungsdaten gelangen, diese Informationen nutzen, um die interne Struktur des Informationsverbunds aufzudecken und dadurch ihre Angriffe gezielter ausrichten. 2 IT-Grundschutz-Kompendium: Stand Februar 2021
OPS.1.1.5 OPS.1.1: Kern-IT-Betrieb 2.6 Falsch konfigurierte Protokollierung Wenn die Protokollierung in IT-Systemen falsch konfiguriert ist, werden wichtige Informationen entweder fehler- haft oder gar nicht aufgezeichnet. Auch kann es sein, dass zu viele oder falsche Informationen protokolliert wer- den. So können z. B. personenbezogene Daten unberechtigt protokolliert und gespeichert werden. Die Institution könnte dadurch gegen gesetzliche Anforderungen verstoßen. Durch eine falsch konfigurierte Protokollierung ist es ebenso möglich, dass die Protokollierungsdaten in inkonsis- tenten oder proprietären Formaten vorliegen. Dadurch lassen sich die Protokolle eventuell nur schwer auswerten und Sicherheitsvorfälle bleiben unentdeckt. 2.7 Ausfall von Datenquellen für Protokollierungsdaten Liefern IT-Systeme in einem Informationsverbund nicht mehr die notwendigen Protokollierungsdaten, lassen sich Sicherheitsvorfälle nicht mehr angemessen detektieren. Ursache für solche Ausfälle von Datenquellen können Feh- ler in der Hard- und Software oder auch fehlerhaft administrierte IT-Systeme sein. Besonders, wenn nicht bemerkt wird, dass Datenquellen ausgefallen sind, kann dies zu einem falschen Bild der Sicherheitslage in der Institution führen. Dadurch können Angreifer z. B. sehr lange unbemerkt bleiben und institutionskritische Informationen ab- greifen oder Produktionssysteme manipulieren. 2.8 Ungenügend dimensionierte Protokollierungsinfrastruktur Aufgrund der komplexen Informationsverbünde und der vielfältigen Angriffsszenarien steigen die Anforderungen an die Protokollierung, da sehr viele Protokollierungsdaten gespeichert und verarbeitet werden müssen. Weiterhin ist es bei Sicherheitsvorfällen üblich, die Intensität der Protokollierung zu erhöhen. Ist die Protokollierungsinfra- struktur dafür jedoch nicht ausgelegt, kann es passieren, dass Protokollierungsdaten unvollständig gespeichert werden. Somit lassen sich sicherheitsrelevante Ereignisse nicht mehr oder nur unzureichend auswerten und Sicher- heitsvorfälle bleiben unentdeckt. 3 Anforderungen Im Folgenden sind die spezifischen Anforderungen des Bausteins OPS.1.1.5 Protokollierung aufgeführt. Grundsätz- lich ist der IT-Betrieb für die Erfüllung der Anforderungen zuständig. Der Informationssicherheitsbeauftragte (ISB) ist bei strategischen Entscheidungen stets einzubeziehen. Außerdem ist der ISB dafür zuständig, dass alle Anforde- rungen gemäß dem festgelegten Sicherheitskonzept erfüllt und überprüft werden. Zusätzlich kann es noch andere Rollen geben, die weitere Zuständigkeiten bei der Erfüllung von Anforderungen haben. Diese sind dann jeweils explizit in eckigen Klammern in der Überschrift der jeweiligen Anforderungen aufgeführt. Grundsätzlich zuständig IT-Betrieb Weitere Zuständigkeiten Fachverantwortliche 3.1 Basis-Anforderungen Die folgenden Anforderungen MÜSSEN für den Baustein OPS.1.1.5 Protokollierung vorrangig erfüllt werden: OPS.1.1.5.A1 Erstellung einer Sicherheitsrichtlinie für die Protokollierung [Fachverantwortliche] (B) Ausgehend von der allgemeinen Sicherheitsrichtlinie der Institution MUSS eine spezifische Sicherheitsrichtlinie für die Protokollierung erstellt werden. In dieser Sicherheitsrichtlinie MÜSSEN nachvollziehbar Anforderungen und Vor- gaben beschrieben sein, wie die Protokollierung zu planen, aufzubauen und sicher zu betreiben ist. In der spezifi- schen Sicherheitsrichtlinie MUSS geregelt werden, wie, wo und was zu protokollieren ist. Dabei SOLLTEN sich Art und Umfang der Protokollierung am Schutzbedarf der Informationen orientieren. Die spezifische Sicherheitsrichtlinie MUSS vom ISB gemeinsam mit den Fachverantwortlichen erstellt werden. Sie MUSS allen für die Protokollierung zuständigen Mitarbeitern bekannt und grundlegend für ihre Arbeit sein. Wird die spezifische Sicherheitsrichtlinie verändert oder wird von den Anforderungen abgewichen, MUSS dies mit dem ISB abgestimmt und dokumentiert werden. Es MUSS regelmäßig überprüft werden, ob die spezifische Sicherheits- richtlinie noch korrekt umgesetzt ist. Die Ergebnisse der Überprüfung MÜSSEN dokumentiert werden. IT-Grundschutz-Kompendium: Stand Februar 2021 3
OPS.1.1: Kern-IT-Betrieb OPS.1.1.5 OPS.1.1.5.A2 ENTFALLEN (B) Diese Anforderung ist entfallen. OPS.1.1.5.A3 Konfiguration der Protokollierung auf System- und Netzebene (B) Alle sicherheitsrelevanten Ereignisse von IT-Systemen und Anwendungen MÜSSEN protokolliert werden. Sofern die in der Protokollierungsrichtlinie als relevant definierten IT-Systeme und Anwendungen über eine Protokollierungs- funktion verfügen, MUSS diese benutzt werden. Wenn die Protokollierung eingerichtet wird, MÜSSEN dabei die Herstellervorgaben für die jeweiligen IT-Systeme oder Anwendungen beachtet werden. In angemessenen Intervallen MUSS stichpunktartig überprüft werden, ob die Protokollierung noch korrekt funktio- niert. Die Prüfintervalle MÜSSEN in der Protokollierungsrichtlinie definiert werden. Falls betriebs- und sicherheitsrelevante Ereignisse nicht auf einem IT-System protokolliert werden können, MÜSSEN zusätzliche IT-Systeme zur Protokollierung (z. B. von Ereignissen auf Netzebene) integriert werden. OPS.1.1.5.A4 Zeitsynchronisation der IT-Systeme (B) Die Systemzeit aller protokollierenden IT-Systeme und Anwendungen MUSS immer synchron sein. Es MUSS sicher- gestellt sein, dass das Datums- und Zeitformat der Protokolldateien einheitlich ist. OPS.1.1.5.A5 Einhaltung rechtlicher Rahmenbedingungen (B) Bei der Protokollierung MÜSSEN die Bestimmungen aus den aktuellen Gesetzen zum Bundes- sowie Landesdaten- schutz eingehalten werden (siehe CON.2 Datenschutz). Darüber hinaus MÜSSEN eventuelle Persönlichkeitsrechte bzw. Mitbestimmungsrechte der Mitarbeitervertretun- gen gewahrt werden. Ebenso MUSS sichergestellt sein, dass alle weiteren relevanten gesetzlichen Bestimmungen beachtet werden. Protokollierungsdaten MÜSSEN nach einem festgelegten Prozess gelöscht werden. Es MUSS technisch unterbun- den werden, dass Protokollierungsdaten unkontrolliert gelöscht oder verändert werden. 3.2 Standard-Anforderungen Gemeinsam mit den Basis-Anforderungen entsprechen die folgenden Anforderungen dem Stand der Technik für den Baustein OPS.1.1.5 Protokollierung. Sie SOLLTEN grundsätzlich erfüllt werden. OPS.1.1.5.A6 Aufbau einer zentralen Protokollierungsinfrastruktur (S) Vor allem in größeren Informationsverbünden SOLLTEN alle gesammelten sicherheitsrelevanten Protokollierungsda- ten an einer zentralen Stelle gespeichert werden. Dafür SOLLTE eine zentrale Protokollierungsinfrastruktur im Sinne eines Logserver-Verbunds aufgebaut und in einem hierfür eingerichteten Netzsegment platziert werden (siehe NET.1.1 Netzarchitektur und -design). Zusätzlich zu sicherheitsrelevanten Ereignissen (siehe OPS.1.1.5.A3 Konfiguration der Protokollierung auf System- und Netzebene) SOLLTE eine zentrale Protokollierungsinfrastruktur auch allgemeine Betriebsereignisse protokollie- ren, die auf einen Fehler hindeuten. Die Protokollierungsinfrastruktur SOLLTE ausreichend dimensioniert sein. Die Möglichkeit einer Skalierung im Sinne einer erweiterten Protokollierung SOLLTE berücksichtigt werden. Dafür SOLLTEN genügend technische, finanzielle und personelle Ressourcen verfügbar sein. OPS.1.1.5.A7 ENTFALLEN (S) Diese Anforderung ist entfallen. OPS.1.1.5.A8 Archivierung von Protokollierungsdaten (S) Protokollierungsdaten SOLLTEN archiviert werden. Dabei SOLLTEN die gesetzlich vorgeschriebenen Regelungen be- rücksichtigt werden. 4 IT-Grundschutz-Kompendium: Stand Februar 2021
OPS.1.1.5 OPS.1.1: Kern-IT-Betrieb OPS.1.1.5.A9 Bereitstellung von Protokollierungsdaten für die Auswertung (S) Die gesammelten Protokollierungsdaten SOLLTEN gefiltert, normalisiert, aggregiert und korreliert werden. Die so bearbeiteten Protokollierungsdaten SOLLTEN geeignet verfügbar gemacht werden, damit sie ausgewertet werden können. Damit sich die Daten automatisiert auswerten lassen, SOLLTEN die Protokollanwendungen über entsprechende Schnittstellen für die Auswertungsprogramme verfügen. Es SOLLTE sichergestellt sein, dass bei der Auswertung von Protokollierungsdaten die Sicherheitsanforderungen eingehalten werden, die in der Protokollierungsrichtlinie definiert sind. Auch wenn die Daten bereitgestellt werden, SOLLTEN betriebliche und interne Vereinbarungen berücksichtigt werden. Die Protokollierungsdaten SOLLTEN zusätzlich in unveränderter Originalform aufbewahrt werden. OPS.1.1.5.A10 Zugriffsschutz für Protokollierungsdaten (S) Es SOLLTE sichergestellt sein, dass die ausführenden Administratoren selbst keine Berechtigung haben, die aufge- zeichneten Protokollierungsdaten zu verändern oder zu löschen. 3.3 Anforderungen bei erhöhtem Schutzbedarf Im Folgenden sind für den Baustein OPS.1.1.5 Protokollierung exemplarische Vorschläge für Anforderungen aufge- führt, die über das dem Stand der Technik entsprechende Schutzniveau hinausgehen und BEI ERHÖHTEM SCHUTZ- BEDARF in Betracht gezogen werden SOLLTEN. Die konkrete Festlegung erfolgt im Rahmen einer Risikoanalyse. OPS.1.1.5.A11 Steigerung des Protokollierungsumfangs (H) Bei erhöhtem Schutzbedarf von Anwendungen oder IT-Systemen SOLLTEN grundsätzlich mehr Ereignisse protokol- liert werden, sodass sicherheitsrelevante Vorfälle möglichst lückenlos nachvollziehbar sind. Um die Protokollierungsdaten in Echtzeit auswerten zu können, SOLLTEN sie in verkürzten Zeitabständen von den protokollierenden IT-Systemen und Anwendungen zentral gespeichert werden. Die Protokollierung SOLLTE eine Auswertung über den gesamten Informationsverbund ermöglichen. Anwendungen und IT-Systeme, mit denen eine zentrale Protokollierung nicht möglich ist, SOLLTEN bei einem erhöhten Schutzbedarf NICHT eingesetzt wer- den. OPS.1.1.5.A12 Verschlüsselung der Protokollierungsdaten (H) Um Protokollierungsdaten sicher übertragen zu können, SOLLTEN sie verschlüsselt werden. Alle gespeicherten Pro- tokolle SOLLTEN digital signiert werden. Auch archivierte und außerhalb der Protokollierungsinfrastruktur gespei- cherte Protokollierungsdaten SOLLTEN immer verschlüsselt gespeichert werden. OPS.1.1.5.A13 Hochverfügbare Protokollierungsinfrastruktur (H) Eine hochverfügbare Protokollierungsinfrastruktur SOLLTE aufgebaut werden. 4 Weiterführende Informationen 4.1 Wissenswertes Das Bundesamt für Sicherheit in der Informationstechnik (BSI) regelt in seinem Mindeststandard „Mindeststandard des BSI zur Protokollierung und Detektion von Cyber-Angriffen“ die Protokollierung und Detektion von sicherheits- relevanten Ereignissen (SRE). Die International Organization for Standardization (ISO) macht in der Norm ISO/IEC 27001:2013 im Kapitel A.12.4 „Protokollierung und Überwachung“ Vorgaben zur Protokollierung. Das Information Security Forum (ISF) macht in seinem Standard „The Standard of Good Practice for Information Security“ in Kapitel TM1.2 – Security Event Logging – Vorgaben zur Protokollierung. Das National Institute of Standards and Technology (NIST) beschreibt in seiner Special Publication 800-92 „Guide to Computer Security Log Management“, wie Protokollierung sicher eingesetzt werden kann. IT-Grundschutz-Kompendium: Stand Februar 2021 5
OPS.1.1: Kern-IT-Betrieb OPS.1.1.5 5 Anlage: Kreuzreferenztabelle zu elementaren Gefährdungen Die Kreuzreferenztabelle enthält die Zuordnung von elementaren Gefährdungen zu den Anforderungen. Anhand dieser Tabelle lässt sich ermitteln, welche elementaren Gefährdungen durch welche Anforderungen abgedeckt sind. Durch die Umsetzung der aus den Anforderungen abgeleiteten Sicherheitsmaßnahmen wird den entspre- chenden elementaren Gefährdungen entgegengewirkt. Die Buchstaben in der zweiten Spalte (C = Vertraulichkeit, I = Integrität, A = Verfügbarkeit) zeigen an, welche Grundwerte der Informationssicherheit durch die Anforderung vorrangig geschützt werden. Die folgenden elementaren Gefährdungen sind für den Baustein OPS.1.1.5 Protokollierung von Bedeutung. G 0.9 Ausfall oder Störung von Kommunikationsnetzen G 0.14 Ausspähen von Informationen (Spionage) G 0.15 Abhören G 0.18 Fehlplanung oder fehlende Anpassung G 0.19 Offenlegung schützenswerter Informationen G 0.22 Manipulation von Informationen G 0.25 Ausfall von Geräten oder Systemen G 0.26 Fehlfunktion von Geräten oder Systemen G 0.27 Ressourcenmangel G 0.29 Verstoß gegen Gesetze oder Regelungen G 0.32 Missbrauch von Berechtigungen G 0.37 Abstreiten von Handlungen G 0.38 Missbrauch personenbezogener Daten G 0.40 Verhinderung von Diensten (Denial of Service) G 0.46 Integritätsverlust schützenswerter Informationen Elementare CIA- G 0.9 G 0.14 G 0.15 G 0.18 G 0.19 G 0.22 G 0.25 G 0.26 G 0.27 G 0.29 G 0.32 G 0.37 G 0.38 G 0.40 G 0.46 Gefährdungen Werte Anforderungen OPS.1.1.5.A1 X OPS.1.1.5.A2 OPS.1.1.5.A3 X X OPS.1.1.5.A4 X X OPS.1.1.5.A5 X X OPS.1.1.5.A6 X X X X X OPS.1.1.5.A7 OPS.1.1.5.A8 X OPS.1.1.5.A9 X X OPS.1.1.5.A10 X OPS.1.1.5.A11 CIA X OPS.1.1.5.A12 CI X X X X X OPS.1.1.5.A13 A X X X 6 IT-Grundschutz-Kompendium: Stand Februar 2021
OPS.1.1.6 OPS.1.1: Kern-IT-Betrieb OPS.1.1.6: Software-Tests und -Freigaben 1 Beschreibung 1.1 Einleitung Der Einsatz von IT in Institutionen setzt voraus, dass die maschinelle Datenverarbeitung soweit wie möglich fehler- frei funktioniert, da die Einzelergebnisse in den meisten Fällen nicht mehr kontrolliert werden können. Deswegen muss Software jeglicher Art schon vor Inbetriebnahme im Rahmen von Software-Tests überprüft werden. In diesen Tests muss nachgewiesen werden, dass die Software die erforderlichen Funktionen zuverlässig bereitstellt und da- rüber hinaus keine unerwünschten Nebeneffekte aufweist. Mit der anschließenden Freigabe der Software durch die fachlich zuständige Organisationseinheit wird die grundsätzliche Erlaubnis erteilt, die Software produktiv in der Institution zu nutzen. Gleichzeitig übernimmt diese Organisationseinheit damit auch die Verantwortung für das IT- Verfahren, das durch die Software unterstützt wird. Software kann an unterschiedlichen Stellen ihres Lebenszyklus getestet werden. So können Software-Tests bereits bei der Entwicklung, vor der Freigabe für den Produktivbetrieb oder im Zuge des Patch- und Änderungsmanage- ments notwendig werden. Dies betrifft sowohl Individualsoftware als auch standardisierte Software. Eine beson- dere Rolle nehmen hierbei Regressionstests ein, denn selbst wenn nur kleinere Aspekte der Software geändert wer- den, besteht die Möglichkeit, dass sich dies auf ganz andere Aspekte und Funktionen der Software auswirkt. Re- gressionstests überprüfen Software genau auf diese Auswirkungen hin. Dieser Baustein beschreibt den Test- und Freigabeprozess für jegliche Art von Software. Der Test- und Freigabepro- zess zeichnet sich dadurch aus, dass dieser je nach Ergebnis mehrmals durchlaufen werden kann. 1.2 Zielsetzung Mit der Umsetzung dieses Bausteins sorgt die Institution dafür, dass die eingesetzte Software den technischen und organisatorischen Anforderungen sowie dem vorliegenden Schutzbedarf der gesamten Institution oder einzelner Organisationseinheiten entspricht. Ein wesentlicher Teilaspekt ist dabei, dass sicherheitskritische Software auf be- stehende Schwachstellen systematisch und methodisch überprüft wird. 1.3 Abgrenzung und Modellierung Der Baustein OPS.1.1.6 Software-Tests und Freigaben ist auf den Informationsverbund einmal anzuwenden. Während der Baustein CON.8 Softwareentwicklung auf den Softwareentwicklungsprozess und die darin enthalte- nen Software-Tests, die während des Entwicklungsprozesses notwendig sind, eingeht, beschreibt dieser Baustein die speziellen Anforderungen, die an ein Test- und Freigabemanagement gestellt werden. Dabei bezieht sich dieses Test- und Freigabemanagement nicht ausschließlich auf selbst oder im Kundenauftrag entwickelte Software, son- dern auch auf das Testen und die Freigabe von jeglicher Software, wie sie in APP.6 Allgemeine Software beschrie- ben wird, sowie alle weiteren Softwareprodukten der Schicht APP Anwendungen. Software-Tests können auch Bestandteil des Patch- oder Änderungsmanagements oder der Software-Entwicklung werden. Entsprechende Anforderungen sind im Baustein OPS.1.1.3 Patch- und Änderungsmanagement sowie CON.8 Software-Entwicklung näher spezifiziert. IT-Grundschutz-Kompendium: Stand Februar 2021 1
OPS.1.1: Kern-IT-Betrieb OPS.1.1.6 2 Gefährdungslage Folgende spezifische Bedrohungen und Schwachstellen sind für den Baustein OPS.1.1.6 Software-Tests und -Frei- gaben von besonderer Bedeutung. 2.1 Software-Tests mit Produktivdaten Werden Software-Tests mit Produktivdaten durchgeführt, können hierdurch Sicherheitsprobleme entstehen. Insbe- sondere vertrauliche Produktivdaten könnten dabei von unbefugten Mitarbeitern oder Dritten eingesehen werden, die mit dem jeweiligen Software-Test beauftragt wurden. Wird mit den „originalen“ Produktivdaten getestet und nicht mit Kopien der Daten, könnten diese ungewollt geändert oder gelöscht werden. Durch Software-Tests im Produktivbetrieb könnte der gesamte Betrieb massiv gestört werden. Denn Fehlfunktionen der zu testenden Software können sich auch auf andere Anwendungen und IT-Systeme auswirken, die dadurch ebenfalls gestört werden. Hinzu kommt, dass Software-Tester bewusst die Software im Grenzbereich testen und damit beabsichtigen, mögliche Fehler aufzudecken. Dies erhöht wiederum die Gefahr, dass der gesamte Betrieb gestört wird. 2.2 Fehlendes oder unzureichendes Testverfahren Wird neue Software nicht oder nur unzureichend getestet und ohne Installationsvorschriften freigegeben, können Fehler in der Software unerkannt bleiben. Ebenso ist es möglich, dass dadurch erforderliche und einzuhaltende Installationsparameter nicht erkannt oder nicht beachtet werden. Diese Software- oder Installationsfehler, die aus einem fehlenden oder unzureichenden Software-Testverfahren re- sultieren, können den IT-Betrieb der Institution erheblich gefährden. So können beispielsweise wichtige Daten ver- loren gehen, wenn ein Update eines Datenbankmanagementsystems ohne vorherigen Test eingespielt wird. 2.3 Fehlendes oder unzureichendes Freigabeverfahren Ein fehlendes oder unzureichendes Freigabeverfahren kann dazu führen, dass Software eingesetzt wird, die von der Fachseite nicht abgenommen wurde. Auf diese Weise kann die Software Funktionen umfassen, die sie nicht enthalten sollte, oder benötigte Funktionen können fehlen. Außerdem kann die Software zu anderen Anwendun- gen inkompatibel sein. 2.4 Fehlende oder unzureichende Dokumentation der Tests und Testergebnisse Software kann in der Regel freigegeben werden, sobald alle Tests durchgeführt wurden und keine Abweichungen gefunden wurden. Sollte die Dokumentation der Software-Tests jedoch unvollständig sein, ist nachträglich nicht erkennbar, was getestet wurde. Wurden erkannte Softwarefehler oder fehlende Funktionen ungenügend doku- mentiert und damit bei der Freigabe nicht berücksichtigt, können durch diese Abweichungen die zu verarbeitenden Produktivdaten ungewollt gelöscht oder verändert werden. Außerdem können andere IT-Systeme und Anwendun- gen gestört werden. 2.5 Fehlende oder unzureichende Dokumentation der Freigabekriterien Wenn Freigabekriterien nicht klar kommuniziert werden, kann dies dazu führen, dass Software voreilig freigegeben wird oder keine Freigabe erfolgt, obwohl diese erteilt werden könnte. Dadurch könnten zum einen Versionen mit unerkannten Softwarefehlern freigegeben werden, die den Produktivbetrieb stören können. Zum anderen kann eine fehlende oder unzureichende Dokumentation der Freigabekriterien dazu führen, dass sich Projekte verzögern und dadurch finanzielle Schäden entstehen. 3 Anforderungen Im Folgenden sind die spezifischen Anforderungen des Bausteins OPS.1.1.6 Software-Tests und -Freigaben aufge- führt. Grundsätzlich ist der IT-Betrieb für die Erfüllung der Anforderungen zuständig. Der Informationssicherheits- beauftragte (ISB) ist bei strategischen Entscheidungen stets einzubeziehen. Außerdem ist der ISB dafür zuständig, dass alle Anforderungen gemäß dem festgelegten Sicherheitskonzept erfüllt und überprüft werden. Zusätzlich 2 IT-Grundschutz-Kompendium: Stand Februar 2021
OPS.1.1.6 OPS.1.1: Kern-IT-Betrieb kann es noch andere Rollen geben, die weitere Zuständigkeiten bei der Erfüllung von Anforderungen haben. Diese sind dann jeweils explizit in eckigen Klammern in der Überschrift der jeweiligen Anforderungen aufgeführt. Grundsätzlich zuständig IT-Betrieb Weitere Zuständigkeiten Datenschutzbeauftragter, Fachverantwortliche, Personalabteilung, Tester 3.1 Basis-Anforderungen Die folgenden Anforderungen MÜSSEN für den Baustein OPS.1.1.6 Software-Tests und -Freigaben vorrangig erfüllt werden: OPS.1.1.6.A1 Planung der Software-Tests (B) Die Rahmenbedingungen für Software-Tests MÜSSEN vor den Tests innerhalb der Institution entsprechend der Schutzbedarfe, Organisationseinheiten, technischen Möglichkeiten und Test-Umgebungen festlegt sein. Die Soft- ware MUSS auf Basis der Anforderungen des Anforderungskatalogs zu der Software getestet werden. Liegt auch ein Pflichtenheft vor, dann MUSS dieses zusätzlich berücksichtigt werden. Die Testfälle MÜSSEN so ausgewählt werden, sodass diese möglichst repräsentativ alle Funktionen der Software überprüfen. Zusätzlich SOLLTEN auch Negativ-Tests berücksichtigt werden, die überprüfen, ob die Software keine ungewollten Funktionen enthält. Die Testumgebung MUSS so ausgewählt werden, sodass diese möglichst repräsentativ alle in der Institution einge- setzten Gerätemodelle und Betriebssystemumgebungen abdeckt. Es SOLLTE dabei getestet werden, ob die Soft- ware mit den eingesetzten Betriebssystemen in den vorliegenden Konfigurationen kompatibel und funktionsfähig ist. OPS.1.1.6.A2 Durchführung von funktionalen Software-Tests [Tester] (B) Mit funktionalen Software-Tests MUSS die ordnungsgemäße und vollständige Funktion der Software überprüft werden. Die funktionalen Software-Tests MÜSSEN so durchgeführt werden, dass sie den Produktivbetrieb nicht be- einflussen. OPS.1.1.6.A3 Auswertung der Testergebnisse [Tester] (B) Die Ergebnisse der Software-Tests MÜSSEN ausgewertet werden. Es SOLLTE ein Soll-Ist-Vergleich mit definierten Vorgaben durchgeführt werden. Die Auswertung MUSS dokumentiert werden. OPS.1.1.6.A4 Freigabe der Software [Fachverantwortliche] (B) Die fachlich zuständige Organisationseinheit MUSS die Software freigeben, sobald die Software-Tests erfolgreich durchgeführt wurden. Die Freigabe MUSS in Form einer Freigabeerklärung dokumentiert werden. Die freigebende Organisationseinheit MUSS überprüfen, ob die Software gemäß den Anforderungen getestet wurde. Die Ergebnisse der Software-Tests MÜSSEN mit den vorher festgelegten Erwartungen übereinstimmen. Auch MUSS überprüft werden, ob die rechtlichen und organisatorischen Vorgaben eingehalten wurden. OPS.1.1.6.A5 Durchführung von Software-Tests für nicht funktionale Anforderungen [Tester] (B) Es MÜSSEN Software-Tests durchgeführt werden, die überprüfen, ob alle wesentlichen nichtfunktionalen Anforde- rungen erfüllt werden. Insbesondere MÜSSEN sicherheitsspezifische Software-Tests durchgeführt werden, wenn die Anwendung sicherheitskritische Funktionen mitbringt. Die durchgeführten Testfälle, sowie die Testergebnisse, MÜSSEN dokumentiert werden. OPS.1.1.6.A11 Verwendung von anonymisierten oder pseudonymisierten Testdaten [Datenschutzbeauftragter, Tester] (B) Wenn Produktivdaten für Software-Test verwendet werden, die schützenswerte Informationen enthalten, dann MÜSSEN diese angemessen während der Software-Tests geschützt werden. Enthalten diese Daten personenbezo- gene Informationen, dann MÜSSEN diese Daten anonymisiert werden. Wenn ein Personenbezug von den Testda- ten abgeleitet werden könnte, MUSS der Datenschutzbeauftragte und unter Umständen die Personalvertretung hinzugezogen werden. IT-Grundschutz-Kompendium: Stand Februar 2021 3
