In diesem Artikel, der von einem Anbieter einer Sicherheitsüberwachungslösung verfasst wurde, war das Hauptargument (das häufig in anderen Publikationen und verschiedenen Messen wiederholt wurde), dass das Patchen von OT-Systemen schwierig ist. Der Autor argumentiert, dass wir uns, da es schwierig ist, anderen Methoden zuwenden sollten, um die Sicherheit zu verbessern. Seine Theorie ist es, eine Alarmierungstechnologie wie seine einzuschalten und die ausstehenden Alarme mit einem Security Incident Response Team zu koppeln. Mit anderen Worten, akzeptieren Sie einfach, dass das Patchen schwierig ist, geben Sie auf und investieren Sie mehr Geld in das frühere Lernen (vielleicht?) und energischer reagieren.
Diese Schlussfolgerung (Patching ist schwierig, also nicht stören) ist jedoch aus mehreren Gründen fehlerhaft. Ganz zu schweigen davon, dass er auch einen sehr großen Faktor beschönigt, der jede Reaktion oder Behebung, die in Betracht gezogen werden sollte, erheblich erschwert.
Der erste Grund, warum dies ein gefährlicher Ratschlag ist, ist, dass Sie das Patchen einfach nicht ignorieren können. Sie müssen tun, was Sie können, wann Sie können, und wenn Patching keine Option ist, wechseln Sie zu Plan B, C und D. Nichts zu tun bedeutet, dass alle Cyber-bezogenen Vorfälle, die in Ihre Umgebung eindringen, maximalen Schaden anrichten. Das klingt sehr nach der M& M-Verteidigung von vor 20 Jahren. Dies ist die Idee, dass Ihre Sicherheitslösung außen hart und knusprig, innen aber weich und zäh sein sollte.
Der zweite Grund, warum dieser Hinweis fehlerhaft ist, ist die Annahme, dass OT-Sicherheitspersonal (für Incident Response oder Patching) leicht zu finden und einzusetzen ist! Dies ist nicht wahr – tatsächlich weist einer der ICS-Sicherheitsvorfälle, auf die im Artikel verwiesen wird, darauf hin, dass zwar ein Patch verfügbar und zur Installation bereit war, jedoch keine ICS-Experten zur Verfügung standen, um die Patch-Installation zu überwachen! Wenn wir unsere Sicherheitsexperten nicht freistellen können, um bekannten Schutz vor Ereignissen als Teil eines proaktiven Patch-Management-Programms bereitzustellen, warum glauben wir, dass wir das Budget für ein vollständiges Incident Response Team im Nachhinein finden können, wenn es zu spät ist?
Das fehlende Stück dieses Arguments ist schließlich, dass die Herausforderungen für das OT / ICS-Patch-Management durch die Menge und Komplexität der Assets und der Architektur in einem OT-Netzwerk weiter verschärft werden. Um es klar zu sagen: Wenn ein neuer Patch oder eine neue Sicherheitsanfälligkeit veröffentlicht wird, ist die Fähigkeit der meisten Unternehmen, zu verstehen, wie viele Assets sich im Umfang befinden und wo sie sich befinden, eine Herausforderung. Aber das gleiche Maß an Einblick und Asset-Profilen wird von jedem Incident Response Team benötigt, um effektiv zu sein. Selbst sein Rat, die Praxis des Patchings zu ignorieren, lässt Sie nicht vermeiden, ein robustes, kontextbezogenes Inventar erstellen zu müssen (die Grundlage für das Patching!) als Grundlage für Ihr OT-Cybersicherheitsprogramm.
Also, was sollen wir tun? In erster Linie müssen wir versuchen zu patchen. Es gibt drei Dinge, die ein ausgereiftes ICS-Patch-Management-Programm beinhalten muss, um erfolgreich zu sein:
- Kontextbezogene Bestandsaufnahme in Echtzeit
- Automatisierung der Behebung (sowohl Patchdateien als auch Ad-hoc-Schutzmaßnahmen)
- Identifizierung und Anwendung kompensierender Steuerelemente
Kontextbezogene Bestandsaufnahme in Echtzeit für das Patch-Management
Die meisten OT-Umgebungen verwenden Scan-basierte Patching-Tools wie WSUS / SCCM, die standard, aber nicht übermäßig aufschlussreich, um uns zu zeigen, welche Assets wir haben und wie sie konfiguriert sind. Was wirklich benötigt wird, sind robuste Asset-Profile mit ihrem operativen Kontext. Was meine ich damit? Asset IP, Modell, Betriebssystem usw. ist eine sehr flüchtige Auflistung dessen, was für den neuesten Patch in Frage kommt. Was wertvoller ist, ist der betriebliche Kontext wie die Kritikalität von Vermögenswerten für einen sicheren Betrieb, den Standort von Vermögenswerten, den Eigentümer von Vermögenswerten usw. um unser aufkommendes Risiko richtig zu kontextualisieren, weil nicht alle OT-Assets gleich sind. Warum also nicht zuerst die kritischen Systeme schützen oder geeignete Testsysteme identifizieren (die kritische Feldsysteme widerspiegeln) und das Risiko strategisch reduzieren?
Und während wir diese Asset-Profile erstellen, müssen wir so viele Informationen wie möglich über die Assets jenseits von IP, Mac-Adresse und Betriebssystemversion enthalten. Informationen wie installierte Software, Benutzer / Konto, Ports, Dienste, Registrierungseinstellungen, Steuerelemente mit den geringsten Berechtigungen, AV, Whitelisting und Sicherungsstatus usw. Diese Art von Informationsquellen erhöht unsere Fähigkeit, unsere Maßnahmen bei neuen Risiken genau zu priorisieren und zu strategisieren, erheblich. Willst du Beweise? Schauen Sie sich den unten angebotenen üblichen Analysefluss an. Woher bekommen Sie die Daten, um die Fragen in den verschiedenen Phasen zu beantworten? Stammeswissen? Instinkt? Warum keine Daten?
Automatische Behebung von Software-Patches
Eine weitere Herausforderung beim Software-Patching ist die Bereitstellung und Vorbereitung von Patches (oder Kompensationskontrollen) auf den Endpunkten. Eine der zeitaufwendigsten Aufgaben im OT Patch Management ist die Vorbereitung. Dies umfasst in der Regel das Identifizieren von Zielsystemen, das Konfigurieren der Patch-Bereitstellung, die Fehlerbehebung bei Fehlern oder das erste Scannen, das Pushen des Patches und das erneute Scannen, um den Erfolg festzustellen.
Aber was wäre, wenn Sie beispielsweise beim nächsten Auftreten eines Risikos wie BlueKeep Ihre Dateien auf die Zielsysteme vorladen könnten, um sich auf die nächsten Schritte vorzubereiten? Sie und Ihr kleineres, agileres OT-Sicherheitsteam können strategisch planen, welche Industriesysteme Sie zuerst, zweitens und drittens auf der Grundlage einer beliebigen Anzahl von Faktoren in Ihren robusten Asset-Profilen wie Asset-Standort oder Kritikalität patchen.
Wenn Sie noch einen Schritt weiter gehen, stellen Sie sich vor, die Patch-Management-Technologie erforderte nicht zuerst einen Scan, sondern hatte den Patch bereits In-Scope-Assets zugeordnet und als Sie sie installiert haben (entweder remote für geringes Risiko oder persönlich für hohes Risiko), Diese Aufgaben überprüften ihren Erfolg und spiegelten diesen Fortschritt in Ihrem globalen Dashboard wider?
Für alle Ihre Assets mit hohem Risiko, die Sie derzeit nicht patchen können oder wollen, können Sie stattdessen eine Port-, Dienst- oder Benutzer- / Kontoänderung als Ad-hoc-Kompensationssteuerung erstellen. Bei einer Sicherheitsanfälligkeit wie BlueKeep können Sie den Remotedesktop oder das Gastkonto deaktivieren. Dieser Ansatz reduziert sofort und signifikant das aktuelle Risiko und ermöglicht auch mehr Zeit für die Vorbereitung auf den eventuellen Patch. Dies bringt mich zu den Fallback–Aktionen, was zu tun ist, wenn das Patchen keine Option ist – Kompensationssteuerelemente.
Was sind Kompensationskontrollen?
Kompensationssteuerelemente sind einfach Aktionen und Sicherheitseinstellungen, die Sie anstelle von (oder besser gesagt auch) Patches bereitstellen können und sollten. Sie werden in der Regel proaktiv bereitgestellt (wo möglich), können jedoch in einem Ereignis oder als vorübergehende Schutzmaßnahmen bereitgestellt werden, z. B. das Deaktivieren des Remotedesktops während des Patches für BlueKeep, auf das ich in der Fallstudie am Ende dieses Blogs eingehe.
Kompensationskontrollen in der OT-Sicherheit identifizieren und anwenden
Kompensationskontrollen nehmen viele Formen an, von der Whitelisting von Anwendungen bis hin zur Aktualisierung von Antivirenprogrammen. In diesem Fall möchte ich mich jedoch auf ICS Endpoint Management als wichtige unterstützende Komponente des OT Patch Managements konzentrieren.
Kompensationskontrollen können und sollten sowohl proaktiv als auch situativ eingesetzt werden. Es wäre für jeden in der OT Cyber Security keine Überraschung, ruhende Administratorkonten und unnötige oder nicht verwendete Software zu entdecken, die auf Endpunkten installiert sind. Es ist auch kein Geheimnis, dass die Prinzipien der Best-Practice-Systemhärtung bei weitem nicht so universell sind, wie wir es gerne hätten.
Um unsere OT-Systeme wirklich zu schützen, müssen wir auch unsere wertvollen Besitztümer verhärten. Ein robustes Echtzeit-Asset-Profil ermöglicht es Industrieunternehmen, die niedrig hängenden Früchte (d. H. ruhende Benutzer, unnötige Software und Systemhärtungsparameter) genau und effizient zu beseitigen, um die Angriffsfläche erheblich zu reduzieren.
Im unglücklichen Fall haben wir eine aufkommende Bedrohung (wie BlueKeep) Das Hinzufügen temporärer Kompensationskontrollen ist machbar. Eine kurze Fallstudie, um meinen Punkt hervorzuheben:
- Die BlueKeep-Sicherheitsanfälligkeit wird behoben.
- Das zentrale Team deaktiviert sofort den Remotedesktop für alle Feldressourcen und sendet E-Mails an das Außendienstteam, die spezifische Anforderungen auf Systembasis erfordern, damit der Remotedesktopdienst während des Risikozeitraums aktiviert werden kann.
- Das zentrale Team lädt Patch-Dateien auf alle Assets im Gültigkeitsbereich vor – keine Aktion, nur Vorbereitung.
- Das zentrale Team trifft sich, um den vernünftigsten Aktionsplan nach Asset-Kritikalität, Standort, Vorhandensein oder Fehlen von Kompensationskontrollen zu bestimmen (d. H. Ein kritisches Risiko für ein Asset mit hoher Auswirkung, das sein letztes Backup nicht bestanden hat, steht ganz oben auf der Liste. Ein Asset mit geringen Auswirkungen, bei dem Whitelisting in Kraft ist, und ein kürzlich durchgeführtes gutes vollständiges Backup können wahrscheinlich warten).
- Der Patching-Rollout beginnt und der Fortschritt wird live in Global Reporting aktualisiert.
- Bei Bedarf sind OT-Techniker an der Konsole, um die Patch-Bereitstellung zu überwachen.
- Der Zeitplan und die Kommunikation dieses Bedarfs werden durch die vom zentralen Team verwendeten Daten vollständig geplant und priorisiert.
So sollte OT Patch Management gehandhabt werden. Und immer mehr Organisationen beginnen, diese Art von Programm einzuführen.
Seien Sie proaktiv mit Kompensationskontrollen
Das ICS-Patch-Management ist schwierig, ja, aber einfach aufzugeben, ist auch keine gute Antwort. Mit ein wenig Weitblick ist es einfach, die drei leistungsstärksten Tools für einfachere und effektivere Patching- und / oder Kompensationskontrollen bereitzustellen. Insight zeigt Ihnen, was Sie haben, wie es konfiguriert ist und wie wichtig es für Sie ist. Mit dem Kontext können Sie Prioritäten setzen (erster Patchversuch – zweiter Versuch, wie und wo Kompensationssteuerelemente angewendet werden). Mit der Aktion können Sie korrigieren, schützen, ablenken usw. Wenn Sie sich nur auf die Überwachung verlassen, müssen Sie zugeben, dass Sie Feuer erwarten, und der Kauf weiterer Rauchmelder kann den Schaden minimieren. Welchen Ansatz würde Ihre Organisation Ihrer Meinung nach bevorzugen?