Resolver Problemas Consiga ayuda para problemas específicos con sus proyectos, procesos y tecnologías.

¿Cuándo es recomendable apagar un sistema en el proceso de respuesta a incidentes?

Este consejo examina algunos de los escenarios más comunes en los que una amenaza pueda requerir el cierre de un sistema y cómo prepararse para tal escenario.

Más que nunca, las empresas –y la sociedad en su conjunto– dependen de las computadoras y los sistemas que las conectan entre sí. Al mismo tiempo, los atacantes que se enfocan en la información valiosa de las empresas, o en ocasiones por razones políticas, nunca han sido más sofisticados, lo que ha aumentado la presión para que los equipos de seguridad de la empresa mantengan en funcionamiento los sistemas críticos, de manera segura y sin interrupciones.

De vez en cuando, independientemente de lo bien preparada que esté una organización desde una perspectiva de seguridad, un ataque dejará al equipo de seguridad debatiendo sobre los riesgos que implica mantener un sistema en funcionamiento y si éstos superan el impacto potencial de apagar un sistema infectado o que está siendo víctima de ataques. ¿Cómo debe tomar esa decisión un equipo de seguridad? ¿Qué factores deben sopesarse?

En este consejo, vamos a examinar algunos de los escenarios más comunes en los que una amenaza pueda requerir el cierre de un sistema y cómo prepararse para tal escenario.

Escenarios de cierre del sistema

Apagar un sistema en respuesta a un incidente de seguridad de la información es sin duda la opción más drástica que se puede tomar, pero podría ser la mejor opción en ciertos escenarios. Para determinar si apagar el sistema es apropiado, las organizaciones deben considerar las consecuencias de hacer frente a un incidente contra apagar el sistema.

Situaciones obvias que podrían justificar el cierre de un sistema (o partes de un sistema) pueden incluir una amenaza a la vida de alguien, o que las consecuencias del incidente llevaran a la organización, o a uno de sus clientes, a la quiebra. Por ejemplo, si existe la posibilidad de que un atacante tuviera el control de un sistema informático que regula los semáforos, probablemente sea mejor deshabilitar este sistema, y ​​por lo tanto los semáforos, porque con suerte los conductores sabrán que las señales de tráfico que no funcionan deben ser tratadas como un indicador de alto. Las consecuencias de permitir al atacante controlar el semáforo, por otro lado, podrían ser nefastas.

Estas son situaciones extremas en donde las decisiones son más fáciles de tomar; sin embargo, los  escenarios que podrían enfrentar las empresas con más probabilidad no serán tan drásticos.

Por ejemplo, un sistema puede estar infectado con un gusano que ataca a otros sistemas locales, y sacar a ese sistema de la red o apagarlo impediría que el gusano se propague a otros sistemas. Los gusanos pueden propagarse muy rápidamente de un sistema a otro, así que la decisión de apagar un sistema debe tomarse rápidamente. Tal decisión también dependerá de la seguridad y la disponibilidad de los controles implementados, incluyendo la existencia de controles que limiten un posible impacto que se extienda a todo el sistema en comparación con sólo una cuenta comprometida.

En un sistema que no contiene datos confidenciales y sólo tiene requisitos de disponibilidad, el equipo de seguridad sólo podría hacer un cálculo básico de los gastos efectuados a partir del tiempo de inactividad en comparación con el costo de recuperación para contener y remediar el sistema comprometido y, a continuación, tomar una decisión con base en los números. También habrá situaciones en las que no sea necesario apagar por completo el sistema. Por ejemplo, cerrar una conexión de red externa para evitar que un atacante tenga acceso adicional mientras se investiga un sistema de alto valor, frecuentemente es un enfoque menos drástico y puede ser preferible.

Por supuesto, también hay escenarios en los que apagar un sistema podría ser la peor opción para responder a un incidente de seguridad de la información. Si un atacante ya ha puesto en peligro un sistema local, apagar el sistema podría destruir evidencia valiosa que podría ser utilizada para el análisis forense. Cerrar las conexiones de red, o, posiblemente, una red completa, también podría destruir evidencia que podría ser utilizada en una investigación. Tal vez sería mejor simplemente desconectar la conexión de red e investigar el sistema mientras éste sigue en funcionamiento, y sin que el atacante pueda acceder al sistema. Las empresas individuales tendrían que evaluar si el valor potencial obtenido de esta evidencia supera la necesidad de apagar un sistema para evitar daños.

Cómo prepararse para cerrar un sistema

Aunque cerrar un sistema es una medida drástica, hay algunos pasos que las empresas pueden tomar para prepararse para ese escenario. En primer lugar, comprenda mejor qué datos se almacenan en el sistema y realice un análisis de impacto al negocio (BIA). El BIA documenta la importancia de un sistema para el negocio, para qué se utiliza el sistema y el impacto de una interrupción potencial. Esto conducirá al desarrollo de un plan de continuidad del negocio y recuperación ante desastres (BCDRP), que es similar a un plan de respuesta a incidentes; ambos deben desarrollarse antes de un incidente y ser probados periódicamente para que si fuera necesario apagar el sistema, haya a la mano un libro de estrategias para hacer frente a la situación.

Antes de cerrar un sistema como parte de un procedimiento de respuesta a un incidente de seguridad, es fundamental obtener la autorización de las partes adecuadas. En la elaboración del plan de respuesta a incidentes o BCDRP, establezca un canal de comunicación con las personas necesarias, incluyendo al jefe de seguridad de la información (CISO), al director de información (CIO), a soporte técnico, los dueños del negocio y mercadotecnia para que sean capaces de tomar rápidamente una decisión informada sobre el cierre potencial de un sistema. Si apagar el sistema esencialmente detendrá las operaciones de la organización, la alta dirección debe ser informada. Ellos necesitarán saber el impacto para la organización, los esfuerzos ya en curso, costos potenciales y el impacto de la remediación. Quiénes necesitan saber qué detalles puede variar dependiendo de la organización y los recursos disponibles.

Por último, recuerde que apagar el sistema en realidad no asegura el sistema y no debe ser el último paso en el proceso de respuesta a incidentes de seguridad. Tras el cierre de un sistema, el siguiente paso es remediar cualquier problema de seguridad que haya causado la situación en el primer lugar. Los esfuerzos de remediación pueden incluir parchar un sistema, hacer cambios en la configuración o restringir el acceso solamente a conexiones de confianza. La duración de esta etapa dependerá de los resultados del BIA y el BCDRP; sin embargo, los sistemas con un mayor impacto por el tiempo de inactividad deben ser remediados rápidamente. Por ejemplo, un servidor Web con una aplicación Web susceptible de una vulnerabilidad de inyección SQL puede pararse mientras se desarrolla un parche, se configura un firewall de aplicaciones Web o se cambia la configuración para eliminar el acceso para evitar que un servidor Web ejecute comandos en el sistema.

Conclusión

Para una organización bajo ataque, el curso de acción más drástica es a veces la mejor (o única) opción a tomar. Comprender el impacto al negocio del tiempo de inactividad de un sistema o red en particular ayudará a determinar si se dedican recursos a la protección de un sistema en peligro o si es más apropiado apagarlo. Independientemente de qué opción es la mejor en una situación dada, asegurarse de tener en orden un plan y canales de comunicación antes de un incidente es fundamental para minimizar el impacto en la organización.



Sobre el autor: Nick Lewis, CISSP, es el oficial de seguridad de la información en la Universidad de Saint Louis. Nick obtuvo su Maestría en Ciencias en seguridad de la información por la Universidad de Norwich en 2005, y en telecomunicaciones por la Universidad del Estado de Michigan en 2002. Antes de incorporarse a la Universidad de Saint Louis en 2011, Nick trabajó en la Universidad de Michigan y en el Hospital de Niños de Boston, el principal hospital de enseñanza pediátrica de la Escuela de Medicina de Harvard; también colaboró para Internet2 y la Universidad Estatal de Michigan.

Investigue más sobre Gestión de la seguridad de la información

Inicie la conversación

Envíenme notificaciones cuando otros miembros comenten sobre este artículo.

Por favor cree un Nombre de usuario para poder comentar.

- ANUNCIOS POR GOOGLE

Close