Opatření pro SSDLC (zabezpečený životní cyklus vývoje softwaru)

measures ssdlc

Zjistěte více o různých bezpečnostních opatřeních k implementaci pro zabezpečené SDLC nebo SSDLC:

Jak technologie rychle roste, odpovídajícím způsobem se zvýšily i bezpečnostní hrozby hackerství a krádeže zabezpečených dat. Není tedy pochyb o tom, že technologický růst staví výrobce softwaru před výzvy, aby zajistili, že jejich software bude silný a odolný proti bezpečnostním hrozbám a zranitelnostem.

Softwarový produkt nelze vydat, i když funguje dokonale pro zamýšlenou funkčnost, pokud se neprokáže jako vysoce zabezpečený a nesplňuje stanovené a regulované standardy zabezpečení a ochrany osobních údajů, zejména v odvětvích obrany, financí a zdravotnictví, které zahrnují osobní a finanční údaje .

Jeden si nemůže dovolit mít bezpečnostní vadu v produktu, když je nasazen, ať už je to vysoká nebo střední závažnost. Proto je velmi důležité chránit software a data před jakýmkoli druhem útoku, škodlivými hrozbami, zranitelnostmi a zajistit důvěryhodnost softwaru pro koncového uživatele.

Oproti našemu tradičnímu vývoji softwaru není testování v poslední fázi po vývoji celého softwaru účinnější. S implementací konceptů Agile, DevOps a ShiftLeft je nezbytné provádět testování v rané fázi i v každé fázi životního cyklu aplikace.

Bez ohledu na to nelze v poslední fázi vybudovat nebo dokonce otestovat zabezpečení softwaru, a proto je třeba jej budovat v každé fázi, aby byla zajištěna celková bezpečnost softwaru.

Co se naučíte:

• Bezpečnostní opatření pro SSDLC
  • # 1) Fáze požadavků
  • # 2) Fáze plánování
  • # 3) Fáze architektury a designu
  • # 4) Fáze vývoje
  • # 5) Fáze implementace
  • # 6) Testování - fáze před nasazením
• Tabulkové shrnutí pro SSDLC
• Závěr
  • Doporučené čtení

Bezpečnostní opatření pro SSDLC

Níže jsou uvedeny různé prostředky opatření souvisejících se zabezpečením, které lze implementovat v celém životním cyklu vývoje softwaru, aby bylo zajištěno zabezpečení SDLC nebo SSDLC a v maximální možné míře se závady nesmí přenášet do další fáze.

Různé bezpečnostní analýzy a hodnocení, na nichž je třeba stavět zabezpečení ve fázích SDLC, jsou.

1. Fáze požadavků
2. Fáze plánování
3. Fáze architektury a designu: Posouzení bezpečnostních rizik na základě návrhu.
4. Fáze vývoje: Secure Code Analysis, statická analýza kódu pro zabezpečení.
5. Fáze implementace: Dynamická analýza kódu, testování zabezpečení aplikace.
6. Testování - fáze před nasazením: Penetrační testování a analýza zranitelnosti.

# 1) Fáze požadavků

• Primárně, aby se zajistilo, že software obsahuje nezbytná bezpečnostní opatření, Specifické požadavky týkající se bezpečnosti je třeba jasně zachytit během fáze požadavků s dostatečnými podrobnostmi a očekávanými výsledky.
• Při identifikaci typických případů použití a obchodních scénářů je jasná sada Případy a scénáře použití související se zabezpečením pro účely ověření je třeba identifikovat, aby bylo možné zachytit funkce zabezpečení a navrhnout scénáře testování zabezpečení.

Níže uvádíme několik ukázkových příkladů, které ilustrují explicitní požadavky týkající se zabezpečení, které lze zachytit.

Sec-Req-01: Systém musí mít zavedena opatření ověřování na všech branách a vstupních bodech.

Sec-Req-02: Systém je povinen implementovat ověřování prostřednictvím zabezpečené přihlašovací obrazovky.

Sec-Req-03: OSOBNÍ ÚDAJE musí být v klidu šifrovány.

# 2) Fáze plánování

Na vysoké úrovni, ale nejen na těchto, je třeba se ve fázi plánování postarat o následující body.

nejlepší čistič PC pro Windows 7

• Silný, Specializovaný tým zabezpečení , fungující mimo PMO (kancelář pro řízení projektů) programového týmu, skládající se z Bezpečnostní pracovník, bezpečnostní architekti, bezpečnostní testeři mají být vytvořeny tak, aby prováděly a řídily všechny bezpečnostní činnosti programu nestranně. Pro každou z těchto rolí jsou definovány jasné RnR (role a odpovědnosti) a RACI.
• Žádný eskalace, nejasnosti související s bezpečnostními problémy musí být řešen PSO (Product Security Officer), aby bezpečnostní tým fungoval hladce a pomáhal při správném rozhodování.
• Robustní Strategie testování bezpečnosti upřesnění toho, jak implementovat požadavky související s bezpečností, jak, kdy a co otestovat, jaké nástroje by se měly v každé fázi použít.
• Je povinné zahrnout Bezpečnostní kontaktní místo pro všechny technické / revizní diskuse týkající se programu, aby si tým zabezpečení byl vědom všech změn, ke kterým v programu došlo.

# 3) Fáze architektury a designu

Věnování větší pozornosti bezpečnostním aspektům v rané fázi návrhové fáze pomůže předcházet bezpečnostním rizikům a sníží značné úsilí ve změnách návrhu později v SDLC.

Při navrhování softwaru a infrastruktury, na které bude software hostován, vše možné Bezpečnostní návrhové implementace musí být dobře navrženy se zapojením bezpečnostních architektů.

Veškeré nejasnosti a konflikty mezi funkčními a nefunkčními aspekty designu a architektury je třeba vyřešit prostřednictvím brainstormingových schůzek zahrnujících správné zúčastněné strany.

Během této fáze proběhne podrobné posouzení rizik zabezpečení produktu, které se také někdy nazývá „Statické hodnocení“ musí být provedeno bezpečnostním týmem odborníků.

Posouzení bezpečnostních rizik zahrnuje revizi programů z bezpečnostního hlediska ve fázi předběžného návrhu / architektury s cílem identifikovat chyby související se zabezpečením z hlediska designu a odpovídajícím způsobem zvýšit produkt Bezpečnostní rizika projektovému týmu, aby je oslovil a vyhnul se vstupu do další fáze.

Tato hodnocení se provádějí na základě organizačních / průmyslových bezpečnostních pokynů, standardů a kontrol uvedených v těchto dokumentech. Např. UXW 00320, UXW 030017

Během hodnocení bezpečnostních rizik produktu:

• Požadavky, funkce, uživatelské příběhy a jejich designové dokumenty jsou kontrolovány na základě podrobností, artefaktů sdílených projektovým týmem, Např. Konstrukční dokumenty (HLDD a LLDD). Součástí hodnocení jsou také diskuse s příslušnými členy projektového týmu v případě absence dokumentů nebo vyjasnění případných pochybností.
• Mezery jsou identifikovány při mapování bezpečnostních požadavků programu proti stanoveným standardům a dalším osvědčeným postupům. Někdy se na základě zjištěných nedostatků vyvíjejí také modely hrozeb.
• Tyto mezery jsou identifikovány jako potenciální bezpečnostní rizika a zahrnují také návrhy možných zmírnění implementace, jsou vyvolány a spravovány.
• Jakmile jsou tyto zmírnění implementovány projektovým týmem, jsou ověřeny pro uzavření pomocí vhodných testovacích případů navržených týmem pro testování systému.
• Matice řízení rizik, která zajišťuje sledovatelnost, je připravena tato rizika sledovat. Schválení a odhlášení se zbytkovým rizikem bude provedeno Security Architect a PSO.

Typické vzory hrozeb, které jsou identifikovány ve fázi návrhu, se týkají ověření vstupu, správy auditu / protokolu, konfigurací a šifrování. Identifikace rizik zahrnuje napadení zranitelných míst, jako jsou slabá hesla, útoky Simple Brute Force Attacks atd.,

Typické kontroly zahrnují rizika související s přístupem k osobním údajům, přístupem k auditovacím trasám, entitám na černé listině a seznamu povolených, čištění dat a aktivitě odstraňování.

ado net otázky a odpovědi pro zkušené

Ukázkové testovací scénáře zahrnují:

• Chyba zabezpečení týkající se přetečení vyrovnávací paměti: Aby bylo zajištěno, že ručním fuzzováním parametrů by nemělo být možné zpomalit server a přinutit server nereagovat (Denial of Service).
• Sanitizace dat: Zajistit, aby ke každému vstupu a výstupu došlo ke správné dezinfekci dat, aby útočník nemohl vložit a uložit škodlivý obsah v systému.

# 4) Fáze vývoje

Zabezpečená analýza kódu je Hodnocení statického kódu metoda, která se používá k posouzení Bezpečnostní kód různých funkcí softwaru pomocí automatizovaného skenovacího nástroje. Příklad: Opevnit.

Tato analýza se provádí při každém vrácení / sestavení kódu, aby se prohledal kód vygenerovaný z hlediska bezpečnostních hrozeb. Toto hodnocení se obvykle provádí na úrovni uživatelského příběhu.

• Na strojích vývojáře je třeba nainstalovat prověřování pomocí pluginů.
• Fortify je třeba integrovat do šablony sestavení.
• Na všech sestaveních bude denně prováděno automatické skenování.
• Výsledek kontroly bude analyzován bezpečnostním týmem kvůli falešným poplachům.
• Vady identifikované tímto hodnocením jsou vyvolány a odstraněny až do uzavření, takže průsak je minimalizován / vynulován na další úroveň.

Ukázkové testovací scénáře zahrnují:

• Zajistit, aby se citlivá data během přenosu dat neposílala jako text.
• Aby byl zajištěn bezpečný přenos dat, musí být na kanálu HTTPS nasazena externí rozhraní API.

# 5) Fáze implementace

Dynamická analýza kódu není nic jiného než Testování zabezpečení aplikací, které se také říká testování OWASP (Open Web Application Security Project). Ve fázi implementace / testování je třeba provést analýzu zranitelnosti a penetrační testování (VAPT).

Tato analýza hodnotí binární soubory a některé konfigurace prostředí a dále posiluje kód požadavků na zabezpečení.

V rámci této analýzy Dynamické chování nebo funkce různých funkcí programů jsou analyzovány z hlediska bezpečnostních slabin. Stanovené případy použití a obchodní scénáře se také používají k provádění dynamické analýzy kódu.

Tato činnost se provádí na Testovací sestavy pomocí různých bezpečnostních nástrojů s automatizovaným a manuálním přístupem.

• Nástroje HP WebInspect, Burp Suite, ZAP a SOAP UI se obecně používají ke kontrole chyb zabezpečení oproti standardním databázím zranitelností ( Příklad: OWASP Top 10 )
• Tato aktivita je však hlavně automatizovaná, kvůli určitým omezením nástrojů může být pro třídění falešných poplachů vyžadována určitá manuální práce.
• To se ideálně provádí v samostatném prostředí (System Testing Environment), kde je nasazen software připravený k testování.
• Je třeba zvýšit zranitelnosti a zavřít je pomocí navrhovaných Zmírnění.

Typické vzorce hrozeb identifikované během této analýzy se týkají ověření vstupu, nefunkčního ověřování a správy relací, vystavení citlivých dat, XSS a správy hesel.

Ukázkové testovací scénáře zahrnují,

• Správa hesel: Zajistit, aby hesla nebyla uložena jako prostý text v konfiguračních souborech nebo kdekoli v systému.
• Únik informací o systému: Aby bylo zajištěno, že informace o systému nebudou v žádném okamžiku prozrazeny, mohly by informace odhalené printStackTrace pomoci protivníkovi z plánu útoku.

# 6) Testování - fáze před nasazením

Penetrační testování , Zkouška perem ve zkratce a Infra VAPT (analýza zranitelnosti a penetrační testování) , je plnohodnotný celostní test s úplné řešení a konfigurace (včetně sítě), které se ideálně provádí v předprodejním nebo produkčním prostředí.

To se provádí hlavně za účelem identifikace chyb zabezpečení DB a serverů spolu s dalšími chybami zabezpečení. Toto je poslední fáze testování zabezpečení, která by proběhla. To tedy zahrnuje také ověření dříve nahlášených závad a rizik.

• K testování pera se používají nástroje jako Nessus, Nmap, HP Web Inspect, Burp Suite, ZAP, které jsou dostupné na trhu.
• Během tohoto testování se provádí skenování webových aplikací pomocí automatizovaných nástrojů a využití pro další ověření. Testování se provádí za účelem simulace chování skutečného útočníka, a proto může zahrnovat i několik negativních testů.
• Zranitelnost infrastruktury Posouzení zahrnuje skenování, analýzu a kontrolu konfigurace zabezpečení infrastruktury (sítě, systémy a servery) za účelem identifikace zranitelných míst a kontroly odolnosti proti cíleným útokům.
• To se provádí v předprodukčním nebo produkčním prostředí, kde je testován software, který je připraven k nasazení, a proto simuluje prostředí v reálném čase.
• Zranitelnosti jsou identifikovány pomocí skenerů i manuálních technik k eliminaci falešných poplachů. Během ručního testování budou také provedeny obchodní scénáře v reálném čase.
• Bude vypracována závěrečná zpráva o celé bezpečnostní analýze prováděné pro celý program, která zvýrazní stav vysoce rizikových položek, pokud existují.

Ukázkové testovací scénáře zahrnují,

• Zajistit, aby nebyly povoleny zranitelné metody HTTP.
• Aby se zajistilo, že citlivé informace ostatních uživatelů nebudou v síti viditelné jako prostý text.
• Aby se zajistilo ověření pro nahrávání souborů, aby se zabránilo nahrávání škodlivého souboru.

Tabulkové shrnutí pro SSDLC

Níže uvedená tabulka shrnuje různé aspekty bezpečnostní analýzy, které jsou vysvětleny výše.

Závěr

Díky implementaci všech těchto aspektů souvisejících se zabezpečením integrovaných v různých fázích SDLC tedy pomáhá organizaci identifikovat chyby zabezpečení na začátku cyklu a umožňuje organizaci implementovat vhodná zmírnění, čímž se vyhne Vysoce rizikové bezpečnostní vady v živém systému.

Studie také ukazuje, že většina bezpečnostních vad je do softwaru indukována během fáze vývoje, tj. Během Fáze kódování , přičemž kódování se z jakýchkoli důvodů dostatečně nestaralo o všechny bezpečnostní aspekty.

V ideálním případě by žádný vývojář nechtěl napsat špatný kód, který by narušil zabezpečení. Abychom tedy mohli vývojářům poradit, jak psát zabezpečený software, obsahuje nadcházející výukový program Osvědčené postupy a pokyny pro kódování pro vývojáře, aby byla zajištěna lepší bezpečnost softwaru.

Doufáme, že vám tento návod na Secure SDLC nebo SSDLC pomohl !!

Doporučené čtení

• Fáze, metodologie, proces a modely SDLC (životní cyklus vývoje softwaru)
• 10 nejlepších nástrojů pro testování zabezpečení mobilních aplikací v roce 2021
• 19 výkonných nástrojů pro testování penetrace používaných profesionály v roce 2021
• Pokyny pro testování zabezpečení mobilních aplikací
• Testování zabezpečení sítě a nejlepší nástroje pro zabezpečení sítě
• Testování zabezpečení (kompletní průvodce)
• Nejlepší 4 nástroje pro testování zabezpečení s otevřeným zdrojovým kódem pro testování webových aplikací
• Průvodce testováním zabezpečení webových aplikací