información concreta
MANTENIMIENTO DEL MANUAL
Tecnología Coordinador Tecnología
Fuente: Población de la Gobernación de Santo Domingo 2018
Elaborado por: Castro Byron
Cada uno de los responsables de área indicados anteriormente, conocen sus funciones y responsabilidades en cuanto al mantenimiento y cuidado del manual de procedimientos, esto gracias a las capacitaciones realizadas.
La capacitación se realizará directamente al personal de la institución, por medio de una presentación audiovisual, que permitirá una fácil comprensión de la implementación del manual de procedimientos en la institución.
Actividades
Identificación, análisis y evaluación del incidente Identificación del incidente
Para identificar un incidente, determinar su alcance y los sistemas afectados por el mismo, se pueden obtener indicios de múltiples maneras en función de la naturaleza y tipo de incidente. Uno de los principales mecanismos es el análisis de logs, registros y fuentes de información para detectar anomalías. Sin ánimo de exhaustividad, fuentes de información a considerar en este punto son:
Consolas de antivirus.
Sistemas de Detección / Prevención de Intrusión (IDS/IPS). Alertas de sistemas de correlación de eventos de seguridad.
112
Registros de auditoría para detectar intentos de acceso no autorizados. Registro de conexiones bloqueadas en los cortafuegos.
Registro de conexiones realizadas a través de proxys corporativos.
Bloqueo de cuentas de usuario u otras anomalías reportadas en masa o que impliquen algún riesgo como pérdidas de USB o equipos portátiles.
Consumos excesivos y repentinos de memoria o disco en servidores. Anomalías de tráfico como picos de consumo a horas no habituales.
Volcados de red, mediante port mirroring, por ejemplo, que permitan confirmar alguna sospecha de incidente.
La detección de este tipo de anomalías permite identificar un posible incidente de seguridad, así como la naturaleza o el alcance del mismo. En el caso de que alguno de estos registros presentase alguna anomalía, sería necesario su análisis detallado para determinar si realmente existe un incidente.
Este análisis se puede realizar, por ejemplo, mediante la detección de tráfico de red malicioso, identificando la infraestructura afectada, las direcciones de origen y destino, valores de puertos utilizados, protocolos, entre otros.
Estas acciones ayudarán a determinar si realmente hay un incidente
algunos ejemplos para conocer si está siendo afectado por un incidente son: Cuentas de usuario inusuales en el sistema o especialmente privilegiadas.
Ficheros ocultos o con tamaños, nombres o ubicaciones sospechosas, pudiendo indicar los mismos algún tipo de fuga de información o registro por parte de algún malware.
Ficheros con permisos inusuales, en rutas no habituales, ficheros huérfanos y que pudieran determinar algún tipo de intrusión o rootkit.
Entradas sospechosas en el registro, principalmente en el caso de infecciones por malware en sistemas Windows, donde ésta es una de las principales técnicas que el malware utiliza para asegurar su persistencia en el sistema infectado.
113
Procesos y servicios inusuales, no sólo servicios a la escucha, si no con conexiones establecidas a puertos o host extraños, poco habituales o incluidos en algún tipo de lista negra de servidores de Comando y Control (C&C) utilizados por las botnets.
Cargas excesivas de disco o memoria pueden estar producidas por un incidente de seguridad como malware, denegaciones de servicio o intrusiones.
En el caso de equipos de usuario o terminales móviles, pueden indicar algún tipo de infección en el sistema, entre otros: comportamiento anómalo de alguna aplicación, ventanas emergentes del navegador, conexiones muy lentas, reinicios o aplicaciones que se cierran sin motivo.
Tareas programadas o actividad sospechosa en los registros de auditoría y logs que indique un funcionamiento anormal del sistema o intentos de intrusión en algún servicio mediante por ejemplo fuerza bruta.
Reporte del antivirus corporativo o de alguna herramienta habitualmente instalada en el sistema de identificación de rootkits, de control de integridad de ficheros, firma de los binarios, etc. No es recomendable instalar ad hoc estas herramientas en un sistema sospechoso ya que pueden alterar las fechas de acceso de los sistemas y suponer una pérdida de evidencias.
Aunque en la organización se contemplen todas estas medidas para identificar un incidente y el equipo o equipos afectados, no es descartable que la identificación del incidente se produzca a través de una fuente de información externa, un reporte de otro organismo, de un usuario externo a la institución, entre otros.
En la entidad debe existir un listado de fuentes generadoras de eventos que permitan la identificación de un incidente. (Ver anexo Formato de gestión de incidencia general) Análisis
Las actividades de análisis del incidente involucran otra serie de componentes, es recomendable tener en cuenta los siguientes:
Tener conocimientos de las características normales a nivel de red y de los sistemas.
114
Los administradores de TI deben tener conocimiento total sobre los comportamientos de la infraestructura que están Administrando.
Toda información que permita realizar análisis al incidente debe estar centralizada (Logs de servidores, redes, aplicaciones).
Es importante efectuar correlación de eventos, ya que por medio de este proceso se pueden descubrir patrones de comportamiento anormal y poder identificar de manera más fácil la causa del incidente.
Para un correcto análisis de un incidente debe existir una única fuente de tiempo (Sincronización de relojes) ya que esto facilita la correlación de eventos y el análisis de información.
Se debe mantener y usar una base de conocimiento con información relacionada sobre nuevas vulnerabilidades, información de los servicios habilitados, y experiencias con incidentes anteriores.
Crear matrices de diagnóstico e información para los administradores menos experimentados.
Evaluación
Para realizar la evaluación de un incidente de seguridad se debe tener en cuenta los niveles de impacto con base en los insumos entregados por el análisis de riesgos y la clasificación de activos de información de la entidad. La severidad del incidente puede ser:
Alto Impacto: El incidente de seguridad afecta a activos de información considerados de impacto catastrófico y mayor que influyen directamente a los objetivos de la institución. Se incluyen en esta categoría aquellos incidentes que afecten la reputación y el buen nombre o involucren aspectos legales. Estos incidentes deben tener respuesta inmediata.
Medio Impacto: El incidente de seguridad afecta a activos de información considerados de impacto moderado que influyen directamente a los objetivos de un proceso determinado.
Bajo Impacto: El incidente de seguridad afecta a activos de información considerados de impacto menor e insignificante, que no influyen en ningún objetivo. Estos incidentes deben ser monitoreados con el fin de evitar un cambio en el impacto.
115 Registro de incidentes
Proceso - Registro de incidentes
Usuario o identificador de incidente
Reconoce que existe un incidente o que ha ocurrido un evento.
Informa incidentes en las distintas áreas poniéndose en contacto con el centro de soporte de tecnología iniciando un registro de incidentes en su propio nombre. Registra toda la información pertinente sobre el incidente y qué acciones se han
tomado.
Recibe notificaciones de resoluciones propuestas o implementadas.
Una vez identificado como un incidente, la mesa de servicio registra el incidente, se debe incluir información, como el nombre del usuario y la información de contacto, la descripción del incidente y la fecha y hora del informe del incidente. El proceso de registro también puede incluir categorización, priorización y los pasos que completa la mesa de servicio. (Ver Anexo Formato registro de incidencias)
No Conformidades de este proceso
Se consideran como no conformidades de este proceso la pérdida de un formato cumplimentado, la falta de registro de cualquier incidencia, el incumplimiento no justificado de los plazos acordados para solventar la incidencia. Estas no conformidades se gestionan tal y como se detalla en este procedimiento, es decir, abriendo la incidencia correspondiente.
Centro de soporte
Recibe llamadas de asistencia del centro de soporte del cliente.
Inicia registros de incidentes, según sea necesario, y garantiza la asignación del incidente al área de responsabilidad correspondiente.
Inicia llamadas a la persona de guardia si el incidente requiere atención inmediata.
Propietario del incidente
Acepta o transfiere la propiedad mediante reasignación a otra área de responsabilidad para su resolución.
116
Al aceptar la propiedad del incidente, establece comunicación con el Centro de soporte, según sea necesario.
Confirma la asignación actualizando la información del asignado en el Registro de incidentes.
Realiza la determinación de incidentes, el desvío de incidentes, la recuperación y la restauración del servicio.
Realiza una evaluación de incidentes y desarrolla los planes necesarios para corregir el incidente.
Garantiza la coordinación de las pruebas y la aceptación del usuario de la resolución.
Evalúa y cambia el nivel de gravedad del registro de incidentes, según corresponda.
Supervisa el progreso y los informes para ayudar a los empleados y a la administración en plazos predefinidos.
Cierra el registro de incidentes dentro de los dos días hábiles posteriores a la resolución del incidente. Si no se llega a un acuerdo sobre la resolución, el incidente permanece abierto y se coloca en estado pendiente o suspendido. Garantiza la precisión y la integridad del registro de incidentes. El departamento
del llamante, la descripción, la fecha y hora de resolución, el código de causa y los componentes deben ser correctos y consistentes para los criterios de búsqueda futuros.
Notifica el identificador de incidente con el estado de resolución, el número de incidente y el área operacional responsable para cualquier seguimiento necesario, o envía registro incidente al Centro de soporte para su cierre y contacto con el cliente.
Categorización y soporte de incidentes
La información sobre una interrupción del servicio se recopila y registra para fines de seguimiento de incidentes, control de cambios y referencia histórica. La entrada inicial se crea en los formatos dados por el identificador de incidente o por el propietario del
117
incidente, a menos que esta persona sea un usuario de la institución que no tenga acceso a los archivos y registros. En esta situación, el centro de soporte creará la entrada inicial para el usuario.
La entrada identificará:
departamento de llamadas qué área encontró el incidente sistema donde ocurrió el evento
componente que causa la interrupción del servicio fecha y hora de la interrupción
descripción del incidente
La persona que crea la entrada inicial, asigna el registro de incidentes al grupo administrativo responsable del componente anómalo. El grupo de servicio asignado se convierte en el propietario del incidente y recibe la notificación para realizarse su respectiva acción.
Algunos ejemplos de clasificación de incidentes podrían ser, (esta clasificación está sujeta a cada entidad dependiendo de su infraestructura, de sus riesgos y criticidad de los activos. (Ver Anexo Categorización y prioridades para la atención de
incidentes)
La clasificación dada es solo un ejemplo):
Acceso no autorizado: Es un incidente que involucra a una persona, sistema o código malicioso que obtiene acceso lógico o físico sin autorización adecuada del dueño a un sistema, aplicación, información o un activo de información.
Modificación de recursos no autorizado: Un incidente que involucra a una persona, sistema o código malicioso que afecta la integridad de la información o de un sistema de procesamiento.
Uso inapropiado de recursos: Un incidente que involucra a una persona que viola alguna política de uso de recursos.
118
No disponibilidad de los recursos: Un incidente que involucra a una persona, sistema o código malicioso que impide el uso autorizado de un activo de información.
Multicomponente: Un incidente que involucra más de una categoría anteriormente mencionada.
Otros: Un incidente que no puede clasificarse en alguna de las categorías anteriores. Este tipo de incidentes debe monitorearse con el fin de identificar la necesidad de crear nuevas categorías.
Tabla 19 Categorización de Incidentes
Categoría Nivel 1 Nivel 2 Nivel 3 (*) Accesos x Consultas x Hardware X Software X Comunicaciones X Equipos X Aplicaciones X
(*): Cualquiera de nivel 1 o nivel 2 que requiera la participación de especialistas
Elaborado por: Castro B.
Priorización de incidentes
Es importante para el cumplimiento la prioridad del incidente, está determinada por su impacto en los usuarios y en el negocio y su urgencia. La urgencia es qué tan rápida se requiere una resolución; El impacto es la medida de la magnitud del daño potencial que puede causar el incidente. (Ver Anexo Acuerdo de nivel de operaciones para la atención de incidentes)
Los incidentes de baja prioridad son aquellos que no interrumpen a los usuarios o al negocio y se pueden solucionar. Se pueden mantener los servicios a usuarios y clientes.
Los incidentes de prioridad media afectan a algunos miembros del personal e interrumpen el trabajo hasta cierto punto. Los clientes pueden verse ligeramente afectados o incomodados.
119
Los incidentes de alta prioridad afectan a una gran cantidad de usuarios o clientes, interrumpen el negocio y afectan la prestación del servicio. Estos incidentes casi siempre tienen un impacto financiero.
Con el fin de permitir una atención adecuada a los incidentes (análisis, contención y erradicación) se debe determinar el nivel de prioridad del mismo, y de esta manera atenderlos adecuadamente según la necesidad. A manera de ejemplo se definen una serie de variables que podrán ser utilizadas para realzar la evaluación de los incidentes
Prioridad
Criticidad de impacto Impacto Actual Impacto Futuro
Nivel de Prioridad: Depende del valor o importancia dentro de la entidad y del proceso que soporta el o los sistemas afectados.
Tabla 20 Niveles de Criticidad de Impacto
Nivel Cri- ticidad
Valor Definición
Bajo 0,25 – 4 Sistemas que apoyan a una sola dependencia o proceso de una entidad.
Medio 0,50 – 3 Sistemas que apoyan más de una dependencias o proceso de la entidad.
Alto 0,75 – 2 Sistemas pertenecientes al área de Tecnología y estaciones de trabajo de usuarios con funciones críticas.
Critico 1,00 – 1 Sistemas Críticos.
Fuente: Seguridad y privacidad de la información
Elaborado por: Castro B.
Impacto Actual: Depende de la cantidad de daño que ha provocado el incidente en el momento de ser detectado.
Impacto Futuro: Depende de la cantidad de daño que pueda causar el incidente si no es contenido, ni erradicado.
120 Tabla 21 Niveles de impacto actual y futuro
Nivel Cri- ticidad
Valor Definición
Bajo 0,25 – 4 Impacto moderado en uno de los componentes de cualquier sistema de información o estación de trabajo.
Medio 0,50 – 3 Impacto alto en uno de los componentes de cualquier sis- tema de información o estación de trabajo.
Alto 0,75 – 2 Impacto moderado en uno o más componentes de más de un sistema de información.
Critico 1,00 – 1 Impacto alto en uno o más componentes de más de un sis- tema de información.
Fuente: Seguridad y privacidad de la información
Elaborado por: Castro B.
Luego de tener definidas las variables se obtiene la prioridad mediante la siguiente formula:
Nivel Prioridad = (Impacto actual * 2,5) + (Impacto futuro * 2,5) + (Criticidad del Sistema * 5)
Y los resultados obtenidos se deben compara con la siguiente tabla para determinar la prioridad de atención:
Tabla 22 Niveles de Prioridad del Incidente
Nivel Criticidad Valor
Bajo 02,50 - 03,74 – 4
Medio 03,75 – 05,00 – 3
Alto 05,25 - 07,99 – 2
Critico 08,00 – 10,00 – 1
Fuente: Seguridad y privacidad de la información
Elaborado por: Castro B.
Tiempos de respuesta
Para el caso de la atención de incidentes se ha establecido unos tiempos máximos de atención de los mismos, con el fin de atender adecuadamente los incidentes de acuerdo a su criticidad e impacto. Los tiempos expresados en la siguiente Tabla son un acercamiento al tiempo máximo en que el incidente debe ser atendido, y no al tiempo en el cual el
121
incidente debe ser solucionado. Esto se debe a que la solución de los incidentes puede variar dependiendo del caso.
Tabla 23 Tiempos Máximos de Atención de Incidentes
Impacto Tiempo de Respuesta Tiempo de Restauración
Bajo 70% de incidentes
dentro de un día hábil
95% de incidentes dentro de 5 días hábiles Medio 70% de incidentes dentro de 8 horas 95% de incidentes dentro de 3 días hábiles Alto 70% de incidentes dentro de 30 minutos 95% de incidentes dentro de 8 horas / 100% de incidentes dentro de 12 horas Critico 70 % de incidentes dentro de 15 minutos 95% de incidentes dentro de 4 horas / 100% de incidentes dentro de 6 horas
Fuente: Seguridad y privacidad de la información
Elaborado por: Castro B.
Cabe resaltar que cada entidad está en la libertad de definir tiempos de atención a incidentes como crean conveniente y dependiendo de la criticidad de los activos impactados. (VerAnexo Niveles de atención – Gestión de Incidencias)
Respuesta de incidentes y recuperación
Se desarrolla e implementa una solución permanente al incidente sujeta a la gestión y la aceptación del cliente. El propietario del incidente actualiza el registro de incidentes una vez que la solución permanente se implementa con éxito, se acepta y se reasigna al centro de soporte para su cierre. El cierre de un registro de incidentes debe realizarse dentro de los dos días posteriores a la resolución del incidente. Si no se llega a un acuerdo sobre la resolución, el incidente está completamente documentado y el registro del incidente se coloca en estado suspendido, pero permanece abierto. Las soluciones permanentes que requieren un cambio se documentan y programan a través del proceso de gestión del cambio
Diagnóstico inicial: esto ocurre cuando el usuario describe su problema y responde las preguntas de resolución de problemas.
122
Escalada de incidentes: ocurre cuando un incidente requiere soporte avanzado, como enviar un técnico en el sitio o asistencia del personal de soporte certificado. Como se mencionó anteriormente, la mayoría de los incidentes deben ser resueltos por el personal de soporte de primer nivel y no deben llegar al paso de escalamiento.
Investigación y diagnóstico: estos procesos se llevan a cabo durante la solución de problemas cuando se confirma que la hipótesis del incidente inicial es correcta. Una vez que se diagnostica el incidente, el personal puede aplicar una solución, como cambiar la configuración del software, aplicar un parche de software u ordenar hardware nuevo.
Resolución y recuperación: es cuando el servicio técnico confirma que el servicio del usuario se ha restaurado al nivel de OLA requerido.
Cierre del incidente: en este punto, el incidente se considera cerrado y el proceso del incidente finaliza.
Estados del incidente
Los estados de los incidentes reflejan el proceso del incidente e incluyen: Nuevo Asignado En progreso En espera o pendiente Resuelto Cerrado
El nuevo estado indica que la mesa de servicio ha recibido el incidente, pero no lo ha asignado a un agente.
El estado asignado significa que se ha asignado un incidente a un agente de servicio de escritorio individual.
El estado en curso indica que se ha asignado un incidente a un agente, pero no se ha resuelto. El agente está trabajando activamente con el usuario para diagnosticar y resolver el incidente.
123
El estado en espera indica que el incidente requiere alguna información o respuesta del usuario o de un tercero. El incidente se pone "en espera" para que no se excedan los plazos de respuesta del OLA mientras se espera una respuesta del usuario o proveedor.
El resuelto estado significa que la mesa de servicio ha confirmado que el incidente se ha resuelto y que el servicio del usuario se ha restaurado a los niveles de OLA.
El estado cerrado indica que el incidente se ha resuelto y que no se pueden tomar más medidas.
La información recopilada durante el seguimiento de incidentes se almacena en la base de conocimientos con fines históricos y de referencia. Esta información es una valiosa ayuda para analizar y resolver incidentes futuros y para identificar soluciones a largo plazo a incidentes recurrentes. Los informes están disponibles en el área de tecnología para admitir la gestión de incidentes.
Todo el personal: Cuando se les asigne una acción correctora han de ejecutarla dentro de los plazos establecidos, comunicando cualquier dificultad al responsable de su área o al responsable de la gestión de incidencia.
Tabla 24 Archivos y registros generados
Archivo/Registro Propietario Tiempo de retención
Archivo de Incidencias Tecnología > 3años
Listado de Incidencias Tecnología > 3años
Registro de Incidencias de usuarios
Tecnología > 3años
Elaborado por: Castro Byron
La gestión de incidentes sigue los incidentes a través de la mesa de servicio para rastrear las tendencias en las categorías de incidentes y el tiempo en cada estado. El componente