Nepaisant visų baisių pardavėjų ir pramonės ekspertų kalbų apie kibernetines atakas, palyginti nedaug atakų iš tikrųjų yra niokojančios. Tačiau „Jaguar Land Rover“ (JLR) ataka buvo.
JLR pažeidimas nebuvo koks nors nemalonus išpuolis, kuris kainavo kelis šimtus tūkstančių dolerių. Remiantis „Reuters“, ji savaitėms visiškai nutraukė gamybą, Britanijos ekonomikai greičiausiai kainuos daugiau nei 2 mlrd. USD ir paveiks net 5000 organizacijų. Tikri žmonės neteko darbo.
JK vyriausybė turėjo įsikišti su beveik 2 mlrd. USD paskolos garantija, kad JLR veiktų.
Košmaras išsipildė
JLR ataka buvo košmariškas scenarijus, kurį gamintojai žinojo, kad teoriškai gali įvykti. Kai tai iš tikrųjų atsitiko, daugelis gamybinių organizacijų bandė išsiaiškinti, kaip jos galėtų išvengti tokio paties likimo.
Iš karto paaiškėjo viena problema: tiekimo grandinė yra viena silpniausių gamintojų saugumo grandžių. Galų gale, JLR ataka kilo įmonės tiekimo grandinėje dėl trečiųjų šalių rangovų naudojamų kredencialų kompromiso.
Kaip užpuolikai įsilaužia į tiekimo grandines? Viena galinga taktika apima programinės įrangos programų, kurias naudoja gamintojai ir jų tiekimo grandinės partneriai, kūrimo įrankius ir procesus.
Tai gali būti ne toks išpuolis, kuris sužlugdė JLR, arba gali; išsami informacija apie išpuolio kilmę nėra vieša. Tačiau svarbi pamoka yra ta, kad jei gamintojai ir jų tiekimo grandinės partneriai nėra budrūs, kad programinės įrangos tiekėjai naudotų saugią kūrimo praktiką, jie pasilieka atviri JLR atakų lygiui.
Tiekimo grandinės kryžkelėje
Atakos prieš tiekimo grandines kuriant programinę įrangą nėra naujiena; bet jie išlieka galingi ir pavojingi. Kai kurios iš garsiausių kada nors įvykdytų kibernetinių atakų buvo susijusios su tokia taktika, įskaitant liūdnai pagarsėjusią 2020 m. ataką prieš „SolarWinds“, 2021 m. ataką prieš Kaseya VSA ir 2023 m. ataką prieš VoIP teikėją 3CX.
Neseniai užpuolikai sukūrė naują požiūrį: jie į programinės įrangos kūrimo procesą išleidžia kenkėjiškų mazgų paketų tvarkykles (NPM). „JavaScript“ kūrėjai naudoja NPM, norėdami bendrinti ir įdiegti daugkartinio naudojimo kodą.
Kai NPM yra kenkėjiški, ataka gali greitai išplisti, trukti mėnesius ir patekti į įvairias programas.
Vienas iš naujausių NPM taikymo pavyzdžių yra „Shai-Hulud“ kriptovaliuta, kuri, kaip pranešama, sukompromitavo daugiau nei 500 NPM paketų, įskaitant kelis, kuriuos naudoja kibernetinio saugumo teikėjai.
NPM atakos yra tik vienas būdas, kurį užpuolikai rado, kaip patekti į tiekimo grandines. Pavyzdžiui, užpuolikai taip pat gali pažeisti programinės įrangos tiekėjų naujinius ir išnaudoti programinės įrangos spragas.
Esmė ta, kad tiekimo grandinės programos yra pažeidžiamos, o gamintojai turi būti tikri, kad jų partnerių naudojamos programos yra saugios.
„Acronis Cyber Protect Cloud“ integruoja duomenų apsaugą, kibernetinį saugumą ir galinių taškų valdymą.
Lengvai padidinkite kibernetinės apsaugos paslaugas iš vienos platformos – efektyviai vykdydami savo MSP verslą.
Nemokamas 30 dienų bandomasis laikotarpis
Reikia atidesnių vertinimų
Kilus pavojui tiekimo grandinėms, gamintojai turi įvertinti esamus ir galimus partnerius, taikančius saugaus programinės įrangos kūrimo gyvavimo ciklo (SSDLC) praktiką.
Daugumoje operacinių technologijų (OT) aplinkų atliekant pirkimų vertinimus daug dėmesio skiriama tiekėjo finansinei būklei, paslaugų lygio susitarimams ir infrastruktūros saugumui. Tačiau jie dažnai nepastebi programinės įrangos kūrimo proceso pažeidžiamumų – problemų, kurios gali sabotuoti tiekimo grandinės programas.
Štai kodėl tiek gamintojams, tiek jų tiekimo grandinės partneriams labai svarbu užtikrinti griežtą SSDLC praktiką. Kai gamintojai neužtikrina SSDLC praktikos tarp savo partnerių, jiems gresia veiklos prastovos, finansiniai nuostoliai, atitikties pažeidimai ir žala reputacijai.
SSDLC: daugiau nei atitikties žymimieji langeliai
Kuo SSDLC toks svarbus ir efektyvus? Pirmiausia tai įpareigoja ES NIS 2 direktyva, kuriai reikalingas oficialus, dokumentuotas SSDLC procesas.
Tai taip pat reiškia esminį poslinkį nuo saugos traktavimo kaip priedo po kūrimo prie jo įterpimo visame programinės įrangos kūrimo procese.
Reikalavimų analizės metu pastebėtas pažeidžiamumas gali užtrukti kelias valandas, kol bus pašalintas. Tas pats trūkumas, aptiktas po išleidimo, gali prireikti kelių savaičių skubios pagalbos.
Praktiškai brandus SSDLC diegimas apima:
- Apsauga pagal dizainą: Apibrėžiami saugos reikalavimai ir modeliuojamos grėsmės prieš įrašant bet kokį kodą.
- Saugi kodavimo praktika: Kūrėjai, apmokyti saugos, privalomo kodo peržiūros ir automatinio saugos testavimo srityse.
- Priklausomybės valdymas: Trečiųjų šalių komponentai tikrinami, stebimi ir prižiūrimi naudojant programinės įrangos sąskaitų rinkinio (SBOM) praktiką.
- Saugūs išleidimo vamzdynai: Pasirašyti atnaujinimai, patikrintas vientisumas ir pristatyti sustiprintais kanalais.
- Pažeidžiamumo valdymas: Koordinuoti atskleidimo procesai ir apibrėžti atsakymo į saugumo problemas terminai.
Gamintojams tai reiškia, kad programinė įranga, valdanti gamybos linijas, valdanti svarbias sistemas ir jungianti pramonines operacijas, turi įterptą saugą nuo pirmosios kodo eilutės iki galutinio diegimo.
Patikimas saugaus kūrimo įrodymas: IEC 62443-4-1 sertifikatas
Pramonės sertifikatai yra patikimas SSDLC naudojimo kūrimo procese matas. Nors egzistuoja įvairūs saugumo sertifikatai, IEC 62443-4-1 turi ypatingą reikšmę gamybos tiekimo grandinėms.
IEC 62443 standartų šeima konkrečiai skirta pramoninės automatikos ir valdymo sistemų saugumui, būtent aplinkai, kurioje veikia gamintojai.
Šioje sistemoje IEC 62443-4-1 daugiausia dėmesio skiriama saugaus produkto kūrimo gyvavimo ciklo reikalavimams ir yra vienas griežčiausių ir aktualiausių OT programinės įrangos tiekėjų vertinimo standartų.
Skirtingai nei bendrosios informacijos saugos sistemos, IEC 62443-4-1 sertifikatas parodo, kad tiekėjas įdiegė praktiką, specialiai sukurtą pramoninėms aplinkoms, kuriose veikimo laikas yra labai svarbus, langų pataisymas gali būti ribotas, o dėl programinės įrangos gedimų gali kilti pasekmių fiziniam pasauliui.
IEC 62443-4-1 sertifikatas suteikia konkrečių, nepriklausomai patikrintų įrodymų, kad programinės įrangos tiekėjai sistemingai kuria kiekvieno produkto saugumą, o ne tik žada. Originalios įrangos gamintojams (OĮG), sistemų integratoriams ir galutiniams klientams gamybos ir ypatingos svarbos infrastruktūros srityse tai suteikia esminį pasitikėjimo pagrindą.
Vertinimų permąstymas
Vertindami partnerius atsižvelgdami į SSDLC, gamintojai turėtų:
- Įterpti SSDLC kriterijus į pirkimo procesus: Į RFP ir sutartis įtraukite saugaus kūrimo reikalavimus, kad tiekėjai suprastų lūkesčius nuo pat pradžių.
- Prašyti struktūrinių įrodymų: Reikalaukite sertifikavimo apimčių, auditorių ataskaitų, SBOM įrašų ir testavimo rezultatų kaip deramo patikrinimo dalį.
- Pirmenybę teikite atitinkamiems sertifikatams: Specialiai ieškokite IEC 62443-4-1, skirto gaminių tiekėjams, dirbantiems pramoninėje aplinkoje, palaikomą ISO/IEC 27001, skirtą organizacijos saugos valdymui ir, kai taikoma, debesims būdingiems sertifikatams.
- Nuolat vertinkite brandą: Pereikite už dvejetainių klausimynų ribų ir vertinkite tiekėjus pagal brandos tęstinumą, nuolat stebint tiekėjų valdymą.
Gamintojai nebegali sau leisti vertinti tiekėjų saugumo kaip pratimo, orientuoto tik į infrastruktūrą ir operacijas. Kūrimo ciklas yra ta vieta, kur atsiranda pažeidžiamumas, o gamintojai turi užtikrinti, kad jų būtų išvengta.
Apie Acronis TRU
„Acronis Threat Research Unit“ (TRU) yra kibernetinio saugumo ekspertų komanda, besispecializuojanti grėsmių žvalgybos, dirbtinio intelekto ir rizikos valdymo srityse. TRU komanda tiria kylančias grėsmes, teikia saugumo įžvalgas ir padeda IT komandoms teikti gaires, reagavimą į incidentus ir mokomuosius seminarus.
Peržiūrėkite naujausius TRU tyrimus
Rėmė ir parašė Acronis.
