Violações de dados: falha nossa

Sobre o autor: Guilherme Teles é um cara qualquer que não dorme direito e acaba escrevendo. Sou Certificado CISSP, CHFI, CEH, LPIC-3, AWS CDA, AWS SAA, AWS SOA Quer assinar a newsletter do site e receber esse e outros artigos? Clique aqui! Aproveite e navegue pelo smeu blog. Quem sabe você não está exatamente precisando de uma ajuda ?  

Uma parte do meu trabalho é entender o cenário de conformidade. Isso significa que eu leio muito sobre leis GDPR e similares. Eu também tenho que ler muito sobre violações de dados para entender como e onde leis como GDPR e LGPD se aplicam a elas, e como elas aconteceram para que eu possa preparar melhor as pessoas através de boas práticas de DevOps para evitá-las.

Quanto mais eu leio sobre violações de dados, mais percebo: a falha é nossa sim. Eu, você, nós, etc…

Não acredita em mim? Tudo bem. Vamos analisar algumas violações de dados recentes juntos.

Senhas? Nós não precisamos de senhas complexas?

Certa vez ouvi de um CTO, quando sugeri senhas complexas, que eu estava exagerando….”que nem o NIST sugeria isso”.

Os dados da Coleção # 1, que representam 21 milhões de endereços de e-mail e senhas exclusivos para uma combinação de mais de 700 milhões, foram encontrados por Troy Hunt… em um armazenamento de dados sem senha. Concedido, isso não era um negócio. Na verdade, é uma coleção de hackers de violações de dados anteriores, mas ainda assim.

Tudo bem, vamos falar de negócios então. Como cerca de 24 milhões de registros de empréstimos, incluindo informações de contas bancárias, e-mail, telefones, números todos os tipos e todo o resto. Sim, isso estava em um banco de dados do Elasticsearch, sem senha de qualquer tipo. Ah, e o armazenamento S3 estava completamente aberto também. Segurança? Isso ainda é uma coisa real?

Que tal expor sua lista inteira de clientes porque você deixou a senha fora do banco de dados (Elasticsearch novamente, é difícil adicionar uma senha ao Elasticsearch). Que tal pilhas de currículos (ElasticSearch, novamente, e MongoDB).

Essas são apenas violações deste ano. Se voltarmos, podemos encontrar mais e mais. Por favor, coloque uma senha em seus sistemas. Falando de senhas …

Senhas Eles são minha única fraqueza.

De acordo com o IdAgent, 63% de todas as violações de dados vêm de senhas fracas ou roubadas. Mas ei, não acredite neles. Vamos conversar com o Conselho Dudley, que evidentemente não teve uma violação de dados (mas como eles sabem), mas, mesmo assim, está relatando pouca segurança em seus sistemas.

Que tal ser invadido em sua casa? A Nest está encorajando ativamente todos a começarem a usar senhas mais fortes. Como cerca de 800.000 dados de sangue de pessoas?

Injeção SQL? Eu pensei que você estava morto.

Sabemos sobre o SQL Injection e as possibilidades que ele oferece para o hacking desde 1998. Isso é mais do que os meus gatos estão vivos. Certamente, em todo esse tempo, descobrimos como lidar com o SQL Injection, certo?

Não.

Como cerca de 1,3 milhões de registros violados, de uma faculdade não menos (você pode dizer FERPA) devido a Injeção de SQL. E se você estiver usando o Magento (melhor conseguir isso)? Você é um gamer? Talvez queira verificar sua conta da Epic Games, porque ela foi invadida por meio da Injeção de SQL. A Toyota sofreu um ataque em Tóquio que veio da Injeção de SQL, não da Godzilla.

PATCHES! Malditos Patches de atualizações…

Você sabe que o suporte ao fluxo principal do SQL Server 2014 está terminando em breve, certo?

Este é realmente difícil. Este blog foi hackeado há alguns anos, porque eu não estava acompanhando os patches de segurança. Sim, estou lhe dizendo que não é só você, sou eu também. Somos nós. O gerenciamento de patches é a primeira linha de defesa para proteger contra violações de dados, e não estamos fazendo isso.

Como eu sei (exceto pela minha própria violação de dados)?

Lembre-se da violação de dados Equifax? As informações sobre exatamente como tudo caiu há quase dois anos estão agora chegando agora. O que nós sabemos? Eles encontraram a brecha depois que aplicaram um patch que haviam adiado por mais de um ano.

O que fazemos agora? Fim de jogo!

Nada disso trata de phishing, hacks internos, perda acidental de laptops e todas as outras coisas que estão dando errado e causam essas violações de dados.

Entendi. Provavelmente não é você diretamente. Você disse ao chefe que colocar o banco de dados sem uma senha era uma má ideia. Você mostrou à organização como todo o código que eles estavam escrevendo estava levando à exposição por meio do SQL Injection. Você tem uma senha um pouco mais forte do que “senha” ou “123456”. O que mais você pode fazer?

É tudo sobre educação. Claro, passe o link para este blog ou para uma das violações de dados listadas acima. No entanto, você e sua organização precisam fazer mais.

Meu conselho? Primeiro, faça uma avaliação de segurança completa, conforme descrito no GDPR e LGPD. Em seguida, comece a implementar processos inteligentes usando o DevOps como modelo.

Vamos corrigir as coisas que podemos para tornar esses tipos de violações de dados uma coisa do passado.

Sobre o autor: Guilherme Teles é um cara qualquer que não dorme direito e acaba escrevendo. Sou Certificado CISSP, CHFI, CEH, LPIC-3, AWS CDA, AWS SAA, AWS SOA Quer assinar a newsletter do site e receber esse e outros artigos? Clique aqui! Aproveite e navegue pelo smeu blog. Quem sabe você não está exatamente precisando de uma ajuda ?