¿Cuál crees que es el estado de la seguridad de las bases de datos hoy en día?

No es nada bueno, bastante malo de hecho. Las empresas prácticamente no tienen control sobre sus bases de datos. Siempre me sorprende la poca visibilidad que tienen las organizaciones sobre lo que ocurre con sus datos. Si consideramos la gran cantidad de filtraciones de datos que ocurren constantemente, es bastante evidente que la situación es desalentadora. Los atacantes solo pueden obtener millones de registros de una base de datos. Eso significa que cualquier filtración significativa es una filtración de datos. Estos resultados son una prueba concluyente y definitiva. De hecho, la terrible realidad es que la situación solo está empeorando, así que quizás «Malo» sea un eufemismo y debería decir «Catastrófico».

Decis que la situación sólo está empeorando, ¿eso significa que la seguridad de las bases de datos se está deteriorando?

No, las brechas de seguridad están empeorando porque el perímetro se penetra con mayor frecuencia, porque las empresas protegen el mismo en lugar de la base de datos. A medida que el perímetro se desintegra, se observan más brechas de seguridad que se convierten en brechas de seguridad de la base de datos.

Las empresas dependen exclusivamente de la protección del perímetro, y ese concepto ya no funciona. De hecho, nunca funcionó bien, pero está empeorando. Al no tener defensas detrás del perímetro para proteger los datos, cualquier penetración se convierte en una filtración de datos.

¿Crees que se trata de una crisis global en todas las organizaciones o se trata de algunos casos aislados?

Si bien algunas organizaciones sin duda obtienen mejores resultados, la naturaleza generalizada de las brechas de seguridad, que afectan a organizaciones de todos los tamaños y sectores, indica fallos sistémicos generalizados. No es que las organizaciones no se esfuercen, sino que sus esfuerzos son, en gran medida, ineficaces. Si las medidas existentes funcionaran, no presenciaríamos la incesante cascada de brechas de seguridad que vemos hoy.

Más allá de la evidente cascada de brechas de datos, ¿ves otras señales de alerta?

Cuando hablo con empresas, suelo empezar por hacerles algunas preguntas para saber en qué punto se encuentran. Por ejemplo, «¿Sabe qué usuarios, programas e IP se conectaron a su base de datos la semana pasada?«. Si el personal de seguridad y los administradores de bases de datos (DBA) desconocen quién se conecta a su base de datos, claramente no hay control. Tener una lista de quién ha accedido a sus bases de datos parece ser lo mínimo. Rara vez obtengo una respuesta adecuada a esta pregunta.

La siguiente pregunta es «¿Quién accedió a sus datos confidenciales la semana pasada?«. Para responderla, las empresas necesitan conocer las bases de datos y tablas que contienen información confidencial y quién ha accedido a ellas. Obtener una respuesta a esta pregunta es poco común. Desconocer quién accede a datos confidenciales es, sin duda, un gran problema. ¿Cómo se puede proteger algo si ni siquiera se sabe dónde está ni quién lo utiliza?

Finalmente, una de mis favoritas es «¿Recibe alertas periódicas de su sistema de seguridad de bases de datos?«. Un síntoma sorprendente de una seguridad ineficaz es la ausencia de alertas de falsos positivos. Algunas personas consideran que la ausencia de falsos positivos es algo positivo. Sin embargo, aunque parezca contradictorio, tener cero falsos positivos significa que es poco probable recibir alertas cuando ocurre un incidente de seguridad real. Un sistema de seguridad en buen estado genera falsos positivos ocasionalmente. Su ausencia es una señal de alerta que indica que la seguridad es demasiado laxa y probablemente no activaría una alarma durante una brecha de seguridad real.

¿Eso significa que la mayoría de las empresas no protegen sus bases de datos?

No, obviamente implementan medidas de seguridad. Tienen políticas de contraseñas, cifrado, mínimos privilegios y más. El problema es que las medidas que implementan no pueden detectar ni prevenir una vulneración. Sus medidas de seguridad no se dirigen a amenazas reales. No se dirigen a los vectores de ataque que los hackers usan para penetrar en su base de datos. Si bien cuentan con algún tipo de seguridad, esta no les alertaría si un atacante entrara y exfiltrara todos sus datos. O peor aún, si alguien modificara algo en sus datos.

Qué interesante. ¿Por qué decis que alterar datos es peor que robarlos?

Quizás lo peor es cuestión de perspectiva. La mayoría de la gente considera el robo de datos como el peor resultado. Sin embargo, considere esto:

Las empresas almacenan datos por una razón, ¿verdad? Los usan para tomar decisiones y actuar. No tiene sentido almacenar datos sin un propósito. Pero ¿qué pasa si los datos se modifican maliciosamente? Significa que las decisiones y acciones basadas en ellos están manipuladas. Quizás sea más fácil verlo de otra manera: ¿tomarías decisiones o acciones basándote en información manipulada?

Los datos inseguros pueden ser engañosos. Es mejor no almacenar datos que almacenarlos de forma insegura.

Volviendo a las medidas de seguridad, ¿por qué crees que fallan? Creo que todos se preguntan cómo alguien puede acceder a una base de datos y robar o manipular datos.

Se preguntan «¿por qué fallan?», y primero quiero enfatizar que, independientemente de si comprendemos correctamente esta falla o no, la realidad es que las medidas de seguridad actuales no son eficaces. Dado que constantemente se producen filtraciones de datos, las medidas de seguridad habituales son ineficaces. Reconocer esta realidad es un primer paso vital: lo que estamos haciendo no funciona.

Pero es justo preguntarse cómo alguien puede penetrar en una base de datos. Es la base para construir una mejor defensa.

Consideren el escenario más simple: credenciales de administrador de base de datos robadas. La mayoría de las organizaciones no sabrían si un atacante se conectó a la base de datos como administrador de base de datos. No existen medidas de seguridad dirigidas a un administrador de base de datos que inicia sesión con un usuario y una contraseña válidos. Dichos inicios de sesión podrían ser utilizados maliciosamente por un hacker con credenciales robadas o por un administrador de base de datos que abuse de sus privilegios.

De igual manera, iniciar sesión en el servidor de la base de datos permitiría a un atacante conectarse a la base de datos sin contraseña. Penetrar en el servidor de la base de datos es una cuestión de seguridad del sistema operativo con múltiples vectores de ataque. Para simplificar el ejemplo, reutilicemos el concepto de credenciales de administrador del sistema robadas. El hacker puede usar estas credenciales para acceder al servidor de la base de datos y, desde allí, no necesita una contraseña para conectarse.

No digo que las credenciales de administrador sean el método principal para acceder a una base de datos, pero estos son ejemplos sencillos que eluden todos los mecanismos de seguridad habituales.

Entiendo que las cuentas DBA son un problema, pero ¿existen otros vectores de ataque que no dependan de ellas?

Todas las cuentas de bases de datos tienen vectores de ataque. Estos vectores suelen presentarse en tres tipos: abuso por parte de empleados, robo de credenciales por parte de un agente externo y vulnerabilidades de software.

Tomemos, por ejemplo, la cuenta de la aplicación. Un empleado que conoce la contraseña podría abusar de ella. Alternativamente, un hacker también podría robarla. Finalmente, un error en el software de la aplicación podría permitir a un atacante aprovechar el acceso a la base de datos de la aplicación para ejecutar su propio SQL malicioso. Por ejemplo, la inyección SQL es una explotación de una falla de la aplicación.

Si consideramos las medidas estándar de seguridad de bases de datos, la triste realidad es que ninguna aborda ninguno de estos vectores de ataque. Medidas como las políticas de contraseñas, el cifrado y el mínimo privilegio no pueden abordar estas amenazas reales.

Si todas las cuentas de bases de datos representan una amenaza, ¿cómo pueden las empresas combatirlas? ¿Existe alguna solución?

Por supuesto. Las soluciones avanzadas de control de la actividad de bases de datos le ayudan a abordar todas estas amenazas y muchas más. Por ejemplo, nuestra solución, Core Audit, lo hace de maravilla. La clave no reside en analizar las amenazas individuales, sino en abordarlas en función de cómo se desvían del comportamiento adecuado de la actividad de la base de datos.

Independientemente de la solución que elija, debe asegurarse de lograr una seguridad eficaz. Los proveedores a menudo intentan confundir a los clientes sobre lo que es importante y les proporcionan una lista irrelevante de amenazas. Debe aplicar el sentido común y validar que la solución pueda combatir las amenazas reales que le afectan.

Por ejemplo, podría utilizar las preguntas básicas que mencioné antes: quién se conectó, quién manipuló datos confidenciales y si recibe una pequeña cantidad de alertas de falsos positivos. Como alternativa, puede comprobar si puede detectar vectores de ataque básicos como el robo de credenciales, el abuso de privilegios y la inyección de SQL. Pero lo más importante es que siempre sienta que tiene el control de su base de datos, no al revés. Siempre debe tener visibilidad de lo que sucede y una confianza razonable de que sabrá cuándo ocurre algo malo.

Mencionaste el control de actividad de la base de datos, ¿podrías darnos algunos ejemplos de cómo podemos combatir las amenazas que nombraste?

Tomemos como ejemplo las cuentas de DBA. Existen múltiples amenazas, ya sea por parte de actores externos que roban privilegios o por abuso interno de privilegios. Sin embargo, hay dos cosas que los DBA no suelen hacer: no modifican los datos de la base de datos y no deberían acceder a información confidencial.

Al alertar o bloquear este tipo de actividad, puede prevenir una vulneración que aproveche las cuentas de DBA. Esto funciona independientemente de quién las esté utilizando: un hacker externo o un empleado interno.

Si considera bloquearlas, también puede establecer una separación de funciones donde el personal de seguridad pueda permitir temporalmente que determinadas cuentas de DBA eludan estas medidas. Por ejemplo, si los DBA necesitan corregir datos ocasionalmente.

La cuestión es que si las cuentas de DBA no pueden modificar datos ni acceder a información confidencial, no pueden utilizarse en una vulneración de datos.

Esta parece una solución que sólo funciona para cuentas DBA, pero ¿qué pasa con las cuentas de la aplicación?

Para la cuenta de la aplicación, debe aplicar diferentes controles que la restrinjan a los comportamientos que normalmente exhibe.

El primer paso es limitar las conexiones al servidor y al programa de la aplicación. Debe alertar o bloquear las conexiones que no provengan del programa de la aplicación ni de sus direcciones IP. Restringir la cuenta de la aplicación al software de la aplicación evitará el robo de credenciales y el abuso de privilegios, ya que solo permitirá la conexión del software de la aplicación.

El segundo paso es alertar sobre una anomalía de SQL. Esto es un cambio en el perfil de comportamiento de la aplicación. Las aplicaciones siempre repiten las mismas SQL, y puede alertar cuando emiten una construcción SQL diferente. Esto detectará la explotación de un error de la aplicación, como un ataque de inyección SQL.

Los controles de la aplicación difieren de los controles de DBA, pero son igual de efectivos, ya que impiden que la cuenta haga cosas que no debería hacer.

Veo que hemos hablado de un par de ejemplos aislados, pero ¿por dónde recomendarías empezar? ¿Cuáles son los primeros pasos para proteger una base de datos y cómo se puede garantizar que se cubra todo?

Esa es una excelente pregunta. El primer paso es comprender la base de datos que estás protegiendo. Es imposible proteger algo si no sabes qué es ni quién hace qué dentro. Proteger algo es como resolver un rompecabezas: primero necesitas analizarlo bien y comprender a qué te enfrentas. Al menos así es como siempre empiezo.

Para ser más específico, necesitas identificar qué bases de datos contienen datos confidenciales y ubicarlos dentro de ellas. Después, necesitas comprender quién accede a esas bases de datos, qué programas utilizan y qué hacen dentro.

Como habrás notado, un enfoque es analizar las cuentas de la base de datos. Es un buen enfoque porque es fácil obtener una lista de todas las cuentas de la base de datos y dividirlas en grupos según el tipo de actividad que generan. Además, necesitas validar con tu solución de actividad de la base de datos que lo que crees que hacen estas cuentas es lo que realmente hacen.

Una vez que conozcas los tipos de cuenta y comprendas sus perfiles de actividad, puedes diseñar controles que alerten sobre cambios en ese perfil.

Veo que sugieres soluciones adaptadas a cada tipo de cuenta, pero ¿existen recomendaciones más genéricas? ¿Algo que no requiera analizar a fondo el perfil de actividad de cada cuenta?

Claro. Existen prácticas más sencillas que mejorarán la seguridad. De hecho, recomiendo combinarlas con el enfoque anterior para reforzar la seguridad. Daré tres ejemplos:

El control de cambios es un aspecto importante para garantizar la seguridad de la base de datos. Monitorear los DDL permite validar que todos los cambios en la base de datos formen parte de un control de cambios aprobado. El uso de instantáneas de metadatos es otro método complementario para garantizar la información sobre la configuración, los objetos, los usuarios, los roles, etc. de la base de datos.

Otro ejemplo es el control de sesiones. Por ejemplo, se pueden configurar alertas de anomalías para nuevos usuarios, usuarios activos en horarios irregulares, usuarios que se conectan desde programas o direcciones IP inusuales, etc. Este tipo de control ayuda a detectar ataques como el robo de credenciales.

Un control más potente es detectar anomalías en tablas sensibles. Debe saber si hay una nueva construcción SQL que afecte a una tabla sensible, o un nuevo usuario, dirección IP, etc. Si bien este tipo de control puede requerir ajustes para reducir los falsos positivos, es un control potente que combate la mayoría de las amenazas.

Parece que proteger cada base de datos es una tarea ardua. ¿Qué ocurre si las empresas tienen muchas bases de datos que necesitan proteger?

Excelente pregunta. Hay tres respuestas. La primera es priorizar. Empezar con las bases de datos más críticas y, con el tiempo, asegurar cada vez más sistemas. No me convence mucho este enfoque porque implica dejar muchos datos sin proteger. También significa que lo que no esté en la primera fase probablemente nunca se asegurará, ya que el enfoque se centrará en otras áreas.

Una segunda respuesta sugiere implementar medidas básicas en todas las bases de datos y una seguridad más completa en las críticas. Puede que nunca lleguemos a asegurar más bases de datos, pero al menos tenemos cierto control sobre todo. Los controles básicos ahorrarán dinero y tiempo, así que es un buen compromiso.

La mejor respuesta, en mi opinión, es que la seguridad de las bases de datos debe estar arraigada en el ADN de la organización. Necesitamos cambiar nuestra forma de operar porque, como mencioné antes, no tiene sentido almacenar datos sin protegerlos. Los datos inseguros no son fiables, lo que los hace inútiles y representan un riesgo en caso de robo.

Una vez que la seguridad de los datos se convierta en parte de nuestro ADN, seguir los pasos que mencioné para protegerlos formará parte de la creación y el mantenimiento de una base de datos. Sé que la mayoría de la gente solo lo ve como un futuro lejano, y definitivamente no es la realidad de la mayoría de las organizaciones hoy en día. Pero es algo a lo que debemos aspirar.

Hablando del futuro: ¿hacia dónde ves que van las cosas?

Podemos mirar tanto al futuro cercano como al lejano. La situación actual con las filtraciones de datos es insoportable. Existe una creciente presión por parte de clientes, legisladores, reguladores y otros. Esta presión seguirá aumentando mientras persistan las filtraciones de datos. Hasta ahora, las filtraciones van en aumento, por lo que es evidente que se dedicará más atención, enfoque y dinero a detenerlas.

Por otro lado, vemos empresas que lo han intentado todo, excepto lo que funciona. Gastaron una fortuna en proteger sus perímetros y toda la infraestructura, excepto la base de datos. Incluso intentaron delegar la responsabilidad a otras entidades mediante seguros o externalización, pero no funciona. El único camino que queda es la seguridad centrada en los datos. Sin embargo, sospecho que la industria de la seguridad encontrará inversiones más ineficaces antes de empezar a proteger sus datos.

La industria de la seguridad es un poco peculiar en su forma de seguir las tendencias y modas. Cada año, muchas empresas siguen la última tendencia. Esa no es la manera de lograr una buena seguridad, pero así es como se comporta el mercado. Lamentablemente, algunas de estas tendencias provocaron aún más filtraciones mediante ataques a la cadena de suministro.

El cambio solo llegará cuando empecemos a proteger los datos. Ya sea por una nueva tendencia o por otras fuerzas del mercado, no veo otra solución, y la presión seguirá aumentando hasta que eso suceda. Al mismo tiempo, la demanda de una solución ya es enorme, y parece que pronto tendremos que ceder. Nos estamos acercando cada vez más al punto de quiebre.

Una vez que las empresas se den cuenta de que el control de actividad moderno es la única forma de proteger las bases de datos y los datos que contienen, la industria de la seguridad experimentará un cambio radical.

¿De qué tipo de cambio estamos hablando?

Hay dos partes. Primero, veremos un cambio en la capacitación del personal de seguridad. Proteger una base de datos no es lo mismo que configurar un firewall o filtrar correos no deseados. El personal de seguridad necesitará comprender mejor las tecnologías de bases de datos y cómo protegerlas.

Creo que también veremos la integración de la seguridad en la compra e implementación de aplicaciones y bases de datos. Ya se ve un poco de eso, pero es solo el comienzo. Por ejemplo, preveo que la identificación de datos confidenciales será un paso obligatorio en todas las implementaciones. No habrá personal de seguridad que tenga que preocuparse después de cada implementación para averiguar qué datos hay dentro de la aplicación y la base de datos y dónde se almacenan.

¿Este cambio masivo se trata únicamente de capacitación, educación e incorporación de seguridad en la implementación de bases de datos y aplicaciones?

No, la visión a largo plazo es mucho más amplia. El control de la actividad de las bases de datos es solo la punta del iceberg. Hoy en día, la seguridad se basa en tres premisas falsas. Estas premisas limitan lo que creemos posible y lo que intentamos lograr.

Perímetro: Primero, está la obsesión por proteger el perímetro, pensando que si de alguna manera podemos mantener a raya a los cibercriminales, todo estará bien. Esta premisa ya se está desintegrando, pero la gente se aferra a ella porque no sabe qué más hacer. Necesitamos proteger el perímetro, pero ese no debería ser nuestro principal objetivo.

Prevención: Segundo, está la creencia de que la prevención es mejor y más importante que la detección. Es excelente prevenir, pero la prevención no puede ser lo suficientemente sensible como para bloquearlo todo. Existe un largo debate sobre los falsos positivos y los falsos negativos, con una conclusión simple: la detección es mucho más eficaz para identificar ataques y brechas, y debemos invertir más en ella. Los responsables de seguridad tendrán que aceptar que no podemos confiar en sistemas automatizados para bloquearlo todo y mantenernos seguros.

Volumen de datos: En tercer lugar, y más importante, está la idea de que no podemos gestionar una gran cantidad de datos y que ya recopilamos demasiados. La seguridad se trata de controlar la actividad, es decir, controlar lo que hacen las personas. Hay mucha actividad en los sistemas de información, y evitamos intentar recopilarla y controlarla toda. Una vez que aceptemos que es posible, todo el panorama de la seguridad se transformará. No tendremos que centrarnos solo en excepciones, alertas y eventos de seguridad. Lo controlaremos todo.

¿Será realmente posible? ¿Podremos controlar toda la actividad?

Ya lo estamos haciendo. Las tecnologías de Blue Core Research le permiten controlar toda la actividad de la base de datos. Está disponible ahora mismo. Las bases de datos son los sistemas más activos en el panorama de TI, y contamos con las tecnologías y metodologías para ayudarle a controlar toda su actividad.

También adaptamos estas tecnologías para ayudarle a proteger las cargas de trabajo de las aplicaciones Java y la actividad de los clientes web. Ese futuro ya está aquí.

Una vez que las personas comprendan que controlar la actividad es posible y que es la única manera de proteger los sistemas, toda la industria de la seguridad cambiará. Les daremos la vuelta a la tortilla a los atacantes y estaremos en el lado ganador de este juego del gato y el ratón.

Gracias por tu tiempo y tu visión optimista del futuro. Espero que ganemos esta guerra y detengamos esta plaga de ciberataques y filtraciones de datos. ¿Tenes alguna reflexión final que quieras compartir?

Las personas deben empezar a comprender que la seguridad de la información consiste en protegerla. Sí, podemos proteger la red, el correo electrónico, etc., pero debemos empezar por proteger la información. Si no se controla la actividad que accede a los datos, nunca se logrará protegerlos.