Mis on küberturvalisuse audit ja mida see ettevõttes hõlmab?

Et mõista, mis on küberturvalisuse audit ettevõttes, tuleb eristada korralduslikku osa, mis hindab vastutust, juurdepääsuõigusi, varukoopiaid ja tegutsemist intsidendi korral, tehnilisest osast, mis kontrollib süsteemide seadistusi, turvanõrkusi ja koodi. Hind sõltub kontrollitavate süsteemide mahust ja töö põhjalikkusest: meie automatiseeritud turvalisuse kontroll maksab olenevalt ulatusest 89–890 €, eksperdi käsitsi tehtava auditi hind algab aga 3500 eurost. Kõigepealt selgitage välja, kumba osa vajate ja milliseid tõendeid ootate, sest veebisaidi kontroll, ettevõtte turbehalduse hindamine ja sertifitseerimine on erinevad tellimused erineva tulemusega.

Kujutage ette, et klient saadab enne lepingu allkirjastamist turvaauditi nõude, kuid lisas on küsimused nii töötajate juurdepääsuõiguste kui ka süsteemi tehnilise kontrolli kohta. Nõude edasisaatmisest arendajale ei piisa: peate kokku leppima, kas klient ootab veebisaidi aruannet, dokumenteeritud ettevõtteprotsesse või sõltumatu asutuse sertifikaati ning milliseid süsteeme või tegevusi peab tõend hõlmama. Soovitame säilitada päringu täpse sõnastuse ja selgitada välja selle eesmärgi enne teostaja valimist ja hinnapakkumise vastuvõtmist.

Mis on küberturvalisuse audit: kaks tööd ühe nime all

Need kaks osa vastavad erinevatele küsimustele. Korralduslik osa uurib, kuidas ettevõte turbeotsuseid teeb ja ellu viib, tehniline osa aga seda, kuidas konkreetne süsteem töötab ja kas selle kaitsest saab mööda minna. Seetõttu käsitletakse sama teemat kummaski hoopis erinevalt: juurdepääsuõiguste korra hindamisel palub audiitor näidata, kes töötaja õigused kinnitab ja kuidas need tühistatakse, rakenduse testimisel püüab ta aga tavakontoga teha midagi, mida sellele kontole pole lubatud. Mõlema tulemusi tasub lugeda koos, kuid üks ei asenda teist: korras juurdepääsupoliitika ei tõenda, et rakendus seda järgib, ning turvaline rakendus ei tõenda, et keegi on lahkunud töötaja konto sulgenud.

Seepärast ütleb sõna „audit” tellimuses üksi vähe. Soovitame lisada kaks asja: kriteeriumid, mille alusel tööd hinnatakse, ja tõendid, mida aruandes ootate. Turvanõrkuste hindamisel on nendeks prioriseeritud leiud, läbistustestimisel konkreetne kaitsemehhanism või tegevuspiirang, millest püütakse mööda minna, korralduslikus vastavusauditis aga nõuete kogum, millega võrreldakse dokumente ja igapäevast praktikat.

Kui valite üksnes puuduste esialgse hindamise, nimetage ka tulemust esialgseks hindamiseks, mitte sertifitseerimiseks, ning leppige juba lähteülesandes kokku, kes peab dokumenti lugema ja millise otsuse tegema. Sertifitseerimisel on oluline teada, kes tõendi väljastab: ISO ise ettevõtteid ei sertifitseeri ning selgitab sertifitseerimist kui sõltumatu asutuse kirjalikku kinnitust teatud nõuetele vastavuse kohta. Samas selgituses märgib ISO, et akrediteering tõendab sertifitseerimisasutuse pädevust, kuid pole kohustuslik; seega oleks ebatäpne väita, et sertifitseerida tohib üksnes akrediteeritud asutus. Kui klient nõuab akrediteeritud sertifitseerimist, täpsustage see tingimus enne lepingu sõlmimist ja kontrollige valitud asutuse akrediteeringut, et teil ei oleks hiljem käes tõendit, mida klient ei ole nõus vastu võtma.

Pakume veebisüsteemide tehnilist kontrolli ja saame korralduslikus osas aidata koostada turbepoliitikaid, kuid me ei sertifitseeri ettevõtteid ega juhi teie eest infoturbe halduse süsteemi (ISMS); see piir tasub kirja panna ka tellimusse. Kui ülesanne hõlmab nii veebisaidi kontrolli kui ka ettevõtte juhtimise hindamist, leppige kokku, kes koostab tehnilised tõendid, kes võrdleb neid valitud nõuetega ja kes vastutab lõpphinnangu eest. Muidu võite oodata meilt juhtimisprotsessi hinnangut ning korraldusliku auditi tegijalt testi, mida te pole tellinud. Korraldusliku osa teeb tavaliselt infoturbehalduse konsultant või ISO/IEC 27001 audiitor, sertifikaadi väljastab aga sertifitseerimisasutus.

Korralduslik osa: dokumente tuleb võrrelda tegeliku tööga

Paber kannatab kõike, seega tasub korralduslikus osas kontrollida, kas turbepoliitikas sätestatul on vastutaja, vajalikud ressursid ja täitmise tõendid ning kas riskihinnangus nimetatud probleemide lahendamiseks on ette nähtud tegevused; ENISA juhend väikestele ja keskmise suurusega ettevõtetele hõlmab juhtkonna vastutust, töötajate kaasamist ja koolitamist, turbepoliitikaid, tarnijate haldust, juurdepääsu kaitset ning intsidentidele reageerimise plaani. Lisage vestlustele juhtkonna ja töötajatega dokumentide ja konkreetsete töönäidete kontroll, et hinnangus saaks eristada kavandatud korda selle täitmisest ning nimetada tõendid, mida audiitor ei saanud ja mis tuleb veel koostada.

Juurdepääsu puhul ei vaata hea audiitor üksnes seda, kuidas kontosid antakse, vaid ka seda, kuidas neid suletakse, kas kasutatakse mitmikautentimist ja millised õigused on tarnijatel. Seetõttu tasub kontrollitavate näidete hulka võtta töötaja lahkumine või tarnija vahetus: just siis kiputakse kontosid unustama. Varukoopiatega on samamoodi, sest vastus „teeme koopiaid” ütleb vähe. Varukoopia, millest keegi pole kunagi taastamist proovinud, võib intsidendi ajal osutuda puudulikuks, ning see selgub siis, kui veebisait juba ei tööta. Süsteemide ja seadmete arvestusel peavad olema vastutajad, sündmuslogidel läbivaatamise kord ning intsidentidele reageerimise plaanil nimeliselt määratud inimene, kes teeb otsuseid ja suhtleb asjaosalistega; muidu jääb plaan dokumendiks, mida intsidendi ajal keegi ei täida.

Kriteeriumide aluseks võib võtta ISO/IEC 27001:2022, mis määrab nõuded infoturbe halduse süsteemile (ISMS); sõna „süsteem” tähendab siin haldust, mitte üksnes kontrollitavat rakendust. BSI standardiselgituses on nimetatud 93 infoturvameedet ja neli valdkonda: organisatsiooniline, inimeste, füüsiline ja tehnoloogiline. Leppige kokku, milliseid nõudeid audit hindab ja milliste tõendite alusel, sest viide standardile hinnapakkumises ei ütle veel, kas tellite haldussüsteemi hindamise või üksnes tehnilise kontrolli, mille tulemusi kasutatakse hiljem laiemas auditis; pange see valik kirja enne töö algust.

Teine alus on CIS Controls v8.1 oma 18 kontrollimeetmete rühmaga, mis hõlmab valdkondi ettevõtte varade arvestusest läbistustestimiseni ning sisaldab kokku 153 kaitsemeedet. CIS kirjeldab CIS Implementation Group 1 (IG1) kui elementaarset küberhügieeni, mis hõlmab 56 kaitsemeedet, seega täpsustage tellimuses ka valitud rühm, mitte üksnes raamistiku nimi. Nõudke, et aruanne seoks iga hinnatud nõude saadud tõendi ja tuvastatud puudusega, et pärast parandusi saaks kontrollida täpselt sama tingimust, selle asemel et võrrelda kahte üldist hinnangut.

Millal nõuab seadus küberturvalisuse auditit

Küberturvalisuse seaduse (KüTS) 16. oktoobrist 2026 kehtiv redaktsioon ei kohusta kõiki üliolulisi ja olulisi üksusi perioodiliselt välisauditit tellima. Riiklikku ja haldusjärelevalvet teeb Riigi Infosüsteemi Amet (RIA): ülioluliste üksuste üle pidevalt, sealhulgas pisteliste kohapealsete kontrollide ja kaugjärelevalvega, oluliste üksuste üle aga üksnes järelkontrollina, kui on alust arvata, et nõudeid, eeskätt turvameetmete rakendamise ja intsidentidest teatamise kohustust, ei täideta. RIA võib mõlema järelevalvevormi raames teha üliolulisele üksusele vajaduspõhise turvaauditi, mille ajend võib olla muu hulgas olulise mõjuga küberintsident või nõuete rikkumine. Teenuseosutaja suhtes tehtav sihipärane turvaaudit lähtub RIA või teenuseosutaja riskihinnangust või muust riskiteabest; rikkumise kahtlus ei ole seega iga auditi eeltingimus. RIA võib teha üliolulisele üksusele ka regulaarse turvaauditi kord kolme aasta jooksul, välja arvatud juhul, kui üksusel on juba KüTSi § 7 lõike 5 alusel korrapärase auditeerimise kohustus, näiteks allpool kirjeldatud E-ITSi audit. Turvaaudit on sõltumatu kontroll, millega hinnatakse turvameetmete piisavust ning vastavust infoturvapoliitikale ja tööprotseduuridele. Sihipärase auditi kulu kannab teenuseosutaja, välja arvatud ministri määruses nimetatud juhtudel. RIA võib ettekirjutusega nõuda turvaauditi soovituste rakendamist mõistliku aja jooksul. Julgeolekuasutuse enda süsteemide haldusjärelevalvet teeb asjakohane julgeolekuasutus, mis täidab ka NIS2 pädeva asutuse ülesandeid KüTSi §-s 14 sätestatud ulatuses. Seadus ei kohaldu riigisaladuse ja salastatud välisteabe töötlemisele ega nende töötlussüsteemidele. Välja jäävad ka seaduses määratletud Kaitseministeeriumi valitsemisala süsteemid ning Eesti diplomaatilised ja konsulaaresindused kolmandates riikides koos seaduses nimetatud süsteemidega.

Vabariigi Valitsuse 9. detsembri 2022. aasta määrus nr 121 „Võrgu- ja infosüsteemide küberturvalisuse nõuded” reguleerib KüTSi § 7 lõike 5 alusel Eesti infoturbestandardi (E-ITS) rakendamist ja auditeerimist. E-ITSi kohaldatakse vähemalt KüTSi § 3 lõigetes 2–5 nimetatud tegevusaladega seotud süsteemidele. E-ITSi auditikohustusega teenuseosutaja peab laskma vastavusauditi teha iga kolme aasta järel ja saatma järeldusotsuse RIA-le 30 päeva jooksul selle kättesaamisest; julgeolekuasutus esitab otsuse sama tähtaja jooksul tema üle haldusjärelevalvet tegevale julgeolekuasutusele. Elutähtsa teenuse osutaja esimese E-ITSi auditi tähtaeg määratakse kriisiolukorra ja riigikaitse seaduse § 83 lõike 4 punkti 3 alusel. E-ITSi asemel saab esitada RIA-le kehtiva ISO/IEC 27001 või EVS-EN ISO/IEC 27001 sertifikaadi, mis hõlmab vähemalt samu süsteeme; sel juhul E-ITSi auditit ei nõuta. E-ITSi ega seda ISO-alternatiivi ei kohaldata teenuseosutajale, kellel on majandusaasta jooksul keskmiselt alla 50 töötaja ning kelle aastane bilansimaht või aastakäive ei ületa 10 miljonit eurot. Partner- või sidusettevõtja andmeid ei arvestata, kui teenuseosutaja on temast teenuse osutamiseks kasutatavate süsteemide osas sõltumatu; suuruse määramisel ei kohaldata Euroopa Komisjoni soovituse 2003/361/EÜ lisa artikli 3 lõiget 4. E-ITSi kohaldamisest on vabastatud ka Eesti Lastekirjanduse Keskus ja Võru Instituut; ülejäänud erandid tuleb kontrollida määruse § 3 lõikest 2¹. Auditikohustust ei ole ka § 3 lõike 3 tingimused täitnud teenuseosutajal. Määruse § 4 lõige 4 vabastab auditist veel seal nimetatud muuseumid, kohaliku omavalitsuse asutused ning Haridus- ja Teadusministeeriumi hallatavad põhikoolid ja gümnaasiumid, kui nad ei ole andmekogu vastutavad ega volitatud töötlejad. Esmased turvameetmed peavad siiski olema püsivalt kasutusel ka neil teenuseosutajatel, kellele E-ITSi kohustust ei kohaldata; meetmete vastavust tegelikule vajadusele ja nende rakendamist tuleb korrapäraselt kontrollida ning tulemuste põhjal meetmeid korrigeerida. Riskianalüüsi tuleb ajakohastada viivitamata pärast olulise mõjuga küberintsidenti või süsteemi turvalisust mõjutavat muudatust, hiljemalt aga kolme aasta möödumisel eelmisest ajakohastamisest. Seadus ega määrus ei nõua iga-aastast enesehindamist ega perioodilist läbistustestimist. E-ITSi auditikohustuse puudumine ei välista eelmises lõigus kirjeldatud RIA regulaarset auditit üliolulisele üksusele. Teenuseosutajal, kes vastas seaduses sätestatud teenuseosutaja tunnustele juba enne KüTSi § 3¹ lõike 1 jõustumist 1. jaanuaril 2026, on nõuetega vastavusse viimiseks kolm aastat selle sätte jõustumisest. Kui selline üksus on elutähtsa teenuse osutaja, kellel tekkis seaduse järgimise kohustus esimest korda pärast 18. oktoobrit 2024, kehtib talle üleminekusättes nimetatud eritähtaeg. Seetõttu paluge „kohustusliku auditi” pakkumise saamisel nimetada konkreetne kohustus ja teie staatus, et E-ITSi auditit, selle asemel RIA-le esitatavat ISO/IEC 27001 sertifikaati, esmaste turvameetmete rakendamist ning RIA järelevalves tehtavat sihipärast, vajaduspõhist või regulaarset turvaauditit ei käsitletaks ühe tellimusena.

Tehniline osa: avalikest aadressidest koodini

Nimetage tehnilises lähteülesandes avalikud aadressid, DNS-kirjed, avatud teenused ja TLS-seadistused, samuti serveri või pilvekeskkonna konfiguratsioon, veebirakendused ja lähtekood, mida lubate kontrollida. Märkige iga osa juures, kas teostaja saab seadistustele juurdepääsu või hindab üksnes väljast nähtavat, sest need on erinevad ülesanded. NIST-i turbetestimise meetodite jaotuses eristatakse dokumentide, logide ja konfiguratsiooni läbivaatamist sihtmärkide tuvastamisest ja analüüsist ning turvanõrkuste kinnitamisest; seda jaotust saate kasutada hinnapakkumises valitud meetodite ja oodatava tulemuse täpsemaks kirjeldamiseks.

Veebirakenduste puhul annab OWASP Top 10:2025 ühise keele: kümme riskikategooriat, millest kaks esimest on juurdepääsukontrolli puudused ja ebaturvaline konfiguratsioon. Nimekiri ise midagi ei kontrolli, seepärast muudab hea audiitor iga kategooria teie rakendust puudutavaks küsimuseks: juurdepääsukontrolli puhul tähendab see ühe rolli toimingute proovimist teise rolli kontoga, ebaturvalise kavandamise kategoorias aga sellise äriprotsessi valimist, mille reeglitest saaks mööda minna. Lisage OWASP-i viitele kontrolli maht, et mõlemale poolele oleks selge, millised funktsioonid ja kasutajarollid tegelikult sellesse töösse kuuluvad.

E-posti osas nähke ette SPF-, DKIM- ja DMARC-seadistuste hindamine ning siduge ülesanne süsteemidega, millest ettevõte kirju saadab: Google'i nõuded saatjatele näevad alates 2024. aasta 1. veebruarist ette, et iga Gmaili kontodele kirju saatev saatja seadistab SPF-i või DKIM-i, üle 5000 kirja päevas saatvad saatjad aga nii SPF-i, DKIM-i kui ka DMARC-i. DMARC-i poliitika võib olla „none”, kuid otse saadetavate kirjade From-väljal märgitud domeen peab olema kooskõlas SPF-i või DKIM-i domeeniga; seepärast nõudke lähteülesandes nii seadistuste kui ka kasutatavate saatmisviiside hindamist, piirdumata märkega domeenikirjete olemasolu kohta.

Meie auditites on kõige sagedasem leid paigaldamata PHP, sisuhaldussüsteemi tuuma ja tarkvararaamistike uuendused. Seetõttu soovitame tehnilisse lähteülesandesse lisada kasutatavate versioonide, pluginate ja sõltuvuste ülevaate ning nõuda leiu kirjelduses konkreetse komponendi ja vajaliku tegevuse nimetamist, et arendaja saaks teostatava ülesande, mitte üldise märkuse vananenud veebisaidi kohta. Kui teile on kõige olulisem see, mida kasutajad süsteemis teha tohivad, ei piisa versiooniülevaatest: siis on vaja ka juurdepääsukontrolli ja äriloogika teste. Oleme kokku puutunud kriitiliste vigadega, mille tõttu võis iga kasutaja saada administraatoriõigused ning mille kõrvaldamine lõppes süsteemi tuuma täieliku ümberkirjutamisega; versiooniülevaade poleks sellist viga leidnud.

Küsimus, mida kasutaja teha tohib, erineb küsimusest paigaldatud versioonide kohta ning kummagi jaoks on aruandes vaja eraldi tõendit. NIST määratleb turvanõrkuste skaneerimist kui meetodit hostide, nende omaduste ja seotud turvanõrkuste tuvastamiseks, meie automatiseeritud turvalisuse kontrollis on skaneerimine aga üks tehnilise töö etappidest. NIST-i selgituse järgi iseloomustab läbistustestimist tegelike rünnete jäljendamine, et otsida võimalusi kaitsest möödumiseks ning sageli ka turvanõrkuste kombinatsioone, mis võimaldavad saada laiema juurdepääsu. Testi valikut käsitleme põhjalikumalt artiklis läbistustestimisest; auditi tellimisel on siin oluline määrata, milliseid puudusi teostaja üksnes otsib, milliste praktilist ärakasutatavust ta püüab kokkulepitud piirides tõendada ning millised tegevused jäetakse teadlikult tööst välja.

Kuidas audit kulgeb lähteülesandest kordustestini

Alustage auditi ulatuse kirjalikust kirjeldusest, milles on nimetatud kontrollitavad süsteemid, rakendused, aadressid ja kasutajarollid ning selgelt märgitud, mida selles tellimuses ei kontrollita. Lisage eesmärk ja töö piirid: milliseid tegevusi lubate, millises keskkonnas need toimuvad, kes võib kontrolli peatada ja kellega võtta ühendust ootamatus olukorras; näiteks tellimissüsteemi puhul leppige eraldi kokku, kuidas kontrollida toiminguid, mis muidu tekitaksid päris tellimuse. Selle kokkuleppe peab läbi lugema ka teie hooldusteenuse osutaja, et lubatud tegevused, juurdepääsud ja kontaktisikud oleksid enne tehnilise töö algust kooskõlastatud.

Valmistage enne töö algust ette dokumendid ja vestlustes osalevad inimesed ülesandes nõutud mahus: korraldusliku osa jaoks poliitikad, juurdepääsuõiguste andmise näited, varukoopiatest taastamise märkmed ja intsidentidele reageerimise plaan, tehnilise osa jaoks aga süsteemi kirjeldus ja kokkulepitud juurdepääsud, märkides ka selle, mida teil veel pole. Kui kontrollite koopiat, pange kirja selle erinevused igapäevaselt kasutatavast süsteemist ning leppige kokku, kuidas neid aruandes kajastada, et lugeja mõistaks hiljem, millise keskkonna kohta tulemused kehtivad ning millised küsimused jäid lahtiseks puuduvate dokumentide, juurdepääsu või funktsiooni tõttu. Leppige tehnilise töö jaoks kokku konkreetsed testimisajad ja suhtluskord, dokumentide hindamiseks aga tähtaeg, milleni kolleegid saavad täpsustusi esitada, et tulemustes oleks kontrollitu selgelt eristatud veel kinnitamata teabest.

Kui teostaja leiab töö käigus olulise probleemi, nõudke sellest teatamist kokkulepitud korras ülejäänud töö jätkumise ajal, ootamata täieliku aruande üleandmise kuupäeva. Leppige ka kokku, kes otsustab, kas leitud probleemi kohas testimist jätkata, ja kuidas saadud load või piirangud kirja panna, sest neid otsuseid on vaja selgitamaks, kui põhjalikult õnnestus konkreetset leidu kinnitada.

Ajakavas tuleb jätta aega ka parandusteks

Audit meie süsteemiga võtab mõne päeva, käsitsi tehtava auditi töö ise aga olenevalt auditi ulatusest 1–3 nädalat ning selle alguseni võib audiitori koormuse tõttu kuluda aega. Teenuselehel märgitud üldine teostusvahemik on 1–60 päeva, seega ärge käsitlege neid kirjeldusi ühe garanteeritud tähtajana ning leppige enne tellimist kokku alguskuupäev, aruande üleandmine ja kordustest. Kui klient või hange on määranud tähtaja, planeerige aega ka leidude läbivaatamiseks ja parandamiseks ning teie meeskonna vastusteks küsimustele, sest kontrolli lõppkuupäev ja kuupäev, milleks soovite puudused kõrvaldada, on erinevad planeerimispunktid.

Meie eksperdi käsitsi tehtava auditi pakkumine sisaldab kordustesti 30 päeva jooksul pärast parandusi. Selle sisukaks kasutamiseks leppige aruande üleandmisel kokku, kes iga leiu parandab, kes teatab töö lõpetamisest ja milliseid tõendeid teostaja uuesti kontrollib; parandustööde maht ja tasu täpsustage eraldi, sest auditi hind ei ole kokkulepe kogu järgneva arenduse kohta. Parandused võite teha oma meeskonnaga ning meie kontrollime neid seejärel, või usaldada need meile eraldi tööna, mille maksumust hindame aruande põhjal. Nõudke kordustesti aruandes kõrvaldatud puuduste eristamist edasilükatutest või veel kontrollimata puudustest ning kasutatud süsteemiseisu märkimist, et teie meeskonnal ja aruande saajal oleks iga esialgse leiu kohta üks arusaadav vastus.

Mida auditiaruandelt nõuda

Nõudke aruande alguses juhtkonnale arusaadavat ülevaadet kontrolli eesmärgist, hõlmatud süsteemidest ja olulisematest leidudest, et tööde ja ressursside üle saaks otsustada kogu tehnilist materjali läbi lugemata, ning paluge samas nimetada ka töö piirangud. Kui lähtekood polnud kättesaadav või mõnda kasutajarolli ei käsitletud, paluge see otse välja öelda, selle asemel et jätta lugeja mõistatama, mida süsteemi seisundi lühihinnang tähendab; hinnake sellist ülevaadet selle järgi, kas teie juht oskab nimetada järgmise otsuse, vastutaja ja küsimuse, millele veel vastust pole.

Nõudke iga tehnilise leiu kohta selle asukohta süsteemis, avastamise asjaolusid, kasutatud kasutajarolli, tegevuse kordamise kirjeldust ja tulemuse tõendit; korraldusliku mittevastavuse puhul paluge nõude viite kõrval nimetada dokument või töönäide, millel hinnang põhineb. Parandussoovitusest peab selguma, mida täpselt muuta, seega täpsustage sõnastust „korrastada juurdepääsud” konkreetsete õiguste ja funktsioonini, mida arendaja peab muutma, ning märkige oodatav käitumine pärast parandust. Nii saab aruannet kasutada nii ülesande üleandmiseks kui ka hilisemaks kontrolliks, ilma et iga järgmine lugeja peaks audiitori mõtet uuesti tõlgendama.

Kui aruandes kasutatakse CVSS-i, nõudke ka versiooni nimetamist: FIRST avaldab CVSS-i, sealhulgas versiooni 4.0, mille tõsidusskaala tähised on „puudub” (0,0), „madal” (0,1–3,9), „keskmine” (4,0–6,9), „kõrge” (7,0–8,9) ja „kriitiline” (9,0–10,0); nende sõnaliste tähiste kasutamine on valikuline. Nõudke numbri kõrval põhjendust ja selgitust mõju kohta teie ettevõtte tööle, näiteks millist tegevust või andmekogumit konkreetne leid puudutab ja miks soovitatakse seda parandada just selles järjekorras, et prioriteeti saaks arutada kirjeldatud asjaolude, mitte üksnes numbri põhjal.

Kasutame selliste kriitiliste vigadega saadud kogemust selleks, et nõuda tagajärgede selget kirjeldust, mitte väita, et iga veebisait vajab ümberehitust: aruandes peab saama eristada konkreetset parandust probleemist, mille lahendamiseks tuleb üle vaadata süsteemi põhitoimimine. Kui aruanne näeb ette ulatuslikku ümbertöötamist, paluge näidata, millised tõendid soovitust toetavad, mida saab parandada eraldi ja milline küsimus jääb lahendamata, kui ettevõte valib üksnes osa pakutud tööst.

Nõudke skanneri töötlemata tulemusfaili lisana, kui tehniline meeskond seda vajab, kuid siduge aruande vastuvõtmine tellimuses oodatud tõendite, prioriteetide ja teostatavate parandussoovitustega; ärge valige kvaliteedimõõduks ridade arvu. Paluge teostajal selgitada üht leidu algusest lõpuni: kuidas see tuvastati, mida tulemus tõendab, kuidas see teie süsteemi mõjutab ja kuidas pärast muudatusi veendutakse selle kõrvaldamises, ning nimetada kõik, mis selles järelduses on veel oletus; selline läbivaatamine annab konkreetse aluse aruande vastuvõtmiseks ja edasise töö jaotamiseks.

Miks auditite hinnad nii palju erinevad

Hinnad erinevad peamiselt seetõttu, et pakkumised hõlmavad erinevat arvu süsteeme ja erinevat töö põhjalikkust: automaatne skaneerimine ja versiooniülevaade maksavad sadu eurosid, kuid käsitsi tehtavad juurdepääsukontrolli ja äriloogika testid, lähtekoodi ülevaatus ning kordustest nõuavad eksperdi tööpäevi. Meie veebilehe turvaauditi teenuse automatiseeritud turvalisuse kontroll maksab olenevalt ulatusest 89–890 € ning on mõeldud WordPressi, Laraveli, Drupali, Joomla ja Moodle'i süsteemidele. Pakkumine sisaldab automaatset turvanõrkuste skaneerimist, versioonide, pluginate ja sõltuvuste kontrolli, konfiguratsiooni ja serveriseadistuste hindamist ning aruannet leidude ja prioriteetidega; kasutage seda sisu hinna võrdlemisel teise pakkumisega ning täpsustage, milliseid teie paigaldusi kontrollitakse. Seostage vahemiku alumine summa kokkulepitud ulatusega, et ühe veebisaidi kontrolli hinda ei kantaks üle kogu ettevõtte süsteemide kogumile, mille piire teostaja pole veel hinnanud.

Meie eksperdi käsitsi tehtava auditi hind algab 3500 eurost ning see sisaldab käsitsi kontrolli OWASP Top 10 järgi, juurdepääsukontrolli teste ja äriloogika teste reeglitest möödumise leidmiseks, lähtekoodi ülevaatust ning lubatud läbistustestimist. Lähtekoodi ülevaatus on ette nähtud Laraveli, WordPressi ja eritellimusel arendatud lahendustele; aruandes järjestame leiud tegeliku riski järgi ja lisame igaühele parandussoovituse ning pakkumine sisaldab ka kordustesti pärast parandusi. Hinna alammäär kehtib ka siis, kui teie süsteemil on ainult üks avalik aadress, sest hinna arvutamiseks tuleb veel kokku leppida funktsioonid, rollid ja kontrollitav kood.

Täielik kontroll meie süsteemiga maksab tavaliselt 500–800 €. Seda summat näeme automatiseeritud turvalisuse kontrolli hinnavahemikus kõige sagedamini; see pole eraldi hind ettevõtte juhtimise, kõigi süsteemide ja sertifitseerimise ühiseks hindamiseks, seega seostage sõna „täielik” konkreetse tehnilise kontrolli ulatusega, mille oleme kokku leppinud. Enamikule veebisaitidele soovitame regulaarset automatiseeritud turvalisuse kontrolli, mida saab sageli korrata, eksperdi käsitsi tehtavat auditit aga siis, kui süsteem töötleb makseid või isikuandmeid või on äritegevuse jaoks kriitiline, sest juurdepääsuõiguste vigu ja äriloogika reeglitest möödumise võimalusi leiab üksnes inimene; praktikas toimib hästi regulaarne automatiseeritud turvalisuse kontroll ja käsitsi tehtav audit kord aastas.

See erinevus aitab ka eelarvet arutada: kui vajate vastuseid veebisaidi komponentide ja seadistuste kohta, küsige hinnapakkumist sellele ülesandele; kui põhiküsimus on aga kasutajaõigustest või ärireeglitest möödumine, kaasake vastavad käsitsi tehtavad testid ning laske teostajal nende tööd eraldi hinnata.

Koostage võrdlemiseks ühesugune süsteemide, rakenduste ja kasutajarollide kirjeldus ning korraldusliku osa vajaduse korral ka ettevõtte tegevuskohtade kirjeldus, seejärel paluge automaatsed ja käsitsi tehtavad tegevused eraldi välja tuua. Kujutage ette üht hinnapakkumist ainult avalikule veebisaidile ja teist samale veebisaidile koos kliendikeskkonna, haldusliidese ja lähtekoodiga: enne summade võrdlemist selgitage välja kummagi pakkumise piirid. Fikseerige iga osa juures ka vajalikud juurdepääsud, valitud vastavuskriteeriumid ja aruande saaja, sest nii annate teostajale konkreetse aluse hinna arvutamiseks ning endale võimaluse märgata välja jäänud ülesannet.

Täpsustage eraldi, kas hind sisaldab leidude selgitamist teie arendajale, nende seostamist valitud standardi nõuetega ja kordustesti ning kus lõpeb audit ja algab paranduste arendamine; soovitame auditi eelarvet koostades otsustada ka, kuidas ja kelle kulul tuvastatud puudused kõrvaldatakse. Kui ka sama mahuga pakkumiste hinnad erinevad endiselt oluliselt, paluge teostajatel selgitada tööd ja selle piire ühe konkreetse funktsiooni, näiteks kasutaja juurdepääsu muutmise kaudu, mitte lisateenuste nimedega; nii saate valida konkreetse tulemuse ja vastutuse alusel, toetumata kõikehõlmava turvalisuse lubadusele.

Millal ettevõte turvaauditit vajab

Soovitame auditi tellida siis, kui ettevõte peab tegema konkreetse turbeotsuse või esitama kontrollitava tõendi, ning nimetada juba alguses, kas otsus puudutab juhtimist, tehnilist seisundit või mõlemat. Kui põhjuseks on NIS2, selgitage kõigepealt välja oma staatus ja kohaldatavad nõuded, kasutades ka meie artiklit NIS2 ja selle kohaldamisala kohta, seejärel sõnastage lähteülesanne. Järjekord on siin oluline: selgitage nõuete kohaldatavus ja vajalik tõend välja enne teenuse valimist, et tehnilise aruande tellimine ei jääks teie ainsaks vastuseks küsimusele, mille puhul tuleb hinnata ka ettevõtte vastutust ja protsesse. Kui veebisaidil pole kasutajakontosid, makseid ega isikuandmete töötlemist ning keegi ei nõua tõendit, pole ulatuslikku auditit tavaliselt vaja: paigaldage esmalt uuendused ning piisab automatiseeritud turvalisuse kontrollist.

Kui kontrolli nõuab kindlustusandja või klient, paluge täpsustada oodatavat tulemust ning andke teostajale nõude tekst; näiteks eristage töötajate koolitamise või varukoopiast taastamise kontrolli puudutav küsimus nõudest kontrollida rakenduse juurdepääsuõigusi ning valmistage vastuste jaoks ette asjakohased tõendid. Kui tarnija küsimustikus tuleb kinnitada laiemat turbeprotsessi, kui teie tehniline audit hõlmab, leppige kliendiga kokku, millist lisateavet esitate, ja määrake ettevõttes inimene, kes selle kogub, selle asemel et laiendada tehnilise aruande tähendust; täpsustage samal ajal, kas saaja ootab aruannet ennast, vastuseid konkreetsetele küsimustele või muud kinnitusvormi ning milline on tähtaeg.

Säilitage hanke jaoks nõutud kontrolliliik ja teostaja kvalifikatsioonitingimused täpselt tellija sõnastuses ning selgitage ebaselgused välja enne hinnapäringut, et pakkumist ei tuleks pärast töö algust ümber kirjutada. Valikut käsitleme põhjalikumalt artiklis hankes nõutava turbekontrolli kohta, tehnilise lähteülesande koostamiseks võite aga saata meile nõude sõnastuse ja süsteemi kirjelduse. Märkige ka esitamise kuupäev, olemasolev dokumentatsioon ja see, kes teie poolel parandused teeb, sest kontrolli teostamise arutelu peab hõlmama nii aruande koostamist kui ka teie meeskonna võimalust selle tulemustega vajaliku kuupäevani töötada.

Pärast intsidenti ja plaaniliste kontrollide vahel

Pärast intsidenti soovitame seada auditi lähteülesande konkreetse vastamata küsimuse järgi: kas parandus kõrvaldab tuvastatud probleemi, kas sarnast juurdepääsuviga tuleb otsida mõnest teisest funktsioonist ning kuidas ettevõte edaspidi vastava korra täitmist kontrollib. Andke teostajale teadaolevate sündmuste kirjeldus ja eristage kinnitatud faktid oletustest. Kui soovite välja selgitada juhtunu käigu, nimetage ka see eraldi tööna ja leppige kokku selle tulemus, eeldamata, et üldine veebilehe turvaaudit vastab automaatselt kõigile intsidenti puudutavatele küsimustele; kontrollitavate paranduste puhul säilitage seos esialgsete leidudega, et pärast muudatusi saaks öelda, millist probleemi täpselt uuesti kontrolliti ja kuidas.

Meie kliendid tellivad auditi tavaliselt üks või kaks korda aastas; see on meie kogemusest lähtuv tähelepanek, mitte kõigile ettevõtetele kehtestatud intervall. Soovitame oma plaani järgmise kuupäeva kõrvale kirja panna ka muudatused, mille järel hindate kontrolli mahtu uuesti, näiteks uue kasutajarolli, ümberkirjutatud juurdepääsufunktsiooni või süsteemiõigustega tarnija vahetuse. Andke vastutavale inimesele ülesanne võrrelda neid muudatusi eelmise auditi ulatusega ja pakkuda välja konkreetne kontrollitav osa, eelmise aruande lahendamata leiud aga säilitage järgmises lähteülesandes koos nende edasilükkamise otsustega, et uus kontroll algaks teadaolevast olukorrast.