Incidentes e Vulnerabilidades
Vazamento de dados da Benesse (2014) — por que um insider não pôde ser detido, e a defesa por menor privilégio
Em 2014, até ~35 milhões de registros de clientes vazaram da Benesse (Japão): um engenheiro terceirizado com acesso legítimo ao banco explorou uma falha de monitoramento — USB bloqueado, smartphone (MTP) não. Defenda-se com menor privilégio, DLP e supervisão de terceiros.
Lemos vazamentos reais e públicos não como reprises de notícias, mas com a pergunta "como você se defende disto?" Este artigo baseia-se no registro público (declarações da empresa, reguladores, jornalismo confiável). As fontes estão listadas ao final; não há passo a passo de ataque nem detalhes que identifiquem qualquer indivíduo.
- Alvo
- Dados de clientes de um serviço de educação (nomes, endereços, datas de nascimento, telefones, etc.)
- Detectado
- Junho–julho de 2014 (veio à tona quando clientes começaram a receber malas diretas de outras empresas; divulgado em 9 de julho)
- Padrão
- Abuso interno por um engenheiro terceirizado em uma empresa do grupo: acesso legítimo ao BD → extração em massa → transferência para um smartphone pessoal → venda a corretores de dados
- Escala
- Até ~35 milhões de registros (um dos maiores vazamentos de dados pessoais do Japão à época)
- Causa raiz
- Privilégio excessivo para um insider + uma falha nos caminhos de exfiltração (USB bloqueado, mas smartphone/MTP não) + detecção fraca de acesso em massa + supervisão fraca do terceiro / subcontratado
- Principais correções
- Menor privilégio / need-to-know; DLP que fecha todo caminho de exfiltração; detecção + logs de auditoria para acesso em massa; gestão e supervisão de terceiros e subcontratados
O que aconteceu (em termos simples)
A maioria dos controles de segurança pressupõe um ataque de fora. Mas quem retirou os dados aqui foi um insider com acesso legitimamente concedido. A Benesse terceirizava a operação e a manutenção do seu banco de dados de clientes para uma empresa do grupo (um terceiro), e um engenheiro de sistemas terceirizado que ali trabalhava usou o acesso concedido para o trabalho a fim de extrair dados de clientes em massa.
A falha decisiva foi o caminho de exfiltração. Os controles corporativos de exfiltração de dados muitas vezes chegam até "bloquear gravações em armazenamento USB", mas a transferência para um smartphone (um método chamado MTP) é fácil de passar despercebida. Aqui também, as gravações em USB estavam bloqueadas, porém a transferência para um smartphone pessoal não estava. Os dados extraídos foram vendidos a corretores de dados e se espalharam ainda mais. Ninguém invadiu de fora. O acesso legítimo de um insider se somou a um caminho de exfiltração que ninguém havia fechado.
Defesas contra ataques externos não detêm um insider
Firewalls e detecção de intrusão miram ataques vindos de fora. Um insider com privilégio legítimo já está dentro, então esses controles não se aplicam. O abuso interno exige outros controles: minimizar o privilégio, fechar a exfiltração em todo caminho, detectar acesso em massa e estender a supervisão aos terceiros. "Confiamos nesta pessoa" não é motivo para deixar de reduzir o privilégio.
Cada etapa do ataque e como detê-la
Esta foi uma cadeia com um ponto para detê-la em cada etapa. Leia como onde ela poderia ter sido quebrada, não como um passo a passo.
1. Privilégio excessivo para um insider
O acesso legítimo alcançava muito mais dados de clientes do que o necessário.
Parada: menor privilégio / need-to-know; segregação de funções; revisão periódica de acessos
2. Dados em massa levados para um dispositivo pessoal
O USB estava bloqueado, mas a transferência para smartphone (MTP) não.
Parada: DLP que fecha todo caminho (USB / smartphone-MTP / nuvem / impressão); detectar exportação em massa
3. Pouca supervisão no terceiro / subcontratado
A operação foi terceirizada, então a supervisão do trabalho real era tênue.
Parada: visibilidade sobre terceiros/subcontratados; contrato + controles técnicos juntos; auditorias
4. Vendido a corretores de dados, espalhado ainda mais
Os dados extraídos foram vendidos e se espalharam de formas difíceis de rastrear.
Parada: monitoramento de logs e detecção precoce; tornar a exfiltração em massa impossível por design
Linha do tempo divulgada
2014-06
Clientes começam a receber malas diretas de outras empresas; disparam as consultas suspeitando de um vazamento.2014-07-09
A Benesse divulga o vazamento (inicialmente descrito como até ~20,7 milhões de registros possivelmente afetados).2014-07-17
A polícia de Tóquio prende o engenheiro de sistemas terceirizado na empresa do grupo; a imprensa relata que ele admitiu extrair e vender os dados a corretores.2014-09-10
O vazamento é estimado em até ~35 milhões de registros. A Benesse anuncia vales-presente (¥500) para os clientes afetados e um plano de indenização/prevenção da ordem de ~¥20 bilhões.2014–2015
Executivos assumem responsabilidade; o METI emite uma recomendação (kankoku) de melhoria. O caso se torna um dos motores da emenda à lei japonesa de proteção de dados pessoais (regras mais rígidas para corretores de dados).2016
O ex-trabalhador terceirizado é condenado (pena de prisão e multa).
Causa raiz: não só um insider, mas várias defesas ausentes
Descartar isto como "havia um indivíduo mau" convida à repetição. Na realidade, várias camadas destinadas a deter o abuso interno estavam tênues ao mesmo tempo.
A configuração que falhou
- A equipe de um terceiro tinha acesso alcançando muito mais dados do que o necessário
- Uma falha nos controles de exfiltração (USB bloqueado, smartphone/MTP aberto)
- Detecção/alertas fracos sobre visualização e exportação em massa
- A supervisão mal alcançava a realidade do terceiro / subcontratado
A configuração que resiste
- Menor privilégio / need-to-know limita os dados alcançáveis ao que é necessário
- DLP que fecha todo caminho (USB / smartphone / nuvem / impressão)
- Detecção e alertas para acesso/exportação em massa, além de logs de auditoria
- Visibilidade e auditorias de terceiros e subcontratados (contrato + técnica)
O custo depois de um incidente supera em muito o investimento de projeto feito antes
A Benesse indenizou os clientes afetados (vales; uma provisão da ordem de ~¥20 bilhões), executivos assumiram responsabilidade e os reguladores emitiram ordens. O caso também ajudou a impulsionar uma emenda à lei japonesa de proteção de dados. O custo da confiança perdida, da indenização e da resposta regulatória excede em muito o investimento feito antes para reduzir privilégio e fechar caminhos. Projete os controles internos à altura do volume de dados pessoais que você guarda — antes de um incidente, não depois.
Como você se defende disto
Por mais que você se blinde contra ataques externos, esses controles não detêm um insider legítimo. Em ordem de prioridade, e em qualquer escala:
Minimize o privilégio (menor privilégio / need-to-know)
Incluindo operadores e terceiros, restrinja o acesso a dados de produção ao mínimo que o trabalho exige. Projete a autorização (quem pode acessar o quê) e aplique o princípio do menor privilégio a chaves e contas em geral. Revise o privilégio periodicamente.
Feche todo caminho de exfiltração (DLP)
Não apenas o armazenamento USB — inventarie e feche também a transferência para smartphone (MTP), o upload para a nuvem, os anexos de e-mail e a impressão. Não se contente com "bloqueamos o USB". Deixe um único caminho aberto e os dados podem sair por ele.
Detecte acesso em massa e exfiltração em massa
Sinalize "uma pessoa visualizou/exportou uma grande quantidade de dados de clientes em pouco tempo" e seja capaz de alertar, exigir aprovação ou pausar. Mantenha logs de auditoria de quem acessou quanto, e quando. Mesmo sem conseguir preveni-lo, encurtar o tempo até perceber reduz a perda.
Estenda a supervisão a terceiros e subcontratados
Terceirizar não é transferência de responsabilidade. Entenda o escopo e a realidade da subcontratação e gerencie-a com contrato (confidencialidade, direitos de auditoria) e tecnologia (privilégio, DLP, logs) em conjunto. Aplique a sua base de segurança para organizações aos terceiros também.
Onde isto se sobrepõe a como este site é construído
Em essência, este incidente deixou um insider legítimo alcançar mais dados do que o necessário, por um caminho de exfiltração esquecido. Isso é o oposto dos próprios princípios deste site: menor privilégio, limitar até onde o dano pode se espalhar se uma parte for violada e defender-se pressupondo que todo caminho existe. Proteja-se apenas contra ataques externos e negligencie o controle de acesso e a exfiltração interna, e a mesma falha aparece. "Reduzir o privilégio, fechar todo caminho, detectar acesso em massa e alcançar os seus terceiros" é uma defesa que qualquer um pode implementar em qualquer escala.
Fontes (registro público)
Os fatos aqui baseiam-se nas seguintes informações públicas. Não há passo a passo de ataque nem detalhes que identifiquem qualquer indivíduo — apenas as lições defensivas.
- Declarações oficiais da Benesse Holdings / Benesse Corporation (avisos sobre o vazamento de dados pessoais / central de atendimento, 2014–) — benesse.co.jp
- METI (Japão), divulgações sobre a resposta à proteção de dados pessoais (2014) — meti.go.jp
- Comissão de Proteção de Informações Pessoais (e órgãos antecessores), materiais e o debate sobre a emenda à lei de proteção (2014–2015) — ppc.go.jp
Leia a seguir
- Prática: A base de segurança para organizações de médio a grande porte (o básico em escala de time; aplique-o também aos terceiros)
- Prática: Menor privilégio para chaves SSH (o princípio do menor privilégio na prática) · Autenticação vs autorização
- Glossário: O que é IDOR (controle de acesso quebrado — ler dados além do seu privilégio)
FAQ
QQual foi a causa raiz do incidente da Benesse?
Não foi um ataque externo, mas um insider. Um engenheiro de sistemas terceirizado, alocado em uma empresa do grupo, usou o acesso ao banco de dados legitimamente concedido para copiar dados de clientes em massa. O software de monitoramento bloqueava gravações em armazenamento USB, mas não bloqueava a transferência para um smartphone pessoal (MTP). Privilégio excessivo, uma falha nos caminhos de exfiltração e supervisão fraca do terceiro / subcontratado se combinaram.
QSe eu me defendo contra ataques externos, estou coberto?
Não. Este foi um insider com acesso legítimo. Firewalls e detecção de intrusão miram ataques vindos de fora; o abuso interno exige outros controles: (1) minimizar privilégio (menor privilégio / need-to-know); (2) detectar visualização/exportação em massa; (3) fechar todo caminho de exfiltração; (4) estender a supervisão a terceiros e subcontratados. Esses quatro pontos são o núcleo da defesa.
QUma organização menor ou um projeto solo pode aprender com isso?
Sim: (1) não dê a operadores ou terceiros acesso amplo demais a dados de produção; (2) inventarie e feche todo caminho capaz de copiar dados para fora (USB, smartphone, nuvem, impressão); (3) mantenha logs de quem acessou quanto, e alerte sobre acesso em massa; (4) entenda o escopo e a realidade da terceirização e da subcontratação. Quanto menor o time, mais fácil é dizer 'confiamos neles' e nunca reduzir o privilégio.