In addition to posts and articles, LinkedIn also has a ‘Contribute expertise’ section. I tried it out.
(german translation can be found at the bottom of this post)
I wanted to take part in one of these specialist contribution topics. Unfortunately, only 750 characters were allowed, so I put my point of view in my article and put the link to the article in the field where the post should be written.
The Topic / Case Study I participated in is called: A vendor experiences a data breach. How do you protect sensitive information?
The URL to this Topic: https://www.linkedin.com/advice/1/vendor-experiences-data-breach-how-do-you-m1u0f?trk=SB
My Opinion after reading all the feedbacks from all oher Authors in it is as follows:
When all the responses are evaluated, it will be possible to compile certain tasks that will allow for the construction of an adequate incident response process. However, you all follow a playbook, relying on knowledge drawn from security frameworks. Anyone who has experienced a real incident knows that what you envision is far from reality. None of you considered managing the technicians and system administrators in a way that allows for analyzing the incident while systems are still operational. Catching an attack in the act is far more effective. You could, for example, redirect an attacker to a honeypot while assembling the crisis management team. The crisis team then decides collectively on all subsequent steps, such as how to communicate internally and externally, which immediate measures to take, how to interact with the public and customers, etc.
Different Companies, Different Playgrounds
Every company, every business, is structurally completely different. Each company may require its own highly customized incident response processes, as the teachings we often read in security frameworks are merely suggestions and are not representative of all cases. Companies with multiple sites, connected via P2P, using shared services, managing diverse internet connections, MPLS, and VPN lines, certainly won’t have their „stolen data“ sitting on a hard drive in a rack server. Nor can you just pull out a process handbook and start following steps like many here have described: isolate, understand the situation, communicate to everyone, take additional measures, etc. It doesn’t work that way, my friends. Doing so may cause more harm than you’re trying to fix.
Ideally, there would be data classification and a prior risk analysis accompanied by an appropriate impact assessment for a data leakage incident. I also didn’t see any feedback mentioning the involvement of law enforcement during the technical analysis. This is not only a legal requirement (see, for example, GDPR), but law enforcement can also create a trace file and potentially identify the source of the breach during the attack or, at the very least, monitor the activity. You might imagine data exfiltration as if the data is simply stored on a single PC. Now imagine trying to handle this in a hyperscaler data center with thousands of nodes, countless redundancies, and distributed storage systems.
Build your processes individually, establish effective risk management, include data leakage incidents actively in your incident response processes, conduct regular crisis drills, and document your business continuity processes. Practice this regularly with your crisis management team, along with all key decision-makers. The most important thing, however, is to analytically assess suspicious indicators: Is it truly an incident or a false positive? Your credibility depends on this distinction.
(German Translation)
—
Wenn man all die Antworten auswertet, wird man einige Tasks zusammenstellen können, die es erlauben, einen adäquaten Incident Response Prozess zu bauen. Doch ihr geht alle nach einem Bilderbuch, das Wissen, was man aus Sicherheitsframeworks kennt. Wer einen echten Vorfall erlebt hat, der wird wissen, dass das, was ihr euch vorstellt, nicht der Realität entspricht. Niemand von euch kam auf die Idee, Techniker und Systemadministratoren so zu steuern, dass der Vorfall während des Betriebs analysiert werden kann. Denn auf frischer Tat ist die Verfolgung eines Angriffs viel effektiver. Man könnte z.B. einen Angreifer auf ein Honeypot umleiten, während der Krisenstab einberufen wird.
—
Der Krisenstab entscheidet dann gemeinsam über die nächsten Schritte, z.B. wie intern und extern kommuniziert wird, welche Sofortmassnahmen ergriffen werden, wie man mit der Öffentlichkeit und den Kunden umgeht, etc. Jede Firma, jedes Unternehmen ist strukturell völlig anders aufgebaut. Jede Firma könnte ihre eigenen, hoch angepassten Incident Response Prozesse benötigen, da die Lehre, die wir oft in Sicherheitsframeworks lesen, nur eine Art Vorschlag darstellt und nicht für alle Fälle repräsentativ ist. Unternehmen mit mehreren Standorten, P2P-Verbindungen, geteilten Diensten, verschiedenen Internetanbindungen, MPLS- und VPN-Leitungen haben ihre „gestohlenen Daten“ sicher nicht auf einer Festplatte in einem Rackserver.
—
Ebenso kann man nicht einfach ein Prozesshandbuch auspacken und loslegen, wie es die meisten hier beschrieben haben: Abriegeln, die Lage verstehen, an alle kommunizieren, zusätzliche Massnahmen ergreifen, usw. So funktioniert das nicht, meine Freunde. Dabei macht man am Ende oft mehr kaputt, als man versucht, wieder in Ordnung zu bringen. Idealerweise gibt es eine Datenklassifizierung und eine zuvor durchgeführte Risikoanalyse mit einer adäquaten Impact-Analyse bei einem Datenleck-Vorfall (Data Leakage Incident). Ich habe auch in keinem Feedback gesehen, dass während der technischen Analyse gegebenenfalls die Strafverfolgungsbehörden eingeschaltet werden sollten.
—
Dies ist einerseits von der Gesetzgebung vorgeschrieben (siehe z.B. DSGVO), andererseits können die Behörden einen Trace-Fall anlegen und so während des Angriffs im besten Fall die Quelle ermitteln oder zumindest die Aktivitäten überwachen. Sie stellen sich vielleicht vor, dass der Datenabgriff nur auf einem PC stattfindet. Stellen Sie sich nun vor, wie Sie das in einem Hyperscaler-Rechenzentrum mit tausenden Nodes, unzähligen Redundanzen und verteilten Speichersystemen handhaben wollen. Baut eure Prozesse individuell auf, etabliert ein effektives Risikomanagement, schliesst Vorfälle von Datenlecks aktiv in eure Incident Response Prozesse ein und führt regelmässige Krisenübungen durch.
—
Dokumentiert die Business-Continuity-Prozesse und übt dies regelmässig mit eurem Krisenstab gemeinsam, inklusive aller Entscheider. Das Wichtigste ist jedoch, dass ihr Verdachtsmomente analytisch bewertet: Ist es sicher ein Incident oder nur ein False Positive? Eure Glaubwürdigkeit hängt davon ab.
