Posted on

Cómo convertir un ataque en una oportunidad de aprendizaje

Historia de un Ciberataque

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

Posted on

Sistemas de detección y prevención de intrusiones

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.

Posted on

Seguridad centrada en datos

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.

Post de LinkedIn

Pequeña descripción de la publicación en LinkedIn

Leer articulo →

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.

Posted on

Q&A’s: Enmascaramiento de Datos

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 la selecció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 al rendimiento 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.

Posted on

Database Visibility: Poll Results

Visibilidad de las bases de datos: lo que todo el mundo echa en falta

Encuestas recientes a profesionales de la ciberseguridad muestran que la mayoría de los encuestados (82%) tienen visibilidad parcial o nula de sus bases de datos y la necesitan. Pocos dijeron que tienen buena visibilidad (7%) o que no la necesitan (11%).

Las encuestas se realizaron en diferentes grupos de LinkedIn tanto en inglés como en español y preguntaban “¿Tienes visibilidad de lo que ocurre dentro de tu base de datos?”. Casi todos los encuestados ingleses afirmaron tener una visibilidad parcial (40%) o no tener la visibilidad que necesitan (53%).

En la encuesta en español, hubo más personas que afirmaron tener buena visibilidad (10%) o no necesitarla (13%), pero aún así la mayoría dijo tener visibilidad parcial o no tenerla y necesitarla (47% y 30% respectivamente).

El reto de la visibilidad de la base de datos

Las bases de datos de las que somos responsables, almacenan muchos datos de terceros y de empresas que son muy sensibles, como datos financieros, información personal y mucho más. Es vital que estos datos no se vean comprometidos, filtrados o manipulados, pero no tenemos visibilidad sobre quién accede a ellos, cuándo o cómo.

Sabemos que necesitamos visibilidad. Sin ella, no podemos diseñar controles eficaces y está generalmente aceptada como un paso fundamental en la seguridad: no vueles a ciegas. No se puede controlar lo que no se ve. Entonces, ¿cómo es que es algo de lo que carecen la mayoría de las organizaciones?

Las bases de datos son un reto por el volumen de actividad y los requisitos de rendimiento. ¿Cómo se puede obtener visibilidad de miles de millones de SQL? ¿Cómo puede incluso recopilar la información sin afectar al rendimiento, por no hablar de procesarla y consumirla? ¿Cómo se puede obtener el control y saber cuándo alguien está haciendo algo malicioso cuando hay tanto ruido? Incluso limitando el alcance a los accesos a tablas confidenciales, hay demasiada actividad que comprender.

Y sin visibilidad, ¿cómo puede establecer controles, informes o alertas? ¿Qué hay que tener en cuenta? ¿Cómo sabrá si se ha producido una violación de datos? O si la ha habido, ¿qué ha ocurrido?

Cómo obtener y mejorar la visibilidad

Como ya se ha mencionado, la visibilidad de las bases de datos es un reto debido a su gran actividad y a sus requisitos de alto rendimiento. También es poco probable que pueda conseguirla por sí mismo sin la solución y la tecnología subyacentes adecuadas.

Las herramientas sencillas que se basan en funcionalidades integradas en las bases de datos suelen tener un impacto en el rendimiento y es poco probable que le proporcionen la visibilidad que necesita. Incluso las herramientas caras suelen basarse en tecnologías antiguas que no pueden ofrecer la visibilidad y el valor que usted necesita.

En los últimos años, Core Audit ha introducido importantes avances e innovaciones en este espacio del mercado, incluidas múltiples tecnologías de captura, procesamiento y análisis. Hable con nosotros para obtener más información sobre cómo podemos ayudarle a proteger sus datos.

Conclusión

Hoy en día, necesitamos proteger más datos, más sistemas y enfrentarnos a mayores riesgos como nunca antes. Estos retos son importantes y necesitamos la visibilidad y el control que ofrecen las últimas tecnologías.

Estas encuestas recientes muestran que la mayoría de los profesionales de la ciberseguridad son conscientes de lo importante que es la visibilidad. Sin embargo, la mayoría de las organizaciones siguen estando a la deriva, con una visibilidad limitada o nula de sus bases de datos.

Póngase en contacto con nosotros hoy mismo en marketing@bluecoreresearch.com para obtener más información sobre cómo podemos ayudarle a mejorar la visibilidad de sus bases de datos y proteger su información confidencial.

Posted on

Anomaly Analysis

Análisis de Anomalías

El análisis de anomalías es una potente herramienta que te permite ahorrar tiempo a la vez que amplía su control a grandes volúmenes de actividad. Esto es posible gracias a la exclusiva tecnología de repositorio de seguridad de Core Audit. 

El motor de análisis de anomalías crea dinámicamente perfiles de comportamiento basados en el repositorio de seguridad para comparar el presente con el pasado. Al contrastar la actividad actual con la histórica, es fácil destacar los cambios de comportamiento que son indicativos de problemas de seguridad.

Esto le permite romper la idea preconcebida de que no puede controlar grandes volúmenes de actividad como la aplicación. El análisis de anomalías le permite detectar la aguja en el pajar para encontrar un único SQL ofensivo entre miles de millones.

¿Cómo funciona?

Como todos los sistemas informáticos, la actividad de las bases de datos es repetitiva, ya que aunque los valores cambian, los patrones persisten. El motor de análisis de anomalías es capaz de mucho más, pero los análisis suelen centrarse en cinco aspectos:

  1. Actividad nueva – Algo visto hoy pero no en el pasado. Como un nuevo usuario, programa, SQL, entre otros.
  2. Alto volumen de actividad – Actividad que existe ahora y en el pasado pero que ahora ocurre aún más.
  3. Hora del día – Actividad que en la actualidad ocurre a una hora diferente al pasado.
  4. Dimensiones combinadas – En lugar de un cambio en una sola dimensión (como un nuevo usuario) ocurre un cambio en múltiples dimensiones (como la combinación de un usuario y una IP). Tanto el usuario como la IP podrían ser conocidos, pero ese usuario podría no haber utilizado nunca esa IP.
  5. Filtros – Reduzca la búsqueda de anomalías a las áreas de interés, como las tablas sensibles, la aplicación, usuarios concretos, etc. Es probable que diversos subconjuntos de la actividad muestren comportamientos diferentes y se beneficien de otros tipos de anomalías.

Hay muchas formas de seleccionar el tipo de anomalías a utilizar. Podrían ser comportamientos que usted espera, patrones vistos en análisis forenses proactivos, los asistentes de Core Audit, la guía de control de Core Audit, o simplemente prueba y error. Pero una de las características cruciales del motor de anomalías es que puede probar inmediatamente una anomalía y encontrar los resultados. Eso hace que elegir y ajustar estas irregularidades sea un proceso relativamente sencillo.

Ventajas

Inicialmente creamos el motor de anomalías para responder a una petición habitual de los clientes. Al considerar la auditoría declarativa tradicional, algunos clientes solían decir: “No quiero decirle a Core Audit sobre qué informar, quiero que Core Audit me diga qué mirar”.

A medida que la tecnología evolucionaba, ayudaba a proteger subconjuntos de la actividad que antes se consideraban imposibles de controlar. Por ejemplo, para proteger la aplicación con sus miles de millones de SQL.

Las anomalías también han demostrado su eficacia para detectar la inyección SQL e incluso los intentos de inyección. La inyección SQL, inevitablemente, hace que la aplicación haga algo que se supone que no debe hacer, creando así una nueva construcción SQL fácil de identificar.

Hoy en día, las anomalías son una poderosa herramienta para reducir el volumen de informes, asegurando grandes subconjuntos de la actividad con un ratio de falsos positivos relativamente bajo.

Conclusión

El análisis de anomalías es vital para la seguridad moderna, ya que permite hacer más controles con menos recursos, como por ejemplo controlar mayores volúmenes procedentes de más fuentes con menos personal, menos tiempo y un conjunto de habilidades más reducido.

En lugar de revisar informes interminables, las anomalías hacen gran parte del trabajo pesado, indicando rápidamente los problemas potenciales. Aunque no son una solución mágica que lo resuelva todo, las anomalías pueden y deben ser un elemento clave en cualquier estrategia de seguridad.

Hable con nosotros para obtener más información y experimentar la diferencia de Core Audit.

Posted on

Proactive forensics

Investigación Forense Proactiva

¿Qué es la investigación forense proactiva? Aprenda sobre esta actividad fundamental que está en el corazón de todas las iniciativas de seguridad.

Uno de los mitos populares sobre la seguridad es que se puede obtener de una caja. Basta con instalar algo y ¡voilá! Estás mágicamente protegido. Pero en realidad eso nunca funciona así.

Independientemente de lo que intentes proteger, tu primer paso debe ser siempre comprender la actividad. Debes saber cómo se utiliza el sistema, quién lo utiliza, cómo, etc. Obtener este tipo de visibilidad en un sistema de producción en vivo es fundamental para averiguar cómo protegerlo.

Visibilidad

No se puede proteger lo que no se ve.

Aunque es importante, obtener visibilidad de los sistemas informáticos no es sencillo, y  resulta cada vez más difícil para los sistemas que procesan grandes volúmenes de actividad. Las bases de datos pueden procesar miles de SQL cada segundo, por lo que toda esta actividad es imposible de entender sin las herramientas adecuadas.

Core Audit es una solución de seguridad integral que incluye, entre sus muchas capacidades, la posibilidad de realizar investigaciones forenses proactivas. Éstas le darán una idea de lo que está ocurriendo en su base de datos. Es el primer paso que recomendamos a la hora de configurar su seguridad.

Una vez que sepa lo que ocurre, podrá diseñar informes eficaces, configurar alertas que tengan sentido, definir análisis prácticos de anomalías, etc.

Beneficios Adicionales

El análisis forense proactivo no se limita a configurar la seguridad, sino que es esencial para identificar las lagunas en las medidas de seguridad. A medida que la actividad evoluciona, debemos ajustar los controles para adaptarlos a los nuevos patrones de actividad, y es imposible hacerlo sin visibilidad. De lo contrario, tus controles quedarán gradualmente desfasados y, con el tiempo, obsoletos.

El análisis forense proactivo también permite identificar malas prácticas de seguridad. Personas que comparten cuentas, que se conectan desde ubicaciones inseguras, que descargan tablas de la base de datos, etcétera. Aunque no se trate de una violación, estas prácticas populares aumentan su exposición y hacen más probable una filtración de datos.

Conclusión

Hay muchas razones para revisar regularmente la actividad de la base de datos, pero la razón subyacente puede ser que necesitamos incluir a las personas en el proceso de seguridad. Independientemente de los informes, alertas o automatizaciones que creemos, una revisión humana periódica puede detectar fácilmente comportamientos y necesidades de seguridad que una máquina nunca detectaría.

Hable con nosotros para obtener más información y pruebe Core Audit para comprobar la diferencia.

Posted on

TOP 5 priorities – 2024 Cybersecurity

Top 5 Prioridades Ciber-Seguridad 2024

Un checklist rápido de los temas principales que deberás cubrir en el 2024, en orden de prioridades para ayudarte determinar qué viene primero.

Introducción

Al considerar las prioridades para el 2024, deben identificarse las brechas críticas entre lo que ya se está realizando y dónde debería estar. Para ayudar a lograrlo rápidamente, creamos una lista de las principales prioridades a abordar.

Una reciente encuesta mostró que aproximadamente la mitad del personal de seguridad incluye entre sus prioridades la automatización y la inteligencia artificial, para que le ayuden a ahorrar tiempo y mejorar la eficiencia. Todas las recomendaciones en las principales prioridades de perímetro y centrado en datos involucran áreas donde la automatización es posible y permiten alcanzar, de manera realista, esas altas eficiencias.

1. Perímetro básico

  • Cortafuegos:
    Cualquier cortafuegos básico servirá. El objetivo principal es garantizar que las conexiones entrantes estén bloqueadas, excepto IP y puertos específicos. Estos suelen estar aislados en una zona desmilitarizada para crear una segunda barrera de entrada.
  • Antivirus:
    Cualquier antivirus básico servirá. El objetivo principal es reducir el riesgo de virus y diversos programas maliciosos. Ningún antivirus es perfecto y casi todos los antivirus, incluidos los integrados en los sistemas operativos, proporcionan una protección razonable.
  • Antispam y DMARC:
    Cualquier sistema de filtro antispam básico funcionará, incluidos los gratuitos integrados en los clientes de correo electrónico. También debe validar las firmas DMARC en todo el correo entrante (tanto SPF como DKIM) y firmar todo el correo electrónico saliente con una política DMARC configurada para rechazar. Esto, por sí solo, reducirá significativamente la carga de spam y el riesgo de suplantaciones.

2. Centrado-en-datos: lineamientos básicos

Esto es algo de lo que carecen muchas organizaciones. Si actualmente no hace esto, debería ser su segunda prioridad. El objetivo centrado-en-datos es defenderse contra ataques que penetran el perímetro poroso antes de llegar a los datos.

  • Seguridad de la base de datos:
    Hay muchos aspectos de la seguridad de la base de datos, desde la configuración de permisos hasta el control de cambios, pero dado que la mayoría de las infracciones utilizan cuentas válidas, la medida más eficaz son las alertas sobre actividades anómalas o sospechosas.
  • Seguridad de las aplicaciones:
    Existen muchas medidas que incluyen revisiones de código, análisis de vulnerabilidades y más. Sin embargo, la cobertura más amplia en esta superficie de ataque extremadamente grande son las alertas de anomalías y los perfiles de actividad de aplicaciones y usuarios finales.
  • Enmascaramiento de datos:
    Esta es la forma más sencilla y eficaz de proteger los datos fuera de producción. Si copia datos de producción a entornos inseguros, debe enmascararlos.

3. Personal

Esto es algo que la mayoría de las organizaciones hacen hasta cierto punto, pero que normalmente pueden mejorar. El objetivo es reducir el riesgo de la mayor vulnerabilidad: las personas. Las dos prioridades anteriores abordan este riesgo, pero es bueno abordarlo de frente.

  • Capacitación:
    La capacitación en seguridad de los empleados puede ayudar a reducir el riesgo de un ataque de ingeniería social exitoso. Si bien es imposible reducir este riesgo a un solo dígito, un buen programa de capacitación con ejemplos e interacción del usuario puede ser una inversión que vale la pena. Los programas simples con presentaciones y videos tienen un impacto mínimo y es posible que no valga la pena la inversión.
  • Gestión de identidad:
    Si bien los proyectos de IAM pueden ser grandes y costosos, al menos debería tener medidas simples para rastrear al personal, cerrar cuentas innecesarias y tener un control básico de quiénes son sus usuarios y a qué tienen acceso.
  • Pentesting:
    Muchas empresas ofrecen escaneos e informes automatizados. Sin embargo, son inútiles cuando se trata de la verdadera vulnerabilidad: las personas. Un verdadero equipo rojo que intente violar la seguridad utilizando cualquier medio, incluida la ingeniería social, le dará una idea mucho mejor de su postura de seguridad. Evite informes sin sentido sobre vulnerabilidades teóricas que no pueden explotarse.

4. Respuestas de análisis forenses

Una vez que haya cubierto sus bases principales, debe pensar en lo que sucede cuando ocurre una infracción o un evento de seguridad.

  • Plan:
    Cree un plan de respuesta para manejar varios eventos. Los planes comienzan con quién identificó el evento, cómo se determina la gravedad, cuál es la respuesta inmediata, a quién se debe notificar, cómo se manejan las investigaciones y más. Tenga en cuenta que los eventos pueden ser generados por personal de seguridad, personal de TI o por terceros, como las fuerzas del orden.
  • Validar:
    Que el plan sea realista. Muchos planes se basan en información y datos forenses que no existen o que son difíciles de extraer y analizar. Algunos planes suponen que el personal tiene habilidades o que los sistemas de TI tienen capacidades que en la realidad faltan. Revise el plan con el personal adecuado para asegurarse de que cada paso sea realizable.
  • Práctica:
    Incluso los mejores planes fracasan cuando las personas no los ejecutan correctamente. Cree eventos realistas y deje que el personal haga su trabajo. Durante el evento, desempeña el papel del atacante, considera sus próximos movimientos e identifica cuándo se da cuenta de que el personal está respondiendo a la intrusión.

5.  Análisis de brechas

Finalmente, debe asegurarse de que todo esté bien implementado, identificar las debilidades y reforzar estratégicamente la seguridad.

  • Exploración de vulnerabilidades:
    Las herramientas automatizadas que exploran en busca de vulnerabilidades pueden identificar rápidamente posibles brechas de seguridad. Ya sean sistemas sin parches, configuraciones incorrectas, contraseñas predeterminadas o muchos otros problemas.
  • Análisis centrado en datos:
    Como principal y última línea de defensa, las medidas centradas en datos deben ser lo más herméticas posible. El análisis de posibles rutas de ataque puede resaltar los puntos débiles donde la seguridad merece una atención adicional.
  • Análisis de sistemas individuales:
    El análisis de la actividad de diferentes sistemas en cada silo es vital para obtener visibilidad del comportamiento en el mundo real. Saber lo que sucede puede ayudar a diseñar e implementar una seguridad más estricta, identificar prácticas de seguridad deficientes y más.

Pensamientos finales

Una estrategia de seguridad equilibrada y bien pensada puede ayudarle a maximizar su postura de seguridad y optimizar su presupuesto. Los puntos anteriores son esenciales para cualquier estrategia, pero cada entorno es diferente y se beneficiará de una asignación de inversión ligeramente diferente. Contáctanos para tener una consulta sin cargo sobre tu estrategia y ver cómo podemos ayudarte a maximizar tu presupuesto.

Estima tu riesgo

CALCULADORA

Calcúlalo AQUÍ

Contáctanos para
CONOCER MÁS

Escríbenos

Posted on

OpEx Vs. CapEx

Maximizar el presupuesto de Ciberseguridad

El objetivo es maximizar la seguridad con los recursos disponibles, incluidos dinero, personal y habilidades. Tomar la regla del 80/20 y las defensas secuenciales equilibradas y cómo implementar.

OpEx Vs. CapEx

Una encuesta reciente mostró que más del 50% de las empresas tienen un presupuesto que es principalmente OpEx (el resto se dividió entre CapEx, Mix y Otros). En LATAM, casi el 80% de las empresas tienen un presupuesto que es mayoritariamente OpEx.

En OpEx las empresas alquilan soluciones y servicios, por lo que cada año pagan por todo. En CapEx, las organizaciones compran productos, por lo que cada año seleccionan proyectos específicos en los que centrarse e invertir. La línea es un poco borrosa ya que incluso en CapEx hay que pagar por el soporte, e incluso en OpEx, las nuevas inversiones toman tiempo para implementarse. Entonces, ¿por qué es importante la distinción?

La flexibilidad de OpEx permite, en teoría, crear una distribución óptima de recursos cada año. Es más caro y puede requerir mucho tiempo, pero puedes redistribuir los recursos más libremente. Eso es parte del atractivo que lo hace tan popular. Por lo tanto, debería aprovechar parte de esa libertad en sus objetivos y planificación presupuestaria. No tienes que hacer el año que viene lo que hiciste el año pasado. Esto plantea la pregunta no trivial de cuál es la distribución óptima de recursos en su organización.

El CapEx también debería comenzar buscando la distribución óptima, pero luego requiere una pregunta adicional sobre cómo llegar allí. El camino puede durar varios años, entonces, ¿cuáles son los mejores proyectos a realizar este año que mejorarán la seguridad más rápidamente?

Primero, debemos considerar OpEx o CapEx: en OpEx alquilamos soluciones y servicios, por lo que cada año pagamos por todo. En CapEx, compramos productos, por lo que cada año tenemos proyectos en los que elegimos centrarnos e invertir. Pero incluso en CapEx tenemos que pagar por el soporte, e incluso en OpEx, tenemos que invertir tiempo en nuevas implementaciones. Entonces, ¿por qué la distinción?

La flexibilidad de OpEx permite, en teoría, crear la distribución óptima de recursos cada año. Es más caro y puede requerir mucho tiempo, pero podemos redistribuir nuestros recursos con mayor libertad. Eso significa que debemos ejercer esta libertad en nuestra planificación y objetivos. Entonces la pregunta importante es: ¿cuál es la distribución óptima de recursos en nuestra organización?

CapEx también debería comenzar preguntando cuál es la distribución óptima, pero luego agregar otra pregunta sobre cuál es el mejor camino para llegar allí. ¿Qué proyectos mejorarán la seguridad más rápidamente para que mejoremos nuestra postura lo más rápido posible?

80/20

Para entender la distribución óptima debemos recordar la regla 80/20. Dice que podemos lograr el 80% de los resultados con el 20% del costo/esfuerzo/tiempo y se necesita el resto del 80% de los recursos para lograr el último 20% de los resultados. 80/20 es una buena regla general en muchas áreas y en algunos casos resulta tener una proporción más extrema como 90/10.

Es decir, siempre debemos empezar por hacer ese 10%-20% de la inversión para conseguir el 80%-90% de los resultados. No necesitamos comprar el mejor firewall porque incluso un firewall simple o gratuito nos permitirá alcanzar el 80%-90% del camino. No necesitamos comprar el mejor antivirus porque incluso un antivirus simple o gratuito nos permitirá alcanzar entre el 80% y el 90% del camino. Y para ser honesto, ningún antivirus o firewall nos solucionará el 100% del camino porque ningún producto de seguridad ofrece una protección del 100%.

Lo mismo ocurre con la formación del personal, los filtros de spam y cualquier otro producto/servicio de seguridad: incluso los productos simples ofrecen una buena protección y ninguna solución es 100% efectiva.

Defensas en series

Ahora debes preguntarte cómo cubrimos ese último 10%-20%. ¿Qué compensa esas soluciones más simples y cómo esto nos lleva a una mayor seguridad?

Aquí es donde necesitamos introducir otro concepto de defensas paralelas y en serie. Las defensas paralelas son lo que conocemos como el eslabón más débil. Un pirata informático puede atravesar el firewall, el correo electrónico no deseado, la seguridad física, es posible que ya esté empleado en la empresa, etc. Cualquier brecha en el perímetro permitirá que el pirata informático ingrese a la red corporativa.

Por el contrario, las defensas seriales se refuerzan entre sí. Con las defensas en serie, un atacante tiene que romper múltiples capas de defensa para tener éxito. Entonces, ¿qué defensa debe traspasar un atacante después de traspasar el perímetro? Estas son las defensas internas alrededor de la base de datos y la aplicación que tendemos a llamar centradas en datos. No habrá una violación de datos si no se accede a la base de datos y/o a la aplicación de alguna manera.

Un cálculo probabilístico simple muestra que si logramos un 80% de protección en el perímetro y un 80% de protección alrededor de los datos, tendremos una protección combinada del 96%. Si el perímetro y el centrado en datos están ambos al 90%, la protección combinada será del 99%. Se trata de niveles de protección que son imposibles de alcanzar con defensas paralelas, independientemente de la inversión.

En otras palabras, lograr niveles de protección similares en el perímetro y centrado en los datos logrará una postura de seguridad óptima.

Presupuesto

¿Cuáles son entonces las mejores asignaciones presupuestarias?

Es difícil dar una cifra exacta porque cada entorno es diferente y tiene un perfil de riesgo único. ¿Cuántos puntos finales, cuántas bases de datos y aplicaciones, qué tan capacitados están los empleados, etc.?

Sin embargo, como referencia, considere una asignación general de:

  • 40% para Perímetro

Esto incluye seguridad de red, puntos finales, seguridad del correo electrónico, capacitación de empleados y más.

  • 40% para Centrado en Datos

Esto incluye seguridad de bases de datos, seguridad de aplicaciones, enmascaramiento de datos, gestión de identidades, autenticación, cifrado, cadena de suministro y más.

  • 20% para Otros esfuerzos

Esto incluye respuesta a incidentes, inteligencia sobre amenazas, SIEM, etc.

Dentro de cada categoría, las asignaciones deben hacerse de manera diferente:

  • En el perímetro, el objetivo es conseguir un nivel de protección similar en todas las categorías. Dado que es casi imposible lograr más del 90% en la capacitación de los empleados, el 90% es un objetivo bueno y razonable para todos los proyectos: bloquear 9 de cada 10 intentos.
  • En el ámbito centrado en datos, el objetivo es centrarse más en categorías que tienen más probabilidades de ofrecer protecciones internas contra ese 1 de cada 10 que traspasó el perímetro. La aplicación y la base de datos tienden a clasificarse como las más importantes.
  • En otros esfuerzos, la atención suele centrarse en proyectos específicos que se ajustan al enfoque de seguridad de la organización, y las organizaciones rara vez invierten en todos los ámbitos.
  • Su organización puede ser diferente y requerir asignaciones diferentes. Por ejemplo, las empresas más pequeñas con presupuestos más reducidos podrían reducir o eliminar por completo la categoría “otros” y centrar sus esfuerzos en el perímetro y centrados en los datos.

Pensamientos finales

Con una buena planificación y asignación, es posible alcanzar niveles extremadamente altos de protección con una inversión modesta. Si bien todos queremos un presupuesto mayor, se puede lograr mucho con mucho menos de lo que gastamos actualmente. Se trata simplemente de recordar que ningún esfuerzo por sí solo puede llevarnos al 100% y siempre debemos compensar con defensas superpuestas o en serie.

Contáctenos para obtener más información sobre cómo podemos ayudarlo a proteger su aplicación y sus datos.

Estima tu riesgo

CALCULADORA

Calcúlalo AQUÍ

Contáctanos para
CONOCER MÁS

Escríbenos

Posted on

Tecnologías Anti-breach – Aplicaciones

Seguridad de Aplicaciones

Las aplicaciones tienen una gran superficie de ataque difícil de proteger. Es imposible encontrar y abordar todas las vulnerabilidades. ¿La solución? Utilizar tecnologías que puedan detectar cualquier ataque.

Las aplicaciones tienen una gran superficie de ataque debido a la contribución de muchos factores:

  • Cuentas de aplicaciones con acceso directo a datos sensibles.
  • Otras cuentas de aplicaciones que pueden requerir explotar una vulnerabilidad como la inyección SQL.
  • Susceptibilidad del usuario final a ataques de ingeniería social como correos electrónicos de phishing, XSS y más.

También existen muchas causas para las vulnerabilidades, formas de acceder a las cuentas, etc.

El problema con una superficie de ataque tan grande es que no sabes por dónde empezar y parece imposible cubrirlo todo. Pero eso es sólo porque estás viendo el problema de manera equivocada.

Intentar encontrar y abordar cada agujero y vulnerabilidad es imposible e inevitablemente fracasará. Si bien es un esfuerzo importante y que vale la pena, no se puede lograr una cobertura suficiente para reducir el riesgo a niveles aceptables.

La solución no es perseguir cada vector de ataque individualmente, sino reconocer que cualquier ataque provocará un cambio en el perfil de comportamiento de la aplicación. Por tanto, monitorear la aplicación y sus usuarios nos permitirá identificar ataques y responder.

Capturar la actividad es el primer desafío para lograr este monitoreo, y depende de la tecnología de la stack de la aplicación. Core Audit contiene múltiples agentes que pueden capturar actividad en diferentes partes del stack:

  • El navegador web del cliente de la aplicación.
  • La aplicación que se ejecuta en el servidor.
  • La base de datos

Independientemente de si la infracción se debe a un abuso de privilegios, una escalada de privilegios, actores externos u otras causas, el perfil de comportamiento del usuario y de la aplicación a menudo mostrará cambios en más de una parte del stack.

Core Audit ofrece múltiples enfoques para permitirle comprender el perfil de comportamiento y reconocer los cambios de manera eficiente. Cada uno es útil en diferentes circunstancias y, en general, se recomienda utilizar una combinación de metodologías. Las metodologías pueden ser, por ejemplo, análisis de anomalías, auditoría declarativa, alertas, análisis forense proactivo y reactivo, y más.

Además de las medidas de detección, Core Audit también ofrece capacidades preventivas. Estas capacidades pueden proteger la aplicación y el cliente web bloqueando comportamientos ilegítimos de ciertos tipos. Por ejemplo, los filtros del cliente web pueden restringir el navegador web para que se comunique únicamente con el servidor de aplicaciones, evitando así ataques XSS y similares.

Contáctenos para obtener más información sobre cómo podemos ayudarlo a proteger su aplicación y sus datos.

Estima tu riesgo

CALCULADORA

Calcúlalo AQUÍ

Contáctanos para
CONOCER MÁS

Escríbenos