Zárja le a szoftver-ellátási láncot a „Secure by Design” funkcióval

A biztonságot a legalapvetőbb szinten előtérbe helyező szoftverek azt jelentik, hogy a rendszert úgy kell megtervezni, hogy az ügyfelek biztonsága legyen a kulcsfontosságú cél, nem pedig egy speciális funkció. És ez a koncepció – a tervezéstől függően – egyre fontosabbá válik, ahogy a támadók egyre gyakrabban veszik célba az ellátási láncokat.

„Megértik, hogy az ellátási lánc sikeres kihasználásával nagyobb hatást érhetnek el” – mondja Thomas Pace, a NetRise vezérigazgatója. Mivel a hagyományos biztonsági megoldások, mint például az EDR, a tűzfalak és a levélszemétszűrők kiválóan alkalmasak a közvetlen támadások megelőzésére, a támadóknak a láncban feljebb kell keresniük a nyílásokat.

Az összeillesztett rendszerek pedig éppen ilyen nyitást biztosítanak. „A kibertámadások könnyebbek, ha a vállalkozások és a szállítók utólag megpróbálják „felcsavarni” a biztonságot” – mondja David Brumley, a ForAllSecure vezérigazgatója. „Olyan ez, mintha egy utángyártott sztereót helyeznénk az autóba – egyszerűen nem működik pontosan.”

A szoftverbiztonság globális fokozása érdekében a Kiberbiztonsági és Infrastruktúrabiztonsági Ügynökség (CISA) kezdeményezést javasolt, amelynek célja a fejlesztési gyakorlatok forradalmasítása azáltal, hogy a szoftverfejlesztés életciklusába beépíti a „beépített biztonságos” elveket. Ez a proaktív biztonsági intézkedések irányába történő sarkalatos elmozdulást tükrözi.

A információkérés a visszatérő szoftversérülékenységek kezelésére, a működési technológia megerősítésére és a biztonságos gyakorlatok költségekre gyakorolt ​​hatásának felmérésére összpontosít. A 20. február 2024-ig nyitva álló véleményezési felhívás a technológiai gyártók és a fogyasztók kollektív felelősségét is hangsúlyozza egy olyan jövő előmozdításában, ahol a technológia eredendően biztonságos.

„A tervezési biztonság azt jelenti, hogy a biztonság része annak, ahogy a szoftvert az alapoktól kezdve felépíteni” – magyarázza Brumley. "Ez azt jelenti, hogy sokkal robusztusabb a támadásokkal szemben."

A biztonság alapszintje

Ken Dunham, a Qualys Threat Research Unit kiberfenyegetésekért felelős igazgatója elmagyarázza, hogy a tervezési biztonság az architektúrával és a kockázatkezelési elvekkel kezdődik, mielőtt a szervezet áttérne a felhőre vagy elkezdené használni a felhőt.

„Ez a modern, összetett hibrid infrastruktúra kritikus eleme” – mondja. „A megosztott felelősség világában a szervezeteknek el kell dönteniük, hogy mely kockázatok elfogadhatók, és melyek azok, amelyek nagyobb kockázatot jelentenek a harmadik felekkel szemben, mint a teljes tulajdonú és házon belül kezelt kockázatokat.”

Rámutat, hogy a szoftvergyártás életciklusa egyre összetettebb, és sok érdekelt félnek kell lennie, akiknek biztonságban kell lenniük a kockázatok csökkentése érdekében. Dunham megkérdezi: „A fejlesztői, akiknek fontosak a funkcionalitás és a felhasználói élmény, jártasak a biztonságos kódolási elvekben, a modern kori támadásokban, a biztonsági ellenintézkedésekben és a SecOps-ban?”

A szervezeti biztonsági elvárások nyomást gyakorolnak a bevezető csapatra, hogy megfelelően telepítsék, konfigurálják és figyeljék a szoftvereket az üzleti architektúrán belül. "Mennyire érettek az incidensekre adott válaszok és a kiberfenyegetések felderítő szolgálatai?" kérdezi. "Bízol bennük egy hibrid felhővilágban, ahol rendkívüli sebességgel lehet egy összetett behatolási támadás?"

„Ha megvannak a megfelelő emberek, a folyamat jól érthető” – ért egyet Brumley. „Mélyreható védelemmel építi meg a terméket, győződjön meg arról, hogy függőségei és harmadik féltől származó szoftverei naprakészek, és olyan modern technikát használ, mint a fuzzing az ismeretlen sebezhetőségek felkutatására.”

Brumley esetében a biztonságos alapértelmezésben azt jelenti, hogy olyan biztonságot kell tervezni, amely összhangban van a szoftverhasználattal. „Vannak olyan tervezési alapelvek, amelyek több alapelvet is átfognak – akárcsak a felhőkarcoló építésekor, a szerkezeti támogatástól a légkondicionálásig mindenre gondolni kell” – magyarázza.

Paradigmaváltás szükséges az IT biztonságban

Dunham megjegyzi, hogy 2023 volt tele példákkal ahol versenykörülmények nulla napig létezett – a sebezhetőségeket a rossz színészek gyorsabban fordították vissza és fegyverezték fel, mint szervezetek foltozhatnák őket.

„Ennyi idő után is vannak olyan szervezetek, amelyek a Log4J sebezhetőségeinek befoltozásával küzdenek” – mutat rá.

Azt mondja, hogy a szervezeteknek azonosítaniuk kell belső és külső támadási felületüket, és ennek megfelelően prioritást kell adniuk az eszközöknek és a kockázatkezelésnek, hogy előrébb kerülhessenek, ha a sebezhetőséghez kapcsolódó kizsákmányolás és támadási kockázat nő.

Pace szemszögéből az IT-biztonsági ágazatnak paradigmaváltáson kell keresztülmennie a kockázatok mérlegelésében és a legjobb prioritási sorrendben – és ez csak az ellátási lánc láthatósága mellett történhet meg. Megosztott egy példát, amelyben egy „nagyon nagy szervezet” nem tudta, milyen függőségei vannak a biztonsági rendszerének, amikor kötelességszerűen frissítette a rendszert. „A frissítés után egy sebezhetőség-ellenőrző vizsgálta át, és megállapították, hogy a legutóbbi kritikus Apache Struts sebezhetőség jelen volt” – mondja. "Most ez a szervezet komoly kockázatot jelentett a szervezetére nézve."

Biztonságos tervezés az IoT-korszakban

John Gallagher, a Viakoo Viakoo Labs alelnöke szerint az egyik kulcsfontosságú kihívás a biztonság tervezése olyan hosszú élettartamú eszközökben, mint a tárgyak internete (IoT) részei, amelyeknél a biztonság kezdetben nem volt tervezési szempont.

"Ez kiterjedtebb tesztelést igényel, és új mérnöki erőforrásokat igényelhet" - mondja. „Hasonlóan az új biztonsági funkciók beépítése új biztonsági rések bevezetésének módja.”

Gallagher szerint a szoftvergyártóknak el kellene fogadniuk a szoftverjegyzékek (SBOM) használatát, hogy gyorsabban megtalálják és orvosolják a sebezhetőséget. Megjegyzi, hogy a vállalatok a biztonságos tervezési gyakorlatot építik be új termékekbe, ami végső soron versenytényező lesz a piacon.

„Az MFA-n és a korlátozott hozzáférési jogosultságokon kívül olyan egyéb intézkedéseket is terveznek a termékekben, mint például az alapértelmezett jelszavak megszüntetése, valamint a firmware egyszerűbb és gyorsabb frissítését biztosító mechanizmusok kialakítása” – mondja.

A „biztonság a homályon keresztül” elkerülése a biztonság egy másik alapelve, mutat rá Gallagher. Az SBOM-ok és a nyílt forráskódú szoftverek például biztonságot nyújtanak azáltal, hogy átláthatóságot biztosítanak a szoftverkód körül.

Pace azt mondja, hogy az egyik olyan terület, amely a legjobban izgatja az alapértelmezés szerint és a tervezett biztonsággal kapcsolatban, az a lényegesen jobb láthatóság a szoftverellátási láncban. „Miután ez a láthatóság elérhető, elkezdhetjük igazán megérteni, hol vannak a problémáink az alapoktól kezdve, majd elkezdhetjük azokat úgy rangsorolni, hogy az értelmes legyen” – mondja.

• SEO által támogatott tartalom és PR terjesztés. Erősödjön még ma.
• PlatoData.Network Vertical Generative Ai. Erősítse meg magát. Hozzáférés itt.
• PlatoAiStream. Web3 Intelligence. Felerősített tudás. Hozzáférés itt.
• PlatoESG. Carbon, CleanTech, Energia, Környezet, Nap, Hulladékgazdálkodás. Hozzáférés itt.
• PlatoHealth. Biotechnológiai és klinikai vizsgálatok intelligencia. Hozzáférés itt.
• Forrás: https://www.darkreading.com/application-security/lock-down-the-software-supply-chain-with-secure-by-design