Parece que cada hackeo importante está acompañado por el apuntar de los dedos. Y hay un montón de lugares para señalarlos: los servidores que no fueron remendados, el minorista que no había terminado de configurar un sistema de detección de intrusiones, el alto funcionario que utilizó su correo electrónico personal para almacenar información crítica, la aplicación crítica con los agujeros de seguridad no fijados, porque los programadores no habían terminado de fijarlos todavía, los usuarios de aplicaciones no autorizadas en la nube o móviles para datos corporativos.
Lo que todas estas cosas tienen en común es que involucran a los sistemas de TI en un estado de excepción. Había reglas (o «mejores prácticas», si es necesario) sobre cómo las cosas deben ser aseguradas, pero, por alguna razón, estas cosas eran una excepción a esas reglas.
Las personas que eran responsables de la seguridad de aquellos que fueron violados habían asumido que las cosas estaban sucediendo de una cierta manera – es decir, sólo las aplicaciones aprobadas estaban en uso, todos los sistemas críticos fueron remendados correctamente, alertas adecuadas fueron monitoreadas y software escrito internamente Se había endurecido. Sin embargo, estas cosas no siempre eran ciertas, todo el tiempo. Hubo excepciones que vivían fuera de la política de seguridad y distorsionaban la aceptable tolerancia al riesgo.
EL ESTADO DE EXCEPCIÓN
Una manera común de que las personas se sienten engañadas por estas excepciones de seguridad es cuando estas cosas están en el proceso de convertirse en «aceptablemente seguras» pero aún no están allí. En las reuniones sobre el estado de los proyectos, no es raro oír, «estamos endureciendo esas cajas, pero estamos atrasados». Y la suposición es que están casi terminados, pero no siempre es así. Otra afirmación engañosa de que un usuario que necesita una solución específica se le dice es: «No tenemos la aplicación correcta de seguridad o el sistema de correo electrónico todavía, pero pronto». A menudo es el usuario quien va a buscar su propia aplicación BYOD hasta TI ofrece una solución, que podría tomar meses o incluso años. Mientras tanto, IT asume que el usuario se está conformando con la solución existente y se acostumbrará a ella.
La suposición es siempre que en un plazo corto, estas excepciones a las reglas serán cerradas. Sin embargo, los períodos de excepción pueden llegar a ser a largo plazo, exponiendo a una organización a niveles cada vez mayores de riesgo a medida que pasan sin resolver.
¿POR QUÉ PERSISTEN LAS EXCEPCIONES?
¿Por qué las soluciones temporales persisten durante años en el estado de excepción a largo plazo? La razón más común es el costo. Una organización establece una solución universal que cubre la mayoría de los casos necesarios a un nivel eficiente y económico. Los pocos casos que la solución no cubre existen en la excepción, pero la suposición es que finalmente se pondrá al día. ¿Por qué no se ponen al día? Hay dos categorías de excepcionales casos: sistemas y personas.
Los sistemas que no se llevan a la regla suelen ser sistemas heredados. Estos sistemas suelen ser costosos y críticos, pero necesitan ser actualizados o reemplazados. Sin embargo, a menudo se tarda más de lo esperado en implementar debido al costo, la falta de experiencia y la complejidad o interacciones inesperadas. Y a medida que se encuentran nuevos problemas, el plazo continuamente se expulsa.
Es la naturaleza humana para que la minoría proteja sus propios intereses en la cara de los cambios mandados por la mayoría que no caben todos. Y nada siempre se ajusta a todos, especialmente en las organizaciones más grandes. Estos tipos de BYOD y sombra de las excepciones de TI son inevitables cuando las soluciones a escala empresarial se despliegan. La gente hará sus propias excepciones y usará lo que quiere usar. He visto a un puñado de usuarios se niegan a usar el correo electrónico corporativo estándar y descargar su propio cliente porque era lo que estaban familiarizados con. Adivina quién se infectó con malware por correo electrónico?
Proporcionar soluciones seguras personalizadas para ese subconjunto de la población requiere un costo significativo y no proporciona ningún beneficio directo a aquellos que mantienen el sistema en general. En otras palabras, si funciona para la mayoría de nosotros, todo el mundo tiene que caer en la línea. Pero eso no suele suceder, y los bolsillos de las excepciones a largo plazo comienzan a infectarse.
QUÉ HACER CUANDO LA EXCEPCIÓN SE CONVIERTE EN LA REGLA
Las excepciones a la política de seguridad que no son controladas y no compensadas se convierten en una fuente de riesgo, que aumenta dependiendo de dos factores. El primer factor es el tamaño de un posible impacto de un fallo de seguridad, que puede ser alto si una excepción involucra datos o sistemas críticos. El segundo factor es la probabilidad de explotación que aumenta con el tiempo, por lo que las excepciones a largo plazo son especialmente peligrosas.
La clave para lidiar con las excepciones es documentarlas y rastrearlas. Los supuestos también deben hacerse explícitamente claros para todos los tomadores de decisiones para que todos estén en la misma página. Es fácil que las excepciones sean pasadas por alto o ignoradas a medida que se demoran con el tiempo, convirtiéndose en parte del status quo.
Los líderes de seguridad deben asegurarse de que todos son conscientes de que existen problemas y no se resolverán por sí mismos. Un poderoso principio de gestión es: Si no puedes medirlo, no puedes manejarlo. Por lo tanto, el riesgo con respecto a estas excepciones debe ser medido, rastreado y reportado regularmente para asegurarse de que no hay sorpresas. También facilita la creación de un lazo de retroalimentación de la administración ejecutiva de los recursos para mitigar el riesgo o ordenar la eliminación de la excepción.
REDUCCIÓN DE EXCEPCIONES
Al implementar una nueva política o sistema, es útil recordar que los nuevos sistemas generarán nuevos problemas. Incluso pequeños cambios pueden actuar como catalizadores de un golpe de retroceso más grande e inesperado que, a tiempo, creará excepciones. Todo depende de lo bien que una solución coincida con la cultura y la infraestructura que se está poniendo en. También es difícil forzar una solución a gran escala a funcionar si no encaja en una organización. Normalmente se integra o crea excepciones significativas.
Una señal de advertencia de que algo no va a integrarse bien es cuando las personas (a veces denominadas «usuarios») son tratadas como componentes inertes y obedientes en lugar de individuos dinámicos con sus propias motivaciones, hábitos y requisitos. Otro problema puede surgir cuando los nuevos procesos de seguridad favorecen la conveniencia de la organización sobre los individuos. Estos son los procesos que podrían ser trabajados en torno a las excepciones en lugar de ser utilizados de manera adecuada y segura. Por ejemplo, un difícil proceso de acceso remoto empujará a los usuarios a sistemas alternativos y menos seguros, manteniendo la ilusión organizacional de que se ha establecido un sistema seguro.
EXCEPCIONES QUE SE MANIFIESTAN CON EL TIEMPO
Incluso un sistema de seguridad totalmente funcional y bien integrado tendrá que ser monitoreado y ajustado con el tiempo. Habrá variabilidad en las demandas y condiciones de cualquier organización normal que si no se compensan pueden crear excepciones ocultas en el programa de seguridad. El éxito significa detectar y seguir estas excepciones a medida que surgen y cumplirlas con las mitigaciones apropiadas. De esta manera, el estado de excepción puede pasar de un riesgo inaceptable a largo plazo a corto plazo y el nivel aceptable de riesgo mantenido.
Fuente: https://www.helpnetsecurity.com/2017/07/05/securitys-blind-spot/