Presentamos la rueda de colores de InfoSec — que combina desarrolladores con equipos de seguridad rojos y azules.

Como desarrollador convertido en persona de seguridad, aprendí de primera mano lo importante que es que todos los equipos trabajen juntos, más que solo DevSecOps.

Es hora de incluir y combinar desarrolladores en nuestro círculo Infosec.

Estado actual de la Seguridad de la Información
Equipos rojo y azul

En el ámbito de la seguridad de la información, suele haber dos grupos principales:

El Equipo Rojo, empleados o contratistas contratados para ser Atacantes , hackers éticos que trabajan para una organización encontrando agujeros de seguridad que un individuo malintencionado podría explotar.

El Equipo Azul , los Defensores de la organización, que son responsables de las medidas de protección dentro de una organización.

Si bien es bueno tener personas dedicadas a asegurar una organización a través de métodos de defensa o ataque, las organizaciones y sus sistemas no permanecen estáticos.

Procesos adicionales, automatizaciones, productos y que se construyen constantemente, con el área de superficie de ataque potencial creciendo con cada nuevo cambio o integración.

Tener solo equipos de seguridad rojos y azules no es suficiente. Hay que incluir a las personas que construyen lo que hay que defender.

Presentamos al equipo amarillo: los constructores

Estas son las personas que crean y diseñan software, sistemas e integraciones que hacen que las empresas sean más eficientes.

Los desarrolladores de aplicaciones, los ingenieros de software y los arquitectos entran en esta categoría.

Su enfoque suele estar en los requisitos, la funcionalidad, la experiencia del usuario y el rendimiento de back-end.

Si queremos tener aplicaciones, automatizaciones y procesos diseñados e implementados de forma segura, Red Team y Blue Team deben trabajar con los constructores .

Los constructores deben incluirse como parte de la seguridad de la información.

(Yellow necesita ser parte del equipo. Solo podemos hacer esto trabajando juntos)

El año pasado, April Wright propuso una solución en su charla BlackHat titulada " Orange is the new Purple " ( versión grabada de DefCamp ) y muestra cómo los constructores/atacadores/defensores son todos un equipo de InfoSec . Parte del contenido a continuación es directamente de su artículo.

Necesitamos convertir a los constructores en "el equipo amarillo" y darles la capacidad de hacer que sus aplicaciones sean más seguras.

El enfoque de un desarrollador está en la funcionalidad y en hacerla tan funcional lo más rápido posible. Una vez que la funcionalidad de una aplicación funciona para todos los usuarios y partes interesadas, sus desarrolladores dormirán tranquilos porque han hecho su trabajo a la perfección.

Los desarrolladores nunca saben, o realmente piensan, si han hecho algo de manera insegura, hasta que se les señala como parte de una prueba de penetración realizada por Red Team, o como parte de una brecha descubierta por Blue Team (teniendo en cuenta que dos tercios de las infracciones tardan meses o más en descubrirse).

Sin embargo, estamos creando software más rápido de lo que se puede probar y defender en términos de seguridad .

Ponemos la responsabilidad de la seguridad en los programadores, que no tienen experiencia en seguridad.

Nuestra industria y organizaciones de seguridad están plagadas de vulnerabilidades y configuraciones incorrectas y todas tienen el mismo origen. La persona o grupo que lo construyó. Como dice el dicho:

Si la depuración es el proceso de eliminación de errores, la programación es el proceso de poner errores en la aplicación. Las pruebas solo prueban la presencia de errores, no la ausencia de ellos.

Para ayudar a resolver esto, las organizaciones actualmente tienen un ciclo:

Amarillo lo construye. Rojo lo rompe. Azul lo defiende. Amarillo lo arregla.

Bueno, esa es la teoría. En realidad es:

Amarillo lo construye. Rojo lo rompe. Azul se queja de eso. Amarillo lo ignora. La gerencia lo oculta

Eso es lo que tiende a fomentar nuestra cultura actual de Seguridad/Desarrollo.

Sin embargo, nuestro ciclo ideal funcionará mejor cuando

Los amarillos se educan con los rojos y trabajan mano a mano con los azules .

Yellow necesita estar involucrado para asegurar una organización.

Cómo ayudar al Equipo Amarillo a ser más seguro

La solución es educar al Equipo Amarillo con técnicas de ataque y utilizar las fortalezas del Equipo Amarillo para hacer que la defensa sea más fácil y visible.

Pasé los últimos cinco años trabajando con Blue Teams programando soluciones de automatización de seguridad y optimizando cómo mejorar sus capacidades de monitoreo y defensa. Si tuviera que etiquetarme en este momento, probablemente soy lo que la industria está tratando de clasificar como DevSecOps. Pero más Dev y Sec que Ops.

En los últimos cinco años, también he dedicado muchas sesiones de capacitación y cursos de piratería ética para desarrolladores y otro personal técnico. Les enseño cómo los atacantes ingresan a las redes, la infraestructura y las aplicaciones, y cómo mitigarlo con buenas prácticas de codificación y otras técnicas de defensa.

¿Cómo acortamos la brecha entre los desarrolladores y la seguridad?

Ahora hemos presentado nuestro equipo amarillo. Ya tenemos nuestro Equipo Rojo y Equipo Azul.

Rojo. Azul. Amarillo. Estos son nuestros Colores Primarios.

Estos tres equipos son necesarios para mantener una organización segura frente a las amenazas, lo que los hace responsables de la seguridad de una organización.

Ataque y Defensa no pueden hacerlo solos. Los programadores no pueden hacerlo solos. Todos necesitan trabajar juntos.

Individualmente, no tienen las habilidades o la visibilidad para proteger una organización.

Presentamos la rueda de color de InfoSec

Si el rojo , el azul y el amarillo son nuestros colores primarios , podemos combinar sus habilidades para crear equipos secundarios que combinen las habilidades y fortalezas de dos equipos primarios.

Esta rueda de color de InfoSec amplía el increíble trabajo de April Wright de incorporar constructores al equipo de seguridad al ponerlo en una sola infografía. (Imagen zip al final del artículo)

¿Como funciona?

Rojo, azul y amarillo son nuestros colores primarios.

Combine dos de ellos y obtendrá los colores secundarios .

Tenemos nuestros equipos rojo y azul como siempre, pero ahora con la introducción de un equipo amarillo, podemos tener equipos de colores secundarios (naranja, verde y morado) dedicados a combinar habilidades entre atacantes, defensores y programadores, lo que hace que el código sea más seguro y la organización más segura .

Veamos cómo podemos combinar estos conjuntos de habilidades para hacer que nuestras organizaciones sean más seguras.

Colores secundarios de InfoSec

La seguridad no puede ni debe estar aislada , pero en muchos casos, los desarrolladores de software y la seguridad actualmente están segregados entre sí y del resto de la organización.

La gente tiende a especializarse en un color primario, pero para que una organización sea segura, todos los colores deben ser fuertes, pero deben trabajar juntos y combinarse.

A medida que nos mezclemos, estos equipos combinarán su conocimiento y capacidad para mejorar y mejorar a los otros equipos para hacer que la organización sea más segura.

No piense en estos equipos de "color secundario" como roles dedicados a tiempo completo: estos colores secundarios son un concepto y una función de los miembros existentes.

Es más probable que haya “reuniones/ejercicios/compromisos” regulares y programados del equipo secundario y una política de puertas abiertas entre los grupos.

El objetivo es hacer que estos equipos principales, generalmente opuestos, trabajen juntos para lograr un objetivo común .

Daniel Miessler lo capta muy bien :

Piense en el Equipo Púrpura como un consejero matrimonial. Está bien que alguien actúe en ese rol para arreglar la comunicación, pero bajo ninguna circunstancia debe decidir que la nueva forma permanente para que ambos se comuniquen sea a través de un mediador.

Equipo Púrpura — Maximizar Rojo. Mejorar azul.

El objetivo principal de un Equipo Púrpura es maximizar los resultados de los enfrentamientos del Equipo Rojo y mejorar la capacidad del Equipo Azul.

En realidad, se trata de un equipo ya establecido, o que se expande fácilmente, dentro de muchas organizaciones maduras en seguridad. Hemos aprendido por experiencia que el negocio funciona mejor cuando los equipos rojo y azul trabajan juntos para mejorar la postura de seguridad de la organización. Ya existen muchos Equipos Púrpura y personas que declaran felizmente su solidaridad con el Equipo Púrpura.

Porque conocer tanto el ataque como la defensa es un gran activo para cualquier organización, equipo e individuo.

Equipo naranja: codificadores inspiradores con atacantes

La razón de muchos errores de seguridad dentro del software no son los programadores maliciosos, sino la falta de conciencia de seguridad dentro de los equipos y arquitectos de desarrollo de software.

El propósito del Equipo Naranja es inspirar al Equipo Amarillo a ser más consciente de la seguridad, aumentando su conciencia de seguridad al brindar educación para beneficiar el código de software y la implementación del diseño. Debe haber compromisos estructurados y continuos entre el equipo rojo y amarillo en beneficio del amarillo.

Quiere que su equipo naranja enseñe a sus desarrolladores a pensar como atacantes

Me uní a la industria de la seguridad como "Instructor de seguridad para desarrolladores", enseñando a los codificadores cómo los atacantes ingresan a las redes y aplicaciones. Según mi experiencia impartiendo cursos de piratería ética y cursos de codificación segura, los desarrolladores no responden positivamente a una lista de vulnerabilidades, pero les ENCANTA aprender a pensar como un atacante.

El equipo amarillo quiere ver y comprender cómo funciona la herramienta/automatización de ataque, y les encanta lo inteligente que puede ser un ataque. Las técnicas que aprenden tienden a ser más inteligentes, insidiosas o fácilmente disponibles de lo que inicialmente se dieron cuenta.

Entonces, un desarrollador, en su cerebro, comenzará a internalizar cómo hacer que sus aplicaciones sean resistentes a este tipo de ataques. Comienzan a comprender no solo los "casos de uso", sino también los " casos de uso indebido" y los "casos de abuso".

Desarrollan e inspiran un pensamiento crítico ofensivo en Yellow Team y en ellos mismos, que es el objetivo: esto ayuda a evitar que se introduzcan errores de seguridad en primer lugar, ya que se convierte en una parte intrínseca de cómo desarrollan y diseñan soluciones.

¿Cómo está aprendiendo seguridad el equipo amarillo sin la ayuda de un equipo naranja?

Buena pregunta. Ciertamente no están leyendo sobre eso. El equipo amarillo está demasiado ocupado con sus propias actualizaciones de herramientas de software. Su primera experiencia suele ser, un día, reciben un informe de prueba de penetración con una lista de vulnerabilidades, luego buscan en Google cuáles son, cambian una o dos líneas de código o configuración y vuelven a su trabajo real (que no es seguridad). ).

Hacer que los constructores entiendan cómo funcionan los ataques y por qué quieren codificar de forma segura es significativamente más efectivo que darles una hoja de cálculo con los hallazgos de vulnerabilidad de una prueba de penetración.

Cuando le da a un desarrollador una lista de verificación de errores de seguridad para corregir, básicamente le está diciendo que su trabajo está mal, después de que le hayan dicho que estaba bien. A nadie le gusta que le digan que su arte está mal, lo que le da más trabajo y hace que todos se sientan molestos con la seguridad por arruinar los horarios y retrasar los plazos . Esto solo crea conflicto.

Tradicionalmente, excluimos a los constructores de la seguridad de la información, pero los regañamos después de una prueba de penetración o una infracción por no saber cosas que cambian constantemente y son difíciles de mantener, ¡incluso para los profesionales experimentados de InfoSec!

Todo está siempre en llamas en InfoSec, puede ser bastante abrumador para alguien que no esté familiarizado con el campo.

Algunas reflexiones sobre la creación de un equipo naranja

Como mencioné anteriormente, no creo que haya un equipo naranja de tiempo completo, aunque puede depender del tamaño de la organización. Algunas organizaciones ya tienen "Campeones de Concientización sobre Seguridad", y creo que el Equipo Naranja es similar a ese rol.

Dado que el objetivo del Equipo Naranja es hacer que los desarrolladores piensen más como atacantes, lo más probable es que ciertos miembros del Equipo Rojo estén disponibles para el Equipo Amarillo. Trabajar con los desarrolladores para comprender cómo funcionan los atacantes será el primer paso.

Los miembros del Equipo Naranja son altamente técnicos y están "en la maleza" . Alguien que pueda hablar código y hablar métodos de ataque y entender esto fundamentalmente y desde una perspectiva de implementación.

Traer a un miembro del equipo rojo o naranja al comienzo de un sprint de software permite que se desarrollen "Historias de abuso" y "Casos de uso indebido" adicionales junto con las "Historias de usuario" y los "casos de uso" habituales del equipo que el Equipo amarillo normalmente haría. confiar para hacer características. Probablemente usando algún tipo de modelo de riesgo/amenaza como STRIDE

Esto le da al Equipo Amarillo retroalimentación inmediata sobre las áreas que necesitan proteger antes de escribir una sola línea de código.

Tiempo dedicado a la formación. Amarillo cómo opera el Equipo Rojo, o incluso solo sesiones de aprendizaje a la hora del almuerzo para ayudar a fomentar las conversaciones, también es una excelente manera de involucrar al Equipo Amarillo para que piense de manera más segura. Fomentar una puerta abierta o un punto de contacto específico también es una excelente manera de cerrar la brecha entre amarillo y rojo.

Si un desarrollador puede comprender una falla de seguridad, puede reconocer la misma falla de seguridad que programó en un proyecto separado que no fue probado por los atacantes, y las fallas de seguridad comienzan a corregirse de manera proactiva .

(En la foto de arriba ^^ Yo. Tantas veces.)

Una vez que Orange comience a tener más creadores de software en su equipo, también pueden estar en puestos de revisión de código para verificar las actualizaciones de código de otros miembros del equipo amarillo que detectan fallas antes de que se confirmen, o en puestos de diseño de arquitectura para garantizar que se tomen las decisiones correctas. hecho al comienzo del proyecto, y no al final después de la prueba.

Con suerte, el resultado final debería ser mejores codificadores entrenados por los atacantes, quienes luego se capacitan entre sí para fomentar una cultura de seguridad entre los desarrolladores.

Green Team: mejora la defensa con programadores

Blue Team no siempre está al tanto de todos los marcos, bibliotecas, sistemas de terceros, llamadas de red y funcionalidades agregadas por Yellow Team. Es posible que Yellow Team apenas sea consciente de algunas de las dependencias detrás de su propio código .

Pregúntele a cualquier codificador que use Node qué hacen sus más de 80 dependencias. De manera sigilosa, podría "enviar un corazón" a un tweet aleatorio de HotPockets . Podría robar bitcoins o contraseñas de desarrollador . Y más ¡Estos son casos reales en bibliotecas muy populares!

En el caso de un incidente, es posible que Blue Team no tenga los datos necesarios para investigar o defender los sistemas violados y nadie quiera probar o tocar el entorno de producción por temor a que se rompa.

El Equipo Verde consta de interacciones estructuradas continuas entre el Equipo Azul y los miembros del equipo de software (Equipo Amarillo). El objetivo final es mejorar la capacidad de defensa basada en código y diseño para detección, respuesta a incidentes y análisis forense de datos.

El equipo amarillo sabe cómo configurar sistemas y codificar. El Equipo Verde trabajará junto con el Equipo Azul o el Equipo Púrpura y discutirá soluciones y mejoras para:

• Salida DFIR
• Mejoras en el registro
• Registrar contenido/eventos
• Estandarización de la generación de registros
• Gestión del cambio
• Monitoreo de integridad
• Protección antivirus/punto final
• Monitoreo de cobertura total

Con Yellow Team trabajando con Blue Team, detectar un evento antes de que se convierta en un incidente, antes de que se convierta en una infracción, es esencial para la defensa de cualquier organización.

¿Cómo está haciendo esto actualmente el Equipo Azul sin la ayuda de un Equipo Verde?

Con mucha dificultad (o por mandato de la dirección). Sin embargo, inyectan requisitos de seguridad y monitoreo en los proyectos, lo que a su vez aumenta los plazos y los presupuestos, que tienden a clasificarse como requisitos no esenciales para el lanzamiento.

Alternativamente, tienen que pedir, rogar y presionar para mejorar el monitoreo una vez que el sistema de producción está activo, lo que obliga a duplicar la cantidad de trabajo para agregar mejoras al final del ciclo de vida del desarrollo.

Ignorar el monitoreo es una práctica de riesgo medio a alto que las empresas realizan todos los días y ahora OWASP la considera una de las vulnerabilidades de aplicaciones web más comunes.

Constantemente hablo de incorporar la seguridad al comienzo del ciclo de vida de desarrollo de software (SDLC) y tener un equipo verde ayudaría a cumplir con este requisito. Presentar el caso al comienzo de un proyecto y durante el desarrollo de las mejoras de monitoreo, las mejoras de registro y el monitoreo de integridad que se integran con los sistemas Blue Team es vital para la visibilidad de la seguridad de una organización.

Como se muestra en el diagrama anterior, un error encontrado en los requisitos es significativamente más económico que una infracción en la producción.

Fuente: Facultad de Gestión de Sistemas de Defensa, 1993.
Sigue siendo muy relevante hoy en día.

Algunas reflexiones sobre la creación de un Equipo Verde

Creo que tener un miembro del Blue Team, con suerte con alguna habilidad de creación de scripts, presente al comienzo del proceso SDLC o Sprint es un buen primer paso. Este nuevo miembro verde escuchará los casos de uso del Sprint, comprenderá la infraestructura que se usa, las diferentes integraciones que podrían ser necesarias, escuchará posibles casos de uso indebido del equipo naranja y comprenderá si hay algo que pueda ser monitoreado desde una defensa. perspectiva.

También pueden dar consejos tempranos sobre cómo proteger o detectar mejor una amenaza o vulnerabilidad de la que el Equipo Amarillo no deba preocuparse.

(Blue tiende a conocer la forma mejor y más rápida de asegurar algo)

El otro lado de Green Team está ayudando a Blue con la automatización; haga que un miembro del equipo amarillo siga las operaciones azules, comprenda cómo funcionan y dónde podrían tener algunos desafíos que se pueden solucionar con procesos automatizados.

Un miembro del equipo amarillo o verde podría mejorar las defensas de Blue a través de adiciones de código relativamente simples o ayudando a exigir estándares de registro dentro de un proyecto.

Puede ser mucho más fácil determinar qué es fácil o difícil de automatizar si alguien es un desarrollador y tiene visibilidad dentro del código de un proyecto.

Green Team podría integrar las pruebas de seguridad automatizadas (¡una de mis especialidades!) en un flujo de trabajo de prueba de código normal. Entonces, cuando Yellow Team confirma el código y ejecuta casos de prueba automatizados, también ejecutan casos de prueba de seguridad automatizados, lo que facilita el trabajo de Blue y Yellow.

Los dos lados de Green Team están mejorando las habilidades de Blue para realizar monitoreo y análisis forense , al mismo tiempo que alientan a Yellow a considerar el mantenimiento de defensa a largo plazo de la aplicación.

El resultado final tiene muchos beneficios que ayudan a la organización en su conjunto.

La primera es una cultura de desarrolladores que desean integrar su trabajo en el tejido de seguridad de una organización y comprender cómo pueden beneficiarse de las protecciones intrínsecas de esos defensores.

El segundo es un control de salud de las operaciones azules y el ahorro de horas, días, semanas, meses de tiempo a través de la automatización simple, informes y estandarizaciones que solo puede realizar un equipo amarillo.

Equipo Blanco: uniendo todos los colores.

Al final del día, la seguridad de la información está dictada por p̶e̶r̶f̶e̶c̶t̶ ̶s̶e̶c̶u̶r̶i̶t̶y̶ ̶r̶e̶q̶u̶i̶r̶e̶m̶e̶n̶t̶s̶ requisitos de gobierno, cumplimiento, políticas y negocios.

Los miembros del Equipo Blanco incluyen elementos de Cumplimiento, Gestión, Analistas, Logística y más. Se trata de terceros que lo saben todo, son neutrales y establecen las reglas de participación, organizan equipos, establecen estrategias, realizan evaluaciones de riesgos y establecen planes y monitorean el progreso.

Son esenciales para todas las organizaciones, pero se consideran " demasiado corporativos " para los desarrolladores, " demasiado exigentes " para los defensores y " demasiado aguafiestas " para los atacantes.

Dado que el equipo blanco no tiende a ser técnico de la misma manera que nuestros equipos de colores primarios, las conversaciones entre estos dos grupos tienden a ser más antagónicas, ya que cada lado intenta transmitir el punto de vista y los requisitos del otro.

^^ Intentar que todos estén en la misma página de alto nivel puede ser difícil para el Equipo Blanco.

El equipo blanco es tan esencial como los constructores, los atacantes y los defensores. El Equipo Blanco engloba y gestiona todos los colores, sin ser directamente uno de ellos.

Entonces, aunque tienen que estar en muchas áreas organizacionales a un alto nivel, tienden a entrar en conflicto cuando interactúan directamente con un color primario.

Hacer que el equipo blanco interactúe con un equipo de color secundario disminuirá el conflicto, ya que los colores secundarios entienden el idioma de los colores primarios de los que provienen, pero están "más cerca del blanco" y entienden varias piezas del rompecabezas de seguridad.

Rainbow Team — Todo lo anterior

Así que presenté este concepto de rueda de colores a algunos de mis amigos rockstar de seguridad (personas mucho más inteligentes que yo con un mínimo de 10 años de experiencia en seguridad, organizan eventos, comunidades, etc.) y muchos se identificaron con todos los colores y se declararon como Rainbow Team.

Han realizado codificación , han realizado capacitación , han realizado ataques , han implementado sistemas defensivos y han auditado y diseñado para el cumplimiento y la regulación .

Tener una comprensión de espectro completo podría ser el camino o la meta final para una persona apasionada por la seguridad.

O tal vez algunas personas prefieran especializarse. Creo que descubriremos en las próximas décadas cómo se desarrolla esto. Veo que algunas personas prefieren especializarse, pero en algún momento todos los equipos tienen un límite estricto para lo que pueden lograr solos.

Uno de mis mejores comentarios hasta ahora sugiere que se supone que los ingenieros de sistemas son el pegamento entre todos los colores y el blanco, y que los problemas que enfrentan el rojo y el azul se deben a la falta de ingenieros de sistemas.

Seguimiento, documentación, verificación y gestión de las diversas interacciones entre rojo, azul y amarillo. Los ingenieros de sistemas son integradores técnicos que son multidisciplinarios.

Si bien no estoy en desacuerdo y no estoy sugiriendo que este modelo sea un reemplazo para los ingenieros de sistemas, creo que esta es una excelente manera de ver cómo podemos incluir a los desarrolladores de software para que trabajen con la seguridad y ayuden a mantener segura a la organización. Muy feliz de que los ingenieros de sistemas sean el pegamento, pero también me gustaría que los desarrolladores fueran capacitados por Red y que los desarrolladores ayudaran a Blue.

¿Qué hacer a continuación?

Me gusta mucho Infosec Color Wheel, y los primeros comentarios han demostrado que ya está ayudando a los equipos de seguridad a comprender cómo interactuar con los equipos de desarrollo y dónde se sientan ciertos profesionales de seguridad dentro de su propia organización como uno de los nuevos colores naranja/verde.

¿Tienes algunos pensamientos? ¿Me he perdido algo? Los comentarios son muy bienvenidos 😊. Me gusta mejorar los artículos, por lo que este puede cambiar ligeramente una vez que reciba comentarios adicionales.

Espero que hayas disfrutado del artículo. Aplaude el artículo si te ha gustado. Puedes aplaudirlo 50 veces si realmente te gusta. También he incluido enlaces a las imágenes utilizadas en la parte inferior de la página. Envíame un mensaje privado si quieres acceder a los PSD.

Para leer más sobre este tema, recomiendo el artículo de April Wright, ya que entra en más detalles y habla sobre cómo implementar este concepto. Echa un vistazo a su video de Youtube y Podcast sobre el tema. También deberías seguirla en Twitter , es bastante genial.

Mientras estés en Twitter, sígueme @proxyblue . Tuiteo cosas de InfoSec.

Por mi parte, he sido una persona de seguridad durante más de 5 años, pero nunca encajé en el molde Azul/Rojo/Púrpura. Como miembro del #equiponaranja y del #equipoverde , ahora puedo ver dónde encajan mis habilidades en una organización, en lugar de solo ser contratado como contratista de vez en cuando.
Además, siempre es lindo estar incluido y tener un equipo 😊🧡💚

Si desea discutir y obtener más información, suelo pasar el rato en The Many Hats Club en Discord, el mejor Discord de InfoSec. Tenemos podcasts y muchos canales de discusión y preguntas. Actualmente, también somos los únicos con estado de socio de Discord. https://discord.gg/infosec

A medida que continúo mi viaje en InfoSec, estoy aprendiendo más habilidades Azul y Roja, así que espero estar en camino de ser el Equipo Arcoíris también. 🌈

Echa un vistazo a mis otras publicaciones populares. En realidad, todos son muy del Equipo Naranja, es bueno finalmente estar incluidos en el círculo de color de InfoSec 🧡💚

10 cosas que los profesionales de InfoSec deben saber sobre redes

Usted 'hace' InfoSec, ¿verdad? ¿Que lees? A quien escuchas?

Lo que los desarrolladores deben saber sobre codificación/cifrado/hashing/salado/estiramiento

Después de escanear más de un millón de aplicaciones: 3 cosas que los desarrolladores de aplicaciones móviles deben saber sobre la seguridad de las aplicaciones

Enlaces útiles a los gráficos de la rueda de colores

https://goto.louis.land/infosec-wheel-pngs-zip

Gracias por leer la palabra “equipo” 120 veces

Gracias a todos mis lectores de prueba. Este artículo no sería lo mismo sin ustedes, gente increíble.