Resumo

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

Blackbaud pertence a um arquivo de risco e responsabilidade porque o cliente visível raramente era a pessoa final exposta. Uma universidade, fundação hospitalar, banco de alimentos, instituição de caridade infantil, organização religiosa, escola, museu, fundação de pesquisa ou organização sem fins lucrativos de serviço público pode ter adquirido software da Blackbaud. Os registros dentro desses sistemas pertenciam a doadores, ex-alunos, pacientes, voluntários de campanhas, estudantes, participantes de eventos, beneficiários, curadores, funcionários e apoiadores. Essas pessoas podem nunca ter visto uma tela de login da Blackbaud.

Elas foram representadas ao fornecedor por uma instituição em que confiavam para uma missão, não por uma conta de consumidor comum.

A linha do tempo pública primária é excepcionalmente instrutiva. A ordem da SEC emhttps://www.sec.gov/files/litigation/admin/2023/33-11165.pdfafirma que a Blackbaud detectou acesso não autorizado em 14 de maio de 2020 e que a investigação da empresa indicou que o acesso pode ter começado já em fevereiro de 2020. A ordem diz que o incidente resultou em acesso não autorizado e exfiltração de mais de um milhão de arquivos relativos a mais de 13.000 clientes. A Blackbaud anunciou o incidente e notificou os clientes afetados em 16 de julho de 2020. A ordem da SEC então diz que os funcionários souberam em dias que declarações anteriores sobre informações de contas bancárias de doadores e números de Seguro Social estavam erradas para alguns clientes, mas o Formulário 10-Q de 4 de agosto de 2020 da empresa não divulgou esse escopo mais amplo e caracterizou o risco como hipotético.

O Formulário 8-K posterior da Blackbaud, disponível emhttps://investor.blackbaud.com/static-files/58a4ae64-afc5-45f7-81df-69dfc93888fc, mudou a imagem pública de risco. Ele afirmava que investigações forenses adicionais descobriram que, para alguns clientes notificados, o invasor pode ter acessado campos não criptografados destinados a informações de contas bancárias, números de Seguro Social, nomes de usuário e/ou senhas. Isso não significava que todos os clientes tinham esses campos expostos. Significava que a arquitetura de notificação original falhou em carregar toda a incerteza e que alguns clientes precisavam de suporte suplementar.

A questão de responsabilidade é, portanto, prática. Quem tinha controle prático sobre a custódia de dados do inquilino, evidências de exfiltração, comunicação de pagamento de resgate, tempo de notificação ao cliente, cooperação com reguladores e a prova de que os constituintes sem fins lucrativos não se tornaram um custo invisível da concentração na nuvem?

A resposta começa com a Blackbaud porque a Blackbaud controlava o ambiente hospedado, a investigação, os primeiros avisos aos clientes, a postura de retenção de dados, os arquivos específicos do serviço e o fluxo de evidências que as instituições a jusante precisavam para notificar suas comunidades.

Isso não elimina a responsabilidade do cliente. Os clientes decidem quais dados coletar, quais campos usar, quais anexos fazer upload, por quanto tempo manter registros antigos e como se comunicar com seus constituintes. Mas a responsabilidade do cliente fica atrás de um portão de evidências do fornecedor.

Se uma organização sem fins lucrativos não pode ver quais arquivos da Blackbaud foram copiados, não pode verificar se um campo estava criptografado, não pode inspecionar as comunicações do invasor e não pode confirmar independentemente a exclusão de dados, então a disciplina de evidências do fornecedor se torna a condição controladora para a responsabilidade de todos os outros.

A linha do tempo é um caso de controle de divulgação, não apenas um caso de invasão

A linha do tempo importa porque mostra que a responsabilidade não terminou quando o invasor foi expulso. Ela se deslocou para os controles de divulgação. O comunicado de imprensa da SEC emhttps://www.sec.gov/intelligence team/press-releases/2023-48diz que a Blackbaud concordou em pagar uma multa civil de USD 3 milhões para resolver acusações de divulgações enganosas, sem admitir ou negar as conclusões da SEC. O ponto importante para este arquivo não é o valor em dólares. É a falha de controle descrita pela SEC: funcionários técnicos e de relações com clientes aprenderam informações sobre dados sensíveis que não chegaram à alta administração responsável pela divulgação pública antes do arquivamento de agosto de 2020.

Esse é um modo de falha diferente de uma brecha de firewall ou comprometimento de endpoint. É uma lacuna no roteamento de evidências. Em um incidente na nuvem, os fatos se movem de investigadores de endpoint para equipes de produto, scripts de suporte ao cliente, advogados, executivos, reguladores, investidores e clientes. Se esses fatos não se moverem rápido o suficiente ou com precisão suficiente, o registro público pode dizer às pessoas afetadas a coisa errada mesmo depois que a empresa sabe que o primeiro aviso estava incompleto. Para clientes liderados por missão, esse atraso não é uma abstração de relações com investidores.

Ele decide quando um doador pode congelar uma conta bancária, quando um paciente pode vigiar o uso indevido de identidade, quando uma universidade pode notificar ex-alunos e quando uma instituição de caridade pode responder a apoiadores ansiosos.

A ordem da SEC descreve uma sequência particularmente nítida. O aviso de 16 de julho da Blackbaud disse que o invasor não acessou informações de contas bancárias de doadores ou números de Seguro Social. Perguntas de clientes então levantaram preocupações de que dados sensíveis foram armazenados em anexos ou campos não criptografados. Em 21 de julho, de acordo com a ordem da SEC, os funcionários desenvolveram um script de atendimento ao cliente reconhecendo que certos anexos e campos potencialmente usados para essas categorias não estavam criptografados.

No final de julho, os funcionários confirmaram o acesso e a exfiltração de algumas informações não criptografadas de contas bancárias de doadores e números de Seguro Social para vários clientes afetados. O Formulário 10-Q de 4 de agosto não incluiu essa correção material.

A FTC posteriormente enquadrou o mesmo evento através da proteção ao consumidor e retenção de dados. Seu comunicado emhttps://www.ftc.gov/news-events/news/press-releases/2024/02/ftc-order-will-require-blackbaud-delete-unnecessary-data-boost-safeguards-settle-charges-its-laxdiz que a Blackbaud não implementou salvaguardas adequadas, permitiu que a violação passasse despercebida por meses, reteve dados por mais tempo que o necessário, pagou 24 Bitcoin após o invasor ameaçar expor os dados roubados e nunca verificou se o invasor excluiu os dados. Estas são alegações e termos de ordem da FTC, não registros forenses privados tornados públicos pela Blackbaud. Ainda são centrais porque identificam o padrão de responsabilidade pública: segurança, retenção, detecção, aviso e prova de exclusão são uma cadeia.

Essa cadeia é a razão pela qual este é um caso de dependência de serviço de nuvem. Os clientes não precisavam apenas de sua própria resposta a incidentes. Eles precisavam de evidências do fornecedor que pudessem ser convertidas em avisos legais, precisos e específicos ao cliente. Uma instituição de caridade não pode dizer responsavelmente aos apoiadores "nenhuma ação é necessária" se a própria revisão do fornecedor ainda não for forte o suficiente para apoiar essa afirmação.

Uma universidade não pode dizer aos ex-alunos se campos bancários ou números de identidade estavam envolvidos se o fornecedor analisou apenas nomes de arquivos e não os conteúdos relevantes. O tempo de notificação torna-se uma superfície de controle.

Dados de caridade não são de baixo risco porque a instituição é benevolente

A frase "dados de caridade" pode parecer suave. Não é. Um banco de dados de doadores pode conter nomes, endereços residenciais, endereços de e-mail, números de telefone, datas de nascimento, relações familiares, informações do empregador, indicadores de riqueza, interesses em doações patrimoniais, histórico de doações recorrentes, detalhes bancários, participação em eventos, preferências de voluntariado, afiliações ao conselho, notas de campanha, associação religiosa ou política, relacionamentos com fundações de saúde e históricos de contato que revelam vínculos privados.

Em um contexto universitário, os registros de ex-alunos podem incluir diploma, ano, identificadores de estudante, padrões de engajamento, detalhes de carreira e capacidade filantrópica. Em um contexto de fundação de saúde, o relacionamento institucional pode implicar proximidade sensível à saúde mesmo quando os registros clínicos não estão no sistema violado.

O Formulário 10-K de 2023 da Blackbaud emhttps://www.sec.gov/Archives/edgar/data/1280058/000128005824000013/blkb-20231231.htmdescreve produtos de captação de recursos e gestão de relacionamento, incluindo Raiser's Edge NXT, Blackbaud CRM, eTapestry, Luminate Online, TeamRaiser, JustGiving, Fundraiser Performance Management e Altru. As descrições dos produtos importam porque mostram a superfície de dependência: captação de recursos, formulários de doação, gestão de campanhas, doação digital, arrecadação de fundos para eventos, análise, engajamento, associação e registros de constituintes. Esses não são arquivos de clientes isolados. São memória operacional para instituições que muitas vezes têm relacionamentos longos com as pessoas.

Os avisos aos clientes tornam a camada humana visível. O aviso da Universidade do Alabama emhttps://giving.ua.edu/data/disse que a Blackbaud notificou a universidade em 16 de julho de 2020 de que um ataque de ransomware ocorreu em maio e que um subconjunto de dados de vários clientes foi copiado. O aviso do Sistema UNC emhttps://www.northcarolina.edu/blackbaud-information-security-incident/descreveu a Blackbaud como um dos maiores provedores de gestão de relacionamento com constituintes para educação superior e disse que o ambiente de dados auto-hospedado foi afetado. O aviso da Universidade Napier de Edimburgo emhttps://www.napier.ac.uk/alumni/alumni-news/latest-news/blackbaud-data-security-incidentlistou categorias incluindo detalhes de contato, detalhes de curso e educação, engajamento com atividades de ex-alunos e captação de recursos, detalhes profissionais e interesses fornecidos através de pesquisas.

Os avisos de caridade não eram idênticos porque os dados dos clientes não eram idênticos. O aviso da Child & Family Service emhttps://childandfamilyservice.org/securityincident/referia-se a informações biográficas, de contato, histórico de doações e relacionamentos. A Task Force for Global Health emhttps://www.taskforce.org/blackbaud-data-security-incident/descreveu um incidente de fornecedor terceirizado e uma investigação sobre o impacto nos dados de doadores. O aviso da Ridgewater College emhttps://ridgewater.edu/alumni-friends/ridgewater-college-foundation/blackbaud-data-security-incident/disse que a Blackbaud foi alvo entre 7 de fevereiro e intermitentemente até 20 de maio de 2020 e notificou a faculdade em 16 de julho. Esses avisos são valiosos porque mostram instituições a jusante traduzindo um evento de fornecedor em muitos relacionamentos de confiança locais.

O problema de responsabilidade é que essas instituições a jusante eram tanto vítimas quanto mensageiros. Elas tiveram que responder a perguntas de doadores, ex-alunos e apoiadores enquanto dependiam da investigação da Blackbaud. Elas também tiveram que avaliar se suas próprias práticas de dados tornaram o impacto pior: Elas armazenaram dados sensíveis em campos de texto livre? Elas fizeram upload de anexos não criptografados? Elas mantiveram registros antigos sem um propósito atual? Elas entenderam como a Blackbaud retinha dados de ex-clientes?

O fornecedor controlava a plataforma, mas os clientes controlavam algumas das escolhas de dados dentro dela. A responsabilidade segue ambas as camadas, nessa ordem.

Fatos confirmados, inferência apoiada e desconhecidos devem permanecer separados

Os fatos públicos confirmados são suficientes para tornar o caso sério. A ordem da SEC diz que mais de um milhão de arquivos relativos a mais de 13.000 clientes foram acessados e exfiltrados. Diz que a empresa detectou o ataque em 14 de maio de 2020, anunciou o incidente e notificou os clientes afetados em 16 de julho, arquivou um Formulário 10-Q em 4 de agosto e divulgou em um Formulário 8-K em 29 de setembro que campos não criptografados destinados a informações de contas bancárias, números de Seguro Social, nomes de usuário e/ou senhas podem ter sido acessados para alguns clientes.

O comunicado da FTC diz que a violação passou despercebida por três meses, milhões de dados pessoais de consumidores estavam envolvidos, a retenção desnecessária de dados foi parte do problema e a ordem exigiu a exclusão de dados não mais necessários e um programa abrangente de segurança da informação.

Os resultados de execução confirmados também são claros. O anúncio de outubro de 2023 da Blackbaud emhttps://www.blackbaud.com/intelligence team/article/blackbaud-resolves-multi-state-attorneys-general-investigation-of-2020-security-incidentdiz que concordou em pagar USD 49,5 milhões a 49 estados e ao Distrito de Columbia e implementar ou melhorar programas e ferramentas de segurança cibernética, evitando fazer declarações enganosas relacionadas a proteção de dados, privacidade, segurança, confidencialidade, integridade e questões de notificação de violação. O comunicado do Procurador-Geral de Nova York emhttps://ag.ny.gov/press-release/2023/attorney-general-james-and-multistate-coalition-secure-495-million-cloud-companydescreveu o acordo como resolvendo uma investigação multiestadual sobre a exposição de informações de doadores. O comunicado do Procurador-Geral da Califórnia emhttps://oag.ca.gov/news/press-releases/attorney-general-bonta-secures-675-million-settlement-against-blackbaud-overanunciou um acordo separado de USD 6,75 milhões em 2024. Esses são registros de resolução civil, não conclusões criminais.

A inferência apoiada é mais estreita. É razoável inferir que muitos clientes não puderam determinar independentemente o escopo do conteúdo do arquivo a partir de seus próprios sistemas porque o incidente ocorreu dentro do ambiente da Blackbaud e porque a ordem da SEC descreve a revisão de nomes de arquivos da Blackbaud e preocupações posteriores dos clientes sobre campos não criptografados. É razoável inferir que a qualidade da notificação foi desigual porque os avisos a jusante dependiam de informações do fornecedor em evolução.

É razoável inferir que a retenção desnecessária aumentou a população de pessoas expostas porque a FTC alegou que a Blackbaud reteve dados por mais tempo que o necessário, incluindo informações pertencentes a ex-clientes.

Os desconhecidos devem permanecer desconhecidos. O registro público não fornece uma lista completa de todos os clientes afetados, todas as pessoas afetadas, todos os nomes de arquivos, todos os campos copiados, todos os campos criptografados, todas as instâncias de produto específicas do cliente, todos os avisos privados, todas as comunicações com as autoridades, todas as comunicações com o invasor, todas as conclusões forenses ou todas as melhorias de segurança. Não prova que todos os registros copiados foram mal utilizados. Não prova que a exclusão pelo invasor ocorreu. Não prova que todos os clientes armazenaram dados de forma responsável.

Também não prova que toda a remediação posterior foi ineficaz. Um arquivo de responsabilidade responsável não deve preencher essas lacunas com acusações não apoiadas.

Essa separação não é uma formalidade legal. É a disciplina que a própria resposta a incidentes deve usar. Fatos confirmados dizem às pessoas qual ação tomar. Inferências apoiadas dizem aos clientes quais perguntas fazer. Desconhecidos dizem aos reguladores onde exigir evidências. Se as três categorias forem misturadas, a comunicação de violação se torna conforto falso ou pânico. O caso da Blackbaud mostra por que as categorias devem ser explícitas desde o primeiro aviso.

Pagamento de resgate não é prova de exclusão

O registro de pagamento de resgate é central porque muitos avisos a jusante repetiram a ideia de que a Blackbaud pagou e recebeu garantias de que os dados copiados foram destruídos. O comunicado da FTC emhttps://www.ftc.gov/news-events/news/press-releases/2024/02/ftc-order-will-require-blackbaud-delete-unnecessary-data-boost-safeguards-settle-charges-its-laxafirma que a Blackbaud pagou 24 Bitcoin após o invasor ameaçar expor os dados e, de acordo com a FTC, nunca verificou se o invasor realmente excluiu os dados roubados. Avisos de clientes como os da Edinburgh Napier, Child & Family Service e Universidade do Alabama descreveram garantias ou confirmação da Blackbaud sobre a exclusão. Esses avisos mostram a dependência a jusante da linguagem do fornecedor.

A questão de responsabilidade é que o pagamento de resgate pode ser uma decisão de crise, mas não é um controle de segurança. Não prova exclusão. Não prova que nenhuma cópia foi feita. Não prova que nenhum dado foi visualizado. Não fecha a questão da retenção. Não notifica as pessoas afetadas. Não repara o caminho de acesso. Não substitui criptografia, segmentação, autenticação multifator, gestão de vulnerabilidades, monitoramento, privilégio mínimo, validação de backup, minimização de dados e controles de divulgação.

O guia StopRansomware da CISA emhttps://www.cisa.gov/stopransomware/ransomware-guidee o guia de tratamento de incidentes do NIST emhttps://csrc.nist.gov/pubs/sp/800/61/r2/finalfornecem vocabulário público útil aqui. Eles não fazem conclusões sobre a Blackbaud. Eles definem por que um evento de ransomware deve ser tratado através de preparação, detecção, contenção, erradicação, recuperação, comunicação e lições aprendidas. Se um provedor paga um resgate, essa decisão fica dentro do registro de resposta. Não deve se tornar a prova de que os consumidores estão seguros.

Para clientes liderados por missão, o problema de exclusão é especialmente difícil. Uma instituição de caridade pode não ter a capacidade técnica para questionar a alegação de exclusão de um fornecedor. Uma universidade pode ter assessoria jurídica, mas não acesso às comunicações do invasor com o fornecedor. Uma pequena fundação pode emitir um aviso usando a redação do fornecedor porque tem pouco mais. É por isso que os reguladores importam.

A ordem da FTC exigindo exclusão de dados e cronogramas de retenção transformou uma alegação de exclusão em uma obrigação operacional: a empresa deve excluir dados que não precisa mais e documentar por que os dados retidos permanecem necessários.

A lição duradoura é que a exclusão de dados deve ser controlável antes de um incidente. Se uma empresa retém dados antigos de clientes porque o armazenamento é barato e a limpeza é complicada, ela cria uma população de violação maior. Se não pode provar o que estava em arquivos copiados, não pode emitir avisos precisos. Se confia em promessas de invasores, transferiu a prova de segurança para a parte menos confiável da cadeia. A responsabilidade exige evidências de exclusão que pertençam ao provedor, não ao invasor.

Avisos aos clientes mostram responsabilidade delegada sob pressão

Os avisos a jusante são a melhor evidência pública de como o incidente alcançou as comunidades. Avisos de universidades, instituições de caridade e fundações repetiram a descrição do evento da Blackbaud, explicaram categorias locais de dados e disseram às pessoas afetadas o que a instituição estava fazendo. Essa repetição não é um defeito por si só. É como a comunicação de incidentes de terceiros funciona. O defeito aparece quando a fonte a montante é incompleta, excessivamente certa ou lenta para atualizar.

O aviso da UNC emhttps://www.northcarolina.edu/blackbaud-information-security-incident/enquadrou a Blackbaud como um importante provedor de gestão de relacionamento com constituintes para educação superior. O aviso da Universidade do Alabama emhttps://giving.ua.edu/data/descreveu registros relacionados a doadores e a garantia de pagamento e exclusão do fornecedor. O aviso da Edinburgh Napier emhttps://www.napier.ac.uk/alumni/alumni-news/latest-news/blackbaud-data-security-incidentdescreveu campos de engajamento de ex-alunos e captação de recursos. A Task Force for Global Health emhttps://www.taskforce.org/blackbaud-data-security-incident/enfatizou informações de doadores e uma investigação institucional em andamento. Cada aviso teve que localizar o evento do fornecedor para uma comunidade distinta.

Isso é responsabilidade delegada. O fornecedor controla as evidências. O cliente controla o relacionamento com os constituintes. O constituinte carrega o risco. Se as evidências do fornecedor são tardias, o cliente parece evasivo. Se a higiene de dados do cliente é ruim, o incidente do fornecedor tem um efeito mais amplo. Se o constituinte perde a confiança, a missão da instituição de caridade pode sofrer mesmo quando a instituição de caridade não operou a infraestrutura comprometida. A linha entre risco do fornecedor e risco da missão desaparece.

A continuidade do setor público faz parte disso porque muitas organizações sem fins lucrativos, universidades e fundações adjacentes à saúde não são instituições decorativas. Elas apoiam educação, pesquisa médica, assistência social, patrimônio cultural, resposta a desastres, serviços comunitários e populações vulneráveis. Uma violação de registros de constituintes pode reduzir a confiança na captação de recursos, criar cargas de apoio, distrair a equipe e tornar as pessoas hesitantes em se engajar. O dano operacional nem sempre é uma interrupção do sistema.

Às vezes, o dano é uma interrupção da confiança: telefones tocam, doadores pedem explicações, ex-alunos questionam práticas de dados e a equipe perde tempo reconstruindo registros e obrigações legais.

O fornecedor deve, portanto, projetar a comunicação de incidentes para responsabilidade delegada. Isso significa escopo específico do cliente, rótulos claros de incerteza, orientação de ação, gatilhos de notificação suplementar, coordenação com reguladores e retenção de evidências. Também significa evitar garantias categóricas antes que o conteúdo dos arquivos e as práticas de campo do cliente sejam conhecidas. No caso da Blackbaud, os registros posteriores da SEC e FTC mostram por que a certeza precoce se tornou um passivo.

A execução transformou a qualidade da notificação em uma obrigação de controle

Os registros da SEC, FTC, procuradores-gerais estaduais e da Califórnia enfatizam cada um uma parte diferente da cadeia. A SEC analisou a divulgação a investidores e os controles de divulgação. A FTC analisou a proteção ao consumidor, segurança de dados, retenção, notificação e representações. Os procuradores-gerais estaduais analisaram a segurança de dados, notificação de violação e deveres de proteção ao consumidor em diferentes jurisdições. A Califórnia adicionou um registro de acordo separado. Juntos, eles transformaram a qualidade da notificação em uma obrigação de controle, não uma preferência de comunicação.

A reportagem da AP emhttps://apnews.com/article/dba8fac12af30f74691c7af4fec69a14é útil como resumo de notícias públicas porque descreve o acordo multiestadual e observa que a violação afetou mais de 13.000 organizações sem fins lucrativos e expôs informações sensíveis de milhões de pessoas, enquanto também observa que a Blackbaud não admitiu irregularidades no acordo. A reportagem da Reuters emhttps://www.reuters.com/legal/software-firm-blackbaud-pay-3-mln-misleading-disclosures-ransomware-attack-sec-2023-03-09/resumiu similarmente o acordo da SEC. As reportagens de notícias não substituem as ordens, mas mostram como os registros de execução se traduziram em entendimento público.

A qualidade da notificação tem vários componentes. Primeiro, tempo: o cliente aprendeu rápido o suficiente para proteger as pessoas afetadas? Segundo, especificidade: o aviso identificou as categorias de dados em questão? Terceiro, precisão: as alegações categóricas foram apoiadas por evidências? Quarto, dever de atualização: a empresa corrigiu os avisos quando novos fatos surgiram? Quinto, acionabilidade: as pessoas afetadas sabiam o que fazer? Sexto, responsabilidade: a empresa identificou quais fatos eram confirmados, quais estavam sob investigação e quais eram desconhecidos?

O registro público da Blackbaud mostra fraqueza em vários desses componentes. A ordem da SEC diz que o arquivamento de agosto omitiu o fato material de que alguns dados não criptografados de contas bancárias e números de Seguro Social foram exfiltrados, mesmo que os funcionários o soubessem. A FTC alegou que a Blackbaud esperou quase dois meses para notificar os clientes e depois enganou os consumidores sobre a extensão dos dados roubados, incluindo declarações de que os clientes não precisavam agir. Os acordos estaduais exigiram mudanças em torno da segurança de dados e práticas de notificação de violação.

Este é um caso sobre evidências se movendo muito lentamente através da organização.

Uma organização que lida com registros sensíveis de outras instituições deve tratar os controles de divulgação como parte da arquitetura de segurança. Ela precisa de um caminho desde as conclusões forenses até os avisos aos clientes, arquivamentos na SEC, reguladores de privacidade, scripts de call center, supervisão do conselho e remediação específica do cliente. Se esse caminho é informal, a primeira declaração pode se tornar uma armadilha. Equipes técnicas podem saber um fato, equipes de cliente outro, equipes legais outro e alta administração outro. O público recebe uma média de ignorância.

A retenção de dados tornou o problema de responsabilidade maior

O foco da FTC na retenção de dados é uma das partes mais importantes do registro da Blackbaud. A retenção é muitas vezes invisível até uma violação. Antes de um incidente, dados históricos extras podem parecer úteis: antigos doadores podem retornar, antigos ex-alunos podem doar, antigos participantes de eventos podem se juntar a uma campanha, anexos antigos podem ajudar a reconstruir um relacionamento. Após um incidente, dados extras se tornam inventário de exposição. Se a organização não pode explicar por que ainda mantém um campo, ela armazenou risco sem propósito.

O comunicado da FTC diz que a Blackbaud manteve dados por mais tempo que o necessário, incluindo informações pertencentes a ex-clientes. Esse detalhe importa porque muda a justiça da alocação de risco. Uma pessoa pode parar de doar, se formar, deixar um programa ou se retirar de uma campanha. A instituição original pode parar de usar um fornecedor. Se os dados permanecem em um ambiente hospedado anos depois, a pessoa exposta ainda carrega risco sem nenhum benefício de serviço atual. Uma falha de retenção pode transformar uma violação de fornecedor em um dano de longo prazo para pessoas que não têm maneira prática de exigir exclusão.

Soberania e localidade de dados também entram aqui. A Blackbaud apoiou clientes em muitos países, e seu Formulário 10-K de 2023 descreve operações nos Estados Unidos, Austrália, Canadá, Costa Rica e Reino Unido, com usuários em mais de 100 países. Esse contexto de plataforma global importa. Um cliente em uma jurisdição pode ter obrigações com doadores ou ex-alunos em outra. Uma universidade do Reino Unido, instituição de caridade canadense, fundação hospitalar dos EUA ou organização sem fins lucrativos australiana pode enfrentar diferentes obrigações de privacidade, notificação e retenção.

A arquitetura hospedada do fornecedor e os mapas de dados específicos do cliente se tornam infraestrutura legal.

A orientação de ransomware da ICO emhttps://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/security/a-guide-to-data-security/ransomware-and-data-protection-compliance/é contexto útil porque trata o ransomware como uma questão de proteção de dados, não apenas um incidente de malware. Ela não faz uma conclusão específica sobre a Blackbaud neste artigo. Mostra por que a análise de violação de dados pessoais deve incluir segurança, disponibilidade, confidencialidade, exfiltração, obrigações do controlador e processador e evidências. Em uma plataforma multi-inquilino sem fins lucrativos, essas obrigações são distribuídas, mas não diluídas.

A disciplina de retenção também é um dever do cliente. Os clientes não devem armazenar números de Seguro Social, detalhes bancários, notas médicas, informações de passaporte ou anexos sensíveis de texto livre em sistemas de relacionamento, a menos que tenham um propósito definido, postura de criptografia, política de acesso, cronograma de exclusão e garantia do fornecedor. A discussão da ordem da SEC sobre anexos e campos não criptografados é um aviso: os clientes podem criar bolsões de dados sensíveis dentro de sistemas que a aquisição pode não entender. O fornecedor deve proteger a plataforma, mas os clientes devem saber o que colocam nela.

A garantia ao cliente deve ser específica do produto

O registro da Blackbaud também mostra por que a garantia genérica do fornecedor é muito fraca para plataformas de gestão de constituintes. Um cliente sem fins lucrativos pode usar um produto para registros de doadores, outro para campanhas online, outro para captação de recursos para eventos e outro para análise ou gestão de subsídios. Cada produto pode armazenar dados diferentes, aplicar padrões diferentes, criar exportações diferentes e suportar diferentes práticas de anexo ou texto livre.

Se um aviso de incidente diz apenas que "dados do cliente" foram copiados, o cliente ainda precisa saber qual produto, quais campos, quais registros históricos, quais exportações e quais integrações estão envolvidos.

A garantia específica do produto deve começar com mapas de dados. Um cliente deve poder ver quais sistemas da Blackbaud contêm nomes, endereços, histórico de doações, campos bancários, números de identidade, campos de login, notas de engajamento, anexos, participação em eventos, links de relacionamento e arquivos importados. Deve saber se esses campos são criptografados, pesquisáveis, exportáveis, copiados em backup ou retidos após o término do contrato. Também deve saber se os administradores do cliente podem acidentalmente colocar dados sensíveis em campos mais fracos.

No caso da Blackbaud, o registro regulatório tornou o posicionamento de campo e anexo parte da história de responsabilidade. Isso deve se tornar uma lição de aquisição.

A mesma garantia deve cobrir integrações. Sistemas de captação de recursos raramente ficam sozinhos. Eles se conectam a processadores de pagamento, plataformas de e-mail, ferramentas de análise, formulários web, sistemas de eventos, data warehouses, sistemas financeiros e provedores de identidade. Um incidente de ransomware no ambiente principal do fornecedor pode não comprometer diretamente todas as integrações, mas o cliente ainda precisa saber se tokens, exportações, webhooks, logs de API ou arquivos importados estavam no patrimônio afetado.

Uma resposta estreita de "banco de dados" pode perder a realidade operacional de como o trabalho de captação de recursos é automatizado.

Pequenas instituições de caridade precisam dessas evidências em uma forma que possam usar. Uma grande universidade pode ter assessoria de privacidade, equipe de aquisição e revisores de segurança. Uma instituição de caridade local pode ter um gerente de operações, um captador de recursos de meio período e um membro do conselho responsável pela supervisão de tecnologia. Se a garantia do fornecedor é escrita apenas para advogados empresariais, os clientes com menos capacidade interna podem tomar as decisões de retenção e notificação mais fracas.

Um provedor de nuvem que atende instituições lideradas por missão deve, portanto, publicar garantias em camadas: um resumo do incidente em linguagem simples, um relatório de categorias de dados específico do cliente, uma atualização de controles de segurança e material mais profundo para clientes regulados ou de alto risco.

A garantia ao cliente também deve separar sistemas ativos de backups e arquivos. Os constituintes frequentemente assumem que, se pararem de doar ou pedirem a uma instituição de caridade para parar de contatá-los, seu risco diminui. Isso pode não ser verdade se exportações antigas, conjuntos de backup, arquivos de campanha arquivados ou bancos de dados de ex-clientes permanecerem. As preocupações de retenção da FTC tornam este ponto concreto. Um pacote de garantia defensável deve explicar cronogramas de exclusão e retenção de backup de uma forma que os clientes possam traduzir em seus próprios avisos de privacidade.

Finalmente, a garantia específica do produto deve ser contínua. Não deve começar apenas após um incidente. Os clientes devem revisar as categorias de dados na implementação, após campanhas importantes, ao importar registros legados, ao alterar fluxos de pagamento, ao ativar novos módulos e na renovação. Uma violação expõe decisões históricas. Melhor governança reduz o histórico que pode ser exposto.

Essa revisão contínua deve incluir design de funções, bem como campos de dados. Captação de recursos, relações com ex-alunos, administração de subsídios, finanças, eventos, gestão de voluntários e relatórios executivos podem todos exigir diferentes padrões de acesso. Se direitos amplos de administrador se tornarem um padrão de conveniência, o cliente cria uma superfície de exposição maior dentro do ambiente do fornecedor. Se o fornecedor não pode mostrar aos clientes onde existem funções privilegiadas, quando foram usadas pela última vez e quais exportações ou anexos podem alcançar, o cliente não pode governar sua parte do risco.

O registro da Blackbaud, portanto, aponta para uma obrigação de garantia compartilhada: o provedor deve tornar os controles do produto visíveis o suficiente para uso, e os clientes devem tratar esses controles como parte da administração de doadores e constituintes, em vez de uma configuração de back-office com revisão recorrente no nível do conselho.

O que o reparo durável deve provar

O reparo durável após o incidente da Blackbaud deve provar sete coisas. Primeiro, deve provar o escopo. O provedor deve saber quais produtos, clientes, arquivos, campos, anexos, categorias de dados e populações de pessoas foram afetados. A revisão de nomes de arquivos pode ser um ponto de partida, mas uma alegação de escopo que afeta informações bancárias ou números de identidade precisa de evidências em nível de conteúdo ou uma razão documentada pela qual a revisão em nível de conteúdo é impossível.

Segundo, deve provar a integridade da notificação. Deve haver uma rota documentada desde os fatos forenses até os avisos aos clientes, avisos suplementares, divulgações a investidores, relatórios a reguladores, scripts de call center e relatórios ao conselho. Se uma equipe técnica descobre que um aviso está errado, a correção não deve depender de escalonamento informal. O caso da SEC mostra que os controles de divulgação são eles próprios um resultado de segurança.

Terceiro, deve provar o controle de retenção. Os cronogramas de retenção de dados devem ser específicos do produto e do cliente o suficiente para explicar por que os dados são mantidos, quando serão excluídos e quem pode aprovar exceções. Os dados de ex-clientes não devem permanecer em ambientes de produção ou backup acessíveis sem uma necessidade defensável. Se a retenção for legalmente exigida, deve ser protegida de acordo com a sensibilidade.

Quarto, deve provar criptografia e governança de campos. Um provedor que permite campos de texto livre e anexos deve saber onde dados sensíveis podem aparecer fora de campos protegidos. A criptografia só ajuda se os clientes não puderem acidentalmente colocar dados sensíveis em locais não criptografados. Design de produto, orientação ao cliente, varredura, avisos e controles padrão são todos parte do reparo.

Quinto, deve provar controle de acesso e segmentação. A FTC alegou falhas em monitoramento, segmentação, autenticação multifator, controles de senha, controles de firewall e testes. Um reparo durável mostraria privilégio mínimo, autenticação mais forte, separação de ambiente, monitoramento de acesso privilegiado, fechamento de vulnerabilidades, cobertura de log e detecção testada.

Sexto, deve provar resposta a ransomware sem depender de garantias do invasor. Se os dados copiados são alegadamente destruídos, a empresa deve declarar quais evidências apoiam essa alegação e qual incerteza permanece. Se a exclusão não pode ser verificada, os avisos não devem implicar verificação. O pagamento não elimina o dever de notificação.

Sétimo, deve provar a governança do cliente. Os clientes da Blackbaud devem receber evidências que os ajudem a corrigir suas próprias práticas: uso de campos sensíveis, riscos de anexos, configurações de retenção, opções de criptografia, acesso a logs e modelos de aviso recomendados. O reparo do fornecedor é incompleto se os clientes puderem recriar os mesmos padrões de exposição dentro do produto.

A responsabilidade segue o controle sobre as evidências

A alocação final segue o controle prático. A Blackbaud controlava o ambiente hospedado, programa de segurança, resposta a incidentes, fornecedores forenses, primeiros avisos aos clientes, evidências de comunicação com o invasor, arquitetura de retenção de dados, salvaguardas do produto, controles de divulgação e cooperação com reguladores. Os clientes controlavam suas escolhas de coleta e uso de campo, avisos locais, relacionamentos com constituintes e governança pós-incidente. Os reguladores controlavam a execução.

As pessoas afetadas controlavam apenas um pequeno conjunto de ações protetivas depois de receberem informações suficientes para agir.

Essa alocação não requer acusações não apoiadas. Não diz que todo registro exposto foi mal utilizado. Não diz que todo cliente lidou mal com os dados. Não diz que toda salvaguarda posterior falhou. Diz que a parte com o portão de evidências tinha o maior dever de mover fatos precisos rapidamente. Os registros da SEC, FTC, estaduais, de clientes e públicos apontam todos para esse portão.

O caso da Blackbaud permanece importante porque mostra um custo oculto da concentração de nuvem para organizações sem fins lucrativos. Instituições lideradas por missão podem agrupar dados operacionais dentro de um fornecedor especializado e ganhar eficiência. Mas quando o fornecedor é comprometido, doadores, pacientes, alunos e apoiadores se tornam uma população de dano distribuído. Eles não são apenas clientes de uma instituição de caridade. Eles são titulares de dados em um sistema de fornecedor que podem não saber que existe.

A lição duradoura é simples e difícil: um provedor de nuvem para o setor social deve ser capaz de provar o que detém, o que foi copiado, o que foi criptografado, o que foi retido desnecessariamente, o que foi dito aos clientes, o que mudou quando novos fatos surgiram e quais salvaguardas previnem recorrência. Sem essa prova, a notificação de dados de caridade se torna um exercício de confiança emprestada. Com essa prova, os clientes podem transformar um incidente de fornecedor em comunicação precisa, oportuna e responsável, em vez de garantia generalizada.