Heading

Suchen Sie den Campus Incident Response Plan? Gehen Sie stattdessen zu Information Security Documents. Der folgende Leitfaden zur Planung der Reaktion auf Vorfälle bezieht sich auf Systeme und Anwendungen, die die MSSEI-Richtlinie des Campus einhalten müssen.

Die Sicherheitsrichtlinien der UC Berkeley schreiben die Einhaltung des Mindestsicherheitsstandards für elektronische Informationen für Geräte vor, die mit abgedeckten Daten umgehen.

Anforderung

Jeder Systemverantwortliche muss mindestens einmal jährlich einen Notfallplan auf Systemebene entwickeln und überprüfen, der Folgendes enthält:

• Namen und Kontaktinformationen für das lokale Notfallteam, einschließlich:
  • Sicherheitskontakt und stellvertretende(r) Kontaktperson(en), die über Systemadministratorenrechte, technisches Wissen über das System und Kenntnisse über den Standort des Notfallplans verfügen.
  • Eine lokale Autorität/Entscheidungsträger für das System, der die geschäftlichen Auswirkungen des Systems und seiner Nichtverfügbarkeit versteht.
• Systemdetails oder Verweis auf den Ort solcher Informationen, einschließlich:
  • Datenflussdiagramme
  • Netzwerkdiagramme
  • System-Hardware-Inventar (wie von der Kontrolle „Jährliche Registrierung“ gefordert)
  • Protokollierungsinformationen (wie von der Kontrolle „Audit Logging“ gefordert)
• Prozeduren für die Meldung und Behandlung eines vermuteten Vorfalls, definiert pro Rolle: Sys Admin, Bulk Access User, End User, z.B.,
  • Wer zu kontaktieren ist
  • Wie man potenzielle Beweise NICHT manipuliert (d.h., keine forensischen Versuche unternehmen, wenn sie nicht autorisiert sind)

Risikobeschreibung

Wenn Benutzer und Systemadministratoren die Verfahren zur Reaktion auf einen Vorfall nicht kennen, verzögert sich die Reaktion und Beweise können beschädigt werden oder verloren gehen, was die potenziellen Auswirkungen eines Vorfalls stark erhöht.

Empfehlungen

Um sicherzustellen, dass Informationssicherheitsereignisse und Schwachstellen in Verbindung mit abgedeckten Kernsystemen so kommuniziert werden, dass rechtzeitig Korrekturmaßnahmen ergriffen werden können, sollten Ereignisberichts- und Eskalationsverfahren in einem formalen Incident Response Plan dokumentiert werden. Die Verfahren zur Reaktion auf Vorfälle gliedern sich typischerweise in die folgenden Phasen:

• Erkennung – Erste Bewertung und Einstufung von Sicherheitsvorfällen auf abgedeckten Kernsystemen, einschließlich der Eskalation an das Information Security Office (ISO) und der Zuweisung einer Prioritätsstufe für den Vorfall.

• Analyse – Durchführung einer detaillierten Auswirkungsanalyse, um die richtigen Prioritäten für zusätzliche Reaktionsmaßnahmen zu setzen, die bei Verstößen mit hoher Auswirkung erforderlich sind. Beginnen Sie mit Beweissicherungs- und Eindämmungsaktivitäten sowie mit der ersten Wiederherstellung.

• Wiederherstellung – Je nach Schwere des Vorfalls, mindern Sie die Auswirkungen des Vorfalls, indem Sie die Eindämmungs- und Ausrottungsaktivitäten abschließen und sich schließlich von dem Vorfall erholen. In dieser Phase wird oft wieder auf die Erkennung und Analyse zurückgegriffen – zum Beispiel, um festzustellen, ob während der Beseitigung eines Malware-Vorfalls weitere Hosts mit Malware infiziert wurden.

• Nach dem Vorfall – Nachdem der Vorfall angemessen behandelt wurde, geben Sie einen Bericht heraus, in dem die Ursache und die Gesamtkosten des Vorfalls detailliert beschrieben werden, zusammen mit den Schritten, die das Unternehmen unternehmen sollte, um zukünftige Vorfälle zu verhindern.

Alle Mitarbeiter auf dem Campus, Auftragnehmer und Benutzer von Drittanbietern sollten auf die Verfahren zur Meldung der verschiedenen Arten von Ereignissen aufmerksam gemacht werden, die Auswirkungen auf die Sicherheit der abgedeckten Geräte haben könnten. Sie sollten aufgefordert werden, jeden Informationssicherheitsvorfall so schnell wie möglich an die festgelegte Kontaktstelle zu melden.

Was ist ein Sicherheitsvorfall?

Ein Sicherheitsvorfall im Kontext dieser MSSEI-Anforderung ist ein Ereignis, das den Betrieb von abgedeckten Kernsystemen oder

die Vertraulichkeit oder Integrität von abgedeckten Datenbeständen gefährdet oder gefährden könnte

Ein Sicherheitsvorfall kann einen oder alle der folgenden Punkte beinhalten:

• eine Verletzung der Computersicherheitsrichtlinien und -standards des Campus
• unautorisierter Computer- oder Datenzugriff
• Vorhandensein einer bösartigen Anwendung, z. B. eines Virus
• Vorhandensein von unerwarteten/unüblichen Programmen
• eine Denial-of-Service-Bedingung gegen Daten, Netzwerk oder Computer
• Missbrauch von Service, Systeme oder Informationen
• Physikalische oder logische Beschädigung von Systemen
• Diebstahl von Computern

Komponenten eines Incident Response Plans für einzelne Systeme und Dienste

Ressourcenbesitzer und Ressourcenverwalter sollten sicherstellen, dass ihr Incident Response Plan die folgenden Komponenten enthält. Wir stellen dieses TEMPLATE für Vorfallsreaktionspläne für einzelne Systeme und Dienste zur Verfügung.

• Namen, Kontaktinformationen und Zuständigkeiten des lokalen Vorfallsreaktionsteams, einschließlich:

  • Vorfallsverantwortlicher: Sicherheitskontakt und stellvertretende(r) Kontaktperson(en), der/die über Systemadministratorenrechte, technisches Wissen über das System und Kenntnisse über den Standort des Vorfallsreaktionsplans verfügt/verfügen.
  • Ressourcenmanager: Eine lokale Autorität/Entscheidungsträger für das System, der die geschäftlichen Auswirkungen des Systems und seiner Nichtverfügbarkeit versteht. Der Ressourceneigentümer sollte die Aufgaben des Ressourcenmanagers übernehmen oder einen Mitarbeiter des Campus für diese Rolle benennen.

• Systemdetails oder Verweis auf den Ort solcher Informationen, einschließlich:

  • Datenflussdiagramme
  • Netzwerkdiagramme
  • System-Hardware-Inventar (wie von der Kontrolle „Jährliche Registrierung“ gefordert)
  • Protokollierungsinformationen (wie von der Kontrolle „Audit-Protokollierung“ gefordert)

• Verfahren zur Meldung und Behandlung eines vermuteten Vorfalls, einschließlich:

  • Füllen Sie einen Bericht zur Aufnahme des Vorfalls aus, der folgende Informationen enthalten sollte:
    • Name und Telefonnummer der Kontaktperson
    • IP-Adresse, Hostname und physischer Standort des betroffenen Systems
    • Name des betroffenen Systems (wie in NetReg angezeigt)
    • Welche Arten von betroffenen Daten waren auf/von dem betroffenen Host verfügbar?
      • Voller Name
      • Sozialversicherungsnummer
      • Führerscheinnummer oder kalifornische Personalausweisnummer
      • Kredit- oder Finanzkontonummer Kartennummer (einschließlich PIN oder Ablaufdatum)
      • Bankkontonummer (einschließlich PIN oder anderer Zugangsdaten)
      • Medizinische Daten oder Krankenversicherungsdaten
      • Sonstiges
    • Für jede Datei, die persönliche Daten enthält, geben Sie an:
      • Name der Datei
      • Größe der Datei
      • Speicherort der Datei (vollständiger Pfad)
    • Wurden die Daten verschlüsselt, und wenn ja, wie?
    • Beschreiben Sie die Auswirkungen des Vorfalls (z. B. die Anzahl der kompromittierten Datensätze oder die Anzahl der Benutzer, die von einem nicht verfügbaren System betroffen sind)
    • Beschreiben Sie den Sicherheitsvorfall, einschließlich des zeitlichen Ablaufs der Aktivitäten, wie der Vorfall erkannt wurde, die Auswirkungen (geschäftlich und technisch) des Vorfalls, Details zu den vorhandenen Abhilfemaßnahmen, z. B. welcher Datenverschlüsselungsmechanismus verwendet wurde.
    • Dokumentieren Sie die Maßnahmen, die für das angegriffene System ergriffen wurden (wie ist der aktuelle Zustand des Systems usw.)

• Melden Sie den Sicherheitsvorfall an die ISO (E-Mail [email protected]*) und fügen Sie den Aufnahmebericht bei. Wir werden einen Sicherheitsanalysten zuweisen, der alle Folgeaktivitäten zur Behebung des Vorfalls koordiniert.

  • Nachdem ein Sicherheitsvorfall an ISO gemeldet wurde, trennen Sie die Verbindung zum betroffenen System nicht und melden Sie sich nicht an, bis Sie vom ISO-Sicherheitsanalysten dazu angewiesen werden.
  • Serviceunterbrechungen, die nicht auf böswillige Aktivitäten zurückzuführen sind, sollten dem zuständigen IT-Supportpersonal gemeldet werden. Weitere Informationen zur Meldung verschiedener Arten von Vorfällen finden Sie auf der Sicherheits-Website. Zum Beispiel sollte für die meisten campusweiten Unternehmensanwendungen eine Dienstunterbrechung an die Campus Shared Services IT gemeldet werden.

• Reagieren Sie auf den Sicherheitsvorfall zeitnah, basierend auf der Richtlinie zur Priorisierung von Vorfällen.

*Beachten Sie, dass die E-Mail-Adresse [email protected] nur verwendet werden sollte, um von MSSEI abgedeckte Sicherheitsvorfälle zu melden. Nicht von MSSEI abgedeckte Sicherheitsvorfälle sollten an [email protected] gemeldet werden.

Priorisierung von Sicherheitsvorfällen

Um die Priorisierung des Zeitplans und der Ressourcen für den Einsatz von Abhilfemaßnahmen zu unterstützen, müssen die Eigentümer und Verwalter von Ressourcen die Auswirkungen eines Sicherheitsvorfalls anhand der folgenden Faktoren bewerten:

• Wie sich der Vorfall auf die bestehende Funktionalität der betroffenen Systeme auswirkt
• Ob der Vorfall die Vertraulichkeit oder Integrität von abgedeckten Daten UC P4 (ehemals UCB PL2) oder nicht abgedeckten Daten verletzt
• Wie viel der Benutzerpopulation von dem Sicherheitsvorfall betroffen ist
• Wie groß ist die Reputation/finanzielle Auswirkung auf den Campus

Anhand der oben aufgeführten Faktoren als Ausgangspunkt, sollten Sicherheitsvorfälle bewertet und von dem designierten Vorfallbearbeiter und Ressourcenmanager einer hohen oder niedrigen Prioritätsstufe zugeordnet werden. Zu den zu berücksichtigenden Faktoren gehören nicht nur die aktuellen Auswirkungen des Vorfalls, sondern auch die wahrscheinlichen zukünftigen Auswirkungen des Vorfalls, wenn er nicht sofort behoben wird. Alle Vorfälle mit hoher Priorität sollten sofort an die ISO gemeldet werden, wobei die Verfahren zur Behandlung von Vorfällen einzuhalten sind. Sobald ein Sicherheitsvorfall dem ISO-Analysten gemeldet wurde, wird die Prioritätseinstufung nach einer zusätzlichen Analyse des Ereignisses bestätigt oder überarbeitet.

Beispiele für Sicherheitsvorfälle mit hoher Priorität sind ein Ereignis, das zum Verlust einer kritischen Funktion für die Benutzer auf dem gesamten Campus oder in einer Abteilung führt. Ebenso muss eine Verletzung der Vertraulichkeit verdeckter Daten, die mehr als 500 Benutzer betrifft, mit hoher Priorität eingestuft werden. Die Prioritätsstufe des Vorfalls kann in späteren Phasen des Vorfallsreaktionsprozesses überarbeitet werden, nachdem zusätzliche Beweisanalysen ein genaueres Verständnis der Auswirkungen des Vorfalls liefern. Jede Aktualisierung der Prioritätsstufe sollte von den Mitgliedern des lokalen Incident Response Teams und einem ISO-Analysten überprüft werden.

Die folgende Tabelle gibt zusätzliche Hinweise zur zeitlichen Beanspruchung der Mitglieder des Incident-Response-Teams im Falle eines Sicherheitsvorfalls (ISO-Analyst, Incident Handler, Ressourcenmanager):

Phasen der Reaktion auf einen Vorfall	Vorfall mit hoher Priorität	Vorfall mit niedriger Priorität
Erkennung	Sofort	8 Stunden
Analyse	Ressourcenmanager und Incident-Handler arbeiten mit ISO-Analyst* auf dedizierter, kontinuierlicher Basis.	Vorfallbearbeiter zugewiesen und engagiert, um mit dem ISO-Analysten während der normalen Geschäftszeiten am Fall zu arbeiten.
Wiederherstellung	Ressourcenmanager und Vorfallbearbeiter arbeiten mit dem ISO-Analysten* auf dedizierter, kontinuierlicher Basis zusammen.	Vorfallbearbeiter arbeiten mit dem ISO-Analysten an einem Fall, wenn Zeit/Ressourcen verfügbar sind.
Post-Incident	Unfallbearbeiter, der mit dem ISO-Analysten an dem Fall arbeitet, sobald Zeit/Ressourcen verfügbar sind.	Unfallbearbeiter, der mit dem ISO-Analysten an dem Fall arbeitet, sobald Zeit/Ressourcen verfügbar sind.

* Fälle mit hoher Priorität können andere Beteiligte auf dem Campus einbeziehen, einschließlich IT Policy, Campus Counsel und andere Vertreter der Campusleitung.

Definitionen der Reaktionsphase auf Vorfälle:

• Erkennung – Hier wird die maximale Zeitspanne angegeben, die vom Zeitpunkt der Entdeckung des verdächtigen Ereignisses bis zum Abschluss der folgenden Aktionen vergehen soll:

  • Erstbeurteilung und Triage
  • Erste Prioritätsstufe auf Basis des Eingangsberichts festlegen
  • Vorfall an ISO melden
  • ISO-Analyst wird zugewiesen, um mit Incident Handler und Ressourcenmanager zusammenzuarbeiten
  • Vorfall in das ISO-Ticketing-System eingeben
• Analyse – Die Zeitspanne, in der der Vorfall bearbeitet wird. Der Zeitraum im Lebenszyklus des Vorfalls, in dem eine aktive Reaktion auf den Vorfall erforderlich ist, um die erfolgreiche Lösung des Vorfalls zu gewährleisten. Dazu gehören typischerweise System- oder Serviceausfälle und/oder dringende Beweissicherungen. Außerdem wird die Rechtmäßigkeit des Vorfalls überprüft, die Priorisierung bestätigt und eine angemessene Eskalation auf der Grundlage der Auswirkungen des Vorfalls vorgenommen. Typische Aktivitäten sind:

  • Bewertung, Triage, Eindämmung, Beweissicherung, erste Wiederherstellung

• Wiederherstellung – Die Zeitspanne im Lebenszyklus des Falls, in der keine aktive Reaktion auf den Vorfall erforderlich ist, um den Fall erfolgreich zu lösen. Typische Aktivitäten sind:

  • Beweissammlung, Analyse und Untersuchung, Forensik, Behebung, vollständige Wiederherstellung, Post-Mortem.

• Post-Incident – Nachdem der Vorfall adäquat behandelt wurde, gibt das Incident Response Team einen Bericht heraus, der die Ursache und die Kosten des Vorfalls sowie die Schritte, die die Organisation unternehmen sollte, um zukünftige Vorfälle zu verhindern, detailliert beschreibt.

Die Definitionen stammen von http://www.first.org/_assets/resources/guides/csirt_case_classification….

Zusätzliche Ressourcen

• NIST Computer Security Incident Handling Guide, http://csrc.nist.gov/publications/nistpubs/800-61rev2/SP800-61rev2.pdf

• Software Engineering Institute Handbook for Computer Security Incident Response Teams (CSIRTs),http://www.sei.cmu.edu/library/abstracts/reports/03hb002.cfm

• Incident Response Plan TEMPLATE für einzelne Systeme und Dienste

• Campus Incident Response Plan