Un comprometido DKIM La clave privada puede permitir a un atacante crear firmas que se verifiquen en el dominio de firma afectado. Trate el evento como un incidente de autoridad de firma. Reemplazar un registro DNS es solo una parte de la contención, y la verificación DKIM por sí sola no puede distinguir a un firmante autorizado de un atacante que posee la misma clave.
Establecer la autoridad afectada
Identifique el dominio de firma, los selectores, el custodio de claves y todos los servicios que utilizan la clave privada. Conserve los registros de auditoría relevantes, la configuración y los mensajes sospechosos representativos sin copiar el secreto en tickets o chat. Registre el tiempo de descubrimiento, la ventana de exposición probable y lo que se sabe y lo que se sospecha.
Separe el robo de clave privada del acceso no autorizado a un servicio de firma. Un atacante con acceso a la cuenta puede continuar firmando después de una rotación de clave a menos que ese acceso esté contenido. El compromiso de la administración DNS es otra dependencia que requiere su propia respuesta. Coordinar estas investigaciones bajo la dirección del propietario del incidente.
Detener nuevos usos indebidos y revocar la antigua ruta de verificación
Suspender las rutas de firma o credenciales afectadas a través del proceso de incidentes aprobados. RFC 6376 permite la revocación publicando un valor p vacío. Quitar la clave también impide la recuperación exitosa una vez que la ausencia es visible. Elija la respuesta soportada por la plataforma y verifique la respuesta exacta selector y dominio antes de cambiarlo.
La revocación no es instantánea en todos los receptores. Los datos DNS almacenados en caché y los mensajes ya evaluados crean un límite dependiente del tiempo. No prometa que cambiar DNS invalida retroactivamente las firmas en el correo entregado o demuestra que no se aceptaron mensajes abusivos.
La superposición de rotación normal preserva la verificación de mensajes legítimos en cola. Durante el compromiso, mantener verificable la clave expuesta también puede preservar la capacidad de un atacante. El propietario del incidente debe sopesar la contención frente a fallas de correo retrasado en lugar de aplicar automáticamente el cronograma de superposición de rutina.
Restaurar la firma a través de un camino limpio
Genere material clave de reemplazo a través de un proceso respaldado y confiable después de abordar la causa de la exposición. Prefiera un nuevo selector compatible para poder distinguir la evidencia nueva y antigua. Aplicar los requisitos criptográficos actuales. Para la firma RSA, RFC 8301 requiere rsa-sha256 en lugar de rsa-sha1 y recomienda al menos 2048 bits llaves.
Respuesta ilustrativa: el selector sales1 está expuesto y su cuenta de firma está contenida. Un firmante limpio utiliza ventas2 mientras que se revoca ventas1. El nuevo correo controlado se verifica con ventas2 y se alinea con De; El correo retrasado firmado con sales1 puede fallar. Este ejemplo describe una compensación explícita, no un incidente completado ni una garantía de comportamiento del receptor universal.
Verificar la recuperación y preservar la incertidumbre
Pruebe todas las rutas afectadas, no solo un buzón. Guarde mensajes sin procesar y resultados confiables, inspeccione el nuevo selector, confirme alineación y verificar que las credenciales comprometidas ya no autoricen la firma. Revise los registros del proveedor y los informes de los receptores para el período de exposición, teniendo en cuenta que los informes no cubren a todos los receptores ni prueban quién envió cada mensaje.
Mantenga un cronograma de contención, observaciones DNS , implementación de reemplazo y evaluación del impacto en el cliente. Mantenga el acceso controlado a las copias forenses. Cerrar el incidente solo con un propietario identificado para continuar con la investigación y corregir la custodia de claves o la falla de acceso. Una nueva firma exitosa demuestra que la ruta de recuperación funciona; no establece por sí solo el alcance total del uso indebido anterior.
Ejercite una mesa antes de una emergencia.
En esta línea de tiempo sintética, la cuenta de servicio A tiene ventas1 y la cuenta limpia B tiene ventas2. En el minuto cero, contiene A. En el minuto uno, publica la revocación de ventas1. En el minuto dos, un solucionador ficticio todavía tiene su antigua clave en caché, por lo que las firmas antiguas pueden permanecer verificables allí. En el minuto tres, inicia la ruta de ventas limpias2. En el minuto treinta, recopile los resultados recibidos por ruta y acceda a la evidencia en lugar de declarar la recuperación solo desde DNS . Estos tiempos ilustran el orden, no un intervalo de propagación prometido.
Este cuadro escrito propone cinco observaciones de recuperación requeridas: acceso antiguo deshabilitado, causa de exposición contenida, nueva clave publicada, firma nueva verificada y firma nueva alineada. Un escenario en el que se pasa correo nuevo pero el acceso antiguo aún está activo falla en la puerta de recuperación. Un escenario que satisfaga los cinco pasa por la puerta modelada. Ambos conjuntos de observaciones son sintéticos; no se ejecutó ningún programa de mesa, inquilino o prueba de mensajes. Durante un incidente real, se requieren contención real, observaciones de caché, aprobaciones y pruebas de mensajes.
Asignar un propietario a cada puerta de recuperación no resuelta
El caso escrito KEY-01 supone que el selector de reemplazo sales2 produce una firma alineada pasajera para From sales@example.org con d=example.org, pero la cuenta de servicio anterior permanece activa. El propietario del incidente debe mantener abierta la recuperación y abordar la contención del acceso; una prueba de firma exitosa de un administrador de correo no puede cerrar esa brecha. Se desconocen los cachés de resolución antiguos y el alcance de los abusos pasados. Las identidades y los resultados son supuestos de enseñanza estipulados, no un incidente ejecutado.