¿Qué debo ver en caso de que un proveedor importante sufra un compromiso con un impacto no especificado?

14

El ejemplo específico que tengo en mente aquí es el infracción de RSA en marzo de 2011 donde los atacantes se salieron con información crítica que podría ser la información semilla que se utiliza para generar los números pseudoaleatorios para los tokens RSA.

RSA se ha mantenido muy callada con respecto a los detalles reales, por lo que si estuviera a cargo de la seguridad en una organización, ¿qué podría hacer para protegerme en el peor de los casos? ¿Cómo podría saber cuál sería el peor de los casos?

    
pregunta Rory Alsop 08.04.2011 - 13:07
fuente

4 respuestas

10

Creo que el hecho de que su proveedor de seguridad esté lejos de ser transparente, ya es un escenario bastante malo.
Cuando el proveedor está siendo reservado, los detalles de seguridad de la escritura, ya sean específicos de un incidente, o los elementos internos de seguridad del producto en sí (o al menos una prueba de seguridad, por ejemplo, crypto algos), es un riesgo inherente para toda la postura de seguridad de tu propia organización

Ahora, mientras que en ciertas circunstancias es legítimo aceptar un riesgo, un riesgo como este (que toda su arquitectura de seguridad dependa de un tercero, en el que se puede confiar o no) no ser aceptado a la ligera.
Cuando un proveedor comienza a inclinarse en la dirección de retener información crítica, en lugar de ayudar a los clientes a tomar decisiones inteligentes, yo diría que la decisión de aceptación de riesgos comienza a ser un poco turbia.

Como resultado, si estuviera en esa posición (e ignorando restricciones como el presupuesto, el tiempo y la política), volvería a evaluar mi relación con TODOS los proveedores que suministran una parte crítica de mi infraestructura. Tenga en cuenta que esto es irrelevante del impacto real: las fallas de alto impacto pueden ocurrirle a (casi) cualquier persona, la parte importante es cómo elige enfrentarlo.
En mi opinión, en este caso, la forma en que lo manejaron (o no) muestra que no entienden la relación de confianza que debe existir, para que la aceptación del riesgo anterior sea válida. Como mínimo, podría considerar cambiar las relaciones de los proveedores a uno de riesgo transferrance en lugar de aceptar, a través de acuerdos de nivel de servicio estrictos con cláusulas de penalización.

¿Y en este caso específico?
Bueno, suponer que cambiar todo el mecanismo de autenticación hasta que se resuelva este acuerdo no es realmente posible, no hay mucho más que hacer, excepto activar más el inicio de sesión en los inicios de sesión, prestar especial atención a los inicios de sesión anómalos, observar lo que hacen sus usuarios y, en general, intentar para minimizar el acceso de los usuarios ...

    
respondido por el AviD 08.04.2011 - 14:38
fuente
9

Si un proveedor sufre un compromiso con un sistema que utiliza y se niega a proporcionarle detalles satisfactorios sobre el impacto del compromiso en sus sistemas, entonces lo que debe buscar es ... un nuevo proveedor.

El peor escenario es el desglose completo del uso del sistema de seguridad. P.ej. en un sistema de autenticación, los atacantes saben lo suficiente como para autenticarse bajo cualquier identidad falsa que deseen, y también pueden evitar que los usuarios válidos se autentiquen, o interrumpen su proceso de autenticación de para que el servidor los autentique de forma transparente con la ID incorrecta. .

    
respondido por el Thomas Pornin 08.04.2011 - 15:21
fuente
4

Esta pregunta realmente se remonta a la gestión de riesgos, y ni siquiera estoy hablando de la gestión de riesgos derivada de la gestión de seguridad de la información.

Estoy hablando de gestión de riesgos de gestión de proyectos. Muchas empresas tienen una PMO (oficina de gestión de proyectos), pero menos tienen expertos en riesgos de proyectos.

Al determinar el alcance de un proyecto, como subcontratar la gestión de identidad a un producto de un proveedor, como RSA SecurID, los gerentes de riesgos del proyecto dirían "¿cuánto deberíamos poner en esta solución de proveedor único?" - no desde una perspectiva de seguridad, sino simplemente desde una perspectiva de "administrar el negocio".

En mi opinión, cuando una gran empresa va a comprar un producto y lo expande (esto se aplica también a la subcontratación y la computación en la nube, incluido SaaS también) existe la idea de no poner todos los huevos en una sola cesta. Si su proveedor principal desaparece, ¿qué tan fácil es trasladarse a un proveedor secundario o terciario?

Al planificar: es fácil simplemente ver cómo los proveedores / proveedores se dividen en porcentajes y sobrellenado. Si tiene una solución que es 100 por ciento interna, considere agregar una solución externa que cubra un vacío del 20 por ciento. Luego, agregue otro proveedor para otro 20 por ciento, un 40 por ciento fuera de la solución. Determine qué proveedor merece la pena de los dos después de un análisis de contabilidad de rendimiento (y probablemente de contabilidad financiera), así como de su propio desempeño de auditoría interna y métricas de negocio en torno a dicho producto.

Si una solución sobresale, toque otro 20 por ciento y si se comportan bien durante otro período de tiempo (un ciclo o iteración de seis sigma), agregue un 20 por ciento final. Luego tiene dos proveedores: uno al 20 por ciento, uno al 60 por ciento (y el 20 por ciento aún es interno). Como medida final, agregue una tercera solución proveedor / proveedor al 20 por ciento (para una solución completamente subcontratada). Sin embargo, retenga su capacidad de recurrir a su solución del 20 por ciento si es necesario durante un período de tiempo determinado. Mira cómo se desempeñan. Uso de su segundo y tercer proveedor: vea si alguno de ellos puede asumir otro 20 por ciento (como lo hizo su primer proveedor) durante las pruebas. Si se aprueban, realice los escenarios de falla en los que reduzca su proveedor primario al 40 por ciento y deje que el proveedor secundario o terciario tome ese 20 por ciento adicional durante un período de tiempo. Analice el uso de sus métricas y las herramientas Six Sigma sobre el desempeño de los proveedores secundarios y terciarios, y cambie los números si su proveedor principal le está fallando.

A largo plazo, podrá moverse rápidamente de un punto de solución a otro y, posiblemente, incluso volver a una solución interna. No se trata solo de la gestión de la seguridad de la información, la gestión de riesgos o las operaciones de recuperación de desastres / procesos empresariales. ¡Es una buena práctica de gestión de proyectos!

    
respondido por el atdre 08.04.2011 - 19:53
fuente
1

Alguien más tendrá una mejor respuesta, estoy seguro, pero creo que, en el peor de los casos, requiere la revocación inmediata de todos los tokens y una auditoría de todos los sistemas para los que se utilizaron los tokens.

Creo que el peor escenario debe ser definido por la empresa, por empresa.

    
respondido por el Steve 08.04.2011 - 14:33
fuente

Lea otras preguntas en las etiquetas