Solución al Robo de Datos y Protección de la Privacidad

Solución al Robo de Datos y Protección de la Privacidad

El robo de datos es un problema persistente y costoso que se ha normalizado. Este artículo propone una solución eficaz al enfocarse en proteger las bases de datos desde el interior, más allá de la seguridad perimetral. La estrategia se centra en el control de actividad para asegurar la información confidencial, incluso si un intruso logra acceder al sistema.

Introducción

Las filtraciones de datos son algo habitual. A la mayoría de las personas les robaron sus correos electrónicos o números de teléfono. Debería ser una realidad impactante, pero la magnitud del problema y las frecuentes filtraciones lo han normalizado, convirtiéndolo en algo que todos aceptan y, en su mayoría, ignoran.

El robo de datos sigue siendo uno de los problemas más persistentes y perjudiciales en la seguridad de la información. Las organizaciones almacenan grandes cantidades de información confidencial, y el volumen sigue creciendo. El potencial de una filtración de datos catastrófica nunca ha sido tan alto.

Existen importantes incentivos financieros para los actores de amenazas, tanto internos como externos, y los resultados hablan por sí solos. Se proyecta que el cibercrimen le costará al mundo 23 billones de dólares para 2027, y el costo promedio de una filtración de datos en 2024 fue de casi 5 millones de dólares. Son cifras alarmantes y, de alguna manera, todos piensan que no les sucederá. Sin embargo, le sucede a alguien constantemente. No pasa una semana sin que se produzca una nueva filtración escandalosa.

Por insuperable que parezca este problema, en realidad no lo es. Solo se necesita un enfoque diferente. La solución más eficaz, y a menudo pasada por alto, reside en proteger los propios datos. Esto implica asegurar las bases de datos que los contienen. Si se protegen los datos, un hacker que penetre en la red corporativa o un empleado interno que viole la confianza no provocará una filtración de datos. La seguridad perimetral impide el acceso de las personas, mientras que la seguridad de las bases de datos controla lo que hacen una vez dentro. Este artículo explica cómo implementar este tipo de seguridad.

Cumplimiento Normativo

El robo de datos no se trata solo de dinero. Se trata de la privacidad, los datos personales, el robo de identidad y mucho más. Estas violaciones perjudican a las personas, erosionan la confianza de los clientes y dañan su reputación.

Es un problema grave para la mayoría de las empresas y las numerosas personas que trabajan con ellas. Como resultado, los gobiernos y los organismos reguladores intervienen. Esto significa que ahora tenemos una presión más para proteger la información: el cumplimiento normativo. Ya no se trata solo de proteger nuestros negocios y hacer lo correcto: es la ley.

Privacidad

Las regulaciones de privacidad tienen múltiples facetas. Además de las restricciones sobre cómo las empresas pueden usar nuestros datos personales, un aspecto fundamental de las leyes de privacidad es mitigar el riesgo de robo de datos. El RGPD (Reglamento General de Protección de Datos) de la Unión Europea es probablemente la regulación de privacidad más conocida. Sin embargo, en los últimos años, la mayoría de los países y estados han promulgado leyes de protección de la privacidad.

Si bien cada ley regula a diferentes entidades y establece restricciones distintas, en lo que respecta a la seguridad de los datos, los objetivos son prácticamente idénticos.

Datos Financieros, Historiales Médicos, Datos Corporativos y Más

El robo de datos representa un riesgo para muchas categorías de información. Hay muchos datos que esperamos que se mantengan confidenciales, y confiamos en que así sea. Las leyes y regulaciones en la mayoría de los países ya cubren datos personales, como información financiera, historiales médicos y números de tarjetas de crédito. En lo que respecta a los datos corporativos y la propiedad intelectual, estos son fundamentales para el negocio, y las empresas ya están incentivadas a protegerlos.

Si personas no autorizadas o el público en general accedieran a cualquiera de estos océanos de datos, se produciría un daño significativo para la persona o empresa cuyos datos se divulgaron.

Los hackers también evolucionan, descubriendo formas más creativas de explotar nuestra dependencia de la información. El ransomware es la estrategia más reciente para extorsionarnos negándonos el acceso a nuestros datos. Para aumentar la presión para pagar el rescate, los hackers utilizan una doble extorsión: también roban los datos y amenazan con exponerlos. Por lo tanto, el ransomware y el robo de datos están estrechamente vinculados.

Hoy en día, pocas personas en el mundo necesitan que se les convenza de la plaga que representa el robo de datos y de la urgente necesidad de detenerlo. La cuestión, entonces, no es si actuar o no, sino cómo construir una defensa sólida que proteja los datos.

Bases de datos: La frontera de seguridad más eficaz y desafiante

La seguridad perimetral busca evitar que agentes maliciosos accedan a la red corporativa, mientras que la seguridad de las bases de datos controla el acceso a los datos y la información que sale. Por lo tanto, las bases de datos son el lugar perfecto para identificar el robo de datos. Ninguna otra capa en la pila tecnológica es capaz de identificar con facilidad y precisión qué información sale y cuánta.

Sin embargo, esto conlleva un desafío importante: TODA la información pasa por la base de datos. No se trata solo de información sensible, y es para cualquier propósito posible. Esto implica miles de millones de consultas y volúmenes masivos de información que alimentan a cada consumidor de datos en cualquier parte de la empresa.

Esto presenta un doble desafío: capturar toda esa actividad sin afectar el rendimiento e identificar la actividad maliciosa en este mar de consultas. Si logramos esto eficazmente, protegeremos nuestros datos. Esa es la clave de la seguridad de los datos.

Tecnologías

Antes de entrar en detalles de implementación, analicemos brevemente las tecnologías necesarias para proteger la base de datos. Estas tecnologías se dividen en dos categorías principales: captura y procesamiento.

Captura

Capturar la actividad implica generar un flujo de auditoría que incluya toda la actividad. En esencia, se trata de “ver” todo lo que ocurre en la base de datos. Esto supone un reto especial para el robo de datos, ya que la mayor parte de la actividad de la base de datos se compone de consultas (las SQL que extraen datos, y existen miles de millones). El reto con tantas SQL es que capturarlas puede afectar al rendimiento de la base de datos. Una solución parcial es capturar un pequeño subconjunto de esas SQL, lo que genera una visibilidad insuficiente. Otro reto de visibilidad es la actividad dentro del servidor de la base de datos y la actividad interna en la base de datos.

Existen tres tecnologías de captura principales en el mercado de la seguridad de bases de datos:

  • La auditoría nativa aprovecha las capacidades integradas de la base de datos. Las soluciones que se basan en ella son más económicas, pero tienen una visibilidad limitada y un alto impacto en el rendimiento de la base de datos.
  • Las soluciones de captura de red pueden verlo todo con una sobrecarga mínima. Requieren un agente para capturar la actividad local y no pueden capturar la actividad interna de la base de datos. También pueden presentar problemas con las conexiones cifradas.
  • La captura completa (Full Capture) es una tecnología que se conecta directamente al motor de la base de datos. Puede verlo todo con un impacto mínimo en el rendimiento. Es lo mejor de ambos mundos: le ofrece una visibilidad superior con menos del 3 % de altura.
Auditoría NativaCaptura de RedCaptura Total
Sobrecarga del RendimientoPobreAlto impacto en la redMenos del 3 % de CPU
Bajo impacto en la red
VisibilidadLimitada debido a la sobrecarga del rendimientoActividad remota y localVisibilidad completa (remota, local, cifrada, interna)
PrecioBajoAltoMedio

Procesamiento

Una vez que se cuenta con un flujo de auditoría, es necesario aprovecharlo. Es necesario, de alguna manera, aumentar la seguridad. Recuerde que hablamos de miles de millones de SQL. La solución es dividir y vencer: utilizar diferentes enfoques para los distintos subconjuntos del flujo de actividad.

Las distintas soluciones del mercado ofrecen distintas capacidades, pero una solución integral debe ofrecer una combinación de métodos cuyas capacidades combinadas aborden toda la actividad de la base de datos.

Los enfoques de procesamiento se dividen en cuatro categorías principales. Primero, explicaremos qué son y, posteriormente, cómo combinarlos para construir una defensa adecuada.

  • Políticas, Informes, Alertas. Estas funciones permiten registrar subconjuntos específicos de la actividad, generar informes y enviar alertas. Este tipo de auditoría se denomina auditoría declarativa: se le indica a la solución qué actividad registrar y qué incluir en los informes y alertas. Estas medidas son excelentes para controlar actividades de alto riesgo y bajo volumen, como las de los administradores.
  • Análisis de Anomalías. Estas funciones analizan el perfil de actividad para detectar comportamientos inusuales. Pueden gestionar cualquier volumen de actividad y su objetivo es identificar actividades sospechosas dentro del flujo. Las anomalías pueden ser un nuevo SQL, un nuevo usuario, una máquina diferente, una hora inusual, un mayor volumen de actividad, etc. Se trata de encontrar una aguja en un pajar y funciona especialmente bien con la actividad repetitiva. El perfil de actividad de la aplicación es repetitivo, y las anomalías pueden identificar ataques dirigidos a vulnerabilidades de la aplicación, como inyecciones de SQL.
  • Análisis Forense Proactivo. Estas funciones buscan brindar al personal de seguridad visibilidad sobre lo que sucede en la base de datos. Le permite investigar el 100% de la actividad pasada de la base de datos para comprender el comportamiento de individuos, programas y más. Esta visibilidad puede servir como un control independiente o como un medio para planificar otros controles e identificar sus deficiencias.
  • Bloqueo avanzado. Estas funciones están diseñadas para prevenir actividades no deseadas. Amplían las medidas de seguridad integradas de la base de datos al analizar cada SQL en cada conexión. Si bien la prevención es una herramienta poderosa, úsela con precaución. Puede bloquear la actividad legítima, causando interrupciones del servicio y quejas de los usuarios.

Con Core Audit, todas estas capacidades están integradas en la solución, lo que le permite lograr más con una interfaz fácil de usar.

Diseño de la Seguridad

El control de actividad es la medida de seguridad más eficaz en las bases de datos. Algunos podrían decir que es la única seguridad eficaz. Sin embargo, diseñar un plan de seguridad para el control de actividad no es trivial. No se puede pulsar un botón y todo está protegido. Esta sección ofrece una guía inicial sobre los pasos necesarios para crear un plan de control de actividad.

Paso 1: Visibilidad

Puede parecer un paso obvio, pero la mayoría de las personas lo pasan por alto. Debe obtener visibilidad del perfil de actividad de la base de datos. Necesita saber quién accede a su base de datos, desde dónde, cuándo y qué hace en ella. Comprender el perfil de actividad que desea proteger es esencial para protegerlo. No se puede proteger lo que no se puede ver ni comprender.

En soluciones como Core Audit, esto forma parte del Análisis Forense Proactivo. El Análisis Forense Proactivo es un conjunto de herramientas de visualización y análisis gráfico que le ayudan a comprender las fuentes de actividad y su función, el volumen de actividad a lo largo del tiempo y la relación entre múltiples dimensiones.

Paso 2: Clasificación de Cuentas y Riesgos

Existen muchas maneras de diseñar un plan de control de actividades. Se pueden diseñar controles para cada riesgo, subdividir la actividad en diferentes dimensiones, etc. Descubrimos que el enfoque más sencillo se basa en las cuentas.

Las cuentas en la base de datos suelen clasificarse en categorías como administradores de bases de datos (DBA), la aplicación, analistas, etc. El perfil de actividad de cada tipo de cuenta suele tener características únicas y una lista de riesgos distinta. Con estas características, podemos diseñar un plan específico para cada tipo de cuenta. Lo explicaremos más adelante, pero primero debemos clasificar las cuentas e identificar los riesgos.

Estos son los pasos:

  • Agrupe las cuentas según su tipo. Por ejemplo: DBA, Aplicación, Conexión local, Analistas.
  • Considere rutas de actividad inusuales, como conexiones locales y nuevas cuentas.
  • Determine los riesgos para cada tipo de cuenta. Debe considerar cómo el usuario objetivo puede abusar de sus privilegios y cómo un hacker externo puede penetrarla. Una brecha externa podría ocurrir, por ejemplo, mediante el robo de credenciales. Las cuentas utilizadas por la aplicación también podrían ser explotadas mediante una vulnerabilidad, como una inyección SQL.

Por ejemplo, estos son tres tipos de cuenta estándar que existen en todas las bases de datos:

  • DBA. Una categoría que incluye cuentas de DBA individuales y cuentas con privilegios compartidos, como SYS, SYSTEM o SA. Esta categoría está sujeta a riesgos como el abuso de privilegios, el robo de credenciales y la vulneración de escritorios.
  • Aplicación. Un tipo de cuenta que incluye una o más cuentas de aplicación. Está sujeta a riesgos como el abuso de privilegios (por ejemplo, por parte de un administrador de aplicaciones), el robo de credenciales y vulnerabilidades (por ejemplo, la inyección SQL).
  • Conexión local. En la mayoría de las bases de datos, existe al menos una cuenta del sistema operativo que puede conectarse a la base de datos sin contraseña. Por lo tanto, vulnerar la cuenta del sistema operativo del servidor otorga al atacante acceso a la base de datos. Los riesgos incluyen el abuso de privilegios y una cuenta del sistema operativo vulnerada.

Después de identificar nuestros grupos de cuentas y sus riesgos, comencemos a configurar los controles para cada uno.

Paso 3: Controles de Sesión

Los controles de sesión proporcionan protección según la información de conexión. Por ejemplo, la cuenta, el programa que se conecta y la dirección IP de origen. Estos son los controles más sencillos que se pueden implementar y son fáciles de entender.

Los controles de sesión son como juzgar un libro por su portada. Es la perspectiva más simple la que puede ofrecer mucha información, pero no se compara con mirar dentro. Son rápidos y fáciles de entender, y pueden ser suficientes para algunos vectores de ataque, pero no para todos.

Los controles de sesión se engloban en los mismos cuatro enfoques mencionados anteriormente:

  • Informes y alertas: Estos informes muestran las conexiones a la base de datos. Por ejemplo, quién se conectó a las cuentas de administrador de base de datos (DBA), desde dónde y cuántas veces. También pueden alertarle cuando la cuenta de la aplicación tiene una conexión que no proviene del programa ni del equipo de la aplicación.
  • Análisis de anomalías: Una anomalía puede alertarle cuando las conexiones provienen de orígenes inusuales. Por ejemplo, cuando un DBA se conecta desde un programa o una dirección IP inusuales. También puede enviar una alerta cuando una nueva cuenta, un nuevo programa, una combinación diferente de programa e IP, etc., se conecta a la base de datos.
  • Análisis forense proactivo: Al igual que obtuvo visibilidad de la actividad de la base de datos en el paso 1, puede optar por utilizar este método como control continuo. Al evaluar periódicamente quién se conecta y desde dónde, puede detectar comportamientos sospechosos e identificar deficiencias en sus controles existentes.
  • Preventivo: Puede bloquear la actividad de las conexiones que no cumplen con los requisitos específicos. Por ejemplo, puede permitir la actividad en la cuenta de la aplicación solo cuando se origina desde el servidor y el equipo de la aplicación.

Los controles de sesión suelen dirigirse a grupos de cuentas específicos, como administradores de bases de datos (DBA) o la aplicación. Sin embargo, también pueden ser globales, como alertar sobre nuevas cuentas o realizar una investigación forense proactiva.

Los controles de sesión suelen ser eficaces contra diversas formas de robo de credenciales, ya que explotarlas suele implicar conectarse desde una máquina o programa diferente. Sin embargo, son completamente ineficaces contra el abuso de privilegios o las vulnerabilidades de la aplicación, ya que este tipo de actividad proviene de fuentes válidas.

Paso 4: Controles SQL

Los controles SQL o de actividad ofrecen protección según la actividad dentro de la conexión. Por ejemplo, el nombre de una tabla dentro del SQL o el comando SQL (p. ej., Crear, Modificar, Eliminar, Insertar, Actualizar, Eliminar, Seleccionar).

Los controles de actividad son más complejos y requieren cierta comprensión de la actividad de la base de datos. Es importante comprender no solo lo que se está analizando, sino también cómo un adversario podría intentar lograr sus objetivos. En otras palabras, comprender cómo trabajan las personas en un entorno de bases de datos.

Los controles SQL son eficaces contra casi cualquier riesgo; solo es cuestión de saber qué buscar.

Es lo opuesto a juzgar un libro por su portada. Es como abrir un libro y mirar en su interior. Hay muchísima información y mucho que ver. De hecho, hay demasiada información, y es muy poco probable que pueda inspeccionarlo todo usted mismo. Sin embargo, si sabe lo que busca, puede encontrarlo basándose en las características que pueda presentar.

Los controles SQL se dividen en los mismos cuatro enfoques:

  • Informes y alertas: Estos informes muestran una actividad específica, como un informe DDL para validar el control de cambios. También pueden alertarle cuando el administrador de base de datos (DBA) toca una tabla sensible.
  • Análisis de anomalías: Una anomalía puede alertarle cuando se produce un cambio en el perfil de actividad de la base de datos. Por ejemplo, cuando la aplicación tiene una nueva construcción SQL que podría ser una inyección SQL. También puede alertar si una cuenta inusual accede a una tabla sensible o si se produce actividad en un momento inusual del día.
  • Análisis forense proactivo: Obtener visibilidad de la actividad de la base de datos puede ser un potente control continuo. Al evaluar periódicamente quién accede a datos sensibles, a cuántos datos se accede y cuándo, puede detectar comportamientos sospechosos e identificar deficiencias en sus controles existentes.
  • Preventivo: Puede bloquear la actividad que no se ajuste a sus expectativas. Por ejemplo, puede impedir que los DBA accedan a datos sensibles. También puede implementar la separación de funciones exigiendo a los DBA que obtengan códigos de amnistía antes de realizar actividades restringidas.

La mayoría de los controles SQL son específicos de tipos de cuenta concretos (p. ej., administradores de bases de datos o aplicaciones), pero en algunos casos pueden utilizarse globalmente, como en un informe DDL.

Estos controles son muy eficaces contra la mayoría de los riesgos. Funcionan tanto para actividades de alto riesgo como las de los administradores de bases de datos, como para actividades de gran volumen, como las aplicaciones que gestionan miles de millones de SQL. Este es un control indispensable para proteger la actividad cuando el origen de la misma parece legítimo (p. ej., un abuso de privilegios o una vulnerabilidad de la aplicación), y funciona igual de bien para actividades que probablemente tengan un origen diferente (p. ej., el robo de credenciales).

Controles Recomendados sobre el Robo de Datos

Toda organización debería diseñar controles específicos para su entorno. Sin embargo, muchas organizaciones utilizan algunos controles comunes. Analicemos estos controles y expliquemos por qué funcionan:

  • Uso de cuentas de DBA (informe de sesión) o Anomalía de sesión de DBA. Este informe resume las conexiones a cuentas de DBA y con privilegios. También puede configurarlo como una alerta de anomalía que solo resalta los cambios en las fuentes de actividad. Este es un control importante contra el robo de credenciales de DBA, ya que detecta cuándo las conexiones de DBA provienen de fuentes inusuales o son sospechosas.
  • Informe de acceso a datos confidenciales de DBA. Este informe enumera la actividad SQL de DBA que accede al esquema de datos o a las tablas de datos confidenciales. Las cuentas de DBA no suelen acceder a datos confidenciales. Es un control sólido, ya que si las conexiones de DBA no acceden a datos confidenciales, significa que no se han utilizado para el robo de datos. Es eficaz contra el abuso de privilegios de DBA, así como contra diversas suplantaciones de identidad de DBA (incluido el robo de credenciales).
  • Anomalía de sesión de aplicación. Esta alerta le informa cuando la actividad de la aplicación proviene de una máquina que no es el servidor de aplicaciones o de un programa que no es la cuenta de la aplicación. Este es un control vital para combatir el robo de credenciales de aplicación y el abuso de la cuenta de aplicación. En ambos casos, las conexiones se originan en programas distintos del software de la aplicación.
  • Anomalía de SQL de la aplicación. Este es un control crítico contra la inyección de SQL y muchos otros tipos de vulnerabilidades de la aplicación. La actividad de la aplicación siempre es repetitiva, incluso para aplicaciones que generan SQL dinámico. Esta alerta le informará cuando cambie el perfil de actividad de la aplicación.
  • Informe DDL. Los DDL son cambios en los metadatos de la base de datos. Si bien no constituyen un robo de datos en sí mismos, los DDL pueden utilizarse para comprometer la seguridad. DCL es una subcategoría de los DDL que gestiona usuarios y permisos, mientras que otros DDL gestionan tablas, procedimientos, desencadenadores y más. Un informe DDL es un control fundamental para cerrar el ciclo y complementar el proceso de control de cambios.
  • Anomalía de nuevo usuario y Anomalía de nuevo programa. Estas alertas de nuevas fuentes de actividad son importantes para controlar la superficie de ataque y mantenerle al tanto de cambios fundamentales en el perfil de actividad de la base de datos que requerirán el ajuste de sus controles. Por ejemplo, si un nuevo usuario se conecta a la base de datos, es algo que debe saber. Probablemente también necesite ajustar uno de los controles para supervisar a este nuevo usuario.
  • Diagrama de dispersión o Anomalía de la relación filas/SQL. Estas prácticas inspeccionan básicamente el promedio de filas por SQL. El robo de datos muestra grandes extracciones que aumentan significativamente esta relación. Observar los diagramas de dispersión o el análisis de relaciones identifica rápidamente posibles extracciones. Por ejemplo, si una determinada combinación de usuario, programa e IP tiene una relación filas/SQL mucho mayor o si dicha relación cambia drásticamente, probablemente significa que esta conexión se utilizó para volcar una tabla.

Hay muchos más controles que puedes implementar, pero estos proporcionan una cobertura buena y amplia para la mayoría de las bases de datos contra la mayoría de las amenazas.

Revisión de controles

Aquí se muestra la correlación entre las amenazas y los controles recomendados. Simplemente revisamos las amenazas detectadas en el paso 2 (y añadimos algunas más):

  • Riesgos para el administrador de bases de datos (DBA):
    • Abuso de privilegios. El informe de acceso a datos confidenciales del DBA revelará cualquier acceso malicioso por parte de los DBA. El informe DDL también es fundamental para garantizar que todos los cambios sean aprobados por el proceso de control de cambios y que los DBA no abusen de los DDL para obtener acceso. Para lograr un control más estricto, también puede implementar medidas preventivas que, por ejemplo, impidan el acceso del DBA a datos confidenciales y establezcan una separación de funciones.
    • Robo de credenciales. Una anomalía en la sesión del DBA le alertará cuando se utilicen las credenciales del DBA desde una máquina o programa inusual. El informe de acceso a datos confidenciales del DBA también le informará si la cuenta se utiliza para actividades maliciosas. Los controles preventivos más estrictos, como el bloqueo del acceso o la separación de funciones, también son eficaces.
    • Escritorio comprometido. Un escritorio de DBA comprometido es idéntico, desde la perspectiva de la base de datos, a un abuso de privilegios y se beneficia de los mismos controles.
  • Riesgos de la Aplicación:
    • Abuso de privilegios. La alerta de anomalía de sesión de la aplicación detectará un abuso de privilegios, ya que dicho abuso se originará en un programa diferente y probablemente también en una máquina distinta. Si los administradores utilizan la cuenta de la aplicación con frecuencia, la anomalía de SQL de la aplicación alertará sobre un comportamiento inusual. Sin embargo, si los administradores utilizan esta cuenta con frecuencia, se recomienda implementar también las medidas de DBA en esas sesiones específicas.
    • Robo de credenciales. El robo de credenciales de la aplicación se manifiesta de forma similar al abuso de privilegios y puede detectarse con las mismas medidas.
    • Vulnerabilidad (p. ej., inyección SQL). La anomalía de SQL de la aplicación detectará una vulnerabilidad de la aplicación. Esta anomalía detectará cualquier cambio en el perfil de actividad de la aplicación, y una vulnerabilidad explotada, inevitablemente, cambiará dicho perfil. Para un control más estricto, también puede realizar investigaciones forenses o configurar anomalías en los volúmenes de actividad. Puede supervisar el número de SQL o el número de filas procesadas.
  • Riesgos de Conexión Local:
    • Abuso de privilegios. En conexiones locales, esto constituye un abuso por parte de los administradores de bases de datos (DBA) y se identificará de la misma manera que otros abusos de privilegios por parte de DBA.
    • Cuenta del sistema operativo vulnerada. En la mayoría de las bases de datos, los DBA utilizan las cuentas del sistema operativo local con regularidad, pero con poca frecuencia. Puede configurar una alerta de inicio de sesión si la cuenta se utiliza con poca frecuencia. Dado que esta cuenta suele ejecutar las mismas SQL, una alerta de SQL anómala sería eficaz. En todos los casos, los controles del DBA, como el informe de acceso a datos confidenciales, detectarían el ataque.

Para que sea eficaz, deberá ajustar los controles a su entorno. Por ejemplo, si la aplicación utiliza una cuenta privilegiada como “SA”, los controles deben distinguir entre el acceso de DBA y el acceso a la aplicación (normalmente según el programa o la máquina). Se recomienda encarecidamente que las aplicaciones utilicen una cuenta dedicada con privilegios mínimos. Sin embargo, este tipo de cambio puede ser difícil y requerir mucho tiempo de implementación. Otro ejemplo de ajuste es que los informes DDL a menudo deben excluir tablas temporales o actividades comunes similares que pueda tener en su entorno.

Puede observar que las recomendaciones de control incluían una anomalía de nuevo usuario y un diagrama de dispersión que no se asignaron a los riesgos. La anomalía de nuevo usuario se asigna al riesgo de una nueva cuenta en la base de datos. Parte de ese riesgo proviene de que un DBA cree una nueva cuenta para robar datos. Sin embargo, la mayor parte del riesgo reside en no ajustar los controles de seguridad cuando hay un nuevo usuario. El control del diagrama de dispersión es más global y tiene como objetivo identificar grandes extracciones de datos de la base de datos, independientemente de cualquier riesgo específico.

DBAAplicaciónLocal
Abuso de PrivilegiosRobo de CredencialesEscritorio comprometidoAbuso de PrivilegiosRobo de CredencialesVulnerabilidadAbuso de PrivilegiosCuent OS
Uso de la cuenta DBA
Anomalía en la sesión DBA
X
Acceso a datos confidenciales
del DBA
XXXXX
Anomalía en la sesión
de la aplicación
XX
Anomalía de SQL de
la aplicación
XXX
Informe DDLpart.part.part.part.part.part.part.part.
Anomalía de nuevo usuario
Anomalía de nuevo programa
part.part.part.part.part.part.part.part.
Diagrama de dispersión
Anomalía en la relación filas/SQL
XXXXXXX

Conclusión

Hay dos cosas que debe reconocer: primero, proteger la base de datos es importante. segundo, es posible. Este artículo pretende demostrar estos hechos.

En el pasado, las tecnologías de seguridad de bases de datos eran mucho menos efectivas. Nuestra incapacidad para defenderlas hizo que la mentalidad de seguridad pasara de centrarse en lo obvio a centrarse en las herramientas disponibles que aportaban valor.

La tecnología de seguridad de bases de datos ha cambiado drásticamente en los últimos 25 años. Las tecnologías modernas son mucho más efectivas tanto para capturar como para analizar los datos. Al mismo tiempo, los atacantes encontraron formas nuevas y efectivas de penetrar el perímetro, lo que limita la eficacia de esas defensas. La ineficacia del perímetro acentúa aún más la necesidad ineludible de proteger la base de datos.

Detectar y prevenir el robo de datos a nivel de base de datos no solo es posible, sino que es un paso crucial en la seguridad. Si bien requiere un poco de trabajo y conocimientos técnicos, las tecnologías modernas lo convierten en la medida más eficaz para identificar un ataque y responder a él.

Siga los vectores de ataque que llevan a los atacantes a los datos. Un control eficaz de la actividad que accede a los datos le permite detectar, prevenir y responder ante una filtración de datos en caso de que ocurra. Una vez que aborde estas diferentes amenazas, combatirá con éxito el riesgo de robo de datos.

La base de datos es el único punto que controla todos los accesos a los datos. No hay otro punto igual. No hay alternativa a las soluciones avanzadas de seguridad de bases de datos. La base de datos es la última y más poderosa línea de defensa en la batalla contra el flagelo del robo de datos.

A medida que avanzamos hacia el futuro utilizando la nube y el teletrabajo, el perímetro se desintegrará por completo. Controlar los datos es el único camino a seguir.

¿Listo para ir más allá de la seguridad perimetral y construir una defensa adecuada para sus datos? Contáctenos para aprender a construir una seguridad robusta de bases de datos con Core Audit.

Si tenes alguna pregunta o comentario, no dude en hacérnoslo saber. Estaremos encantados de escucharle.

Matriz de Control de Riesgos

Matriz de Control de Riesgos

Las defensas en serie superpuestas pueden reducir significativamente la posibilidad de un ataque exitoso. Ese es un paso crítico para evitar una brecha de datos.

Anteriormente hablamos sobre la seguridad centrada en los datos y la necesidad de contar con defensas herméticas. El uso de IDS e IPS es un primer paso en esa dirección, pero vamos a ir más allá creando controles superpuestos que reforzarán aún más la seguridad.

La matriz de control de riesgos es el núcleo de la planificación de la seguridad. La matriz asigna nuestros riesgos a los controles que planeamos aplicar. No es un concepto revolucionario, pero llevarlo a la práctica puede resultar complicado. Para que el debate sea menos teórico y más práctico, tomaremos un ejemplo real de la seguridad de las bases de datos y utilizaremos la matriz de control de riesgos de auditoría básica.

Riesgos

Enumerar los riesgos es el primer paso para crear una matriz. Para asegurarnos de que cubrimos todos los riesgos y facilitar su asignación a los controles, hemos optado por hacerlo por cuenta de base de datos.

Las bases de datos suelen tener cuentas para los administradores de bases de datos, la aplicación y otros. Al enumerar todas las cuentas de la base de datos, nos aseguramos de que no hay ningún hueco en el lado de los riesgos de la matriz.

También hay riesgos fuera de nuestra lista de cuentas. Por ejemplo, las nuevas cuentas, las vulnerabilidades de la base de datos que no requieren cuentas, el acceso a la base de datos desde dentro de la máquina de la base de datos y los datos copiados fuera de la base de datos.

A continuación, debemos determinar los posibles exploits para cada cuenta. Por lo general, cualquier cuenta, incluidas las cuentas DBA, puede ser explotada por sus propietarios (un abuso de privilegios), un hacker que utilice credenciales robadas o alguna otra suplantación de identidad, como comprometer el escritorio del propietario de la cuenta.

Las cuentas de aplicaciones tienen factores de riesgo adicionales. El principal es una vulnerabilidad en la aplicación. Por ejemplo, un ataque de inyección SQL engañará a la aplicación para que ejecute un SQL que no debe ejecutar. Otro riesgo es un cambio no aprobado que se salió del proceso de control de cambios.

La ventaja añadida de enumerar los riesgos por tipo de cuenta es que así es también como los controlamos. Desde la perspectiva de la base de datos, una sesión DBA es una sesión DBA. La base de datos no puede distinguir entre el DBA real y una suplantación de identidad exitosa. En ese sentido, hay poca diferencia entre un abuso de privilegios por parte del DBA y una suplantación de identidad: en ambos casos, la cuenta DBA ejecutó una actividad maliciosa.

Controles

Cada riesgo debe tener controles correspondientes. El truco para lograr una seguridad más estricta es tener múltiples controles que se superpongan. Veamos algunos ejemplos:

El primer nivel en Core Audit consiste en identificar cambios en la configuración, los usuarios, los permisos, los objetos, etc. Además de validar el control de cambios, este tipo de control identificará algunos efectos secundarios de los ataques. Por ejemplo, si un hacker crea un usuario para una puerta trasera, crea una tabla para extraer datos, etc.

Obviamente, eso no es suficiente, y en el nivel 2 podemos crear informes y alertas sobre sesiones y SQL específicos. Estos controles son eficaces para actividades de bajo volumen. Desde la perspectiva de la supervisión de cuentas DBA, podríamos supervisar los DML, los DDL y el acceso a tablas confidenciales. Si nos fijamos en la cuenta de la aplicación, podemos comprobar si hay sesiones que se originan fuera del servidor de la aplicación. Es mejor dejar los informes sobre otras actividades de la aplicación para el nivel 3, ya que su volumen es demasiado alto para que sean eficaces en el nivel 2. Estos controles no detectarán todos los ataques, pero son un buen comienzo.

En el nivel 3, tenemos el Análisis de anomalías, que identifica cambios en el perfil de actividad conductual. Se trata de una automatización que puede escalarse a volúmenes de actividad extremadamente altos. Esto lo convierte en un control potente y eficaz sobre la actividad de las aplicaciones, ya que tiende a ser repetitiva. También puede eliminar las consultas SQL repetitivas de los administradores de bases de datos y señalar las nuevas. Otro uso es el análisis de las fuentes de actividad para identificar a las personas que se conectan desde diferentes máquinas, programas, en momentos inusuales y mucho más.

Otra capacidad del nivel 3 es el análisis forense proactivo, que ofrece al personal de seguridad visibilidad sobre quién está haciendo qué en la base de datos. El personal puede investigar las fuentes de actividad, la cantidad de datos a los que se accede, la relación entre las sentencias SQL y las filas, y mucho más.

Y eso nos lleva al nivel 4, que es preventivo. Aquí debemos tener cuidado de no bloquear actividades legítimas. Esos son los falsos positivos que son problemáticos en IPS. Pero aún así podemos bloquear ciertas actividades, como el acceso de los administradores de bases de datos a esquemas confidenciales, el acceso a una tabla confidencial desde fuera de la aplicación, la aplicación de la separación de funciones y mucho más.

Controles superpuestos

Como puede ver, cada columna de riesgos tiene muchos controles potenciales, cada uno de los cuales aborda un aspecto diferente de los riesgos. Podemos tener múltiples informes y alertas que aborden la misma amenaza desde una perspectiva diferente. También podemos tener controles preventivos y detectivos calibrados con diferentes sensibilidades.

También utilizamos cinco tipos diferentes de controles: Nivel 1, auditoría declarativa (Nivel 2), análisis de anomalías (Nivel 3), análisis forense proactivo (Nivel 3) y preventivo (Nivel 4). Cada tipo tiene diferentes fortalezas y debilidades, como la inversión de tiempo, la participación del personal de seguridad, la visibilidad, la prevención o la detección, entre otras.

Estas superposiciones son las que hacen que este tipo de seguridad sea mucho más estricta. Aunque probablemente no implementará demasiados informes y alertas, puede planificar su implementación en función de la tasa de falsos positivos y del tiempo que pueda dedicar a esta seguridad.

Aplicaciones

Y también podemos ir más allá e implementar defensas similares en la aplicación. Se trata de controles de actividad de la aplicación independientes de los controles de la base de datos que se describen en este artículo. Auditoría declarativa, análisis de anomalías, análisis forense proactivo y mucho más: todo ello funciona en los perfiles de actividad de la aplicación.

Al añadir controles adicionales sobre la aplicación, reduciremos aún más el riesgo de vulnerabilidad de la misma. Esto añadirá barreras adicionales entre el atacante y los datos.

Si desea obtener más información, póngase en contacto con nosotros en info@bluecoreresearch.com/esnew

Haz una Pregunta

Si tienes una pregunta o coentario, por favor hazlo saber. Estaremos felices de escuchar de ti.

Por Qué el Argumento de “no es tan sensible” Se Desmorona Bajo Escrutinio

Por Qué el Argumento de “no es tan sensible” Se Desmorona Bajo Escrutinio

Todos los datos requieren protección. Es una verdad que a menudo ignoramos, socavando así nuestra dependencia de la información. No aceptar esta realidad destruye los cimientos de todas nuestras decisiones y acciones.

Introducción

Seamos francos: la mentalidad de que «nuestros datos no son tan sensibles» es una falacia peligrosa. Es un punto ciego que deja a las organizaciones vulnerables y socava el propósito mismo de recopilar y almacenar información en primer lugar. Necesitamos cambiar el paradigma.

Todos los datos son sensibles. No se trata solo de números de la Seguridad Social, tarjetas de crédito e historiales médicos, sino de la savia vital de la propia organización. Como profesionales de la seguridad, no solo debemos comprenderlo intelectualmente, sino también interiorizarlo y defender esta perspectiva dentro de nuestras organizaciones.

Piénselo lógicamente:

  • Valor: ¿por qué almacenamos estos datos si no tienen ningún valor? Ya se trate de registros de interacción con los clientes, detalles de proyectos internos, información sobre la cadena de suministro o incluso registros de asistencia de los empleados, estos datos sirven para tomar decisiones, impulsar las operaciones y proporcionar información. Si no tienen ningún valor, elimínalos. Pero si se conservan, es porque tienen un propósito, y ese propósito les confiere valor.
  • Confianza: ¿puedes tomar decisiones empresariales acertadas basándote en datos en los que no confías? Los datos que han sido manipulados, están incompletos o son inexactos son peores que inútiles: son activamente engañosos. Si los datos tienen valor para usted, entonces alguien puede beneficiarse de alterarlos y romper su confianza en ellos. Las violaciones de seguridad no solo exponen la información, sino que erosionan la integridad de los propios datos, haciéndolos poco fiables. La ley SOX es uno de los pocos requisitos de cumplimiento que tiene como objetivo establecer la confianza en la exactitud de los datos que regula. Pero debe confiar en todos sus datos.
  • Necesidad operativa: considere los datos de nóminas. Puede que no se clasifiquen como «altamente sensibles» según algunas normativas de cumplimiento, al igual que los datos de cuentas financieras. Pero, ¿se imagina el caos y las ramificaciones legales si se manipularan los datos de nóminas? El impacto es significativo, aunque no encaje perfectamente en una casilla de cumplimiento específica.
  • El factor de responsabilidad: en el panorama actual, las violaciones de datos no solo suponen una pérdida directa de información. Provocan daños a la reputación, batallas legales, multas reglamentarias y una pérdida de confianza por parte de los clientes. Incluso los datos aparentemente inocuos, cuando se exponen en un contexto inadecuado o se combinan con otra información comprometida, pueden generar responsabilidades significativas.

Los datos inseguros son inútiles, engañosos y suponen una responsabilidad. Es mejor no almacenar datos que almacenarlos sin protegerlos.

Bases de datos: el Fort Knox de la información de su organización

¿Dónde residen estos datos valiosos y potencialmente responsables? Principalmente, en sus bases de datos. Estos son los repositorios que albergan los ingredientes básicos para obtener información, tomar decisiones y actuar. Descuidar su seguridad y centrarse únicamente en la protección de los puntos finales es como construir un castillo de arena alrededor de un tesoro sin cerrar con llave.

¿Por qué esta desconexión? Quizás sea por la complejidad percibida de la seguridad de las bases de datos, el gran volumen de bases de datos dentro de una organización o el atractivo de amenazas más visibles como el malware. Pero la verdad sigue siendo la misma: las bases de datos inseguras son un agujero enorme en tu postura de seguridad.

Más allá de la falacia: un llamamiento a la acción para los profesionales de la seguridad

Como profesionales de la seguridad, tenemos la responsabilidad de defender una visión holística de la seguridad de los datos. Esto significa:

  • Educar y promover: debemos explicar el valor inherente y la responsabilidad potencial de todos los datos a nuestros compañeros y directivos. Debemos ir más allá de la definición de «sensible» basada en el cumplimiento normativo y hacer hincapié en el impacto empresarial de los datos inseguros. Utilice ejemplos reales de su organización para ilustrar este punto. Dondequiera que haya datos, habrá alguien que se beneficie de modificarlos o robarlos.
  • Adoptar un enfoque basado en el riesgo (de forma inteligente): aunque el objetivo final es proteger todos los datos, la realidad es que los recursos son limitados. Un enfoque basado en el riesgo puede ayudar a priorizar los esfuerzos. Sin embargo, esta priorización debe basarse en una comprensión global del impacto potencial de una violación, y no solo en una definición estrecha de la sensibilidad. La seguridad básica debe aplicarse de forma coherente en todas las bases de datos, y una mayor seguridad en aquellas con mayor riesgo.
  • Priorizar la seguridad de las bases de datos: La seguridad de las bases de datos debe convertirse en un pilar fundamental de nuestra estrategia de seguridad, no en una idea de último momento. Para la mayoría de las bases de datos, podemos empezar con medidas de seguridad básicas como el control de acceso, el cifrado, el control de cambios y la supervisión básica. Inicialmente, se utilizarán controles de actividad avanzados solo en la información más sensible. Pero el objetivo final debe ser una seguridad sólida de todas las bases de datos.
  • Crear un ADN de seguridad de los datos: proteger los datos y las bases de datos no es lo mismo que gestionar antivirus o filtrar el spam. Se necesita tiempo, formación y el apoyo de la dirección para que los equipos de seguridad y técnicos lleguen a un punto en el que la seguridad de los datos sea una parte natural del hecho de tener datos. Tenemos que crear una cultura en la que la seguridad de los datos esté arraigada en todas las operaciones de TI y seguridad y en la que todos comprendan su papel en la protección de la información.
  • Mejora iterativa: Reconocemos que no es realista proteger todas las bases de datos al más alto nivel de la noche a la mañana. El camino hacia una seguridad sólida de las bases de datos es iterativo. A medida que evoluciona la madurez de la seguridad de la organización, también lo hará su capacidad para implementar medidas de seguridad más sofisticadas en todo su panorama de datos. La clave es empezar ahora y mejorar continuamente.

Reflexiones finales

Invertir únicamente en cortafuegos, antivirus y seguridad del correo electrónico, mientras se descuida la seguridad de las bases de datos, es una clara mala asignación de recursos. Es como poner todos los huevos en la cesta equivocada.

Cambiemos el discurso. Ayudemos a nuestras organizaciones a comprender que todos los datos son valiosos y, por lo tanto, todos los datos son sensibles. Al convertir la seguridad de las bases de datos en la piedra angular de nuestras estrategias, podemos proteger verdaderamente los activos más críticos de nuestras organizaciones y construir un futuro digital más resistente y fiable. No es solo una conclusión lógica, es una necesidad empresarial.

  • 2025-07-25 01:17:05
    Eyal:
    ¡Excelente publicación! Gracias.
  • 2025-07-25 08:43:02
    Carlos:
    Muchas gracias.

Si tenes alguna pregunta o comentario, no dude en hacérnoslo saber. Estaremos encantados de escucharle.

Por Qué las Amenazas a las Bases de Datos Deben Pasar a Primer Plano

Por Qué las Amenazas a las Bases de Datos Deben Pasar a Primer Plano

Las bases de datos son el verdadero objetivo final de la mayoría de los ciberataques, pero siguen siendo peligrosamente ignoradas. Descubra por qué su defensa debe comenzar por sus datos y cómo protegerlos de una vez por todas.

Introducción

Como profesionales de la seguridad, nos vemos constantemente bombardeados por amenazas. Los ciclos de noticias están llenos de historias sobre sofisticadas campañas de phishing, nuevas cepas de malware y las tácticas en constante evolución de los intrusos en la red. Aplicamos parches a nuestros puntos finales, implementamos firewalls robustos y formamos a nuestros usuarios para que desconfíen de las estratagemas de ingeniería social. Se trata de defensas vitales, la primera línea en nuestra batalla continua.

Pero pensemos en el resultado final. ¿Cuál es el premio definitivo para estos atacantes? ¿Qué es lo que realmente buscan? En la gran mayoría de las brechas de datos, la respuesta se encuentra en el corazón de nuestros ecosistemas digitales: la base de datos.

Piensa en los titulares que realmente duelen. Las brechas que exponen millones de registros de clientes, información financiera confidencial, tarjetas de crédito, direcciones de correo electrónico, contraseñas y mucho más. Ahora, profundiza un poco más. ¿De dónde proceden todos esos datos? ¿Cuál es el denominador común? En casi todos los casos, los atacantes, independientemente de su punto de entrada inicial, tuvieron que comprometer la base de datos.

La intrusión inicial (el correo electrónico de phishing que engañó a un empleado, la vulnerabilidad en una aplicación web, el dispositivo de red mal configurado) es equivalente a un ladrón que encuentra una ventana sin cerrar. Proporcionan acceso, pero el verdadero tesoro se encuentra dentro de la cámara acorazada. Y en nuestro mundo digital, esa cámara acorazada es la base de datos.

Podrías argumentar: «¡Pero tenemos seguridad perimetral! ¡Tenemos sistemas de detección de intrusiones!». Y eso es loable. Son capas de defensa esenciales. Sin embargo, centrarse únicamente en la seguridad perimetral es como espantar mosquitos mientras se pasea por el parque. Puede que tengas suerte y elimines algunos, pero la amenaza siempre está ahí y algunos se posarán en tu piel y te picarán.

Piense en la epidemia del ransomware. Para que un atacante pueda paralizar realmente una organización y obtener un rescate cuantioso, necesita robar y cifrar los datos de la base de datos. Penetrar en la máquina de la base de datos es un requisito previo para que un ataque de ransomware tenga éxito. Conectarse a esa base de datos es la única forma de extraer los datos para poder amenazar con exponerlos.

La verdad es que la sofisticación de los ataques de inyección SQL, la naturaleza insidiosa del robo de credenciales y el riesgo siempre presente de los empleados maliciosos representan la principal amenaza para la vida misma de nuestras organizaciones. No se trata de riesgos teóricos, sino de los mecanismos por los que se producen las brechas más dañinas.

Entonces, ¿por qué la seguridad de las bases de datos suele parecer una preocupación secundaria, eclipsada por amenazas más visibles y quizás más sensacionalistas? ¿Por qué las amenazas a las bases de datos no son su mayor preocupación? Quizás sea por la complejidad percibida y los conocimientos especializados que se requieren. Tal vez sea por la mentalidad de «ojos que no ven, corazón que no siente». La base de datos suele funcionar silenciosamente en lo más profundo del centro de datos, como una fortaleza aparentemente impenetrable.

Pero esta aparente impenetrabilidad es una ilusión peligrosa con consecuencias catastróficas. Los atacantes comprenden el valor de sus datos y eso es lo que buscan. Hace mucho tiempo que desarrollaron métodos para eludir las medidas de seguridad tradicionales de las bases de datos. Establecer el cifrado y aplicar el principio del privilegio mínimo, aunque es importante, no los detendrá. Debemos comprender cómo los atacantes acceden a sus datos y luego implementar medidas para detectarlos y detenerlos.

Necesitamos un cambio de paradigma. Debemos elevar la seguridad de las bases de datos de una preocupación secundaria a un pilar fundamental de nuestra estrategia de seguridad global. No se trata de descartar la importancia de la seguridad de la red o la protección de los puntos finales. Se trata de reconocer que, por lo general, estos son solo un trampolín para los atacantes. Los objetivos finales, las joyas de la corona, residen en la base de datos.

Amenazas a las Bases de Datos

Aunque es fantástico defender la seguridad de las bases de datos y abogar por abordar las amenazas del mundo real, la pregunta sigue siendo: ¿cuáles son esas amenazas y cómo podemos abordarlas? Empecemos por cómo los atacantes logran esta hazaña y acceden a la base de datos.

Hay tres cosas que hay que tener en cuenta al responder a esta pregunta:

  • Examina casos reales de brechas importantes. No siempre se puede encontrar información publicada sobre lo que ocurrió exactamente, pero a veces hay pistas. Por ejemplo, un ataque de ransomware significa que el servidor se vio comprometido o los atacantes no podrían cifrar los archivos. Otro ejemplo es la amenaza interna siempre presente, que ronda el 20 % de las brechas desde hace años.
  • Desafía a tu equipo de bases de datos a averiguar cómo violarían sus bases de datos. Es una especie de ejercicio teórico de equipo rojo.
  • Reconoce los hechos. Aunque muchos proveedores intentan confundirnos con amenazas imaginarias, la realidad es que los atacantes no pueden conectarse a una base de datos sin un nombre de usuario y una contraseña válidos. Todas las bases de datos modernas han superado hace tiempo la etapa de los paquetes especiales que permiten a alguien burlar mágicamente la seguridad. No hay desbordamientos de pila ni puertas traseras no documentadas para obtener acceso.

Dicho esto, ¿cómo entran los atacantes? Sabemos que lo hacen, así que, ¿cuál es el truco? Bueno, no hay ninguna magia real y ya conoce la respuesta:

  • Amenaza interna. No nos gusta admitirlo, pero las estadísticas muestran que los actores internos representan alrededor del 20 % de las brechas de datos. Cada año se muestra en el DBIR (Informe de investigación de brechas de datos) de Verizon. Las personas en las que confiamos y a las que les damos acceso abusan de sus privilegios.
  • Cuentas individuales comprometidas. Muchas veces, los atacantes se hacen pasar por otras personas. Roban contraseñas o comprometen un ordenador de sobremesa y lo utilizan para conectarse. Si un atacante penetra en una máquina con acceso a la base de datos, como un ordenador de sobremesa DBA, acceder a los datos es muy sencillo.
  • Cuentas compartidas comprometidas. Las credenciales de las cuentas privilegiadas compartidas (como SYS o SA) y las cuentas de aplicaciones se almacenan en archivos de configuración, hojas de cálculo y otros soportes. Nadie recuerda una contraseña segura de 12 caracteres, siempre se escribe en algún sitio.
  • Acceso local. Obtener acceso al servidor de la base de datos le permitirá acceder a la base de datos. Esto ocurre en todos los ataques de ransomware. No solo se pueden robar los archivos de datos, sino que hay una cuenta del sistema operativo local que puede conectarse a la base de datos sin contraseña.
  • Aplicación. Las vulnerabilidades de las aplicaciones son otra vía habitual. La inyección SQL es el vector de ataque a aplicaciones más conocido, pero muchos fallos de las aplicaciones permiten a los atacantes modificar o extraer datos de la base de datos.

Pero aunque sabemos que estas amenazas existen y somos conscientes de que se explotan, seguimos ignorándolas. Eso es ilógico. ¡Así es como se producen las brechas de datos! ¡Eso es lo que debemos detener!

Abordar las amenazas

Al analizar estas amenazas y pensar en la seguridad tradicional de las bases de datos, se dará cuenta de que las medidas tradicionales no sirven de nada. Sí, es importante cifrar los datos en tránsito y los datos en reposo. Pero los atacantes no se centran en el tráfico de red y no roban archivos físicos (aunque pueden cifrarlos para pedir un rescate). Sí, es importante aplicar los principios de privilegios mínimos y cerrar las cuentas que no se utilizan, pero no es así como un hacker suele acceder a sus datos.

Entonces, ¿cómo podemos defendernos? Quizás la razón por la que no nos centramos en la seguridad de las bases de datos es que no podemos protegerlas.

Las soluciones modernas de seguridad de bases de datos, como Core Audit, tienen muchas capacidades para hacer frente a estas amenazas:

  • Informes de cumplimiento. Uno de los métodos más antiguos es el tipo de informes que se utilizan en todos los marcos de cumplimiento. Informes sobre la actividad de los administradores de bases de datos, DDL, etc. Aunque este tipo de informes puede llevar mucho tiempo, ofrece una buena visibilidad de ciertos aspectos de alto riesgo de la actividad de la base de datos. Esta es la forma tradicional de proteger las bases de datos contra amenazas internas, cuentas comprometidas y acceso local.
  • Análisis de anomalías. Un enfoque moderno consiste en buscar cambios en los perfiles de actividad. Buscar una nueva combinación de usuarios y programas que se conectan a la base de datos. Buscar un nuevo SQL que acceda a datos confidenciales. Actividad a una hora inusual del día o un volumen de actividad superior al habitual. Las anomalías son herramientas poderosas para controlar la actividad repetitiva y de gran volumen, como la aplicación. Son eficaces contra todas las amenazas, incluidas las amenazas internas, las cuentas comprometidas, el acceso local y las vulnerabilidades de las aplicaciones, como la inyección de SQL.
  • Análisis forense proactivo. Otra herramienta poderosa es proporcionar al personal de seguridad visibilidad de lo que ocurre en la base de datos. Al involucrar a las personas en el proceso de seguridad, se pueden identificar ataques, prácticas de seguridad deficientes y lagunas en los controles. Lo más importante es que el análisis forense proactivo ayuda a diseñar informes y alertas eficaces que se centran en el perfil de actividad de su base de datos concreta.
  • Bloqueo SQL avanzado. Pasando de la detección a la prevención, el bloqueo SQL avanzado te permite limitar los privilegios de los administradores de bases de datos, controlar las fuentes de actividad, aplicar la separación de funciones y mucho más. Esto mejora la seguridad de la base de datos más allá de lo que ofrecen las capacidades integradas.

Reflexiones Finales

El zumbido de los mosquitos es molesto, pero lo que realmente molesta es la picadura. Del mismo modo, las intrusiones en el perímetro son preocupantes, pero inevitables, y lo que conduce a brechas catastróficas de datos es el compromiso de la base de datos.

No podemos permitirnos permanecer complacientes. Debemos comprender las amenazas reales a las bases de datos y defender la causa de la seguridad de las bases de datos para hacerles frente. Debemos hacerlo con el mismo vigor y urgencia que aplicamos a otras áreas de la ciberseguridad, si no más. La mayoría silenciosa, nuestras bases de datos y las amenazas a las que se enfrentan, son el secreto para derrotar a nuestros adversarios. Nuestros datos son el tesoro que ellos ansían y es hora de que demos a nuestras bases de datos la protección que se merecen.

Vos podes proteger tu base de datos. La solución está acá. ¡Ponte en contacto con nosotros hoy mismo!

  • 2025-07-28 07:18:48
    Enrique:
    Me Encanta!!

Si tenes alguna pregunta o comentario, no dude en hacérnoslo saber. Estaremos encantados de escucharle.

Integridad de los Datos, SOX e Información Financiera

Integridad de los Datos, SOX e Información Financiera

Los escándalos financieros de Enron y WorldCom cambiaron las reglas del juego. Este artículo explora cómo la Ley Sarbanes-Oxley impacta en la integridad de los datos y qué papel juega IT —y especialmente las bases de datos— en el cumplimiento normativo.

Introducción

La mejor manera de explicar la ley SOX es recapitular las historias de los escándalos de Enron y WorldCom.

Enron era una empresa energética estadounidense que cotizaba en bolsa y que, en 2001, se declaró en quiebra tras descubrirse un fraude interno generalizado. Las acciones de Enron pasaron de valer 90 dólares a valer unos céntimos, y los inversores lo perdieron todo. Con 63 000 millones de dólares en activos, Enron se convirtió en la mayor reorganización por quiebra de la época. También provocó la disolución de su empresa de contabilidad, Arthur Andersen, anteriormente una de las cinco más grandes del mundo.

El escándalo consistió en que Enron manipuló la información que comunicaba al mercado de valores. Mediante una serie de prácticas contables poco éticas y fraudulentas, exageraron los ingresos y ocultaron las pérdidas. El precio de las acciones se disparó como resultado de esos beneficios falsos y se desplomó cuando se hizo público.

Menos de un año después, en 2002, WorldCom, la segunda empresa de telecomunicaciones más grande de Estados Unidos en ese momento, también se vio envuelta en un escándalo contable. Su unidad de auditoría interna descubrió más de 3800 millones de dólares en entradas fraudulentas en el balance. Finalmente, WorldCom se vio obligada a admitir que había sobrevalorado sus activos en más de 11 000 millones de dólares. Los altos ejecutivos, liderados por el director general, inflaron las ganancias para mantener el precio de las acciones. En ese momento, fue el mayor fraude contable de la historia de Estados Unidos y, un año después, la empresa se declaró en quiebra.

Estos y otros escándalos llevaron a Paul Sarbanes y Michael Oxley a aprobar la Ley Sarbanes-Oxley en 2002. Su objetivo es resolver un problema recurrente: los ejecutivos manipulan el precio de las acciones manipulando la información que comunican al mercado bursátil. Lo consiguieron gracias a unos controles internos insuficientes, a la falta de responsabilidad y a la cooperación de sus empresas de contabilidad.

Por ejemplo, el artículo 302 establece que el director ejecutivo y el director financiero son directamente responsables de la exactitud de todos los informes financieros, así como de la estructura de control interno. El artículo 404 exige que los informes financieros anuales incluyan un informe de control interno y que auditores externos certifiquen que los controles están implantados, son operativos y eficaces. La sección 906 tipifica como delito la certificación de un informe financiero engañoso o fraudulento, con sanciones de hasta 5 millones de dólares en multas y 20 años de prisión, y la sección 802 impone hasta 20 años de prisión por alterar, ocultar o falsificar registros con la intención de afectar a las investigaciones legales.

La Comisión de Bolsa y Valores (SEC) es responsable de prevenir la manipulación del mercado. Esto incluye asegurarse de que la información que las empresas comunican al mercado de valores sea precisa. La ley SOX no cambia el papel de la SEC, pero impone requisitos y expectativas adicionales en materia de controles internos, rendición de cuentas e independencia de los auditores. En última instancia, son las regulaciones y acciones de la SEC las que guían a las empresas sobre cómo cumplir con la ley.

¿Cómo se relaciona esto con las tecnologías de la información?


Ahora que entendemos qué es SOX, profundicemos en el aspecto informático y, más concretamente, en el aspecto de las bases de datos. Entonces, ¿por qué afecta SOX a la informática y de qué manera?

Los informes financieros que revisan los auditores y que las empresas envían a la SEC se basan en datos almacenados en bases de datos y gestionados por sistemas informáticos. La manipulación de estos datos subyacentes da lugar a informes financieros incorrectos. En el caso de WorldCom, por ejemplo, se reclasificaron los gastos operativos como activos fijos. Se trataba de un cambio en la información utilizada para elaborar el informe, lo que dio lugar a 11 000 millones de dólares de beneficios falsos.

Para mitigar estos riesgos, la ley SOX exige a las empresas que establezcan controles internos sobre la información financiera. También les exige que proporcionen al mercado de valores una evaluación de esos controles internos realizada por un auditor externo independiente. Las regulaciones de la SEC amplían aún más el mantenimiento de registros, garantizando que las transacciones se registren según sea necesario, que los ingresos y gastos estén autorizados, que se prevenga o detecte la adquisición, el uso o la disposición no autorizados, y más.

En otras palabras, se exige a las TI que protejan toda la información que afecta a los estados financieros. Este requisito no solo se aplica a las empresas que cotizan en bolsa, sino también a todas sus filiales en todo el mundo que contribuyen a los estados financieros de las empresas públicas.

Aunque también se deben proteger estos datos contra el robo, la ley SOX solo se centra en garantizar la integridad de los datos. Se trata de garantizar que la información sea precisa y no haya sido manipulada. Esto se debe a que los datos manipulados afectan a la información financiera que las empresas comunican al mercado bursátil, lo que repercute en el precio de las acciones y da lugar a escándalos como los de Enron y WorldCom.

Implicaciones en las bases de datos

Ahora que entendemos la teoría, resumamos nuestros objetivos:

  • Datos que hay que proteger: Información Financiera. Cualquier dato utilizado para crear los estados financieros que se envían al mercado de valores. Incluye ventas, costes, gastos, activos (propiedades que posee la empresa y su valor) y mucho más.
  • Riesgo: manipulación de datos, es decir, un cambio no autorizado o ilegítimo. En términos de SQL, el alcance es DML y DDL. DML (insertar, actualizar y eliminar) cambia los datos directamente y es el riesgo principal. Sin embargo, los DDL también pueden afectar a la integridad de los datos y a la forma en que se almacenan y procesan los datos financieros (por ejemplo, desencadenantes, procedimientos, restricciones y más).

La buena noticia es que los datos financieros son una parte relativamente pequeña de los datos que gestiona la organización. Además, los DML y los DDL también son una pequeña parte de la actividad de esas bases de datos. Por lo tanto, nuestro ámbito se limita a un pequeño número de bases de datos y a una pequeña parte de la actividad de cada una de ellas.

La mala noticia es que todavía hay muchas bases de datos que proteger. Peor aún, aunque las DML y las DDL constituyen un pequeño porcentaje de la actividad total de la base de datos, su número absoluto puede ascender a millones o más. También contamos con un número limitado de personas y tiempo. Por lo tanto, para controlar toda esta actividad se necesita una solución especializada que pueda supervisar de manera eficiente esta escala de actividad y ayudar a garantizar que todo sea legítimo.

Vectores de Ataque

En primer lugar, debemos aclarar que esta evaluación de riesgos es genérica y puede que no sea aplicable a todas las empresas y bases de datos. Para cumplir con la ley SOX, es posible que su auditor le solicite ver su evaluación de riesgos y controles. Por lo tanto, le recomendamos que realice una. Sin embargo, puede utilizar este artículo como punto de partida para evaluar sus riesgos y los controles adecuados.

Aunque no se indica explícitamente, una gran parte del riesgo SOX es interno. La principal preocupación de los autores de la ley SOX era que las personas que trabajaban para la empresa manipularan los datos financieros. Si bien la preocupación debe extenderse a los actores externos, las amenazas internas son mucho más difíciles de manejar porque tienen acceso legítimo. Muchos paradigmas de seguridad se centran en el acceso ilegítimo, y se considera difícil protegerse contra las amenazas internas.

Con las amenazas internas, el problema no son las suplantaciones de identidad, el robo de credenciales, etc. No hay conexiones desde máquinas inusuales ni actividad a horas sospechosas. El agente de la amenaza abusa de su acceso legítimo. Aprovecha sus interacciones diarias habituales con el sistema para hacer algo malicioso. Por lo tanto, hay que inspeccionar cada actividad para encontrar esa aguja en el pajar. Tener esa capacidad también servirá para hacer frente a las amenazas externas.

En general, las amenazas a las bases de datos giran en torno a las cuentas autenticadas. Esto se debe a que es casi imposible conectarse sin un usuario y una contraseña válidos. La ley SOX se centra aún más en las personas con credenciales válidas que no necesitan eludir la seguridad.

En otras palabras, el «ataque», o, más exactamente, la manipulación no autorizada de datos, que nos preocupa, podría ser fácilmente ejecutado por el administrador de bases de datos o utilizando la cuenta de la aplicación. Esos son, en realidad, los vectores de ataque de alto riesgo.

Una vez más, no debemos descartar otros vectores de ataque, como los hackers que penetran en los sistemas financieros. Sin embargo, los controles que pueden descubrir actividades ilegítimas de los administradores de bases de datos o de la cuenta de la aplicación detectarán fácilmente a los hackers externos. Más información a continuación.

Implementación

Con una comprensión clara de lo que queremos proteger y cuáles son los vectores de ataque más preocupantes, elaboremos un plan de implementación para hacer frente a las amenazas.

Los métodos de seguridad de bases de datos más populares, como la seguridad de las cuentas, el cifrado y la aplicación de parches, tienen una relevancia menor y no abordan estos vectores de ataque. Aunque son esenciales, especialmente en sistemas financieros críticos, no pueden detectar ni prevenir la manipulación de datos. Por ejemplo, no abordan la amenaza interna y no alertan ni impiden que una cuenta DBA o la cuenta de la aplicación modifique los datos financieros.

Para lograr este tipo de detección y prevención de la manipulación de datos, necesitamos soluciones de control de actividades, más conocidas como auditoría de bases de datos. Core Audit es una solución de seguridad de bases de datos de Blue Core Research que cuenta con capacidades avanzadas de control de actividades. Los ejemplos de implementación que utilizamos en este artículo se basan en las capacidades de Core Audit.

El primer paso para cumplir con la ley SOX es garantizar que podemos proporcionar a los auditores un registro detallado de todas las DML y DDL relevantes. Todas las soluciones de auditoría pueden registrar un registro de auditoría. Las diferencias radican en el impacto en el rendimiento de la base de datos, los niveles de detalle y el volumen que pueden manejar.

Core Audit aprovecha la tecnología Full Capture, que tiene un impacto insignificante en el rendimiento de la base de datos. También cuenta con dos repositorios independientes que proporcionan un registro de auditoría: el repositorio de seguridad y el repositorio de cumplimiento. El repositorio de seguridad siempre registra información sobre toda la actividad SQL, por lo que siempre sabrá quién hizo qué en su base de datos. No es necesario que realice ninguna acción para registrar esta información. Si necesita información más detallada, también puede registrar la actividad en el repositorio de cumplimiento. La actividad en el repositorio de cumplimiento incluye detalles completos de la sesión, resolución de menos de un segundo y mucho más. El repositorio de cumplimiento consume más espacio en disco, pero es eficiente y escalable, capaz de gestionar fácilmente miles de millones de SQL. Dado que solo se centra en DDL y DML específicos, ambos repositorios son aplicables, y debe elegir en función del nivel de detalle que usted y sus auditores requieran.

Una vez que tengamos un registro de toda la actividad que necesitamos supervisar, debemos aplicar controles más estrictos que nos informen de posibles problemas. Tenemos DDL y DML que debemos controlar, por lo que el siguiente paso es controlar los DDL.

Las prácticas recomendadas de seguridad requieren un proceso de control de cambios para controlar los DDL. Para garantizar que nada se escape del proceso, también debe supervisar la actividad DDL. Core Audit puede informar sobre la actividad DDL e integrarse con el proceso de control de cambios.

Eso nos deja con los DML. Podemos dividir la actividad DML en actividad de cuentas que no deben ejecutar DML y actividad de cuentas que sí deben hacerlo.

El siguiente paso son los DML de fuentes sospechosas. Por ejemplo, es poco probable que los administradores de bases de datos realicen cambios en los registros financieros. De hecho, es poco probable que dichos cambios provengan de alguien que no sea la aplicación. Más concretamente, solo el software de aplicación que utiliza la cuenta de aplicación del servidor de aplicaciones debe ejecutar DML. Puede alertar sobre dicha actividad inusual o bloquearla por completo.

Lo que nos deja con las DML que se originan en la aplicación. El motor de análisis de anomalías puede identificar actividades inusuales de la aplicación. Al comparar el perfil de actividad de la aplicación de hoy con el perfil de la semana o el mes pasado, Core Audit puede señalar comportamientos inusuales. Dependiendo de la aplicación, el motor de análisis de anomalías puede comparar diferentes aspectos del perfil de actividad o subconjuntos de la actividad. Esto detectará, por ejemplo, un ataque de inyección SQL. Puede detectar SQL inusuales, cambios en el volumen de SQL, actividad durante una hora diferente del día y otros comportamientos sospechosos de la aplicación. Aunque normalmente quedan fuera del alcance del cumplimiento de la ley SOX, se trata de controles valiosos que mejorarán significativamente la seguridad de los datos.

Para garantizar un control estricto de quién accede a la base de datos, también recomendamos implementar controles de sesión mediante informes, alertas de anomalías o análisis forenses proactivos. Un informe puede, por ejemplo, ofrecer un resumen diario de quién se ha conectado. Una anomalía le informará cuando se produzca un cambio en el origen de la actividad, como un usuario que se conecta desde una IP diferente. El análisis forense proactivo le permite inspeccionar los orígenes de la actividad e identificar algo que no esperaba.

Yendo Más Allá

Aunque queda fuera del alcance de la ley SOX, recomendamos supervisar las consultas para evitar el robo de datos. Es una buena idea para cualquier información confidencial. Esto queda fuera del alcance de este artículo, pero dentro del alcance y las capacidades de Core Audit.

Otra ampliación más allá del cumplimiento tradicional de la ley SOX es el seguimiento de los cambios en los datos. La ley SOX no exige un registro detallado que permita rastrear el origen de cada dato. Sin embargo, esa es una de las capacidades de Core Audit.

La Integridad de los Datos no es solo para SOX

Hasta ahora solo hemos hablado de SOX, pero los mismos conceptos se aplican mucho más allá de la información financiera. La forma en que garantizamos la exactitud de los datos financieros es similar a la forma en que garantizamos la fiabilidad de cualquier dato. Aunque le puedan preocupar los diferentes actores, el problema es casi idéntico, al igual que la solución.

Esto plantea una pregunta interesante: además de los datos financieros, ¿qué otros datos debe proteger para garantizar su integridad y fiabilidad? Quizás una mejor forma de plantear esta pregunta sea: ¿qué datos pueden no ser precisos y fiables? ¿Qué datos puede utilizar si no son fiables y no sabe si son correctos o no?

La verdad es que los datos poco fiables son inútiles. Cuando invertimos tiempo y dinero en almacenar datos, necesitamos que sean fiables. Eso nos lleva a asumir que nuestros datos son siempre precisos, pero esa es una suposición peligrosa cuando no se protegen adecuadamente.

Reflexiones finales

Aunque al principio puede resultar intimidante, el cumplimiento de la ley SOX no es demasiado difícil. Con la solución y los conocimientos adecuados, puede lograrlo y garantizar la seguridad de sus datos.

Mediante la implementación de este tipo de medidas de integridad de los datos, las organizaciones pueden cumplir y superar los requisitos de la ley SOX. Déjenos ayudarle a construir una base de confianza y fiabilidad en su información financiera.

Haz una Pregunta

Si tenes alguna pregunta o comentario, no dude en hacérnoslo saber. Estaremos encantados de escucharle.

La ilusión del muro: por qué tu fortaleza de datos es un castillo de arena

La ilusión del muro:
Por qué tu fortaleza de datos es un castillo de arena

La seguridad basada en el perímetro nos proporcionaba una sensación de seguridad y control. Hoy en día, nos quedamos atrás esperando una brecha. El mundo ha cambiado y esas defensas ya no sirven. Es hora de replantearnos cómo alinear nuestra inversión y nuestros esfuerzos con la realidad.

Introducción

Durante años, el mantra de la ciberseguridad se centró en el «perímetro». Los cortafuegos se erigían como murallas digitales de Adriano, el software antivirus patrullaba las puertas y los filtros de correo electrónico actuaban como centinelas vigilantes. Este enfoque se centraba en mantener alejados a los «malos» y ofrecía una sensación tangible de seguridad. Podíamos ver las defensas, observarlas en acción y sentir una apariencia de control.

Pero los ataques modernos del siglo XXI no funcionan así. Los hackers han tenido en cuenta estas cerraduras de las puertas principales y han aprendido a trepar por las ventanas. Al fin y al cabo, estas «ventanas» ofrecen un acceso mucho más fácil.

Pero el panorama digital sigue cambiando. El perímetro, que antes era una frontera aparentemente sólida, ahora es poroso, fragmentado y cada vez más irrelevante. Todo se ha interconectado tanto que las fronteras se han disuelto. La computación en la nube, el trabajo a distancia, la externalización y las integraciones de sistemas han difuminado las líneas hasta hacerlas desaparecer. Confiar únicamente en las defensas perimetrales hoy en día es como proteger un cofre del tesoro con la puerta principal cerrada con llave mientras todas las ventanas están abiertas de par en par.

Con el 90 % de las empresas informando de al menos un ataque en el último año, las olas golpean constantemente nuestro castillo de arena. Y con casi el 40 % de ellas vulneradas, el agua ya está entrando.

La fría y dura lógica: por qué la seguridad perimetral falla en la protección de sus datos


Las brechas de seguridad ya no son una cuestión de «si» ocurrirán, sino de «cuándo». Los titulares gritan esta verdad con alarmante regularidad. Los atacantes sofisticados eluden habitualmente incluso los perímetros más robustos y costosos. Atacan a las organizaciones más grandes y seguras del planeta. Lo hacen a través de:

  • Ingeniería social: el factor humano sigue siendo el eslabón más débil. Los ataques de phishing inteligentes y las tácticas de manipulación social pueden engañar incluso a los empleados más vigilantes. Una vez dentro, tras el perímetro, los atacantes tienen vía libre.
  • Amenazas internas: los empleados descontentos, los usuarios codiciosos o la pura malicia dentro de su organización representan un riesgo significativo y a menudo pasado por alto. Más del 20 % de las violaciones de datos son obra de actores internos y el perímetro no ofrece ninguna protección contra ellos.
  • Explotaciones de día cero: estas vulnerabilidades previamente desconocidas en el software pueden ser explotadas incluso antes de que estén disponibles los parches. Las defensas perimetrales, centradas en las amenazas conocidas, son impotentes contra estos nuevos ataques.
  • Ataques a la cadena de suministro: cada vez más, los atacantes se dirigen a proveedores externos menos seguros para acceder a sus objetivos principales. Su sólido perímetro pierde relevancia si un socio con acceso se ha visto comprometido.
  • Configuraciones erróneas: los errores humanos son inevitables. Una regla de firewall mal configurada o un control de acceso demasiado permisivo pueden crear inadvertidamente grandes agujeros en sus defensas, lo que hace que su inversión sea inútil.
  • Dispositivos inseguros: El trabajo remoto y el BYOD (traiga su propio dispositivo) significan que hay muchos dispositivos sobre los que no tiene control y que están en su red. Cualquiera que tenga acceso al ordenador doméstico de un empleado está conectado directamente a su red interna.

Pensar que su perímetro resistirá estas amenazas multifacéticas no solo es optimista, sino peligrosamente ingenuo. Es como creer que un foso detendrá a un enemigo decidido con alas.

El camino hacia la verdadera seguridad

Adoptar el enfoque centrado en los datos

Sabemos que la seguridad perimetral no es infalible. Cada semana vemos cómo se producen violaciones de seguridad en organizaciones. Somos conscientes de que una violación de datos es inevitable y solo es cuestión de tiempo. Sin embargo, seguimos confiando en el perímetro y realizando grandes inversiones en él.

La ilusión creada por la seguridad perimetral nos da una falsa sensación de tranquilidad. Sin embargo, la verdadera seguridad no reside en construir muros más altos, sino en proteger las joyas de la corona: sus datos. Eso requiere un cambio de paradigma hacia una seguridad centrada en los datos y una estrategia de defensa en profundidad.

Pasos preliminares: Estos son pasos fundamentales para establecer una base mínima para su seguridad. No detendrán ningún ataque moderno, pero ofrecen una buena base sobre la que empezar a construir.

  • Conozca sus datos: localice dónde residen sus datos confidenciales, quién tiene acceso a ellos y cómo los utilizan. Esta visibilidad fundamental es el primer paso hacia una protección eficaz. No se pueden proteger datos si no se sabe dónde están ni quién los maneja. Empiece por las bases de datos y luego vaya avanzando hacia fuera. Core Audit puede ayudarle a obtener esta visibilidad tanto en sus bases de datos como en sus aplicaciones.
  • Bloquee el acceso: desde las políticas de contraseñas hasta los privilegios mínimos, debe asegurarse de que los usuarios estén debidamente autenticados y solo tengan autorización para acceder a los datos necesarios para realizar sus tareas. Estos son pasos fundamentales en materia de seguridad, pero son insuficientes y no pueden detener a los atacantes. Debe hacer más.
  • Cifrado: cifre los datos en tránsito y en reposo. Hoy en día, se trata de una medida de seguridad estándar, integrada en todas las pilas tecnológicas y fácil de habilitar. Aunque es vital, tampoco detendrá la mayoría de los ataques.

Control de actividades: El reto subyacente en la seguridad centrada en los datos es inspeccionar y proteger todas las actividades que acceden a los datos. Al inspeccionar todo (y hay miles de millones de actividades), lo que se ve en su mayor parte son actividades legítimas. Hay que aislar las pocas actividades potencialmente ilegítimas que hay entre ellas. Ahí es donde entran en juego el análisis de anomalías, el análisis forense proactivo y la prevención avanzada de actividades. Por eso son indispensables soluciones como Core Audit y Core Masking. El control de la actividad también es un requisito de todos los requisitos de cumplimiento, lo que reconoce su importancia vital.

  • Seguridad de bases de datos: Más allá de lo mínimo imprescindible, debe emplear la supervisión de la actividad, el análisis de anomalías, el análisis forense proactivo y la prevención avanzada de actividades. Se trata de tecnologías especializadas diseñadas para proteger su sistema de bases de datos específico. Sin este tipo de defensas, no podrá detener ningún ataque actual. Core Audit es una solución esencial en esta tarea, ya que ofrece la protección más avanzada para sus bases de datos.
  • Seguridad de las aplicaciones: siguiendo los datos desde la base de datos hasta la aplicación, emplee la supervisión de la actividad, el análisis de anomalías y el análisis forense proactivo a nivel de la aplicación. Se trata de variaciones de las tecnologías especializadas en bases de datos. Sin embargo, las hemos diseñado para bloquear su aplicación. Son complementarias al WAF, pero superiores, ya que miran dentro de la aplicación, no solo fuera. Core Audit es compatible con aplicaciones Java y Web Client Security para complementar las medidas de seguridad de la base de datos y mantener sus datos a salvo.
  • Enmascaramiento de datos: Debe enmascarar los datos fuera de los sistemas de producción. Aunque hay otras formas de defenderlos, el enmascaramiento de datos es, con diferencia, la solución más fácil y rentable. El reto es garantizar que los datos enmascarados sean valiosos para las pruebas, el desarrollo u otros fines para los que están destinados. De lo contrario, eliminar la información confidencial no tiene sentido. Aquí es donde las capacidades de Core Masking se vuelven indispensables, ya que ofrecen una amplia gama de algoritmos que se adaptan a cada propósito.

El factor humano: Las soluciones necesitan personas que las operen. Sin personas que comprendan las tecnologías, sepan qué buscar y cómo responder, no se logrará la seguridad. Son las personas las que harán que su seguridad funcione.

  • Forma a tu personal de seguridad: pasar de la seguridad perimetral tradicional a una centrada en los datos requiere habilidades adicionales. Las personas deben saber cómo es una inyección SQL y cómo reaccionar ante las alertas de actividades sospechosas. Las organizaciones pasan por un proceso de maduración a medida que pasan de limpiar virus y correos electrónicos no deseados a combatir las amenazas modernas. Esto requiere las soluciones adecuadas, formación, experiencia y arraigarlo en tu ADN de seguridad.
  • Forma a tus administradores de bases de datos y aplicaciones: la seguridad centrada en los datos puede ser muy técnica y requerir que se base en los conocimientos especializados a nivel de dominio que ya existen en su organización. Contar con la participación de los administradores no solo consolidará el respaldo técnico que pueda necesitar, sino que también integrará la seguridad en toda la pila de TI.

Reflexión Final

Superar la mentalidad obsoleta centrada en el perímetro es inevitable. Es solo cuestión de tiempo. Sin embargo, requiere valor y voluntad para adoptar un enfoque más moderno y completo. Más aún, requiere reconocer que los muros fallarán y que debe cambiar su enfoque para proteger lo que realmente importa: sus datos.

Comience por proteger su base de datos. Ese es un primer paso importante y le ayudará a adoptar este cambio radical de mentalidad: pensar en sus datos. Incluso si, en este momento, no sabe qué son, dónde están, quién los utiliza o cómo. Ese es el comienzo de este nuevo viaje.

No deje que la ilusión del muro le lleve a una falsa sensación de seguridad. El coste de la inacción es mucho mayor que la inversión en una seguridad sólida centrada en los datos. Es hora de abandonar el castillo de arena y construir una verdadera fortaleza de datos desde dentro hacia fuera. Su negocio, sus clientes y su tranquilidad dependen de ello.

La seguridad centrada en los datos y los controles de actividad son el futuro de la seguridad. Es, por ejemplo, la única forma de proteger la nube, ya que esta no tiene perímetro. Sin embargo, con o sin perímetro, la seguridad centrada en los datos es el único método eficaz para protegerlos. Déjenos ayudarle a controlar sus datos. ¡Póngase en contacto con nosotros hoy mismo!

Haz una Pregunta

Si tenes alguna pregunta o comentario, no dude en hacérnoslo saber. Estaremos encantados de escucharle.

Lo que estás haciendo no está funcionando

Lo que estás haciendo no está funcionando

La mayoría de las organizaciones sufren constantes ciberataques, y muchos de ellos tienen éxito. Está claro que las defensas actuales nos están fallando y que es urgente cambiar.

Una encuesta de Rubrik Zero Labs revela que el 90 % de los responsables de TI y seguridad sufrieron ciberataques durante el último año, y el 20 % informó de un ataque cada dos semanas de media.

Se trata solo de ataques, pero los ataques tienen consecuencias. El 30 % informó de brechas de datos en las instalaciones, el 28 % de brechas en la nube o SaaS y el 26 % de ransomware.

Y lo más alarmante es que esos son solo los que se conocen. Probablemente haya muchos más.

La única conclusión a la que puede llegar cualquier persona racional es que lo que sea que estés haciendo no está funcionando. No se trata de hacer más de lo mismo. Hay que hacer algo diferente. El camino actual se está desintegrando ante nuestros ojos. El 90 % de las empresas sufren ataques porque estos ataques tienen éxito. Las defensas son simplemente ineficaces y no funcionan. No hay otra forma de explicar estas cifras.

¿Qué puedes hacer?


En primer lugar, hay que aceptar que defender el perímetro es una batalla perdida. Es una batalla que debemos librar, pero que perderemos. Por lo tanto, no invierta demasiado en la defensa del perímetro. Desde la seguridad de la red hasta los puntos finales, los correos electrónicos, el AIM y las contraseñas, es una batalla que probablemente ya haya perdido muchas veces sin darse cuenta. No es que los atacantes hayan comprometido todas las defensas del perímetro, pero sí algunas de ellas. O tal vez los atacantes entraron por otra vía.

La realidad es que los atacantes penetran constantemente los perímetros de la mayoría de las empresas. Si no es desde el exterior, entonces desde un actor interno. En la encuesta de Rubrik, los empleados internos fueron responsables del 28 % de los ataques. Otras estimaciones los sitúan en torno al 20 %. Sin embargo, ya sean internos o externos, los atacantes encuentran la manera de entrar. No hay forma de detenerlo, solo de ralentizarlo.

La pregunta obvia es: «¿Qué podemos hacer?».

Una respuesta que escucho a menudo es «Nada». Solo hay que esperar la inevitable brecha. Está por llegar.

No me gusta esa respuesta y me niego a aceptarla.

La otra respuesta es la seguridad centrada en los datos. Significa centrarse en proteger los datos. Si no se puede evitar que los actores maliciosos penetren en la red, hay que proteger los datos de todo el mundo.

Dado que hay actores maliciosos que entran desde el exterior y amenazas internas desde el interior, todo el mundo es sospechoso. Tenemos que proteger los datos contra todo el mundo.

Las contraseñas pueden ser robadas, las personas suplantadas y los privilegios abusados. Hay una lista interminable de vectores de ataque, y la conclusión es simple: no se puede confiar en ninguna actividad. Hay que evaluar cada acceso a los datos. Todo es sospechoso.

Es una gran conclusión, pero ¿cómo se puede hacer?

Con miles de millones o billones de accesos al mes, no es un trabajo que pueda realizar una persona. Sin embargo, las tecnologías modernas pueden capturar y evaluar todos estos accesos para encontrar esa aguja en el pajar.

Esa afirmación suena demasiado buena para ser cierta, y en cierta medida lo es. Es una generalización, y los detalles son mucho más complicados. Pero sí. Es posible controlar toda la actividad de la base de datos y toda la actividad de la aplicación. Blue Core Research ha desarrollado una serie de tecnologías que pueden lograrlo. Póngase en contacto con nosotros para obtener más información.

Haz una Pregunta

Si tenes alguna pregunta o comentario, no dude en hacérnoslo saber. Estaremos encantados de escucharle.

Introducción a las bases de datos para profesionales de la seguridad

Introducción a las bases de datos para profesionales de la seguridad

Este artículo ofrece una breve introducción a las bases de datos, explica sus modelos de seguridad y por qué las medidas de seguridad tradicionales no logran hacer frente a las amenazas reales. 

¿Qué es una base de datos?

Una base de datos es una solución de software que almacena, manipula y recupera datos. Piensa en una hoja de cálculo de Excel, pero una base de datos opera a una escala mucho mayor. Una base de datos es como miles de hojas de cálculo de Excel, algunas con millones de filas, a las que acceden simultáneamente miles de personas. Para ser precisos, se trata de una base de datos relacional, pero las bases de datos relacionales son el tipo más común de base de datos y te dan una idea general.

Parece bastante complejo, pero por eso la tecnología es tan valiosa. Estas «hojas de cálculo» se denominan tablas y existen relaciones entre ellas. Por ejemplo, una tabla puede contener el nombre y la dirección de un cliente, mientras que otra tabla contiene más información sobre ese cliente. La segunda tabla hace referencia al cliente de la primera a través de un ID de cliente. Esa es la parte relacional de las bases de datos relacionales.

Para acceder a estos datos, debe utilizar un lenguaje llamado SQL. El SQL es un lenguaje similar al inglés que entienden las bases de datos. Es casi idéntico en todos los tipos de bases de datos. Permite a los usuarios consultar datos utilizando «select» o modificar datos utilizando «insert», «update» y «delete». Hay otra categoría de SQL llamada DDL. Los administradores utilizan los DDL para gestionar la base de datos, por ejemplo, para crear o eliminar tablas.

¿Quién utiliza la base de datos y cómo?


Escribir SQL no es demasiado difícil, pero no es habitual que las personas que trabajan con bases de datos conozcan SQL o lo utilicen. La mayoría de las personas utilizan aplicaciones que traducen lo que intentan hacer a SQL.

Por lo general, hay tres tipos de cuentas en las bases de datos:

  • Los administradores de bases de datos, o DBA, son responsables de gestionar la base de datos. A menudo escriben SQL, pero también utilizan aplicaciones diseñadas para administradores. Estas facilitan ciertas operaciones al eliminar la necesidad de escribir SQL. Los DBA tienen acceso ilimitado a la base de datos y a los datos. Pueden acceder a cualquier cosa y cambiar lo que quieran. Además de las cuentas DBA individuales, los DBA suelen tener acceso a cuentas de base de datos privilegiadas especiales integradas. Por lo general, también tienen acceso al sistema operativo del servidor de la base de datos.
  • Las cuentas de aplicación no son para personas reales. Los servidores de aplicaciones las utilizan para acceder a los datos de la aplicación. Los usuarios finales reales utilizan el software de los servidores de aplicaciones, y ese software envía SQL a la base de datos utilizando una cuenta de aplicación.
  • Las bases de datos a veces tienen cuentas para analistas y otras personas que necesitan acceso directo a los datos. A veces escriben SQL, pero a menudo utilizan herramientas especiales para acceder a los datos.

El modelo de seguridad de bases de datos

Las bases de datos tienen dos mecanismos para dar acceso a los usuarios. Los «privilegios» otorgan a los usuarios derechos globales, como el derecho a leer cualquier tabla de la base de datos. Estos suelen ser para los administradores de bases de datos, a quienes se les otorgan derechos de superusuario. Los «permisos» otorgan a los usuarios acceso a tablas o columnas específicas. Estos son para todas las demás cuentas, a las que se les concede acceso solo a información concreta.

Por lo general, los privilegios y permisos se otorgan a través de un sistema o roles, en lugar de directamente a cada usuario. Un rol es un conjunto de privilegios y permisos que se pueden otorgar a los usuarios u otros roles.

La aplicación debe tener acceso a todos los datos y siempre tiene permiso para acceder a todo. La capa de seguridad que concede a cada usuario final acceso solo a algunos de los datos se encuentra dentro de la aplicación. Los servidores de aplicaciones realizan la autenticación y autorización de los usuarios finales. La lógica interna del servidor de aplicaciones se encarga de garantizar que los usuarios finales solo puedan acceder a lo que están autorizados a hacer. Desde la perspectiva de la base de datos, la aplicación tiene acceso a todos los datos.

Las fortalezas y los retos de la seguridad de las bases de datos

Puede habilitar fácilmente funciones de seguridad en las bases de datos, como el cifrado de datos en tránsito y datos en reposo. También puede activar reglas de política de contraseñas integradas. Más importante aún, la autenticación de bases de datos es muy madura, y es poco probable que alguien pueda conectarse sin un nombre de usuario y una contraseña válidos.

Sin embargo, el mayor problema es que la mayoría de las cuentas tienen acceso a todos los datos. Los administradores de bases de datos tienen acceso a todo debido a sus privilegios administrativos. La cuenta de la aplicación puede acceder a todo porque la aplicación lo necesita. Los analistas y otras cuentas pueden tener permisos más limitados, pero muchas veces también tienen acceso a la mayoría (si no a todos) los datos.

Esto supone un reto, ya que la forma en que utilizamos las bases de datos no se ajusta al modelo de seguridad de las mismas. No hay forma de limitar el acceso de los administradores de bases de datos o de las aplicaciones, y estas cuentas representan casi toda la actividad de la base de datos.

Amenazas a las bases de datos

Dado que las conexiones a la base de datos siempre utilizan usuarios y contraseñas válidos, las amenazas se limitan a las conexiones autenticadas. Las conexiones pueden provenir de usuarios reales o de alguien que se haga pasar por ellos. A continuación se muestra la lista de amenazas:

  • Amenaza interna del administrador de bases de datos (DBA). Se trata de la amenaza de abuso de privilegios por parte de un administrador de bases de datos. Aunque los DBA suelen ser personas de confianza, su acceso sin restricciones los convierte en un riesgo para la seguridad.
  • Compromiso de la cuenta del DBA. Se trata de una amenaza externa de que alguien robe las credenciales del DBA. Esto puede ocurrir, por ejemplo, a raíz de una violación de la seguridad del ordenador del DBA. También podría tratarse del robo de credenciales de una cuenta privilegiada compartida, como SYS o SA.
  • Compromiso de la cuenta de la aplicación. Puede tratarse de una amenaza interna o externa. Se trata de obtener acceso a las credenciales de la aplicación. Podría ser un administrador o desarrollador de la aplicación con acceso a las credenciales (amenaza interna) o un agente externo que las haya obtenido de un archivo de configuración (amenaza externa).
  • Compromiso de la aplicación. Puede tratarse de una amenaza interna o externa. Por ejemplo, explotar una vulnerabilidad en la aplicación (como una inyección SQL). También podría tratarse de desarrolladores que abusan de su acceso al código de la aplicación.
  • Otro abuso o compromiso de cuentas. Al igual que la cuenta del administrador de bases de datos, otras cuentas de bases de datos pueden ser objeto de abuso por parte de sus legítimos propietarios o comprometidas por un agente externo.
  • Acceso local. La mayoría de las bases de datos permiten conexiones no autenticadas desde cuentas específicas del sistema operativo en el servidor de la base de datos. Esto significa que obtener acceso a estas cuentas en el servidor de la base de datos le dará acceso a la base de datos. Incluso si dicho acceso está bloqueado, normalmente se puede habilitar o eludir.

Protección de una base de datos

Ahí es donde las cosas se ponen interesantes. Comenzaremos con las mejores prácticas más populares para proteger una base de datos. Esa orientación suele incluir:

  • Seguridad de las cuentas. Identifique las cuentas inactivas y ciérrelas. Siga los principios de privilegios mínimos para las cuentas activas y habilite una política de contraseñas.
  • Cifrado. Active el cifrado de los datos en tránsito y en reposo.
  • Parches. Asegúrese de instalar el último parche de seguridad.
  • Análisis de vulnerabilidades. Realice análisis de vulnerabilidades y solucione las que se detecten.

Aunque son importantes, ninguna de estas medidas aborda las amenazas a las bases de datos mencionadas anteriormente. No abordan ni una sola amenaza. Esto se debe a que los atacantes se han adaptado hace tiempo a las defensas estándar de las bases de datos.

Se necesita un nombre de usuario y una contraseña válidos para acceder a una base de datos, por lo que las medidas de seguridad de las cuentas no detendrán los ataques. El acceso tampoco implica rastrear paquetes de red o robar archivos, por lo que el cifrado no es útil. Por último, las bases de datos modernas rara vez tienen vulnerabilidades relacionadas con la autenticación, por lo que el análisis de vulnerabilidades y la aplicación de parches no se dirigen a estas amenazas.

Entonces, ¿cómo podemos proteger una base de datos?

La seguridad eficaz de las bases de datos aprovecha el control de la actividad. El control de la actividad combina medidas de detección y prevención que aplican la seguridad a nivel de sesión de la base de datos y de SQL. Soluciones como Core Audit le ayudarán a combatir estas amenazas reales.

Control de actividades

El control de actividades incluye auditoría de bases de datos, bloqueo avanzado de SQL, análisis de anomalías y análisis forense proactivo y reactivo. Aplica medidas de seguridad a las sesiones autenticadas que ejecutan actividades autorizadas.

Por ejemplo, las medidas para proteger las cuentas de DBA se centrarían en actividades que los DBA rara vez ejecutan. La detección podría alertar de DML (inserciones, actualizaciones y eliminaciones) o del acceso a datos confidenciales. Las medidas de detección más sencillas se aplicarían a nivel de sesión, inspeccionando los inicios de sesión fallidos y las fuentes de conexión, como los programas, las máquinas y las direcciones IP que utilizan los DBA para conectarse.

Las medidas preventivas para las cuentas de DBA podrían bloquear el acceso de los DBA a datos confidenciales. El bloqueo avanzado de SQL puede inspeccionar cada SQL y bloquear aquellos que acceden al esquema de datos. Otra medida preventiva para las cuentas de administrador de bases de datos es imponer una separación de funciones. Esto requiere que los administradores de bases de datos obtengan autorización previa del personal de seguridad para determinadas actividades.

Otras medidas de detección pueden proteger los miles de millones de SQL que provienen de la aplicación. El análisis de anomalías es una potente herramienta que puede inspeccionar cada SQL de la aplicación y alertar cuando se produce un cambio en el perfil de actividad de la aplicación.

Se pueden aplicar medidas similares a las conexiones locales o a cualquier otra cuenta.

Existen más capacidades para el análisis forense reactivo y proactivo. El primero tiene como objetivo investigar los eventos de seguridad, y el segundo proporciona visibilidad de la actividad para facilitar el diseño de controles, el análisis de deficiencias, la identificación de prácticas de seguridad deficientes y mucho más.

La conclusión es que controlar la actividad le permite proteger la base de datos contra todas las amenazas. Se necesita algo de tiempo y esfuerzo para determinar el mejor enfoque para cada subsección de la actividad, pero todo se puede proteger.

Reflexión Final

La seguridad de las bases de datos es imprescindible. Las bases de datos contienen los datos que debemos proteger, y salvaguardarlas es fundamental para la seguridad de la información. Los enfoques tradicionales son inadecuados y no logran proteger las bases de datos. Sin embargo, las soluciones modernas como Core Audit ofrecen una seguridad sólida y eficaz que reducirá significativamente el riesgo de una violación de datos.

Póngase en contacto con nosotros hoy mismo y déjenos ayudarle a proteger sus activos críticos.

Haz una Pregunta

Si tenes alguna pregunta o comentario, no dude en hacérnoslo saber. Estaremos encantados de escucharle.

Webinar Series: Database Compliance

Serie de Webinars Educativos
Cumplimiento Normativo de BBDD

Aprende a implementar los requisitos de cumplimiento normativo en sus bases de datos. Esta serie de seminarios web gratuitos, impartidos por expertos del sector, te guiará desde los conceptos básicos hasta ejemplos prácticos.

Esta serie de seminarios web educativos gratuitos ofrece una visión detallada del cumplimiento normativo en bases de datos. Con el apoyo de la división de investigación de BCR, los expertos de DBLandIT explorarán la aplicación práctica de diferentes normativas de cumplimiento en bases de datos. Aunque cada sesión se inspira en una normativa o un sector específico, todas ellas se aplican en mayor o menor medida a todos los requisitos de todos los sectores.

Robo de datos y protección de la privacidad

Introduce tus datos para inscribirte en esta serie de eventos:

Robo de datos y protección de la privacidad

Protegiendo la privacidad y previniendo el robo de datos: un enfoque desde la base de datos

El robo de datos es hoy uno de los problemas más críticos y costosos en el mundo de la ciberseguridad. A medida que las organizaciones almacenan volúmenes cada vez mayores de información sensible, los riesgos asociados —desde sanciones regulatorias hasta pérdidas millonarias y daño reputacional— aumentan de forma alarmante. El cumplimiento de normativas y las leyes de privacidad de datos no son opcionales: son esenciales para proteger a la empresa y a sus usuarios.

En este webinar vamos a analizar este desafío desde un ángulo muchas veces descuidado: la base de datos, el lugar donde reside la información más valiosa.

Nos enfocaremos en 4 aspectos clave:

1. Comprender los riesgos reales: Exploraremos las amenazas que afectan directamente a las bases de datos, tanto desde el exterior (ciberataques, robo de credenciales) como desde el interior (abuso de privilegios, accesos no autorizados).

2. Abordar el problema desde la fuente: Veremos cómo la protección efectiva comienza en el nivel donde se almacena y procesa la información, aplicando controles que permiten detectar, auditar, y en algunos casos prevenir actividades sospechosas directamente desde la base de datos.

3. Ver casos y ejemplos concretos: Presentaremos escenarios reales con soluciones aplicadas, que muestran cómo monitorear y auditar grandes volúmenes de actividad sin afectar el rendimiento de los sistemas con la ayuda de nuestra herramienta Core Audit.

4. Entender cómo estas soluciones reducen riesgos y mejoran el cumplimiento: Analizaremos cómo las herramientas y enfoques presentados contribuyen al cumplimiento de regulaciones.

Este encuentro está pensado para profesionales de seguridad, cumplimiento y tecnología que buscan enfoques prácticos y efectivos para reducir la exposición al robo de datos y fortalecer la postura de privacidad de su organización.

Información Adicional

Lee este artículo de nuestro blog para obtener más información sobre el robo de datos, protección de la privacidad y PCI-DSS.

No pierdas la oportunidad de fortalecer la seguridad y el cumplimiento normativo de tu organización con un enfoque práctico y claro.

Registrate ahora y sumate a la conversación.

Disertante

Francisco Veiga

DBlandIT domain expert

Descuidar Bases de Datos es una Bomba de Tiempo

Descuidar Bases de Datos es una Bomba de Tiempo

En un entorno dominado por amenazas cibernéticas constantes, las organizaciones refuerzan sus defensas externas, pero muchas pasan por alto un riesgo crítico: la seguridad de sus bases de datos. Esta negligencia representa una crisis silenciosa en el núcleo digital de las empresas.

Vivimos en una era de amenazas cibernéticas implacables. Los titulares hablan de ataques de ransomware, violaciones de datos y sofisticadas campañas de phishing. En respuesta, las organizaciones suelen apresurarse a reforzar sus defensas perimetrales, actualizar la seguridad de los puntos finales e implementar las últimas herramientas de supervisión de redes. Si bien estas medidas son sin duda importantes, se está gestando una crisis silenciosa en el corazón digital de muchas organizaciones: las bases de datos descuidadas.

Piénselo. ¿Dónde residen sus datos más críticos? La información de los clientes, los registros financieros, la propiedad intelectual, los datos sanitarios confidenciales… todo ello se canaliza a través de sus bases de datos. Esto las convierte en el objetivo definitivo de los actores maliciosos. Una violación a nivel de la base de datos puede tener consecuencias catastróficas, muy superiores al impacto de un punto final comprometido o una interrupción temporal de la red.

Sin embargo, ¿por qué la seguridad de las bases de datos suele quedar en un segundo plano? Hay varios factores que contribuyen a este peligroso descuido:

  • La mentalidad de «ojos que no ven, corazón que no siente»: las bases de datos funcionan entre bastidores y, a menudo, son gestionadas por equipos especializados. Esto puede dar lugar a una falta de visibilidad y comprensión entre los responsables de seguridad en general con respecto a su verdadera vulnerabilidad.
  • Visión estrecha impulsada por el cumplimiento normativo: aunque normativas como el RGPD, la HIPAA y la PCI DSS suelen abordar la protección de datos, su enfoque puede ser a veces más amplio, haciendo hincapié en los controles de acceso y la seguridad perimetral en lugar de en las medidas de seguridad granulares necesarias dentro de la propia base de datos.
  • El factor «poco atractivo»: seamos realistas, la seguridad de las bases de datos no siempre acapara los titulares como un exploit de día cero o un ataque de un Estado-nación. Puede parecer compleja, técnica y menos impactante a primera vista que ver cómo un cortafuegos bloquea una conexión maliciosa.
  • La ilusión del retorno de la inversión: calcular el retorno directo de la inversión en actualizaciones de seguridad de bases de datos puede resultar complicado. Es más fácil cuantificar el coste de un nuevo cortafuegos que el beneficio aparentemente intangible de prevenir una violación de datos.

Pero seamos sinceros: ¿puede su organización permitirse realmente no dar prioridad a la seguridad de las bases de datos?

Usted conoce las consecuencias de una violación de datos. Eso es lo que ocurre cuando alguien accede a su base de datos. Un coste que puede alcanzar millones de dólares en multas reglamentarias, honorarios legales, indemnizaciones a clientes, investigaciones forenses y mucho más. Además de los efectos duraderos del daño irreversible a la reputación cuando se pierde la confianza de los clientes y las partes interesadas.

Base de datos: tu prioridad desde el minuto cero

La realidad es que una seguridad sólida de las bases de datos no es solo otro elemento más de su lista de comprobación de seguridad, sino que es la base sobre la que se sustentan todas las demás medidas de seguridad. Es la prioridad cero. Sin ella, todos sus sofisticados cortafuegos y sistemas de detección de puntos finales pueden estar simplemente protegiendo una cámara acorazada vacía.

Piénselo de esta manera: no construiría una fortaleza con paredes endebles alrededor de una cámara del tesoro. Su base de datos es esa cámara del tesoro. Exige la protección más sólida y sofisticada que pueda permitirse.

Invertir en seguridad de bases de datos: una inversión a su futuro

El argumento de que la seguridad de las bases de datos es difícil de rentabilizar es erróneo. Piense en los posibles costes que se evitan al prevenir una filtración de datos. El ahorro en multas, litigios, pérdida de clientes y daños a la reputación supera con creces la inversión en seguridad de bases de datos.

Pero lo más importante es que pasarse a una solución moderna de seguridad de bases de datos le permitirá ahorrar dinero. Esto se debe a que las soluciones modernas pueden hacer más con menos:

  • Menor impacto en la base de datos. Core Audit tiene un impacto insignificante en sus servidores de bases de datos, lo que le da más poder para gestionar su negocio.
  • Menos hardware. Core Audit requiere menos recursos para funcionar. Ahorrará dinero en CPU, memoria y espacio en disco. Podrá hacer más con menos.
  • Menos tiempo. Con informes y alertas más eficientes, análisis de anomalías y mucho más, dedicará menos tiempo a la seguridad de las bases de datos.
  • Visibilidad completa. Con análisis forenses proactivos, obtendrá una visibilidad completa de todo lo que ha ocurrido en su base de datos. Sabrá lo que está pasando, por lo que podrá mejorar las prácticas de seguridad y diseñar controles adecuados.
  • Mayor seguridad. Y lo más importante, obtendrá una mayor seguridad. Podrá defenderse de cualquier amenaza y garantizar que sus datos estén bien protegidos.

Todo esto se traduce en dinero. Dinero real en hardware y recursos humanos, por no hablar de evitar los costes de las catástrofes.

No persigas tendencias y protege lo que más importa

Es hora de ir más allá del atractivo de las soluciones de seguridad de moda y centrarse en la verdad fundamental: sus datos son su activo más valioso y su base de datos es su principal guardián. Una postura de seguridad de bases de datos sólida y bien mantenida no es solo una buena idea, es una necesidad empresarial.

En lugar de adoptar al azar la última moda en seguridad, dé un paso atrás y realice una evaluación exhaustiva del panorama de seguridad de su base de datos. ¿A qué amenazas se enfrenta y está preparado para hacerles frente? Invierta en soluciones que le proporcionen la protección que necesita.

No espere a que se produzca una violación de datos para convencerse. El coste de la inacción supera con creces la inversión en seguridad moderna para bases de datos. Haga de la seguridad de las bases de datos su prioridad número uno hoy mismo y garantice la seguridad y la resiliencia a largo plazo de su organización. Su futuro depende de ello.

Haz una Pregunta

Si tenes alguna pregunta o comentario, no dude en hacérnoslo saber. Estaremos encantados de escucharle.