+ASST.2.3 Inventar der Anwendungen
---+ASST.2.3.1 Autorisierung von Anwendungen
---+ASST.2.3.2 Software Bill of Materials (SBOM)
------+ASST.2.3.2.1 Software Discovery
|
ASST.2.3 Inventar der Anwendungen
Informationen und Assets SOLLTE ein Inventar der Anwendungen einschließlich Produktname, Versionsstand, Herkunft und Lizenzierung dokumentieren. Erläuterung Ein zentrales Inventar der Anwendungen, oft auch als Application Inventory oder Teil des Software Asset Management (SAM) bezeichnet, dient als grundlegende, strukturierte Übersicht aller in der Institution eingesetzten Applikationen. Relevant sind dabei sowohl lokal installierte Anwendungen, als auch solche, die auf Cloud-Servern oder in verteilten Diensten betrieben werden. Hierbei beschreibt die Herkunft nicht nur den Hersteller, sondern auch den Lieferanten oder die Bezugsquelle, um die Vertrauenswürdigkeit bewerten zu können. Die Lizensierung erfasst die rechtliche Grundlage für die Nutzung, einschließlich des Lizenzmodells (z.B. pro Benutzer, pro Gerät, Abonnement), der Anzahl erworbener Lizenzen und deren Gültigkeitsdauer. Häufig sind weitere Angaben sinnvoll, z.B. Beschaffungs- und Installationszeitpunkt, URL, App-Store, Schnittstellen wie z.B. Cloud-APIs oder Datenexporte in andere Anwendungen, auch auf Dateiserver. Ohne eine solche Übersicht könnte die Institution unwissentlich Software mit bekannten, kritischen Schwachstellen einsetzen oder durch den Einsatz nicht lizenzierter Produkte hohe finanzielle und rechtliche Risiken eingehen. Ein gepflegtes Inventar kann hingegen bei neuen Sicherheitswarnungen eine schnelle Auswirkungsanalyse ermöglichen. Zur praktischen Umsetzung kann die Institution eine zentrale Liste, beispielsweise in einer Datenbank oder einem spezialisierten SAM-Tool, aufbauen, die durch verschiedene Quellen gespeist wird. Eine automatisierte Erfassung kann durch technische Werkzeuge erfolgen, wie zum Beispiel durch (1) Netzwerks-Scanner, die installierte Applikationen auf Endgeräten identifizieren, (2) Agenten-basierte Systeme, die kontinuierlich Software-Änderungen melden, oder (3) die Auswertung von Daten aus zentralen Software-Verteilungssystemen. Die Dokumentation kann auch durch eine Liste mit Verweisen umgesetzt werden (z.B. auf die Lizendateien und Schnittstellenkonfiguration).
1. Přehled
| Název |
Standard |
|
ASST.2.3.1 Autorisierung von Anwendungen
|
Informationen und Assets für IT-Systeme SOLLTE die Nutzung von Anwendungen auf diesen durch [eine zuständige Person oder Rolle] autorisieren. Erläuterung Der Sinn dieser Regelung liegt in der Minimierung von Risiken, die durch unkontrollierte Nutzung entstehen. Durch nicht autorisierte Anwendungen könnte beispielsweise Schadsoftware in die Systeme der Institution eingeschleust, könnten durch Sicherheitslücken in veralteter Software Angriffsvektoren geöffnet oder könnten durch den Einsatz nicht konformer Tools sensible Informationen unkontrolliert abfließen. Ein strukturierter Autorisierungsprozess kann somit die Integrität der IT-Systeme wahren und sicherstellen, dass nur geprüfte, für den Geschäftszweck erforderliche und aus rechtlicher Sicht unbedenkliche Anwendungen zum Einsatz kommen, was die gesamte Angriffsfläche der Institution signifikant reduziert. Relevant sind dabei sowohl lokal installierte Anwendungen, als auch solche, die auf Cloud-Servern oder in verteilten Diensten betrieben werden. Je nach Geschäftsprozessen oder Risikoprofil kann die Autorisierung einzeln für jedes System und jede Anwendung, oder für bestimmte Kategorien von Systemen oder Anwendungen vorgenommen werden (z.B. "Alle Office-Produkte eines bestimmten Herstellers auf Notebooks mit einem bestimmten Betriebssystem). Hierbei ist es sinnvoll, Standard-Anwendungen zu bestimmen, die für alle Nutzenden freigegeben sind und die Verwendung darüber hinausgehender Anwendungen pro Nutzer oder Organisationseinheit zu autorisieren.
|
|
ASST.2.3.2 Software Bill of Materials (SBOM)
|
Informationen und Assets für Anwendungen SOLLTE die Software Bill of Materials (SBOM) dokumentieren. Erläuterung Eine Software Bill of Materials (SBOM) ist in diesem Zusammenhang eine strukturierte Liste aller Komponenten, Bibliotheken und Abhängigkeiten, die in einer Anwendung enthalten sind, einschließlich ihrer Versionen und Herkunft. Sie kann dabei sowohl Open-Source- als auch proprietäre Bestandteile erfassen und in maschinenlesbaren Formaten (z. B. SPDX, CycloneDX) vorliegen. Der Zweck dieser Dokumentation liegt darin, Transparenz über die eingesetzten Softwarebestandteile zu schaffen, sodass Abhängigkeiten, potenzielle Schwachstellen oder veraltete Komponenten nachvollziehbar bleiben. Ohne diese Transparenz könnte es bei Sicherheitsvorfällen, Lizenzkonflikten oder fehlender Wartbarkeit zu erheblichen Problemen kommen, während eine gepflegte SBOM die schnelle Identifikation von Risiken, die Minimierung von Vendor Lock-in und die Nachvollziehbarkeit der Software-Lieferkette unterstützen kann. Hierzu kann die BSI TR-03183-2 verwendet werden.
|
1.1 Odkazy
1.2 Identifikované požadavky
1.3 Související regulace
2. Identifikované požadavky
Požadavky
| Zdroj |
Požadavek |
3. Související regulace
Propojené úkoly
|