La ciberseguridad es uno de los sectores que se ha convertido en un principal en todas las empresas. Por eso, desde Making Science consideramos que es el momento de que conozcas un poco más de las jergas y abreviaturas ya que no se usan en el día a día y muchas personas podemos tener problemas para comprender ciertos artículos.

¡Dentro artículo! 🚀

Términos básicos de detección y respuesta

• SIEM: Acrónimo de las siglas: Security Information and Event Management.

Se trata de un software que intenta detectar y prevenir amenazas antes de que ocurran. Dicho término sale de la unión de, por un lado, SEM que se encarga del almacenamiento y análisis de eventos en tiempo real; y por otro lado, el almacenaje para el futuro análisis, SIM.

Su objetivo es recopilar, identificar y analizar los eventos de forma rápida para prevenir ataques y vulnerabilidades.

• SOAR: Acrónimo de las siglas: Security Orchestration, Automation, and Response.

SOAR se refiere a un conjunto de herramientas que optimizan las operaciones de los analistas de seguridad, mediante la gestión de amenazas, respuesta a los incidentes y automatización de seguridad.

Estas herramientas se utilizan para mejorar las plataformas SIEM, ya que esta no posee ciertas capacidades. Aunque si bien es cierto que cada vez la diferencia entre SOAR y SIEM se ha vuelto menos clara, por eso podemos ver en muchos sitios que trabajan en conjunto.

• SOC: Acrónimo de las siglas: Security Operation Center.

Un SOC se trata del equipo que se encarga de la seguridad, su objetivo es evitar posibles ataques en la empresa con la ayuda de herramientas necesarias para analizar, investigar y dar soporte a todos los eventos que puedan ocurrir, entre esas herramientas la principal es SIEM.

Las principales ventajas de tener un SOC pueden ser proteger los datos, cumplir con las normas de seguridad gubernamentales, y defenderse de intrusiones, entre otros.

• EDR: Acrónimo de las siglas: Endpoint Detection Response.

Se trata de un sistema de protección de equipos finales (ordenadores, móviles, servidores…) en una empresa. Puede ser una herramienta o un conjunto de ellas. 

Detectan e investigan comportamientos sospechosos en los puntos finales, permitiendo así a los equipos de seguridad responder a las amenazas rápidamente.

Las funciones que tienen son supervisar y recopilar datos de actividades en los equipos finales, analizar dichos datos para identificar amenazas. Si bien es cierto, EDR se limita solo a puntos finales y no da una visibilidad más profunda, un SIEM tiene la capacidad de conectarse con muchas herramientas, entre ellas EDR.

• XDR

Acrónimo de las siglas: Extended Detection and Response.

Se considera que son la evolución o las sucesoras del EDR.

No solo detecta amenazas en los endpoints si no que recopila información sobre esos puntos finales. Resuelven desafíos que las empresas tienen con los SIEM tradicionales pero no sustituye a un SIEM porque no resuelve todos los casos de seguridad, son complementarios.

Los casos de seguridad que puede resolver un XDR pueden ser amenazas en tiempo real, determina que es real o no en un ataque, respuestas más profundas…

Si te ha gustado este post…

No dudes echar un vistazo a nuestros últimos posts sobre ciberseguridad, en los que hablamos sobre herramientas y tecnología qué pueden ayudarte a reforzar la seguridad de tu organización.¡Échales un ojo aquí! 

Lev Tolstói empieza su libro Anna Karenina diciendo «Todas las familias felices se parecen unas a otras; pero cada familia infeliz tiene un motivo especial para sentirse desgraciada». Este principio es también aplicable a la gestión de seguridad en la nube, pues lo cierto es que, la combinación entre diferentes proveedores de nube, recursos utilizados, y casos de uso, hacen que cada organización sufra de distintos males muy específicos para ella misma.

En este artículo trataremos los usos que le podemos dar a la herramienta Security Command Center (SCC), creada por Google Cloud para solventar muchas de las vulnerabilidades que sufre nuestra organización.

Filtración de credenciales

Según una encuesta realizada por la consultora de seguridad Constella Intelligence, casi en su totalidad, todos los directivos de las empresas consultadas piensan que el cambio de paradigma de la presencialidad a la virtualidad laboral ha ocasionado un incremento en los riesgos de seguridad, especialmente en cuanto a una probabilidad más alta de sufrir una filtración de credenciales. Afortunadamente, Security Command Center (SCC) viene con una funcionalidad que notifica inmediatamente si se encuentran credenciales en los sistemas con los que se tienen asociación. Por ejemplo, SCC notificará tan pronto se haya usado o compartido una clave SSH para una de nuestras Service Accounts (SAs) en un repositorio público de GitHub. La información que se incluirá en el JSON descriptivo del incidente será el proyecto en el que sucedió, el nombre de la SA, la clave SSH filtrada y la URL en la cual se encontró dicha clave.

Otra de las particularidades que nos permite detectar es si se ha hecho uso de alguna de las cuentas en una posición geográfica poco frecuente. SCC se encargará de analizar las zonas desde las cuales se suele acceder a las cuentas y notificar si se percibe comportamiento de inicio de sesión desde localizaciones poco frecuentes.

Adicionalmente, y esta es una de mis favoritas, es la de auto investigación de cuentas. Comúnmente cuando alguien obtiene acceso a una SA que no creó ni ha mantenido, lo primero que realizará es verificar que permisos posee la cuenta. Esto se hace con una llamada de auto investigación revisando las políticas IAM de la cuenta desde ella misma. Si bien en cuentas de usuario este tipo de consultas pueden parecer normales, no lo es en SA, puesto que estas están destinadas en su mayoría a automatizar labores de autenticación de máquinas a máquinas con un propósito muy bien definido. Evidentemente, SCC notificará de este tipo de actividad en las SA de la organización.

Finalmente, para las SAs existe otra herramienta de análisis y es la de uso de nuevos métodos API. Como mencioné anteriormente, la naturaleza de una SA es la de realizar autenticación con un propósito muy bien definido. Por tanto, una SA que consume un método API es muy probable que utilice  dicho método por un periodo continuo, por ejemplo, 7 días. Será extremadamente sospechoso si con las credenciales de dicha SA se empiezan a consumir métodos, especialmente si estos están relacionados con servicios críticos aislados de las funciones iniciales de la SA.

Modificaciones de seguridad y extracción de datos confidenciales

Imaginemos que nuestro sistema tiene una VPC configurada con un control de acceso para asegurarnos de que los datos dentro de esa VPC jamás salgan de ella. Un atacante con credenciales o un empleado por error elimina la configuración que define dicho perímetro de seguridad de datos. Con SCC nos podemos percatar cuando esto ocurra, a su vez nos notificará si, en el peor de los casos, los datos han dejado el perímetro previamente definido y cuál ha sido el método por el cual se han extraído. Por ejemplo, puede ser que los datos se encontraran dentro de una instancia de Cloud SQL y fueran extraídos hacia un bucket, SCC nos dará toda esta información.

A su vez, una de las modificaciones que un atacante puede realizar para conseguir acceso persistente a nuestro entorno es darse a sí mismo acceso a un rol, de esta forma, aunque las credenciales de la SA originalmente comprometida se rotaran, aún seguiría teniendo acceso. Para ello, SCC tiene un sistema de detección de anomalías en el aprovisionamiento de permisos en IAM.

Es importante que tengamos en cuenta que esta herramienta no es solo útil a posteriori de un ataque, si no que a su vez puede ser una herramienta útil a priori para descubrir accesos demasiado permisivos en nuestro entorno.

El atacante monetizando nuestro entorno en la nube con minado de criptomonedas

Una de las maneras más eficientes que un atacante tiene para monetizar nuestro entorno, independientemente del uso que le estemos dando, es por medio del minado de criptomonedas.

El atacante simplemente adquirirá cantidades inmensas de capacidad de computación en Compute Engine, y de una manera automatizada la utilizará para minar y ganar dinero imposible de rastrear. El riesgo es inmenso, puesto que el atacante puede solicitar cantidades de recursos hasta alcanzar alguno de los límites definidos por Google, la factura a final de mes será colosal. En este caso, SCC, detectará inmediatamente se estén haciendo peticiones a URL ya conocidos y sospechosos de minado.

Sí, por otro lado, se utiliza un dominio personalizado (imposible de vincular de manera automatizada con minado de criptomonedas) se puede hacer uso de otra de las herramientas de SCC, esta es denominada detector de Amenazas para máquinas virtuales, la cual desplegando una herramienta directamente en el hypervisor de las máquinas virtuales y haciendo un análisis constante del uso de memoria detectará y notificará inmediatamente se perciba que se está realizando una labor de minado.

Concluyendo este artículo, SCC es una herramienta valiosa a considerar si se desea minimizar los riesgos de seguridad a los que las organizaciones se enfrentan constantemente. Si bien como mencionamos al inicio, cada compañía tiene una mezcla de detalles que hacen que cada una sufra de vulnerabilidades muy particulares, SCC brinda una gama muy amplia de opciones a implementar y personalizar para asegurarnos que nuestro entorno en GCP sea tan seguro como el estado del arte de las herramientas disponibles nos lo permitan.

¿Quieres implementar Security Command Center y reforzar la seguridad de tu negocio? Nuestro equipo de expertos en Cloud & Seguridad puede ayudarte en tu caso concreto. ¡No dudes en contactarnos! 🚀

Contacta aquí

Es posible que últimamente hayas escuchado hablar sobre Zero Trust, un enfoque de seguridad basado en la «confianza cero» se ha convertido en uno de los puntos más importantes de la agenda de muchas empresas y líderes empresariales. Zero Trust es un modelo de seguridad que no confía en «nadie» por defecto. Entonces, ¿qué es exactamente Zero Trust? ¿Cómo afecta a mi compañía? ¿Qué cuestiones básicas debes conocer? 

El término «Zero Trust» fue acuñado por un analista de Forrester Research Inc. en 2010, cuando se presentó por primera vez el modelo del concepto. Unos años más tarde, Google anunció que había implementado la seguridad de Zero Trust en su red, lo que llevó a un creciente interés en la adopción dentro de la comunidad tecnológica. En 2019, Gartner, una firma global de investigación y asesoramiento, enumeró el acceso de seguridad de Zero Trust como un componente central de las soluciones de borde de servicio de acceso seguro (SASE). 

La lógica básica de la arquitectura Zero Trust promueve el «no confiar y verificar siempre». En un mundo de complejas amenazas a la ciberseguridad y fuerzas de trabajo móviles armadas con innumerables aplicaciones y dispositivos, Zero Trust pretende ofrecer una protección integral sin asumir que una solicitud nunca procede de una fuente de confianza, aunque haya nacido dentro del cortafuegos corporativo. Todo se trata como si procediese de una red abierta insegura, y la confianza se considera una obligación dentro del marco de Zero Trust. La arquitectura de confianza cero se basa en los principios de verificación indudable de la solicitud entrante y validación continua a lo largo de la conexión, proporcionando el nivel más bajo de autoridad y reduciendo la superficie de amenaza. 

Para Zero Trust, la seguridad de los datos es importante, y es por esto que su marco de ciberseguridad protege contra los ataques avanzados en entornos informáticos complejos con cargas de trabajo dinámicas que se mueven con frecuencia entre diferentes ubicaciones y diferentes dispositivos. 

Principales ventajas de Zero Trust

Sus principales ventajas son:

• Reduce el riesgo cerrando las brechas de seguridad y controlando los movimientos en la red
• Proporciona ciberseguridad avanzada y soporte para trabajadores móviles y remotos
• Proporciona una potente protección para las aplicaciones y los datos, ya sea en la nube o on-premise
• Defensa fiable contra amenazas como las amenazas de caracter persistente y avanzado

Además de proporcionar un entorno más seguro, la principal ventaja de Zero Trust Security es que evita las limitaciones basadas en la seguridad de los cortafuegos y las redes perimetrales. Zero Trust también destaca en que las credenciales de los usuarios se autentican de forma precisa y eficaz a intervalos regulares dentro de la red e incluye el uso de la protección perimetral y el cifrado para proteger los sistemas objetivo. 

Zero Trust actúa como una barrera para proteger una aplicación, sus procesos y sus datos contra los intrusos y los hackers malintencionados. Con una aplicación eficaz, este modelo de seguridad ha creado un nuevo paradigma de ciberseguridad.

¿Quieres saber más sobre Zero Trust y cómo securizar tus activos digitales? Nuestro equipo de expertos en seguridad ha ayudado a compañías líderes en el mercado a proteger tanto sus datos como sus arquitecturas y puede ayudarte en tu caso concreto. ¡No dudes en escribirnos!🛡

Contacta aquí

Es muy probable que en algún momento de tu vida hayas escuchado por un motivo u otro nombrar CSP o CORS, o ambas cabeceras HTTP, y que si no aclaraste los conceptos recuerdes que ambas cabeceras de seguridad parecen funcionar de manera similar, pero en realidad no es así.

Cross Origin Resource Sharing (CORS) y Content Security Policy (CSP) son dos cabeceras usadas en el protocolo HTTP que cuando se implementan ayudando a mejorar la seguridad de una aplicación web. 

Podemos decir que ambas cabeceras HTTP (CORS y CSP) permiten gestionar y controlar mediante una “whitelist” a los propietarios el origen de los recursos en su aplicación web, y de este modo aumentar la seguridad del activo digital.

CORS

Citando a MDN Web Docs:

El Intercambio de Recursos de Origen Cruzado (CORS) es un mecanismo que utiliza cabeceras HTTP adicionales para permitir que un user-agent obtenga permiso para acceder a recursos seleccionados desde un servidor, en un origen distinto (dominio) al que pertenece. Un agente crea una petición HTTP de origen cruzado cuando solicita un recurso desde un dominio distinto, un protocolo o un puerto diferente al del documento que lo generó.

Es decir, que si desde una página web realizamos una petición XHR a otra, el navegador internamente inicia con una solicitud de OPTIONS de verificación. Cuando el servidor al que se le ha lanzado la petición responde, verifica la respuesta y evalúa que en la lista de orígenes permitidos está la web desde la que se lanza la petición.

Algunos encabezados clave enviados como respuesta a la solicitud de OPTIONS comentanda anteriormente son:

• Access-Control-Allow-Origin: Tendrá una lista con los sites permitidos (como si de una whitelist se tratara). Para peticiones desde cualquier sitio se debe especificar «*», de este modo, el acceso al recurso a cualquier origen. 
• Access-Control-Allow-Methods: Lista de métodos HTTP permitidos: PUT, POST, etc.
• Access-Control-Request-Headers: Si se establece, las cookies son enviadas por el navegador.

CSP

Citando a MDN Web Docs:

Política de Seguridad del Contenido o (CSP) – del inglés Content Security Policy – es una capa de seguridad adicional que ayuda a prevenir y mitigar algunos tipos de ataque, incluyendo Cross Site Scripting (XSS) y ataques de inyección de datos. Estos ataques son usados con diversos propósitos, desde robar información hasta la desfiguración de sitios o distribución de malware.

Es decir, el objetivo principal es proteger frente a los ataques de Cross-Site Scripting (XSS) estableciendo en qué secuencias de comandos se debe confiar y cuáles no. Cuando un navegador intenta ejecutar un script desde una fuente desconocida, CSP lo bloqueará. 

CSP se establece a través del encabezado HTTP Content-Security-Policy.

Una vez explicadas ambas, podemos decir que la diferencia con CORS, es que CORS evita que desde un tercer sitio se acceda a nuestro activo digital, mientras que CSP evita que un sitio web cargue contenido de un tercero.

Para aclarar un poco más cada una de las cabeceras, nos valdremos del siguiente ejemplo. 

Supongamos que nuestro website es mywebsite.com y que otherwebsite.com es otro con “malas intenciones“.

Usando cabeceras CORS evitaremos este tipo de peticiones, ya que otherwebsite.com no se encuentra en la lista de orígenes permitidos.

mywebsite.com <———— X ———— otherwebsite.com 

                 (mywebsite.com/style.css)

Por otro lado, si tenemos configurada la cabecera CSP en nuestra web, y alguien intenta realizar una llamada desde mywebsite.com a otra URL que no tenemos permitida, el navegador bloqueará dicha petición.

mywebsite.com ———— X ————> otherwebsite.com

                  (otherwebsite.com/script.js)

Ahora ya sabes diferenciar CORS y CSP, pero quizás, pueda surgirte alguna duda todavía. ¡No dudes en comentárnosla! 🚀

Contacta aquí

¿Cuáles son las recomendaciones básicas para operar de forma segura con GKE? En este artículo compartimos con vosotros algunas recomendaciones de seguridad y buenas prácticas para asegurar un poco más tu cluster de Google Kubernetes Engine (GKE) y su seguridad.

No uses la cuenta de servicio por defecto

Puede sonar básico para algunas personas, pero no todo el mundo sabe acerca de los problemas de seguridad de la utilización de la cuenta de servicio por defecto. Esta cuenta por defecto tiene un rol de editor adjunto, por lo que su acceso es casi ilimitado y una cuenta de carácter peligroso. Si alguien es capaz de comprometer un nodo de tu cluster, será capaz de hacer cosas como crear o/y borrar instancias, robar credenciales, datos, entre otros.

Desde Making Science te aconsejamos evitar el uso de esa cuenta en todas partes, y es por esto que tendrás que crear una nueva cuenta de servicio para el cluster GKE. Esta cuenta se configura a nivel de pool, por lo que podemos crear un nuevo pool en cualquier momento y migrar nuestros servicios en cualquier momento sin destruir el cluster.

Nota importante: No olvides añadir al menos los roles Logs Writer y Monitoring Metric Writer y nunca adjuntar un rol primitivo a esa cuenta de servicio.

Si es posible, no utilices nunca claves de cuentas de servicio

Esta es una recomendación general. No utilices una clave generada por una cuenta de servicio si es posible. La razón es que las claves no se rotan automáticamente y por lo tanto debemos rotarlas manualmente cada vez. Esto no siempre es posible y es un problema de seguridad. El acceso IAM en cambio, gestiona la rotación de claves automáticamente y es, por tanto, más seguro. Si su aplicación es capaz de iniciar sesión utilizando la cuenta de servicio por defecto en la instancia, el mejor enfoque es utilizar la identidad de carga de trabajo para poder vincular las cuentas de servicio de Google con las cuentas de servicio de K8s.

Para utilizar las GSA (cuentas de servicio de Google) en K8s, habilitaremos la opción de identidad de carga de trabajo en el cluster, y luego vincularemos la KSA (cuenta de servicio de Kubernetes) a una GSA. Una vez hecho esto, adjuntaremos esa KSA a un deployment, statefulset, etc… y entonces los pods creados por ella podrán iniciar sesión usando la cuenta de servicio por defecto.

Nota importante: La recomendación aquí es la misma que la de las instancias y es utilizar una cuenta de servicio diferente para cada servicio.

Nunca utilice roles primitivos

Esta es también una recomendación general y es seguir el principio de mínimo privilegio. NUNCA use roles primitivos en la Cuenta de Servicio porque puede llevar a una severa brecha de seguridad.

Encripta la base de datos de secretos usando KMS

Por defecto en GKE la base de datos etcd está encriptada en reposo (como todo), pero este archivo es accesible desde el interior de los nodos de GKE sin encriptación, por lo que puede ser extraído por un atacante si gana suficiente acceso al cluster. Para añadir una capa de seguridad adicional, podemos utilizar el servicio KMS para cifrar los datos utilizando una clave simétrica, por lo que extraer los datos de etcd será mucho más difícil.

Para ello, necesitaremos crear un llavero y una clave simétrica en el servicio KMS. Una vez creada la clave, configuraremos el cifrado de secretos de la capa de aplicación para que utilice esa clave.

Desactiva las autenticaciones inseguras

Asegúrate de que las autenticaciones heredadas e inseguras están deshabilitadas. Por ejemplo:

• Autorización heredada
• Autenticación básica

Habilita la autorización binaria

La autorización binaria es un servicio que le permitirá comprobar si los servicios desplegados en su cluster están validados. Esto se hace verificando que el despliegue está firmado, por lo que evitará que un atacante pueda desplegar un servicio comprometido aunque haya conseguido acceso al cluster.

Este enfoque también es muy útil para asegurarse de que todos los servicios desplegados en el cluster han superado una serie de pasos, por ejemplo, un pipeline de CI/CD que comprueba la seguridad de la imagen.

No utilices nunca la cuenta de root en el pod

Como siempre, debemos utilizar la cuenta de root en cualquier lugar es inseguro. Si un atacante consigue acceder al pod, tendrá acceso ilimitado a él. Lo mejor es crear una cuenta de servicio personalizada con el mínimo acceso en la imagen del pod y utilizarla para ejecutar todos los servicios. Esto protegerá tu pod de accesos no autorizados.

Utiliza un sistema de archivos R/O

Por defecto todos los pods pueden escribir en el sistema de archivos, lo que puede ser aprovechado por un atacante para ejecutar código en su servidor modificando o añadiendo archivos al mismo. Los pods son stateful y esto puede solucionarse simplemente reiniciando el pod, pero puede ser tardío para nuestra aplicación y puede haber sido comprometido de otras formas, como inyectando código en la base de datos o incluso obteniendo datos privados de la misma.

La mejor manera de evitar este tipo de vulnerabilidad es tener una aplicación bien programada, pero nada es totalmente seguro, por lo que es bueno tener una capa de seguridad extra habilitando el acceso R/O. Esto se puede hacer simplemente usando la opción readOnlyRootFilesystem en el despliegue.

Por supuesto, estas no son todas las recomendaciones para asegurar tu cluster GKE, pero es un punto de partida. ¿Quieres saber más sobre la seguridad de GKE? Nuestro equipo de expertos estará encantado de ayudarte en tu caso concreto. ¡Escríbenos! ⛅️

Contacta aquí

La seguridad de una aplicación web es crucial de cara a la protección de datos no solo de la organización, sino también de los clientes. Los ciberataques han causado aproximadamente un total de 6 trillones de USD en daños a lo largo de 2021 y se prevé que incremente anualmente un 15% en los próximos 5 años. Es importante usar todas las herramientas posibles para reducir el riesgo de estos ciberataques.

Google cloud armor es un “firewall» a nivel de aplicación el cual es capaz de protegernos de una gran variedad de ciberataques de manera sencilla y eficiente. Para poder utilizar esta herramienta tendremos que hacer uso de los balanceadores de carga que GCP proporciona ya que será ahí donde habilitaremos el Cloud Armor sobre los backend services.

Una vez configurado el balanceador de carga y activado un security policy a un backend service, será la hora de ajustar qué reglas WAF deseamos aplicar. Hay una gran variedad disponible según nuestras necesidades. En la siguiente tabla veremos un listado de algunas de estas reglas preconfiguradas agrupadas por categorías:

Cada una de estas reglas contienen docenas de firmas que son compiladas de ModSecurity v3.0.2. GCP proporciona una manera controlada de debugear estas reglas con tráfico real sin que el usuario se vea afectado ya que a la hora de habilitarlas podremos selecciona el modo “preview only”, esto significa que cada vez que una de estas reglas se dispare y vaya a bloquear una petición simplemente lo deje registrado y dejará pasar el tráfico. Obviamente al activar el modo preview no estaremos securizando nuestra plataforma de ningún modo pero podremos evitar falsos positivos y granularmente ir agregando cada una de estas reglas. 

Además del modo preview only GCP otorga la posibilidad de incrementar el verbose de estas security policies. ¿Y esto qué significa? Que por cada petición bloqueada por estas reglas veremos en el logging información detallada de qué firma y que parte de la petición ha causado el bloqueo, como previamente he mencionado cada una de las reglas listadas en la tabla previa contiene un número de firmas por lo que puede que alguna de estas firmas cause falsos positivos y deba ser deshabilitada.

Con esta protección podemos evitar los siguientes ataques:

• SQL injection
• Cross-site scripting
• Local file inclusion
• Remote file inclusion
• Remote code execution
• Method enforcement (public preview)
• Scanner detection
• Protocol attack
• PHP injection attack
• Session fixation attack

¿Quieres saber más sobre cómo securizar mejor tus sitios  web y aplicaciones? ? El equipo Cloud de Making Science puede ayudarte en tu caso concreto. No dudes en contactarnos en info@makingscience.com. ¡Te esperamos! ?