11
UBA Maestría en Seguridad Informática Pág. 3/11 RIESGOS Desarrollo de un caso práctico A continuación se desarrolla un ejemplo de gestión de riesgos, con el fin de conformar una muestra de guía práctica, en concordancia con el enfoque de la norma ISO/IEC 27005. Es importante recordar que dicha norma indica expresamente que no constituye un método, razón por la cual habrá que utilizar las técnicas desarrolladas por los métodos existentes. En este caso particular, se utiliza las matrices que figuran como ejemplos en los anexos de la mencionada norma. Se seguirán los pasos del sector señalado en la figura siguiente

Riesgo CasoPractico

Embed Size (px)

DESCRIPTION

Riesgo - Caso Practico

Citation preview

Page 1: Riesgo CasoPractico

UBA – Maestría en Seguridad Informática Pág. 3/11

RIESGOS

Desarrollo de un caso práctico

A continuación se desarrolla un ejemplo de gestión de riesgos, con el fin de conformar una muestra de guía práctica,

en concordancia con el enfoque de la norma ISO/IEC 27005.

Es importante recordar que dicha norma indica expresamente que no constituye un método, razón por la cual habrá

que utilizar las técnicas desarrolladas por los métodos existentes.

En este caso particular, se utiliza las matrices que figuran como ejemplos en los anexos de la mencionada norma.

Se seguirán los pasos del sector señalado en la figura siguiente

Page 2: Riesgo CasoPractico

1 E R . P A S O - E S T A B L E C E R E L C O N T E X T O

Criterios básicos necesarios para la gestión de riesgos de seguridad de la información

Criterio de evaluación de riesgos

Para evaluar el riesgo de seguridad de la información se tendrá en cuenta que los procesos de negocios estratégicos de

la organización son los correspondientes a las liquidaciones de los beneficios de la seguridad social, así como el cum-

plimiento de las leyes y regulaciones relacionadas con la seguridad social.

Es resorte de la Dirección Ejecutiva definir el criterio de evaluación para otros procesos y activos.

Criterio de impacto (grado de daño o costo)

MUY ALTO – Incumplimiento de fechas de pagos previsionales

ALTO – No se cargan las novedades del mes.

MEDIO – Brecha legal

BAJO - Daño a la reputación

MUY BAJO – Falta de disponibilidad del sitio Web

Criterio de aceptación del riesgo

Aceptación de riesgos Nivel Puntuación

Se aceptarán riesgos para incidentes que afecten al valor estratégico del

proceso de negocio de liquidaciones cuyo nivel sea

MEDIO

/BAJO

0-5

Mientras la Dirección Nacional de Protección de Datos Personales (DNPDP)

no aplique las sanciones previstas o los usuarios no comiencen a hacer

juicio se aceptará el riesgo de incumplimiento de la Ley de Habeas Data

cuyo nivel sea (¡)

MEDIO

/BAJO

0-5

Se aceptarán los riesgos relacionados con la falta de disponibilidad del sitio

de la organización en Internet cuyo valor sea

ALTO

/MEDIO

/BAJO

0-8

Nótese que la segunda fila tiene una alerta. Dado que el proceso de gestión de riesgo es cíclico, se tendrá en cuenta la

condición planteada en futuras revisiones, de manera de detectar el momento en que la DNPDP comience a aplicar

sanciones, en cuyo caso el nivel de riesgo aceptable debiera bajar.

Alcances y limitaciones

Se requiere realizar un estudio de la organización. Es decir definir el negocio, estrategia, misión y valor de la organiza-

ción y su estructura – Ej. Organismo gubernamental de seguridad social, atiende las prestaciones sociales de activos y

pasivos, responde a las políticas que fija el gobierno en ejercicio, etc. El área de Seguridad Informática no depende de

la Alta Dirección, lo cual induce a pensar que la organización no está preocupada seriamente por este tema.

Page 3: Riesgo CasoPractico

Se deberá tomar en cuenta todas las restricciones que afectan a la organización y que determinan su orientación

respecto de la seguridad de la información. Ej. La cooperación con otros organismos gubernamentales obliga a com-

partir datos sensibles, razón por la cual será necesario confeccionar adecuados convenios; o bien, limitaciones en el

presupuesto para la compra de software especializado de seguridad.

Se deberá tomar conocimiento de todas las leyes y regulaciones que alcanzan a la organización.

Se deberá tomar en cuenta todas las restricciones que afectan al alcance. Ej. Del ambiente (situación geográfi-

ca/clima, situación geopolítica/atentados), gestión de recursos humanos (requerimientos concernientes al entrena-

miento de operadores, definición de los puestos de administradores).

Organización para la gestión de riesgos

- Desarrollar el proceso de gestión de riesgos adecuado para la organización (política, normas, modelos a aplicar, espe-

cificaciones propias, etc.)

- Definir los roles y responsabilidades

- Detectar y desarrollar las interfaces de este proceso con otros procesos de la organización.

- Identificar los interesados o grupos de interés.

2 D O . P A S O - V A L O R A C I Ó N D E L R I E S G O

Análisis de riesgo

Identificación del riesgo

Identificación de los activos. Incluye todos los datos de cada activo (código, descripción, ubicación, dueño, etc.).

Es posible definir diferentes agrupaciones de activos. En este caso se distinguirá entre dos tipos de activos:

Los primarios

Procesos y actividades de negocio

En este tipo se incluirá aquellos procesos cuya pérdida o degradación harían imposible el logro de la misión de la

organización; los que contienen procesos secretos o involucra tecnología propietaria; los necesarios para cum-

plir con requerimientos contractuales, legales o regulatorios, así como cualquier proceso crítico.

En el ejemplo que se ha elegido, dado el criterio de evaluación de riesgo presentado, se deberá contemplar to-

dos los aspectos de seguridad de la carga de novedades a las liquidaciones, la ejecución de las liquidaciones y su

emisión a los bancos. Ello involucra la disponibilidad de la red, del mainframe y de los subprocesos de transfe-

rencia de información.

Información

En este tipo se incluirá generalmente la información crítica como, por ejemplo, aquélla que es vital para el cum-

plimiento de los objetivos del negocio (en nuestro caso la involucrada en los proceso de liquidación); aquélla

protegida por la ley, por ejemplo en nuestro país, los datos personales; la información estratégica o de alto cos-

to de gestión (recolección, almacenamiento, etc.)

En general, si existieran procesos o información que, según el criterio de evaluación de riesgos de la organiza-

ción califican como de riesgo nulo, no serán considerados en el estudio.

Los que dan soporte a los procesos primarios:

Page 4: Riesgo CasoPractico

Hardware

Consiste de todos los elementos físicos, como por ejemplo, los equipos de procesamiento de información, los fi-

jos y móviles, los periféricos, los de almacenamiento, etc.

Software

Consiste en todos los programas que contribuyen al procesamiento de información tales como, los sistemas

operativos, mantenimiento y administración de software, software de base, las aplicaciones de negocios, etc.

Red

Consiste en el equipamiento, los medios de comunicación y sus interfaces.

Personal

Consiste en los grupos de personas involucradas en el sistema de información, como por ejemplo, quienes to-

man decisiones (la dirección, los dueños de la información, etc.), los usuarios finales, desarrolladores y personal

de operación y mantenimiento.

Sitio de procesamiento

Consiste en todos los sitios involucrados en el procesamiento, como por ejemplo, los de las sucursales (equipos

de telecomunicaciones, servidores), el perímetro de la red, los sitios de servicios tercerizados, los accesorios

como unidades de power suply, aire acondicionado, sistema de prevención y detección de incendios, etc.

Estructura de la organización

Describe el marco organizacional que consiste en el personal que compone las estructuras así como los procesos

que controlan estas estructuras. Por ejemplo autoridades, los involucrados en proyectos específicos, proveedo-

res, contratados, etc.

Caso en desarrollo - Activos a proteger

Primarios

Proceso de carga de novedades

Proceso de liquidación previsional/otras

Proceso de emisión a bancos.

Proceso de inventario de hardware y software

Proceso de gestión de datos personales

Gestión y mantenimiento del sitio Web

De soporte

Disponibilidad del mainframe

Disponibilidad red interna

Seguridad del perímetro de la red

Sitio de procesamiento

Sitio de telecomunicaciones en cada una de las sucursales

Protección de red interna frente a externa

Page 5: Riesgo CasoPractico

Software y equipamiento de transferencia a bancos

Seguridad física de los bienes de inventario

Seguridad física y lógica de la base de datos personales (accesos, extracción no autorizada, etc.)

Seguridad de los servidores expuestos a Internet.

Seguridad de los sistemas operativos

Identificación de las amenazas. Las amenazas son potenciales daños a los activos. Pueden ser internas o externas, de

origen natural o humano, accidental o deliberado. Es necesario tipificarlas y definir la fuente.

Caso en desarrollo - Identificación amenazas

Tipo de amenaza Amenaza Origen (*)

Daño físico

Fuego A,D,E

Destrucción del equipamiento A,D,E

Polvo, temperatura A,D,E

Polución A,D,E

Naturales Fenómeno meteorológico E

Sismos E

Humanas

Errores, ataques físicos, fraude, abuso de derechos, accio-

nes no autorizadas/delictivas, acciones administrativas

penalizadas por el reglamento de personal (usuarios inter-

nos no capacitados, descontentos, negligentes, deshones-

tos).

A, D

Ataques (delincuentes informáticos). D

Técnicas Mal funcionamiento o falla de equipamiento/red A

(*) Accidental (A), Deliberada (D), Ambiental (E)

Identificación de los controles existentes. Evita la duplicación de controles y permite evaluar su efectividad (cuál es el

riesgo residual)

Caso en desarrollo – Identificación de controles

Contrato de mantenimiento del mainframe con demora de 8 hrs. en la respuesta al llamado frente a desperfecto.

Identificación de las vulnerabilidades. Enumerar las vulnerabilidades que pueden ser explotadas por una amenaza. En

lo posible, se utilizarán métodos para identificarlas. Por ejemplo, test de intrusión, escaneo automáticos de vulnerabi-

lidades, etc.

Caso en desarrollo - Identificación de vulnerabilidades

Page 6: Riesgo CasoPractico

Tipo de vulnerabilidad Vulnerabilidad Amenaza que puede explotarla

Hardware Insuficiencia/falta de mantenimien-

to

Mal funcionamiento o falla del

equipamiento

Sitio

Falta de control de acceso físico Acciones no autorizadas

Falta de espacio físico cerrado Ataques físicos, errores huma-

nos

Sofware

Firewall mal configurado Ataques de delincuentes in-

formáticos

Construcción de contraseñas débi-

les

Abuso de derechos

Falta de aplicación de parches en

los sistemas operativos de servido-

res

Ataques (delincuentes informá-

ticos)

Perímetro de la red

Dispositivos de grabación en los

equipos personales

Acciones no autoriza-

das/delictivas (usuarios inter-

nos)

Usuarios internos con permisos de

administración local en los equipos

personales

Acciones no autoriza-

das/delictivas (usuarios inter-

nos)

Personal

Procedimientos inadecuados de

reclutamiento de personal , falta de

concientización, pobre cultura

organizacional

Acciones administrativas penali-

zadas por el reglamento de

personal.

Red Migración de la red a una tecnolog-

ía inmadura

Mal funcionamiento o falla de

equipamiento/red

Identificación de consecuencias. Identifica el daño o impacto negativo que un escenario de incidente puede causar a

la organización. Un escenario de incidente es la descripción de una situación en la cual una amenaza puede explotar

una vulnerabilidad o conjunto de vulnerabilidades.

Caso en desarrollo – Identificación de consecuencias

Falta de disponibilidad del mainframe, donde el escenario de incidente es:

- Amenaza: Mal funcionamiento o falla de equipamiento/red

- Vulnerabilidad: Insuficiencia/falta de mantenimiento del mainframe

Estimación del riesgo

El criterio o metodología de estimación debe ser definido formalmente y está asociado a la valorización de las conse-

cuencias y a la probabilidad de ocurrencia. Puede ser utilizado en diferentes grados de detalle dependiendo de la criti-

cidad de los activos, los riesgos ya conocidos y los incidentes que históricamente han ocurrido. Puede ser cuantitativo

o cualitativo pero debe ser relevante para el activo valuado.

Page 7: Riesgo CasoPractico

En general, conviene realizar en primera instancia una estimación de alto nivel y de valoración cualitativa. De esta

manera se llegará a un consenso de manera más rápida y menos costosa.

Como el proceso de gestión de riesgos es iterativo y debe ser monitoreado, en sucesivas instancias es posible profun-

dizar la estimación.

Estimación del impacto o consecuencias

Sería posible usar alguna de las medidas siguientes:

- El costo de reemplazo del activo y/o la relevancia y cantidad de los procesos a los que da soporte, es decir, el gra-do de dependencia. También se puede medir cualitativamente.

- Las consecuencias para el negocio en caso de destrucción, no disponibilidad, modificación no autorizada y/o falta de integridad de la información. Puede ser obtenido a través de un análisis de impacto del negocio (BIA por sus si-glas en inglés). El impacto está asociado al grado de éxito del incidente (amenaza que explota una vulnerabilidad). En este caso es necesario definir cuáles son todas las posibles consecuencias, una base común que debe ser usada

por todos y para todos los casos, y definir la calidad de impacto en el negocio (por ej. bajo, medio o alto; o bien

muy bajo, bajo, medio, alto, muy alto).

El valor determinado por el impacto del negocio suele ser más significativo que el valor del activo, dependiendo de la

criticidad del mismo. Se considera que el impacto puede tener un efecto inmediato, por ejemplo operacional o a futu-

ro, por ejemplo en el negocio si tuviera consecuencias financieras o de mercado.

Caso en desarrollo - Estimación del Impacto o consecuencias

Usaremos la escala cualitativa y mediremos el impacto sobre el negocio.

Como matriz modelo usaremos la siguiente:

ESCENARIO Probabilidad

del escenario

de incidente

MUY BAJA (MUY

IMPROBABLE)

BAJA (IMPROBA-

BLE)

MEDIA

(POSIBLE)

ALTA (PROBA-

BLE)

MUY ALTA

(MUY PRO-

BABLE)

Impacto en

el negocio

MUY BAJA 0 1 2 3 4

BAJA 1 2 3 4 5

MEDIA 2 3 4 5 6

ALTA 3 4 5 6 7

MUY ALTA 4 5 6 7 8

Los valores numéricos representan el nivel de riesgo.

Page 8: Riesgo CasoPractico

Será necesario definir con anterioridad qué comprende el valor de cada elemento de la escala de impacto en el nego-

cio. A continuación se incluye un ejemplo.

Nivel de Impacto Definición

ALTO

La ocurrencia del incidente provoca:

- Una pérdida económica superior a $………, o

- La pérdida, divulgación o modificación no autorizada de

información de alta criticidad, o

- Un daño considerable a las actividades, o

- Un daño considerable a la imagen o reputación, o

- Perjuicios graves a seres humanos

MEDIO

La ocurrencia del incidente provoca:

- Una pérdida económica superior a $………, o

- La pérdida, divulgación o modificación no autorizada de información de criti-

cidad media, o

- Un daño a las actividades, o

- Un daño a la imagen o reputación, o

- Perjuicio a seres humanos

BAJO

La ocurrencia del incidente provoca:

- Una pérdida económica inferior a $………, o

- La pérdida, divulgación o modificación no autorizada de

información de criticidad baja, o

- Un daño no significativo a las actividades, o

- Un daño no significativo a la imagen o reputación

Es posible incorporar a esta escala niveles intermedios a los establecidos.

Page 9: Riesgo CasoPractico

Estimación de la probabilidad de ocurrencia

Para realizar esta actividad es necesario tener en cuentas estadísticas sobre situaciones anteriores; para las amenazas

deliberadas, la posible motivación y capacidad y para las amenazas accidentales, los factores geográficos y de ubica-

ción, etc.

Caso en desarrollo – Estimación de la probabilidad de ocurrencia

La probabilidad del escenario de incidente se obtiene de la siguiente matriz:

También será necesario definir previamente bajo qué condición se conceptúa tanto la probabilidad de ocurrencia co-

mo la facilidad de explotación, como alta, baja o media. A continuación daremos un ejemplo sobre la probabilidad de

ocurrencia de la amenaza.

Nivel de probabilidad Definición

ALTO

La fuente de amenaza posee alta motivación y suficiente capacidad, o el

incidente ha ocurrido frecuentemente en el pasado; y los controles para

prevenir que la vulnerabilidad sea explotada no son efectivos.

MEDIO

La fuente de amenaza posee motivación y capacidad, o el incidente ha ocu-

rrido en ciertas ocasiones en el pasado; pero los controles existentes serían

capaces de prevenir que la vulnerabilidad sea explotada.

BAJO

La fuente de amenaza carece de motivación o capacidad, o el incidente no

ocurrido en el pasado, o los controles se encuentran en condiciones de

prevenir, o al menos impedir significativamente, que la vulnerabilidad sea

explotada.

Es posible incorporar a esta escala niveles intermedios a los establecidos.

AMENAZA Probabilidad de ocurrencia

de la amenaza

BAJA (IMPROBA-

BLE)

MEDIA (PO-

SIBLE)

ALTA (PROBA-

BLE)

VULNERABILIDAD Facilidad de explotación

de la vulnerabilidad B

M

A

B

M

A

B

M

A

Probabilidad del escenario

de incidente

MB

B

M

B

M

A

M

A

MA

Page 10: Riesgo CasoPractico

Nivel de la estimación de riesgo

Se obtiene como combinación del escenario de incidente y sus consecuencias. Su finalidad es obtener un valor del

riesgo para que sea posible definir si será tratado, en función de su evaluación, y luego la priorización de tratamiento.

Caso en desarrollo – Nivel de estimación del riesgo

Estimación del riesgo: Falta de disponibilidad del mainframe

Escenario del incidente

Amenaza: Mal funcionamiento o falla de equipamiento/red

Vulnerabilidad: Insuficiencia/falta de mantenimiento del mainframe

Si la organización tiene un contrato de mantenimiento con el proveedor que estipula un tiempo de respuesta con una

demora de hasta 8 hrs., se daría una situación (en amarillo) en la que la facilidad de explotación es Media, siendo la

probabilidad de ocurrencia Baja (equipo con poco tiempo de uso), lo cual nos da un escenario con Baja probabilidad.

Control existente: Contrato de Mantenimiento.

Si la organización no tiene mantenimiento, se daría una situación (en naranja) en la que la facilidad de explotación es

Alta. Si además por obsolescencia del equipamiento la probabilidad de ocurrencia es Media, nos da un escenario con

Alta probabilidad. Control existente: Ninguno.

MAL FUNCIONAMIENTO O

FALLA DE EQUIPAMIENTO/RED

Probabilidad de ocurrencia

de la amenaza

BAJA (IMPROBA-

BLE)

MEDIA (PO-

SIBLE)

ALTA (PROBA-

BLE)

INSUFICIENCIA/FALTA DE

MANTENIMIENTO DEL MAIN-

FRAME

Facilidad de explotación

de la vulnerabilidad B

M

A

B

M

A

B

M

A

Probabilidad del escenario

de incidente

MB

B

M

B

M

A

M

A

MA

Page 11: Riesgo CasoPractico

El riesgo del escenario en análisis es R1: Falta de disponibilidad del mainframe - No se cargan las novedades del mes

/ Incumplimiento de fechas de pagos previsionales

R1 Probabilidad

del escenario

de incidente

MUY BAJA (MUY

IMPROBABLE)

BAJA (IMPROBA-

BLE)

MEDIA

(POSIBLE)

ALTA (PROBA-

BLE)

MUY ALTA

(MUY PROBA-

BLE)

Impacto

en el

negocio

MUY BAJO 0 1 2 3 4

BAJO 1 2 3 4 5

MEDIO 2 3 4 5 6

ALTO 3 4 5 6 7

MUY ALTO 4 5 6 7 8

Se colorea en amarillo el impacto ALTO en el caso de imposibilidad de carga de las novedades del mes y en naranja el

impacto MUY ALTO correspondiente al incumplimiento de fechas de pago previsionales.

Evaluación del riesgo

Evaluación del riesgo: R1- Falta de disponibilidad del mainframe - No se cargan las novedades del mes / Incumpli-

miento de fechas de pagos previsionales

Dado que el proceso estratégico del negocio es la ejecución de las liquidaciones y su criterio de aceptación de riesgos

estipula que sólo aceptará los niveles medio y bajo queda claro que es necesario tratar el riesgo ya que en el caso colo-

reado en naranja el nivel de riesgo dio Muy Alto.

3 E R . P A S O – T R A T A M I E N T O D E L R I E S G O

Riesgo R1 - Falta de disponibilidad del mainframe - No se cargan las novedades del mes / Incumplimiento de fechas

de pagos previsionales

En este caso, en virtud que el nivel de aceptación del riesgo es nivel medio, el riesgo de nivel alto debe ser evitado. Por

lo tanto, se deberá contratar el mantenimiento. Sin embargo habrá que analizar, en función de las condiciones del

equipo, si es efectivo tener un contrato con 8 hrs. de demora.

Mediante un procedimiento como el que acabamos de utilizar, se llegará a la evaluación de todos los riesgos a fin de

tabularlos indicando los controles a aplicar para obtener el riesgo residual.