Doogree
Respuesta · Remediación

Reparar con consentimiento: remediar sin cruzar la línea

06/07/2026 · ~5 min de lectura
RemediaciónNIST RespondTOFUCanal de control firmado

La detección es solo la mitad del trabajo. La otra mitad es reparar, pero la remediación automática a ciegas es exactamente tan peligrosa como el propio problema. El enfoque de Doogree es simple: no reparamos a tus espaldas. Cada problema reparable aflora como una sugerencia, alguien la aprueba, y solo entonces se pone en marcha una acción conocida, acotada y reversible.

La anatomía de una sugerencia de reparación

Cada problema reparable no se ejecuta por su cuenta: se propone. El operador ve tres botones: Aprobar / Reparar, Ahora no, Descartar. Al pulsar Aprobar se envía una acción modelada y de lista blanca —no un comando de shell arbitrario— y a continuación el sistema vuelve a verificar el estado y ejecuta el bucle de nuevo hasta que el problema queda resuelto o descartado. No hay ningún «reparar todo con un clic» ejecutándose en la oscuridad; hay una cadena corta de sugerencia → aprobación → acción → verificación.

Una sugerencia, no una ejecución. Por defecto, siempre es el humano (o más adelante, una política definida) quien está en el bucle. Nunca ocurre una acción significativa sin consentimiento explícito, y cada una tiene un registro de auditoría completo: quién la aprobó, qué se envió y cuál fue el resultado.

Por qué no hay un shell libre: el modelo de confianza

El secreto está en que las acciones no son «ejecuta este comando». Las acciones contra un servidor se envían sobre un canal de control firmado y anclado por TOFU (Trust On First Use): la forma canónica del comando va firmada, de modo que un reenvío o manipulación se detecta de inmediato. No hay shell libre: solo acciones de una lista blanca, invocadas por sus nombres explícitos. El significado práctico: incluso si se vulnera una nube o una base de datos, un atacante no puede falsificar un comando y convertirlo en RCE sobre la flota. La línea entre «detectar» y «ejecutar código en un dispositivo» se custodia con celo.

Privilegio mínimo en acción. Cada acción sabe exactamente qué se le permite hacer, y nada más. No hay una «llave para todas las puertas»: hay llaves específicas de lista blanca, cada una de las cuales abre una sola puerta y deja un rastro.

Incidente crítico → botón de contención

Reparar con consentimiento se conecta directamente con el motor de incidentes. Cuando el motor SIEM-lite funde varias alertas en un incidente correlacionado de severidad alta/crítica, ofrece automáticamente un botón de contención. Aprobar el botón actúa sobre el mismo canal de control firmado: el mismo modelo de confianza, la misma lista blanca, la misma auditoría. Así, la cadena de ataque no solo se detecta y etiqueta, sino que obtiene una acción de respuesta reversible a un toque de distancia.

Por qué esto es crítico para una pequeña empresa

Una pequeña empresa normalmente no tiene un ingeniero de seguridad a tiempo completo. Reparar con consentimiento le da a un dueño de negocio no experto un botón seguro de «reparar esto» —totalmente documentado— en lugar de necesitar un SOC caro. Y cuando se trata de algo significativo, el humano permanece en el bucle; más adelante puedes protegerlo con una política con aprobación 2FA (push-approval) para que una acción arriesgada solo salga tras la verificación.

El marco teórico: esta es la etapa Respond de NIST: no solo detectar, sino responder de forma controlada. Todo se construye sobre el privilegio mínimo y sobre la seguridad de la cadena de suministro: no hay ningún canal por el que una nube vulnerada pudiera lanzar comandos arbitrarios a los dispositivos. Remediación: sí. Cruzar la línea: nunca.

← Volver al blog · Cómo funciona →