Se ha escrito mucho sobre los motivos del reciente incidente de Crowdstrike. Sin detenernos demasiado en el pasado (puede obtener los antecedentes aquí), la pregunta es: ¿qué podemos hacer para planificar el futuro? Preguntamos a nuestros analistas expertos qué medidas concretas pueden tomar las organizaciones. No confíe en sus proveedores ¿Suena duro? Debería. No confiamos en las redes o la infraestructura y la gestión de acceso, pero luego nos permitimos asumir que los proveedores de software y servicios son 100% herméticos. La seguridad tiene que ver con la permeabilidad de la superficie de ataque general: así como el agua encontrará una manera de atravesarla, también lo hará el riesgo. Crowdstrike era anteriormente el niño mimado de la industria, y su marca tenía un peso considerable. Las organizaciones tienden a pensar: «Es un proveedor de seguridad, así que podemos confiar en él». Pero ya sabe lo que dicen sobre las suposiciones… Ningún proveedor, especialmente un proveedor de seguridad, debe recibir un trato especial. Por cierto, que Crowdstrike declare que este evento no fue un incidente de seguridad se perdió por completo el punto. Cualquiera sea la causa, el impacto fue la denegación de servicio y daños tanto comerciales como a la reputación. Trate cada actualización como sospechosa Los parches de seguridad no siempre se tratan de la misma manera que otros parches. Pueden ser activados o solicitados por equipos de seguridad en lugar de operaciones, y pueden ser (percibidos como) más urgentes. Sin embargo, no existe tal cosa como una actualización menor en seguridad u operaciones, como cualquiera que haya experimentado un parche malo sabrá. Cada actualización debe ser examinada, probada e implementada de una manera que administre el riesgo. La mejor práctica puede ser probar primero en una muestra más pequeña de máquinas, luego hacer la implementación más amplia, por ejemplo, mediante un sandbox o una instalación limitada. Si no puede hacer eso por cualquier motivo (quizás contractual), considérese trabajando en riesgo hasta que haya pasado suficiente tiempo. Por ejemplo, el parche Crowdstrike fue una instalación obligatoria, sin embargo, algunas organizaciones con las que hablamos lograron bloquear la actualización usando configuraciones de firewall. Una organización usó su plataforma SSE para bloquear los servidores de actualización una vez que identificó el parche malo. Como tenía buenas alertas, el equipo de SecOps tardó unos 30 minutos en reconocerlo e implementarlo. Otro limitó las actualizaciones de Crowdstrike a 100 Mb por minuto; solo fue afectado por seis hosts y 25 puntos finales antes de establecerlo en cero. Minimizar los puntos únicos de falla En el pasado, la resiliencia se lograba mediante la duplicación de sistemas específicos, el llamado «2N+1», donde N es el número de componentes. Sin embargo, con la llegada de la nube, hemos pasado a la idea de que todos los recursos son efímeros, por lo que no tenemos que preocuparnos por ese tipo de cosas. No es cierto. Haz la pregunta: «¿Qué sucede si falla?», donde «eso» puede significar cualquier elemento de la arquitectura de TI. Por ejemplo, si eliges trabajar con un solo proveedor de nube, observa las dependencias específicas: ¿se trata de una sola máquina virtual o de una región? En este caso, el problema de Microsoft Azure se limitó al almacenamiento en la región Central, por ejemplo. Para que conste, también puede y debe referirse al propio agente de detección y respuesta. En todos los casos, ¿tiene otro lugar al que hacer la conmutación por error en caso de que «ya» deje de funcionar? La duplicación integral es (en gran medida) imposible para los entornos de múltiples nubes. Un mejor enfoque es definir qué sistemas y servicios son críticos para el negocio en función del costo de una interrupción y luego gastar dinero en cómo mitigar los riesgos. Considérelo como un seguro; un gasto necesario. Trate las copias de seguridad como una infraestructura crítica Cada capa de infraestructura de copia de seguridad y recuperación cuenta como una función empresarial crítica y debe reforzarse tanto como sea posible. A menos que los datos existan en tres lugares, no están protegidos porque si solo tiene una copia de seguridad, no sabrá qué datos son correctos; además, la falla a menudo se produce entre el host y la copia de seguridad en línea, por lo que también necesita una copia de seguridad fuera de línea. El incidente de Crowdstrike arrojó luz sobre las empresas que carecían de una base de capacidad de conmutación por error y recuperación para sistemas críticos basados ​​en servidores. Además, debe tener confianza en que el entorno que está poniendo en marcha es «limpio» y resistente por derecho propio. En este incidente, un problema común fue que las claves de cifrado de Bitlocker se almacenaron en una base de datos en un servidor que estaba «protegido» por Crowdstrike. Para mitigar esto, considere usar un conjunto completamente diferente de herramientas de seguridad para la copia de seguridad y la recuperación para evitar vectores de ataque similares. Planifique, pruebe y revise los procesos de falla La recuperación de desastres (¡y esto fue un desastre!) no es una operación de una sola vez. Puede parecer una carga pensar constantemente en lo que podría salir mal, así que no lo haga, pero tal vez preocúpese trimestralmente. Realice una evaluación exhaustiva de los puntos débiles en su infraestructura y operaciones digitales, y busque mitigar los riesgos. Como se discutió, todo riesgo es riesgo comercial, y la junta directiva es el árbitro final de la gestión de riesgos. Es trabajo de todos comunicar los riesgos y sus ramificaciones comerciales, en términos financieros, a la junta. Si la junta elige ignorarlos, entonces ha tomado una decisión comercial como cualquier otra. Las áreas de riesgo resaltadas en este caso son los riesgos asociados con parches defectuosos, los tipos incorrectos de automatización, demasiada confianza en los proveedores, falta de resiliencia en la gestión de secretos (es decir, claves de Bitlocker) y la imposibilidad de probar los planes de recuperación tanto para servidores como para dispositivos de borde. Busque una automatización resiliente La situación de Crowdstrike ilustró un dilema: no podemos confiar al 100% en los procesos automatizados. La única forma en que podemos lidiar con la complejidad de la tecnología es a través de la automatización. La falta de una solución automatizada fue un elemento importante del incidente, ya que requirió que las empresas «toquen manualmente» cada dispositivo, a nivel mundial. La respuesta es insertar humanos y otras tecnologías en los procesos en los puntos correctos. Crowdstrike ya ha reconocido la insuficiencia de sus procesos de prueba de calidad; este no fue un parche complejo, y probablemente se habría encontrado que tenía errores si se hubiera probado correctamente. De manera similar, todas las organizaciones necesitan tener procesos de prueba a la altura. Las tecnologías emergentes como la IA y el aprendizaje automático podrían ayudar a predecir y prevenir problemas similares al identificar vulnerabilidades potenciales antes de que se conviertan en problemas. También se pueden utilizar para crear datos de prueba, arneses, scripts, etc., para maximizar la cobertura de prueba. Sin embargo, si se dejan funcionar sin escrutinio, también podrían convertirse en parte del problema. Revise la diligencia debida del proveedor Este incidente ha ilustrado la necesidad de revisar y «probar» las relaciones con los proveedores. No solo en términos de servicios proporcionados, sino también acuerdos contractuales (y cláusulas de reparación para permitirle reclamar daños y perjuicios) por incidentes inesperados y, de hecho, cómo responden los proveedores. Tal vez Crowdstrike sea recordado más por cómo la empresa y el director ejecutivo George Kurtz respondieron que por los problemas causados. Sin duda, se seguirán aprendiendo lecciones. Tal vez deberíamos tener organismos independientes que auditen y certifiquen las prácticas de las empresas de tecnología. Tal vez debería ser obligatorio para los proveedores de servicios y vendedores de software facilitar el cambio o la duplicación de funcionalidad, en lugar de los enfoques de jardín amurallado que prevalecen hoy. En general, sin embargo, se aplica el viejo adagio: «Si me engañas una vez, la culpa es tuya; si me engañas dos veces, la culpa es mía». Sabemos a ciencia cierta que la tecnología es falible, pero esperamos que con cada nueva ola se vuelva de algún modo inmune a sus propios riesgos y a la entropía del universo. Ahora que el nirvana tecnológico se ha pospuesto indefinidamente, debemos asumir las consecuencias. Colaboradores: Chris Ray, Paul Stringfellow, Jon Collins, Andrew Green, Chet Conforte, Darrel Kent, Howard Holton