Metricile reprezinta acele valori numerice care determina randamentul, eficienta si performanta unui sistem, a unei aplicatii sau a unei persoane. Multe organizatii pun accent pe acesti parametri pentru a vedea daca si cum sunt indeplinite obiectivele business-ului si daca asteptarile managerilor, clientilor si actionarilor sunt satisfacute. Intr-o organizatie totul trebuie sa poate fi masurabil, inclusiv activitatea SOC-ului (Security Operations Center). Insa trebuie avuta grija la metricile folosite in acest caz pentru ca unele dintre ele au potentialul de a incuraja comportamente negative. O metrica foarte populara intr-un SOC este MTTR – mean time to resolution sau timpul mediu de remediere al unui incident. Desi pentru un NOC (network operation center) acest parametru este unul valid, intrucat aici conteaza foarte mult uptime-ul, poate fi daunator intr-un SOC intrucat stimuleaza analistii de securitate sa inchida rapid incidentele, fara a-i incuraja sa conduca o investigatie amanuntita care sa ofere feedback masurilor de control implementate pentru a preveni incidentele similare. In acelasi mod, masurarea performantei unui analist dupa numarul de tichetele preluate il poate face pe acesta sa „culeaga” acele incidente pe care stie ca le poate rezolva rapid. Ceea nu nu produce rezultate mai bune sau nu reduce riscul asupra organizatiei. Un alt exemplu de metrica nepotrivita pentru un SOC este numarul de reguli de firewall aplicate politicilor de acces la resursele organizatiei. Pot fi configurate 1000 de reguli, dar daca prima regula le sunteaza pe celelalte (permit any any – am vazut aceasta regula nu doar o data in retele de productie, din pacate), atunci sunt inutile.
Metricile bune sunt derivate din misiunea SOC-ului si din valoarea pe care acesta trebuie sa o aduca business-ului. Organizatia isi doreste ca SOC-ul sa poate preveni atacurile informatice si ca daca sau cand o bresa de securitate are loc, SOC-ul sa poate interveni rapid, sa minimizeze impactul asupra activitatii si sa invete din atac pentru a preveni incidente asemenatoare. Metricile bune trebuie sa ofere date relevante pentru ca organizatia sa decida daca are incredere in activitatea si capabilitatile SOC-ului, iar aceasta incredere este de doua feluri:
- Increderea in configuratie – este atunci cand sistemele hardware si software de securitate sunt configurate corespunzator pentru a preveni un atac, cand exista un plan de raspuns la incident aplicat automat si cand se pot colecta informatii relevante pentru partea de analiza post incident
- Increderea operationala – este atunci cand SOC-ul are oamenii si procesele potrivite pentru a se ocupa de o bresa daca sau atunci cand aceasta are loc
Pentru a determina nivelul de incredere in configuratii, organizatia trebuie sa se intrebe daca:
- Masurile de securitate functioneaza. De exemplu, un dezvoltator are nevoie sa testeze o aplicatie si are nevoie sa foloseasca un anumit port. Echipa SecOps configureaza regulile de port forwarding in firewall de acces, si uita sa le stearga/dezactiveze dupa ce developer-ul isi face testul, ceea ce ofera unui hacker o portita de intrare in retea.
- Au loc modificari „ad hoc” in politicile de acces in reteaua organizatiei. Modificarile trebuie sa fie facute intotdeauna conform procedurilor stabilite, chiar daca este un proces consumator de timp. Orice deviatie de la procedura scade nivelul de incredere in masurile de control implementate.
- Sistemele de securitate implementate adera la bunele practici in domeniu. Securitatea organizatiei este un organism viu, si respectarea bunelor practici trebuie evaluata periodic.
- Foloseste tehnologia implementata la adevarata valoare. Altfel spus, cat la suta din functiile de care este capabil un sistem sunt utilizate de SOC. Multe tehnologii achizitionate de organizatie sunt prea putin folosite la adevaratul potential, ceea ce face ca organizatia sa aiba un fals sentiment de securitate, si o sa o motiveze sa achizitioneze si alte tehnologii cu rol similar, ceea ce duce la si mai multe sisteme de administrat si monitorizat fara sa aduca vreun plus de valoare. De exemplu, un firewall care este capabil de inspectia traficului SSL, dar care nu este folosit in acest sens. O mare parte din trafic, peste 80%, este trafic criptat, care poate contine malware. Analistii nu pot vedea malware-ul ascuns in traficul criptat si nu pot bloca respectivele amenintari, decat daca au vizibilitate si implementeaza inspectia SSL.
Pentru a determina nivelul de incredere operationala organizatia trebuie sa se intrebe:
- Cate evenimente sunt procesate de un analist intr-o ora. Aceasta metrica nu trebuie sa fie folosita pentru a compara angajatii din SOC, ci pentru a evalua eficienta intregii echipe de SecOps. Un numar mare de evenimente procesate poate indica un grad mare de alerte prelucrate manual si ca sistemele de triere si de determinare a alertelor fals pozitive trebuie sa fie evaluate. Procesarea unui numar mare de alerte duce la oboseala pentru analist, care ii va scadea eficienta si evident va impacta increderea operationala in SOC.
- Daca centrul SOC se ocupa de incidente de securitate care au mai avut loc si in trecut. Daca evenimentele sunt investigate corespunzator, atunci concluziile trebuie sa fie introduse in masurile de control pentru a opri pe viitor atacuri similare. Daca SOC-ul se ocupa de incidente recurente similare, atunci bucla de reactie nu este corect implementata, ceea ce duce la timp pierdut si o eficienta scazuta a centrului de operatiuni de securitate.
- Daca centrul SOC se ocupa de alerte pentru amenintari cunoscute. Amenintarile cunoscute ar trebui sa fie blocate inainte ca acestea sa poata afecta organizatia si sa fie analizate de SOC. Acest lucru inseamna ca masurile de securitate sunt configurate necorespunzator.
- Daca sunt devieri in procedurile pe care SOC-ul trebuie sa le urmeze. Aceasta metrica indica nevoie de instruire pentru un analist si poate semnala faptul ca anumite proceduri nu mai sunt atat de relevante pentru business case si e nevoie de actualizarea lor.
Metricile trebuie sa fie folosite pentru a imbunatati masurile de protectie implementate si pentru a convinge organizatia ca echipa SecOps isi indeplineste misiunea de a preveni, remedia si mitiga atacurile informatice cu impact minim asupra business-ului. Metricile din SOC trebuie sa masoare si calitatea muncii, nu doar volumul. Fiecare metrica luata individual nu poate oferi o imagine de ansamblu asupra eficientei SOC-ului, dar impreuna arata ca organizatia este protejata corespunzator si ca SOC-ul este capabil sa previna amenintarile si raspunda in fata unui atac informatic.
Mihai Dumitrascu, Sr Systems Engineer
