Muchas organizaciones se quedan cortas en lo que a control y visibilidad se refiere. ¿Tienes control sobre tus datos?
El control de los datos es la base de la seguridad de los datos. Es la esencia de todos los requisitos de cumplimiento y establecer el control es el núcleo de lo que hacemos.
Mientras navegamos por el final de este año y nos preparamos para el siguiente, examinemos este requisito básico. Nuestra experiencia nos dice que muchas organizaciones tienen dificultades con los fundamentos, pero siga leyendo y vea cuál es su situación.
¿Qué es el control?
Controlar los datos significa controlar el acceso a ellos. En otras palabras, controlar la actividad. Pero, ¿qué significa en la práctica y cómo lo hacemos?
Lo que todo el mundo sabe es que gestionar el acceso a los datos implica dos actividades:
Usuarios y permisos – ¿Quiénes son los usuarios y qué acceso necesitan?
Supervisión – ¿Qué está ocurriendo en la realidad?
Todo el mundo tiende a centrarse en la primera e ignorar la segunda. Pero la aplicación correcta tiene que ser diferente, porque es imposible asegurar los datos sin saber lo que está ocurriendo con ellos. No se puede proteger lo que no se ve.
Establecer controles sobre los usuarios y el acceso sin saber lo que ocurre en realidad carece de sentido. No sólo carece de visibilidad sobre si los controles están funcionando según lo previsto, sino que ni siquiera sabe qué cosas están sucediendo que necesita detener. Usted está asumiendo que sus usuarios y permisos se comportan como imaginaba, pero esa suposición suele ser errónea.
El conocimiento es poder
Saber lo que ocurre es la base de cualquier seguridad. Un guardia de seguridad ciego y sordo deambulando por los pasillos no podrá detener a los delincuentes. La visibilidad es la clave del éxito.
¿Tienes el control?
Por desgracia, muchas organizaciones se quedan cortas en lo que a visibilidad se refiere. Carecen de las herramientas necesarias para responder a preguntas básicas como:
¿Quién accedió a mis datos la semana pasada?
¿Qué programas se utilizaron para acceder a los datos?
¿A cuántos datos se accedió?
Sin respuestas a estas y otras preguntas similares, es imposible establecer controles eficaces. ¿Cómo puede determinar sobre qué debe informar o alertar? ¿Qué hay que evitar?
Cuando preguntamos a los clientes por qué configuran determinadas alertas, solemos obtener respuestas vagas como “me lo recomendaron”, “es una buena práctica”, “me parece una buena idea”, etcétera.
Por tanto, no es sorprendente que estos controles rara vez produzcan incidentes de seguridad. La falta de falsas alertas positivas es indicativa de una seguridad ineficaz, porque significa que hay muchos falsos negativos (sucesos no detectados).
Visualiza tu actividad como nunca antes
La seguridad ha cambiado mucho en los últimos 20 años y las tecnologías y soluciones nacidas a principios de la década de 2000 se consideran hoy en día obsoletas. Las soluciones modernas como Core Audit pueden dar una visibilidad sin precedentes de la actividad utilizando Proactive Forensics y ese es el primer paso recomendado en las implementaciones.
Con Core Audit Proactive Forensics, usted puede:
Visualizar fuentes de actividad para entender quién ejecuta actividad, cuánta, desde dónde y cuándo.
Investigar los patrones de actividad para comprender quién accede, a qué datos, cuándo y cuánto.
Profundizar en los subconjuntos de actividad y visualizar cada uno para determinar la mejor manera de controlarlo.
El análisis forense proactivo es una de las muchas funciones de Core Audit, como el análisis de anomalías, las auditorías declarativas, los controles preventivos y muchas más. Sin embargo, Proactive Forensics es el primer paso en las implementaciones que le ayuda a entender el perfil de actividad y determinar qué otros controles debe implementar.
No te conformes con menos
Si cree que comprende bien lo que ocurre dentro de sus bases de datos y aplicaciones, ¡enhorabuena! Pero si no es así, es hora de considerar una alternativa. Programe una demostración para ver lo que Core Audit puede ofrecerle y, a continuación, pruébelo en sus propios sistemas para experimentar una visibilidad real.
Póngase en contacto con nosotros hoy mismo y adopte el futuro de la seguridad de las bases de datos.
Presupuestos para un futuro seguro Optimiza el tuyo para 2025
A medida que nos adentramos en 2025, el panorama digital sigue evolucionando, trayendo consigo inmensas oportunidades e importantes riesgos. Las ciberamenazas son cada vez más sofisticadas y se dirigen a empresas de todos los tamaños. Para que las organizaciones prosperen, una estrategia de ciberseguridad sólida ya no es un lujo; es una necesidad básica.
Escasa inversión en ciberseguridad
En relación a su PIB, Latinoamérica invierte entre 4 y 5 veces menos en Ciberseguridad que Norteamérica. El crecimiento previsto de los presupuestos de Ciberseguridad en Latam también es inferior al de NA.
Al mismo tiempo, las brechas de datos en Latinoamérica están en su punto más alto. Diferentes estudios muestran cifras diferentes en cuanto a los países más atacados, y los primeros de la lista suelen ser México, Brasil, Colombia y Perú. Sin embargo, toda Latinoamérica está bajo ataque, con muchas brechas de datos exitosas.
Con mayores riesgos y menor inversión, América Latina debe invertir de forma MÁS INTELIGENTE. Es la única manera de luchar contra las olas de ataques si se tiene recursos limitados.
Una inversión más inteligente
Lo ideal sería poder comprar y utilizar muchas soluciones que aborden todos los riesgos posibles, pero eso no es realista. Nadie tiene presupuesto ni personal suficientes para hacer realidad esa fantasía.
La solución consiste en identificar unos pocos elementos críticos que impidan una filtración de datos y crear una inversión equilibrada en todos ellos. Hable con nosotros para obtener más información sobre cómo equilibrar el perímetro frente a los datos, los IPS frente a los IDS y mucho más. Permítanos ayudarle a crear en conjunto una defensa ganadora.
Ciberseguridad con un presupuesto optimizado
En Blue Core Research comprendemos la importancia de equilibrar las necesidades de seguridad con las limitaciones presupuestarias. Nuestro equipo de expertos trabaja en estrecha colaboración con los clientes para crear enfoques personalizados que se ajusten a su presupuesto y, al mismo tiempo, maximicen la protección de sus datos.
Cómo podemos ayudarle a optimizar su presupuesto de ciberseguridad
Comienza con una conversación para entender tus necesidades: Queremos entenderte a vos y tu situación particular. Tus motores, necesidades, expectativas, entorno, etc. Cuanto más sepamos sobre vos y tu organización, mejor podremos elaborar un plan que responda a tus necesidades y se ajuste a tu presupuesto.
Crear un enfoque personalizado: Nuestras soluciones pueden utilizarse de muchas maneras en función de los recursos disponibles. Sugeriremos un enfoque diferente para la implantación en función del número de sistemas, el personal disponible, el nivel de seguridad previsto, etc. Encontraremos la forma de sacar el máximo partido a sus recursos.
Precios agresivos: Queremos cuidar de tu negocio y vamos a trabajar en conjunto con vos para encontrar la manera. Podemos sugerirte diferentes niveles de seguridad y encontrar la forma de cubrir todo lo que necesites. Tenemos precios agresivos para ayudarle a cumplir sus objetivos presupuestarios.
Invertí en tranquilidad
Trabaja con nosotros para asegurarte de que tu presupuesto para 2025 incluya las soluciones de primera categoría que necesitas para luchar contra los ciberataques, las filtraciones de datos y mucho más.
Recordá que un plan presupuestario sólido no es un gasto, sino que es una inversión en el futuro de tu empresa.
Ponte en contacto con nosotros hoy mismo para hablar de tus necesidades específicas y saber cómo podemos ayudarte a protegerte de las inminentes amenazas.
Aprende más sobre el rendimiento del enmascaramiento de datos, un aspecto crítico de las soluciones actuales.
El enmascaramiento de datos no es una tarea cotidiana, así que ¿por qué es vital tener en cuenta el rendimiento?
Mientras que es de poca importancia si un proceso de enmascaramiento de datos tarda 5 segundos o 5 minutos, es crítico si tarda cinco días o no termina nunca. Los tiempos de ejecución imposiblemente largos no son inusuales y hacen que el producto sea inútil. Muchos proyectos de enmascaramiento fracasan por este motivo.
Aspectos del Rendimiento
Entonces, ¿qué hace que una solución de enmascaramiento de datos funcione rápida o lentamente? Hay tres factores que influyen significativamente en el rendimiento del enmascaramiento:
Ajuste de la base de datos
Implementación de la solución de enmascaramiento de datos
“Triggers”, o disparadores de la base de datos
Implementación
Cuando se ejecuta una solución de enmascaramiento de datos, se actualizan millones de valores de datos en la base de datos. Hay dos aspectos críticos relacionados con la implementación de la solución que pueden hacer que un trabajo se ejecute muy rápido o dolorosamente lento:
Tiempo de ejecución de SQL
Los viajes de ida y vuelta por la red
Los viajes de ida y vuelta por la red son el aspecto más crítico de la aplicación. El trabajo de enmascaramiento será insoportablemente lento si cada actualización de cada uno de los millones de valores se ejecuta por separado. Cada ejecución es un viaje de ida y vuelta, y un buen viaje de ida y vuelta para aplicaciones LAN es de unos 2-5ms. Eso significa que si se envían actualizaciones durante 24 horas en un bucle, se podría obtener una media de entre 17 y 43 millones de actualizaciones al día. No es tanto como podría parecer si se multiplica el número de filas de la base de datos por el número de columnas que requieren enmascaramiento.
Sin embargo, si el producto de enmascaramiento de datos utiliza la vinculación de matrices (con sentencias preparadas), puede enviar miles de actualizaciones en un solo viaje de ida y vuelta. Al eliminar la mayoría de los viajes de ida y vuelta, el tiempo de ejecución se reducirá de un día a menos de un minuto. Tenga en cuenta que una vez que el round-trip se vuelve insignificante, otros aspectos se convierten en el cuello de botella, por lo que el tiempo de ejecución no suele ser tan corto.
El tiempo de ejecución de SQL también depende de la implementación de la solución de enmascaramiento de datos. Cada base de datos tiene capacidades diferentes, y las implementaciones deben optimizarse para cada base de datos. Además de las sentencias preparadas y la vinculación de matrices mencionadas anteriormente, algunas bases de datos ofrecen un direccionamiento de filas más rápido que los índices. Oracle, por ejemplo, tiene ROWIDs que permiten el acceso directo a las filas. SQL Server tiene SQLBulkOperations. Del mismo modo, cada base de datos requiere una implementación única para maximizar la velocidad.
Triggers
Los “triggers” son fragmentos de código en la base de datos que se ejecutan cada vez que se modifican los datos. Tienen muchas finalidades, como validar datos, ajustar valores, sincronizar datos entre tablas y columnas, etc. La mayoría de las tablas de bases de datos no tienen triggers, pero cuando existen, se consideran parte integrante de la base de datos, vitales para su correcto funcionamiento.
Aunque el tiempo de ejecución de un único trigger suele ser corto, estos intervalos se acumulan cuando se actualizan millones de valores. Dado que el enmascaramiento de datos realiza millones de actualizaciones, los triggers de las tablas que requieren enmascaramiento suelen provocar que el tiempo de ejecución sea imposiblemente largo.
No es sencillo resolver el problema de los triggers, ya que su desactivación puede causar muchos problemas. Resolver el problema de los triggers, por tanto, requiere un mecanismo alternativo para replicar la funcionalidad de los triggers sin triggers. ¿Cómo podemos hacerlo?
Los triggers funcionan fila a fila. Esto tiene sentido para el código que se ejecuta cada vez que cambia un único valor. Sin embargo, las bases de datos pueden realizar actualizaciones verticales y cambiar todas las filas de la tabla con un único SQL. Convertir los triggers en un procedimiento con actualizaciones verticales le permitirá desactivar temporalmente los disparadores durante el enmascaramiento y mantener la funcionalidad del trigger ejecutando ese procedimiento.
Recodificar los triggers como actualizaciones verticales es un proceso manual. Sin embargo, el principal reto suele ser identificar todos aquellos que se disparan y el código que ejecutan. Core Audit, nuestra solución de auditoría de bases de datos, le muestra cualquier SQL que se ejecute en la base de datos, incluidos los SQL que se ejecutan dentro de los triggers. Es la solución perfecta para identificarlos, y a menudo la utilizamos durante las instalaciones de enmascaramiento con este fin.
Sintonización
El último aspecto del rendimiento del enmascaramiento es el ajuste de la base de datos. Con soluciones bien implementadas como Core Masking, no suele ser necesario. Sin embargo, es posible mejorar aún más.
La mayoría de las bases de datos hacen un uso intensivo de la lectura y se ajustan en función del rendimiento de lectura. La consulta de datos es, con diferencia, la actividad más habitual en las bases de datos. Sin embargo, el enmascaramiento de datos es una operación de escritura intensiva y se beneficiará de un ajuste diseñado para mejorar la velocidad de escritura.
Los administradores de bases de datos están bien equipados para ajustar una base de datos para que escriba más rápido, pero aquí hay un par de sugerencias que pueden ayudar:
Eliminación de índices en columnas enmascaradas. El objetivo de los índices es mejorar las consultas, pero cada cambio en una columna indexada requiere una actualización del índice. Eliminar los índices antes de enmascarar y volver a crearlos después es mucho más rápido.
Rehacer registros y archivar registros. Sólo enmascaramos las bases de datos que no son de producción, por lo que nunca es necesario recuperarlas en caso de fallo. Los registros de repetición y los registros de archivo son funciones de la base de datos que trabajan duro durante la actividad de escritura para garantizar que una base de datos pueda recuperarse. Deshabilitar o limitar esta funcionalidad de la base de datos durante el enmascaramiento mejorará significativamente el rendimiento de escritura.
Las bases de datos tienen muchos otros parámetros ajustables que pueden ayudar a mejorar el rendimiento, pero, como se mencionó anteriormente, rara vez es necesario ajustar la base de datos para el enmascaramiento.
El cambio de la base de datos a y desde una configuración de escritura intensiva puede automatizarse con acciones previas y posteriores al enmascaramiento. Éstas pueden eliminar índices o cambiar la configuración de la base de datos, volviendo a la configuración de lectura intensiva una vez finalizado el proceso de enmascaramiento.
Consejos
Entonces, ¿cómo deben abordar los clientes un proyecto de enmascaramiento?
Si ya dispone de una solución, intente identificar los cuellos de botella de rendimiento y solucionarlos. También puede considerar servicios profesionales como los que ofrecen nuestros socios. Otra posibilidad es adquirir una solución diferente, como Core Masking.
Si aún no ha adquirido una solución, tenga en cuenta las sugerencias siguientes. Sin embargo, el aspecto más importante a la hora de adquirir una solución de enmascaramiento de datos es asegurarse de contar con un proveedor y un socio que respalden sus soluciones y garanticen que todo funciona. Ninguna evaluación puede sustituir las capacidades que los proveedores pueden esgrimir para resolver problemas si se preocupan lo suficiente por usted como cliente.
Evaluación teórica
Es bueno evaluar la base teórica de una solución de enmascaramiento. Por ejemplo, los algoritmos de coherencia, las metodologías admitidas, los pros y los contras para la seguridad y la usabilidad de los datos, etc. La evaluación teórica y la comparación entre soluciones pueden revelar debilidades tecnológicas difíciles de identificar mediante pruebas. Estos puntos débiles rara vez se resuelven mediante actualizaciones o parches y es probable que permanezcan durante el resto de la vida útil del producto.
Evaluación práctica
Muchas evaluaciones de enmascaramiento dan rodeos. Intentan asegurarse de que algo funciona, pero no son inflexibles a la hora de analizar todos los casos de uso de principio a fin.
Por falta de tiempo, los clientes tienden a posponer la cuestión del desencadenante a la implementación posterior a la compra. Esto tiene cierta lógica, ya que los disparadores no son un problema en el software de enmascaramiento. Sin embargo, su capacidad para resolverlo es un requisito para utilizar el software. Así que, tanto si puede resolverlo usted mismo como si necesita que el proveedor o el socio le ayuden, es valioso realizar el ejercicio durante la evaluación.
A veces, las evaluaciones ni siquiera enmascaran las tablas por completo. Es simplemente una cuestión de tiempo, porque puede llevar demasiado tiempo. Pero así es como el rendimiento acaba siendo un problema sólo después de la compra. Además, las evaluaciones suelen probar los datos enmascarados comparando unas pocas filas. Sin embargo, nunca validan que todas las filas de la tabla estaban enmascaradas. Aunque no es un ejercicio trivial, tampoco es tan difícil.
En resumen, las evaluaciones prácticas son vitales, y los clientes deben ser inflexibles a la hora de repasar sus casos de uso de principio a fin. Hay que asegurarse de que el enmascaramiento termina en un tiempo aceptable y de que todos los datos están bien enmascarados.
Identifica tus necesidades
Toda selección de productos debe empezar por identificar las necesidades actuales y futuras. Esto es especialmente importante en el enmascaramiento de datos, ya que las posibilidades de los datos que se quieren enmascarar y las posibles aplicaciones de los datos enmascarados son infinitas. Cada producto tiene diferentes puntos fuertes, pero sus puntos débiles serán debilitantes para determinados casos de uso.
Sin embargo, los requisitos son algo que la mayoría de los clientes no tienen. Eso hace que la compra sea un juego de adivinanzas mientras se siguen las recomendaciones del proveedor. Le recomendamos que identifique algunos casos de uso difíciles y pida a los proveedores que los cumplan de principio a fin. Los proveedores pueden distinguirse por su capacidad para superar estos retos y no ofrecer soluciones uniformes.
Incluye a las partes interesadas
Muchas evaluaciones de enmascaramiento son realizadas por administradores de bases de datos. Es lógico, ya que el enmascaramiento es un producto de base de datos. Sin embargo, puede ser útil incluir a representantes de otros dos equipos. Una persona del equipo de seguridad para garantizar un enmascaramiento adecuado. Y lo que es más importante, al menos una persona de los usuarios destinatarios de los datos enmascarados. En otras palabras, representantes de los equipos de control de calidad o desarrollo previstos que puedan validar que los datos enmascarados les son útiles.
La razón de estas inclusiones es que si los clientes de los datos no han validado su utilidad, es probable que los rechacen y sigan utilizando datos sin enmascarar.
Incluir a varias partes interesadas de distintos equipos puede complicar el proceso de evaluación. Así que hay que intentar identificar a las personas adecuadas que puedan trabajar juntas, cooperar y hacer las cosas con rapidez.
Conclusión
El enmascaramiento de datos es, en muchos sentidos, un proceso sencillo, y la mayoría de los clientes lo consideran una compra sencilla. Aunque es sencillo, no es trivial, y saltarse algunos detalles puede suponer malgastar dinero en un software inútil.
Muchos proveedores de enmascaramiento de datos ven el enmascaramiento de datos de la misma manera que los clientes: un producto sencillo y menor sin barreras tecnológicas significativas. De nuevo, esto no es del todo falso, pero esta actitud da lugar a soluciones que sólo funcionan en algunos casos de uso y son inutilizables en otros. Esto ocurre tanto en los grandes vendedores como en los pequeños. Los grandes proveedores descuidan los productos más pequeños de la cartera, y los pequeños reducen costes recurriendo a desarrolladores baratos en países del Tercer Mundo.
Nuestro consejo es que pruebe a fondo la solución que pretende comprar y se asegure de que trabaja con un socio y un proveedor que resolverá sus problemas posteriores a la compra y hará que todo funcione.
Muchos proyectos de enmascaramiento fracasan. Trabaje con nosotros y le garantizaremos el éxito.
Echa un vistazo a este breve cómic sobre un ataque realista y lee las explicaciones a continuación en las que se describen los métodos, se ofrecen estadísticas y se comentan posibles técnicas de defensa.
Análisis y Explicación de los Ataques
Este artículo analiza los tipos de ataques utilizados en los cómics y ofrece estadísticas sobre su popularidad y posibles medidas de defensa. Esta brecha, como cualquier otra, requirió una combinación de varios pasos. Aunque puede que no sea posible detenerlos todos, deberías intentar detener varios y solo necesitas tener éxito en prevenir uno.
BEC y Ataques de Pretexto
Los ataques de pretexto son similares a los de phishing, pero mucho más eficaces. Los ataques de pretexto suelen suplantar la identidad de alguien para generar confianza y tienen un alto índice de éxito en la manipulación de las personas.
Según el DBIR de Verizon, en 2023, el pretexting fue el ataque de ingeniería social más frecuente y eficaz. El Business Email Compromise (BEC) aumenta aún más la eficacia de los ataques y va en aumento.
Credenciales Robadas
El 86% de los accesos iniciales en 2023 utilizaron credenciales robadas (Verizon DBIR). Es uno de los medios más comunes y altamente efectivos de obtener acceso a la organización y es cada vez más difícil de detener a causa de los empleados que trabajan de forma remota.
La MFA (Multi Factor Authentication o Autenticación Multifactor) es una forma de ayudar a combatir las credenciales robadas, pero tiene múltiples limitaciones, como demuestran las altas tasas de éxito de estos ataques.
Contraseñas
Todos los administradores tienen un archivo con las credenciales de los muchos sistemas que administran. Es la única manera de «recordar» docenas de contraseñas seguras.
Si un hacker encuentra la manera de llegar al escritorio de un administrador o a este archivo, puede llegar a cualquier parte que el administrador pueda.
Una bóveda de contraseñas tiene un éxito limitado en la protección de tales credenciales por varias razones, incluyendo porque el acceso al escritorio del administrador comprometerá cualquier sistema al que accedan.
Compromiso de la Base de Datos
Con una contraseña de administrador del servidor o de la base de datos, sólo hay una forma de detener este ataque: la seguridad de la base de datos. Las defensas centradas en los datos, especialmente las defensas de bases de datos, pueden ser muy eficaces.
Esta organización no tenía seguridad de base de datos, por lo que el personal de seguridad no estaba al tanto del ataque y no pudo detenerlo.
En este caso, el atacante robó los datos y los cifró. El ransomware garantizó que la organización descubriera la brecha. Si el atacante hubiera optado sólo por robar, la organización no habría sido consciente del ataque, y seguiría sin saberlo hasta que un tercero descubriera los datos y los cotejara para determinar su origen.
Reflexiones finales
Este ataque utiliza los medios más comunes y más eficaces para una brecha de datos. No utiliza vulnerabilidades de día cero, conocimientos únicos o talento excepcional. Es un escenario muy realista para un ataque con el que te puedes encontrar y probablemente pasará desapercibido.
Es posible que pueda mejorar aún más las defensas perimetrales, pero sigue siendo probable que ataques eficaces como éste tengan éxito. Por eso estos ataques son los más comunes y sobre todo funcionan.
Sin defensas eficaces centradas en los datos para protegerlos, este escenario será probablemente una brecha exitosa. El perímetro es fácil de penetrar, y sólo unas defensas internas eficaces en la aplicación y la base de datos pueden detener estos ataques tan comunes.
Si estás interesado, descarga la guía “Seguridad Perimetral Vs. Centrada en Datos” para obtener más información.
Más Allá del Perímetro: La Necesidad de Defensas Centradas en los Datos
Una reciente campaña masiva de phishing puso al descubierto una vulnerabilidad crítica en Proofpoint, uno de los principales proveedores de seguridad de correo electrónico basada en la nube.
El incidente plantea importantes cuestiones sobre los ataques a la cadena de suministro, la eficacia de la seguridad del correo electrónico y la necesidad de una defensa en capas contra los ataques.
Lo que ocurrió
Los hackers encontraron un exploit en organizaciones que utilizan Office 365 y Proofpoint. El exploit permitió a los hackers enviar correos electrónicos autenticados con firmas digitales idénticas a los correos electrónicos enviados por esas organizaciones. La lista de organizaciones explotadas incluye Disney, Coca-Cola, IBM, Nike, Best Buy y muchas otras.
Utilizando este exploit, los hackers enviaron durante al menos siete meses una media estimada de 3 millones de correos electrónicos al día, con picos que alcanzaron los 14 millones de correos electrónicos diarios. Es decir, entre 500 y 1.000 millones de correos electrónicos de phishing perfectamente falsificados.
Desconocemos el número de tarjetas de crédito, credenciales, identidades y demás información robada por los hackers. Sin embargo, algunos ataques se aprovecharon de los servicios vendidos por las empresas que falsificaban, enviando a los clientes a páginas de compra con cargos recurrentes en sus tarjetas de crédito.
Importancia
Los correos electrónicos autenticados enviados a través de Office 365 y Proofpoint son idénticos a los correos electrónicos enviados por las empresas auténticas, y los clientes no pueden notar la diferencia. Sin embargo, los ataques de phishing suelen embaucar a los clientes sin recurrir a falsificaciones de alta calidad, por lo que el mayor problema es otro.
Estos correos electrónicos tienen tasas de entregabilidad y de envío muy elevadas. Todos los proveedores de correo electrónico y filtros de spam admiten millones de correos electrónicos por minuto de esas organizaciones, y no entran en la carpeta de spam. Esto, unido a su autenticidad, crea potentes ataques de phishing.
Además, muchas organizaciones etiquetan los correos electrónicos externos para alertar a los empleados de posibles intentos de phishing. Estos correos autenticados eludirán estas advertencias, ya que son idénticos a los enviados por la organización. Esto hace que sea muy probable que los empleados sean presa de un ataque de phishing dirigido.
Ataques a la cadena de suministro y servicios en la nube
Los ataques a la cadena de suministro son motivo de gran preocupación, ya que exponen a las organizaciones a amenazas que desconocen y a las que no pueden hacer frente. Los ataques a la cadena de suministro también tienen un potencial aterrador, ya que los piratas informáticos pueden explotar las vulnerabilidades de cualquier organización que recurra a ese proveedor.
El problema de la cadena de suministro aumenta exponencialmente en los servicios basados en la nube. Los piratas informáticos pueden explotar las vulnerabilidades de la cadena de suministro en la nube sin acceder a la red corporativa ni hacer saltar las alarmas. Como demostró este ataque, muchas grandes organizaciones fueron víctimas de un ataque a gran escala del que no tenían conocimiento.
Seguridad del correo electrónico
La seguridad del correo electrónico es casi un oxímoron, y este ataque es otra prueba de nuestra incapacidad para protegerlo. Autenticar y firmar los correos electrónicos con DKIM, SPF y DMARC es beneficioso y valioso, pero es un esfuerzo que no puede evitar ni siquiera los simples ataques de phishing. Mejora las cosas, pero dista mucho de ser perfecto.
Las organizaciones deben aceptar que el correo electrónico es inseguro, que muchos empleados y clientes son presa del phishing y, en consecuencia, que se producen ataques de phishing con éxito de forma regular.
Debemos hacer esfuerzos razonables para proteger el perímetro. Es significativo porque reduce el número de ataques. Sin embargo, no se puede evitar que los intrusos lo penetren y accedan a la red corporativa. Por lo tanto, el aumento de las inversiones en la protección del perímetro tiene rendimientos decrecientes, especialmente los ineficaces como la seguridad del correo electrónico.
Enfoque por capas con defensas centradas en los datos
Dada nuestra limitada capacidad para proteger la red corporativa, debemos aplicar un enfoque de seguridad por capas con defensas centradas en los datos que impidan una violación de los datos cuando un hacker inevitablemente penetre en el perímetro.
Comprendiendo cómo se produce una violación de datos y aplicando una estrategia de seguridad adecuada, las organizaciones pueden reducir significativamente el riesgo de ser víctimas de ataques.
Core Audit es un componente fundamental en la batalla contra las brechas de datos, ya que proporciona la visibilidad y el control necesarios para proteger a su organización contra los ataques y las amenazas emergentes. Póngase en contacto con nosotros para obtener más información, analizar el entorno único de su organización y comprender sus necesidades de seguridad. Permitinos ayudarte a tener éxito.
Endpoints: ¿Seguridad garantizada o riesgo potencial?
Las recientes interrupciones de servicio en todo el mundo debidas a una actualización de CrowdStrike plantean una pregunta inevitable: ¿los beneficios de la seguridad en los dispositivos individuales superan los riesgos? ¿Cuáles son las alternativas?
Lo que ocurrió
Como hemos visto, un error en una actualización de CrowdStrike causó estragos en todo el mundo. Aproximadamente 8 millones de ordenadores con Windows se bloquearon en muchas empresas, desde aerolíneas a noticieros y hospitales. Los usuarios desesperados acudieron a los foros, algunas organizaciones enteras se paralizaron y algunos problemas persistieron durante uno o más días.
Aunque CrowdStrike pudo solucionar el problema rápidamente, la recuperación llevó mucho tiempo. Este incidente pone de manifiesto la fragilidad y los riesgos que entraña la seguridad basada en endpoints. Se derivan de un problema simple: tenemos muchos ordenadores de sobremesa y portátiles repartidos por todo el mundo, y se necesita mucho tiempo y esfuerzo para llegar a cada uno de ellos. Incluso con la gestión centralizada remota, alguien debe llegar físicamente a los sistemas que no arrancan.
Seguridad de endpoints: ventajas e inconvenientes
La seguridad de endpoints forma parte de la seguridad perimetral y, junto con los cortafuegos, la seguridad del correo electrónico, la seguridad física, etc., intenta mantener a los hackers fuera de la red corporativa. Aunque proteger todos los dispositivos de la red parece una estrategia sólida, no está exenta de serios inconvenientes.
Manejabilidad
Proteger un gran número de dispositivos puede ser una tarea compleja y laboriosa. Cada dispositivo varía en muchos aspectos, como el hardware, el sistema operativo, el software instalado y el uso. Hay que realizar muchas tareas en cada dispositivo de forma individual, como actualizaciones, configuración, parches, rendimiento y estabilidad, supervisión de la seguridad, resolución de problemas y mucho más. La gestión centralizada y remota ayuda mucho, pero los dispositivos se desincronizan a menudo. Y como demostró el incidente de CrowdStrike, los problemas pueden ser difíciles de resolver y llevar mucho tiempo, con repercusiones catastróficas para la empresa.
Costo
La seguridad de los endpoints puede resultar cara a medida que crecen la organización y el número de dispositivos en ella. Los costos de licencia por dispositivo pueden ser elevados, pero los recursos necesarios para gestionarla y mantenerla adecuadamente son significativos.
Eficacia
La seguridad de los endpoints no siempre es eficaz a la hora de proteger contra los ataques. Algunos ejemplos obvios son la amenaza interna que representa el 20% de las filtraciones de datos, los dispositivos inseguros en la red (inicios de sesión VPN, dispositivos conectados físicamente, sistemas operativos no compatibles, etc.) o los ataques que no comprometen un endpoint (como XSS). Sin embargo, los ciberdelincuentes son cada vez más sofisticados y descubren medios para penetrar incluso en dispositivos protegidos.
Soluciones alternativas
Aunque la seguridad perimetral en todos sus componentes es valiosa para reducir el número de ataques, no puede detenerlos todos. Un enfoque más sencillo consiste en centrar nuestros esfuerzos en unos pocos servidores clave en lugar de en el interminable mar de endpoints vulnerables. La gestión del rendimiento lleva décadas utilizando este paradigma, y la tendencia equivalente en seguridad es el paso de la seguridad perimetral a la seguridad centrada en los datos.
Ahí es donde entra en juego nuestra tecnología. Al centrarnos en la seguridad de bases de datos y aplicaciones, ofrecemos una seguridad más eficaz que es más fácil de gestionar y mantener. Aunque la seguridad centrada en los datos no está exenta de dificultades, ofrece una protección más sólida a un coste menor y con una mejor capacidad de gestión.
El incidente de CrowdStrike demuestra que la seguridad de endpoints conlleva riesgos inherentes. La seguridad centrada en los datos ofrece una buena alternativa, permitiéndole centrar sus recursos en lo que realmente importa: proteger sus datos críticos.
¿Estás listo para el cambio?
Si está buscando una forma más segura y eficiente de proteger sus datos, póngase en contacto con nosotros hoy mismo para obtener más información sobre cómo podemos ayudarlo a implementar una solución de seguridad centrada en los datos que satisfaga las necesidades de su empresa.
¿Cómo puede un día que parece ser el peor de tu carrera resultar positivo? Esta historia ficticia describe acontecimientos realistas sobre una brecha de datos en el que las cosas salieron bien. Mira lo que hay que hacer para que ocurra.
Comienza el ataque
El sonido de un nuevo correo electrónico parpadeó en la pantalla de Cora. Era otra alerta de Core Audit, y no era la primera del día. Pero tomó un vistazo rápido a las SQL y la adrenalina la despertó. Sintió como si le hubieran inyectado cafeína directamente en el cerebro. Esto no es un falso positivo, es un ataque. Alguien está ejecutando con éxito un ataque de inyección SQL a través de la aplicación y en la base de datos.
Cora Blue es un DBA en el equipo de seguridad y entendió exactamente lo que estaba pasando. Esa es la primera etapa del ataque, ya que el intruso está intentando determinar si la aplicación es vulnerable y reunir información sobre el tipo de base de datos y las tablas que contiene. Hasta ahora, es probable que sólo sea un script recopilando información, pero dependiendo de lo bueno que sea este atacante, pronto se convertirá en una brecha de datos. Podría llevar días, a veces horas, pero en el peor de los casos, pueden pasar unos minutos antes de que empiecen a filtrar datos: no hay tiempo que perder.
Deteniendo la brecha
Cora sabe lo que tiene que hacer. Aunque desconectar la aplicación probablemente sea suficiente en este caso, la política exige cerrar tanto la aplicación como la base de datos. Como miembro senior del equipo de seguridad, tiene los permisos necesarios para hacerlo. Más vale prevenir que curar, y unos minutos más tarde, todo está fuera de línea. Mientras los sistemas se desconectan, envía un mensaje al grupo de notificación. Eso llegará al equipo de respuesta y a todos los que necesiten saberlo.
Cuando se reunió el equipo, Cora pudo echar un vistazo a la información forense de la auditoría central. Parece que los hackers todavía estaban en la fase de descubrimiento, y no se llevaron nada. Encontró el servidor de aplicaciones del que procedía el ataque y la hora, y a partir de los SQL, incluso pudo adivinar el área comprometida de la aplicación: la primera parte del SQL es el código original con la tabla y las columnas de la consulta original.
Ahora que todo el equipo está en una reunión de Zoom hay dos objetivos inmediatos. Conseguir que la aplicación y la base de datos vuelvan a estar en línea de forma segura es importante, ya que el servicio de asistencia probablemente ya esté recibiendo llamadas (menos mal que formaban parte de la cadena de notificación). Pero lo más apremiante es cómo entraron en la red, si siguen dentro y qué más hay que hacer de inmediato para detener este ataque en seco.
El pequeño equipo de respuesta incluye a Cora Blue, que identificó el suceso y es también la experta en bases de datos del equipo. Brandon Reese, el administrador de sistemas sabelotodo. Randall Shield, que controla la red. Y Audrey Cortez, que representa a la alta dirección.
¿Qué fue lo que pasó?
Cora explica rápidamente lo sucedido: un ataque de inyección SQL afectó a la base de datos a través del servidor de aplicaciones CBR002 a partir de las 14:35, pero el servidor de aplicaciones y la base de datos se cerraron antes de que se tomara algo. Audrey la felicita por su diligencia y rápida respuesta. No es la primera vez que el equipo se reúne y todos saben que Audrey puede hablar un rato. Pero también saben que no le importa que la interrumpan, sobre todo cuando el tiempo es oro, y antes de que pueda continuar, Brandon la interrumpe de manera cortés compartiendo su pantalla en la que muestra un grep de los registros de Apache.
Los registros muestran claramente el rápido disparo de las peticiones HTTP que causaron la inyección SQL y la IP que las envió. Parece que el ataque provino del rango de IP de la VPN. Mientras Brandon continuaba en Core Audit para ver las pantallas forenses de auditoría de aplicaciones, Randall, el administrador de red, encontró la asignación de IP DHCP que mostraba que el ataque procedía del ordenador personal de Holly Ackerman, la asistente administrativa de uno de los vicepresidentes.
Unos segundos más tarde, Brandon también encontró el ataque en el análisis forense de Core Audit, confirmando que se trataba del inicio de sesión de Holly en la aplicación. Aunque nadie del equipo conoce bien a Holly, no parece tener muchos conocimientos informáticos y probablemente nunca haya oído el término SQL Injection. Alguien debió apoderarse de su ordenador personal y utilizarlo para lanzar el ataque.
Se neutraliza la amenaza
En cualquier caso, el equipo desactiva la cuenta de Holly y la desconecta de la VPN. El equipo de asistencia técnica la llamará para explicárselo, el equipo de seguridad empezará más tarde a investigar su ordenador y el equipo de Windows acabará ayudándola a reinstalarlo. Brandon envía un breve correo electrónico de actualización al grupo de notificación de infracciones que pondrá todo en marcha.
El equipo cree que en este punto el ataque está prácticamente contenido. Necesitan ver si el usuario de Holly se utilizó en algún otro lugar, poner la base de datos en línea, encontrar el problema en la aplicación y averiguar cómo ponerla en línea de forma segura. También tienen que investigar la PC de Holly para averiguar cómo entró alguien, aunque probablemente sólo hizo clic en el correo electrónico equivocado.
El día no ha terminado, pero parece que han evitado lo peor.
¿Cómo lo lograron?
Repasemos algunos de los puntos clave que hicieron de esta historia un éxito para el equipo de seguridad.
En primer lugar, a pesar de una brecha del perímetro que probablemente era inevitable, contaban con una solución IDS de base de datos que reconoció el acceso anómalo a los datos y envió una alerta. Sin esa alerta, esta historia habría sido muy diferente. Pasarían meses antes de que se enteraran del ataque, y probablemente sólo como resultado de una notificación de las fuerzas de seguridad. El equipo de respuesta estaría entonces analizando una violación de datos de meses de duración, tratando de determinar cuántos sistemas se vieron comprometidos y a quién debían notificar que sus datos habían sido robados.
En segundo lugar, Cora Blue, una DBA con conocimientos y formación en ciberseguridad, recibió la alerta. Sabía qué buscar y reconoció el ataque. También disponía de información forense sobre la actividad de la base de datos que le permitía actuar de inmediato. Sin una solución como Core Audit, no hay información forense sobre cada SQL ni forma de determinar lo que ocurrió en la base de datos.
También había políticas sencillas que indicaban a Cora cómo responder, y ella tenía los permisos necesarios para actuar y detener el ataque en seco.
El equipo se reunió rápidamente, era lo suficientemente pequeño como para operar con eficacia y contaba con personas bien informadas con acceso a todos los sistemas. El equipo se había reunido muchas veces y tenía una buena relación de trabajo. Tampoco era la primera vez que intentaban responder a un ataque, ya que todos sabían exactamente qué hacer.
Todo puede salir bien cuando se reciben las alertas, se dispone de información de apoyo y se cuenta con personas con talento y formación que saben lo que tienen que hacer.
Sistemas de detección (IDS) y prevención (IPS) de intrusiones
Anteriormente hablamos de las defensas centradas en los datos como la última línea de defensa crítica, donde uno de nuestros requisitos es intentar que sea lo más hermética posible. No es un requisito menor ni trivial, y en este artículo hablaremos de cómo conseguirlo.
Hay dos conceptos que tendremos que discutir:
– Falsos positivos y falsos negativos
– IPS (Sistemas de Prevención de Intrusiones) e IDS (Sistemas de Detección de Intrusiones)
Los falsos negativos se producen cuando un sistema de seguridad no reacciona ante un ataque. Por lo tanto, nuestro objetivo es reducir o intentar eliminar los falsos negativos. Si lo conseguimos, tendremos una seguridad hermética.
Los falsos negativos son el pequeño y sucio secreto de los sistemas de seguridad: el tema del que nadie habla. Nadie habla de cuántos falsos negativos tienen, de cómo medirlos, estimarlos y, en general, de la eficacia de la seguridad. Es un tema importante, pero que todo el mundo intenta evitar.
Para entender cómo reducir los falsos negativos, primero debemos entender los falsos positivos.
Un falso positivo es lo contrario: cuando un sistema de seguridad clasifica incorrectamente una actividad legítima como un ataque, por ejemplo, cuando un buen correo electrónico llega a la carpeta de spam.
Los falsos positivos pueden ser molestos, como en el caso de los correos electrónicos mal clasificados, pero también pueden impedir que la gente haga su trabajo cuando, por ejemplo, no pueden iniciar sesión en un sistema que necesitan para trabajar. Estos son ejemplos de falsos positivos en seguridad preventiva. Dado que pueden ser debilitantes y causar muchas quejas, los IPS se diseñan y ajustan para que tengan pocos o, en el mejor de los casos, ningún falso positivo.
Como puedes imaginar, hay un equilibrio entre falsos positivos y falsos negativos. Reducir uno tiende a aumentar el otro. Así, al reducir los falsos positivos para que la gente pueda hacer su trabajo, inevitablemente aumentan los falsos negativos, y más ataques pasan desapercibidos.
Otra forma de verlo es la sensibilidad del sistema de seguridad. Un sistema sensible detectará más ataques pero tendrá muchas falsas alertas. Un sistema calibrado para ser menos sensible tendrá menos falsas alertas pero pasará por alto muchos ataques.
Esto nos lleva al otro tema de los IPS y los IDS. Existe la idea errónea de que la prevención es más importante que la detección. La lógica detrás de esto es, ¿por qué detectar algo cuando puedes prevenirlo? Parece una buena idea, pero es errónea.
Como acabamos de decir, en IPS tenemos que reducir los falsos positivos, y eso aumenta los falsos negativos. Pero IDS no tiene un requisito de cero falsos positivos, e incluso esperamos un cierto nivel de falsos positivos. Los falsos positivos en IDS son falsas alertas que recibe la gente de seguridad, y pueden ser molestos si son demasiado frecuentes, pero los esperamos hasta cierto punto. Ser capaces de acomodar algunos falsos positivos nos permite reducir significativamente los falsos negativos. En otras palabras, calibramos los sistemas IDS para que sean más sensibles y detecten un número mucho mayor de ataques.
Utilizar una combinación de IDS e IPS es una forma sencilla de calcular el número de falsos negativos del IPS. Hay otras formas de hacerlo utilizando el análisis estático.
Entonces: ¿Qué es mejor, IDS o IPS?
La verdad es que necesitamos ambos. Preventivos para bloquear todo lo posible y detectives para identificar y alertar sobre el resto. Así es como nos acercamos al hermetismo.
Y también hay otros mecanismos estratégicos para acercarse al hermetismo, como el uso de defensas en serie y parcialmente solapadas. Esto nos lleva a la matriz de control de riesgos, que es el tema de otro artículo.
Si desea saber más o mantener una conversación gratuita con uno de nuestros expertos, póngase en contacto con nosotros en info@bluecoreresearch.com.
Seguridad centrada en datos: la clave en en siglo XXI
A menudo pensamos en la ciberseguridad como si estuviera formada por muchos silos. Pensamos en la seguridad de la red, la formación, la seguridad física, la seguridad del correo electrónico, etc., donde a su vez cada uno de ellos suele estar formado por silos más pequeños. Por ejemplo, la seguridad de la red incluye cortafuegos, routers, VLAN y muchas otras medidas que no están necesariamente relacionadas de forma directa.
El problema cuando se piensa en cualquier tema como si estuviera hecho de tantos componentes pequeños y no relacionados es que es casi imposible elaborar una estrategia adecuada, asignar valor a los diferentes componentes y, en general, crear un enfoque equilibrado que lo cubra todo. Obtenemos una seguridad que es muy desigual, con algunas áreas que están fuertemente fortificadas y otras que no tienen ninguna cobertura en absoluto.
Así que empecemos por poner un poco de orden en este caos y averigüemos a dónde pertenecen las cosas y qué valor aportan. qué funciona con qué, qué es complementario, qué se solapa, etcétera.
Una oportuna primera división es entre las medidas destinadas a impedir que entren los de fuera y las medidas destinadas a impedir que nadie llegue a los datos. Me gusta llamar a la primera seguridad perimetral y a la segunda seguridad centrada en los datos.
Una buena prueba para ver si una medida de seguridad forma parte del perímetro o está centrada en los datos es preguntarse «¿Nos va a proteger esto de una amenaza interna?». Las amenazas internas son personas que trabajan para la empresa, por lo que si una medida les impedirá robar o modificar datos, es una medida que protege los datos.
En general, los atacantes externos suelen necesitar vulnerar un activo interno antes de acceder a los datos, pero no siempre se da así. Por ejemplo, una aplicación de cara al público en Internet puede dar acceso directo a los datos sin vulnerar nada más que esa aplicación. Ese es un ejemplo de datos a los que se puede acceder directamente desde el exterior y que no tienen protección perimetral. Otro ejemplo son los datos que están fuera del perímetro, como un portátil o una cinta de copia de seguridad que está fuera del edificio: tampoco tienen protección perimetral y pueden ser robados sin acceder a los activos internos.
La seguridad del perímetro es importante, pero su función es sólo reducir el número de intentos de ataque a los datos, ya que ninguna de las medidas de seguridad del mismo es hermética. Por ejemplo, la seguridad del correo electrónico, siendo realistas, sólo pretende reducir el spam y no evitarlo. Si se supone que debe evitar el spam por completo, casi todos los días fracasa en su cometido. Incluso si algunas medidas del perímetro pudieran ser herméticas, hay demasiados vectores de ataque en el perímetro como para pretender que siempre podemos cubrirlos todos perfectamente. Por lo tanto, el perímetro pretende reforzar las medidas centradas en los datos y no sustituirlas.
Aunque algunos lo consideran una exageración, creo que las medidas centradas en los datos deben aspirar a ser herméticas. Es una afirmación contundente y difícil de conseguir, pero no imposible. Es un punto importante porque cuando las medidas centradas en los datos fallan, tenemos una vulneración de datos. A menudo no tenemos ninguna barrera adicional que nos proteja. Si es posible, deberíamos superponer medidas centradas en los datos para obtener esa protección adicional.
¿Qué tipo de medidas de seguridad se centran en los datos?
Bueno, aquí estamos hablando de la protección en torno a los datos, por lo que la seguridad de las bases de datos y de las aplicaciones son los pilares principales. También tenemos la seguridad del servidor junto con la seguridad física y de la red para el centro de datos, el cifrado de datos en reposo y los controles contra administradores. En general, cualquier cosa que se interponga entre los datos y las personas.
Tenemos nuestra primera división de la seguridad entre la perimetral y la centrada en los datos. Esta clase se centrará en la centrada en los datos. También identificamos el papel de la seguridad centrada en los datos como el objetivo de proteger los datos. Protegerlos tanto de las amenazas internas como de las externas que penetran en el perímetro. Y, por último, tenemos el objetivo de hacer que nuestra protección centrada en los datos sea hermética.
Como la gente trabaja cada vez más desde casa, el perímetro se vuelve imposible de asegurar. No podemos proteger el perímetro físico de los empleados en casa, sus ordenadores personales, su red doméstica ni todos sus dispositivos. Es una batalla perdida que simboliza la muerte del perímetro y convierte la protección centrada en los datos en la principal forma de seguridad del siglo XXI.
Preguntas frecuentes sobre el enmascaramiento de datos
¿Has pensado cómo proteger los datos confidenciales? El enmascaramiento estático de datos es una forma sencilla, fácil y eficaz de evitar una filtración.
Presentamos a continuación las respuestas a las preguntas más habituales:
1. ¿Por qué enmascarar? Porque no podemos proteger los datos fuera de Producción: Imagine que copia los datos de un cliente para realizar pruebas. ¿Cómo los protegerá después de copiarlos? Sin enmascaramiento de datos, usted expondrá todos los nombres, direcciones, teléfonos, correos electrónicos, información financiera y más. El enmascaramiento estático sustituye estos valores por buenas falsificaciones para que puedas hacer las pruebas sin poner en riesgo tu información confidencial o la de las personas que te la confiaron.
2. ¿Revertir el enmascaramiento? No es posible, ¡esa es la cuestión!: A diferencia del cifrado, el enmascaramiento estático es una transformación unidireccional. Los datos enmascarados se parecen a los originales, pero no los revelan. Este proceso irreversible garantiza que su información sensible permanezca protegida incluso si los datos enmascarados caen en las manos equivocadas.
3. ¿Integridad de los datos? Es imprescindible. De lo contrario, las aplicaciones no funcionarán correctamente en el entorno de prueba, o la prueba será ineficaz. El proceso de enmascaramiento debe conservar la validez, coherencia e integridad referencial de los datos. Es como un disfraz elaborado: todo parece diferente pero tiene que funcionar igual.
4. ¿Una única fórmula? Por supuesto que no. Hay muchas formas de enmascarar cualquier tipo de datos. Elegir una estrategia que se adapte a sus necesidades le garantizará alcanzar sus objetivos de seguridad a la vez que saca el máximo partido a sus datos.
5. ¿Debo preocuparme por el rendimiento? Sí y no: el rendimiento en el enmascaramiento de datos no es un problema, a menos que sea tan lento que resulte inviable. Vamos a explicarlo mejor:
Existe una idea preconcebida de que el enmascaramiento estático de datos es inherentemente lento y consume muchos recursos, pero no es un gran problema, ya que sólo tenemos que hacerlo una vez después de copiar los datos. Algunos dirían que sólo es necesario ejecutarlo una vez.
La verdad
No importa si un proceso de enmascaramiento tarda 30 segundos, 5 minutos o media hora, sólo porque no es algo que se ejecute todo el tiempo, y no se ejecuta en producción, ralentizando los procesos críticos de negocio.
Sin embargo, eso no es del todo cierto, ya que el enmascaramiento deja de ser práctico si tarda días o semanas. Tampoco es cierto que el enmascaramiento sólo se ejecute una vez, ya que hay que hacerlo cada vez que se actualizan los datos de prueba. A medida que el enmascaramiento se hace más rápido y sencillo, puede actualizar sus datos de prueba con más frecuencia y sacarle más partido.
Culpables del rendimiento
El enmascaramiento lento suele deberse a una de estas razones:
Selección del producto: Las diferentes soluciones ofrecen distintas capacidades de rendimiento. Entre los motivos más comunes se encuentran la calidad del código, las API de base de datos elegidas, el tamaño de las transacciones, etc.
Rendimiento de la base de datos: Como cualquier producto que funciona con una base de datos, el rendimiento del enmascaramiento también depende del rendimiento de la base de datos subyacente.
Disparadores: Uno de los problemas de rendimiento más difíciles de resolver son estas pequeñas piezas de código que se ejecutan cada vez que cambian los datos. Al actualizar millones de filas, un desencadenador se ejecutará millones de veces, lo que puede hacer que el proceso de enmascaramiento se eternice. Sin embargo, los disparadores no deberían desactivarse automáticamente, ya que a menudo son esenciales para la validez e integridad de los datos.
Domar a la “bestia del rendimiento”
Abordar estos problemas permitirá que el enmascaramiento de datos sea una parte integral de un ciclo de vida de datos dinámico, en lugar de una carga lenta e inutilizable que todo el mundo quiere evitar.
Presentamos algunas cuestiones a tener en cuenta para cada una de las razones en el punto anterior:
Si hablamos de laselección de productos, al buscar una solución de enmascaramiento de datos, siempre es aconsejable probar varias soluciones en su entorno con su red, base de datos y volumen de datos. Aunque las pruebas de productos pueden llevar mucho tiempo, es la única manera de asegurarse de que la solución funciona. Las grandes marcas, los productos conocidos, los analistas de mercado y los consejos amistosos a menudo pueden resultar contraproducentes y dar lugar a un software propio inutilizable.
En cuanto alrendimiento de la base de datos,el enmascaramiento de datos es un proceso muy intensivo en escritura que requiere un ajuste diferente de la base de datos. Para mejorar temporalmente el rendimiento de la base de datos durante el enmascaramiento, puede, por ejemplo, eliminar índices y restricciones, detener el archivado, suspender la replicación, etc. Las acciones previas y posteriores al enmascaramiento pueden ayudar a automatizar estas acciones durante el mismo. Colabore con sus DBA para maximizar la velocidad de escritura de su base de datos.
Finalmente, resolver los problemas de rendimiento de los disparadores requiere algo de trabajo manual. En primer lugar, evalúe qué disparadores son relevantes para los datos que está enmascarando y desactive los irrelevantes. En segundo lugar, convierta los disparadores necesarios en un procedimiento de actualización vertical. Una única actualización de todas las filas es mucho más rápida que millones de pequeñas actualizaciones. Core Audit puede ayudar a acelerar este proceso identificando las SQL que deben reescribirse como actualizaciones verticales.
El enmascaramiento es esencial
Al hablar de problemas de rendimiento, es fácil perder de vista el panorama general: ¿por qué es tan importante el enmascaramiento de datos?
Reduce el riesgo: la eliminación de la exposición de datos confidenciales fuera de la producción reducirá drásticamente su perfil de exposición y riesgo.
Tiene un cumplimiento simplificado: el enmascaramiento es esencial a la hora de adherirse a las normativas de cumplimiento y privacidad de datos. Este le permite reducir el ámbito de cumplimiento, ya que los sistemas con datos enmascarados no suelen estar sujetos a dicho cumplimiento.
Mejora el desarrollo: los datos enmascarados alimentan los entornos de desarrollo y pruebas, lo que mejora la calidad del producto, acorta los ciclos de desarrollo y acelera los plazos de los proyectos.
Reflexiones finales
El enmascaramiento de datos es un componente fundamental del ciclo de vida de los datos y de la forma en que nuestros datos pueden impulsar y mejorar muchas funciones de nuestra empresa, como el desarrollo de productos, las pruebas, el análisis de datos, etc. A su vez, nos permite utilizar los datos de forma segura fuera de la producción, multiplicando el valor que podemos obtener de ellos.
Aunque sencillo y esencial, no es trivial. Muchos proyectos de enmascaramiento fracasan por diversos motivos, como la definición de las políticas de enmascaramiento adecuadas o la resolución de posibles problemas de rendimiento, entre otros.
A través de nuestra experiencia trabajando con clientes, hemos descubierto que los clientes siempre tienen éxito cuando cuentan con el producto adecuado y el equipo de apoyo para garantizar el éxito del proyecto. La falta de uno u otro disminuye considerablemente las posibilidades de éxito, y la falta de ambos garantiza el fracaso.
No dudes más y contáctanos hoy mismo a info@bluecoreresearch.com para saber más sobre cómo podemos ayudarte a enmascarar y asegurar tus datos.
