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.

Reflexiones Finales

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

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

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

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.