Alexandra Svatikova trabalha como especialista em segurança da informação em Odnoklassniki. Há mais de 8 anos, ela passou de desenvolver em Java para testar a segurança de aplicativos.
Nós a entrevistamos onde discutimos:
- É difícil para um desenvolvedor mudar para a análise de aplicativos?
- diferenças no desempenho do pentester, do pesquisador e do analista;
- ciclo de vida de desenvolvimento de segurança ou SDLC;
- o papel do homem na busca de vulnerabilidades;
- como estão as análises de segurança em outras empresas.
Não haverá nenhum incômodo neste artigo - você pode segui-lo até o Heisenbug 2019 em Moscou , onde Alexandra falará sobre testes de segurança estática. Iremos ao relatório dela no final do post, mas, por enquanto, seja bem-vindo ao gato.
Fazer login na segurança do aplicativo não é tão difícil quanto parece
"Para quem você estudou?" Por que você se envolveu na segurança de aplicativos?
- Provavelmente não sou um exemplo a seguir (risos) . Estudei como programador e algo como "engenharia de software" está escrito no diploma. Trabalhou primeiro como desenvolvedor móvel e depois mudou para desenvolvimento web em Java. Depois de encontrar outro emprego como programador Java, entrei na equipe que lida com segurança de aplicativos - mantendo a parte do desenvolvimento relacionada à segurança. Havia um processo bem organizado e formulado, e eles precisavam de pessoas para fazer revisões de código e analisadores estáticos. Dessa forma, eles estavam procurando um programador Java e estavam prontos para lhe ensinar segurança. Pareceu-me interessante, então fiquei.
- O que você acha que vai ficar nesta área por um longo tempo ou algo seguirá mais esta etapa?
- Acho que vou ficar para sempre, porque sou analista de segurança de aplicativos desde 2011. Eu já tenho menos experiência em desenvolvimento, ao que parece. O programador não deve ter medo de tarefas rotineiras, corrigir bugs, mas o especialista em segurança tem uma especificidade diferente, isso me atrai mais.
- Que áreas adicionais, em comparação com o desenvolvimento convencional, você teve que dominar?
- No início da minha carreira, eu estava testando. Isso define bem o seu cérebro: você vê o sistema na forma não de um monte de código, mas de um organismo, que pode ser influenciado de maneiras diferentes. Portanto, testadores e desenvolvedores têm uma diferença de pensamento.
Por exemplo, 10 a 15 anos atrás, acreditava-se que os testadores deveriam quebrar o sistema e encontrar o bug de qualquer maneira. Às vezes, os profissionais de segurança precisam ter um ponto de vista semelhante. Então, você precisa entender como o sistema funciona como um todo.
Alguns desenvolvedores estão concentrados nos detalhes: eles sabem como uma parte do sistema funciona, mas não entendem como tudo interage. Por exemplo, ele sabe como o JS é executado em um navegador, mas o desenvolvedor não sabe como esse navegador funciona mais e se comunica com o servidor, por que isso é organizado dessa maneira. O testador deve olhar do ponto de vista de um pássaro para avaliar as interconexões dos componentes, alterações fracas ou quaisquer vulnerabilidades.
- E alguma coisa de engenharia, por exemplo, pilhas de rede, você teve que aprender do zero? Por exemplo, como JS, front, backing funciona?
- Em princípio, eu já era desenvolvedor full-stack, então entendo como o back-end e o front-end funcionam. Você precisa ter uma certa perspectiva, mas o aprofundamento dos detalhes já depende do que você está fazendo. Os mesmos desenvolvedores e testadores, dependendo do projeto, conhecem algum tipo de coisa do sistema (por exemplo, protocolos de rede) ou sabem mais sobre o frontend. Depende das circunstâncias.
- Quão realista parece a você que um desenvolvedor de pilha cheia abstrato ou um testador de pilha cheia, envolvido em programação, automação e teste, passará para a análise de aplicativos, ou seja, o que você está fazendo?
- É fácil para um testador. Certifique-se de ter algumas habilidades de programação e entender como o sistema é construído por dentro. Mas um bom testador sem isso não existe mais. Se for esse o caso, surge a questão da especialização: ele precisa ler sobre segurança e certas tecnologias (por exemplo, Android ou suporte), ou seja, o que ele está tentando encontrar vulnerabilidades.
Os desenvolvedores vêem sua participação no processo um pouco diferente. Portanto, para o desenvolvedor, isso é uma revolução, uma visão diferente da profissão. É importante para o desenvolvedor que algo funcione, mas será difícil para ele quebrar.
Pentester, rescher e analista de segurança de aplicativos: qual é a diferença
- Pelo que entendi, sua especialização está relacionada a pentesters. Como os pentesters e os pesquisadores de vulnerabilidade do dia zero se comparam, ou estão todos misturados em uma única garrafa e é realmente difícil descobrir quem é quem?
- Não há uma divisão clara em postagens. Mas vou lhe dizer quais termos a parte usa.
Existem olheiros que pesquisam um produto, tecnologia, protocolo, servidor, na tentativa de encontrar um problema interessante. Interessante refere-se a um problema que não foi encontrado anteriormente, ou foi identificado em um local inesperado, ou é uma combinação complexa de problemas conhecidos anteriormente. Posso dizer que, como regra, todos os tipos de vulnerabilidades de 0 dias são encontrados por olheiros.
Pentest é um serviço. Você tem um sistema e deseja encontrar vulnerabilidades. A tarefa dos pentesters é penetrar no sistema. Eles não serão capazes de encontrar todos os problemas em potencial. Por exemplo, uma vulnerabilidade pode ser mitigada por outros mecanismos de segurança em diferentes níveis. O Pentester procurará o que realmente está sendo explorado e, depois disso, emitirá um relatório e sairá, porque não tem a tarefa de aumentar a segurança do sistema ou ajustar os processos de desenvolvimento.
Também existem análises de segurança de aplicativos ou de segurança de produtos. Pelo contrário, olham o sistema por dentro. A tarefa deles é tornar o sistema seguro. Isso significa que eles têm informações sobre o sistema e não é uma "caixa preta" para eles. Por outro lado, eles classificam os problemas de maneira diferente. Os analistas até consideram vulnerabilidades que não podem ser exploradas no momento. Por exemplo, existe um buraco crítico no painel do administrador e é claro que ele é acessível apenas a partir da rede interna e, portanto, não é muito assustador. Mas o insider entende que, sob certas circunstâncias, uma coisa terrível pode acontecer.
Os analistas estão mais focados em apoiar o processo. Se os pentesters encontrarem 20 bugs e sairem, e os desenvolvedores no processo de correção de bugs fizerem o mesmo, os pentesters não ajudarão aqui. Portanto, entender o número de vulnerabilidades no sistema será relevante apenas naquele momento.
- Então o analista de segurança de aplicativos faz isso no processo, dia a dia?
- Sim, e ao mesmo tempo, a atividade é direcionada em duas direções. Por um lado, você precisa procurar por vulnerabilidades existentes e combatê-las. Por outro lado, há uma tarefa para tornar o sistema mais seguro.
Isso pode ser abordado de diferentes maneiras. Por exemplo, crie o processo de desenvolvimento para que haja menos erros ou eles sejam rapidamente detectados. Ou implemente mecanismos que reduzam o risco de que a vulnerabilidade caia em produção. Existem várias maneiras de garantir a segurança do sistema.
- Então, o trabalho de análise de segurança de aplicativos está intimamente conectado às equipes e ao processo de desenvolvimento exatamente dentro?
- Sim, um analista de segurança de aplicativos deve fazer uma pergunta sobre o processo de desenvolvimento. O SDLC (Secure Development LifeCycle) é a primeira palavra da moda a ser encontrada ao ler sobre segurança de aplicativos. Em suma, o objetivo dessas ações é garantir que as considerações de segurança do sistema sejam levadas em consideração em cada estágio do desenvolvimento. Nesse caso, nem sempre é um especialista em segurança envolvido na execução de tarefas específicas; às vezes você pode delegar para outros membros da equipe. Afinal, quanto mais cedo você encontrar um problema, mais barato será corrigi-lo.
A mente humana ainda é indispensável para encontrar vulnerabilidades
- Problemas com o produto podem ser encontrados no nível da especificação, sua discussão, protótipo, esboço, quando não há uma única linha de código. Mas questões de segurança em que estágio é possível encontrar? E é possível encontrá-los antes mesmo de escrever o código?
- Claro, porque há problemas diretamente relacionados à forma como os requisitos são formulados. Deixe-me dar um exemplo selvagem. Você cria um formulário de login e o designer diz: "e permita que nossos usuários digam que eles não apenas digitaram a senha errada, mas que cometeram um erro na última letra da senha". Ou seja, a redação do requisito pode ser inerentemente insegura.
Além disso, no estágio de TK, pode-se supor que o sistema estará sujeito a certas vulnerabilidades e que alguns mecanismos de proteção terão que ser implementados. Se você seguir o mesmo formulário no site, precisará fazer um captcha para evitar a adivinhação de senha. Portanto, esses pontos devem ser mencionados no desenvolvimento da arquitetura.
- Com que frequência os testes de segurança são incorporados nos processos de CI / CD e isso é difícil? Ou seja, para poder "rasgar" qualquer pipeline no Jenkins ou no TeamCity, e havia um estágio separado em que os testes de segurança são executados. Quão real é isso?
- Existem diretrizes para o mesmo SDLC, há requisitos dos reguladores. Consequentemente, as empresas que possuem um processo de desenvolvimento maduro as implementam. Existem ferramentas para automatizar parte do processo, mas a proporção do esforço e do resultado depende da natureza do projeto e em que estágio do desenvolvimento essas técnicas começaram a ser implementadas.
Se o aplicativo foi escrito do zero, você pode usar um analisador estático para evitar instruções duvidosas no código. E, se dez anos antes de você escrever o código e você chegou lá com sua ferramenta por dinheiro maluco, é claro que encontrará um pouco.
Todas as ferramentas automáticas têm o problema de não saber de imediato como o sistema funciona. Se um componente individual do sistema puder ser isolado, ele poderá ser testado com ferramentas prontas. Mas em um sistema com muitas dependências, os scanners automatizados podem perder informações valiosas.
Análise de segurança em outras empresas
- Qual empresa ou qual projeto individual, na sua opinião, é o principal em análise de segurança de aplicativos, com base em discursos da empresa e apresentações em conferências?
- A Microsoft surgiu com a implementação do SDLC, que se tornou o cânone. Mas eis como eles funcionam no nível mais baixo, quais ferramentas são usadas, eu não sei.
O Facebook escreve muito sobre como tudo é organizado tecnicamente: como eles digitalizam códigos, encontram vulnerabilidades em sistemas de trabalho etc. Algumas ferramentas do Facebook são até projetos de código aberto, para que você possa se aprofundar mais.
Se pegarmos empresas russas, o Sberbank falou interessante sobre como formalizaram o SDLC, documentando o processo. Embora a equipe de segurança de aplicativos seja bastante grande, não é suficiente para muitos desenvolvedores. Portanto, eles educam os campeões de segurança em equipes, colocam algum conhecimento sobre segurança em suas cabeças e, nesse caso, os campeões podem levantar uma bandeira vermelha.
Yandex fala em conferências sobre coisas legais como "como invadir um navegador".
- É realista que o testador após a conferência, onde ouviu um relatório sobre ameaças e ferramentas, tenha um efeito significativo após sua implementação? Por exemplo, uma empresa comprará um scanner por US $ 10.000 que procura buracos no oleoduto Jenkins. Ou é mais importante conhecer a mecânica da exploração de vulnerabilidades para implementar algumas coisas?
- Você não pode comprar um scanner por 10 mil dólares (risos) . Se falamos sobre a busca por vulnerabilidades, tudo se resume a testar cenários específicos. Os cenários são retirados de coleções de conhecimentos gerais.
Por exemplo, o OWASP (Projeto de segurança de aplicativos da Web abertos) publica guias sobre como realizar testes de segurança, revisões de código etc. Por exemplo, no OWASP Application Security Verification Standard, está escrito sobre tudo o que precisa ser testado. Para ler o documento, não é necessário conhecimento especial, basta saber sobre aplicativos da Web, para que qualquer testador possa lidar com isso.
As folhas padrão e de dicas são suficientes para executar testes manuais. Ele diz que tipos de vulnerabilidades existem e como procurá-las. Alguns testes não podem ser executados por scanners padrão por definição: por exemplo, aqueles relacionados à verificação da lógica de negócios.
Por outro lado, se você precisar encontrar o XSS, será necessário adicionar aspas, colchetes etc. em todos os parâmetros alterados e, se houver 100 milhões de parâmetros no sistema, a tarefa não será mais possível. Mas ferramentas automatizadas se sairão bem com ela.
Mas quando você inicia o scanner, pode haver três cenários:
- A ferramenta publicou um relatório em que existem muitos erros reproduzíveis bons e um pouco de falso positivo (ideal, mas improvável).
- O relatório contém 20 mil descobertas, das quais cerca de 1% são verdadeiras. Portanto, você tem que sentar e determinar se os problemas reais.
- A ferramenta não conseguiu entender algo no sistema, portanto, emitiu um relatório em que está tudo bem, mas não está. Por exemplo, não consegui compilar o código porque não consegui encontrar a biblioteca. Ou é um scanner de vulnerabilidades que fez 10 solicitações, correu para o anti-flood e não recebeu uma resposta do servidor pelos milhões restantes de solicitações.
Portanto, acho importante entender, no entanto, que o scanner está "sob o capô" para selecionar a ferramenta correspondente à tarefa que está sendo resolvida e avaliar adequadamente o resultado.
Alexander desenvolverá o tópico da escolha certa e do ajuste das ferramentas em seu relatório sobre a Heisenbug. Lá, ela falará sobre a aplicação e personalização das soluções SAST SonarQube e Find Security Bugs para procurar vulnerabilidades em seu projeto. Quais recursos essas ferramentas fornecem "prontas para uso"? E como expandir suas funcionalidades por conta própria? Como exemplo, o palestrante considerará as vulnerabilidades do XSS e do IDOR.
A conferência será realizada de 5 a 6 de dezembro em Moscou.