CAFM: Security Testing (Vulnerability/PenTest)

CAFM-Systeme sind meist Web- oder Netzwerksysteme und teilen viele Schwachstellen mit klassischen Webanwendungen und IoT-Geräten.

• Web-UI und APIs: Unsichere Eingabevalidierung kann zu SQL-Injection oder Cross-Site Scripting führen, wie sie im OWASP Top 10 gelistet sind (z. B. A03: Injection). Fehlende oder fehlerhafte Authentifizierung/Session-Handling (OWASP A07) kann es Angreifern ermöglichen, Konten zu übernehmen. APIs leiden oft unter „Broken Authentication“ oder „Broken Object Level Authorization“, wenn z. B. Zugriffsprüfung auf Datenobjekte unzureichend ist.

• Berechtigungen: Unvollständige oder falsch konfigurierte Zugriffsrechte erlauben es, dass ein eingeschränkter Nutzer erweiterte Aktionen durchführen kann (OWASP A01: Broken Access Control).

• Drittanbieter-Schnittstellen: CAFM-Systeme integrieren oft IoT-Sensoren, BMS-Komponenten, Wetter-APIs oder Datenbanken. Sicherheitslücken in solchen Anbindungen (unsichere Protokolle, fehlende Härtung) können als Einstiegspunkte dienen.

• Angriffe auf Gebäudesteuerung: Wie IBM-Berichte zeigen, kann die Übernahme eines Gebäudeautomationssystems (BAS) Alarmanlagen, Heizung/Kühlung oder Beleuchtung aushebeln. Im schlimmsten Fall lassen sich so Notausgänge manipulieren oder infrastrukturelle Störungen verursachen. Zudem besteht Gefahr der lateralen Bewegung ins Unternehmensnetz.

• Allgemeine Angriffsvektoren: Veraltete Softwarekomponenten (vgl. OWASP A06), unsichere Serverkonfigurationen, fehlende Verschlüsselung oder Standardpasswörter. Der OWASP Scan-Guide zählt typischerweise Cross-Site-Scripting, SQL-Injection, Command Injection, Path Traversal etc. als Hauptvorkommen auf Webservern.

• Datenschutzverletzungen: Durch mangelhaften Schutz können personenbezogene oder sensible Gebäudedaten (Belegungspläne, Zugangsdaten) unberechtigt ausgelesen und missbraucht werden.

Die Security-Tests umfassen automatisierte und manuelle Verfahren. Zu den automatisierten Tools gehören Netzwerk- und Port-Scanner (z. B. Nmap) sowie Schwachstellenscanner wie Nessus oder OpenVAS, die bekannte Lücken und Fehlkonfigurationen in Betriebssystemen, Datenbanken und Anwendungen aufspüren. Web-Anwendungen werden zusätzlich mit Web-App-Scannern (Nikto, OWASP ZAP, Burp Scanner u. Ä.) auf gängige XSS-, SQLi- und andere webtypische Schwachstellen geprüft. Ferner kommen Man-in-the-Middle-Proxies (z. B. Burp Suite, ZAP) zum Einsatz, um Browser-HTTP-Traffic abzufangen und zu manipulieren – so lassen sich etwa versteckte Formularfelder oder CSRF-Angriffe identifizieren. Manuelle Tests ergänzen das Bild: Sicherheitsexperten konstruieren gezielt bösartige Eingaben, fügen Manipulations-Skripte ein oder entwickeln Proof-of-Concept-Exploits. Dabei werden auch Business-Logik-Tests oder komplexe Angriffsszenarien durchgespielt. (Social-Engineering-Angriffe sind hier ausgeschlossen.) Insgesamt erfolgt meist ein hybrider Ansatz: Zuerst automatisierte Scans (um „Low-Hanging Fruits“ zu finden), dann manuelles Nachtestens und Exploit-Versuche.

Bei Planung und Bewertung von Security-Tests stützen sich Unternehmen auf bewährte Standards und Kataloge. Für Web- und API-Security sind die OWASP Top Ten (bzw. OWASP API Top Ten) führend: Sie fassen die am häufigsten auftretenden bzw. ausgenutzten Schwachstellen zusammen (z. B. Broken Access Control, Injection, Insecure Design). Die CWE (Common Weakness Enumeration) listet systematisch Software- und Hardware-Schwächen und ihre Ursachen auf (z. B. CWE-79 für XSS). Konkrete Schwachstellen in Produkten werden über CVE-IDs (Common Vulnerabilities and Exposures) referenziert – ein internationales Register, das jede öffentlich bekannte Sicherheitslücke eindeutig benennt. Zusätzlich spielen Branchenstandards wie NIST/NVD, ISO 27001, BSI-IT-Grundschutz oder CIS Benchmarks eine Rolle, wenn Sicherheitsmaßnahmen oder Audit-Tauglichkeit nachgewiesen werden sollen. Für Web-Apps können auch OWASP ASVS oder WSTG als Prüfgrundlage dienen. Insgesamt dient dies alles dazu, Testergebnisse systematisch einzuordnen und Gegenmaßnahmen gezielt abzuleiten.

Vor jedem Penetrationstest muss eine formelle Genehmigung und Abnahmeanordnung vorliegen. Das bedeutet in der Praxis: Schriftliche Freigabe des Tests durch Verantwortliche mit klar definiertem Scope (welche Systeme, IPs, Zeitfenster, Testtiefe) sowie einer Haftungsvereinbarung. Ohne diese offizielle Auftragserteilung sind Penetrationstests rechtswidrig. Im Vertrag sind üblicherweise auch Details zur Geheimhaltung (NDA), zum Umgang mit Daten und zum Berichtsverfahren festzuhalten. Enthält der Test den Zugriff auf personenbezogene Daten, muss ein AV-Vertrag (Auftragsverarbeitungsvertrag) geschlossen werden: Der Penetrationstester agiert dann als Auftragsverarbeiter für den Auftraggeber. Dies stellt sicher, dass alle Datenschutzvorgaben (DSGVO) eingehalten werden. Testergebnisse und Analysen sollten umfassend dokumentiert werden. Compliance-Anforderungen (z. B. ISO 27001, PCI-DSS) verlangen oft, Testergebnisse prüfbar zu machen; wie z. B. der Anbieter HackCheck betont, müssen Tests ggf. so aufbereitet werden, dass sie für Audits und Zertifizierungen verwertbar sind. Die Dokumentation umfasst Testprotokolle, Logs und Beweise für gefundene Schwachstellen. Schließlich ist auch die Haftung zu regeln: Befindet sich durch den Test ein Schaden am System, müssen Vertrag und Versicherung diesen Fall abdecken.

Nach Abschluss der Tests werden die Schwachstellen systematisch bewertet, priorisiert und an die verantwortlichen Stellen weitergeleitet. Üblich ist die Nutzung des CVSS-Scores (Common Vulnerability Scoring System), um die Gefährlichkeit der Schwachstelle (Basis, temporäre und Umgebungsmetriken) zu quantifizieren. So wird beispielsweise ein CVSS-Score von 9,0–10,0 als kritisch eingestuft und erhält höchste Priorität. Die Ergebnisse fließen in ein Ticket- oder Issue-Tracking-System ein: Wie Experten berichten, werden Security-Funde als Tickets an das Patch- oder Entwicklungsteam verteilt. Dort wird festgelegt, ob ein offizieller Patch eingespielt oder alternative Gegenmaßnahmen ergriffen werden. Patching und Behebung erfolgt idealerweise nach einem Change-Management-Prozess: Updates werden zuerst in Testumgebungen verifiziert und anschließend produktiv ausgerollt. Der Fortschritt (Patches, Workarounds) wird in Tickets dokumentiert. Nach der Behebung wird ein Re-Test durchgeführt (siehe unten), um die erfolgreiche Schließung der Lücke zu verifizieren.

Die Testergebnisse werden in mehreren Formaten aufbereitet. Typischerweise entsteht ein Management Summary (Executive Summary) mit kompakten Schlüsselergebnissen und Handlungsempfehlungen für Entscheider. Ergänzt wird dies durch einen technischen Detailbericht (Technical Report) für IT-Architekten und Entwickler: Dieser enthält genaue Beschreibungen jeder Schwachstelle, Exploit-Nachweise (Screenshots, Logs, Code-Ausschnitte) und reproduzierbare Schritte zur Demonstration des Problems. Zusatzinformationen wie CVSS-Bewertungen oder Offsets in Compliance-Standards können ebenfalls enthalten sein. Nach Implementierung der Gegenmaßnahmen wird ein Retest-Verfahren durchgeführt: Der Penetrationstest wird (ganz oder partiell) wiederholt, um zu bestätigen, dass alle kritischen Schwachstellen zuverlässig behoben wurden. Viele Dienstleister liefern auch eine vergleichende Zusammenfassung der Ergebnisse (Vorher-/Nachher).

Aus Gründen der Sicherheit empfiehlt sich eine kontinuierliche Teststrategie: Regelmäßige (z. B. vierteljährliche) Schwachstellenscans und jährliche oder ereignisbasierte Penetrationstests helfen, das Risiko auf einem akzeptablen Niveau zu halten. Security-Tests sollten idealerweise Teil eines ganzheitlichen Prozesses sein: So schließen moderne DevSecOps-Pipelines bereits in der Entwicklungsphase automatisierte Sicherheitsprüfungen ein. Hierbei kommen statische Tests (SAST, Code-Reviews, Dependency-Scans) ebenso zum Einsatz wie dynamische Tests (DAST/IAST) direkt in der CI/CD-Pipeline. OWASP empfiehlt in diesem Sinne, z. B. Git-Repositories auf geleakte Zugangsdaten zu scannen und SAST-/DAST-Scanner sowie Infrastructure-as-Code-Scans (z. B. Terraform-Validierung) einzubinden. Auf Basis der entdeckten Schwachstellen sollte ein risikobasiertes Managementmodell verwendet werden: Assets und Schwachstellen nach Kritikalität einordnen, Prioritäten setzen und regelmäßige Reviews durchführen (→ „Identify, Prioritize, Remediate, Re-evaluate“. Weitere Best Practices sind: zeitnahe Patch-Management-Prozesse, Einsatz von Intrusion Detection/Prevention, Netzwerksegmentierung, Härtung von Betriebsystemen und Applikationen, sowie Schulung der Entwickler in Secure Coding. Durch die Kombination aus automatisierten Tools (SAST/DAST) und regelmäßigen manuellen Penetrationstests wird die Abdeckung maximiert und die Systemsicherheit über den gesamten Lebenszyklus verbessert.