Este documento tiene como finalidad la gestión de incidentes de seguridad de la información, con el objetivo de crear directrices y procedimientos claros para garantizar que los incidentes de seguridad de la información sean registrados, notificados y tratados de forma adecuada.
También busca, a partir de la mejora continua y del uso del historial de incidentes, crear medidas de prevención y protección contra la repetición de incidentes, así como alimentar el análisis de riesgos y la revisión de los demás controles y procesos de seguridad.
Esta planificación se basa en todas las actividades, controles y procesos del Sistema de Gestión de Seguridad de la Información (SGSI).
Este documento es público, y su acceso está destinado a los colaboradores de 2CLIX TECNOLOGIA EIRELI y a sus clientes.
RESPONSABILIDADES
Todo colaborador tiene la responsabilidad de notificar un evento de seguridad al equipo de Seguridad o al responsable del área afectada.
Un evento de seguridad se considera cualquier acontecimiento que afecte la disponibilidad, integridad o confidencialidad de la organización y de la información de la misma y de sus clientes. De este modo, se contemplan eventos ocurridos tanto en las dependencias de la organización como en sus activos físicos, así como en sus activos digitales y aplicaciones.
El equipo de Seguridad debe registrar todos los reportes comunicados a través de los medios de comunicación corporativos. Estos registros deben realizarse siguiendo el modelo de Registro de Incidencias ubicado en una carpeta específica dentro de los archivos de Seguridad de la Información.
Una vez registrada la ocurrencia, el equipo de Seguridad también debe tratarla, recopilando evidencias en las herramientas de auditoría y monitoreo, así como gestionar la comunicación de los incidentes a las áreas y personas afectadas. El equipo de Seguridad debe también iniciar los protocolos internos de normalización del sistema.
El equipo de Administración debe responsabilizarse por el contacto con clientes, proveedores y autoridades; deben contar con los informes y evidencias provistos por el equipo de Seguridad, y deben iniciar los protocolos de normalización del sistema que requieran contactos externos.
Es responsabilidad del equipo de Seguridad y de Administración elaborar un plan de control y resolución, así como poner a disposición boletines con información sobre plazos y condiciones del sistema durante la resolución del incidente.
Cada incidente debe ser tratado con seriedad y, dependiendo de su gravedad, el equipo de Administración puede convocar una reunión extraordinaria con el equipo de Seguridad y representantes de los equipos de soporte, desarrollo y proyectos para definir el mejor camino de resolución.
NOTIFICACIÓN
Las notificaciones de eventos o incidentes pueden originarse de diversas formas, dependiendo de cómo fue detectado el evento.
SIEM
Los eventos de seguridad detectados por el SIEM y por el equipo que monitorea los logs recolectados por este sistema deben comunicarse directamente al Administrador del Sistema o al Gerente de Seguridad, junto con información y evidencias relacionadas al evento de seguridad.
Indisponibilidades de los Ambientes WEB
Los eventos relacionados con la disponibilidad de los ambientes web, servidores y bases de datos son detectados por la aplicación de monitoreo. Esta aplicación identifica indisponibilidades y su nivel de impacto, y crea automáticamente un registro que envía por correo electrónico a los usuarios definidos (Gerente de Seguridad y Administrador del Sistema) una alerta indicando el lugar de la indisponibilidad, su gravedad y el tiempo transcurrido.
En esta aplicación también pueden realizarse reportes personalizados, permitiendo que, incluso si los escáneres o automatizaciones no detectan una indisponibilidad parcial, los colaboradores puedan generar un reporte.
Tickets de Usuarios/Clientes
Tickets relacionados con comportamientos sospechosos del sistema reportados por clientes, así como sospechas u ocurrencias de seguridad en sus ambientes, que llegan al equipo de Soporte, deben ser encaminados al equipo de Seguridad con todas las evidencias recopiladas del cliente.
Eventos Internos
Si durante el uso de las estaciones de trabajo, el cumplimiento de funciones o el uso de los ambientes físicos de la organización se identifica un evento sospechoso, el equipo de Seguridad y el Administrador del Sistema deben ser notificados por el colaborador a través de los canales de comunicación oficiales. Esta notificación debe ser seguida por la recolección de evidencias y registros por parte del equipo de Seguridad.
Eventos Críticos
Cuando un evento de seguridad es de alta criticidad, cuyo impacto debe ser mitigado con urgencia, la notificación debe realizarse directamente al Administrador del Sistema o a las Autoridades, dependiendo de la situación, iniciando inmediatamente los protocolos de normalización y mitigación, junto con el proceso de registro. El equipo de Seguridad debe actuar junto con el Administrador del Sistema para asegurar las evidencias, notificar a los afectados y normalizar el sistema lo más rápido posible.
VULNERABILIDAD
Toda vulnerabilidad encontrada debe ser notificada, incluso cuando sea apenas una sospecha o un falso positivo de un escáner.
Colaboradores o Proveedores
Cuando la vulnerabilidad o sospecha es identificada por un colaborador o proveedor, el equipo de Seguridad debe ser notificado a través de los canales oficiales. Esta notificación debe registrarse y dar inicio a una investigación para verificar la existencia y el potencial impacto de la vulnerabilidad, preparando un comunicado con un resumen de las mejoras que su corrección aportará a la seguridad.
Clientes y Usuarios
Vulnerabilidades o sospechas identificadas por clientes deben comunicarse a través de los canales de soporte (help center, correo electrónico o teléfono). El equipo de Soporte debe recopilar todas las informaciones y evidencias y enviarlas condensadas en un único correo al equipo de Seguridad. También deben orientar al usuario a no intentar explotar la vulnerabilidad y agradecer el reporte.
El equipo de Seguridad debe investigar la vulnerabilidad y generar un comunicado oficial sobre el riesgo y las medidas de control y corrección aplicadas. Este comunicado debe ser enviado al cliente que realizó la notificación.
EVALUACIÓN DE EVENTOS
Los eventos deben ser evaluados según su gravedad e impacto. Eventos de criticidad baja a media deben ser evaluados por el equipo de Seguridad, que debe recopilar todas las evidencias y registrarlas en los directorios destinados al almacenamiento seguro. Una vez identificadas las causas e impactos, el equipo debe iniciar las acciones de normalización y corrección.
Eventos de criticidad alta o muy alta deben ser evaluados por el equipo de Seguridad en conjunto con el Administrador del Sistema y, dependiendo del caso, un representante de Soporte y Desarrollo. En estos casos, la recopilación de evidencias ocurre paralelamente a las acciones de normalización.
Si el evento es considerado un Incidente de Seguridad, la recolección de evidencias debe comenzar con las fuentes que lo identificaron y avanzar hacia las trilas de auditoría, contacto con el Data Center, análisis de registros de servicios, revisión de códigos, y eventualmente análisis forense por especialistas externos.
Todas las evidencias deben almacenarse tanto en los repositorios digitales como en el servidor de backup para garantizar redundancia.
Si el evento no es considerado un incidente de seguridad, debe generarse un informe explicando las causas, los impactos y las evidencias que justifican esta clasificación.
RESPUESTA A INCIDENTES
Una vez identificado y confirmado un incidente de seguridad, el equipo de Seguridad junto con el Administrador del Sistema deben encontrar la causa y el alcance del impacto.
Una vez identificada la causa, debe generarse un diagnóstico con las acciones necesarias para la normalización y, si es posible, la corrección del problema. Este diagnóstico se envía a los colaboradores y proveedores necesarios para ejecutar las acciones correctivas.
Mientras el proceso de normalización está en curso, todos los afectados deben ser notificados sobre la situación, el plazo estimado y las acciones previstas.
RECOLECCIÓN DE EVIDENCIAS
Las evidencias incluyen toda información que compruebe la ocurrencia del evento, sus causas o impactos. La recolección comienza con el material inicial proporcionado en la notificación (capturas de pantalla, e-mails de alerta, alertas de antivirus, firewall, fotografías, etc.). A partir de esto, el equipo de Seguridad debe consultar logs, SIEM, base de datos, IDS, Azure y demás sistemas.
Si el incidente ocurre en un activo físico, éste debe ser retirado de la red y enviado a análisis forense.
Una vez reunidas, las evidencias son analizadas para identificar la causa y definir el mejor curso de acción.
MEJORA CONTINUA
Al finalizar el tratamiento del incidente, cuando el sistema esté normalizado, el equipo de Seguridad debe registrar un informe final con retroalimentación, controles aplicados y mejoras sugeridas.
Las mejoras pueden ser enviadas para evaluación del equipo de Administración siguiendo el proceso de Cambios.
Pueden ser programadas capacitaciones para reforzar procesos o realizar reciclaje con los colaboradores.
GESTIÓN DE DOCUMENTOS
Este documento es válido a partir de su aprobación más reciente y es responsabilidad del equipo de Administración de 2CLIX TECNOLOGIA EIRELI.
El ciclo de actualización es anual y debe realizarse a partir de la evaluación de su eficacia y adecuación respecto a las demás políticas de la empresa.
Para garantizar una evaluación clara y concisa, se utilizarán los siguientes criterios:
- Retorno de las partes interesadas sobre la eficacia e impacto del SGSI;
- Evolución del número de incidentes de seguridad reincidentes;
- Tiempo de respuesta a los incidentes;
- Evolución de incidentes causados por uso indebido de equipos personales;
- Retroalimentación proveniente de capacitaciones;
- Evolución de incidentes graves causados por falta de notificación;
- Feedback de clientes y colaboradores después del tratamiento de incidentes;
- Casos derivados de definiciones confusas o insuficientes en los procedimientos de gestión de incidentes.
