Aikido A segurança pentest de IA integra-se na pilha que já utiliza. Mesmo que esteja comprometido com o seu código atual e com as suas ferramentas de segurança na nuvem , pode adicionar o pentest de IA por cima para detetar as falhas lógicas complexas que as ferramentas determinísticas não conseguem identificar.
Se pretende aprofundar os seus testes de penetração ou testar cada lançamento, talvez esteja à procura de uma solução que vá além da contratação de pentesters manuais. Quando o First National Bank of America precisou de realizar um teste de penetração num novo portal do cliente dentro de um prazo, a sua equipa executou um teste de penetração com IA da Aikido em menos de um dia. O teste terminou em 1 hora e 40 minutos e detetou uma falha de gravidade elevada, que o banco corrigiu antes de o portal ser disponibilizado ao público. Como cada teste demora apenas algumas horas, as equipas podem executá-lo sempre que a aplicação sofrer alterações, e cada teste gera um relatório pronto para auditoria.
Os leitores que ainda estejam a escolher um fornecedor devem consultar o Guia do Comprador da «pentest de IA », mas se estiver a considerar seriamente a Aikido, continue a ler.
{{cta}}
O que é necessário para realizar um teste de penetração de IA com o Aikido
Opcional, mas recomendado: os testes de caixa branca (que conferem ao pentest de IA acesso aos repositórios ligados) detetam mais vulnerabilidades do que os testes de caixa preta, com o mesmo número de créditos. Aikido O Infinite (pentest contínuo) realiza testes de penetração nas diferenças das novas implementações.
Comece com um teste de penetração
Não é necessário adotar nenhum outro produto da Aikido para realizar um primeiro teste de penetração, e todas as ferramentas que já fazem parte do seu conjunto podem permanecer exatamente onde estão. No que diz respeito aos testes de penetração de aplicações web e APIs, a maior parte da configuração resume-se a duas decisões: qual a aplicação que pretende testar e quais dos seus domínios estão abrangidos pelo âmbito do teste.
Recomendamos que o teste de penetração seja realizado num ambiente de teste ou de pré-produção que espelhe o ambiente de produção, mas que utilize dados de teste. Isso mantém os testes isolados da sua aplicação em produção e permite que os agentes o testem na íntegra, sem riscos para os utilizadores ou dados reais.
Aikido solicita também que forneça aos agentes as credenciais de início de sessão e uma conta para cada função de utilizador, como um utilizador normal e um administrador, para que possam navegar pelas áreas protegidas da aplicação e verificar se uma função consegue aceder a dados que pertencem a outra. Sem credenciais, o teste apenas mostra o que um visitante anónimo veria.
A ligação dos seus repositórios é opcional, mas altera o que o teste consegue detetar. Os testes de caixa branca, com acesso ao código-fonte, são muito mais exaustivos do que os testes sem esse acesso; em mais de 1 000 testes de penetração, os testes de caixa branca revelaram 7 vezes mais vulnerabilidades do que os testes de caixa cinzenta.
Esta profundidade também se confirmou na experiência do cliente do Aikido. O First National Bank of America iniciou o seu primeiro teste de penetração um dia após ter decidido utilizar o Aikido, e o engenheiro de Gestão de Identidades e Acessos do banco atribuiu o impacto dos resultados à abordagem de caixa aberta, uma vez que os agentes dispunham do contexto de cada repositório.
«O facto de poder contar com o Aikido para analisar os nossos repositórios e ter esse contexto proporcionou-nos tarefas de correção realmente eficazes. Com essas informações de backend, obtêm-se conclusões muito mais aprofundadas... Detetámos [uma vulnerabilidade de gravidade elevada] antes de esta chegar à produção. Isso representa um valor claro para nós.»
Os documentos de configuração explicam em pormenor cada avaliação e cada opção de acesso.
Escolher o que testar em termos de segurança
Os termos relacionados com testes de penetração são utilizados de forma pouco precisa, pelo que é útil começar por definir o que se pretende testar e, a partir daí, chegar ao nome adequado.
Se quiseres realizar testes em cada implementação, adiciona pentest contínuo com Aikido Infinite
Para as organizações que necessitam de testes contínuos, oAikido Infinite permite realizar testes de penetração de forma contínua à medida que a aplicação sofre alterações. Utiliza a última avaliação completa como referência e monitoriza as ramificações que configurar. Quando uma alteração parece ser relevante em termos de segurança, o sistema lança agentes específicos, quer no momento da implementação, quer de acordo com um calendário definido por si.
Antes de ativar a funcionalidade, certifique-se de que as pessoas certas têm as permissões necessárias, de que os ramos ou a programação correspondem à forma como a sua equipa lança as versões, de que os agentes continuam a conseguir aceder à aplicação e de que dispõe de créditos suficientes para os testes previstos. Os repositórios também têm de estar ligados, uma vez que o Infinite os consulta para determinar quais as alterações que necessitam de ser testadas.
Como integrar os resultados d pentest de IA o no seu fluxo de trabalho de segurança
As suas ferramentas SAST e SCA continuam a fazer o que sabem fazer: identificar código de risco e dependências vulneráveis. O teste de penetração responde a uma questão diferente: o que é que um atacante pode realmente explorar na aplicação em execução. Isso inclui falhas que a análise estática não consegue detetar, como controle de acesso quebrado, ou a falsificação de assinaturas eletrónicas Aikido que os agentes encontraram numa aplicação de assinatura de documentos e que uma equipa de análise manual não detectou.
Cada descoberta é validada por agentes adicionais para excluir falsos positivos e confirmar a explorabilidade, pelo que os resultados dos testes de penetração podem passar diretamente para o topo da fila sem necessidade de uma triagem manual. Cada descoberta inclui também uma prova de conceito e passos de reprodução, o que significa que um programador pode confirmar o problema sem ter de recorrer à equipa de segurança para obter contexto. As descobertas são apresentadas com uma classificação de gravidade e um tempo estimado para correção, o que permite à equipa definir prioridades e atribuir a correção diretamente aos programadores.
Como corrigir e voltar a testar as conclusões dos testes de penetração com IA
Um teste de penetração que contribui para uma lista de tarefas já sobrecarregada só vem aumentar a pilha; por isso, decida para onde vão as conclusões e quem é o responsável por elas antes da primeira execução. Numa configuração simples, a equipa cria um item de trabalho no seu sistema de acompanhamento existente para cada conclusão, associa-o à conclusão « Aikido » e atribui-o ao programador responsável pelo código afetado.
A correção passa então pelo processo normal de revisão de código e é implementada no ambiente de teste, onde a falha é testada novamente. Os resultados dos novos testes fornecem provas de que o problema foi resolvido, algo que uma pull request incorporada, por si só, não consegue comprovar. Se pretender a criação automática de tickets ou a sincronização de estados, experimente-o com uma falha real identificada num teste de penetração antes de o implementar em todas as equipas. O guia prático sobre testes de penetração em CI/CD aborda este fluxo de trabalho de início a fim.
O que decidir antes do seu primeiro teste de penetração com IA
- Âmbito: No caso de testes de penetração em aplicações web e APIs (abordaremos outros domínios num artigo futuro), comece por enumerar o que precisa de ser testado, o que normalmente significa aplicações específicas, servidores, APIs e as funções dos utilizadores que lhes acedem. É importante incluir cada função, porque muitas das falhas mais graves, como um utilizador aceder aos dados de outro utilizador, só se revelam quando o teste consegue iniciar sessão como mais do que um tipo de utilizador. Terá também de decidir se pretende incluir todo o seu perímetro exposto à Internet ou se prefere que o primeiro teste se concentre numa única aplicação.
- Acesso: Um teste de penetração com IA só consegue testar aquilo a que tem acesso, pelo que necessita de credenciais para todas as funções abrangidas pelo âmbito do teste. Terá também de decidir se pretende integrar o código-fonte. Com acesso ao código, o teste consegue identificar o ficheiro e a linha exatos de uma falha, o que agiliza a correção. Sem esse acesso, o teste funciona da mesma forma que um atacante externo o faria, apenas a partir da aplicação em execução.
- Cadência: Um teste de penetração pontual fornece uma visão pontual da situação, que é frequentemente o que um auditor ou uma análise de segurança de um cliente solicita. Os testes contínuos associados às implementações verificam cada versão à medida que esta é lançada, pelo que um novo terminal é testado antes de estar em funcionamento há meses. A escolha certa depende da frequência com que a sua aplicação sofre alterações e de quem solicita os resultados.
- Responsabilidades: Decida quem configura os testes, quem tem acesso aos resultados, quem pode solicitar novos testes e quem aprova as correções antes de os primeiros resultados serem divulgados. Os resultados dos testes de penetração abrangem frequentemente várias equipas, pelo que definir estas responsabilidades desde o início evita que um resultado crítico fique por ler, porque todos partiram do princípio de que outra pessoa se encarregaria disso.
- Custo: O preço depende do número de avaliações que realizar ou da quantidade de testes contínuos que utilizar. Como se baseia na utilização, pode adaptá-lo ao âmbito que escolheu e ajustá-lo à medida que esse âmbito for mudando. Consulte os preços atuais dos testes de penetração para obter mais detalhes.
Aikido pentest de IA para aplicações web e o resto da plataforma de segurança « Aikido »
Um teste de penetração com IA numa aplicação web é uma das formas como a Aikido Security utiliza agentes autónomos para identificar vulnerabilidades, sendo que cada um testa algo que os outros, por razões estruturais, não conseguem. Os melhores resultados obtêm-se ao combiná-los em camadas, de modo a que cada um seja executado onde for mais económico e mais útil.
SAST como padrão: o SAST determinístico é executado em cada commit e no IDE, identificando padrões conhecidos, como a injeção, sempre da mesma forma. É suficientemente rápido e económico para controlar o fluxo de trabalho de CI/CD, o que o torna a base sobre a qual tudo o resto se assenta. No entanto, não consegue avaliar a intenção, pelo que falhas lógicas como IDORs e controle de acesso quebrado são deixadas para as camadas acima dele.
Auditoria de segurança do código para novas aplicações e versões principais: a Auditoria de Segurança de Código analisa toda a base de código, seguindo uma solicitação desde o manipulador de rota até à consulta à base de dados e verificando se o código faz o que é suposto fazer. Só necessita de acesso ao repositório, pelo que deteta falhas lógicas antes de existir um alvo ativo para testar, incluindo código por trás de sinalizadores de funcionalidades e rotas exclusivas para administradores que um teste de penetração poderá nunca alcançar. Isso torna-a o primeiro passo natural numa nova aplicação ou antes de uma versão importante.
Revisão Aprofundada de PR para acompanhar o ritmo entre lançamentos: a Revisão Aprofundada de PR aplica o mesmo raciocínio a todos os pedidos de pull, verificando como cada alteração interage com o código noutras partes do repositório e em repositórios associados. Deteta as falhas lógicas que, de outra forma, surgiriam no próximo teste de penetração ou em produção, enquanto o programador que escreveu a alteração ainda se lembra da razão pela qual a escreveu dessa forma.
pentest de IA com uma frequência que se adapte ao seu nível de risco: o teste de penetração valida tudo isto em relação à aplicação em execução, e o âmbito é garantido através de controlos técnicos que mantêm os agentes em alvos incluídos na lista de autorizações e fora do ambiente de produção, a menos que tal seja deliberadamente definido como parte do âmbito.
A frequência com que o executa depende dos seus requisitos regulamentares e do grau de sensibilidade do seu setor. A maioria das equipas realiza testes anualmente ou aquando de lançamentos importantes, muitas vezes para cumprir as normas SOC 2 ou ISO 27001. As equipas em setores regulamentados ou de alto risco, que necessitam de verificar a vulnerabilidade à medida que a sua aplicação sofre alterações, utilizam oAikido Infinite, que realiza testes em cada implementação, e oAikido Machine, que executa os mesmos testes de penetração no local para setores em que o código não pode sair da sua rede. Os testes de penetração na rede externa abrangem todos os recursos expostos à Internet sob o seu domínio.
As conclusões são diretamente integradas no processo de correção. Quando possível, o AutoFix propõe alterações no código para as conclusões dos testes de penetração, e os programadores analisam-nas e incorporam-nas, realizando depois novos testes para confirmar se a correção funcionou. As equipas podem começar apenas com o pentest de IA e adicionar as outras camadas mais tarde, tal como a Tyro fez quando integrou o resto dos seus testes de aplicações no Aikido , a par dos seus testes de penetração.
{{walkthrough}}
