Ir al contenido principal

Todo era crítico esta semana. Alguien tuvo que decidir de todas formas.

PAN-OS, eMudhra, PHP2Shell, Node.js. Ocho días, seis incidentes y ninguna puntuación que indicara por dónde empezar. Aquí se explica quién debería haber decidido y cuándo.

Christophe MazzolaChristophe Mazzola· Practicing CISO · Founder of Cyber Academy7 min de lectura
Una mano acciona una palanca en un desvío de cinta transportadora, encaminando un paquete iluminado por un carril dorado mientras seis paquetes idénticos esperan en carriles oscuros

Ocho días. Seis incendios.

El 14 de octubre, Palo Alto Networks divulgó un fallo en PAN-OS que otorga a un atacante autenticado acceso root en el firewall a través de la interfaz de gestión. Ya había sido explotado como zero-day. El 17 de octubre, un investigador demostró que ocho autoridades de certificación intermedias gestionadas por eMudhra tenían claves privadas que cualquiera podía recuperar en menos de un segundo. Una de esas claves era el número 4. El 19 de octubre, Unit 42 informó de que grupos de ransomware, entre ellos Qilin, estaban usando un fallo de GlobalProtect para saltarse el MFA sin obstáculos.

El 21 de octubre, PHP publicó correcciones de emergencia para PHP2Shell, una ejecución de código no autenticada en todas las instalaciones PHP que atienden peticiones web, después de que los detalles se filtraran un día antes. El mismo día, Node.js publicó diez CVEs, incluido un bug de ejecución remota de código en su decodificador Brotli. El 22 de octubre, Palo Alto confirmó que PHP2Shell está presente en todas las versiones de PAN-OS y Panorama, sin parche disponible ni fecha prevista para uno. Las versiones corregidas se estiman ahora para el 26 al 30 de octubre, según la rama de lanzamiento.

Si se gestiona una función de seguridad, esa semana no se resolvió parcheando. Se resolvió tomando decisiones, o alguien las tomó en lugar de uno.

Las puntuaciones no decidieron nada

Alineemos los números.

El exploit de root en PAN-OS, usado contra firewalls reales: 8,6. El bypass de GlobalProtect, en manos de operadores de ransomware: 7,8. El colapso de eMudhra, una CA de confianza cuyas claves de firma cualquiera podía recalcular, descrito por un ingeniero de criptografía de Mozilla como un incidente de impacto máximo posible: el incidente en sí no tiene puntuación alguna, y el único CVE derivado que CISA puntuó obtuvo un 5,4. PHP2Shell: 9,2 según PHP, y clasificado por Palo Alto como un problema de disponibilidad en sus propios firewalls.

El día anterior a todo eso, Microsoft publicó más de 1.400 CVEs en un único Patch Tuesday. Sesenta y nueve estaban calificados como Critical. El que ya estaba siendo explotado estaba calificado como Important.

Una puntuación CVSS describe lo grave que podría ser un fallo sobre el papel. No sabe nada sobre si alguien lo está usando esta mañana, si está expuesto a internet en el entorno de cada uno, ni qué hay detrás. Esta semana, esas tres cosas eran toda la historia.

La política de parcheo habría programado el vector de ransomware para el mes siguiente

Abra la política de gestión de vulnerabilidades. Probablemente dice algo así: Critical en 7 días, High en 30, Medium en 90.

Aplíquela a esta semana. PHP2Shell entra en el bloque de 7 días, correcto. El fallo root de PAN-OS explotado activamente es High: 30 días. El bypass de GlobalProtect que grupos de ransomware están usando activamente: High, 30 días. eMudhra: Medium, 90 días, suponiendo que alguien haya abierto siquiera un ticket.

La propia política habría clasificado las dos cosas que los atacantes estaban usando realmente como trabajo de segunda categoría, y habría dado a una autoridad de certificación comprometida un trimestre para resolverlo.

Como auditor, eso es lo que dejaría por escrito. Ser lento es un hallazgo. Un proceso documentado que provoca lentitud cuando se aplica al pie de la letra es un hallazgo peor, y eso es una no conformidad en A.8.8 contra una política que hace exactamente para lo que fue escrita.

Los derechos de decisión se otorgan en tiempos de paz

Esta es la pregunta que diferenció a las organizaciones esta semana. ¿Quién podía desconectar una interfaz de gestión de firewall de internet a las 23:00, sin esperar al comité de cambios del jueves?

PAN-OS dio dos motivos en ocho días para dejar de exponer esa interfaz. La recomendación de Palo Alto ante el primer fallo es restringir el acceso de gestión a direcciones internas de confianza, y afirma que el segundo es más peligroso cuando la interfaz acepta conexiones desde internet. Es un cambio de configuración que un ingeniero competente realiza en minutos. En la mayoría de las organizaciones, nadie tiene autorización para hacerlo solo.

Amazon registró un intento de explotación de PHP2Shell el 17 de octubre, cuatro días antes de la divulgación pública. CISA dio a las agencias federales de EE. UU. tres días para el fallo de PAN-OS. El CAB se reúne semanalmente. Los números no cuadran, y ningún nivel de talento técnico cierra una brecha de gobernanza.

El procedimiento de emergencia debe existir antes de la emergencia. Personas nombradas. Las acciones concretas que pueden tomar sin consultar. Cómo lo registran. A quién informan después. Se redacta un martes tranquilo, se ensaya una vez, y estará disponible el sábado.

eMudhra fue la prueba real

PAN-OS y PHP tienen parches, o los tendrán. eMudhra no tiene nada que instalar.

Los navegadores reaccionaron rápido. Chrome y Firefox bloquearon los ocho intermediarios el 17 de octubre; Microsoft y Apple siguieron en días. eMudhra los revocó y el 22 de octubre anunció que abandonaba el negocio de certificados TLS por completo.

Los navegadores están bien. Los contenedores, máquinas virtuales, appliances, keystores de Java y todos los entornos Python que llevan su propia copia de certifi son otra conversación. Node.js tuvo que incluir la revocación de confianza dentro de su propia versión de seguridad. Go publicó nuevas versiones para ello.

La pregunta que la organización tenía que responder de verdad era esta: ¿dónde confiamos en autoridades de certificación, y quién puede cambiar eso en todas partes a la vez? La mayoría no puede responder ni la primera parte. Eso es un problema de inventario, y el inventario deja de ser una tarea de IT en el momento en que un regulador lo solicita. Bajo NIS2, el órgano de dirección aprueba las medidas de gestión de riesgos y responde por ellas.

El orden de decisión

Antes de la puntuación, hay que hacerse cuatro preguntas.

  • ¿Está siendo explotado? KEV, el aviso del proveedor, la inteligencia de amenazas propia. Si la respuesta es sí, salta la cola independientemente de su número.
  • ¿Está expuesto? Expuesto a internet supera a lo interno. Las interfaces de gestión superan a casi todo lo demás.
  • ¿Qué alcanza? Identidad, confianza, los sistemas que almacenan los datos, los equipos de los que dependen todos los demás.
  • ¿Cuál es la puntuación? Úsela para ordenar lo que queda.

Bruselas llegó a la misma conclusión. Desde el 11 de septiembre, los fabricantes sujetos al Cyber Resilience Act deben notificar las vulnerabilidades explotadas activamente. La explotación es el detonante, y la puntuación no aparece en ningún lugar del texto.

Consejo: Reescriba los SLA en torno a esas preguntas. Explotado y expuesto: horas. Explotado o expuesto: días. Ninguno de los dos: el ciclo habitual, con la puntuación como criterio de desempate. Así se entrega al auditor una política que realmente se puede seguir.

Lo que el comité de dirección necesita escuchar esta semana

Tres frases.

Si estamos expuestos a alguno de estos fallos, sí o no. Qué se hizo y cuándo. Qué se ha decidido dejar para más adelante y quién lo ha aprobado.

Un recuento de CVEs no les da nada sobre lo que puedan actuar. La tercera frase es la que importa. Bajo el Artículo 20 de NIS2, el órgano de dirección aprueba las medidas de gestión de riesgos de ciberseguridad, supervisa su implementación y puede ser considerado responsable de los fallos. Si nunca se les comunica lo que se ha diferido, no pueden asumirlo, y se habrá tomado en silencio una decisión que les correspondía a ellos.

El backlog es una decisión. Fírmela.

No se puede arreglarlo todo. No se ha podido en años. El volumen simplemente hace imposible seguir fingiendo lo contrario.

Lo que queda pendiente ha sido aceptado, lo haya escrito alguien o no. Así que hay que escribirlo. Un responsable nombrado, el motivo, el control compensatorio si existe, y una fecha para revisarlo. Una vulnerabilidad diferida con una firma es una decisión de riesgo. Sin ella, es una omisión que habrá que explicar más adelante.

Reflexión final

Semanas como esta van a seguir llegando. El descubrimiento de vulnerabilidades acelera más rápido de lo que nadie puede parchear, y todos los sistemas de puntuación seguirán entregando listas en las que todo parece urgente.

Las organizaciones que salieron bien paradas esta semana tenían algo en común. Sabían quién estaba autorizado a decidir, en qué orden, y cómo comunicar a sus superiores lo que había quedado pendiente. Sus escáneres eran los mismos que los de todos los demás.

Eso es trabajo de liderazgo. Nadie más en la organización lo va a hacer por uno.

Esas son las competencias que desarrollan tres de nuestros cursos. Certified CISO by PECB para los derechos de decisión y la conversación con el comité de dirección. NIS 2 Directive Lead Implementer para el Artículo 20 y lo que el órgano de dirección debe responder ahora. ISO 27001 Lead Implementer para una política de vulnerabilidades que realmente se pueda seguir, y una aceptación de riesgos que se sostenga en una auditoría.

Elija el que corresponde a la brecha que esta semana ha puesto al descubierto.

¿Quieres recibir la próxima nota de campo en tu bandeja de entrada?

El boletín The GRC Brief. Cinco enlaces y un análisis breve, cada lunes a las 8h CET. Tres minutos de lectura.