5 aspectos esenciales a tener en cuenta en la seguridad de base de datos

Buenas,

Al hilo de una mesa redonda a la que he asistido esta mañana, quiero dejar aquí unos comentarios sobre seguridad en base de datos. Es uno de los temas que se han tratado, así que viendo que las personas que han dado la charla han atinado en el planteamiento, me he animado a compartir con vosotros lo que yo entiendo como una seguridad en base de datos adecuada.

Las bases de datos son una de las grandes desconocidas en el mundo de la auditoría de sistemas y en las revisiones de seguridad. No es fácil encontrarse con auditores experimentados en este campo, y eso quizás responde a la enorme complejidad, tecnológica y no tecnológica que tienen las bases de datos empresariales, por no hablar de que cada entorno es hijo de su padre y su madre, y la uniformidad de la tecnología es algo que brilla por su ausencia. Por desgracia, dada esta complejidad, el normal ver planteamientos de auditoría basados en verificar la configuración de seguridad de los motores, la presencia de cifrado, y con un poco de suerte, los hay que se aventuran a mirar las tripas de los procesos y dictaminar si existe una adecuada segregación de funciones. Todos son factores importantes, pero no son por sí mismos representativos del estado de seguridad de una base de datos. Es muy frecuente que los dictámenes se basen en auditar aspectos aislados de la base de datos y no en su conjunto, y lo que es peor: ni pararse a pensar en los datos, estudiando solamente si la plataforma que contiene los datos es o no acorde a una determinada guía de militarización.

La lista puede ser interminable ya que cada cual tiene su modo de proceder, pero voy a sintetizar en 5 los puntos que hay que mirar cuando se analiza una base de datos. Cubren lo que considero mínimo, y en su ausencia yo al menos, salvo casos muy aislados, consideraría que la seguridad de los datos es deficiente.

1. El modelo de protección de datos

Cuando se planifica la seguridad de una base de datos, la única manera de hacerlo bien es acorde a una definición previa de algo tan básico como qué es lo que queremos proteger, dónde y cómo. Este modelo, aunque lo podemos impulsar desde el departamento de seguridad, quien tiene que autorizarlo es el propietario de los datos, muchas veces con ayuda de especialistas, como el departamento legal para el caso de cumplimiento normativo. Es una tarea dura, ingrata y tediosa, pero es estrictamente necesario hacerlo, como veremos a continuación.

Si pedís el modelo y no obtenéis respuesta, mala señal. Las probabilidades de fallar protegiendo los datos sin un modelo consensuado de qué hay que proteger son casi de 1 a 1. Las medidas técnicas que describiremos después dependen de este modelo, con lo que si este no existe, repito, alerta roja. Yo sería muy escéptico a la hora de confiar en la veracidad de que los privilegios, segregación, cifrado y enmascaramiento en un clúster de 10 motores con 60.000 tablas sean correctos sin que nadie se haya sentado a escribir que hay que proteger y cómo. Os van a contar de todo, que casualmente están terminando el borrador del plan, que no pasa nada porque todo está cifrado, que no merece la pena documentar algo tan extenso, que no hay riesgo porque en esta casa todos somos amigos y tomamos cañas juntos, etc. Atentos a este factor, es siempre el humo que indica que hay fuego en las proximidades.

2. El cifrado de los datos

Este es uno de los puntos cruciales y que genera más confusión y controversia. Qué duda cabe que si queremos proteger datos, los razonable es acudir al cifrado. Lo razonable y lo único que sirve, siempre y cuando se acompañe al cifrado de otras medidas que describiremos. Pequeño corolario: los datos críticos que no están cifrados NO ESTÁN PROTEGIDOS. Y peor aún: el cifrado tiene que afectar a todos los elementos que protegen a los datos, da igual que sea un campo de la base de datos, una fila, una columna, una tabla o la base completa. Y señores, el sistema de ficheros del sistema operativo también tiene que estar cifrado. Y las comunicaciones de la base de datos con el resto de la infraestructura. Incluso la memoria de la máquina donde se ubica el gestor, idealmente. Cifrar es cifrar todo, si algo en la cadena no está cifrado el resultado es datos críticos no protegidos.

Contentar a un auditor con un SELECT de la tabla de recursos humanos que muestra únicamente un galimatías y no los datos reales es tremendamente fácil. Y el auditor se irá dando palmas con las orejas, y pondrá en su informe que la base de datos está cifrada. Luego, cuando el auditor se va, el DBA se queda pensando qué pasa con el clon de producción que envían todos los martes por FTP a un outsourcing de Murcia, y que lógicamente, no está cifrado. O que pasa con las copias de seguridad que van a cartucho, que ni están cifrados ni pasan por un canal cifrado. O qué pasa con una aplicación que comunica con el motor en un canal no cifrado. O qué pasa con él mismo, que como es DBA apaga y enciende el cifrado de la base de datos según le viene en gana sin que se entere nadie, o que descifra lo que quiere y cuando quiere porque las llaves maestras están en el propio sistema operativo -sin cifrar-, sistema al que casualmente también tiene acceso root. Incluso, aunque esperemos que no, podría preguntarse si debería haber hecho el SELECT en la base de datos real, y no en una vista enmascarada preparada a tal efecto para quitarse de encima a los auditores.

El cifrado es crucial para montar un esquema de seguridad, y aquí, si se trata de datos críticos, tolerancia cero. En el momento que exista un sólo punto en el que los datos circulen en claro sin una adecuada protección criptográfica, se resquebraja todo. Cifrar sólo una tabla, poner únicamente HTTPS en las aplicaciones que tiran del motor o aplicar el cifrado sólo cuando el dato pasa a cartucho es un cifrado de pandereta, y no es aceptable. Este es el campo donde la tradicional excusa de que el cifrado echa por tierra el rendimiento sale a relucir instantáneamente, argumento ante el cual hay que ser firme alegando que no hay por qué cifrar el motor completo y que hay soluciones hardware que aceleran la gestión criptográfica, empezando por los propios procesadores. El rendimiento, cuando se cifra selectivamente (acorde al plan, acordaos) y no a lo loco, no tiene por qué verse deteriorado significativamente.

3. Control de superusuarios y otros usuarios privilegiados

Muy atentos a este factor. Da igual lo que hagas respecto a cifrar, y da igual lo que exista o no un plan de protección. Si los superusuarios no están controlados, no existe seguridad. Esto aplica a cada uno de los usuarios que tienen relación con los datos, ya sea el DBA, el root del sistema donde corre la base de datos o el amiguete que controla las llaves maestras del HSM donde reside la criptografía. Un superusuario sin control puede hacer lo que quiera con la base de datos, y la única manera de controlar esto es declarar las medidas de control allí donde el superusuario no tiene privilegio alguno. ¿Que necesitan acceso a producción para resolver emergencias? Sin problema. Lo pueden tener. Pero supervisado y controlado por un tercero independiente. ¿Que se queja y patalea porque no puede hacer un SELECT * en la tabla de salarios? No necesita verlos. Es vital y necesario que existan reglas que definan qué pueden hacer, y qué eventos requieren autorización o monitorización especial. Tener superusuarios que pueden entrar cuando quieren y hacer lo que quieren sin que exista control alguno es equivalente a tener una base de datos insegura.

Y da igual que sean de la casa, de fuera, que tomen o dejen de tomar cañas con quien sea. No hay necesidad alguna, y en ausencia de reglas que delimiten el comportamiento de un superusuario y el control de sus acciones, no existe seguridad. Evidentemente, las medidas de control hay que implementarlas en el bajo nivel, en el propio núcleo, o con mecanismos que impidan que el superusuario tenga acceso a dichos controles, de lo contrario, no habremos solucionado nada.

Hay una manera muy rápida de ver si esto está o no controlado. Te sientas con el DBA, hola que tal, buenos días. Yo soy Sergio, encantado. Mira, por favor, haz un SELECT de la tabla de recursos humanos, y saca en pantalla los DNI y los sueldos brutos anuales. Acto seguido, te vas a los de seguridad y les dices, a ver, enseñadme las trazas del DBA en los últimos 30 minutos. Si hay trazas, o si no te da tiempo a ir a buscarlos porque ellos se presentan o llaman al DBA antes de que tú recojas los papeles, hay esperanza. De lo contrario, más humo, y más fuego.

4. Auditoría

Una instalación de seguridad que protege a datos críticos sin trazas de auditoría es inútil. Si no sabemos quien ha hecho qué, y en qué momento, no es posible armar un sistema de monitorización acorde y lógicamente, se pierde toda la traza en caso de ser necesaria una investigación. La auditoría ha de ser completa, no sólo para el motor de la base de datos, sino para el sistema operativo, y para los datos críticos, debe quedar claramente registrado quién ha leído, modificado o borrado un dato. Obviamente, para proteger adecuadamente la auditoría, es preciso moverla a una consola segura y monitorizada donde los superusuarios de la base de datos y sus componentes satelitales no tengan acceso de ningún tipo.

Y por favor, seamos congruentes. No se trata de grabar TODO lo que pasa en la base de datos, se trata de que la operativa con datos críticos quede registrada, así que tened esto en cuenta cuando os digan que no hay manera de poner en marcha la recomendación, que la auditoría se come tera y medio de espacio en disco en 24 horas, y que el almacenamiento está muy caro, y que mover los logs ralentiza la red, y que los operadores del SIEM no pueden mirar 50.000 alertas por hora, y bla bla bla. Auditoría inteligente, suficiente y protegida. Con eso basta.

5. Monitorización

Hemos definido un plan, hemos cifrado, hemos segregado funciones y tenemos el mejor registro de auditoría de la historia. Pongamos la guinda al pastel monitorizando los elementos críticos, por ejemplo, consultas inusuales, comandos privilegiados, procesos que no acaban a su hora, uso de credenciales privilegiadas, operativas de mantenimiento de la base de datos, etc. Pensemos qué cosas pueden hacer que todo lo que hayamos montado se rompa, que no será mucho después de habernos esforzado en todo lo anterior, y convirtamos estos eventos en alertas en el SIEM. Creemos un pequeño saco de eventos no convencionales e imprevistos que merecen ser investigados. Y hagámoslo porque no existe la seguridad al 100%, y es imposible contemplar a priori todo lo que puede pasar en un entorno complejo, con lo que por lo menos, pongámosle las cosas difíciles a los malos de la película. Y esto es factible seleccionando con criterio las alertas que queremos generar basadas en los eventos que creemos pueden hacernos pensar que nuestro planteamiento ha sido vulnerado.

Espero que estas reflexiones os sean de utilidad.

Un saludo,

Reflexiones sobre ZeuS Mitmo (Man-in-the-mobile)

Hola,

Tras pegarse 12 horitas analizando una aplicación Symbian S60, el amigo David de S21 ha publicado unas interesantes entradas (Parte I, Parte II, Parte III) sobre ZeuS Mitmo (Man-in-the-mobile).

Interesantes por varios motivos. El primero y más obvio es que los amigos de lo ajeno ratifican que le están metiendo mano a los esquemas de seguridad más recientes en entornos de banca a distancia. También interesante porque estos movimientos dejan entrever que el malware en dispositivos móviles es un campo que por desgracia tiene mucho recorrido para los criminales. Por último, también interesante, estos ataques dejan claro que no todo el mundo está implementando correctamente la autenticación de transacciones (eso dejando a un lado los que se empeñan erróneamente en autenticar a personas)

Cuando se emplea un teléfono móvil como canal alternativo para, repito, autenticar transacciones, no a personas, por obvio que parezca la relación entidad-cliente requiere que este último informe su teléfono móvil. Maneras de que el cliente informe su móvil hay muchas, y creedme, no es tan sencillo como pueda parecer. Cuando se tienen miles, cientos de miles o millones de clientes, los que desarrollan el negocio tienen dificultades muy elevadas para conseguir que el 100% de la masa de clientes informe de su móvil, especialmente en determinados perfiles de clientela más apegados a la bancarización tradicional.

Ante esta disyuntiva existen diferentes maneras de atajar el problema. Desde soportar transaccionalidad en modalidades distintas (los que han informado el móvil emplean el móvil y los que no, emplean medios tradicionales, como las tarjetas de coordenadas, las claves de operaciones, etc.) hasta forzar a la clientela al uso obligatorio de un teléfono si se quiere emplear la banca a distancia. Hay muchas maneras aceptables y seguras de obtener el móvil de un cliente para poder ofrecer autenticación en canal alternativo, como por ejemplo, tener gestores eficaces en la oficina, ofrecer premios o ventajas a quienes informen del teléfono, capturar el dato en la apertura de productos para nuevos clientes, etc. Lógicamente, obtener el teléfono a través de la propia aplicación de banca a distancia es lo más rápido y cómodo, pero lo que demuestra ZeuS Mitmo es que solicitar el teléfono empleando el mismo entorno de banca a distancia puede entrañar riesgos severos. ¿Por qué? Porque los amigos de lo ajeno pueden insertar ahí un troyano que capture los detalles y hacernos descargar una aplicación maliciosa en nuestro teléfono. Y si se contamina el canal alternativo, señoras y señores, a no ser que se disponga de una autenticación de transacciones bien fundamentada y con los debidos puntos de control, game over.

Y hago mención al servidor de aplicaciones porque el fundamento de la autenticación de transacciones no es otro que enviar al canal alternativo un número de autenticación (mTAN) que esté 100% vinculado a cada transacción que se quiera autenticar. Si el mTAN se genera teniendo en cuenta la cuenta origen, la cuenta destino, el importe y otra serie de parámetros, y este mTAN se valida en el lado del servidor, es posible montar un esquema en el que para transferir pasivo de la cuenta A a la cuenta B sólo exista un mTAN que haga que la operación culmine con éxito. ¿Es este esquema invencible? NO. Ni mucho menos, pero puede ser respaldado con medidas que mitiguen el riesgo.

Un troyano puede capturar la cuenta destino sobre la que queremos operar y hacer la transformación a la cuenta destino de los atacantes. Este paquete se envía al servidor de aplicación, se genera el mTAN, confirmamos la operación y otra vez, game over. Lógicamente, si el canal móvil no está contaminado, el cliente debe recibir un mensaje descriptivo que además del mTAN, incluya la cuenta destino y el importe, como último recurso para detectar anormalidad, pero esto no siempre es así. Sea como fuere, parece más que obvio que los atacantes tienen que, en algún momento, vulnerar el esquema para informar del número de cuenta destino malicioso y así poder extraer dinero de la cuenta origen. ¿Es esto una batalla perdida? NO. Si existe un riesgo de modificación de parámetros, ¿por qué no hacer hincapié en medidas como la utilización de libretas de contactos en la propia aplicación? Si en vez de pasar en la petición HTTP un parámetro cuenta destino pasamos un parámetro contacto 25, y el servidor resuelve que el contacto 25 es el código cuenta cliente cuya numeración es XXXX, ¿qué van a modificar los atacantes? Parece que lo tendrán más difícil, aunque siempre podrán intentarlo cuando demos de alta un contacto en la libreta.

Y como punto de defensa final, estando en pleno siglo XXI, yo al menos espero que mi entidad explote adecuadamente un sistema de prevención del fraude que sepa detectar operativa inusual, y si realizo por primera vez una transferencia a un CCC que nunca he utilizado, bien sea a una cuenta de Albacete o a un IBAN de Bielorrusia, yo quiero ver esa operación en rojo carmesí en el SIEM, e incluso prefiero que la operación sea bloqueada hasta que un operador me llame y me confirme si efectivamente quiero transferir 2000 euros a un tal Dimitri de Uzbekistán. Lamentablemente, este planteamiento choca de bruces con el desarrollo de negocio, cuyo único objetivo es que el cliente opere con comodidad y sin restricciones desde su iPad, su iPhone o su PC, con lo que finalmente, muchas de estas operativas se fraguan en fraude consumado.

La banca en línea es un entorno de alto riesgo que está siendo atacado continuamente. La lección más importante que podemos aprender de estos nuevos métodos de ataque es algo que ya sabemos: los amigos de lo ajeno innovan a pasos agigantados. Pero también podemos aprender otra lección, y esa no es otra que los fraudes en entornos complejos son igualmente complejos, y aunque no existe un método perfecto para solventar la papeleta, cuando se tiene un esquema adecuado cuesta muchísimo más atacar a la clientela que cuando se tiene un sistema elemental.

Un saludo,