Cybersecurity Back to Basics: Incident Response

Čak i uz dobre preventivne mere i odličnu vidljivost nad IT okruženjem, bezbednosni incidenti će se dešavati.

Pitanje nije da li će se dogoditi, već kada i koliko ćete biti spremni da na njih odgovorite.

Incident Response (IR) je strukturisan proces otkrivanja i obuzdavanja bezbednosnih incidenata, kao i oporavka nakon njih.

Posle više od dve decenije rada u sajber bezbednosti, jedna stvar se stalno potvrđuje: kompanije koje se najbolje snalaze tokom krize nisu one koje imaju najviše alata. To su one koje su se unapred pripremile.

Pročitajte prethodne tekstove iz serijala Cybersecurity Back to Basics.

Zašto je Incident Response važan?

  • Brzina i kvalitet reakcije direktno utiču na razmere štete, troškove i reputaciju organizacije.
  • Regulative poput NIS2 zahtevaju od organizacija sposobnost da otkriju incidente, odgovore na njih i oporave se.
  • Haotična reakcija često može da napravi više štete od samog incidenta: izgubljeni dokazi, izgubljeno vreme, prebacivanje odgovornosti... lista može biti prilično duga.
  • Dobar Incident Response omogućava da iz svakog incidenta nešto naučimo i unapredimo bezbednost.

Back to Basics principi Incident Response-a

1. Priprema je najvažnija faza

Ono što uradite pre incidenta u velikoj meri određuje koliko ćete uspešno reagovati kada se incident dogodi.

To podrazumeva da imate plan, jasno definisane uloge, unapred određene kanale komunikacije i pristup informacijama i alatima koji će vam biti potrebni.

Da, to uključuje i pristup „čistim“ računarima koje možete bezbedno koristiti tokom incidenta.

2. Napravite jednostavan i praktičan plan

Incident Response plan ne mora da bude dokument od 100 strana.

Mora da bude jasan, primenljiv i poznat ljudima koji treba da ga koriste.

Drugim rečima, njegova svrha nije samo da postoji kako biste tokom provere usklađenosti mogli da kažete: „Da, imamo Incident Response plan.“

Plan bi trebalo da definiše najmanje:

  • uloge i odgovornosti,
  • način i nivoe eskalacije,
  • šablone za komunikaciju,
  • kriterijume za donošenje ključnih odluka.

3. Pratite jasan proces

Incident Response može se organizovati kroz nekoliko osnovnih koraka:

  1. Detection & Analysis, otkrivanje i analiza
  2. Containment, obuzdavanje incidenta
  3. Eradication, uklanjanje pretnje
  4. Recovery, oporavak
  5. Post-Incident Review, analiza nakon incidenta i naučene lekcije

Poslednji korak je posebno važan, a vrlo često se zanemaruje.

4. Prvo zaustavite širenje incidenta

U ranim fazama prioritet je da „zaustavite krvarenje“.

Fokusirajte se na ograničavanje mogućnosti napadača da se dalje kreće kroz okruženje ili napravi dodatnu štetu, pre nego što krenete u detaljnu forenzičku analizu.

Međutim, iako je obuzdavanje jedan od najvažnijih koraka, ne dozvolite da žurba ugrozi ono što sledi.

Na primer, ako odmah reinstalirate kompromitovanu radnu stanicu, možda ćete zaustaviti deo problema, ali ćete istovremeno uništiti važne dokaze koji su vam potrebni da biste razumeli šta se zapravo dogodilo.

5. Komunikacija je ključna

Unapred odredite ko treba da bude obavešten, kada i kojim putem.

U zavisnosti od incidenta, to mogu biti:

  • interni timovi,
  • menadžment,
  • pravni tim,
  • eksterne strane,
  • korisnici ili klijenti, kada je to potrebno.

Loša komunikacija tokom incidenta stvara konfuziju i dodatni rizik.

Posebno obratite pažnju na kanal kojim komunicirate. I on može biti kompromitovan.

Zato unapred razmislite: Kako ćemo komunicirati ako naši uobičajeni sistemi za komunikaciju nisu bezbedni ili dostupni?

To nije pitanje koje želite prvi put da postavite usred incidenta.

6. Učite i unapređujte proces

Svaki incident treba da se završi analizom u kojoj cilj nije traženje krivca.

Postavite nekoliko jednostavnih pitanja:

Šta je funkcionisalo?

Šta nije funkcionisalo?

Šta treba da promenimo kada su u pitanju ljudi, procesi ili tehnologija?

Incident Response proces treba da bude bolji nakon svakog incidenta.

Šta možete da uradite već danas?

  • Napišite ili ažurirajte kratak i praktičan Incident Response plan. Možete početi od postojećeg primera sa interneta ili koristiti AI da napravite osnovu, a zatim ga obavezno prilagodite svom okruženju.
  • Jasno definišite uloge. Ko vodi odgovor na incident? Ko je zadužen za tehničko obuzdavanje? Ko upravlja komunikacijom?
  • Pobrinite se da možete brzo da pristupite ključnim informacijama, kao što su evidencija IT resursa, mrežni dijagrami, liste kontakata i sistemi za logovanje, čak i kada njihove uobičajene lokacije nisu dostupne. Nema mnogo koristi od mrežnog dijagrama koji se nalazi samo na SharePoint serveru ako je taj server tokom incidenta nedostupan ili su podaci na njemu šifrovani.
  • Pripremite osnovne šablone za internu i eksternu komunikaciju.
  • Sprovedite jednostavnu tabletop vežbu najmanje jednom ili dva puta godišnje. Još bolje, koristite Breach and Attack Simulation (BAS) kako biste proverili da li sve zaista funkcioniše kako treba: sistemi za detekciju, prevenciju i zaštitu, ali i ljudi, procesi i reakcije. Ako nemate resurse da ovo uradite samostalno, uključite partnera (na primer Net++ technology) koji vam može pomoći.
  • Proverite da li su logging i backup pouzdani. Oba su ključna tokom odgovora na incident i oporavka. I da ponovimo još jednom: molimo vas, imajte dobar backup.

Najčešća greška

Jedna od najčešćih grešaka je tretiranje Incident Response plana kao dokumenta koji postoji samo zbog compliance zahteva.

Ako tim nikada nije vežbao njegovu primenu ili zaposleni čak ne znaju gde se plan nalazi, velika je verovatnoća da neće mnogo pomoći kada vam bude najpotrebniji.

Viđali smo organizacije sa skupim i naprednim bezbednosnim alatima koje su se veoma loše snalazile tokom incidenta jer niko nije znao ko je odgovoran ili šta treba prvo uraditi.

Sa druge strane, timovi sa relativno jednostavnim alatima, ali jasnim planom, uvežbanim ulogama i kvalitetnim logovima često mnogo brže obuzdaju incident i prođu sa znatno manjom štetom.

Kao i u stvarnom životu, Incident Response i cybersecurity timovi moraju da vežbaju. Reakcija na incident ne bi trebalo prvi put da se isprobava onda kada se incident zaista dogodi.

Priprema je bolja od panike.

Izvor: LinkedIn Pulse by Vladimir Vučinić