tässä artikkelissa kirjoittanut toimittaja turvallisuuden seuranta ratkaisu, pääargumentti (usein toistettu muissa julkaisuissa ja eri tradeshows) oli, että paikkaus OT järjestelmien on vaikea. Kirjoittaja esittää, että koska se on vaikeaa, meidän pitäisi kääntyä muiden keinojen puoleen turvallisuuden parantamiseksi. Hänen teoriansa on käynnistää hänen kaltaisensa hälytysteknologia-ja yhdistää vireillä olevat hälytykset turvavälikohtausten vastausryhmään. Toisin sanoen, vain hyväksyä paikkaus on vaikeaa, luopua, ja kaada enemmän rahaa oppimiseen aikaisemmin (ehkä?) ja vastaa voimakkaammin.
tämä johtopäätös (paikkaaminen on vaikeaa, joten älä vaivaudu) on kuitenkin virheellinen paristakin syystä. Puhumattakaan, hän myös kaunistelee erittäin suuri tekijä, joka merkittävästi vaikeuttaa mitään vastausta tai korjaamista, joka pitäisi harkita.
ensimmäinen syy, miksi tämä on vaarallinen neuvo, on se, että paikkaamista ei yksinkertaisesti voi jättää huomiotta. Sinun täytyy tehdä voitavasi, kun voit, ja kun paikkaaminen ei ole vaihtoehto, siirryt suunnitelmaan B, C ja D. Jos ei tehdä mitään, kaikki kyber-liittyvät vaaratilanteet, jotka tekevät tiensä ympäristöösi, tuottavat mahdollisimman suurta vahinkoa. Tämä kuulostaa paljolti M&M-puolustukselta 20 vuoden takaa. Tämä on ajatus siitä, että turvaratkaisusi pitäisi olla kova ja rapea ulkopuolelta, mutta pehmeä ja pureva sisältä.
toinen syy, miksi tämä neuvo on virheellinen, on oletus, että OT: n turvallisuushenkilöstö (hätätilanteisiin vastaamiseen tai paikkaamiseen) on helppo löytää ja ottaa käyttöön! Tämä ei ole totta – itse asiassa yksi artikkelissa mainituista ICS-tietoturvatapahtumista huomauttaa, että vaikka laastari oli saatavilla ja valmis asennettavaksi, ei ollut ICS-asiantuntijoita valvomassa laastarin asennusta! Jos emme voi vapauttaa tietoturva-asiantuntijoitamme ottamaan käyttöön tunnettua, tapahtumaa edeltävää suojausta osana ennakoivaa korjaustiedostojen hallintaohjelmaa, miksi uskomme löytävämme budjetin koko tapahtumatyöryhmälle sen jälkeen, kun on liian myöhäistä?
tästä väitteestä puuttuu vielä se, että OT/ICS-korjaustiedostojen hallinnan haasteita pahentaa entisestään ot-verkon omaisuuden ja arkkitehtuurin määrä ja monimutkaisuus. On selvää, kun uusi laastari tai haavoittuvuus vapautetaan, useimpien organisaatioiden kyky ymmärtää, kuinka monta omaisuutta on soveltamisala ja missä ne ovat, on haaste. Mutta saman tason näkemystä ja voimavaraprofiileja vaaditaan kaikilta vaaratilanteiden vastausryhmiltä, jotta ne olisivat tehokkaita. Jopa hänen neuvonsa sivuuttaa käytäntö paikkaus ei voi antaa sinun välttää rakentaa vankka, asiayhteyteen inventaario (perusta paikkaus!) Oman ot-kyberturvallisuusohjelman pohjana.
Joten, mitä meidän pitäisi tehdä? Ennen kaikkea meidän on yritettävä paikata. On kolme asiaa, jotka kypsä ICS patch hallintaohjelma on sisällytettävä onnistuakseen:
- Real-time, contextual inventory
- automation of remediation (both patch files and ad-hoc protections)
- Identification and application of compensating controls
Real-time contextual inventory for patch management
useimmat OT-ympäristöt käyttävät scan-pohjaisia paikkaustyökaluja, kuten WSUS/SCCM, joka ovat melko standardi, mutta eivät liian oivaltava näyttää meille, mitä omaisuutta meillä on ja miten ne on määritetty. Todella tarvitaan vankkaa omaisuusprofiilia, johon sisältyy niiden toimintaympäristö. Mitä tarkoitan tällä? Omaisuuserän IP, malli, käyttöjärjestelmä jne. on hyvin pintapuolinen luettelo siitä, mitä voisi olla soveltamisala uusin laastari. Arvokkaampaa on toimintaympäristö, kuten varojen kriittisyys turvalliseen toimintaan, omaisuuden sijainti, omaisuuden omistaja jne. jotta voidaan asianmukaisesti kontekstualisoida syntymässä riski, koska kaikki OT varat eivät ole tasavertaisia. Miksi emme siis ensin suojaisi kriittisiä järjestelmiä tai tunnistaisi sopivia testausjärjestelmiä (jotka heijastavat kriittisiä kenttäjärjestelmiä) ja vähentäisi strategisesti riskejä?
ja samalla kun rakennamme näitä omaisuusprofiileja, meidän on sisällettävä mahdollisimman paljon tietoa IP -, Mac-osoite-ja käyttöjärjestelmäversion ulkopuolisista omaisuuseristä. Tiedot, kuten asennetut ohjelmistot, käyttäjät / tili, portit, palvelut, rekisterin asetukset, vähiten etuoikeuksia koskevat säädöt, AV, whitelisting ja backup status jne. Tämäntyyppiset tietolähteet lisäävät merkittävästi kykyämme priorisoida ja strategisoida toimintamme tarkasti, kun syntyy uusia riskejä. Haluatko todisteita? Tutustu alla olevaan tavalliseen analyysivirtaan. Mistä saat tiedot, joilla voit vastata kysymyksiin eri vaiheissa? Heimotuntemusta? Vaisto? Miksei data?
automatisoida korjaus ohjelmiston paikkaukseen
toinen ohjelmiston paikkaus haaste on käyttöönotto ja valmistautuminen korjaustiedostojen (tai kompensoivien kontrollien) käyttöönottoon päätepisteisiin. Yksi aikaa vievimmistä tehtävistä OT patch management on prep työ. Se sisältää tyypillisesti kohdejärjestelmien tunnistamisen, korjaustiedostojen käyttöönoton määrittämisen, vianmäärityksen, kun ne epäonnistuvat tai skannaus ensin, korjaustiedoston työntämisen ja uudelleenskannauksen onnistumisen määrittämiseksi.
mutta mitä jos esimerkiksi seuraavan kerran, kun bluekeepin kaltainen riski ilmaantui, voisit esikuormata tiedostosi kohdejärjestelmiin valmistautuaksesi seuraaviin vaiheisiin? Sinä ja pienempi, ketterämpi ot security team voisi strategisesti suunnitella, mitkä teollisuuden järjestelmät rullattu patch päivitykset ensimmäinen, toinen, ja kolmas perustuu useisiin tekijöihin vankan omaisuuden profiileja, kuten omaisuuden sijainti tai kriittisyys.
jos korjaustiedostojen hallintateknologia ei vaatisi ensin skannausta, vaan olisi jo kartoittanut laastarin sisältämiin resursseihin ja kun olet asentanut ne (joko etänä pienen riskin tai henkilökohtaisesti suuren riskin varalta), nämä tehtävät varmistivat menestyksensä ja heijastivat tätä edistystä maailmanlaajuisessa kojelaudassasi?
kaikille korkean riskin omaisuuksillesi, joita et voi tai halua korjata juuri nyt, voit sen sijaan luoda portin, palvelun tai käyttäjän/tilin muutoksen tilapäisenä kompensoivana kontrollina. Joten haavoittuvuus, kuten BlueKeep, voit poistaa käytöstä etätyöpöydän tai vieras tili. Tämä lähestymistapa vähentää välittömästi ja merkittävästi nykyistä riskiä ja antaa myös enemmän aikaa valmistautua mahdolliseen laastariin. Tämä tuo minut ’fall back’ toimia, mitä tehdä, kun paikkaus ei ole vaihtoehto – kompensoiva valvontaa.
mitä kompensoivat kontrollit ovat?
kompensoivat kontrollit ovat yksinkertaisesti toimintoja ja suojausasetuksia, jotka voit ja jotka sinun tulisi ottaa käyttöön (tai pikemminkin yhtä hyvin kuin) paikkauksen sijasta. Ne ovat tyypillisesti käytössä ennakoivasti (jos mahdollista), mutta voidaan ottaa käyttöön tapahtuma tai väliaikaisina suojaustoimenpiteinä, kuten poistamalla remote desktop kun laastari BlueKeep, jota laajennan tapaustutkimuksessa lopussa tämän blogin.
Tunnista ja käytä kompensoivia kontrolleja OT-suojauksessa
kompensoivat kontrollit ovat monenmuotoisia sovelluksen whitelistauksesta ja virustorjunnan pitämisestä ajan tasalla. Mutta tässä tapauksessa haluan keskittyä ICS päätepisteiden hallinta keskeisenä tukena OT patch management.
kompensoivia kontrolleja voidaan ja tulee käyttää sekä ennakoivasti että tilannekohtaisesti. Ei olisi yllätys kenellekään OT cyber security löytää lepotilassa admin tilit ja tarpeettomat tai käyttämättömät ohjelmistot asennettu päätepisteisiin. Ei ole myöskään mikään salaisuus, että parhaiden käytäntöjen karkaisuperiaatteet eivät ole läheskään niin yleisiä kuin haluaisimme.
suojellaksemme todella OT-järjestelmiämme meidän on myös kovetettava arvostettua omaisuuttamme. Reaaliaikaisen, vankan voimavarojen profiilin avulla teollisuusorganisaatiot voivat tarkasti ja tehokkaasti poistaa matalalla roikkuvat hedelmät (eli lepotilassa olevat käyttäjät, tarpeettomat ohjelmistot ja järjestelmän kovettumisparametrit) vähentääkseen merkittävästi hyökkäyspintaa.
valitettavassa tapauksessa meillä on nouseva uhka (kuten BlueKeep) lisäämällä väliaikaisia kompensoivia tarkastuksia on mahdollista. Nopea tapaustutkimus pointtini korostamiseksi:
- BlueKeep-haavoittuvuus on julkaistu.
- keskustiimi poistaa etätyöpöydän välittömästi käytöstä kaikilla kenttäomaisuuksilla ja sähköpostien kenttäryhmällä, joka vaatii järjestelmäkohtaisia pyyntöjä etätyöpöytäpalvelun käyttöön ottamiseksi riskijakson aikana.
- keskustiimi esikuormasi paikkatiedostot kaikkiin ulottuvuuksiin – ei toimia, vain valmista.
- keskustiimi kokoontuu päättämään järkevimmän toimintasuunnitelman omaisuuserien kriittisyyden, sijainnin, kompensoivien kontrollien läsnäolon tai puuttumisen perusteella (ts.viimeisen varmistuksensa pettäneen suuritehoisen omaisuuserän kriittinen riski menee listan kärkeen. Pieni vaikutus voimavara whitelisting voimassa ja viimeaikainen Hyvä täysi varmuuskopio voi todennäköisesti odottaa).
- paikkauksen käyttöönotto alkaa, ja edistymistä päivitetään suorana maailmanlaajuisessa raportoinnissa.
- tarvittaessa ot-teknikot ovat konsolilla valvomassa laastarin käyttöönottoa.
- tämän tarpeen aikataulu ja viestintä on täysin suunniteltu ja priorisoitu keskusryhmän käyttämien tietojen perusteella.
näin OT patch management tulisi hoitaa. Ja yhä useammat organisaatiot ovat alkaneet toteuttaa tällaista ohjelmaa.
ole proaktiivinen kompensoivien kontrollien kanssa
ICS-korjaustiedostojen hallinta on vaikeaa, Kyllä, mutta pelkkä yrittämisestä luopuminen ei ole myöskään hyvä vastaus. Pienellä ennakoinnilla on helppo tarjota kolme tehokkainta työkalua helpompaan ja tehokkaampaan säätöjen paikkaamiseen ja / tai kompensointiin. Insight näyttää, mitä sinulla on, miten se on määritetty ja kuinka tärkeää se on sinulle. Kontekstin avulla voit priorisoida (ensimmäinen yritys paikata-toinen kertoo, miten ja missä käyttää kompensoivia ohjausobjekteja). Toiminnan avulla voit korjata, suojata, taipua, jne. Jos luottaa vain valvontaan, myöntää odottavansa tulipaloa ja ostaa lisää palovaroittimia, saattaa minimoida vahingot. Kumman lähestymistavan luulet organisaatiosi valitsevan?