Newsletter Anmeldung

Bleiben Sie mit dem Newsletter immer up to date.

Anfrage
arrow-to-top

Das Sicherheitsdispositiv, das nur funktioniert, weil Peter da ist

05/2026 – Fachartikel Swiss Infosec AG

Physische Sicherheit ist in den meisten Organisationen nicht vergessen – aber oft wird nicht so genau hingeschaut.

Es gibt eine Kategorie von Sicherheitsrisiken, die in keinem Dashboard erscheint und die auch kein Penetrationstest aufdeckt, weil sie sich nicht im Netzwerk befindet. Sie sitzt gewissermassen im Kopf von Peter – dem Leiter Facility, der seit zwölf Jahren weiss, dass die Badge-Berechtigungen der externen Reinigungsfirma seit dem letzten Vertragswechsel nicht sauber nachgeführt wurden, der zweimal intern nachgehakt hat, und der das alles nie dokumentiert hat, weil das bisher auch nie jemand gefordert hat.

Es bleibt ein Zutrittssystem, das formal korrekt aussieht und im Betrieb eine Lücke hat, von der niemand mehr weiss – weil Peter seit anderthalb Jahren nicht mehr in dieser Funktion ist und weil es in dieser Organisation nie einen Grund gab, sein Wissen irgendwo festzuhalten, solange Peter da war.

Das begegnet uns regelmässig, und meistens sieht es von aussen nicht beunruhigend aus, weil die Strukturen ja funktionieren.

Gewachsen, bewährt – und dabei kaum verstanden

Wer in Unternehmen und Institutionen schaut, wie physische Sicherheit tatsächlich funktioniert, begegnet erstaunlich oft dem gleichen Bild: Systeme, die sich über Umzüge, Umstrukturierungen, Übernahmen und Generationenwechsel hindurchgehangelt haben und dabei immer irgendwie funktioniert haben – und zwar deshalb, weil die Menschen oft die gleichen geblieben sind. Weil sich in hektischen Situationen jemand an etwas erinnert hat, das nirgends dokumentiert war. Weil ein Mensch in der Lage ist, komplexe Ausnahmesituationen pragmatisch zu lösen, und weil genau das über Jahre eine Art stiller Stabilisator war, den kein System explizit vorgesehen hatte.

Zutrittskonzepte, bei denen bestimmte Schliessebenen aus einem Projekt stammen, das längst abgeschlossen ist. Schlüsselverwaltung, die auf dem Kenntnisstand einer Person basiert, die das Unternehmen vor drei Jahren verlassen hat. Externe Dienstleister, deren Zugangsberechtigungen auf Vertrauensbasis laufen, weil der entsprechende Prozess mal pragmatisch gelöst wurde und sich das einfach so gehalten hat.

Das ist – und das ist wichtig festzuhalten – nicht zwingend das Resultat von Nachlässigkeit. Es ist das Ergebnis davon, dass Sicherheitsstrukturen im Alltag funktionieren und dabei zwangsläufig Kompromisse eingegangen werden müssen. Die Frage, die sich daraus ergibt, ist nicht ob solche Strukturen entstehen, sondern wie belastbar sie sind, wenn sich die Bedingungen ändern.

Was passiert, wenn die Bedingungen sich ändern

Stellen wir uns ein Unternehmen vor, das in der Informationssicherheit gut aufgestellt ist: ein Security Operations Center, regelmässige Audits, ausgereifte Incident Response-Prozesse. Auf dieser Ebene gibt es wenig auszusetzen. Gleichzeitig existiert ein Zutrittssystem, das wie beschrieben über mehrere Jahre gewachsen ist, mit Berechtigungen, die nie vollständig bereinigt wurden, und Schutzzonen, die auf einem Konzeptstand basieren, der nicht mehr der Betriebsrealität entspricht.

An einem gewöhnlichen Dienstagnachmittag kommt ein externer Techniker ins Gebäude. Kein ausserordentlicher Vorgang, er war schon mehrfach hier, kennt die Wege. Sein letzter offizieller Auftrag wurde bereits abgeschlossen und dass seine Zugangskarte eigentlich deaktiviert sein sollte, hat niemand überprüft – es gibt keinen Prozess, der das automatisch sicherstellt, und die Person, die früher solche Dinge im Blick hatte, ist in einer anderen Funktion.

Er gelangt in einen Bereich, der für externe Personen nicht vorgesehen ist, weil die Schutzzonendefinition dort eine Grauzone aufweist, die aus einem älteren Konzept stammt. Im Raum befindet sich Netzwerkinfrastruktur, die für den Betrieb zentral ist und die – das zeigt sich erst im Nachgang – nie explizit als schützenswert ausgewiesen wurde, weil sie nie Teil einer integrierten Risikobetrachtung war. Was dann passiert, ist kein gezielter Angriff: ein falscher Handgriff, eine kurzfristige Unterbrechung, eine Komponente, die nicht so reagiert wie erwartet.

Innerhalb weniger Minuten zeigen Systeme auffälliges Verhalten. Das Monitoring reagiert, die Analyse beginnt – und beginnt dort, wo sie immer beginnt, nämlich im Netzwerk. Es dauert über eine Stunde, bis klar wird, dass die Ursache physischer Natur ist. Zu diesem Zeitpunkt laufen bereits Prozesse, die sich auf einen Cybervorfall ausgerichtet haben, der gar keiner ist, und die Wiederherstellung ist komplizierter als erwartet, weil niemand eine klare Übersicht darüber hatte, welche physische Infrastruktur welche digitalen Systeme trägt.

Die Informationssicherheit hat funktioniert – das Problem lag davor

Was dieser Vorfall zeigt, ist nicht, dass das Monitoring versagt hat oder die Incident Response-Prozesse unzureichend waren. Beides hat funktioniert, und das ist auch anzuerkennen. Er zeigt aber, dass eine ausgereifte digitale Sicherheitsarchitektur an einem Punkt verwundbar war, der ausserhalb des Wahrnehmungsbereichs lag: nämlich in der physischen Realität des Gebäudes, in den gewachsenen Zutrittsprozessen, in der fehlenden Verbindung zwischen dem, was das Konzept sagt, und dem, was im Betrieb tatsächlich passiert.

Das ist eine Schnittstelle, die in vielen Organisationen systematisch unterschätzt wird, nicht weil sie unbekannt wäre, sondern weil die Zuständigkeiten dafür getrennt organisiert sind. Physische Sicherheit ist Facility-Thema, Informationssicherheit ist IT-Thema, und dazwischen gibt es bestenfalls gelegentliche Abstimmung, aber selten ein gemeinsames Risikobild. Was dabei verloren geht, ist das Verständnis dafür, dass beide Bereiche aufeinander aufbauen und dass Lücken in einem Bereich den anderen exponieren können.

Hinzu kommt, dass viele Schutzsysteme, die wir als physisch betrachten – Zutrittskontrolle, Alarmierung, Videoüberwachung – längst selbst auch digitale Systeme sind, mit Konfigurationen, die gepflegt werden müssen, mit Schnittstellen, die absicherungsbedürftig sind, und mit Abhängigkeiten, die selten vollständig dokumentiert sind. Die saubere Trennung zwischen physischer und digitaler Sicherheit, die konzeptionell praktisch erscheint, bildet die technische Realität schon lange nicht mehr ab.

Der Mensch – und warum die einseitige Betrachtung zu kurz greift

In Diskussionen über Sicherheit erscheint der menschliche Faktor meistens als Problem. Menschen umgehen Prozesse, wenn diese im Alltag unpraktisch sind. Sie tolerieren Abweichungen, die sich eingeschliffen haben. Sie treffen unter Zeitdruck Entscheidungen, die im Nachhinein falsch waren. Das alles stimmt, und es wäre unehrlich, das kleinzureden.

Aber die gleiche Beobachtung gilt in die andere Richtung, und das wird in der Sicherheitsdiskussion auffallend selten gesagt: Es ist fast immer ein Mensch, der in einer unklaren Situation das Richtige tut. Der nachfragt, obwohl es niemand von ihm erwartet. Der eine Abweichung meldet, die er auch hätte stillschweigend übergehen können. Der erkennt, dass etwas nicht stimmt – nicht, weil ein System Alarm geschlagen hat, sondern weil er Erfahrung hat und ein Gespür dafür entwickelt hat, wie es sich anfühlt, wenn etwas aus dem Rahmen fällt.

Sicherheitskonzepte, die den Menschen primär als Risikofaktor behandeln, verpassen diese Ressource und bauen auf Systeme, die darauf ausgelegt sind, menschliches Verhalten zu kontrollieren, statt es einzubinden. Was funktioniert, sind Strukturen, in denen Menschen wissen, warum eine Massnahme sinnvoll ist, in denen Abweichungen gemeldet werden können, ohne dass es unangenehm wird, und in denen implizites Wissen – das Wissen von Personen wie Peter – einen Weg findet, irgendwo festgehalten zu werden, bevor es verloren geht.

Was das in der Praxis bedeutet

Es geht nicht darum, alles neu aufzubauen oder physische Sicherheit als neues Megaprojekt zu positionieren. Was es braucht, ist eine ehrliche Auseinandersetzung mit ein paar Fragen, die unangenehm sind, weil die Antworten selten so klar ausfallen, wie man es erwarten würde: Welche unserer physischen Sicherheitsstrukturen funktionieren, weil sie gut aufgebaut sind – und welche, weil bestimmte Personen sie stillschweigend am Laufen halten? Wo gibt es implizites Wissen, das nie dokumentiert wurde? Welche physischen Abhängigkeiten unserer IT sind nie Teil einer integrierten Risikobetrachtung gewesen? Und wo haben sich Abweichungen vom Soll als Normalzustand eingeschliffen, weil es bisher gut gegangen ist?

Diese Fragen lassen sich nicht durch ein Audit beantworten, das Konzepte gegen eine Checkliste prüft. Sie erfordern einen Blick auf das, was im Betrieb tatsächlich passiert – und die Bereitschaft, zwischen dokumentierter Sicherheit und wirksamer Sicherheit zu unterscheiden. Das ist nicht immer dasselbe. Physische und digitale Sicherheit als zusammenhängendes System zu verstehen, bedeutet nicht, dass man die eine auf Kosten der anderen stärken soll. Es bedeutet, dass man die Bereiche kennt, auf die das eigene Sicherheitskonzept bisher schlicht nicht ausgerichtet war – und dass man anfängt, dort hinzuschauen.

Gerne beantworten wir alle Ihre Fragen rund um den Physische Sicherheit. Nehmen Sie unverbindlich mit uns Kontakt auf.

Swiss Infosec AG; 01.05.2026
Kompetenzzentrum Consulting, +41 41 984 12 12, infosec@infosec.ch


Betriebssicherheit (Prinzip 5)

Der Dienst muss sicher betrieben und verwaltet werden, um Angriffe zu verhindern, zu erkennen oder zu verhindern. Eine gute Betriebssicherheit sollte keine komplexen, bürokratischen, zeitaufwändigen oder teuren Prozesse erfordern.

Es gibt vier Elemente zu berücksichtigen:

  • Konfigurations- und Änderungsmanagement – Sie sollten sicherstellen, dass Änderungen am System ordnungsgemäss getestet und autorisiert wurden. Änderungen sollten nicht unerwartet Sicherheitseigenschaften ändern.
  • Schwachstellenmanagement – Sie sollten Sicherheitsprobleme in konstituierenden Komponenten identifizieren und mildern.
  • Schutzüberwachung – Sie sollten Massnahmen ergreifen, um Angriffe und unbefugte Aktivitäten auf den Dienst zu erkennen.
  • Vorfallmanagement – Stellen Sie sicher, dass Sie auf Vorfälle reagieren und einen sicheren, verfügbaren Service wiederherstellen können.

5.1 Konfigurations- und Änderungsmanagement

Sie sollten sich ein genaues Bild von den Assets, aus denen der Service besteht, sowie deren Konfigurationen und Abhängigkeiten machen.

Änderungen, die sich auf die Sicherheit des Dienstes auswirken könnten, sollten identifiziert und verwaltet werden. Unbefugte Änderungen sollten erkannt werden.

Wenn Änderungen nicht effektiv verwaltet werden, können Sicherheitsschwachstellen unbeabsichtigt in einen Dienst eingefügt werden. Selbst wenn das Bewusstsein für die Schwachstelle vorhanden ist, kann sie möglicherweise nicht vollständig gemildert werden.

Ziele
Sie sollten hierauf vertrauen können:

  • Der Zustand, der Standort und die Konfiguration der Servicekomponenten (Hard- und Software) werden über ihre gesamte Lebensdauer verfolgt.
  • Änderungen am Dienst werden auf mögliche Auswirkungen auf die Sicherheit geprüft, dann verwaltet und verfolgt bis zur Fertigstellung.

Implementierung – Konfigurations- und Änderungsmanagement

Zusätzliche Hinweise – Priorisierung von Änderungen
Es ist wichtig, dass effektive Change-Management-Prozesse vorhanden sind. Aber Sie müssen auch erkennen, dass Ihr Service bis zum Abschluss des Prozesses verwundbar bleibt. Daher müssen Änderungen je nach Risikoschwere priorisiert werden.

5.2 Schwachstellenmanagement

Dienstanbieter sollten über Managementprozesse verfügen, um Schwachstellen zu identifizieren, zu analysieren und zu minimieren. Dienste, die dies nicht tun, werden schnell anfällig für Angriffe mit öffentlich bekannten Methoden und Tools.

Ziele
Hierauf sollten Sie vertrauen können:

  • Potenzielle neue Bedrohungen, Schwachstellen oder Ausbeutungstechniken, die Ihren Dienst beeinträchtigen könnten, werden bewertet und Korrekturmassnahmen ergriffen.
  • Relevante Informationsquellen über Bedrohungs-, Schwachstellen- und Nutzungstechniken werden vom Dienstanbieter überwacht.
  • Die Schwere der Bedrohungen und Schwachstellen wird im Rahmen des Dienstes berücksichtigt, und diese Informationen werden verwendet, um die Umsetzung von Minderungsmassnahmen zu priorisieren.
  • Mit Hilfe eines geeigneten Change Management-Prozesses werden bekannte Schwachstellen verfolgt, bis Massnahmen ergriffen wurden.
  • Sie kennen die Fristen der Dienstleister für die Umsetzung von Minderungsmassnahmen und sind damit einverstanden.

Implementierung – Schwachstellenmanagement

Zusätzliche Hinweise – Behandlungsfristen
Exploits für bekannte Schwachstellen sind häufig innerhalb weniger Stunden nach der Veröffentlichung im Internet verfügbar. Unternehmen, die Schwachstellen in ihren Diensten mindern und beheben, haben schnell kleinere Schwachstellenfenster.

Sie sollten wissen, ob Ihr Dienstanbieter Schwachstellen innerhalb akzeptabler Fristen behebt.

Wenn es Hinweise darauf gibt, dass eine Schwachstelle in freier Wildbahn aktiv genutzt wird, müssen Dienstleister unverzüglich Abhilfemassnahmen ergreifen.

Wenn es keine Beweise dafür gibt, dass eine Schwachstelle aktiv genutzt wird, sollten die folgenden Fristen als Mindestanforderungen für eine gute Praxis angesehen werden:

  • «Kritische» Patches sollten innerhalb weniger Stunden bereitgestellt werden.
  • «Wichtige» Patches sollten innerhalb von 2 Wochen nach Verfügbarkeit eines Patches bereitgestellt werden.
  • «Andere» Patches, die innerhalb von 8 Wochen nach Verfügbarkeit eines Patches bereitgestellt werden.

5.3 Schutzüberwachung

Ein Dienst, der nicht effektiv auf Angriffe, Missbrauch und Fehlfunktionen überwacht, wird keine Angriffe (sowohl erfolgreiche als auch erfolglose) erkennen können. Infolgedessen kann er nicht schnell auf potenzielle Kompromisse in Ihren Umgebungen und Daten reagieren.

Ziele
Sie sollten darauf vertrauen können:

  • Der Dienst generiert angemessene Auditereignisse, um eine effektive Identifizierung verdächtiger Aktivitäten zu unterstützen.
  • Diese Ereignisse werden analysiert, um mögliche Kompromittierungen oder unangemessene Nutzung Ihres Dienstes zu identifizieren.
  • Der Dienstanbieter ergreift umgehend und angemessen Massnahmen, um Vorfälle zu beheben.

Umsetzung – Schutzüberwachung

Zusätzliche Hinweise – Überwachung und Analyse
Dienste, die keine relevanten Berechnungs- und Auditinformationen sammeln, werden wahrscheinlich keine Angriffe oder versuchte Angriffe erkennen und schnell darauf reagieren. Wenn Angriffe durch andere Mechanismen erkannt werden, wird es schwierig sein, Ausmass, Dauer und Schwere des Kompromisses zu ermitteln, wenn relevante Auditdaten nicht verfügbar sind.

Dienste, die Berechnungs- und Auditinformationen sammeln, aber keine effektive Analyse dieser Informationen haben, werden ebenso wenig Angriffe erkennen und schnell darauf reagieren. Es gibt keine Möglichkeit zu wissen, ob ungeprüfte Daten ausreichen, um eine Untersuchung oder Strafverfolgung zu unterstützen, sollte eine solche stattfinden.

Zusätzliche Hinweise – Überwachungsverantwortung
In IaaS- und PaaS-Diensten führen Benutzer ihre Anwendungen oder Software zusätzlich zum Dienst aus. Es ist unwahrscheinlich, dass die Anbieter eine Schutzüberwachung für diese Anwendungen anbieten, es sei denn, Verbraucher und Dienstleister haben bei der Entwicklung einer geeigneten Lösung zusammengearbeitet.

In diesen Szenarien sind es in der Regel Sie, der Servicebenutzer, der für die Identifizierung von Angriffen auf Ihre Anwendungen oder Software verantwortlich (und oft am besten platziert) ist. Dazu benötigen Sie eigene Überwachungssysteme.

5.4 Vorfallmanagement

Wenn es keine sorgfältig vorbereiteten Vorfallmanagementprozesse gibt, werden bei Auftreten von Vorfällen wahrscheinlich schlechte Entscheidungen getroffen, was die Gesamtauswirkungen auf die Benutzer potenziell verschlimmern könnte.

Diese Prozesse müssen nicht komplex sein oder grosse Mengen an Beschreibung erfordern, aber ein gutes Vorfallmanagement minimiert die Auswirkungen von Sicherheits-, Zuverlässigkeits- und Umweltproblemen bei einem Service auf die Benutzer.

Ziele
Hierauf sollten Sie vertrauen können:

  • Für den Service sind Vorfallmanagementprozesse vorhanden, die aktiv als Reaktion auf Sicherheitsvorfälle eingesetzt werden.
  • Für die Reaktion auf gängige Arten von Vorfällen und Angriffen stehen vordefinierte Prozesse zur Verfügung.
  • Es gibt einen definierten Prozess und Kontaktweg für die Meldung von Sicherheitsvorfällen durch Verbraucher und externe Stellen.
  • Sicherheitsvorfälle, die für Sie relevant sind, werden in akzeptablen Zeitabständen und Formaten gemeldet.

Implementierung – Vorfallmanagement

Zusätzliche Hinweise – Signifikante Angriffe und hohe Verfügbarkeit
Jeder, der Dienste veröffentlicht, die (volumenmässig oder technisch) erheblichen Angriffen ausgesetzt sein können, sollte Anbieter in Anspruch nehmen, die über robuste, gut getestete und erprobte Vorfallsmanagementverfahren verfügen.

Denial-of-Service-Angriffe von „hacktivistischen“ Gruppen oder Kriminellen auf öffentliche Infrastrukturen zur Erzielung von Gewinnen können ein besonders anspruchsvoller Test von Vorfallsreaktionsprozessen sein, insbesondere für Benutzer mit einem hohen Verfügbarkeitsanspruch.

www.ncsc.gov.uk

http://www.nationalarchives.gov.uk/doc/open-government-licence/version/3/

17.11.2018


© Swiss Infosec AG 2026