universitat politÈcnica de catalunya (upc) barcelonatech
TRANSCRIPT
FACULTAT D’INFORMÀTICA DE BARCELONA (FIB) UNIVERSITAT POLITÈCNICA DE CATALUNYA (UPC) – BarcelonaTech
CYBER STRATEGY A DELOITTE: Optimització i millora de la gestió de logs fent ús d’un
SIEM
TREBALL FINAL DE GRAU
GRAU EN ENGINYERIA INFORMÀTICA
SISTEMES D’INFORMACIÓ
Gener 2020
Autor: David Sánchez Soles
Ponent:
Joan Antoni Pastor Collado Enginyeria de Serveis i Sistemes d'Informació
Directora:
Patricia Lopez Martinez
1
2
RESUM
Les empreses avui dia tracten amb una immensa quantitat de dades i és
imprescindible que facin tot el possible per a mantenir el control d’aquestes i que les
utilitzin a favor seu per a millorar la seguretat dels seus sistemes i assegurar la
continuïtat del negoci.
En aquest projecte final de grau d’Enginyeria Informàtica s’explica a alt nivell el
funcionament de la tecnologia SIEM, utilitzada per a millorar la gestió dels registres
que graven les aplicacions i dispositius, tant per a tenir-los més organitzats, com per
a utilitzar-los per a detectar amenaces i prevenir desastres informàtics.
A més, es documenten els processos de negoci seguits per a gestionar la
implementació del registre de logs i la seva integració a un sistema SIEM per a un
client de Deloitte, on s’està duent a terme el treball.
Conté una planificació temporal per a l’elaboració d’aquest així com també un
pressupost estimat del projecte. El projecte però, continuarà sent actualitzat i
mantingut per tècnics per tal d’assegurar la seguretat i vigilància del sistemes del
client.
3
RESUMEN
Las empresas tratan a día de hoy con una inmensa cantidad de datos y es
imprescindible que hagan todo lo posible para mantener el control de estos y que los
utilicen a su favor para así mejorar la Seguridad de sus sistemas y asegurar la
continuidad del negocio.
En este proyecto final de grado de Ingeniería Informática se explica a alto nivel el
funcionamiento de la tecnología SIEM, utilizada para mejorar la gestión de los
registros que graban las aplicaciones y dispositivos, tanto para tenerlos mejor
organizados, como para utilizarlos para detectar amenazas y prevenir desastres
informáticos.
Además, se documentan los procesos de negocio seguidos para gestionar la
implementación del registro de logs y su integración en un sistema SIEM para un
cliente de Deloitte, donde se está llevando a cabo el trabajo.
Contiene una planificación temporal para la elaboración de este y también un
presupuesto estimado del proyecto. Sin embargo, el proyecto seguirá siendo
actualizado y mantenido por técnicos para así asegurar la seguridad y vigilancia de
los sistemas del cliente.
4
ABSTRACT
Enterprises these days have to deal with huge amounts of data and it is of utmost
priority to do everything in hand to keep the data under control and leverage it to
improve their systems’ security and ensure business continuity.
This thesis for Bachelor Degree in Computer Engineering explains in a high-level
manner, the way SIEM technologies work. This technology is used to improve
management of the logs registered by devices and applications, both to have them
better organized and to use them to detect threats and prevent disasters related to
information systems.
Furthermore, business processes followed to manage the implementation of the log
registration and their SIEM integration for a Deloitte client are documented and
explained.
The document contains a time planning displayed on a Gantt chart as well as an
estimated budget that will be needed. Nevertheless, the project will continue to be
updated and maintained by technical staff to ensure the security and vigilance of the
client’s systems.
5
Índex:
1. INTRODUCCIÓ.............................................................................................................. 9
1.1. Context ................................................................................................................... 9
1.2. Justificació i estat de l’art ...................................................................................... 13
2. ABAST DEL PROJECTE ............................................................................................ 16
2.1. Abast .................................................................................................................... 16
2.2. Metodologia .......................................................................................................... 16
3. TECNOLOGIA SIEM ................................................................................................... 18
3.1. Què és un log i un esdeveniment .......................................................................... 18
3.1.1. Sistemes de gestió d’esdeveniments ............................................................. 18
3.1.2. Seguretat en els logs ..................................................................................... 19
3.2. Què és un SIEM ................................................................................................... 19
3.2.1. Diferències amb SIM i SEM ........................................................................... 20
3.2.2. Avantatges ..................................................................................................... 20
3.2.3. Desavantatges ............................................................................................... 21
3.2.4. Arquitectura del SIEM .................................................................................... 21
3.3. Quadres de comandament .................................................................................... 22
3.3.1. Tipus de quadres de comandament ............................................................... 23
3.4. Tipus d’esdeveniments ......................................................................................... 25
3.5. Cerca d’esdeveniments ........................................................................................ 25
3.6. Regles de correlació ............................................................................................. 27
4. DESENVOLUPAMENT ................................................................................................ 28
4.1. Estat actual ........................................................................................................... 28
4.2. Valor afegit ........................................................................................................... 28
4.3. Integració de les fonts que aportin valor a la companyia: Selecció dels logs a
registrar ........................................................................................................................... 29
4.4. Procés de recol·lecta de logs ................................................................................ 31
4.4.1. Recol·lecta d’informació de contacte ............................................................. 34
4.4.2. Obtenció estat actual ..................................................................................... 34
4.4.3. Obtenció de pressupostos ............................................................................. 36
4.4.4. Aprovació de pressupostos i implementació del registre. ............................... 36
4.4.5. Reporting a client ........................................................................................... 38
6
4.5. Regles de correlació: Casos d’ús .......................................................................... 41
4.5.1. Casos d’ús ..................................................................................................... 43
4.5.2. Creació d’una regla ........................................................................................ 49
4.6. Investigació d’alertes i vulnerabilitats .................................................................... 50
4.6.1. Anàlisis de les alertes obtingudes .................................................................. 50
4.6.2. Investigació d’usuaris d’alt risc ....................................................................... 53
5. PLANIFICACIÓ TEMPORAL ....................................................................................... 54
5.1. Tasques a dur a terme: ......................................................................................... 54
5.2. Taula i diagrama de tasques ................................................................................. 55
5.3. Valoració d’alternatives i pla d’acció. .................................................................... 58
6. PRESSUPOST I SOSTENIBILITAT ............................................................................ 59
6.1. Consideracions: .................................................................................................... 59
6.2. Pressupost de la ciberseguretat: ........................................................................... 59
6.3. Identificació i estimació de costos del projecte: ..................................................... 59
6.3.1. Recursos humans .......................................................................................... 59
6.3.2. Recursos materials ........................................................................................ 60
6.3.3. Costos directes per activitat ........................................................................... 61
6.3.4. Costos indirectes ........................................................................................... 62
6.3.5. Contingències i Imprevistos ........................................................................... 62
6.3.6. Pressupost total ............................................................................................. 63
6.3.7. Control de gestió ............................................................................................ 63
6.4. Sostenibilitat ......................................................................................................... 63
6.4.1. Impacte econòmic .......................................................................................... 63
6.4.2. Impacte social ................................................................................................ 64
6.4.3. Impacte ambiental ......................................................................................... 64
7. COMPLIMENT NORMATIU ......................................................................................... 65
8. CONCLUSIÓ ............................................................................................................... 66
8.1. Conclusions del projecte ....................................................................................... 66
8.2. Competències tècniques finals.............................................................................. 67
BIBLIOGRAFIA .................................................................................................................. 69
7
Índex d’imatges:
Imatge 1: Gràfic amb els principals riscos globals ................................................... 11
Imatge 2: Principals inversions tecnològiques per al creixement d’una corporació. . 12
Imatge 3: Ingressos de les grans consultores de seguretat l’any 2017. ................... 14
Imatge 4: Estats de maduresa de la ciberseguretat d’una empresa. ....................... 17
Imatge 5: Arquitectura típica d’un SIEM. .................................................................. 22
Imatge 6: Quadre de comandament general de RSA NetWitness ........................... 23
Imatge 7: Quadre de comandament d’identitat de RSA NetWitness. ....................... 24
Imatge 8: Quadre de comandament d’operacions de RSA NetWitness ................... 24
Imatge 9: Quadre de comandament d’amenaces de RSA NetWitness .................... 25
Imatge 10: Reporting a client: Visió general. ............................................................ 39
Imatge 11: Reporting a client: Progrés per servei .................................................... 40
Imatge 12: Generació de regles en RSA NetWitness .............................................. 49
Imatge 13: Condicions de regles en RSA NetWitness ............................................. 50
Imatge 14: Pagina de visualització d’alertes en RSA NetWitness ............................ 51
Imatge 15: Detalls d’una alerta en RSA NetWitness. ............................................... 52
Imatge 16: Dades de context per a l’entitat sel·leccionada en RSA NetWitness ...... 52
Imatge 17: Exemple dels 5 principals usuaris d’alt risc en RSA NetWitness. ........... 53
Índex de taules:
Taula 1: Exemple BBDD amb logs d’una aplicació. ................................................. 26
Taula 2: Resposta al query definit contra la BBDD de la Taula 1 ............................. 26
Taula 3: Taula de tasques a dur a terme. ................................................................. 55
Taula 4: Factors de risc per al projecte .................................................................... 58
Taula 5: Pressupost de recursos humans ................................................................ 60
Taula 6: Recursos materials necessaris. .................................................................. 61
Taula 7: Costos directes per activitat. ...................................................................... 62
Taula 8: Costos indirectes del projecte .................................................................... 62
Taula 9: Pressupost total del projecte ...................................................................... 63
Taula 10: Control de gestió ...................................................................................... 63
8
Índex de diagrames:
Diagrama 1: Esquema general en ArchiMate del procés seguit per a la
implementació dels registres log a client. ................................................................. 33
Diagrama 2: Recol·lecta d’informació de contacte. .................................................. 34
Diagrama 3: Obtenció de l’estat actual..................................................................... 34
Diagrama 4: Obtenció de pressupostos. .................................................................. 36
Diagrama 5: Aprovació de pressupostos i implementació dels registres. ................. 38
Diagrama 6: Cicle de vida d’un Cas d’Ús. ................................................................ 41
Diagrama 7: Tipus de compte d’usuari. .................................................................... 43
Diagrama 8. Possibles casos d’ús per a usuaris. ..................................................... 44
Diagrama 9: Possibles casos d’us per IPs. .............................................................. 44
Diagrama 10: Primera part del diagrama de Gantt ................................................... 56
Diagrama 11: Segona part del diagrama de Gantt ................................................... 57
Índex de casos d’ús:
Cas d'ús 1. Força bruta. ........................................................................................... 45
Cas d'ús 2. Escalat de privilegis ............................................................................... 45
Cas d'ús 3. Mal ús d’un compte inactiu. ................................................................... 46
Cas d'ús 4: Canvi de contrasenya general sospitós. ................................................ 46
Cas d'ús 5: Canvi de contrasenya privilegiat sospitós .............................................. 47
Cas d'ús 6. Manipulació de registres ........................................................................ 47
Cas d'ús 7. Accessos a arxius inaccessibles ........................................................... 48
Cas d'ús 8. Injecció SQL. ......................................................................................... 48
9
1. INTRODUCCIÓ
1.1. Context
Aquest projecte tracta sobre la gestió de la ciberseguretat d’una empresa, i més
concretament en la part orientada a la gestió a alt nivell de registres logs i la part de
govern o estratègia, en les que s’entrarà en detall més endavant.
Els procediments i metodologies utilitzades són basats en els que utilitza Deloitte,
empresa o s’està duent a terme el treball, per a un client concret. Deloitte es una
consultora multinacional amb clients molt importants al voltant del món, per als quals
és de vital importància mantenir els seus sistemes ben protegits ja que un mínim error
els podria portar al desastre i provocar pèrdues que podrien ser milionàries.
Primerament s’explicarà de manera general la importància de la ciberseguretat dins
d’una empresa, les fases del seu anàlisi i el que comprèn, seguidament es farà èmfasi
en la part de gestió de registres log i la tecnologia SIEM, la qual s’acompanyarà per
l’explicació i els procediments interns que s’utilitzaran per assessorar als clients i
dirigir el projecte, i finalment passarem a documentar la part pràctica, que és una part
molt específica dins del marc de la ciberseguretat.
Abans d’aprofundir en la temàtica de la ciberseguretat, cal definir lleugerament alguns
termes i conceptes propis del tema:
Les quatre capes o dominis en les que podem separar la gestió de la ciberseguretat
o els seus riscos, segons el Framework definit per NIST1, són:
Identify (Estratègia): Capa de govern. Ajuda als executius a crear el seu pla de ciber-
risc alineat amb l’apetit de risc i els objectius a llarg termini de la Empresa.
Protect: Seguretat i mitigació de riscos. Es centra en crear controls de seguretat,
sobretot en aquells actius més importants per a l’empresa, però busca un balanç entre
l’apetit de risc i el no afectar gaire a la productivitat
Detect: Detecció i resposta de forma ràpida a les incidències que ja s’han produït.
Respond & Recover: Automatització de la resposta a través de la preparació en cas
de ciber-desastre.
1 NIST Cybersecurity Framework: https://nvlpubs.nist.gov/nistpubs/CSWP/NIST.CSWP.04162018.pdf
10
Aquest projecte de gestió de logs formarà part, sobretot, de les capes de govern i
detecció, més endavant s’entendran les raons.
D’altra banda, i principalment dins de la capa d’estratègia tenim diferents tipus de
projectes que el client podria demanar que s’executés en vers a la seguretat
informàtica dins la seva empresa:
CSF: Cyber Strategy Framework
TA: Threat Assessment: avaluació de riscos i amenaces
PDSI: Pla director de Seguretat de la Informació
PESI: Pla estratègic de seguretat.
A partir dels tipus de projectes definits anteriorment, existeix la possibilitat de dur a
terme un anàlisi complet de la ciberseguretat i proposta d’implantació de mesures
preventives o correctives amb l’impuls de nous projectes, que consta de dues parts:
AS-IS: Avaluació de l’estat inicial de la ciberseguretat dins l’empresa
TO-BE: Estat desitjat al qual es vol arribar un cop implantades les mesures
pertinents
La ciberseguretat és un camp molt ampli i del qual podríem definir infinitat de
conceptes; es definiran els que siguin oportuns a mesura que vagin apareixent en el
treball.
La gestió de la ciberseguretat i la mitigació dels riscos davant de possibles amenaces
és de vital importància per a totes les empreses avui dia, tant petites com grans
corporacions.
En una època on la transformació digital té un gran paper i els volums de dades estan
incrementant ràpidament, la protecció de dades és d’alta prioritat. Els costos
relacionats amb ciberatacs van ser d’aproximadament 400 mil milions de dòlars($)2
l’any 2016 dels quals 280 mil milions van ser causats a empreses.
Segons el World Economic Forum, a data 2019, els ciberatacs són el quart risc més
preocupant a escala global, tenint en compte la seva probabilitat i el seu impacte, per
sota només, de desastres naturals, com es pot observar al gràfic de la imatge 1.
2 Segons www.consultancy.uk
11
Imatge 1: Gràfic que mostra els principals riscos globals en escales d’impacte i probabilitat. Font: World Economic Forum Global Risks Report 2019. https://www.climateforesight.eu/global-policy/global-risks-report-
2019-environment-related-risks-account-for-three-of-the-top-five-risks-by-likelihood-and-four-by-impact/
Per altra banda, la inversió en ciberseguretat és considerada per molts assessors
d’inversions com una de les més importants actualment (com s’observa en la Imatge
2) per ajudar al negoci a créixer i sobre tot, perquè aquest mitigui riscos tecnològics
que puguin posar en risc el negoci i damnificar la seva reputació.
12
Imatge 2: Principals inversions tecnològiques per al creixement d’una corporació. Font:
https://www.forbes.com/sites/louiscolumbus/2019/06/16/top-10-cybersecurity-companies-to-watch-in-2019/#5c764b976022
Tenint identificat el problema queda definit que els actors implicats, que seran usuaris
del productes (servei en aquest cas) seran totes aquelles empreses que tinguin com
a objectiu aconseguir que la seguretat informàtica de les seves empreses estigui en
les millors mans possibles per a mitigar tots aquells problemes i amenaces que es
puguin trobar.
Com a actors també es poden catalogar els ciberdelinqüents que intentaran per tots
els mitjans al seu abast vulnerar la seguretat dels sistemes informàtics de les seves
víctimes. Aquests poden ser:
● Organitzacions criminals
● Competència
● Hacktivistes
● Hackers
● Nacions/Estats
● Grups terroristes
● Socis/Insiders
● Etc..
13
1.2. Justificació i estat de l’art
A dia d'avui existeixen moltes solucions i paquets de software integrats per a gestionar
la seguretat informàtica i mantenir protegits els dispositius. Aquestes eines tot i ser
molt avançades i en la majoria de casos suficients per a l'usuari individual no són
suficients per a mantenir els sistemes informàtics complexos de grans corporacions
protegits, ja que aquestes estan en el punt de mira de molts ciberdelinqüents, que
faran tot el possible per penetrar en els sistemes. És per això que a més de disposar
de software específic per reduir el risc d'infecció dels sistemes, es requereix personal
i recursos dedicats exclusivament a protegir els béns digitals.
Aquests equips, de grandesa variable segons la necessitat estan encapçalats per
l'anomenat CISO (de l’Anglès Chief Information Security Officer) què és l'equivalent
director de la seguretat informàtica.
Segons les necessitats de cada companyia, aquestes decidiran recórrer a serveis
externs (Per exemple de consultores com és el nostre cas) per assessorar-se o fins i
tot per externalitzar tota la seguretat dels sistemes.
Deloitte té una xarxa global de CICs (de l’Anglès Cyber Intelligence Centers) a la que
moltes empreses líders en els seus sectors recorren per obtenir un servei de gestió
de la Seguretat informàtica totalment personalitzat.
Les alternatives directes als serveis que ofereix Deloitte seria optar per una altra de
les Big-43 (PwC, EY o KPMG) Però tot i que som ferms creients en què la nostra feina
i els nostres serveis són de la millor qualitat possible no seria un fet objectiu catalogar
una de “millor”, el que si podem esmentar objectivament és que els ingressos de
Deloitte són els més elevats de tots com s'observa la imatge 3 i això facilita la
destinació de recursos a aquest àmbit, que afecten positivament als resultats que
s'obtindran.
3 Big-4 són considerades les 4 majors corporacions en els àmbits d’auditoria i consultoria a nivell
mundial.
14
Imatge 3: Ingressos de les grans consultores de seguretat l’any 2017. Font:
https://www.consultancy.uk/news/13927/the-worlds-top-10-largest-cybersecurity-security-consulting-firms
Addicionalment s’ofereix un valor diferencial basat en la manera d'estructura el
diagnòstic de la seva seguretat a través d'una sèrie de iniciatives per a determinar el
nivell de maduresa d'una companyia en vers de la seva ciberseguretat (AS-IS) i el
nivell de maduresa objectiu (TO-BE), i està format pels dominis ja esmentats amb
anterioritat que tenen capacitats pròpies: Identify, Protect, Detect i Respond &
Recover.
Amb freqüència les organitzacions centren en seus esforços per obtenir un bon nivell
de maduresa en la estratègia i la protecció dels seus sistemes, però manquen a l’hora
de detectar incidents de ciberseguretat (detecció), i tampoc saben respondre
correctament quan aquestes s'han produït (respondre i recuperar-se).
El model ha sigut aplicat a centenars d’empreses de manera satisfactòria
internacionalment la qual cosa es indicativa de la seva robustesa, a més, es troba en
constant evolució i millora.
Fent èmfasi en la detecció, com és la monitorització dels registres dels sistemes i
aplicacions, moltes grans empreses a dia d’avui segueixen sense disposar d’una eina
per a la gestió centralitzada de logs, i les que en disposen moltes no integren totes
15
les fonts que seria adequat que fossin integrades. I amb molts projectes paral·lels
cadascun registra logs segons es definís a l’inici del projecte, provocant que hi hagi
molta heterogeneïtat en el registre de logs.
Sense una eina que s’encarregui de gestionar els registres, les empreses són
vulnerables a moltes amenaces, de les quals només en serien conscients un cop
aquestes ja han tingut un impacte considerable a l’empresa, i un cop s’ha produït,
tindrien una gran dificultat per estudiar les causes i culpables de l’incident. Aquest és
un risc, que moltes empreses no poden, o si més no, no haurien d’assumir.
A més, una mala gestió dels registres pot portar a l’incompliment de normatives legals
com ara la GDPR4.
Aquests dos punts comentats són els que justifiquen la necessitat de tota gran
empresa d’impulsar un projecte per a la transició a una millor gestió dels registres
d’aplicacions i dispositius.
4 General Data Protection Regulation: https://ec.europa.eu/info/law/law-topic/data-protection/data-protection-eu_es
16
2. ABAST DEL PROJECTE
2.1. Abast
Un cop Establert el context en que es troba el projecte, passarem a definir quin és
l'abast i els objectius que es volen aconseguir amb aquest projecte.
Els objectius d'aquest projecte són mostrar el procés seguit per a la adequada
implementació d’un software SIEM5 i ensenyar al lector per quins aspectes està
compresa la ciberseguretat dins d'una corporació.
El projecte que es durà a terme a l’empresa consisteix en la millora de la gestió dels
logs d’una empresa fent ús d’aquest software, que més endavant veurem la
importància que té en un món tant digital en el que vivim.
S’entendrà la utilitat i el valor que aporta a una organització fer ús d’aquesta eina i la
manera en que aquesta funciona a alt nivell per al cas concret de NetWitness de
l’empresa RSA, que és el SIEM que s’utilitzarà. També es documentaran els
processos de negoci seguits per a gestionar la transició i integració d’aplicacions de
negoci a aquesta tecnologia.
Així un cop finalitzada la lectura, el lector hauria de tenir unes bones nocions respecte
com s'aborden els problemes i els riscos de seguretat en una empresa amb l'estat i
desenvolupament tecnològic propi del 2019.
S’obtindrà una visió a alt nivell d’un dels aspectes més importants a tenir en compte
quan es vol incrementar la seguretat informàtica d’una empresa.
2.2. Metodologia
La metodologia que s’utilitzarà en aquest projecte pot ser dividida en dos grans blocs:
La metodologia a seguir en la recopilació d’informació i redacció del document, i la
metodologia usada per la implementació del registre de logs (part pràctica).
Pel que fa a la implementació de projectes concrets i serveis oferts són molt variables
i poden presentar moltes diferències els uns dels altres però concretament en el
projecte que es durà a terme, s’usarà un procés agile de constant feedback entre
l'empresa client i Deloitte amb reunions molt regulars (de manera bimensual en aquest
cas concret) i feina en paral·lel (En les fases de contacte amb responsables
5 Tipus de Software (De l’anglès: Security Information and Event Management)
17
d’aplicacions com es veurà més endavant) però dividida en quatre grans blocs que si
tindran dependències temporals, com es veurà a l’apartat de desenvolupament.
La implementació d’un SIEM seria una part molt concreta dels possibles projectes que
Deloitte duu a terme en una empresa, i que ajudaria a la maduresa global en termes
de ciberseguretat de la companyia.
Els diferents estats de maduresa en ciberseguretat d’una empresa són els següents,
com es veu a la Imatge 3:
Inicial, Repetible, Definit, Gestionat i Optimitzat.
Imatge 4: Estats de maduresa de la ciberseguretat d’una empresa. Basat en el model CMMI (Capability Maturity Model Integration).
Pel que fa a la obtenció d’informació i redacció del document (més enllà de la
documentació de la part pràctica), es farà servir una aproximació en cascada,
redactant i detallant be cada apartat abans de prosseguir amb el següent, com es
veurà plasmat en la planificació temporal del projecte.
Inicial
Repetible
Definit
Gestionat
Optimitzat
18
3. TECNOLOGIA SIEM
3.1. Què és un log i un esdeveniment
Primerament, abans d’aprofundir en la tecnologia, han de quedar clars conceptes
bàsics com ara, què és un log, ja que és l’essència d’un SIEM, del que s’alimenta per
a funcionar.
Un log és un registre d’informació que deixa gravat una aplicació o sistema i que
pertany a un moment determinat. Aquest és utilitzat per a guardar informació bàsica
relacionada amb un esdeveniment per a poder disposar d’aquesta en un futur si fos
necessari.
La informació guardada principalment respon al que, qui, quan, com, on d’un
esdeveniment produït en un dispositiu o aplicació.
L’Estàndard mes comú pels logs és Syslog, que són registres de xarxa formats per
caràcters ASCII i que poder ser oberts amb un simple editor de text.
Exemple de log web:
183.121.143.32 [21/Feb/2019:08:04:22 +0100] "GET /images/logo.jpg HTTP/1.1" 200
512 "http://www.ejemplosiem.org/" "Mozilla/5.0 (X11; U; Linux i686; es-ES;rv:1.7.5)"
Que desglossat equivaldria a:
[ip] [data] [acció] [codi (error/satisfactori)] [quantitat dades (B)] [URL destí]
[Navegador/Maquina]
3.1.1. Sistemes de gestió d’esdeveniments
A dia d’avui hi ha tres tipus de software als que es pot recórrer per a gestionar els
esdeveniments de seguretat de manera centralitzada, aquests són: el SIM, el SEM i
el SIEM.
També existeixen altres tipus de sistemes per a la gestió de logs, com ara els LM (de
l’anglès, Log Management), però aquests no es centren en esdeveniments de
seguretat, sinó en tot tipus de logs, això dificulta molt la visió del que és realment
rellevant en quant a seguretat informàtica.
Els LM (tot i que els SIEM també cobreixen aquest aspecte), es focalitzen sobretot en
el compliment normatiu o compliance, i no en la correlació d’esdeveniments en temps
real, qüestió crítica, sobretot en una empresa multinacional amb informació molt
sensible.
19
3.1.2. Seguretat en els logs
És de vital importància que els logs no siguin modificats i mantinguin el seu estat i
valor durant tot el període de retenció que s’hagi definit, per això és necessari
implementar les mesures de seguretat en l’emmagatzematge que siguin pertinents
per assegurar-ne la seva validesa i no alteració. Aquests tampoc podran ser
modificats quan es transmetin al SIEM.
Per altra banda també s’ha d’assegurar la confidencialitat d’aquelles dades que ho
requereixin, permetent només l’accés a la visualització dels logs a aquells empleats o
persones que ho requereixin de manera justificada.
3.2. Què és un SIEM
SIEM o Gestió d’esdeveniments i informació de seguretat (De l’anglès: Security
Information and Event Management) és un tipus de programari per a empreses que
proveeix a aquestes d’informació rellevant sobre potencials amenaces a través de la
centralització de les dades de seguretat, prioritzant amenaces segons el seu potencial
impacte a l’organització. Les dades utilitzades són obtingudes de moltes fonts, com
poden ser aplicacions de negoci, firewalls, antivirus, etc.
A grans trets el SIEM és una eina que facilita l’anàlisi de tot el que està succeint a
l’organització i facilita la detecció d’accions o succeïments sospitosos, protegint així a
l’empresa i entitats relacionades i optimitzant els recursos dedicats a la seguretat
informàtica.
Per què implementar-ne un?
A l’època en que vivim, els usuaris i les organitzacions generen una quantitat de dades
molt elevada, i aquestes dades poden ser de gran utilitat per a les empreses per a
monitoritzar qualsevol esdeveniment que és produeixi dins de la mateixa. A més,
mantenir un control d’aquests registres i ser capaços de fer una anàlisis exhaustiu
dels esdeveniments de seguretat, ajudarà a garantir l’acompliment de les lleis i
obligacions i fer front a riscos de seguretat en les tecnologies de la informació.
Per altra banda, és important tenir un SIEM per, en cas d’incident, poder disposar de
la informació necessària per:
o Detectar aquest incident més ràpidament per reduir-ne l’impacte, ja que aquest
ens avisarà si detecta anomalies.
o Analitzar la causa “arrel” d’aquest incident i aplicar les mesures que siguin
necessàries per que no es torni a produir.
20
Monitorització en temps real
La monitorització en temps real de tot el que està succeint als sistemes serà de gran
utilitat a l’hora de prevenir i mitigar les creixents amenaces a la continuïtat del negoci
i la centralització de tots els registres d’esdeveniments de seguretat farà possible a
l’empresa accedir a dades de dispositius encara que aquests ja no es trobin físicament
a l’abast de l’empresa.
3.2.1. Diferències amb SIM i SEM
Els altres tipus de software per a gestionar els esdeveniments de manera
centralitzada, són, com hem comentat, el SIM i el SEM, (que representen “Security
Information Management” i “Security Event Management” respectivament) que el que
fan és tan sols treballar amb una part del que el SIEM gestiona, així doncs podem dir
que el SIEM és una combinació de SIM i SEM.
El SIM gestiona tots els logs dels sistemes, és a dir, tots els logs generats per sistemes
operatius i aplicacions, per tant el seu nivell de control dependrà de la quantitat i
qualitat dels logs generats pels sistemes. El SIM proporciona control centralitzat de
tots els processos de negoci.
El SEM per altra banda gestiona tots els esdeveniments generats per sistemes de
seguretat, com podrien ser Firewalls, IPS, etc. La unificació dels logs generats per
tots aquests dispositius disminueix la possibilitat de falsos positius i la correcta
avaluació de prioritats.
3.2.2. Avantatges
Un dels principals avantatges de tenir un SIEM en una organització, és que aquest
ens ajudarà a reduir considerablement el temps i capital invertit en la investigació d’un
incident de seguretat, la qual cosa permetrà respondre a aquests de manera rapida
per tal que no es tornin a produir o reduir-ne el seu impacte.
Un SIEM és capaç de centralitzar molts registres log provinents de diferents
dispositius en un mateix lloc, la qual cosa és molt més pràctica que tenir registres per
a totes les aplicacions, per separat, ja que per a una empresa de grandària
considerable, aquests poden estar separats en centenars o milers d’arxius. A més,
aplicacions internes amb registres separats poden tenir usuaris o actius comuns, però
al estar separats no se’ns permet tenir una visió global d’un actiu o usuari concret de
manera senzilla, mentre que en un SIEM si.
A l’estar centralitzat, també permet crear i definir alertes per a la detecció de
comportaments anòmals o sospitosos, permetent així, anticipar-se a possibles
incidents de seguretat.
Un SIEM també té un quadre de comandament i ens permet generar informes que
facilitaran saber l’estat en que es troba l’organització i conseqüentment obrirà pas a
millorar la seguretat informàtica.
21
A més, aquest tipus de sistema garanteix el compliment normatiu (SOX, PCI, GDPR,
HIPAA) respecte existència, la custodia i el xifrat dels logs.
3.2.3. Desavantatges
L’emmagatzematge requerit per guardar tot l’històric de logs provinents de molts
dispositius i aplicacions que seran usats pel SIEM pot ser molt elevat, a més a mesura
que passa el temps la capacitat requerida puja ràpidament. En aquests tipus de
sistema, l’emmagatzematge de dades amb anterioritat major a 30 dies ja és
considerat per alguns com a llarg termini. Amb el preu decreixent de
l’emmagatzematge aquest problema va perdent importància, però no deixa de ser un
aspecte a tenir en compte.
Un SIEM és bo per investigar el que és conegut i allò que busquem amb concessió,
però no ajuda tant en allò que es desconeix, quan no se sap el que es busca realment.
Falsa sensació de seguretat, ja que si no salta cap alerta pot portar-nos a pensar que
tot està funcionant correctament i no hi ha perill però s’ha de ser molt curós a l’hora
d’assegurar-se que tota la informació rellevant s’està passant correctament al SIEM i
s’estan monitoritzant les dades més importants.
També és important que la informació que veiem a través del SIEM sigui el més
propera a temps real possible, ja que algunes alertes si es veuen amb gaire retràs pot
ser massa tard per fer front a una incidència.
Un SIEM no és tan sols una eina que s’instal·la i es deixa fer, un SIEM és un servei
que requereix ser monitoritzat i mantingut per experts en l’àmbit, la qual cosa fa que
el seu cost sigui encara més elevat.
3.2.4. Arquitectura del SIEM
Com ja s’ha comentat, el SIEM recol·lecta logs i esdeveniments de moltes fonts i
formats diferents que poden ser agrupats en:
o Dispositius de xarxa
o Dispositius de seguretat
o Servidors
o Aplicacions
Per tal d’obtenir tota la informació provinent d’aquests dispositius, s’utilitzarà un
recol·lector (Collector), que s’encarregarà de normalitzar aquests logs abans de
centralitzar-los amb els demés registres, un cop normalitzats, aquests s’envien a la
base de dades, on romandran el temps que s’hagi establert per la política de retenció
de logs de l’empresa.
22
L’arquitectura seguida per la majoria de SIEMs descrita anteriorment pot ser
representada de la següent manera.
Imatge 5: Arquitectura típica d’un SIEM. Elaboració pròpia.
Aquestes tres capes són comuns a totes les eines SIEM.
Ja hem vist a l’apartat de desavantatges que l’emmagatzematge requerit en un SIEM
és molt elevat, és per això que existeixen diversos tipus d’emmagatzematge,
comunament coneguts com “hot” que seria el de més ràpid accés i més car, i el “cold
o warm” que seria més assequible però més lent. A la majoria de sistemes SIEM, i
amb el que es treballarà en aquest projecte en particular, s’usarà una combinació
d’aquests dos tipus d’emmagatzematge, el “hot”, que serà sobre el que actuarà el
motor de correlació d’esdeveniments, emmagatzemarà dades de fins a sis mesos, i
el cold, a fi de mantenir un històric de tot el que ha succeït, emmagatzemarà registres
dels últims 10 anys.
3.3. Quadres de comandament
Per tal de poder visualitzar les dades i extreure’n informació de manera intuïtiva, és
indispensable fer us de quadres de comandament, que són una eina important dins
d’un SIEM.
El seu propòsit és facilitar la interpretació de les dades recol·lectades de les diferents
fonts mitjançant la representació gràfica d’aquestes.
A més, la visualització de les dades permetrà trobar errors en el parseig de la
informació, ja que no podrà representar-la correctament.
recol·lector 1
Motor
intern:
Processat
de dades,
Reporting,
Correlació,
Alertes …
Aplicacions
recol·lector 2 Disp. Xarxa
recol·lector 3 Disp. Seguretat
recol·lector 4 Servidors
DB
SIEM
23
La informació representada correspondrà sempre a un període de temps, ja que es
tracta d’un històric del que ha succeït, i no pas del que està succeint en un instant
determinat.
3.3.1. Tipus de quadres de comandament
Els tipus de quadres de comandament mostrats a continuació són els propis del
software SIEM d’RSA: Netwitness. I es classifiquen en: Quadre general, d’identitat,
d’operacions, SecurID i d’amenaces.
Es mostren exemples6 dels més rellevants a continuació:
Quadre de comandament general: Mostra una vista de les tendències dels
registres en un període de 24 hores.
Imatge 6: Quadre de comandament general de RSA NetWitness. Font: https://community.rsa.com/docs/DOC-
64694
Quadre de comandament d’identitat (Activitat d’usuaris): mostra els usuaris i serveis
que podrien tenir activitats malicioses i són comparades amb les mitjanes per tenir
contrast.
6 Els exemples mostrats no són captures del SIEM desplegat en els sistemes del client per mantenir la seva confidencialitat.
24
Quadre de comandament d’operacions (Logs): mostra les tendències i distribucions
dels logs de diferents tipus i classes.
Imatge 8: Quadre de comandament d’operacions de RSA NetWitness. Font:
https://community.rsa.com/docs/DOC-64694
Quadre de comandament d’amenaces: mostra un resum dels diferents
esdeveniments registrats que han sigut categoritzats com a possibles amenaces.
Imatge 7: Quadre de comandament d’identitat de RSA NetWitness. Font: https://community.rsa.com/docs/DOC-64694
25
Imatge 9: Quadre de comandament d’amenaces de RSA NetWitness. Font:
https://community.rsa.com/docs/DOC-64694
3.4. Tipus d’esdeveniments
Els esdeveniments podrien ser categoritzats en dos grans tipus. Esdeveniments
correlats i esdeveniments agregats.
Els esdeveniments agregats són agrupacions d’esdeveniments base que tenen
característiques relacionades entre ells (com podria ser l’usuari que duu a terme una
acció), però on la font d’aquests esdeveniments tan sols és una.
Els esdeveniments correlats, per altra banda, permeten unificar moltes fonts
d’esdeveniments diferents per a analitzar patrons. Aquests seran de gran importància
per a aquest projecte ja que s’integraran fonts d’una gran quantitat d’aplicacions.
3.5. Cerca d’esdeveniments
Com ja s’ha comentat, els quadres de comandament ens permetran veure l’estat en
que es troba l’organització mitjançant gràfics.
26
Per altra banda les alertes faran ús de les regles de correlació per informar i avisar
d’un esdeveniment que hagi succeït.
Addicionalment a aquestes dues formes d’obtenció d’informació, també disposem, en
la gran majoria de SIEMs, de la funcionalitat de cercar un (o més) log concret fent us
de querys en llenguatge SQL o un propi del software i així obtenir una visió a baix
nivell del que ha succeït. Així doncs, l’accés a aquests logs seria molt similar a si es
tractés d’una base de dades relacional.
Un exemple molt basic de query sql contra una taula del SIEM del seria:
SELECT [columna] AS [canvi_nom] FROM [taula]
On columna indicaria el camp a obtenir (data, ip, etc..), canvi_nom seria un nom que
volem donar al camp quan retorni la consulta i taula seria la font de logs del SIEM a
consultar.
Un altre exemple de cerca per a consultar les accions registrades per un usuari en un
dia concret seria:
SELECT acció, hora FROM taula_aplicació1 WHERE id_usuari = ‘U1234’ AND data
= ‘12/10/2019’
Que en una taula com la següent (taula_aplicació1):
id_usuari ip data hora acció
U1234 84.XX.238.112 12/10/2019 09:23 Accés denegat a arxiu X
U4567 84.XX.238.132 12/10/2019 10:33 Descàrrega factura 1
U1234 84.XX.238.114 12/10/2019 11:24 Accés denegat a arxiu Y
U1234 84.XX.228.112 12/10/2019 11:27 Accés denegat a arxiu Y
U4567 84.XX.231.112 13/10/2019 09:13 Enviament factura 2
U1234 84.XX.222.112 15/10/2019 05:13 Sol·licitud canvi contrasenya
Taula 1: Exemple BBDD amb logs d’una aplicació. Elaboració pròpia
Obtindríem la següent resposta per a l’usuari U1234 el dia 12/10/2019:
acció hora
Accés denegat a arxiu X 09:23
Accés denegat a arxiu Y 11:24
Accés denegat a arxiu Y 11:27 Taula 2: Resposta al query definit contra la BBDD de la Taula 1. Elaboració pròpia
27
D’aquesta manera, obtindrem una visió molt més clara de les accions que ha dut a
terme l’usuari en qüestió durant el dia seleccionat i pot ser de gran utilitat per a
investigar un incident
3.6. Regles de correlació
La finalitat de la implementació de regles de correlació en un SIEM és detectar i alertar
de comportaments anòmals i sospitosos a més alt nivell del que ens poden donar els
esdeveniments, que podrien ser una amenaça real per a l’empresa i per als quals s’ha
de prendre mesures determinades, ja sigui pre o post incident. D’aquesta manera
elevarem el nivell de seguretat de l’empresa respecte amenaces de ciberseguretat.
Les regles de correlació es defineixen amb els següents paràmetres:
Condicions que els esdeveniments han de complir:
Una o més condicions que s’han de complir
Agregació:
Nombre de vegades que s’han de complir les condicions anteriorment
establertes en un espai de temps determinat
Accions:
Accions a dur a terme quan es produeixin les condicions establertes en
l’agregació temporal definida.
Per defecte, molts paquets de software SIEM ja porten predefinits diversos casos d’ús
genèrics, però és convenient que aquests siguin modificats i adaptats segons les
característiques de l’empresa en que s’implementa, sobretot per a aplicacions
creades únicament per aquesta empresa (com són amb les que es tracta en aquest
projecte), ja que el SIEM no reconeixerà a priori l’estructura del tipus de log que rebrà.
No tots els casos d’ús definits seran igual d’importants, depenent del tipus de negoci
alguns resultaran més importants que d’altres.
Els casos d’ús a definir haurien de seguir un context com el següent:
Els caos d’ús donen una visió, processada per l’analítica i alimentada de les dades
emmagatzemades.
28
4. DESENVOLUPAMENT
4.1. Estat actual
Prèviament a començar el desenvolupament, cal conèixer l’estat actual (o AS-IS) en
que es troba l’empresa en matèria de ciberseguretat, i més concretament, respecte al
registre de logs.
A dia d’avui, l’empresa en qüestió disposa ja d’un SIEM desplegat i gestionat per
Deloitte, aquest SIEM és l’anomenat NetWitness de l’empresa RSA, que és una
pionera en temes de seguretat de la informació. Aquest desplegament, però, no
afectava a les aplicacions, sinó que només s’hi registraven logs de dispositius de
seguretat, servidors i dispositius de xarxa.
Així doncs, com s’ha vist a l’apartat d’arquitectura d’un SIEM, faltaria la integració de
les aplicacions al SIEM (Que aquestes passin els logs al SIEM), que és part de
l’objectiu d’aquest projecte.
Fins ara, les aplicacions de l’organització no disposaven d’un estàndard ni d’un mínim
de logs a registrar ni de si havien o no de registrar logs, i degut a això la situació en
que es troben és molt heterogènia, amb gran quantitat d’aplicacions que no registren
cap mena de log i altres que en registren alguns segons s’indiqués al pla de
desenvolupament de cada aplicació.
Tot i que no es cobreix en el desenvolupament perquè ja es va dur a terme amb
anterioritat a l’inici d’aquest TFG, la instal·lació d’un SIEM es duu a terme en un
servidor dedicat. Un cop instal·lat s’hi podrà accedir a través d’un navegador web amb
la direcció IP local en la que es trobi, ja sigui de manera local o a través d’una VPN i
disposarà d’un front end des d’on es podrà manejar i fer ús del software si es disposa
d’un usuari amb permís per accedir al SIEM.
4.2. Valor afegit
Partint de l’estat actual, l’objectiu del projecte serà implementar el registre de logs per
a les aplicacions de l’empresa de manera que s’aconsegueixi homogeneïtat i
s’obtingui valor de tots els logs d’aplicacions registrats al SIEM.
Ja hem vist el que és un SIEM, però com s’ha esmentat a les desavantatges, un SIEM
requereix molt més que només ser instal·lat. Sense personal dedicat, només serviria
per tenir els logs centralitzats i complir amb normatives legals.
29
Per tal d’obtenir les avantatges per les quals es caracteritza el SIEM, és necessària
l’acció d’un (o un equip) tècnic capacitat per obtenir les següents funcionalitats:
1. Integració de les fonts que aportin valor a la companyia:
o No tots els logs han de ser integrats
o No tots els logs ens aporten informació valuosa
2. Creació de les regles de correlació sobre els logs
3. Creació d’alertes i informes per a fer visible la funció del SIEM
4. Anàlisis de les alertes obtingudes
o Detecció d’incidents i vulnerabilitats
o Millora de les regles de correlació
I per tal de disminuir-ne el cost i el soroll, a més de possiblement limitar la capacitat
requerida pel SIEM, és important seguir un procés de selecció de quins logs seran
necessaris integrar i quins no. Per això serà necessari saber per a quina finalitat es
guardaran els logs, tenint-los en compte a les regles de correlació i de quantes fonts
s’hauran de recollir els logs.
El cas ideal seria registrar-ho i aprofitar absolutament tot, però això és inviable a la
gran majoria d’empreses ja que els sistemes SIEM a dia d’avui no són capaços de
processar la immensa quantitat de dades que podrien ser registrades, a més seria
inviable econòmicament, tot i tractar-se en el nostre cas, d’una multinacional amb
molts recursos.
És per això que solament s’implementarà en primera instància el registre de les
aplicacions més crítiques, per aquelles dades que considerem que són de més
rellevància.
4.3. Integració de les fonts que aportin valor a la
companyia: Selecció dels logs a registrar
En aquesta fase del projecte només es tindran en compte les aplicacions internes de
l’empresa i no les que utilitzen els clients finals (tan sols és una aplicació mòbil i la
plataforma web), que en última instància, també hauran de formar part del SIEM, així
com tampoc dels dispositius de xarxa o servidors, com ja s’ha comentat a l’apartat 4.1
sobre l’estat actual, que d’igual manera han de formar part d’aquest i ja van ser
integrats amb anterioritat, per tant queden fora de l’abast d’aquest projecte.
Pel que fa a les dimensions del projecte, com es veurà a l’apartat de pressupostos, hi
ha identificades aproximadament 885 aplicacions, i varien des de gestió documental
fins a gestió de riscos i tenen una gran varietat de funcionalitats diferents, però s’han
seleccionat 114 aplicacions que són considerades més importants per a les quals es
30
donarà prioritat en la implementació i un cop aquesta wave sigui finalitzada, es repetirà
el procés per a les demés aplicacions.
A més, les aplicacions tenen una naturalesa molt heterogènia, per tant, la feina a dur
a terme per registrar els logs per part dels programadors no podrà ser reutilitzada, la
qual cosa, com es reflexa a l’apartat de pressupostos, augmentarà molt el requeriment
de recursos econòmics i humans.
Per altra banda, i tot i que les aplicacions tenen funcionalitats molt diferents, trobem
punts en comú respecte els registres que es poden extreure.
Per aquest projecte, s’han identificat com a necessaris d’implementar, de manera
general, els registres següents:
IP – Nombre que identifica de manera única a una interfície en xarxa d’un
dispositiu. Ens servirà per saber des de quina xarxa es connecten els possibles
atacants a les aplicacions, a més si certes ips són considerades fraudulentes
poden ser afegides a una blacklist o ser monitoritzades amb prioritat.
Terminal – Des de quin terminal s’ha fet l’acció (Poden haver diverses en un
dispositiu amb l’ús, per exemple, de VDI, o escriptoris virtuals). Pot donar
informació addicional sobre mal ús d’escriptoris remots.
Data i hora – Data i hora en que s’ha produït l’acció. Crucial. Ens donarà una
visió temporal i permetrà relacionar-los amb altres logs i fer agrupacions que
portin a l’execució d’alertes.
Camps indexats – Si/No els camps registrats es troben indexats, de cara a
tenir una referència i millor organització.
Acció de l’usuari – L’acció concreta que s’ha dut a terme. També
imprescindible. Ja sigui la visualització d’una pagina, un login satisfactori, o la
descarrega d’un document, qualsevol acció de que es tracti ha de quedar
registrada.
Usuari – Identificador de l’usuari que ha dut a terme l’acció. Ens servirà per
saber qui ha dut a terme l’acció registrada i al igual que amb la ip, permetrà
relacionar-lo amb altres logs d’aquest usuari i fer agrupacions i visualització a
alt nivell d’aquestes.
Dispositiu que ha realitzat l’acció – Des de quin dispositiu físic s’ha realitzat
l’acció. Una capa addicional d’informació per saber quin dispositiu ha sigut
usat.
31
Aquestes dades definides són el mínim, i per a casos concrets podria ser necessari
registrar més paràmetres. També hi ha diversos casos en que per la naturalesa
concreta de la aplicació no es poden registrar algunes dades, com seria el cas
d’aplicacions que només executen processos automatitzats, per tant, l’acció no la duu
a terme un usuari concret.
Les dades hauran de ser registrades per a totes les accions que es duen a terme dins
l’aplicació, per molt insignificants que semblin, com seria la visualització d’una pàgina
de l’aplicació sense cap acció posterior. La raó per la qual s’ha de registrar tot és
perquè aquestes dades poden servir en cas d’una investigació ja sigui per temes
interns, o processos judicials, que per exemple, requereixin conèixer tot el que ha fet
un usuari, o totes les persones que han visualitzat certa informació
4.4. Procés de recol·lecta de logs
Al ser una empresa externa, no tenim accés directe a les aplicacions sobre les quals
es farà la recol·lecta de logs. Aquestes, com ja s’ha vist a l’estimació de pressupost
per al projecte, disposen cadascuna d’elles d’un responsable, que serà amb el qual
ens posarem en contacte per a dirigir el procés.
El responsable serà qui es faci càrrec d’ordenar als programadors amb coneixements
de baix nivell de l’aplicació d’implementar el necessari o demanar la informació sobre
l’estat actual.
En cas d’haver algun inconvenient ja sigui per requeriments o característiques
concretes de l’aplicació o per consultes sobre les dades sol·licitades, serà el
responsable qui contacti amb nosaltres i de manera extraordinària es faran reunions
que poden involucrar als programadors.
Al Diagrama 1 que es mostra a continuació es descriu el procés seguit per a dur a
terme el projecte. Aquest flux ha sigut dissenyat en ArchiMate7, que es tracta d’un
software per al modelatge d’arquitectura empresarial.
Aquest software separa el domini en tres capes:
Business: Funcionament del procés seguit a l’organització. S’estableixen rols
i responsabilitats.
Application: Mostra les interaccions amb l’aplicació i els processos interns que
es produeixen per cada interacció amb els usuaris involucrats.
7 Per a més informació: www.archimatetool.com
32
Technology: Mostra com s’implementen els processos que realitza l’aplicació
a nivell tecnològic, com seria el backend d’aplicacions, servidors, BBDD, etc..
L’esquema general es mostra a continuació, seguit de l’explicació de les parts o fases
en que es pot dividir, que són:
1. Recol·lecta d’informació de contacte
2. Obtenció estat actual
3. Obtenció de pressupostos
4. Aprovació de pressupostos i implementació del registre.
I de manera rutinària, que no forma part del procés de recol·lecta:
Reporting a client
Diagrama 1: Esquema general en ArchiMate del procés seguit per a la implementació dels registres log a client. Elaboració pròpia
34
4.4.1. Recol·lecta d’informació de contacte
Primerament, el consultor accedeix a la CMDB8 on es troben registrades totes les
aplicacions amb els seus responsables corresponents, a qui posteriorment es
demanarà la informació que pertoqui.
Tots els contactes quedaran registrats en una taula excel per a facilitar la comunicació
i el registre de l’estat en que es troba.
4.4.2. Obtenció estat actual
Després d’obtenir la informació de contacte del responsable d’una o varies
aplicacions, i alhora que es va recol·lectant la d’altres responsables, es contacta amb
aquest a traves del correu corporatiu i se’l demana la informació sobre l’estat actual
en que es troba la/les aplicacions al seu càrrec respecte al registre de logs, aquest
serà responsable de contactar amb el/els tècnics responsables, que comprovaran
quins dels logs en qüestió són o no registrats.
8 Base de dades de la gestió de la configuració
Diagrama 2: Part de l’esquema referent a la recol·lecta d’informació de contacte. Elaboració pròpia
Diagrama 3: Part de l’esquema referent a l’obtenció de l’estat actual. Elaboració pròpia
35
Quan el responsable coneix la informació sol·licitada, la comunica a través del mateix
mitjà i el consultor s’encarregarà de centralitzar la informació demanada.
La informació obtinguda, juntament amb la de contacte, serà bolcada en un Excel,
en fulls iguals a la plantilla que es mostra en el formulari 1.
En aquest trobem separades principalment dues parts, la primera, la informació de
contacte de el/la responsable de l’aplicació per tal d’agilitzar-ne la comunicació per a
futurs contactes amb aquest.
La segona part té més rellevància a nivell de projecte ja que és aquí on es registraran
totes les dades que es tenen respecte el registre de logs d’aquesta aplicació per tal
d’obtenir una imatge general de l’estat en que es troba l’organització. Conèixer
aquestes dades ajudarà després de cara a la justificació dels pressupostos (següent
apartat) així com també per tenir un lloc centralitzat d’on partir a l’hora de comunicar-
se amb els responsables i altres parts involucrades, un cop les dades siguin
registrades aquests fulls s’actualitzaran amb les noves, que idealment, serà que es
registren totes les dades que apareixen.
Acompanyant a aquesta segona part, trobem l’últim apartat, que és si es registra o no
en el SIEM, que al principi no serà cap, però en un futur totes ho haurien de complir.
formulari 1: Full d’excel que recull la informació de l’estat actual. Elaboració pròpia
36
4.4.3. Obtenció de pressupostos
Un cop s’ha obtingut l’estat actual de totes les aplicacions es passarà a la fase de
càlcul de pressupostos estimats.
Per obtenir-los, s’anirà responsable per responsable seguint el mateix mètode de
comunicació, demanant el cost estimat que seria requerit per a dur a terme el registre
complet dels registres pels quals es preguntava a la fase anterior, incloent la integració
al SIEM.
Els responsables establiran una estimació de cost, tant temporal com econòmic, així
com també el temps que trigarien en poder implementar-ho, doncs podria tenir un cost
temporal de, per exemple, 30 hores, però depenent de la dedicació diària disponible
del personal encarregat es trigaria més o menys temps en finalitzar la tasca.
Al tractar-se de projectes interns de l’entitat, si l’estimació fos superior al que realment
s’acaba necessitant, els fons reservats per al projecte es recuperarien, evitant
provocar despeses de més, que per a tantes aplicacions podria ser un cost
considerable. De totes maneres, aquests pressupostos han de ser prèviament
aprovats, com es veu a la següent fase, abans de passar a fase de producció.
4.4.4. Aprovació de pressupostos i implementació del registre.
Per acabar, seria necessària l’aprovació dels pressupostos per a cadascuna de les
aplicacions. Al tractar-se de tantes, tan variades i amb estats actuals diferents, els
Diagrama 4: Part de l’esquema referent a l’obtenció de pressupostos. Elaboració pròpia
37
pressupostos variaran molt els uns dels altres, és per això que es demanarà una
justificació de la quantia requerida.
Per a la aprovació dels pressupostos serà necessària la intervenció d’una figura amb
càrrec directiu dins l’entitat, ja que com a consultora tecnològica, no podem aprovar
pressupostos de manera independent.
Aquest càrrec serà directiu, o que reporti directament a la direcció, en el nostre cas
es tractarà del CISO, un cop tots els pressupostos siguin centralitzats, es passarà un
informe amb tots els pressupostos, amb les justificacions necessàries per aquells
pressupostos mes costosos.
En base al cost, i al potencial risc que suposaria no implementar el registre, es a dir,
fent un anàlisi cost/benefici, el CISO decidirà si aprova o rebutja el pressupost per a
cada aplicació.
Aquest anàlisi contemplaria un escenari crític de desastre i es calcularia l’impacte
monetari que tindria amb i sense tenir el registre implementat, si l’impacte econòmic
fos considerablement menor al cost de la implementació del registre i la seva
integració al SIEM, no sortiria a compte dur-lo a terme.
També és possible que es decideixi reduir els requeriments de logs a registrar per així
disminuir el cost de la seva implementació, així doncs es duria a terme una negociació
amb el responsable de l’aplicació per veure quina seria la millor alternativa.
La implementació del registre la duran a terme el/s programadors responsables, i per
a passar les dades i integrar l’aplicació al SIEM crearan una integració personalitzada9
per a RSA NetWitness.
9 Per a més informació sobre la creació d’una integració personalitzada: https://community.rsa.com/docs/DOC-107252
38
Diagrama 5: Part de l’esquema referent a l’aprovació de pressupostos i implementació dels registres. Elaboració
pròpia
4.4.5. Reporting a client
Pràcticament la totalitat de les fases anteriors es duen a terme per la consultora, o
com a mínim, aquesta fa d’intermediària, per tant, es faran rutinàriament reunions amb
el cap de projecte per part de client, en aquest cas el CISO o un càrrec just per sota
d’aquest.
Amb aquest es parlarà l’estat del projecte així com també possibles noves propostes
per al projecte.
Per al reporting de l’estat del projecte es farà ús de pàgines com les mostrades en les
imatges 10 i 11. Aquestes han sigut anonimitzades per qüestions de confidencialitat.
A la imatge 10 es mostra la portada amb l’estat general de la fase de les comentades
anteriorment en que es trobi el projecte a fi de mostrar l’estat en que es troba d’una
manera intuïtiva.
A aquesta es mostren les barres de progrés per a les fases identificades (la recol·lecta
de l’estat actual, el progrés de la pressupostació i el progrés de la implantació)
39
Les dues primeres representen la quantitat d’aplicacions de les quals es coneix l’estat
actual (amb el formulari 1 complet per aquestes) i la quantitat de responsables amb
els que s’ha contactat respectivament.
Haver contactat no significa necessàriament que fruit de la primera contestació
s’obtinguin les dades requerides. Cada responsable es troba en una situació diferent,
ja sigui per falta de coneixement en l’àmbit o per consultes puntuals, molts demanen,
abans de facilitar la informació, dur a terme una reunió o una trucada per a respondre
consultes, d’altres no disposen de temps per a respondre immediatament, i per
aquesta raó, al moment de capturar la Imatge 10 s’havia contactat amb tots els
responsables però no es coneixia l’estat actual per a totes les aplicacions.
Imatge 10: Reporting a client: Visió general. Elaboració pròpia
A la imatge 11 es desglossa el progrés segons l’àrea de la que es tracti.
Cada àrea es troba representada per una barra al gràfic en que es divideix
percentualment l’estat en que es troben les aplicacions que hi pertanyen.
Els diferents estats en que pot estar una aplicació són:
Amb resposta: El responsable de l’aplicació ha respost però no ha facilitat les
dades encara, això pot ser tant una consulta per part seva, com una notificació
de que s’està treballant per obtenir les dades.
40
Sense resposta: El responsable no ha respost al nostre contacte, si des de
client (direcció) donen el vistiplau es procedirà a trucar o escalar el fil.
Retirada: L’aplicació identificada es troba en estat d’inactivitat permanent, per
tant, no caldrà dur a terme l’exercici de registre de logs integració amb el SIEM.
No implementada: Excepció. L’aplicació no es troba encara en fase de
producció i no ha acabat de ser desenvolupada; es comunicarà la necessitat
de dur a terme l’exercici quan aquesta sigui implementada.
Finalitzada: Ja s’ha obtingut tota la informació requerida sobre l’estat en que
es troben les aplicacions actualment.
A més, cadascuna de les barres disposa d’un botó a la part dreta que porta
directament a l’excel amb les pàgines que contenen versions del formulari 1 amb la
informació de cadascuna de les aplicacions que pertanyen a l’àrea.
Imatge 11: Reporting a client: Progrés per àrea. Elaboració pròpia
41
4.5. Regles de correlació: Casos d’ús
Ja hem definit, en una secció anterior, les dades que requerirem que siguin
emmagatzemades, i una vegada aquestes són registrades, s’haurà d’aplicar l’analítica
corresponent per poder identificar les anomalies que es produeixin dins l’organització.
Aquesta pot ser molt complexa o molt simple, si és simple té l’avantatja que és més
comprensible i per tant és més fàcilment retocada i optimitzada. A més el retorn en la
inversió d’aquestes és molt elevada.
Tots els casos d’ús han de tenir un cicle de vida, i han de ser actualitzats i revisats
periòdicament, ja que al igual que el negoci les característiques i necessitats poden
canviar i de no fer-se podria resultar en falsos positius o negatius.
Diagrama 6: Cicle de vida d’un Cas d’Ús. Font: https://www.sumologic.com/blog/why-modern-siem/
Al diagrama 6 es veu representat el cicle de vida típic d’un cas d’ús segons Gartner,
on cadascun d’aquests romandrà en constant millora segons el rendiment obtingut.
Un cop un cas d’ús es considera antiquat, haurà de ser esborrat i eliminat
correctament per evitar falses alertes i no dificultar la visió de les que si són realment
importants.
Punts a tenir en compte a l’hora de definir casos d’ús:
Intents de comprometre les credencials d’un usuari:
Es registren múltiples intents d’inici de sessió no satisfactoris a un compte
determinat en un temps curt. (aquest cas d’us, així com la majoria, s’hauria
d’anar perfeccionant amb el pas del temps).
42
Escalat de privilegis no justificat:
Un usuari determinat executa o fa funcions per a les quals originalment no tenia
permisos.
Mal ús d’un compte:
Un compte que porta molt temps inactiu i sobtadament executa una acció pot
ser indicatiu de mal ús d’un compte, i requerirà ser analitzat.
També es pot donar el cas d’una combinació d’aquest cas d’ús amb el Cas d’ús
Número 1 explicat més endavant (Força bruta: molts intents d’accés a un
compte inactiu durant molt de temps).
Si aquest intent d’accés és satisfactori, el SIEM pot procedir a investigar si amb
la mateixa IP s’han dut a terme altres accions inusuals (correlació
d’esdeveniments), com podria ser un escaneig de ports, cas en el qual s’ha
d’elevar la importància de l’amenaça i prendre les mesures necessàries.
Comportament inusual de comptes amb privilegis:
Els comptes amb privilegis o compartits han de ser supervisats més
curosament, ja que són objectius atractius per als hackers.
Un exemple de cas d’us sospitós seria un canvi de contrasenya d’un usuari
amb privilegis a altes hores de la matinada.
Protecció contra pèrdua d’informació
Monitorització de tots els punts de sortida d’informació i de quantitats inusuals
de sortida d’informació. Especial focus en aquells comptes amb accés a
informació més critica i als usuaris que han sigut donats de baixa recentment
o ho seran en poc temps.
Canvis a sistemes
Manipulació de registres d’auditoria o arxius de configuració dels sistemes.
Intents de denegació de servei
Els atacs de denegació de servei són molt coneguts i comuns, i tenen diferents
aproximacions. Un nombre de sol·licituds fora del normal en un temps molt curt
des de diferents ports o la mateixa IP pot ser indicatiu de que s’està produint
un atac DoS, o de denegació de servei.
43
4.5.1. Casos d’ús
A continuació es mostren els diagrames de casos d’ús que duran a terme els actors
en que provocarien l’aparició alertes en el SIEM, seguit dels casos d’ús individuals.
Aquests tan sols representen una mostra, molts més podrien ser afegits amb el temps
així com també perfeccionar i modificar els ja existents, com s’ha vist prèviament amb
el diagrama 6.
Diagrames de casos d’ús:
Diagrama 7: Tipus de compte d’usuari. Elaboració pròpia
44
Diagrama 8. Possibles casos d’ús per a usuaris. Elaboració pròpia
Diagrama 9: Possibles casos d’us per IPs. Elaboració pròpia
A continuació es llisten alguns casos d’ús identificats basats en els diagrames
anteriors:
45
Cas d’ús Força Bruta
Actor principal IP
Precondicions No té sessió iniciada en el sistema
Disparador L’atacant vol iniciar una sessió aliena
Gravetat Baixa
Escenari principal d’èxit
1. L’atacant inicia el panell d’inici de sessió
2. L’atacant envia moltes peticions d’inici de sessió no satisfactòries
(manualment o de manera automatitzada)
Extensions (escenaris alternatius)
1. L’atacant intenta diferents combinacions de la contrasenya per al mateix
usuari en diferents aplicacions en un espai de temps curt
Cas d'ús 1. Força bruta. Elaboració pròpia
Cas d’ús Escalat de Privilegis
Actor principal Usuari no privilegiat
Precondicions L’usuari s’ha identificat
Disparador L’usuari vol dur a terme una acció per a la qual no tenia permisos
Gravetat Alta
Escenari principal d’èxit
1. L’usuari executa un programa o acció per la qual no tenia permisos
originàriament.
Extensions (escenaris alternatius)
Cas d'ús 2. Escalat de privilegis. Elaboració pròpia
46
Cas d’ús Mal ús d’un compte inactiu
Actor principal Usuari
Precondicions L’usuari porta 2 mesos inactiu
Disparador L’usuari vol dur a terme una acció amb un compte inactiu
Gravetat Baixa
Escenari principal d’èxit
1. L’usuari inicia sessió
2. L’usuari executa un programa o acció després d’estar 2 o més mesos
sense registrar activitat.
Extensions (escenaris alternatius)
Cas d'ús 3. Mal ús d’un compte inactiu. Elaboració pròpia
Cas d’ús Canvi de contrasenya general sospitós
Actor principal Usuari
Precondicions No autentificat
Disparador L’atacant vol segrestar un compte d’ usuari
Gravetat Baixa/Mitja
Escenari principal d’èxit
1. L’atacant fa 5 intents d’inici de sessió sobre un mateix usuari no
satisfactoris.
2. L’atacant inicia sessió satisfactòriament per aquest usuari
3. L’atacant canvia la contrasenya per aquest usuari.
Extensions (escenaris alternatius)
Cas d'ús 4: Canvi de contrasenya general sospitós. Elaboració pròpia
47
Cas d’ús Canvi de contrasenya privilegiat sospitós
Actor principal Usuari amb privilegis
Precondicions Horari entre 1 i 5 de la matinada
Disparador L’usuari canvia la contrasenya
Gravetat Mitja
Escenari principal d’èxit
1. L’usuari amb privilegis sol·licita canviar la contrasenya d’usuari a altes
hores de la matinada.
Extensions (escenaris alternatius)
Cas d'ús 5: Canvi de contrasenya privilegiat sospitós. Elaboració pròpia
Cas d’ús Manipulació de registres
Actor principal Usuari
Precondicions L’usuari s’ha identificat
Disparador L’usuari modifica un arxiu de registres
Gravetat Alta
Escenari principal d’èxit
1. L’usuari manipula arxius de registres d’auditoria o arxius de configuració
dels sistemes.
Extensions (escenaris alternatius)
Cas d'ús 6. Manipulació de registres. Elaboració pròpia
48
Cas d’ús Accessos a arxius inexistents
Actor principal IP
Precondicions -
Disparador Una mateixa IP fa molts intents d’accés a arxius/dominis inexistents
Gravetat Baixa
Escenari principal d’èxit
1. Una IP fa molts intents d’accés a arxius/dominis inexistents en un curt espai
de temps
Extensions (escenaris alternatius)
Cas d'ús 7. Accessos a arxius inaccessibles. Elaboració pròpia
Cas d’ús Injecció SQL10
Actor principal IP
Precondicions -
Disparador Es vol accedir a sistemes sense tenir usuari
Gravetat Baixa
Escenari principal d’èxit
1. Un intent d’inici de sessió conté expressions booleanes com “Or 1=1” ja
sigui al nom d’usuari o a la contrasenya.
Extensions (escenaris alternatius)
Cas d'ús 8. Injecció SQL. Elaboració pròpia
10 Tipus d’atac a bases de dades per provocar incorrecta comprovació de credencials i obtenir accés a sistemes
49
4.5.2. Creació d’una regla
En aquest apartat es mostra com es crea una nova regla de correlació per al cas
concret d’RSA Netwitness, SIEM desplegat en els sistemes del client.
L’exemple representa la creació de la regla basada en el cas d’ús Canvi de
contrasenya general sospitós.
A la secció ESA Rules de la pestanya de configuració del software es troba l’opció de
crear una nova regla, aquesta conté els següents paràmetres:
Nom de la regla: Objectiu de la regla en qüestió, per al nostre exemple podríem
posar el mateix nom: Canvi de contrasenya sospitós 1.
Descripció: Descripció del que està detectant aquesta regla.
Regla de prova: Per a executar-la inicialment a mode de prova i veure la seva
efectivitat abans d’establir-la completament.
Gravetat: Nivell de gravetat que es consideraria una alerta causada per
aquesta regla. Per aquest exemple, baixa.
Condicions: Aquí és on s’introduirà l’escenari en que es compliria la regla.
La pestanya de generació de regles es mostra a continuació:
Imatge 12: Generació de regles en RSA NetWitness. Font: https://community.rsa.com/docs/DOC-90539
I l’Escenari en que es compleix (Conditions) s’introdueix de la següent manera:
50
Imatge 13: Condicions de regles en RSA NetWitness. Font: https://community.rsa.com/docs/DOC-90539
D’igual manera, es crearan les regles de correlació per als diferents casos d’ús definits
anteriorment.
4.6. Investigació d’alertes i vulnerabilitats
4.6.1. Anàlisis de les alertes obtingudes
L’anàlisi exhaustiu d’alertes i resposta a les mateixes les durà a terme l’equip tècnic
responsable, en el cas de Deloitte, es tractaria del CyberSOC11, amb coneixements
específics en l’àmbit i experiència, que sabran respondre de manera adequada a les
alertes obtingudes, catalogant-les segons la seva importància i tractant-les prenent
les mesures correctives adients.
La següent imatge mostra una captura del panell de visualització d’alertes, on es
disposarà de la llista d’alertes obtingudes en el sistema, aquesta llista mostra per
cadascuna de les alertes una descripció bàsica, la data, i la gravetat d’aquesta segons
el que es definís a les regles de correlació.
11 Per a més informació: https://www2.deloitte.com/es/es/pages/governance-risk-and-compliance/solutions/cybersoc.html
51
Imatge 14: Pagina de visualització d’alertes en RSA NetWitness. Font: https://community.rsa.com/docs/DOC-
91533
També es disposa de filtres per a poder obtenir una llista que compleixi uns
paràmetres determinats i així facilitar-ne la visualització.
Al seleccionar una alerta determinada, el tècnic disposarà d’una vista amb els detalls
de la alerta. A l’esquerra, es mostrarà una descripció general de l’alerta i a la dreta el
panell d’esdeveniments (un o més) que la formen.
Els esdeveniments mostrats es composaran per aquelles columnes en que es poden
separar els esdeveniments o registres. Com hem definit anteriorment, si són respecte
a aplicacions en les que s’ha treballat en aquest projecte, els camps contindran IP,
terminal, data i hora, usuari i acció duta a terme, com a mínim.
A continuació es mostra la pantalla de vista d’una alerta:
52
Imatge 15: Detalls d’una alerta en RSA NetWitness. Font: https://community.rsa.com/docs/DOC-91533
Al prémer un esdeveniment es mostraran els seus detalls i es podrà veure el context
d’aquest i saber, per exemple, la quantitat d’alertes i incidents relacionats amb el seu
originador (ja sigui una IP o un usuari) així com també el risc que comporta. A més, si
es considera oportú es podrà afegir una IP o usuari concret a una Whitelist o llista
blanca a fi de reduir els falsos positius en futures alertes.
Imatge 16: Resum de dades de context per a l’entitat sel·leccionada en RSA NetWitness. Font:
https://community.rsa.com/docs/DOC-91533
53
4.6.2. Investigació d’usuaris d’alt risc
Una altra característica important de la majoria de SIEMs és la possibilitat d’investigar
usuaris concrets. Per al SIEM RSA NetWitness, que és el que s’ha desplegat en el
client, disposem una vista que seria semblant a un quadre de comandament, on es
troben els usuaris que el sistema considera de major risc, basant-se en les alertes i
incidents en que s’han vist involucrats. La vista en qüestió es mostra a continuació:
Imatge 17: Exemple dels 5 principals usuaris d’alt risc en RSA NetWitness. Font:
https://community.rsa.com/docs/DOC-103902
Aquells usuaris la puntuació dels quals és major a 100 es consideren crítics i
requereixen atenció immediata. Per aquests usuaris s’estudiarà la intenció que tenien,
si era fraudulenta o no, i es miraran totes aquelles alertes relacionades.
Cada cas originarà una resposta diferent depenent del seu context, ja sigui reunir-se
amb l’usuari en qüestió per saber més sobre el que ha succeït o directament revocar
els permisos que tenia com a mesura preventiva.
54
5. PLANIFICACIÓ TEMPORAL
El TFG té una durada d’aproximadament 4 mesos, amb la lectura a finals de gener.
Per tal de poder finalitzar el projecte en el temps esperat és necessari crear una
planificació temporal amb totes les tasques a dur a terme, tot indicant quant de temps
requerirà cada tasca i quina serà la dedicació temporal diària aproximada.
5.1. Tasques a dur a terme:
GEP: Contextualització i abast
GEP: Planificació temporal
GEP: Pressupost i sostenibilitat
GEP: Integració del document final
Resum
Abstracte
Estat de l’art
Recerca de conceptes i temes
Redacció de conceptes i temes
Tecnologia SIEM
Descripció
Desenvolupament i documentació de la part pràctica
- La part pràctica es durà a terme durant tota la jornada laboral, treballant per
a una empresa client, la dedicació a llarg termini dependrà de si es decideix
incorporar-me a nous projectes, però que a inici d’aquest projecte serà de
43 hores setmanals aproximadament. La tasca serà relacionada amb la
gestió i registre de logs de les aplicacions de la empresa client, com ja s’ha
vist a seccions anteriors i no disposa de data fi perquè el projecte continuarà
un cop finalitzat aquest TFG.
Desenvolupament: Recol·lecta
Desenvolupament: Regles de correlació
Desenvolupament: Investigació d’alertes
Conclusions
55
5.2. Taula i diagrama de tasques
Amb una dedicació aproximada de 3h per dia, obtindríem una aproximació temporal
com la següent:
Tasca: Hores Data inici Data fi
GEP: Contextualització i abast 25 16/09/2019 24/09/2019
GEP: Planificació temporal 8 25/09/2019 30/09/2019
GEP: Pressupost i sostenibilitat 9 01/10/2019 07/10/2019
GEP: Integració del document final 20 08/10/2019 14/10/2019
Resum 2 14/10/2019 15/10/2019
Estat de l’art 20 16/10/2019 24/10/2019
Recerca de conceptes i temes 22 25/10/2019 31/10/2019
Redacció de conceptes i temes 10 01/11/2019 04/11/2019
Justificació 5 05/11/2019 06/11/2019
Tecnologia SIEM 40 07/11/2019 18/11/2019
Descripció 15 19/11/2019 22/11/2019
Desenvolupament: Recol·lecta 30 23/11/2019 08/12/2019
Desenvolupament: Regles de correlació 30 09/12/2019 24/12/2019
Desenvolupament: Investigació d’alertes 30 25/12/2019 09/01/2020
Desenvolupament i documentació de la part
pràctica a l’empresa 430 16/09/2019 -
Conclusions 5 10/01/2020 11/01/2020
Total → 271+430
Taula 3: Taula de tasques a dur a terme. Elaboració pròpia
A continuació es mostra el diagrama de Gantt amb les tasques a dur a terme:
56
Diagrama 10: Primera part del diagrama de Gantt referent a les tasques a dur a terme. Elaboració pròpia
57
Diagrama 11: Segona part del diagrama de Gantt referent a les tasques a dur a terme. Elaboració pròpia
58
5.3. Valoració d’alternatives i pla d’acció.
A la recerca de conceptes i temes, així com a l’apartat de Tecnologia SIEM als qual
s’ha donat 22 i 40 hores respectivament, aquestes són comptades dins de la dedicació
diària de 3 hores, però si fos el cas que una requerís més, o si necessités informació
de difícil accés, es poden dedicar hores de la jornada laboral (9 diàries) per a
l’obtenció d’informació i així poder recuperar les hores de desviació temporal que
pogués haver sorgit.
Les dependències entre tasques són simples i per tant, si un apartat, per qualsevol
raó s'hagués de posposar, o, com s’ha comentat en l’apartat anterior, dedicar més
hores de la jornada, es podria seguir treballant en una altra tasca no dependent
d’aquesta sense gaire inconvenient a mig termini.
A la següent taula es mostren diferents factors de risc que poden fer que el
desenvolupament del projecte es vegi afectat:
Risc Gravetat Pla de contingència
Damnificació portàtil Alta Es farà copies diàries a google drive per tal de tenir un backup recent. A més es disposa de segon equip per a poder treballar.
Falta d’informació Mitjana Es disposa de molts companys de feina amb amplis coneixements en el tema a qui consultar.
Discontinuïtat del projecte per part del client.
Alta Es documentaria tot el que s’ha fet i el que estava previst tot indicant les causes de la discontinuïtat.
Taula 4: Factors de risc per al projecte. Elaboració pròpia
En l’inesperat cas que es produís una important desviació temporal irremeiable
s’optaria per prioritzar aquelles tasques de major importància amb més hores de
treball diari.
59
6. PRESSUPOST I SOSTENIBILITAT
6.1. Consideracions:
La gestió de la ciberseguretat dins d’una empresa és una tasca molt laboriosa, doncs
les empreses estan constantment exposades a les amenaces i s’han de mantenir
segures i anticipar-se a les amenaces. Així doncs, els costos relacionats amb
mantenir els sistemes informàtics segurs serà molt variable depenent dels objectius
de cada empresa en aquesta matèria.
6.2. Pressupost de la ciberseguretat:
Segons diverses fonts com ara la mateixa consultora Deloitte12, el pressupost mitjà
en ciberseguretat de les empreses és del 8,5% del pressupost per a IT/OT. Tot i que
al ser una quantitat percentual, fa que el capital monetari i humà destinat a projectes
de ciberseguretat sigui molt heterogeni en funció de la grandària i pressupost IT de
cada empresa. A això cal sumar el fet que hi ha una gran variació de recursos
destinats a IT en funció del sector en que es troba una empresa.
A més, també segons Deloitte13, hi ha una alta relació entre inversió en ciberseguretat
i quantitat d’incidents que es produeixen, la qual cosa demostra que és una inversió
fructosa. Aquelles empreses que inverteixen més del 10% del pressupost IT tenen
una mitja de 0,63 incidents relacionats amb la seguretat a l’any mentre que aquelles
que inverteixen menys de 10% en tenen 3,01.
6.3. Identificació i estimació de costos del projecte:
A continuació s’identificaran els costos relacionats diferents rols i materials implicats
en el projecte en el que estic implicat dins l’empresa, essent aquest tan sols una petita
part dels aspectes sobre els que s’ha de treballar respecte la ciberseguretat d’una
empresa.
6.3.1. Recursos humans
12 Entre d’altres, de l’informe realitzat per Deloitte juntament amb CISOs d’importants empreses:
https://www2.deloitte.com/es/es/pages/risk/articles/preocupaciones-ciso-estado-ciberseguridad.html 13 De l’estudi: https://www2.deloitte.com/es/es/pages/risk/articles/preocupaciones-ciso-estado-ciberseguridad.html
60
Aquest consta de dos consultors en ciberseguretat a temps complet i un manager
amb una dedicació setmanal aproximada de 8 hores. El TFG i té una durada
aproximada de 3 mesos, però per altra banda, el projecte en si (Integració total al
SIEM) tindrà una durada superior, aproximadament de 9 a 12 mesos, doncs es
requereix la intervenció de moltes parts involucrades que no sempre podran executar
el que es demani immediatament.
A més, es requereix per part de l’empresa client que es dediquin certes hores de feina
per cada aplicació a millorar, que serà d’aproximadament 20 hores per cada aplicació
(varia segons l’estat actual de les aplicacions), amb unes 885 aplicacions sobre les
quals aplicar les millores (Registre complet de logs i integració amb SIEM).
Els salaris utilitzats són basats en estimacions tenint en compte la situació actual del
mercat i no representen el cost real d’aquest projecte.
Rol Hores estimades Remuneració Cost estimat
2x Consultor Ciber 2x480 70€/h 67200€
1x Manager (consultora)
120 100€/h 12000€
885x Programadors
20x885 30€/h 531000€
TOTAL 18780 - 610200€
Taula 5: Pressupost de recursos humans. Elaboració pròpia
A això cal afegir el cost de la seguretat social dels empleats, que serà per a tots
aquests, de 30,9%, així doncs, el cost real que tindrà serà de 610200* 1,309 =
798751,8 €
Així doncs, el cost total obtingut pel que fa als recursos humans seria de 798751,8 €,
pot semblar una xifra molt elevada, però cal tenir en compte que es tracta d’una
empresa, que per qüestions de confidencialitat no pot ser mencionada, però que té
un patrimoni net d’uns 12000 Milions d’euros, per tant no representa una inversió tant
summament elevada com ho seria per una Pyme. D’altra banda pel que fa a les hores,
18780, al ser dutes a terme per 885 aplicacions independents sobre les quals es pot
treballar paral·lelament, es pot assolir dins del termini establert.
6.3.2. Recursos materials
61
La Taula 6 reflecteix els costos de Software i Hardware:
Tant Ms Office con l’ordinador portàtil, són actius que poden ser usats durant un llarg
període de temps, i per tant, subjectes a amortitzacions. Posarem que tenen una vida
útil de 5 anys abans que calgui renovar els equips. així doncs, el cost serà repartit en
5.
De 99€ que val la llicència, ens costarà 20 en aquest any fiscal.
I pel cas de l’ordinador que val 1400€, ens costarà l’equivalent a 280 aquest any fiscal.
Recurs Cost
MS Office Pro Plus 20€
RSA NetWitness SIEM 780€/mes*
Ordinador portàtil 280€
Gantter 0€
Windows 10 0€**
Total 2640€
Taula 6: Recursos materials necessaris. Elaboració pròpia
*Preu del SIEM on s’integrarà el registre de logs, segons esecurityplanet14
** Preu inclòs en el preu de l'ordinador portàtil
El preu total estimat són 2640€ per a la durada del projecte, però el cost mensual del
SIEM haurà de continuar sent pagat de manera indefinida.
6.3.3. Costos directes per activitat
Activitat Hores Responsable Cost
1. Comunicació i recol·lecció i anàlisi d’informació
2x480 Consultor 67200€
2. Anàlisi estat actual 1x885 Programadors 26550€
3. Presa de decisions i anàlisi
120 Manager 12000€
4. Implementació registre logs
19x885 Programadors 504450€
14 https://www.esecurityplanet.com/products/rsa-netwitness-siem.html
62
TOTAL 18780 - 610200€
Taula 7: Costos directes per activitat. Elaboració pròpia
A aquests costos cal, com hem fet anteriorment, afegir els costos de seguretat social,
així doncs, els costos directes totals seran: 798751,8 €
6.3.4. Costos indirectes
Com a costos indirectes es poden classificar el consum energètic i la connexió a
internet, com s’ha representat a las taula 8.
S’han agafat preus al voltant del preu mitjà a Espanya per a cadascun dels serveis,
amb 0,15€/kWh pel cas del consum energètic i 40€/mes per a la connexió a internet
dels dispositius.
Servei Preu Període Cost
Connexió a internet 40€/mes 3 mesos 120€
Consum energètic 0,15€/kWh 18780h 158,35€
Total 278,35€
Taula 8: Costos indirectes del projecte. Elaboració pròpia
Cost consum energètic = 56,2 Wh = 0,0562 kW*18780h = 1055,436 kWh *
0,15€/kWh = 158.35€
6.3.5. Contingències i Imprevistos
Els càlculs i estimacions s’han dut a terme amb la millor aproximació possible, per al
ser un projecte que depèn de tant de personal, amb el qual només es té contacte
digital o telefònic (Programadors i responsables d’aplicacions), és possible que es
produeixi algun imprevist pel que fa als recursos que s’han de dedicar, per això, es
destinarà un 15% addicional de recursos per combatre aquests imprevistos.
Si sorgeixen imprevistos molt probablement sigui degut a la intervenció d’un elevat
nombre de persones, la indisponiblitat d’alguna podria provocar un lleuger increment
dels recursos requerits.
Això seria:
63
Cost imprevistos = 0,15 * (costos directes + costos indirectes) = 0,15*(798751,8 +
278,35) = 119854,52€
6.3.6. Pressupost total
Per acabar, el pressupost total del projecte englobant els aspectes vists anteriorment
serà:
Concepte Cost
Costos directes 610200€
Costos indirectes 278,35 €
Imprevistos i Contingència 119854,52€
Recursos materials 2640€
Total 732972,87€
Taula 9: Pressupost total del projecte. Elaboració pròpia
6.3.7. Control de gestió
Per tal de mantenir el control pressupostari, cada setmana es farà un recompte
d’hores dedicades al projecte classificats segons el rol en una taula com la següent:
Setmana Consultors Managers Programadors
30/09 - 06/10 4h 4h -
Taula 10: Control de gestió. Elaboració pròpia
Així, a mesura que evoluciona el projecte s’anirà veient com d’exactes eren les
estimacions i si hi ha o no desviacions i es podran prendre les mesures que convingui.
6.4. Sostenibilitat
6.4.1. Impacte econòmic
Hem comprovat que el cost econòmic del projecte és molt elevat però com ja s’ha
comentat amb anterioritat, es tracta d’una multinacional molt gran i que gràcies a la
64
implementació total del registre de logs permetrà evitar catàstrofes de ciberseguretat
que poden tenir un impacte molt major que la inversió en el projecte.
A més, com ja hem vist, la inversió en ciberseguretat és inversament proporcional a
la quantitat de ciberincidents que es produeixen en una empresa.
6.4.2. Impacte social
L’impacte social del projecte en concret seria molt reduït, doncs el fet de tenir un
registre complet de logs no suposarà cap diferència d’ús en el dia a dia, el que si pot
però és canviar la manera en que els usuaris fan les coses, ja que si són conscients
que cada operació està sent registrada potser no farien certes accions.
A gran escala el fet de millorar la ciberseguretat pot tenir un impacte molt important,
doncs les persones som usuaris dels serveis de les empreses i un incident de
ciberseguretat en aquestes ens pot afectar directament, i si es tracta d’informació
sensible o dades bancàries pot tenir una gran repercussió sobre la vida de les
persones.
6.4.3. Impacte ambiental
Al projecte, es faran servir tots aquells recursos que siguin necessaris però no més
dels que ho són.
la quantitat de consum energètic és elevada, d’aproximadament 1055,436 kW, però
cal tenir en compte que els ordinadors utilitzats són portàtils amb un consum
relativament baix, si és tractés d’ordinadors sobretaula el consum incrementaria molt.
A més, no es produirà despeses d’impressió de papers innecessàries i es durà a terme
tot de manera digital.
65
7. COMPLIMENT NORMATIU
Addicionalment als beneficis ja esmentats, disposar d’un SIEM en ajudarà a complir
certes normes establertes per organismes reguladors referents a l’emmagatzematge
de logs.
També és important disposar d’aquests per si es dona el cas d’estar en un
procediment judicial per l’ocurrència d’alguna incidència, disposar de les evidències
requerides segons correspongui.
És cert que un SIEM per si mateix podria ser un risc per al complement de la GDPR
en temes de retenció de dades, però aquesta contempla la permissió de retenció en
base a l’interès legítim, com seria la retenció de les dades per motius de seguretat.
Dit això, hi ha molts altres aspectes en que és beneficiós disposar d’un SIEM per al
compliment de la GDPR:
Protecció de les dades: El fet d’usar un SIEM farà que el nivell de protecció de
l’empresa en general augmenti i conseqüentment la protecció de les dades
també.
Visibilitat dels logs: Al tenir les dades centralitzades i de manera estructurada
es facilitarà l’accés als logs.
Notificació de forats de seguretat: Un SIEM ens ajudarà a detectar forats de
seguretat, a alertar al personal de seguretat i a analitzar l’impacte que aquest
pot tenir per tal de realitzar un informe detallat tal i com requereix la GDPR.
Registre del processat de dades: Podrem identificar esdeveniments relacionats
amb dades personals i tenir constància de canvis a les dades per generar
informes tal i com requereix la GDPR.
66
8. CONCLUSIÓ
8.1. Conclusions del projecte
Aquest projecte tenia com a objectiu donar una solució sòlida a un client en vers a la
gestió dels logs per a millorar la ciberseguretat de l’entitat gestionant la transició i
implantació d’aquests en un SIEM i en la finalització d’aquest TFG puc afirmar que
s’han realitzat i establert tots els passos necessaris per que això es faci realitat en un
futur proper.
El projecte degut a la seva magnitud i dependència en moltes parts, no ha finalitzat i
un cop finalitzi la implementació requerirà sempre de personal dedicat per a donar
resposta a les incidències que sorgeixin, com ja estem fent a dia d’avui. Tot i això, va
molt ben encaminat i es troba en la part final de la fase d’obtenció de pressupostos i
pròximament es durà a terme l’última fase d’aprovació i implementació del registre,
segons s’ha definit al model Archi.
Com a conclusió puc dir que estic molt satisfet amb la feina realitzada, i d’haver sigut
capaç de respondre a les necessitats del client i haver pogut gestionar aquesta
transició donant suport tècnic a companys i empleats de l’empresa client gràcies als
coneixements adquirits durant l’etapa universitària.
També considero molt positiu el fet que la universitat ens ajudés amb l’inici de la
realització del treball tenint en compte aspectes tant importants com els treballats a la
fase de gestió de projectes de cara a obtenir una bona planificació en diversos
aspectes.
El modelatge de les tasques que es duien a terme en Archi ha servit per a tenir un
procés definit de cara a no perdre el fil i seguir una metodologia definida en el projecte
així com també per a explicar a client i altres parts interessades el procés seguit, i si
l’empresa decidís canviar la persona responsable o requerís algú que supleixi la meva
labor, aquest simplificaria molt el traspàs i la comprensió.
Molt adequat i professional ha sigut el tracte amb l’empresa en que s’ha dut a terme
el treball, Deloitte, on disposo de molt bons companys dels quals he après molt de
molts àmbits, però sobretot en temes de ciberseguretat. L’empresa va contactar amb
mi gràcies a l’esdeveniment organitzat per l’associació FIB Visiona on vaig tenir
l’oportunitat de donar-me a conèixer i és en aquesta empresa en que pretenc
desenvolupar-me i créixer com a professional en el món de la informàtica.
67
8.2. Competències tècniques finals
CSI2.1: Demostrar comprensió i aplicar els principis i les tècniques de
gestió de qualitat i d'innovació tecnològica a les organitzacions. [Bastant]
La transició d’un estat de desordre i “caos” a un estat d’organització i
centralització dels registres log fent ús d’una eina tant potent com és un SIEM
és un procés de millora de la qualitat organitzativa i mostra voluntat i esforç per
mantenir l’empresa com una referent pel que fa a l’evolució i adaptació a les
noves tecnologies.
CSI2.2: Concebre, desplegar, organitzar i gestionar sistemes i serveis
informàtics, en contextos empresarials o institucionals, per a millorar-ne
els processos de negoci; responsabilitzar-se'n i liderar-ne la posada en
marxa i la millora contínua; valorar el seu impacte econòmic i social. [Una
mica]
Gran part del rol i les tasques dutes a terme en aquest projecte han sigut
l’organització del projecte, la gestió i comunicació amb tots les parts
involucrades, fent d’intermediaris entre responsables d’aplicacions i l’alta
direcció i definint els processos de negoci a seguir.
A més, s’ha realitzat l’estimació pressupostària així com també l’impacte (de
manera genèrica a les institucions) que té el fet de tenir una bona o mala gestió
de la ciberseguretat.
CSI2.5: Demostrar coneixement i capacitat d'aplicació dels sistemes
d'informació empresarial (ERP, CRM, SCM, etc.). [Una mica]
Entenent un SIEM com un sistema d’informació empresarial, s’ha demostrat
coneixement i capacitat d’aplicació d’aquest en el transcurs de tot el projecte.
CSI2.7: Gestionar la presència de l'organització a Internet. [Bastant]
Arran de l’evolució del projecte en que vaig ser assignat, aquesta competència
que inicialment anava a tenir un pes important va veure’s disminuïda fins ser
pràcticament nul·la. De manera indirecta però, la bona gestió de la
ciberseguretat ajuda a mantenir la reputació i presencia de l’organització.
CSI3.1: Demostrar comprensió dels principis de l'avaluació de riscs i
aplicar-los correctament en l'elaboració i l'execució de plans d'actuació.
[En profunditat]
Aquest projecte parteix de la premissa que la ciberseguretat és un dels riscos
més importants contra el que les organitzacions han de lluitar,
68
conseqüentment, es va iniciar el projecte per a la transició a una millor gestió
dels logs que com ja hem vist, és de gran utilitat per a mitigar els riscos als que
les empreses s’exposen.
CSI4.2: Participar activament en el disseny, la implementació i el
manteniment dels sistemes d'informació i de comunicació. [Una mica]
La selecció de les fonts a integrar i la creació de les regles de correlació, així
com també l’anàlisi de les alertes han sigut tasques relacionades amb el
disseny, la implementació i el manteniment dels sistemes d'informació.
Addicionalment a les competències definides des d’un inici, considero convenient
afegir dues competències de l’especialitat de Sistemes d’Informació que també han
estat assolides:
CSI3.5: Proposar i coordinar canvis per a millorar l'explotació del sistema
i de les aplicacions.
El projecte es va originar de la proposta al client de millorar l’explotació dels
sistemes i aplicacions amb la implementació d’un SIEM per així millorar la
maduresa de l’empresa en temes de seguretat de la informació i s’ha pres
l’important paper de coordinar totes les parts involucrades.
CSI1: Demostrar comprensió i aplicar els principis i les pràctiques de les
organitzacions, de manera que puguin exercir d'enllaç entre les
comunitats tècnica i de gestió d'una organització, i participar activament
en la formació dels usuaris.
La funció de gestió d’aquest projecte amb contacte tant amb empleats
encarregats d’aplicacions, amb funció més tècnica i amb els quals em reunia
per a resoldre dubtes, com amb càrrecs directius, per a reportar l’estat del
projecte justifiquen l’assoliment d’aquesta competència.
69
BIBLIOGRAFIA
1. Archimatetool. (s.d.). Obtingut de www.archimatetool.com
2. Columbus., L. (2019). Forbes. Top 10 cybersecurity companies to watch in 2019.
Obtingut de https://www.forbes.com/sites/louiscolumbus/2019/06/16/top-10-
cybersecurity-companies-to-watch-in-2019/
3. Consultancy.uk. (2017). The worlds top 10 largest cybersecurity security
consulting firms. Obtingut de https://www.consultancy.uk/news/13927/the-
worlds-top-10-largest-cybersecurity-security-consulting-firms
4. Deloitte. (2019). Las principales preocupaciones del CISO. Obtingut de
https://www2.deloitte.com/es/es/pages/risk/articles/preocupaciones-ciso-
estado-ciberseguridad.html
5. National Institute of Standards and Technology. (2018). Framework for Improving
Critical Infrastructure Cybersecurity. Obtingut de
https://nvlpubs.nist.gov/nistpubs/CSWP/NIST.CSWP.04162018.pdf
6. RSA. (2018). Alerting: Pestaña Generador de reglas. Obtingut de
https://community.rsa.com/docs/DOC-90539
7. RSA. (2019). Respond: Revisión de alertas. Obtingut de
https://community.rsa.com/docs/DOC-91533
8. RSA. (2019). UEBA: Investigar a los usuarios de alto riesgo. Obtingut de
https://community.rsa.com/docs/DOC-103902
9. Dupont, G. (2016). Recordedfuture. SIEM threat intelligence. Obtingut de
https://www.recordedfuture.com/siem-threat-intelligence-part-1/
10. Europa.eu. (s.d.). La protección de datos en la UE. Obtingut de
https://ec.europa.eu/info/law/law-topic/data-protection/data-protection-eu_es
11. Exabeam. (s.d.). 10 SIEM Use Cases in a Modern Threat Landscape. Obtingut
de https://www.exabeam.com/siem-guide/siem-use-cases/
12. FIB. (2018). El informe de sostenibilidad del TFG. Obtingut de
https://www.fib.upc.edu/sites/fib/files/documents/estudis/informe-
sostenibilidad-espanol-2018.pdf
70
13. Helpsystems. (2019). ¿Qué es un SIEM?. Obtingut de
https://www.helpsystems.com/es/blog/que-es-un-siem
14. Ionos. (2016). Ficheros log: Toda la información de registro en un archivo.
Obtingut de https://www.ionos.es/digitalguide/online-marketing/analisis-
web/el-log-el-archivo-de-registro-de-procesos-informaticos/
15. Karnam, S. (2019). Sumo logic. 10 Modern SIEM Use Cases. Obtingut de
https://www.sumologic.com/blog/why-modern-siem/
16. Robb, D. (2018). Esecurityplanet. RSA NetWitness Suite: SIEM Product
Overview and Insight. Obtingut de
https://www.esecurityplanet.com/products/rsa-netwitness-siem.html
17. RSA. (s.d.). Documentación de RSA NetWitness. Obtingut de
https://community.rsa.com/community/products/netwitness/documentation/sp
anish
18. Techtarget. (2014). The past, present and future of SIEM technology. Obtingut
de https://searchsecurity.techtarget.com/video/The-past-present-and-future-
of-SIEM-technology
19. Zeltser, L. (2016). Zeltser. Critical Log Review Checklist for Security Incidents.
Obtingut de https://zeltser.com/security-incident-log-review-checklist/