v tomto článku napsaném prodejcem řešení pro monitorování zabezpečení byl hlavním argumentem (často opakovaným v jiných publikacích a různých veletrzích), že oprava OT systémů je těžká. Autor tvrdí, že protože je to těžké, měli bychom se obrátit na jiné metody ke zlepšení bezpečnosti. Jeho teorií je zapnout varovnou technologii, jako je jeho, a spárovat čekající alarmy s týmem reakce na bezpečnostní incidenty. Jinými slovy, jen přijmout záplatování je těžké, vzdát se a nalít více peněz do učení dříve (možná?) a reagovat razantněji.
tento závěr (oprava je těžká, takže se neobtěžujte) je vadný z několika důvodů. Nemluvě o tom, že také glosuje velmi velký faktor, který významně komplikuje jakoukoli reakci nebo nápravu, která by měla být zvážena.
první důvod, proč je to nebezpečné, je, že nemůžete ignorovat opravu. Musíte dělat, co můžete, když můžete, a když oprava není možnost, přejdete do plánu B, C A D. Nedělat nic znamená, že všechny kybernetické incidenty, které se dostanou do vašeho prostředí, způsobí maximální poškození. To zní hodně jako obrana m&M z doby před 20 lety. To je myšlenka, že vaše bezpečnostní řešení by mělo být na vnější straně tvrdé a křupavé, ale uvnitř měkké a žvýkací.
druhým důvodem, proč je tato rada vadná, je předpoklad, že OT bezpečnostní personál (pro reakci na incident nebo opravu) lze snadno najít a nasadit! To není pravda-ve skutečnosti, jeden z bezpečnostních incidentů ICS uvedených v článku poukazuje na to, že zatímco oprava byla k dispozici a připravena k instalaci, nebyli k dispozici žádní odborníci ICS, kteří by dohlíželi na instalaci opravy! Pokud nemůžeme osvobodit naše bezpečnostní experty k nasazení známých, ochrana před událostmi jako součást proaktivního programu správy oprav, proč si myslíme, že můžeme najít rozpočet pro tým plné reakce na incidenty poté, co je příliš pozdě?
konečně, chybějící část z tohoto argumentu je, že výzvy pro správu oprav OT/ICS jsou dále zhoršeny množstvím a složitostí aktiv a architektury v OT síti. Aby bylo jasné, když je vydána nová oprava nebo zranitelnost, schopnost většiny organizací pochopit, kolik aktiv je v rozsahu a kde jsou, je výzvou. Stejná úroveň vhledu a profilů aktiv však bude vyžadována od každého týmu reakce na incidenty, aby byl efektivní. Dokonce i jeho rada ignorovat praxi záplatování vám nedovolí vyhnout se nutnosti vytvářet robustní, kontextový inventář (základ pro záplatování!) jako základ vašeho ot cyber security programu.
takže, co bychom měli dělat? V první řadě se musíme pokusit opravit. Existují tři věci, které musí zralý program správy oprav ICS zahrnovat, aby byl úspěšný:
- kontextový inventář v reálném čase
- automatizace sanace (soubory oprav i ochrana ad-hoc)
- identifikace a aplikace kompenzačních ovládacích prvků
kontextový inventář v reálném čase pro správu oprav
většina prostředí OT používá nástroje pro opravu založené na skenování, jako je WSUS/SCCM, které jsou docela standardní, ale ne příliš bystré, aby nám ukázaly, jaká aktiva máme a jak jsou nakonfigurováno. Co je skutečně potřeba, jsou robustní profily aktiv s jejich provozním kontextem. Co tím myslím? IP aktiv, model, OS atd. je velmi zběžný seznam toho, co by mohlo být v prostoru pro nejnovější opravu. Cennější je provozní kontext, jako je kritičnost aktiv vůči bezpečným operacím,umístění aktiv, vlastník aktiv atd. abychom správně kontextualizovali naše vznikající riziko, protože ne všechna aktiva OT jsou stvořena stejná. Proč tedy nejprve chránit kritické systémy nebo identifikovat vhodné testovací systémy (které odrážejí kritické systémy v terénu) a strategicky snížit riziko?
a zatímco vytváříme tyto profily aktiv, musíme zahrnout co nejvíce informací o aktivech mimo IP, Mac adresu a verzi OS. Informace, jako je nainstalovaný software, uživatelé / účet, porty, služby, nastavení registru, kontroly nejmenších oprávnění, AV, whitelisting a stav zálohování atd. Tyto typy informačních zdrojů významně zvyšují naši schopnost přesně upřednostňovat a strategizovat naše akce, když se objeví nové riziko. Chcete důkaz? Podívejte se na obvyklý tok analýzy nabízený níže. Kde získáte data pro zodpovězení otázek v různých fázích? Kmenové znalosti? Instinkt? Proč ne data?
automatizovat nápravu pro opravu softwaru
další výzvou pro opravu softwaru je nasazení a příprava na nasazení oprav (nebo kompenzačních ovládacích prvků) do koncových bodů. Jedním z časově nejnáročnějších úkolů v ot patch management je přípravná práce. Obvykle zahrnuje identifikaci cílových systémů, konfiguraci nasazení opravy, řešení problémů při selhání nebo skenování jako první, posunutí opravy a opětovné skenování k určení úspěchu.
ale co když se například příště objeví riziko, jako je BlueKeep, můžete předem načíst soubory do cílových systémů a připravit se na další kroky? Vy a váš menší, agilnější bezpečnostní tým OT byste mohli strategicky naplánovat, které Průmyslové systémy jste aktualizovali na první, druhý a třetí, na základě libovolného počtu faktorů ve vašich robustních profilech aktiv, jako je umístění aktiv nebo kritičnost.
Představte si, že technologie správy patchů nevyžadovala nejprve skenování, ale spíše již mapovala opravu na aktiva v rozsahu a jak jste je nainstalovali (buď vzdáleně pro nízké riziko, nebo osobně pro vysoké riziko), tyto úkoly ověřily svůj úspěch a odrážely tento pokrok ve vašem globálním řídicím panelu?
pro všechna vaše vysoce riziková aktiva, která právě nemůžete nebo nechcete opravit, můžete místo toho vytvořit port, službu nebo změnu uživatele/účtu jako kompenzační kontrolu ad hoc. Takže pro zranitelnost, jako je BlueKeep, můžete zakázat vzdálenou plochu nebo účet hosta. Tento přístup okamžitě a významně snižuje současné riziko a také umožňuje více času na přípravu případné opravy. To mě přivádí k „zpětným“ akcím, co dělat, když oprava není možností-kompenzační kontroly.
co jsou kompenzační ovládací prvky?
kompenzační ovládací prvky jsou jednoduše akce a nastavení zabezpečení, které můžete a měli byste nasadit namísto (nebo spíše stejně jako) záplatování. Obvykle jsou nasazeny proaktivně (pokud je to možné), ale mohou být nasazeny v události nebo jako dočasná opatření ochrany, jako je deaktivace vzdálené plochy při opravě pro BlueKeep, kterou rozšiřuji v případové studii na konci tohoto blogu.
Identifikujte a aplikujte kompenzační ovládací prvky v OT security
kompenzační ovládací prvky mají mnoho podob od seznamu povolených aplikací a udržování antiviru up-to-date. Ale v tomto případě se chci zaměřit na správu koncových bodů ICS jako klíčovou podpůrnou součást správy oprav OT.
kompenzační ovládací prvky mohou a měly by být použity jak proaktivně, tak situačně. Nebylo by žádným překvapením, kdyby někdo v ot cyber security objevil spící administrátorské účty a zbytečný nebo nepoužívaný software nainstalovaný na koncových bodech. Není také žádným tajemstvím, že zásady tvrdnutí systému osvědčených postupů nejsou zdaleka tak univerzální, jak bychom si přáli.
abychom skutečně chránili naše OT systémy, musíme také zatvrdit náš ceněný majetek. Robustní profil aktiv v reálném čase umožňuje průmyslovým organizacím přesně a efektivně vyčistit nízko visící ovoce (tj.
v této nešťastné události se objevuje hrozba (jako BlueKeep) přidání dočasných kompenzačních kontrol je proveditelné. Rychlá případová studie pro zvýraznění mého bodu:
- bluekeep zranitelnost je uvolněna.
- centrální tým okamžitě zakáže vzdálenou plochu ve všech polních aktivech a e-mailech, které vyžadují specifické požadavky na základě jednotlivých systémů, aby byla služba vzdálené plochy povolena během rizikového období.
- centrální tým předem načte soubory oprav na všech aktivech v rozsahu-žádná akce, stačí se připravit.
- centrální tým se svolává, aby rozhodl o nejrozumnějším akčním plánu podle kritičnosti aktiv, umístění, přítomnosti nebo nepřítomnosti kompenzačních kontrol(tj. kritické riziko u aktiva s vysokým dopadem, které selhalo při jeho poslední záloze, jde na začátek seznamu. Aktivum s nízkým dopadem s platným whitelistingem a nedávnou dobrou úplnou zálohou může pravděpodobně počkat).
- Oprava zavádění začíná a pokrok je aktualizován živě v globálním hlášení.
- v případě potřeby jsou ot technici na konzoli dohlížející na nasazení opravy.
- harmonogram a komunikace této potřeby jsou plně naplánovány a upřednostňovány údaji používanými centrálním týmem.
takto by se mělo zacházet se správou ot patchů. A stále více organizací začíná zavádět tento typ programu.
buďte proaktivní s kompenzačními ovládacími prvky
správa oprav ICS je těžká, Ano, ale prostě vzdát se pokusu není dobrá odpověď. S trochou předvídavosti je snadné poskytnout tři nejvýkonnější nástroje pro snadnější a efektivnější opravy a/nebo kompenzační kontroly. Insight vám ukáže, co máte, jak je nakonfigurován, a jak důležité je pro vás. Kontext umožňuje stanovit priority (první pokus o opravu-druhý vám vědět, jak a kde použít kompenzační ovládací prvky). Akce umožňuje opravit, chránit, odklonit atd. Spoléhat se pouze na monitorování je přiznat, že očekáváte požár a nákup více detektorů kouře by mohl minimalizovat škody. Jaký přístup by podle vás vaše organizace preferovala?