Mit tartozik a szoftfejlesztésre vonatkozó információbiztonságipolitikába?
A szoftverfejlesztéshez szükséges információbiztonság irányelv az a dokumentum, amelyben rögzíti, hogy szervezete hogyan kezeli az információ-, rendszer- és kódbiztonságot. Egy szoftvervállalatnak ezt két dologra kell figyelnie egyszerre: az általa felépített termék biztonsága, valamint az azt felépítő környezet biztonsága. Mindkettő ugyanabban a dokumentumban tartozik elő, pedig tartalmilag különböző témakörök.
Ez konkrétan azt jelenti, hogy az irányelv általában kitér a hatályre (mely rendszerek és fejlesztési projektek tartoznak alá), a felelősségekre (ki dönt, ki kezeli, ki ellenőriz), a forráskódhoz és fejlesztési környezetekhez való hozzáférés szabályozásának módjára, hogyan történik a saját kódban lévő sebezhetőségek feltárása és kijavítása, hogyan kezelik a tesztelési és az éles termelési környezeteket, hogyan rögzítik az incidenseket, és hogyan tartják karban és tekintik át az irányelveket. Az ügyfél kérdőíve gyakran éppen ilyen dokumentumokat kér bizonyítékként, nem pedig a forráskód műszaki leírását.
Két réteg: a termék és a fejlesztési infrastruktúra
Az első réteg a termékre vonatkozik: az ügyfeleknél telepített szoftver. Ehhez hozzátartozik annak leírása, hogyan kezeli az átadás után felfedezett sebezhetőségeket, hogyan kerülnek az frissítések és javítások az ügyfeleknél, és ki felelős a szervezetben a terméket érintő biztonsági problémákról szóló értesítések követéséért.
A második réteg a fejlesztési infrastruktúrára vonatkozik: az a környezet, amelyben a csapata dolgozik. Ez a verziókezelési környezet, az építési és tesztpipeline, valamint a tesztelési és az éles termelési környezet közötti elkülönítés. Itt olyan kérdésekről van szó, mint hogy ki férhet hozzá a forráskódhoz, hogyan kerülnek felülvizsgálatra a módosítások az éles üzem előtt, és hogyan vonják vissza a hozzáférést, amikor valaki elhagyja a csapatot. Mindkét réteg ugyanabban a dokumentumban lehet, de gyakran külön írják le, mert az ezekben rejlő kockázatok és tulajdonosaik eltérnek egymástól.
Miért kérdez rá az ügyfél
Azok a szervezetek, amelyek maguk tartoznak a gondoskodási kötelezettség alá, kötelesek értékelni beszállítóiknál lévő kockázatokat. Egy szoftvervállalatnak, amely ilyen szervezet számára fejleszt, így olyan kérdésekre kapnak, amelyek nem saját kötelezettségből, hanem a beszerzési láncon belülről fakadnak. Az információbiztonság irányelve ekkor gyakran az első, amit felkérnek, mivel egyetlen dokumentumban mutatja meg, mennyire rendszeres megközelítést követnek a biztonságban. Ha hiányzik, akkor egy kérdőívben mindent egyenként külön kell magyaráznia, ami több időbe telik és kevésbé meggyőző, mint egy már létező dokumentum.
Hogy szervezete maga tartozik-e a gondoskodási kötelezettség alá, a beszerzési lánc alá, vagy egyikhez sem, nem látható egy pillantásra. néhány kérdésben láthatóan megmutatja, hol áll a szervezete erre vonatkozóan ad első támpontot, és magyarázatot arra, hogy miért.
Hogyan viszonyul ez az irányelv az egyes intézkedésekhez
Az információbiztonság irányelve nem áll egymagában. Főbb vonalakban leírja, hogyan kezeli a biztonságot, míg az egyes intézkedések — hozzáférés-szabályozás, mentések, incidensrögzítés, beszállítóértékelés — ezek konkrét megvalósítása. Aki az irányelveket írja meg anélkül, hogy az alá tartozó intézkedések rendben lennének, olyan dokumentummal áll elő, amely nem felel meg a gyakorlatnak. Fordítva sem jó: az egyes intézkedések anélkül, hogy átfogó irányelvek lennének, rendszertelen benyomást keltenek, aki megkérdezi. az összes tárgy áttekintése helyzetre lebontva megmutatja, hogyan függnek össze ezek az összetevők.
Mit szokott a gyakorlatban hiányozni
Sok kezdeti verziójú ilyen szabályzatban hiányzik az egyes komponensekhez rendelt egyértelmű felelős: ki felel az hozzáférési szabályzat naprakészen tartásáért, ki a javítási szabályzatéért. Gyakran egy rögzített értékelési dátum is hiányzik, ezért egy két éve készített szabályzat ma is aktuálisnak tűnik, pedig a fejlesztési folyamat közben sok minden megváltozott. Harmadik pont, amely gyakran nem szerepel: a szabályzat és azok a bizonyítékok közötti kifejezett kapcsolat, amelyek azt mutatják, hogy valóban végre is hajtják, például hozzáférési jogok naplói vagy a végrehajtott javítások áttekintése.
Saját helyzetének értékelése
Pontosan mely komponenseket kell tartalmaznia, az függ a szervezete szerepétől az ellátási láncban és attól, hogy az adott ügyfél mit kér. Ez a cikk az általános felépítést ismerteti, nem egy kötelező sablont, és az itself jogszabály nem ír elő rögzített formátumot. Saját helyzete megítéléséhez egy jogász vagy az illetékes felügyeleti hatóság az ideális partner; az ilyen típusú dokumentumokkal kapcsolatos gyakori kérdések további áttekintést nyújt arról, amit gyakran kérnek.
Szeretné megtudni, hogyan tarthat nyilván egy ilyen szabályzatot a mögöttes intézkedésekkel és bizonyítékokkal együtt egy folyamatban lévő dossziéban, ahelyett hogy önálló dokumentumként kezelnék? hogyan építi fel és tartja naprakészen a secria.eu az információkat ezt mutatja meg. Másként kezdje a ingyenes NIS2-vizsgálattal, vagy böngésszen a tudásbázisban, hogy megnézze, mely témák relevánsak a szervezete számára.