secria.eu

Čo patrí do politiky bezpečnosti informácií pre vývoj softvéru?

Politika bezpečnosti informácií pre vývoj softvéru popisuje tak to, ako chránite produkt, ktorý vytvárate, ako aj to, ako chránite svoju vlastnú vývojovú linku — tento článok objasňuje, ktoré časti do nej patria.

Čo patrí do politiky bezpečnosti informácií pre vývoj softvéru?

Politika bezpečnosti informácií pre vývoj softvéru je dokument, v ktorom stanovujete, ako vaša organizácia zaobchádza s bezpečnosťou informácií, systémov a kódu. Pre softvérovú spoločnosť ide o dve veci súčasne: bezpečnosť toho, čo vytvárate, a bezpečnosť prostredia, v ktorom to vytvárate. Obe by mali byť v tom istom dokumente, aj keď z obsahového hľadiska ide o rôzne témy.

V praxi to znamená, že politika zvyčajne sa zaoberá rozsahom (ktoré systémy a ktoré vývojové projekty sú zahrnuté), zodpovednosťou (kto rozhoduje, kto spravuje, kto kontroluje), spôsobom, ako je usporiadaný prístup k zdrojovému kódu a vývojovým prostrediam, ako sa identifikujú a riešia zraniteľnosti vo vlastnom kóde, ako sa zaobchádza s testovacími prostrediami verzus produkčnými prostrediami, ako sa incidenty zaznamenávajú a ako sa samotná politika udržiava a preskúmava. Zoznam otázok od zákazníka často žiada práve takéto dokumenty ako dôkaz, nie technický popis vášho zdrojového kódu.

Dve vrstvy: produkt a vývojové prostredie

Prvá vrstva sa týka produktu: softvéru, ktorý dodávate zákazníkom. Patrí sem popis toho, ako zaobchádza te so zraniteľnosťami, ktoré sa objavia po dodaní, ako sa aktualizácie a záplaty dostanú k zákazníkom, a kto v rámci organizácie je zodpovedný za sledovanie hlásení o bezpečnostných problémoch v produkte.

Druhá vrstva sa týka vývojového prostredia: prostredia, v ktorom pracuje váš tím. Ide o prostredie správy verzií, build a testovacia pipeline a rozdelenie medzi testovacím a produkčným prostredím. Tu ide o otázky, ako kto má prístup k zdrojovému kódu, ako sa zmeny kontrolujú pred ich nasadením, a ako sa revokuje prístup, keď niekto opúšťa tím. Obe vrstvy môžu byť v tom istom dokumente, ale často sa popisujú oddelene, pretože sa líšia riziká a ich vlastníci.

Prečo sa na to pýta váš zákazník

Organizácie, ktoré sami spadajú pod povinnosť starostlivosti, sú povinné hodnotiť riziká u svojich dodávateľov. Softvérová spoločnosť, ktorá vyvíja pre takúto organizáciu, dostáva teda otázky, ktoré nevychádzajú z vlastnej povinnosti, ale z reťazca. Politika bezpečnosti informácií je potom často prvý dokument, ktorý sa požaduje, pretože v jednom dokumente ukazuje, ako štrukturálne je bezpečnosť riešená. Ak chýba, musíte to v zozname otázok vysvetliť zvlášť po jednotlivých otázkach, čo trvá dlhšie a pôsobí menej presvedčivo ako existujúci dokument.

Či vaša organizácia sama spadá pod povinnosť starostlivosti, spadá pod reťazec, alebo nespadá pod žiadne z toho, nie je vidieť na prvý pohľad. v niekoľkých otázkach vidí, kde sa vaša organizácia nachádza na základe prvého indikátora, s vysvetlením prečo.

Ako sa táto politika vzťahuje k jednotlivým opatreniam

Politika bezpečnosti informácií nestojí sama o sebe. Opisuje na hlavných líniách, ako zaobchádza te s bezpečnosťou, zatiaľ čo jednotlivé opatrenia — správa prístupu, zálohy, registrácia incidentov, hodnotenie dodávateľov — sú jej konkrétna realizácia. Kto politiku napíše bez toho, aby malo podkladné opatrenia na poriadku, má dokument, ktorý sa nezhoduje s praktikou. Naopak je to tiež ťažké: jednotlivé opatrenia bez celkovej politiky pôsobia roztriešťane voči tomu, kto sa ich pýta. prehľad všetkých tém podľa situácie ukazuje, ako sa tieto prvky navzájom spájajú.

Čo v praxi často chýba

V mnohých počiatočných verziách takýchto politík chýba jasný vlastník pre každú časť: kto je zodpovedný za udržiavanie aktuálnosti politiky prístupu, kto za politiku záplat. Často chýba aj pevný dátum hodnotenia, čo spôsobuje, že politika zo pred dvoch rokov sa stále prezentuje ako aktuálna, hoci sa vývojový pipeline medzičasom zmenil. A tretí bod, ktorý často chýba: explicitná väzba medzi politikou a dôkazmi, ktoré dokazujú, že sa tiež vykonáva, ako sú protokoly prístupových práv alebo prehľad implementovaných záplat.

Posúďte vašu vlastnú situáciu

Ktoré konkrétne prvky sa očakávajú, závisí od úlohy vašej organizácie v dodávateľskom reťazci a od toho, čo požaduje konkrétny odberateľ. Tento článok opisuje bežnú štruktúru, nie povinný vzor, a samotný zákonný text nepredpisuje pevné usporiadanie. Pri posúdení vašej špecifickej situácie je právnik alebo príslušný dohľadný orgán príslušnou stranou. často kladeným otázkam o takýchto dokumentoch poskytuje doplňujúci prehľad toho, čo sa často požaduje.

Chcete vidieť, ako sa takáto politika spolu s podkladajúcimi opatreniami a dôkazmi vedú v prebiehajúcom spise namiesto ako samostatný dokument? ako secria.eu informácie buduje a udržiava to ukazuje. Inak začnite bezplatnou NIS2-kontrolou, alebo si prelistujte vedomostnú základňu, aby ste zistili, ktoré témy sú relevantné pre vašu organizáciu.

Tento článok obsahuje všeobecné informácie a nepredstavuje právne poradenstvo.