Já falei longamente sobre o amadurecimento da segurança cibernética e a mudança da segurança baseada em promessas para a segurança baseada em evidências . Nesta peça, vou expandir uma das tendências relacionadas a essa transformação - ou seja, a ascensão da engenharia de segurança.

Mude da segurança baseada em promessas para a segurança baseada em evidências e a evolução da TI

Quando falo sobre o amadurecimento da segurança cibernética , quero dizer, em grande parte, mudar a maneira como abordamos isso. Até muito recentemente, pensávamos nisso como um recurso e assumimos que a segurança é um problema de ferramenta: se você comprar o produto de segurança “certo”, “próxima geração” de um fornecedor importante, você estará “seguro”.

Agora, depois de muitos anos vendo como essa abordagem falhou em cumprir sua promessa, estamos começando a entender que a segurança é um processo, não um recurso. Estamos desenvolvendo uma crença sistêmica de que precisamos voltar ao básico: coletar dados de segurança em um só lugar, entender o que está acontecendo em nosso ambiente, aprender o que constitui práticas comerciais normais em nossa organização e o que pode ser um sinal de comprometimento, identificar como para detectar comportamento malicioso e responder adequadamente. Em vez de obter um widget que, quando ativado, ativa um escudo protetor impenetrável, as equipes de segurança maduras estão olhando para a segurança através das lentes das camadas e dos trabalhos a serem executados.

“A melhor maneira de construir uma postura de segurança é construí-la sobre controles e infraestrutura que podem ser observados, testados e aprimorados. Não se baseia em promessas de fornecedores que devem ser aceitas pelo valor de face. Isso significa que o conjunto exato de atividades maliciosas e comportamentos dos quais você está protegido deve ser conhecido e você deve ser capaz de testar e provar isso. Isso também significa que, se você puder descrever algo que deseja detectar e prevenir, poderá aplicá-lo unilateralmente sem a intervenção do fornecedor. Por exemplo, se um engenheiro de segurança leu sobre o WannaCry, ele deve ter a capacidade de criar sua própria lógica de detecção sem esperar um ou dois dias até que o fornecedor lance um novo lançamento.”

Outro fator que está mudando a forma como a segurança é feita é a evolução da TI que temos testemunhado na última década. Houve um tempo em que uma experiência em TI era suficiente para começar como um profissional de segurança, pois forneceria uma compreensão básica de como diferentes elementos da infraestrutura funcionavam, interagiam entre si e o que era necessário para protegê-los.

A automação da TI e a ascensão da nuvem estão abstraindo muito do que está acontecendo em segundo plano, tornando mais difícil desenvolver modelos mentais em torno da infraestrutura de TI e entender como protegê-la. Para ter sucesso na segurança hoje, é preciso entender a infraestrutura local, vários componentes da infraestrutura de nuvem, bem como infraestrutura como código e pipelines de DevOps, para citar alguns. À medida que a TI se torna mais complexa, aumentam os requisitos para as pessoas responsáveis pela manutenção, administração e compreensão dessa complexidade.

Outros fatores que aceleram a mudança na forma como fazemos segurança incluem:

- Fraca correlação entre resultados e gastos com segurança,

- Negócios que exigem resultados mensuráveis,

- Aumento da complexidade dos ambientes de segurança e dos clientes,

- Proliferação de ferramentas de segurança,

- Amadurecimento crescente dos profissionais de segurança,

- Aumento dos prêmios de seguro,

- Surgimento da nova geração de prestadores de serviços,

- Surgimento do ecossistema de fornecedores de suporte,

- Estabelecimento de estruturas de segurança, e

- Apoio ao investidor de segurança baseada em evidências.

A cibersegurança do futuro vai se parecer muito com a engenharia de software

Vendo a engenharia de software como um modelo para segurança cibernética

A segurança cibernética se originou em círculos de hackers - entre pessoas com inclinação técnica, curiosas sobre produtos e ferramentas de engenharia reversa, ajustes e invasão do que era visto como inquebrável. Então, vários fornecedores de segurança vieram prometer segurança, dizendo “iremos alertar quando algo de ruim acontecer, basta ter alguém para verificar os alertas”. Impressionados com a perspectiva de tamanha simplicidade, começamos a contratar analistas de segurança para monitorar os alertas. Hoje, mais ou menos uma década depois, estamos vendo que temos que voltar ao básico. Essa abordagem é, obviamente, uma simplificação exagerada, mas a verdade é que precisamos trazer os hackers de volta à indústria. A verdade é que a cibersegurança do futuro vai se parecer muito com a engenharia de software.

O desenvolvimento de software nos oferece um ótimo modelo: analistas de negócios e gerentes de produto operam entre negócios e tecnologia - eles conversam com os clientes, entendem e avaliam requisitos de negócios, traduzem-nos em requisitos técnicos e priorizam esses requisitos para o desenvolvimento. Costumo ouvir como as equipes de segurança são culpadas por não falar com os clientes e não entender o negócio o suficiente. Embora o sentimento seja justo, acho que as pessoas que fazem essas declarações estão perdendo o ponto: criticar os profissionais técnicos de segurança por não entenderem os negócios é o mesmo que criticar os engenheiros de back-end por não serem bons em fazer entrevistas com usuários. A verdade é simples: se os engenheiros de back-end quisessem fazer entrevistas com usuários, eles não teriam escolhido o back-end e teriam se tornado designers de UX.

Precisamos sim de equipes de segurança para entender melhor o negócio, disso não há dúvidas. Mas não podemos resolver o problema enviando todo mundo de TI e segurança para começar a entrevistar funcionários em toda a empresa (embora devamos encorajar a construção de relacionamentos). Em vez disso, precisamos do equivalente a analistas de negócios e gerentes de produto em segurança para preencher a lacuna .

Princípios de engenharia de software para cibersegurança

A engenharia de software oferece um grande conjunto de ferramentas, conceitos, princípios e modelos mentais que compartilham a cibersegurança de amanhã.

Em primeiro lugar, a segurança de amanhã será a segurança como código.

Agora que temos tudo como código - políticas como código, infraestrutura como código, privacidade como código, detecções como código, etc. - podemos implantar, rastrear e testar as alterações para a postura de segurança da organização e revertê-los conforme necessário. Isso, por sua vez, significa uma abordagem que pode ser testada e validada, solidificando ainda mais o ponto sobre a segurança baseada em evidências. Semelhante à forma como funciona na engenharia de software, agora você pode executar testes de segurança automatizados para ver como seu sistema se comportará e contratar uma pessoa de garantia de qualidade (pense em testador de penetração) para ir além dos autômatos e procurar casos extremos não cobertos pela automação .

Em segundo lugar, a segurança cibernética do futuro será baseada em monitoramento contínuo, implantação contínua e iterações frequentes. A postura de segurança de uma organização não é estática, muda a cada segundo e a velocidade com que muda foi acelerada com o surgimento da nuvem. Segundos após a implementação de uma nova cobertura de detecção e resposta, o ambiente de uma organização teria mudado com centenas de máquinas virtuais sendo instaladas na nuvem e dezenas de novos aplicativos SaaS instalados nos endpoints, para citar alguns. A avaliação e a cobertura de segurança não podem permanecer estáticas - elas precisam evoluir à medida que a própria organização evolui. A segurança, portanto, é um processo, não um recurso - um processo baseado na avaliação contínua e no refinamento contínuo da postura de segurança da organização.

Em terceiro lugar, a indústria de amanhã terá que fazer as coisas em escala, priorizando a API. Foi-se o tempo em que as equipes de segurança precisavam fazer login em dezenas de ferramentas para ajustar manualmente algumas configurações e, mais ainda, implantar soluções de segurança manualmente. Tudo tem que ser feito na escala da máquina, via API.

Em quarto lugar, a segurança cibernética verá o mundo das ferramentas comerciais coexistir e se integrar fortemente ao mundo do código aberto. Embora esse tenha sido o caso da engenharia de software por um tempo, com todas as ferramentas comerciais de engenharia de software aproveitando bibliotecas e componentes de código aberto, na segurança cibernética, o código aberto costuma ser visto separadamente do mercado de fornecedores. Anteriormente, examinei profundamente o papel do código aberto na segurança cibernética. Vejo esse papel crescendo à medida que o setor amadurece. Os fornecedores de segurança cibernética não conseguirão escapar simplesmente criando versões comerciais das ferramentas de código aberto; eles precisarão desenvolver e agregar valor real além de fazer uma declaração de que “não somos de código aberto” e mostrar seu certificado de conformidade SOC 2.

Adotar uma abordagem de engenharia para a segurança significa focar na melhoria dos processos para a entrega contínua de defesa, em vez de verificar as caixas de conformidade. Ele capacita as equipes de segurança a fornecer soluções técnicas e criar ferramentas escaláveis antes de recomendar a contratação de mais pessoas, o que, por sua vez, permite que elas alcancem mais com menos. Todos esses fatores combinados tornam a abordagem de segurança baseada em evidências que discuti em profundidade antes uma inevitabilidade; não é mais uma questão de se, é uma questão de quando (resposta: já está acontecendo).

Lugar de segurança no ciclo de vida do produto

Quando pensamos em segurança, uma das primeiras perguntas que vêm à mente é “qual é o seu lugar no ciclo de vida do desenvolvimento de software?”. Embora seja uma pergunta válida, ampliar o ciclo de vida de desenvolvimento de software sozinho cria pontos brilhantes em torno do que acontece com o software em estado selvagem. Para discutir adequadamente o papel da abordagem de engenharia para segurança cibernética, é imperativo olhar para o ciclo de vida do produto como um todo, que inclui como o software é construído, bem como o que acontece depois que ele começa a ser usado na produção.

Historicamente, a segurança era isolada da equipe de desenvolvimento que construía o produto e, como resultado, era vista como a última etapa para garantir a “conformidade” antes do lançamento. Certo, a segurança não era a única parte do ciclo de vida de desenvolvimento de software (SDLC) que existia como um silo; assim como gerenciamento de produto (PM), design, engenharia (muitas vezes dividido em front-end e back-end) e garantia de qualidade (QA), para citar alguns.

Antes da adoção do Agile, que instituiu a ideia de equipes multifuncionais, o desenvolvimento de software era basicamente o seguinte:

1. Um gerente de produto escreveria requisitos e os enviaria aos designers
2. Os designers construíam maquetes e as enviavam para a equipe de desenvolvimento
3. Os engenheiros de back-end concluíam sua parte do trabalho e enviavam a parte restante para a equipe de front-end
4. O produto acabado foi então enviado para QA para revisão

Como as pessoas certas não estavam envolvidas na etapa certa, essa abordagem tradicional chamada cascata resultou em muito desperdício, ineficiências, retrabalho e decisões ruins. Ágil com suas estruturas Scrum e Kanban levou a iterações curtas e lançamento frequente do código e, o mais importante, criou equipes de produtos multifuncionais onde um PM, um designer, engenheiros de software e QA trabalhariam juntos. Em termos práticos, isso significava que os engenheiros de software e o controle de qualidade forneceriam feedback sobre os requisitos e designs antes que fossem considerados prontos para desenvolvimento, e os PMs/QA forneceriam suas informações conforme o produto estava sendo construído, reduzindo a necessidade de descartar o código posteriormente e refazer o que já estava “feito”.

Agile não resolveu todos os problemas. Em particular, quando o DevOps surgiu, os engenheiros de DevOps se viram desprovidos de qualquer contexto sobre o que as equipes de produto estavam fazendo, tornando seu trabalho reativo e difícil de fazer. Eventualmente, as melhores práticas de design organizacional alcançaram e, recentemente, em 2019, Manuel Pais e Matthew Skelton publicaram aquele que é na minha opinião o guia mais impactante sobre design de equipes de tecnologia - Team Topologies: Organizing Business and Technology Teams for Fast Flow . Em seu livro, Manuel e Matthew revisam os desafios comuns do design organizacional, compartilham as melhores práticas sobre padrões e interações de equipes bem-sucedidas e recomendam maneiras de otimizar fluxos de valor para empresas de tecnologia.

Até recentemente, a segurança estava atrasada em se tornar parte da organização de desenvolvimento, existindo como um posto de controle isolado que, na melhor das hipóteses, autorizava os lançamentos e atribuía novos tíquetes às equipes de desenvolvimento, comumente marcadas como “prioridade mais alta ”. Embora esse ainda seja um padrão observado em muitas organizações, a abordagem de segurança começou a mudar nos últimos anos. Estamos vendo o crescimento do DevSecOps como uma resposta de segurança ao DevOps e, à medida que a segurança está sendo incorporada aos pipelines de CI/CD, sua função está mudando de conformidade para entrega de defesa. No que se refere ao desenvolvimento de novos produtos, a segurança está realmente começando a parecer engenharia de software.

Indo para o futuro, provavelmente continuaremos a ver as equipes de segurança operando como unidades autônomas dentro de suas organizações. No entanto, cada vez mais vulnerabilidades específicas de aplicativos serão tratadas por aqueles que constroem o produto e têm mais contexto sobre o código - engenheiros de software. As equipes de segurança atuarão como consultores para as equipes de desenvolvimento de produtos, semelhante ao papel desempenhado hoje pelos engenheiros de confiabilidade da plataforma e do site.

Mentalidade de engenharia para infraestrutura e operações de segurança

Embora geralmente seja fácil imaginar como seria uma mentalidade de engenharia para segurança quando estamos falando sobre desenvolvimento de software, pode ser muito mais difícil de fazer quando olhamos para infraestrutura e operações de segurança - coisas que acontecem no dia a dia, depois, e fora do desenvolvimento de software. Isso ocorre em grande parte porque a segurança do aplicativo faz parte do ciclo de vida do desenvolvimento de software, e as startups nativas da nuvem financiadas por empreendimentos têm procurado ativamente maneiras de proteger seu código e fazê-lo de maneira escalonável.

Comparativamente, pouco discurso foi visto sobre trazer uma mentalidade de engenharia, abordagens e estruturas para operações de segurança, detecção e resposta, tratamento de incidentes, análise forense digital e outras áreas de segurança. Esses componentes vitais dos processos de segurança cibernética de uma empresa são vistos como partes internas que podem desempenhar bem seu trabalho, desde que tenham “os produtos certos” implantados na rede e algumas pessoas para monitorar esses produtos. Mais importante ainda, as equipes de segurança têm sido consistentemente com poucos recursos e consumidos pelo fogo mais recente, tornando-os incapazes de se concentrar na construção de defesas de forma proativa.

Desnecessário dizer que essa abordagem provou ser limitante e muitas vezes prejudicial à postura de segurança da organização. Embora eu não tenha evidências para apoiar essa afirmação, eu especularia que a maioria (se não todas) as empresas que aparecem nas notícias como tendo sofrido uma violação nos últimos anos tiveram as melhores e mais recentes ferramentas implantadas em seus ambiente. O fato de essas ferramentas não protegerem as empresas de incidentes de segurança não é de forma alguma uma sugestão de que elas fazem um trabalho ruim (muito pelo contrário). Em vez disso, acho que esses eventos destacam que nenhum produto é à prova de balas, apesar do que o marketing do fornecedor possa sugerir e, para defender nossos negócios e nosso pessoal, precisamos mudar a maneira como abordamos a segurança.

Adotar uma mentalidade de engenharia para segurança significa várias coisas, incluindo:

• Aceitar que as ferramentas são apenas ferramentas e olhar além da seleção do fornecedor para os fundamentos da segurança cibernética como uma área de prática. Isso significa fazer perguntas como “O que devo fazer para proteger minha organização? Quais são os riscos que estou enfrentando? Quais comportamentos maliciosos podem ocorrer em meu ambiente? Como estou detectando-os? Como responderei quando forem detectados?”, em vez de “Que ferramenta devo comprar para proteger minha organização?”
• Armadas com essa percepção, as empresas precisam colocar essa abordagem em prática, garantindo que tenham visibilidade total de seu ambiente (“painel único de vidro”), sobre o que estão detectando e como estão fazendo isso (saber quais detecções funcionam em seu ambiente , o que exatamente eles detectam e como detectam), juntamente com a capacidade de testar suas defesas de maneira reproduzível.
• Perceber que muitos componentes das operações de segurança podem e devem ser automatizados e procurar maneiras de criar maneiras escaláveis de fornecer defesa para a organização. Na prática, isso significa adotar detecções como código, infraestrutura como código e outras abordagens que comprovadamente funcionam e escalam em outras áreas da tecnologia. Quando uma equipe detecta novas vulnerabilidades e comportamentos mal-intencionados, ela deve ter as ferramentas para responder a eles de uma forma que elimine a necessidade de aplicar manualmente a mesma resposta à mesma vulnerabilidade amanhã.

Historicamente, a maior parte do conhecimento de segurança residia nas cabeças de profissionais experientes que “já estiveram lá, fizeram isso”. À medida que a indústria está amadurecendo, precisamos procurar maneiras de codificar esse conhecimento e torná-lo compartilhável, testável e acessível para uso e melhoria para organizações em todo o mundo. A segurança cibernética sempre será uma arte, pois lida com o adversário criativo e inteligente. No entanto, também precisa se tornar uma ciência se quisermos continuar aumentando nossa base de conhecimento e tornar as defesas cibernéticas acessíveis a organizações que não podem contratar “o melhor dos melhores” no campo. Adotar a abordagem de engenharia baseada na ciência para a segurança permitirá que as equipes de segurança criem sistemas e processos para fazer seu trabalho de forma consistente.

A ascensão da engenharia de segurança e como ela está mudando a cibersegurança de amanhã

A evolução da engenharia de detecção e o surgimento da engenharia de detecção como serviço

Nos últimos anos, tem havido muita ênfase na transparência na detecção de ameaças. O problema atraiu a atenção de profissionais de segurança, fundadores de startups e analistas do setor, para citar alguns. Em 2022, dois ex-analistas do Gartner, Anton Chuvakin e Oliver Rochford, escreveram um miniartigo intitulado “Sobre confiança e transparência na detecção”, que começa da seguinte forma: “Quando detectamos ameaças, esperamos saber o que estamos detectando. Parece dolorosamente óbvio, certo? Mas está muito claro para nós que, ao longo de toda a história da indústria de segurança, nem sempre foi assim. Alguns de nós se lembram dos primeiros dias da rede Os sistemas de detecção de intrusão IDS eram entregues sem que os clientes pudessem ver como as detecções funcionavam. O mercado falou, e esses fornecedores estão todos mortos e enterrados pelo Snort e seus descendentes, que abriram suas assinaturas de detecção para revisão e modificação.” A postagem no blog é uma ótima leitura para qualquer pessoa interessada no assunto.

O ambiente de cada organização é único e a singularidade só aumenta com o crescimento do SaaS e o surgimento de ferramentas especializadas para quase tudo. Cada departamento da organização tem dezenas de ferramentas que usa para gerenciar seu trabalho (imagine apenas o número de aplicativos projetados para substituir o uso de planilhas apenas para equipes de marketing, recursos humanos, finanças, produtos e operações). Além disso, quase todas as empresas que atingem um certo nível de crescimento desenvolvem seus próprios aplicativos internos para economizar para os casos de uso exclusivos de suas operações, modelo de negócios ou estratégia de entrada no mercado.

A singularidade do ambiente de cada organização significa que tanto a forma como os invasores entrariam em cada organização quanto a forma como os defensores seriam capazes de detectar comportamentos mal-intencionados nesse ambiente seriam diferentes. Em termos práticos, para que as equipes de segurança resolvam o problema de detectar algo exclusivo do ambiente de sua organização, elas precisariam criar uma lógica de detecção para esse ambiente específico.

Os fornecedores de segurança que prometem cobertura geral para todos são uma ótima camada básica (assim como o antivírus), mas não são suficientes para empresas que têm muito a perder.

A engenharia de detecção evoluiu muito nos últimos 10 anos, como atestam as próprias pessoas que fazem isso há uma década . No artigo mencionado acima, Zack Allen, diretor de pesquisa de segurança da Datadog, descreve como a abordagem “quanto mais, melhor” para criar conteúdo de detecção evoluiu para uma percepção madura de que precisamos de conteúdo de detecção abrangente e de alta qualidade, não apenas “mais detecções ". Os engenheiros de detecção que costumavam ser vistos como "magos" que "descem de sua torre e pregam ao mundo suas últimas descobertas, presentes na Blackhat e na DEFCON" são agora um dos muitos tipos de engenheiros de segurança.

Falando sobre engenharia de detecção, Zack conclui:

“Você não pode escrever detecções para seu produto de segurança de rede se não tiver especialistas em segurança de rede. Isso é o mesmo para detecções baseadas em endpoint, nuvem, aplicativo e host. É como ter um grupo de cientistas de dados construindo um modelo de aprendizado de máquina para detectar asma em pacientes. No entanto, eles se esqueceram de trazer um médico para mostrar como os pacientes com pneumonia dariam falsos positivos ao modelo. Você precisa dos especialistas no assunto. Isso não mudou na indústria, nem deveria. O que mudou é que esses especialistas precisam de uma base sólida em princípios de engenharia de software. Você não pode dimensionar todas essas detecções e implantá-las em um ambiente moderno, gerenciar sprints (sim, isso é engenharia de software :)) ou escrever testes de unidade, integração e regressão sem muitos corpos ou muita automação. Posso dizer com segurança que meu chefe prefere ouvir que posso reduzir o problema com software do que com a contratação de mais pessoas.”

Vejo dois sinais de que a engenharia de detecção evoluiu para uma profissão dedicada e bem definida: o número crescente de eventos como DEATHCon (Detection Engineering and Threat Hunting Conference), palestras e treinamentos em Black Hat, BSides e outras reuniões de profissionais, bem como o início da definição dos estágios de maturidade pelos quais as organizações passam ao implementá-lo. A Matriz de Maturidade da Engenharia de Detecção de Kyle Bailey é a melhor tentativa de medir as capacidades e a maturidade da função nas organizações.

À medida que mais e mais organizações estão percebendo que a lógica de detecção não é de tamanho único, e é improvável que os fornecedores de segurança consigam cumprir sua promessa de “manter todos seguros”, estamos começando a ver startups de segurança cibernética especializadas na construção de detecção contente. Em vez de simplesmente disparar alertas, essas empresas tornam o conteúdo da própria regra visível e editável, o que permite que as equipes de segurança entendam exatamente o que está sendo detectado em seu ambiente, como exatamente está sendo detectado e quais playbooks ou alertas serão acionados quando isso acontecer. é detectado. Dois exemplos notáveis de startups neste espaço são SOC Prime e SnapAttack, que suportam a linguagem padrão de fato para escrever conteúdo de detecção - Sigma. Em vez de prometer cobertura total, esses fornecedores oferecem às empresas a capacidade de acessar a cobertura de segurança de maneira totalmente transparente, pagando conforme o uso.

As organizações não apenas podem comprar cobertura de detecção genérica de fornecedores especializados em engenharia de detecção, mas também podem fazer com que seus provedores de serviços de segurança criem a lógica de alertas personalizada sob medida para seu ambiente. Embora isso não seja algo oferecido por todos os provedores hoje, é para onde eu acho que o setor está indo, pois as consultorias de segurança e as empresas de detecção e resposta gerenciadas estão procurando agregar mais valor além da seleção de fornecedores e monitoramento de alertas. Em breve, a engenharia de detecção como serviço se tornará padrão para provedores de serviços de segurança.

Notavelmente, a mudança nas expectativas do cliente também está mudando a maneira como os fornecedores de segurança, como detecção e resposta de endpoint (EDR) e detecção e resposta estendidas (XDR), estão operando. Tendo começado frequentemente como “caixas pretas” que executam a lógica de detecção genérica construída internamente em todos os seus clientes, eles agora também oferecem a capacidade de os clientes escreverem suas próprias detecções no topo. Fornecedores mais novos, como LimaCharlie, onde lidero o produto, Panther e toda uma nova categoria do chamado Open XDR também estão oferecendo visibilidade total da cobertura de segurança da organização (não apenas as regras personalizadas, mas todas as detecções executadas na organização).

A crescente importância da engenharia de segurança

Eu uso a engenharia de detecção como exemplo; estamos vendo um grande impulso em direção à engenharia em todas as áreas de segurança. Com a infraestrutura como código, o gerenciamento da infraestrutura agora é propriedade da engenharia, não da TI. Portanto, as habilidades de engenharia de software estão se tornando um pré-requisito para a segurança.

Com o surgimento da nuvem, os princípios e práticas de engenharia de software agora sustentam como a infraestrutura é provisionada, como as políticas e configurações de segurança são aplicadas, como a postura de segurança da empresa é testada e interrogada, como as mudanças nas configurações de segurança são implementadas e rastreadas e assim por diante . Enquanto os engenheiros de DevOps são responsáveis pelo provisionamento e gerenciamento da infraestrutura, os engenheiros de segurança que combinam um forte conhecimento de engenharia com um profundo conhecimento de segurança são ideais para protegê-la.

A maioria dos profissionais de segurança cibernética hoje desenvolveu suas habilidades em TI - projetando arquiteturas de rede, provisionando firewalls e gerenciando políticas de firewall e outras tarefas críticas para manter a TI na empresa funcionando. Infelizmente, muitas das pessoas encarregadas da segurança têm apenas o conhecimento mais básico da engenharia de software, impedindo-as de desenvolver as habilidades necessárias em um mundo onde tudo - infraestrutura, políticas, detecções etc. - existe como código. É natural que, quando a infraestrutura subjacente está em código, os profissionais de segurança precisem aprender a codificar. O mesmo vale para automação e uso de API: como a grande maioria das tarefas técnicas agora é realizada em escala via API (incluindo o trabalho que antes era feito manualmente pelas próprias equipes de segurança), precisamos de pessoas que entendam como projetar, usar e desativar APIs de maneira segura.

Espera-se que as equipes de engenharia de segurança vão além dos controles operacionais, criando soluções de engenharia para problemas de segurança. À medida que mais e mais organizações percebem que as ferramentas de segurança disponíveis no mercado não atendem à singularidade de suas necessidades e ambientes, aquelas que têm os níveis certos de recursos e suporte para levar a sério o fortalecimento de sua postura de segurança estão começando a ir além da configuração comercial. produtos. Embora, para alguns casos de uso, uma ferramenta comprada de um fornecedor de segurança possa ser implementada como está, na maioria das vezes ela precisa de alguns ajustes para acomodar as necessidades exclusivas de uma organização. No entanto, vemos um entendimento cada vez maior, especialmente entre grandes empresas que lidam com muitos dados e empresas nativas da nuvem, de que as ferramentas comerciais não são capazes de atender à multiplicidade de necessidades e requisitos de segurança. Essas empresas estão começando a criar alguns elementos de sua pilha de segurança internamente, delegando o design e o desenvolvimento dessas soluções a arquitetos e engenheiros de segurança internos.

Tom Tovar, da Appdome, sugeriu em seu podcast recente que podemos colocar as organizações de segurança em três categorias:

1. Equipes de segurança tradicionais, compostas por profissionais de segurança tecnicamente fortes, com profundo conhecimento de segurança e conformidade e melhores práticas para ambos.
2. Equipes de segurança avançadas que geralmente têm pesquisadores de segurança e arquitetos de segurança encarregados de projetar sistemas, avaliação de produtos, testes de penetração, etc.
3. Organizações de segurança cibernética e engenharia que possuem talentos de engenharia “hardcore” capazes de criar e fornecer soluções de segurança para organizações modernas

Vejo essas categorias não como diferentes estágios de maturidade, mas como uma evolução em termos de necessidades organizacionais. As empresas nativas da nuvem estão começando a criar equipes de engenharia de segurança projetadas para trabalhar em estreita colaboração com DevOps, engenharia de software e desenvolvimento de produtos. Com isso, muitos dos elementos que tradicionalmente seriam propriedade das equipes de TI e segurança, agora pertencem às equipes de DevOps e engenharia de segurança. Esse modelo que depende de construtores - talentos de engenharia capazes de criar soluções de segurança - não é necessário para todas as organizações. No entanto, à medida que mais e mais empresas iniciam a nuvem primeiro desde o primeiro dia, à medida que seus ambientes se tornam mais exclusivos com a proliferação de ferramentas SaaS e à medida que mais equipes de segurança percebem o valor da segurança adaptada às suas necessidades, veremos um enorme mudança para a engenharia de segurança.

No momento em que escrevo este artigo, vemos que as práticas recomendadas para o design organizacional não acompanharam a ascensão da engenharia de segurança. Em termos práticos, isso significa que, embora as equipes de engenharia de segurança tenham suas próprias ferramentas pelas quais são responsáveis pelo gerenciamento, parece haver muitos conflitos de propriedade entre engenheiros de segurança e engenheiros de software/DevOps, bem como equipes de segurança operacional. É justo dizer que hoje em dia, em todas as organizações que têm a sorte de ter uma equipe de engenharia de segurança, a forma dessa equipe parece um pouco diferente. Conflitos organizacionais e áreas pouco claras de propriedade são passos naturais na formação de qualquer nova disciplina, então o que estamos vendo é orgânico e esperado.

A natureza mutável da função do analista de segurança

À medida que a segurança cibernética se torna um código, ficará cada vez mais difícil para aqueles que não codificam. Estou falando sobre a mudança do papel dos analistas de segurança.

Os analistas de segurança, tradicionalmente categorizados em Nível 1 (especialista em triagem), Nível 2 (resposta a incidentes) e Nível 3 (analista especialista), desempenham um papel importante em uma equipe de centro de operações de segurança (SOC). Com os recentes avanços na automação, a forma dessa função começou a mudar.

Em primeiro lugar, à medida que as equipes de segurança buscam maneiras de melhorar a eficiência e a produtividade, cada vez mais processos e procedimentos em um SOC que costumavam ser manuais estão sendo automatizados. Em segundo lugar, o aumento da inteligência artificial (IA) promete eliminar a necessidade de triagem manual de milhares de alertas - sem dúvida um dos maiores pontos problemáticos que as equipes de segurança estão enfrentando. Até hoje, a IA ainda não cumpriu sua promessa de automatizar a segurança, mas isso acabará acontecendo. Provavelmente, mais cedo do que gostaríamos de imaginar, veremos uma batalha de IA com adversários treinando seus próprios modelos e defesa - os seus próprios. Deixando de lado as imagens futuristas, os analistas do SOC precisarão se ajustar às mudanças na forma da segurança.

Devido aos dois fatores descritos acima, os analistas de SOC (especialmente aqueles tradicionalmente conhecidos como “Tier 1”) precisam começar a aprender novas habilidades. A habilidade técnica mais premente é a codificação, e os analistas entendem isso, conforme ilustrado pela pesquisa Voice of the SOC Analyst encomendada pela Tines em 2022.

Existem alarmistas suficientes na indústria sugerindo que o futuro dos analistas é sombrio, mas eu vejo isso de forma diferente. O papel não vai desaparecer, mas sua forma e escopo vão mudar. No passado, ser analista era basicamente saber como usar produtos de segurança específicos. Agora a segurança está começando a ser vista não como um problema de ferramenta, mas sim como um problema de abordagem. Além disso, as ferramentas de segurança estão se tornando comoditizadas e padronizadas para que todas funcionem de maneira semelhante: se um analista usou um EDR, é provável que não precise de muito tempo para aprender outro. Quais produtos exatos um analista usou no passado se tornarão menos importantes do que sua compreensão dos fundamentos de segurança. Os analistas que desejam permanecer relevantes à medida que o setor amadurece precisam se tornar mais técnicos. Embora nem todos devam se tornar engenheiros, será cada vez mais importante que eles entendam como os agentes de ameaças veem o mundo e como os ataques são conduzidos.

Acho que o futuro dos analistas de segurança será semelhante ao futuro dos profissionais de QA (garantia de qualidade) no desenvolvimento de software. A grande maioria dos trabalhos de controle de qualidade não é mais manual e requer o uso de ferramentas, linguagens e estruturas de automação. Aqueles que pagam mais são o que a Amazon e muitas outras empresas agora chamam de “engenheiros em teste” - engenheiros de software com foco em testar a funcionalidade do produto e APIs. O controle de qualidade manual ainda existe, mas é difícil de encontrar, as funções são incrivelmente competitivas e, como a oferta de trabalhadores qualificados supera em muito a demanda, eles recebem a remuneração mais baixa. O Mechanical Turk da Amazon muda drasticamente o jogo, reduzindo ainda mais o custo do controle de qualidade. A garantia de qualidade não morreu, mas se transformou bastante (e, notavelmente, não precisou de IA e ML avançados para mudá-la).

Pilha de segurança do futuro

À medida que as equipes de segurança se tornam mais técnicas, elas começam a reconhecer que nenhum fornecedor pode prometer “segurança” e “proteção” como um recurso. Tradicionalmente, a maioria das ferramentas de segurança comercial abstraía as camadas fundamentais das equipes de segurança e oferecia uma visão de alto nível na forma de alertas e relatórios que resumiam o que aconteceu. As organizações que desejavam visibilidade das camadas fundamentais da infraestrutura de segurança e dos dados em nível de eventos foram forçadas a usar ferramentas de código aberto ou criar as ferramentas do zero.

Como a abordagem DevSecOps requer visibilidade nas camadas fundamentais de segurança, a pilha de segurança do futuro parecerá muito diferente do que vemos hoje quando olhamos para os chamados mapas do mercado de segurança cibernética. Em primeiro lugar, veremos cada vez mais soluções neutras que podem ser usadas pelos profissionais para interrogar seus sistemas, obter visibilidade total de seu ambiente e construir uma cobertura de segurança adaptada às suas necessidades. Essas ferramentas funcionarão de forma transparente e o trabalho que realizam será facilmente testado e verificado. É importante ressaltar que veremos uma mistura de soluções comerciais e de código aberto que podem funcionar juntas para atender aos casos de uso de segurança da organização. No centro da segurança estarão os processos e profissionais de segurança – não “produtos” pois as ferramentas são apenas isso – ferramentas; é como eles são usados e para que são usados que importa.

Nos últimos anos, começamos a ver cada vez mais líderes de segurança rejeitando a ideia de confiar cegamente nos fornecedores: é a abordagem que promovemos na LimaCharlie, onde lidero produtos, bem como adotada por outras soluções de nova geração, como SOC Prime, Panther, Prelude e, mais recentemente , Interpres, para citar alguns.

A imagem abaixo é uma lista das empresas atuais e das ferramentas de código aberto que adotam uma abordagem de engenharia baseada em evidências para a segurança. Não pretende ser exaustivo (existem muitas outras ferramentas excelentes que se enquadram nos critérios acima) e não é um “mapa de mercado” tradicional.

Fechando a lacuna de talentos

Para contratar grandes talentos, as empresas precisam mudar a forma como funcionam

As equipes de segurança que defendem as empresas de agentes mal-intencionados estão estressadas, com falta de pessoal, subvalorizadas e mal pagas. A realidade é que os grupos de hackers são melhores em atrair talentos profundamente técnicos do que qualquer corporação. Eles pagam isentos de impostos e muito mais do que qualquer empresa pagaria. Eles oferecem um grande equilíbrio entre vida profissional e pessoal, a emoção de hackear e uma sensação de realização. A maioria deles é 100% anônima. Não há necessidade de acumular certificações sem valor e pagar algumas centenas de dólares a cada poucos anos para mantê-las “atualizadas” e não há necessidade de lidar com recrutadores, recursos humanos, treinamento básico de conformidade, política no local de trabalho, jurídico, conformidade, folha de pagamento e chefes exigentes como se não bastasse. Se isso soa como se eu estivesse trabalhando para o adversário - essa não é minha intenção, e a verdade é que nada disso é novidade para profissionais de segurança experientes. Estou apenas demonstrando que, para contratar grandes talentos, a empresa precisa fazer melhor.

Esta postagem, juntamente com o fato de que muitos dos melhores profissionais de segurança não se sentem motivados a lidar com a burocracia de trabalhar para grandes corporações, pinta um quadro sombrio do mercado de trabalho atual.

Seria antiético e falso sugerir que eu tenho uma lista de soluções rápidas e fáceis, então nós, como indústria, temos que encontrá-las juntas. Podemos começar eliminando o requisito de “5 anos de experiência” para empregos de nível básico e desenvolver isso à medida que avançamos, removendo preconceitos e melhorando nosso processo de contratação.

Fazendo com que engenheiros de software façam segurança

Como tudo em segurança está se tornando um código, um dos canais raramente discutidos para talentos em segurança cibernética pode ser a engenharia de software. Alguns argumentam que pode ser mais fácil ensinar segurança a engenheiros do que a engenharia de software para profissionais de segurança. Embora eu não seja a pessoa certa para fazer um julgamento sobre a correção dessa afirmação, já vi engenheiros de software se transformarem em profissionais de segurança para saber que esse caminho é real.

O desafio consiste em tornar conhecido que a segurança cibernética é uma carreira viável para graduados em engenharia de software, fornecendo-lhes o treinamento certo (adicionando cursos de segurança cibernética de nível profundo aos programas de ciência da computação) e projetando planos de carreira significativos para que eles encontrem seu caminho cíber segurança. Isso levanta uma questão de compensação para muitos empregos básicos de segurança cibernética que os recém-formados podem comandar: se uma pessoa pode conseguir seu primeiro emprego em software que paga 20-40% a mais do que qualquer coisa que é oferecida em segurança (se eles conseguirem uma entrevista ), toda a ideia de contratar engenheiros de software para cuidar da segurança desmorona.

Educando a nova geração de engenheiros de segurança

Muito se fala sobre a escassez de talentos em segurança cibernética, e é fácil notar um mar de novos entrantes prometendo resolver esse problema. De bootcamps de segurança cibernética de 6 semanas a cursos on-line, bem como novos diplomas universitários - todos querem uma fatia do bolo em “educar o futuro da segurança”. É tentador pensar que tudo o que precisamos é preparar mais alunos do ensino médio e adultos para mudar de carreira entusiasmados com a segurança e se inscrever nesses programas e, 3 a 5 anos depois, estamos prontos, vejo o problema muito mais profundo.

Se você observar a grande maioria dos programas educacionais, perceberá que seus currículos tendem a omitir o componente de engenharia. Não gastei tempo suficiente compilando os dados, então minhas observações sobre esse tópico são bastante anedóticas, mas aqui está o que estou vendo:

• A maioria dos bootcamps são tão curtos e de alto nível que seria irracional acreditar que eles podem fornecer a seus graduados qualquer conhecimento profundo da indústria. Conheci muitos grandes profissionais de segurança que passaram por bootcamps. No entanto, eles se tornaram grandes não porque puderam participar de um bootcamp, mas por causa do que fizeram fora deles. Não estou sugerindo que esses cursos imersivos curtos não ofereçam valor. Para ilustrar o ponto que estou tentando enfatizar, encorajo você a pensar sobre por que existem tantos bootcamps de 4 a 8 semanas ensinando desenvolvimento front-end e tão poucos treinamentos de 4 a 8 semanas ensinando desenvolvimento back-end. A resposta é simplesmente porque o desenvolvimento de back-end, semelhante à segurança, requer uma compreensão sólida de teorias e conceitos profundamente técnicos e a capacidade de processar esses conceitos e implementá-los em código sem nenhum feedback visual. Vou deixar registrado que você não pode ensinar isso durante o mesmo tempo que leva para ensinar as pessoas a criar um site simples.
• Muitos programas universitários, especialmente no nível de mestrado, concentram-se mais em redigir políticas do que no desenvolvimento de habilidades práticas. Mesmo aqueles que são mais profundos e práticos tendem a ser o que a educação universitária é como um todo - muito antigo, muito teórico e muito superficial. A segurança está evoluindo diariamente, com novas explorações, novas vulnerabilidades, novos vetores de ataque e novas tecnologias criadas diariamente também. Os programas universitários têm que passar por longas aprovações, revisões acadêmicas rigorosas e avaliações, tanto que, quando um programa é aprovado, fala sobre as notícias há seis meses ou mais. Existem alguns ótimos professores e instrutores que estão trabalhando duro para se manter atualizados com a indústria e ensinar a seus alunos habilidades úteis, práticas e atuais. Todos devemos ser profundamente gratos por seu trabalho, mas vale dizer que essas pessoas não trabalham de acordo com o sistema educacional em si, mas contornam suas limitações para fazer o bem aos alunos e à sociedade.
• As certificações de segurança cibernética não refletem as habilidades e experiências que o mercado precisa. Não pretendo diminuir a quantidade de esforço que as pessoas colocam neles, e não estou sugerindo que não ofereçam nenhum valor. Em vez disso, o que quero dizer é que, com pouquíssimas exceções, essas certificações oferecem conceitos teóricos e fazem as pessoas sentirem que sabem como a segurança deve ser feita, sem fornecer nenhuma habilidade real para realmente fazê-lo. Enquanto os invasores estão se aprofundando no código e procurando maneiras de contornar os controles, explorar vulnerabilidades e exfiltrar dados, parece que pensamos seriamente que podemos detê-los ensinando as pessoas a escrever políticas e passar em exames de múltipla escolha sobre segurança na nuvem . Imagine ser operado por um cirurgião cardíaco com “certificado em corações” que não fez uma única cirurgia na vida (não posso).

Tudo isso é um longo caminho para dizer que os melhores profissionais de segurança de hoje não vêm das universidades, e nem pelo que parece virão os de amanhã. As pessoas que se tornam profissionais de ponta em engenharia de segurança vêm de trabalhos práticos em testes de penetração, militares, NSA e outras instituições governamentais com fortes componentes ofensivos. Eles vêm de equipes de segurança maduras em empresas nativas da nuvem que tratam a segurança com seriedade. Eles são autodidatas na frente de seus computadores, em competições CTF (capture the flag) e em eventos como Open SOC, Black Hat, DefCon e afins.

Para moldar o futuro da segurança e fechar a lacuna de talentos, não podemos esperar que um número suficiente de indivíduos motivados encontre uma maneira de aprender sozinhos as habilidades necessárias para proteger nosso pessoal, negócios e países. A esperança não é uma estratégia, nem os bootcamps de 6 semanas; precisamos construir sistemas e instituições para fechar a lacuna técnica de segurança cibernética. A segurança é difícil. Ensinar segurança também é difícil, mas precisa ser feito. Conformidade e redação de políticas são importantes, mas sozinhas não nos ajudarão a defender nossas redes contra invasores - incrivelmente talentosos, altamente qualificados, muito motivados e bem pagos.

Embora precisemos encontrar maneiras de colocar engenheiros de software na segurança cibernética, também precisamos de profissionais de segurança profundamente especializados para adquirir habilidades de engenharia. Embora nem todos os profissionais de resposta a incidentes, forense digital e segurança de endpoint se tornem engenheiros, quase todos se beneficiariam ao conhecer os fundamentos do desenvolvimento de software e tornar-se fluente em linguagens como Python. A adoção de uma abordagem de engenharia para as operações de segurança nos permitirá automatizar partes manuais da resposta a incidentes e criar continuamente maneiras escaláveis de proteger o perímetro da organização, gastando mais tempo na construção proativa de defesas. Para isso, a educação em segurança cibernética deve começar a incluir cursos de engenharia de software da mesma forma que os cursos de engenharia de software e ciência da computação devem ensinar os fundamentos da segurança.

Pensamentos finais

De fato, não há balas de prata que resolverão todos os nossos problemas de segurança, e produzir mais engenheiros de segurança também não resolverá isso. No entanto, adotar uma abordagem de engenharia para a segurança pode nos ajudar a criar segurança em produtos de software desde o início, acelerar o amadurecimento do setor e preparar nossas operações de segurança para o futuro.

A escassez de talentos certamente será um obstáculo. No entanto, só porque não temos os recursos de que precisamos, não podemos e não devemos descartar uma solução viável para o difícil problema. Também está claro que precisamos mudar nossas práticas de contratação e reavaliar os critérios usados para identificar futuros líderes de segurança. Obtemos o que otimizamos. Todos os dias, os invasores passam inúmeras horas aprendendo novas tecnologias, fazendo engenharia reversa de software que construímos e procurando vulnerabilidades no código. Se olharmos para as postagens de trabalho de segurança, é fácil concluir que esperamos parar o adversário passando em testes de múltipla escolha e obtendo certificações que são habilidades muito diferentes daquelas necessárias para entender como o código funciona e como defendê-lo.

Estou convencido de que a abordagem de engenharia para segurança cibernética é inevitável. Já começamos a ver os sinais de seu crescimento, e daqui para frente ele só vai acelerar. A questão é - com que rapidez seremos capazes de construir a infraestrutura para seu desenvolvimento? Se a história nos ensinou alguma coisa, é que o estado da prática de segurança cibernética como um todo está atrasado anos atrás das últimas e melhores palestras dadas na DefCon, Black Hat e similares. Teremos que ver quais eventos que alteram a indústria virão a seguir.

A imagem principal deste artigo foi gerada peloAI Image Generator do HackerNoon por meio do prompt "cybersecurity".