SIEM, SOC un MDR: ko jūs patiesībā pērkat?
Šie trīs saīsinājumi bieži ir vienā piedāvājumā, taču tie neatbild uz vienu jautājumu. SIEM raksturo tehnoloģisku spēju, SOC – organizētu darbu, bet MDR – pakalpojuma modeli ar konkrētu tvērumu.
SIEM apkopo kontekstu
SIEM apvieno drošības notikumus no dažādiem avotiem, ļauj tos meklēt un sasaistīt atklāšanas scenārijos. Identitātes pieteikšanās, galaiekārtas darbība un tīkla savienojums kopā var dot vairāk konteksta nekā katrs ieraksts atsevišķi. Tomēr platforma redz tikai tos datus, kurus tai piegādā un kurus tā spēj pareizi interpretēt.
Microsoft Sentinel dokumentācija ir konkrētas SIEM platformas piemērs: tā apraksta datu izmantošanu noteikšanai, izmeklēšanai un reaģēšanai. Tas nav solījums, ka jebkura uzstādīta SIEM instance automātiski veic šos uzdevumus jūsu vidē. Pircējam jāprasa, kuri scenāriji būs ieviesti, kādi avoti tiem vajadzīgi un kā tiks pārbaudīta darbība.
SOC ir cilvēku un procesu funkcija
SOC jeb drošības operāciju centrs organizē signālu izvērtēšanu, izmeklēšanu, eskalēšanu un spēju uzlabošanu. Tas var būt iekšējs, ārējs vai dalīts. Būtiski ir pienākumi, pieejamība un lēmumu pieņemšana, nevis atsevišķas telpas vai ekrānu siena. Iekšējais IT administrators var palīdzēt, bet viņa ikdienas noslodze jāņem vērā plānā.
Skaidri nodaliet automātisku datu saņemšanu no cilvēka darba laika. Sistēma var saņemt ierakstus naktī, kamēr pirmā analītiķa pārbaude notiek nākamajā rītā. Ja vajadzīga reakcija ārpus darba laika, vienojieties par dežūrām, aizvietošanu un lēmuma pieņēmēju. Nosaukums SOC pats par sevi nenosaka šos nosacījumus.
MDR pakalpojumu nosaka līgums
MDR parasti apvieno pārvaldītu draudu atklāšanu, izmeklēšanu un reaģēšanas atbalstu. Praktiskais saturs var atšķirties: viens pakalpojums fokusējas uz galaiekārtām, cits aptver arī identitātes, mākoņvidi un tīklu. Noskaidrojiet, vai sniedzējs tikai iesaka izolēt ierīci vai drīkst to izdarīt pats un kā šāds lēmums tiek dokumentēts.
EDR palīdz atklāt draudus darbstacijās un serveros, izmeklēt aizdomīgas darbības un reaģēt uz tām. Tas var būt svarīgs MDR datu avots, taču nav sinonīms visam monitoringa tvērumam. Kritiskai biznesa lietotnei vai mākoņa administrēšanas darbībai var būt vajadzīgi atsevišķi avoti. Neizdariet secinājumu par pārklājumu no viena produkta nosaukuma.
Salīdziniet vienādu uzdevumu
Pirms piedāvājumu salīdzināšanas sagatavojiet vienu prasību lapu: sistēmas, avoti, vēlamie scenāriji, analītiķu darba laiks, eskalācijas kontakti un ierobežošanas pilnvaras. Lūdziet katram sniedzējam atzīmēt, kas ir iekļauts, kas jānodrošina jums un kas maksā atsevišķi. Tas palīdz pamanīt atšķirību starp licenci, sākotnējo ieviešanu un regulāru operāciju darbu.
Pārbaudiet arī aiziešanas nosacījumus. Kam pieder noteikumi un izmeklēšanas materiāli? Kā saņemsiet savus datus? Kas noņems ārējās piekļuves? Saprotams pakalpojums apraksta gan ikdienas darbu, gan izmaiņas un izbeigšanu. Šī pārbaude bieži atklāj pienākumu robežas agrāk nekā tehniska demonstrācija.
Pārbaudiet ar scenāriju
Izvēlieties droši veicamu piemēru, piemēram, testa konta lomas maiņu ar iepriekšēju atļauju. Izsekojiet ceļu no avota līdz signālam, analītiķa izvērtējumam un atbildīgās personas paziņojumam. Pierakstiet, kas bija redzams un kas palika ārpus pārbaudes. Pieņemšanas kritērijam jābūt novērojamam rezultātam, nevis apgalvojumam, ka sistēma ir ieslēgta.
Darba sarunā dodiet abām pusēm vienu un to pašu piemēru: kritiska lietotāja konts veic negaidītu administratīvu darbību. Lūdziet izskaidrot, kurš avots to parādīs, kurš pārbaudīs biznesa kontekstu un kurš varēs apturēt turpmāko darbību. Ja atbilde balstās tikai uz produkta funkciju sarakstu, pienākumu sadalījums vēl nav gatavs. Pirms budžeta apstiprināšanas ierakstiet šo sadalījumu piedāvājuma pielikumā un norādiet neatrisinātos jautājumus.