Kaj ISO 27001 pri izvajalcu pomeni za naročnika

Kaj ISO 27001 pri izvajalcu pomeni za naročnika#

ISO 27001 je mednarodni standard za sistem upravljanja informacijske varnosti. Kadar je ta standard vzpostavljen v delivery strukturi izvajalca, to pomeni, da so postopki za oceno tveganj, nadzor dostopa, obravnavo incidentov in upravljanje sprememb dokumentirani in ponovljivi, ne odvisni od posameznika. Za naročnika to konkretno pomeni, da lahko od izvajalca zahteva dokazila o tem, kako se obravnavajo dostopi do podatkov, gesla, izvorna koda in produkcijska okolja, ter da so ta pravila enaka ne glede na to, kdo v ekipi projekt izvaja.

Standard sam po sebi ne pove, ali je posamezen projekt varen – pove, da obstaja sistem, ki varnost obravnava sistematično. Za naročnika, ki povezuje ERP, CRM, dokumentne sisteme in poročanje z novo rešitvijo, je to pomembno, ker se tveganje ne nanaša le na novo aplikacijo, temveč na vse sisteme, s katerimi ta izmenjuje podatke. Sistematičen pristop pomeni, da izvajalec pred integracijo oceni, kateri podatki se prenašajo, kdo ima dostop do njih in kako se ta dostop nadzoruje skozi celoten razvojni cikel.

Znotraj Epixa in njegove specialistične partnerske mreže so v delivery strukturi vzpostavljeni standardi ISO 9001, ISO 20000/20001, ISO 27001 in ISO 27701. To pomeni, da projektne ekipe, ki jih sestavimo za posamezen projekt, delujejo znotraj teh okvirov ne glede na to, ali gre za razvoj informacijskega sistema, integracijo API-jev ali podporo po uvedbi. Za naročnika je razlika med izvajalcem, ki varnost obravnava priložnostno, in izvajalcem znotraj certificirane delivery strukture, najbolj vidna takrat, ko pride do incidenta, revizije ali menjave člana ekipe.

Zakaj to vpliva na projekte, ki povezujejo več sistemov#

Projekti, ki povezujejo ERP, CRM, proizvodne sisteme in poročanje, širijo obseg podatkov, do katerih ima izvajalec dostop, prek meja ene aplikacije. Vsaka integracija prek API-ja pomeni novo točko, kjer se podatki prenašajo med sistemi, in vsaka taka točka je hkrati mesto, kjer je treba dostop nadzorovati, beležiti in po potrebi omejiti. Kadar izvajalec deluje znotraj strukturirane varnostne prakse, to pomeni, da se pred vsako integracijo vnaprej opredeli, kateri podatki se prenašajo, kdo do njih dostopa in kako se ta dostop dokumentira za morebitno revizijo.

Za vodjo IT ali direktorja to pomeni manj negotovosti pri odločitvi, komu zaupati dostop do produkcijskih sistemov. Kadar projekt vodi projektni vodja z opredeljenimi odgovornostmi ekipe, roki in načinom poročanja, je jasno, kdo je odgovoren za posamezen del integracije in kako se spremembe potrjujejo, preden pridejo v produkcijo. To je še posebej pomembno pri projektih, ki povezujejo obstoječe sisteme, saj napaka pri eni integraciji lahko vpliva na delovanje več oddelkov hkrati.

Ločevanje razvojnega, testnega in produkcijskega okolja je del iste logike. V testnem okolju se ne uporabljajo pravi osebni podatki, kar zmanjša tveganje, da bi se občutljivi podatki naročnika znašli zunaj nadzorovanega okolja med razvojem ali testiranjem. Spremembe gredo skozi pregled in testiranje, preden se objavijo v produkcijo, kar naročniku daje možnost, da spremembe spremlja in po potrebi zahteva dodatno preverjanje pred uvedbo v delovanje.

Kaj ISO 27001 pri izvajalcu dejansko pokriva#

ISO 27001 se osredotoča na sistem upravljanja informacijske varnosti kot celoto, ne na posamezno tehnologijo. To pomeni, da standard predpisuje, kako se ocenjujejo tveganja, kako se dostopi dodeljujejo in odvzemajo, kako se obravnavajo incidenti in kako se dokumentacija vodi skozi čas. Za naročnika je pomembno razumeti, da to ni tehnično poročilo o eni aplikaciji, temveč okvir, znotraj katerega izvajalec vodi vse projekte, ki jih prevzame.

Za naročnika, ki upravlja z ERP, CRM ali dokumentnimi sistemi, to pomeni, da lahko izvajalca vpraša po konkretnih elementih: kako se ocenjujejo tveganja pred začetkom projekta, kako se vodi dostop do gesel in produkcijskih okolij, kako se obravnava incident, če do njega pride, in kako se dokumentacija ter dostopi predajo naročniku ob zaključku projekta ali menjavi izvajalca.

Znotraj Epixa in njegove specialistične partnerske mreže lahko za varnostno zahtevne projekte sestavimo ekipo s kompetencami na več področjih varnosti:

Obseg, ki ga posamezen projekt dejansko potrebuje, se določi glede na to, ali gre za javni sektor, regulirano panogo ali interno rešitev brez posebnih zahtev po skladnosti. Ni nujno, da vsak projekt zahteva enak nabor varnostnih kompetenc – pomembno je, da se ta obseg opredeli na začetku, ne šele takrat, ko pride do vprašanja ali incidenta.

• varnostna arhitektura in utrjevanje infrastrukture
• penetracijsko testiranje in vulnerability management
• upravljanje identitet in dostopov (IAM)
• odziv na incidente in digitalna forenzika
• cloud security in DevSecOps
• skladnost z GDPR in zahtevami reguliranih sistemov

Kako preveriti, da izvajalec resnično izpolnjuje zahteve#

Certifikat ali navedba standarda sama po sebi ne zadošča – naročnik mora vedeti, kaj to pomeni v praksi za njegov projekt. Smiselno je, da pred podpisom pogodbe zahteva konkretne odgovore o tem, kako izvajalec obravnava dostope, gesla, izvorno kodo in podatke, ter kako se te prakse razlikujejo med razvojnim, testnim in produkcijskim okoljem.

Vprašanja, ki jih je smiselno postaviti izvajalcu pred podpisom pogodbe:

Odgovori na ta vprašanja povedo več o dejanski varnostni praksi izvajalca kot sam naziv standarda. Pri Epixu in njegovi partnerski mreži so izvorna koda in podatki last naročnika, dokumentacija, dostopi in gesla pa so del primopredaje ob zaključku projekta ali posameznega sklopa.

Smiselno je tudi preveriti, kako izvajalec obravnava prevzem obstoječega ali nedokončanega sistema. Pri projektih, kjer naročnik že ima delujoč ERP, CRM ali dokumenten sistem, je namreč pogosto potrebna analiza obstoječe izvorne kode, arhitekture, infrastrukture in podatkov, preden se lahko načrtuje nadaljnji razvoj ali integracija novih funkcionalnosti.

• Kdo znotraj ekipe ima dostop do produkcijskih podatkov in kako se ta dostop dodeljuje ter odvzema?
• Kako se obravnavajo gesla in dostopi ob zaključku projekta ali menjavi člana ekipe?
• Ali se v testnem okolju uporabljajo pravi osebni podatki naročnika?
• Kako izvajalec dokumentira spremembe, preden gredo v produkcijo?
• Kdo je lastnik izvorne kode in podatkov po zaključku projekta?
• Kako je organizirana podpora po uvedbi in kakšni so razredi obravnave napak?

Ločevanje okolij in obravnava sprememb#

Ločevanje razvojnega, testnega in produkcijskega okolja je eden temeljnih elementov sistematične varnostne prakse. V praksi to pomeni, da se sprememba najprej razvije in preizkusi v okolju, ki je ločeno od podatkov in delovanja, ki jih naročnik uporablja vsak dan, šele nato pa se objavi v produkcijo.

Preden gre sprememba v produkcijo, jo je smiselno preveriti skozi testne scenarije, ročno in avtomatizirano testiranje ter po potrebi prevzemno testiranje po vnaprej dogovorjenih merilih. Pri zahtevnejših projektih je mogoče vključiti tudi neodvisen QA, ločen od razvojne ekipe, kar zmanjša tveganje, da bi napako spregledala ista oseba, ki jo je povzročila.

Za naročnika to pomeni, da ni odvisen samo od zaupanja v posameznega razvijalca, temveč od procesa, ki napake ujame, preden vplivajo na delovanje sistema. To je še posebej pomembno pri projektih, ki povezujejo več oddelkov, saj napaka v enem delu sistema lahko vpliva na poročanje, proizvodnjo ali delo kadrovske službe hkrati.

Odgovornost, lastništvo podatkov in primopredaja#

Vprašanje varnosti je tesno povezano z vprašanjem lastništva. Izvorna koda in podatki so last naročnika, dokumentacija, dostopi in gesla pa so del primopredaje. To pomeni, da naročnik ob zaključku projekta ali ob menjavi izvajalca ni odvisen od dobre volje prejšnjega izvajalca, temveč ima do teh elementov dogovorjen dostop.

Za direktorja ali vodjo IT je to pomembno predvsem zato, ker se izvajalci sčasoma menjajo, projekti pa ostajajo v uporabi več let. Jasno dogovorjena primopredaja dokumentacije in dostopov zmanjša tveganje, da bi bila naslednja faza razvoja ali menjava izvajalca vezana na posameznika, ki je projekt izvajal prvotno.

Projekt je mogoče prevzeti v celoti ali kot posamezen sklop, prav tako je mogoče prevzeti obstoječ ali nedokončan sistem po pregledu izvorne kode, arhitekture, infrastrukture in podatkov. Pri obeh scenarijih je dokumentacija o dostopih in podatkih temelj, na katerem naslednji izvajalec lahko dejansko oceni stanje, namesto da začenja pregled iz nič.

Podpora po uvedbi in obravnava napak#

Varnost projekta se ne konča z uvedbo v produkcijo. Po uvedbi je mogoče prevzeti nadzor delovanja, odpravo napak, tehnične in varnostne posodobitve ter nadaljnji razvoj, kar pomeni, da sistem ostaja vzdrževan tudi po tem, ko je prvotni razvoj zaključen.

Napake in zahteve se pri tem razvrščajo po razredih, kar naročniku pove, kako je obravnava posameznega primera prednostno urejena:

Konkretni odzivni časi za posamezen razred se dogovorijo v pogodbi o podpori in se razlikujejo glede na kritičnost sistema za naročnika. Za naročnika je pomembno, da so ti razredi opredeljeni vnaprej, ne šele takrat, ko pride do izpada, saj se v tistem trenutku že šteje vsaka ura.

• Razred 1 – izpad: sistem ali ključni del ne deluje, obravnava ima najvišjo prednost
• Razred 2 – motnja: sistem deluje, posamezna funkcija pa ne, obravnava po dogovorjeni prednosti
• Razred 3 – napaka: manjša napaka brez vpliva na poslovanje, uvrsti se v naslednjo objavo
• Razred 4 – zahteva: sprememba ali nadgradnja, obseg se oceni in termin uskladi

Kdaj je varnostna raven izvajalca še posebej pomembna#

Raven varnostne prakse izvajalca postane še posebej pomembna pri projektih v javnem sektorju in reguliranih panogah, kjer so zahteve po dokumentaciji, sledljivosti in skladnosti višje kot pri internih rešitvah brez posebnih regulatornih zahtev.

Panoge, kjer je izkušena delivery struktura in preverjena varnostna praksa še posebej pomembna:

Za projekte v teh panogah je poleg razvoja pogosto potrebna tudi dokumentacija, izobraževanje uporabnikov in vzpostavitev SLA za nadaljnjo podporo. Pri javnem sektorju to na primer vključuje informacijske sisteme, portale, interaktivne rešitve in dokumentacijo, ki mora ustrezati zahtevam naročnika skozi celoten čas uporabe, ne le ob uvedbi.

Za naročnika iz teh panog je smiselno, da varnostno raven izvajalca preveri pred podpisom pogodbe, ne šele med izvedbo. Vprašanja o dostopih, ločevanju okolij, primopredaji in obravnavi incidentov so pri teh projektih enako pomembna kot funkcionalne zahteve rešitve same.

• javni sektor
• bančništvo in fintech
• zavarovalništvo
• zdravstvo
• energetika in kritična infrastruktura
• proizvodnja in logistika

Kaj to pomeni za zaposlene naročnika#

Varnostna praksa izvajalca ne vpliva samo na sistem, temveč tudi na zaposlene, ki ta sistem uporabljajo. Jasno opredeljeni dostopi pomenijo, da ima vsak zaposleni dostop le do tistih podatkov in funkcij, ki jih dejansko potrebuje za svoje delo, kar zmanjša tveganje nenamerne izpostavitve podatkov.

Kadar izvajalec pri uvedbi novega sistema predvidi tudi dokumentacijo in izobraževanje, se zaposleni lažje prilagodijo spremembi, hkrati pa razumejo, katere podatke smejo obdelovati in kako. To je še posebej pomembno pri projektih, ki povezujejo več oddelkov, kjer se vloge in dostopi med sabo razlikujejo.

Za vodjo kadrovske službe ali vodjo posameznega oddelka to pomeni, da uvedba novega sistema ni le tehnično vprašanje, temveč tudi vprašanje, kako se spremeni vsakodnevno delo zaposlenih in kdo je odgovoren za usposabljanje ter podporo v obdobju po uvedbi.

Kako izbrati izvajalca za projekt z visokimi varnostnimi zahtevami#

Pri izbiri izvajalca za projekt, ki zadeva več sistemov in oddelkov, je smiselno preveriti, ali ima izvajalec izkušnje s podobnimi projekti, kako organizira projektno ekipo in kako je opredeljena odgovornost za posamezen del izvedbe.

Pri večjih projektih je koristno, da izvajalec določi projektnega vodjo, odgovornosti ekip, roke ter način komunikacije in poročanja. To naročniku omogoča, da med izvedbo spremlja napredek in po potrebi prilagodi obseg, ne da bi moral čakati na zaključek celotnega projekta, da bi ugotovil, kje je prišlo do odstopanja.

Cena projekta je odvisna od obsega funkcionalnosti, števila sistemov, ki jih je treba povezati, zahtev glede varnosti in skladnosti ter obsega podpore po uvedbi. Namesto splošne cenovne ocene je smiselno začeti s krajšo analizo, ki obseg razčleni na sklope, tako da je vsak sklop ocenljiv in izvedljiv ločeno.