¡alarma! ¡alarma! ¡incidente!
La gestión de incidentes siempre es una tarea compleja, que depende del tipo de incidente que estamos tratando y del personal que se dispone en el momento de la aparición del incidente. Todos sabemos cómo se forman los grupos de gestión de incidentes, la teoría está muy bien, pero falla en un 90% de las veces.
Casi siempre el grupo se forma con la gente presente, no es lo mismo detectar el incidente un sábado a las 4 de la mañana con solo el equipo de guardia trabajando, que un martes a las 12 de la mañana cuando está todo el personal operativo. Y lo mejor de todo es esa persona que simplemente pasaba por allí, pero que por circunstancias de la vida tiene que participar también en la resolución del mismo.
Ahora que ya tenemos formado el grupo toca atacar el problema. Un incidente en los sistemas de control no se puede tratar igual que en la red corporativa. En la red corporativa lo que prima es que el problema no se extienda por toda la empresa, por lo que lo usual es aislar el problema, como se consigue esto; muy fácil, desconectamos los equipos infectados de la red. Pero en la red de control lo más importante por encima de todo es la disponibilidad. No podemos desconectar un equipo y quedarnos tan contentos, a lo mejor es el equipo que controla el reactor (vamos a suponer un incidente en una central nuclear) y tenemos un nuevo Chernóbil. Los equipos tienen que seguir operativos realizando su cometido durante el mayor tiempo posible, al menos hasta que dé tiempo a parar otros sistemas que dependan del afectado. Por eso aquí es muy importante el tiempo, para que los daños sean mínimos, y el trabajo de preparación ante incidentes, esto es, equipos de respaldo, copias de seguridad, etc.
El plan de contingencia debe empezar desde el momento de la instalación/implantación. Puede ser tedioso y no utilizarse nunca, pero es importante documentar y registrar la instalación de los equipos (configuración del sistema operativo, instalación software, importación de aplicaciones…), controlando el tiempo que se tarda en tenerlo operativo, de esta forma siempre sabremos el tiempo máximo necesario para recuperarnos de un desastre total (si disponemos del hardware). Algo que parece tan trivial como las copias de seguridad no siempre se hace o se tiene correctamente documentado. Es muy importante tener un control de las copias de seguridad y de los cambios que se producen de unas a otras. Puede que el problema se deba a un cambio por una actualización y con regresar a la versión anterior ya estaría solucionado el incidente.
Tener equipos de respaldo para equipos críticos puede verse como algo inútil y un gasto exagerado (los equipos de control son caros), teniendo en cuenta que “nuestra empresa nunca tiene problemas”, pero todos sabemos que los incidentes aparecen tarde o temprano, y es mejor estar bien cubiertos. Si seguimos con el ejemplo anterior en la central nuclear, un fallo en el programa por una actualización que lo hace incompatible con alguna función se soluciona poniendo el equipo de respaldo con la copia de seguridad sin las actualizaciones, teniendo un tiempo de indisponibilidad mínimo o incluso nulo. Posteriormente ya nos encargaremos de volver a recuperar el equipo afectado por el problema. Si tenemos esto y copias periódicas de los datos, no debe ser mayor problema una caída de los sistemas de control.
Lo que siempre falla después de todo el proceso de resolución de un incidente es la documentación. Como el incidente ya se ha resuelto, el personal que ha estado trabajando en su resolución se vuelve a sus tareas ordinarias y se olvida de redactar los informes sobre la forma de trabajo que se ha llevado a cabo y los pasos que se han seguido para solucionar el problema. En los incidentes se aprende y se solucionan antes si todo queda documentado y se puede revisar, y no dependiendo de la idea brillante de alguna cabeza privilegiada del grupo. Puede que una vez la idea funcione estupendamente, pero puede que la siguiente vez no surja ninguna y se tenga un problema grave de verdad.
Siempre hemos de recordar que un incidente en una red de control puede tener efectos graves sobre el medio ambiente, las personas o las infraestructuras, y por tanto han de tenerse muy en cuenta y ser conscientes de su criticidad.
Jairo Alonso
S21sec Labs
http://blog.s21sec.com/2010/01/alarma-alarma-incidente.html
