Sie wissen vielleicht wenig über den SOC, aber es wird intuitiv klar sein, dass bei seiner Arbeit nur zwei Dinge am wichtigsten sind: Vorfälle identifizieren und darauf reagieren. Wenn Sie sich jedoch nicht mit der Situation befassen, in der es sich um komplexe interne Betrugsfälle oder Anzeichen der Tätigkeit einer Berufsgruppe handelt, besteht die Antwort in der Regel aus einer Reihe sehr einfacher technischer Maßnahmen (Entfernung des Viruskörpers oder der Software, Sperrung des Zugriffs oder Kontos) und organisatorischen Maßnahmen (Klärung von Informationen von Benutzern oder Überprüfung und Anreicherung der Analyse führt zu Quellen, die für die Überwachung nicht zugänglich sind). Aus einer Reihe von Gründen hat sich der Kundenreaktionsprozess in den letzten Jahren jedoch erheblich geändert, und dies erforderte Änderungen seitens des SOC. Da es sich um eine Antwort handelt, bei der „nicht nur alles“ wichtig ist - und Genauigkeit,Vollständigkeit und Schnelligkeit - Es ist sehr wahrscheinlich, dass Sie den Vorfall nicht normal behandeln können, wenn Ihr interner oder externer SOC die neuen Anforderungen für diesen Prozess nicht berücksichtigt.
Mittlerweile gibt es viele unserer Kunden, die es leichter haben, eine Antwort als "Full Cycle" -Dienst zu erhalten. In diesem Fall blockieren wir einen Angriff auf die Abwehrkräfte des Unternehmens und begleiten den Reaktionsprozess im Verantwortungsbereich des IT-Dienstes. Zum Beispiel helfen wir bei der Rechtfertigung der Blockierung, die theoretisch zu Problemen in Geschäftsprozessen führen kann, oder wir beraten bei Arbeiten, die teilweise auf ihrer Seite ausgeführt werden müssen - Kontosperrung, Hostisolation usw.
Die Mehrheit zieht es jedoch immer noch vor, sich selbst auf technische Reaktionen einzulassen, und sie verlangen von uns die rechtzeitige Erkennung eines Vorfalls, die Analyse und Filterung von Fehlalarmen sowie die Bereitstellung analytischer Informationen mit Empfehlungen zu vorrangigen Maßnahmen als Reaktion auf einen Vorfall.
Wer war zuvor an diesem Prozess beteiligt und für das Ergebnis des Kunden verantwortlich? In der Regel arbeiteten ein oder zwei Spezialisten für Informationssicherheit, die die Reaktion mit anderen Aufgaben der Abteilung kombinierten und nicht immer über fundierte Nischenkenntnisse in der Angriffsanalyse verfügten (wie Sie aus dem vorherigen Absatz ersehen können, war dies nicht erforderlich). Trotzdem ging es immer um Spezialisten für Informationssicherheit, die die Risiken, Bedrohungen und den Kontext des Geschehens verstehen.
In letzter Zeit wird die Verantwortung für die Vollständigkeit und Aktualität der Reaktion auf Kundenseite zunehmend auf Informationssicherheit und IT-Services verteilt, und hier ist der Grund dafür.
Erstens hat die Anzahl der Vorfälle und der Verdacht auf Vorfälle erheblich zugenommen. Wenn früher die durchschnittliche Anzahl der Benachrichtigungen mit ein oder zweihundert pro Monat gemessen wurde, hat sie sich jetzt um ein Vielfaches erhöht. Ein Teil des Problems ist das Wachstum der Entropie in Unternehmensinfrastrukturen aufgrund ständiger (und nicht immer fester) Änderungen, die durch den heute allgemein als Modebegriff "Digitalisierung" oder "digitale Transformation" bezeichneten Begriff verursacht werden. Ein Nebeneffekt besteht darin, dass Benutzeraktionen vielfältiger werden und technische Lösungen sie eher als Verhaltensanomalien klassifizieren, die wiederum von einem Sicherheitsbeauftragten für einen Angreifer gehalten werden können. Dies sind beispielsweise falsch positive Ergebnisse des ersten Typs.
Zweitens nimmt natürlich auch die Aktivität von Cyberkriminellen stetig zu (mit anderen Worten, die Anzahl der Angriffe nimmt zu). Dies wird von uns, anderen Akteuren der Branche und den Kunden selbst festgestellt. Infolgedessen muss der SOC ständig immer cleverere Szenarien zur Erkennung von Angriffen erfinden und sicherstellen, dass diese mit dem Kunden verbunden sind. Dies führt natürlich auch zu einer Zunahme der Anzahl von Vorgängen, einer Zunahme des Nichtdeterminismus der Kundenaktionen und der Notwendigkeit, dass Informationen über den Vorfall einen externen Kontext enthalten (dessen Arbeitsstation es ist, ist es im Unternehmen üblich, RAS-Tools zu verwenden, und wenn ja, welche, wer Sie können für was und dergleichen verwendet werden.
Tatsächlich führt dies dazu, dass immer mehr Unternehmen versuchen, den externen SOC auf die direkte Interaktion nicht mit der Informationssicherheit, sondern mit den IT-Abteilungen zu übertragen, um den Reaktionsprozess zu beschleunigen. Und das ist ganz logisch: Vorfälle, bei denen Software entfernt oder das Konto gesperrt werden muss, werden direkt an die IT weitergeleitet und erfordern eine Netzwerkisolation des Hosts - an Netzwerkabteilungen + Helpdesk usw. Wenn das Unternehmen über ein eigenes Überwachungszentrum verfügt, muss es häufig Trigger vom SIEM-System an die IT übertragen.
Jede Änderung des Prozesses birgt jedoch das Risiko einer Verlangsamung, das Risiko unvollständiger Informationen für die Parteien und letztendlich eine Verringerung der Effizienz. Glücklicherweise verstehen die meisten Unternehmen dies, und daher besteht (und manchmal aufgrund gesetzlicher Anforderungen - insbesondere bei der Einrichtung von GosSOPKA-Zentren) eine wachsende Nachfrage nach einer Überprüfung des tatsächlichen Reaktionsniveaus - Vollständigkeit, Qualität und Zeitpunkt der Empfehlungen der IT- und Informationssicherheitsabteilungen Unternehmen.
Vor der Durchführung von Audits muss den Mitarbeitern jedoch ein Tool zur Erzielung des Ergebnisses zur Verfügung gestellt werden. Mit anderen Worten, der SOC muss die Ergebnisse der Analyse jedes Vorfalls anpassen, um ein klares Routing in der IT zu gewährleisten. Durch Versuch und Irrtum haben wir eine Liste der Anforderungen für an den Kunden gesendete Vorfallinformationen zusammengestellt.
In diesen Ergebnissen der Analyse des Vorfalls sollte der für die technische Reaktion verantwortliche Mitarbeiter eindeutig identifiziert
werden. Was sind die Fallstricke: Um eine solche verantwortliche Person korrekt zu identifizieren, ist es erforderlich, den Ort des Vorfalls genau zu identifizieren - eine bestimmte Abteilung, die Kritikalität des Gastgebers, seine Geschäftszugehörigkeit, die Art des Vorfalls. Dies erfordert ein sehr tiefes Eintauchen in die Infrastruktur des Kunden in der Bestandsphase (und vor allem eine ständige Aktualisierung dieser Daten).
Dieselben Informationen werden benötigt, um die Kritikalität eines Vorfalls zu bestimmen. Zum Beispiel ist die Bank bereit, auf eine Virusinfektion eines Autos in einer Filiale in Magadan viel langsamer und mit Hilfe eines lokalen Informationssicherheitsspezialisten zu reagieren. Wenn es sich um das lokale AWP des KBR handelt, erfordert der Vorfall eine sofortige Reaktion und Beteiligung, einschließlich des CISO des Kunden zur Koordinierung des Risikos sowie der Spezialisten des Kommunikationszentrums vor Ort, um den Host sofort zu isolieren.
Um auf einen Angriff auf eine Webanwendung im E-Commerce-Segment reagieren zu können, müssen in der Regel nicht nur Sicherheitspersonal, sondern auch Anwendungsspezialisten einbezogen werden, die die mit der Implementierung verbundenen Risiken genauer bestimmen und Informationen zu Bestellungen aus der Datenbank auf demselben Host entladen können. Im Gegenteil, in keinem Fall sollten Antragsteller (sie sind einer der potenziellen Angreifer) oder sogar IT-Spezialisten beteiligt sein. Zusätzlich zur Informationssicherheit ist jedoch häufig die Teilnahme des Dienstes für wirtschaftliche Sicherheit erforderlich.
Alle diese Szenarien - wen wir wann, zu welchem Zeitpunkt und zu welchem Zweck einbeziehen - müssen im Voraus ausgearbeitet und mit dem Kunden vereinbart werden. SOC kennt sich besser mit Informationssicherheit aus, aber der Kunde kennt sein Geschäft besser und weiß, welche Risiken für ihn am kritischsten sind. Daher werden die Skripte gemeinsam entwickelt.
Dies gilt auch für die Beschreibung der Bedrohung und ihrer Risiken sowie für den Detaillierungsgrad in der Beschreibung der Reaktionsempfehlungen. Darüber hinaus sollte die Reihenfolge der erforderlichen Aktionen idealerweise in einen Baum von Pflicht- und Hilfsereignissen unterteilt werden. Wenn der SOC beispielsweise den Start des Remote Admin-Tools auf dem Endhost aufzeichnet, die Überwachungsebene jedoch nicht ausreicht, um die Benutzeraktivität von einem möglichen Start einer Hintertür durch einen Angreifer zu unterscheiden, ist der erste und obligatorische Punkt die Kommunikation des Spezialisten mit dem Benutzer, um herauszufinden, ob er diese Aktivität initiiert hat. Wenn die Antwort Ja lautet, handelt es sich um eine regelmäßige Aktivität oder höchstens um einen Verstoß gegen die Informationssicherheitsrichtlinie. Wenn dies negativ ist, kann es Teil eines Hackerangriffs sein und erfordert eine völlig andere Reaktionsarbeit.
Die Überprüfung der Antwortergebnisse sollte die Möglichkeit der technischen Kontrolle sowohl der Tatsache der Umsetzung der Empfehlungen (mithilfe von Protokollen in SIEM oder anderen Tools) als auch der Tatsache enthalten, dass der Vorfall in Zukunft nicht mehr auftreten wird.
Lassen Sie uns das Beispiel mit der Ausführung von RAT auf dem Host fortsetzen. Zum Beispiel gingen wir zum ersten Zweig - Benutzeraktivität, die gegen Richtlinien zur Informationssicherheit verstieß. In diesem Fall wird dem IT-Service empfohlen, die RAT auf dem Host zu entfernen. Zusätzlich zum kontrollierten Start des Löschskripts oder der Überprüfung auf das Fehlen / Vorhandensein des Dienstprogramms auf dem Host muss das Inventarmittel mit dem alten Vorfall verknüpft sein, wenn es erneut ausgelöst wird. Dies signalisiert nicht nur einen wiederholten Verstoß, sondern auch eine mögliche mangelhafte Umsetzung der Empfehlung durch die Antwort.
Schließlich ist der Kontext oder die Delta-Nachbarschaft des Vorfalls wichtig. Es ist sehr wichtig, was genau mit dieser Maschine / diesem Konto während des letzten Zeitintervalls passiert ist, ob es ähnliche oder potenziell verwandte Vorfälle gab, die in der Kill-Kette gesammelt werden konnten. Mit diesen Informationen können Sie schnell feststellen, ob Sie das Sicherheits- oder Incident-Response-Team des Anbieters sofort in den Incident einbeziehen müssen.
Jeder SOC sucht nach seinen eigenen Antworten auf diese Herausforderungen und kann diese Aufgaben mit verschiedenen Tools ausführen. Die Hauptsache ist, zu kontrollieren, ob er dies im Prinzip tut. Da bei kleineren Vorfällen Verzögerungen und Verzögerungen bei der Reaktion nicht wahrnehmbar sein können und bei kritischen Vorfällen ein unregulierter Prozess einfach nicht funktioniert. Und die Schuldigen, als ob "nicht sein wird"