Ejemplo 4 - Caso Propuesto a Auditar

IMPLEMENTACIÓN DE UN SISTEMA DE
GESTIÓN DE SEGURIDAD DE INFORMACIÓN
(SGSI) BASADO EN LA NORMATIVA ISO/IEC
27001.
BANCO EN LA NUBE OPORTUNIDADES A PARTIR DE LA
COMUNICACIÓN A6354 DEL BCRA, UTILIDAD DE LA FAMILIA DE
NORMAS ISO/IEC 27000 EN LA TERCERIZACIÓN DE SERVICIOS DE TI Y
CUMPLIMIENTO REGULATORIO
Índice
Unidad 3. Reformulación del caso Caso.
Banco en a la nube……………………………………………………………………………………… 3
Unidad 3. Actividades individuales relacionadas.
Metodología de Riesgos .……………………………………………………………………………….5
Planificación para la implantación .……...………………...…………………………………………. 6
Identificación y análisis de riesgos ……………………………………………….………….......…….
6
Unidad 4. Actividades individuales relacionadas.
Declaración de aplicabilidad …………………………….………………………………….…….…….
7
Política de Seguridad de la Información ………………………………….…………….…..….…..…
7
Controles …………………………………………………………………………….………………..….
9
.
Unidad 5. Actividades individuales relacionadas.
Métricas ………………………..……………...……………………………………………...……….....
9
Plan de auditoría ……………………..………………………………..……..………….…..………...
10
Unidad 6. Actividades individuales relacionadas.
Acciones correctivas y de mejora ..…………………………………………………………………...
11
Estrategia de continuidad………...…………………………………………………………………... 12
2
UNIDAD 3. Presentación del Caso
Introducción
El caso que se presenta se vincula con la decisión del Banco Central de la República Argentina
(BCRA) del 3 de noviembre de 2017, en la que se actualizó la normativa bancaria, permitiendo
a estas entidades usar servicios tercerizados y desde la nube. Hasta ahora, las entidades
financieras podían almacenar datos y realizar procesos sólo en datacenters propios o de sus
entidades matrices.
Esto otorga a los bancos la posibilidad de lograr agilidad y capacidad de respuesta e
innovación, hasta ahora muy "pegados" al hardware y a los procesos clásicos de desarrollo y
los pone en una posición para competir con las “fintech” nacidas de la mano de las nuevas
tecnologías.
Teniendo la posibilidad de usar soluciones de nube se abren numerosas oportunidades,
algunas de las cuales se relacionan con la gestión centralizada de recursos distribuidos sobre
múltiples nubes (comunicaciones, almacenamiento, procesamiento de datos provistos desde
varias nubes) y también con los servicios de valor agregado que se puede montar sobre estos
servicios de nube.
Objetivo
Cumplir las regulaciones técnicas correspondientes a la naturaleza y tipo de actividades de la
institucióndescentralizando y/o tercerizando actividades de servicios de Tecnología Informática,
las mismas sujetas a auditorías de la autoridad regulatoria.
Descripción del caso
Institución
Corresponde a un caso genérico para la industria bancaria (banco extranjero de primera línea),
entidad regulada por el BCRA. El trabajo se focalizará en desarrollar el alineamiento de la
institución con la nueva resolución "A" 6354 que habilitó a las entidades financieras a tercerizar
los servicios de almacenamiento y de procesamiento de datos en la nube desde la perspectiva
de la norma ISO / IEC 27001:2013.
Dicha descentralización puede ser en instalaciones propias, de la casa matriz o controlante,
con recursos técnicos y humanos propios o de terceros. También puede tercerizar en
instalaciones de terceros con recursos técnicos y humanos propios o de terceros.
Las actividades descentralizadas y/o tercerizadas estarán sujetas a las regulaciones técnicas
correspondientes a la naturaleza y tipo de actividades.
A partir de la tercerización de servicios a la nube se proponen las siguientes mejoras en la
institución:
1. Reducir costos en infraestructura y servicios de tecnología.
2. Aumentar la velocidad de procesamiento y capacidad de storage e
integración.
3. Tener acceso a distintas fuentes de información y servicios de análisis en
múltiples nubes a fin de desarrollar inteligencia de negocios (para conocer
mejor a los clientes, saber qué quieren y qué necesitan y direccionar mejor
las promociones).
4. Reducir drásticamente los tiempos de desarrollo permitiendo tener un “time
to market” que beneficie especialmente la experiencia del usuario.
3
Alcance
Se entiende la Gestión de Seguridad de los STI tercerizados como el ciclo de procesos que
reúnen distintas tareas, especialidades y funciones, de manera integrada e interrelacionada,
repetible y constante para la administración, planificación, control y mejora continua de la
seguridad informática en los STI tercerizados. El alcance del caso cubrirá el proceso de
Control de Accesos.
Proceso
El Control de Accesos refiere a la problemática del control de acceso a los sistemas de
información. Cubre los dominios de autenticidad y confidencialidad sirviendo de control base
para asegurar una buena trazabilidad. Incluye la evaluación, desarrollo e implementación de
medidas de seguridad para la protección de la identidad, mecanismos de autenticación,
segregación de roles y funciones y demás características del acceso a los STI. Incluye los
subprocesos de Gestión de Asignación de Perfiles de Acceso, Gestión de Solicitudes de
Acceso y Gestión de Controles de Acceso.
Propuesta de equipo de trabajo
Sponsor: Director de Sistemas y Tecnología
Líder: Gerente de Seguridad Informática
Integrantes del equipo:
o Analista de Seguridad Informática
o Analista de Procesos y Cumplimiento de TI
o Consultor especializado en certificación ISO IEC 27001
Otros interesados:
o Gerente de Gestión de Servicios de Tecnología de Información.
o Gerente de Administración y Control de Tecnología de la Información
o Gerente de Desarrollo de Personas.
4
UNIDAD 3. Actividades individuales relacionadas

Bloque temático 2. Análisis de riesgo. 2. En caso de haber realizado el Curso de
Fundamentos e Introducción a SGSI, proponga aquí que Metodología de Riesgos utilizaría
en el Caso Práctico que planteo como Evaluación Integradora Final. Justifique y explique.
Metodología de riesgos

Inventario y clasificación de activos
 Identificación de los activos involucrados en los procesos del alcance
o Clasificación de los activos (hardware, software, comunicaciones y documentación
en ppio)
 Valoración de activos
o Importancia en función de la confidencialidad, integridad y disponibilidad

Identificación de amenazas
o Tipos de amenazas
o Probabilidad de ocurrencia
o Impacto o efecto
Identificación de riesgos
o Tipos de riesgos
o Determinación del riesgo
Análisis de riesgos: matriz de análisis de riesgo


Explicación:
El proceso de Gestión de Riesgos de Activos Tecnológicos, define dos instancias de
análisis: una cíclica, de acuerdo a la estrategia de gestión de riesgos de TI, y otra “ad hoc”
en caso de incorporar un nuevo activo de alta criticidad según la clasificación de activos.
El Gerente de Gestión de Servicios de Tecnología de Información:

Define los límites para el análisis de riesgos tomando como base la estrategia de
riesgos de TI y el conjunto de procesos críticos de la organización.

Realiza una evaluación primaria de los riesgos ya sea por la severidad o por el daño
que puede causar al negocio la aceptación del riesgo.

Identifica los cambios en los activos provenientes de:

o
El estado del tratamiento de vulnerabilidades cuya mitigación o eliminación
se definió en ciclos de riesgos anteriores,
o
La gestión de cambios de ítems de configuración,
o
Nuevos activos no incluidos en ciclos de gestión de riesgos anteriores,
Define quéactivos deben estar dentro del alcance de la gestión de riesgos de TI y los
revisa y modifica para su incorporación.
Definición de Controles
El Analista de riesgos de TI releva con las áreas involucradas, por tipo de activo, los
controles a implementar, las amenazas relacionadas, la severidad y probabilidad de
ocurrencia de los mismos, teniendo en cuenta:

Buenas prácticas,

Metodologías,

Manuales de fabricantes y normativas reconocidas internacionalmente,

Resultados de auditorías internas y externas,
5

Por cada incidente de Tecnología severo acontecido durante el período definido en el
alcance, examina las causas de los mismos e identifica controles a evaluar sobre los
activos.

Por cada incidente de Seguridad acontecido durante el período definido en el
alcance, examina las causas de los mismos e identifica la existencia de controles a
evaluar sobre los activos.

Además, considera los reportes de incidentes, reportes relacionados a PRD (plan de
recuperación ante desastres), así como otros informes o reportes internos relevantes.
Identificación de Riesgos

El Analista de riesgos de TI identifica y distribuye a los especialistas técnicos de cada
áreacuestionarios del análisis de riesgos.

Los especialistas técnicos realizan el análisis de riesgo evaluando el nivel de
cumplimiento de cada uno de los controles definidos para los activos a través de los
cuestionarios de la herramienta.

El Analista de riesgos de TI monitorea y controla el estado de respuesta de los
cuestionarios enviados e implementa las acciones necesarias para que los mismos
sean completados.
Evaluación de riesgos

El Analista de riesgos de TI realiza un estudio del riesgo, obteniendo para cada
activo los índices PSR (nivel de riesgo basado en la probabilidad, severidad y
probabilidad) de cada control y el Índice de Riesgo porcentual del activo y otras
estadísticas necesarias para la evaluación de riesgos.

Clasifica los riesgos en aquellos que podrían ser aceptados o tratados de acuerdo a
los límites establecidos.
Análisis de riesgos
(ver Análisis de riesgos.xlsx)
Análisis de
riesgo.xlsx
Plan de tratamiento de riesgos
(ver Plan de acción.xlsx)
Plan de acción.xlsx

Bloque temático 3. Planificación. Todos en este momento del Curso deberían estar
trabajando con un Caso Práctico, proponga una Planificación plausible para dicha
Implantación a su criterio.
(ver Plan de Acción.xlsx)
Plan de
ac t ividades.xlsx
6
UNIDAD 4. Actividades individuales relacionadas

Bloque temático 1. En base a lo estudiado hasta esta Unidad, realice una propuesta de
Alcance y Declaración de Aplicabilidad de Objetivos de Control que aplica en su
caso. Realice un resumen de su propuesta y compártala en el apartado de Caso Propuesta
Caso Práctico por Grupos.
(ver Declaración de Aplicabilidad.xlsx)
Declaración de
aplicabilidad.xlsx

Bloque temático 2.
1. Revise del siguiente documento en el caso del capítulo 6 a 9.
https://www.incibe.es/extfrontinteco/img/File/intecocert/sgsi/img/Guia_apoyo_SGSI.pdf
En caso de haber realizado el Curso de Fundamentos e Introducción a SGSI, revise del
Caso Práctico que planteo como Evaluación Integradora Final los siguientes puntos:
alcance, Política de seguridad, identificación y análisis de riesgos, selección de Controles y
Declaración de Aplicabilidad. Justifique y explique.
Controles: ver punto Unidad 5, bloque 2.
En lo que se refiere al contenido, la Política de Seguridad:




Deberá existir una Política de Control de Accesos que siga el principio del mínimo
privilegio, un usuario sólo debe tener acceso a aquella información estrictamente
necesaria para desempeñar sus funciones diarias, siempre que nos refiramos a
información confidencial. Control de acceso e identidad. Control de acceso a los
recursos, actualizaciones de seguridad y parches, gran parte de estos accesos no
autorizados se podrían evitar si los sistemas y aplicaciones estuvieran
convenientemente actualizados.
Se deberán gestionar los derechos de acceso asignados a usuarios: establecer un
sistema de clasificación de la información, para ligarlo a roles y niveles de acceso.
Deberá existir la gestión de contraseñas de usuarios.
Control de acceso a las redes y servicios asociados: algunos incidentes de seguridad
como la fuga información, son causados por el uso inadecuado de servicios en la nube
y son parecidos a los causados por uso de redes sociales y la forma de tratarlos es
muy similar.
Esquema de la Política:
Capítulo Uno.
 Definición de la seguridad de la información
 Objetivos de la política
 Alcance de la seguridad de la información en la organización
 Importancia como mecanismo de control que permite compartir la información.
Capítulo Dos.
 Declaración de la Dirección apoyando los objetivos y principios de la seguridad de la
información.
Capítulo Tres.
 Breve explicación de las políticas
Capítulo Cuatro.
 Definición de responsabilidades generales y específicas, incluyendo los roles dentro de
la organización.
7
Capítulo Cinco.
 Referencias a documentación que pueda sustentar la política:
o Procedimientos operativos de seguridad (POS): describen las actividades y
tareas de los procesos relacionados, roles y funciones que las ejecutan sin
entrar en detalles técnicos.
o Instrucciones técnicas (IT): desarrollan los POS llegando al máximo nivel
dedetalle, indicando comandos técnicosempleados para la realización de las
tareas.
o Guías de seguridad: tienen un carácter informativo y buscan ayudar a
losusuarios a aplicar correctamente las medidas de seguridad
proporcionandorazonamientos en los casos en los que no existan
procedimientos precisos.Ayudan a prevenir que se pasen por alto aspectos
importantes de seguridadque pueden materializarse de varias formas.
8
UNIDAD 5. Actividades individuales relacionadas

Bloque temático 2. Proponga alguna métrica plausible de utilizarse en el Caso Práctico a su
criterio. Justifique y explique. Compártalo en el Foro proactivo.
Controles
Métricas
A.9.1 Requisitos comerciales del control de acceso
Objetivo: limitar el acceso a las instalaciones de procesamiento de información e
información.
A.9.1.2 Acceso a las redes y servicios de red
Control: los usuarios solo recibirán acceso a la Porcentaje de sistemas y aplicaciones
red y a la red servicios que han sido corporativas
para
los
que
los
específicamente autorizados para usar.
"propietarios" adecuados han: (a) sido
identificados, (b) aceptado formalmente
sus responsabilidades, (c) llevado a cabo o encargado- revisiones de accesos y
seguridad de aplicaciones, basadas en
riesgo y (d) definido las reglas de control
de acceso basadas en roles.
A.9.2 Gestión de acceso de usuario
Objetivo: garantizar el acceso autorizado de los usuarios y evitar el acceso no autorizado a
sistemas y servicios.
A.9.2.1 Registro de usuario y des-inscripción
Control: un registro formal de usuarios y un Porcentaje de descripciones de puesto
proceso de cancelación de registro serán de
trabajo
que
incluyen
implementado para permitir la asignación de responsabilidades en seguridad de la
derechos de acceso.
información (a) totalmente documentadas
y (b) formalmente aceptadas.
A.9.2.2 Aprovisionamiento de acceso de usuario
Control: se implementará un proceso formal de Tiempo medio transcurrido entre la
provisión de acceso de usuario para asignar o solicitud y la realización de peticiones de
revocar derechos de acceso para todos los cambio de accesos
tipos de usuario a todos los sistemas y
servicios.
A.9.2.3 Gestión de derechos de privilegio de acceso
Control: la asignación y el uso de los derechos Porcentaje de sistemas y aplicaciones
de acceso privilegiado sea restringido y corporativas
para
los
que
los
controlado.
"propietarios" adecuados han: (a) sido
identificados, (b) aceptado formalmente
sus responsabilidades, (c) llevado a cabo o encargado- revisiones de accesos y
seguridad de aplicaciones, basadas en
riesgo y (d) definido las reglas de control
de acceso basadas en roles.
A.9.2.6 Remoción o ajuste de los derechos de acceso
Control: los derechos de acceso de todos los Porcentaje
de
identificadores
de
empleados y usuarios externos a las usuario pertenecientes a personas que
instalaciones de procesamiento de información han dejado la organización, separados por
e información se eliminarán al término de su las categorías de activos (pendientes de
empleo, contrato o acuerdo, o ajustado al desactivación) e inactivos (pendientes de
cambio.
archivo y borrado).
A.9.4 Sistema y control de acceso a la aplicación
Objetivo: evitar el acceso no autorizado a sistemas y aplicaciones.
A.9.4.1 Acceso a la información restricción
Control: el acceso a la información y las Estadísticas de cortafuegos, tales como
funciones del sistema de aplicación se porcentaje de paquetes o sesiones
restringido de acuerdo con la política de control salientes que han sido bloqueadas (p. ej.,
de acceso.
intentos de acceso a páginas web
9
A.9.4.4 Uso de la utilidad privilegiada
programas
Control: el uso de programas de utilidad que
podrían ser capaces de anular los controles del
sistema y de la aplicación deben ser
restringidos y estrictamente revisado.
A.9.4.5 Control de acceso al programa código
fuente
Control: el acceso al código fuente del
programa debe estar restringido.

prohibidas;
número
de
ataques
potenciales
de
hacking
repelidos,
clasificados
en
insignificantes/preocupantes/críticos).
Estadísticas de vulnerabilidad de
sistemas y redes, como nº de
vulnerabilidades
conocidas
cerradas,
abiertas y nuevas; velocidad media de
parcheo
de
vulnerabilidades
(analizadas por prioridades/categorías del
fabricante o propias).
Bloque temático 3.
2. Proponga un Plan de Auditoría que aplique en el caso práctico. Justifique. Comparta su
propuesta en el Foro proactivo.
(ver Plan de Auditoría.xlsx)
Plan de
audit oría.xlsx
10
UNIDAD 6. Actividades individuales relacionadas

Bloque temático 1. En base a lo estudiado hasta aquí proponga Acciones Correctivas y
Mejoras Continuas que a su criterio apliquen en el Caso Práctico. Compártalo en el Foro
proactivo.
2. Revise el Capítulo 11 del Documento proponga una estrategia de Continuidad de
Negocio para el Caso Justifique su posición en el Foro proactivo: Compártalo en el Foro
proactivo. Incorpore sus propuestas de las Unidades anteriores al Caso Práctico
presentado.
Origen
Auditoría de
certificación
Auditoría de
certificación
Auditoría de
certificación
Auditoría de
certificación
Auditoría
documental
Hallazgo
En referencia al punto
A.9.3.1 sobre uso de
autenticación secreta
información, no existe un
plan de capacitación y
concientización de los
usuarios en el uso de
contraseñas seguras.
En referencia al punto
A.9.4.2 sobre
procedimientos de logeo
seguro, el acceso a
sistemas y las
aplicaciones no se
controla mediante un
procedimiento de inicio de
sesión seguro.
En referencia al punto
A.9.4.3 Sistema de
gestión de passwords, los
sistemas de gestión de
contraseñas no son
interactivos ni aseguran
contraseñas de calidad.
En referencia al punto
A.9.2.6 sobre remoción o
ajuste de los derechos de
acceso, no existe un
control de usuarios
pertenecientes a
personas que han dejado
la organización,
separados por las
categorías de activos
(pendientes de
desactivación) e inactivos
(pendientes de archivo y
borrado).
En referencia al punto
A.9.2.3 sobre gestión de
derechos de privilegio de
acceso, ni está
documentado el
procedimiento para la
asignación de accesos a
los sistemas y aplicativos.
Acción de mejora
Establecer planes de
capacitación y
concientización al
personal en el uso de
información de
autenticación secreta.
Responsable
Director de
Desarrollo de
Personas
Plazo
6 meses
Tipo
Mejora
Establecer un
procedimiento de
acceso seguro según
política de control de
acceso.
Gerente de
Seguridad
Informática
12
meses
Mejora
Establecer un sistema
de gestión de
contraseñas
interactivo con el
usuario que valide
calidad de la misma al
momento del ingreso
Establecer el
indicador: porcentaje
de identificadores de
usuario
pertenecientes a
personas que han
dejado la
organización,
separados por las
categorías de activos
(pendientes de
desactivación) e
inactivos (pendientes
de archivo y borrado).
Gerente de
Seguridad
Informática
12
meses
Mejora
Gerente de
Seguridad
Informática
3 meses
Correctiva
Gerente de
Seguridad
Informática
3 meses
Correctiva
Establecer un
procedimiento para la
asignación de
accesos a los
sistemas y aplicativos.
11

Bloque temático 3
2. Por último revise esta Guia. Considérela para la aplicación de la Continuidad de Negocio
en el Caso Práctico. Justifique.Comparta su propuesta en el Foro proactivo. Suba todo lo
propuesto a la Carpeta de Entrega del Caso Práctico a Revisar.
Estrategia de Continuidad
Se deberá establecer un Plan de Continuidad fijando los siguientes objetivos:

Mantener el negocio de la organización, priorizando las operaciones de negocio
críticas necesarias para continuar en funcionamiento después de un incidente no
planificado.

Reducir el número y la magnitud de las decisiones que se toman durante un
período en que los errores pueden resultar mayores.
Establecer, organizar y documentar los riesgos, responsabilidades, políticas y
procedimientos, acuerdos con entidades internas y externas.
La activación de un Plan de Continuidad deberá producirse solamente en
situaciones de emergencia y cuando las medidas de seguridad hayan fallado.


Hitos a considerar:

Análisis de Impacto: realizar un inventario de los procesos críticos de la compañía,
estableciendo los tiempos de recuperación de los mismos, antes de incurrir en pérdidas
graves.

Componentes de los procesos describir cada uno de los componentes hardware,
software, comunicaciones, etc., que conforman los procesos definidos.

Establecer tiempos máximos de recuperación de los procesos

Análisis de riesgos

Listado de amenazas

Vulnerabilidades tomando como base los objetivos de seguridad de la ISO 17799 y en
función de las Amenazas posibles, establecer los escenarios en que una amenaza
puede convertirse en un incidente de seguridad. (ESCENARIOS, NIVEL DE
PROTECCIÓN y RESPUESTA)

Evaluación de riesgos

Definir recomendaciones y contramedidas

Definir un plan de recuperación:
o
Definir Comité de Crisis
o

Definir equipo de recuperación

Definir equipo de coordinación logística

Definir equipo de relaciones públicas

Definir equipo de las unidades de negocio
Establecer fases de la alerta:

Fase de Alerta

Definir procedimiento de notificación del desastre

Definir procedimiento de ejecución del plan

Definir procedimiento de comunicaciones durante la ejecución del plan
12



Fase de transición

Definir procedimiento de concentración y traslado de recursos
humanos y materiales.

Definir procedimiento de puesta en marcha del centro de recuperación
Fase de recuperación

Definir procedimiento de restauración

Definir procedimiento de soporte y gestión durante la recuperación
Fase de vuelta a la normalidad

Realizar un análisis de impacto del desastre

Planificar adquisiciones de recursos a recuperar

Dar por finalizada la contingencia
13