Detaillierte Ursachenanalyse zum Shh/Updater-B False Positive-Vorfall

4. Oktober 2012

Einleitung

Am 19. September 2012 veröffentlichte Sophos um 20:02 (UTC-Zeit) ein Update der Erkennungsregeln in Form einer IDE-Datei, das viele Fehlalarme auf den Kunden-PCs und den Sophos Management-Konsolen ausgelöst hat. Diese Fehlalarme verhinderten zudem, dass unsere und einige Sophos fremde Produkte Updates beziehen konnten.

Sophos‘ Hauptziel ist es, branchenweit führende Standards im Bereich Produktqualität sowie Kundensupport und -schutz zu etablieren und aufrecht zu erhalten. Der jetzige Vorfall stellte einen nicht akzeptablen Fehltritt in unseren Qualitäts- und Veröffentlichungsprozessen dar, der sich auf viele Kunden und Partner negativ ausgewirkt hat.

Dieses Dokument fasst zusammen, wie es zu dem Vorfall kommen konnte, und welche Änderungen Sophos bereits vorgenommen hat und in Zukunft vornehmen wird, um seine Qualitätskontrolle und Veröffentlichungsprozesse zu optimieren und sicherzustellen, dass sich ein solches Ereignis nicht wiederholen kann.

Auswirkung auf die Kunden

Der Betroffenenkreis lässt sich im Wesentlichen in zwei Kategorien einteilen: 1) Benutzer der aktuellen Version von Sophos Endpoint-Software mit aktuellen Standardeinstellungen zu Bereinigung und Live-Schutz 2) Benutzer von Sophos Endpoint-Software, bei der der Live-Schutz nicht aktiviert war oder Änderungen an den Standardbereinigungseinstellungen vorgenommen wurden.

Kategorie 1

Kunden mit Endpoint-Software und den aktuellen Sophos Standardeinstellungen „Nur Zugriff verweigern“ plus „Live-Schutz aktivieren“ waren am wenigsten betroffen – der Normalbetrieb inklusive Anwendungen anderer Anbieter konnte schnell wiederhergestellt werden. Der Hauptaufwand für diese Kunden bestand in der Entfernung zahlreicher False Positive-Alerts aus den Ereignisprotokollen sowie der Beantwortung von Endbenutzer-Fragen zur Ursache des Problems.

Kategorie 2

In anderen Kundenumgebungen waren auf allen Endpoints Korrekturmaßnahmen zur Wiederherstellung der Sophos Software und einiger Anwendungen anderer Anbieter erforderlich. Bei vielen Kunden und Partnern führte dies zu einem erheblichen Mehraufwand. In einigen Fällen waren, wie erwähnt, auch andere Systeme und Programme betroffen (z.B. Java, Adobe Acrobat, Google Chrome usw.).

Bei Kunden ohne aktivierten Live-Schutz musste diese Option aktiviert werde, um das Problem zusammen mit Änderungen am Sophos Update Manager zu beheben. In einigen Fällen mussten Administratoren jeden einzelnen betroffenen Endpoint aufsuchen.

Kunden, die die standardmäßig nicht aktivierten Optionen „Verschieben“ oder „Löschen“ ausgewählt hatten, waren stärker betroffen, da sich Sophos Endpoint nicht mehr ordnungsgemäß aktualisierte. Dieses Problem trat auch bei Anwendungen anderer Anbieter auf. Zur Unterstützung des Wiederherstellungsprozesses stellten wir Tools zur Verfügung, die allerdings auf allen betroffenen Geräten ausgeführt werden mussten.

Hintergrund

Der Sophos Endpoint Protection Agent umfasst eine Threaterkennungs-Engine zum Scannen von Dateien und anderen Inhalten, um Malware, verdächtigen Code, bekanntermaßen schadfreien Code usw. zu ermitteln. Die Engine greift auf ca. 200.000 Erkennungsregeln zu, um zu ermitteln, wann Alerts ausgelöst werden sollen. Um sicherzustellen, dass Sophos aktuelle Malware, Exploits und legitime Anwendungen erkennt, werden die Erkennungsregeln regelmäßig mit einer IDE-Datei, die mehrere Updates enthält, aktualisiert. Die Regeln rufen diverse „Operatoren“ in der Engine ab. Wenn dabei eine Erkennung ausgelöst wird, können mehrere Aktionen durchgeführt werden (z.B. Identifizierung der zu bereinigenden Objekte, Senden von Live-Schutz-Daten zurück an Sophos, Auslösen eines Alerts an die Endbenutzerkonsole usw.). Die Threaterkennungs-Engine von Sophos ist für die plattformunabhängige Nutzung konzipiert und analysiert Malware auf allen Hauptbetriebssystemen (Windows, Linux, UNIX, Mac).

Sophos veröffentlicht in der Regel einmal pro Monat eine neue Version des Endpoint Protection Agents sowie der dazugehörigen Threaterkennungs-Engine. Zudem werden mehrmals täglich IDE-Regel-Updates veröffentlicht. An manchen Tagen finden die SophosLabs bis zu 180.000 neue Viren oder Malware. Im Durchschnitt veröffentlicht Sophos sechs IDE-Dateien in 24 Stunden. Die Anzahl hängt von der Dringlichkeit oder der Bedrohungslandschaft im Allgemeinen ab. Sophos führt vor der Versendung an die Kunden ausgiebige Tests aller neuen Softwareversionen, Erkennungs-Engine-Updates und Regel-Updates (IDE) durch.

Allerdings können bei Software- und Daten-Updates Fehler nie ganz ausgeschlossen werden. Um diese Fehler weitestgehend auszuschalten, führt Sophos zahlreiche automatisierte Tests und mehrstufige Analystenprüfungen durch, um ein maschinelles und menschliches „Sicherheitsnetz“ zu schaffen. Alle IDE-Versionen, einschließlich der bei dem Vorfall relevanten Version, durchlaufen ein zwölfstufiges Testverfahren. Hierbei laufen Hunderte physischer und virtueller Systeme parallel auf mehreren Plattformen (unterschiedliche Versionen von Windows, Mac und Linux/UNIX) und testen die neuen Versionen mit mehreren zehn Millionen Dateien und Terabytes an Daten, die alle bekannten, aktiven Threats sowie legitime Anwendungen charakterisieren. Die Tests umfassen maschinelle und menschliche Codeinspektionen, Validierung, umfassende Scansimulationen, Tests in der Produktionsumgebung und Experten-Reviews.

Ursachen des Vorfalls und vorbeugende Maßnahmen von Sophos für die Zukunft

Der Auslöser des Vorfalls war menschliches Versagen und bestand darin, dass ein Analyst ein Update unserer Erkennungsregeln in einem IDE-Datei-Update nicht ordnungsgemäß codierte. So wurde ein False Positive im Sophos Endpoint-Produkt für Windows ausgelöst.

Trotz dieses individuellen Fehlers hätte das Problem dennoch vom zwölfstufigen Testverfahren erkannt werden müssen. In diesem Fall führte eine Kombination aus menschlichem Irrtum, der zu einer fälschlichen Auslegung der Testergebnisse führte, und einer Diskrepanz bei den Testumgebungen dazu, dass die fehlerhafte IDE-Datei freigegeben wurde.

In den folgenden Abschnitten werden diese Faktoren in drei Hauptbereichen detaillierter erörtert:

1. Regeländerung
2. Testprozesse
3. Ausfallsicherheit des Produkts

1. Regeländerung

Am 19. September 2012 wurden unsere Erkennungsregeln geändert. Dabei wurde vor allem eine Regel geändert, die dazu diente, das Aufkommen von Live-Schutz-Abfragen zu zugelassener Software zu ändern. Die modifizierte Regel wurde zum nächsten, geplanten IDE-Update hinzugefügt: AGEN-XUV.IDE. Die modifizierte Regel verwendete einen Operator in der Threaterkennungs-Engine, der der Ermittlung des Erkennungsnamens dient.

Der Threaterkennungs-Engine-Operator weist einen bekannten Nebeneffekt auf: Auch die Erkennung selbst wird an den Sophos Endpoint Agent gemeldet. Der Operator wird häufig von den SophosLabs verwendet – in der Regel beim Schreiben von Bereinigungsregeln. Das Verhalten des Operators ist ausgiebig dokumentiert. Analysten sollen den Operator nur nutzen, wenn diesem ein separater, davon unterschiedlicher Operator vorangeht, der die Erkennung trotzdem an den Endpoint meldet und somit gegebenenfalls negative Nebenwirkungen verhindert.

Die Situation verkomplizierte sich noch weiter, da die aktualisierte Regel einen Operator verwendete, der auf bestimmten UNIX-Versionen nicht unterstützt wird. Der Analyst fügte somit Kontrollen hinzu, um die Regel nur in Windows-Umgebungen auszuführen. Da die Regel der Ermittlung legitimer Windows-Software diente, wurde die Einschränkung als hinnehmbar erachtet.

Zusätzlich zur fehlerhaften Regel schützte die IDE-Version auch vor eingesendeten Samples und einer kritischen Sicherheitslücke im Microsoft Internet Explorer (Details unter http://www.sophos.com/de-de/threat-center/threat-analyses/viruses-and-spyware/Exp~20124969-A/detailed-analysis.aspx).

Empfohlene Maßnahmen

Sophos hat das IDE-Problem ermittelt und behoben und veröffentlicht in Kürze eine aktualisierte Version der Threaterkennungs-Engine.

VON SOPHOS ERGRIFFENE MASSNAHMEN STATUS
Veröffentlichung der korrigierten IDE-Regel in allen Update-Systemen (javab-jd.ide). check ABGESCHLOSSEN
Veröffentlichung einer neuen Version der Threaterkennungs-Engine, bei der der ursprünglich vorhandene Nebeneffekt eliminiert wird. check ABGESCHLOSSEN
Überprüfung aller bekannten und dokumentierten Defekte und Nebeneffekte seitens aller Analysten in den SophosLabs und Aufnahme entsprechender Prüfungen in den Experten-Reviews. check ABGESCHLOSSEN
Überprüfung/Verbesserung automatischer Kennungsprüfungen inklusive neuer Alarmfunktionen bei Risikobereichen in Zusammenhang mit Engine-Operatoren. check ABGESCHLOSSEN

2. Testprozesse

Sophos führt umfassende Tests zu allen Endpoint-Produktversionen durch. Hierzu zählen Tests der Threaterkennungs-Engine, Komponententests und Systemtests in allen unterstützten Betriebssystemen inklusive und groß angelegten Produktionsumgebungen. Darüber hinaus führt Sophos umfassende Tests aller IDE-Dateien vor ihrer Veröffentlichung durch. Die defekte IDE-Datei hätte bei fünf von zwölf Testphasen erkannt werden müssen. Die Testphasen werden in der folgenden Tabelle zusammengefasst.

Von Sophos zu allen IDE-Veröffentlichung und -Updates durchlaufene Testphasen Testphasen, bei denen die defekte IDE-Datei erkannt hätte werden müssen
  • Komponententest der Analysten
  • Experten-Review
  • Kompilierungstests und Warnung
  • Validierung der Kennung
  • Positivtests (umfassenden Tests von Malwareerkennungen)
  • Wildlist-Tests (auf der Basis von aufwildlist.org veröffentlichten Samples)
  • Erkennungstests (IDE-Test)
  • Leistungstests
  • Speichertests
  • Cleanup-Entfernungstests
  • False Positive-Tests
  • Produktionstests
  • Komponententest der Analysten
  • Experten-Review
  • Validierung der Kennung
  • Erkennungstests (IDE-Test)
  • False Positive-Tests

 

Bei allen dieser fünf Testphasen traten Fehler auf. Das Ergebnis dieser Kombination war die Freigabe der IDE-Datei. Die fünf Probleme werden im Folgenden noch ausführlicher beschrieben.

Komponententest der Analysten. Der Analyst verwendete eine neuere, noch unveröffentlichte Version der Threaterkennungs-Engine, bei der der Nebeneffekt des Operators bereits behoben worden war. Aus diesem Grund konnte er die False Positive-Meldung beim Entwicklungstest nicht sehen. In der Regel arbeiten Analysten mit der aktuellen Version der Engine, um sicherzustellen, dass die aktuellen Schutzfunktionen berücksichtigt werden. Erstellte Regeln werden im Anschluss mit allen im Umlauf befindlichen Vorgängerversionen der Engine getestet.

Experten-Review. Sämtliche Modifizierungen und Kennungszusätze, einschließlich globaler Routinen, werden im Rahmen des Experten-Reviews von einem zweiten, unabhängigen Analysten geprüft. Die fälschliche Nutzung des Engine-Operators und die Auswirkungen des Engine-Defekts sowie die Windows-Prüfung hätten erkannt werden müssen, was aufgrund menschlichen Versagens jedoch nicht der Fall war.

Validierung der Kennung. Analysten übermitteln Kennungen in das Code-Kontrollsystem von Sophos, in dem alle Kennungen, Regeln und Versionen nachverfolgt werden können. Dies ist die sogenannte Kennungsdatenbank (Identity Database). Im Rahmen dieses Prozesses werden neue Regeln und Kennungen validiert sowie Warnmeldungen erzeugt. Die Validierungsprüfung identifiziert unter Einbezug bekannter Fehler folgende Probleme: das Auffinden von Fehlern in der Programmcode-Syntax und der fälschlicher Gebrauch von Operatoren, Da der Operator auf eine Validierungsprüfung zurückgriff, die bei korrektem Gebrauch funktionierte, wurde der Fehler nicht in die Datenbank schwerwiegender Fehler aufgenommen und dementsprechend auch nicht gemeldet.

Erkennungstests (IDE-Test). In der IDE-Testphase wird geprüft, ob alle relevanten Dateien von unserer veröffentlichten Threaterkennungs-Engine erkannt, und dass Regeldaten in Zusammenhang mit der zu veröffentlichenden IDE-Datei hinzugefügt werden. Hierbei handelt es sich 31 Tests, die über zahlreiche, virtuelle Systemknoten verteilt werden.

Im Rahmen dieser Testphase versagten einige der virtuellen Systemknoten. Daher meldeten die Testergebnisse einen schwerwiegenden Fehler. Da die Veröffentlichung der IDE jedoch als dringend eingestuft wurde (Fix der von Kunden eingereichte Samples und einer kritische Sicherheitslücke im Microsoft Internet Explorer ) und der Analyst davon ausging, dass die Fehler der Systemknoten auf Instabilitäten der Hardware bzw. der virtuellen Systemumgebung und nicht den Test selbst zurückzuführen waren, wurde die Fehlermeldung nicht berücksichtigt. In den Testergebnissen wurden die Knotenfehler an erster Stelle angezeigt. Hätte der Analyst jedoch die Ergebnisse weiter unten genauer betrachtet, hätte er auch die Fehlermeldungen zur „Shh“-Kennung gesehen. Entscheidend ist, dass der Analyst die Ursache des schwerwiegenden Fehlers nicht weiter erforschte bzw. den Test nicht wiederholte.

False Positive-Tests. Parallel zum IDE-Test führt Sophos einen False Postive-Test der zu veröffentlichenden IDE-Datei durch. Die False Positive-Testumgebung besteht aus einer großen Anzahl an Parallelsystemen. Diese Systeme greifen auf die zuletzt veröffentlichtenThreaterkennungs-Engines und –Regeln, einschließlich der zu veröffentlichenden Datei, zurück, und scannen mehr als 10 Millionen „guter“ Dateien und Terabytes an Daten. Der Testdatei-Einsatz wird regelmäßig aktualisiert und umfasst alle Microsoft Betriebssystemdateien, viele beliebte Anwendungen (wie etwa Java, Adobe und Google Maps), zahlreiche Unternehmensanwendungen und alle aktuellen und früheren Veröffentlichungen von Sophos Produkten.

Die Threaterkennungs-Engine wird auf mehreren Plattformen, einschließlich Windows und vielen Linux- und UNIX-Varianten unterstützt. Da der Test möglichst umfassend sein soll, wurden die False Positive-Tests angesichts der großen Datenmengen auf Linux-Servern durchgeführt. Die große Mehrheit der Sophos Regeln und Kennungen sind plattformübergreifend und werden auf mehreren Betriebssystemen (einschließlich Linux, Windows, Mac OS und UNIX gleichermaßen ausgeführt). Der Hauptzweck des False Positive-Tests bestand in der Ermittlung von False Positives und nicht der Bestätigung der plattformübergreifenden Kompatibilität der IDE-Datei. Bei der Regel handelte es sich um eines der wenigen Beispiele, die Analysten nur zum Einsatz in Windows-Umgebungen geschrieben haben. Da die False Positive-Testumgebung nur auf Linux-Servern läuft, meldeten die Tests die „Shh/“-False Positive nicht, da die Regel mit dem entsprechenden Fehler nur für Windows gilt.

Wenn eines der fünf Probleme nicht aufgetreten wäre, so hätte die IDE-Datei, wie bereits erwähnt, eine der Testphasen nicht bestanden und wäre nicht veröffentlicht worden.

Empfohlene Maßnahmen

Sophos hat bereits die im Folgenden genannten Maßnahmen ergriffen oder leitet demnächst entsprechende Schritte ein.

VON SOPHOS ERGRIFFENE MASSNAHMEN STATUS
Bei schwerwiegenden Fehlern oder Systemausfällenwerden alle IDE-Tests grundsätzlich wiederholt. Wenn eine IDE erneut erstellt werden muss, werden nicht nur die problematische Kennung, sondern auch nicht dringende Objekte entfernt. In die neu erstellte Version werden nur dringende Objekte integriert, um das Fehlerrisiko in der zweiten Runde zu minimieren. Kein Test wird als bestanden erachtet, wenn System-, Tool- oder Testfehler JEDWEDER ART auftreten. check ABGESCHLOSSEN
Einrichtung einer False Positive-Testumgebung, in der Plattformen ordnungsgemäß aufeinander abgestimmt sind. Dies gilt für Windows- und Linux-Plattformen, damit die False Positive-Testumgebung auch als Plattformtestumgebung fungieren kann. check ABGESCHLOSSEN
Verbesserung und Erweiterung des False Positive-Testsystems mit Bezug auf Umfang, Plattformabdeckung und Ausfallsicherheit. check ABGESCHLOSSEN
Einführung separater Veröffentlichungszyklen für dringende Kennungs-Updates und allgemeinere Verfahrens-/Regelupdates. Allgemeine Verfahrens-/Regelupdates erhalten separate Testverfahren und längere Veröffentlichungszyklen. check ABGESCHLOSSEN
Alle generellen Verfahrens- und Regeländerungen müssen in Produktionsumgebungen getestet werden. Zusätzlich ist das Durchlaufen eines umfassenden Systemtests Pflicht, wobei auch die Management-Konsole sowie eine Auswahl an internen Sophos Produktions-Endpoints vor dem Versand an die Kunden einbezogen werden. IN ARBEIT
Formalisierung von Zielen, (4 Augen) Experten-Review-Inspektionen mit zusätzlichen und Testphasenkriterien. Dokumentation von Prozessen und Anforderungen, wobei zwischen Review und „Inspektion“ unterschieden wird. Regelmäßige Schulungen für SophosLabs-Mitarbeiter – sowohl für neue als auch langjährige Angestellte. IN ARBEIT
Verbessern der Prüfung von Erkennungsvalidierungen und Einbezug einer umfassenderen Datenbank mit Codefehlern, wobei auch Regeln berücksichtigt werden, die zwar keine Fehler auslösen, jedoch das Zusatzrisiko von Nebenwirkungen oder Defekten auf die Engine bergen.

IN ARBEIT

 

3. Produktausfallsicherheit

Die Sophos Endpoint Produkte enthalten ein automatisches Update-System, das zur Durchführung redundanter Updates aus einem zentralen Installationsverzeichnis über den Sophos Update Manager und/oder per http direkt von Sophos konfiguriert werden kann.

Die für Updates zuständige Komponente des Endpoint-Agents wird als Sophos AutoUpdate bezeichnet. Das Update-System ist vollkommen unabhängig vom Sophos Remote Management System (RMS), mit dem Konfigurationsrichtlinienänderungen von der Management-Konsole versendet und Reports sowie Ereignisse zentral übertragen werden können. Ein dritter, unabhängiger Kommunikationspfad führt von allen Sophos Endpoint Agents über Live-Abfragen zu Sophos, wenn der „Live-Schutz“ aktiviert wurde. In Kombination stellen die drei Systeme nicht nur sicher, dass Sophos kontinuierliche Updates zum Schutz vor aktuellen Malwarebedrohungen bereitstellen kann, sondern sorgen zudem für die nötige Redundanz zur Wiederherstellung bei Problemen. Der Live-Schutz ist seit der im Juni 2010 veröffentlichten Version 9.5 in allen Sophos Endpoint-Versionen enthalten. Das Feature ist standardmäßig aktiviert.

Im vorliegenden Fall wurden der Sophos Update Manager und das Sophos AutoUpdate im Zuge des unabhängigen Abfrageprozesses bei Kunden mit aktvierter Live Protectionals „sauber“ ausgewiesen, um die False Positive-Meldung in den lokal bereitgestellten Regeln zu umgehen. Damit konnten der Sophos Update Manager und Endpoint-Agent (plus alle anderen ggf. betroffenen Anwendungen) wieder in den Normalbetrieb versetzt werden.

Bei Kunden ohne aktivierte Live Protection verhinderte der False Positive, dass der Sophos Update Manager und Sophos AutoUpdate ordnungsgemäß ausgeführt werden konnten. In Folge konntedie reparierte IDE-Datei in diesen Umgebungen nicht heruntergeladen werden. Auch wenn der Sophos Endpoint-Agent weiterhin Scans durchführte und Endpoints schützte, waren Korrekturmaßnahmen erforderlich, damit weiterhin Updates von Sophos bezogen werden konnten. Bei vielen betroffenen Kunden mussten daher Konfigurationsänderungen am Update Manager vorgenommen werden, um weiterhin Updates zu ermöglichen. In den meisten Fällen wurde die volle Funktionalität der Sophos Produkte und Anwendungen anderer Anbieter wiederhergestellt, indem die Konfigurationsänderungen sowie eine Richtlinienänderung zur Aktivierung des Live-Schutzes bereitgestellt und über das unabhängige RMS-System auf Endpoint Agenten verteilt wurde.

Wir gehen davon aus, dass bei fast allen Sophos Kunden der Live-Schutz aktiviert war bzw. die Standardbereinigungseinstellung des Sophos Endpoint-Produkts für verdächtige Dateien „Nur Zugriff verweigern“ und nicht „Verschieben“ oder „Löschen“ (optionale Einstellungen) lautete.

In einigen Fällen – vor allem wenn Kunden nicht standardmäßige Richtlinien zum Verschieben oder Löschen von in Zusammenhang mit der False Positive-Meldung erkannten Dateien nutzten, musste die Sophos Software auf allen Endpoints repariert werden, damit automatische Updates wieder funktionierten. Sophos Techniker entwickelten kurzfristig neue Tools zur Automatisierung dieses Prozesses und machten diese über die Unternehmenswebsite verfügbar.

Sophos erwägt momentan eine Reihe möglicher Modifikationen am Sophos Endpoint-Produkt, die die Konsequenzen solcher Defekte abschwächen und die Wiederherstellung für Kunden und Partner automatischer und überschaubarer gestalten.

Empfohlene Maßnahmen

Einige derzeit von Sophos erwogene Produktverbesserungen können Sie der nachstehenden Tabelle entnehmen.

VON SOPHOS ERGRIFFENE MASSNAHMEN STATUS
Evaluierung der Möglichkeit, die Löschfunktion durch eine robuste und wiederherstellbare Quarantänefunktion zu ersetzen FÜR KÜNFTIGE VERSIONEN GEPLANT.
Verbesserung der in das Produkt integrierten Benachrichtigungen zum Live-Schutz und Empfehlung zur Aktivierung der Option an vorhandene und neue Kunden. FÜR KÜNFTIGE VERSIONEN GEPLANT.
Verbesserung der Ausfallsicherheit des Update-Prozesses von Sophos. FÜR KÜNFTIGE VERSIONEN GEPLANT.
Erweiterung der Selbstschutzfähigkeit des Sophos Endpoint-Agents in Sachen Updates. FÜR KÜNFTIGE VERSIONEN GEPLANT.

 

REAKTION AUF DEN VORFALL Weitere, aus dem Vorfall gewonnene Erfahrungen

Zwar betrachten Kunden und Partner die Sophos Kommunikation und Unterstützung bei der Problembehebung im Allgemeinen als zuvorkommend und reaktionsschnell, es zeichneten sich jedoch drei wichtige Bereiche ab, in denen wir uns entscheidend verbessern wollen.

1. Telekommunikationskapazitäten in den Support-Callcentern

Nach Entdeckung des Vorfalls stellte Sophos das gesamte, verfügbare technische Personal zur Bearbeitung der Support-Anfragen ab. Gleichzeitig wurden die Arbeitszeiten in allen wichtigen Callcentern in Abingdon, Boston, Karlsruhe, Madrid, Mailand, Paris, Singapur, Sydney, Tokio, Vancouver, Wiesbaden und anderen Städten weltweit ausgeweitet. In den ersten 48 Stunden nach dem Vorfall betrug das Anrufaufkommen mehr als das Zehnfache im Vergleich zum Normalbetrieb. Dies führte zu langen Wartezeiten für Kunden und in einigen Fällen zu Überlastungen unserer Telefonsysteme. Infolgedessen wurden Kunden nicht in die Telefonwarteschlange aufgenommen. Die Lage verschärfte sich aufgrund eines Defekts im Telefonsystem unseres Callcenters in Boston. Drei Tage lang wurden die eingehenden Telefonkapazitäten in Boston um 50 % reduziert. Sophos‘ Ziel ist es, den reaktionsschnellsten Kundensupport in der IT Security-Branche anzubieten. Im Durchschnitt warten Kunden weniger als drei Minuten, bis sie zu einem qualifizierten Support-Mitarbeiter durchgestellt werden. Im Verlauf des Vorfalls konnte Sophos seinen Kunden die üblichen Zielreaktions- und -wartezeiten nicht gewährleisten. Obwohl wir diverse Maßnahmen eingeleitet haben, um sicherzustellen, dass sich ein solcher Störfall nicht wiederholt, verbessern wir gleichzeitig die Support-Infrastruktur, um für massenhafte Kundenanfragen jederzeit gerüstet zu sein.

Empfohlene Maßnahmen

VON SOPHOS ERGRIFFENE MASSNAHMEN STATUS
Beauftragung eines Drittanbieters zur Verarbeitung plötzlicher Anrufspitzen. check IN UK UND NORDAMERIKA ABGESCHLOSSEN
Implementierung einer Vorgehensweise zur Notfallbehandlung, um die Beantwortung eingehender Anrufe umgehend neu organisieren zu können (einschließlich IVR (hinterlassener)-Nachrichten, Anrufweiterleitung und Rückrufen). IN ARBEIT
Zusammenarbeit mit Callcenter-Service-Providern zur Optimierung der Auslastung und Redundanz von Telefonsystemen zum Schutz vor Infrastrukturausfällen bei besonders hohem Anrufaufkommen. check IN ARBEIT

2. Proaktives Benachrichtigungssystem

Binnen einer Stunde nach dem Vorfall hat Sophos das False Positive-Problem auf Twitter gemeldet und einen Support-Artikel in die Knowledgebase aufgenommen. Nachdem die Sachlage klar war, haben wir innerhalb von zweieinhalb Stunden umfangreich in der Presse und den Social-Media-Kanälen über den Vorfall informiert. Es dauerte jedoch 19 Stunden, bis alle Sophos Kunden per E-Mail benachrichtigt wurden.

Empfohlene Maßnahmen

VON SOPHOS ERGRIFFENE MASSNAHMEN STATUS
Überarbeitung der Sophos Vorgehensweise zur Notfallbehandlung, um Kunden zukünftig rund um die Uhr informieren zu können. check ABGESCHLOSSEN
Entwickeln und regelmäßiges Testen automatischer E-Mail-Kommunikationssysteme und Kontaktdatenbanken, um eine schnellere Zustellung von Notfall-E-Mail-Benachrichtigungen zugewährleisten. IN ARBEIT
Identifizieren von alternativen, E-Mail-unabhängigen Kommunikationswegen, um Kunden zu informieren. Beispielsweise SMS, Konsolen-Alerts und RSS. IN ARBEIT

3. Support-Artikel

Die ersten Versionen des Support-Artikels waren für Kunden schwer verständlich. Zudem lieferte das Sophos Veröffentlichungssystem trotz Verfügbarkeit neuer Support-Artikelversionen nicht immer die richtigen Ergebnisse. Folglich wurden innerhalb der ersten 48 Stunden veraltete Versionen und in einigen Fällen leere Seiten angezeigt. In diesem Zeitraum musste die Sophos Webseite ein 25-fach erhöhtes Besucheraufkommen verarbeiten.

Empfohlene Maßnahmen

VON SOPHOS ERGRIFFENE MASSNAHMEN STATUS
Überarbeiten der Sophos Vorgehensweise zur Notfallbehandlung, um umgehend einen Verantwortlichen für wichtige Support-Artikel benennen zu können. check ABGESCHLOSSEN
Erstellen einer Support-Artikelvorlage für Notfälle, einschließlich Screenshots und Checklisten, anhand derer Kunden und Partner ermitteln können, ob sie betroffen sind, und gegebenenfalls das Ausmaß bemessen können. check ABGESCHLOSSEN
Überarbeiten und Abwandeln des Veröffentlichungsprozesses für Support-Artikel, um in Notfällen eine schnellere Veröffentlichung in allen Sprachen realisieren zu können. IN ARBEIT

 

Zusätzliche Empfehlungen

Der Vorfall hat gezeigt, dass Sophos gegenüber Kunden und Partnern mehr vorschriftsmäßige Empfehlungen über am besten geeignete Richtlinieneinstellungen für die Bereitstellung und Verwaltung seiner Produkte aussprechen sollte. Die Sophos Standardeinstellungen für neue Installationen hätten über Alarme hinausgehende Störungen bei diesem Vorfall verhindert. Einige Kunden hatten den Live-Schutz jedoch nicht aktiviert, und andere Kunden hatten als Standardeinstellung für eine nicht verfügbare Bereinigung „Verschieben“ oder „Löschen“ gewählt.

Wir haben hierzu den Support-Artikel 114345 in der Knowledgebase veröffentlicht, in dem die aktuell empfohlene Richtlinie erläutert wird. Neben weiteren Empfehlungen erläutern wir, wie der Live-Schutz aktiviert und die Einstellung „Nur Zugriff verweigern“ gewählt werden kann, wenn keine Bereinigung möglich ist.

Fazit

Seit der Gründung von Sophos im Jahre 1985 haben Kunden und Partner unsere branchenführende Produktqualität und unseren erstklassigen Kundensupport schätzen gelernt. Wir müssen uns wieder darauf konzentrieren, unsere Systeme, Prozesse, und Organisationregelmäßig konkret zu verbessern. Nur so können wir verhindern, dass sich ein solcher Vorfall wiederholt. Gleichzeitig müssen wir auf kritische Sicherheitsvorfälle unabhängig von ihrer Quelle in Zukunft besser reagieren. Das Vertrauen unserer Kunden zu gewinnen und ihre Unternehmen zu schützen, ist unser höchstes Ziel. Sophos wird aus dem Vorfall lernen und gestärkt aus dieser Situation hervorgehen, um Partnern und Kunden in Zukunft ein noch besseres Preis-Leistungs-Verhältnis mit mehr Verlässlichkeit und Reaktionsschnelle bieten zu können.