Kas yra IT saugumo auditas įmonėje?

Aiškinantis, kas yra IT saugumo auditas įmonėje, reikia atskirti organizacinę dalį, kurioje vertinama atsakomybė, prieigos, atsarginės kopijos ir veiksmai įvykus incidentui, nuo techninės dalies, kurioje tikrinami sistemų nustatymai, pažeidžiamumai ir kodas. Kaina priklauso nuo tikrinamų sistemų apimties ir darbo išsamumo: mūsų automatizuota saugumo patikra kainuoja 89–890 € priklausomai nuo apimties, o eksperto rankiniu būdu atliekamas auditas siūlomas nuo 3 500 €. Pirmiausia išsiaiškinkite, kurios dalies Jums reikia ir kokių įrodymų tikitės, nes svetainės patikrinimas, įmonės saugumo valdymo vertinimas ir sertifikavimas yra skirtingi užsakymai, kurių rezultatai skiriasi.

Įsivaizduokite, kad klientas prieš pasirašant sutartį atsiunčia reikalavimą atlikti saugumo auditą, o priede pateikiami klausimai ir apie darbuotojų prieigos teises, ir apie techninį sistemos patikrinimą. Vien persiųsti reikalavimą programuotojui nepakanka: turite sutarti, ar klientas tikisi svetainės ataskaitos, dokumentuotų įmonės procesų, ar nepriklausomos įstaigos sertifikato ir kokias sistemas ar veiklos dalį šis patvirtinimas turi apimti. Rekomenduojame išsaugoti tikslią prašymo formuluotę ir išsiaiškinti jo tikslą prieš pasirenkant vykdytoją ir priimant kainos sąmatą.

Kas yra IT saugumo auditas: dvi skirtingos užduotys

Abi dalys atsako į skirtingus klausimus. Organizacinėje dalyje klausiama, kaip įmonė priima ir įgyvendina saugumo sprendimus, o techninėje – kaip veikia konkreti sistema ir ar galima apeiti jos apsaugą. Todėl ta pati tema abiejose dalyse atrodo visiškai skirtingai: vertindamas prieigos teisių suteikimo tvarką auditorius prašo parodyti, kas patvirtina darbuotojo teises ir kaip jos panaikinamos, o testuodamas programą jis įprasta paskyra mėgina atlikti tai, kas šiai paskyrai neleidžiama. Abu rezultatus verta nagrinėti kartu, tačiau vienas kito jie nepakeičia: tinkamai parengta prieigos politika neįrodo, kad programa jos laikosi, o saugi programa neįrodo, kad kas nors uždarė išėjusio darbuotojo paskyrą.

Todėl vien žodis „auditas“ užsakyme pasako mažai. Rekomenduojame pridėti du dalykus: kriterijus, pagal kuriuos bus vertinamas darbas, ir įrodymus, kurių tikitės ataskaitoje. Vertinant pažeidžiamumus tai yra nustatyti trūkumai ir jų prioritetai, atliekant įsilaužimo testavimą – konkretus apsaugos mechanizmas ar veiksmų apribojimas, kurį bus mėginama apeiti, o atliekant organizacinį atitikties auditą – reikalavimų rinkinys, su kuriuo bus lyginami dokumentai ir kasdienė praktika.

Jei pasirenkate tik pradinį trūkumų vertinimą, taip ir vadinkite jo rezultatą, o ne sertifikavimu, ir jau formuluodami užduotį sutarkite, kas turės perskaityti šį dokumentą ir kokį sprendimą priimti. Sertifikavimo atveju svarbu žinoti, kas išduos patvirtinimą: pati ISO įmonių nesertifikuoja, o sertifikavimą ji aiškina kaip nepriklausomos įstaigos rašytinį patvirtinimą, kad laikomasi nustatytų reikalavimų. Tame pačiame paaiškinime ISO nurodo, kad akreditacija patvirtina sertifikavimo įstaigos kompetenciją, tačiau nėra privaloma; todėl teiginys, kad sertifikuoti gali tik akredituota įstaiga, būtų netikslus. Jei Jūsų klientas reikalauja akredituoto sertifikavimo, išsiaiškinkite šią sąlygą prieš sudarydami sutartį ir patikrinkite pasirinktos įstaigos akreditaciją, kad vėliau neliktumėte su patvirtinimu, kurio klientas nesutiko priimti.

Mūsų pasiūlymas yra techninis žiniatinklio sistemų patikrinimas, o organizacinėje dalyje galime padėti parengti saugumo politikas, tačiau įmonių nesertifikuojame ir informacijos saugumo valdymo sistemos (ISVS) už Jus nevaldome; šią ribą verta įrašyti ir į užsakymą. Jei užduotis apima ir svetainės patikrinimą, ir įmonės valdymo vertinimą, sutarkite, kas rengia techninius įrodymus, kas juos lygina su pasirinktais reikalavimais ir kas atsako už galutinį vertinimą, nes kitaip iš mūsų tikėsitės valdymo proceso vertinimo, o iš organizacinio auditoriaus galite tikėtis testo, kurio neužsakėte. Organizacinę dalį paprastai atlieka informacijos saugumo valdymo konsultantas arba ISO/IEC 27001 auditorius, o sertifikatą išduoda sertifikavimo įstaiga.

Organizacinė dalis: dokumentus reikia palyginti su praktika

Popierius viską iškenčia, todėl organizacinėje dalyje verta patikrinti, ar saugumo politikoje numatytiems veiksmams paskirti atsakingi asmenys, skirti reikiami ištekliai ir yra vykdymo įrodymų, o rizikos vertinime įvardytoms problemoms numatyti veiksmai; ENISA vadovas mažosioms ir vidutinėms įmonėms apima vadovybės atsakomybę, darbuotojų įtraukimą ir mokymą, saugumo politikas, tiekėjų valdymą, prieigos apsaugą ir kibernetinių incidentų valdymo planą. Pokalbius su vadovybe ir darbuotojais papildykite dokumentų ir konkrečių darbo pavyzdžių patikrinimu, kad vertinant būtų galima atskirti numatytą tvarką nuo jos vykdymo ir įvardyti įrodymus, kurių auditoriui nepavyko gauti ir kuriuos dar reikia parengti.

Vertindamas prieigą geras auditorius žiūri ne tik į tai, kaip suteikiamos paskyros, bet ir kaip jos uždaromos, ar naudojama kelių veiksnių autentifikacija (MFA) ir kokias teises turi tiekėjai, todėl į tikrinamus pavyzdžius verta įtraukti darbuotojo išėjimą arba tiekėjo pakeitimą: būtent tokiais atvejais paskyros neretai pamirštamos. Panašiai yra ir su atsarginėmis kopijomis, nes atsakymas „kopijas darome“ pasako mažai. Kopija, iš kurios niekas niekada nebandė atkurti duomenų, įvykus incidentui gali pasirodyti esanti nepilna, ir tai paaiškėja tada, kai svetainė jau neveikia. Sistemų ir įrenginių apskaitai reikia atsakingų asmenų, įvykių žurnalams – peržiūros tvarkos, o kibernetinių incidentų valdymo planui – konkrečiai įvardyto žmogaus, kuris priima sprendimus ir bendrauja su susijusiais asmenimis; kitaip planas lieka dokumentu, kurio įvykus incidentui niekas nevykdo.

Kriterijams galima naudoti ISO/IEC 27001:2022, kuriame nustatyti reikalavimai informacijos saugumo valdymo sistemai; žodis „sistema“ čia reiškia valdymą, o ne vien tikrinamą programą; BSI standarto paaiškinime įvardytos 93 informacijos saugumo kontrolės priemonės ir keturios sritys: organizacinė, žmonių, fizinė ir technologinė. Sutarkite, kokius reikalavimus auditas vertins ir kokiais įrodymais remsis, nes nuoroda į standartą kainos sąmatoje dar nepasako, ar užsakote valdymo sistemos vertinimą, ar tik techninį patikrinimą, kurio rezultatai vėliau bus naudojami platesniame audite; šį pasirinkimą užrašykite prieš pradedant darbą.

Kitas pagrindas yra CIS Controls v8.1 su 18 kontrolės priemonių grupių, apimančių sritis nuo įmonės išteklių apskaitos iki įsilaužimo testavimo ir iš viso turinčių 153 apsaugos priemones. CIS Implementation Group 1 (IG1) CIS apibūdina kaip pagrindinę kibernetinę higieną su 56 apsaugos priemonėmis, todėl užsakyme patikslinkite ir pasirinktą grupę, o ne vien priemonių rinkinio pavadinimą. Prašykite ataskaitoje kiekvieną vertintą reikalavimą susieti su gautu įrodymu ir nustatytu trūkumu, kad po taisymų būtų galima patikrinti tą pačią sąlygą, o ne lyginti du bendro pobūdžio vertinimus.

Kada įstatymas reikalauja IT saugumo audito

Lietuvos kibernetinio saugumo įstatymo 14 straipsnio 8 dalis įpareigoja kibernetinio saugumo subjektus ne rečiau kaip kartą per trejus metus atlikti nepriklausomą kibernetinio saugumo auditą pagal Nacionalinio kibernetinio saugumo centro prie Krašto apsaugos ministerijos (NKSC) patvirtintą metodiką. Ji patvirtinta NKSC direktoriaus 2026 m. vasario 24 d. įsakymu Nr. 1-25 ir įsigaliojo 2026 m. vasario 25 d. Auditorius turi būti sertifikuotas visuotinai pripažintos tarptautinės organizacijos kaip informacinių sistemų saugumo atitikties auditorius, NKSC vadovo nustatyta tvarka išklausęs mokymus ir išlaikęs kvalifikacinį žinių bei praktinių įgūdžių patikrinimo egzaminą, taip pat atitikti metodikos nepriklausomumo, nešališkumo ir nepriekaištingos reputacijos reikalavimus. Jis negali vertinti tinklų ir informacinių sistemų, kurias valdo ar tvarko jo darbdavys, saugos. Priežiūrą vykdo NKSC: esminių subjektų patikrinimai gali būti planiniai ar neplaniniai, pradėti centro iniciatyva, gavus skundą ar remiantis kitais šaltiniais, o svarbių subjektų – tik neplaniniai, gavus informacijos apie įtariamą įstatymo pažeidimą. Jei per patikrinimą rizikos analizė rodo aukštą rizikos lygį, NKSC gali nurodyti subjektui savo lėšomis atlikti nepriklausomą tikslinį kibernetinio saugumo auditą ir pateikti jo rezultatus. Pačiam patikrinimui NKSC gali savo lėšomis pasitelkti kvalifikuotus nepriklausomus specialistus ir audito įmones; audito kainos įstatymas nenustato. 14 straipsnis netaikomas, kai ES teisės aktai subjektui nustato bent lygiaverčio poveikio kibernetinio saugumo rizikos valdymo reikalavimus; žvalgybos institucijoms įstatymas netaikomas, išskyrus VII skyrių.

O Kibernetinio saugumo reikalavimų aprašas, patvirtintas Vyriausybės 2018 m. rugpjūčio 13 d. nutarimu Nr. 818 (2024 m. lapkričio 6 d. nutarimo Nr. 945 redakcija), atskiria kasmetinį atitikties vertinimą nuo nepriklausomo audito. Subjekto vadovo nustatyta tvarka turi numatyti atitikties įstatymui, aprašui ir subjekto kibernetinio saugumo politikai vertinimą ne rečiau kaip kartą per metus, o nepriklausomą auditą pagal įstatymo 14 straipsnio 8 dalį – ne rečiau kaip kartą per trejus metus. Kasmetinį atitikties vertinimą atlieka pats subjektas; jo ataskaitą ir, jei nustatyta neatitikčių, jų šalinimo planą su atsakingais vykdytojais, ištekliais bei terminais tvirtina vadovas arba jo įgaliotas asmuo. Esminiai subjektai papildomai bent kartą per metus užpildo NKSC klausimyną Kibernetinio saugumo informacinėje sistemoje (KSIS); svarbiems subjektams NKSC rekomenduoja jį pildyti. NKSC atliekant patikrinimą, audito dokumentų, atitikties vertinimo ataskaitos, neatitikčių šalinimo plano, rizikos vertinimo ataskaitos ir rizikos valdymo plano kopijas reikia pateikti į KSIS per penkias darbo dienas nuo centro prašymo gavimo. 45.8 punktas reikalauja ne rečiau kaip kas šešis mėnesius atlikti visą tinklų ir informacinių sistemų pažeidžiamumų skenavimą; tai nėra reikalavimas atlikti įsilaužimo testavimą. Įstatymo 14 straipsnio 2 dalis numato, kad Vyriausybės nustatomas reikalavimų įgyvendinimo laikotarpis negali būti trumpesnis nei 12 mėnesių nuo subjekto įregistravimo KSIS. Pagal aprašą reikalavimus reikia įgyvendinti per 12 mėnesių nuo šios datos, o 26, 31, 47, 57, 60, 64 ir 69 punktuose išvardytus techninius reikalavimus – per 24 mėnesius. Krašto apsaugos ministerija nurodo, kad specialiesiems subjektams ir patikimumo užtikrinimo paslaugų teikėjams nuo įtraukimo į registrą taikomos tik Komisijos įgyvendinimo reglamento (ES) 2024/2690 kibernetinio saugumo rizikos valdymo priemonės. Todėl gavę pasiūlymą atlikti „privalomą auditą“ prašykite įvardyti konkrečią pareigą ir Jūsų statusą: ar esate esminis, svarbus, specialusis subjektas ar patikimumo užtikrinimo paslaugų teikėjas. Patikslinkite, ar siūlomas kasmetinis atitikties vertinimas, nepriklausomas auditas bent kas trejus metus, NKSC nurodytas tikslinis auditas subjekto lėšomis, kai per patikrinimą nustatoma aukšta rizika, ar bent kas šešis mėnesius atliekamas pažeidžiamumų skenavimas.

Techninė dalis: nuo viešųjų adresų iki kodo

Techninėje užduotyje įvardykite viešuosius adresus, DNS įrašus, atviras paslaugas ir TLS nustatymus, taip pat serverio ar debesijos aplinkos konfigūraciją, žiniatinklio programas ir pirminį kodą, kuriuos leidžiate tikrinti, o prie kiekvienos dalies nurodykite, ar vykdytojas gaus prieigą prie nustatymų, ar vertins tik tai, kas matoma iš išorės, nes tai skirtingos užduotys. NIST saugumo testavimo metodų klasifikacijoje dokumentų, žurnalų ir konfigūracijos peržiūra atskiriama nuo tikrinimo objektų nustatymo ir analizės bei pažeidžiamumų patvirtinimo; šį skirstymą galite naudoti tiksliau aprašydami pasirinktus metodus ir laukiamą rezultatą kainos sąmatoje.

Žiniatinklio programoms OWASP Top 10:2025 suteikia bendrą kalbą: dešimt rizikos kategorijų, kurių pirmosios dvi yra prieigos kontrolės trūkumai ir nesaugi konfigūracija. Pats sąrašas nieko nepatikrina, todėl geras auditorius kiekvieną kategoriją pavers klausimu apie Jūsų programą: prieigos kontrolės atveju tai reiškia bandymą atlikti vienam vaidmeniui skirtus veiksmus naudojant kito vaidmens paskyrą, o nesaugaus projektavimo kategorijos atveju – verslo proceso, kurio taisykles kas nors galėtų apeiti, pasirinkimą. Nuorodą į OWASP papildykite patikrinimo apimtimi, kad abiem šalims būtų aišku, kurios funkcijos ir naudotojų vaidmenys iš tiesų įeina į šį darbą.

El. pašto dalyje numatykite SPF, DKIM ir DMARC nustatymų vertinimą, susiedami užduotį su sistemomis, iš kurių įmonė siunčia laiškus: Google reikalavimai siuntėjams nuo 2024 m. vasario 1 d. numato, kad kiekvienas siuntėjas, siunčiantis į Gmail paskyras, nustato SPF arba DKIM, o siunčiantys daugiau kaip 5 000 laiškų per dieną nustato ir SPF, ir DKIM, ir DMARC. DMARC politika gali būti „none“, tačiau tiesioginių siuntimų atveju lauke From nurodytas domenas turi būti suderintas su SPF arba DKIM domenu; todėl užduotyje prašykite vertinti ir nustatymus, ir Jūsų naudojamus siuntimo kelius, neapsiribojant vien patikrinimu, ar domeno įrašai yra.

Mūsų audituose dažniausiai nustatomi neįdiegti PHP, turinio valdymo sistemos branduolio ir programinės įrangos karkasų atnaujinimai. Todėl į techninę užduotį rekomenduojame įtraukti naudojamų versijų, įskiepių ir priklausomybių apžvalgą, o aprašant nustatytą trūkumą prašyti įvardyti konkretų komponentą ir būtiną veiksmą, kad programuotojas gautų įvykdomą užduotį, o ne bendrą pastabą apie pasenusią svetainę. Jei Jums svarbiausia, ką naudotojai gali daryti sistemoje, versijų apžvalgos nepakanka: tuomet reikia ir prieigos kontrolės bei verslo logikos testų. Mūsų praktikoje pasitaikė kritinių klaidų, dėl kurių bet kuris naudotojas galėjo įgyti administratoriaus teises, o šias klaidas šalinant teko visiškai perrašyti sistemos branduolį; versijų apžvalga tokios klaidos nebūtų aptikusi.

Klausimas, ką naudotojas gali daryti, skiriasi nuo klausimo apie įdiegtas versijas, ir kiekvienam iš jų ataskaitoje reikia atskiro įrodymo. NIST pažeidžiamumų skenavimą apibrėžia kaip būdą nustatyti pagrindinius kompiuterius, jų savybes ir susijusius pažeidžiamumus, o mūsų automatizuotoje saugumo patikroje skenavimas yra vienas techninio darbo etapų. Įsilaužimo testavimui pagal NIST paaiškinimą būdingas tikrų atakų imitavimas, ieškant galimybių apeiti apsaugą ir dažnai pažeidžiamumų derinių, leidžiančių įgyti platesnę prieigą. Paties testavimo pasirinkimą išsamiau aptariame straipsnyje apie įsilaužimo testavimą; užsakant auditą čia svarbu nustatyti, kurių trūkumų vykdytojas tik ieškos, o kurių praktinį išnaudojimą mėgins įrodyti sutartose ribose, taip pat kokių veiksmų sąmoningai neįtrauks į darbą.

IT saugumo audito etapai: nuo užduoties iki pakartotinio patikrinimo

Pradėkite nuo rašytinio audito apimties aprašo, kuriame įvardytos tikrinamos sistemos, programos, adresai ir naudotojų vaidmenys, taip pat aiškiai nurodyta, kas pagal šį užsakymą nebus tikrinama, ir pridėkite tikslą bei darbo ribas: kokius veiksmus leidžiate, kokioje aplinkoje jie vyks, kas gali sustabdyti patikrinimą ir į ką kreiptis susidarius nenumatytai situacijai; pavyzdžiui, užsakymų sistemos atveju atskirai sutarkite, kaip tikrinti veiksmus, dėl kurių kitu atveju būtų sukurtas tikras užsakymas. Šį susitarimą turi perskaityti ir Jūsų sistemos prižiūrėtojas, kad leidžiami veiksmai, prieigos ir kontaktiniai asmenys būtų suderinti prieš pradedant techninį darbą.

Prieš pradedant darbą parenkite dokumentus ir pasirūpinkite pokalbiuose dalyvausiančiais žmonėmis tiek, kiek reikia užduočiai: organizacinei daliai – politikas, prieigos suteikimo pavyzdžius, atkūrimo iš atsarginių kopijų įrašus ir kibernetinių incidentų valdymo planą, o techninei daliai – sistemos aprašą ir suderintas prieigas, pažymėdami ir tai, ko dar neturite. Jei tikrinate kopiją, užrašykite jos skirtumus nuo kasdien naudojamos sistemos ir sutarkite, kaip juos parodyti ataskaitoje, kad skaitytojas vėliau suprastų, kuriai aplinkai taikomi gauti rezultatai ir kurie klausimai liko atviri, nes nebuvo prieinami dokumentai, prieiga ar atitinkama funkcija. Techniniam darbui sutarkite konkretų testavimo laiką ir bendravimo tvarką, o dokumentų vertinimui numatykite terminą, iki kurio Jūsų kolegos gali pateikti patikslinimus, kad rezultate būtų aiškiai atskirta tai, kas patikrinta, nuo to, kas dar nepatvirtinta.

Jei dirbdamas vykdytojas aptinka reikšmingą problemą, prašykite apie ją pranešti sutarta tvarka, kol likęs darbas tęsiamas, nelaukiant visos ataskaitos perdavimo datos. Taip pat sutarkite, kas priima sprendimą dėl tolesnio šios vietos testavimo ir kaip užrašyti gautus leidimus ar apribojimus, nes šių sprendimų reikės aiškinant, kiek pavyko patvirtinti konkretų nustatytą trūkumą.

Termine reikia numatyti laiko ir taisymams

Auditas naudojant mūsų sistemą trunka kelias dienas, o pats rankiniu būdu atliekamo audito darbas užima 1–3 savaites priklausomai nuo audito apimties; iki jo pradžios gali tekti palaukti, nes tai priklauso nuo auditoriaus užimtumo. Paslaugos puslapyje nurodytas bendras atlikimo intervalas yra 1–60 dienų, todėl šių aprašymų nelaikykite vienu garantuotu terminu ir prieš užsakydami suderinkite pradžios datą, ataskaitos perdavimą ir pakartotinį patikrinimą. Jei turite kliento ar pirkimo sąlygose nustatytą datą, suplanuokite laiko ir nustatytų trūkumų peržiūrai bei taisymui, ir Jūsų komandos atsakymams į klausimus, nes patikrinimo pabaigos data ir data, iki kurios norite pašalinti trūkumus, yra skirtingi planavimo taškai.

Į mūsų eksperto rankiniu būdu atliekamo audito pasiūlymą įtrauktas pakartotinis patikrinimas per 30 dienų po taisymų. Kad jis būtų naudingas, perduodant ataskaitą sutarkite, kas taiso kiekvieną nustatytą trūkumą, kas praneša apie darbo pabaigą ir kokius įrodymus vykdytojas tikrins pakartotinai; pačių taisymų apimtį ir apmokėjimą patikslinkite atskirai, nes audito kaina nėra susitarimas dėl visų tolesnių programavimo darbų. Taisymus galite atlikti savo komandos jėgomis, o mes vėliau juos patikrinsime, arba patikėti juos mums kaip atskirą darbą, kurį įvertinsime pagal ataskaitą. Pakartotinėje ataskaitoje prašykite atskirti pašalintą trūkumą nuo atidėto arba dar nepatikrinto ir nurodyti, kokios būsenos sistema naudota, kad Jūsų komanda ir ataskaitos gavėjas turėtų vieną aiškų atsakymą apie kiekvieną iš pradžių nustatytą trūkumą.

Ko prašyti audito ataskaitoje

Ataskaitos pradžioje prašykite vadovybei suprantamos patikrinimo tikslo, apimtų sistemų ir svarbiausių nustatytų trūkumų apžvalgos, kad sprendimą dėl darbų ir išteklių būtų galima priimti neskaitant visos techninės medžiagos, ir paprašykite toje pačioje vietoje įvardyti darbo apribojimus. Jei pirminis kodas buvo neprieinamas arba kuris nors naudotojo vaidmuo nebuvo nagrinėtas, prašykite tai pasakyti tiesiai, o ne palikti skaitytojui spėlioti, ką reiškia trumpas sistemos būklės vertinimas; tokią apžvalgą vertinkite pagal tai, ar Jūsų vadovas iš jos gali įvardyti kitą sprendimą, atsakingą asmenį ir klausimą, į kurį dar neatsakyta.

Prie kiekvieno techninio trūkumo prašykite nurodyti jo vietą sistemoje, aplinkybes, kuriomis jis aptiktas, naudotą naudotojo vaidmenį, veiksmų pakartojimo aprašą ir rezultato įrodymą, o prie organizacinės neatitikties šalia nuorodos į reikalavimą paprašykite įvardyti dokumentą ar darbo pavyzdį, kuriuo grindžiamas vertinimas. Taisymo rekomendacijoje turi būti suprantama, ką konkrečiai reikia pakeisti, todėl formuluotę „sutvarkyti prieigas“ patikslinkite iki konkrečių teisių ir funkcijos, kurią turi pakeisti Jūsų programuotojas, ir nurodykite laukiamą veikimą po taisymo, kad ataskaitą būtų galima naudoti ir užduočiai perduoti, ir vėlesniam patikrinimui, neverčiant kiekvieno naujo skaitytojo iš naujo aiškintis auditoriaus sumanymo.

Jei ataskaitoje naudojama CVSS, prašykite nurodyti ir versiją: FIRST skelbia CVSS, įskaitant 4.0 versiją, kurios pavojingumo vertinimo skalės žymenys yra „nėra“ (0,0), „žemas“ (0,1–3,9), „vidutinis“ (4,0–6,9), „aukštas“ (7,0–8,9) ir „kritinis“ (9,0–10,0); šių žodinių žymenų naudojimas yra pasirenkamas. Šalia skaičiaus prašykite pagrindimo ir paaiškinimo, susijusio su Jūsų įmonės veikla, pavyzdžiui, kokį veiksmą ar duomenų rinkinį konkretus trūkumas paveikia ir kodėl rekomenduojama jį taisyti tokia eilės tvarka, kad prioritetą būtų galima aptarti pagal aprašytas aplinkybes, o ne vien pagal skaičių.

Patirtį, įgytą taisant tokias kritines klaidas, naudojame tam, kad prašytume aiškaus pasekmių aprašymo, o ne teigtume, jog kiekvieną svetainę reikia perdaryti: ataskaitoje turi būti galima atskirti konkretų taisymą nuo problemos, kuriai išspręsti reikia persvarstyti esminį sistemos veikimą. Jei ataskaitoje numatytas platus perdarymas, prašykite parodyti, kokie įrodymai pagrindžia šią rekomendaciją, ką galima ištaisyti atskirai ir koks klausimas liks neišspręstas, jei įmonė pasirinks tik dalį siūlomo darbo.

Neapdorotų skenerio rezultatų failo prašykite kaip priedo, jei jo reikia techninei komandai, tačiau ataskaitos priėmimą susiekite su įrodymais, prioritetais ir įvykdomomis taisymo rekomendacijomis, kurių tikitės pagal savo užsakymą; eilučių skaičiaus nesirinkite kokybės matu. Paprašykite vykdytojo paaiškinti vieną nustatytą trūkumą nuo pradžios iki pabaigos: kaip jis aptiktas, ką rezultatas įrodo, kaip tai paveikia Jūsų sistemą ir kaip po pakeitimų bus įsitikinta, kad trūkumas pašalintas, taip pat įvardyti viską, kas šioje išvadoje tebėra prielaida; tokia peržiūra suteikia konkretų pagrindą priimti ataskaitą ir paskirstyti tolesnius darbus.

Kodėl audito kainos taip skiriasi

Kainos skiriasi pirmiausia todėl, kad pasiūlymai apima skirtingą sistemų skaičių ir skirtingą darbo išsamumą: automatinis skenavimas ir versijų apžvalga kainuoja šimtus eurų, o rankiniu būdu atliekami prieigos kontrolės ir verslo logikos testai, pirminio kodo peržiūra ir pakartotinis patikrinimas reikalauja eksperto darbo dienų. Mūsų svetainės saugumo audito paslaugos automatizuota saugumo patikra kainuoja 89–890 € priklausomai nuo apimties ir skirta WordPress, Laravel, Drupal, Joomla bei Moodle sistemoms. Pasiūlymas apima automatinį pažeidžiamumų skenavimą, versijų, įskiepių ir priklausomybių patikrinimą, konfigūracijos ir serverio nustatymų vertinimą bei ataskaitą su nustatytais trūkumais ir prioritetais; šiuo turiniu remkitės lygindami kainą su kitu pasiūlymu ir patikslinkite, kurie Jūsų įdiegti sprendimai bus tikrinami. Mažiausią intervalo sumą susiekite su suderinta apimtimi, kad vienos svetainės patikrinimo kainos nepritaikytumėte visam įmonės sistemų rinkiniui, kurio ribų vykdytojas dar neįvertino.

Mūsų eksperto rankiniu būdu atliekamas auditas siūlomas nuo 3 500 € ir apima rankinį patikrinimą pagal OWASP Top 10, prieigos kontrolės ir verslo logikos testus, kuriais mėginama apeiti nustatytas taisykles, pirminio kodo peržiūrą ir įsilaužimo testavimą gavus leidimą. Pirminio kodo peržiūra numatyta Laravel, WordPress ir individualiai sukurtiems sprendimams, o ataskaitoje nustatytus trūkumus surikiuojame pagal realią riziką ir prie kiekvieno pridedame taisymo rekomendaciją; į pasiūlymą įtrauktas ir pakartotinis patikrinimas po taisymų. Žodis „nuo“ galioja ir tada, kai Jūsų sistema turi tik vieną viešąjį adresą, nes kainai apskaičiuoti dar reikia suderinti funkcijas, vaidmenis ir tikrinamą kodą.

Visa patikra naudojant mūsų sistemą paprastai kainuoja 500–800 €. Tai suma, kurią dažniausiai matome automatizuotos saugumo patikros kainų intervale, o ne atskira kaina už bendrą įmonės valdymo, visų sistemų ir sertifikavimo vertinimą, todėl žodį „visa“ susiekite su konkrečia mūsų suderinta techninės patikros apimtimi. Daugumai svetainių rekomenduojame reguliarią automatizuotą saugumo patikrą, kurią galima dažnai kartoti, o eksperto rankiniu būdu atliekamą auditą – kai sistema apdoroja mokėjimus, asmens duomenis arba yra kritiškai svarbi verslui, nes prieigos teisių klaidas ir verslo logikos apėjimą aptinka tik žmogus; praktikoje gerai veikia reguliari automatizuota saugumo patikra ir rankinis auditas kartą per metus.

Šis skirtumas padeda ir kalbantis apie biudžetą: jei Jums reikia atsakymų apie svetainės komponentus ir nustatymus, prašykite kainos sąmatos šiai užduočiai, o jei pagrindinis klausimas yra naudotojų teisių ar verslo taisyklių apėjimas, įtraukite atitinkamus rankinius testus ir leiskite vykdytojui atskirai įvertinti šį darbą.

Palyginimui parenkite vienodą sistemų, programų, naudotojų vaidmenų ir, jei reikia organizacinės dalies, įmonės veiklos vietų aprašą, tada paprašykite atskirai nurodyti automatinius ir rankinius veiksmus. Įsivaizduokite vieną kainos sąmatą tik viešajai svetainei, o kitą – tai pačiai svetainei kartu su klientų savitarna, administravimo dalimi ir pirminiu kodu: prieš lygindami sumas išsiaiškinkite kiekvieno pasiūlymo ribas. Prie kiekvienos dalies užfiksuokite ir reikalingas prieigas, pasirinktus atitikties kriterijus bei ataskaitos gavėją, nes taip vykdytojui suteikiate konkretų pagrindą kainai apskaičiuoti, o sau – galimybę pastebėti praleistą užduotį.

Atskirai patikslinkite, ar į kainą įeina nustatytų trūkumų paaiškinimas Jūsų programuotojui, jų susiejimas su pasirinkto standarto reikalavimais ir pakartotinis patikrinimas, taip pat kur baigiasi audito darbas ir prasideda taisymų programavimas; planuojant audito biudžetą rekomenduojame priimti sprendimą ir dėl nustatytų trūkumų šalinimo. Jei ir vienodos apimties pasiūlymų kainos vis dar reikšmingai skiriasi, paprašykite vykdytojų paaiškinti darbą ir jo ribas pasitelkiant vieną konkrečią funkciją, pavyzdžiui, naudotojo prieigos pakeitimą, o ne papildomų paslaugų pavadinimus; taip galėsite rinktis pagal konkretų rezultatą ir atsakomybę, nepasikliaudami visapusiško saugumo pažadu.

Kada įmonei reikia saugumo audito

Auditą rekomenduojame užsakyti, kai įmonei reikia priimti konkretų saugumo sprendimą arba pateikti patikrinamą patvirtinimą, ir jau pradžioje įvardyti, ar sprendimas susijęs su valdymu, technine būkle, ar abiem. Jei priežastis yra NIS2, pirmiausia išsiaiškinkite savo statusą ir taikomus reikalavimus, pasitelkdami ir mūsų straipsnį apie NIS2 ir jos taikymo sritį, tada suformuluokite darbo užduotį. Čia svarbi veiksmų seka: reikalavimo taikymą ir reikalingą patvirtinimą išsiaiškinkite prieš pasirinkdami paslaugą, kad techninės ataskaitos užsakymas netaptų vieninteliu Jūsų atsakymu į klausimą, kurį sprendžiant dar reikia įvertinti įmonės atsakomybę ir procesus. Jei svetainėje nėra naudotojų paskyrų, mokėjimų ar asmens duomenų tvarkymo ir niekas nereikalauja patvirtinimo, plataus audito paprastai nereikia: pirmiausia įdiekite atnaujinimus, o tada pakaks automatizuotos saugumo patikros.

Jei patikrinimo reikalauja draudikas arba klientas, paprašykite patikslinti laukiamą rezultatą ir perduokite vykdytojui patį reikalavimo tekstą; pavyzdžiui, klausimą apie darbuotojų mokymą arba atkūrimo iš atsarginės kopijos patikrinimą atskirkite nuo reikalavimo patikrinti programos prieigos teises; atsakymams parenkite atitinkamus įrodymus. Jei tiekėjo anketoje reikia patvirtinti platesnį saugumo procesą, nei apima Jūsų techninis auditas, paprašykite kliento sutarti dėl papildomos informacijos ir įmonėje paskirkite žmogų, kuris ją surinks, užuot išplėtę techninės ataskaitos reikšmę; kartu patikslinkite, ar gavėjas tikisi pačios ataskaitos, atsakymų į konkrečius klausimus, ar kitokios patvirtinimo formos, ir kokiu terminu.

Pirkimui išsaugokite reikalaujamą patikrinimo rūšį ir vykdytojo kvalifikacijos sąlygas tiksliai taip, kaip jas suformulavo užsakovas, o neaiškumus išsiaiškinkite prieš prašydami kainos, kad pasiūlymo nereikėtų perrašyti pradėjus darbą. Pasirinkimą išsamiau nagrinėjame straipsnyje apie pirkime reikalaujamą saugumo patikrinimą, o techninei užduočiai parengti galite atsiųsti mums reikalavimo formuluotę ir sistemos aprašą. Taip pat nurodykite pateikimo datą, turimą dokumentaciją ir kas Jūsų pusėje atliks taisymus, nes pokalbis apie patikrinimo vykdymą turi apimti ne tik ataskaitos rengimą, bet ir Jūsų komandos galimybę iki reikiamos datos dirbti su jos rezultatais.

Po incidento ir tarp planinių patikrinimų

Po incidento audito užduotį rekomenduojame susieti su konkrečiu neatsakytu klausimu: ar taisymas pašalina nustatytą problemą, ar panašios prieigos klaidos reikia ieškoti kitoje funkcijoje ir kaip įmonė ateityje tikrins atitinkamos tvarkos vykdymą. Perduokite vykdytojui žinomų įvykių aprašą ir atskirkite patvirtintus faktus nuo prielaidų. Jei norite išsiaiškinti įvykio eigą, šį darbą taip pat įvardykite atskirai ir sutarkite dėl jo rezultato, nemanydami, kad bendras svetainės auditas automatiškai atsakys į visus incidento klausimus; o tikrinamus taisymus išlaikykite susietus su iš pradžių nustatytais trūkumais, kad po pakeitimų būtų galima pasakyti, kokią konkrečiai problemą ir kaip tikrinote dar kartą.

Mūsų klientai auditą paprastai užsako vieną arba du kartus per metus; tai mūsų praktikos stebėjimas, o ne visoms įmonėms nustatytas intervalas. Savo plane šalia kitos datos rekomenduojame įrašyti ir pakeitimus, po kurių iš naujo įvertinsite patikrinimo apimtį, pavyzdžiui, naują naudotojo vaidmenį, perrašytą prieigos funkciją arba pakeistą tiekėją, turintį teises sistemoje. Atsakingam žmogui patikėkite palyginti šiuos pakeitimus su ankstesnio audito apimtimi ir pasiūlyti konkrečią tikrintiną dalį, o neišspręstus ankstesnės ataskaitos trūkumus išsaugokite kito darbo užduotyje kartu su sprendimais dėl jų atidėjimo, kad naujas patikrinimas prasidėtų nuo žinomos situacijos.