Procesos relevantes para la

Gestión de Riesgos y
Ciberseguridad
Profesor: Wilson España

Facultad de Ingeniería
Contenido
Tema 1. Introducción .................................................................................................................. 4
Tema 2. Monitoreo y comunicación de incidentes................................................................... 5
Modelo de funcionamiento..................................................................................................... 6
Monitoreo y comunicación ................................................................................................. 6
Equipos de respuesta .......................................................................................................... 6
Señales de un incidente .......................................................................................................... 7
Notificación de incidentes .................................................................................................... 10
Tema 3. Formación y concientización..................................................................................... 12
Programa de formación y concientización ......................................................................... 12
Aspectos clave para tener en cuenta al momento de implementar un programa de
formación y concientización ................................................................................................ 13
Apoyo de la alta dirección ................................................................................................. 13
Posicionamiento del término “Security Awareness”....................................................... 13
Establecer un diagnóstico ................................................................................................ 14
Definición de Objetivos y recursos disponibles .............................................................. 14
Definir una estrategia basada en la situación particular ................................................ 14
Conectado con el público ................................................................................................. 14
Apuntar al “por qué” .......................................................................................................... 14
Utiliza recursos imaginativos ........................................................................................... 15
Debe ser medible ............................................................................................................... 15
Adaptativo .......................................................................................................................... 15
Tema 4. Gestión de usuarios y accesos.................................................................................. 16
Actividades de gestión de acceso ....................................................................................... 17
Solicitud de acceso ........................................................................................................... 17
Verificación ........................................................................................................................ 17
Monitoreo del estado de la identidad .............................................................................. 17
Logging y seguimiento ...................................................................................................... 18
Eliminación o restricción de privilegios ........................................................................... 18
Subprocesos .......................................................................................................................... 19
Mantener un catálogo de roles de usuario y perfiles de acceso: .................................. 19
Aprovisionamiento de solicitudes de acceso de usuarios: ............................................ 19

FACULTAD DE INGENIERÍA 2
 Asignación de privilegios .................................................................................................. 19
Consideraciones en la implementación........................................................................... 20
Tema 5. Gestión e inventario de activos ................................................................................. 21
Identificación y clasificación de activos.............................................................................. 21
Identificación y descubrimiento ....................................................................................... 21
Clasificación de activos .................................................................................................... 21
Propósito y beneficios de clasificar los activos.............................................................. 22
Protegiendo los activos ........................................................................................................ 23
Definición de una línea base ............................................................................................. 23
Manejo de medios ................................................................................................................. 24
Tema 6. Corrección y gestión de vulnerabilidades................................................................. 26
Proceso de Patch Management ........................................................................................... 26
La Importancia de parchar.................................................................................................... 27
Desafíos al momento de parchar ......................................................................................... 28
Tiempo, priorización y pruebas: ....................................................................................... 28
Configuración del parchado:............................................................................................. 29
Arquitecturas diferentes: .................................................................................................. 29
Otros desafíos:................................................................................................................... 30
Participantes del proceso ..................................................................................................... 30
Actividades contempladas en el proceso ........................................................................... 30
Consideraciones y recomendaciones.................................................................................. 31
Tema 7: Conclusiones .............................................................................................................. 33
Bibliografía................................................................................................................................. 34

FACULTAD DE INGENIERÍA 3
Tema 1. Introducción
En el camino a lograr un adecuado nivel de ciberseguridad en las organizaciones, nos
encontramos con elementos que forman parte fundamental en el éxito de este objetivo.
Uno de estos aspectos lo constituyen los procesos que rigen el funcionamiento de las
organizaciones y poseen un carácter estratégico para su adecuada definición, implantación
y operación en el tiempo.

La naturaleza de la organización, los objetivos de negocio, su cultura organizacional, las

regulaciones entre otros aspectos, necesariamente deben ser considerados al momento de
planificar en la selección, diseño e implementación de ciertos procesos específicos
relacionados con la ciberseguridad. Si bien, podemos tener claridad respecto al objetivo de
cada uno de ellos, estos aspectos nos aportarán mucha claridad al momento de tomar
decisiones como responsables de ciberseguridad de cualquier organización.

Finalmente, junto con los aspectos anteriores, el estado de madurez de la seguridad de la

información y ciberseguridad, también constituye un elemento fundamental en esta
planificación, sobre todo al momento de priorizar las actividades relacionadas con estos
procesos.

En el transcurso de la clase, revisaremos los aspectos principales del entorno en la nube

para luego revisar los principales procesos relacionados con la ciberseguridad y seguridad
de la información.

FACULTAD DE INGENIERÍA 4
Tema 2. Monitoreo y comunicación de incidentes
El monitoreo y la comunicación de incidentes constituyen en sí mismo, un componente
fundamental de un framework o marco de trabajo relacionado con la Gestión, Respuesta y
Recuperación de Incidentes de Ciberseguridad y forma la base para una gestión efectiva.

Fuente: Adaptado de NIST. (2012).

Computer Security Incident Handling Guide SP 800-61r2.

Este proceso debe considerar aspectos particulares de cada organización, contemplando

elementos tanto técnicos como políticos y en conexión con los objetivos del negocio.

Entre las características principales de este proceso se tienen las siguientes:

• Debe estar disponible para cualquier persona que descubra o sospeche que ha
ocurrido un incidente que involucra a la organización.

• Se deben analizar los datos en el menor tiempo posible para determinar el impacto
y actuar adecuadamente para minimizar el daño y restaurar los servicios normales.

• Depende de la participación y cooperación de las personas en toda la organización.

• El proceso de monitoreo y comunicación de incidentes está soportado por el equipo

de respuesta a incidentes.

FACULTAD DE INGENIERÍA 5
Modelo de funcionamiento
El modelo de funcionamiento se estructura a partir del monitoreo y comunicación de
Incidentes, el cual puede ser organizado de manera centralizada o distribuida. Así mismo,
el monitoreo y la comunicación son parte de las actividades del equipo de respuesta a
incidentes, el cual puede usar cualquiera de los tres modelos de personal:

Monitoreo y comunicación
Centralizado: un solo equipo de respuesta a incidentes para toda la organización. Este
modelo es efectivo para organizaciones pequeñas y para aquellas con una diversidad
geográfica mínima en términos de recursos informáticos.

Distribuidos: la organización cuenta con múltiples equipos de respuesta a incidentes, cada

uno responsable de un segmento lógico o físico particular de la organización.

Este modelo es efectivo para organizaciones grandes como por ejemplo, un equipo por
división y para aquellas con importantes recursos informáticos en ubicaciones distantes.

Sin embargo, los equipos deben ser parte de una sola entidad coordinada, para que el
proceso de respuesta a incidentes sea consistente en toda la organización y la información
se comparta entre los equipos. Esto es particularmente importante porque varios equipos
pueden revisar componentes del mismo incidente o pueden manejar incidentes similares.

Equipos de respuesta
Interno: la organización realiza todo su trabajo de respuesta a incidentes, con un apoyo
técnico y administrativo limitado por parte de los contratistas.

Outsorcing parcial o mixto: la organización externaliza partes de su trabajo de respuesta a

incidentes. El acuerdo más frecuente es que la organización externalice el monitoreo de
sensores de detección de intrusiones, firewalls y otros dispositivos de seguridad las 24
horas del día, los 7 días de la semana (24/7) a un proveedor de servicios de seguridad
administrado fuera del sitio o MSSP (Managed Security Service Provider). El MSSP identifica
y analiza actividades sospechosas e informa cada incidente detectado al equipo de
respuesta a incidentes de la organización.

FACULTAD DE INGENIERÍA 6
Algunas organizaciones desarrollan un trabajo básico de respuesta a incidentes
internamente y solicitan a los contratistas que ayuden con su manejo, particularmente en
aquellos que son más graves o generalizados.

Totalmente tercerizado: la organización externaliza por completo su trabajo de respuesta

a incidentes, generalmente a un contratista in situ. Es muy probable que este modelo se use
cuando la organización necesita un equipo de respuesta a incidentes presencial y a tiempo
completo, pero no tiene suficientes empleados calificados disponibles. Se supone que la
organización tendrá empleados que supervisen y evalúen el trabajo del subcontratista.

Señales de un incidente
Para muchas organizaciones, la parte más difícil del proceso de respuesta a incidentes es
detectar y evaluar con precisión los posibles incidentes, determinando si se ha producido
un incidente y, de ser así, el tipo, el alcance y la magnitud del problema. Lo que hace que
esto sea tan desafiante es una combinación de tres factores:

• Los incidentes pueden detectarse a través de muchos medios diferentes, con

diferentes niveles de detalle y fidelidad. Las capacidades de detección
automatizada incluyen IDPS (Identification and Prevention Systems) basados en red
y en host, software antivirus y analizadores de registros. Los incidentes también
pueden detectarse a través de medios manuales, como problemas informados por
los usuarios. Algunos incidentes tienen signos evidentes que pueden detectarse
fácilmente, mientras que otros son casi imposibles de detectar.

• El volumen de posibles señales de incidentes suele ser alto; por ejemplo, no es raro
que una organización reciba miles o incluso millones de alertas de sensores de
detección de intrusos por día.

• Se necesitan conocimientos técnicos especializados y profundos y una amplia

experiencia para un análisis adecuado y eficiente de los datos relacionados con
incidentes.

Las señales de un incidente se dividen en una de dos categorías: precursores e indicadores.

Un precursor es una señal de que puede ocurrir un incidente en el futuro. Un indicador es
una señal de que un incidente puede haber ocurrido o puede estar ocurriendo ahora.

Si se detectan precursores, la organización puede tener la oportunidad de prevenir el

incidente alterando su postura de seguridad para hacer frente a un objetivo del ataque.

FACULTAD DE INGENIERÍA 7
Como mínimo, la organización podría monitorear la actividad que involucra al objetivo.
Ejemplos de precursores son:

• Entradas de registro del servidor web que muestran el uso de un escáner de

vulnerabilidades.

• Un anuncio de un nuevo exploit que se dirige a una vulnerabilidad del servidor de

correo de la organización.

• Una amenaza de un grupo que indica que atacará a la organización.

Existen demasiados tipos de indicadores para enumerarlos exhaustivamente, pero a

continuación se enumeran algunos ejemplos:

• Un sensor de detección de intrusiones en la red alerta cuando se produce un intento

de desbordamiento de búfer contra un servidor de base de datos.

• El software antivirus alerta cuando detecta que un host está infectado con malware.

• Un administrador del sistema ve un nombre de archivo con caracteres inusuales.

• Un host registra un cambio de configuración de auditoría en su registro.

• Una aplicación registra múltiples intentos fallidos de inicio de sesión desde un

sistema remoto desconocido.

• Un administrador de correo electrónico ve una gran cantidad de correos electrónicos

rechazados con contenido sospechoso.

• Un administrador de red nota una desviación inusual de los flujos de tráfico de red
típicos

La detección y análisis de incidentes sería fácil si se garantizara que cada precursor o

indicador sea exacto; por desgracia, este no es el caso. Por ejemplo, los indicadores
proporcionados por el usuario, como una queja de que un servidor no está disponible, a
menudo son incorrectos. Los sistemas de detección de intrusiones pueden producir falsos
positivos o indicadores incorrectos.

FACULTAD DE INGENIERÍA 8
Estos ejemplos demuestran lo difícil que resultan la detección y el análisis de incidentes.
Idealmente, cada indicador debe evaluarse para determinar si es legítimo y para empeorar
las cosas, el número total de indicadores puede ser de miles o millones por día por lo que
encontrar los incidentes de seguridad reales que ocurrieron en todos los indicadores puede
ser una tarea desalentadora.

Los precursores e indicadores se identifican utilizando muchas fuentes diferentes, siendo

las más comunes las alertas de software de seguridad, los registros, la información
disponible públicamente y las personas.

Tipo Fuente

IDPSs

SIEMs

Alertas AV Antispam

FIM

Fuentes externas

Internas
Personas
Externas

Información pública Nuevas vulnerabilidades y exploits

S.O. Aplicaciones

Logs Disp. Red

Net Flows

Fuente: SP 800-61 Rev. 2 Computer Security Incident Handling Guide

FACULTAD DE INGENIERÍA 9
Notificación de incidentes
Cuando se analiza y prioriza un incidente, el equipo de respuesta al incidente debe notificar
a las personas apropiadas para que todos los que necesiten participar desempeñen sus
funciones. Las políticas de respuesta a incidentes deben incluir disposiciones relativas a la
notificación de incidentes, como mínimo, qué se debe informar a quién y en qué momentos
(por ejemplo, notificación inicial, actualizaciones periódicas del estado). Los requisitos de
informes exactos varían entre las organizaciones, pero las partes que generalmente se
notifican incluyen:

• CIO

• Jefe de seguridad de la información

• Oficial de seguridad local

• Otros equipos de respuesta a incidentes dentro de la organización

• Equipos externos de respuesta a incidentes, en caso de que aplique.

• Propietario del sistema

• RR. HH. para casos que involucran a empleados).

Durante el manejo de incidentes, el equipo puede necesitar proporcionar actualizaciones de

estado a ciertas partes, incluso en algunos casos a toda la organización. El equipo debe
planificar y preparar varios métodos de comunicación, incluidos los métodos alternativos a
los tecnológicos (por ejemplo, en persona, en papel), y seleccionar aquellos que sean
apropiados para un incidente en particular. Los posibles métodos de comunicación
incluyen:

• Correo electrónico

• Sitio web (interno, externo o portal)

• Llamadas telefónicas

• En persona (por ejemplo, sesiones informativas diarias)

FACULTAD DE INGENIERÍA 10
• Saludo del buzón de voz (por ejemplo, configure un buzón de voz separado para
actualizaciones de incidentes y actualice el mensaje de saludo para reflejar el
estado actual del incidente; use el saludo de correo de voz de la mesa de ayuda)

• Papel (por ejemplo, publicar avisos en tableros de anuncios y puertas, entregar

avisos en todos los puntos de entrada).

FACULTAD DE INGENIERÍA 11
Tema 3. Formación y concientización

Programa de formación y concientización

Establecer un programa de formación y concientización en la organización es fundamental
para lograr una real integración de la seguridad de la información y la ciberseguridad, con
un adecuado nivel de profundidad y especificidad en todos los niveles de la organización.

Durante este proceso, se debe tener en cuenta los roles y responsabilidades de cada una
de las partes interesadas (stakeholders) y cuál es el nivel de conocimiento, educación y
awareness necesario para cumplir los objetivos trazados en el plan, todo alineado con los
objetivos de la organización.

A continuación, revisaremos algunas consideraciones adicionales al momento de diseñar

e implementar un programa de formación y concientización:

• Asegurarse de que el material de concientización y capacitación desarrollado sea

apropiado y oportuno para el objetivo y la audiencia.

• Garantizar que el material de concientización y capacitación se implemente

efectivamente para llegar a la audiencia deseada.

• Corroborar que los usuarios y gerentes tengan una manera efectiva de proporcionar
comentarios sobre la conciencia, material de capacitación y su presentación.

• Confirmar que el material de sensibilización y capacitación se revise periódicamente

y se actualice cuando sea necesario.

• Establecer una estrategia general para el programa de concientización y

capacitación en seguridad de TI.

• Confirmar que el programa de capacitación y concientización en seguridad de la

información esté financiado.

• Asegurarse que todos los usuarios estén suficientemente capacitados en sus

responsabilidades.

• Cerciorarse que existan mecanismos efectivos de seguimiento y reporte.

FACULTAD DE INGENIERÍA 12
Por otra parte, si bien existen empresas que pueden pertenecer a un determinado sector
económico o tener una equivalencia en tamaño y organización, cada una de ellas en
particular tiene características individuales que deben ser consideradas al momento de
definir un programa de formación y concientización.

Entre los aspectos a considerar en cada organización podemos mencionar, entre otros:

• La cultura organizacional

• Rango etario de los colaboradores

• Ubicación geográfica

• Aspectos de idioma

• Culturas locales

• Leyes y reglamentaciones

A continuación, presentamos una lista de aspectos clave para tener en cuenta al momento
de implementar un programa de formación y concientización.

Aspectos clave para tener en cuenta al momento de

implementar un programa de formación y concientización

Apoyo de la alta dirección

• Uno de los puntos más importantes en todo programa de formación y
concientización es el apoyo de la alta administración. Este apoyo, más que un
aspecto económico, representa el empoderamiento y el compromiso de la alta
administración con los objetivos y los resultados que se pretenden conseguir.

• Cada integrante de la organización debe percibir explícitamente este apoyo.

Posicionamiento del término Security Awareness

• Entender el concepto es el primer paso para la creación de conciencia.

FACULTAD DE INGENIERÍA 13
 • El proceso de awareness, capacitación y educación es un continuo.

Establecer un diagnóstico
• El punto de partida para establecer objetivos claros y obtener resultados eficientes
parte por un adecuado diagnóstico de la situación.

• Se deben fijar parámetros de referencia que permitan una adecuada medición del
diagnóstico. (benchmark, niveles esperados, etc.).

Definición de objetivos y recursos disponibles

• El correcto equilibrio entre los objetivos y los recursos disponibles generará
expectativas reales. De lo contrario solo tendremos problemas.

Definir una estrategia basada en la situación particular

• La estrategia a utilizar debe estar sustentada en un entendimiento de la situación
particular de cada organización.

Conectado con el público

• La conexión con la audiencia genera lazos que permiten transmitir de manera fluida
el mensaje.

• La utilización de historias que identifiquen la realidad y necesidades de la audiencia

• Generalmente es necesario agrupar la audiencia dependiendo de sus intereses y

necesidades.

Apuntar al ¿por qué?

• Los programas de concientización y capacitación deben diseñarse teniendo en
cuenta la misión de la organización. Es importante que el programa de
concientización y capacitación respalde las necesidades de la organización y sea
relevante para la cultura de esta. Los programas más exitosos son aquellos que los
usuarios sienten son relevantes para el tema y los problemas presentados.
FACULTAD DE INGENIERÍA 14
Utiliza recursos imaginativos
• El mundo de hoy ofrece una vasta cantidad de alternativas para transmitir el
mensaje y lograr los objetivos de formación y concientización.

• La utilización de recursos imaginativos es una excelente vía para conectar con la

audiencia.

Debe ser medible

• La definición de métricas permite medir objetivamente los logros y la consecución
de los objetivos.

• Un programa de concientización que no se puede medir, no permite que se adapte y

se mejore.

Adaptativo
• La adecuación de los distintos elementos del programa permite hacer frente a la
respuesta dinámica del público objetivo.

• La adaptación del plan permite hacer frente a entornos y escenarios dinámicos.

FACULTAD DE INGENIERÍA 15
Tema 4. Gestión de usuarios y accesos
El acceso debe otorgarse de acuerdo con las reglas establecidas por la política de seguridad
de la información, esto quiere decir que la gestión de acceso no debe dictar ninguna de las
políticas de seguridad. Las actividades de gestión de acceso tanto físico como lógico, por
lo tanto, responden de acuerdo con las reglas que ya se han establecido.

Fuente: Elaboración propia

FACULTAD DE INGENIERÍA 16
Actividades de gestión de acceso

Solicitud de acceso
Este es el primer paso en la implementación de la gestión de acceso. Las solicitudes pueden
venir de la mesa de servicio a través de una solicitud (en operación) o de una solicitud de
cambio (en transición). En ocasiones, el acceso puede implicar pasar de no tener acceso a
tener acceso, o de tener un nivel de acceso a otro nivel. Idealmente, el catálogo de servicios
debe incluir procesos para responder a cada una de las solicitudes, permitiendo definir
claramente las actividades, sin dar lugar a improvisaciones o aplicación de criterios
subjetivos al momento de procesar la solicitud.

Esta actividad debe definir quién puede solicitar acceso, qué información se requiere y
cómo pasará la solicitud a través del sistema.

Verificación
Esta actividad verifica que un individuo que solicita acceso está calificado para solicitarlo,
el usuario debe demostrar su identidad y que tiene un motivo legítimo para la solicitud. Los
diferentes niveles de acceso pueden incluir diferentes cantidades de verificación; por
ejemplo, el acceso para ver y editar informes financieros debe requerir requisitos de
aprobación muy diferentes a la verificación requerida para crear un nuevo usuario con
permisos predeterminados.

Monitoreo del estado de la identidad

Los cambios en el estado de la identidad son de vital importancia, especialmente para las
grandes organizaciones, aquí es donde es vital tener un repositorio de acceso que ya se ha
otorgado.

Si hay demasiadas personas procesando solicitudes de cambio de acceso, existe la

posibilidad de que se otorgue acceso que podría entrar en conflicto con otro acceso
otorgado, por otra parte, el monitoreo automático de los cambios de seguridad también
garantiza que el acceso solo se otorgue de acuerdo con la política.

FACULTAD DE INGENIERÍA 17
Logging y seguimiento
Al registrar la actividad y rastrear los cambios de acceso, nos aseguramos que el acceso
otorgado solo se use según lo previsto, el seguimiento de los cambios también protege a la
organización de las brechas y riesgos de seguridad. Los eventos tales como el acceso no
autorizado, la actividad inusual de la aplicación y los intentos excesivos de inicio de sesión
incorrecto, deben evaluarse para detectar infracciones a las definiciones de seguridad o
actividad de malware.

Eliminación o restricción de privilegios

Esta actividad implica eliminar el acceso una vez que se le ha otorgado o restringirlo en
función de los roles de los usuarios, esto ocurre cuando estos cambian de roles en el
transcurso de su empleo, trabajando en diferentes departamentos o en diferentes sistemas.

Ya sea que un usuario sea despedido, fallezca, cambie de rol, departamento o de ubicación
física, debe existir un proceso para otorgarles el acceso que su rol debería permitir, cuyas
actividades son la base de una política sólida de seguridad de la información, debiendo
existir flujos claramente definidos para cada actividad, y qué se aplica a cada rol de usuario.

FACULTAD DE INGENIERÍA 18
Subprocesos

Mantener un catálogo de roles de usuario y perfiles de acceso:

Este subproceso implica construir y mantener un repositorio activo de todos los roles de
usuario y perfiles de acceso dentro de la organización. Los roles de usuario son listados
definidos y jerarquías de todos los roles en una organización, incluidos los tipos de usuarios,
como el agente de la mesa de servicio, el usuario comercial, el vendedor, etc.

Es importante revisar estos roles periódicamente, particularmente cuando las solicitudes

llegan para acceder a cambios que no parecen corresponder al rol. El acceso dado a los
roles también debe evaluarse cuando se compra o se da de baja un nuevo software, lo que
permite otorgar y eliminar el acceso en función del proceso en lugar de solicitudes únicas.

Aprovisionamiento de solicitudes de acceso de usuarios:

Este subproceso es donde entran en juego las actividades de administración de acceso, la
gestión de acceso verifica al usuario, proporciona derechos de acceso, monitorea el estado
de la identidad, elimina o restringe el acceso, lo registra y rastrea. El éxito de este
subproceso depende de la mantención de un perfil de usuario y un repositorio de acceso
que sean precisos.

Asignación de privilegios:
Una vez que el individuo ha sido verificado, es hora de proporcionar acceso. Esto implica
agregar al usuario a un nuevo grupo, si es necesario, es posible que se deban crear
credenciales en cada sistema al que el usuario solicite acceder.

La tarea de la gestión de acceso es garantizar que lo proporcionado no interfiera con ningún

otro derecho de acceso ya otorgado, por lo que, construir el catálogo de roles de usuario y
perfiles de acceso ayuda a mantener en orden a los diferentes grupos. También es
conveniente incluir en este catálogo una matriz de exclusiones para los roles incompatibles.

FACULTAD DE INGENIERÍA 19
Consideraciones en la implementación
• Definición clara de los entes autorizados para requerir el acceso.

• Independencia de funciones.

• Asegurar actividad de asignación y reseteo de credenciales.

• Es más amplio que alta, baja y modificación de usuarios.

• Considerar todas las plataformas (DB, networking, servidores, etc.).

• Modelar casos de uso para alertas y monitoreo del proceso.

• Backup del personal.

FACULTAD DE INGENIERÍA 20
Tema 5. Gestión e inventario de activos

Identificación y clasificación de activos

Identificación y descubrimiento
La identificación y descubrimiento de los activos de una organización puede ser una tarea
ardua y compleja, por lo que se requiere que sea un proceso formal al interior de la
organización. El resultado de este proceso idealmente debe estar integrado con los
procesos aportantes de activos, garantizando con ello un inventario fidedigno y actualizado.

Clasificación de activos
El éxito y confiabilidad del proceso de clasificación radica en el compromiso y apoyo de la
gerencia, definiendo claramente el accountability (o el compromiso o la responsabilidad) y
estar sustentado por una política.

El diseño del proceso y sus definiciones deben hacer que, el determinar los niveles correctos
de clasificación por parte del propietario sea una tarea fácil y certera, permitiendo que otros
entiendan completamente cómo proteger los activos.

Ejemplos de clasificación:

• Ultrasecreto

• Empresa restringida

• Confidencial

• Pública

FACULTAD DE INGENIERÍA 21
Una adecuada política de clasificación de activos debe considerar aspectos tales como:

• ¿Quiénes deberían tener acceso a la data?

• ¿Cómo es asegurado el activo y su contenido?

• ¿Cuánto tiempo debe ser retenida la información?

• ¿Cómo se pone a disposición la data y el activo?

• Condiciones para el encriptar la información.

• El uso más apropiado de la data.

Propósito y beneficios de clasificar los activos

Un adecuado proceso de clasificación permite que los activos reciban un nivel apropiado
de protección, indicándonos la necesidad y las prioridades para la protección de la
seguridad, minimizando con ello los riesgos de alteración de información no autorizada.
Adicionalmente previene situaciones de divulgación no autorizada, tal como información
estratégica, sensible de la compañía o sus clientes; lo que podría por ejemplo, mantener
una ventaja competitiva o cumplir con los estándares de la industria.

Otra de las razones de mantener una adecuada clasificación posibilita una mayor
conciencia entre los empleados y clientes a través de la identificación de información
crítica, posibilitando un enfoque en los controles de integridad, una mayor sensibilidad a la
necesidad de proteger información valiosa, comprender el valor de la información y cumplir
los requisitos legales.

El proceso de clasificación de activos, no está ausente de dificultades y contratiempos. El

Error humano constituye un riesgo importante en la implementación de este proceso, por lo
que, un proceso consistente y el entendimiento por parte de los dueños de información de
los niveles de clasificación, constituyen factores críticos de éxito.

Una adecuada clasificación de activos depende de la capacidad y el conocimiento del

clasificador, así como un etiquetado claro de todos los artículos clasificados; un adecuado
nivel de conocimiento de las regulaciones, las expectativas del cliente y del negocio.

Finalmente, y no menos importante, se debe considerar los aspectos relativos a la

desclasificación y destrucción de los activos.

FACULTAD DE INGENIERÍA 22
Protegiendo los activos
Definición de una línea base
Al momento de implementar la protección de los activos, se deben definir los niveles
mínimos de seguridad y requisitos de protección, considerando los distintos niveles de
clasificación de los mismos.

Entre las definiciones que podemos establecer, según los distintos niveles de clasificación
podemos mencionar:

• Utilización de una configuración base de herramientas de seguridad.

• Lista blanca en ciertos dispositivos.

• Estándares de configuración de seguridad (S.O. base de datos, aplicaciones, etc.).

• Lista de protocolos prohibidos (SSL, Telnet, FTP, etc.).

• Lista de aplicaciones prohibidas.

• Niveles de cifrado de la información

• Algoritmos de cifrado permitidos/excluidos

• Entre otros

La definición de una línea base de protección para los activos asume una serie de
consideraciones que debemos tener a la vista, tales como:

• Revisar donde aplica la misma línea base.

• No es para todo, pueden existir situaciones particulares.

• ¿A qué nivel de seguridad debería apuntar?

• ¿Cómo determinaremos los controles a aplicar?

• Definir niveles mínimos de protección para proteger activos valiosos.

• Pueden ser configuraciones para arquitecturas y sistemas específicos.

FACULTAD DE INGENIERÍA 23
 Clasificación Acceso Cifrado Etiquetado Monitoreo

• MFA
• Cifrado
• Marca de • Integrado al
• Dueño del fuerte para
agua SIEM
activo almacenami
Alto electrónica monitoreo
aprueba las ento de
en tiempo
acciones datos y • Marca física real
acceso
• NDA

• MFA • Integrado al
SIEM,
• Dueño del • Cifrado
• Etiquetado monitoreo
Medio activo fuerte para
físico de
aprueba las acceso
Frecuencia
acciones media

• Password
fuerte
• Dueño del • No hay
Bajo • Sin cifrado • Ninguno
activo monitoreo
aprueba las
acciones

Fuente: Elaboración propia

Manejo de medios
El manejo de medios debe ser también un punto de atención importante en la gestión de
activos, debe mantenerse un control de los medios que contienen activos de información,
aplicándose controles físicos y lógicos a los medios que almacenan información
confidencial. En el caso de los medios sensibles, estos deben siempre mantenerse
resguardados de posibles compromisos físicos.

Los medios de almacenamiento deben tener una etiqueta física que identifique la
sensibilidad de la información contenida, indicando claramente si los medios están
encriptados. La etiqueta también puede contener información sobre un punto de contacto
y un período de retención.

Cuando los medios se encuentran o se descubren sin una etiqueta, se debe etiquetar con el
nivel más alto de sensibilidad hasta que el análisis revele lo contrario.

FACULTAD DE INGENIERÍA 24
Siempre que sea posible, los medios de respaldo deben estar encriptados y almacenados
en un contenedor de seguridad, debiendo solo el personal designado tener acceso a medios
sensibles.

Otro de los aspectos importantes que posibilitan un adecuado cumplimiento de las

definiciones relacionadas con esta materia, lo constituye la definición de políticas claras de
retención de la información y manejo adecuado de los medios sensibles. La efectiva
comunicación de las políticas y los procedimientos debe considerar el otorgar capacitación
a cada una de las personas responsables de la gestión de los medios sensibles.

La remanencia de datos es la representación física residual de los datos que se han borrado
de alguna manera, después de borrar los medios de almacenamiento, puede haber algunas
características físicas que permitan reconstruir los datos. Debido a esto, los medios que
ya no se necesiten o que estén defectuosos deben destruirse de manera adecuada en lugar
de simplemente eliminarse, considerando la remanencia de datos al momento de su
eliminación.

Por ejemplo, en una unidad de disco duro (HDD), los datos se escriben magnéticamente en
la unidad alterando el campo magnético de la bandeja del disco duro, por lo que una
adecuada destrucción o reutilización debe considerar contramedidas que aborden de
manera apropiada la remanencia de datos, de acuerdo con el nivel de sensibilidad de la
información contenida en el medio.

Tres contramedidas comúnmente aceptadas empleadas para abordar la remanencia de

datos en HDD son:

Clearing: eliminación de datos confidenciales de los dispositivos de almacenamiento

mediante herramientas que eviten reconstrucción utilizando las funciones normales del
sistema o las utilidades de recuperación de datos / archivos de software. Los datos aún
pueden ser recuperables, pero no sin técnicas especiales de laboratorio.

Purgado: eliminación de datos confidenciales de un sistema o dispositivo de

almacenamiento de manera que estos no puedan ser reconstruidos por ninguna técnica
conocida.

Destrucción: El medio de almacenamiento queda inutilizable para equipos convencionales,

la efectividad de destruir los medios varía, la utilización de técnicas apropiadas es el
método más seguro para prevenir la recuperación y se conoce como "destrucción
defendible".

FACULTAD DE INGENIERÍA 25
Tema 6. Corrección y gestión de vulnerabilidades

Proceso de Patch Management

Para cada una de las fases del proceso de patch management, disponemos de una serie de
recursos que apoyan de manera adecuada cada una de las actividades consideradas.

Tal es el caso de los ejercicios de análisis de vulnerabilidades o ethical hacking que nos
permiten identificar las vulnerabilidades presentes en nuestro entorno, así como las
revisiones de compliance y auditorías para verificar que la instalación de los parches y
upgrades se realiza en tiempo y forma, de acuerdo con las definiciones de la organización
y las regulaciones vigentes.

Fuente: Elaboración propia

FACULTAD DE INGENIERÍA 26
La importancia de parchar

"Una onza de prevención equivale a una libra de cura".

Benjamín Franklin

El manejo de la vulnerabilidad es la "onza de prevención" en comparación con la "libra de

cura“, desde una perspectiva de seguridad, los parches mitigan las vulnerabilidades de
fallas de software y reducen las oportunidades de su explotación por parte de los
cibercriminales. Sin duda, el parchado constituye la forma y a veces la única solución
totalmente más efectiva de mitigar las vulnerabilidades de fallas de software.

A veces hay alternativas a los parches, como soluciones temporales que involucran
software o reconfiguración de control de seguridad, pero estas soluciones a menudo
afectan negativamente la funcionalidad.

Necesariamente, la decisión sobre cómo y cuándo mitigar mediante parches u otros

métodos de remediación debe considerar la comparación de tiempo, recursos y dinero a
gastar.

Costo para no mitigar = Ws * T * R,

Donde (Ws) es el número de estaciones de trabajo, (T) es el tiempo empleado para

recuperar una estación y (R) es el costo por hora del tiempo dedicado.

FACULTAD DE INGENIERÍA 27
Desafíos al momento de parchar
Tiempo, priorización y pruebas:
Estos son problemas que están estrechamente ligados. Idealmente deberíamos desplegar
cada nuevo parche en el menor tiempo posible, sin embargo, los recursos son limitados y
debe priorizarse su aplicación. Adicionalmente, los impactos de la aplicación de los parches
pueden afectar servicios críticos de la organización, por lo que deben probarse. En la
mayoría de los casos, el tiempo, la priorización y las pruebas provocan tensiones en
sentidos opuestos.

Algunos proveedores tienen como práctica realizar liberaciones de parches con una
frecuencia definida y agrupar en dicho período todos los parches. Sin embargo, pueden
existir liberaciones fuera de ciclo dependiendo de la urgencia y gravedad de la
vulnerabilidad. El problema con esto es que el período de tiempo entre la liberación y su
descubrimiento alarga el período de exposición.

Otro de los problemas se relaciona con el hecho que a veces no basta con instalar el parche,
muchas veces es necesario realizar un reboot del sistema o de algunos procesos críticos.

La decisión de parchar puede depender de la importancia relativa de los sistemas

vulnerables (por ejemplo, servidores versus clientes) y la gravedad relativa de cada
vulnerabilidad (por ejemplo, métricas de gravedad de la vulnerabilidad como el Sistema de
puntuación de vulnerabilidad común [CVSS]).

Otra consideración son las dependencias que los parches pueden tener entre sí; instalar un
parche puede requerir la instalación de otros parches primero, y en algunos casos requiere
reiniciar una aplicación o reiniciar un host varias veces para que los parches surtan efecto
secuencialmente.

FACULTAD DE INGENIERÍA 28
Configuración del parchado:
Otro de los desafíos son los múltiples mecanismos para la aplicación de los parches:

• Un software puede actualizarse automáticamente por sí mismo.

• Puede existir una herramienta centralizada que inicie el proceso automáticamente.

• Aplicaciones de terceros.

• Soluciones de NAC pueden iniciar automáticamente el proceso.

• Los usuarios pueden iniciar manualmente o configurar actualizaciones

automáticas.

Estas múltiples vías para ejecutar los parchados puede ocasionar conflictos entre
aplicaciones, ya que muchas de estas están ligadas entre sí respecto a su funcionamiento.

Arquitecturas diferentes:
Cuando se emplean arquitecturas de host no homogéneas, la administración de parches
puede ser considerablemente más difícil.

Los ejemplos de estas arquitecturas incluyen lo siguiente:

• Hosts no administrados

• Hosts fuera de la oficina

• Componentes no estándar (appliances)

• Dispositivos móviles

• Firmware

• Sistemas virtualizados

FACULTAD DE INGENIERÍA 29
Otros desafíos:
• Sobrecarga de recursos

• Manejo de inventario de software

• Efectos secundarios

• Verificación de la implementación

• Existencia de soluciones de whitelist

Participantes del proceso

Como punto inicial en la implementación de un proceso efectivo, debemos considerar la
creación una función encargada del proceso, así como la incorporación de representantes
de seguridad de la información, ciberseguridad y operaciones.

Estos representantes deben incluir personas con conocimiento de la vulnerabilidad y la

gestión de parches, así como la administración del sistema, la detección de intrusos y la
gestión de firewall.

Además, es útil contar con especialistas en los sistemas operativos y aplicaciones más
utilizadas dentro de la organización. El personal que ya proporciona funciones de
administración del sistema o la red, realiza escaneos de vulnerabilidades u opera sistemas
de detección de intrusos son buenos candidatos para incorporarse al proceso.

Actividades contempladas en el proceso

• Mantener un inventario: S.O, aplicaciones, infraestructura, etc.

• Mantener un proceso constante de monitoreo de vulnerabilidades, remediaciones y

amenazas.

• Definir niveles de priorización (basado en riesgo, tipo y característica de la amenaza,

sensibilidad del activo, etc.).

• Definir instancias de prueba de parches.

• Estrategia de despliegue de las distintas remediaciones.

FACULTAD DE INGENIERÍA 30
 • Definir flujos de comunicación de las vulnerabilidades, amenazas y remediaciones.

• Definir procesos automáticos de instalación de parches.

• Configuración de procesos automáticos de actualización de aplicaciones cuando

sea posible.

• Definir un proceso formal y constante de verificación de remediaciones.

• Entrenamiento y capacitación constante del personal involucrado.

Consideraciones y recomendaciones
Finalmente, presentamos una lista de consideraciones y recomendaciones a tener presente
al momento de implementar un proceso de corrección y gestión de vulnerabilidades.

• Es altamente recomendable definir un responsable/función dedicada al parchado y

la gestión de vulnerabilidades.

• La gestión de parches debe ser un proceso propio de TI más que una función de
seguridad.

• Si bien debe ser un proceso propio de TI, es sumamente importante que sea
considerado en el contexto de la seguridad.

• Debe ser un proceso de amplio alcance. (IoT, servidores, networking, workstations,

smartphones, etc.).

• La infraestructura utilizada para apoyar el proceso también debe ser incluida.

• Debe contemplar instancias de análisis y evaluación de riesgo de los hallazgos, así

como del impacto de la aplicación de las remediaciones.

• Se debe considerar un balance entre las necesidades de seguridad y las

necesidades de usabilidad.

• Definición de políticas, normas y procedimiento.

• Monitorear continuamente en busca de vulnerabilidades, remediaciones y

amenazas.

FACULTAD DE INGENIERÍA 31
• Priorice la aplicación de parches y use implementaciones por fases según
corresponda.

• En lo posible, probar los parches antes de la implementación.

• En lo posible, implementar soluciones automatizadas de parches en toda la

empresa.

• Asegurar un inventario completo, oportuno y fidedigno de todos los activos de

tecnología de la información.

• Usar configuraciones estandarizadas para recursos de TI tanto como sea posible.

• Verificar que se hayan corregido las vulnerabilidades.

• Medir constantemente la eficacia de la gestión de parches y vulnerabilidades de la

organización y aplicar acciones correctivas según sea necesario.

• Capacitar al personal aplicable en técnicas de monitoreo y corrección de

vulnerabilidades.

FACULTAD DE INGENIERÍA 32
Tema 7: Conclusiones
• En el desarrollo de esta clase, hemos podido revisar los aspectos relacionados con
el entorno en la nube, así como los procesos más relevantes a tener en
consideración en cualquier organización.

• Sin duda alguna, la sola implementación de estos procesos, así como los entornos
y servicios tecnológicos actuales, representan un desafío al momento de estructurar
una estrategia para abordar la ciberseguridad de toda organización. Desafíos que
necesariamente deben contemplar el entorno en el cual se desenvuelve la
organización, así como los objetivos estratégicos, la cultura organizacional, el nivel
de madurez en materias de gobierno de TI y ciberseguridad y la legislación vigente.

FACULTAD DE INGENIERÍA 33
Bibliografía
• Chalmers, D. (1997). The Conscious Mind: In Search of a Fundamental Theory.
Oxford: Oxford University Press.

• Chapple, M., Stewart, J. M., & Gibson, D. (2018). (ISC)2 CISSP Certified Information
Systems Security Professional Official Study Guide. Sybex.

• Forum of Incident Response and Security Teams FIRST (s.f.). Common Vulnerability
Scoring System Specification Document.

• NIST. (1998). Information Technology Security Training Requirements: a Role- and

Performance-Based Model SP 800-16.

• NIST. (2003). Building an Information Technology Security Awareness and Training

Program SP 800-50 (2003, Octubre).

• NIST. (2012). Computer Security Incident Handling Guide SP 800-61r2.

• Peter, M. & Grance, T. (2009). The NIST Definition of Cloud Computing.

FACULTAD DE INGENIERÍA 34