Guardian360
Começar teste gratuitoTorna-te parceiro
← Todos os artigos

Opinião

Yellow Teaming: palavra da moda ou ponto de rutura?

Por Jan Martijn Broekhof ·

Nunca tinha ouvido o termo “Yellow Team” até ler um artigo recente da Dark Reading sobre IA e segurança. Ao fim do segundo parágrafo, apercebi-me de algo ligeiramente incómodo: a Guardian360 tem sido discretamente uma, há anos, e ninguém, eu incluído, alguma vez se deu ao trabalho de lhe chamar isso.

Durante muito tempo, isso pouco importou. Construir as ferramentas que as equipas Red e Blue usam era visto como trabalho de commodity: necessário, sem glamour, raramente tema de uma palestra numa conferência. Os atacantes ficavam com o drama. Os defensores ficavam com o mérito de aguentar a linha. As pessoas que construíam as plataformas por baixo de ambos ficavam com uma rubrica no orçamento. A IA está a mudar esse cálculo, e vale a pena perceber porquê, e o que isso significa para a forma como a Guardian360 trabalha com os seus parceiros.

Afinal, o que são as equipas Red, Blue e Yellow, e onde encaixa o DevSecOps?

O vocabulário de cores na cibersegurança é mais antigo do que a maioria das pessoas imagina. Red Team refere-se às pessoas que simulam ataques: os pentesters, os hackers éticos, aqueles que são pagos para entrar antes que alguém com piores intenções o faça. Blue Team refere-se aos defensores: os analistas e engenheiros que detetam, respondem e recuperam desses ataques. A Yellow Team fica por baixo de ambas. É o grupo que concebe, constrói e mantém os sistemas, aplicações e ferramentas com que, e sobre os quais, a Red e a Blue realmente operam.

Esta distinção foi proposta pela primeira vez na Black Hat em 2017, quando foi introduzida uma roda de cores para mapear as diferentes funções dentro do trabalho de segurança para além do familiar enquadramento red-contra-blue, como os investigadores de segurança da Retest Security documentaram desde então na sua própria história do modelo. O amarelo foi definido como os construtores: arquitetos, programadores e engenheiros responsáveis por sistemas seguros de raiz, e não as pessoas que os atacam ou defendem depois de estarem feitos.

O DevSecOps não é uma cor separada nessa roda. É a prática que as Yellow Teams usam para fazer o seu trabalho: integrar a segurança no próprio pipeline de desenvolvimento, para que as vulnerabilidades sejam apanhadas no ponto de criação, em vez de descobertas mais tarde pela Red ou limpas mais tarde pela Blue. O DevSecOps é o método. A Yellow Team é o grupo de pessoas que o aplica.

Apenas DevSecOps com uma nova mão de tinta?

Um cético justo travava-me aqui. Se a Yellow Team são simplesmente as pessoas a fazer DevSecOps, o que mudou de facto? As organizações têm engenheiros de desenvolvimento seguro há uma década. Chamar-lhes “amarelos” não torna o trabalho novo.

Esse ceticismo merece uma resposta honesta, e a resposta honesta é: por si só, o rótulo seria de facto vinho velho em garrafa nova. O que torna este momento diferente não é o nome, é a escala daquilo para que as Yellow Teams estão agora a ser chamadas a construir. Modelos de IA de fronteira, como o Claude Mythos e o GPT-5.5, conseguem encontrar e encadear vulnerabilidades de software mais depressa do que quase qualquer equipa humana, e as organizações estão apenas a começar a perceber como apontar essa capacidade numa direção útil, em vez de caótica. Esse apontar, afinal, é trabalho de Yellow Team, e não se parece em nada com escrever checklists de revisão de código seguro.

Porque a IA acabou de mudar as contas para os construtores

Segundo o que a Dark Reading noticia, engenheiros de empresas como a Cisco, a Microsoft, a Cloudflare e a Netskope estão agora a passar o tempo a construir “harnesses”: construções de software que definem exatamente o que um modelo de IA pode fazer, que permissões tem e que barreiras de proteção tem de respeitar enquanto caça vulnerabilidades. Um harness parece restritivo, mas é o oposto. Sem um, as equipas Red ficam soterradas em falsos positivos e descobertas despidas de contexto de negócio; com um, o mesmo modelo de IA torna-se genuinamente útil tanto para a simulação de ataques como para a defesa.

O CISO da Netskope, James Robinson, descreve exatamente este padrão: o modelo assinalou um endpoint interno como não autenticado, tecnicamente verdade, mas não percebeu que o endpoint nunca tinha sido, à partida, alcançável a partir da web. Passar do output bruto da IA para algo em que um analista humano confiaria exigiu um esforço de engenharia dedicado, não um prompt.

O efeito de arrasto é que a Blue e a Yellow estão a ser puxadas para mais perto uma da outra do que alguma vez estiveram. Como diz Levi Bolourie, da Zscaler, as equipas blue que não usam IA para análise arriscam-se a ficar soterradas pelo enorme volume de sinais que o red teaming assistido por IA produz agora, e as duas disciplinas terão de se integrar muito mais estreitamente em consequência disso. As Yellow Teams já não são uma função de apoio, de pé e em silêncio, atrás da Red e da Blue. São a razão pela qual qualquer uma das equipas consegue, sequer, acompanhar.

De um sistema de registo a um sistema de ação

Há uma segunda mudança a decorrer por baixo de tudo isto, e aplica-se muito para além da segurança. Durante duas décadas, a maioria do software empresarial foi aquilo a que se chama agora um “sistema de registo”: um local que armazena o que aconteceu. O teu CRM regista que um cliente ligou. A tua plataforma de análise regista que existe uma vulnerabilidade. Útil, necessário e inteiramente passivo.

Um “sistema de ação” faz algo diferente. Em vez de apenas armazenar o que aconteceu, usa essa informação para decidir o que deve acontecer a seguir e, cada vez mais, para o fazer. A própria investigação da Grammarly sobre produtividade no trabalho concluiu que 77 por cento dos profissionais se sentem sobrecarregados pelo enorme volume de informação que têm de processar, e 83 por cento dizem que lhes faltam as ferramentas para agir sobre aquilo que sabem. Essa lacuna entre ter dados e fazer algo útil com eles é exatamente o que um sistema de ação pretende fechar.

Gosto de pensar nisto como a diferença entre um farol tradicional e um que pudesse orientar o seu próprio feixe. Um farol tradicional é um sistema de registo puro: marca uma posição fixa e conhecida, e cabe ao capitão do navio ler a luz, avaliar a distância e escolher o rumo. Não se ajusta ao navio à sua frente. Agora imagina um farol capaz de acompanhar uma embarcação que se aproxima e de redirecionar ativamente o seu feixe para avisar esse navio específico, naquele momento específico, sobre o perigo mais próximo dele. O capitão continua a comandar o navio. Mas o farol deixou de ser um marcador estático e começou a ser um participante ativo na proteção desse navio.

Costumávamos entregar aos parceiros um mapa. Agora queremos guiar a rota.

Uma breve nota sobre posicionamento antes de avançar: a Guardian360 é um fornecedor independente de software. Desenvolvemos o Lighthouse: análise contínua, recomendações de conformidade, inventário de ativos, pontuação de risco de negócio e técnico. Não gerimos um Security Operations Centre, não realizamos testes de penetração manuais nem resposta a incidentes, e não vendemos diretamente a clientes. Esse trabalho pertence aos nossos parceiros, e sempre pertenceu.

Durante anos, o que entregávamos aos parceiros era, na prática, um mapa. O Lighthouse mostrava onde estava o risco, o que precisava de atenção e, aproximadamente, quão urgente era. Encontrar a melhor rota, dessa informação até um ambiente de cliente fixo, ficava inteiramente ao encargo do parceiro. Esse era o modelo certo quando o próprio mapa era a parte difícil de construir. É um modelo mais complicado agora que a IA pode ajudar a gerar não só o mapa, mas também um próximo passo genuinamente útil.

Ao longo dos próximos meses, queremos que o Lighthouse se afaste mais do mapa e se aproxime da navegação: não apenas mostrar aos parceiros onde está o risco, mas propor a melhor rota para lidar com ele, uma e outra vez, à medida que as circunstâncias mudam. É isso que construir um sistema de ação significa, na prática, para nós.

Vale a pena ser honesto quanto a isto, porque levanta uma pergunta óbvia para todos os parceiros que estão a ler: se a plataforma começa a propor a rota, o que sobra para o condutor? A nossa resposta é que o parceiro continua no controlo do carro. Não estamos a construir ferramentas para excluir os parceiros do trabalho; estamos a construí-las para tirar das suas mãos as partes do trabalho que não precisam de um juízo humano, para que os juízos que precisam de um humano recebam mais da sua atenção, e não menos. Os parceiros estão, na prática, a tornar-se a Blue Team de amanhã: aqueles que decidem, agem e assumem a responsabilidade pelo resultado, apoiados por uma Yellow Team a quem finalmente se pede que faça mais do que manter as luzes acesas.

Então, que equipa tens sido, discretamente?

A Guardian360 foi uma Yellow Team muito antes de o termo existir, e suspeito que um bom número de organizações que lê isto pode dizer o mesmo de, pelo menos, uma parte da sua própria operação. A questão que vale a pena ponderar não é se o Yellow Teaming é uma categoria real ou apenas um rebranding. É qual das tuas equipas tem feito este trabalho em segundo plano, há anos, sem nome e sem crédito, e se estás pronto para lhes dar as ferramentas, e a atenção, que este momento realmente exige.

Fontes