Apresentando a roda de cores InfoSec — misturando desenvolvedores com equipes de segurança vermelhas e azuis.
Como um desenvolvedor que virou pessoa de segurança, aprendi em primeira mão como é importante para todas as equipes trabalharem juntas, mais do que apenas DevSecOps. É hora de incluir e misturar desenvolvedores em nosso círculo Infosec.
Estado atual de Segurança da Informação — Equipes Vermelhas e Azuis
No domínio da segurança da informação, tendem a haver dois grupos principais:
- A Equipe Vermelha, funcionários ou empreiteiros contratados para serem Atacantes, hackers éticos que trabalham para uma organização encontrando falhas de segurança que um indivíduo mal-intencionado poderia explorar.
- A Equipe Azul, os Defensores da organização, que são responsáveis por medidas de proteção dentro de uma organização.
Estado atual de segurança. Equipes Vermelhas e Azuis
Embora seja bom ter pessoas dedicadas a garantir uma organização através de métodos de defesa ou ataque, as organizações e seus sistemas não permanecem estáticos. Processos adicionais, automações, produtos e sendo construídos por desenvolvedores e arquitetos constantemente — com a potencial área de superfície de ataque crescendo a cada nova mudança ou integração.
Só ter equipes de segurança vermelhas e azuis não é suficiente. As pessoas que constroem o que deve ser defendido precisam ser incluídas.
Apresentando a Equipe Amarela — Os Construtores
Equipe Amarela — Construtores
Desenvolvedores de aplicativos, engenheiros de software e arquitetos se enquadram nessa categoria.
Essas são as pessoas que constroem e projetam softwares, sistemas e integrações que tornam as empresas mais eficientes.
Seu foco geralmente está em requisitos, funcionalidade, experiência do usuário e desempenho back-end.
Se queremos ter aplicativos, automações e processos projetados e implementados com segurança, a Equipe Vermelha e a Equipe Azul precisam trabalhar com os Construtores. Os construtores precisam ser incluídos como parte da Segurança da Informação.
Amarelo precisa fazer parte da equipe. Só podemos fazer isso trabalhando juntos.
No ano passado, April Wright desenvolveu uma solução em sua palestra blackhat intitulada “Orange is the new Purple” (Versão Gravada de DefCamp) e ela prega totalmente como construtores/atacantes/defensores são todos uma equipe do InfoSec. Parte do conteúdo abaixo é diretamente de seu trabalho de submissão.
Precisamos fazer construtores “A Equipe Amarela” e lhes dá a capacidade de tornar suas aplicações mais seguras.
O foco de um desenvolvedor é a funcionalidade e torná-lo o mais funcional possível. Uma vez que a funcionalidade de um aplicativo funcione para todos os usuários e partes interessadas, seus desenvolvedores dormirão tranquilos porque fizeram seu trabalho perfeitamente.
Os desenvolvedores nunca sabem, ou realmente pensam, se fizeram algo de forma insegura — até que seja apontado para eles como parte de um teste de penetração conduzido pela Red Team, ou como parte de uma brecha descoberta pela Equipe Azul (tendo em mente que dois terços das violações levam meses ou mais para descobrir).
Mas, estamos construindo software mais rápido do que pode ser testado e defendido de segurança.
Nós colocamos a responsabilidade de segurança em programadores, que não têm a experiência de segurança.
Nossa indústria de segurança e organizações são atormentadas por vulnerabilidades e configurações erradas e todas elas têm a mesma fonte. A pessoa ou grupo que a construiu. Como diz o ditado:
Se a depuração é o processo de remoção de bugs, então a programação é o processo de colocar bugs no aplicativo. Os testes só comprovam a presença de insetos, não a ausência deles.
Para ajudar a resolver isso, as organizações atualmente têm um ciclo:
Amarelo constrói. Vermelho Quebra. Azul defende isso. Amarelo Conserta isso.
Bem, essa é a teoria. Na realidade é:
Senhor? Senhor? Você está ouvindo? Senhor?
Amarelo constrói. Red Quebra. Blue reclama disso. Amarelo ignora isso. A gerência esconde isso.
Isso é o que nossa cultura atual de Segurança / Desenvolvimento tende a incentivar.
No entanto, nosso ciclo ideal funcionará melhor quando o Amarelo for educado com vermelho e trabalhar lado a lado com o Azul.
Amarelo precisa estar envolvido para garantir uma organização.
Como ajudar a Equipe Amarela a se tornar mais segura
A solução é educar a Equipe Amarela com técnicas de ataque, e usar os pontos fortes da Equipe Amarela para tornar a defesa mais fácil e visível.
Passei os últimos cinco anos trabalhando com a Blue Teams programando soluções de automação de segurança e otimizando como melhorar seus recursos de monitoramento e defesa. Se eu tivesse que me rotular no momento, eu sou provavelmente o que a indústria está tentando classificar como DevSecOps. Mas mais Dev e Sec do que Ops.
Nos últimos cinco anos, também dediquei muitas sessões de treinamento e cursos de hacking éticos para desenvolvedores e outros técnicos. Ensino-lhes como os atacantes invadem redes, infraestrutura e aplicativos — e como atenuá-lo com boas práticas de codificação e outras técnicas de defesa.
Como fazemos a ponte entre desenvolvedores e segurança?
Agora apresentamos nossa Equipe Amarela. Já temos nossa Equipe Vermelha e Equipe Azul.
Vermelho. Azul. Amarelo. Estas são nossas cores primárias.
Essas três equipes são necessárias para manter uma organização segura contra ameaças, tornando-as todas responsáveis pela segurança de uma organização.
Ataque e Defesa não podem fazer isso sozinhos. Codificadores não podem fazer isso sozinhos. Todos precisam trabalhar juntos.
Individualmente, eles não têm as habilidades ou visibilidade para proteger uma organização.
Apresentando a roda de cores InfoSec
Se vermelho, azul e amarelo são nossas cores primárias, podemos misturar suas habilidades para criar equipes secundárias que combinam as habilidades e pontos fortes de duas equipes primárias
Vermelho, Azul e Amarelo são nossas cores primárias. Combine dois deles e você tem cores secundárias.
Esta Roda colorida InfoSec expande-se no incrível trabalho de April Wright de trazer construtores para a equipe de segurança, colocando-o em um único infográfico. (Zíper de imagem na parte inferior do artigo)
Como funciona?
Temos nossas Equipes Vermelha e Azul como sempre fizemos, mas agora com a introdução de uma Equipe Amarela, podemos ter equipes secundárias de cores (Laranja, Verde e Roxo) dedicadas à mistura de habilidades entre atacantes, defensores e codificadores — tornando o código mais seguro e a organização mais segura.
Gráfico secundário de criação de cores
Cores secundárias do InfoSec
A segurança não pode e não deve ser siloed, mas em muitos casos, desenvolvedores de software e segurança são atualmente segregados uns dos outros e do resto da organização.
As pessoas tendem a se especializar em uma cor primária, mas para uma organização ser segura, todas as cores devem ser fortes, mas devem trabalhar juntas e se misturar.
À medida que nos misturamos, essas equipes combinarão seus conhecimentos e capacidade para aprimorar e melhorar as outras equipes para tornar uma organização mais segura.
Não pense nessas equipes de “cor secundária” como papéis dedicados em tempo integral — essas cores secundárias são um conceito e função dos membros existentes.
É mais provável que haja “reuniões/compromissos” regulares e programados da equipe secundária e uma política de portas abertas entre os grupos. O objetivo é que essas equipes primárias geralmente opostas trabalhem juntas para alcançar um objetivo comum.
Daniel Miessler captura este poço:
Pense na Equipe Roxa como uma conselheira matrimonial. É bom ter alguém atuando nesse papel para corrigir a comunicação, mas sob nenhuma circunstância você deve decidir que a nova maneira permanente de ambos os parceiros se comunicarem é através de um mediador.
Purple Team — Maximise Red. Enhance Blue.
O objetivo principal de uma Equipe Roxa é maximizar os resultados dos compromissos da Equipe Vermelha e melhorar a capacidade da Equipe Azul.
Esta é, na verdade, uma equipe já estabelecida, ou facilmente girada, dentro de muitas organizações maduras de segurança. Aprendemos com a experiência que o negócio funciona melhor quando as Equipes Vermelha e Azul trabalham juntas para melhorar a postura de segurança da organização. Há muitas Equipes Roxas já existentes e pessoas felizes declarando sua solidariedade ao Time Roxo.
Porque conhecer tanto o ataque quanto a defesa é um grande trunfo para qualquer organização, equipe e indivíduo.
Orange Team — Codificadores inspiradores com atacantes
A razão para muitos bugs de segurança dentro do software não são programadores maliciosos, mas uma falta de consciência de segurança dentro de equipes de desenvolvimento de software e arquitetos.
O objetivo da Equipe Laranja é inspirar a Equipe Amarela a ser mais consciente da segurança, aumentando sua consciência de segurança, fornecendo educação para beneficiar o código de software e a implementação do design. Deve haver compromissos estruturados e contínuos entre a Equipe Vermelha e Amarela em benefício da Yellow.
Então você quer escrever código seguro…
Entrei para a indústria de segurança como um “Developer Security Trainer Guy”, ensinando codificadores como os atacantes invadem redes e aplicativos. Na minha experiência executando cursos de hacking éticos e cursos de codificação seguros, os desenvolvedores não respondem positivamente a uma lista de vulnerabilidades, mas adoram aprender a pensar como um atacante.
A Equipe Amarela quer ver e entender como a ferramenta de ataque/automação funciona, e eles adoram o quão inteligente um ataque pode ser. As técnicas que aprendem tendem a ser mais inteligentes, insidiosas ou facilmente disponíveis do que perceberam inicialmente.
Um desenvolvedor, então, em seu cérebro, começará a internalizar como tornar seus aplicativos resistentes a esses tipos de ataques. Eles começam a entender não apenas “casos de uso”, mas “casos de uso indevido” e “casos de abuso”.
Eles desenvolvem e inspiram o pensamento crítico ofensivo na Equipe Amarela e em si mesmos, que é o objetivo — isso ajuda a evitar que bugs de segurança sejam introduzidos em primeiro lugar, uma vez que se torna uma parte intrínseca de como eles desenvolvem e projetam soluções.
Como a Equipe Amarela está aprendendo segurança sem a ajuda de uma Equipe Laranja?
Boa pergunta. Eles certamente não estão lendo sobre isso. A Equipe Amarela está muito ocupada acompanhando suas próprias atualizações de ferramentas de software. Sua primeira experiência geralmente é, um dia, eles recebem um relatório de teste de penetração com uma lista de vulnerabilidades, depois google o que eles são, alterar uma linha ou duas de código ou configuração, e voltar para o seu trabalho real (que não é segurança).
Fazer com que os Construtores entendam como os ataques funcionam e por que eles querem codificar com segurança é significativamente mais eficaz do que dar-lhes uma planilha de achados de vulnerabilidade a partir de um teste de penetração.
Ao dar a um desenvolvedor uma lista de erros de segurança para corrigir, você está basicamente dizendo a eles que seu trabalho está errado, depois de ser dito que era certo. Ninguém gosta de saber que sua arte está errada, dando-lhes mais trabalho para fazer e fazendo com que todos se ressentem da segurança por arruinar horários e empurrar para trás cronogramas. Isso só cria conflito.
Tradicionalmente, excluímos construtores da Information Security, mas os repreendemos após um teste de penetração ou violação por não saberem coisas que mudam constantemente e é difícil acompanhar mesmo quando é nosso trabalho!
Muito difícil acompanhar o InfoSec, mesmo quando você está no InfoSec. Tudo está sempre queimando.
Alguns pensamentos sobre a criação de uma Equipe Laranja
Como mencionado anteriormente, não acho que haverá uma Equipe Laranja em tempo integral, embora possa depender do tamanho de uma organização. Algumas organizações já têm “Campeões de Conscientização de Segurança”, e eu sinto que orange team é semelhante a esse papel.
Uma vez que o objetivo da Orange é fazer os desenvolvedores pensarem mais como atacantes, provavelmente começará com certos membros da Equipe Vermelha disponíveis para a Equipe Amarela. Trabalhar com desenvolvedores para entender como os atacantes funcionam será o primeiro passo.
Os membros da Equipe Laranja são altamente técnicos e “in-the-weeds”. Alguém que pode falar código, e falar métodos de ataque e entender isso fundamentalmente e de uma perspectiva de implementação.
Trazer um membro da Equipe Vermelha ou Laranja no início de um sprint de software permite que “Histórias de Abuso” e “casos de uso errado” sejam desenvolvidos ao lado dos “Histórias de Usuário” usuais da equipe e “casos de uso” que a Equipe Amarela normalmente confiaria para fazer recursos. Isso dá ao Yellow Team feedback imediato sobre as áreas que eles precisam proteger antes de escrever uma única linha de código.
O tempo dedicado ao treinamento amarelo como a Equipe Vermelha opera, ou mesmo apenas sessões de aprendizado na hora do almoço para ajudar a incentivar conversas também é uma ótima maneira de envolver a Equipe Amarela a pensar com mais segurança. Encorajar um ponto de contato de porta aberta ou específico também é uma ótima maneira de fazer a ponte entre amarelo e vermelho.
Se um desenvolvedor pode entender uma falha de segurança, ele pode reconhecer a mesma falha de segurança que programaram em um projeto separado que não foi testado pelos atacantes — e falhas de segurança começam a se fixar proativamente.
Na foto acima ^^ mim. Tantas vezes.
Uma vez que a Orange comece a ter mais construtores de software em sua equipe, eles também podem estar em posições para revisões de código para verificar outras atualizações de código de membros da Equipe Amarela capturando falhas antes de serem comprometidas, ou em posições de design de arquitetura para garantir que as decisões certas sejam tomadas no início do projeto, e não no final após os testes.
O resultado final deve ser, esperançosamente, melhores codificadores treinados por atacantes, que então treinam uns aos outros para incentivar uma cultura de segurança entre os desenvolvedores.
Equipe Verde — Melhore a defesa com codificadores
A Equipe Azul nem sempre está ciente de todas as estruturas, bibliotecas, sistemas de terceiros, chamadas de rede e funcionalidade adicionadas pela Equipe Amarela. A Equipe Amarela pode mal estar ciente de algumas das dependências por trás de seu próprio código.
Pergunte a qualquer codificador usando o Node o que suas mais de 80 dependências fazem. Furtivamente, pode “coração” um tweet aleatório hotpockets. Pode roubar senhas de bitcoin ou desenvolvedor. E mais. Estes são casos reais em bibliotecas muito populares!
No caso de um incidente, a Equipe Azul pode não ter os dados necessários para investigar ou defender sistemas violados e ninguém quer testar ou tocar no ambiente de produção por medo de quebrar.
A Equipe Verde consiste em interações estruturadas contínuas entre a Equipe Azul e membros da equipe de software (Equipe Amarela). O objetivo final é melhorar a capacidade de defesa baseada em códigos e design para detecção, resposta a incidentes e perícia de dados.
A Equipe Amarela sabe como configurar sistemas e códigos. A Equipe Verde trabalhará em conjunto com a Equipe Azul ou a Equipe Roxa e discutirá soluções e melhorias para:
- Saída DFIR
- Melhorias no registro
- Registrar conteúdo/eventos
- Padronização da geração de log
- Gestão de Mudanças
- Monitoramento de integridade
- Proteção antivírus / ponto final
- Monitoramento completo da cobertura
Com a Equipe Amarela trabalhando com a Equipe Azul, pegar um evento antes que se torne um incidente, antes que se torne uma brecha, é essencial para a defesa de qualquer organização.
Detectado e preso. Azul e Amarelo juntos são difíceis de romper
Como a Equipe Azul está fazendo isso sem a ajuda de uma Equipe Verde?
Com grande dificuldade (ou mandato da gestão). Eles injetam requisitos de segurança e monitoramento em projetos, porém, que, por sua vez, aumentam prazos e orçamentos, que tendem a se classificar como requisitos não essenciais para o lançamento.
Alternativamente, eles têm que pedir e implorar e pressionar por melhorias de monitoramento uma vez que um sistema de produção está ao vivo, forçando o dobro da quantidade de trabalho para adicionar melhorias no final do ciclo de vida do desenvolvimento.
Ignorar o monitoramento é uma prática de médio a alto risco que as empresas estão fazendo todos os dias e agora é considerada uma das vulnerabilidades mais comuns do aplicativo web pelo OWASP.
Falo constantemente em trazer segurança no início do Ciclo de Vida de Desenvolvimento de Software (SDLC) e ter uma Equipe Verde ajudaria a cumprir esse requisito. Fazer o caso no início de um projeto, e durante o desenvolvimento para monitoramento de melhorias, melhorias de registro, monitoramento de integridade que se integram com sistemas blue team é vital para a visibilidade de segurança de uma organização.
Um bug encontrado nos requisitos é significativamente mais barato do que uma brecha na produção. Fonte: Defense Systems Management College, 1993. Ainda é muito relevante hoje.
Alguns pensamentos sobre a criação de uma Equipe Verde
Eu acho que ter um membro da Equipe Azul, espero que com alguma habilidade de script, presente no início do processo SDLC ou Sprint é um bom primeiro passo. Este novo membro verde vai começar a ouvir os casos de uso do Sprint, entender a infraestrutura que está sendo usada, diferentes integrações que podem ser necessárias, ouvir casos de uso indevido potencial da Orange Team — e entender se há algo que pode ser monitorado do ponto de vista da defesa. Eles também podem dar dicas antecipadas de como proteger algo facilmente com o qual a Equipe Amarela pode não precisar se preocupar.
Azul tendem a saber a melhor e mais rápida maneira de garantir algo
O outro lado da Equipe Verde está ajudando a Blue com automação; ter um membro da Equipe Amarela sombra Operações Azul, entender como eles funcionam, e onde eles podem ter alguns desafios que podem ser corrigidos com processos automatizados. Um membro da Equipe Amarela ou Verde pode ser capaz de melhorar as defesas da Blue através de adições de código relativamente simples ou padronizações de registro dentro de um projeto.
Pode ser muito mais fácil determinar o que é fácil ou difícil de automatizar se alguém é um desenvolvedor e tem visibilidade dentro do código de um projeto.
A Equipe Verde pode ser capaz de integrar testes automatizados de segurança (uma das minhas especialidades!) em um fluxo de trabalho normal de teste de código. Assim, quando a Equipe Amarela comete código e executa casos de teste automatizados, eles também executam casos automatizados de teste de segurança também, facilitando o trabalho da Blue e Yellow.
Os dois lados da Equipe Verde estão melhorando as habilidades da Blue para realizar monitoramento e perícia, ao mesmo tempo em que encoraja a Yellow a considerar a manutenção de defesa a longo prazo da aplicação.
O resultado final tem muitos benefícios que ajudam a organização como um todo.
A primeira é uma cultura de desenvolvedores que querem integrar seu trabalho no tecido de segurança de uma organização e entender como eles podem se beneficiar das proteções intrínsecas desses defensores.
A segunda é uma verificação de saúde das operações Blue e horas de poupança, dias, semanas, meses de tempo através de automação simples, relatórios e padronizações apenas factíveis por uma Equipe Amarela.
Equipe Branca — reunindo todas as cores.
No final do dia, a Segurança da Informação é ditada 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̶ governança, conformidade, política e requisitos de negócios.
Por favor, alguém me envie uma imagem melhor para mostrar o Gerenciamento de Segurança da Informação. Meu Google-fu falhou comigo.
Os membros da White Team incluem elementos de Compliance, Gestão, Analistas, Logística e muito mais. São indivíduos de terceiros, que definem as regras de engajamento, organizam equipes, fazem planos e monitoram o progresso.
Eles são essenciais para todas as organizações, mas são vistos como “corporativos demais” para os desenvolvedores, “muito exigentes” para os defensores e “muito killjoy” para os atacantes.
Como a Equipe Branca não tende a ser técnica da mesma forma que nossas equipes de cores primárias, as conversas entre esses dois grupos tendem a ser mais contraditórias, cada lado tentando atravessar o ponto de vista do outro e os requisitos ouvidos.
A vida é difícil para a Equipe Branca
Mas a Equipe Branca é tão essencial quanto construtores, atacantes e defensores. Equipe Branca engloba, e gerencia todas as cores, sem ser diretamente uma delas.
Assim, embora eles tenham que estar em muitas áreas organizacionais em alto nível, eles tendem a entrar em conflito quando interagem diretamente com uma cor primária.
Ter a Equipe Branca interagindo com uma equipe de cores secundárias diminuirá o conflito, uma vez que as cores secundárias entendem a linguagem das cores primárias de onde vêm, mas estão “mais perto do branco” e entendem várias peças do quebra-cabeça de segurança.
Rainbow Team — Tudo isso
Então eu coloquei este conceito roda de cor para alguns dos meus amigos rockstar de segurança (pessoas muito mais inteligentes do que eu com experiência mínima de segurança de 10 anos, executar eventos, comunidades etc) e muitos se identificaram com todas as cores e se declararam como um Time arco-íris.
Eles fizeram codificação, fizeram treinamento, realizaram ataques, implementaram sistemas defensivos, e auditaram e projetaram para conformidade e regulação.
Ter uma compreensão completa do espectro pode ser o caminho ou objetivo final para uma pessoa de segurança apaixonada.
Ou talvez algumas pessoas prefiram se especializar. Acho que vamos descobrir nas próximas décadas como isso vai acabar. Eu vejo algumas pessoas preferindo se especializar, mas em algum momento todas as equipes têm um limite difícil para o que podem alcançar sozinhos.
Uma das minhas melhores peças de feedback até agora sugere que os Engenheiros de Sistema deveriam ser a cola entre todas as cores e branco — e que os problemas que a Vermelho e o Azul estão enfrentando são devido à falta de Engenheiros de Sistema.
Rastreamento, documentação, verificação e gerenciamento das diversas interações entre vermelho, azul e amarelo. Os engenheiros de sistemas são integradores técnicos que são multidisciplinados.
Embora eu não discorde e não esteja sugerindo que este modelo seja um substituto para os Engenheiros de Sistemas, acredito que esta é uma ótima maneira de ver como podemos incluir os Construtores de Software para trabalhar com segurança para ajudar a manter a organização segura. Muito feliz para os Engenheiros de Sistema serem a cola, mas também gostaria de ter desenvolvedores treinados pela Red e ter desenvolvedores ajudar blue.
O que fazer agora?
Eu realmente gosto da Roda de Cores Infosec, e o feedback inicial mostrou que já está ajudando as equipes de segurança a entender como interagir com as equipes de desenvolvimento, e onde certos profissionais de segurança agora se sentam dentro de sua própria organização como uma das novas cores Laranja/Verde.
Tem alguns pensamentos? Perdi alguma coisa? Feedback é muito bem-vindo 😊 . Eu gosto de melhorar os artigos, então este pode mudar um pouco quando eu receber algum feedback adicional.
Espero que tenha gostado do artigo. Bata palmas para o artigo se você gostou. Você pode bater palmas 50 vezes se você realmente gosta. Também incluí links para as fotos usadas na parte inferior da página. DM me se você quiser acesso a PSDs.
Para mais leitura sobre este tema, recomendo o artigo de April Wright à medida que ela entra em mais detalhes e fala sobre como implementar esse conceito. Confira o vídeo do Youtube e podcast sobre o tema. Você deve segui-la no Twitter também - ela é bem radical.
Enquanto estiver no twitter, siga-me @proxyblue. Eu twitto coisas do InfoSec.
Para mim, sou segurança há mais de 5 anos, mas nunca me encaixo no molde Azul/Vermelho/Roxo. Como #orangeTeam #greenTeam pessoa, agora posso ver onde minhas habilidades se encaixam em uma organização, em vez de apenas ser trazido como um empreiteiro de tempos em tempos.
Além disso, é sempre bom ser incluído e ter uma equipe 😊🧡💚
Se você quiser discutir e aprender mais, eu regularmente fico no The Many Hats Club on Discord, o melhor InfoSec Discord. Temos podcasts e muitos canais para discussão e perguntas. Nós também somos atualmente o único com status de parceiro discord. https://discord.gg/infosec
Enquanto continuo minha jornada no InfoSec, estou aprendendo mais habilidades azuis e vermelhas, então espero estar a caminho de ser o Time arco-íris também. 🌈
Links úteis para gráficos de rodas coloridas https://goto.louis.land/infosec-wheel-pngs-zip
Obrigado por ler a palavra “equipe” 120 vezes
Autor: Louis Cremen