Éveken át a penetrációs tesztelés volt a szervezet kiberbiztonsági helyzetének ellenőrzésére szolgáló legfontosabb módszer. De a fejlesztési ciklusok villámsebességgel haladnak, a fenyegetések pedig óránként fejlődnek. Az egyszeri tesztelés még mindig célravezető?
Nagyon gyakran ez azt jelenti, hogy a biztonsági csapatok a tegnapi sebezhetőségekre reagálnak ahelyett, hogy megelőznék a holnap fenyegetéseit.
A penetrációs tesztelés öröksége és korlátai
A hagyományos penetrációs tesztelés abban a korban született, amikor a szoftverfrissítések ritkák voltak és a kiadási ciklusok hónapokig tartottak. Ma, a folyamatos szállítási csatornákkal és a felhőalapú alkalmazásokkal, sokan kérdőjelezik meg, hogy ez a modell megfelel-e a mai valóságnak.
A penetrációs tesztek általában évente egyszer zajlanak, gyakran megfelelőségi jelölőnégyzetként vagy incidens utáni gyakorlatként. Ezek az egyszeri értékelések egy adott pillanatban azonosítják a sebezhetőségeket, de nem vehetik figyelembe, mi történik az azt követő hetekben és hónapokban. Így hosszú kitettségi ablakokhoz vezethetnek a tesztek között. Új sebezhetőségek már másnap megjelenhetnek, és a támadók nem várnak a következő ciklusig.
Még rosszabb, hogy a fejlesztési ciklus végén végzett tesztelés lelassíthatja a kiadásokat, vagy feszültséget teremthet a biztonsági és fejlesztési csapatok között. Az utóbbiak, a gyors funkciókiszállítás nyomása alatt, gyakran fékezőként tekintenek a biztonságra. Ha a penetrációs tesztelés akadállyá válik útmutató helyett, kockáztatja, hogy kisiklatja azt az innovációt, amelyet meg kíván védeni.
A csendes időszakok nem annyira csendesek
A tesztek között sok minden megváltozhat: a kód fejlődik, a konfigurációk eltolódnak, és új alkalmazásprogramozási interfészeket (API-kat) adnak hozzá, vagyis minden változtatás potenciális gyengepontokat vezet be, amelyek ellenőrizetlenek maradnak a következő tervezett tesztig.
E gyengepontok kezelésére elvégezhet egy gyors, felőleti szintű vizsgálatot, amely hamis biztonsági érzetet kelthet, vagy egy mély, manuális tesztet, amely lelassítja az üzleti tempót. Egyik sem ideális.
Ez az úgynevezett „csendes időszak” az, ahol a legnagyobb kockázatok rejtőznek. Sok valós jogSértés azért következik be, mert a szervezetek nem tesztelnek folyamatosan, így megkönnyítik a támadók számára ezen rések kihasználását — néha az új sebezhetőség bevezetését követő órákon belül.
Folyamatos érvényesítés: biztonság, amely követi Önt
Az előrelátó biztonsági vezetők megszakítják ezt a reatív ciklust azzal, hogy a folyamatos érvényesítést beágyazzák DevSecOps folyamataikba. A biztonsági tesztelés már nem egyszeri eseményként tekinthető; inkább egy folyamatos diszciplína, amely az üzlettel együtt fejlődik.
Az NTT DATA egy globális kiskereskedelmi vállalkozással dolgozik együtt, amely negyedevénként végez inkrementális teszteket, az új kiadásokhoz igazítva, miközben fenntartja az üzletspecifikus biztonsági követelmények alapvonalát. Minden teszt az előzőre épül, nem az elejéről kezdi el. A kiskereskedő külső „támadási felület érvényesítéseket” is végez, amelyek külső hírszerzési adatfolyamokat használnak a valós támadói viselkedés tükrözésére. Ez relevánsnak és adaptívnak tartja a tesztelést.
Más NTT DATA ügyfelek az automatizált vizsgálatot és a fenyegetésfelderitést közvetlenül a folyamatos integrációs és szállítási (CI/CD) csatornáikba integrálják. A manuális jóváhagyások helyett ezek a tesztek csendben futnak a háttérben, korán felszínre hozzák a problémákat, és valós időben oktatják a fejlesztőket.
Az automatizálás sokkal egészségesebbe tette a biztonság és a fejlesztők közötti kapcsolatot. Ha a tesztelés a csatornában zajlik, nem zavaró. A biztonság elősegítővé válik, nem akadállyá.
A folyamatos biztonság szemléletének kialakítása
A folyamatos érvényesítés szemléletről is szól. A biztonsági csapatok fokozatosan kapuőrökből együttműködőkké válnak, és a fejlesztőknek is a minőség szerves részének kell tekinteniük a biztonságot, nem csak egy kip ipálandó jelölőnégyzetnek.
Ez a kult urális váltás gyakran kis lépésekkel kezdődik: szkennelő eszközök beágyazása a csatornába, gyakoribb tesztek ütemezése vagy a tesztelési naptárak összehangolása az ismert kiadási ciklusokkal. A cél nem az, hogy mindent mindig tesztteljünk, hanem az, hogy kialakítsunk egy ritmust, ahol a tesztelés és a fejlesztés együtt fejlődik.
Idővel az előnyök nyilvánvalóvá válnak:
- Kevesebb meglepés: a sebezhetőségeket korábban fedezik fel, csökkentve az újramunkát és a késedelmeket.
- Nagyobb rugalmasság: a folyamatos betekintések segítik a szervezeteket abban, hogy alkalmaz kod janak a változó fenyegetési környezethez.
- Gyorsabb inováció: a biztonság a folyamat részévé válik, nem annak akadályozójává.
Egy élő, lélegző megközelítés a biztonság biztosítására
Végső soron az offenzív biztonság jövője a penetrációs tesztelés fejlesztéséről szól, nem annak felváltásáról. A folyamatos érvényesítés alkalmazásával a szervezetek a tesztelést reatív tevékenységből proaktív képességgé alakítják.
Végül is abba kell hagyn unk, hogy a tesztelést eseményként kezteljük, és el kell kezdenünk ökoszisztémaként kezelni — olyanként, amely soha nem alszik.
MI A KÖVETKEZŐ LÉPÉS
Olvasson többet az NTT DATA Offensive Security-as-a-Service megoldásairl.