Fejlesztési biztonsági szemlélet kialakítása

Ez a cikk segítséget nyújt a biztonsági és technológiai csapatoknak egy fejlesztési biztonsági szemlélet kialakításában és modernizálásában. Ez a szemlélet segíti a biztonsági, mérnöki és technológiai csapatokat annak biztosításában, hogy a szoftverek biztonságosan legyenek megtervezve, felépítve, integrálva és üzembe helyezve – az innováció lassítása nélkül.

A biztonsági szemléletek a kapcsolódó biztonsági munka olyan csoportjai, amelyek segítenek a szervezeteknek a teljes technológiai tulajdonban lévő biztonsági eredmények következetes megvalósításában. A biztonsági bevezetési modellen belül a szemléletek hidat biztosítanak az üzleti forgatókönyvek és a műszaki megvalósítás között, biztosítva, hogy a biztonsági befektetések a biztonsági bevezetési modell részeként valós mérhető eredményekké alakulnak.

Miért ez a szemlélet?

A szoftverek szorosan kapcsolódnak az identitásokhoz, az adatokhoz, az infrastruktúrához és az üzleti folyamatokhoz. Ha a fejlesztési biztonság gyenge vagy inkonzisztens, minden szoftverkiadás új biztonsági réseket vezethet be, amelyeket a támadók kihasználnak, hogy szélesebb körű szervezeti eszközökhöz férhessenek hozzá.

Hatékony fejlesztési biztonsági szemlélet nélkül a szervezetek gyakran tapasztalják:

• A fejlesztés során bevezetett szoftveres biztonsági rések nagyobb kockázattal járnak.
• Az alkalmazás kompromittálódása, amely lehetővé teszi az identitások és adatok közötti oldalirányú terjedést.
• Az üzleti műveletek és a bevétel megszakadása.
• Az ügyfél és a szabályozott adatok expozíciója vagy visszaélése.
• A műszaki adósság felhalmozása, amely növeli a hosszú távú kockázatot és a szervizelési költségeket.

Az erős fejlesztésbiztonsági fegyelem biztosítja, hogy minden egyes kiadás csökkentse a kockázatot, ahelyett hogy tovább növelné azt.

Küldetés és eredmények

A Fejlesztési biztonság szemlélet csökkenti a szervezeti kockázatokat azáltal, hogy biztosítja, hogy a belsőleg vagy a partnerek által fejlesztett összes szoftver a biztonsági szabványoknak megfelelően legyen megtervezve, felépítve, integrálva és üzembe helyezve anélkül, hogy lassítaná a teljesítést vagy az innovációt.

Azok a szervezetek, amelyek magas szintre fejlesztik ezt a területet, a következőket érik el:

• A biztonság a fejlesztési folyamatokba van beépítve, nem pedig későn kerül hozzáadásra.
• A tervezési és megvalósítási hibák korábbi azonosítása és elhárítása.
• Kiszámíthatóbb, biztonságosabb kiadási ciklusok.
• Csökkentett átdolgozás, vészhelyzeti javítások és működési zavarok.
• A technikai és biztonsági adósságok alacsonyabb halmozódása az idő függvényében.

A Development Security biztosítja, hogy a biztonsági helyzet folyamatosan javuljon az egyes kiadásoknál ahelyett, hogy rendszeres időközönként alaphelyzetbe állítanák őket.

Változások a csapatmunkában

Fontos, hogy a fejlesztési biztonsági szemlélet megfeleljen a fejlesztőknek és a termékcsapatoknak, ahol vannak, és a biztonság meglévő fejlesztési munkafolyamatokba való integrálására összpontosítva ahelyett, hogy késői szintű vezérlőket, súrlódást okozó felülvizsgálati folyamatokat vezetnének be, vagy akár kihagynák a fejlesztési folyamatok biztonságát.

Ezt a megközelítést gyakran balra tolódásnak nevezik, amely a biztonsági gondolkodást az ideáció, a tervezés és a megvalósítás korábbi szakaszában mutatja be, amikor a problémák könnyebben és kevésbé költségesen javíthatóak. A balra helyezés nem azt jelenti, hogy a folyamat során korábban kell nemet mondani. Ehelyett a termékkel kapcsolatos döntések javítása és a biztonsági és üzleti követelményeknek megfelelő megoldások biztosítása érdekében korai bevezetést vezet be a biztonsággal kapcsolatos információkról.

A fő alapelvek a következők:

• Korai integráció: Fontolja meg a biztonságot az ideáció és a tervezés során, nem csak a tesztelés során
• Fejlesztői összehangolás: Érd el a fejlesztői és termékcsapatokat ott, ahol már dolgoznak
• Kicsi, növekményes változás: Az automatizálás és az alacsony súrlódású fejlesztések előnyben részesítése
• Folyamatos fejlesztés: A biztonság kezelése folyamatos szemléletként, nem mérföldkőként

A konzisztens integráció idővel csökkenti a tűzfúrásokat, és nem lassítja, hanem felgyorsítja a teljesítést.

Hogyan alkalmazza ezt a módszert

A fejlesztési biztonság szemlélet hatékony alkalmazása érdekében a biztonságos alkalmazások és szolgáltatások szervezeten belüli létrehozásának és fenntartásának egységes megközelítésére kell összpontosítania:

1. Biztonságos fejlesztési stratégia meghatározása az üzleti kockázathoz igazítva
   Világos megközelítés kialakítása az alkalmazások és szolgáltatások tervezésének, kialakításának és karbantartásának módjához a kockázat csökkentése és a kritikus üzleti funkciók védelme érdekében.
2. Biztonság beágyazása fejlesztési és mérnöki folyamatokba
   Győződjön meg arról, hogy a biztonsági eljárások integrálva vannak a tervezési, tervezési, fejlesztési és üzembehelyezési tevékenységekbe, és ne alkalmazzák őket a tény után.
3. Szabványosított biztonságos fejlesztési eljárások létrehozása
   Adjon egyértelmű útmutatást annak biztosításához, hogy a biztonságos kódolási, tesztelési és kiadási eljárások egységesen érvényesüljenek a csapatok és projektek között.
4. A fejlesztési biztonság és a kritikus fontosságú eszközök és üzleti forgatókönyvek összehangolása
   Rangsorolja a nagy értékű eszközöket és kulcsfontosságú üzleti műveleteket támogató alkalmazások és szolgáltatások védelmét.
5. Folyamatos fejlesztés a kockázatok, a biztonsági rések és a visszajelzések alapján
   A biztonsági résekből, incidensekből és tesztelési eredményekből származó megállapításokkal erősítheti a fejlesztési gyakorlatokat, és csökkentheti a kockázatokat az idő múlásával.

Változások kezelése

A modern fejlesztési biztonságot jellemzően devSecOps-megközelítéssel valósítják meg, amely egyesíti az agilis teljesítést az alapvető szabályozási és minőségi gyakorlatokkal a kiadás előtt.

Ahelyett, hogy a sebesség és a biztonság közötti választást választaná, a DevSecOps a fejlesztési életciklus legfontosabb szempontjainak védelmére összpontosít a sürgős kockázatok csökkentése érdekében, miközben nem akadályozza a gyors kiadási ciklusokat:

A kialakítás védelme – Bevált biztonsági tervezési minták használata és a tervek érvényesítése fenyegetésmodellezéssel. A kód védelme – Kövesse a biztonságos kódolási eljárásokat, és ellenőrizze a szoftvereket és a függőségeket. A folyamat védelme – A folyamat folyamatának ellenőrzése és a CI/CD-rendszerek védelme a illetéktelen módosításokkal szemben. Győződjön meg arról, hogy a folyamat módosításai és a folyamaton áthaladó szoftverek nyomon követhetők. Biztonságos műveletek – Győződjön meg arról, hogy az üzembe helyezett számítási feladatok a konfigurációt, a javítást és az üzemeltetési ajánlott eljárásokat követik.

A Teams a fejlesztés, a biztonság és a műveletek közötti együttműködés folyamatos finomításával, a funkcionális teljesítési célok megbízhatósággal és kockázatcsökkentéssel való kiegyensúlyozásával javíthatja az eredményeket.

Ezt a folyamatos növekményes javulást mind a munkagyártásra (az életciklus során előállított szoftverkódra), mind a fejlesztési életciklus érlelésére alkalmazni kell.

DevSecOps-folyamat definiálása

A Fejlesztési biztonság általában egy Olyan DevSecOps-üzemeltetési modellen keresztül implementálható, amely idővel fejlődik, és nem teljesen formázottnak tűnik. A DevSecOps összehozza a fejlesztést, a biztonságot és a műveleteket, hogy folyamatos fejlesztéssel jobb eredményeket érjen el.

A legtöbb szervezet az alábbi szakaszokban halad előre:

Fejlesztés (Dev) – Az első éles kiadás egy minimálisan működőképes termék (MVP) megvalósítására összpontosít, amely megfelel az alapvető üzleti követelményeknek. DevOps – A kezdeti kiadás után a csapatok a folyamatos teljesítés révén a gyors iterációra, a működési stabilitásra és a szabályozásra összpontosítanak. DevSecOps – Ahogy az együttműködés kiforrott, a fejlesztés, a biztonság és a műveletek együtt dolgoznak a folyamatok folyamatos finomításán, valamint a sebesség, a kockázat és a megbízhatóság kiegyensúlyozásán.

Ez a folyamat lehetővé teszi a szervezetek számára a biztonsági eredmények javítását anélkül, hogy feláldozná az agilitást vagy az innovációt.

Biztonságos MVP-alapkonfiguráció létrehozása

Ebben a modellben a legfontosabb lépés az, hogy fejlesztési, biztonsági és üzemeltetési szempontból határozza meg, hogy mi minősül minimálisan életképes terméknek (MVP). A közös alapkonfiguráció létrehozása egyértelművé teszi a csapatokat, és lehetővé teszi a folyamatos javulást az idő múlásával.

Komponens	Részletek
Dev(elopment)	Győződjön meg arról, hogy a szoftver megfelel a minimális üzleti és funkcionális követelményeknek.
Sec(urity)	Győződjön meg arról, hogy a szoftver megfelel a minimális biztonsági és megfelelőségi követelményeknek.
Op(eration)s	Győződjön meg arról, hogy a szoftver megfelel a minimális minőségi, megbízhatósági és működési felkészültségi követelményeknek.

Az MVP követelményei szervezetenként és iparágonként eltérőek, és a kockázati étvágy, a szabályozási kitettség és az üzleti kritikusság befolyásolják. Ezek a követelmények gyakran a szervezet, a fenyegetési környezet és a kézbesítési modellek változásával változnak.

Folyamatos szoftverfejlesztés

A kezdeti éles kiadás után a számítási feladatok folyamatos fejlesztési ciklusokba kerülnek. Ebben a fázisban a fejlesztés, a biztonság és a műveletek finomítják a szoftvert és a kézbesítési folyamatot is. A biztonsági erőfeszítések a következőkre összpontosítanak:

• A biztonság natív integrálása a fejlesztési munkafolyamatokba ugyanazokkal az eszközökkel és rangsorolási modellekkel, mint a többi mérnöki munka
• A standard kiadási ciklusok részeként gyorsan azonosíthatja, rangsorolhatja és kijavíthatja a biztonsági hibákat.

Ez a megközelítés összhangban áll Microsoft Biztonságos jövő kezdeményezés (SFI) tanulásával, például a prPaved Paths, ahol a biztonságos eljárások a platformokba és folyamatokba épülnek, és nem külsőleg kényszeríthetők ki.

Ez a folyamatos tanulás idővel segít a csapatoknak a követelmények finomításában, az együttműködés hatékonyabbá tételében és a szállítási sebesség, a biztonság és a megbízhatóság jobb egyensúlyában.

Szakterületi szerepkörök és közreműködők

A Dev Security szemléletet általában alkalmazás- és termékfejlesztést végző csapatok futtatják.

Ebben a szemléletben az elsődleges szerepkörök általában a következők:

• Technológiai szállítási és termékmenedzserek
• Szoftverfejlesztők (beleértve az AI-fejlesztést is)
• Szoftverbiztonsági mérnökök
• DevOps- és platformmérnökök
• Tesztelési és minőségi mérnöki szerepkörök
• Ellátási lánc és függőségek biztonsági szerepkörei

A fő közreműködők a következők:

• Üzleti és műszaki vezetés – Szponzorálás és rangsorolás biztosítása
• Architektúraszerepkörök – Útmutató a biztonságos tervezési és integrációs döntésekhez
• Biztonsági stratégia, integráció és irányítás szemléleti szerepkörök – A politika, az oktatás és a felügyelet biztosítása
• Infrastruktúra- és platformcsapatok – Biztonságos fejlesztési környezetek engedélyezése
• Biztonsági műveletek (SecOps) – Alkalmazások támadásának monitorozása és megválaszolása

Összhang más szakterületekkel

A Development Security szorosan integrálva van más SAF-szemléletekkel:

• Hozzáférés és identitások – Védi a fejlesztői, a számítási feladatokat és a szolgáltatásidentitásokat.
• Infrastruktúra-biztonság – Az alkalmazásokat és folyamatokat futtató platformokat védi.
• Adatbiztonság – Biztosítja a bizalmas adatok védelmét a szoftver teljes életciklusa során.
• SecOps – Észleli és reagál az alkalmazásszintű támadásokra.
• Biztonsági stratégia, integráció és irányítás – A fejlesztési gyakorlatokat a vállalati kockázati prioritásokhoz igazítja.

Ezek a szemléletek együttesen biztosítják, hogy a szoftverbiztonság szélesebb körű üzleti és biztonsági eredményeket biztosítson.

Igazodás a technológiai pillérekhez

A fejlesztési biztonsági szemlélet stratégiájának végrehajtásához több technológiai alappillér biztonsági ellenőrzése szükséges.

A technológiai pillérekhez való igazodás a következőket foglalja magában:

• Identitások: Védi a fejlesztői és számítási feladatok identitásait és hitelesítő adatait.
• Végpontok: Védi a fejlesztői munkaállomásokat és a buildelési rendszereket.
• Infrastruktúra: Védi a kódot, folyamatokat és számítási feladatokat üzemeltető platformokat.
• Alkalmazások: Elsődleges hangsúlyt fektet a fejlesztési biztonsági eljárásokra.
• Adatok: Védi az alkalmazások által használt, létrehozott és tárolt adatokat.
• Hálózat: Szoftvereket tervez, hogy biztonságosan működjenek a nem megbízható hálózatokon.
• AI: A modern alkalmazásokban használt AI-összetevők és modellek védelme.

Ez az átfogó jelleg biztosítja, hogy a szakterület a valós támadási útvonalakkal foglalkozzon.

Mi a következő lépés?

A fejlesztési biztonsági stratégia további útmutatást nyújt a fejlesztési biztonsági stratégiában.

Vegyen részt egy műhelyfoglalkozáson

Microsoft Unified szakértő által vezetett workshopokat kínál, amelyek segítenek a szervezeteknek modernizálni a dev biztonsági szemléletüket. Ezek a műhelyek a következők:

• Architektúra- és stratégiai workshopok – A biztonsági bevezetési keretrendszer (SAF) – Architektúratervezési szekció: Infrastruktúra és fejlesztési biztonsági workshop a fejlesztési biztonság modernizálásának felgyorsítására és az infrastruktúra biztonságával való integrációra összpontosít. Ez a workshop kevesebb mint négy órás vitafórumként érhető el, amely a legfontosabb tanulásokra és ajánlott eljárásokra összpontosít.
• Technológiai bevezetési műhelyek: Microsoft Az Unified workshopokkal segíti a szervezeteket a Microsoft Fejlesztési biztonsági technológia használatának megismerésében, tervezésében, megvalósításában és optimalizálásában, ahogyan az ebben a diagramban látható.

Tekintse át a Microsoft Biztonságfejlesztési életciklus

A Microsoft folyamatos biztonsági fejlesztési életciklusa módszertant biztosít a szoftverek biztonságos fejlesztéséhez. A Security Development Lifecycle (SDL) az a megközelítés, Microsoft a biztonságot a DevOps-folyamatokba (más néven DevSecOps-megközelítésbe) integrálja. Az SAF fejlesztési biztonsági útmutatója segít az SDL megközelítésének és gyakorlatának a szervezethez való igazításában.

Az SDL-megközelítésben leírt eljárásokat a szoftverfejlesztés minden típusára és minden platformra alkalmazhatja, a klasszikus vízeséstől a modern DevOps-megközelítésekig. Ez az általánosan alkalmazható szoftverbiztonsági megközelítés bármilyen típusú szoftveren és platformon működik.

További információ: Microsoft Biztonságfejlesztési életciklus (SDL).

A hatékony fejlesztési biztonsághoz olyan biztonsági fejlesztési életciklus (SDL) szükséges, mint a Microsoft Biztonságfejlesztési életciklus (SDL)

Következő lépések

Megismerheti a DevOpsról a DevSecOpsra való váltást.