Vorfallsreaktionsmuster
Weitere Informationen zu Well-Architected Trust → Security Incident Response (Sicherheitsvorfallsreaktion)
Sicherheitsvorfälle treten trotz vorbeugender Maßnahmen auf. Trust Architektur erfordert die Entwicklung auf Erkennbarkeit, schnelle Reaktion, forensische Untersuchung und graziöse Wiederherstellung. Auf dieser Seite werden die Muster für die Reaktion auf Vorfälle aus dem Abschnitt “Vorfallsreaktion” der Trust-Säule konsolidiert, der die Erkennungsarchitektur, die Antwortverfahren, die forensischen Funktionen und das Lernen nach dem Vorfall abdeckt.
Muster
| Wohin schauen | Wie gut aussieht |
|---|---|
| Ereignisüberwachung | ✅ Aktivieren der Ereignisüberwachung zum Erfassen von Anmeldemustern, Massendatenexporten, Berechtigungsänderungen und API-Aktivitäten mit Weiterleitung an SIEM-Plattformen zur Aufbewahrung, die die nativen Aufbewahrungsobergrenzen überschreitet |
| Transaktionssicherheitsrichtlinien | ✅ Konfigurieren von Richtlinien, die Ereignisse in Echtzeit auswerten, um verdächtige Aktionen zu blockieren, eine schrittweise Authentifizierung anzufordern oder Benachrichtigungen basierend auf verhaltensbasierten Grundlagen auszulösen |
| Setup-Aktivierungsprotokoll | ✅ Überwachen von administrativen Konfigurationsänderungen zur Erkennung nicht autorisierter Änderungen mit 180-tägiger Aufbewahrung |
| Benutzerdefinierte Antragsprotokollierung | ✅ Implementieren der sicherheitsrelevanten Ereignisprotokollierung in Apex zum Erfassen von Authentifizierungsfehlern, Autorisierungsverweigerungen und verdächtigen Eingabemustern |
| Integritätsprüfungsüberwachung | ✅ Konfigurieren der automatisierten Erkennung von Konfigurationsabweichungen im Vergleich zu Sicherheitsgrundlagen, die auf nicht autorisierte Änderungen hinweisen könnten |
| SIEM-Integration | ✅ Weiterleiten von Ereignisüberwachungsprotokollen an Enterprise SIEM-Plattformen zur Korrelation mit der Telemetrie und Verhaltensanalyse der Unternehmenssicherheit |
| Benachrichtigungsregeln | ✅ Entwerfen von Benachrichtigungsregeln zur Erkennung verdächtiger Muster (Massenzugriff außerhalb der Geschäftszeiten, Anmeldung aus neuen Regionen, schnelle Eskalation der Berechtigungen) mit Verhaltensgrundlagen zur Minimierung falsch positiver Werte |
| Verhaltensanalysen | ✅ Einrichten von Verhaltensgrundlagen zur Erkennung von Anomalien für ungewöhnliche Datenzugriffsvolumen, Verwaltungsaktivitäten außerhalb der Geschäftszeiten und API-Verbrauchsmuster |
| Mehrkanalerkennung | ✅ Implementieren der Erkennung durch Ereignisüberwachung, Transaktionssicherheit, Setup-Aktivierungsprotokoll, benutzerdefinierte Protokollierung und Integritätsprüfung, die mehrere unabhängige Erkennungssignale bereitstellen |
| Unveränderlicher Protokollspeicher | ✅ Leiten Sie Protokolle an unveränderlichen externen Speicher weiter, den Angreifer selbst mit administrativem Salesforce-Zugriff nicht ändern können, um die Integrität der forensischen Beweise sicherzustellen |
Antimuster
| Wohin schauen | Wie schlecht sieht |
|---|---|
| Nur native Protokollaufbewahrung | ⚠️ Ausschließlich auf nativen Salesforce-Aktivierungsprotokoll-Aufbewahrungsfenstern (native Obergrenzen für die Ereignisüberwachung, Setup-Aktivierungsprotokoll für 180 Tage) ohne externe Archivierung beruhend, erkennen Sie Protokolle, die abgelaufen sind, wenn die Untersuchung historische Analysen erfordert |
| Keine verhaltensbasierten Grundlagen | ⚠️ Keine verhaltensbasierten Grundlagen für die Anomalieerkennung, wodurch übermäßige falsch positive Benachrichtigungen generiert werden, die Sicherheitsteams anlernen, Benachrichtigungen zu ignorieren |
| Keine SIEM-Integration | ⚠️ Fehlende SIEM-Integration für Unternehmen, fehlende Korrelationsmöglichkeiten mit Sicherheitstelemetrie aus anderen Systemen, die breitere Kompromissmuster aufdecken würden |
| Manuelle Protokollüberprüfung | ⚠️ Abhängig von der regelmäßigen manuellen Überprüfung des Protokolls statt der automatischen Benachrichtigung, Erkennen von Vorfällen Wochen oder Monate nach Auftreten eines umfangreichen Schadens |
| Keine Transaktionssicherheitsrichtlinien | ⚠️ Keine Echtzeit-Transaktionssicherheitsrichtlinien, keine Möglichkeit, verdächtige Aktionen zu blockieren, um Schäden zu verhindern, bevor sie auftreten |
| Unvollständige Abdeckung | ⚠️ Überwachen nur einer Teilmenge sicherheitsrelevanter Ereignisse (Anmeldung, aber kein Datenzugriff, Konfigurationsänderungen, aber keine Berechtigungsänderungen), wodurch blinde Flecken entstehen |
| Warnung Müdigkeit | ⚠️ Generieren übermäßiger falsch positiver Benachrichtigungen ohne Tuning, Anlernen von Teams zum Ignorieren von Benachrichtigungen, einschließlich legitimer Sicherheitsereignisse |
Muster
| Wohin schauen | Wie gut aussieht |
|---|---|
| Isolationsgrenzen | ✅ Entwerfen Sie eine Architektur, damit kompromittierte Komponenten durch Widerruf von Berechtigungssätzen, Änderungen der IP-Einschränkung oder Sitzungsabbruch isoliert werden können, ohne dass wichtige Geschäftsfunktionen unterbrochen werden |
| Sitzungsverwaltung | ✅ Implementieren von Funktionen zur schnellen Sitzungsbeendigung für kompromittierte Accounts, einschließlich Abmeldung erzwingen und Sitzungsungültigkeit für alle aktiven Sitzungen |
| Berechtigungswiderruf | ✅ Gewähren Sie Berechtigungen über Berechtigungssätze anstelle von Basisprofilen, damit der Widerruf schnell erfolgt: Durch Entfernen der Berechtigungssatzzuweisung wird der Zugriff widerrufen, wenn kein Profil oder eine andere Zuweisung dieselbe Berechtigung unabhängig erteilt |
| IP-Einschränkungen | ✅ Konfigurieren von IP-Bereichen für Anmeldungen auf Profilebene für berechtigte Accounts, sodass Anmeldungen von anderen Adressen sofort verweigert werden, was eine schnelle Isolierung auf Netzwerkebene von bekannten Verwaltungsstandorten ermöglicht |
| Einfrieren von Benutzeraccounts | ✅ Implementieren von Account-Fixierungsverfahren, die die Authentifizierung verhindern und gleichzeitig Daten für Untersuchungen beibehalten, ohne den kompromittierten Account zu löschen |
| API-Zugriffssteuerungen | ✅ Design-API-Authentifizierung mit Token-Widerrufsfunktionen für die schnelle Isolierung kompromittierter Integrationsaccounts |
| Isolation mehrerer Organisationen | ✅ Bewerten Sie bei Vermögenswerten mit hohem Wert die Architektur mehrerer Organisationen, um kritische Komponenten bestmöglich zu isolieren und die betriebliche Komplexität zu erhöhen |
| Notfallverfahren für Bruchgläser | ✅ Beibehalten dokumentierter Zugriffsverfahren für Glasbruch für den administrativen Notfallzugriff mit Überprüfung und Validierung nach der Verwendung |
Antimuster
| Wohin schauen | Wie schlecht sieht |
|---|---|
| Keine Isolationsgrenzen | ⚠️ Fehlende architektonische Isolationsgrenzen, die ein vollständiges Herunterfahren des Systems erfordern, um Kompromisse einzugehen und alle Geschäftsfunktionen zu unterbrechen |
| Übermäßig berechtigter Zugriff | ⚠️ Erteilen von umfassenden Berechtigungen zum Ändern aller Daten zum Verhindern des Widerrufs granularer Berechtigungen ohne Unterbrechung mehrerer Geschäftsprozesse |
| Freigegebene Service-Accounts | ⚠️ Die Verwendung eines einzelnen freigegebenen Accounts vom Typ “API-Benutzer” oder “Integrationsbenutzer” über mehrere Systeme hinweg verhindert die Isolation bestimmter kompromittierter Integrationen, ohne alle Integrationen zu unterbrechen |
| Keine IP-Einschränkungen | ⚠️ Keine IP-Zulassungsliste für berechtigte Accounts, keine Sicherheitsfunktionen auf Netzwerkebene, wenn Accounts kompromittiert werden |
| Keine Sitzungsverwaltung | ⚠️ Fehlende Sitzungsbeendigungsfunktionen, die eine Kennwortzurücksetzung als einzige Möglichkeit zum Erzwingen der Abmeldung erfordern, wodurch Verzögerungen in kritischen Antwortfenstern auftreten |
| Keine Notfallverfahren | ⚠️ Keine dokumentierten Zugangsverfahren für Bruchgläser oder Notfälle, Improvisieren wichtiger Entscheidungen unter Druck während aktiver Vorfälle |
Muster
| Wohin schauen | Wie gut aussieht |
|---|---|
| Ereignisüberwachungsprotokolle | ✅ Erfassen detaillierter Aktivitätsprotokolle, einschließlich Benutzeraktionen, API-Aufrufen, Authentifizierungsereignissen und Datenzugriffsmustern, mit ausreichend Details für die forensische Analyse |
| Feld-Aktivierungsprotokoll | ✅ Aktivieren des Feld-Aktivierungsprotokolls zum Beibehalten des Datenänderungsverlaufs für eingeschränkte und vertrauliche Felder mit Aufbewahrungsübereinstimmung mit regulatorischen Anforderungen (unterstützt die unbegrenzte Aufbewahrung; bestätigt den erforderlichen Zeitraum im Gegensatz zur geltenden Verordnung) |
| Unveränderlicher Speicher | ✅ Leiten Sie Protokolle an externe unveränderliche Speicher weiter, die Angreifer nicht ändern können, um die Integrität der forensischen Beweise während der gesamten Untersuchung sicherzustellen |
| Setup-Aktivierungsprotokoll | ✅ Beibehalten des administrativen Konfigurationsänderungsverlaufs für die Untersuchung nicht autorisierter Systemänderungen mit 180-tägiger Aufbewahrung |
| Scope Assessment (Scope-Bewertung) | ✅ Entwerfen Sie Berechtigungsmodelle und Datenzugriffssteuerungen, die eine schnelle Bewertung des Umfangs der Datenexposition anhand kompromittierter Accountberechtigungen ermöglichen |
| Ändern der Korrelation | ✅ Aufrechterhalten der Korrelation zwischen Setup-Aktivierungsprotokoll-Konfigurationsänderungen und Ereignisüberwachungs-Aktivitätsmustern zur Untersuchung von Angreifertechniken |
| Datenzugriffsprotokollierung | ✅ Protokollieren des gesamten Zugriffs auf eingeschränkte und vertrauliche Daten, um zu untersuchen, welche Daten während des Kompromisszeitraums offengelegt wurden |
| Integrations-Aktivierungsprotokoll | ✅ Erfassen von API-Authentifizierungs-, Autorisierungs- und Datenaustauschmustern für integrierte Systeme zur Untersuchung systemübergreifender Kompromisse |
| Beweiserhaltung | ✅ Leiten Sie Protokolle und Überprüfungsprotokolle kontinuierlich an unveränderlichen externen Speicher weiter, damit forensische Beweise erhalten bleiben und verfügbar sind, wenn ein Vorfall untersucht wird |
Antimuster
| Wohin schauen | Wie schlecht sieht |
|---|---|
| Mutable Log Storage (Speicher für stummgeschaltetes Protokoll) | ⚠️ Speichern von Protokollen nur in Salesforce, wo Angreifer mit administrativem Zugriff forensische Beweise löschen oder ändern können |
| Unzureichende Protokolldetails | ⚠️ Erfassen von Ereignissen auf hoher Ebene ohne ausreichende Details für die Untersuchung (Anmeldung aufgezeichnet, aber keine IP-Adresse, Datenzugriff aufgezeichnet, aber keine spezifischen Datensätze) |
| Keine Datenzugriffsprotokollierung | ⚠️ Fehlende detaillierte Protokollierung des Zugriffs auf eingeschränkte und vertrauliche Daten, nicht in der Lage, den Umfang der Datenexposition während der Benachrichtigung über Verstöße zu bewerten |
| Trail für fehlende Feldüberprüfung | ⚠️ Feld-Aktivierungsprotokoll für sensible Felder nicht aktivieren, da nicht bestimmt werden kann, welche Datenwerte während des Kompromisses angezeigt wurden |
| Keine Änderungskorrelation | ⚠️ Keine Korrelationsfunktion zwischen Setup-Aktivierungsprotokoll-Konfigurationsänderungen und nachfolgenden Ereignisüberwachungs-Aktivitätsmustern |
| Gelöschter Überprüfungsverlauf | ⚠️ Zulassen, dass der Überprüfungsverlauf vor dem gesetzlichen Aufbewahrungsminimum abläuft, das in der geltenden Verordnung für Ihre Bereitstellung festgelegt ist, was zu Compliance-Verstößen führt |
Muster
| Wohin schauen | Wie gut aussieht |
|---|---|
| Wiederherstellungszeitziele | ✅ Definieren und Testen des Wiederherstellungszeitziels und des Wiederherstellungspunktziels für Sicherheitsvorfallsszenarien, nicht nur für Notfallwiederherstellungsszenarien |
| Getestete Wiederherstellungsverfahren | ✅ Dokumentwiederherstellungsprozesse für kompromittierte Accounts, Massendatenexfiltration, nicht autorisierte Bereitstellungen, Berechtigungseskalation und Paketkompromittierung mit vierteljährlichen Tests |
| Sicherungsvalidierung | ✅ Validieren der Sicherungsintegrität, um die Funktion der Wiederherstellungsfunktionen bei Sicherheitsvorfällen und nicht nur bei Betriebsfehlern regelmäßig sicherzustellen |
| Wiederherstellungsfunktionen | ✅ Entwerfen von Bereitstellungspipelines mit getesteten Rollback-Verfahren für nicht autorisierte Codebereitstellungen oder bösartige Konfigurationsänderungen |
| Credential Rotation (Rotation der Anmeldeinformationen) | ✅ Implementieren von Schnellrotationsverfahren für Anmeldeinformationen für kompromittierte Integrationsaccounts, API-Benutzer und Anmeldeinformationen mit Namen |
| Berechtigungswiederherstellung | ✅ Dokumentverfahren zur Wiederherstellung des entsprechenden Zugriffs nach zu umfassenden Isolationsaktionen während der Vorfallsreaktion |
| Datenwiederherstellung | ✅ Entwerfen von Datenwiederherstellungsfunktionen zur Behebung von Datenbeschädigungen oder -löschungen infolge von Sicherheitsvorfällen im Unterschied zur Notfallwiederherstellung |
| Servicekontinuität | ✅ Architektenlösungen, damit die Reaktion auf Sicherheitsvorfälle die Kontinuität wichtiger Geschäftsfunktionen während der Untersuchung und Behebung aufrechterhält |
| Wiederherstellungsvalidierung | ✅ Testen Sie Wiederherstellungsverfahren vierteljährlich, um zu überprüfen, ob wiederhergestellte Systeme ordnungsgemäß funktionieren und ob der Kompromiss durch die Wiederherstellung nicht bestehen geblieben ist |
Antimuster
| Wohin schauen | Wie schlecht sieht |
|---|---|
| Nicht getestete Verfahren | ⚠️ Dokumentierte Wiederherstellungsverfahren, die nie durch Übungen getestet wurden, wobei bei tatsächlichen Vorfällen festgestellt wird, dass Verfahren unvollständig oder falsch sind |
| Kein RTO/RPO für Sicherheit | ⚠️ Definieren von Wiederherstellungszeitzielen nur für die Notfallwiederherstellung ohne Berücksichtigung von Sicherheitsvorfallsszenarien, die unterschiedliche Wiederherstellungsverfahren erfordern |
| Keine Wiederherstellungsfunktion | ⚠️ Fehlende Bereitstellungs-Rollback-Verfahren für nicht autorisierte Code-Bereitstellungen, die eine vollständige Überarbeitung erfordern, um bösartige Änderungen zu entfernen |
| Nicht validierte Sicherungen | ⚠️ Testen Sie niemals die Wiederherstellung von Sicherungen und stellen Sie bei Vorfällen fest, dass Sicherungen beschädigt oder unvollständig sind |
| Keine Anmeldeinformationsrotationsverfahren | ⚠️ Keine Verfahren zur schnellen Rotation von Anmeldeinformationen für kompromittierte Integrationsaccounts vorhanden, sodass kompromittierte Anmeldeinformationen während der Untersuchung aktiv bleiben |
| Manuelle Wiederherstellungsprozesse | ⚠️ Abhängig von manuellen Wiederherstellungsverfahren während Vorfällen, Einführung von Fehlern und Verzögerungen bei kritischer Geschwindigkeit |
| Keine Wiederherstellungstests | ⚠️ Niemals validieren, dass wiederhergestellte Systeme nach der Wiederherstellung ordnungsgemäß funktionieren, was potenziell zu Kompromittierungen oder Datenbeschädigungen führen kann |
Muster
| Wohin schauen | Wie gut aussieht |
|---|---|
| Kompromittierte Benutzeraccountantwort | ✅ Dokumentverfahren: Benutzer fixieren, Zurücksetzen von Anmeldeinformationen erzwingen, Setup-Aktivierungsprotokoll und Datenzugriffsprotokolle auf Kompromisszeiträume überprüfen, Umfang der Datenexposition bewerten, Benachrichtigung über Verstöße ausführen, wenn auf eingeschränkte Daten zugegriffen wird |
| Antwort auf Massendatenexfiltration | ✅ Dokumentverfahren: Sitzung sofort widerrufen, Berechtigungen einschränken, betroffene Datensätze und Klassifizierungsebenen identifizieren, Benachrichtigungen über Verstöße gegen Vorschriften innerhalb der Zeitachse ausführen, die die maßgebende Verordnung für Ihre Bereitstellung festlegt |
| Antwort auf nicht autorisierte Codebereitstellung | ✅ Dokumentverfahren: Sofortige Wiederherstellung der Bereitstellung, Überprüfung aller Änderungen anhand kompromittierter Anmeldeinformationen, Überprüfung der Pipeline-Sicherheit auf Autorisierungsumgehung, Scannen des bereitgestellten Codes auf persistente Hintertüren |
| Berechtigungseskalationsantwort | ✅ Dokumentverfahren: sofortiges Widerrufen eskalierter Berechtigungen, Überprüfen von Aktivitäten mit erhöhtem Zugriff, Untersuchen der Umgehung von Genehmigungskontrollen durch Eskalation, Implementieren von Ausgleichskontrollen |
| AppExchange-Paketkompromittierungsantwort | ✅ Dokumentverfahren: Isolieren von Paketberechtigungen, Bewerten von Daten, auf die nach Paket zugegriffen wird, Auswerten von Optionen zum Ersetzen von Paketen, Dokumentieren von Lektionen für Kriterien zur Paketbewertung |
| Erkennungssignale | ✅ Konfigurieren der Überwachung zur Erkennung jedes Szenarios: Anmeldeanomalien für kompromittierte Accounts, Berichtexportvolumen zur Exfiltration, Bereitstellungsüberwachung für nicht autorisierten Code, Berechtigungsänderungsüberwachung für Eskalation |
| Tabletop-Übungen | ✅ Durchführen von Tabletop-Übungen zum Testen von Antwortverfahren für plattformspezifische Szenarien zur Validierung der Teambereitschaft und der Verfahrensvollständigkeit |
| Antwortautomatisierung | ✅ Echtzeit-Transaktionssicherheitsrichtlinien blockieren automatisch verdächtige Aktionen, erfordern eine verstärkte Authentifizierung oder benachrichtigen Responder bei Signalen zur Erkennung hoher Konfidenz, wodurch eine automatisierte Eindämmung bereitgestellt wird, die die Antwortzeit reduziert |
Antimuster
| Wohin schauen | Wie schlecht sieht |
|---|---|
| Nur allgemeine Antwortpläne | ⚠️ Nur allgemeine Vorgehensweisen zur Reaktion auf Vorfälle ohne Salesforce-spezifische Anleitung, Improvisieren plattformspezifischer Aktionen während aktiver Vorfälle |
| Keine Erkennungskonfiguration | ⚠️ Keine Überwachung zum Erkennen plattformspezifischer Szenarien (Massenexport, Berechtigungseskalation, nicht autorisierte Bereitstellung) konfiguriert, Erkennen von Vorfällen durch Benutzerberichte oder Überprüfungen |
| Keine Tabletop-Übungen | ⚠️ Niemals Übungen für Tabletops durchführen, um die Vertrautheit des Teams mit plattformspezifischen Antwortverfahren zu überprüfen und Knowledge Lücken während tatsächlicher Vorfälle zu entdecken |
| Keine Automatisierung | ⚠️ Vollständige manuelle Reaktion auf alle Vorfälle ohne Echtzeit-Transaktionssicherheitsrichtlinien für die automatisierte Eindämmung, wodurch Verzögerungen eingeführt werden, wenn die sofortige Blockierung Schäden reduzieren könnte |
| Playbooks für fehlende Antworten | ⚠️ Fehlende dokumentierte Antwort-Playbooks für allgemeine Szenarien (kompromittierter Benutzeraccount, Datenexfiltration, Bereitstellung nicht autorisierten Codes) |
| Keine Benachrichtigungsverfahren bei Verstößen | ⚠️ Es gibt keine Verfahren für Benachrichtigungsanforderungen bei Verstößen gegen Vorschriften, sodass es schwierig ist, die Verpflichtungen während tatsächlicher Vorfälle zu verstehen, wenn die Zeitpläne eng sind |
Muster
| Wohin schauen | Wie gut aussieht |
|---|---|
| Out-of-Band-Kommunikation | ✅ Einrichten von Kommunikationskanälen, die nicht von potenziell kompromittierten Systemen (Telefonbäumen, externen Messaging-Plattformen) für die Koordination von Reaktionen abhängig sind |
| Eskalationsverfahren | ✅ Dokumenteskalationspfade von der Ersterkennung bis hin zur Benachrichtigung der Geschäftsleitung mit Kontaktinformationen und Eskalationskriterien |
| Benachrichtigungsvorlagen | ✅ Verwalten vordefinierter Benachrichtigungsvorlagen für allgemeine Vorfallstypen für eine schnelle Kommunikation mit Beteiligten, Kunden und Regulierungsbehörden |
| Identifizierung der Beteiligten | ✅ Identifizieren von Beteiligten, die für verschiedene Vorfallstypen benachrichtigt werden müssen, einschließlich Führungskräften, rechtlichen, Compliance- und betroffenen Benutzern und Regulierungsbehörden |
| Zeitachsen für behördliche Benachrichtigungen | ✅ Dokumentieren Sie die behördlichen Benachrichtigungsanforderungen der einzelnen Jurisdiktionen, die im Vergleich zur geltenden Verordnung für Ihre Bereitstellung bestätigt wurden, mit Verfahren, die die zeitnahe Einhaltung gewährleisten |
| Interne Koordinierung | ✅ Entwerfen von Verfahren zur Koordinierung von Vorfällen mit Angabe von Rollen und Zuständigkeiten (Vorfallskommandant, technischer Leiter, Kommunikationsleiter, rechtlicher Ansprechpartner) |
| Externe Koordinierung | ✅ Einrichten von Verfahren zur Koordinierung mit dem Salesforce-Support, externen forensischen Ermittlern, Rechtsbeiständen und Strafverfolgungsbehörden nach Bedarf |
| Statuskommunikation | ✅ Implementieren eines regelmäßigen Statuskommunikationsrhythmus bei aktiven Vorfällen, um Beteiligte auf dem Laufenden zu halten, ohne das Untersuchungsteam zu überfordern |
Antimuster
| Wohin schauen | Wie schlecht sieht |
|---|---|
| Keine Kommunikation außerhalb des Bandes | ⚠️ Abhängig von potenziell kompromittierten E-Mails oder internen Nachrichten für die Vorfallskoordination, wodurch die Kommunikationsfähigkeit verloren geht, wenn primäre Kanäle kompromittiert sind |
| Unklare Eskalationspfade | ⚠️ Keine dokumentierten Eskalationsverfahren, was zu Verzögerungen und Verwirrung darüber führt, wer wann benachrichtigt werden sollte |
| Keine Benachrichtigungsvorlagen | ⚠️ Verbessern von Vorfallsbenachrichtigungen bei aktiven Vorfällen unter Zeitdruck, was zu unvollständigen oder falschen Kommunikationen führt |
| Fehlende Listen der Beteiligten | ⚠️ Keine vorab identifizierten Listen von Beteiligten haben und bei Vorfällen feststellen, dass kritische Parteien (Recht, Compliance, Führungskräfte) nicht benachrichtigt wurden |
| Kein Bewusstsein für regulatorische Zeitachsen | ⚠️ Unkenntnis der regulatorischen Benachrichtigungszeiträume, die für Ihre Bereitstellung während der Reaktion auf Vorfälle gelten, fehlende Termine und Schaffung zusätzlicher Compliance-Verstöße |
| Mehrdeutige Rollen | ⚠️ Unklare Rollen und Zuständigkeiten bei der Reaktion auf Vorfälle, was zu Verwirrung darüber führt, wer befugt ist, Eindämmungsentscheidungen zu treffen |
| Keine externen Koordinierungsverfahren | ⚠️ Es gibt keine bestehenden Beziehungen oder Verfahren, um bei Bedarf den Salesforce-Support, die forensischen Ermittler oder die Strafverfolgung einzuschalten |
Muster
| Wohin schauen | Wie gut aussieht |
|---|---|
| Schuldlose Kultur | ✅ Konzentrieren Sie sich bei Überprüfungen nach einem Vorfall auf Systemverbesserungen und nicht auf individuelle Schuldzuweisungen, sodass organisatorisches Lernen ohne Angst vor Auswirkungen möglich ist |
| Dokumentation der Vorfallszeitachse | ✅ Dokument mit vollständiger Vorfallszeitachse, einschließlich anfänglichem Kompromiss, Erkennung, Antwortaktionen und Lösung mit genauen Zeitstempeln |
| Steuern der Fehleranalyse | ✅ Identifizieren, welche präventiven und detektivischen Steuerelemente den Vorfall nicht verhindern oder erkennen konnten, um architektonische Verbesserungen zu ermöglichen |
| Dokumentation zu architektonischen Schwächen | ✅ Dokumentieren von architektonischen Schwächen, die durch den Vorfall in Architekturentscheidungsdatensätzen (Architektur Decision Records, ADRs) aufgedeckt wurden, um Sicherheitsänderungen zu erfassen |
| Sanierungspriorität | ✅ Priorisieren der Sanierung anhand des Risikominderungspotenzials, wobei die Ursachen anstelle der Symptome angegangen werden |
| Lektionsfreigabe | ✅ Teilen Sie Ihre Erfahrungen über Teams und Geschäftseinheiten hinweg, um ähnliche Vorfälle in anderen Teilen der Organisation zu verhindern |
| Aktualisierungen an Erkennungsregeln | ✅ Aktualisieren von Erkennungsregeln und Verhaltensgrundlagen anhand der während der Untersuchung beobachteten Angriffstechniken |
| Verfeinerung des Antwortverfahrens | ✅ Aktualisieren von Vorfallsreaktionsverfahren basierend darauf, was während der tatsächlichen Vorfallsreaktion funktioniert hat und was nicht |
| Kennzahlenverfolgung | ✅ Verfolgen der mittleren Zeit bis zur Erkennung (MTTD), der mittleren Zeit bis zur Antwort (MTTR) und des Umfangs der Auswirkungen über die Zeit, um Trends zu identifizieren, die architektonische Investitionen erfordern |
| Rhythmus überprüfen | ✅ Führen Sie eine zeitnahe Überprüfung nach einem Vorfall durch, während die Details aktuell bleiben und Dynamik für Verbesserungen vorhanden ist |
Antimuster
| Wohin schauen | Wie schlecht sieht |
|---|---|
| Übersprungene Bewertungen | ⚠️ Überspringen von Überprüfungen nach einem Vorfall, direktes Übergehen zum nächsten Vorfall, ohne gewonnene Erkenntnisse oder architektonische Verbesserungen zu erfassen |
| Schuldzuweisungskultur | ⚠️ Fokussierung der Überprüfungen nach einem Vorfall auf individuelle Schuldzuweisungen statt auf Systemverbesserungen, Verbergen von Vorfällen und Verhindern organisatorischer Lerninhalte |
| Keine Architekturdokumentation | ⚠️ Fehler beim Dokumentieren von Änderungen an der Sicherheitsarchitektur, die durch Lerninhalte bei Vorfällen in Architekturentscheidungsdatensätzen verursacht werden |
| Symptombehandlung | ⚠️ Beheben von nur Vorfallssymptomen (kompromittiertes Kennwort) ohne Beheben der Ursachen (fehlende MFA), wodurch ähnliche Angriffe erfolgreich sein können |
| Keine Lektionsfreigabe | ⚠️ Beibehalten von Erkenntnissen zu Vorfällen im Antwortteam anstelle der organisationsübergreifenden Freigabe, wodurch ähnliche Vorfälle in anderen Geschäftseinheiten zugelassen werden |
| Keine Erkennungsaktualisierungen | ⚠️ Fehlende Aktualisierung von Erkennungsregeln oder Verhaltensgrundlagen auf der Grundlage beobachteter Angriffstechniken, die für ähnliche Angriffe anfällig bleiben |
| Keine Kennzahlenverfolgung | ⚠️ Keine Verfolgung der mittleren Erkennungszeit (MTTD), der mittleren Antwortzeit (MTTR) oder der Scope-Trends, fehlender Opportunities zum Erkennen systemischer Schwächen |
| Verzögerte Überprüfungen | ⚠️ Durchführung von Überprüfungen nach einem Vorfall Monate nach der Lösung des Vorfalls, wenn Details vergessen werden und Verbesserungsdynamik verloren geht |
| Keine Befolgung der Sanierung | ⚠️ Identifizieren von Verbesserungen während der Überprüfung nach einem Vorfall, deren Umsetzung jedoch fehlschlägt, wodurch ähnliche Vorfälle wiederholt werden können |