Das V SOC Forum, die größte Veranstaltung zur Aufdeckung und Analyse von Vorfällen in Russland, beginnt morgen. Ich bin sicher, dass viele Leser dieses Hubs anwesend sein werden und viele professionelle Berichte in diesem Bereich der Informationssicherheit hören werden. Aber zusätzlich zu den Begriffen, Definitionen und bewährten Praktiken, die im SOC-Forum behandelt werden, hat jeder von Ihnen wahrscheinlich viele unterschiedliche Meinungen über die Funktionsweise des SOC, den Schutz vor APT-Angriffen usw. gehört. Heute werden wir einige populäre Mythen und Legenden diskutieren.
Wir sind an Ihrer Meinung zu jedem von ihnen interessiert, daher warten wir auf Ihre Kommentare. Willkommen bei Katze.
Mythos 1 - SOC auf einen Streich oder die Magie der Analyse des Netzwerkverkehrs
Wenn wir mit dem Kunden über einen umfassenden Schutz vor externen Eindringlingen sprechen, hören wir sehr oft: „Und wir verfügen über Hardware A, die durch das Fachwissen des Anbieters und Informationen über neue Bedrohungen erweitert wird und uns vollständig vor externen Angriffen schützt.“ Und okay, wenn uns nach diesen Worten eine Anti-APT-Lösung mit mehreren Modulen gezeigt würde - es gäbe Fragen, aber es gäbe viel weniger. Hinter diesem "universellen Gerät" verbirgt sich meist ein gewöhnliches IDS, manchmal mit grundlegenden Funktionen zur Analyse des https-Verkehrs. Wir stellen die Expertise von Anbietern im Bereich Cybersicherheit und deren Wissen über die Aktivitäten von Hackern sowie die Nützlichkeit der Aufzeichnung und Analyse des Netzwerkverkehrs nicht in Frage (dieses Thema wird auf dem Forum sicherlich wiederholt zur Sprache gebracht), wollen uns aber dennoch auf die Grenzen des Ansatzes konzentrieren Der SOC konzentriert sich nur auf Netzwerkereignisse.
- Beginnen wir mit der Basis und einigen bereits angeschlagenen. Seit 2013 beobachten wir Hacker-Angriffe ohne den Einsatz von Malware als solche und zumindest ohne ein Modul zur Interaktion mit dem Management-Server. Zu den Angreifern gehören legitime Remoteverwaltungs-Tools, die sich mit der richtigen Konfigurationsdatei nicht von Benutzern unterscheiden, die gerne von zu Hause aus arbeiten, oder von Remoteverwaltern in Unternehmen mit geringem IT-Reifegrad. Auf der Ebene von Netzwerkereignissen ist es einfach unmöglich, eine Sitzung von einer anderen zu unterscheiden, und für eine vollständige Analyse der Methode und der Gründe für das Starten einer Sitzung sind Informationen von Endsystemen erforderlich.
- Wenn die Idee von RAT für den Angreifer widerlich ist oder sie in einem bestimmten Angriffsfall nicht anwendbar sind, kann das https-Protokoll als Interaktionsmethode eingesetzt werden. Bei einer Kopie des Datenverkehrs ist keine Protokollentschlüsselung möglich. Der Sensor muss sich daher ausschließlich mit Informationen zu den Paketköpfen begnügen. Dies ist nur sinnvoll, wenn sich die Zentrale in einem bestimmten Bereich befindet und per IP berechnet werden kann. Wir sprechen jedoch häufiger von großen Hosting-Diensten oder öffentlichen Diensten (wir haben bereits früher über das Hacken von Wordpress-Seiten geschrieben), wodurch wir nicht erkennen können, wo die legitime und wo die gefährdete Verbindung besteht.
- Bei aller Nützlichkeit zeichnen Netzwerkverbindungen (und wir sprechen normalerweise über ein Stück Eisen im Umkreisbereich) nur die Beziehung zwischen der Zentrale und der obersten Kette von Bot-Clients auf. Häufig verwenden aktuelle Angreifer eine Kette von Proxy-C & C-Servern (die erste Stufe der Infrastrukturerfassung), um mit internen Bot-Clients zu kommunizieren. Zu diesem Zeitpunkt erkennen Beschränkungen des Standorts der Ausrüstung den Angriff nicht vollständig.
- Bei all den verschiedenen Aktionen eines Angreifers muss er in regelmäßigen Abständen überhaupt nicht aus dem Internet kommen. Es ist möglich, ein RAS-Konto zu gefährden und dann unter den legitimen Rechten eines Administrators oder Benutzers zu arbeiten. Zunehmend verwenden Gruppen die Supply-Chain-Methode und starten einen Angriff, indem sie einen Auftragnehmer hacken, der häufig über einen statischen und schlecht kontrollierten Kanal zur Infrastruktur und zu denselben privilegierten Konten verfügt. Es gibt jedes Jahr immer mehr Vektoren, und sie sind weiter von den klassischen Mitteln entfernt.
- Im Allgemeinen geht es bei SOC nicht nur darum, Hackern entgegenzuwirken. Interne Angreifer, Verstöße gegen IS-Richtlinien oder Betrug, das Herunterladen oder die Beeinträchtigung von Kundendaten und vieles mehr gehören ebenfalls zu einem umfassenden SOC-Ansatz. Und es erfordert viel komplexere Techniken und Werkzeuge in seiner Arbeit.
Mythos 2 - SOC ohne Beine oder Arbeiten ohne die erste Zeile
Eine unserer Lieblingslegenden. Witze über SOC, wo nur 1 Person arbeitet, so dass er eine kleine 1., eine kleine 2. und eine kleine 3. Unterstützungslinie ist, überfluteten bereits das Internet. Aber viele Kunden, die viele verschiedene Berichte gehört und Artikel gelesen haben, sprechen über die Notwendigkeit eines magischen Stückes Eisen / Verfahren / Technologie (unterstreichen Sie es, wenn nötig), das alle Probleme der ersten Zeile automatisiert und löst. Und da im Kopf des Kunden häufig die 1. Zeile der 24 * 7-Betriebsart entspricht (alle anderen arbeiten in der Regel nach dem Standardplan), entsteht automatisch das Gefühl einer deutlichen Reduzierung der Personalkosten und es entstehen Gespräche in der Taste „1. Zeile nicht“ müssen wir gleich mit dem zweiten anfangen zu bauen. "
Das Hauptproblem dieser Legende ist unserer Meinung nach die Verwirrung in der Terminologie. Wenn der Redner über die erste Zeile spricht, wird er häufig von ITIL-Praktiken geleitet, bei denen atomare Aufgaben wirklich in die Hände von Operatoren fallen:
- Aufgabenannahme
- Klassifizierung
- Kontext hinzufügen (Asset oder Informationssystem)
- Priorisierung oder Priorisierung
- Ernennung der für das System / die Prüfung / die Warteschlange verantwortlichen Person.
Für diese Art von Aufgaben ist natürlich keine spezielle erste Zeile erforderlich: Diese Prozesse sind zwar nicht einfach, aber vollständig automatisiert. Was wir unter der ersten Zeile verstehen, haben wir bereits mehrfach geschrieben - zum Beispiel
hier ). Dennoch ist die erste Zeile kein Ersatz für die Automatisierung und nicht einmal ein Team, das ausschließlich an einem Spielbuch arbeitet. Diese Mitarbeiter sind neugierig und auf der Suche, obwohl sie nur über grundlegende Kenntnisse in der Analyse von Ereignissen und der Untersuchung von Vorfällen verfügen. In ITIL-Begriffen würde eine solche Zeile als 2nd bezeichnet, wodurch alle Fragen und Unstimmigkeiten sofort beseitigt werden.
Ich möchte die Fragen 24 * 7 nicht ignorieren. Über die Organisation der Schicht, die Effizienz der Bediener und Analytiker bei Nacht, psychische Blindheit beim Betrachten von Ereignissen ist zu viel gesagt worden. Die integralen Schlussfolgerungen sind ungefähr gleich - die erste SOC-Linie und eine Verschiebung rund um die Uhr werden ineffizient und unnötig. Unsererseits haben wir im Laufe der Jahre auch verschiedene Methoden ausprobiert, und im Moment können wir auf Bundesebene des SOC das Risiko der Ermüdung von Spezialisten während der Nachtschicht minimieren (ein kritischer Vorfall wird einfach in eine andere Zeitzone gesendet). Dennoch möchte ich einige Punkte anmerken.
- Eine Reduzierung der Schaltzeiten für den Bediener ist eine sehr gute Idee. Arbeiten nach dem Prinzip der IT-Pflicht für ein oder drei Tage in der Informationssicherheit ist eher unmöglich. Es ist jedoch sehr wichtig, den Fokus auf Vorfälle zu richten ...
- ABER ... der Operator der 1. Zeile sitzt nicht wie der Operator aus dem Film "The Matrix" und betrachtet den Strom der Rohereignisse auf der Suche nach Anomalien. Zumindest in keinem uns bekannten SOC sind wir auf einen solchen Ansatz gestoßen. Seine Aufgabe ist es, regelmäßige Berichte und Jagden zu analysieren oder Szenarien zur Identifizierung von Vorfällen auszuarbeiten. In dieser Art der Aufmerksamkeits- und Aktivitätsumschaltung (mit dem richtigen Zahlenausgleich auf der Linie) scheinen uns die Risiken einer schnellen psychischen Blindheit minimal zu sein.
Fazit: Egal wie weit die Automatisierung fortgeschritten ist, es ist üblich, an jedem kritischen Produktionsstandort einen Spezialisten zu beauftragen, der die Situation mit Maschinen und Robotern überwacht. Und wenn Ihre Gabel in diesem Fall lautet: "Kann mir die Automatisierung helfen, keine 5-6 Raten für die Schicht zuzuweisen?", Dann ist unsere Antwort eindeutig: Das kann ich nicht.
Mythos 3 - Perfekter SOC ohne eine einzige Pause, oder wir arbeiten ohne falsch positive Ergebnisse
Je mehr Sie SOC aufbauen oder mit einem MSSP / MDR-Anbieter zusammenarbeiten, desto mehr wünschen Sie sich das Ideal. Nun gingen viele Kunden durch Feuer-, Wasser- und Kupferrohre der ersten unabhängigen Annäherungen an das Projektil oder durch Piloten / Verträge mit externen Lieferanten und jeder versucht irgendwie, das Ideal anzustreben. Und das Ideal in den Augen des Leiters / der Person, die für den externen Dienst verantwortlich ist, drückt sich normalerweise in dem Satz aus: "Jeder Alarm ist ein bestätigter Vorfall" oder "Wir überwachen keinen Verdacht - wir erfassen Angriffe." Und in Bezug auf Schlüsselaspekte der Effizienz ist es schwierig, mit dieser Aussage zu argumentieren. Aber wie immer steckt der Teufel im Detail.
Die meisten SOCs zielen auf eine möglichst gründliche Analyse des Vorfalls anhand aller verfügbaren Informationen ab. Und sie nähern sich zunehmend der Perfektion, wenn sie die Gelegenheit haben,
Muschelscheite für sie zu erhalten. Betrachten wir ein Beispiel für einen Vorfall im Zusammenhang mit der Funktionsweise von Netzwerkindikatoren für Virensoftware (die Adresse für die Kommunikation mit der Zentrale). Um diese zu identifizieren, benötigen Sie lediglich einige Informationen zu Netzwerkflüssen ins Internet, z. B. Firewall-Protokolle, die jedoch häufig zu falschen Ergebnissen führen. Es reicht für den Angreifer, seinen Malware-Management-Server auf dem Host zu verstecken, und wir werden automatisch auf eine große Anzahl von Fehlalarmen stoßen. Für eine effektive Filterung und Analyse des Vorfalls ist es erforderlich, die Aktivität auf dem auslösenden Host zu lokalisieren (ausgelöste Prozesse, offene Sockets usw.). Dies führt dazu, dass Ereignisse von allen Hosts im Netzwerk verbunden werden müssen.
Total: Damit SOC nahezu die Möglichkeit hat, ausschließlich Angriffe ohne Fehlalarme zu erkennen, müssen wir eine maximale Überwachungsabdeckung der Infrastruktur sicherstellen - idealerweise, um ALLE Protokolle von ALLEN Objekten zu sammeln.
Dies führt uns zu mehreren Problemen auf einmal.
- Tatsächlicher Widerstand der IT-Abteilungen gegen die Erhöhung des Prüfungsniveaus oder die Installation zusätzlicher Systeme zur Erfassung (um Übel zu vermeiden, werden wir nicht einmal auf das Thema der Verbindung von ACS-Segmenten und -Technologen eingehen). Kompatibilitätstests, ein unvorhersehbarer Anstieg der Systemlast und andere Faktoren, die sich auf die Gesamtverfügbarkeit der Infrastruktur auswirken können, sind der Auslöser für die nächste Runde des Krieges zwischen IT- und Informationssicherheit. Und meistens hinterlassen sie nur große weiße Flecken auf der Infrastrukturüberwachungskarte des SOC.
- Aufrechterhaltung der vollen Abdeckung. Es ist nicht möglich, alle Protokolle von allen Servern zu erfassen. Beispielsweise können in neuen Systemen Protokolle einfach nicht enthalten sein. Während des Serverwechsels gehen die Überwachungseinstellungen auf den Arbeitsstationen und die Zugriffsbeschränkungen häufig teilweise oder vollständig verloren. Außerdem müssen die Einstellungen aktualisiert werden, sobald neue Angriffsvektoren angezeigt werden. All dies verursacht Betriebskosten für die Bereitstellung einer vollständigen Abdeckung, die deutlich höher sind als die Risiken einer unvollständigen Überprüfung durch die Überwachung und mit Sicherheit höher als die Kosten einer potenziellen falsch-positiven Antwort.
- Das dritte Problem führt uns zum alten DOOM-Spiel. Denn für eine vollständige Abdeckung müssen Sie unter anderem Codes eingeben.
a. IDKFA - Vollmunition in Form von endlosen Serverkapazitäten zum Sammeln und Speichern von Ereignissen und - aus wirtschaftlicher Sicht viel trauriger - endlosen Lizenzen für SIEM und andere SOC-Tools.
b. IDDQD ist ein riesiges und unsterbliches SOC-Team, das in jedem Vorfall alle offensichtlichen und indirekten Merkmale analysieren kann.
Das Zusammentreffen solcher Faktoren, Aufgaben und Budgets für die Informationssicherheit wird als Fall eines Treffens des grünen Elefanten betrachtet und ist daher keine typische Situation im Leben von SOC. Nur bestätigte Angriffe zu identifizieren (mit dem Wunsch, mit automatischen Tools so gründlich wie möglich zu analysieren), ist ein wenig fantastischer Traum moderner Sicherheitskräfte.
Anstelle eines Nachwortes
Wir haben versucht, nur die häufigsten Mythen der SOC-Bauindustrie zu diskutieren. In komplexen Situationen, in denen Prozesse zum Überwachen und Reagieren auf Vorfälle eingeleitet werden, empfehlen wir Ihnen daher, eingehende Informationen möglichst skeptisch zu betrachten, sie in verschiedenen Quellen zu überprüfen und die Angst vor
Fälschungen unbestätigter Meinungen zu maximieren.
Und möge die Macht mit dir sein;).