IT-Grundschutz-Kompendium – Februar 2020
Dieses Dokument ist Teil der Anfrage „Sicherheit des Bürgerportals“
CON: Konzepte und Vorgehensweisen CON.3 Elementare CIA- G 0.1 G 0.2 G 0.18 G 0.19 G 0.22 G 0.29 G 0.45 G 0.46 Gefährdungen Werte Anforderungen CON.3.A1 X X CON.3.A2 X CON.3.A3 CON.3.A4 X CON.3.A5 X X X CON.3.A6 X CON.3.A7 X CON.3.A8 CON.3.A9 X X X CON.3.A10 X X CON.3.A11 X X CON.3.A12 X X X X X CON.3.A13 CIA X X X X 6 IT-Grundschutz-Kompendium: Stand Februar 2020
CON.4 CON: Konzepte und Vorgehensweisen CON.4: Auswahl und Einsatz von Standardsoftware 1 Beschreibung 1.1 Einleitung Unter Standardsoftware wird Software verstanden, die auf dem Markt angeboten und in der Regel über den Fach- handel oder Onlineportale bezogen wird. Sie zeichnet sich dadurch aus, dass Institutionen sie selbst installieren und mit wenig Aufwand anpassen können. Hierbei muss auch die Informationssicherheit über den gesamten Lebenszyklus der Standardsoftware von der Pla- nung bis zur Aussonderung hinweg berücksichtigt werden. So müssen Institutionen einen Anforderungskatalog für Standardsoftware erstellen, ein geeignetes Produkt auswählen und es sicher installieren. Außerdem müssen sie die Lizenzen geeignet verwalten und das Produkt auch wieder sicher deinstallieren können. 1.2 Zielsetzung Der Baustein zeigt systematisch auf, welche Schutzmaßnahmen zu ergreifen sind, damit Standardsoftware auf si- chere Art geplant, beschafft, betrieben und ausgesondert werden kann. Übergeordnetes Ziel ist dabei, die mit der Standardsoftware verarbeiteten Informationen zu schützen. 1.3 Abgrenzung und Modellierung Der Baustein CON.4 Auswahl und Einsatz von Standardsoftware ist für den gesamten Informationsverbund einmal anzuwenden, wenn Standardsoftware beschafft, deren Betrieb geregelt und diese ausgesondert werden soll. Dieser Baustein befasst sich ausschließlich mit standardisierten Programmen, die von Anwendern selbstständig, ohne Unterstützung durch den Hersteller oder externe Dienstleister eingesetzt und angepasst werden können. Der vorliegende Baustein geht nicht auf Software-Tests und -Freigaben ein. Anforderungen dazu sind im Baustein OPS.1.1.6 Software-Tests und -Freigaben aufgeführt. Auch die Softwareentwicklung wird nicht thematisiert. Dazu sollten die Anforderungen des Bausteins CON.8 Softwareentwicklung gesondert berücksichtigt werden. 2 Gefährdungslage Folgende spezifische Bedrohungen und Schwachstellen sind für den Baustein CON.4 Auswahl und Einsatz von Standardsoftware von besonderer Bedeutung: 2.1 Fehlende Anpassung der Standardsoftware an den Bedarf der Institution Wenn eingekaufte Standardsoftware nicht an die Anforderungen der Institution angepasst wird, kann der interne Betrieb erheblich gestört werden. Es könnte z. B. sein, dass Formate nicht mit bereits eingesetzten Programmen kompatibel sind oder neue Produkte einen zu geringen Funktionsumfang haben. Das kann zu Leistungsverlusten, Störungen oder Fehlern innerhalb der Geschäftsprozesse führen. 2.2 Offenlegung schützenswerter Informationen durch fehlerhafte Konfiguration Ist eine Standardsoftware fehlerhaft konfiguriert, können unbeabsichtigt schützenswerte Informationen offenge- legt werden, z. B. wenn nicht benötigte Funktionen noch aktiviert sind. Das kann zu finanziellen Einbußen führen oder dazu, dass die Reputation einer Institution geschädigt wird. Zusätzlich könnte die Institution auch gegen gel- tendes Recht verstoßen, z. B. wenn personenbezogene Daten offengelegt werden. IT-Grundschutz-Kompendium: Stand Februar 2020 1
CON: Konzepte und Vorgehensweisen CON.4 2.3 Bezug von Standardsoftware und Updates aus unzuverlässiger Quelle Werden Standardsoftware oder zugehörige Updates aus unzuverlässigen Quellen bezogen, kann die Integrität und Funktionalität der Software nicht sichergestellt werden. Dies gilt auch für Erweiterungen wie Plug-ins oder Add- ons. Wird kompromittierte Software installiert, kann Schadcode in der Institution verteilt werden. Außerdem ist es möglich, dass die Software nicht wie vorgesehen funktioniert. Darüber hinaus kann die Integrität und Verfügbar- keit von IT-Systemen beeinträchtigt werden. 2.4 Software-Schwachstellen in Standardsoftware Trotz intensiver Tests werden meist nicht alle Schwachstellen und Fehler in Standardsoftware entdeckt, bevor sie an die Kunden ausgeliefert wird. Werden diese Schwachstellen und Fehler nicht rechtzeitig erkannt, können daraus resultierende Abstürze oder Fehler weitreichende Folgen haben. Darüber hinaus können die Vertraulichkeit und die Integrität der gespeicherten Daten und die Verfügbarkeit betroffener IT-Systeme beeinträchtigt werden. Durch Software-Schwachstellen bzw. -Fehler können außerdem schwerwiegende Sicherheitslücken in der Standardsoft- ware auftreten. Diese können unter Umständen von Angreifern ausgenutzt werden, um Schadcode einzuschleu- sen. 2.5 Einsatz nicht-lizenzierter Standardsoftware Wird Standardsoftware ohne gültige Software-Lizenz eingesetzt, weil beispielsweise unbemerkt zu viele Lizenzen vergeben wurden, kann das Vertragsstrafen zur Folge haben. Umgekehrt werden möglicherweise zu hohe Lizenz- kosten entrichtet, wenn Standardsoftware an Arbeitsplätzen installiert ist, an denen sie nicht benötigt wird. 2.6 Unerlaubtes Ausüben von Rechten in Standardsoftware Zutritts-, Zugangs- und Zugriffsrechte werden als organisatorische Maßnahmen eingesetzt, um Informationen, Ge- schäftsprozesse und IT-Systeme vor unbefugtem Zugriff zu schützen. Können unautorisierte Personen Standard- software oder bestimmte Funktionen benutzen, kann das die Vertraulichkeit und Integrität der Informationen ge- fährden, indem diese verändert, gelöscht oder unsachgemäß erstellt werden. Solche Sicherheitslücken entstehen beispielsweise durch fehlerhafte Rechtevergaben. Betroffene Geschäftsprozesse können so korrumpiert werden. Außerdem können unbeabsichtigt fehlerhafte Informationen verarbeitet oder schützenswerte Informationen of- fengelegt werden. 2.7 Datenverlust durch fehlerhafte Nutzung von Standardsoftware Durch falsch benutzte Standardsoftware können Mitarbeiter Daten versehentlich löschen oder so verändern, dass diese unbrauchbar werden. Dadurch können ganze Geschäftsprozesse blockiert werden. Auch wenn Funktionen zur Verschlüsselung fehlerhaft benutzt werden, kann es passieren, dass die Daten zwar noch vorhanden sind, aber nicht mehr entschlüsselt werden können. In diesem Fall können die Daten nicht mehr oder nur noch mit erhöhtem Aufwand wiederhergestellt werden. Dies kann die Institution zusätzlich finanziell belasten. 3 Anforderungen Im Folgenden sind die spezifischen Anforderungen des Bausteins CON.4 Auswahl und Einsatz von Standardsoft- ware aufgeführt. Grundsätzlich ist der IT-Betrieb für die Erfüllung der Anforderungen zuständig. Der Informations- sicherheitsbeauftragte (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. Zu- sätzlich kann es noch andere Rollen geben, die weitere Zuständigkeiten bei der Erfüllung von Anforderungen ha- ben. Diese sind dann jeweils explizit in eckigen Klammern in der Überschrift der jeweiligen Anforderungen aufge- führt. Grundsätzlich zuständig IT-Betrieb Weitere Zuständigkeiten Beschaffungsstelle, Fachabteilung 2 IT-Grundschutz-Kompendium: Stand Februar 2020
CON.4 CON: Konzepte und Vorgehensweisen 3.1 Basis-Anforderungen Die folgenden Anforderungen MÜSSEN für den Baustein CON.4 Auswahl und Einsatz von Standardsoftware vor- rangig erfüllt werden: CON.4.A1 Sicherstellen der Integrität von Standardsoftware (B) Bei der Installation von Standardsoftware MÜSSEN originale und unveränderte Softwareprogramme verwendet werden. Dazu MUSS sie entweder von Originaldatenträgern oder von geprüften identischen Kopien des originalen Installationsprogramms installiert werden. Das Installationsprogramm MUSS auf Schadsoftware überprüft werden. Von den Installationsdateien SOLLTEN im Rahmen des Datensicherungskonzepts Sicherungskopien angelegt wer- den. CON.4.A2 Entwicklung der Installationsanweisung für Standardsoftware (B) Für jede ausgewählte Standardsoftware MUSS eine Installationsanweisung erstellt werden. Auch MÜSSEN geeig- nete Parameter für die Konfiguration sowie organisatorische Rahmenbedingungen für die Installation der Software vorgegeben werden. CON.4.A3 Sichere Installation und Konfiguration von Standardsoftware (B) Freigegebene Standardsoftware MUSS so installiert und konfiguriert werden, dass dabei die entsprechenden Instal- lationsanweisungen eingehalten werden. Wird von diesen Anweisungen abgewichen, MUSS dies durch den Vorge- setzten genehmigt werden. Alle Installationen DÜRFEN NUR vom IT-Betrieb durchgeführt werden. Dabei MUSS si- chergestellt sein, dass ausschließlich die benötigten Programmfunktionen installiert werden. Die Software MUSS so konfiguriert werden, dass sie die Sicherheitsrichtlinien der Institution erfüllt. Nicht benötigte Dienste und Funktionen MÜSSEN deinstalliert werden. Falls dies nicht möglich ist, MÜSSEN sie abgeschaltet wer- den. Bevor und nachdem Standardsoftware installiert wurde, SOLLTEN von allen beteiligten IT-Systemen Datensi- cherungen erstellt werden. 3.2 Standard-Anforderungen Gemeinsam mit den Basis-Anforderungen entsprechen die folgenden Anforderungen dem Stand der Technik für den Baustein CON.4 Auswahl und Einsatz von Standardsoftware. Sie SOLLTEN grundsätzlich erfüllt werden. CON.4.A4 Festlegung der Verantwortlichkeiten im Bereich Standardsoftware [Fachabteilung] (S) Für die Einführung einer Standardsoftware SOLLTEN Verantwortliche benannt werden. Dabei SOLLTE mindestens festgelegt werden, wer einen Anforderungskatalog erstellt, das Produkt auswählt, es testet und freigibt. Außerdem SOLLTE bestimmt werden, wer letztlich für die Installation verantwortlich ist. Zusätzlich SOLLTE ein Einführungs- und Freigabeprozess definiert werden. Für den Betrieb von Standardsoftware SOLLTEN technische und fachliche Produktverantwortliche benannt werden. CON.4.A5 Erstellung eines Anforderungskatalogs für Standardsoftware [Fachabteilung] (S) Wird Standardsoftware beschafft, SOLLTE zuvor ein Anforderungskatalog erstellt werden, der neben funktionalen Anforderungen auch Sicherheitsanforderungen umfasst. Dazu SOLLTEN auch die Programmanforderungen der Fach- und IT-Abteilungen erhoben werden. Der fertige Anforderungskatalog SOLLTE mit allen betroffenen Fachab- teilungen abgestimmt werden. CON.4.A6 Auswahl einer geeigneten Standardsoftware [Fachabteilung, Beschaffungsstelle] (S) Anhand des Anforderungskatalogs SOLLTEN die am Markt erhältlichen Produkte gesichtet und mithilfe einer Be- wertungsskala miteinander verglichen werden (siehe CON4.A5 Erstellung eines Anforderungskatalogs für Stan- dardsoftware). Danach SOLLTE untersucht werden, ob die Produkte aus der engeren Wahl die Anforderungen der Institution auch wirklich erfüllen. Gibt es mehrere Produktalternativen, SOLLTE auch der zusätzliche Aufwand be- rücksichtigt werden, z. B. für Schulungen oder für die Migration. Letztlich SOLLTE die Beschaffungsstelle gemein- sam mit dem Leiter der anfordernden Fachabteilung und des IT-Betriebs anhand der Bewertungen und Testergeb- nisse ein geeignetes Softwareprodukt auswählen. IT-Grundschutz-Kompendium: Stand Februar 2020 3
CON: Konzepte und Vorgehensweisen CON.4 CON.4.A7 Überprüfung der Lieferung von Standardsoftware [Fachabteilung] (S) Es SOLLTE überprüft werden, ob neue Softwareprodukte vollständig und korrekt geliefert wurden. Dabei SOLLTE mindestens kontrolliert werden, ob die Lieferung bestellt wurde, für wen sie bestimmt ist und ob alle notwendigen Komponenten vorhanden sind. Auch reine Download-Software inklusive zugehöriger Lizenzdateien oder -schlüssel SOLLTE entsprechend geprüft werden. Die Ergebnisse der Überprüfung SOLLTEN dokumentiert werden. Danach SOLLTEN alle gelieferten Produkte und Lizenzinformationen mit eindeutigen Identifizierungsmerkmalen versehen und in ein Bestandsverzeichnis übernommen werden. CON.4.A8 Lizenzverwaltung und Versionskontrolle von Standardsoftware (S) Lizenzpflichtige Standardsoftware-Produkte, die auf IT-Systemen der Institution eingesetzt werden, SOLLTEN kor- rekt lizenziert sein. Die Lizenzen SOLLTEN die tatsächliche Nutzeranzahl und den Einsatzzweck abdecken. Um das sicherzustellen, SOLLTEN die installierten Programmversionen und die Lizenzen regelmäßig kontrolliert wer- den. Dafür SOLLTEN entsprechende Listen, Datenbanken oder spezielle Lizenzverwaltungsprogramme verwendet werden. Die Bestandslisten für die Lizenzen SOLLTEN immer auf dem aktuellen Stand sein. Darüber hinaus SOLLTEN die verschiedenen Konfigurationen der installierten Standardsoftware dokumentiert werden. CON.4.A9 Deinstallation von Standardsoftware (S) Wird Standardsoftware deinstalliert, SOLLTEN alle Dateien entfernt werden, die für den Betrieb der Software auf dem IT-System angelegt worden sind. Auch SOLLTEN alle Einträge in Systemdateien, die für das Produkt vorgenom- men wurden, gelöscht werden. Um Standardsoftware wieder vollständig deinstallieren zu können, SOLLTEN die während der Installation durchgeführten Systemänderungen entweder manuell oder mit entsprechenden Program- men dokumentiert werden. 3.3 Anforderungen bei erhöhtem Schutzbedarf Im Folgenden sind für den Baustein CON.4 Auswahl und Einsatz von Standardsoftware exemplarische Vorschläge für Anforderungen aufgeführt, die über das dem Stand der Technik entsprechende Schutzniveau hinausgehen und BEI ERHÖHTEM SCHUTZBEDARF in Betracht gezogen werden SOLLTEN. Die konkrete Festlegung erfolgt im Rah- men einer Risikoanalyse. CON.4.A10 Implementierung zusätzlicher Sicherheitsfunktionen (H) Es SOLLTE geprüft werden, ob sich die Sicherheitsfunktionen der betriebenen Standardsoftware für einen erhöhten Schutzbedarf eignen. Ist das nicht der Fall, SOLLTEN geeignete Funktionen implementiert werden, um den Betrieb abzusichern. Grundsätzlich SOLLTE ein erhöhter Schutzbedarf jedoch bereits bedacht werden, wenn die Anforderungen defi- niert werden und das Produkt ausgewählt wird. CON.4.A11 Nutzung zertifizierter Standardsoftware (H) Bei der Beschaffung von Standardsoftware SOLLTE festgelegt werden, ob eine Zusicherung des Herstellers, Vertrei- bers oder Anbieters über implementierte Sicherheitsfunktionen als ausreichend vertrauenswürdig anerkannt wer- den kann. Ist dies nicht der Fall, SOLLTE eine Zertifizierung der Anwendung nach Common Criteria als Entschei- dungskriterium in Betracht gezogen werden. Stehen mehrere Produkte zur Auswahl, SOLLTEN insbesondere dann Sicherheitszertifikate berücksichtigt werden, wenn der evaluierte Funktionsumfang die Mindestfunktionalität (wei- testgehend) umfasst und die Mechanismenstärke dem Schutzbedarf entspricht. Gibt es auf dem Markt kein geeig- netes und zertifiziertes Produkt, SOLLTE die Einsatzumgebung der Standardsoftware entsprechend einem hohen Schutzbedarf abgesichert sein. CON.4.A12 Einsatz von Verschlüsselung, Checksummen oder digitalen Signaturen (H) Wenn Daten mit erhöhtem Schutzbedarf übertragen oder gespeichert werden, SOLLTEN sie vorher verschlüsselt werden. Gibt es in einer Standardsoftware eine integrierte Verschlüsselungsfunktion, SOLLTE geprüft werden, ob diese ausreichend sicher ist. Das SOLLTE besonders bei älteren Produktversionen überprüft werden. Benutzer SOLL- TEN im Umgang mit den Verschlüsselungsfunktionen geschult und sensibilisiert werden. 4 IT-Grundschutz-Kompendium: Stand Februar 2020
CON.4 CON: Konzepte und Vorgehensweisen 4 Weiterführende Informationen 4.1 Wissenswertes Die International Organization for Standardization (ISO) gibt in der Norm ISO/IEC 27001:2013 im Annex A.14 „Security requirements of information systems“ Anforderungen an die Informationssicherheit von IT-Systemen, die auch bei der Auswahl und dem Einsatz von Standardsoftware berücksichtigt werden sollten. Die Common Criteria for Information Technology Security Evaluation (CC) stellen die Basis für international aner- kannte Produktzertifizierungen dar. Eine CC-Zertifizierung kann somit als Nachweis für die Informationssicherheit eines Softwareproduktes herangezogen werden. Das National Institute of Standardisation and Technology formuliert in der NIST Special Publication 800-53 im Appendix F „Family System and Service Acquisition“ unter anderem Anforderungen an die Anschaffung von IT- Produkten, hierunter auch Standardsoftware. Das Infomation Security Forum (ISF) stellt in seinem Standard „The Standard of Good Practice for Information Secu- rity“ in dem Kapitel „Business Application Management“ unter anderem Best Practices zur Absicherung von Stan- dardsoftware vor. 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 CON.4 Auswahl und Einsatz von Standardsoft- ware von Bedeutung. G 0.18 Fehlplanung oder fehlende Anpassung G 0.19 Offenlegung schützenswerter Informationen G 0.20 Informationen oder Produkte aus unzuverlässiger Quelle G 0.22 Manipulation von Informationen G 0.28 Software-Schwachstellen oder -Fehler G 0.29 Verstoß gegen Gesetze oder Regelungen G 0.31 Fehlerhafte Nutzung oder Administration von Geräten und Systemen G 0.39 Schadprogramme G 0.46 Integritätsverlust schützenswerter Informationen IT-Grundschutz-Kompendium: Stand Februar 2020 5
CON: Konzepte und Vorgehensweisen CON.4 Elementare CIA- G 0.18 G 0.19 G 0.20 G 0.22 G 0.28 G 0.29 G 0.31 G 0.39 G 0.46 Gefährdungen Werte Anforderungen CON.4.A1 X X CON.4.A2 X CON.4.A3 X X CON.4.A4 X CON.4.A5 X CON.4.A6 X CON.4.A7 X CON.4.A8 X CON.4.A9 X X CON.4.A10 CIA X CON.4.A11 CIA X X X CON.4.A12 CI X X X 6 IT-Grundschutz-Kompendium: Stand Februar 2020
CON.5 CON: Konzepte und Vorgehensweisen CON.5: Entwicklung und Einsatz von Individualsoftware 1 Beschreibung 1.1 Einleitung Viele Institutionen stehen vor Herausforderungen, die sie nicht mehr hinreichend mit Standardsoftware lösen kön- nen. Die mit diesen Herausforderungen verbundenen Aufgabenstellungen bedürfen häufig Softwarelösungen, die auf die individuellen Bedürfnisse der Institutionen zugeschnitten sind, im Folgenden Individualsoftware genannt. Hierzu können einerseits Basislösungen, die aus einer Grundmenge an typischen Funktionen bestehen, eingesetzt und individualisiert werden. Die Grundfunktionen werden hierbei für den individuellen Einsatzzweck der Institution angepasst und um individuell benötigte Funktionen erweitert. Gängige Beispiele hierfür sind IT-Anwendungen wie ERP- (Enterprise Resource Planning), CMS- (Content Management Systeme) oder IDM-Systeme (Identity Manage- ment). Individualsoftware kann auch vollständig neu von der Institution selbst oder von Dritten entwickelt werden. Von essentieller Bedeutung ist es hierbei, dass bereits bei der Planung und Konzeptionierung der Individualsoftware auch die benötigten Sicherheitsfunktionen bedacht werden und die Informationssicherheit in dem gesamten Le- benszyklus der Individualsoftware berücksichtigt wird. Fehler in der Planung oder fehlende Sicherheitsfunktionen können im laufenden Betrieb nicht oder nur mit hohem zusätzlichen Aufwand ausgeglichen werden. Gängige Beispiele für Individualsoftware sind Anwendungen zur Geschäftsprozesssteuerung oder individuell ange- passte Fachanwendungen, wie Personalverwaltungssoftware, Verfahren zur Verwaltung von Sozialdaten oder Mel- dedaten. 1.2 Zielsetzung Ziel dieses Bausteins ist es aufzuzeigen, welche grundlegenden Sicherheitsanforderungen bei der Planung, Be- schaffung und Inbetriebnahme sowie im regulären Betrieb und bei der Außerbetriebnahme von Individualsoftware zu berücksichtigen sind. 1.3 Abgrenzung und Modellierung Der Baustein CON.5 Entwicklung und Einsatz von Individualsoftware ist für einzelne Anwendungen zu nutzen, wenn es sich hierbei um Individualsoftware handelt. Der Fokus dieses Bausteins liegt auf organisatorischen und konzeptionellen Aspekten, die einen sicheren Einsatz der Individualsoftware über deren gesamten Lebenszyklus hinweg ermöglichen. Weitergehende Aspekte der Soft- ware-Entwicklung werden in dem Baustein CON.8 Softwareentwicklung behandelt. Auswahl, Konfiguration und sicherer Betrieb von Sicherheitsfunktionen in Anwendungen sind in diesem Baustein nur allgemein und grundlegend beschrieben. Konkrete Beschreibungen für breit genutzte Standardanwendungen finden sich in den weiteren Bausteinen der Schicht APP Anwendungen sowie im Baustein CON.4 Auswahl und Einsatz von Standardsoftware. Die Freigabe und Tests von Individualsoftware wird in dem Baustein OPS.1.1.6. Software-Tests und -Freigaben be- handelt. Soll die zu entwickelnde Software im Outsourcing-Kontext eingesetzt werden, müssen die aus den Bau- steinen OPS.2.1 Outsourcing für Kunden bzw. OPS 3.1 Outsourcing für Dienstleister zutreffenden Anforderungen berücksichtigt werden, wie z. B. die Anforderungen zum Mandantenkonzept. IT-Grundschutz-Kompendium: Stand Februar 2020 1
CON: Konzepte und Vorgehensweisen CON.5 2 Gefährdungslage Folgende spezifische Bedrohungen und Schwachstellen sind für den Baustein CON.5 Entwicklung und Einsatz von Individualsoftware von besonderer Bedeutung: 2.1 Ungeeignete Verwaltung von Zugangs- und Zugriffsrechten Wenn die Vergabe von Zugangs- und Zugriffsrechten schlecht geregelt ist, führt das schnell zu gravierenden Sicher- heitslücken, z. B. durch eine zu freizügige oder zu komplizierte Rechtevergabe. So kann es etwa sein, dass Benutzer Berechtigungen auf Zuruf erhalten. Umgekehrt ist es auch möglich, dass Berechtigungen über unnötig kompli- zierte Wege vergeben werden. So können einerseits fehlende Berechtigungen die tägliche Arbeit behindern. Ande- rerseits kann es dazu kommen, dass Berechtigungen vergeben werden, obwohl sie gar nicht erforderlich sind. Auf diese Weise kann ein Sicherheitsrisiko entstehen. 2.2 Unzulängliche vertragliche Regelungen mit externen Dienstleistern Aufgrund von unzulänglichen vertraglichen Regelungen mit externen Dienstleistern können vielfältige und schwer- wiegende Sicherheitsprobleme auftreten. Dies gilt insbesondere bei der Erstellung, der Einführung, der Unterstüt- zung und bei der Wartung der Anwendung. Sind Aufgaben, Leistungsparameter oder der Aufwand ungenügend oder missverständlich beschrieben, können Sicherheitsmaßnahmen möglicherweise aus Unkenntnis oder aufgrund mangelnder Qualifizierung oder fehlender Ressourcen nicht umgesetzt werden. Dies kann viele negative Auswir- kungen nach sich ziehen, etwa wenn regulatorische Anforderungen und Pflichten nicht erfüllt werden, Auskunfts- pflichten und Gesetze nicht eingehalten werden oder keine Verantwortung übernommen wird, weil Kontroll- und Steuerungsmöglichkeiten fehlen. 2.3 Software-Konzeptionsfehler Werden Anwendungen, Programme und Protokolle konzeptioniert, können sicherheitsrelevante Konzeptionsfeh- ler entstehen. Diese ergeben sich häufig daraus, dass Anwendungsmodule und Protokolle, die für einen bestimm- ten Zweck vorgesehen sind, in anderen Einsatzszenarien wiederverwendet werden. Sind dann andere Sicherheits- vorgaben relevant, kann dies zu massiven Sicherheitsproblemen führen, zum Beispiel wenn Anwendungsmodule und Protokolle, die eigentlich für abgeschottete betriebliche Umgebungen vorgesehen sind, an das Internet ange- bunden werden. 2.4 Undokumentierte Funktionen Viele Anwendungen enthalten vom Hersteller eingebaute, undokumentierte Funktionen, häufig für Entwicklungs- oder Supportzwecke. Diese sind den Benutzern meistens nicht bekannt. Undokumentierte Funktionen sind dann problematisch, wenn sie es erlauben, dass wesentliche Sicherheitsmechanismen umgangen werden, wie z. B. zum Zugriffsschutz. Dies kann die Vertraulichkeit, Integrität und Verfügbarkeit der verarbeiteten Daten erheblich beein- trächtigen. 2.5 Fehlende oder unzureichende Sicherheitsmaßnahmen in Anwendungen Sicherheitsmechanismen oder Sicherheitsfunktionen sollen in der Anwendung sicherstellen, dass bei der Verarbei- tung von Informationen die Vertraulichkeit, Integrität und Verfügbarkeit im benötigten Maße gewährleistet wer- den können. Häufig steht bei der Entwicklung einer Anwendung aber die fachliche Funktionalität oder der Zeit- und Kostenrahmen im Vordergrund. So können wichtige Sicherheitsmechanismen zu schwach ausgeprägt sein, sodass sie einfach umgangen werden können oder sogar ganz fehlen. 3 Anforderungen Im Folgenden sind die spezifischen Anforderungen des Bausteins CON.5 Entwicklung und Einsatz von Individual- software aufgeführt. Grundsätzlich ist der die Anwendung einsetzende Fachbereich für die Erfüllung dieser Anfor- derungen zuständig. Der Informationssicherheitsbeauftragte (ISB) ist bei strategischen Entscheidungen stets einzu- beziehen. Außerdem ist der ISB dafür zuständig, dass alle Anforderungen gemäß dem festgelegten Sicherheitskon- zept erfüllt und überprüft werden. Zusätzlich kann es noch andere Rollen geben, die weitere Zuständigkeiten bei 2 IT-Grundschutz-Kompendium: Stand Februar 2020
CON.5 CON: Konzepte und Vorgehensweisen der Umsetzung von Anforderungen haben. Diese sind dann jeweils explizit in eckigen Klammern in der Überschrift der jeweiligen Anforderungen aufgeführt. Grundsätzlich zuständig Fachverantwortliche Weitere Zuständigkeiten Beschaffer, IT-Betrieb, Notfallbeauftragter 3.1 Basis-Anforderungen Die folgenden Anforderungen MÜSSEN für den Baustein CON.5 Entwicklung und Einsatz von Individualsoftware vorrangig erfüllt werden: CON.5.A1 Festlegung benötigter Sicherheitsfunktionen der Individualsoftware [IT-Betrieb] (B) Der Fachverantwortliche MUSS bereits bei der Anforderungserhebung und -dokumentation die erforderlichen Si- cherheitsfunktionen für die Individualsoftware definieren. Hierzu MÜSSEN die mit der Individualsoftware verarbei- teten Informationen und deren Schutzbedarf sowie die damit verbundenen Geschäftsprozesse betrachtet werden. Vom IT-Betrieb MÜSSEN die Sicherheitsfunktionen zur Integration in die IT-betriebliche Infrastruktur definiert wer- den. Die Sicherheitsfunktionen MÜSSEN geeignet dokumentiert werden. CON.5.A2 ENTFALLEN (B) Diese Anforderung ist entfallen. CON.5.A3 Sichere Installation von Individualsoftware [IT-Betrieb] (B) Es MUSS eine Installationsanweisung erstellt werden, die alle benötigten Anwendungskomponenten (einschließ- lich erforderlicher Bibliotheken), die Installationsreihenfolge und die Konfiguration der Anwendungsmodule ent- hält. Der IT-Betrieb MUSS die Installationsanweisung auf die IT-betrieblichen Strukturen der Institution anpassen. Ebenso MUSS der IT-Betrieb die Individualsoftware gemäß der Installationsanweisung installieren. Bei Änderungen in der Anwendung und bei funktionalen Updates MUSS die Installationsanweisung aktualisiert werden. CON.5.A4 Heranführen von Benutzerinnen und Benutzern an Individualsoftware (B) Alle Benutzer der Individualsoftware, darunter auch die zuständigen Administratoren, MÜSSEN an die korrekte Nutzung und Administration der Anwendung einschließlich der Sicherheitsfunktionen herangeführt werden. Hierzu SOLLTEN Richtlinien und Arbeitsanweisungen zur Nutzung und Administration der Anwendung, Schulun- gen und Einweisungen, Handbücher und Online-Hilfen sowie eine Benutzerunterstützung durch Schlüsselanwen- der angeboten werden. CON.5.A5 ENTFALLEN (B) Diese Anforderung ist entfallen. 3.2 Standard-Anforderungen Gemeinsam mit den Basis-Anforderungen entsprechen die folgenden Anforderungen dem Stand der Technik für den Baustein CON.5 Entwicklung und Einsatz von Individualsoftware. Sie SOLLTEN grundsätzlich erfüllt werden. CON.5.A6 Dokumentation der Anforderungen an die Individualsoftware (S) Alle relevanten Anforderungen an die Individualsoftware SOLLTEN umfassend dokumentiert werden. Diese Doku- mentation SOLLTE bei Änderungen an der Individualsoftware sowie bei funktionalen Updates aktualisiert werden. CON.5.A7 ENTFALLEN (S) Diese Anforderung ist entfallen. IT-Grundschutz-Kompendium: Stand Februar 2020 3
