Close

Abordagem em relação aos testes de segurança externos


A Atlassian recebe, com frequência, pedidos para divulgar relatórios de testes de intrusão por parte de clientes em busca de garantias da eficácia dos processos para identificar (e corrigir) vulnerabilidades de segurança nos produtos e no Cloud da Atlassian. A gente tem uma estratégia de testes de segurança externos estruturada em torno do conceito de "garantia contínua": em vez de fazer um teste de intrusão em um momento específico, a gente segue um modelo de testes permanentes, oferecendo recompensas por bug por meio de crowdsourcing.

Filosofia e abordagem da Atlassian

A Atlassian é muito conhecida pelos valores, que influenciam de verdade tudo o que a gente faz, inclusive a estratégia de testes de segurança. Na prática, esses valores conduzem até as seguintes filosofias e estratégias:

  • Bugs são inevitáveis do processo de desenvolvimento. A questão não é se a gente tem bugs, mas com que eficiência e rapidez eles são encontrados e solucionados. Isso não significa que a gente gosta de bugs ou não está sempre buscando novas maneiras de reduzir a frequência e gravidade deles. Mas, quando se trata de bugs de software, a negação não é uma boa ideia.
  • O objetivo da Atlassian é aumentar o custo de localização e exploração de vulnerabilidades dos produtos e serviços. Ao identificar e solucionar com rapidez os problemas, a tendência é aumentar o custo econômico de encontrar bugs de segurança. Aumentando o custo de exploração de uma vulnerabilidade (fazendo com que dure mais, exigindo mais conhecimento e mais recursos dos vilões), seu retorno sobre o investimento cai. Se esse retorno diminuir o bastante, vai se tornar proibitivo ou nada atraente para eles.
  • A Atlassian apoia e usa as normas do setor. A padronização na terminologia e na estratégia ajuda a garantir que a gente não está esquecendo de nada e ajuda os clientes a entenderem o que a gente faz. Por exemplo, as classificações de vulnerabilidades comuns que usam o Common Vulnerability Scoring System (CVSS) garantem clareza no entendimento da gravidade de uma vulnerabilidade específica para a gente e para os clientes. Os processos de gerenciamento de vulnerabilidades descritos na ISO 27001 e na Cloud Security Alliance (CSA) também são seguidos. 
  • Os pesquisadores de segurança externos são uma extensão valiosa da equipe. Se um produto da Atlassian apresentar alguma vulnerabilidade, é do interesse de todos (da Atlassian e dos clientes) que seja encontrada e resolvida o mais rápido possível. Esses pesquisadores, que ajudam a fazer esse trabalho, são uma extensão valiosa da equipe de segurança da Atlassian e devem ser devidamente recompensados. Com a ajuda deles, é possível adaptar a equipe muito além das estratégias tradicionais!
  • A Atlassian é sincera e transparente com relação ao programa de testes de segurança. O programa de recompensas por bugs mostra estatísticas sobre os bugs encontrados, a velocidade com que se tenta corrigir bugs de segurança não é segredo e a gente disponibiliza relatórios com resumo dos testes, quando possível.
     

Garantia de segurança contínua

Teste de intrusão

A gente recorre a empresas de consultoria especializadas em segurança para concluir os testes de intrusão em infraestruturas e produtos de alto risco. Pode ser uma nova infraestrutura configurada para a gente (por exemplo, o ambiente Cloud), um novo produto (como o Trello) ou uma rearquitetura fundamental (como o amplo uso de microsserviços). 

Nesses casos, a estratégia de testes de intrusão é bastante direcionada e concentrada. Em geral, esses testes são:

  • Caixa branca: quem testa vai receber a documentação do projeto e instruções dos engenheiros de produto para embasar o teste
  • Baseados no código: quem testa vai ter acesso total à base de códigos em questão para auxiliar no diagnóstico de um comportamento de sistema inesperado durante o teste e para identificar possíveis alvos
  • Baseados em ameaças: o teste tem como foco uma situação de ameaça em particular, como presumir a existência de uma instância comprometida e testar o movimento lateral do ponto de partida

A gente publica Cartas de Avaliações (Letters of Assessment, LoA) de parceiros de Teste de Intrusão, disponíveis para uso externo na parte inferior desta página. Pela grande quantidade de informações internas disponíveis a quem testa durante essas avaliações, não são oferecidos relatórios completos. A maioria desses sistemas e produtos vai ser, em outro momento, incluída no programa de recompensas por bugs, a garantia externa contínua que os clientes buscam. Todas as descobertas dessas avaliações passam por triagem e são solucionadas de acordo com o SLA de Vulnerabilidade de Segurança Pública

Recompensas por Bugs

O programa de recompensas por bugs da Atlassian é hospedado pelo Bugcrowd. O objetivo desse programa é garantir que os produtos sejam testados sempre para buscar vulnerabilidades de segurança. Esta é a peça central do programa de testes de segurança externos da Atlassian e o resultado de pesquisa, análise e comparação significativas entre modelos de testes.

A gente acredita que o grupo de pesquisadores independentes que participa do programa de recompensa por bugs oferece o processo de testes externos de segurança mais eficaz porque:

  1. Uma recompensa por bugs está sempre ativa. Em geral, os testes de intrusão são limitados a algumas semanas. Em um ambiente de desenvolvimento ágil de verdade, com lançamentos frequentes, o teste contínuo é uma necessidade. 
  2. Uma recompensa por bug atrai mais de 60.000 pessoas que fazem teste em potencial. Os testes de intrusão, no geral, são feitos por uma ou duas pessoas. Não importa se esses indivíduos são bons ou não; eles jamais vão superar a capacidade total da equipe do programa de recompensas por bugs.
  3. Os pesquisadores que buscam recompensas por bugs desenvolvem ferramentas especializadas e têm processamentos verticais (tipos de bugs específicos) e horizontais (recompensas específicas). Essa especialização oferece uma chance maior de identificar vulnerabilidades obscuras, mas significativas.

A Atlassian vai continuar usando testes de intrusão e consultores de segurança especializados para suporte interno. No entanto, para o programa externo de cobertura ampla, uma recompensa por bugs é a melhor saída. A combinação de estratégias aumenta as chances de encontrar vulnerabilidades. 

Mais de 25 dos produtos ou ambientes da Atlassian, abrangendo produtos de servidor, aplicativos móveis e produtos Cloud, estão no escopo do programa de recompensa por bugs. As informações sobre o número de vulnerabilidades relatadas, o tempo médio de resposta e a média de pagamento são encontradas no site do Bugcrowd, com mais de 800 pessoas que fazem teste registradas em específico no programa da Atlassian.

Entre as vulnerabilidades que o programa de recompensas por bugs busca identificar, estão os tipos comuns capturados no Projeto Aberto de Segurança em Aplicações Web (OWASP) e nas listas de ameaças do Web Application Security Consortium (WASC). Isso inclui:

  • Acesso/vazamento de dados entre instâncias
  • Execução Remota de Código (RCE)
  • Server-Side Request Forgery (SSRF)
  • Cross-site Scripting (XSS)
  • Cross-site Request Forgery (CSRF)
  • SQL Injection (SQLi)
  • XML External Entity (XXE)
  • Vulnerabilidades no controle de acesso (problemas de referência direta de objetos inseguros, etc.)
  • Problemas transversais de diretório/caminho

Como parte da iniciativa de sinceridade e transparência da Atlassian, todos estão convidados a visitar a página do programa de recompensas por bugs, se inscrever e nos testar.

Relatórios de vulnerabilidade

Quando uma vulnerabilidade é identificada por um dos usuários durante o uso normal de um produto (em vez de ser identificada em uma tentativa específica para testar o sistema, o que a Atlassian exige que ocorra por meio do programa de recompensas por bugs), a Equipe de Suporte da Atlassian agradece a notificação e responde de imediato a todas as vulnerabilidades enviadas, mantendo os interessados atualizados durante a investigação e solução do item.

Antes de divulgar um item, a gente pede que os pesquisadores primeiro solicitem permissão. A Atlassian processa as solicitações de divulgação ao público por relatório. Elas só vão ser consideradas após a vulnerabilidade relatada ter sido corrigida.

Exclusões dos nossos programas de testes de segurança

A gente é sincera e clara sobre os testes que faz, assim como sobre os testes que a gente não faz, ou sobre aqueles que não têm suporte no momento. Estão excluídos do programa de testes de segurança:

Apps do Marketplace — os apps do Marketplace são estritamente excluídos do programa de recompensas por bugs e a gente não conclui a análise de códigos ou os testes de segurança neles. A Atlassian vai transmitir todas as vulnerabilidades do aplicativo informadas, mas elas não vão valer recompensas.

Testes iniciados por clientes — 

Seguindo os Termos de Uso dos produtos de nuvem, a partir de agora, a gente permite testes iniciados por clientes. A gente tem o compromisso de ser sincera e vai continuar a publicar estatísticas do programa de recompensas por bugs com frequência. 

A gente acredita que a Recompensa por Bugs é um método mais eficiente e econômico para avaliar a segurança dos produtos e serviços, mas entende que, talvez, você queria testar a segurança por conta própria. A gente permite a realização de avaliações de segurança (testes de intrusão e avaliações de vulnerabilidade) por parte dos clientes. A gente só pede que você siga algumas regras para que todos permaneçam seguros. Se quiser comunicar um item que tiver encontrado, a gente tem instruções sobre como relatar uma vulnerabilidade no site.

Certos tipos de vulnerabilidade de baixo risco — os produtos da Atlassian são desenvolvidos para desenvolver o potencial de cada equipe, o que requer colaboração. No geral, vulnerabilidades relacionadas à enumeração e à coleta de informações não são consideradas riscos graves.

Medindo aquilo que importa

A gente tem uma política de atualização de segurança que funciona como um Acordo do Nível de Serviço (SLA) interno entre as equipes de produto e de segurança. Ao categorizar os bugs, a gente usa o Common Vulnerability Scoring System (CVSS versão 3), que ajuda a comunicar a gravidade das vulnerabilidades aos clientes. A gente tenta cumprir os seguintes prazos para corrigir problemas de segurança:

  • Os bugs de gravidade crítica (nota >= 8 no CVSS v2 e nota >= 9 no CVSS v3) devem ser corrigidos no produto dentro de 4 semanas após serem relatados.
  • Os bugs de gravidade alta (nota >= 6 no CVSS v2 e nota >= 7 no CVSS v3) devem ser corrigidos no produto dentro de 6 semanas após serem relatados.
  • Os bugs de gravidade média (nota >= 3 no CVSS v2 e nota >= 4 no CVSS v3) devem ser corrigidos no produto dentro de 8 semanas após serem relatados.

Esses cronogramas são reavaliados todo ano e ajustados conforme necessário, com base no ambiente de ameaças em constante mudança.

Além disso, considerando o objetivo de aumentar o custo para encontrar e explorar vulnerabilidades em nossos produtos, é necessário quantificar esse custo. A gente usa a "recompensa" oferecida aos pesquisadores de segurança para encontrar uma vulnerabilidade como um proxy. Em termos práticos, ao longo do tempo, o número de bugs identificados através do programa de recompensas por bugs deve diminuir e, quando isso acontecer, vai ser necessário aumentar a quantia paga por eles se a gente quiser que os relatórios continuem chegando. Se, no fim das contas, a quantidade de esforço necessário para encontrar uma vulnerabilidade com uma recompensa de US$ 3.000,00 acabar não valendo a pena (já que o esforço vale mais do que US$ 3.000,00), vai ser preciso aumentar o custo para encontrar essa vulnerabilidade.  

Em outras palavras, você vai ver os pagamentos de recompensas aumentarem com o tempo.

Um breve resumo

A Atlassian tem um programa de testes de segurança externo transparente, aberto e maduro, estruturado em torno de recompensas por bugs.

Quer saber mais?

Neste breve artigo, a gente mencionou um bocado de documentos e recursos. É recomendável que você se aprofunde neles para compreender melhor a estratégia da Atlassian em relação aos testes de segurança. 

Baixe os relatórios atuais de recompensas por bugs

Todas as vulnerabilidades identificadas nos relatórios abaixo são monitoradas no Jira interno conforme chegam pelo processo de recolhimento de Recompensas por Bugs. Todas as descobertas das Recompensas por Bugs passam por triagem e são solucionadas de acordo com o SLA de Vulnerabilidade de Segurança Pública.

Baixe as Cartas de Avaliação (LoA)

Todas as vulnerabilidades de segurança identificadas nos relatórios abaixo são monitoradas no Jira interno conforme chegam pelo processo de relatórios do teste de intrusão. Todas as descobertas dessas avaliações passam por triagem e são solucionadas de acordo com o SLA de Vulnerabilidade de Segurança Pública.