Fourth Factor (De-)Authentication
January 18th, 2007 por Alf
Un post interesante de Hugh Thompson en el blog de CSO sobre mecanismos de desautentificación y monitorización de anomalías.
Measuring behavior “post authentication” brings a whole new dimension to trust but verify. It basically makes the statement “We trust that this person is who the say they are because they just *proved* it…but we’ll keep checking to see what they do just incase.” It can automatically tune security controls. Right now, if you’re making a bigger-than-normal transfer on many banking sites they may ask you for some additional information like your mothers maiden name. What if this was taken a step further? If my browsing behavior on a site was “different” is some meaningful way maybe a series of safeguards kick in even if the transaction that I made was “normal.”
El ejemplo que pone Hugh en su artículo es bastante común. El uso “anormal” de tarjetas de crédito. Esto lo hacen la mayoría de los bancos y proveedores de tarjetas de crédito. Una transacción se puede hacer correctamente, pero si existen circunstancias anormales (por ejemplo, siempre haces las compras en Madrid, pero una viene de Kiev), dejas de estar “autenticado” y una comprobación de emergencia debe ser realizada (normalmente te llaman para comprobar que la compra la has hecho tú)
Ahora bien, ¿por que no se implementan estos mecanismos en otras aplicaciones? Vale que hayas entrado con tu usuario y tu contraseña. Pero la aplicación debería monitorizar actividades que se salgan de lo normal. Y en ese caso hacer varias cosas: generar una alerta, aumentar el nivel de autenticación necesario, registrar con especial cuidado toda la transacción a efectos de auditoría y análisis post-mortem, etc.
Sí, se puede decir que es Intrusion Detection, pero debería ser una parte integral de las aplicaciones. Con mecanismos correctivos, no sólo de detección.
