
Empecemos por el principio. El primer aspecto de la fase de preparación consiste en identificar y asignar roles y responsabilidades. Esto dependerá de diversos factores, como la gravedad del incidente, las particularidades del entorno y las herramientas disponibles.
Una vez que se identifican las personas adecuadas, la siguiente pregunta es "¿Qué hacen?" O más específicamente, "Una vez que el equipo sabe y está capacitado sobre qué hacer, ¿cómo saben cuándo hacerlo?" La respuesta a esta pregunta variará según la nivel de madurez de seguridad de su organización.
Puede comenzar a responder esta pregunta identificando cuáles de los cientos, o incluso miles, de eventos de seguridad diarios deben clasificarse como incidentes y merecen mayor atención. La mayoría de las organizaciones no han abordado esta cuestión explícitamente y abordan su seguimiento de forma ad hoc, según los recursos y la experiencia disponibles. Si bien este enfoque es viable por un tiempo, no proporciona información consistente para la revisión y mejora, y probablemente resulte en una respuesta general de menor calidad. Es mejor abordar los detalles mediante la creación de un proceso formal para identificar incidentes de forma proactiva.
¿Qué se considera un incidente?
Según el Instituto Nacional de Estándares y Tecnología (NIST), Un evento de seguridad es cualquier suceso observable en una red o sistema de información. Por lo tanto, cuanto más se observe la red y más sensible sea la instrumentación, más eventos se observarán o detectarán. Estos pueden variar en gravedad, desde pings del firewall hasta intentos de phishing y exfiltración de datos. Dependiendo de la experiencia y de la presencia o ausencia de controles compensatorios, muchos de estos eventos probablemente se puedan ignorar con seguridad. Por otro lado, el NIST define un ciberincidente como un suceso disruptivo y un evento que también infringe las políticas de seguridad, los procedimientos de seguridad o las políticas de uso aceptable.“
El enfoque del NIST refleja un enfoque de gestión programática. El incidente en cuestión representa una violación de las normas, ya sea por parte de un agente interno o externo, y la respuesta depende de la norma infringida. Sin embargo, desde la perspectiva de un analista de seguridad, un evento o posible incidente representa la observación de un comportamiento anormal en la red. Antes de clasificar un incidente, es necesario partir de una línea base de mediciones de actividad para determinar qué constituye una actividad normal. Desde el punto de vista de la preparación, es necesario contar con políticas y procedimientos que especifiquen la actividad "normal" en la red.
Otra forma de identificar eventos e incidentes es hacer algunas preguntas clave sobre el evento:
- ¿El evento indica una infracción de la ley o de la normativa aplicable, como PCI/DSS, HIPAA, FERPA, etc.? ¿Existen normativas que exijan la notificación pública como resultado del evento?
- ¿El evento indica una violación de la política corporativa? ¿Y cuál es la consecuencia especificada en la política?
- ¿El evento refleja una violación de los valores y/o la ética corporativa? (Si responde afirmativamente a las preguntas 3 pero no a la 2, considere si debería existir una política al respecto).
La preparación para la respuesta a incidentes es un desafío, pero al formalizar el proceso sobre cómo identificar un incidente, estará mucho mejor preparado. preparado para la respuesta:contener, erradicar y remediar el incidente.
*Adaptado de uno existente Sincronicidad entrada de blog.

