Close

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


A Atlassian recebe pedidos regulares para divulgar relatórios de testes de intrusão por parte dos clientes que procuram saber sobre a garantia dos processos para identificar (e corrigir) vulnerabilidades de segurança no Cloud e nos produtos da Atlassian. Com a abordagem de testes de segurança externos, estruturada em torno do conceito de "garantia contínua", em vez de um teste de intrusão em momentos específicos, o modelo de testes usado está sempre ativo e funcionando, além de oferecer uma recompensa por bugs via crowdsourcing.

 

Filosofia e abordagem da Atlassian

A Atlassian é muito conhecida por seus valores. Eles realmente influenciam tudo o que fazemos, incluindo a nossa abordagem para testes de segurança. Na prática, esses valores conduzem às seguintes filosofias e abordagens:

  • Bugs são uma parte inevitável do processo de desenvolvimento. A pergunta não é se temos bugs, mas sim 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á constantemente buscando novas maneiras de reduzir sua frequência e gravidade. Porém, quando se trata de bugs de software, a negação não é uma abordagem eficaz.
  • 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 ela dure mais e exigindo maior conhecimento e mais recursos dos caras maus), 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 os padrões do setor. A padronização na terminologia e abordagem ajuda a garantir que a gente não está esquecendo de nada e ajuda os clientes a entender o que a gente faz. Por exemplo, as classificações de vulnerabilidades comuns usando o Common Vulnerability Scoring System (CVSS) garantem clareza no entendimento da gravidade de uma vulnerabilidade específica entre a gente e 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 da Atlassian e dos clientes que ela seja encontrada e resolvida o mais rápido possível. Os pesquisadores de segurança externos 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 dimensionar a equipe muito além das abordagens tradicionais!
  • A Atlassian é aberta e transparente com relação ao programa de testes de segurança. O programa de recompensa por bugs traz estatísticas sobre bugs encontrados, a velocidade com que tentamos corrigir bugs de segurança não é segredo e os relatórios resumidos dos testes são disponibilizados, quando possível.

 

Garantia de segurança contínua

Testes de intrusão

Usamos empresas de consultoria especializadas em segurança para concluir os testes de intrusão em infraestruturas e produtos de alto risco. Eles podem ser ser uma nova infraestrutura configurada para nós (por exemplo, o ambiente Cloud), um novo produto (como o Trello) ou uma rearquitetura fundamental (como o uso extensivo de microsserviços). 

Nesses casos, a Atlassian tem uma abordagem para testes de intrusão extremamente direcionada e focada. Em geral, esses testes são:

  • Caixa branca: os testadores vão receber a documentação do projeto e os briefings dos nossos engenheiros de produtos como base para os testes
  • Código assistido: os testadores vão ter acesso completo à base de códigos relevantes para ajudar a diagnosticar qualquer comportamento inesperado do sistema durante o teste e para identificar possíveis alvos
  • Com base em ameaças: o teste vai se concentrar em um cenário de ameaça específico. Por exemplo, presumir que uma instância comprometida existe e testar o movimento lateral a partir desse ponto inicial

Não disponibilizamos esses relatórios ou extratos para consumo externo devido à grande quantidade de informações disponibilizadas aos testadores durante a realização dessas avaliações.

Em seguida, a maioria desses sistemas e produtos vai ser inclusa em nosso programa público de recompensa por bugs, fornecendo a garantia externa que os clientes procuram.

Bug bounty

O programa de recompensa por bugs da Atlassian é hospedado pelo Bugcrowd. O objetivo desse programa é garantir que os produtos sejam testados constantemente para checar 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.

Acreditamos que o grupo de pesquisadores de segurança independentes que participam 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 testadores em potencial. Os testes de intrusão geralmente têm 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 de participantes 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 continua 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. Acreditamos que a combinação de abordagens 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 testadores registrados especificamente no programa da Atlassian.

O programa de recompensa por bugs é uma tentativa de identificar vulnerabilidades, como os tipos comuns capturados no Projeto aberto de segurança em aplicativos 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)
  • Injeção SQL (SQLi)
  • Ataques de 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 do esforço de abertura e transparência, todos estão convidados a visitar a página do programa de recompensa por bugs, fazer a inscrição no programa e testar os produtos.

Relatórios de vulnerabilidade

Quando uma vulnerabilidade é identificada por um dos usuários durante a execução padrão de um produto (em vez de ser identificada numa tentativa específica de testar o sistema, o que deve ocorrer através do programa de recompensas por bugs), a Equipe de suporte da Atlassian agradece por ser notificada. A Atlassian responde de imediato a quaisquer vulnerabilidades enviadas e mantém os interessados atualizados durante a investigação e solução do problema.

O pesquisadores precisam solicitar a permissão da Atlassian antes de divulgarem um problema ao público. Nós processamos as solicitações para divulgação ao público por relatório. As solicitações de divulgação só vão ser consideradas após a vulnerabilidade relatada ser corrigida.

 

Exclusões do programa de testes de segurança

A Atlassian é sincera e clara com relação aos testes que faz, assim como é igualmente sincera e clara sobre os testes que não faz, ou para os quais não tem suporte atualmente. 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 não é feita a análise de códigos ou testes de segurança neles. A Atlassian vai transmitir quaisquer vulnerabilidades do aplicativo informadas, mas elas não vão valer recompensas.

Testes iniciados pelo cliente - Seguindo o Contrato do cliente, os testes dos ambientes de produção iniciados pelos clientes não são permitidos no momento. O compromisso assumido de transparência e publicação das estatísticas do programa de recompensas por bugs dá aos clientes a certeza de contar com um programa de testes de segurança ativo. Os clientes e seus consultores de segurança podem se inscrever no programa de recompensas por bugs e concluir os testes através desse processo.

Certos tipos de vulnerabilidade de baixo risco - Os produtos da Atlassian são desenvolvidos para estimular o potencial de cada equipe, o que requer colaboração. Em geral, as vulnerabilidades relacionadas à enumeração e coleta de informações não são consideradas riscos significativos.

 

Medição do que importa

Temos uma política de correção de bugs que funciona como um Contrato de nível de serviço (SLA) interno entre as equipes de produtos e de segurança. Ao classificar os bugs, usamos o Common Vulnerability Scoring System (CVSS versão 3), que ajuda a comunicar a gravidade das vulnerabilidades aos clientes. O objetivo é seguir os seguintes prazos para corrigir problemas de segurança:

  • Os bugs de gravidade crítica (CVSS v2 score >= 8, CVSS v3 score >= 9) devem ser corrigidos no produto dentro de quatro semanas após serem relatados.
  • Os bugs de gravidade alta (CVSS v2 score >= 6, CVSS v3 score >= 7) devem ser corrigidos no produto dentro de seis semanas após serem relatados.
  • Os bugs de gravidade média (CVSS v2 score >= 3, CVSS v3 score >= 4) devem ser corrigidos no produto dentro de oito 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. Usamos 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 recompensa aumentarem com o tempo.

 

Resumo

A Atlassian tem um programa de teste de segurança externo, transparente, aberto. maduro e estruturado com base nas recompensas por bugs

 

Baixe os relatórios de testes atuais

Todas as vulnerabilidades de segurança identificadas nos relatórios abaixo são monitoradas no nosso próprio Jira assim que aparecem no processo de captação do programa de Recompensa por Bugs e são concluídas de acordo com o cronograma de SLA que consta na Política de Segurança de Correção de Bugs.

 

Baixe os relatórios de testes atuais

Todas as vulnerabilidades de segurança identificadas nos relatórios abaixo são monitoradas no nosso próprio Jira assim que aparecem no processo de captação do programa de Recompensa por Bugs e são concluídas de acordo com o cronograma de SLA que consta na Política de Segurança de Correção de Bugs.