Fitted Security

Seguridad a medida

Muchas organizaciones diseñan sus estrategias de ciberseguridad y deciden qué soluciones comprar en función de las tendencias y mejores prácticas de la industria. El resultado suele ser desequilibrado e inapropiado para el perfil de riesgo y las necesidades de seguridad de la organización.

Las implementaciones de mejores prácticas suelen ser de talla única y no se adaptan al entorno específico. Al ser predecibles, generalmente existen herramientas y guías en Internet que pueden vencerlos. Un enfoque genérico de esta naturaleza tampoco logra aprovechar las ventajas fácilmente disponibles cuando se examinan los aspectos específicos del entorno.

Muchas soluciones vienen con seguridad lista para usar. Contienen políticas integradas y firmas diseñadas para una baja tasa de falsos positivos en cualquier entorno. Estos tienen dificultades para identificar variaciones de ataque y nunca pueden identificar otros vectores, lo que resulta en una defensa más débil.

Este documento trata sobre cómo hacer la seguridad de manera diferente.

Perímetro vs. Centrado en datos

La mayoría de las soluciones de seguridad se clasifican en una de dos categorías: seguridad perimetral o seguridad centrada en los datos.

La seguridad perimetral tiene como objetivo evitar que los atacantes ingresen a la red y accedan a los sistemas internos. Un escritorio comprometido no es una violación de datos, pero una vez que los atacantes tienen este acceso, pueden dar el siguiente paso e intentar obtener acceso a la aplicación o la base de datos. Una violación de datos solo ocurriría si los atacantes pueden navegar desde ese escritorio comprometido hasta los datos.

La seguridad perimetral tiene dos limitaciones estratégicas:

  • Amenazas internas: cuando una amenaza ya está dentro de la red y detrás del perímetro, no puede protegerse con este tipo de defensas. Lo mismo se aplica a las amenazas fuera de la red con acceso VPN (por ejemplo, socios, consultores y más).
  • Defensa estadística: las protecciones perimetrales casi siempre tienen como objetivo reducir el número de penetraciones, pero no evitarlas por completo. Independientemente de lo buenos que sean nuestros filtros de spam, seguimos recibiendo correos electrónicos no deseados. No importa cuán buena sea la capacitación de nuestro personal, la gente aún hace click en esos correos electrónicos de phishing.

Data-centric es una metodología que gira en torno a los datos. Comienza con el lugar donde se almacenan los datos: la base de datos y se expande hacia las aplicaciones que procesan esos datos.

La seguridad centrada en datos incluye seguridad de bases de datos, seguridad de aplicaciones, IAM y más. Una sólida postura centrada en los datos puede evitar una filtración de datos independientemente de cuántos atacantes hayan penetrado en el perímetro. Por ejemplo, las aplicaciones basadas en la nube se basan principalmente en medidas centradas en datos.

La seguridad perimetral es una defensa paralela donde los atacantes solo necesitan violar una de las medidas para ingresar. Los atacantes que no logran penetrar el firewall pueden probar el sistema de correo, la ingeniería social, etc. La seguridad perimetral es tan fuerte como su eslabón más débil.

La seguridad centrada en datos es una seguridad en capas que da como resultado una defensa en serie donde los atacantes deben penetrar todas las capas. Una violación exitosa de la aplicación que no puede ejecutar un ataque contra la base de datos es un ataque fallido. La seguridad centrada en los datos es la última línea de defensa y pretende ser lo más hermética posible.

Las defensas perimetrales y centradas en datos no se excluyen mutuamente, y las estrategias bien equilibradas incluirán ambas.

Consideraciones generales

Al construir una estrategia de seguridad, debemos considerar las amenazas que percibimos como relevantes. Por ejemplo, ¿nos preocupan las amenazas externas, las amenazas internas, o ambas? Si las amenazas internas son una preocupación importante, la seguridad del perímetro no será eficaz contra ellas y debemos reforzar los componentes centrados en los datos.

También debemos considerar la efectividad de diferentes medidas en el panorama actual. Por ejemplo, a medida que más y más personas trabajan de forma remota, la seguridad de la red y la seguridad de los terminales son menos efectivas. Una vez que las personas trabajan desde casa, están fuera del firewall corporativo y usan las computadoras de su hogar. Con un control mínimo sobre todas estas minioficinas remotas con conexiones VPN, nuestra defensa perimetral se vuelve más débil de lo esperado.

BYOD (Bring-Your-Own-Device) plantea un desafío similar en el que muchos teléfonos y tabletas descontrolados e inseguros deambulan por la red corporativa dentro de nuestro perímetro.

A medida que cambia el panorama moderno y disminuye la efectividad de los controles perimetrales, hay un cambio creciente hacia las defensas internas. Parte de este cambio incluye una redefinición de la línea perimetral: proteger la red del centro de datos es más importante que la red corporativa.

Consideraciones de activos

Hay varias consideraciones a la hora de elegir en qué sistemas centrar nuestras defensas y cómo asignar los recursos:

  • Riesgo: algunos sistemas presentan un mayor riesgo que otros. Por ejemplo, es necesario un firewall porque, sin él, tendremos infinidad de atacantes dentro de nuestra red. Necesitamos defender la aplicación porque todas las personas que la usan, o tienen acceso a la red, forman una gran superficie. También debemos proteger nuestra base de datos porque almacena todos los datos y una violación sería catastrófica.
  • Efectividad: algunos sistemas son más fáciles de asegurar con mejores resultados, mientras que otros pueden ser costosos de proteger o tener beneficios de seguridad limitados. Por ejemplo, los firewalls son una medida efectiva y son baratos y fáciles de implementar; esa es una opción fácil. La seguridad de la aplicación o la base de datos (según la solución utilizada) puede ser difícil o costosa de implementar, pero con buenos resultados. IAM puede ser costoso de implementar pero con un valor limitado.
  • Caminos de ataque: algunos sistemas se encuentran en una ruta crítica entre los atacantes y los datos. Otros están en caminos que los atacantes podrían eludir. Por ejemplo, un atacante debe comunicarse con la base de datos para extraer los datos. Es poco probable que un ataque tenga éxito sin él. Sin embargo, si una aplicación está en esa ruta depende del entorno. A veces, la ruta principal a los datos es a través de una sola aplicación. En otros casos, varias aplicaciones o conexiones directas a bases de datos ofrecen rutas alternativas.

Equilibrar las rutas de riesgo, eficacia y ataque es una consideración central en la estrategia de ciberseguridad, y existen múltiples métodos de equilibrio. Sin embargo, es importante recordar que hay muchas variables. Por ejemplo, la efectividad de la seguridad depende de la solución y la tecnología que esté evaluando, ya que las diferentes soluciones diferirán en costo y efectividad.

IDS e IPS

Los sistemas de detección de intrusiones (IDS) y los sistemas de prevención de intrusiones (IPS) son metodologías fundamentalmente diferentes en seguridad.

IPS tiene como objetivo prevenir ataques e infracciones. Estos son sistemas de seguridad clásicos como firewalls, usuarios y contraseñas, etc. Los IPS son componentes críticos en cualquier estrategia de seguridad.

Por el contrario, IDS busca detectar ataques y alertar o informar sobre ellos. Estos incluyen medidas como auditoría, SIEM, etc. Los IDS también son un componente crítico en cualquier estrategia de seguridad, ya que informan al personal de seguridad, les permiten iniciar una respuesta y brindan información forense.

Es importante comprender las diferencias fundamentales entre IPS e IDS:

  • Tolerancia a los falsos positivos.
    Los falsos positivos en IPS significan que el sistema impide que los usuarios realicen actividades legítimas. Por lo tanto, IPS no puede tolerar falsos positivos.
    Los falsos positivos en IDS significan que los informes o alertas requieren que el personal de seguridad los investigue mientras los usuarios continúan haciendo su trabajo. Si bien no queremos demasiados falsos positivos, la mayoría de los IDS están diseñados y calibrados para tener un cierto nivel de falsos positivos.
  • Tiempo de respuesta.
    IPS debe determinar si las actividades son válidas antes de dejarlas pasar. Un IPS lento significa que los sistemas de TI tienen tiempos de respuesta más largos y los usuarios se quejan. Por lo tanto, un IPS siempre está diseñado para usar algoritmos en tiempo real capaces de tomar decisiones en una fracción de segundo.
    IDS, por otro lado, puede tomarse su tiempo para informar o alertar. Los IDS suelen utilizar algoritmos más complejos y pueden analizar grandes volúmenes de datos para identificar intrusiones. Pueden hacer referencia a información histórica o esperar a que ocurran eventos futuros.
  • Burla.
    Cuando un sistema IPS previene un ataque, el atacante es inevitablemente consciente del intento fallido y puede volver a intentarlo. Por lo tanto, los atacantes desafían constantemente los sistemas IPS hasta que encuentran la manera de penetrarlos.
    Los IDS informan al personal de seguridad del ataque permitiéndoles responder de varias maneras. Las respuestas pueden incluir desconectar los sistemas, desviar los ataques a los honeypots, rastrear el ataque hasta su fuente y más. En todos los casos, los atacantes no tienen una segunda oportunidad de volver a intentarlo contra una defensa idéntica. Los sistemas IDS son, por lo tanto, mucho más difíciles de eludir.

En consecuencia, mientras que IPS podría prevenir una intrusión, es más probable que IDS la detecte y es menos probable que se eluda. Siempre se recomienda, cuando sea posible, implementar ambos tipos de sistemas. Implemente un IPS para bloquear la mayoría de los ataques e implemente un IDS para detectar los que pasaron.

Seguridad a medida

Cada entorno es diferente. Las diferencias incluyen la arquitectura de la aplicación, la pila de tecnología, la cantidad de usuarios, el acceso del administrador y más. Otros parámetros incluyen los roles de usuario, los programas en uso, los segmentos de red, los tipos de datos, los perfiles de actividad, etc.

Aprovechar dichos parámetros mientras se implementan medidas preventivas y de detección produce resultados más efectivos. Tal seguridad personalizada no puede estar lista para usar, ya que requiere evaluación, consideración y planificación. Sin embargo, es vital para lograr una alta efectividad en la detección de ataques y una baja tasa de falsos positivos.

Personalizar la seguridad de esta manera requiere tiempo y esfuerzo, y no existe una varita mágica. Pero es mucho más probable que los resultados resistan un ataque y prevengan una violación de datos.

DCSA

La evaluación de seguridad centrada en datos es un servicio que ofrece Blue Core Research para ayudar a los departamentos de seguridad a cuantificar el riesgo de cada uno de sus sistemas y evaluar la eficacia de diferentes controles y estrategias.

DCSA es una evaluación basada en entrevistas que utiliza su opinión sobre sus sistemas. Combinará múltiples parámetros sobre cada sistema en su entorno y producirá su nivel de riesgo.

DCSA tiene como objetivo ayudarlo a elegir las soluciones y estrategias con el mayor impacto en su seguridad para minimizar el riesgo.

Pensamientos finales

La calidad y la solidez de su estrategia de seguridad dependen del tiempo y el esfuerzo que se dediquen a ella. Tendrá una buena postura de seguridad si tiene un buen equilibrio entre su perímetro y su centro de datos, creó seguridad en capas, combinó IPS e IDS en cada sistema con una estrategia de respuesta adecuada, adaptó sus soluciones a cada entorno, y distribuye sus recursos de acuerdo con el riesgo, la eficacia y las rutas de ataque que es probable que sigan los atacantes.

Suena a mucho, pero no es tan difícil. Sin embargo, significa no seguir las tendencias y comprar soluciones solo porque están de moda. Significa poner esfuerzos en las implementaciones y no solo buscar seguir las mejores prácticas. Eso requiere esfuerzo y una reflexión cuidadosa, pero es la mejor manera de reducir el riesgo de una filtración de datos.

AGENDA UNA CONSULTA SIN COSTO


Únete a nuestro próximo
WEBINARIO

Inscríbete


AI and Cybersecurity

IA y Ciberseguridad

¿Cómo la inteligencia artificial, en particular la nueva inteligencia artificial generativa, afecta la ciberseguridad? Este trabajo examina desarrollos en inteligencia artificial, sus posibles implicaciones en ciberseguridad, y las esperadas tendencias en la industria.

Capacidades IA

Antes de discutir ciberseguridad, debemos entender primero la IA y qué puede hacer.

IA intenta imitar a la gente. Y significa mímica sin pensar. Solo actuar en formas que parecen similares. La IA no tiene una agenda, no entiende consecuencias, no aplica la lógica, sentimientos, o incluso sentido común. La IA no entiende qué dice o hace o por qué. Solo busca lo que la gente ha hecho y trata de imitarlo así los resultados lucen similar.

Para conseguir esto, necesitamos entrenar una inteligencia artificial. Entrenar a una IA significa darle muchos ejemplos y dejándole encontrar los patrones. No sabemos usualmente o entendemos que ve la IA en la información con la que la alimentamos, o si al seguir esos patrones conseguiremos los resultados esperados.

Pero desde que no entiende o piensa, podemos asumir errores cuando aplicamos escenarios intrincados. Errores que incluso niños no cometerían porque aún un chico entiende qué está haciendo.

Desafíos en ciberseguridad

Más allá de sus capacidades limitadas, la IA representa una significativa y en aumento amenaza a la ciberseguridad.

Una razón por esta amenaza es que la IA es mucho mejor hoy imitando humanos. Sistemas de seguridad y protocolos que intentan establecer que están hablando con una persona probablemente fallarán eventualmente. El ejemplo más simple es CAPTCHA, pero hay otros casos, incluyendo protocolos de mesa de ayuda, cuyo propósito es establecer que no se están comunicando con una máquina.

Un tema más alarmante es que las imitaciones de la IA aparecen como falto de patrones o, más precisamente, tiene patrones muy complejos de reconocer. Esto significa que la seguridad de los sistemas basados en la firma no será capaz de identificar las firmas de los ataques. Estos incluyen anti-virus, anti-malware, WAF, filtros de email, y más.

Por ejemplo, los virus polimorfos no son nuevos, pero la IA puede reescribir el código de ataque en formas elaboradas, haciéndola imposible de detectar. El mismo aplica a WAF y muchos otros sistemas de seguridad basados en firmas.

Finalmente, la IA moderna a menudo aparece como humana, y no podemos decir cuál es la diferencia. Entonces los ataques de ingeniería social pueden ser automatizados y escalados en volumen y complejidad. Las personas encontrarán más difícil de identificar phishing emails en tanto lucirán como los realistas.

Desde que cada phishing email será completamente diferente, ellos también engañarán spam filters. Así que usen filtros Bayesian u otros algoritmos, será duro reconocer múltiples emails son esencialmente una reescritura del mismo mensaje. Por lo tanto, protección de email será menos efectiva.

Debido a que las capacidades generativas de las IAs modernas las vuelven indistinguibles de los humanos, la mayoría de las defensas de seguridad basadas en IA probablemente se volverán ineficaces contra una IA atacante.

Mientras todo esto suena muy severo, en última instancia es solo otro clavo en la muerte del perímetro. El perímetro sufrió múltiples golpes a través de los años recientes, incluyendo trabajo remoto y BYOD. Junto con la actual alta tasa de éxito de los ataques de phishing, estamos perdiendo la batalla. Es probable que esta batalla empeore cuando los atacantes empiecen a aprovechar la IA.

Asegurar que nadie penetre el perímetro es imposible, y nuestra habilidad para controlarlo probablemente continuará siendo menor.

Diferenciación de actor

Mientras la IA presenta desafíos, muchos actores probablemente no tendrán acceso a ella. Puede cambiar en el futuro, pero el acceso directo a la tecnología y recursos requeridos de informática es poco probable se convierta en un lugar común.

Actor estatales probablemente ya tienen acceso a IA o pronto la tendrán. Ataques de grupos grandes tal vez también obtengan acceso a los recursos necesarios. Pero los script kiddies son el grupo más grande de atacantes y es poco probable que tengan acceso a tales capacidades.

En otras palabras, la diferencia entre los actores grandes y pequeños se volverá más extrema. Grandes actores son probablemente ya capaces de penetrar tu perímetro y encontrarán eso más fácil de hacer en el futuro, mientras pequeños actores continuarán utilizando sus actuales métodos y herramientas.

De cualquier forma, mejorar nuestras defensas contra las amenazas de la IA no solo mitigará los riesgos de la IA pero además significativamente reducirá el riesgo de pequeños actores.

Medidas efectivas

Es importante considerar qué tipo de medidas son efectivas contra la IA. Lo más alto que percibes la amenaza de actores con accesos a la IA, más debes invertir en tecnologías resilientes.

La seguridad más efectiva es la basada en la verdad. Esta reside en saber la respuesta correcta. La respuesta más simple es un usuario & contraseña. Ahí hay solo una respuesta correcta, y más allá de como los humanos- como una IA es, no será capaz de adivinarlo. Lo mismo aplica a autenticación de dos factores, preguntas de seguridad, cartas clave, biométricos, y más. Pero no es necesario invertir en complejidad o seguridad cara para combatir la IA desde que toda la seguridad basada en la verdad es IA resiliente.

Una medida en la que vale invertir es la gente. Más precisamente, pensando en la gente. Las IAs atacantes pueden imitar gente pero no puede pensar, y las IAs defensivas tienen la misma limitación. Trayendo a la gente de vuelta en el juego de la seguridad traerá de vuelta la fortaleza de pensamientos humanos y sentido común.

Pero hay buenas razones para nuestra mayor dependencia de la automatización en lugar de las personas. Estos incluyen el costo de personal, encontrar la persona apropiada, y, más importante, el desafío de humanos controlando volúmenes masivos de actividad.

Traer gente de vuelta a la seguridad requiere armarlos con sistemas detectives que pueden manejar los volúmenes de actividad y dar visibilidad a ella. Como los sistemas de prevención y detección automática continúan tu declive en efectividad, seguridad basada en el humano se volverá más crítica.

Finalmente, deberíamos volvernos menos predecibles y no confiar tanto en paradigmas estándardes de seguridad y buenas prácticas. Pero personalizando nuestra seguridad y haciendo cosas diferentes, sistemas automatizados no sabrán qué esperar y falta de patrones para seguir o imitar.

Incluso hoy, escaneos de vulnerabilidad es una herramienta efectiva usada por atacantes. Es efectiva porque el software escaneado sabe que esperar y puede testear un número grande de vectores de ataques contra un número grande de sistemas. Lo más único de nuestra seguridad, lo menos probable es que sea por un escaneo de vulnerabilidad o una IA entrenada para asistir a un atacante.

Educación & Entrenamiento

¿Por qué están el desafío del perímetro e IA haciendo las cosas peor? La principal razón nuestros usuarios. Y también es una actitud general que Internet puede ser seguro y usarlo requerirá pequeños entrenamientos y conocimiento.

Nuestros usuarios constantemente interactúan con internet pero carecen de habilidades para protegerse y a la organización. También usan softwares que pretenden ser fáciles pero promueven comportamiento de seguridad pobre.

Por ejemplo, métodos de automatización de emails como SPF, DKIM, y DMARC pueden validar la fuente de email y están aumentando su popularidad. Como sea, la gente no mira la dirección de email o el dominio – miran lo más rápido de leer que es el nombre del display. Y las personas solo tienen parte de la culpa porque la mayoría del software de emails solo muestra este nombre para mostrar en la lista de corre electrónico y, usualmente, luego de abrir el email también.

Para empoderar a la gente a ser consiente de quién les manda el email, debemos hacer más que meramente hacer cumplir DMARC políticas. Debemos exponer a la gente a una dirección de email y nombre de dominios de quien envía y entrenarlos para mirar y entender esto.

Otro ejemplo es la facilidad con la cual la gente puede abrir un adjunto o hacer click en un link en un email. Dichas acciones deberían requerir al menos dos pasos. Por ejemplo, usuarios deberían salvar archivos adjuntos antes de ser capaces de abrirlos. Un link debería ser copiado y pegado en un navegador. Mientras tales pasos extra hacen el uso menos amigable, eso evita el accidental común click y fuerza a los usuarios a ser más consiente de acciones potencialmente peligrosas.

Similarmente, encriptado y certificados pueden validar la máquina remota y asegurar el secreto de la comunicación. Como sea, para esto ser efectivo, la gente necesita mirar el dominio en la URL.

Internet no es un lugar seguro. Esa es la realidad. Son individuos, grupos, y organizaciones que quieren hacernos daño. Con la IA a su lado, nuestra capacidad para fingir que estas entidades nefastas no existe disminuirá.

Centrado en datos

Como el perímetro se vuelve menos efectivo, debemos continuar cambiando nuestro foco a seguridad centrada en datos. Esto es una tendencia en crecimiento, y las amenazas de IA pueden probablemente potenciarlo.

Seguridad centrada en datos va alrededor de proteger los sistemas responsables por procesamiento de datos y almacenamiento. La motivación es que una filtración de perímetro será una filtración de datos fallidos si el atacante no puede comprometer los sistemas internos que manejan los datos.

Proteger las aplicaciones y bases de datos es efectivo contra amenazas internas y no solo las externas. El tipo de seguridad también crea una capa donde los ataques pueden ser detectados por múltiples medidas de seguridad, por lo tanto reduciendo las oportunidades de una filtración exitosa.

Seguridad centrada en datos busca proteger contra la gente, entonces una IA imitando exitosamente el comportamiento humano no es un riesgo en crecimiento. Centrado en datos es además más resiliente a la IA porque estos sistemas internos son usualmente separados de Internet por la menos una capa de protección de red. Esta separación de red hacer que sea más difícil para una IA basada en la nube atacar sistemas internos.

Seguridad detective

La creciente importancia de la seguridad centrada en datos, involucramiento humano, y menos predecible defensas llevan atención para un tipo particular de soluciones de seguridad detectives.

Estas son soluciones que pueden:

  • Manejar el volumen extremadamente alto de actividad de bases de datos y aplicaciones.
  • Ofrece personalizaciones usando ambientes específicos atributos en alertando, reporteando, análisis, y más.
  • Dar al personal de seguridad completa visibilidad sobre todo lo que está sucediendo usando herramientas forenses interactivas y de avanzada.

Core Audit de Blue Core Research hace más fácil conseguir estos objetivos. Desde análisis de anomalías a 360° forenses, y mucho más, Core Audit es un solución integral que puede ayudar a que encuentres y superar tu actual y futura seguridad y desafíos de cumplimiento normativo.

Ideas finales

Es difícil predecir cuando la amenaza de IA de ciberseguridad se materializará o por cuánto tiempo tomará antes que sepamos de una filtración asistida por IA. Hoy, esta amenaza es probablemente limitada por el estado o muy grandes actores de quien las filtraciones de datos son a veces no descubiertas y cuyos métodos pueden mantener desconocidos.

IA es poco probable que cambie los riesgos de pequeños actores, pero IA- defensas resilientes probablemente también será efectivo contra ellos.

El desafío principal continúa siendo mejorar el comportamiento humano. Es probable que la Ingeniería social aumente como riesgo principal, ya que las personas siguen siendo el talón de Aquiles de la seguridad.

IA no parece forzar un cambio en las tendencias de seguridad, solo acelerarlas y demandar atención a cambios ya necesarios. Estos incluyen el valor menguante de las defensas perimetrales de alta gama ya que luchan por la justificación y el cambio de enfoque hacia la seguridad centrada en los datos.

Download this

WHITEPAPER

Download HERE


Talk to us to
LEARN MORE

Contact us

SQL Injection Attack Detection

Detección de ataques de Inyección de SQL

Recibí un alerta dos días antes de año nuevo. Fue poco antes de la media noche el 30 de diciembre de 2021. Era una alerta de una anomalía diaria relacionada al backend de la base de datos de un viejo sitio web, pero claramente un ataque.

Como se vio luego, este fue el primero de muchos intentos de ataques. Hubo tres más en enero de 2022, dos más en febrero, y uno más en agosto, octubre, y noviembre. Considerándolo todo, nueve ataques similares en el curso de un año.

Antecedentes

Usamos WordPress (un sistema de gestión de contenidos de código abierto) en muchos de nuestros sitios webs y siempre con un backend MySQL (la configuración más popular). El sitio web en questión era viejo, y debido a problemas de compatibilidad, no habíamos actualizado algunos de los componentes de software en un tiempo. Entonces cuando vi esta alerta, pareció altamente plausible que había una vulnerabilidad que derivó en un ataque exitoso.

Como luego resultó, esto era un falso positivo. La razón de este falso positivo fue que adicional a una vieja versión de WordPress y plugins, este sitio web también usaba una vieja versión de Core Audit. Pero más de esto luego.

Ninguno de nuestros sitios web contiene información confidencial, pero como mostrará este documento, proteger la base de datos de cualquier aplicación con Core Audit es un medio muy eficaz para detectar ataques y proteguer la aplicación.

La Anomalía

El alerta de anomalía tiene 168 líneas, y la primera línea fue esta:

SELECT * FROM wp_users WHERE user_login = 
'') UNION ALL SELECT NULL-- HupP'

Mientras cada línea fue diferente, cada línea empezó con uno de estos:

SELECT * FROM wp_users WHERE user_login =''

SELECT * FROM wp_users
 INNER JOIN wp_usermeta ON user_id = ID WHERE meta_key = '' AND user_login = ''

Lo que hizo claro que se trataba de un ataque fueron las muchas variaciones de SQLs que lucen como esto:

;SELECT SLEEP(9)#' LIMIT 9

) AND SLEEP(9) AND (\\\''=\\\''

WAITFOR DELAY \\\'' AND \\\''=\\\'' LIMIT 9

;SELECT SLEEP(9)#'

);SELECT PG_SLEEP(9)--'

;SELECT PG_SLEEP(9)--' LIMIT 9

);WAITFOR DELAY \\\''--'

;WAITFOR DELAY \\\''--' LIMIT 9

) AND 9=(SELECT 9 FROM PG_SLEEP(9))

UNION ALL SELECT NULL-- HupP'

) UNION ALL SELECT NULL-- HupP' LIMIT 9

UNION ALL SELECT NULL,NULL,NULL-- iIWs'

UNION ALL SELECT NULL,NULL,NULL,NULL-- ynbe'

Tener en cuenta que las cuerdas vacías ('') y los 9s no son parte del SQL original. Ellos se relacionan en cómo la seguridad del repositorio de Core Audit opera. Este repositorio automáticamente colecciona todos los SQLs en la base de datos, entonces para reducir espacio y eliminar anomalías de literales embebidos, automaticamente elimina todos los números y cuerdas.

Los SQLs vistos anteriormente son el resultado de un atacante que intentó escanear la aplicación en búsqueda de una vulnerabilidad de inyección de SQL. Intentaban detectar si la inyección SQL era posible en esta aplicación y encontrar información adicional que facilitara el ataque:

  • Cada instrucción SLEEP/DELAY solo funcionaría en un tipo de base de datos. Así que un retraso en la respuesta le dice al atacante que la inyección fue exitosa y el tipo de base de datos utilizada.
  • Las diversas permutaciones UNION y NULL estaban tratando de determinar el número de campos en la query y si podrían agregar datos de otras tablas.

Adicional a muchas más variaciones de SLEEP y UNION, hubo expresiones llenas de color como:

) AND (SELECT 9 FROM(SELECT COUNT(*),CONCAT(0x7178707671,(SELECT (ELT(9=9,9))),0x7171767171,FLOOR(RAND(9)*9))x FROM INFORMATION_SCHEMA.CHARAC

) AND 9=CAST((CHR(9)||CHR(9)||CHR(9)||CHR(9)||CHR(9))||(SELECT (CASE WHEN (9=9) THEN 9 ELSE 9 END))::text||(CHR(9)||CHR(9)||CHR(9)||CHR(9)||C

) AND 9=CAST((CHR(9)||CHR(9)||CHR(9)||CHR(9)||CHR(9))||(SELECT (CASE WHEN (9=9) THEN 9 ELSE 9 END))::text||(CHR(9)||CHR(9)||CHR(9 )||CHR(9)||CHR(9)) AS NUMERIC) AND (\\\''= \\\''

;SELECT DBMS_PIPE.RECEIVE_MESSAGE(CHR(9)||CHR(9)||CHR(9)||CHR(9),9) FROM DUAL--'

AND 9=CONVERT(INT,(SELECT CHAR(9)+CHAR(9)+CHAR(9)+CHAR(9)+CHAR(9)+(SELECT (CASE WHEN (9=9) THEN CHAR(9) ELSE CHAR(9) END))+CHA R(9)+CHAR(9)+C

) AND (SELECT 9 FROM(SELECT COUNT(*),CONCAT(0x7178707671,(SELECT (ELT(9=9,9))),0x7171767171,FLOOR(RAND(9)*9))x FROM INFORMATION_SCHEMA.CHARACTER_SETS GROUP BY x)a) AND (\\\''=\\\''

) AND 9=CONVERT(INT,(SELECT CHAR(9)+CHAR(9)+CHAR(9)+CHAR(9)+CHAR(9)+(SELECT (CASE WHEN (9=9) THEN CHAR(9) ELSE CHAR(9) END))+CHAR(9)+CHAR(9)+CHAR(9)+CHAR(9)+CHAR(9))) AND (\\\''=\\\''

Estos SQLs eran claramente inusuales y parecen intentar eludir un sistema de protección de inyección de SQL como un WAF.

Forences

Experimentamos un ataque. El alerta no deja ninguna duda sobre esto. Las dos preguntas remanentes fueron:

  • ¿Fue exitoso el ataque?
  • ¿Qué parte de la aplicación fue objetivo?

Base de datos forences

La primera pregunta fue fácil de responder. Empecé por localizar las queries en la vista forense de SQL reducida. El repositorio reducido de SQL tiene una resolución de 5 minutos, y todos estos SQLs fueron ejecutados en la ventana de 8:20 am a 8:25 am.

Una vez que localicé las queries, también vi las buenas noticias – todos fueron exitosos (sin errores), y los números de las filas recuperadas fueron cero para todas.

¿Por qué son buenas noticias las ejecuciones exitosas? Porque este ataque estaba tratando de testar si la aplicación era vulnerable a una inyección de SQL. En este escaneo, se supone que muchas de estas queries fallen, y pocas exitosas indicando el método para explotar una vulnerabilidad. Por ejemplo, los SQLs con PG_SLEEP() nunca pueden ser exitosos en nuestra base de datos MySQL desde que esta función solo existe en base de datos PostgreSQL. Por lo tanto, ejecuciones exitosas significan el intento de inyección fallido de modificar la SQL.

Adicionalmente, estas SQLs no recuperan datos, entonces allí no hubo filtración. Mientras la mayoría de estos SQLs no estaban intentando extraer nada, es confortante saber que nada fue recuperado.

En otras palabras – este ataque no logró romper el límite literal. Volveremos a este asunto después y también responder la pregunta más interesante de porqué recibimos el alerta de anomalía en primer lugar.

Aplicaciones Forences

Ahora que tenemos más información, es fácil buscar los logs de Apache para más detalles en el ataque y a qué dirigió.

El ataque fue entre las 8:20 am y 8:25 am, y accedió a la tabla wp_users. Mirando al log de Apache, podemos ver que este ataque empezó exactamente a las 8:20 am:

[29/Dec/2021:08:20:00] "GET /wp-login.php?log=1&pwd=-9696%20UNION%20ALL%20SELECT%2024%2C24--%20ptzf"

Este ataque fue una pregunta GET al script wp-login.php. Esta es la página de logueo de WordPress. El ataque entregó su intento de inyección a través del campo de contraseña que, en este primer intento, incluyó:

-9696 UNION ALL SELECT 24,24-- ptzf

El último intento de ataque fue usando este requerimiento POST a las 8:21:51 am:

[29/Dec/2021:08:21:51] "POST /wp-login.php?Phws%3D5963%20AND%201%3D1%20UNION%20ALL%20SELECT%201%2CNULL%2C%27%3Cscript%3Ealert%28%22XSS%22%29%3C%2Fscript%3E%27%2Ctable_name%20FROM%20information_schema.tables%20WHERE%202%3E1--%2F%2A%2A%2F%3B%20EXEC%20xp_cmdshell%28%27cat%20..%2F..%2F..%2Fetc%2Fpasswd%27%29%23"

Los logs de Apache no graban los parámetros POST, pero podemos ver esta carga en el requerimiento:

Phws=5963 AND 1=1 UNION ALL SELECT 1,NULL,'<script>alert("XSS")</script>',table_name FROM information_schema.tables WHERE 2>1--/**/; EXEC xp_cmdshell('cat ../../../etc/passwd')#

Esta carga útil es un poco graciosa dado que contiene una inyección de SQL con un escaneo de secuencias de comandos entre sitios (alert(“XSS”)) y un intento de que SQL Server ejecute un comando de shell (EXEC xp_cmdshell) con un comando Unix/Linux imprimiendo el contenido de un archivo de contraseña Unix/Linux (cat …/passwd).

Este es una mezcla de ataques fragmentados que podrían nunca funcionar juntos. Y hay muchas otras cosas mal con el último requerimiento.

Esto indica que la persona corriendo el ataque tiene poco entendimiento de lo que está haciendo. Combinada con el hecho de que todo el escaneo duró menos de 2 minutos, sugiere esto fue un script o, más probable, muchos scripts ellos descargaron fuera de Internet y ejecutaron contra varios sitios.

Falso Positivo

Entonces, ¿por qué falló el ataque?, ¿y por qué recibimos una alerta de anomalía de cualquier forma?

Un ataque de inyección de SQL intenta modificar la estructura SQL al quebrar a través de los límites literales. En otras palabras, cuando un SQL contiene un literal como este:

SELECT * FROM wp_users WHERE user_login = 'JOHN'

Un ataque de inyección de SQL intenta mandar una cadena otra que “JOHN” entonces la estructura SQL cambia. Por ejemplo, la cadena “X' or 'Y'='Y” resultará in este SQL:

SELECT * FROM wp_users WHERE user_login ='X' or 'Y'='Y'

Al cambiar el SQL estructura y agrega “or 'Y'='Y'“, la base de datos correrá algo no intencionado por el desarrollador que escribió este código. Colocando una etiqueta (') en el aporte rompió a través de límites literales y permitió al atacante alterar la estructura SQL. Escapar los literales antes de incrustarlos en un SQL previene esta vulnerabilidad.

En el SQL estandard, puedes escapar etiquetas (') al usar etiquetas dobles (''). Cuando se escapa, el ejemplo de más arriba producirá:

SELECT * FROM wp_users WHERE user_login = 'X'' or ''Y''=''Y'

En este caso, la base de datos comparará el campo user_login a la cadena entera, con la palabra OR es solo parte de un nombre de usuario, no parte de una estructura SQL.

WordPress debe haber escapado de la entrada correctamente en nuestro ataque, y la estructura SQL no fue modificada. Es por esto que los SQLs se ejecutaron sin error, y el ataque falló.

Pero, ¿por qué recibimos un alerta de anomalía si el ataque no quebró los límites literales?

A diferencia de otras bases de datos, en MySQL, hay 2 formas de escapar de las etiquetas en las cadenas. La primera es con etiquetas dobles ('') de acuerdo con el SQL estándard. Pero hay un segundo método de preceder la etiqueta con un backslash (\'). WordPress usa el segundo método.

Acá es donde la vieja versión de Core Audit entra a jugar. Aquella vieja versión fue liberada cortamente luego de la liberación del soporte de MySQL, y la eliminación literal en el repositorio de SQL reducido no admitía el método de escape de barra invertida para bases de datos MySQL.

Una vez que descubrimos el consecuente no intencionado de detectar falsamante estos ataques de inyección de SQL, nosotros mantenemos a propósito la vieja versión de Core Audit en ese sitio web. Queríamos ver cómo muchos más ataques fallido experimentaríamos. Como comentamos antes, este viejo sitio web experimentó nueve intentos a lo largo del siguiente año. Una vez que actualizamos la versión de Core Audit, paramos de recibir estas alertas de falso positivo.

Area de superficie de ataque de la aplicación

Tal vez te preguntes por qué alguien intentó un ataque de inyección de SQL que no funcionó contra WordPress. Los atacantes, como cualquier otro, tenían acceso a WordPress. Entonces, ¿por qué no sabían que este ataque fallaría?

Esta es una pregunta interesante que resalta los complejidad de la cadena de suministro en algunas aplicaciones de terceros, como WordPress.

El primer pensamiento que viene a mi mente es que quizás algunas versiones de WordPress son susceptibles de ataque. Como sea, la inyección de SQL es una amenaza bien conocida, y el equipo de desarrollo de WordPress es estricto sobre escapando entradas antes de literales incrustados en SQLs. Mientras usar variables incrustadas sería más seguro, desarrolladores web tienen una inclinación por literales embebidos.

Como sea, es mundialmente conocido que múltiples versiones y parches significativamente aumentan el área de la superficie de ataque. La razón es que muchas organizaciones actualizan y emparchan aplicaciones de tanto en tanto y nunca pueden estar seguras qué vulnerabilidades eliminaron o introdujeron y en qué punto.

Pero desde que es poco probable que ninguna versión de WordPress fue susceptible a una inyección de SQL en la pantalla de login, que lleva otra interesante característica de WordPress – Plugins.

Una gran parte del poder y flexibilidad de WordPress son más de decenas de miles de plugins que pueden extenderlo. Estos plugins son código que puede adjuntarse a varios lugares en WordPress y modificar su comportamiento en casi cualquier manera inimaginable.

Plugins ofrece poder y flexibilidad a los usuarios, pero también muestran un riesgo de seguridad. WordPress plugins introducen proveedores adicionales, códigos estándar, cambios al modelo de la base de datos, nuevos caminos en la ejecución de la aplicación, y, por lo tanto, nuevas vulnerabilidades.

El riesgo en plugins no es solo vulnerabilidades en software de terceros pero también el riesgo de ataques en la cadena de suministro. Estos ataques pueden ser iniciados por el autor del plugin o por un hacker que alteró el código fuente.

Es poco probable que WordPress fuera susceptible de este ataque, pero es altamente plausible que algunos de los plugins lo sean. El atacante estaba apuntando a un plugin que no fue instalado en nuestro WordPress.

Ideas finales

Las inyecciones de SQL son notoriamente difíciles de detectar y, aún más, de prevenir. Como sea, el análisis de anomalías de Core Audit fue capaz de alertar sobre estos ataques.

No solo fue un análisis de anomalías capaz de detectar un ataque, pero se hizo sin ninguna firma de ataque o soporte para PHP o WordPress. Y, realmente, sin siquiera buscar un ataque de inyección de SQL.

Y esta es la razón por la que el análisis de anomalías es tan efectivo contra la inyección de SQL – no es buscando especialmente por esto. Es buscando por SQLs que son nuevos a la aplicación, por lo tanto, sospechosos. La inyección de SQL puede mascarar en muchas formas pero, por definición, no es parte del vocabulario SQL de la aplicación. Por lo tanto, el análisis de anomalías siempre detectará el ataque.

WordPress Attack Detection

Ataques a tu aplicación

Detección de Ataques en WordPress

Un domingo al mediodía, recibí un alerta sobre una anomalía. Era 19 de marzo de 2023. Esta historia es sobre lo que sucedió.

Antecedentes

El sitio web de Blue Core Research usa WordPress (sistema libre y de código abierto de gestión de contenidos). WordPress usualmente usa MySQL como base de datos de backend, y nuestra instalación no es diferente.

Mientras nuestro WordPress no contiene información sensible, aún lo protegemos con Core Audit. Parcialmente, lo hacemos porque producimos Core Audit, y las licencias no nos cuestan nada. Pero para contextos más grandes, protegemos esta base de datos porque nuestro sitio web es la cara de la compañía, y aún sin información sensible, una filtración dañaría nuestra reputación.

Como verás en este trabajo, protegiendo la base de datos proteges la aplicación (WordPress) también. Y eso defiende nuestro servidor de ataques en Internet.

La Anomalía

Nuestra instalación de Core Audit cuenta con una configuración relativamente simple con alertas diarias de detección de anomalías. Recibimos algunos falsos positivos cada tanto, pero una mañana de domingo del 19 de marzo de 2023, recibimos un alerta de un nuevo error.

Access denied for user ''@'' (using password: YES)

Eso inmendiatamente me levantó una bandera roja. Esto es porque las anomalías solo alertan sobre algo diferente, como un cambio en la actividad del perfil de la aplicación. Pero un cambio que causa un acceso denegado parece sospechoso.

La Investigación

Las anomalías de Core Audit descansan en el repositorio de seguridad de Core Audit. Y esta anomalía particular está basada en la reducción de la porción de SQL de ese repositorio. El repositorio reducido SQL contiene cada construcción SQL que la base de datos ejecuta con la resolución de 5 minutos.

Una vez que recibí el alerta, me logué en Core Audit y revisé la vista relevante forense. Rápidamente encontré sobre qué fui alertado:

Date:     Sat 2023/03/18
Time:     18:55 - 19:00
Count:    1 per 5 minutes
Rows:     0
Command:  ERROR TEXT
Activity: Access denied for user ''@'' (using password: YES)

Esto es un error interno MySQL resultante de un log in fallido. El usuario y anfitrión en este error están entre comillas simples (‘) y son, por lo tanto, despojados desde el repositorio reducido de SQL. La división de literales es parte de cómo opera el repositorio reducido de SQL.

Mi próxima parada fue para buscar la sesión fallida que la causó. Al alternar a la sesión de vista forence, encontré esta sesión:

Start:    2023/03/18 18:55:59
End:      2023/03/18 18:55:59
Type:     No Login
Username: username_here
Machine:  localhost

Esto luce inusual desde que no contamos con un usuario en la base de datos llamado username_here Esto es, obviamente, un usuario inválido. Mi próxima parada fue mirar los logs del web server para ver quién o qué disparó este login inusual.

Aquí hay un extractro del log de Apache:

[18:55:36] GET /.wp-config.php_copy
[18:55:38] GET /.wp-config.php.rar
[18:55:39] GET /.wp-config.php.7z
[18:55:41] GET /.wp-config.php.tmp
[18:55:42] GET /.wp-config.php_tmp
[18:55:44] GET /.wp-config.php.old
[18:55:46] GET /.wp-config.php.0
[18:55:47] GET /.wp-config.php.1
[18:55:49] GET /.wp-config.php.2
[18:55:50] GET /.wp-config.php.zip
[18:55:52] GET /.wp-config.php.gz
[18:55:53] GET /.wp-config.php~
[18:55:55] GET /wp-config.php.templ
[18:55:56] GET /wp-config.php1
[18:55:58] GET /wp-config.php2
[18:55:59] GET /wp-config-sample.php
[18:56:00] GET /wp-config-backup.txt
[18:56:02] GET /wp-config.php.orig
[18:56:03] GET /wp-config.php.original
[18:56:05] GET /wp-license.php?file=..%2F..
[18:56:06] GET /wp-config.save
[18:56:07] GET /wp-config.txt
[18:56:09] GET /wp-config.dist
[18:56:10] GET /.wp-config.php.swo
[18:56:12] GET /wp-config%20copy.php
[18:56:12] GET /wp-config_good
[18:56:14] GET /wp-config-backup
[18:56:15] GET /wp-config-backup.php
[18:56:16] GET /wp-config-backup1.txt
[18:56:18] GET /wp-config-good
[18:56:19] GET /wp-config-sample.php.bak
[18:56:21] GET /wp-config-sample.php~
[18:56:22] GET /wp-config.backup

El culpable es claramente wp-config-sample.php, y mirando dentro de él, podemos encontrar estas líneas:

define( 'DB_USER', 'username_here' );
define( 'DB_PASSWORD', 'password_here' );
…
require_once ABSPATH . 'wp-settings.php';

Ahora entendemos qué pasó: alguien escaneó el sitio web buscando vulnerabilidades y llamó wp-config-sample.php. Ese script PHP contiene un usuario y contraseña inválido que disparó una falsa conexión a la base de datos. Core Audit detectó este inusual comportamiento y elevó una alerta.

Resolución

En WordPress, wp-config-sample.php es parte del paquete de instalación de WordPress. El proceso de instalación de WordPress copia este archivo en wp-config.php y define algunos parámetros como el usuario y contraseña de la base de datos.

Por lo tanto, wp-config-sample.php es esperado que exista en una instalación de WordPress. Y si el equipo de desarrollo de WordPress ha hecho bien su trabajo, es probable que no signifique una filtración de WordPress al llamarlo así.

Pero como todos sabemos, los errores existen, y ataques 0-dia pueden siempre ocurrir. Teniendo este archivo alrededor parece preguntar por problemas. Este archivo no tiene otro propósito en WordPress que no sea como plantilla para wp-config.php, entonces ¿no deberías eliminarlo?

Esto nos lleva a otro comportamiento de WordPress: su actualización. Cuando WordPress actualiza, sobre escribe todos los archivos que son parte del paquete de WordPress. Por lo tanto, borrando wp-config-sample.php será desecho tan pronto como WordPress automáticamente actualice.

Otra opción es dejar el archivo en el lugar pero cambiar los permisos del archivo así Apache no puede acceder ahí. Esto prevendría este script PHP de ejecutarse. Como sea, esto tal vez cause errores cuando WordPress intenta actualizar porque no será capaz de sobre escribir el archivo. Entonces la actualización requiere intervención manual.

Por ejemplo, puedes eliminar permisos ejecutando:

chown root:root wp-config-sample.php
chmod 000 wp-config-sample.php

Más allá

Como expliqué previamente, wp-config-sample.php es usado para crear wp-config.php durante la instalación. Esto significa que wp-config.php puede ser también vulnerable al mismo ataque u otro similar ataque 0-dia.

Más problemático es si una actualización de WordPress arregla una vulnerabilidad en wp-config-sample.php, este arreglo no actualizará wp-config.php desde que ese copy nunca es modificado.

wp-config.php está pensado para ser incluido por otros archivos de WordPress como index.php. Luego de definir los parámetros de la conexión de la base de datos, el script llama wp-settings.php para configurar el ambiente WordPress, incluyendo la conexión a la base de datos.

En otras palabras, wp-config.php nunca quiere ser ejecutado directamente. Para protegerlo contra un ataque ejecutado directamente, podemos agregar una línea en la parte de superior de wp-config.php para detener el proceso.

if (get_included_files()[0] == '/path_to_site/wp-config.php') exit();

¿WordPress?

Mientras muchos no van a considerar WordPress un buen ejemplo de seguridad de aplicación, pensamos que aporta valor por estas razones:

3ra Parte & Cadena de suministro

Primero y más importante, esto es una aplicación 100% de terceros. Nosotros no la codeamos, no revisamos el código fuente, y no tenemos casi conocimiento del código, el modelo de datos, y ningún otro aspecto de la aplicación.

WordPress es un software de código abierto expuesto tanto para vulnerabilidades descubiertas por hackers como ataques a la cadena de suministro.

Para hacerlo peor, los sitios de WordPress casi siempre usan plug-ins. Mucho del poder de una plataforma de WordPress está en su extensibilidad por las decenas de miles de plugins que existen. Los plugins significativamente expanden la superficie del área de la tercera parte del software y ataques a la cadena de suministro. Plug-ins significan un montón de código adicional desconocido de vendors o desarrolladores múltiples, diferentes estándares de código, mejoras al modelo de datos con más tablas, y más.

SQL dinámico

WordPress lleva el concepto de SQL dinámico a un extremo. No solo todos los SQLs embebidos literales, sino que los SQLs a menudo se generan dinámicamente con cláusulas creadas sobre la marcha en función de la entrada del usuario.

El desafío no es solo los dinámicos ataques SQL pero también el gran vocabulario SQL donde es imposible predecir todas las combinaciones SQL que WordPress puede generar.

De nuevo, plug-ins empeoran el problema debido a un todavía más grande y desconocido vocabulario SQL, y más potenciales vulnerabilidades en el código que genera SQLs dinámicos.

Popular & De cara a Internet

WordPress es muy popular y es una aplicación orientada a Internet. Hackers son, por lo tanto, altamente incentivados para encontrar vulnerabilidades. Explotar estas vulnerabilidades puede ser también fácil desde que Internet está lleno de sitios en WordPress con poca o no adicional seguridad.

Ideas finales

A pesar de estos desafíos, los análisis de anomalía de Core Audit proveen seguridad efectiva así como tiene un razonable nivel de falsos positivos y, en este caso, ha sido alertado de un ataque contra la aplicación.

Es importante notar que Core Audit no tiene un soporte especial para PHP o WordPress. Tampoco miramos ninguna vulnerabilidad en particular en la base de datos o la aplicación. Solo teníamos un objetivo general de detección de anomalía que nos alertó tan pronto como la aplicación se comportó diferente. Esto fue suficiente para identificar un ataque.

Como has visto, monitorear cambios en el perfil de la actividad de la base de datos de la aplicación nos permite detectar muchos cambios en el comportamiento de la aplicación. Mientras algunos cambios ocurren naturalmente, otros indican un problema de seguridad o un ataque.

April Webinar – Data Masking

Seminario Web

CASO DE ÉXITO

Jueves 20 de Abril

10 am CO|EC|PE – 9 am MX – 12 pm CL|ARG

VEN A CONOCER CÓMO NUESTRO CLIENTE,
Una Gran Multinacional Europea
implementó Core Masking en diferentes mercados en Europa.

Únete a nosotros para una conversación sobre un interesante caso de éxito real de implementación de nuestra solución de enmascaramiento de datos como gran proyecto, logros alcanzados y los detalles de los desafíos de implementar en los diferentes mercados de Europa.

¿Cuál es tu nombre?
¿Cuál es tu apellido?
¿Cuál es tu correo electrónico corporativo?
Si quieres, compártenos tu número de celular
¿En qué compañía trabajas?
¿Cuál es tu cargo en esa compañía?
¿En qué país vives?
¿Cómo te enteraste del evento?

Te contactaremos con la información de acceso momentos antes del Webinario.

Speakers

Carlos Ardila

TS4B

Co-fundador de TS4B con un MBA y experiencia en todos los aspectos de la gestión de la seguridad de aplicaciones y proyectos. Actualmente se desempeña como jefe de servicios de implementación para TS4B.

Trabajó durante los últimos 12 años en toda América Latina y España en una variedad de proyectos de seguridad, tales como proyectos de seguridad de aplicaciones, auditoría, alta disponibilidad, migración y administración.

Paulo Camiletti

Blue Core Research

Líder empresarial con 20 años de experiencia en la industria de Tecnología y Telecomunicaciones.

Amplia experiencia trabajando con clientes y empresas en toda América Latina y América del Norte.

Actualmente se enfoca en proyectos de cumplimiento y seguridad de TI, brindando valor a los clientes en múltiples industrias.

January Webminar – Java Auditing

Seminario Web

Seguridad en aplicaciones de Java

Jueves 26 de Enero

10 am CO|EC|PE – 9 am MX – 12 pm CL|ARG

Ven a conocer sobre los desafíos de la seguridad de las aplicaciones de Java, los beneficios de la auditoría y cómo conseguir visibilidad de la actividad. Descubre nuevas tecnologías de seguridad que no requiere cambios en el código.

Únete a nosotros para una discusión sobre la seguridad de las aplicaciones de Java con nuestros partners expertos Martín Mihura de DBlandIT, Carlos Ardila y Christian Carlos de TS4B. Todos con más de 40 años de experiencia combinada, y Paulo Camiletti, nuestro Director general LATAM.

¿Cuál es tu nombre?
¿Cuál es tu apellido?
¿Cuál es tu correo electrónico corporativo?
Si quieres, compártenos tu número de celular
¿En qué compañía trabajas?
¿Cuál es tu cargo en esa compañía?
¿En qué país vives?
¿Cómo te enteraste del evento?

Te contactaremos con la información de acceso momentos antes del Webinario.

Speakers

Martin Mihura

DBlandIT

Ingeniero en sistemas de la información de la Universidad Tecnológica Nacional (UTN), especializado en aplicaciones y arquitecturas de datos. CTO en DBlandIT, consultora de Big Data y Analytics, utilizando tecnología tanto On-Prem como Cloud, con clientes tales como Movistar, Personal, Brubank, Junta de Andalucia, Edenor, Disney, entre otros. Consultor externo en INDEC.
Docente en la UTN de la materia Implementación de bases de Datos NOSQL y en la Diplomatura en Arquitecturas de Big Data Aplicadas. Docente del ITBA en la Diplomatura en Ingenieria y Cienca de Datos.

Carlos Ardila

TS4B

Co-fundador de TS4B con un MBA y experiencia en todos los aspectos de la gestión de la seguridad de aplicaciones y proyectos. Actualmente se desempeña como jefe de servicios de implementación para TS4B.

Trabajó durante los últimos 12 años en toda América Latina y España en una variedad de proyectos de seguridad, tales como proyectos de seguridad de aplicaciones, auditoría, alta disponibilidad, migración y administración.

Christian Carlos

TS4B

Consultor de TI con más de 15 años de experiencia trabajando con clientes en una variedad de industrias.

Trabajó extensamente con clientes en la industria financiera en Perú en la entrega de proyectos de auditoría y cumplimiento.

Actualmente está a cargo de proyectos de seguridad de bases de datos en América del Sur y Central.

También participa en proyectos relacionados con la protección de datos, la copia de seguridad como servicio (Baas), APM y más.

Paulo Camiletti

Blue Core Research

Líder empresarial con 20 años de experiencia en la industria de Tecnología y Telecomunicaciones.

Amplia experiencia trabajando con clientes y empresas en toda América Latina y América del Norte.

Actualmente se enfoca en proyectos de cumplimiento y seguridad de TI, brindando valor a los clientes en múltiples industrias.

Database security – self assessment

Autoevaluación de la seguridad de tu base de datos

¡Hola! Te invitamos a participar de un juego para obtener información de calidad sobre el estado actual de la seguridad de tu base de datos. Responder estas preguntas no demorará más de 3 minutos y una vez completada, recibirás información de calidad sobre seguridad.

¿Sabes dónde está tu información sensible? ¿Cuáles bases de datos y qué tablas y columnas las contienen?
El requerimiento más elemental para proteger datos sensibles es saber dónde están. Es esencial contar con la lista de bases de datos que los contienen y las tablas y columnas que requieren protección.
¿Has asegurado que tus usuarios sólo cuenten con los mínimos privilegios que necesitan (menos privilegiado)?
Una importante buena práctica es asegurar los mínimos privilegios – que los usuarios solo tengan los permisos necesarios para desarrollar su trabajo. Esto es especialmente importante para la administración de privilegios que son, desafortunadamente, a menudo ofrecidos por error o sin una buena justificación.
¿Estás al tanto de los cambios en tu base de datos?
El control de cambios es una forma simple de demostrar el control básico sobre los ambientes. Dado que los administradores a veces olvidan documentar estos cambios, es altamente recomendado cerrar el círculo monitoreando los cambios y aprobándolos.
¿Revisas quién se conectó a tu base de datos?
El conocer qué usuarios, programas, y máquinas están conectadas a la base de datos es la más mínima visibilidad para entender qué está sucediendo. Esta información debería ser revisada diaria o semanalmente.
¿Revisas los accesos a las tablas sensibles?
Especial atención debe darse a tablas sensibles. Es importante saber quién está desempeñando cada acceso, a cuánta data es accedida, cuándo ese acceso es “inusual”, y más. Establecer reportes efectivos es esencial entonces los reportes son cortos, significativos y fáciles de revisar.
¿Monitoreas la actividad de DBAs?
Debido a sus elevados privilegios, la actividad de DBAs es considerada de alto riesgo. Esto es tanto desde una amenaza interna de abuso de privilegios, y en caso de que sus credenciales fueran robadas o sus máquinas hackeadas.
¿Cuánto tiempo, en promedio, pasas en la seguridad de tu base de datos?
El monitoreo efectivo puede usualmente ser hecho en menos de 2 horas por semana. Pasar más tiempo sugiere que sus controles no son efectivos y que estás ahogándote en información inútil. No pasar nada de tiempo, sugiere que tus controles están calibrados tan bajos que es poco probable que sepas si ocurrió un problema real.
¿Monitoreas la actividad inusual de la base de datos como usuarios conectándose desde diferentes programas o desde diferentes computadoras?
Las bases de datos tienen un montón de conexiones y es fácil perder cambios pequeños como diferentes direcciones IP para un usuario particular, o un programa que un usuario normalmente no usa. La automatización puede ayudar a asegurar que estés al tanto de cualquier cambio en las conexiones de perfiles.
¿Monitoreas actividades de aplicaciones anómalas como inyección SQL?
Las aplicaciones ejecutan una masiva cantidad de SQLs que son imposibles de revisar manualmente. Este es un lugar donde la automatización es la única solución. Análisis de anomalías, por ejemplo, puede analizar la actividad de los perfiles y señalar cambios en el comportamiento de la aplicación. La inyección de SQL es un ejemplo de un ataque apalancando un error de aplicación.
¿Cómo auditas la actividad de tu base de datos?
La auditoría de la actividad de la base de datos requiere la correcta tecnología. A una escala menor, guiones hechos en casa pueden ser efectivos. Como sea, cuando se audita más actividad de largas bases de datos, el desarrollo se vuelve muy alto y la inversión de tiempo requerido – desafiante. Usar la solución adecuada puede ayudar a monitorear toda la actividad, con poco trastorno, y alcanzar reportes efectivos.
¿Tienes separación de deberes que previenen, por ejemplo, DBAs de acceder a datos sensibles?
Las bases de datos son diseñadas para tener cuentas administrador con privilegios ilimitados. Estas cuentas son un vector de ataque de alto riesgo tanto por amenazas internas – abusos de privilegios- como por las externas – robo de credenciales por hackeo en máquinas de DBA. Reducir el acceso a estas cuentas y establecer la separación de deberes puede significativamente reducir el riesgo de cuentas de DBA.

¡Has terminado el juego!

La madurez de la seguridad de tu base de datos es de 10

10 Out of 10

Por favor completa esta información para recibir por mail un reporte con el resultado y más detalles:

Nombre
Apellido
Compañía
Rol
Email
Teléfono

October Webminar – Database Risks & Solutions

Seminario Web GRATUITO

Identificación y mitigación de riesgos en base de datos

Jueves 13 de Octubre

10 am CO|EC|MX|PE – 12 pm CL|ARG

Ven a conocer los riesgos reales de las bases de datos, los desafíos de la identificación y clasificación de riesgos y las mejores estrategias y enfoques para mitigarlos.

Únase a nosotros para una discusión sobre la seguridad de la base de datos con los expertos en bases de datos Carlos Ardila y Christian Carlos, con más de 25 años de experiencia combinada, y el experto en negocios, Paulo Camiletti, de Blue Core Research.

¿Cuál es tu nombre?
¿Cuál es tu apellido?
¿Cuál es tu correo electrónico corporativo?
Si quieres, compártenos tu número de celular
¿En qué compañía trabajas?
¿Cuál es tu cargo en esa compañía?
¿En qué país vives?
¿Cómo te enteraste del evento?

Te contactaremos con la información de acceso momentos antes del Webinario.

Speakers

image/svg+xmlOpenclipart

Carlos Ardila

TS4B

Co-fundador de TS4B con un MBA y experiencia en todos los aspectos de la gestión de bases de datos y proyectos. Actualmente se desempeña como jefe de servicios de implementación para TS4B.

Trabajé durante los últimos 12 años en toda América Latina y España en una variedad de proyectos de bases de datos, tales como proyectos de seguridad de bases de datos, auditoría, enmascaramiento de datos, PAM (Gestión de acceso privilegiado), alta disponibilidad, migración y administración.

Christian Carlos

TS4B

Consultor de TI con más de 15 años de experiencia trabajando con clientes en una variedad de industrias.

Trabajó extensamente con clientes en la industria financiera en Perú en la entrega de proyectos de auditoría y cumplimiento.

Actualmente está a cargo de proyectos de seguridad de bases de datos en América del Sur y Central.

También participa en proyectos relacionados con la protección de datos, la copia de seguridad como servicio (Baas), APM y más.

Paulo Camiletti

Blue Core Research

Líder empresarial con 20 años de experiencia en la industria de Tecnología y Telecomunicaciones.

Amplia experiencia trabajando con clientes y empresas en toda América Latina y América del Norte.

Actualmente se enfoca en proyectos de cumplimiento y seguridad de TI, brindando valor a los clientes en múltiples industrias.

Enmascaramiento estático de datos – corta

Enmascaramiento estático de datos
¿Por Qué?

Introducción

Cuando hablamos de bases de datos no productivas nos referimos a aquellas bases de datos utilizadas para educación, pruebas, desarrollo, entre otras. ¿Por qué es importante enfocarnos en estas bases de datos? ¿Cuál es el riesgo?  Muy simple: por lo general los equipos de desarrollo utilizan datos reales sacados de los sistemas de producción para mejorar la calidad del software que desarrollan y así acortar los ciclos de desarrollo.

El uso de datos reales en las primeras fases de los ciclos de desarrollo ayuda a mejorar la calidad del software. Al realizar más pruebas con los datos reales, se pueden detectar fallas antes, para así reparar más rápido dichas fallas, reducir el costo de desarrollo y reducir el tiempo total de despliegue, lo cual permite una mejor respuesta a usuarios y clientes, y por consiguiente al negocio. Vivimos en un mundo en el que el despliegue de nuevos modelos o funcionalidades pueden representar el alcanzar o no los objetivos requeridos por el negocio.

¿Qué vectores de seguridad representan una amenaza real?

El almacenamiento y utilización de datos sensibles fuera de los entornos productivos expone dichos datos a usuarios que no deberían tener acceso a ellos. Esto agranda la brecha de seguridad en tres áreas principalmente:

  • Ejecución de consultas y extracción de información sensible almacenada en su interior.
  • Utilización de la aplicación para acceso a cualquier dato sensible gestionado sin ninguna trazabilidad.
  • La seguridad de estos ambientes carecen de los controles de seguridad. Esto permite el acceso a personal a los datos sensibles por personal no autorizado.

El panorama de amenazas al que los sistemas no productivos están expuestos es enorme, desde abuso interno de privilegios hasta hackeos externos. En general, los sistemas que no son de producción tienen niveles de seguridad más bajos o están mal protegidos.

Las amenazas a ambientes no productivo incluyen:

  • Un gran número de individuos sin autorización con acceso ilimitado a datos sensibles.
  • Autorizaciones mal gestionadas y contraseñas inseguras o triviales, que proveen acceso a muchos individuos desconocidos.
  • Controles de accesos mal gestionados que proveen acceso elevado o de administrador a muchos individuos.
  • Software mal gestionado con parches faltantes, configuraciones inseguras, vulnerabilidades conocidas, y más, permitiendo a intrusos un fácil acceso.
  • Seguridad física mal gestionada que permite acceso a servidores y los datos allí almacenados. En ocasiones, el hardware portátil, como el almacenamiento externo que se utiliza en estos entornos.
  • No hay medidas de seguridad significativas como firewalls. La segmentación de red es casi inexistente, no se manejan trazas de auditoría sobre la actividad realizada, etc.

¿Cómo solucionamos este gran reto?

La solución más sencilla es de-sensibilizar los entornos no productivos eliminando los datos sensibles. Cualquier otro intento para asegurar adecuadamente todos estos entornos será costoso y requerirá mucho tiempo y recursos. Esta de-sensibilización se conoce como enmascaramiento estático de datos.

Una vez realizada esta actividad es imposible revertir el cambio. El enmascaramiento cambia los datos en los múltiples entornos no productivos por datos parecidos que no puedan ser asociados a los datos reales.

En pocas palabras, el objetivo es sustituir los datos sensibles por datos falsos e inofensivos. La idea es que los ambientes no productivos no manejen datos sensibles para evitar abrir brechas de seguridad.

Sin embargo, tenemos un gran reto. ¿Cómo hacemos para que los datos enmascarados utilizados se consideren buenos? Dichos datos deben satisfacer tres principios fundamentales:

  • El proceso debe eliminar toda información sensible, debe eliminar cualquier posibilidad de reconstrucción de los datos originales a partir de los datos enmascarados.
  • Los datos enmascarados deben ser válidos y coherentes. Los campos que tienen reglas especiales o sumas de comprobación deben mantenerse. Las claves primarias enmascaradas deben ser únicas. Las claves externas enmascaradas (o referencias equivalentes) deben coincidir. La ciudad, el estado y el código postal deben ser consistentes,
  • Los datos enmascarados deben conservar o mejorar la calidad de las pruebas. Esto significa que los datos enmascarados deben “parecer” reales. Por ejemplo, debe conservar la frecuencia de los datos como la proporción entre hombres y mujeres. Debe seguir utilizando los mismos patrones, si existiesen valores válidos y no válidos deberían seguir existiendo.

Estrategias de enmascaramiento

Hay cuatro estrategias principales para el enmascaramiento de datos estático:

  • Manipulación de valores: modifica cada campo independientemente. Los datos enmascarados son una función aplicada a los datos originales. Dependiendo de la función de enmascaramiento, los datos enmascarados pueden conservar algunos aspectos de los datos originales.
  • Generación de datos: crea nuevos datos no relacionados con la información sensible original. Aunque la información enmascarada no revelará nada sobre los datos originales, también será completamente ajena. Por lo tanto, las columnas enmascaradas con la generación de datos no deberán ser importantes para la prueba.
  • Perfilado automático – tiene tres pasos: analizar los datos originales, crear un perfil de datos y generar datos basados en ese perfil. Esta estrategia es un tipo de generación de datos basado en los datos originales, proporciona datos realistas de alta calidad que no exponen los datos e incluso rompe la asociación de filas.
  • Perfiles personalizados: se trata de una forma avanzada de elaboración automática de perfilado. Se permite crear datos que se ajustan a escenarios particulares, se asemejan a perfiles de datos anteriores, o que sean similares a otros conjuntos de datos. También es un medio eficaz para crear conjuntos de datos de cualquier tamaño, tanto más grandes como más pequeños.

Dado que cada enfoque tiene diferentes ventajas e inconvenientes, una buena solución de enmascaramiento de datos ofrecerá todas estas estrategias permitiendo utilizar el método más adecuado para cada situación.

Reflexiones finales

El enmascaramiento de datos es un concepto sencillo, pero la implementación no lo es. Cualquier persona puede lograr ofuscar datos pero hacer que mantengan la consistencia requerida es otra cosa. Cada vez más nos encontramos con que un número creciente de clientes que se enfrenta a retos no triviales a la hora de enmascarar datos. Cada vez es más importante poder enmascarar los datos manteniendo las características necesarias para replicar la operación de las aplicaciones. Mientras más rápido puedan liberar aplicaciones confiables, mayor será el retorno para la empresa y mayor su reconocimiento.

Hable con nosotros para que le ayudemos a entender mejor los retos existentes que visualiza y recibir guía sobre cómo utilizar mejor las herramientas adecuadas para mantener sus datos sensibles fuera de las manos incorrectas.

Core Masking es la solución de enmascaramiento de datos más potente en el mercado, y este documento pretende darle una pequeña muestra de eso. Si quieres recibir más información, escríbenos a marketing@bluecoreresearch.com

Survey for UAN security class

Encuesta de evaluación de la clase sobre seguridad informática

Esta es una pequeña encuesta sobre la actividad de seguridad en ambientes productivos y no productivos de Blue Core Research en la Universidad Antonio Nariño. Te tomará 20 segundos responder esta encuesta.

Nombre y apellido

Teléfono

Email

Linkedin

Sobre el contenido de la clase, ¿cómo calificarías tu experiencia?

Sobre el speaker de la clase, ¿cómo calificarías tu experiencia?

Sobre la herramienta Core Audit, por favor compártenos un comentario general

Muchas gracias por completar esta encuesta. ¡Hasta pronto!