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.

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.

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!

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.

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!

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.

¿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.

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.

El seguimiento de los cambios en los datos es una piedra angular del mantenimiento de registros y la integridad de los datos. En el mundo altamente regulado de la banca y las instituciones financieras, la capacidad de realizar un seguimiento preciso y reconstruir los cambios en los datos no es solo una buena práctica, sino un requisito normativo fundamental.

Las instituciones financieras manejan información de clientes y datos transaccionales en los que incluso una alteración menor y no documentada puede tener importantes implicaciones fiscales y legales. Este artículo explora el seguimiento de los cambios en los datos y examina su implementación práctica en las bases de datos Oracle y SQL Server.

¿Qué es el seguimiento de los cambios en los datos?

En lo que respecta a la auditoría, el mantenimiento de registros y la integridad de los datos, hay tres medidas que los clientes encuentran confusas:

• La auditoría de consultas tiene como objetivo registrar todas las solicitudes de acceso para ver los datos. Este tipo de auditoría tiene como objetivo combatir el robo de datos mediante la inspección y/o el control de quién accede a qué. Eso es algo en lo que podemos ayudarle, pero no entra dentro del alcance de este artículo.
• La auditoría de modificación de datos tiene como objetivo evitar cambios no autorizados mediante la inspección y/o el control de quién cambia los datos. Esto incluye insertar filas, eliminar datos o modificar registros. También podemos ayudarle con esto, pero no entra dentro del alcance de este artículo.
• El seguimiento de cambios en los datos tiene como objetivo rastrear el linaje de cada dato, lo que le permite deshacer los cambios. Ese es el tema de este artículo, y vamos a explicarlo un poco más.

Entonces, ¿en qué se diferencia el seguimiento de cambios en los datos de la auditoría de modificaciones?

Supongamos que tenemos una columna de saldo y alguien emite un SQL que lo cambia. Por ejemplo:

saldo = saldo + 1000

En la auditoría, registramos el SQL, quién lo ejecutó y cuándo. En el seguimiento de cambios en los datos, registramos los valores anteriores y nuevos del saldo (por ejemplo, 10 000 y 11 000). Esos valores no están en el SQL, ya que el SQL solo pidió añadir 1000 al valor anterior.

Si el SQL anterior modificó 10 filas, la auditoría registrará el SQL y el hecho de que modificó 10 filas. Sin embargo, la auditoría no enumerará qué filas cambiaron. El seguimiento de cambios en los datos registrará cada cambio, enumerando los 10 valores anteriores y los 10 nuevos.

Del mismo modo, si alguien eliminó varias filas, la auditoría registrará el SQL y el número de filas eliminadas. El seguimiento de cambios registrará los valores de cada fila eliminada.

El seguimiento de cambios en los datos es un requisito importante común en entornos altamente regulados, como bancos e instituciones financieras. Significa que conoceremos los valores antes y después de cada cambio. Esto es fundamental para llevar un registro detallado.

Las Regulaciones

El seguimiento de los cambios en los datos es la piedra angular de un buen mantenimiento de registros. Significa que conocemos el origen de cada dato y podemos revertirlo si alguien realiza un cambio no autorizado. Por lo tanto, es un requisito de todas las regulaciones de cumplimiento para bancos y otras instituciones financieras.

En los Estados Unidos, la FINRA (Autoridad Reguladora de la Industria Financiera) y el FFIEC (Consejo Federal de Examen de Instituciones Financieras) publican directrices para bancos e instituciones financieras.

Por ejemplo, la norma 4511 de la FINRA y la norma 17a-4 de la SEC en la que se basa tratan sobre el mantenimiento de registros electrónicos y exigen que el registro de auditoría incluya «todas las modificaciones y eliminaciones del registro o de cualquier parte del mismo» (17a-4(f)(2)(i)(A)(1)).

Existen directrices similares del BCE (Banco Central Europeo), la BaFin (Bundesanstalt für Finanzdienstleistungsaufsicht) en Alemania, la ACPR (Autorité de contrôle prudentiel et de résolution) en Francia y la CNMV (Comisión Nacional del Mercado de Valores) en España.

En América Latina, los reguladores también tienen requisitos estrictos de la CNBV (Comisión Nacional Bancaria y de Valores) en México, la SFC (Superintendencia Financiera de Colombia) en Colombia, la SBS (Superintendencia de Banca, Seguros y Administradoras Privadas de Fondos de Pensiones) en Perú y muchos más.

BCBS 239 (Comité de Supervisión Bancaria de Basilea – Principios para la agregación eficaz de datos de riesgo y la presentación de informes de riesgo) es una guía bancaria global que influye en la mayoría de los reguladores de todo el mundo. La mayoría de las interpretaciones tienden a coincidir en que también exige este tipo de registro detallado.

Implementaciones

El seguimiento de los cambios en la base de datos es posible a través de diferentes mecanismos. Aunque cada base de datos es ligeramente diferente y se revisa a continuación, los principios generales y las ventajas e inconvenientes son similares.

Los desencadenadores son fragmentos de código que se ejecutan cuando se producen cambios en los datos. Uno de los métodos más sencillos para realizar un seguimiento de los cambios en una base de datos es utilizar un desencadenador que registre los cambios en una tabla de auditoría. Esto es algo que cualquier administrador de bases de datos puede implementar en cualquier base de datos.

Sin embargo, los disparadores tienen un gran inconveniente: un alto impacto en el rendimiento. El registro adicional en la tabla de auditoría forma parte de la transacción y la ralentiza considerablemente. El impacto típico es de al menos un 100 %, lo que hace que todo tarde el doble de tiempo.

Los desencadenantes ligeros son una variante de la implementación clásica de los desencadenantes. En lugar de una inserción, ejecutan un SQL ficticio que incluye los datos que han cambiado. El uso de un SQL ficticio reduce significativamente la sobrecarga de rendimiento. Core Audit Full Capture puede ver estos SQL internos en los desencadenantes, extraer los datos y registrarlos en el servidor Core Audit.

Una de las ventajas de los desencadenantes ligeros es que permiten correlacionar los cambios en los datos con el resto de los datos de auditoría, incluida la sesión exacta en la que se produjeron.

Los desencadenantes ligeros funcionarán en cualquier base de datos siempre que se disponga de la tecnología Core Audit Full Capture para recopilar los datos. Por ejemplo, la información de los desencadenantes ligeros de SQL Server almacenada en Core Audit puede tener este aspecto:

Time	2025/05/16 15:38:19
Session	714000000000002308 (link to Core Audit session)
Username	sa
Session Info	OSQL-32 local
Owner	test
Table	emp
Operation	UPDATE
New Values	id=1 first=’John’ last=’Doe’ salary=11000
Old Values	id=1 first=’James’ last=’Doe’ salary=10000

Los registros de rehacer o registros de transacciones son nombres diferentes para lo mismo. Se trata de registros que existen en todas las bases de datos y que registran cada cambio en los datos. Son una parte fundamental de la base de datos, ya que permiten la recuperación tras un fallo y la recuperación en un momento determinado, lo que garantiza la integridad de los datos.

Dado que estos registros siempre existen y registran cada cambio, se pueden extraer para obtener los cambios que se desean rastrear. La principal ventaja de extraer estos registros es que no forma parte del SQL y no ralentiza las transacciones de la base de datos.

La desventaja es que la extracción de estos registros aumenta el consumo de recursos en el servidor y, lo que es más importante, se limita a la información almacenada en los registros. Por ejemplo, algunas bases de datos registran la información de la sesión, mientras que otras solo registran el cambio en sí, sin ninguna referencia a quién lo ha realizado. A continuación se ofrece información específica para cada tipo de base de datos, incluidas las desventajas que dependen de la base de datos.

Registros de rehacer de Oracle

Puede controlar la información de los registros de rehacer de Oracle a través de la configuración de registro suplementario de Oracle. Si su objetivo es extraer cambios de los registros, debe, como mínimo, ejecutar este SQL:

ALTER DATABASE ADD SUPPLEMENTAL LOG DATA;

Sin ello, «update» a veces aparece como «delete» e «insert». Puede habilitar el registro adicional para registrar más información sobre claves primarias, otras columnas y mucho más.

Oracle Logminer le permite consultar los registros de rehacer en línea y archivados para extraer información de los registros de rehacer de Oracle.

Core Audit puede utilizar Logminer para consultar los registros de rehacer y almacenar la información en el servidor Core Audit. Por ejemplo, la información de Logminer almacenada en Core Audit puede tener este aspecto:

Time	2025/05/15 12:22:55
Session	68
Serial#	3787
Username	HRAPP
Session Info	login_username=HRAPP client_info= OS_username=bluecore Machine_name=WORKGROUP\BLUECORE2 OS_terminal=BLUECORE2 OS_process_id=5976:5220 OS_program_name=sqlplus.exe
Owner	HRAPP
Table	SALARIES
Operation	UPDATE
Redo SQL	update “HRAPP”.”SALARIES” set “SALARY” = ‘11000’ where “SALARY” = ‘10000’ and ROWID = ‘AABnEEAAEAAAAJUAAE’;
Undo SQL	update “HRAPP”.”SALARIES” set “SALARY” = ‘10000’ where “SALARY” = ‘11000’ and ROWID = ‘AABnEEAAEAAAAJUAAE’;
New Values	Salary=11000
Old Values	Salary=10000
Field

Registros de transacciones de SQL Server

Los registros de transacciones de SQL Server no contienen información de sesión, por lo que es imposible vincular los cambios a los usuarios que los realizaron.

Core Audit puede aprovechar el motor de replicación de SQL Server para extraer información de los registros de transacciones. Se trata de una extracción de alto rendimiento casi en tiempo real, pero ocupa el motor de replicación, por lo que no se puede utilizar la replicación de SQL Server junto con la extracción de registros de transacciones de Core Audit.

Por ejemplo, la información de los registros de transacciones de SQL Server almacenada en Core Audit puede tener este aspecto:

Time	2025/05/16 13:42:33
Owner	test
Table	emp
Operation	update
Redo SQL	update [dbo].[emp] set [salary] = 11000 where [id] = 1

SQL Server también cuenta con mecanismos integrados para extraer información de los registros de transacciones. Estos mecanismos también se limitan a la misma información disponible en los registros. El seguimiento de cambios es el mecanismo antiguo, y la captura de datos modificados (CDC) es el más reciente. CDC es mejor, pero aún así requiere cierta administración y mantenimiento regular, y los resultados no son fáciles de entender.

Resumen

El seguimiento de los cambios en los datos es vital para un buen mantenimiento de los registros y esencial en los sistemas bancarios y financieros.

Este requisito tiene múltiples opciones de implementación, y Core Audit las admite todas. Aunque la mejor opción puede depender de su entorno, muchos clientes consideran que las limitadas desventajas de los desencadenantes ligeros y la alta calidad de la información son convincentes.

Como profesionales de la seguridad, estamos programados para mirar hacia afuera. Las luces rojas intermitentes, los escaneos de puertos siniestros, los rumores de sofisticadas APT: estas son las narrativas que captan nuestra atención. Construimos fortalezas digitales, fosos de cortafuegos y torres de vigilancia de sistemas de detección de intrusiones, todo ello apuntando hacia un adversario externo sin rostro.

¿Y por qué no íbamos a hacerlo? A los medios de comunicación les encantan las buenas historias sobre hackers. Los titulares gritan sobre ataques de estados-nación y bandas de ransomware que secuestran empresas. Es un drama apasionante, lleno de destreza técnica y figuras oscuras.

Pero, ¿y si la verdadera amenaza no acecha en la oscuridad exterior, sino que se encuentra cómodamente dentro de tus propias paredes? ¿Y si las llaves de tu reino ya están en manos de alguien en quien confías, o crees confiar?

Dejemos de lado las estadísticas abstractas por un momento y pintemos un cuadro.

Imagina a Jennifer, una administradora de bases de datos que lleva cinco años en la empresa. Conoce los sistemas al dedillo, tiene acceso privilegiado a tus datos más sensibles y, en general, se la considera una empleada fiable. Pero Jenny está ahogada en deudas personales y una figura oscura en Internet le ha ofrecido mucho dinero a cambio de una copia de los registros de los clientes. Es algo puntual, se dice a sí misma. Nadie lo sabrá nunca.

O pensemos en Mark, un gerente de ventas descontento que se siente ignorado para un ascenso. Todavía tiene acceso a datos críticos de ventas y decide sabotear sutilmente los registros, sesgando los informes y socavando a sus antiguos superiores. Es su forma de vengarse, un acto silencioso de venganza digital.

Luego está David, un becario bienintencionado pero despistado, que trabaja desde casa y deja su ordenador desatendido. Un amigo malintencionado de su compañero de piso se aprovecha del acceso interno legítimo de David. Navega con facilidad por su red supuestamente segura y accede directamente a sus bases de datos.

No se trata de villanos de Hollywood con sudaderas con capucha. Son personas normales que se enfrentan a presiones cotidianas y que, de forma intencionada o no, pueden convertirse en conductos o en la fuente directa de devastadoras violaciones de datos.

Piénsalo:

• Tienen las llaves: los empleados internos poseen credenciales y permisos legítimos que los atacantes externos solo pueden soñar con obtener. Ni siquiera necesitan eludir tus defensas perimetrales cuidadosamente construidas.
• Conocen el terreno: están familiarizados con tus protocolos de seguridad, comprenden las estructuras de tus bases de datos, pueden localizar dónde se encuentran los datos y saben cómo modificarlos. Utilizan estos datos a diario y los conocen al dedillo. Por eso los ataques internos son mucho más peligrosos y difíciles de detectar.
• El daño puede ser catastrófico: un empleado malintencionado con el acceso adecuado puede extraer grandes cantidades de datos y modificar información crítica sin que nadie se dé cuenta. Pueden causar un daño irreparable a la reputación y a los resultados de su organización.

Dedicamos mucho tiempo y energía a construir muros, pero ¿qué pasa con las puertas y ventanas que dejamos abiertas a sabiendas para los que están dentro? Supervisamos meticulosamente el tráfico de red en busca de anomalías, pero ¿aplicamos el mismo nivel de escrutinio a la actividad interna?

La cifra del 20 % no es solo una estadística; representa empresas reales, personas reales y consecuencias reales. Aparece cada año en el DBIR (Informe de investigación sobre violaciones de datos) de Verizon, y es una parte significativa del panorama de las violaciones que no podemos permitirnos ignorar.

La seguridad centrada en los datos no es solo una «mejor» defensa contra las amenazas externas; es la única defensa verdadera contra el enemigo interno. Al centrarse en proteger los datos en sí, se deja sin poder al atacante, ya sea externo o interno, incluso si logra penetrar en su perímetro o aprovechar credenciales legítimas.

Recuerde que el hombre del saco en el borde de la red no suele ser un hacker experto, sino un script kiddy que busca una vulnerabilidad oportunista. El verdadero hombre del saco es el que toca sus datos todos los días y puede causar un daño inimaginable con solo pulsar unas teclas.

Tenga en cuenta estas prácticas recomendadas de seguridad de bases de datos.

Imagine que Jennifer intenta extraer registros de clientes, pero es detectada por una alerta de anomalía de Core Audit o se le deniega el acceso por una política de bloqueo SQL de Core Audit. Imagine que los intentos de Mark de sabotear los datos se marcan inmediatamente como un cambio en su perfil de actividad. Imagine que el amigo que utiliza el ordenador de David no consigue extraer los datos porque está accediendo a una cantidad inusual de información confidencial.

No se trata de desconfiar de todos los miembros de su organización. Se trata de reconocer que la naturaleza humana es compleja, que las circunstancias cambian y que incluso las personas bienintencionadas pueden ser explotadas. Se trata de implementar una estrategia de seguridad que asuma que se producirá un ataque a la base de datos, independientemente de su origen.

Así que, la próxima vez que revise su postura de seguridad, tómese un momento para mirar hacia dentro. Más allá de las deslumbrantes luces del panorama de amenazas externas, existe una realidad más silenciosa, quizás menos dramática, pero igualmente peligrosa dentro de sus propias paredes digitales. No permita que el enfoque en el exterior le impida ver las vulnerabilidades internas. Sus datos, y el futuro de su organización, dependen de ello. Es hora de sentir el peso de la amenaza interna, no solo de reconocer su existencia.

¿Por qué es tan importante la seguridad de las bases de datos?

Una brecha de datos grave significa que alguien ha accedido a su base de datos y ha robado datos. Las bases de datos son las guardianas de sus datos, y cualquiera que quiera obtenerlos debe hacerlo a través de la base de datos.

Aunque debe proteger todos los componentes de la infraestructura, ninguno es más importante que la base de datos. Independientemente de cómo se inicien, todas las brechas terminan en la base de datos.

Muchas organizaciones no prestan suficiente atención a la seguridad de las bases de datos por diversas razones. Algunas no creen que sea posible protegerlas, otras piensan que no disponen de los recursos necesarios, les preocupan los costes, etc. Pero la verdad es que la tecnología adecuada y los conocimientos técnicos de los socios le permitirán proteger sus bases de datos a un precio asequible. Y esa protección es el paso más importante en la seguridad informática.

Amenazas a las bases de datos

Por extraño que parezca, Internet está lleno de tonterías sobre las amenazas a las bases de datos. Incluso blogs y artículos de fuentes acreditadas repiten estas afirmaciones sin fundamento. La siguiente lista pretende aclarar estos hechos:

Amenazas Internas

Sí, la amenaza interna es un gran problema. Para cuantificarla con mayor precisión, alrededor del 20 % de las brechas de datos involucran a un actor interno malintencionado. El informe DBIR de Verizon es una buena fuente de información, ya que cada año presenta cifras similares. Algunos países, como Alemania, informan que la amenaza interna alcanza hasta un 26 %. Independientemente de si se trata de 1 de cada 4 o 1 de cada 5 brechas, se trata de una amenaza significativa que no debemos ignorar.

Esta amenaza es otra razón más por la que las organizaciones deben invertir en la seguridad de las bases de datos. Las defensas centradas en los datos, en general, y la seguridad de las bases de datos, en particular, son las únicas defensas contra los actores internos.

Amenazas externas

La mayoría de los ataques provienen de agentes externos. Sin embargo, es fundamental comprender cómo estos agentes penetran en la base de datos. Dado que las bases de datos no deben estar conectadas directamente a Internet, todos estos ataques deben realizarse a través de un intermediario.

Desde el punto de vista de la seguridad de las bases de datos, es irrelevante si el atacante ha entrado en la organización mediante un ataque de phishing, algún otro tipo de ataque de ingeniería social, un error de configuración o cualquier otra cosa. Lo importante es que ha entrado y ahora va a por tus datos. El resto de esta lista desglosa cómo ocurre esto.

Acceso al servidor local

Aunque es difícil cuantificar la amenaza que supone el acceso al servidor de la base de datos local, es posible establecer un límite mínimo. Ten en cuenta que más del 40 % de las brechas de datos implican ransomware y que, por definición, casi todos los ataques de ransomware deben comprometer el servidor de la base de datos. Simplemente no hay otra forma de cifrar los archivos de datos.

Por lo tanto, independientemente de si la amenaza del acceso al servidor local es del 40 % o superior, se trata de una amenaza significativa que no podemos ignorar.

Cuentas válidas

Las amenazas a través de cuentas válidas incluyen el robo de credenciales, la suplantación de identidad y ataques similares. Pero todo lo demás en esta lista de amenazas, como las amenazas internas, las inyecciones SQL y otras, también se manifiesta a través de una cuenta válida. Aunque no podemos estimar el nivel exacto de amenaza de las cuentas válidas, estas son el método principal para penetrar en una base de datos.

Pero, ¿por qué agrupar el robo de credenciales con, por ejemplo, el abuso de privilegios por parte de actores internos? Se debe a la forma en que abordamos estas amenazas. Si no podemos confiar en la actividad de las conexiones autenticadas, debemos identificar la actividad maliciosa dentro de esas conexiones. No importa si alguien robó las credenciales o si el usuario abusó de sus privilegios. Más adelante se profundizará en este tema.

Inyección SQL

Puede resultar sorprendente, pero no hay cifras fiables sobre el nivel de amenaza de la inyección SQL. Aunque se estima que es alto, especialmente para las aplicaciones conectadas a Internet, diferentes fuentes publican cifras muy dispares.

Aunque la inyección SQL es solo un tipo de vulnerabilidad de las aplicaciones, es sin duda la más común. Las soluciones de seguridad para aplicaciones web, como WAF, no logran abordarla de manera consistente, mientras que las soluciones modernas de seguridad de bases de datos, como Core Audit, ofrecen una defensa eficaz. Las defensas modernas de bases de datos abordan más que la inyección SQL y, hoy en día, son la solución preferida. La situación actual contrasta fuertemente con la de hace dos décadas, cuando surgió la tecnología WAF.

Errores humanos

Los errores humanos pueden crear vulnerabilidades en las bases de datos. Por ejemplo, al otorgar demasiados privilegios, descuidar el cierre de cuentas, utilizar contraseñas sencillas, etc. Sin embargo, las pruebas sugieren que esto no es una causa significativa de brechas de la seguridad de las bases de datos. Si bien los errores humanos son una razón fundamental para la penetración del perímetro, no son una causa para la penetración de las bases de datos.

No obstante, identificar y corregir dichos errores es una buena práctica. Establecer procesos de control de cambios (véase más abajo) es un paso esencial en esa dirección.

Riesgos menores

Algunas amenazas teóricas suponen amenazas minúsculas para las bases de datos. Las mencionamos porque existen afirmaciones de este tipo en diversos blogs y artículos. Sin embargo, son absurdas.

Las bases de datos modernas no tienen vulnerabilidades significativas, desbordamientos de búfer ni debilidades similares. Al menos, no las que son responsables de una brecha, ya que esta falta de vulnerabilidades es particularmente cierta en el caso de las vulnerabilidades relacionadas con la autenticación que permiten a los atacantes conectarse sin contraseña. No existe ningún paquete mágico ni puerta trasera secreta no documentada que permita a alguien acceder a su base de datos. Si bien es esencial aplicar parches de seguridad, es raro que se aproveche una vulnerabilidad de la base de datos sin un nombre de usuario y una contraseña válidos.

Además, no se debe conectar una base de datos directamente a Internet. Las bases de datos deben residir únicamente en redes internas seguras. Por lo tanto, las bases de datos no son vulnerables a los ataques de denegación de servicio (DoS). Y eso se aplica doblemente a los ataques de denegación de servicio distribuido (DDoS). Cualquier intento de proteger una base de datos contra tales ataques es inútil.

Resumen de amenazas

En resumen, una brecha de la base de datos aprovecha un usuario y una contraseña válidos para conectarse a la base de datos. Estas son las vías principales:

• Amenaza interna del administrador de bases de datos (DBA). Se trata de un abuso de privilegios por parte de un administrador de bases de datos.
• Compromiso de la cuenta del DBA. Se trata de un agente externo que ha penetrado el escritorio del DBA, ha robado la contraseña del DBA o la contraseña de una cuenta con privilegios compartidos (como SYS o SA).
• 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. Una brecha de este tipo suele ser obra de un agente externo, pero también puede ser un abuso de privilegios.
• Compromiso de la cuenta de la aplicación. Se trata de un agente externo que ha obtenido acceso a la contraseña de la aplicación, o de un agente interno que abusa de su acceso.
• Compromiso de la aplicación. Se trata de un exploit de una vulnerabilidad de la aplicación, como una inyección SQL.
• Otro abuso o compromiso de cuentas. Al igual que la cuenta DBA, otras cuentas de la base de datos pueden ser objeto de abuso por parte de sus legítimos propietarios o comprometidas por un agente externo.

Prácticas básicas

Las prácticas básicas de seguridad tienen como objetivo reforzar una base de datos, pero no abordan las amenazas comunes. Se trata de pasos esenciales, pero no impedirán una brecha de la seguridad.

1. Cifrado. Active el cifrado de red y de disco. Aunque ninguna amenaza común se dirige a los paquetes de red o a los archivos, es una buena práctica y fácil de implementar.
2. Seguridad de las cuentas:

• Inventario de cuentas. Haga una lista de todas las cuentas de la base de datos e identifique a las personas o aplicaciones asociadas a ellas.
• Cuentas inactivas. Cierre las cuentas inactivas.
• Cuentas individuales. Asegúrese de que todas las cuentas sean cuentas individuales, excepto las cuentas de aplicaciones y las cuentas de administración compartidas integradas (como SYS o SA).
• Contraseña. Asegúrese de que ninguna contraseña sea la contraseña predeterminada o una contraseña codificada.
• Política de contraseñas. Active las políticas de contraseñas que requieran una longitud mínima de contraseña, complejidad de contraseña, bloqueo de cuentas, etc.
• Privilegios mínimos. Asegúrese de que todas las cuentas tengan los privilegios mínimos que las personas necesitan para realizar sus tareas.

3. Parches. Instale todos los parches de seguridad para la base de datos y todo el software y las herramientas asociados. Esto incluye el software de aplicación, las herramientas de generación de informes, las herramientas de administración de bases de datos, las herramientas de gestión del rendimiento, etc.

4. Control de cambios. Implemente un proceso de control de cambios y valide de forma independiente que todos los cambios estén aprobados. Esto incluye cambios en la configuración, los usuarios, los permisos, los objetos de la base de datos, etc.

Buenas prácticas

Como se mencionó anteriormente, las medidas de seguridad básicas son esenciales, pero no pueden hacer frente a las principales amenazas. Para hacer frente a estas amenazas se utiliza el control de actividad, el método principal para la seguridad de las bases de datos.

Casi todas las amenazas provienen de conexiones válidas que utilizan privilegios adecuados. Por lo tanto, la única forma de hacerles frente es inspeccionando cada SQL en cada conexión y aplicando los controles detectivos o preventivos adecuados.

Dado que los controles de actividad tienen como objetivo garantizar que las conexiones solo realicen actividades «buenas», independientemente de si la amenaza es interna o externa, lo que importa es el perfil de actividad de la cuenta y cómo evitar que realice acciones maliciosas.

1. Cuentas DBA y conexiones locales. Por lo general, los administradores de bases de datos (DBA) no deben acceder a datos confidenciales. Muchas veces, tampoco ejecutan DML. Eso significa que alertar o bloquear estas actividades en las cuentas administrativas es una forma excelente de prevenir una brecha. Los controles internos de la base de datos no pueden hacer eso, pero el control avanzado de actividades sí. Estos controles mitigan cualquier amenaza que se manifieste a través de una cuenta privilegiada, incluido el abuso por parte de un DBA, el robo de credenciales y las conexiones locales.
2. Cuenta de aplicación. Las aplicaciones tienden a repetir las mismas construcciones SQL una y otra vez. Aunque puede haber varios cientos de miles de construcciones, en última instancia, todas se repiten. Un análisis de anomalías de la actividad de la aplicación es una forma excelente de identificar cambios en el perfil de actividad de la aplicación. Esto funciona para detectar inyecciones SQL, así como la mayoría de los tipos de comportamiento indebido de las aplicaciones.
   Aunque esto también detecta el abuso de la cuenta de la aplicación o el robo de credenciales, también se pueden detectar mediante controles de sesión (que se describen a continuación).
3. Actividad DDL. Ciertos tipos de actividad, como DDL y DCL, merecen precauciones adicionales. Los DDL permiten administrar la base de datos, y los DCL son un subtipo relacionado con la autorización (usuarios y concesiones). La práctica habitual es informar sobre estos SQL para garantizar que los cambios sean aprobados.
4. Tablas confidenciales. Controlar el acceso a los datos confidenciales es fundamental, y el análisis de anomalías es una medida eficaz para identificar cambios en el comportamiento relacionado con estas tablas. Esto permitirá detectar accesos inusuales por parte de los administradores de bases de datos u otras cuentas, cambios peligrosos en el comportamiento de la aplicación y mucho más.
5. Programas sensibles. Algunos programas no tienen restricciones integradas sobre lo que pueden hacer sus usuarios y les permiten ejecutar cualquier SQL. Los administradores suelen utilizar estos programas para gestionar la base de datos, y los analistas a veces escriben SQL para aprovechar al máximo las capacidades de la base de datos. La ausencia de restricciones merece una supervisión adicional que depende de cómo utilicen estas personas los programas. Puede implicar la supervisión del acceso a tablas sensibles, DML, anomalías, etc.
6. Sesiones y origen de la actividad. El control de sesiones es el tipo de control más sencillo y fácil de entender. Implica supervisar quién se conecta, desde dónde y cuándo. Los informes pueden referirse a un subconjunto de cuentas, como los administradores de bases de datos o la aplicación, para garantizar que todas las conexiones proceden de las fuentes esperadas. Las anomalías son alertas cruciales que destacan un cambio en el origen de la actividad (por ejemplo, una IP diferente), una hora inusual del día, un mayor volumen de actividad y mucho más.

Ponte a Prueba

Las siguientes preguntas evalúan su nivel de control sobre sus bases de datos. Si no está seguro, considere algunas de las mejores prácticas recomendadas anteriormente.

1. ¿Recibe alertas falsas positivas de su solución de seguridad de bases de datos?
   Ningún sistema de seguridad es perfecto. Todas las soluciones equilibran los falsos positivos y los falsos negativos (eventos de seguridad no detectados). No recibir falsos positivos significa que su seguridad es demasiado laxa o inexistente. Significa que no recibirá ninguna alerta aunque se produzca una brecha de seguridad.
2. ¿Sabe quién ha accedido a sus datos confidenciales durante la última semana?
   Saber quién accede a los datos confidenciales de su base de datos es un indicador clave de concienciación. Si no sabe la respuesta, es poco probable que sepa cuándo se produce un acceso malicioso. También es poco probable que pueda llevar a cabo una investigación forense satisfactoria de una brecha de seguridad.
3. ¿Sabe qué usuarios, programas e IP han accedido a su base de datos durante la última semana?
   Esa es una pregunta fundamental sobre el control de sesiones. Conocer las fuentes de actividad de su base de datos es un control esencial. Si no lo sabe, no sabrá si se ha producido un robo de credenciales y no podrá llevar a cabo una investigación forense.
4. ¿Cree que sabría si un intruso ha aprovechado el acceso local o una cuenta de DBA?
   Esa es una pregunta más compleja, ya que un intruso podría utilizar la misma fuente de actividad que el usuario real. Sin embargo, es una prueba crítica, ya que se trata de vectores de ataque muy populares.
5. ¿Cree que sabría si se ha producido un intento de inyección SQL?
   La inyección SQL se considera una amenaza importante y el principal vector de ataque a las aplicaciones. También es muy difícil de detectar, y el análisis de anomalías es el único método eficaz.

Una postura de seguridad adecuada debería permitirle responder a estas preguntas. Al fin y al cabo, cubren las vías más populares para la brecha de datos.

Reflexiones Finales

La seguridad de las bases de datos es fundamental para proteger tus datos. En este artículo se explican las principales amenazas, cómo abordarlas y cómo ponerse a prueba. Si no controla sus bases de datos, es mucho más probable que sufra una brecha de datos y es poco probable que se entere.

Toma el control de tus bases de datos. ¡Ponte en contacto con nosotros hoy mismo!