SIEM ieviešana: no tvēruma līdz pieņemšanai

Vienojieties par pirmo rezultātu

Nosauciet aizsargājamo pakalpojumu, projekta īpašnieku un lēmumu pieņēmēju. Izvēlieties sākotnējos scenārijus, kuri ir svarīgi jūsu videi un kuriem var iegūt vajadzīgos datus. Piemēram, privileģētas piekļuves izmaiņas vai negaidīta rezerves kopiju politikas maiņa ir pārbaudāmāki uzdevumi nekā vispārīgs mērķis atklāt visus uzbrukumus.

Apstipriniet arī robežas: sistēmas ārpus tvēruma, neiegūstamie dati un sākotnēji nepieejamās reaģēšanas darbības. Katrai robežai vajadzīgs īpašnieks vai pārskatīšanas lēmums. Ja pilotam nepieciešama administratora piekļuve, iepriekš vienojieties par tās apjomu, izmantošanas uzskaiti un atcelšanu pēc darba.

Veidojiet datu plūsmu ar atbildīgo

Sagatavojiet avotu sarakstu, kolektoru izvietojumu, piekļuves nosacījumus un tīkla savienojumus. Pārbaudiet, vai avoti spēj eksportēt vajadzīgos ierakstus un vai licencēšanas ierobežojumi to pieļauj. Administrēšanas kontiem piešķiriet tikai nepieciešamās tiesības. Integrācijas kļūdu labošana nedrīkst kļūt par pastāvīgu pamatojumu pārmērīgi plašai piekļuvei.

Pirmajā pilotā izmēriet saņemto apjomu, aizkavi, dublikātus un formāta kļūdas. Salīdziniet notikumu avotā ar ierakstu analīzes sistēmā. Ja laiks vai lietotāja identifikators interpretēts nepareizi, korelācijas rezultāts var maldināt. Pirms jaunu avotu pievienošanas novērsiet šādas pamata problēmas.

Pārbaudiet scenāriju visā ķēdē

Katram atklāšanas scenārijam aprakstiet vajadzīgos avotus, signāla loģiku, sagaidāmo analītiķa rīcību un izņēmumus. Izmēģiniet drošu, iepriekš atļautu testa darbību. Pārbaudiet, vai brīdinājums satur pietiekamu kontekstu un nonāk pie pareizā cilvēka. Testa veikšanas atļauja un iespējamā ietekme ir daļa no sagatavošanās.

Testējiet arī normālu darbību, kura var izskatīties aizdomīga. Apkopes logs vai apstiprināta administratora darbība palīdz novērtēt troksni. Izņēmumam jābūt šauram un dokumentētam; citādi kļūdaini pozitīva signāla novēršana var izslēgt vērtīgu noteikšanu. Saglabājiet noteikuma versiju un pārbaudes rezultātu, lai izmaiņas varētu pārskatīt.

Pieņemiet pakalpojumu, ne tikai tehnoloģiju

Pieņemšanā pārbaudiet, kurš uztur integrācijas, labo parsēšanu, pārskata noteikumus un saņem eskalāciju. Atsevišķi apstipriniet cilvēku darba laiku un pilnvaras incidenta ierobežošanai. Ja tiek lietots SLA, tam jānosaka mērāma darbība un laika atskaites punkts. Sistēmas pieejamība un analītiķa atbildes laiks ir atšķirīgi rādītāji.

Lūdziet piemēra incidenta darba ierakstu ar secinājumiem un turpmāko darbību. Pārbaudiet, vai organizācijas komanda saprot ziņojumu un prot izmantot saziņas kanālu. Dokumentējiet, kur glabājas izmeklēšanas pierādījumi un kam tiem ir piekļuve. Veiksmīga pieņemšana nozīmē, ka abas puses zina savu nākamo soli.

Ieplānojiet uzturēšanu jau sākumā

Vienojieties par pārskatīšanu pēc būtiskām sistēmu, licenču, formātu vai komandu izmaiņām. Jauns savienotājs vai cita autentifikācijas kārtība var mainīt esošā noteikuma darbību. NIST incidentu reaģēšanas vadlīnijas sasaista gatavošanos, atklāšanu, reaģēšanu un pilnveidi; arī monitoringa projektam vajadzīga šī atgriezeniskā saite.

Projekta noslēgumā nododiet avotu reģistru, scenāriju pārbaudes, piekļuves sarakstu, eskalācijas kārtību un uzturēšanas īpašniekus. Pierakstiet atlikušos ierobežojumus. Laika plānu un pieņemšanas datumus nosakiet pēc faktiskās vides izpētes, nevis universāla solījuma par ieviešanu noteiktā nedēļu skaitā.

Atbildību par pārmaiņām sadaliet jau pilotā. Ja avota īpašnieks maina audita politiku, monitoringa komanda par to jāinformē; ja analītiķis maina noteikumu, jābūt iespējai redzēt pamatojumu un pārbaudi. Iekļaujiet ieviešanas plānā drošu atkāpšanās kārtību neveiksmīgai konfigurācijai. Zināms iepriekšējais stāvoklis un saskaņots izmaiņu logs palīdz labot kļūdu, nepalielinot sistēmas nepieejamību vai nezaudējot vajadzīgos notikumus pārejas laikā.