Ingeniería en Barracuda

La historia detrás de Active Threat Intelligence de Barracuda

Hace un tiempo, en una de nuestras sesiones de lluvia de ideas, mientras los equipos discutían el siguiente nivel de evolución de nuestros productos, se puso en evidencia que la detección y protección contra amenazas nuevas y emergentes requería un análisis intensivo de datos a gran escala. Ese análisis tendría que predecir el riesgo de los clientes y hacerlo de forma eficiente y rápida si queríamos evitar que se produzcan acciones hostiles.

A medida que analizábamos los requisitos, nos dimos cuenta de que, para poder proteger contra atacantes avanzados como los bots, necesitábamos construir una plataforma que pudiera analizar el tráfico de las sesiones web, correlacionarlo con los datos de las sesiones y, para muchas cosas, a través de toda la base de clientes. También nos dimos cuenta de que muchas partes del sistema debían funcionar en tiempo real, algunas casi en tiempo real, y otras podían tener una fase de análisis mucho más prolongada.

Hace unos años presentamos Barracuda Advanced Threat Protection (BATP) para la protección contra ataques de malware de día cero en toda la línea de productos de Barracuda. Esta capacidad (analizar archivos para detectar el malware mediante varios motores además del sandboxing) se introdujo en los productos de seguridad de aplicaciones de Barracuda para proteger aplicaciones como los sistemas de procesamiento de pedidos donde terceros subían archivos. Este fue el primer intento de utilizar una capa basada en la nube para realizar análisis avanzados que habría sido difícil de integrar en los dispositivos de web application firewall.

Pero aunque la capa de nube de BATP podía gestionar millones de escaneos de archivos, necesitábamos un sistema que pudiera almacenar grandes cantidades de metainformación para que pudiera ser analizada y así identificar amenazas nuevas y en evolución. Esto nos inició el camino hacia la próxima plataforma de inteligencia contra las amenazas.

Cómo funciona Active Threat Intelligence

La plataforma Barracuda Active Threat Intelligence es nuestra respuesta. La plataforma se basa en un lago de datos masivo, que puede manejar el procesamiento de flujos, así como el procesamiento por lotes de datos. Procesa millones de eventos por minuto en diversas geografías y proporciona inteligencia utilizada para detectar bots y ataques del lado del cliente, además de ofrecer información para proteger contra esos vectores de amenazas. Asimismo, Barracuda Active Threat Intelligence está diseñado con una arquitectura abierta para poder evolucionar rápido y abordar amenazas más recientes.

Hoy, la plataforma Barracuda Active Threat Intelligence recibe datos de los motores de seguridad en el Barracuda Web Application Firewall y WAF-as-a-Service, así como de otras fuentes. A medida que se reciben los eventos, se enriquecen utilizando fuentes de amenazas de origen colectivo y otras bases de datos de inteligencia. El análisis detallado de estos eventos, tanto de forma individual como formando parte de una sesión de usuario, se utiliza para categorizar a los clientes como humanos o bots.

Los canales de análisis de datos utilizan varios motores y modelos de aprendizaje automático para analizar diversos aspectos del tráfico y llegar a sus recomendaciones, que al final se unen para producir el veredicto final.

Formas en que Active Threat Intelligence le ayuda a proteger sus aplicaciones

Además de admitir todos los análisis necesarios para la Protección Avanzada contra bots, la plataforma Active Threat Intelligence también se usa para nuestras últimas ofertas: la Protección del Lado del Cliente y el Motor de Configuración Automatizado.

Active Threat Intelligence rastrea cualquier recurso externo que pueda utilizar la aplicación, como un JavaScript externo o una hoja de estilo. Al mantener un seguimiento de los recursos externos, nos aseguramos de ser conscientes de la superficie de amenaza y podemos protegernos contra ataques como MageCart y otros.

Dado que los metadatos recopilados son extremadamente ricos, podemos extraer información adicional para ayudar a los administradores proporcionándoles recomendaciones de configuración basadas en el tráfico real que llega a sus aplicaciones.

Esta plataforma ha sido fundamental para ayudarnos a crear la próxima generación de capacidades de protección que requieren nuestros clientes. Continuamos aprovechando esta plataforma escalable para obtener información detallada sobre los patrones de tráfico, el consumo de aplicaciones y mucho más. Manténganse al tanto de los blogs de nuestros equipos de ingeniería, que les explicarán cómo desarrollamos Barracuda Advanced Threat Intelligence.

Anshuman Singh

Anshuman Singh es Director Senior de Product Management en Barracuda. Conecte con él en LinkedIn aquí.

www.barracuda.com

Registro de eventos altamente escalable en AWS

La mayoría de las aplicaciones generan eventos de configuración y de acceso. Es importante que los administradores tengan visibilidad de estos eventos. El servicio Barracuda Email Security proporciona transparencia y visibilidad de muchos de estos eventos para ayudar a los administradores a ajustar y comprender el sistema. Por ejemplo, saber quién ha iniciado sesión en la cuenta y cuándo. O saber quién ha añadido, cambiado o eliminado la configuración de una política específica.

Para construir este sistema distribuido y de búsqueda, se nos ocurren muchas preguntas, tales como:

• ¿Cómo debería usted escribir estos registros de todas las aplicaciones, servicios y máquinas en una ubicación central?
• ¿Cuál debería ser el formato estándar de los archivos de registro?
• ¿Durante cuánto tiempo debería conservar estos logs?
• ¿Cómo debería usted correlacionar eventos de diferentes aplicaciones?
• ¿Cómo le proporciona un mecanismo de búsqueda simple y rápido a través de una interfaz de usuario al administrador?
• ¿Cómo se hace que estos logs estén disponibles a través de una API?

Cuando piensa en un motor de búsqueda distribuido, lo primero que le viene a la mente es Elasticsearch. Es altamente escalable, con búsquedas casi en tiempo real y está disponible como un servicio totalmente gestionado en AWS. Así, el proceso comenzó con la idea de almacenar estos logs de eventos en Elasticsearch y que las diferentes aplicaciones le enviaran logs a Elasticsearch mediante Kinesis Data Firehose.

Componentes involucrados en esta arquitectura

1. Kinesis Agent: Amazon Kinesis Agent es una aplicación de software Java independiente que ofrece una manera sencilla de recopilar y enviar datos a Kinesis Data Firehose. El agente supervisa continuamente los archivos de logs de eventos en las instancias de EC2 Linux y los envía al stream de entrega configurado de Kinesis Data Firehose. El agente gestiona la rotación de archivos, el punto de control y los reintentos en caso de fallos. Proporciona todos sus datos de manera fiable, puntual y sencilla. Nota: Si la aplicación que necesita escribir en Kinesis Firehose es un contenedor de Fargate, necesitará un contenedor de Fluentd. Sin embargo, este artículo se centra en las aplicaciones que se ejecutan en instancias EC2 de Amazon.
2. Kinesis Data Firehose: el método de inserción directa de Amazon Kinesis Data Firehose puede escribir los datos en formato JSON en Elasticsearch. De esta manera, no se almacena ningún dato en el stream.
3. S3: Se puede utilizar un bucket de S3 para hacer copias de seguridad de todos los registros o de los registros que fallen y no se entreguen a Elasticsearch. Las políticas de ciclo de vida también se pueden configurar para archivar automáticamente los logs.
4. Elasticsearch: Elasticsearch alojado por Amazon. Se puede habilitar el acceso a Kibana para ayudarle a consultar y buscar los logs con cualquier finalidad de depuración.
5. Curator: AWS recomienda usar Lambda y Curator para gestionar los índices y las instantáneas del clúster de Elasticsearch. AWS ofrece más detalles y ejemplos de implementación que se pueden encontrar aquí.
6. Interfaz API REST: Puede crear una API como una abstracción para Elasticsearch que se integre bien con la interfaz de usuario. Se ha demostrado que las arquitecturas de microservicios impulsadas por API son las mejores en muchos aspectos, como la seguridad, el cumplimiento normativo y la integración con otros servicios.

Escalado

• Kinesis Data Firehose: Por defecto, los streams de entrega de Kinesis Firehose pueden escalar hasta 1000 registros/seg o 1 MiB/seg para el este de EE. UU. (Ohio). Este es un límite flexible y se puede aumentar hasta 10 000 registros/seg. Esto es específico para cada región.
• Elasticsearch: el clúster de Elasticsearch puede escalarse tanto en términos de almacenamiento como de potencia de cómputo en AWS. También es posible actualizar la versión. Amazon ES utiliza un proceso de implementación azul/verde al actualizar los dominios. Esto significa que el número de nodos en el clúster podría aumentar temporalmente mientras se aplican sus cambios.

Ventajas de esta arquitectura

1. La arquitectura del canal está completamente gestionada de manera efectiva y requiere muy poco mantenimiento.
2. Si el clúster de Elasticsearch falla, Kinesis Firehose puede retener los registros hasta 24 horas. Además, también se realiza una copia de seguridad en S3 de los registros que fallen y no se entreguen.

Las probabilidades de pérdida de datos son bajas con estas opciones disponibles.

3. El control de acceso detallado es posible tanto para la API de Kibana como para la de Elasticsearch a través de políticas de IAM.

Deficiencias

1. Los precios deben considerarse y monitorizarse con atención. El Kinesis Data Firehose puede manejar grandes volúmenes de ingesta de datos con facilidad, y si un agente malintencionado comienza a registrar grandes cantidades de datos, el Kinesis Data Firehose los entregará sin inconvenientes. Esto puede ocasionar grandes costes.
2. La integración de Kinesis Data Firehose con Elasticsearch solo se admite para clústeres de Elasticsearch que no sean VPC.
3. Actualmente, Kinesis Data Firehose no puede entregar registros a clústeres de Elasticsearch que no estén alojados por AWS. Si desea autohospedar clústeres de Elasticsearch, esta configuración no funcionará.

Conclusión

Si busca una solución completamente gestionada que se escale (en su mayoría) sin intervención, esta sería una buena opción a considerar. La copia de seguridad automática en S3 con políticas de ciclo de vida también soluciona con facilidad el problema de retención y archivo de logs.

Sravanthi Gottipati

Sravanthi Gottipati es Gerente de Ingeniería de Email Security en Barracuda Networks. Puede conectar con ella en LinkedIn aquí.

www.barracuda.com

DJANGO-EB-SQS: Una manera más sencilla de que las aplicaciones de Django se comuniquen con AWS SQS.

Los servicios de AWS, como Amazon ECS, Amazon S3, Amazon Kinesis, Amazon SQS y Amazon RDS, se utilizan extensamente en todo el mundo. Aquí en Barracuda, utilizamos AWS Simple Queue Service (SQS) para gestionar la mensajería dentro y entre los microservicios que hemos desarrollado en el framework de Django.

AWS SQS es un servicio de cola de mensajes que puede «enviar, almacenar y recibir mensajes entre componentes de software a cualquier volumen, sin perder mensajes ni requerir que otros servicios estén disponibles». SQS está diseñado para ayudar a las organizaciones a desacoplar aplicaciones y escalar servicios, y fue la herramienta perfecta para nuestro trabajo en microservicios.  Sin embargo, cada nuevo microservicio basado en Django o el desacoplamiento de un servicio existente mediante AWS SQS requería que duplicáramos nuestro código y lógica para comunicarnos con AWS SQS. Esto dio lugar a una gran cantidad de código repetido y animó a nuestro equipo a crear esta biblioteca de GitHub: DJANGO-EB-SQS

Django-EB-SQS es una biblioteca de Python diseñada para ayudar a los desarrolladores a integrar rápido AWS SQS con aplicaciones existentes y/o nuevas basadas en Django. La biblioteca se encarga de las siguientes tareas:

• Serialización de los datos
• Incorporación de lógica de retrasos
• Sondeo continuo desde la cola
• Deserialización de los datos según los estándares de AWS SQS y/o uso de bibliotecas de terceros para comunicarse con AWS SQS.

En resumen, abstrae toda la complejidad involucrada en la comunicación con AWS SQS y permite que los desarrolladores se centren únicamente en la lógica empresarial central.

La biblioteca se basa en Django ORM framework y boto3 library.

Cómo lo utilizamos

Nuestro equipo trabaja en una solución de protección del correo electrónico que utiliza inteligencia artificial para detectar spear phishing y otros ataques de social engineering. Nos integramos con la cuenta de Office 365 de nuestros clientes y recibimos notificaciones cada vez que reciben nuevos correos electrónicos. Una de las tareas es determinar si el nuevo correo electrónico está libre de cualquier tipo de fraude. Al recibir dichas notificaciones, uno de nuestros servicios (Figura 1: Servicio 1) se comunica con Office 365 a través de Graph API y obtiene esos correos electrónicos. Para el procesamiento adicional de esos correos electrónicos y para que estén disponibles para otros servicios, esos correos electrónicos se envían a la cola de AWS SQS (Figura 1: queue_1).

FIGURA 1

Examinemos un caso de uso sencillo sobre cómo usamos la biblioteca en nuestras soluciones. Uno de nuestros servicios (Figura 1: Servicio 2) es responsable de extraer encabezados y conjuntos de características de correos electrónicos individuales y ponerlos a disposición de otros servicios para su consumo.

El Servicio 2 está configurado para escuchar queue_1 y recuperar los cuerpos de correos electrónicos en bruto.

Supongamos que el Servicio 2 realiza las siguientes acciones:

# consumir mensajes de correo electrónico de queue_1

…

# extraer encabezados y conjuntos de características de los correos electrónicos

…

# enviar una tarea

process_message.delay(tenant_id=, correo electrónico=, headers=, tenant_id=, feature_set=, ....)

Este método process_message no se llamará de forma sincrónica, sino que se pondrá en cola como una tarea y se ejecutará una vez que uno de los trabajadores la recoja. El trabajador aquí podría ser del mismo servicio o de un servicio diferente. Quien llama el método no debe preocuparse por el comportamiento subyacente ni por cómo se ejecutará la tarea.

Veamos cómo se define el método process_message como una tarea.

Desde la tarea de importación eb_sqs.decorators

@task(queue_name='queue_2′, max_retries=3)
def process_message(tenant_id: int, email_id: str, headers: List[dict], feature_set: List[dict], …) :

pruebe a:

# realizar alguna acción utilizando encabezados y conjuntos de características
# también puede poner en cola tareas adicionales, si es necesario

except(OperationalError, InterfaceError) como exc:

pruebe a:

process_message.retry()

excepto MaxRetriesReachedException:

logger.error(‘MaxRetries reached for Service2:process_message ex: {exc}')

Cuando decoramos el método con el decorador de tareas, lo que sucede internamente es que se añaden datos adicionales, como el método de llamada, el método de destino, sus argumentos y algunos metadatos adicionales antes de serializar el mensaje y enviarlo a la cola de AWS SQS. Cuando el mensaje es consumido de la cola por uno de los trabajadores, este tiene toda la información necesaria para ejecutar la tarea: qué método llamar, qué parámetros pasar, etcétera.

También podemos volver a intentar realizar la tarea en caso de una excepción. Sin embargo, para evitar un escenario de bucle infinito, podemos establecer un parámetro opcional max_retries para detener el procesamiento cuando alcancemos el número máximo de reintentos. A continuación, podemos registrar el error o enviar la tarea a una cola de mensajes muertos para su posterior análisis.

AWS SQS ofrece la capacidad de retrasar el procesamiento del mensaje hasta 15 minutos. Podemos añadir una capacidad similar a nuestra tarea pasando el parámetro delay:

process_message.delay(email_id=, headers=, …., delay=300) # delaying by 5 min

La ejecución de las tareas se puede lograr ejecutando el comando process_queue de Django. Esto permite la escucha de una o más colas, la lectura de las colas de manera indefinida y la ejecución de las tareas a medida que llegan:

python manage.py process_queue –queues

Acabamos de ver cómo esta biblioteca facilita la comunicación dentro de un servicio o entre servicios a través de las colas de AWS SQS.

Puede encontrar más detalles sobre cómo configurar la biblioteca con los ajustes de Django, la capacidad de escuchar múltiples colas, la configuración de desarrollo y muchas más características aquí.

Contribuir

Si desea contribuir al proyecto, haga referencia a: DJANGO-EB-SQS

Rohan Patil

Rohan Patil es Ingeniero Principal de Software en Barracuda Networks. Actualmente, está trabajando en Barracuda Sentinel, una protección basada en IA contra el phishing y la usurpación de cuentas. Ha trabajado durante los últimos cinco años en tecnologías en la nube y en la última década en varios roles relacionados con el desarrollo de software. Tiene un máster en Informática por la Universidad Estatal de California y se licenció en Informática en Bombay (India).

Conecte con Rohan en LinkedIn aquí.

www.barracuda.com

Uso de GraphQL para APIs robustas y flexibles

El diseño de API es un área en la que puede haber mucha disputa entre los desarrolladores de aplicaciones cliente y los desarrolladores de backend. Las API REST nos han permitido diseñar servidores sin estado y un acceso estructurado a los recursos durante más de dos décadas, y siguen sirviendo a la industria, principalmente debido a su simplicidad y curva de aprendizaje moderada.

REST se desarrolló alrededor del año 2000, cuando las aplicaciones cliente eran relativamente simples y el ritmo de desarrollo no era tan rápido como lo es hoy en día.

Con un enfoque tradicional basado en REST, el diseño se basaría en el concepto de recursos que gestiona un servidor específico. Luego, normalmente confiaríamos en los verbos HTTP como GET, POST, PATCH, DELETE para realizar operaciones CRUD en esos recursos.

Desde la década de los 2000, varias cosas han cambiado:

• El aumento del uso de aplicaciones de una sola página y aplicaciones móviles ha creado la necesidad de una carga de datos eficiente.
• Muchas de las arquitecturas de backend han pasado de arquitecturas monolíticas a arquitecturas de microservicios para ciclos de desarrollo más rápidos y eficientes.
• Se necesita una variedad de clientes y consumidores para las API. REST dificulta la creación de una API que soporte múltiples clientes, ya que devolvería una estructura de datos fija.
• Las empresas esperan desplegar las características más rápido en el mercado. Si es necesario realizar un cambio en el lado del cliente, a menudo se requiere un ajuste en el lado del servidor con REST, lo que lleva a ciclos de desarrollo más lentos.
• El aumento de la atención a la experiencia del usuario a menudo lleva a diseñar vistas/widgets que requieren datos de múltiples servidores de recursos de la API REST para renderizarlas.

GraphQL como una alternativa a REST

GraphQL es una alternativa moderna a REST que busca resolver varias deficiencias, y su arquitectura y herramientas están diseñadas para ofrecer soluciones a las prácticas contemporáneas de desarrollo de software. Permite a los clientes especificar exactamente qué datos son necesarios y permite obtener datos de múltiples recursos en una única solicitud. Funciona más como RPC, con consultas nombradas y mutaciones en lugar de acciones obligatorias estándar basadas en HTTP. Esto sitúa el control donde corresponde: el desarrollador de la API de backend especifica lo que es posible, y el cliente/consumidor de la API especifica lo que se requiere.

Aquí tiene un ejemplo de consulta de GraphQL, que fue revelador para mí cuando lo encontré por primera vez. Supongamos que estamos desarrollando un sitio web de microblogging y necesitamos consultar 50 publicaciones recientes.

query recentPosts(count: 50, offset: 0) {
id
title
tags
content
author {
id
name
profile {
email
interests
}
}
}

La consulta GraphQL mencionada anteriormente tiene como objetivo solicitar:

• 50 publicaciones recientes
• ID, título, etiquetas y contenido de cada entrada de blog
• Información del autor que incluye ID, nombre e información de perfil.

Si tenemos que utilizar un enfoque tradicional de API REST para esto, el cliente tendría que hacer 51 solicitudes. Si las publicaciones y los autores se consideran recursos separados, se realiza una solicitud para obtener 50 publicaciones recientes y luego 50 solicitudes para obtener la información del autor de cada publicación. Si la información del autor puede incluirse en los detalles de la publicación, entonces esto también podría ser una solicitud con la API REST. Sin embargo, en la mayoría de los casos, cuando modelamos nuestros datos utilizando las mejores prácticas de normalización de bases de datos relacionales, gestionaríamos la información del autor en una tabla separada, lo que convierte la información del autor en un recurso de API REST independiente.

Esta es la parte interesante de GraphQL. Supongamos que en una vista móvil, no disponemos de espacio en la pantalla para mostrar tanto el contenido de la publicación como la información del perfil del autor. Esa consulta ahora podría ser:

query recentPosts(count: 50, offset: 0) {
id
title
tags
author {
id
name
}
}

El cliente móvil ahora especifica la información que desea, y la API de GraphQL proporciona exactamente los datos que se solicitan, ni más ni menos. No tuvimos que hacer ningún ajuste en el lado del servidor, ni nuestro código del lado del cliente tuvo que cambiar significativamente, y el tráfico de red entre el cliente y el servidor es óptimo.

El punto a tener en cuenta aquí es que GraphQL nos permite diseñar APIs flexibles basadas en los requisitos del lado del cliente en lugar de desde la perspectiva de la gestión de recursos del lado del servidor. Una percepción general es que GraphQL solo tiene sentido para arquitecturas complejas que implican varias decenas de microservicios. Esto es verdad hasta cierto punto, dado que hay una curva de aprendizaje con GraphQL en comparación con las arquitecturas de API REST. Pero esa brecha se está cerrando, con una importante inversión intelectual y financiera de la emergente fundación de proveedores neutrales.

Barracuda es pionera en la adopción de arquitecturas GraphQL. Si este blog ha despertado su interés, siga este espacio para ver mis próximas publicaciones, donde profundizaré en más detalles técnicos y beneficios arquitectónicos.

Vinay Patnana

Vinay Patnana es el director de ingeniería del Servicio de Seguridad del Correo Electrónico de Barracuda.  En este puesto, ayuda en el diseño y desarrollo de los servicios de escalabilidad de las soluciones de correo electrónico de Barracuda.

Vinay tiene un máster en Informática por la Universidad Estatal de Carolina del Norte y una licenciatura en Ingeniería por el BIT Mesra, India.  Lleva varios años en Barracuda y tiene más de una década de experiencia laboral con distintas variedades de pilas tecnológicas.  Puede conectar con él en LinkedIn aquí.

www.barracuda.com