secria.eu

Co patří do bezpečnostní politiky pro vývoj softwaru?

Bezpečnostní politika pro vývoj softwaru popisuje jak to, jak chráníte produkt, který budujete, tak i to, jak chráníte své vlastní vývojové prostředí — tento článek vysvětluje, které součásti by do ní měly patřit.

Co patří do bezpečnostní politiky pro vývoj softwaru?

Bezpečnostní politika pro vývoj softwaru je dokument, v němž vaše organizace stanovuje, jak nakládá se zabezpečením informací, systémů a kódu. Pro softwarovou společnost jde současně o dvě věci: zabezpečení toho, co budujete, a zabezpečení prostředí, ve kterém to budujete. Obě patří do stejného dokumentu, i když obsahově se jedná o různá témata.

V praxi to znamená, že politika se obvykle věnuje rozsahu (které systémy a které vývojové projekty patří do jejího oboru), odpovědnosti (kdo rozhoduje, kdo spravuje, kdo kontroluje), způsobu, jakým je upravován přístup ke zdrojovému kódu a vývojovým prostředím, tomu, jak jsou hledány a řešeny zranitelnosti v novém kódu, jak se zachází s testovacími prostředími a provozními prostředími, jak jsou incidenty zaznamenávány a jak se samotná politika udržuje a přezkoumává. Katalog otázek od zákazníka často požaduje právě takto vypadající dokumenty jako důkaz, nikoliv technický popis vašeho zdrojového kódu.

Dvě vrstvy: produkt a vývojové prostředí

První vrstva se zabývá produktem: softwarem, který dodáváte zákazníkům. Patří sem popis toho, jak nakládáte se zranitelnostmi, které jsou zjištěny po dodání, jak se aktualizace a záplaty dostávají k zákazníkům a kdo je v organizaci odpovědný za sledování hlášení o bezpečnostních problémech v produktu.

Druhá vrstva se věnuje vývojovému prostředí: prostředí, ve kterém váš tým pracuje. Jde o prostředí správy verzí, o kanál budování a testování a o oddělení testovacích a provozních prostředí. Zde jde o otázky typu kdo má přístup ke zdrojovému kódu, jak se kontrolují změny dříve, než se nasadí do provozu, a jak se přístup odebere, když někdo tým opustí. Obě vrstvy mohou být v jednom dokumentu, ale často se popisují zvlášť, protože se liší rizika a jejich vlastníci.

Proč si to zákazník vyžádá

Organizace, které samy podléhají zákonné povinnosti, jsou povinny posoudit rizika u svých dodavatelů. Softwarová společnost, která pro takovou organizaci vyvíjí, dostane proto otázky, které nevycházejí z vlastní povinnosti, ale z dodavatelského řetězce. Bezpečnostní politika je pak často prvním kuskem, který si vyžádá, protože v jednom dokumentu ukazuje, jak systematicky se k bezpečnosti přistupuje. Pokud to chybí, musíte to vysvětlit v katalogu otázek bod za bodem, což trvá déle a působí méně přesvědčivě než existující dokument.

Zda vaše organizace sama podléhá zákonné povinnosti, podléhá dodavatelskému řetězci, nebo nic z toho, nelze poznat na první pohled. v několika otázkách vidíte, kde vaše organizace stojí zde podává první orientaci s vysvětlením proč.

Jak se tato politika vztahuje k jednotlivým opatřením

Bezpečnostní politika nestojí samostatně. Na vysoké úrovni popisuje, jak se zabezpečením zabýváte, zatímco jednotlivá opatření — řízení přístupu, zálohování, zaznamenávání incidentů, posouzení dodavatelů — jsou její konkrétní realizací. Kdo politiku napíše bez toho, aby měl vyřešena základní opatření, má dokument, který neodpovídá praxi. Opačně je to také obtížné: jednotlivá opatření bez obecné politiky vypadají chaoticky pro toho, kdo se na ně dívá. přehled všech témat pro každou situaci ukazuje, jak spolu tyto součásti souvisejí.

Co v praxi často chybí

V mnoha prvních verzích takové politiky chybí jasný vlastník pro každou část: kdo je odpovědný za aktualizaci zásad přístupu, kdo za politiku oprav. Také pevné datum vyhodnocení často chybí, takže politika ze před dvěma lety je stále prezentována jako aktuální, přestože se vývojová linka mezitím změnila. A třetí věc, která často chybí: explicitní propojení mezi politikou a důkazy, které ukazují, že se také provádí, jako jsou protokoly přístupových práv nebo přehled provedených oprav.

Posouzení vaší vlastní situace

Které části přesně se očekávají, závisí na roli vaší organizace v dodavatelském řetězci a na tom, co konkrétní odběratel požaduje. Tento článek popisuje běžnou strukturu, nikoli povinnou šablonu, a samotný text zákona nestanovuje pevné rozdělení. Pro posouzení vaší specifické situace je právník nebo příslušný orgán dohledu tou správnou stranou; časté otázky o tomto typu dokumentů poskytuje dodatečný přehled toho, na co se často ptají.

Chcete vidět, jak se taková politika spolu s podkladovými opatřeními a důkazy vede v průběžném spisu místo jako samostatný dokument? jak secria.eu informace vytváří a vede to ukazuje. Jinak začněte bezplatnou NIS2-kontrolou nebo si prohlédněte znalostní bázi, abyste viděli, která témata jsou pro vaši organizaci relevantní.

Tento článek je obecné informace a není právní porada.