Change Paradigm : A new Path to secure our platform!

Change Paradigm : A new Path to secure our platform!


Infra and Security

“By 2025, 99% of cloud security failures will be caused by cloud customer negligence.” Gartner

Este artículo va ser netamente en base a mi experiencia y mucha investigación que estuve haciendo, voy a tratar de traer ejemplos de las diversas situaciones para darle claridad a este concepto.

Un poco de historia

Entonces, como siempre me gusta hagamos un poquito de historia, el concepto de seguridad de la información como disciplina ha venido desarrollándose y evolucionando a lo largo de los años. 

Hagamos un quick recap. Durante la década de 1950 - 1960, los únicos sistemas que existían eran de grandes empresas y empresas del gobierno, en ese momento no existía prácticamente nada relacionado a seguridad. Gracias a que la computadora e internet llegaron al “hombre de a pie” y se volvió muy accesible, la práctica de seguridad comenzó a existir como preocupación a tener. Entre 1970 - 2000 se consideraba a la seguridad como un subconjunto de las tareas de los administradores de sistemas o sysadmin. A medida que los sistemas se volvieron cada vez más complejos y se conectaron a redes cada vez más amplias, a lo largo de la década de 2000 y 2010,la seguridad de la información evolucionó dando al menos dos ramas bien claras: Seguridad de la información y Ciberseguridad. Esta última, se convirtió en una rama separada con un conjunto de habilidades y conocimientos específicos. Esto fue impulsado por el aumento de los ciberataques, el robo de información confidencial y la necesidad de cumplir con las regulaciones de seguridad de la información. En el 2008 pasó algo que podemos llamarlo un punto de inflexión en las industrias, el famoso “Cloud Computing”, de la mano de varias compañías, pero por sobre todo, AWS había puesto al alcance del “hombre de pie” el poder de tener tu propios servidores, esto no es nada menor ya que llevo a distribuir, adoptar y fomentar aún más el uso y desarrollo de nuevas tecnologías.

En la actualidad la estructura típica de un equipo de seguridad en una organización puede variar dependiendo del tamaño y las necesidades específicas de la empresa. Sin embargo, en general, un equipo de seguridad suele estar compuesto por varios roles clave, como los siguientes:

  • Gestión de Identidades  ( IAM ) : Responsable de gestionar los accesos y control de las identidades del personal de la empresa.

  • Gobierno, Cumplimiento y Riesgo ( GRC ): Responsable de asegurar que la empresa cumpla con las regulaciones y las normativas de seguridad de la información relevantes.

  • Operaciones de Seguridad ( SecOps) : Encargado de investigar incidentes de seguridad y de determinar su causa y su impacto.

  • Investigadores de incidentes ( SOC ): Encargado de investigar incidentes de seguridad y de determinar su causa y su impacto.

  • Especialistas en Seguridad de la Información: Responsables de proteger los sistemas de información de la organización mediante la implementación de controles de seguridad, como firewalls, sistemas de detección de intrusos, etc.

Con un approach más moderno: 

  • Appsec : Seguridad en la aplicación cuidando todo el ciclo de vida de una aplicación.

  • Offensive Security o también llamado Red Team: Equipo ofensivo que simula ataques para anticiparse a problemas.

  • Cloud Security o también llamado Blue Team: Proteger las nuevas plataformas Cloud de ataques.

  • Purple Team: la combinación de los equipos Red & Blue trabajando en conjunto, complementando sus habilidades

  • GRC: el equipo tradicional de cumplimiento, pero con un enfoque mucho más basado en el riesgo tecnológico y su gestión.   

  • IAM: explotando metodologías como el modelo Zero Trust

Ahora si vamos a como esta compuesto los equipos de Infra !  Vemos que hay equipos de resiliencia SRE, equipos de Plataforma y DevOps.

SRE: Tiene que trabajar de cara a métricas, resiliencia, automatismos. Su objetivo es la resiliencia. Cross teams

Platform: Tiene que trabajar con todos los equipos. Su objetivo es ser un habilitador de los desarrolladores, creando una plataforma interna que permite el autoservicio.

Equipo de DevOps, con objetivo de construir pipelines, despliegue de la infraestructura “estatica” necesaria para que el equipo de plataforma se monte sobre la misma.

Esto nos trae a la actualidad: según un estudio realizado en 2020, el 73% de las empresas en América Latina utilizan la metodología DevSecOps para mejorar la seguridad en la nube. DevSecOps empieza por DevOps, área que comienza por solucionar una problemática entre los equipos desarrollo y la operación, pero ya no es suficiente dando paso a equipos como SRE y Platform comentados en https://www.linkedin.com/pulse/site-reliability-engineering-path-build-fail-learn-repeat-behrend/ y https://www.youtube.com/watch?v=8uYnHppsOXc; a esto se le suma otra evolución más que introducir la seguridad como principal actor de la película.

¿Entonces, qué es DevSecOps y qué otras tendencias estamos viendo en seguridad? 

DevSecOps, es una tendencia que implica integrar la seguridad en todas las etapas del ciclo de vida del desarrollo de software, desde el diseño hasta la implementación y el mantenimiento. Al hacerlo, se pueden detectar y corregir problemas de seguridad de manera más eficiente y reducir el tiempo de implementación de soluciones de seguridad. 

Lo podemos ver como una metodología a adoptar por todo una empresa, un área o incluso tener un equipo dentro de la empresa que sean los responsables de la metodología DevSecOps. Existen todos los sabores y no podemos decir que ninguno es mejor sobre el otro, ya que cada uno tiene sus pro y sus contras, como se comentó en los artículos de SRE y Plataforma. 

Hoy incluso hay propuestas más extremas (como la de la Cloud Security Alliance) que aseguran que todo DevOps son de hecho DevSecOps

Convocatoria de la CSA en el último evento RSA

Vayamos ahora a contar un posible caso: contábamos con un equipo DevOps que se encargaba de los pipelines CI/CD, despliegue de Infra como código y mantenimiento de la Cloud/Servidores/Kubernetes. Por otro lado tenemos un equipo SecOps que se encarga de la operación de la seguridad, pero como ya hemos visto, sin importar la naturaleza del equipo, todos vamos a buscar automatizar lo máximo posible para optimizar nuestra operación. En pos de estas automatizaciones, va a pasar naturalmente que la operación de SecOps también va ser como Infra como código ( IaC), apoyada en los pipelines y creando automatismos sobre los servidores. En este caso, estamos viendo dos equipos que trabajan prácticamente con la misma metodología de trabajo y prácticamente con el mismo set de herramientas, pero en la práctica, ¿por qué terminan trabajando como dos granjas aisladas?, ¿por qué terminan ambos gestionando pipelines de CI/CD?, ¿por qué se arman silos y se duplican los esfuerzos? Estas son algunas de las preguntas que a mi criterio DevSecOps viene a responder y vuelve el trabajo mucho más eficiente para que, con menos, se pueda lograr mucho más.

Ahora bien, hablemos de este nuevo equipo “DevSecOps”. Este equipo obligatoriamente tiene que tener una composición lo más cercana a un 50% y 50% tradicionales infra y seguridad. Pero lo fundamental es que estén todos los miembros del equipo abiertos a decir “ahora me toca aprender de una práctica que antes no desarrollaba y escuchar otros puntos de vista”. Este punto que parece muy trivial es sin lugar a dudas lo más difícil a la hora de implementar una correcta metodología de DevSecOps.

Infraestructura y Seguridad

La seguridad es una parte fundamental de la infraestructura de la nube. Sin una adecuada protección, las empresas corren el riesgo de sufrir ataques cibernéticos, pérdida de datos y otros problemas de seguridad que pueden tener consecuencias graves. Por esta razón, es importante que los equipos de infraestructura y seguridad trabajen juntos de manera estrecha para garantizar la seguridad de la nube.

Tradicionalmente, los equipos de infraestructura y seguridad han estado bastante separados. Los equipos de infraestructura se encargaban de configurar y mantener la red, mientras que los equipos de seguridad se centraban en protegerla. Sin embargo, esta separación puede tener consecuencias negativas para la seguridad y la eficiencia.

Por ejemplo, si un equipo de infraestructura implementa un cambio en la red sin involucrar al equipo de seguridad, es posible que no se consideren todos los aspectos de seguridad relevantes. Esto puede dejar la red vulnerable a ataques cibernéticos o puede crear puntos débiles que pueden explotarse más adelante.

Por otro lado, si el equipo de seguridad no está involucrado en la planificación de la infraestructura, es posible que no se tenga en cuenta la seguridad desde el principio. Esto puede llevar a la implementación de medidas de seguridad ineficientes o costosas que podrían haber sido evitadas si se hubieran considerado desde el principio.

En las empresas cloud native, donde la infraestructura se basa en la nube y es altamente flexible y escalable, es aún más importante que los equipos de infraestructura y seguridad trabajen juntos de manera estrecha. La nube permite una mayor flexibilidad y escalabilidad, pero también presenta nuevos desafíos de seguridad. Por lo tanto, es esencial que los equipos de infraestructura y seguridad colaboren para garantizar la seguridad de la nube.

Hay varias maneras en que los equipos de infraestructura y seguridad pueden colaborar de manera más efectiva. Por ejemplo, pueden integrar sus herramientas y procesos de trabajo para garantizar que se considere la seguridad en cada paso del camino. También pueden implementar prácticas de trabajo conjunto para proteger adecuadamente la seguridad en la nube, es importante seguir algunas de las mejores prácticas recomendadas por AWS y otros expertos en seguridad. 

El cambio de paradigma

Pomelo es un startup fintech muy joven, en la cual tenemos marcado en el ADN repreguntarnos si realmente estamos siendo eficientes o no. Como parte de este análisis y habiendo realizando benchmark de mercado con varios colegas de diversas industrias y empresas, encontramos lo siguiente: 

  • La gran mayoría de las empresas tienen los mismos problemas.

  • Se encuentra que los departamentos de infraestructura/desarrollo no le dedican suficiente tiempo ni priorizan las necesidades de seguridad.

  • Roadmaps de seguridad,infraestructura y desarrollo fuera de sync

  • Falta de optimización y eficiencia de recursos: Tiempo y Costo, Construcción de herramientas y pipe paralelos para solucionar los mismos problemas

  • Seguridad son los últimos en enterarse de las necesidades reales del negocio, y al estar alejados del negocio se terminan convirtiendo en un bloqueante

“Insanity Is Doing the Same Thing Over and Over Again and Expecting Different Results”

Albert Einstein

Con esto sobre la mesa, nos pusimos en modo investigador para buscar qué es lo que hacen las empresas más modernas del mercado. Y nos encontramos algo que era esperado, ninguna lo resolvió de la misma forma pero todas de alguna forma u otra se enfocan en un concepto de cómo securizar la plataforma.

Luego de un mes de varias reuniones, varias hipótesis que lo fuimos construyendo entre todo el equipo habíamos llegado a un nuevo modelo. Un cambio de paradigma, en Pomelo tenemos una gran plataforma que tiene que estar preparada bajo los mejores estándares de Seguridad e Infraestructura, ya que estamos en el negocio de vender Infraestructura Fintech “de servicio/camino crítico”. Estándares como cumplir con PCI DSS Level 1, ISO 27001, regulaciones gubernamentales de varios países con el más alto nivel de servicio y uptime posible.

Un cambio de paradigma que radica en la fusión de Infraestructura y Seguridad “One big platform, One big team”

Ahora, ¿cuáles son los scopes de estos nuevos equipos de InfraSec? 

Track Secure Platform: 

CloudOps>

  • Soporte Level 1 tópicos Infra,Seguridad y DataOps 

  • Third Party VPN Management , Migraciones Base de datos en zona protegida

  • Soporte Despliegue y Mantenimiento Non-IT

  • Static-Infra Deployment (AWS / GCP)

DevSecOps>

  • CI/CD ( pipelines, orbs, contexts management, Security, access and permissions, IaC Repositories ). Integrar la seguridad en todas las etapas del ciclo de vida del desarrollo, desde el diseño hasta la implementación y el mantenimiento.

  • Static-Infra Management 

  • Networking: provisioning and troubleshooting

  • Edge Security 

  • Mantenimiento/Upgrade EKS, Addons k8s, ArgoCD, Sonarqube, Contract Testing Broker, E2E testing framework)

  • Configuración y mantenimiento de imágenes base Golden IMAGE 

  • Security Incidents of the Platform (General Security incidents reporting)

  • Cloud Security (General Cloud Security matters AWS or GCP)

  • Firewall (AWS Network Firewall)

Reliability>

  • Observabilidad - Monitoreo y Alertas : NewRelic, OpsGenie, Rundeck Management

  • Load, Chaos and Stress Tests: Configuración y mantenimiento

  • Incident Management & Response

Platform Core > 

  • Rocket (Internal Developer Platform, Secure-Dynamic-Infra, Informations ,Approvals, Notification, Events, en todos los ambientes y para todos los equipos Desa, Data, Infrasec, Templates repositorios base)

Platform Solutions > 

  • Aplicaciones estructurales

  • Ayudar a todos los equipos en troubleshooting L3 

  • Ayudar en el inicial Startup de los equipos 

  • Support Secure Development  (Orb Security, Threat Modelling, Security Automated)
    Security reviews : Testing code & Running code

  • Definicion de parametros de seguridad (imágenes base contenedores, segregación de tráfico y permisos entre apis)

  • Offensive security

Track Seguridad de la información : 

Access & Support > 

  • Endpoint Security (Responsible for threat prevention to security end-user and business activities for design incident detection and response)

  • Access & Secret Management (Automatización In-House de ABM, Gobierno de accesos de Apps, Control y hardening de accesos, accesos privilegiados, Requerimientos Regulatorios)

  • IT Support (Gestión de ABM de Apps, troubleshooting & Internal Customer problem solving, IT Assets Management and Customer Experience First)

Governance,Risk and Compliance > 

  • Governance Framework (Change Management, Cyber Risk, Cyber Committee, etc.)

  • Keys Management (HSM / EMV + Lastpass Privileged Users Vault + Secrets Manager)

  • Compliance: PCI Compliance Scope, Regional Regulatory, Third Party Due Diligences 

  • IT Risk Management: Cyber Risk Analysis / Business Continuity Plan / Disaster Recovery Plan / Business Impact Analysis

  • Cyber Awareness and Cyber Culture 

  • Data Protection / Data Privacy 

Cambiamos los equipos, pero para cambiar un paradigma se necesita más que eso. Por eso fuimos a evolucionar el framework buscando las metodologías más novedosas del mercado, algunas de ellas:

Metodología SOCless

El objetivo era llegar a eliminar lo que veíamos como el SOC tradicional, donde teníamos un centro de monitoreo con monitores totalmente reactivos y llenos de errores humanos e Incorporar SOCless. Su tecnología se basa en generar automatismos necesarios para tener las alertas, e incluso llegar al punto que los Playbooks a accionar también los podamos automatizar. Ir a SOCless no es algo que pasa de un día para otro, sino que tenemos que trabajar todos bajo este mantra.

https://www.pipelinepub.com/top-trends-2021/beyond-the-SOC/2 

Zero Trust y mejoras en el control de postura de seguridad

“Nunca confíes en nada ni en nadie”, esa es la filosofía que nos trae Zero Trust, no es más que la propia evolución de conceptos ya antiguos de “No hacer seguridad por confianza”. Ahora, técnicamente Zero Trust nos trae este concepto de no confiar en NADA ni en NADIE, por lo que es un modelo que va a permitir, dentro de un zona de confianza conocida por todos los actores, y sólo a aquellos que validen toda la cadena de confianza, acceder a donde se requiera para cumplir su rol o función.

Pongamos un ejemplo, uno de los assets más valiosos de una compañía es su información.
¿Cómo podemos asegurarnos que la persona debida es la que tiene ingresar al lugar correcto y no es alguien haciéndose pasar por un empleado de nuestra empresa?

Para lograr Zero Trust tenemos que poder controlar y garantizar: 

  • El equipo desde el cual se está conectando, esté controlado y sea de propiedad de la empresa, con los debidos controles de seguridad Antivirus, Antimalware y con un login de un usuario válido desde el IDP elegido por la empresa.

  • El usuario que se está conectado es un usuario válido con los permisos necesarios.

  • El usuario se conecta mediante la VPN de la organización.

  • El usuario utilizó un sistema de 2FA que permite validar la persona.

Si alguien llegara a hacerse de las credenciales de un empleado, necesita también tener un dispositivo válido y con el 2FA válido.

Por lo que, si aplicamos esto como control para conectarnos a la VPN, la Plataforma y el repositorio de código, estaríamos reduciendo en gran medida los riesgos de robo de identidades interno, que es uno de los ataques más comunes que reciben las plataformas hoy en día.

https://www.skyflow.com/post/what-is-zero-trust

Tokenize Everything: Una Respuesta Eficaz

En los últimos años, la protección y gobierno de datos se ha convertido en un tema de gran relevancia, impulsado en gran medida por regulaciones como el Reglamento General de Protección de Datos (GDPR) en Europa. En Latinoamérica, esta tendencia también ha cobrado fuerza, con la mayoría de los países adoptando medidas similares. En este contexto, Tokenize Everything emerge como una solución clave para mitigar uno de los mayores riesgos actuales en seguridad: el acceso no autorizado a datos privados y sensibles.

El robo o filtración de datos privados y sensibles es una preocupación creciente para empresas de todos los tamaños y sectores. La pérdida de información confidencial puede acarrear consecuencias devastadoras, incluyendo pérdida de confianza de los clientes, sanciones económicas y daños a la reputación de la compañía. Es aquí donde la estrategia de Tokenize Everything emerge como una poderosa solución para salvaguardar los datos y preservar la privacidad.

¿Qué es Tokenize Everything?

Tokenize Everything es un enfoque innovador que implica transformar y proteger la información sensible mediante el uso de tokens. Estos tokens son representaciones cifradas de los datos originales y son utilizados para operar en lugar de los datos en sí mismos. Esto significa que los datos privados no se almacenan en las bases de datos operativas o Datalakes en su forma original, lo que reduce significativamente el riesgo de exposición y robo.

Beneficios y Desafíos

La adopción de Tokenize Everything conlleva beneficios significativos para las organizaciones, pero también implica nuevos desafíos que deben abordarse de manera cuidadosa. Entre los principales beneficios se encuentran:

  • Mayor Seguridad: Al no almacenar los datos en plano, los sistemas se vuelven menos vulnerables a ataques y filtraciones, proporcionando una capa adicional de seguridad.

  • Cumplimiento Normativo: El uso de tokens puede facilitar el cumplimiento de regulaciones sobre protección de datos, como el GDPR, al minimizar el riesgo de incumplimiento.

  • Mantenimiento de la Confianza: Al proteger la información privada de los clientes, las empresas pueden mantener la confianza y lealtad de su base de usuarios.

Sin embargo, también existen desafíos asociados con la implementación de Tokenize Everything:

  • Cambios en Procesos: Esta estrategia puede requerir ajustes en los procesos de desarrollo y análisis de datos para garantizar una implementación adecuada.

  • Mayor infraestructura: La tokenización puede aumentar la carga sobre la infraestructura, ya sea por la propia infra para que suceda, como la complejidad de la plataforma en sí.

  • Seguridad de Tokens: Asegurar la protección de los propios tokens se vuelve crucial, ya que un acceso no autorizado a ellos podría comprometer la seguridad de los datos.

Shift Left Security : Mayor adopción de Secure Software Development Life Cycle

Shift Left Security,  llevemos al inicio del proyecto a pensar en seguridad. 

 

La nube, con todas sus ventajas y desventajas, ha permitido la convergencia de varias prácticas y varias prácticas, incluyendo las áreas de infra y seguridad. Ahora, hablando de lo que me tocó trabajar en los últimos 5 años: el caso de las fintech. Estas tienen que cumplir con diversas regulaciones como PCI DSS, ISO 27001, SOC2, regulaciones bancarias de diversos países. Por lo tanto, la convergencia de estas áreas es cada vez más necesaria, además de otras más que puedan ir surgiendo para ser habilitadores del negocio.

Entonces, ¿qué beneficios, desventajas y desafíos trae esta fusión de equipos?

Beneficios:

  • Mayor eficiencia en la entrega de software: Al integrar la seguridad en todas las etapas del ciclo de vida del software, es más probable que se detecten y corrijan problemas de seguridad temprano en el proceso, lo que puede acelerar la entrega de software y evitar retrasos.

  • Mayor colaboración y comunicación entre los equipos: Al fusionar los equipos de devops y cloudsec en equipos multifuncionales, se fomenta una mayor colaboración y comunicación entre los equipos, lo que puede mejorar la calidad del software y reducir los errores.

  • Mayor confianza del cliente: Al garantizar que la seguridad sea una consideración clave en todas las etapas del proceso de desarrollo y entrega de software, es más probable que los clientes confíen en la seguridad del software y en la empresa en general.

  • Mejor comunicación y colaboración. Una mentalidad y objetivos compartidos evitan silos y aseguran un enfoque coordinado.

  • Mayor eficiencia: Se reducen los esfuerzos duplicados y se logra una visión unificada de los riesgos, controles y requisitos de cumplimiento.

  • Mejor gestión de riesgos: Los riesgos de infraestructura y aplicaciones se gestionan de manera integral en toda la organización. Los controles se implementan de manera coherente e integral.

  • Optimización de costos: Los recursos, esfuerzos e inversiones se asignan más eficientemente, y los gastos, se racionalizan.

  • Agilidad e innovación: Un equipo integrado puede implementar nuevas tecnologías y procesos más rápidamente, al tiempo que gestiona los riesgos.

  • Ventajas para el negocio: La integración de equipos permite un enfoque más estratégico de la seguridad y la infraestructura, lo que impulsa la transformación digital y el crecimiento de las fintech.

  • Cumplimiento normativo: Los controles y la gestión de riesgos integrados facilitan el cumplimiento de las regulaciones, lo que reduce la carga de auditoría y el riesgo de sanciones.

Sin embargo, también existen desventajas, desafíos y riesgos significativos en la integración de equipos, no quiere decir que tengan que ser así sino que son preguntas que nos tenemos que hacer a la hora de explorar este camino! 

  • Conflictos de interés: Los equipos pueden tener diferentes prioridades, incentivos y objetivos clave de rendimiento, lo que puede ser difícil de conciliar. Es clave acá el tener un único referente que pueda primar y tener un único sentido en frente a esto.

  • Falta de especialización: Los perfiles generalistas pueden carecer de profundidad en Infraestructura o Ciberseguridad, lo que puede provocar debilidades en el equipo.

  • Mayor complejidad: La integración de equipos requiere un esfuerzo sustancial en alineación, comunicación y coordinación para funcionar de manera efectiva.

  • Carga regulatoria: Los estrictos requisitos de cumplimiento en las fintech aumentan la dificultad de integrar equipos y los riesgos de no pasar auditorías.

  • Diferencias culturales: Los equipos de TI y seguridad a menudo tienen culturas, mentalidades y formas de trabajar distintas que pueden ser difíciles de combinar.

  • Responsabilidades difusas: Pueden surgir responsabilidades y autoridades de decisión poco claras, lo que crea brechas o redundancias.

En conclusión, si bien la integración de los equipos de Infraestructura de TI y Ciberseguridad en las fintech tiene importantes beneficios potenciales, también plantea grandes desafíos, especialmente en una industria altamente regulada. Las empresas deben evaluar cuidadosamente si las ventajas de la integración superan las dificultades y los riesgos antes de decidir fusionar estos equipos. Con una planificación integral, la alineación de las partes interesadas, una gobernanza clara y una cultura compartida, la integración de equipos puede tener éxito. Sin embargo, requiere un trabajo contínuo para desarrollar una mentalidad común, prioridades unificadas y esfuerzos coordinados. Los riesgos y desafíos de la integración deben gestionarse activamente.

Ahora ¿Entonces cómo les fue en la práctica?

Artículos:

  1. “Forming a Secure Infrastructure Team” (Formación de un equipo de infraestructura segura), de Dan Young, publicado en la revista Network World: https://www.networkworld.com/article/3301677/forming-a-secure-infrastructure-team.html

  2. ”How to Build a Strong Security Team” (Cómo formar un equipo de seguridad sólido), de Ryan O’Leary, publicado en la revista CSO Online: https://www.csoonline.com/article/2114982/how-to-build-a-strong-security-team.html

  3. ”Forming a Secure Infrastructure Team” (Formación de un equipo de infraestructura segura), de Dave Shackleford, publicado en la revista Dark Reading: https://www.darkreading.com/endpoint/forming-a-secure-infrastructure-team/a/d-id/1332523

  4. ”Building a Strong Security Team” (Formación de un equipo de seguridad sólido), de James Turnbull, publicado en la revista Security Boulevard: https://securityboulevard.com/2018/03/building-a-strong-security-

  5. ”Building a Secure Infrastructure Team” de Chris Romeo: Este artículo proporciona una visión general de los pasos a seguir para construir un equipo de infraestructura segura, incluyendo la identificación de las necesidades de seguridad de la empresa, la definición de roles y responsabilidades y la implementación de medidas de seguridad.

  6. ”Creating a Secure Infrastructure Team” de Joe Kinsella: Este artículo proporciona una visión general de cómo formar un equipo de infraestructura segura y proporciona consejos sobre cómo seleccionar a los miembros del equipo, cómo capacitar al equipo y cómo establecer una cultura de seguridad.

  7. ”The 10 Key Elements of a Secure Infrastructure Team” de Tim Prendergast: Este artículo proporciona una lista de los 10 elementos clave que deben tener en cuenta los equipos de infraestructura segura, incluyendo la identificación de las necesidades de seguridad de la empresa, la implement

  8. ”A Practical Guide to Building an Effective Cloud Security Team” (Una guía práctica para crear un equipo

  9. ”The Key to Building an Effective Cloud Security Team” (La clave para crear un equipo de seguridad en la nube efectivo), de la plataforma de seguridad de la información Zscaler. Este artículo ofrece consejos y estrategias para crear un equipo de seguridad en la nube efectivo.

  10. ”6 Steps to Building an Effective Cloud Security Team” (6 pasos para crear un equipo de seguridad en la nube efectivo), de la empresa de seguridad de la información AlienVault. Este artículo ofrece una guía paso a paso para crear un equipo de seguridad en la nube efectivo y establece las responsabilidades y las expectativas para los miembros del equipo.

  11. ”Building an Effective Cloud Security Team: A Practical Guide” (Creación de un equipo de seguridad en la nube efectivo: una guía práctica), de la empresa de seguridad de la información Duo Security. Este artículo ofrece consejos y estrategias para crear un equipo de seguridad en la nube efectivo y establece las responsabilidades y las expectativas para los miembros del equipo.

  12. ”Building a Security Team in the Cloud Era” (Creación de un equipo de seguridad en la era de la nube), de la empresa de seguridad de la información Cloud Security Alliance. Este artículo ofrece consejos y estrategias para crear un equipo de seguridad en la nube y establece las responsabilidades y las expectativas para los miembros del equipo.

**


© 2024 Thanks! Gracias!⚡️