Kas ietilpst uzņēmuma drošības auditā?

Uzņēmuma drošības auditā jānošķir organizatoriskā daļa, kurā izvērtē atbildību, piekļuves, dublējumkopijas un rīcību incidentā, no tehniskās daļas, kurā pārbauda sistēmu iestatījumus, ievainojamības un kodu. Cena ir atkarīga no pārbaudāmo sistēmu apjoma un darba dziļuma: mūsu automatizētā drošības pārbaude maksā €89–890 atkarībā no tvēruma, bet manuāls eksperta audits ir pieejams, sākot no €3 500. Vispirms noskaidrojiet, kura daļa Jums vajadzīga un kādu pierādījumu sagaidāt, jo vietnes pārbaude, uzņēmuma drošības pārvaldības izvērtējums un sertifikācija ir atšķirīgi pasūtījumi ar atšķirīgu rezultātu.

Iedomājieties, ka klients pirms līguma parakstīšanas atsūta prasību veikt drošības auditu, bet pielikumā ir jautājumi gan par darbinieku piekļuves tiesībām, gan par sistēmas tehnisko pārbaudi. Ar prasības pārsūtīšanu izstrādātājam vien nepietiek: Jums jāvienojas, vai klients gaida ziņojumu par vietni, dokumentētus uzņēmuma procesus vai neatkarīgas iestādes sertifikātu, un kādu sistēmu vai darbības daļu šim apliecinājumam jāaptver. Mēs iesakām saglabāt pieprasījuma precīzo formulējumu un noskaidrot tā mērķi, pirms izvēlaties izpildītāju un pieņemat cenu aprēķinu.

Divi darbi ar vienu nosaukumu

Abas daļas atbild uz atšķirīgiem jautājumiem. Organizatoriskā daļa jautā, kā uzņēmums pieņem un izpilda drošības lēmumus, tehniskā daļa jautā, kā konkrēta sistēma darbojas un vai tās aizsardzību var apiet. Tāpēc viena un tā pati tēma abās izskatās pavisam citādi: piekļuves tiesību kārtības izvērtējumā auditors prasa parādīt, kas apstiprina darbinieka tiesības un kā tās atsauc, bet lietotnes testā viņš ar parastu kontu mēģina izdarīt to, kas šim kontam nav atļauts. Abus rezultātus vērts lasīt kopā, taču viens neaizstāj otru: sakārtota piekļuves politika nepierāda, ka lietotne to ievēro, un droša lietotne nepierāda, ka aizgājuša darbinieka kontu kāds ir slēdzis.

Tāpēc vārds «audits» pasūtījumā vien pasaka maz. Mēs iesakām tam pievienot divas lietas: kritērijus, pēc kuriem darbu vērtēs, un pierādījumus, kurus sagaidāt ziņojumā. Ievainojamību novērtējumam tie ir atradumi ar prioritātēm, ielaušanās testam konkrēts aizsardzības mehānisms vai darbības ierobežojums, ko mēģinās apiet, bet organizatoriskam atbilstības auditam prasību kopums, ar kuru salīdzinās dokumentus un ikdienas praksi.

Ja izvēlaties tikai sākotnēju nepilnību izvērtējumu, rezultātu arī nosauciet par tādu, nevis par sertifikāciju, un jau uzdevumā vienojieties, kam šis dokuments būs jāizlasa un kāds lēmums jāpieņem. Sertifikācijas gadījumā ir svarīgi zināt, kas izsniegs apliecinājumu: ISO pats uzņēmumus nesertificē, un sertifikāciju tas skaidro kā neatkarīgas iestādes rakstisku apliecinājumu par atbilstību noteiktām prasībām. Tajā pašā skaidrojumā ISO norāda, ka akreditācija apliecina sertifikācijas iestādes kompetenci, tomēr nav obligāta; tādēļ apgalvojums, ka sertificēt drīkst tikai akreditēta iestāde, būtu neprecīzs. Ja Jūsu klients prasa akreditētu sertifikāciju, noskaidrojiet šo nosacījumu pirms līguma un pārbaudiet izvēlētās iestādes akreditāciju, lai vēlāk nepaliktu ar apliecinājumu, kuru klients nav piekritis pieņemt.

Mūsu piedāvājums ir tīmekļa sistēmu tehniskā pārbaude, un organizatoriskajā daļā mēs varam palīdzēt sagatavot drošības politikas, taču uzņēmumus nesertificējam un informācijas drošības pārvaldības sistēmu Jūsu vietā nevadām, un šo robežu ir vērts ierakstīt arī pasūtījumā. Ja uzdevums ietver gan vietnes pārbaudi, gan uzņēmuma pārvaldības izvērtējumu, vienojieties, kurš sagatavo tehniskos pierādījumus, kurš tos salīdzina ar izvēlētajām prasībām un kurš atbild par gala vērtējumu, jo citādi no mums sagaidīsiet vadības procesa vērtējumu, bet no organizatoriskā auditora varat gaidīt testu, kuru Jūs neesat pasūtījuši. Organizatorisko daļu parasti veic informācijas drošības pārvaldības konsultants vai ISO/IEC 27001 auditors, bet sertifikātu izsniedz sertifikācijas iestāde.

Organizatoriskā daļa: dokumenti jāsalīdzina ar darbu

Papīrs pacieš visu, tāpēc organizatoriskajā daļā vērts pārbaudīt, vai drošības politikā noteiktajam ir atbildīgais, nepieciešamie resursi un izpildes pierādījumi, bet risku izvērtējumā nosauktajām problēmām ir paredzēta rīcība; ENISA ceļvedis mazajiem un vidējiem uzņēmumiem aptver vadības atbildību, darbinieku iesaisti un apmācību, drošības politikas, piegādātāju pārvaldību, piekļuves aizsardzību un incidentu reaģēšanas plānu. Sarunām ar vadību un darbiniekiem pievienojiet dokumentu un konkrētu darba piemēru pārbaudi, lai vērtējumā varētu atšķirt iecerēto kārtību no tās izpildes, kā arī nosaukt pierādījumus, kurus auditoram neizdevās saņemt un kuri vēl jāsagatavo.

Piekļuves jautājumos labs auditors skatās ne tikai uz to, kā kontus piešķir, bet arī uz to, kā tos slēdz, vai izmanto daudzfaktoru autentifikāciju un kādas tiesības ir piegādātājiem, tāpēc pārbaudāmajos piemēros vērts iekļaut darbinieka aiziešanu vai piegādātāja nomaiņu: tieši tur kontus mēdz aizmirst. Ar dublējumkopijām ir līdzīgi, jo atbilde «kopijas veidojam» pasaka maz. Kopija, kuru neviens nekad nav atjaunojis, incidenta brīdī var izrādīties nepilnīga, un to uzzina tad, kad vietne jau nedarbojas. Sistēmu un ierīču uzskaitei vajadzīgi atbildīgie, notikumu žurnāliem pārskatīšanas kārtība, bet incidentu reaģēšanas plānam vārdā nosaukts cilvēks, kurš pieņem lēmumus un sazinās ar iesaistītajiem, citādi plāns paliek dokuments, kuru incidenta brīdī neviens neizpilda.

Kritērijiem var izmantot ISO/IEC 27001:2022, kas nosaka prasības informācijas drošības pārvaldības sistēmai; ar vārdu «sistēma» šeit jāsaprot pārvaldība, ne tikai pārbaudāmā lietotne; BSI standarta skaidrojumā nosaukti 93 kontroles pasākumi un četras jomas: organizatoriskā, cilvēku, fiziskā un tehnoloģiskā. Vienojieties, kādas prasības audits izvērtēs un ar kādiem pierādījumiem, jo atsauce uz standartu cenu aprēķinā vēl nepasaka, vai pasūtāt pārvaldības sistēmas izvērtējumu vai tikai tehnisku pārbaudi, kuras rezultātus vēlāk izmantos plašākā auditā; šo izvēli uzrakstiet pirms darba sākuma.

Cits pamats ir CIS Controls v8.1 ar 18 kontroles pasākumu grupām, kas aptver jomas no uzņēmuma resursu uzskaites līdz ielaušanās testiem un kopā ietver 153 aizsardzības pasākumus. CIS pirmo ieviešanas grupu jeb IG1 raksturo kā pamata kiberhigiēnu ar 56 aizsardzības pasākumiem, tādēļ pasūtījumā precizējiet arī izvēlēto grupu, ne tikai ietvara nosaukumu. Prasiet ziņojumā sasaistīt katru vērtēto prasību ar saņemto pierādījumu un konstatēto trūkumu, lai pēc labojumiem varētu pārbaudīt tieši to pašu nosacījumu, nevis salīdzināt divus vispārīgus vērtējumus.

Latvijā pašvērtējums un ārējais audits ir atšķirīgi pienākumi

Nacionālās kiberdrošības likuma 44. pants neuzliek katram būtisko vai svarīgo pakalpojumu sniedzējam vispārēju pienākumu periodiski pasūtīt ārējo auditu: Nacionālais kiberdrošības centrs un Satversmes aizsardzības birojs atbilstoši uzraudzības dalījumam var veikt atbilstības auditu vai uzdot ārējo auditu, ja ir aizdomas par pārkāpumiem vai tie konstatēti. Šādam ārējam auditam vajadzīgs neatkarīgs auditors bez interešu konflikta, kurš atbilst noteiktajām prasībām, bet informācijas un komunikācijas tehnoloģiju kritiskajā infrastruktūrā arī saskaņojums ar Satversmes aizsardzības biroju; izmaksas un pārkāpumu novēršana ir subjekta pienākums.

Savukārt Ministru kabineta noteikumi Nr. 397 «Minimālās kiberdrošības prasības» nosaka pašvērtējumu reizi gadā kritiskās infrastruktūras īpašniekam vai tiesiskajam valdītājam un subjektam, kura īpašumā vai valdījumā ir vismaz viena A klases informācijas sistēma. Pārējiem subjektiem bez A klases sistēmas pašvērtējums paredzēts reizi trijos gados, ja vien Nacionālais kiberdrošības centrs nenosaka citādi; ziņojums jāiesniedz līdz attiecīgā gada 1. oktobrim. Atsevišķi šo noteikumu 131.1. punkts A klases informācijas sistēmai prasa ielaušanās testu pirms nodošanas ekspluatācijā un pēc tam ne retāk kā reizi trijos gados. Tādēļ, saņemot piedāvājumu izpildīt «obligāto auditu», prasiet nosaukt konkrēto pienākumu un Jūsu statusu, lai pašvērtējuma sagatavošanu un uzraudzības iestādes uzdoto ārējo auditu neuztvertu kā vienu pasūtījumu.

Tehniskā daļa: no publiskajām adresēm līdz kodam

Tehniskajā uzdevumā nosauciet publiskās adreses, DNS ierakstus, atvērtos pakalpojumus un TLS iestatījumus, kā arī servera vai mākoņvides konfigurāciju, tīmekļa lietotnes un pirmkodu, kuru atļaujat pārbaudīt, un pie katras daļas norādiet, vai izpildītājs saņems piekļuvi iestatījumiem vai vērtēs tikai no ārpuses redzamo, jo tie ir atšķirīgi uzdevumi. NIST drošības testēšanas paņēmienu dalījumā dokumentu, žurnālu un konfigurācijas pārskatīšana ir nošķirta no mērķu identificēšanas un analīzes, kā arī ievainojamību apstiprināšanas; šo dalījumu varat izmantot, lai cenu aprēķinā precīzāk aprakstītu izvēlētās metodes un sagaidāmo rezultātu.

Tīmekļa lietotnēm OWASP Top 10:2025 ir kopējā valoda: desmit risku kategorijas, no kurām pirmās divas ir piekļuves kontroles kļūmes un nedroša konfigurācija. Saraksts pats par sevi neko nepārbauda, tāpēc labs auditors katru kategoriju pārvērš jautājumā par Jūsu lietotni: piekļuves kontrolei tas nozīmē mēģināt vienas lomas darbības ar citas lomas kontu, bet nedroša projektējuma kategorijai izvēlēties biznesa procesu, kura noteikumus kāds varētu apiet. Atsauci uz OWASP papildiniet ar pārbaudes apjomu, lai abām pusēm būtu skaidrs, kuras funkcijas un lietotāju lomas šajā darbā tiešām ietilpst.

E-pasta daļā paredziet SPF, DKIM un DMARC iestatījumu izvērtēšanu, sasaistot uzdevumu ar sistēmām, no kurām uzņēmums sūta vēstules: Google prasības sūtītājiem kopš 2024. gada 1. februāra paredz, ka ikviens sūtītājs uz Gmail kontiem iestata SPF vai DKIM, bet tie, kuri dienā nosūta vairāk nekā 5 000 vēstuļu, iestata gan SPF, gan DKIM, gan DMARC. DMARC politika drīkst būt «none», bet tiešajiem sūtījumiem From laukā norādītajam domēnam jābūt saskaņotam ar SPF vai DKIM domēnu; tādēļ uzdevumā prasiet vērtēt gan iestatījumus, gan Jūsu izmantotos sūtīšanas ceļus, neaprobežojoties ar domēna ierakstu esamības atzīmi.

Mūsu auditos visbiežākais atradums ir neuzstādīti PHP, satura pārvaldības sistēmas kodola un programmatūras ietvaru atjauninājumi. Tāpēc tehniskajā uzdevumā iesakām iekļaut izmantoto versiju, spraudņu un atkarību pārskatu, bet atraduma aprakstā prasīt nosaukt konkrēto komponenti un nepieciešamo rīcību, lai izstrādātājs saņemtu izpildāmu uzdevumu, nevis vispārīgu aizrādījumu par novecojušu vietni. Ja Jums svarīgākais ir tas, ko lietotāji sistēmā drīkst darīt, ar versiju pārskatu nepietiek: tad vajadzīgi arī piekļuves kontroles un biznesa loģikas testi. Mūsu pieredzē ir bijušas kritiskas kļūdas, kuru dēļ jebkurš lietotājs varēja iegūt administratora tiesības, un to novēršana beidzās ar pilnīgu sistēmas kodola pārrakstīšanu; versiju pārskats šādu kļūdu nebūtu atradis.

Jautājums par to, ko lietotājs drīkst darīt, ir cits nekā jautājums par instalētajām versijām, un katram ziņojumā vajadzīgs savs pierādījums. NIST ievainojamību skenēšanu definē kā paņēmienu resursdatoru, to īpašību un saistīto ievainojamību identificēšanai, savukārt mūsu automatizētajā drošības pārbaudē skenēšana ir viens no tehniskā darba posmiem. Ielaušanās testam NIST skaidrojumā raksturīga reālu uzbrukumu atdarināšana, meklējot aizsardzības apiešanas iespējas un bieži arī ievainojamību kombinācijas, kuras ļauj iegūt plašāku piekļuvi. Paša testa izvēli sīkāk aplūkojam rakstā par ielaušanās testu; audita pasūtījumā šeit ir būtiski noteikt, kuras nepilnības izpildītājs tikai meklēs un kurām izpildītājs saskaņotajās robežās mēģinās pierādīt praktisku izmantošanu, kā arī kuras darbības apzināti atstās ārpus darba.

Kā audits norit no uzdevuma līdz atkārtotai pārbaudei

Sāciet ar rakstisku tvēruma aprakstu, kurā nosauktas pārbaudāmās sistēmas, lietotnes, adreses un lietotāju lomas, kā arī skaidri norādīts, ko šajā pasūtījumā nepārbaudīs, un pievienojiet mērķi un darba robežas: kuras darbības atļaujat, kādā vidē tās notiks, kurš var apturēt pārbaudi un ar kuru cilvēku sazināties, ja rodas neparedzēta situācija; piemēram, pasūtījumu sistēmai atsevišķi vienojieties, kā pārbaudīt darbības, kas citādi radītu īstu pasūtījumu. Šī vienošanās ir jāizlasa arī Jūsu uzturētājam, lai atļautās darbības, piekļuves un kontaktpersonas būtu saskaņotas pirms tehniskā darba sākuma.

Pirms darba sākuma sagatavojiet dokumentus un cilvēkus sarunām tādā apjomā, kādu prasa uzdevums: organizatoriskajai daļai politikas, piekļuves piešķiršanas piemērus, dublējumkopiju atjaunošanas pierakstus un incidentu reaģēšanas plānu, bet tehniskajai daļai sistēmas aprakstu un saskaņotās piekļuves, atzīmējot arī to, kā Jums vēl nav. Ja pārbaudāt kopiju, pierakstiet tās atšķirības no ikdienā izmantotās sistēmas un vienojieties, kā ziņojumā tās atspoguļot, lai lasītājs vēlāk varētu saprast, uz kuru vidi attiecas iegūtie rezultāti un kuri jautājumi palikuši atvērti tādēļ, ka dokumenti, piekļuve vai attiecīgā funkcija nebija pieejama. Tehniskajam darbam vienojieties par konkrētiem testēšanas laikiem un saziņas kārtību, bet dokumentu izvērtēšanai paredziet termiņu, līdz kuram Jūsu kolēģi var iesniegt precizējumus, lai rezultātā būtu skaidri nodalīts pārbaudītais no vēl neapstiprinātā.

Ja darba laikā izpildītājs atrod būtisku problēmu, prasiet ziņot par to saskaņotajā kārtībā, kamēr pārējais darbs turpinās, negaidot pilnās atskaites nodošanas datumu. Vienojieties arī, kas pieņem lēmumu par turpmāko testēšanu šajā vietā un kā pierakstīt saņemtās atļaujas vai ierobežojumus, jo šie lēmumi būs vajadzīgi, skaidrojot, cik tālu konkrēto atradumu izdevās apstiprināt.

Termiņā jāparedz laiks arī labojumiem

Audits ar mūsu sistēmu aizņem dažas dienas, bet pats manuālā audita darbs aizņem 1–3 nedēļas atkarībā no tvēruma, un līdz tā sākumam var paiet laiks, jo tas atkarīgs no auditora noslodzes. Pakalpojuma lapā norādītais kopējais izpildes diapazons ir 1–60 dienas, tādēļ šos aprakstus neuztveriet kā vienu garantētu termiņu un pirms pasūtījuma saskaņojiet sākuma datumu, atskaites nodošanu un atkārtoto pārbaudi. Ja Jums ir klienta vai iepirkuma noteikts datums, plānojiet arī laiku atradumu izskatīšanai un labošanai, kā arī Jūsu komandas atbildēm uz jautājumiem, jo pārbaudes pabeigšanas datums un datums, līdz kuram vēlaties novērst trūkumus, ir atšķirīgi plānošanas punkti.

Mūsu manuālā eksperta audita piedāvājumā ir atkārtota pārbaude 30 dienu laikā pēc labojumiem. Lai to izmantotu jēgpilni, nododot atskaiti, vienojieties, kurš labo katru atradumu, kurš paziņo par darba pabeigšanu un kādus pierādījumus izpildītājs pārbaudīs atkārtoti; pašu labojumu apjomu un apmaksu precizējiet atsevišķi, jo audita cena nav vienošanās par visu turpmāko izstrādi. Labojumus varat veikt ar savu komandu, un mēs pēc tam tos pārbaudīsim, vai uzticēt tos mums kā atsevišķu darbu, kuru aplēšam pēc atskaites. Atkārtotajā ziņojumā prasiet atšķirt novērstu trūkumu no atlikta vai vēl nepārbaudīta, kā arī norādīt izmantoto sistēmas stāvokli, lai Jūsu komandai un atskaites saņēmējam būtu viena saprotama atbilde par katru sākotnējo atradumu.

Ko prasīt audita ziņojumā

Ziņojuma sākumā prasiet vadībai saprotamu pārskatu par pārbaudes mērķi, aptvertajām sistēmām un svarīgākajiem atradumiem, lai lēmumu par darbiem un resursiem varētu pieņemt, nepārlasot visu tehnisko materiālu, un lūdziet tajā pašā vietā nosaukt arī darba ierobežojumus. Ja pirmkods nebija pieejams vai kāda lietotāja loma netika aplūkota, lūdziet to pateikt tieši, nevis atstāt lasītājam minēt, ko nozīmē īsais vērtējums par sistēmas stāvokli; šādu pārskatu vērtējiet pēc tā, vai Jūsu vadītājs no tā var nosaukt nākamo lēmumu, atbildīgo un jautājumu, uz kuru vēl nav atbildes.

Katram tehniskajam atradumam prasiet vietu sistēmā, apstākļus, kādos tas atrasts, izmantoto lietotāja lomu, darbības atkārtošanas aprakstu un rezultāta pierādījumu, bet organizatoriskai neatbilstībai līdzās prasības atsaucei lūdziet nosaukt dokumentu vai darba piemēru, uz kuru vērtējums balstās. Labojuma ieteikumā jābūt saprotamam, kas tieši jāmaina, tādēļ formulējumu «sakārtot piekļuves» precizējiet līdz konkrētajām tiesībām un funkcijai, kas Jūsu izstrādātājam jāmaina, un norādiet sagaidāmo darbību pēc labojuma, lai atskaiti var izmantot gan uzdevuma nodošanai, gan vēlākai kontrolei, neprasot katram nākamajam lasītājam no jauna iztulkot auditora ieceri.

Ja ziņojumā izmanto CVSS, prasiet nosaukt arī versiju: FIRST publicē CVSS, tostarp versiju 4.0, kuras bīstamības vērtējumu skalas apzīmējumi ir «nav» (0,0), «zema» (0,1–3,9), «vidēja» (4,0–6,9), «augsta» (7,0–8,9) un «kritiska» (9,0–10,0); šo vārdisko apzīmējumu izmantošana ir izvēles iespēja. Līdzās skaitlim prasiet pamatojumu un skaidrojumu par Jūsu uzņēmuma darbu, piemēram, kuru darbību vai datu kopumu konkrētais atradums skar un kāpēc ieteikts to labot šādā secībā, lai prioritāti var apspriest pēc aprakstītajiem apstākļiem, ne tikai pēc skaitļa.

Pieredzi ar šādām kritiskām kļūdām izmantojam, lai prasītu skaidru seku aprakstu, nevis lai apgalvotu, ka katrai vietnei vajadzīga pārbūve: ziņojumā jāspēj atšķirt konkrēts labojums no problēmas, kuras risināšanai jāpārskata sistēmas pamatdarbība. Ja atskaite paredz plašu pārstrādi, prasiet parādīt, kuri pierādījumi šo ieteikumu pamato, ko iespējams izlabot atsevišķi un kāds jautājums paliks neatrisināts, ja uzņēmums izvēlēsies tikai daļu no piedāvātā darba.

Skenera neapstrādātu rezultātu failu prasiet kā pielikumu, ja tas nepieciešams tehniskajai komandai, bet ziņojuma pieņemšanu saistiet ar pierādījumiem, prioritātēm un izpildāmiem labojumu ieteikumiem, kurus Jūs sagaidāt savā pasūtījumā; rindu daudzumu neizvēlieties par kvalitātes mēru. Palūdziet izpildītājam izskaidrot vienu atradumu no sākuma līdz beigām: kā tas konstatēts, ko rezultāts apliecina, kā tas skar Jūsu sistēmu un kā pēc izmaiņām pārliecināsies, ka tas novērsts, kā arī nosaukt visu, kas šajā secinājumā vēl ir pieņēmums; šāda izskatīšana dod konkrētu pamatu ziņojuma pieņemšanai un turpmākā darba sadalei.

Kāpēc audita cenas tik ļoti atšķiras

Cenas atšķiras galvenokārt tāpēc, ka piedāvājumi aptver atšķirīgu sistēmu skaitu un atšķirīgu darba dziļumu: automātiska skenēšana un versiju pārskats maksā simtos eiro, bet manuāli piekļuves kontroles un biznesa loģikas testi, pirmkoda pārskats un atkārtota pārbaude prasa eksperta darba dienas. Mūsu drošības audita pakalpojumā automatizētā drošības pārbaude maksā €89–890 atkarībā no tvēruma un paredzēta WordPress, Laravel, Drupal, Joomla un Moodle sistēmām. Piedāvājums ietver automātisku ievainojamību skenēšanu, versiju, spraudņu un atkarību pārbaudi, konfigurācijas un servera iestatījumu izvērtēšanu, kā arī atskaiti ar atradumiem un prioritātēm; šo saturu izmantojiet, salīdzinot cenu ar citu piedāvājumu, un precizējiet, kuras Jūsu instalācijas tiks pārbaudītas. Diapazona zemāko summu uztveriet saistībā ar saskaņoto tvērumu, lai vienas vietnes pārbaudes cenu nepārnestu uz visu uzņēmuma sistēmu kopumu, kura robežas izpildītājs vēl nav izvērtējis.

Mūsu manuālais eksperta audits ir pieejams, sākot no €3 500, un ietver manuālu pārbaudi pēc OWASP Top 10, piekļuves kontroles un biznesa loģikas apiešanas testus, pirmkoda pārskatu un atļautu ielaušanās testu. Pirmkoda pārskats paredzēta Laravel, WordPress un individuāli izstrādātiem risinājumiem, bet ziņojumā atradumus sakārtojam pēc reālā riska un katram pievienojam labojuma ieteikumu; piedāvājumā iekļauta arī atkārtota pārbaude pēc labojumiem. Vārdi «sākot no» paliek spēkā arī tad, ja Jūsu sistēmai ir tikai viena publiska adrese, jo cenu aprēķinam vēl jāsaskaņo funkcijas, lomas un pārbaudāmais kods.

Pilna pārbaude ar mūsu sistēmu parasti maksā €500–800. Tā ir summa, kādu mēs redzam visbiežāk automatizētās drošības pārbaudes cenu diapazonā, nevis atsevišķa cena par uzņēmuma pārvaldības, visu sistēmu un sertifikācijas kopīgu izvērtēšanu, tādēļ vārdu «pilna» saistiet ar konkrēto tehnisko tvērumu, kuru mēs esam saskaņojuši. Vairumam vietņu mēs iesakām regulāru automatizētu drošības pārbaudi, ko var atkārtot bieži, bet manuālo eksperta auditu, kad sistēma apstrādā maksājumus, personas datus vai ir kritiska biznesam, jo piekļuves tiesību kļūdas un biznesa loģikas apiešanu atrod tikai cilvēks; praksē labi strādā regulāra automatizētā drošības pārbaude un manuālais audits reizi gadā.

Šī atšķirība palīdz arī budžeta sarunā: ja Jums vajadzīgas atbildes par vietnes komponentēm un iestatījumiem, prasiet aprēķinu šim uzdevumam, bet, ja galvenais jautājums ir lietotāju tiesību vai biznesa noteikumu apiešana, iekļaujiet atbilstošos manuālos testus un ļaujiet izpildītājam atsevišķi novērtēt to darbu.

Salīdzināšanai sagatavojiet vienādu sistēmu, lietotņu, lietotāju lomu un, ja vajadzīga arī organizatoriskā daļa, arī uzņēmuma darbības vietu aprakstu, pēc tam lūdziet atsevišķi norādīt automātiskās un manuālās darbības. Iedomājieties cenu aprēķinu tikai publiskajai vietnei un otru tai pašai vietnei kopā ar klientu kabinetu, administrāciju un pirmkodu: pirms summu salīdzināšanas noskaidrojiet katra piedāvājuma robežas. Pie katras daļas fiksējiet arī nepieciešamās piekļuves, izvēlētos atbilstības kritērijus un ziņojuma saņēmēju, jo šādi izpildītājam dodat konkrētu pamatu aprēķinam un sev iespēju pamanīt izlaistu uzdevumu.

Atsevišķi precizējiet, vai cenā ir atradumu izskaidrošana Jūsu izstrādātājam, sasaistīšana ar izvēlētā standarta prasībām un atkārtota pārbaude, kā arī to, kur beidzas audita darbs un sākas labojumu izstrāde, un audita budžetā iesakām paredzēt lēmumu arī par konstatēto trūkumu novēršanu. Ja arī vienāda apjoma piedāvājumos cena joprojām būtiski atšķiras, lūdziet izpildītājiem izskaidrot darbu un tā robežas ar vienu konkrētu funkciju, piemēram, lietotāja piekļuves maiņu, nevis ar papildu pakalpojumu nosaukumiem; tā Jūs varēsiet izvēlēties pēc konkrēta rezultāta un atbildības, nepaļaujoties uz solījumu par visaptverošu drošību.

Kad uzņēmumam vajadzīgs drošības audits

Auditu iesakām pasūtīt, kad uzņēmumam jāpieņem konkrēts lēmums par drošību vai jāsniedz pārbaudāms apliecinājums, un jau sākumā nosaukt, vai lēmums attiecas uz pārvaldību, tehnisko stāvokli vai abiem. Ja iemesls ir NIS2, vispirms noskaidrojiet savu statusu un piemērojamās prasības, izmantojot arī mūsu rakstu par NIS2 un tās tvērumu, pēc tam formulējiet darba uzdevumu. Šeit svarīga ir secība: prasības piemērojamību un vajadzīgo apliecinājumu noskaidrojiet pirms pakalpojuma izvēles, lai tehniska ziņojuma pasūtīšana nekļūtu par Jūsu vienīgo atbildi uz jautājumu, kurā vēl jāizvērtē arī uzņēmuma atbildība un procesi. Ja vietnei nav lietotāju kontu, maksājumu vai personas datu apstrādes un neviens neprasa apliecinājumu, plašs audits parasti nav vajadzīgs: vispirms uzstādiet atjauninājumus, un pietiek ar automatizētu drošības pārbaudi.

Ja pārbaudi pieprasa apdrošinātājs vai klients, palūdziet precizēt sagaidāmo rezultātu un izpildītājam nododiet pašu prasības tekstu; piemēram, jautājumu par darbinieku apmācību vai dublējumkopijas atjaunošanas pārbaudi nodaliet no prasības pārbaudīt lietotnes piekļuves tiesības; atbildēm sagatavojiet atbilstošus pierādījumus. Ja piegādātāja anketā jāapliecina plašāks drošības process, nekā Jūsu tehniskais audits aptver, lūdziet klientu vienoties par papildu informāciju un uzņēmumā nozīmējiet cilvēku, kurš to savāks, nevis paplašiniet tehniskā ziņojuma nozīmi; vienlaikus precizējiet, vai saņēmējs gaida pašu atskaiti, atbildes uz konkrētiem jautājumiem vai citu apliecinājuma formu un termiņu.

Iepirkumam saglabājiet prasīto pārbaudes veidu un izpildītāja kvalifikācijas nosacījumus tieši tā, kā pasūtītājs tos formulējis, un neskaidrības noskaidrojiet pirms cenas pieprasīšanas, lai piedāvājumu nevajadzētu pārrakstīt pēc darba sākuma. Detalizētāk izvēli izskatām rakstā par iepirkumā prasīto drošības pārbaudi, bet tehniskā uzdevuma sagatavošanai varat atsūtīt mums prasības formulējumu un sistēmas aprakstu. Norādiet arī iesniegšanas datumu, pieejamo dokumentāciju un to, kurš Jūsu pusē veiks labojumus, jo sarunai par pārbaudes izpildi jāaptver ne tikai atskaites sagatavošana, bet arī Jūsu komandas iespēja līdz vajadzīgajam datumam strādāt ar tās rezultātiem.

Pēc incidenta un starp plānotajām pārbaudēm

Pēc incidenta audita uzdevumu iesakām pakārtot konkrētajam neatbildētajam jautājumam: vai labojums novērš konstatēto problēmu, vai līdzīga piekļuves kļūda jāmeklē citā funkcijā un kā uzņēmumā turpmāk pārbaudīs attiecīgās kārtības izpildi. Nododiet izpildītājam zināmo notikumu aprakstu un nodaliet apstiprinātos faktus no pieņēmumiem. Ja vēlaties noskaidrot notikušā gaitu, arī šo darbu nosauciet atsevišķi un vienojieties par tā rezultātu, nepieņemot, ka vispārīgs vietnes audits automātiski atbildēs uz visiem incidenta jautājumiem; savukārt pārbaudāmajiem labojumiem saglabājiet sasaisti ar sākotnējiem atradumiem, lai pēc izmaiņām varētu pateikt, kuru problēmu tieši pārbaudījāt vēlreiz un kā.

Mūsu klienti auditu parasti pasūta vienu vai divas reizes gadā; tas ir mūsu pieredzes novērojums, nevis visiem uzņēmumiem noteikts intervāls. Jūsu plānā iesakām līdzās nākamajam datumam ierakstīt arī izmaiņas, pēc kurām vēlreiz izvērtēsiet pārbaudes apjomu, piemēram, jaunu lietotāju lomu, pārrakstītu piekļuves funkciju vai nomainītu piegādātāju ar tiesībām sistēmā. Atbildīgajam cilvēkam uzticiet salīdzināt šīs izmaiņas ar iepriekšējā audita tvērumu un piedāvāt konkrēto pārbaudāmo daļu, bet iepriekšējās atskaites neatrisinātos atradumus saglabājiet nākamā darba uzdevumā kopā ar lēmumiem par to atlikšanu, lai jaunā pārbaude sāktos ar zināmo situāciju.