U upitniku za izbor dobavljača obično stoji red „ISO 27001 sertifikat: da / ne“. Naš odgovor je ne. Conimex IT je tim od 5 ljudi iz Beograda i nikada nismo bili sertifikovani po ISO 27001, međunarodnom standardu za upravljanje bezbednošću informacija. Ono što nudimo je kratak spisak navika koje možete da proverite jednu po jednu: kod i serveri vode se na ime klijenta, svako ima svoj nalog, stvarni podaci nikada ne dolaze na test server, rezervne kopije pravimo svakog dana i namerno iz njih vraćamo podatke, a kada otkrijemo problem, klijent o njemu čuje od mene pre nego što počne popravka.
U nastavku opisujemo svaku od tih navika zajedno sa načinom da je proverite, kažemo otvoreno gde bi nas sertifikat pobedio i dajemo pitanja koja možete da postavite svakom malom dobavljaču, pa i nama.
Zašto mali dobavljač često nema ISO 27001 sertifikat
Najjednostavniji razlog je to što nas klijenti nikada nisu pitali za njega. Sertifikat se obično pojavi u nabavci, kroz formalne tendere ili obrasce za dobavljače, najčešće pre nego što je iko pogledao kako dobavljač zapravo radi.
Sertifikacija nije papir koji se jednom pribavi. Firma prvo izgradi i dokumentuje sistem upravljanja bezbednošću informacija, odnosno skup pravila, uloga i zapisa o tome kako čuva informacije, a zatim prolazi audit u dve faze, proveru koju sprovodi nezavisno sertifikaciono telo. Za malu firmu to traje oko 6 meseci. Posle toga sledi nadzorni audit svake godine i resertifikacija na svake 3 godine. Najveći deo cene ne plaća se novcem nego vremenom osnivača, a do sada to od nas nije tražio nijedan klijent.
Trenutno važeća verzija standarda je ISO/IEC 27001:2022. Njen Aneks A sadrži 93 kontrole, odnosno konkretne mere zaštite, podeljene u 4 grupe: organizacione, one koje se odnose na ljude, fizičke i tehnološke. Izdanje standarda 27001 iz 2026. godine ne postoji. Ove godine promenio se jedan drugi standard, ISO 9001:2026 za upravljanje kvalitetom, a o njemu smo pisali u tekstu o tome šta donose izmene standarda ISO 9001:2026.
Šta NIS2 zaista traži od kupca
NIS2 je direktiva Evropske unije o sajber bezbednosti koja se odnosi na takozvane ključne i važne subjekte, organizacije čiji rad direktiva smatra posebno značajnim za privredu i društvo. Član 21 nabraja mere koje ti subjekti moraju da sprovedu, a među njima je bezbednost lanca snabdevanja, odnosno bezbednost odnosa sa direktnim dobavljačima i pružaocima usluga.
Član 21, stav 3 objašnjava šta to znači u praksi. Kupac treba da uzme u obzir slabe tačke specifične za svakog dobavljača, ukupan kvalitet njegovih proizvoda i njegove prakse sajber bezbednosti, „uključujući i njihove procedure bezbednog razvoja“.
U tom tekstu ISO 27001 se ne pominje. Direktiva traži da pogledate šta dobavljač radi. Sertifikat je jedan način da dobavljač to pokaže, a opis prakse koji možete sami da proverite je drugi.
Kako čuvamo podatke klijenata
Sledi šest navika kojih se držimo na projektima. Uz svaku navodimo kako možete da je proverite kod nas ili kod bilo kog drugog dobavljača.
Kod, serveri i nalozi vode se na ime klijenta
Kad god možemo, sve držimo na strani klijenta: repozitorijum koda (mesto na kome se čuva kod sa celom istorijom izmena), hosting nalog, domen i naloge u prodavnicama aplikacija. Kada saradnja prestane, klijent samo promeni pristupe i ne mora ništa da traži nazad. Neki klijenti još nemaju tehničku postavku da te naloge vode sami, pa ih za njih držimo u okviru naloga naše firme dok ne budu spremni da ih preuzmu.
Kako da proverite: Za svaki nalog pitajte na čije se ime vodi. Zatim se zapitajte da li biste sutra mogli da isključite dobavljača a da ga ništa ne pitate.
Svako ima svoj nalog
Niko u timu ne deli prijavu za kod ili servere. Većina naloga zahteva 2FA, dvofaktorsku potvrdu kod koje se pored lozinke unosi i jednokratna šifra sa telefona, pa ukradena lozinka sama nije dovoljna za ulazak. Lozinke i pristupne ključeve, odnosno tajne nizove znakova kojima se programi prijavljuju na servise, čuvamo u aplikaciji Apple Passwords, a ne u porukama u četu.
Kako da proverite: Pogledajte spisak korisnika u repozitorijumu i na hostingu. Svaka osoba treba da ima svoje ime, a zajednički nalog tipa „dev“ ne bi smeo da postoji.
Stvarni podaci ostaju u produkciji
Produkcija je sistem koji koriste Vaši stvarni korisnici. Test okruženja uvek punimo izmišljenim podacima, a stvarni zapisi o kupcima nikada se ne kopiraju na laptop programera ni na test server. Diskovi na svim radnim računarima su šifrovani. Svaki član tima i svaki spoljni saradnik potpisuje ugovor o poverljivosti.
Kako da proverite: Pitajte odakle su podaci na test serveru. Loš odgovor glasi: „Kopirali smo produkciju i promenili neka imena.“
Rezervne kopije svakog dana, vraćanje namerno
Rezervnu kopiju baze podataka pravimo jednom dnevno. Na nekoliko projekata, ali ne na svim, jednom mesečno namerno vratimo podatke iz rezervne kopije da bismo potvrdili da vraćanje zaista radi. Moje mišljenje je jednostavno: rezervna kopija iz koje nikada niste vratili podatke nije rezervna kopija nego nada.
Kako da proverite: Pitajte dobavljača kada je poslednji put vratio podatke iz rezervne kopije i koliko je to trajalo.
Svaku izmenu čita još jedan programer
Cilj nam je da svaka izmena prođe nezavisan pregled koda (code review), u kome drugi programer pročita izmenu pre nego što ona uđe u projekat. Tako u projekat ne ulazi kod koji je video samo njegov autor. Detaljnije smo opisali kako organizujemo pregled koda u posebnom tekstu. Tipičan nalaz na pregledu koda je izostavljena provera ovlašćenja, mesto na kome aplikacija ne pita da li korisnik sme da uradi ono što pokušava.
Trudimo se i da programere ne uvodimo u projekat i ne povlačimo iz njega bez preke potrebe. Zašto nam je to važno, objasnili smo u tekstu o tome šta se dešava kada programer ode usred projekta.
Kako da proverite: Tražite od dobavljača da Vam pokaže jednu izmenu koja je već spojena sa glavnim kodom, zajedno sa komentarima sa pregleda koda.
O problemu prvo čujete Vi
Kada pronađemo bezbednosni problem, klijentu to lično kažem odmah, pa tek onda počinjemo popravku. Ne posle zakrpe i ne u mesečnom izveštaju. Smatram da ne možete sami da odlučite o svom riziku ako dobavljač to tiho odluči umesto Vas. Evropska unija je isti refleks upisala u zakon za proizvođače: po propisu Cyber Resilience Act (CRA), proizvođač mora nadležnim organima da pošalje rano upozorenje u roku od 24 časa kada sazna da napadači već aktivno koriste neku ranjivost, odnosno bezbednosni propust u njegovom proizvodu. Više o tome pisali smo u tekstu o obavezama prijavljivanja po Cyber Resilience Act.
Kako da proverite: Pitajte dobavljača koji je poslednji bezbednosni problem pronašao i kada je klijent za njega saznao. Ako je odgovor „nikada nismo imali problem“, nastavite da pitate.
Admin rute koje smo zatekli u tuđem kodu
Jedan projekat došao nam je kao gotova aplikacija koja je već radila, preuzeta od drugog tima. Takav projekat se u struci zove brownfield. U kodu smo našli admin rute, odnosno adrese iza administratorskog panela, bez ikakve zaštite. Svako ko zna ili pogodi adresu mogao je da im pristupi, što je otvaralo vrata krađi podataka i stvarnoj finansijskoj šteti. Srećom, ništa nije ukradeno.
Popravku smo počeli onog trenutka kada smo propust videli. Zatvaranje ruta bilo je lakši deo posla. Važnije je to što smo promenili automatske testove, programe koji posle svake izmene sami proveravaju aplikaciju, tako da sada proveravaju baš ovaj slučaj. Nezaštićena admin ruta sada obara build, odnosno automatsko sastavljanje nove verzije aplikacije, pre nego što ta verzija stigne do produkcije.
Po mom iskustvu, bezbednost dobavljača ne vidi se u čistom dosijeu. Vidi se u onome što dobavljač uradi onog dana kada pronađe rupu.
Gde bi nas sertifikat pobedio
Sertifikat ne čini softver bezbednim, ali nameće redovnost, a redovnost je slaba tačka malog tima. Kod nas se to vidi na tri mesta:
- Testovi proboja. Test proboja je provera u kojoj spoljni tim namerno pokušava da provali u aplikaciju. Imali smo ga na 2 projekta, od kojih je jedan rađen za jednu banku. Redovno sprovođenje takvih testova na svakom projektu teško je izvodljivo za tim naše veličine.
- Uklanjanje pristupa. Kada se projekat završi, pristupe, u zavisnosti od klijenta, uklanjam ja ili ih uklanja sam klijent. Naše pravilo je najviše 2 nedelje. Za bivšeg dobavljača to je dugo vreme da drži ključ, pa ako Vam je važan kraći rok, upišite ga u ugovor.
- Ažuriranje zavisnosti. Zavisnosti su biblioteke i paketi na koje se aplikacija oslanja. Kritične bezbednosne ispravke primenjujemo odmah, a sve ostalo redovno ažuriramo jednom u 6 meseci. Taj redovni ciklus je donja granica, a ne cilj. Upravo tu stavku bismo najradije pooštrili.
Naša preporuka je jednostavna. Ako pravila Vaše nabavke traže ISO 27001 sertifikat i tačka, mi nismo Vaš dobavljač i ovaj tekst to neće promeniti. Ako pravila traže da procenite stvarnu praksu dobavljača, a upravo to traži NIS2, spisak iznad možete da proverite za jedno popodne.
Pitanja za svakog dobavljača bez sertifikata
Ovih 9 pitanja možete da postavite bilo kom malom dobavljaču, pa i nama:
- Na čije ime se vode repozitorijum koda, hosting i domen i može li se pristup dobavljača ukinuti bez njegove pomoći?
- Da li svaka osoba ima svoj nalog i koji nalozi zahtevaju 2FA?
- Gde se čuvaju lozinke i pristupni ključevi?
- Da li stvarni podaci ikada napuštaju produkciju?
- Kada su podaci poslednji put vraćeni iz rezervne kopije i na kom projektu?
- Ko pregleda kod pre nego što se izmena spoji sa glavnim kodom?
- Koliko brzo se uklanja pristup kada neko napusti projekat?
- Kada se pronađe bezbednosni problem, ko obaveštava klijenta i koliko brzo?
- Da li je neki projekat prošao test proboja i šta je taj test pokazao?
Naši odgovori na sva pitanja nalaze se u ovom tekstu. Ako dobavljač na većinu ne može da odgovori u kratkom razgovoru, to će Vam reći više nego što bi rekao sertifikat.
Pre nego što potpišete ugovor
Conimex IT razvija softver po meri, veb i mobilne aplikacije u tehnologijama Laravel, React i React Native, za klijente u Evropskoj uniji i SAD. Rado ćemo Vašem timu za bezbednost ili nabavku pre potpisivanja pokazati kako bilo koja od ovih navika izgleda u praksi. Kako izgledaju naši dosadašnji projekti, možete da vidite u primerima naših projekata.
Ako Vam predstoji provera dobavljača, pišite nam na [email protected] i zajedno ćemo proći kroz Vaš upitnik.