Thema: incident-response
-
Ein Secret wurde committet: warum Löschen der Datei nicht reicht und wie die Reihenfolge der Reaktion aussieht
Zugangsdaten, die in ein Git-Repository gepusht wurden, bleiben in Historie, Forks, Klonen, Caches und CI-Protokollen erhalten. Das Umschreiben der Historie verringert künftige Exposition, kann bereits erstellte Kopien aber nicht zurückholen; deshalb steht zuerst der Widerruf und die Erneuerung der Zugangsdaten an, danach das Bereinigen der Historie, danach die Prüfung auf Verwendung.
-
Postmortem-Massnahmen bis zum Abschluss verfolgen: Tracking-Bugs, einzelne Verantwortliche und Alters-Review
Das Site Reliability Workbook warnt, dass Massnahmen aus Postmortems ohne einen formalen Tracking-Prozess oft in Vergessenheit geraten; jeder Massnahme einen Tracking-Bug, eine einzige verantwortliche Person, einen Typ und eine Priorität geben, offene Massnahmen planmässig nach Alter durchgehen und eine überfällige Massnahme als zu treffende Entscheidung behandeln, nicht als übersprungene Zeile.
-
Nach Eingang eines Schwachstellenberichts: bestätigen, bewerten, privat beheben, offenlegen
Sobald ein Bericht die Sicherheitskontaktstelle des Projekts erreicht, ist die Arbeit eine Abfolge mit Terminen: schnell bestätigen, klassifizieren (wie vorgesehen, Bug, Feature-Wunsch, Schwachstelle), mit der meldenden Person ein Embargo vereinbaren, den Fix privat entwickeln, eine CVE-Kennung beschaffen, dann veröffentlichen und ein Advisory publizieren, das betroffene und behobene Versionen nennt und die meldende Person würdigt. Der OpenSSF-Leitfaden für Maintainer und GitHubs Hinweise zur Offenlegung beschreiben diesen Prozess; dieser Artikel fasst ihn für ein Projekt mit ein bis fünf Maintainern zusammen.
-
Reaktion auf Sicherheitsvorfälle für ein kleines Team: ein Minimalverfahren
Ein Zweierteam kann kein Security Operations Center betreiben, aber es kann im Voraus eine Kontaktliste, eine Checkliste zur Eindämmung und eine Regel zur Beweissicherung vorbereiten; NIST SP 800-61 Rev. 3 fasst die Reaktion auf Vorfälle als Teil des laufenden Risikomanagements auf, und dieses Verfahren ist das Minimum, das die erste Stunde vorhersehbar macht.
-
Postmortems ohne Schuldzuweisung: Ablauf, Ursachen und Massnahmen festhalten
Ein Postmortem beschreibt, was während eines Vorfalls geschah, wen es wie lange traf, welche Umstände es ermöglichten und welche Massnahmen eine Wiederholung unwahrscheinlicher machen. Schuldfreiheit ist kein Höflichkeitsgebot, sondern die Bedingung dafür, dass Beteiligte Fakten berichten statt sich zu verteidigen.
-
Korrelation versus Kausalität in Vorfalls- und Betriebsdaten
Ein Korrelationskoeffizient misst, wie sich zwei Reihen gemeinsam bewegen; er sagt nichts darüber, welche die andere antreibt, ob ein dritter Faktor wie Traffic beide antreibt, oder ob die Daten nach dem Ergebnis ausgewählt wurden. Zuerst plotten, für die naheliegenden gemeinsamen Ursachen konditionieren, das zeitliche Verhältnis prüfen und mit einer Intervention wie einem Flag oder einem Canary bestätigen, bevor gehandelt wird.
-
Ein erster Game Day: ein Chaos-Experiment mit Hypothese, Blast Radius und Abbruchregel
Eine erste Fehlerinjektionsübung als geplantes, angekündigtes Experiment durchführen: den stabilen Zustand als messbare Grösse definieren, die Hypothese aufstellen, dass er unter einem bestimmten Fehler bestehen bleibt, den Blast Radius begrenzen, eine Abbruchbedingung festlegen, injizieren und festhalten, was das System und die Menschen getan haben; die Principles of Chaos Engineering geben die vier Schritte vor, und das Google-SRE-Buch beschreibt Katastrophen-Rollenspiele als wöchentliches Ritual.
-
Runbooks für den Betrieb: Anleitungen, die eine Fremde nachts ausführen kann
Ein Runbook pro Dienst beantwortet in dieser Reihenfolge: Was tut der Dienst, woran erkennt man in einer Minute, ob er gesund ist, welche bekannten Störungen gibt es mit Symptom, Diagnosebefehl und Gegenmassnahme, welche Handlungen sind sicher, welche gefährlich, und wer ist wann zu eskalieren; geprüft wird es von jemandem, der es nicht geschrieben hat.
-
Teams mit weniger, an Alerts gekoppelten Dashboards diagnostizieren Vorfälle schneller als Teams mit vielen unbetreuten Dashboards
Hypothese: Bei Diensten vergleichbarer Grösse ist die Zeit von einer Alarmierung (Page) bis zu einer benannten wahrscheinlichen Ursache kürzer, wenn das Team eine kleine Anzahl betreuter Dashboards pflegt, auf die Alerts direkt verlinken, als wenn es viele kopierte oder automatisch erzeugte Dashboards pflegt, durch die sich reagierende Personen durcharbeiten müssen; ein vorgeschlagener Vergleich anhand von Vorfall-Zeitleisten und Dashboard-Bestandsaufnahmen.
-
Eine öffentliche Statusseite ehrlich betreiben: Komponenten, Automatisierung und Historie
Eine Statusseite verdient nur dann Vertrauen, wenn sie rot wird, wenn Nutzende Rot sehen; sie ausserhalb der Infrastruktur hosten, über die sie berichtet, Komponenten auflisten, die Nutzende wiedererkennen, allen im Bereitschaftsdienst das Posten ohne Freigabe erlauben, während eines Vorfalls in festem Rhythmus aktualisieren und die Historie sichtbar halten.
-
Statusmeldungen bei Vorfällen: eine Vorlage und ein Takt
Während eines Vorfalls übernimmt eine Person die Kommunikation und veröffentlicht Updates nach festem Zeitplan anhand einer Vorlage: Status, für Nutzende sichtbare Auswirkung, was bekannt ist, was unternommen wird, und der Zeitpunkt des nächsten Updates; das Update erscheint pünktlich, auch wenn sich nichts geändert hat.
-
Alarme mit Runbook-Link werden schneller quittiert und seltener stummgeschaltet als Alarme ohne Link
Hypothese: Alarmierungsregeln können Annotationen wie Beschreibungen oder Runbook-Links tragen, wie die Prometheus-Dokumentation beschreibt; die These lautet, dass Alarmierungen aus Regeln mit funktionierendem Runbook-Link innerhalb desselben Teams und Zeitraums schneller quittiert und behoben werden und seltener stummgeschaltet oder unterdrückt werden als Alarmierungen aus Regeln ohne einen solchen Link.
-
Schweregrade von Vorfällen: Definitionen, wer sie ausruft und wann vom Schlimmsten auszugehen ist
Eine Schweregradskala funktioniert nur, wenn jede Person im Bereitschaftsdienst einen Vorfall ausrufen und ohne Rückfrage einen Grad wählen darf, wenn jeder Grad an eine konkrete Reaktion gebunden ist und wenn bei Unsicherheit die Regel gilt, den höheren Grad zu wählen und ihn im Postmortem zu überprüfen; sowohl PagerDutys öffentliche Dokumentation zur Vorfallsreaktion als auch das Google-SRE-Buch nennen Bedingungen für ein frühes Ausrufen.
Maschinenlesbar: JSON