Mòdul Professional 1: Incidents de ciberseguretat - Resposta a incidents

Índex

La resposta a incidents és una funció o activitat molt especialitzada i com a conseqüència acostuma a quedar reflectida com un departament o equip especialitzat dins l'organigrama de l'empresa, normalment emmarcat en el que coneixem com a blue team.

Lògicament aquest equip, depenent del mida de l'organització, pot ser un equip dedicat (més o menys petit) o pot tenir assignades altres funcions. Tanmateix, i com veurem més endavant, el core acostuma a estar constituït per personal especialitzat.

1 Creació de l'equip de respostes a incidents

Com hem vist anteriorment, el CEO de l'organització crea la política de seguretat i dins d'aquesta estableix els objectius a assolir en aquesta matèria. Si un dels objectius és precisament, o se'n deriva, la resposta a incidents aleshores esdevindrà aquest equip mitjançant una subpolítica creada pel CSO o CISO, d'aquesta forma tindrà la força legal per poder actuar sobre tota l'organització.

També caldrà definir de forma molt clara durant la seva constitució el seu abast, objectius i serveis proactius i relatius que donarà tant internament a l'organització com externament a terceres entitats.

L'equip de resposta a incidents s'anomena normalment CSIRT (Ciber Security Incident Response Team).

2 El procés de la resposta a incidents

Les fases de la resposta a incidents són: fases_IR.png

2.1 Preparació

En aquest punt bàsicament s'estableixen el pla, s'aprovisiona l'equip amb els recursos necessaris incloent la formació i es realitzen simulacres.

També d'estableixen els mecanismes necessaris per a detectar incidències.

2.2 Detecció

La detecció succeïx en algun dels "sensors", ja sigui SOC, SIEM, Help Desk, agents externs o els propis usuaris.

Un cop realitzada la detecció caldrà que passi per una fase de triatge on es descartin falsos positius i es categoritzi la incidència per categoria i per grau de importància.

2.3 Anlàlisi

En aquesta fase es recolliran dades com logs, memòria volàtil, memòria no volàtil, etc per fer un anàlisi forense que permeti determinar el tipus d'incident de forma molt concreta, la gravetat i l'abast.

2.4 Contenció

Un cop determinats l'abast i la natura de la incidència, caldrà contenir-la per a que no s'expandeixi per l'organització, minimitzant els danys que pugui ocasionar.

2.5 Erradicació i recuperació

Es tractaran els equips per eliminar l'amenaça i tornar-los a producció aixi com verificar que aquests elements ja no són vulnerables a aquest tipus d'atacs.

Aquestes millores de seguretat per fer invulnerables l'equip caldrà fer-les extensives a tota l'organització.

2.6 Activitats post incidents

Es farà un repàs de tot el procés el·laborant un memoràndum i cercant millorar el procés de resposta d'incidents

3 El CSIRT

3.1 Personal dins CSIRT

3.1.1 Core team

Aquest equip està format per personal de l'organització que té assignades funcions del CSIRT com a part de les seves assignacions diàries. Depenent del tamany de l'organització això pot significar que la seva dedicació al CSIRT és complerta o la compaginen amb altres assignacions en altres equips.

IR Coordinator
Serà el màxim responsable de l'equip i acostuma a ser el CSO, CISO o el ISO (Informaticon Securty Officer). Com a tal serà normalment el gestor tant pre-incident, incident i post-accident de l'equip alhora que el canal de comunicació amb el CEO.
CSIRT Analista senior
Personal amb gran experiència amb el rol de CSIRT i forense. Són el pal de paller alhora de realitzar totes les tasques del CSIRT (plans, formació, IR) i les realitzen o supervisen amb el suport de la resta de membres.
CSIRT Analista
Analista amb menys experiència dins del CSIRT i encara en fase de formació i expertessa.
SOC Analista
Alguns dels membres del SOC es poden incorporar en l'equip CSIRT per incorporar algú amb experiència en la detecció i anàlisi de incidències. D'aquesta manera pot servir com a triager dins de SOC per veure si cal elevar una incidència al CSIRT de forma immediata.
Enginyier / analista de seguretat IT
La incorporació d'aquests perfils al CSIRT permet, en la fase de preparació, preparar millor les mesures de seguretat per a que detectin les incidències, així com accedir-hi i recollir evidències en la fase d'anàlisi. En post-incident poden desplegar les millores en seguretat alhora que monitoritzar per verificar que la contenció ha estat efectiva.

3.1.2 Technical support personnel

Aquest personal no té assignació dins del equip del CSIRT però hi dona assistència tècnica segon les demandes que aquest faci, sobretot durant una incidència.

Administrador/Arquitecte de xarxes
Sempre que es vegin compromesos elements de xarxa, l'administrador pot facilitar la gestió d'una incidència compartint l'expertesa per saber quin tràfic és anòmal dins la xarxa de l'organització així com obtenint evidències sobre els elements de xarxa i aplicant-hi pegats.
Administrador de sistemes
Quan els servidors es veuen compromesos, la seva assistència pot ser crítica.
Suport a aplicacions
En tractar temes de APPs de l'empresa.
Tècnics informàtics
Aquest que donen suport dia a dia a les estacions de treball.
Help Desk
Ens poden ser molt útils per detectar incidències i reseguir-les, per això ñes important que estiguin formats en la identificació d'incidències.

3.1.3 Organizational support personnel

A nivell organitzatiu, el CSIRT també necessita suport per dur a terme les seves tasques. Aquest suport acostuma a ser:

Legal
El Departament Legal de l'empresa caldrà que estigui informat de les incidències ja que aquestes poden tenir repercussions sobre les obligacions legals de l'empresa. Per tant cal avisar-los i establir canals de comunicació el més aviat possible.
Recursos humans
Quan una incidència s'origina per una causa humana interna, o té relació (phising, insider,etc) cal establir canals de comunicació amb RRHH per a que determini si s'han de despendre responsabilitats.
Marketing / Comunicacions
Quan una incidència pot afectar als clients externs o proveidors, caldrà implicar al Dept. de Marketing, junt amb el Legal, per a que el·laborin i publiquin el missatge adeqüat (que compleixi amb la legalitat alhora que minimitzi els danys a l'imatge de l'organització). També s'encarrega de contactar amb terceres parts com per exemple proveidors que pugin haver estat la font o mitjà del atacs, CERTs, etc.
Consergeria
Molts cops el tractament d'una incidència comporta accés a les insta·lacions i àrees que normalment el CSIRT no té accés, o a hores fora del marc laboral. Per tant caldrà la participació del personal de "consergeria" per facilitar aquest accés.
Seguretat interna
Referit a seguretat física (policia, guarda-jurat, etc.) pot ser necessari en cas d'insider o incidència que impliqui un accés o component físic en les instal·lacions.

3.1.4 External resources

Com a personal extern queden encabits aquelles organitzacions on hi tenim relacions o obligacions contractuals o legals i que cal col·laboració en el cas d'un incident de seguretat. Aquestes són:

CERT
Per llei estem obligats a informar sobre les incidències de seguretat patides, a més, poden proporcionar formació, pre-alertes i assistència durant tot el procés.
Cossos de seguretat
En cas de voler denunciar o simplement per a que puguin donar feedback o pre-alertes sobre tendències.
Proveidors
Si detectem que han estat utilitzats per generar la incidència, cal avisar-los de que tenen una incidència de seguretat.

3.2 Models de CSIRT

El funcionament i sobretot el triage i escalada d'una incidència depèn en gran mesura del model o encaix que tingui el CSIRT dins l'organització. Podem observar varis models:

3.2.1 CSIRT

En cas que el CSIRT sigui un element solitari, les incidències vindràn reportades principalment pels propis usuaris, fen un triage el personal de Help Desk o els tècnics del departament de IT.

Aquest és l'escenari més petit i alhora on l'escalada és més lenta i s'obtenen menys dades sobre l'incidència.

3.2.2 SOC

Si es disposa d'un SOC intern o extern, aleshores el SOC Manager serà qui reporti al CSIRT Manager les incidències. Per tant és el SOC qui fa el triatge inicial.

Aquest sistema presenta l'avantatge que que el SOC té una actitut pro-activa i cerca de forma activa qualsevol incidència a IT, i a més ens estalviem falsos positius ja que el primer triatge que fan ja assegura que es tracta d'una incidència. Tanmateix, un cop aquesta arriba al CSIRT caldrà un segon triatge per determinar la natura i sobretot la gravetat. A més es pot perdre informació durant la comunicació entre departaments.

CSIRT_Separat.png

3.2.3 CSIRT + SOC

Si integrem els dos departaments i subeditem el SOC dins del CSIRT obtenim una simplificació en la cadena de comunicacions alhora que podem controlar millor quina informació es considera rellevant (i per tant cal recabar en el primer triatge) per catalogar l'incidència.

CSIRT+SOC.png

3.2.4 CSIRT Fusion Center

Finalment, i seguint les noves tendències, el SOC pot "evolucionar" i esdevenir un Departament de Intel·ligencia d'Amenaçes, fent "threat hunting" de forma activa i proporcionant per part seva prevenció i quan detecten que una amenaça es materialitza activant el CSIRT.

Tanmateix, això implica la fusió de tres departaments (CSIRT, SOC i Intel·ligència) amb la qual cosa l'estructura és molt gran i poques organitzacions tenen els recursos suficients per implementar-ho.

FusionCenter.png

3.3 Warroom

Com a warroom entem l'espai físic utilitzat per a coordinar la resposta a incidents. Tot i que sembli tribal, és important que es contemplin algunes necessitats operatives per assegurar que totes les tasques a realitzar, junt amb la coordinació, es poden fer de forma eficaç i sense limitacions. Aquesta pot ser fixa i exclusiva o temporal i sota demanda, alhora que també pot ser física o digital en alguns aspectes, però en qualsevol cas cal que compleixi amb:

Espais de treball
Llocs i equipaments adequats per a realitzar les tasques (forense, etc).
Team Displays
Projectors o pantalles grans per a que el CSIRT pugui compartir els resultats de les diferents fases i afrontar les següents amb garanties.
Compartició denotes de treball
D'alguna forma és necessari que es puguin compartir documents entre equips que estan distanciats remotament.
Pissàrres
Ha de disposar d'alguna mena de mitjà de compartició d'informació dinàmica i temporal.
Accés limitat
Lògicament, tots aquests espais (físics o virtuals) han de tenir accés limitat per assegurar la confidencialitat de informació.

3.4 Comunicacions

Caldrà establir sistemes de comunicació tant interna com externa (especialment al warroom) i tenint en comple que les incidències tractades poden haver inutilitzat o compromés els canals habituals. Per tant aquest punt, tot i que aparentment sense importància, cal pensar-ho detingudament ja que no pot haver res pitjor que estar intentant aturar un atac quan el propi atacant pot escoltar i interferir en el procés.

Recordem que aquestes comunicacions seran:

Internes
Dins de la pròpia organització i equip (CSIRT, CEO, Altres Depts).
Externa
Amb clients i proveïdors.
Notificacions
Entitats legals i públiques.

Aquestes comunicacions normalment es realitzaran en format de reunió pre-establerta per el IC (Incident Commander) amb regularitat (4 hores per exemple). També és important establir un informe diària i reunió per fer-ho arribar al cap del CSIRT i en cas d'incidències crítiques al CEO.

3.5 Rotació

Quan un incident es desencadena i s'activa el CSIRT la prioritat és resoldre-ho en el menor plaç possible, actuant com bombers. Això implica que molts cops el conjunt del departament està treballant 24h diàries per resoldre la incidència.

És per això que cal establir sistema de rotacions i guàrdies de manera que es respectin periodes de descans necessaris per a un bon rendiment del personal alhora que s'assegura minimitzar la necessitat de traspàs d'informació (per consum de temps) i que sempre hi haurà un responsable disponible.

Normalment s'intenten respectar periodes de descans de 8 hores deprès de les 24 hores següents a l'activació. Un altre estratègia és donar descans en els periodes d'inactivitat d'un incident, per exemple després de contenir-lo i mentre es verifica que la contenció ha estat efectiva.

4 Pla de resposta a inciddents

El pla de resposta a incidents articula tot la operativa del CSIRT de manera que per un costat està ja tot pre-establert i es minimitza el caos i les possibles errades durant el procés alhora que permet analitzar el procediment i implementar millores.

4.1 Incident Playbook

Com a peça clau del pla de resposta a incidents trobem els anomenats playbooks que no deixen de ser plans de resposta resumits que permeten guiar dins del caos d'una incidència, pas a pas que cal fer, tot donant marge de maniobra i adaptació.

Tots els incidents que s'hagin classificat i identificat com a incidents crítics o d'alt nivell necessiten tenir un playbook associat, de manera que han estat estudiats prèviament i creat plans de resposta per a gestionar-los de forma adeqüada. D'aquesta manera estem "assegurant" que l'organització no patirà mai conseqüencies greus derivades d'aquestes amenaçes.

Aquests playbooks acostumen a estar dividits en les fases que hem vist (preparació, detecció, anàlisi, contenció, erradicació, recuperació i post-incident).

Cal remarcar que aquests playbooks serveixen com a guies i mai estàn "escrits en pedra", per tant s'han de revisar de forma periòdica i actualitzar.

playbook.png

4.2 Classificació de incidents

La classificació de l'incident intenta moderar la resposta i per tant la dispensa de recursos i esforços. No és el mateix gestionar una petita incidència, on l'equip implicat serà menor alhora que l'estress, que una incidència greu que afecta a tota l'organització.

Així doncs caldria que dins del pla de resposta a incidents es realitzi una classificació i escalat clara de les incidències, tot remarcant quines característiques faran caure una incidència en una o altre classificació alhora que determinar quins recursos s'assginaràn per resoldre cadascuna d'elles.

En termens generals podem donar les pautes següents:

4.2.1 Incident d'alt nivell

incidència que implica un dany important, corrupció o pèrdua de recursos estratègics o crítics de l'organització o dels clients. Poden entrar en aquesta classificació:

  • Intrusions.
  • Accessos físics no autoritzats.
  • Informació critica compromesa.
  • Pèrdua de sistemes que contenen informació confidencial.
  • Afectació de més del 25% de la xarxa per malware.
  • Atacs dirigits.

4.2.2 Indicents de nivell mig

En cas de incidents moderats, els podem entendre per incidents que comportin la pèrdua d'informació reemplaçable sense compromís per l'empresa (informació que no compromet als clients ni és crítica per al negoci). Per exemple:

  • Atacs DoS.
  • Pèrdua de informació no sensible/crítica.
  • Abús d'accessos autoritzats.
  • Intrusions automatitzades.
  • Malware confinat a certs equips.
  • Rendiment o comportament anòmals.
  • Instal·lació de programes maliciosos.
  • Canvis no controlats en configuracions.

4.2.3 Incidents de baix nivell

Finalment, les incidències de baix nivell acostumen a causar inconvenients o danys no intencionats o col·laterals de informació que es pot recuperar amb certa facilitat. Podem incloure aquí:

  • Violacions de les polítiques detectades en auditories.
  • Pèrdua o robatori d'equipament que no contingui dades.
  • Instal·lació de programari no autoritzat (però no perillós).
  • Infeccions de Malware en un únic equip.

4.3 Escalada d'incidents

Un aspecte molt important també en reflectir dins del pla de respostes a incidents, i del qual ja hem parlat una mica, és l'escalat d'incidències o el triatge. Cal determinar i establir el protocol per a que un cop detectada una incidència, qui pren la responsabilitat de la seva detecció i comunicar-la al personal del CSIRT (i a qui cal que la comuniquin).

Per exemple, si un help desk detecta una màquina infectada amb malware pot:

  1. Comunicar-ho al seu responsable i que aquest contacti amb el responsable del CSIRT per activar-lo.
  2. O pot llançar eines de desinfecció estàndard (ja pautades) i en cas que no resolguin el problema escalar-ho ell directament al cap de CSIRT.

Tot plegat cal relacionar-ho amb el personal que no pertany al CSIRT però que hi tè funcions assignades i que vàrem veure anteriorment. Aquest personal caldrà formar-lo en procediment i en detecció d'anomalies, i la seva expertessa en la seva posició l'hi permetrà detectar i diferenciar aquestes incidències i realitzar correctament aquest primer triatge.

Aquest serà el primer triatge on, a posteriori, un membre del Core Team del CSIRT farà un segon triatge per classificar la incidència segons els criteris anteriors i iniciar la resposta.

4.4 Estratègies de detecció

Com hem contentat abans, i sense estendre més, les estratègies de detecció estàn molt lligades amb l'estructura interna de l'organització i l'encaix que tingui el CSIRT dins d'aquesta.

Les fonts de detecció típiques són els propis usuaris, que podran reportar a help desk o al personal de IT encarregat del manteniment dels equips i aquests al personal de CSIRT. Els propis administradors de la xarxa i servidors podran també detectar funcionament anòmals. Tanmateix en un escenari d'aquest tipus serà interessant desplegar sota el control de CSIRT o IT IDS i sistemes SIEM per poder fer una detecció automatitzada d'algun tipus.

Tots aquests "problemes" es resolen amb la inclusió d'un SOC o departament t'intel·ligència de anemaçes ja que seran ells qui monitoritzà tota la infraestructura cercant incidències ja sigui de forma més passiva (SOC) o activa (Threat Hunting).

4.5 Estratègies d'anàlisis

4.5.1 Abast

L'abast refereix especialment als equips afectats. Cal fer-ne un anàlisis molt exhaustiu per no deixar equips infectats que puguin continuar propagant el malware o donant accés al atacant. Per tant és un dels aspectes més delicats i rellevants de l'anàlisi i caldrà perfilar per cada incident, què cal revisar per determinar l'abast.

Caldrà doncs fer una investigació de registres i xarxa per detectar fin "on ha saltat" la incidència i verificar equip per equip si ha estat afectat.

Els equips a revisar són pràcticament tots, des d'estacions de treball, servidors, switch, enrutadors, tablets, etc.

Remarcar que molts cops serà molt important detectar el punt d'origen o primer element afectat, ja que aquest contindrà el vector mitjançant el qual l'organització ha patit l'incidència (per exemple en el cas de malware el "pacient 0" pot ser l'equip que ha rebut i obert el email mitjançant el qual ha arribat el malware a l'organització).

4.5.2 Impacte

L'impacte és l'afectació de la incidència i caldrà determinar de quin manera ha impactat i en quins recursos. És important determinar-ho i associar-ho amb els pilars de la ciberseguretat (confidencialitat, integritat, disponibilitat) ja que en conseqüència a això i als recursos afectats es pot determinar la criticitat de la incidència aixì com possibles repercusions legals i comunicacions extres que s'han de realitzar amb altres departaments i/o entitats externes.

Pilars.png

4.5.3 Causa

Caldrà identificar les causes de la incidència, això implica determinar el punt feble mitjançant el qual s'ha originat la incidència i la natura concreta de la incidència. Amb aquesta investigació podrem determinar al cap i a la fi, com corregir la nostra IT per evitar futures incidències i si més no com les podem controlar.

4.5.4 Atribució

Finalment cops és vol determinar l'atribució o autoria per conèixer quina ha estat la font i també la intenció de la incidència. Tanmateix aquest aspecte té una rellevància important si es volen portar a terme accions legals. Si aquest no és el cas, és un aspecte on no s'acostuma a fer gran incidència donat la dificultat per determinar-ho (consum de recursos) i el poc valor que dona al procés.

4.6 Estrategies de contenció

El pas de contenció cerca reduïr i limitar el dany potencial d'una incidència en sectors o àrees de la xarxa de la nostra IT. Caldrà doncs disposar d'una clara idea de la topologia de xarxa, i per tant depenent del tamany i canvis que pateixi, ens serà necessàri disposar de suport del departament de IT (relacionat amb la gestió de xarxa).

Remarcar un altre aspecte de la contenció i és que normalment en empreses mitjanes / grans, cal realitzar tot un procediment quan s'apliquen canvies a la infraestructura IT per a assegurar que els canvis són controlats i correctes (proposta, aprovació, test, implementació, etc.). Tanmateix enmig d'una incidència, i tenint el rellotge en contra, el CSIRT ha de tenir la llibertat d'aplicar canvis en la IT sense seguir aquest procediment, per tant al instant i de forma unilateral. Tanmateix això no implica que aquests canvis hagin de ser descontrolats, i caldrà vigilar molt en documentar correctament l'estat original i cada canvi realitzat de manera que per un costat permeti estendre aquests canvis a la resta de la xarxa (si constitueixen una mersura de protecció) alhora que puguem desfer aquests canvies amb garanties de tornar la configuració al seu estat anterior.

4.6.1 Contenció física

La contenció física és la més efectiva però no sempre és possible. Desconnectar el cable de xarxa és ràpid i efectiu, però depenent del nombre d'equips afectats i la seva distribució geogràfica pot fer que aquest tipus de contenció sigui inviable.

4.6.2 Contenció en xarxa

La contenció en xarxa implica aïllar els equips afectats de la xarxa de producció. Normalment serà factible si els equips ocupen, gairebé de forma complerta, un segment de la xarxa concreo o si podem reprogramar de forma simple els elements de xarxa (switchos, enrutadors i tallafocs) per aïllar els elements desitjats.

Si utilitzem en l'organització tecnologies com VPN o SDN pot ser relativament simple i tenir ja preparades xarxes específiques per a equipaments compromessos, equipaments en tractament i equipaments en producció. Adicionalment aquest tipus de tecnologies permeten realitzar l'operació de contenció de forma simple, centralizada i remota, facilitant molt la tasca.

4.6.3 Contenció perimetral

Si l'organització, o les circunstàncies, no permeten la contenció de xarxa, en veurem obligats a intentar contenir l'incidència dins de les subxarxes afectades. Per a fer això caldrà utilitzar i configurar els elements "separadors" per a evitar que l'incidència es propagui tot bloquejant el tràfic perillòs. Aquests elements usualment seràn enrutadors i tallafocs.

4.6.4 Contenció virtual

Finalment, la contenció virtual fa referència a contenir la incidència desconnectant els equips de forma virtual. Lògicament això tan sols serà possible quan aquests siguin equips virtuals i podrem gestionar la seva connexió en la consola de control del sistema de virtualització associat.

En aquest cas obtenim els beneficis de la contenció física però de forma remota i centralitzada.

4.7 Estratègies d'erradicació

La erradicació de la incidència versa en tornar els equips afectats a un estat òptim per a la producció, eliminat tant les conseqüències de l'incidència (malware) com les seves causes (vulnerabilitat). Tanmateix és difícil, per no dir impossible, estar al 100% segur que s'ha erradicat la incidència, és per això que molts cops s'utilitza la re-imatge o els backups per restaurar el sistema a un estat previ considerat segur. Per fer-ho caldrà doncs haver realitzat amb perícia la fase d'anàlisi i saber exactament què hem de eliminar i com.

De forma rutinària l'erradicació es realitza simplement restaurant imatges base i backups i actualitzant-los de manera que resolguin la vulnerabilitat detectada. Per realitzar aquesta estratègia caldrà tenir molt clar el moment d'inici del incident (infecció, intrusió, etc) aconseguit en la fase d'anàlisi per assegurar que la imatge o backup utilitzat per restaurar el sistema està net i no afectat.

Tanmateix a vegades, aquesta "reparació" de les causes pot implicar mesures no tècniques com canvis de procediments, etc.

A part d'aquesta estratègia estàndar, també es fa si es possible, l'aillament i estudi per separat dels equips infectats o compromessos junt amb els "teòricament" recuperats. Per fer-ho es creen dues subxarxes noves, una per infectats i un altre per a "recuperats", amb totes les mesures de seguretat associades junt amb fortes mesures de monitorització, i es compara el comportament dels equips de les dues subxarxes. Si s'arriba a la conclusió de que les accions realitzades han aconseguit erradicar la incidència, es reprodueixen de forma massiva amb la resta d'equips i es retornen a la xarxa de producció.

erradicació.png

4.8 Estratègies de recuperació

En aquesta fase, on normalment intervé també el departament IT, es té com objectiu assegurarque tota la IT de l'empresa és resistent a l'amenaça detectada. Per tant caldrà aplicar pegats de forma massiva, realitzar canvis de configuració (aquí ja si, seguint els protocols normals), canviar procediments, etc. Aquesta tasca es durà a terme de forma inter-departamental i el CSIRT intervendrà expossant les evidències obtingudes i les metodologies d'erradicació aplicades.

4.9 After Action Review

Finalment caldrà generar un informe de tot l'incident que serà escalat al CSO amb el detall de tot el que ha succeït. A més a més caldrà retroalimentar tot el pla de resposta a incidents i els playbooks implicats buscant punts de millora.

5 Auditories

Com a tot sistema, caldrà realitzar auditories de forma regular i periòdica on es posi a prova el pla de resposta a incidents. Aquestes auditories tenen un ampli abast, des del pla de respostes a incidents fins als playbooks específics, alhora que engloba al personal del CSIRT tant core com personal adjunt i de tota l'empresa.

Això normalment es realitza mitjançant simulacres que poden anar des de exercicis "d'escriptori" fins a l'ús i implicació dels anomenats "blue/red o purpel team". La integració d'aquests equips en els simulacres implica moltes més avantatges ja que per un costat aquest equips també podem exercitar, alhora que desenvolupem un exercici molt més proper a la realitat.

Amb els resultats d'aquestes auditories es repassen i milloren tots els aspectes del departament, des del pla, playbooks, detecció de noves necessitats de formació etc.

Data: 2021-07-29 dj. 00:00

Autor: Raul Gimenez Herrada

Created: 2021-08-07 ds. 09:13