Aneks A, deo 20: A.8.19 i A.8.32–8.33 — Softver i upravljanje promenama

 Dvadeseti deo serije o Aneksu A. Vraćamo se na temu planiranih promena iz klauzule 6.3 i klauzule 8.1, sada iz konkretnijeg, tehničkog ugla — instalacije softvera i formalnog procesa upravljanja promenama u IT sistemima.

Šta ove kontrole traže

A.8.19 — Instalacija softvera na operativnim sistemima. Treba primeniti procedure i mere za bezbedno upravljanje instalacijom softvera na sistemima koji se koriste u svakodnevnom radu — ne dozvoliti da bilo ko instalira bilo šta bez kontrole.

A.8.32 — Upravljanje promenama. Promene na objektima za obradu informacija i informacionim sistemima treba da prate formalne procedure upravljanja promenama.

A.8.33 — Test podaci. Podaci korišćeni za testiranje treba da budu odgovarajuće izabrani, zaštićeni i upravljani.

Zašto su ove kontrole bitne

A.8.32 je bliska rođaka klauzule 6.3 i primera nenamernih promena iz klauzule 8.1, koje smo već detaljno obradili u glavnoj seriji. Razlika je u fokusu — ovde je reč specifično o promenama u softveru i tehničkim sistemima, sa formalnijim koracima nego što opšti princip iz 6.3 zahteva. A.8.19 i A.8.33 dopunjuju ovu temu sa dve strane koje do sada nismo pokrili — šta se sme instalirati, i kakvi podaci se koriste dok se nešto testira.

Primer iz prakse

A.8.19, kontrola koja sprečava slučajne odluke pojedinaca: zaposleni u agenciji ne mogu sami da instaliraju softver na službenim laptopovima — svaki zahtev ide preko spoljnog IT saradnika, koji proverava da li je program licenciran, u skladu sa politikom prihvatljive upotrebe opisanom u ranijem delu serije, i da li narušava standardnu konfiguraciju uređaja opisanu u delu serije o osnovnim operacijama. Ovo sprečava upravo onu vrstu situacije koja je dovela do korišćenja ličnog servisa za deljenje fajlova, opisanog u tekstu o klauzuli 8.1 — sada bi taj isti zaposleni morao prvo da prođe kroz ovaj proces, umesto da sam instalira šta mu zatreba.

A.8.32, nadogradnja koja nije ista priča kao migracija koju već znate: kad je cloud platforma najavila veću nadogradnju, sa novim korisničkim interfejsom i izmenjenim načinom upravljanja pristupom, agencija nije jednostavno prihvatila ažuriranje čim je ponuđeno. Prvo je dokumentovano šta se tačno menja, na osnovu najave dobavljača. Zatim je procenjeno da li nova verzija utiče na postojeće kontrole pristupa — individualne naloge i dvofaktorsku autentifikaciju. Nadogradnja je testirana u probnom okruženju koje je dobavljač ponudio, sa unapred pripremljenim planom povratka na staru verziju ako nešto krene naopako. Tek posle svega toga, nadogradnja je primenjena za sve korisnike, uz najavu timu nekoliko dana unapred. Ovo je drugačija situacija od migracije klijenata sa Excel fajlova opisane u klauzuli 6.3 — ista disciplina, ali primenjena na promenu koju je pokrenuo dobavljač, ne sama agencija.

A.8.33, isti princip koji ste već upoznali kao maskiranje podataka: test okruženje korišćeno za proveru nadogradnje iz prethodnog primera sadržalo je isti maskiran, izmišljen skup podataka opisan u delu serije o zaštiti podataka, ne stvarne klijentske informacije. Posle završenog testiranja, test okruženje je očišćeno, kako privremeni podaci ne bi ostali negde zaboravljeni.

Gde se dokumentuje

A.8.19 dokumentuje se kroz kratak proces odobravanja instalacije softvera, uključen u istu tematsku politiku o prihvatljivoj upotrebi. A.8.32 dokumentuje se kroz obrazac promene — šta se menja, procena uticaja, plan testiranja, plan povratka, odobrenje — sličan planu promene opisanom u klauzuli 6.3, samo detaljniji za tehničke promene. A.8.33 dokumentuje se kroz kratku napomenu da se test podaci brišu posle upotrebe, deo iste politike koja pokriva maskiranje podataka.

Najčešća greška

Najčešća greška kod A.8.19 je dozvoljavanje zaposlenima da sami instaliraju softver „jer im hitno treba", bez ikakve provere — tačno situacija koja je dovela do primera sa ličnim servisom za deljenje fajlova. Kod A.8.32, greška je prihvatanje nadogradnji i promena čim ih dobavljač ponudi, bez ijedne provere uticaja na postojeće kontrole — udobno, ali rizično, jer se promena koja izgleda bezazleno može pokazati kao nešto što tiho naruši već uspostavljenu bezbednost. Kod A.8.33, najčešća greška je korišćenje stvarnih podataka za testiranje jer je „jednostavnije", uz zaboravljanje da se ti podaci posle testiranja obrišu.

Šta sledi

Sledeći deo serije ide na kontrole A.8.20–8.23 — mrežnu bezbednost, gde prelazimo na infrastrukturu koja povezuje sve što smo do sada opisali.