“
Sempre saiba onde seus dados estão
Isso pode parecer simples (e óbvio), mas muitas vezes nos deparamos com situações em que as restrições sobre onde os dados podem e não podem ir, e as diretrizes sobre quais dados podem ser adicionados a fontes públicas, são ignoradas nas discussões ou processos de projetos, ou, em alguns casos, não são documentadas. Essa falta de clareza deixa as pessoas decidindo por si mesmas o que é aceitável, levando a potenciais riscos de segurança.
Nossas equipes de resposta a incidentes lidaram com vários casos em que desenvolvedores usaram armazenamento e repositórios de acesso público não autorizados ou não documentados. Mesmo quando um repositório é conhecido e aprovado para uso dentro da organização, é crucial definir claramente o que é permitido armazenar ali. As diretrizes sobre o que precisa ser removido de um código-fonte antes de enviá-lo para um repositório público devem ser bem definidas e aplicadas regularmente. Não fazer isso pode criar riscos não gerenciados significativos. Não importa quão fortes sejam suas defesas de segurança cibernética, você não pode proteger os dados se não souber que eles existem.
Resolver a governança relacionada ao armazenamento e fornecer documentação clara do projeto que define os parâmetros para o que pode/não pode ser armazenado publicamente sempre ajudará, assim como o treinamento obrigatório do pessoal para todos os funcionários. Em cima disso, serviços de inteligência de ameaças e varredura de DLP também podem ser usados com eficácia para monitorar e procurar evidências de exposições públicas tanto em locais públicos quanto em seus próprios locais de armazenamento conhecidos – esses são bem dignos de monitoramento e relatórios a longo prazo.
Repositórios de código
Perdi a conta de quantos incidentes lidamos recentemente em que uma violação foi causada pela exposição pública de dados confidenciais. Várias dessas violações ocorreram devido a informações confidenciais armazenadas em repositórios do GitHub de acesso público ou em buckets do Amazon S3.
Frequentemente, esses recursos armazenados continham materiais codificados, como chaves administrativas do AWS para contas de usuário e credenciais de usuário. Em alguns casos, eles até incluíam chaves de API estáticas para serviços públicos que armazenam informações financeiras confidenciais; é praticamente como sinalizar um alvo para ataque e dar ao atacante as chaves da porta.
O uso de repositórios há muito é uma prática padrão para desenvolvedores, tornando essencial que as empresas revisem continuamente seus protocolos de segurança. Não se trata apenas de esperar que os desenvolvedores evitem erros, mas de garantir que existam regras claras e verificações automatizadas para ajudar a prevenir erros também.
Por exemplo, o GitHub oferece ferramentas para varredura de segredos e recursos de segurança avançados que podem ajudar a detectar e evitar que dados confidenciais sejam expostos em seu código-fonte. Implementando esses tipos de salvaguardas, você reduz o risco de informações confidenciais, como chaves de API, serem publicadas inadvertidamente. Sem essas verificações, mesmo os desenvolvedores mais bem-intencionados podem comprometer inadvertidamente a segurança.
Mantenha-o privado
Não estou sugerindo que o GitHub ou outros repositórios de código sejam ruins – longe disso (eles salvaram minha sanidade muitas vezes para que eu os considerasse como tais!). Mas manter a segurança significa que as organizações devem se esforçar para esconder seu código até que seja seguro fazer o contrário.
Com isso em mente, a privacidade deve sempre ser a postura padrão até que verificações apropriadas tenham sido executadas em tudo o que está sendo armazenado. E se você pretende publicar publicamente, certifique-se de completar as verificações de repositório pré e pós-publicação primeiro.
Facilite o relato
Pesquisadores especialistas e caçadores de recompensas de bugs podem fornecer insights valiosos (mesmo que você não os tenha empregado diretamente), desde que você lhes dê um caminho claramente sinalizado para informá-lo sobre qualquer coisa que eles descobrirem. No caso da Fujitsu, Jelle Ursem, um pesquisador de segurança com sede na Holanda, tentou entrar em contato com a empresa, mas descobriu que não conseguia facilmente alcançar a pessoa certa.
Prevenir uma situação semelhante é relativamente simples: configure um formulário de contato em seu site ou use uma caixa de entrada monitorada dedicada para lidar com as descobertas. Você pode até introduzir um programa de recompensas de bugs para recompensar hackers éticos e a comunidade de pesquisa mais ampla por descobrir e relatar vulnerabilidades a você.
De qualquer forma, a chave é ter um método estruturado para trabalhar com outras pessoas para permitir a comunicação de problemas, porque, vamos ser realistas – é sempre preferível a descobrir depois de uma violação. Nesse ponto, normalmente é tarde demais e o dano caro já foi feito.
A realidade é que quanto maior e mais complexa sua organização, mais dados ela terá. Infelizmente, isso aumenta a probabilidade de informações serem expostas acidentalmente. Mas, como acontece com muitas coisas, o planejamento, a educação e as políticas transparentes, bem como o uso de ferramentas apropriadas para verificar contra erros humanos, ajudarão a minimizar o risco.
“