secria.eu

Kas turėtų būti informacijos saugumo politikoje programinės įrangos kūrimui?

Informacijos saugumo politika programinės įrangos kūrimui aprašo tiek tai, kaip jūs saugote produktą, kurį kuriate, tiek kaip saugote savo pačių kūrimo liniją — šiame straipsnyje išdėstomi komponentai, kurie turėtų būti šioje politikoje.

Kas turėtų būti informacijos saugumo politikoje programinės įrangos kūrimui?

Informacijos saugumo politika, skirta programinės įrangos kūrimui, yra dokumentas, kuriame nurodote, kaip jūsų organizacija tvarkosi su informacijos, sistemų ir kodo saugumu. Programinės įrangos įmonei tai reiškia du dalykus vienu metu: kuriamos programinės įrangos saugumą ir aplinkos, kurioje ją kuriate, saugumą. Abu turėtų būti viename dokumente, nors turinio požiūriu tai skirtingi klausimai.

Praktikoje tai paprastai reiškia, kad politika apima taikymo sritį (kurios sistemos ir kurie kūrimo projektai į ją patenka), atsakomybes (kas nusprendžia, kas valdo, kas tikrina), galimybę pasiekti šaltinio kodą ir kūrimo aplinkas, kaip randamos ir pašalinamos savojo kodo pažeidžiamosios vietos, kaip tvarkomi testavimo aplink ir gamybos aplinkos, kaip registruojami incidentai ir kaip pati politika palaikoma ir peržiūrima. Užsakovo klausimynas dažnai prašo būtent tokių dokumentų kaip įrodymo medžiaga, o ne techninės jūsų šaltinio kodo aprašymo.

Du lygiai: produktas ir kūrimo procesas

Pirmasis lygis yra skirtas produktui: programinei įrangai, kurią tiekiate klientams. Čia turėtų būti aprašymas, kaip tvarkotės su pažeidžiamomis vietomis, kurios surandamos po išsiuntimo, kaip atnaujinimai ir laidos pasiekia klientus, ir kas organizacijoje yra atsakingas už pranešimų apie saugumo problemas sekimą.

Antrasis lygis apima kūrimo procesą: aplinką, kurioje dirbate jūsų komanda. Tai versijų kontrolės aplinka, kūrimo ir testavimo konvejeris bei testavimo ir gamybos aplinkų atskyrimas. Čia kyla klausimai, kaip kas gali pasiekti šaltinio kodą, kaip tikrinami pakeitimai prieš tai, kai jie nukeliama į veiklą, ir kaip atšaukiama prieiga, kai kas nors opuoli komandą. Abu lygiai gali būti viename dokumente, tačiau dažnai aprašomi atskirai, nes su jais susiję rizikai ir atsakingi asmenys skiriasi.

Kodėl užsakovas apie tai klausias

Organizacijos, kurios pačios patenka į pareigų sritį, yra pripalintos įvertinti rizikų, susijusias su jų tiekėjais. Programinės įrangos įmonė, kuri kuria tokiai organizacijai, dėl to gauna klausimus, kurie kyla ne iš savos pareigos, bet iš tiekimo grandinės. Informacijos saugumo politika paprastai yra vienas iš pirmųjų prašomų dokumentų, nes iš jo matyti, kaip struktūriškai buvo taikomas saugumas. Jei jo nėra, turite atsakyti į klausimyną po klausimo, o tai užima daugiau laiko ir yra mažiau įtikinami nei turint esamą dokumentą.

Tai, ar jūsų organizacija pati patenka į pareigų sritį, pateka į grandinę ar į nei vieną, nėra iš karto akivaizdu. per porą klausimų pamatyti, kur stovi jūsų organizacija pateikia pirmą rodiklį, su paaiškinimais, kodėl.

Kaip šis saugumo reglamentas susijęs su atskiraias priemonėmis

Informacijos saugumo politika neegzistuoja viena. Ji aprašo bendromis linijomis, kaip tvarkotės su saugumu, o atskiros priemonės — prieigos valdymas, atsargos kopijos, incidentų registracija, tiekėjų įvertinimas — yra jos konkretus įgyvendinimas. Kas rašo politiką neturėdamas esamų tiesioginių priemonių, turi dokumentą, kuris neatitinka praktikos. Ir atvirkščiai: atskiros priemonės be visuotinos politikos atrodo šiukšliškai tam, kas jų ieško. visų temų apžvalga priklausomai nuo situacijos parodo, kaip šie elementai susiję vienas su kitu.

Kas praktikoje dažnai trūksta

Daugelyje pirmųjų tokios politikos versijų trūksta aiškaus savininko kiekvienam skyriui: kas atsakingas už prieigos politikos atnaujinimą, kas už pataisų politiką. Taip pat dažnai trūksta nustatytos vertinimo datos, todėl dar ir šiandien pristatoma politika iš prieš dvejus metus, nors programavimo aplinka tuo tarpu jau pasikeitė. Ir trečias dalykas, kurio dažnai nepakanka: aiški sąsaja tarp politikos ir įrodymų, rodančių, kad ji iš tikrųjų įgyvendinama, pavyzdžiui, prieigos teisių žurnalai ar įgyvendintų pataisų peržvalga.

Įvertinkite savo padėtį

Kurie tiksliai komponentai tikėtini, priklauso nuo jūsų organizacijos vaidmens tiekimo grandinėje ir nuo to, ką reikalauja konkretus pirkėjas. Šiame straipsnyje aprašomas bendras struktūra, ne privalomas šablonas, o pati teisės akto tekstas nenustato jokios fiksuotos struktūros. Norėdami susidaryti nuomonę apie jūsų konkrečią padėtį, turėtumėte kreiptis į jurista ar kompetentingą priežiūros institucją. dažnai užduodami klausimai apie tokius dokumentus pateikia papildomą apžvalgą, kas dažnai klausiama.

Norėtumėte pamatyti, kaip tokia politika, kartu su pagrindinėmis priemonėmis ir įrodymais, yra saugoma nuolatiniame dosyje, o ne kaip atskiras dokumentas? kaip secria.eu sudaro ir saugo informaciją tai parodo. Kitu atveju pradėkite nuo nemokamos NIS2 patikros arba naršykite žinių bazę, kad pamatytumėte, kokie klausimai yra svarbūs jūsų organizacijai.

Šis straipsnis yra bendroji informacija, o ne teisinė konsultacija.