Drošības politikas, kuras cilvēki spēj ieviest

Drošības politikai būtu jāpalīdz cilvēkam izlemt, kā rīkoties reālā situācijā. Tās vērtība ir atkarīga no skaidriem noteikumiem, pieejamām kontrolēm un praktiska veida, kā tos ievērot. Dokuments, kas sola kontroles, kuras jūsu sistēmas nevar nodrošināt, rada apjukumu darbiniekiem un neuzticamus pierādījumus pārskatītājiem.

Tāpēc tehnoloģiju direktoram politiku izstrāde ir ieviešanas uzdevums: definēt prasīto rīcību, pārbaudīt tehniskās atkarības, piešķirt atbildību un pārbaudīt, vai noteikums praksē darbojas.

Sāciet ar lēmumu, kas cilvēkiem jāpieņem

Izvēlieties konkrētu darbību, piemēram, failu kopīgošanu ar ārējām personām, piekļuves piešķiršanu ražošanas videi vai ziņošanu par pazaudētu ierīci. Nosakiet aptverto informāciju, sistēmas, cilvēkus un darbības, attiecīgā gadījumā ieskaitot darbuzņēmējus un ārējos pakalpojumu sniedzējus.

Aizstājiet neskaidrus formulējumus, piemēram, „kopīgojiet informāciju droši”, ar prasībām, kuras kāds var piemērot. Ārējai kopīgošanai norādiet atļautās informācijas klases, apstiprinātos kanālus, pilnvarojumu, saņēmēja piekļuvi un izņēmumus. Īsi izskaidrojiet iemeslu: piekļuve vārdā nosauktiem saņēmējiem samazina nejaušu izpaušanu un ļauj noņemt piekļuvi.

Nošķiriet trīs slāņus:

Sasaistiet politiku ar procedūru, ko darbinieki faktiski izmanto. Tādējādi politika nav jāpārraksta katru reizi, kad mainās rīka saskarne.

Izspēlējiet reālistisku piemēru pirms apstiprināšanas

Ilustratīvi pieņēmumi: projekta komanda kopīgo konfidenciālus projektēšanas failus ar ārēju konsultantu. Tās sadarbības platforma atbalsta vārdā nosauktus saņēmējus un piekļuves derīguma termiņu, taču klasificēšana notiek manuāli.

Ieviešams noteikums varētu prasīt, lai projekta īpašnieks atļauj izpaušanu, sūtītājs izmanto apstiprināto platformu un piekļuves termiņš beidzas līdz ar sadarbības beigām. Publiskas saites šai informācijas klasei nebūtu atļautas.

Izspēlējiet melnrakstu faktiskajā darba plūsmā:

• Sūtītājs nosaka faila klasifikāciju, izmantojot klasifikācijas ceļvedi.
• Projekta īpašnieks apstiprina, ka konsultantam informācija ir nepieciešama.
• Sūtītājs piešķir piekļuvi konsultanta pārbaudītajam kontam un iestata saskaņoto derīguma termiņu.
• Apstiprinājuma ierakstā norādīts fails, saņēmējs, nolūks un beigu datums.
• Sistēmas īpašnieks pārbauda, vai piekļuves termiņš beidzas vai piekļuve tiek noņemta, kad sadarbība beidzas.

Pierādījumi ietvertu pilnvarojumu, kopīgošanas konfigurāciju un piekļuves noņemšanas ierakstu. Ja konsultants nevar autentificēties, risinājums nav neformāla publiska saite: izmantojiet izņēmumu procesu vai citu apstiprinātu piegādes metodi.

Pārbaudiet, vai organizācija spēj izpildīt prasības

Pārskatiet melnrakstu kopā ar cilvēkiem, kuriem to paredzēts ieviest, ieskaitot palīdzības dienesta darbiniekus un sistēmu īpašniekus. Lūdziet viņus izpildīt darba plūsmu, nevis tikai apstiprināt formulējumu.

Pārliecinieties, ka ir pieejami rīki, laiks, kompetence, atļaujas un atbalsts. Ja derīguma termiņu nevar automatizēt, izlemiet, vai pietiek ar plānotu manuālas noņemšanas uzdevumu. Pretējā gadījumā mainiet ieviešanas plānu, pirms paziņojat, ka kontrole darbojas.

Definējiet izņēmumu procesu ar apstiprinātāju, pamatojumu, skarto tvērumu, aizsardzības pasākumiem, derīguma termiņu un pārskatīšanu. Saglabājiet izņēmumus redzamus riska pārvaldībai, nevajadzīgi neizplatot sensitīvu informāciju. Atkārtoti izņēmumi var liecināt par nepiemērotu noteikumu vai trūkstošu spēju, nevis tikai par darbinieku neatbilstību.

Padariet pieņemšanu par piegādes daļu

Publicējiet politikas vietā, kur darbinieki tās var atrast darba laikā, nevis tikai audita mapē. Iekļaujiet saites uz politikām attiecīgajās pieprasījumu veidlapās un ievadīšanas darbā materiālos. Izskaidrojiet, kas mainījās un kam jārīkojas.

Izmantojiet īsas, uz scenārijiem balstītas instrukcijas: lūdziet sūtītājam konfigurēt ārēju kopīgošanu vai pajautājiet darbiniekam, kā viņš ziņotu par pazudušu klēpjdatoru. Nodrošiniet ziņošanas ceļu, ko var izmantot bez pazudušās ierīces. Iepazīšanās apliecinājumi parāda komunikāciju; tie nepierāda, ka kāds spēj izpildīt procesu.

Sasaistiet prasības ar darbības pierādījumiem

ISO/IEC 27001 attiecas uz informācijas drošības pārvaldības sistēmu ar definētu tvērumu. Sasaistiet politikas ar piemērojamajām prasībām un riska apstrādes lēmumiem šajā tvērumā, nevis importējiet katru veidni kā obligātu. Uzturiet šīs sasaistes atsevišķi no darbiniekiem paredzētajām instrukcijām.

Katram svarīgam noteikumam nosakiet tā īpašnieku, atbalsta kontroli, pierādījumus un pārskatīšanas metodi. Failu kopīgošanai pārbaudiet reālu kopīgošanu izlasi attiecībā uz pilnvarojumu, saņēmēju ierobežojumiem un piekļuves robežām. Kā praktisku rekomendāciju apvienojiet konfigurācijas pierādījumus ar darījumu ierakstiem: ekrānuzņēmums ar drošiem noklusējuma iestatījumiem viens pats nepierāda, ka katra kopīgošana notika saskaņā ar procesu.

Saglabājiet politikas saskaņā ar mainīgajām sistēmām

Saglabājiet īpašnieku, apstiprinātāju, versiju, spēkā stāšanās datumu, komunikācijas ierakstu un pārskatīšanas vēsturi. Pārskatiet plānotos intervālos un tad, kad mainās attiecīgās sistēmas, incidenti, līgumi vai pienākumi.

MI var palīdzēt sagatavot melnrakstus, balstoties uz apstiprinātām prasībām un esošām procedūrām. Pirms publicēšanas pārskatiet katru apgalvojumu par pašreizējo ieviešanu.

Secani sasaistiet politiku avota materiālus ar prasībām, kontrolēm, īpašniekiem un pierādījumiem; pārvērtiet nepilnības uzdevumos un saglabājiet pārskatītos lēmumus. Cilvēka pārskatīšana paliek skaidri noteikta, palīdzot politikai saglabāt saikni ar faktisko ieviešanu.

Sāciet ar vienu bieži izmantotu darba plūsmu. Pārbaudiet to kopā ar tās lietotājiem, novērsiet trūkstošās spējas un savāciet darbības pierādījumus, pirms paplašināt politiku kopu.