Opatrenia pre SSDLC (zabezpečený životný cyklus vývoja softvéru)

measures ssdlc

Dozviete sa viac o rôznych bezpečnostných opatreniach, ktoré treba implementovať pre zabezpečené SDLC alebo SSDLC:

Pretože technológia rýchlo rastie, zodpovedajúcim spôsobom sa zvýšili aj bezpečnostné hrozby hackerstva a krádeže zabezpečených údajov. Niet pochýb o tom, že technologický rast kladie výzvy na výrobcov softvéru, aby zabezpečili, že ich softvér je silný a odolný proti bezpečnostným hrozbám a zraniteľnostiam.

Softvérový produkt nie je možné vydať, aj keď funguje dokonale pre zamýšľanú funkčnosť, pokiaľ sa nepreukáže ako vysoko zabezpečený a nespĺňa stanovené a regulované štandardy bezpečnosti a ochrany súkromia, najmä v sektoroch obrany, financií a zdravotníctva, ktoré zahŕňajú osobné a finančné údaje .

Jeden si nemôže dovoliť mať bezpečnostnú chybu v produkte, keď je nasadený, či už vysokej alebo strednej závažnosti. Preto je veľmi dôležité chrániť softvér a údaje pred akýmkoľvek druhom útoku, škodlivými hrozbami, slabými miestami a zabezpečiť dôveryhodnosť softvéru pre koncového používateľa.

Proti nášmu tradičnému vývoju softvéru nie je testovanie v poslednej fáze po vývoji celého softvéru efektívnejšie. S implementáciou konceptov Agile, DevOps a ShiftLeft je nevyhnutné vykonať testovanie na začiatku aj v každej fáze životného cyklu aplikácie.

Z uvedeného vyplýva, že bezpečnosť softvéru nemožno vytvoriť alebo dokonca otestovať v poslednej fáze, a preto je potrebné ho budovať v každej fáze, aby sa zaistila úplná bezpečnosť softvéru.

Čo sa dozviete:

• Bezpečnostné opatrenia pre SSDLC
  • # 1) Fáza požiadaviek
  • # 2) Fáza plánovania
  • # 3) Fáza architektúry a dizajnu
  • # 4) Fáza vývoja
  • # 5) Fáza implementácie
  • # 6) Testovanie - fáza pred nasadením
• Tabuľkové zhrnutie pre SSDLC
• Záver
  • Odporúčané čítanie

Bezpečnostné opatrenia pre SSDLC

Nižšie sú uvedené rôzne prostriedky bezpečnostných opatrení, ktoré je možné implementovať počas celého životného cyklu vývoja softvéru, aby sa zabezpečilo zabezpečenie SDLC alebo SSDLC a aby sa chyby v čo najväčšej možnej miere neprevádzali do ďalšej fázy.

Existujú rôzne bezpečnostné analýzy a hodnotenia, na ktorých je potrebné stavať na bezpečnosti vo fázach SDLC.

1. Fáza požiadaviek
2. Fáza plánovania
3. Fáza architektúry a dizajnu: Posúdenie bezpečnostných rizík podľa návrhu.
4. Fáza vývoja: Secure Code Analysis, statická analýza bezpečnostného kódu.
5. Fáza implementácie: Dynamická analýza kódu, testovanie bezpečnosti aplikácií.
6. Testovanie - fáza pred nasadením: Testovanie prieniku a analýza zraniteľnosti.

# 1) Fáza požiadaviek

• Primárne, aby sa zabezpečilo, že softvér obsahuje zabudované potrebné bezpečnostné opatrenia, Osobitné požiadavky týkajúce sa bezpečnosti je potrebné jasne zachytiť počas fázy požiadaviek s dostatočnými podrobnosťami a očakávanými výsledkami.
• Pri identifikácii typických prípadov použitia a obchodných scenárov existuje jasná sada Prípady a scenáre týkajúce sa bezpečnosti na účely overenia je potrebné identifikovať, aby sa mohli zachytiť bezpečnostné prvky a navrhnúť scenáre bezpečnostného testovania.

Ďalej uvádzame niekoľko príkladov príkladov, ktoré ilustrujú výslovné požiadavky týkajúce sa bezpečnosti, ktoré je možné zachytiť.

Sec-Req-01: Systém musí mať zavedené autentifikačné opatrenia na všetkých bránach a vstupných bodoch.

Sec-Req-02: Systém je povinný implementovať autentifikáciu prostredníctvom zabezpečenej prihlasovacej obrazovky.

Sec-Req-03: OSOBNÉ ÚDAJE musia byť v pokoji šifrované.

# 2) Fáza plánovania

Na vysokej úrovni, nielen však na týchto, je potrebné sa vo fáze plánovania postarať o nasledujúce body.

DVD Ripper pre Windows 10 na stiahnutie zadarmo

• Silný, Špecializovaný tím zabezpečenia , fungujúci mimo PMO (kancelária pre riadenie projektu) programového tímu, ktorý pozostáva z: Pracovník v oblasti bezpečnosti, architekti v oblasti bezpečnosti, testéri bezpečnosti ktoré sa majú sformovať s cieľom vykonávať a riadiť všetky bezpečnostné činnosti programu nestranným spôsobom. Pre každú z týchto rolí sú definované jasné RnR (úlohy a zodpovednosti) a RACI.
• akýkoľvek eskalácie, nejasnosti súvisiace s bezpečnostnými otázkami musí vybavovať úradník pre bezpečnosť produktov (PSO), aby bezpečnostný tím fungoval hladko a pomáhal pri prijímaní správnych rozhodnutí.
• Robustný Stratégia testovania bezpečnosti upresnenie, ako implementovať požiadavky týkajúce sa bezpečnosti, ako, kedy, čo a čo treba otestovať, aké nástroje by sa mali v každej fáze použiť.
• Je povinné zahrnúť Bezpečnostné kontaktné miesto pre všetky technické / kontrolné diskusie týkajúce sa programu, aby bol bezpečnostný tím informovaný o akýchkoľvek zmenách v programe.

# 3) Fáza architektúry a dizajnu

Venovanie väčšej pozornosti bezpečnostným aspektom už počas fázy návrhu pomôže predchádzať bezpečnostným rizikám a zníži značné úsilie pri zmenách návrhu neskôr v SDLC.

Pri navrhovaní softvéru a infraštruktúry, na ktorej bude softvér hostený, je všetko možné Implementácie bezpečnostných návrhov musia byť dobre navrhnuté so zapojením bezpečnostných architektov.

Akékoľvek nejasnosti a konflikty medzi funkčnými a nefunkčnými aspektmi Dizajnu a architektúry je potrebné vyriešiť prostredníctvom brainstormingových stretnutí, do ktorých sú zapojené správne zainteresované strany.

Počas tejto fázy sa podrobne hodnotí bezpečnostné riziko produktu, ktoré sa tiež niekedy nazýva „Statické hodnotenie“ musí byť vykonaný bezpečnostným tímom odborníkov.

Posúdenie bezpečnostných rizík obsahuje preskúmanie programov z hľadiska bezpečnosti v predbežnej fáze návrhu / architektúry s cieľom identifikovať chyby súvisiace so zabezpečením z hľadiska dizajnu a zodpovedajúcim spôsobom zvýšiť produkt Bezpečnostné riziká projektovému tímu, aby ich oslovil a zabránil vstupu do ďalšej fázy.

Tieto hodnotenia sa vykonávajú na základe organizačných / priemyselných bezpečnostných smerníc, štandardov a kontrol uvedených v týchto dokumentoch. Napr. UXW 00320, UXW 030017

Počas hodnotenia bezpečnostných rizík produktu:

• Požiadavky, funkcie, užívateľské príbehy a ich dizajnérske dokumenty sa kontrolujú na základe podrobností, artefaktov zdieľaných tímom projektu, Napr. Dokumenty o dizajne (HLDD a LLDD). Súčasťou posúdení sú aj diskusie s príslušnými členmi projektového tímu v prípade, že chýbajú dokumenty, alebo s cieľom objasniť, či existujú pochybnosti.
• Medzery sa identifikujú pri mapovaní bezpečnostných požiadaviek programu proti stanoveným štandardom a iným osvedčeným postupom. Niekedy sa na základe zistených medzier vyvíjajú aj modely hrozieb.
• Tieto medzery sú identifikované ako potenciálne bezpečnostné riziká. Zahŕňajú aj navrhovanie možných zmiernení implementácie, sú zvyšované a riadené.
• Keď projektový tím implementuje tieto zmiernenia, overuje sa ich uzavretie prostredníctvom vhodných testovacích prípadov navrhnutých tímom pre testovanie systému.
• Matica riadenia rizík, ktorá poskytuje sledovateľnosť, je pripravená na sledovanie týchto rizík. Schválenie a odhlásenie so zvyškovým rizikom bude prijaté architektom bezpečnosti a úradom pre ochranu údajov.

Typické vzory hrozieb, ktoré sa identifikujú vo fáze návrhu, súvisia s overovaním vstupu, správou auditu / protokolu, konfiguráciami a šifrovaním. Identifikácia rizík zahŕňa útoky na slabé miesta ako slabé heslá, jednoduché útoky hrubou silou atď.,

Typické kontroly zahŕňajú riziká spojené s prístupom k osobným údajom, prístupom k záznamom o transakciách, entitami zaradenými na čiernu listinu, ktoré sú na bielu listinu, čistením údajov a aktivitou odstraňovania.

Príklady testovacích scenárov:

• Zraniteľnosť pretečenia medzipamäte: Aby sa zabezpečilo, že manuálnym fuzzovaním parametrov by nemalo byť možné spomaliť server a prinútiť ho, aby nereagoval (Denial of Service).
• Sanitizácia údajov: Zaistiť, aby pre každý vstup a výstup prebehla správna dezinfekcia údajov, aby útočník nemohol injektovať a uložiť škodlivý obsah v systéme.

# 4) Fáza vývoja

Analýza bezpečného kódu je a Hodnotenie statického kódu metóda, ktorá sa používa na hodnotenie Zabezpečený kód rôznych funkcií softvéru pomocou automatizovaného skenovacieho nástroja. Príklad: Opevniť.

Táto analýza sa vykonáva pri každom odhlásení / zostavení kódu, aby sa skenoval kód vygenerovaný kvôli bezpečnostným hrozbám. Toto hodnotenie sa zvyčajne vykonáva na úrovni User Story.

• Na strojoch vývojára je potrebné nainštalovať vylepšené skenovanie pomocou doplnkov.
• Fortify je potrebné integrovať do šablóny zostavenia.
• Na všetkých zostaveniach sa bude denne vykonávať automatické skenovanie.
• Výsledok skenovania bude bezpečnostným tímom analyzovaný na prítomnosť falošných poplachov.
• Poruchy identifikované v tomto hodnotení sa zvyšujú a odstraňujú po uzávierku, takže priesak je minimalizovaný / vynulovaný na ďalšiu úroveň.

Príklady testovacích scenárov:

• Aby sa zabezpečilo, že sa citlivé dáta nebudú počas prenosu dát odosielať ako text.
• Na zabezpečenie bezpečného prenosu údajov musia byť na kanáli HTTPS nasadené externé rozhrania API.

# 5) Fáza implementácie

Dynamická analýza kódu nie je nič iné ako Testovanie bezpečnosti aplikácií, ktoré sa nazýva aj OWASP (Open Web Application Security Project). Vo fáze implementácie / testovania je potrebné vykonať analýzu zraniteľnosti a testovanie prieniku (VAPT).

Táto analýza hodnotí binárne súbory a niektoré konfigurácie prostredia a ďalej posilňuje kód bezpečnostných požiadaviek.

V rámci tejto analýzy je Dynamické správanie alebo funkčnosť rôznych funkcií programov sa analyzujú na chyby zabezpečenia. Na uskutočnenie dynamickej analýzy kódu sa používajú aj stanovené prípady použitia a obchodné scenáre.

Táto činnosť sa vykonáva na Testovacie zostavy pomocou rôznych bezpečnostných nástrojov s automatizovaným a manuálnym prístupom.

• Nástroje HP WebInspect, Burp Suite, ZAP a SOAP UI sa všeobecne používajú na kontrolu chýb oproti štandardným databázam zraniteľností ( Príklad: OWASP Top 10 )
• Táto činnosť je však hlavne automatizovaná, kvôli obmedzeniam niektorých nástrojov môže byť pri triedení falošných pozitívov potrebná určitá manuálna práca.
• Toto je ideálne vykonať v samostatnom prostredí (System Testing Environment), kde je nasadený softvér pripravený na testovanie.
• Zraniteľnosti je potrebné zvýšiť a uzavrieť pomocou navrhovaných zmierňovacích opatrení.

Typické vzory hrozieb identifikované počas tejto analýzy súvisia s overovaním vstupu, nefunkčnou autentifikáciou a správou relácie, vystavením citlivých údajov, XSS a správou hesiel.

Príklady testovacích scenárov sú:

• Správa hesiel: Zabezpečiť, aby sa heslá neukladali v obyčajnom texte v konfiguračných súboroch alebo kdekoľvek v systéme.
• Únik informácií o systéme: Aby sa zabezpečilo, že v žiadnom okamihu nedôjde k úniku systémových informácií, mohli by informácie odhalené programom printStackTrace pomôcť protivníkovi z plánu útoku.

# 6) Testovanie - fáza pred nasadením

Testovanie prieniku Skúška perom v skratke a Infra VAPT (analýza zraniteľnosti a testovanie penetrácie) , je plnohodnotný celostný test s úplné riešenie a konfigurácie (vrátane siete), ktoré sa ideálne vykonáva v predprodukčnom alebo produkčnom prostredí.

Toto sa vykonáva hlavne na identifikáciu chýb zabezpečenia DB a servera a všetkých ďalších chýb zabezpečenia. Toto je posledná etapa testovania bezpečnosti, ktorá by sa mala vykonať. Preto sem patrí aj overenie skôr nahlásených chýb a rizík.

Páni, na akom serveri hrať

• Na vykonávanie testovania pomocou pera sa používajú nástroje ako Nessus, Nmap, HP Web Inspect, Burp Suite, ZAP, ktoré sú dostupné na trhu.
• Počas tohto testovania sa vykonáva skenovanie webových aplikácií pomocou automatizovaných nástrojov a využitie na ďalšie overenie. Testovanie sa vykonáva s cieľom simulovať správanie skutočného útočníka, a preto môže zahŕňať aj niekoľko negatívnych testov.
• Zraniteľnosť infraštruktúry Posúdenie zahŕňa skenovanie, analýzu a kontrolu konfigurácie zabezpečenia infraštruktúry (sietí, systémov a serverov) s cieľom identifikovať zraniteľné miesta a skontrolovať odolnosť proti cieleným útokom.
• To sa vykonáva v predprodukčnom alebo produkčnom prostredí, kde sa testuje softvér, ktorý je pripravený na nasadenie, a teda simuluje prostredie v reálnom čase.
• Zraniteľnosti sa zisťujú pomocou skenerov aj manuálnych postupov na elimináciu falošných poplachov. Počas manuálneho testovania sa tiež uskutočnia obchodné scenáre v reálnom čase.
• Bude vypracovaná záverečná správa o celej bezpečnostnej analýze, ktorá sa vykonáva pre celý program, s vyznačením stavu vysoko rizikových položiek, ak existujú.

Príklady testovacích scenárov sú:

• Zabezpečiť, aby neboli povolené citlivé metódy HTTP.
• Aby sa zabezpečilo, že citlivé informácie ostatných používateľov nebudú v sieti viditeľné ako čistý text.
• Aby ste sa ubezpečili, že je implementovaná validácia pre nahrávanie súborov, zabráňte nahraniu škodlivého súboru.

Tabuľkové zhrnutie pre SSDLC

V nasledujúcej tabuľke sú zhrnuté rôzne aspekty bezpečnostnej analýzy, ktoré sú vysvetlené vyššie.

Záver

Implementácia všetkých týchto aspektov týkajúcich sa bezpečnosti integrovaných do rôznych fáz SDLC teda pomáha organizácii identifikovať chyby zabezpečenia na začiatku cyklu a umožňuje organizácii implementovať príslušné zmiernenia, čím sa vyhne Vysokorizikové bezpečnostné chyby v živom systéme.

Štúdia tiež ukazuje, že väčšina bezpečnostných chýb je do softvéru indukovaná počas vývojovej fázy, tj. Počas Fáza kódovania , pričom kódovanie sa z akýchkoľvek dôvodov nedostatočne postaralo o všetky bezpečnostné aspekty.

V ideálnom prípade by žiadny vývojár nechcel napísať zlý kód, ktorý by ohrozil bezpečnosť. Nasledujúci návod preto ponúka vývojárom návod, ako napísať zabezpečený softvér Osvedčené postupy a pokyny pre kódovanie pre vývojárov, aby sa zaistila lepšia bezpečnosť softvéru.

Dúfame, že vám tento návod na Secure SDLC alebo SSDLC pomohol !!

Odporúčané čítanie

• Fázy, metodiky, proces a modely SDLC (životný cyklus vývoja softvéru)
• 10 najlepších nástrojov na testovanie bezpečnosti mobilných aplikácií v roku 2021
• 19 výkonných nástrojov na testovanie prieniku, ktoré profesionáli používali v roku 2021
• Pokyny na testovanie zabezpečenia mobilných aplikácií
• Testovanie zabezpečenia siete a najlepšie nástroje zabezpečenia siete
• Testovanie bezpečnosti (kompletný sprievodca)
• Najlepšie 4 nástroje na testovanie bezpečnosti s otvoreným zdrojom na testovanie webových aplikácií
• Sprievodca testovaním bezpečnosti webových aplikácií