Kas jāiekļauj informācijas drošības politikā programmatūras izstrādei?
Programmatūras izstrādes informācijas drošības politika ir dokuments, kurā jūs noteiciet, kā jūsu organizācija rīkojas ar informācijas, sistēmu un koda drošību. Programmatūras uzņēmumam tas attiecas uz diviem jautājumiem vienlaikus: to, ko jūs veidojat, drošības nodrošināšanu un vidi, kurā jūs to veidojat, drošības nodrošināšanu. Abi jautājumi jāiekļauj vienā dokumentā, lai arī tie ir atšķirīgi satura ziņā.
Konkrēti tas nozīmē, ka politika parasti satur darbības jomu (kuras sistēmas un kuri izstrādes projekti tiek ietverti), atbildību (kas pieņem lēmumus, kas pārvalda, kas pārbauda), paņēmienus, kā tiek regulēta piekļuve pirmkoda un izstrādes videi, kā tiek konstatētas un novērstas ievainojamības savā kodā, kā tiek rīkoties ar testa vidēm salīdzinājumā ar ražošanas vidēm, kā tiek reģistrēti incidenti un kā pati politika tiek uzturēta un pārskatīta. Klienta jautājumju saraksts bieži pieprasa tieši šādu dokumentu kā pierādījumu, nevis tehnisko aprakstu par jūsu pirmkodu.
Divi slāņi: produkts un izstrādes vide
Pirmais slānis attiecas uz produktu: programmatūru, ko jūs piegādājat klientiem. Tas ietver aprakstu par to, kā jūs rīkojaties ar ievainojamībām, kas atklātas pēc piegādes, kā atjauninājumi un labojumprogrammas nonāk pie klientiem, un kurš organizācijā ir atbildīgs par atsaucību uz informāciju par produkta drošības problēmām.
Otrais slānis attiecas uz izstrādes vidi: vidi, kurā strādā jūsu komanda. Tā ir versiju kontroles vide, veidošanas un testēšanas cauruļvads un atšķirība starp testa un ražošanas vidēm. Šeit jautājumi ir par to, kurš drīkst piekļūt pirmkodam, kā tiek pārbaudītas izmaiņas pirms to publicēšanas, un kā tiek atsaukta piekļuve, kad kāds atstāj komandu. Abi slāņi var atrasties vienā dokumentā, taču tos bieži apraksta atsevišķi, jo to riski un īpašnieki atšķiras.
Kāpēc klients tam jautā
Organizācijām, kuras pašas pakļaujas pienākumam veikt riskus noveršošas darbības, ir jānovērtē riski, kas saistīti ar to piegādātājiem. Programmatūras uzņēmums, kas izstrādā šādas organizācijas programmatūru, tāpēc saņem jautājumus, kas neizriet no pašas vispārējās normatīvās pienācības, bet no piegādes ķēdes. Informācijas drošības politika tad bieži ir pirmais pieprasītais dokuments, jo vienā dokumentā parāda, cik strukturēti drošiba ir ņemta vērā. Ja tā ir pietrūkusi, jums ir jāpaskaidro tas jautājumā pēc jautājuma jautājumā, kas prasa vairāk laika un ir mazāk pārliecinošs nekā esošs dokuments.
Tas, vai jūsu organizācija pašas pakļaujas pienākumam veikt riskus noveršošas darbības, pakļaujas piegādes ķēdei vai nē, nav redzams vienā mirklī. dažu jautājumu laikā noskaidrojiet, kur atrodas jūsu organizācija sniedz pirmo norādi, ar skaidrojumiem, kāpēc.
Kā šī politika attiecas uz atsevišķiem pasākumiem
Informācijas drošības politika nepastāv neatkarīgi. Tā galvenokārt apraksta, kā jūs rīkojaties ar drošību, kamēr atsevišķi pasākumi — piekļuves kontrole, dublējumi, incidentu reģistrācija, piegādātāju novērtēšana — ir to konkrētā īstenošana. Tas, kurš raksta politiku bez tā, lai būtu sakārtoti pamatā esošie pasākumi, ir dokuments, kas neatbilst praksei. Otrādi ir arī grūti: atsevišķi pasākumi bez apvienojošas politikas izskatās sašķaidīti tam, kurš to uzklausa. visu tēmu pārskats atkarībā no situācijas parāda, kā šie komponenti ir saistīti viens ar otru.
Kas praksē bieži tiek palaists garām
Daudzu šādu politiku pirmajās versijās trūkst skaidra katra komponenta atbildīgā: kas ir atbildīgs par piekļuves politikas aktualizēšanu, kas par ielāpošanas politiku. Bieži vien trūkst arī pastāvīga novērtēšanas datuma, tāpēc divi gadus veca politika joprojām tiek prezentēta kā aktuāla, lai gan attīstības procesu tikmēr ir mainījies. Un trešais punkts, kas bieži tiek aizmirsts: skaidra saikne starp politiku un pierādījumiem, kas apliecina tās īstenošanu, piemēram, piekļuves tiesību žurnāli vai ielāpoto grindu saraksts.
Novērtējiet savu situāciju
Kurš precīzi komponents tiek gaidīts, ir atkarīgs no jūsu organizācijas lomas piegādes ķēdē un no tā, ko pieprasa konkrēts pircējs. Šis raksts apraksta parasto uzbūvi, nevis obligātu veidni, un likuma teksts nenorāda fiksētu izkārtojumu. Lai novērtētu jūsu konkrēto situāciju, piemērota puse ir tiesībnieks vai kompetentā uzraudzības iestāde; bieži uzdotie jautājumi par šādu dokumentu sniedz papildu pārskatu par to, ko parasti vaicā.
Vai vēlaties redzēt, kā šāda politika, kopā ar pamatā esošajiem pasākumiem un pierādījumiem, tiek uzturēta nepārtrauktā dosiejā, nevis kā atsevišķs dokuments? kā secria.eu informāciju strukturē un uztur to parāda. Tā vietā sāciet ar bezmaksas NIS2-pārbaudi vai pārlūkojiet zināšanu bāzi, lai redzētu, kuri temati ir aktuāli jūsu organizācijai.