în acest articol scris de un furnizor al unei soluții de monitorizare a securității, argumentul principal (adesea ecou în alte publicații și diverse târguri) a fost că patch-ul sistemelor OT este greu. Autorul susține că, deoarece este greu, ar trebui să apelăm la alte metode de îmbunătățire a securității. Teoria lui este să pornească o tehnologie de alertare ca a lui și să asocieze alarmele în așteptare cu o echipă de răspuns la Incidente de securitate. Cu alte cuvinte, doar accepta patching este greu, renunta, și se toarnă mai mulți bani în procesul de învățare mai devreme (poate?) și să răspundă mai energic.
cu toate acestea, această concluzie (patch-uri este greu asa ca nu deranjez) este defect pentru o serie de motive. Ca să nu mai vorbim, el glosează și un factor foarte mare care complică semnificativ orice răspuns sau remediere care ar trebui luată în considerare.
primul motiv pentru care acest sfat este periculos este că pur și simplu nu puteți ignora patch-urile. Trebuie să faci ce poți, când poți, și când patching – ul nu este o opțiune, treci la planul B, C și D. A nu face nimic înseamnă că toate incidentele legate de cyber care își fac drum în mediul dvs. vor produce daune maxime. Acest lucru sună foarte mult ca M&m apărare de acum 20 de ani. Aceasta este ideea că soluția dvs. de securitate ar trebui să fie dură și crocantă la exterior, dar moale și mestecată la interior.
al doilea motiv pentru care acest sfat este defect este presupunerea că personalul de securitate OT (pentru răspunsul la incidente sau patch-uri) este ușor de găsit și implementat! Acest lucru nu este adevărat – de fapt, unul dintre incidentele de securitate ICS la care se face referire în articol subliniază că, în timp ce un patch era disponibil și gata de instalare, nu existau experți ICS disponibili pentru a supraveghea instalarea patch-urilor! Dacă nu putem elibera experții noștri în securitate pentru a implementa o protecție cunoscută, înainte de eveniment, ca parte a unui program proactiv de gestionare a corecțiilor, de ce credem că putem găsi bugetul pentru o echipă completă de răspuns la incidente după fapt, când este prea târziu?
în cele din urmă, piesa lipsă din acest argument este că provocările pentru gestionarea patch-urilor OT/ICS sunt exacerbate și mai mult de cantitatea și complexitatea activelor și arhitecturii într-o rețea ot. Pentru a fi clar, atunci când este lansat un nou patch sau o vulnerabilitate, capacitatea majorității organizațiilor de a înțelege câte active sunt în domeniu și unde se află este o provocare. Dar același nivel de înțelegere și profiluri de active va fi necesar ca orice echipă de răspuns la incidente să fie eficientă. Chiar și sfatul său de a ignora practica de patch-uri nu vă poate permite să evitați să construiți un inventar robust, contextual (baza pentru patch-uri!) ca fundament al programului dvs. de securitate cibernetică OT.
deci, ce ar trebui să facem? În primul rând, trebuie să încercăm să patch-uri. Există trei lucruri pe care trebuie să le includă un program Matur de gestionare a patch-urilor ICS pentru a avea succes:
- inventar contextual în timp Real
- automatizarea remedierii (atât fișiere de patch-uri, cât și protecții ad-hoc)
- identificarea și aplicarea controalelor compensatoare
inventar contextual în timp Real pentru gestionarea patch-urilor
majoritatea mediilor OT utilizează instrumente de patch-uri bazate pe Scanare, cum ar fi WSUS/SCCM care sunt destul de standard, dar nu prea perspicace pentru a ne arăta ce active avem și cum sunt configurate. Ceea ce este cu adevărat necesar sunt profilurile de active robuste, cu contextul lor operațional inclus. Ce vreau să spun prin asta? IP activ, model, sistem de operare etc. este o listă foarte sumară a ceea ce ar putea fi în domeniul de aplicare pentru cele mai recente patch-uri. Ceea ce este mai valoros este contextul operațional, cum ar fi criticitatea activelor pentru operațiuni sigure, localizarea activelor, proprietarul activelor etc. pentru a contextualiza în mod corespunzător riscul nostru emergent, deoarece nu toate activele OT sunt create egale. Deci, de ce să nu protejăm mai întâi sistemele critice sau să identificăm sisteme de testare adecvate (care reflectă sistemele critice de câmp) și să reducem strategic riscul?
și în timp ce construim aceste profiluri de active, trebuie să includem cât mai multe informații despre activele dincolo de IP, adresa Mac și versiunea OS. Informații cum ar fi software-ul instalat, utilizatori/cont, porturi, servicii, setările de registry, controalele cel privilegiu, AV, whitelisting și starea de backup etc. Aceste tipuri de surse de informații cresc semnificativ capacitatea noastră de a prioritiza și strategiza cu exactitate acțiunile noastre atunci când apare un nou risc. Vrei dovezi? Aruncați o privire la fluxul obișnuit de analiză oferit mai jos. De unde veți obține datele pentru a răspunde la întrebări în diferite etape? Cunoștințe tribale? Instinct? De ce nu date?
automatizarea remedierii pentru patch-uri software
o altă provocare de patch-uri software este implementarea și pregătirea pentru a implementa patch-uri (sau controale de compensare) la punctele finale. Una dintre cele mai consumatoare de timp sarcini în gestionarea patch-urilor OT este lucrarea de pregătire. De obicei, include identificarea sistemelor țintă, configurarea implementării patch-urilor, depanarea atunci când eșuează sau scanarea mai întâi, împingerea patch-urilor și re-scanarea pentru a determina succesul.
dar dacă, de exemplu, data viitoare când apare un risc precum BlueKeep, ați putea preîncărca fișierele pe sistemele țintă pentru a vă pregăti pentru următorii pași? Dvs. și echipa dvs. de securitate OT mai mică și mai agilă ați putea planifica strategic ce sisteme industriale ați rulat actualizări de patch-uri la primul, al doilea și al treilea pe baza oricărui număr de factori din profilurile dvs. de active robuste, cum ar fi locația activelor sau criticitatea.
făcând un pas mai departe, imaginați-vă dacă tehnologia de gestionare a patch-urilor nu a necesitat mai întâi o Scanare, ci mai degrabă a mapat deja patch-ul la activele din domeniu și pe măsură ce le-ați instalat (fie de la distanță pentru risc scăzut, fie personal pentru risc ridicat), acele sarcini și-au verificat succesul și au reflectat acel progres în tabloul de bord global?
pentru toate activele dvs. cu risc ridicat pe care nu le puteți sau nu doriți să le corectați acum, Puteți crea în schimb un port, un serviciu sau o modificare a utilizatorului/contului ca un control compensator ad-hoc. Deci, pentru o vulnerabilitate, cum ar fi BlueKeep, puteți dezactiva desktopul la distanță sau contul de invitat. Această abordare reduce imediat și semnificativ riscul actual și permite, de asemenea, mai mult timp pentru pregătirea eventualului plasture. Acest lucru mă aduce la acțiunile ‘fall back’ de ce să fac atunci când patch – uri nu este o opțiune de compensare controale.
ce sunt controalele compensatoare?
controalele compensatoare sunt pur și simplu acțiuni și setări de securitate pe care le puteți și ar trebui să le implementați în locul (sau mai degrabă, precum și) patch-urilor. Acestea sunt de obicei implementate proactiv (acolo unde este posibil), dar pot fi implementate într-un eveniment sau ca măsuri temporare de protecție, cum ar fi dezactivarea desktopului la distanță în timp ce faceți patch-uri pentru BlueKeep, pe care le extind în studiul de caz de la sfârșitul acestui blog.
identificați și aplicați controale compensatoare în securitatea OT
controalele compensatoare iau multe forme din lista albă a aplicației și menținerea antivirusului actualizat. Dar, în acest caz, vreau să mă concentrez pe ICS endpoint management ca o componentă cheie de susținere a gestionării patch-urilor OT.
controalele compensatoare pot și trebuie utilizate atât proactiv, cât și situațional. Nu ar fi o surpriză pentru nimeni în securitatea cibernetică OT să descopere conturi de administrare latente și software inutil sau neutilizat instalat pe puncte finale. De asemenea, nu este un secret faptul că principiile de întărire a sistemului de bune practici nu sunt aproape la fel de Universale pe cât ne-am dori.
pentru a ne proteja cu adevărat sistemele vechi, trebuie, de asemenea, să ne întărim bunurile prețioase. Un profil robust al activelor în timp real permite organizațiilor industriale să elimine cu exactitate și eficient fructele agățate scăzute (adică utilizatorii latenți, software-ul inutil și parametrii de întărire a sistemului) pentru a reduce semnificativ suprafața de atac.
în cazul nefericit, avem o amenințare în curs de dezvoltare (cum ar fi BlueKeep) adăugarea de controale compensatorii temporare este greu de realizat. Un studiu de caz rapid pentru a evidenția punctul meu de vedere:
- vulnerabilitatea BlueKeep este eliberată.
- echipa centrală dezactivează imediat desktop la distanță pe toate activele de teren și e-mailuri echipa de teren care necesită cereri specifice pe o bază sistem-cu-sistem pentru serviciul Desktop la distanță pentru a fi activat în timpul perioadei de risc.
- echipa centrală pre-încarcă fișierele de patch-uri pe toate activele din domeniu – nicio acțiune, doar pregătește-te.
- echipa centrală se reunește pentru a decide cel mai rezonabil plan de acțiune prin criticitatea activelor, locația, prezența sau absența controalelor compensatorii (adică, un risc critic asupra unui activ cu impact ridicat care nu a reușit ultima copie de rezervă merge în partea de sus a listei. Un activ cu impact redus, cu lista albă în vigoare și o copie de rezervă completă recentă poate aștepta probabil).
- lansarea patch-urilor începe, iar progresul este actualizat în direct în raportarea globală.
- acolo unde este necesar, tehnicienii OT sunt la consola care supraveghează implementarea patch-urilor.
- programul și comunicarea acestei nevoi sunt pe deplin planificate și prioritizate de datele utilizate de echipa centrală.
acesta este modul în care ar trebui tratată gestionarea patch-urilor OT. Și tot mai multe organizații încep să pună în aplicare acest tip de program.
fii proactiv cu controale compensatoare
ICS patch management este greu, Da, dar pur și simplu renunțarea la încercarea nu este un răspuns bun, fie. Cu un pic de previziune, este ușor să oferiți cele mai puternice trei instrumente pentru controale de patch-uri și/sau compensări mai ușoare și mai eficiente. Insight vă arată ce aveți, cum este configurat și cât de important este pentru dvs. Contextul vă permite să prioritizați (prima încercare de patch – a doua vă permite să știți cum și unde să aplicați controale compensatoare). Acțiunea vă permite să corectați, să protejați, să deflectați etc. Să te bazezi doar pe monitorizare este să recunoști că te aștepți la foc și cumpărarea mai multor detectoare de fum ar putea minimiza daunele. Ce abordare crezi că ar prefera organizația ta?