Toimitusketjun riskit saivat sinut alas? Pysy rauhallisena ja strategisesti!

Tietoturvateollisuus menettää kollektiivisesti järkensä, kun ohjelmistoista löydetään uusia haavoittuvuuksia. OpenSSL ei ole poikkeus, ja kaksi uutta haavoittuvuutta ylitti uutissyötteet lokakuun lopussa ja marraskuun alussa 2022. Löytäminen ja paljastaminen ovat vasta tämän loputtoman haavoittuvuussyklin alkua. Asianomaiset organisaatiot joutuvat korjaamaan, mikä on erityisen tuskallista IT-alan etulinjassa oleville. Tietoturvajohtajien on ylläpidettävä tehokasta kyberturvallisuusstrategiaa, joka auttaa suodattamaan osan uusien haavoittuvuuksien aiheuttamasta melusta, tunnistamaan vaikutukset toimitusketjuihin ja turvaamaan omaisuutensa vastaavasti.

Toimitusketjuhyökkäykset eivät katoa

Noin vuoden aikana olemme kärsineet vakavista komponenttien haavoittuvuuksista, mukaan lukien log4j, Kevätpuitteetja OpenSSL. Vanhojen haavoittuvuuksien hyödyntäminen ei myöskään lopu koskaan toteutuksissa, jotka on määritetty väärin tai jotka käyttävät tunnettuja haavoittuvia riippuvuuksia. Marraskuussa 2022 yleisö sai tietää hyökkäyskampanja liittovaltion siviilihallitusta vastaan (FCEB), joka johtuu valtion tukemasta Iranin uhkasta. Tämä Yhdysvaltain liittovaltion entiteetti käytti VMware Horizon -infrastruktuuria, joka sisälsi Log4Shell-haavoittuvuuden, joka toimi ensimmäisenä hyökkäysvektorina. FCEB joutui monimutkaiseen hyökkäysketjuun, joka sisälsi sivuttaisliikkeen, valtuustietojen kompromissin, järjestelmän kompromissin, verkon pysyvyyden, päätepisteiden suojauksen ohituksen ja kryptojauksen.

Organisaatiot voivat kysyä "miksi ylipäätään kuluttaa OSS:ää?" haavoittuvien pakettien, kuten OpenSSL:n tai Log4j:n, aiheuttamien tietoturvahäiriöiden jälkeen. Toimitusketjuhyökkäykset jatkavat nousuaan, koska komponenttien uudelleenkäytöstä on "hyvää liiketaloudellista järkeä" kumppaneille ja toimittajille. Suunnittelemme järjestelmiä käyttämällä olemassa olevaa koodia uudelleen sen sijaan, että rakennamme tyhjästä. Tällä vähennetään suunnittelutyötä, skaalataan toiminnallisesti ja toimitetaan nopeasti. Avoimen lähdekoodin ohjelmistoja (OSS) pidetään yleensä luotettavina sen vastaanottaman julkisen tarkastelun perusteella. Ohjelmistot kuitenkin muuttuvat jatkuvasti, ja ongelmia syntyy koodausvirheistä tai linkitetyistä riippuvuuksista. Uusia ongelmia paljastuu myös testaus- ja hyödyntämistekniikoiden kehitys.

Toimitusketjun haavoittuvuuksien poistaminen

Organisaatiot tarvitsevat asianmukaiset työkalut ja prosessit varmistaakseen nykyaikaisen suunnittelun. Perinteiset lähestymistavat, kuten haavoittuvuuden hallinta tai ajankohtaiset arvioinnit, eivät yksin pysy perässä. Säännökset voivat silti sallia nämä lähestymistavat, mikä säilyttää kuilun "turvallisen" ja "yhteensopivan" välillä. Useimmat organisaatiot haluavat saavuttaa jonkin tason DevOps-kypsyysasteen. "Jatkuva" ja "automaattinen" ovat yleisiä DevOps-käytäntöjen piirteitä. Turvaprosessit eivät saa erota toisistaan. Tietoturvajohtajien on keskityttävä koko rakennus-, toimitus- ja suoritusvaiheen aikana osana turvallisuusstrategiaansa:

• Jatkuva skannaus CI/CD:llä: Pyri turvaamaan rakennusputkistot (eli vaihto vasemmalle), mutta huomaa, että et voi skannata kaikkea koodia ja sisäkkäistä koodia. Menestystä siirtovasemmalle -lähestymistapojen kanssa rajoittavat skannerin tehokkuus, skannerin tulosteen korrelaatio, julkaisupäätösten automatisointi ja skannerin valmistuminen julkaisuikkunoissa. Työkalujen pitäisi auttaa priorisoimaan löydösten riskit. Kaikki löydökset eivät ole käytännöllisiä, eivätkä haavoittuvuudet välttämättä ole hyödynnettävissä arkkitehtuurissasi.

• Jatkuva skannaus toimituksen aikana: Kompromisseja ja ympäristön ajautumista tapahtuu. Sovellukset, infrastruktuuri ja työkuormat tulee tarkistaa toimituksen aikana, jos jokin on vaarantunut digitaalisessa toimitusketjussa, kun ne hankitaan rekistereistä tai arkistoista ja bootstrattiin.

• Jatkuva tarkistus ajon aikana: Suorituksenaikainen tietoturva on monien tietoturvaohjelmien lähtökohta, ja turvallisuuden valvonta on useimpien kyberturvallisuustoimien perusta. Tarvitset mekanismeja, jotka voivat kerätä ja korreloida telemetriaa kaikentyyppisissä ympäristöissä, mukaan lukien pilvi-, kontti- ja Kubernetes-ympäristöt. Suorituksen aikana kerättyjen oivallusten pitäisi palata aikaisempiin rakennus- ja toimitusvaiheisiin. Identiteetti ja palveluvuorovaikutus

• Priorisoi suorituksen aikana paljastuneet haavoittuvuudet: Kaikki organisaatiot kamppailevat saadakseen riittävästi aikaa ja resursseja kaiken skannaamiseen ja korjaamiseen. Riskeihin perustuva priorisointi on olennaista turvallisuusohjelmatyössä. Internet-altistuminen on vain yksi tekijä. Toinen on haavoittuvuuden vakavuus, ja organisaatiot keskittyvät usein suuriin ja kriittisiin vakaviin ongelmiin, koska niillä katsotaan olevan suurin vaikutus. Tämä lähestymistapa voi silti hukata suunnittelu- ja turvallisuustiimien syklejä, koska he saattavat jahtaa haavoittuvuuksia, jotka eivät koskaan lataudu ajon aikana ja joita ei voida hyödyntää. Käytä ajonaikaista älykkyyttä varmistaaksesi, mitä paketteja todella ladataan käynnissä oleviin sovelluksiin ja infrastruktuuriin, jotta tiedät organisaatiosi todellisen turvallisuusriskin.

Olemme luoneet tuotekohtaiset ohjeet ohjata asiakkaita viimeaikaisen OpenSSL-hulluuden läpi.

Uusin OpenSSL-haavoittuvuus ja Log4Shell muistuttavat meitä kyberturvallisuusvalmiuksien ja tehokkaan tietoturvastrategian tarpeesta. Meidän on muistettava, että CVE-ID:t ovat vain niitä tunnettuja ongelmia julkisissa ohjelmistoissa tai laitteistoissa. Monet haavoittuvuudet jäävät ilmoittamatta, erityisesti heikkoudet kotimaisessa koodissa tai ympäristön virheelliset konfiguraatiot. Kyberturvallisuusstrategiasi tulee ottaa huomioon hajautettu ja monipuolinen nykyaikaisen suunnittelun teknologia. Tarvitset modernisoidun haavoittuvuuksien hallintaohjelman, joka käyttää ajonaikaisia ​​näkemyksiä priorisoidakseen suunnittelutiimien korjaustyöt. Tarvitset myös uhkien havaitsemis- ja reagointivalmiuksia, jotka korreloivat signaaleja eri ympäristöissä yllätysten välttämiseksi.

kirjailijasta

Michael Isbitski, Sysdigin kyberturvallisuusstrategian johtaja, on tutkinut ja neuvonut kyberturvallisuutta yli viiden vuoden ajan. Hän on perehtynyt pilviturvallisuuteen, konttiturvallisuuteen, Kubernetes-tietoturvaan, API-tietoturvaan, tietoturvatestaukseen, mobiilitietoturvaan, sovellusten suojaukseen ja turvalliseen jatkuvaan toimitukseen. Hän on ohjannut lukemattomia organisaatioita maailmanlaajuisesti niiden turvallisuushankkeissa ja heidän liiketoimintansa tukemisessa.

Ennen tutkimus- ja neuvontakokemustaan ​​Mike oppi monia kovia opetuksia IT:n etulinjoilla yli 20 vuoden käytännön ja johtajuuden kokemuksella, joka keskittyi sovellusten tietoturvaan, haavoittuvuuksien hallintaan, yritysarkkitehtuuriin ja järjestelmäsuunnitteluun.