Adobe transformou o armazenamento de senhas em uma prova de responsabilidade identitária de longo prazo

Resumo

• Relatório sobre a violação de dados de clientes da Adobe em 2013, o armazenamento de senhas, a exposição do código-fonte, a redefinição de contas de clientes e a responsabilidade identitária de longo prazo.
• A violação de dados de clientes da Adobe em 2013 expôs registros de contas e um risco relacionado ao código-fonte, ao mesmo tempo que forçou uma conscientização pública sobre a proteção de senhas, notificação e reutilização de longo prazo de credenciais.
• Quem tinha o controle efetivo sobre o design do armazenamento de senhas, a proteção do código-fonte, o aviso de violação, a redefinição de contas de clientes, a minimização de campos expostos, as evidências de acerto e a prova de que os sistemas de contas legados não continuaram a transferir o risco após a data de divulgação?
• O problema de responsabilidade é que as decisões de armazenamento de senhas tomadas antes de uma violação podem continuar a impor custos depois que a empresa redefiniu as contas e desviou a atenção pública.
• Os clientes, desenvolvedores, compradores de software, equipes de gerenciamento de risco de identidade, reguladores, entidades em ações coletivas e engenheiros de segurança precisavam de evidências de que a reparação do sistema de conta tratou os riscos persistentes relacionados a credenciais e código-fonte.

Por que este caso pertence a um arquivo de risco e responsabilidade

Adobe transformou a prova do armazenamento de senhas em um teste de responsabilidade identitária de longo prazo, porque a violação de 2013 não foi apenas um evento de divulgação. Ela se tornou uma lição pública sobre como sistemas de contas antigos, escolhas de armazenamento de senhas, notificação de clientes, proteção de código-fonte de software e dependência de identidade na era das assinaturas podem continuar transferindo o risco depois que uma empresa pede a seus clientes que redefinam suas senhas. A questão central de responsabilidade não é se a Adobe finalmente reconheceu mais contas afetadas do que o primeiro número divulgado.

Trata-se de saber se o arquivo público permitiu que clientes e compradores de software entendessem as consequências duradouras do design de armazenamento e da reparação.

Este caso é antigo o suficiente para ser confundido com uma simples história. Isso é perigoso. O antigo anúncio de segurança do cliente da Adobe emhttp://blogs.adobe.com/conversations/2013/10/important-customer-security-announcement.htmle o anúncio sobre o código-fonte emhttp://blogs.adobe.com/asset/2013/10/illegal-access-to-adobe-source-code.htmlforam os primeiros registros públicos da disseminação dos dados de clientes e do código-fonte dos produtos. Relatórios posteriores, incluindo a cobertura da BBC emhttps://www.bbc.com/news/technology-24740873, descreveram a extensão do número inicial de 2,9 milhões de clientes afetados para cerca de 38 milhões de usuários ativos e notaram a exposição do código-fonte envolvendo Photoshop, bem como referências anteriores a Acrobat e ColdFusion. Os números importam, mas a lição de design importa mais.

O armazenamento de senhas é uma decisão anterior à violação que só se torna pública após uma falha. Se uma empresa armazena senhas de uma forma que ajuda invasores a fazer suposições, a redefinição não apaga o dano. Os invasores podem não precisar mais do serviço original. Eles podem testar as mesmas credenciais ou similares em outros lugares, usar dicas de senha para inferir padrões, combinar endereços de e-mail com outros dados expostos e continuar a se beneficiar de um design de armazenamento fraco muito depois de o site principal ser reparado.

É por isso que o artigo trata a violação como um registro de identidade de longo prazo, em vez de uma manchete de segurança momentânea.

A exposição do código-fonte adiciona um segundo horizonte de tempo. A FAQ do SANS Internet Storm Center emhttps://isc.sans.edu/diary/The+Adobe+Breach+FAQ/16727discutiu os dados do cliente, o código-fonte e o contexto do ColdFusion logo após a divulgação. A cobertura de segurança da Krebs emhttp://krebsonsecurity.com/2013/10/adobe-to-announce-source-code-customer-data-breach/e da Ars Technica emhttp://arstechnica.com/security/2013/10/adobe-source-code-and-customer-data-stolen-in-sustained-network-hack/também apresentaram o evento como um comprometimento tanto dos dados do cliente quanto do código-fonte. O código-fonte não cria o mesmo risco que uma tabela de senhas, mas pode alterar a economia dos invasores ao revelar detalhes de implementação, suposições de produto e possíveis caminhos de vulnerabilidade.

Este artigo não trata cada alegação secundária como um fato interno provado. Ele distingue as declarações da Adobe, os relatos contemporâneos, as análises técnicas e as normas atuais. As páginas atuais do Trust Center da Adobe, comohttps://www.adobe.com/trust.htmlehttps://www.adobe.com/trust/security.html, são usadas para o vocabulário atual do programa de segurança, e não como prova dos controles de 2013. Os documentos OWASP e NIST são usados para os princípios de senha e identidade, e não como conclusões legais retrospectivas. Essa disciplina de fontes é importante porque a responsabilidade de longo prazo depende de distinguir entre o que era conhecido, o que foi relatado depois e o que ainda está fora do registro público.

O armazenamento de senhas pode transferir custos após a redefinição

A resposta comum a um banco de dados de senhas comprometido é uma redefinição. Uma redefinição é necessária, mas não aborda todo o risco. Se o armazenamento original de senhas permitia tentativas de adivinhação offline significativas, os invasores podem aprender os hábitos de senha do usuário mesmo depois que a conta Adobe não pode mais ser acessada com o segredo antigo. Se a mesma senha ou uma relacionada foi reutilizada em outros lugares, as outras contas do usuário podem permanecer expostas. Se dicas de senha estavam disponíveis em texto simples ou de forma adivinhável, elas podem continuar ajudando os invasores.

O custo de longo prazo recai sobre o usuário, e não apenas sobre a empresa comprometida.

A análise da Ars Technica focada em senhas emhttp://arstechnica.com/security/2013/11/how-an-epic-blunder-by-adobe-could-strengthen-hand-of-password-crackers/tornou-se influente porque explicava por que a forma da proteção de senhas é importante. O artigo não deve ser reduzido a uma reprimenda técnica. Ele levantou um princípio de responsabilidade: o design do armazenamento determina o valor que os invasores podem extrair após a exfiltração. Um sistema sólido assume que o roubo do banco de dados é possível e armazena verificadores de senha de forma a tornar o roubo menos útil. Um sistema legado mais fraco pode transformar o banco de dados em um conjunto de aprendizado para quebradores de senhas.

A folha de dicas do OWASP sobre armazenamento de senhas emhttps://cheatsheetseries.owasp.org/cheatsheets/Password_Storage_Cheat_Sheet.htmlfornece um vocabulário moderno para esse problema: hash lento de senhas, salting, fatores de trabalho, peppering quando apropriado e migração para longe de esquemas fracos. Esses conceitos não são enfeites posteriores. Eles definem as evidências que usuários e auditores precisam. Quando uma empresa diz que as senhas foram redefinidas, o registro público ainda deve perguntar qual design de armazenamento foi removido, qual novo design o substituiu, como os registros antigos foram migrados, se os registros inativos foram mantidos e se as dicas de senha ou artefatos de recuperação de conta associados foram minimizados.

As diretrizes atuais do NIST sobre identidade digital emhttps://pages.nist.gov/800-63-4/sp800-63b.htmlreforçam o ponto de que a autenticação é um ciclo de vida. Ela inclui emissão, manutenção, invalidação, controles de sessão e reparação. Uma redefinição de senha é um evento nesse ciclo de vida. Recuperação de conta, opções de MFA, filtragem de segredos comprometidos, reautenticação e reparação de problemas de autenticação contam todos após uma violação. Para a Adobe, o problema de longo prazo é saber se os clientes receberam evidências suficientes para saber até onde o risco relacionado às suas credenciais poderia se espalhar além da conta Adobe.

O registro público mostra por que "criptografado" pode ser uma palavra insuficiente para o usuário. Criptografia, hash, salt e dicas de senha têm consequências diferentes, mas muitos avisos comprimem essas distinções em uma ampla reafirmação. Os usuários não precisam de aulas de criptografia, mas precisam do resultado prático. Os invasores podem reverter ou adivinhar eficazmente as senhas antigas? As dicas foram expostas? As contas inativas foram incluídas? Identificadores de cliente, endereços de e-mail, registros de pagamento ou outros atributos estavam vinculados ao mesmo arquivo?

O aviso deve responder à pergunta de risco do usuário, não apenas à categoria de divulgação da empresa.

A exposição do código-fonte transforma uma violação em um problema de ciclo de vida de software

O evento de 2013 da Adobe também pertence a esta série porque a exposição do código-fonte se estende além da identidade do cliente. O antigo anúncio da Adobe sobre o código-fonte, a FAQ do SANS, o relato de Krebs, a cobertura da BBC e a cobertura da Ars Technica trataram o incidente como envolvendo código-fonte de produtos ou componentes importantes da Adobe. Os relatos públicos mencionavam Acrobat, ColdFusion, ColdFusion Builder e, posteriormente, Photoshop. A questão de responsabilidade não é se a exposição do código-fonte cria automaticamente um exploit conhecido.

Trata-se de saber se a empresa pode provar que a revisão de segurança dos produtos, a resposta a vulnerabilidades e as orientações aos clientes mudaram para corresponder ao novo risco.

O ciclo de vida do software e o lock-in estão no centro da superfície de responsabilidade da Adobe. Muitos clientes dependem das ferramentas Adobe para produção criativa, fluxos de trabalho documentais, formulários do setor público, marketing corporativo e gerenciamento de PDF. Eles não podem migrar instantaneamente após um evento de código-fonte. Essa dependência impõe ao fornecedor o dever de fornecer evidências claras de segurança do produto: quais produtos foram afetados, quais branches foram revisados, quais patches ou medidas de hardening eram importantes e como os clientes podiam monitorar avisos posteriores. O índice atual de boletins de segurança da Adobe emhttps://helpx.adobe.com/security/security-bulletin.htmlmostra o vocabulário contínuo de avisos e patches, mas o público precisa da ponte entre um evento de código-fonte e a garantia subsequente de segurança do produto.

A proteção do código-fonte também é um problema de governança. Envolve acesso a repositórios, segmentação, gerenciamento de segredos, controles de build, revisão de código, registro em log, monitoramento de acesso interno e externo e resposta a incidentes. As páginas de segurança atuais da Adobe, comohttps://www.adobe.com/trust/security/product-security.htmlehttps://www.adobe.com/trust/security/incident-response.html, descrevem os conceitos atuais do programa de segurança, incluindo o ciclo de vida seguro do produto e a resposta a incidentes. Elas são úteis porque mostram o que um leitor moderno deve esperar ver em um arquivo de evidências, mesmo que não possam provar exatamente como os sistemas de 2013 funcionavam.

O risco de longo prazo não é que os invasores detenham o código-fonte para sempre de maneira simples. É que os defensores precisam da garantia de que o código exposto foi revisado de um ângulo diferente. Se os invasores pudessem inspecionar detalhes de implementação, as equipes de produto deveriam se perguntar se a obscuridade foi tratada como um controle oculto, se componentes compartilhados precisavam de revisão, se as diretrizes de hardening para clientes deveriam mudar e se vulnerabilidades históricas deveriam ser reexaminadas.

A continuidade do setor público entra no arquivo porque ferramentas documentais e plataformas de aplicativos web amplamente implantadas podem se tornar dependências institucionais. Um evento de segurança de produto nessa escala não é um inconveniente privado.

É por isso que o arquivo de evidências deve conectar os dados do cliente e o código-fonte, em vez de tratá-los como manchetes separadas. A exposição de senhas afeta usuários e equipes de identidade. A exposição do código-fonte afeta desenvolvedores, empresas e compradores de software. A mesma resposta a uma violação precisa de trilhas distintas, mas essas trilhas devem compartilhar uma linha do tempo e um proprietário de governança. Se a empresa diz que os clientes devem redefinir senhas enquanto as equipes de produto revisam discretamente o código-fonte, observadores externos não podem julgar se o evento foi contido.

A responsabilidade exige que ambas as trilhas sejam suficientemente visíveis para que organizações dependentes possam planejar.

A qualidade do aviso determina se os usuários podem proteger outras contas

O problema do aviso da Adobe não era apenas o número inicial de usuários afetados. Era a questão prática do que os usuários deveriam fazer além da Adobe. A cobertura da BBC emhttps://www.bbc.com/news/technology-24740873relatou que a Adobe havia redefinido as senhas e que as credenciais reutilizadas em outros serviços continuavam sendo um risco. Este é o cerne da responsabilidade identitária de longo prazo. A empresa pode desativar a senha antiga da Adobe. Ela não pode redefinir todas as outras contas onde o cliente a reutilizou. O aviso deve, portanto, dizer o suficiente sobre o risco relacionado às credenciais para incentivar uma ação proporcional em outros lugares.

Um aviso eficaz distinguiria várias coisas: contas ativas, contas inativas, identificadores de cliente, endereços de e-mail, senhas criptografadas, dicas de senha, dados de cartão de pagamento, exposição do código-fonte e status da redefinição. Também explicaria o que a empresa ainda não podia validar. Em um incidente em rápida evolução, os números podem mudar. Isso não torna a divulgação precoce inútil. Significa que a divulgação precoce deve ser explícita quanto à incerteza. Um usuário pode entender que um número pode aumentar. O usuário não pode agir bem se um aviso reduz toda incerteza a uma declaração confiante, mas incompleta.

As diretrizes da FTC sobre resposta a violações emhttps://www.ftc.gov/business-guidance/resources/data-breach-response-guide-businesssão úteis porque tratam o aviso como parte da resposta, e não como relações públicas. O guia da FTC sobre informações pessoais emhttps://www.ftc.gov/business-guidance/resources/protecting-personal-information-guide-businesstambém enfatiza a minimização e as medidas de proteção antes do incidente. Para a Adobe, o problema para os usuários é saber se o aviso traduziu os fatos técnicos em etapas: redefinir a senha da Adobe, alterar senhas reutilizadas em outros lugares, monitorar contas de pagamento, estar atento a tentativas de phishing e entender o que a exposição do código-fonte significava ou não para os usuários dos produtos.

A mesma lógica se aplica a entidades em ações coletivas e reguladores. Os processos legais geralmente se concentram na qualidade para agir, danos, acordo e provas processuais. Esses registros contam, mas não substituem as evidências técnicas. Os clientes precisavam entender o risco contínuo para suas identidades e contas. Os reguladores precisavam entender se o design do armazenamento, os registros inativos, as dicas de senha e as práticas de notificação correspondiam a expectativas de segurança razoáveis. Os compradores de software precisavam entender se a revisão de segurança do produto havia alcançado o código afetado.

Um único canal de divulgação raramente atende a todos esses públicos, a menos que seja deliberadamente estruturado.

A norma de notificação deve, portanto, ser medida pelas decisões downstream. Um cliente podia determinar se deveria alterar senhas em outros serviços? Uma equipe de identidade corporativa podia decidir buscar a reutilização de senhas da Adobe em contas corporativas? Um desenvolvedor podia decidir monitorar os avisos da Adobe mais de perto? Um comprador do setor público podia fazer as perguntas certas sobre compras e patches? Se o aviso não apoiava essas decisões, deixava o risco de longo prazo fora do quadro de responsabilidade da empresa.

Registros inativos tornam sistemas legados parte do dano

Registros inativos são um problema recorrente em violações de contas antigas. Os relatos da BBC indicavam que a Adobe acreditava que os invasores acessaram detalhes de contas não utilizadas por dois anos ou mais, além de usuários ativos. Esse fato é importante porque as contas inativas geralmente recebem menos atenção de empresas e usuários. Um usuário pode não se lembrar de um antigo identificador Adobe, não monitorar seu e-mail, ter reutilizado a senha anos atrás e não entender por que uma conta antiga de software criativo cria um risco de identidade atual.

As escolhas de retenção e migração da empresa moldam, portanto, a exposição atual do usuário.

Sistemas de contas legados também complicam a reparação. Se um antigo sistema de armazenamento de senhas estava previsto para ser retirado ou não fazia parte do caminho de autenticação atual, a empresa ainda precisa provar que os registros desse sistema não podem continuar a vazar valor. Retirar um sistema após uma violação não é suficiente se cópias legadas, backups, logs, dicas ou contas inativas persistirem.

O registro público deve indicar como os armazenamentos antigos foram inventariados, como foram protegidos, como foram excluídos ou migrados e como a empresa verificou que nenhum registro de credencial paralelo continuava a apresentar risco.

Soberania e localidade de dados surgem aqui como preocupações práticas de governança de registros. A Adobe atendia clientes globalmente, e os registros de identidade podem cruzar fronteiras de produtos, assinaturas, suporte, pagamentos e regiões. Um cliente em uma jurisdição pode ter direitos de notificação diferentes de outro, mas o risco técnico de uma dica de senha ou senha reutilizável não respeita essa fronteira. Um arquivo de responsabilidade de longo prazo deve explicar as categorias de dados de forma que elas viajem. Não deve exigir que cada jurisdição, cliente ou comprador reconstrua o design do armazenamento a partir de fragmentos.

O Cybersecurity Framework do NIST emhttps://www.nist.gov/cyberframeworke os Controles CIS emhttps://www.cisecurity.org/controlsoferecem uma forma de pensar sobre isso sem fazer afirmações não fundamentadas sobre os sistemas internos da Adobe. Inventário, gerenciamento de identidades, proteção de dados, registro em log, resposta a incidentes e recuperação são todos relevantes. Uma revisão do conselho deve perguntar se a empresa pode listar armazenamentos de contas antigos, identificar aqueles que contêm material de autenticação, nomear proprietários, documentar o motivo da retenção e provar que os armazenamentos obsoletos foram eliminados ou fortalecidos.

O caso Adobe continua útil porque mostra como uma violação pode revelar a arqueologia de um sistema de contas. As empresas geralmente modernizam as portas de entrada enquanto os armazenamentos de registros antigos permanecem no porão. Os clientes não podem ver esse porão. Eles só ficam sabendo dele quando um incidente o expõe. Essa assimetria é a razão pela qual sistemas legados precisam de responsabilidade pública quando criam risco atual.

Normas não são um veredito, mas definem as evidências de reparação

As normas modernas de armazenamento de senhas não devem ser usadas preguiçosamente como um veredito retrospectivo sobre um sistema de 2013. A tecnologia muda, os modelos de ameaça mudam e as diretrizes públicas evoluem. Mas as normas permanecem necessárias porque definem como devem ser as evidências de reparação agora. As diretrizes do OWASP sobre senhas emhttps://cheatsheetseries.owasp.org/cheatsheets/Password_Storage_Cheat_Sheet.html, as diretrizes do NIST sobre identidade emhttps://pages.nist.gov/800-63-4/sp800-63b.html, as diretrizes da CISA sobre segurança desde a concepção emhttps://www.cisa.gov/securebydesigne as páginas atuais do programa de segurança da Adobe mostram juntas o vocabulário de um arquivo de reparação mais robusto.

As evidências de reparação devem responder a várias perguntas. Qual esquema de armazenamento de senhas estava envolvido? Era unidirecional, salgado, lento e ajustado para resistir a ataques offline? As dicas de senha eram armazenadas e, em caso afirmativo, por quê? As contas inativas eram mantidas com os mesmos dados que as contas ativas? Os sistemas antigos foram desativados ou apenas escondidos dos caminhos de login comuns? A redefinição invalidou sessões e tokens? Os usuários foram solicitados a alterar senhas reutilizadas em outros lugares? Os administradores corporativos receberam indicadores para buscar exposição?

As equipes de segurança de produto receberam requisitos de revisão de código-fonte?

Essas perguntas são questões de evidência, não acusações. Uma empresa pode respondê-las de forma a proteger detalhes confidenciais de implementação. Ela pode descrever classes de sistemas, etapas de correção, marcos de migração e garantia externa sem publicar receitas de exploração. O que ela não deve fazer é pedir aos clientes que aceitem "redefinimos as senhas" como a reparação completa. Uma redefinição é visível. A migração de armazenamento, a minimização de dicas, a limpeza de contas inativas e a revisão de código-fonte são menos visíveis. É precisamente por isso que precisam de evidências responsáveis.

O arquivo público também deve distinguir documentos de normas de obrigações legais. Os guias da FTC são conselhos para empresas. Os documentos do NIST e da CISA são normas ou diretrizes públicas. OWASP é um guia de segurança comunitária. O Trust Center da Adobe é redigido pela empresa. Nenhuma dessas fontes é por si só uma conclusão judicial. Mas sua sobreposição é útil: autenticação forte, armazenamento sólido de senhas, minimização, resposta a incidentes, segurança de produto e reparação aparecem todos como temas de controle duradouros.

Um artigo sobre responsabilidade de longo prazo usa essa sobreposição para definir o arquivo de reparação que os clientes mereciam.

Essa abordagem evita um erro comum na escrita retrospectiva sobre violações. Ela não diz: "Aqui está uma lista de verificação moderna, portanto a empresa antiga falhou em todos os pontos." Ela diz: "Aqui estão as evidências que seriam necessárias agora para mostrar que o risco parou de ser transferido." A distinção é importante. A responsabilidade não é apenas um julgamento moral sobre o passado. É uma demanda por prova de que as escolhas antigas de design não prejudicam mais as pessoas que não podem inspecionar o sistema por si mesmas.

A confiança no produto e a confiança na identidade evoluíram juntas

A violação da Adobe foi importante porque a confiança no produto e a confiança na identidade evoluíram juntas. Os clientes usavam contas Adobe para acesso a software, gerenciamento de assinaturas, pagamentos, atualizações, suporte e identidade. Desenvolvedores e empresas dependiam dos produtos Adobe para fluxos de trabalho documentais e criativos. Organizações do setor público dependiam dos formatos e ferramentas Adobe em formulários, registros e comunicação. Quando os dados do cliente e o código-fonte apareceram no mesmo quadro de incidente público, a empresa teve que proteger tanto a camada de identidade quanto a camada de produto.

Essa dupla superfície de confiança é visível nas páginas atuais da Adobe. O Trust Center emhttps://www.adobe.com/trust.htmlenfatiza segurança, privacidade, disponibilidade, conformidade e recursos do produto. A visão geral de segurança emhttps://www.adobe.com/trust/security.htmltrata do ciclo de vida seguro do produto, segurança operacional, resposta a incidentes e boletins de segurança. A página de resposta a incidentes emhttps://www.adobe.com/trust/security/incident-response.htmldescreve a abordagem atual para monitoramento e resolução de incidentes. A página de segurança do produto emhttps://www.adobe.com/trust/security/product-security.htmldescreve processos de desenvolvimento reproduzíveis. Essas páginas são atuais, e não evidências de 2013. Elas mostram, no entanto, a estrutura de evidência integrada que um comprador de software moderno deve esperar.

Um comprador deve poder perguntar: se as senhas dos clientes foram expostas, o que mudou nos sistemas de identidade? Se o código-fonte do produto foi acessado, o que mudou na revisão de segurança do produto? Se os sistemas antigos continham material de senha, o que mudou no gerenciamento do ciclo de vida? Se os clientes tiveram que redefinir suas credenciais, quais orientações os ajudaram a gerenciar a reutilização em outros lugares? Se o código antigo ou armazenamentos de contas criaram risco após a data de divulgação, quais evidências encerraram a cauda?

A confiança no produto e a confiança na identidade não podem ser separadas quando a mesma conta desbloqueia software, pagamentos, suporte, atualizações e administração corporativa.

É também aqui que o ciclo de vida do software e o lock-in se tornam tópicos de responsabilidade, em vez de abstrações de negócios. Os clientes muitas vezes não podem sair rapidamente de um fornecedor de software básico. Seus arquivos, fluxos de trabalho, treinamento de pessoal, integrações e cronogramas de aquisição os mantêm dependentes. Esse lock-in aumenta o dever do fornecedor de fornecer evidências utilizáveis após uma violação. Um cliente que não pode sair facilmente precisa saber como continuar usando o produto com segurança.

Um aviso vago torna o lock-in mais caro, pois deixa o cliente dependente a inventar seu próprio plano de garantia.

O caso Adobe permanece, portanto, relevante para software em nuvem e por assinatura hoje. Os sistemas de contas acumulam dados antigos. Repositórios de código-fonte e sistemas de build tornam-se alvos de alto valor. Os clientes confiam em camadas de identidade controladas pelo fornecedor. Usuários do setor público dependem de formatos de arquivo e canais de atualização. Uma violação que expõe material de conta e código-fonte do produto torna-se um teste da capacidade do fornecedor de converter reparação privada em garantia pública sem expor novos detalhes confidenciais.

A cauda longa é onde a responsabilidade geralmente se perde

O risco de identidade de longo prazo é difícil de governar porque sobrevive ao cronograma de incidentes. A empresa pode concluir uma redefinição, encerrar uma investigação, atualizar uma página de segurança do produto e publicar novos avisos, enquanto os clientes continuam carregando hábitos de credenciais aprendidos pelos invasores a partir do antigo conjunto de dados. É por isso que o caso Adobe permanece valioso. Mostra que a unidade de responsabilidade não é apenas o banco de dados comprometido.

É a cadeia de decisões posteriores que clientes, empresas e equipes de segurança devem tomar com conhecimento parcial do que o banco de dados revelou.

A cauda longa também altera o significado do dano. Um usuário pode não perder dinheiro por causa da conta Adobe em si. O usuário pode, em vez disso, receber phishing direcionado, descobrir que uma senha antiga foi reutilizada em um serviço não relacionado, gastar tempo revisando registros de pagamento ou fazer parte de um corpus de quebra de senhas que melhora ataques contra outros. Esses custos são difusos e difíceis de quantificar, mas não são imaginários. Eles decorrem do fato de que material de senha, endereços de e-mail, dicas e histórico de contas podem ser recombinados após o bloqueio da conta original.

As empresas enfrentam um problema paralelo. Uma equipe de identidade corporativa pode ter funcionários que usaram endereços de e-mail profissionais para contas Adobe ou reutilizaram senhas relacionadas. A equipe precisa saber se deve buscar segredos comprometidos, forçar redefinições, verificar exceções de SSO, alertar a equipe ou monitorar campanhas de phishing. Essa decisão depende da qualidade das evidências públicas. Se o aviso de um fornecedor explica apenas que as senhas foram redefinidas, ele deixa as equipes corporativas a deduzir o resto.

Se o aviso explica o design do armazenamento, as populações afetadas, os registros inativos e as ações recomendadas para empresas, torna-se uma entrada de controle utilizável.

Os compradores do setor público têm outra dependência. As ferramentas Adobe são frequentemente integradas em fluxos de trabalho documentais, processamento de formulários, produção criativa, registros de aquisição e comunicações públicas. Um evento de código-fonte pode não obrigar cada agência a parar de usar o produto, mas deve desencadear perguntas sobre avisos, cadência de atualizações, controles compensatórios e garantia do fornecedor. O fornecedor responsável não precisa publicar detalhes confidenciais do código. Ele deve dar aos clientes uma base fundamentada para continuar suas operações com segurança.

A cauda longa é onde a responsabilidade geralmente se perde porque todos estão cansados nesse ponto. A imprensa passou para outra coisa, o processo legal é lento, os usuários redefiniram as senhas e as equipes de produto retornaram ao trabalho planejado. Mas os invasores não se importam com o cronograma de incidentes. Eles se importam com segredos reutilizáveis, conhecimento de código e controles de acompanhamento fracos.

Um arquivo de reparação maduro precisa, portanto, de uma fase de manutenção: orientações atualizadas para clientes, notas para administradores corporativos, acompanhamento de segurança do produto e confirmação de que os armazenamentos antigos foram limpos, em vez de simplesmente esquecidos.

As evidências devem viajar das equipes de segurança para os clientes

Outra lição do caso Adobe é que o trabalho de segurança privada deve ser traduzido sem ser esvaziado de sua substância. As equipes de segurança podem saber quais armazenamentos foram expostos, qual esquema criptográfico foi usado, quais repositórios de código foram acessados, quais grupos de clientes foram notificados e quais sistemas foram desativados. Os clientes não precisam dos detalhes internos brutos, mas precisam de uma versão pública precisa desses fatos. Se a tradução remove as distinções que importam, o aviso torna-se menos útil do que as evidências privadas que o produziram.

A tradução deve ser deliberadamente em camadas. A primeira camada é para usuários individuais: redefinir a senha da Adobe, alterar senhas reutilizadas em outros lugares, estar atento a phishing, monitorar instrumentos de pagamento se relevante e entender se os dados de cartão de pagamento estavam envolvidos. A segunda camada é para administradores corporativos: identificar domínios de e-mail corporativo afetados, avaliar reutilização de credenciais, monitorar falhas de login, comunicar-se com a equipe e acompanhar os avisos do fornecedor.

A terceira camada é para compradores de software: fazer perguntas sobre revisão de código-fonte, mudanças de desenvolvimento seguro, cadência de boletins e compromissos de suporte. A quarta camada é para reguladores e tribunais: reter datas, números, categorias de dados, registros de notificação e evidências de remediação.

Cada camada deve reter os mesmos fatos com diferentes níveis de detalhes técnicos. Essa é a melhor forma de evitar contradições. Se os usuários são simplesmente solicitados a redefinir senhas enquanto os administradores são informados de que o código-fonte foi exposto, o arquivo público parece fragmentado. Se os advogados descrevem o material de senha como criptografado enquanto os analistas de segurança explicam por que o design ainda facilitava a quebra, o público pode ouvir tanto reafirmação quanto alarme. Um arquivo de responsabilidade sólido torna essas declarações compatíveis ao explicar a consequência prática de cada termo.

A linguagem atual do Trust Center da Adobe é relevante porque mostra que as empresas agora entendem a garantia como um produto público. As descrições do programa de segurança, as páginas de resposta a incidentes, as páginas de segurança do produto e os índices de boletins fazem parte de como os compradores julgam a confiança. A lição de 2013 é que esses sistemas de garantia pública devem estar prontos antes que uma violação os force a carregar uma história complexa. Uma página de confiança que existe apenas para vendas não pode fazer o trabalho. Uma página de confiança ligada a evidências, avisos e proprietários responsáveis pode.

O arquivo de reparação deve, portanto, ser projetado como um pipeline de evidências. As descobertas internas da investigação tornam-se categorias de clientes. As categorias de clientes tornam-se avisos e orientações para administradores. As descobertas de segurança do produto tornam-se avisos e mudanças de ciclo de vida. Os registros legais tornam-se responsabilidade processual sem substituir o arquivo técnico. As normas tornam-se referências para garantia futura. Quando esse pipeline está faltando, cada público constrói sua própria interpretação e a empresa perde o controle do significado público de sua reparação.

Um arquivo de reparação completo da Adobe preservaria a cauda

Um arquivo de reparação completo começaria com uma linha do tempo validada. Ele listaria quando a intrusão foi detectada, quando a exposição dos dados do cliente foi confirmada, quando o acesso ao código-fonte foi confirmado, quando os números de pessoas afetadas mudaram, quando as redefinições de senha ocorreram, quando os avisos aos clientes foram emitidos, quando os registros inativos foram avaliados e quando as revisões de segurança do produto ou avisos ocorreram. Cada data deve identificar as evidências disponíveis naquele momento. O objetivo não é punir a incerteza precoce.

É impedir que resumos posteriores apaguem a incerteza que moldou as decisões dos clientes.

A segunda parte seria um registro do design do armazenamento. Explicaria o sistema de armazenamento de senhas envolvido, o tratamento de salts, os fatores de trabalho, a criptografia ou hash, as dicas de senha, os registros inativos e a migração para armazenamento mais robusto. Também descreveria quais armazenamentos legados foram desativados, quais backups foram mantidos e como o material de credencial antigo foi tornado menos útil. Os clientes não precisam dos detalhes secretos de implementação. Eles precisam de confiança de que o design antigo parou de transferir o risco.

A terceira parte seria um registro de ações para os clientes. Separaria as redefinições de conta Adobe do risco de reutilização de senhas em outros lugares. Daria aos administradores corporativos orientações para buscar exposição de credenciais corporativas. Daria aos clientes individuais orientações claras sobre alterar senhas reutilizadas, monitorar contas de pagamento e resistir a phishing baseado na violação. Explicaria se monitoramento de crédito ou assistência contra roubo de identidade se aplicava a populações específicas.

Preservaria as diferenças entre exposição de cartão de pagamento, exposição de identificador de conta, exposição de senha e exposição de código-fonte.

A quarta parte seria um registro de segurança do produto. Explicaria quais repositórios de código-fonte de produto foram envolvidos, quais linhas de produto foram revisadas, quais avisos ou patches estavam relacionados, quando aplicável, e como os clientes deveriam monitorar boletins futuros. Também explicaria o que não era conhecido. A exposição do código-fonte não é o mesmo que uma vulnerabilidade confirmada em cada produto. Mas altera o ônus da garantia. Um fornecedor de software deve ser capaz de mostrar que revisou o código e o pipeline de desenvolvimento considerando a exposição.

Finalmente, o arquivo de reparação deve ter uma norma de encerramento. O encerramento não deve significar que a atenção do público se deslocou ou que a primeira redefinição de senha está concluída. O encerramento deve significar que os armazenamentos de contas antigos foram inventariados, o design do armazenamento foi fortalecido, os registros inativos foram tratados, a exposição do código-fonte do produto foi revisada, orientações aos clientes foram fornecidas e a incerteza restante foi nomeada. Para a Adobe, a lição de longo prazo é que as evidências de armazenamento de senhas devem sobreviver ao ciclo de notícias.

Arquivo de evidências para o leitor

O artigo usa as seguintes fontes públicas como arquivo de leitura para a violação de dados de clientes da Adobe em 2013, armazenamento de senhas, exposição de código-fonte, redefinição de contas de clientes e registro de responsabilidade identitária de longo prazo. Os anúncios da empresa são tratados como evidências do que a Adobe declarou publicamente na época. Notícias e análises de segurança são usadas para a linha do tempo e contexto técnico. As páginas atuais de confiança da empresa e as diretrizes de normas são usadas para definir as evidências modernas de reparação, em vez de provar os controles internos de 2013.

1. http://blogs.adobe.com/conversations/2013/10/important-customer-security-announcement.html— Fonte pública usada para o arquivo de evidências.
2. http://blogs.adobe.com/asset/2013/10/illegal-access-to-adobe-source-code.html— Fonte pública usada para o arquivo de evidências.
3. https://www.bbc.com/news/technology-24740873— Fonte pública usada para o arquivo de evidências.
4. https://isc.sans.edu/diary/The+Adobe+Breach+FAQ/16727— Fonte pública usada para o arquivo de evidências.
5. http://krebsonsecurity.com/2013/10/adobe-to-announce-source-code-customer-data-breach/— Fonte pública usada para o arquivo de evidências.
6. http://arstechnica.com/security/2013/10/adobe-source-code-and-customer-data-stolen-in-sustained-network-hack/— Fonte pública usada para o arquivo de evidências.
7. http://arstechnica.com/security/2013/11/how-an-epic-blunder-by-adobe-could-strengthen-hand-of-password-crackers/— Fonte pública usada para o arquivo de evidências.
8. https://www.adobe.com/trust.html— Fonte pública usada para o arquivo de evidências.
9. https://www.adobe.com/trust/security.html— Fonte pública usada para o arquivo de evidências.
10. https://www.adobe.com/trust/security/incident-response.html— Fonte pública usada para o arquivo de evidências.
11. https://www.adobe.com/trust/security/product-security.html— Fonte pública usada para o arquivo de evidências.
12. https://helpx.adobe.com/security/security-bulletin.html— Fonte pública usada para o arquivo de evidências.
13. https://cheatsheetseries.owasp.org/cheatsheets/Password_Storage_Cheat_Sheet.html— Fonte pública usada para o arquivo de evidências.
14. https://pages.nist.gov/800-63-4/sp800-63b.html— Fonte pública usada para o arquivo de evidências.
15. https://www.ftc.gov/business-guidance/resources/protecting-personal-information-guide-business— Fonte pública usada para o arquivo de evidências.
16. https://www.ftc.gov/business-guidance/resources/data-breach-response-guide-business— Fonte pública usada para o arquivo de evidências.
17. https://www.cisa.gov/securebydesign— Fonte pública usada para o arquivo de evidências.
18. https://www.nist.gov/cyberframework— Fonte pública usada para o arquivo de evidências.
19. https://www.cisecurity.org/controls— Fonte pública usada para o arquivo de evidências.

Este arquivo de evidências é deliberadamente mais amplo do que um único anúncio, porque o problema da cauda longa abrange armazenamento de senhas, registros inativos, proteção de código-fonte, redefinição de contas, garantia de produto e dependência de compradores de software. O arquivo público deve permitir que os leitores separem a reparação da identidade do cliente da reparação da segurança do produto sem fingir que essas tarefas não estão relacionadas.

Perguntas para a revisão do conselho

Uma revisão do conselho deve perguntar quem era o proprietário dos armazenamentos de contas legados, quem era o proprietário da migração do armazenamento de senhas, quem era o proprietário do aviso ao cliente, quem era o proprietário do acesso a repositórios de código-fonte, quem era o proprietário da revisão de segurança do produto, quem era o proprietário das orientações para clientes corporativos e quem era o proprietário do encerramento. A resposta deve ser um mapa de controle, não uma narrativa de esforços. Mapas de controle tornam mais difícil para sistemas antigos permanecerem como risco de todos e dever de ninguém.

A revisão também deve exigir evidências de que os registros inativos são governados. Contas antigas, backups antigos, dicas antigas e armazenamentos de autenticação antigos devem ter proprietários, razões de retenção, normas de proteção e datas de exclusão. Se uma transição de produto para assinatura aumenta o valor da identidade da conta, a empresa deve revisitar os armazenamentos antigos antes que os invasores o façam. Legado não significa inofensivo.

O conselho deve exigir um manual de resposta à exposição de código-fonte. Ele deve definir o isolamento de repositórios, rotação de credenciais e segredos, gatilhos de revisão de código, regras de aviso ao cliente, revisão de hardening de produto e evidências para clientes dependentes. Um evento de código-fonte pode não exigir detalhes públicos sobre cada repositório interno, mas exige garantia suficiente para clientes que precisam continuar usando o software.

Para este caso específico, uma revisão do conselho deve perguntar: quem tinha o controle efetivo sobre o design do armazenamento de senhas, a proteção do código-fonte, o aviso de violação, a redefinição de clientes, a minimização de campos expostos, as evidências de acerto e a prova de que os sistemas de contas legados não continuaram a transferir o risco após a data de divulgação?

A resposta deve incluir evidências datadas, proprietários nomeados, prova de migração de armazenamento de senhas, limpeza de registros inativos, revisão de segurança do produto, orientações de ação para clientes e incerteza residual que não desapareceu quando a primeira redefinição foi concluída.