Sumário

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

A ION Cleared Derivatives pertence a um arquivo de risco e responsabilidade porque mostra como um único provedor de tecnologia pode se tornar um gargalo de continuidade em um mercado construído sobre obrigações distribuídas. Membros compensadores, corretores, bolsas, usuários finais, reguladores e plataformas de processamento de negociações não estão todos dentro de uma empresa. No entanto, uma interrupção em um provedor pode impedir que muitas empresas processem negociações, concluam relatórios, validem dados e reconectem-se com segurança ao resto do mercado.

A declaração pública da ION emhttps://iongroup.com/press-release/markets/cleared-derivatives-cyber-event/diz que a ION Cleared Derivatives, uma divisão da ION Markets, sofreu um evento de segurança cibernética com início em 31 de janeiro de 2023 que afetou alguns de seus serviços. Diz que o incidente foi contido a um ambiente específico, todos os servidores afetados foram desconectados e a remediação dos serviços estava em andamento. Essa declaração é curta, mas é a principal fonte da empresa para a existência, data, quadro de contenção, decisão de desconexão e postura de remediação.

A declaração da CFTC emhttps://www.cftc.gov/PressRoom/SpeechesTestimony/cftcstatement020223fornece a visão pública do regulador dois dias depois. Diz que a equipe da CFTC trabalhou com colegas reguladores, participantes do mercado e partes impactadas para entender o incidente cibernético e ajudar a garantir que os mercados de derivativos regulados pela CFTC não fossem comprometidos. Diz que o problema afetou a capacidade de alguns membros compensadores de fornecer dados oportunos e precisos à CFTC. Também diz que o relatório semanal Commitments of Traders seria adiado até que todas as negociações pudessem ser relatadas, e que as empresas afetadas deveriam usar as melhores estimativas para relatórios diários de grandes traders e arquivar relatórios revisados assim que os sistemas estivessem operacionais.

Esse é o quadro de responsabilidade. O incidente não precisou destruir uma câmara de compensação ou parar um mercado inteiro para ser importante. Afetou o pipeline de evidências. Os reguladores precisavam de dados oportunos e precisos. Os usuários do mercado público esperavam o relatório Commitments of Traders. Os membros compensadores tinham obrigações legais e operacionais de relatórios.

Se uma interrupção de fornecedor impede essas saídas, a questão de responsabilidade se torna como empresas, fornecedores, reguladores e órgãos da indústria coordenam relatórios em modo degradado sem transformar estimativas e trabalho manual em um ponto cego permanente.

O caso também é importante porque o registro público pós-ação é excepcionalmente explícito. O relatório de setembro de 2023 da FIA diz que a interrupção foi desencadeada por um ataque de ransomware a um único provedor de serviços terceirizado usado por muitos corretores de compensação globalmente. Diz que o ataque demonstrou que uma interrupção em um único provedor de serviços pode ter efeitos prejudiciais em uma ampla gama de empresas e ameaçar o funcionamento ordenado do mercado.

Também diz que algumas empresas impactadas precisaram de até duas semanas de trabalho intensivo para reunir e processar registros de negociações perdidos e reconectar sistemas ao resto do mercado. Essa é uma declaração clara de concentração e ônus de recuperação.

O cronograma público confirmado passou de contenção para atraso de relatório e recuperação

O cronograma público confirmado começa em 31 de janeiro de 2023, a data na declaração da ION. A empresa disse que alguns serviços foram afetados, o incidente foi contido a um ambiente específico, os servidores afetados foram desconectados e a remediação estava em andamento. A declaração pública não identifica o invasor, vetor de acesso inicial, exposição de dados, demanda de resgate, número de clientes ou cronograma de restauração sistema por sistema. O artigo, portanto, trata esses detalhes como desconhecidos, a menos que apoiados por outras evidências públicas.

Em 1º de fevereiro, a FIA publicou um comentário público emhttps://www.fia.org/fia/articles/fia-comments-ion-group-cyber-incident. A FIA disse que estava ciente de problemas de rede causados por um incidente cibernético em certos sistemas do ION Group que estavam impactando a negociação e compensação de derivativos negociados em bolsa pelos clientes da ION em mercados globais. A FIA disse que estava trabalhando com membros impactados, incluindo empresas de compensação e bolsas, bem como reguladores de mercado e outros, para avaliar o impacto na negociação, processamento e compensação. Também disse que estava coordenando comunicação e compartilhamento de informações por meio de chamadas regulares para avaliar empresas impactadas, como as empresas poderiam mitigar a interrupção e clareza sobre obrigações regulatórias e relatórios afetados.

Em 2 de fevereiro, a CFTC publicou sua primeira declaração pública. Disse que o problema afetou a capacidade de alguns membros compensadores de fornecer dados oportunos e precisos. Vinculou o incidente a dados atrasados exigidos por registrantes e ao atraso do relatório semanal Commitments of Traders. Instruiu as empresas de relatórios afetadas a usar as melhores estimativas para relatórios diários de grandes traders e arquivar relatórios revisados assim que os sistemas estivessem operacionais.

Essa é uma instrução notável de modo degradado público: continue a conformidade o máximo possível, use estimativas quando necessário, coordene com a equipe e repare o registro depois.

Em 10 de fevereiro, a CFTC emitiu um acompanhamento emhttps://www.cftc.gov/PressRoom/PressReleases/8655-23. Disse que o impacto do incidente havia sido mitigado, mas as empresas responsáveis pelos relatórios continuavam enfrentando problemas com o envio oportuno e preciso de dados. Disse que o relatório Commitments of Traders continuaria a ser adiado até que todas as negociações pudessem ser relatadas e que um relatório seria publicado após recebimento e validação. Novamente disse às empresas afetadas para continuarem seus melhores esforços para acelerar as obrigações de conformidade e arquivar relatórios revisados assim que os sistemas estivessem operacionais.

Em 16 de fevereiro, a CFTC anunciou emhttps://www.cftc.gov/PressRoom/PressReleases/8662-23que o relatório Commitments of Traders normalmente programado para 17 de fevereiro seria adiado. A equipe pretendia retomar a publicação já em 24 de fevereiro, começando com o relatório originalmente programado para 3 de fevereiro, e então emitir sequencialmente os relatórios perdidos de forma acelerada, sujeito ao envio preciso e completo dos dados. O registro público, portanto, mostra um atraso de relatório medido em semanas, não em horas.

O cronograma é importante porque cada fase tinha um dever de responsabilidade diferente. Durante a contenção, a ION teve que isolar servidores afetados e remediar serviços. Durante a resposta do mercado, membros compensadores e bolsas tiveram que continuar negociando, compensando e processando onde possível e identificar obrigações regulatórias afetadas. Durante a resposta do regulador, a equipe da CFTC teve que preservar as expectativas de conformidade enquanto permitia melhores estimativas e relatórios revisados.

Durante a recuperação, todas as partes tiveram que validar dados acumulados antes que os relatórios públicos pudessem ser retomados.

O incidente expôs a concentração de terceiros nos fluxos de trabalho pós-negociação

A concentração de terceiros é frequentemente discutida como um problema de nuvem, data center ou rede de pagamentos. O incidente da ION mostra que a concentração também pode residir em software pós-negociação especializado. Os mercados de derivativos negociados em bolsa e compensados não são apenas mecanismos de correspondência e câmaras de compensação. Eles também dependem de ferramentas de gestão de ordens, execução, negociação, alocação, transferência, captura de negociações, compensação, liquidação, conciliação, risco e relatórios regulatórios.

Um fornecedor que se situa nesses fluxos de trabalho pode se tornar crítico mesmo sem ser ele próprio a contraparte central.

O relatório pós-ação da FIA é a principal fonte pública para este ponto. Diz que um ataque de ransomware a um único provedor de serviços terceirizado usado por muitos corretores de compensação globalmente desencadeou uma interrupção significativa no processamento de negociações executadas em múltiplas bolsas. Diz que o ataque foi notável pela escala e gravidade, e que demonstrou como uma interrupção em um provedor de serviços pode ter efeitos prejudiciais em uma ampla gama de empresas.

Também diz que a força-tarefa trabalhou com a presunção de que ataques futuros terão sucesso, focando na recuperação em vez de assumir que a prevenção sempre funcionará.

Esse enquadramento é útil porque evita duas posições fracas. A primeira posição fraca é assumir que, se os mercados regulados não foram comprometidos, o incidente foi meramente um problema de fornecedor. As declarações da CFTC mostram por que isso é muito restrito: relatórios e dados públicos de mercado foram atrasados. A segunda posição fraca é assumir que a segurança cibernética é apenas sobre prevenir a entrada. O relatório da FIA diz que futuros ataques devem ser assumidos e a recuperação deve ser melhorada. Em mercados complexos, a qualidade da recuperação é uma questão de controle de mercado.

A inferência apoiada é que as empresas que dependem de um fornecedor compartilhado precisam de um inventário de dependências vivo, não de uma lista estática de fornecedores. Um inventário vivo deve mostrar quais funções de negócios dependem do fornecedor, quais relatórios dependem dos dados do fornecedor, quais soluções alternativas manuais existem, quais funcionários podem operá-las, quais clientes são afetados, quais bolsas e câmaras de compensação estão envolvidas, quais reguladores precisam de notificações e quais portões de reconexão devem ser satisfeitos antes que os fluxos normais sejam retomados.

Desconhecidos permanecem. O registro público não identifica todos os clientes da ION, todas as bolsas afetadas, todos os produtos afetados, todos os registros de negociações perdidos ou todas as soluções alternativas. Também não mostra como cada empresa individual contratou para resiliência, acesso a dados, objetivos de tempo de recuperação, direitos de auditoria, notificação cibernética ou suporte de reconexão. O artigo não reivindica esses detalhes. Identifica as categorias de evidência que importam quando um provedor apoia muitas empresas.

Os atrasos nos relatórios transformaram uma interrupção de fornecedor em um problema de evidência do mercado público

As declarações da CFTC são importantes porque mostram que o incidente passou de recuperação privada de fornecedor para dados regulatórios públicos. O relatório Commitments of Traders é amplamente usado por participantes do mercado, analistas e pesquisadores para entender o posicionamento. Um atraso nesse relatório não é o mesmo que uma parada de mercado, mas é uma lacuna de evidência pública. Significa que reguladores e usuários estão esperando por dados completos, precisos e validados das empresas afetadas.

A declaração da CFTC de 2 de fevereiro diz que as empresas de relatórios afetadas não tinham informações suficientes naquele momento para preparar completamente os relatórios diários de grandes traders exigidos pela Parte 17 dos regulamentos da CFTC. Os requisitos de relatório de grandes traders da Parte 17 da CFTC estão disponíveis no texto regulamentar emhttps://www.ecfr.gov/current/title-17/chapter-I/part-17. A declaração disse às empresas afetadas para usarem as melhores estimativas e arquivarem relatórios revisados assim que os sistemas estivessem operacionais. Essa linguagem preserva a responsabilidade: as estimativas são permitidas como uma ponte temporária, mas devem ser revisadas quando o registro estiver disponível.

As divulgações de 10 e 16 de fevereiro da CFTC mostram que o problema de relatório persistiu mesmo após o impacto ter sido mitigado. A divulgação de 16 de fevereiro descreveu um plano de recuperação sequencial, começando com o relatório perdido de 3 de fevereiro e depois emitindo relatórios perdidos de forma acelerada, sujeito a dados acumulados precisos e completos. Esse é um exemplo prático de governança de relatórios em modo degradado. O regulador não publicou simplesmente dados incompletos porque o mercado queria um relatório. Esperou pelo recebimento e validação.

A inferência apoiada é que a continuidade dos relatórios regulatórios deve ser projetada antes de um incidente. As empresas devem saber quais relatórios dependem de sistemas de fornecedores, quais dados-fonte podem ser exportados, como as estimativas são criadas, quem as aprova, como as revisões são rastreadas, como os reguladores são notificados e como os registros acumulados são validados. O fornecedor deve saber quais exportações de dados do cliente são necessárias para apoiar relatórios degradados, e os clientes não devem ter que fazer engenharia reversa durante uma interrupção.

A questão pública de responsabilidade não é se a equipe da CFTC lidou com o atraso razoavelmente; o registro público sugere uma abordagem estruturada. A questão é se os participantes do mercado e fornecedores tinham capacidade de portabilidade de dados e reconstrução de relatórios suficientemente planejada. O relatório da FIA sugere que algumas empresas precisaram de trabalho intensivo para reunir e processar registros de negociações perdidos. Isso implica uma lacuna entre os fluxos de trabalho automatizados normais e as necessidades de evidência de emergência.

Reconexão é uma decisão de controle, não apenas um reinício técnico

A declaração da ION diz que os servidores afetados foram desconectados. O relatório pós-ação da FIA posteriormente enfatizou a reconexão como uma grande lição. A reconexão em um ambiente de mercado financeiro não é simplesmente conectar os sistemas de volta. Requer garantia de que o ambiente está limpo, os dados são precisos, as interfaces são seguras, as contrapartes estão prontas, os reguladores são informados e os clientes entendem quais registros foram processados normalmente e quais precisam de conciliação.

O relatório da FIA diz que a reconexão exigiu atestações e que requisitos díspares adicionaram atraso. Trata a reconexão como uma das etapas críticas no processo de recuperação. Isso é importante porque cada empresa afetada tem que decidir quando é seguro reconectar a um provedor que sofreu um incidente cibernético, e cada provedor tem que fornecer evidências suficientes para satisfazer clientes com diferentes políticas de risco, reguladores, câmaras de compensação, bolsas e padrões de controle interno.

A inferência apoiada é que os padrões de reconexão devem ser pré-negociados. As empresas não devem descobrir durante um evento de ransomware que cada cliente exige um pacote de evidências diferente, cada bolsa tem um limite diferente, cada regulador espera uma notificação diferente e cada comitê de risco interno pede atestações diferentes.

Um pacote básico de reconexão pode incluir status de contenção do incidente, escopo do ambiente afetado, evidência de erradicação de malware, verificações de integridade, status de reconciliação de dados, revisão de acesso privilegiado, status de patches e configuração, validação de terceiros e uma declaração clara de risco residual.

A reconexão também tem implicações de equidade de mercado. Se algumas empresas reconectam mais cedo do que outras porque seus requisitos de evidência são mais leves, a capacidade operacional pode retornar de forma desigual. Isso não prova injustiça ou má conduta. Significa que a reconexão não é apenas um julgamento de segurança cibernética. Afeta negociação, compensação, relatórios, atendimento ao cliente, carga de trabalho e potencialmente posição competitiva. Um bom quadro de responsabilidade deve tornar esses critérios de reconexão transparentes o suficiente para serem previsíveis antes do próximo incidente.

O artigo não afirma que as decisões de reconexão da ION foram deficientes. A evidência pública não permite essa conclusão. Diz que o evento demonstrou que a própria reconexão deve ser um padrão de controle da indústria, porque um provedor que atende muitos corretores de compensação não pode restaurar a confiança uma conversa bilateral de cada vez.

Membros compensadores carregaram o ônus operacional do incidente de outra pessoa

Um dos problemas difíceis de responsabilidade em incidentes de fornecedores é a transferência de custos. Um fornecedor pode ser a parte comprometida, mas os clientes carregam o ônus operacional. No incidente da ION, membros compensadores e outras empresas tiveram que avaliar processos impactados, continuar a atividade de mercado onde possível, preparar melhores estimativas, depois enviar relatórios revisados, reunir registros de negociações perdidos, processar acúmulos e satisfazer requisitos internos e externos de reconexão. Esse trabalho não é gratuito.

O comentário da FIA de 1º de fevereiro diz que a associação trabalhou com membros impactados, empresas de compensação, bolsas, reguladores de mercado e outros para avaliar o impacto na negociação, processamento e compensação. Isso significa que o ônus foi distribuído pela indústria. O relatório pós-ação da FIA diz que algumas empresas impactadas precisaram de até duas semanas de trabalho intensivo para reunir e processar registros de negociações perdidos e reconectar sistemas. Essa é uma declaração direta do esforço de recuperação do lado do cliente.

A inferência apoiada é que contratos de terceiros e programas de resiliência devem alocar obrigações de recuperação com mais precisão. Se um provedor suporta funções críticas pós-negociação, os contratos devem abordar direitos de exportação de dados, suporte de emergência, prazo de notificação de incidentes, objetivos de recuperação, garantia independente, evidência de reconexão, participação em testes, responsabilidade, coordenação com o cliente e assistência voltada ao regulador.

Se esses termos forem vagos, os clientes podem descobrir durante um incidente que seus direitos teóricos de continuidade não se traduzem em dados e suporte utilizáveis.

Esta não é apenas uma questão contratual bilateral. As observações do Departamento do Tesouro emhttps://home.treasury.gov/news/press-releases/jy2029discutem resiliência operacional, transparência, concentração e a necessidade de provedores de serviços assumirem mais responsabilidade pela segurança dos clientes. Embora essas observações não sejam conclusões específicas sobre a ION, elas capturam um tema político que se encaixa no caso: onde clientes do setor financeiro dependem de provedores de tecnologia concentrados, o ônus da resiliência não deve recair inteiramente sobre o cliente.

Os desconhecidos são importantes. O registro público não divulga os contratos da ION, compromissos de nível de serviço, comunicações de recuperação com clientes, créditos financeiros, custos de incidentes, reivindicações de seguro, postura de litígio ou qualquer acordo regulatório com a ION. O artigo não infere esses fatos. Diz que o registro público do incidente torna essas categorias de responsabilidade relevantes.

A atribuição de ransomware deve ser tratada com cautela

Reportagens públicas, incluindo a Reuters emhttps://www.reuters.com/technology/hackers-say-ransom-paid-case-derivatives-data-firm-ion-company-declines-comment-2023-02-03/, discutiram alegações de hackers e afirmações relacionadas a resgate. Outras reportagens descreveram alegações do LockBit e possível contexto de pagamento. Esses relatórios são úteis para entender a narrativa pública e a preocupação do mercado, mas não são tratados aqui como prova de pagamento de resgate, exfiltração de dados ou causa raiz técnica.

A razão para a cautela é a mesma de outros arquivos de responsabilidade de ransomware. Os invasores têm incentivos para exagerar. Uma listagem na dark web não é um relatório forense. Uma alegação de resgate pode ser impossível de verificar a partir de fontes públicas. Um relatório de que a empresa se recusou a comentar não é confirmação. A análise pública deve evitar converter marketing do adversário em fato estabelecido.

Os fatos públicos confirmados são suficientes. A ION confirmou um evento de segurança cibernética afetando alguns serviços, contenção em um ambiente específico, desconexão de servidores e remediação em andamento. A CFTC confirmou atrasos de relatórios e impactos na capacidade de alguns membros compensadores de fornecer dados oportunos e precisos. A FIA confirmou coordenação da indústria e posteriormente descreveu a interrupção como desencadeada por um ataque de ransomware a um único provedor usado por muitos corretores de compensação. Essas fontes estabelecem o caso de responsabilidade sem depender de alegações de atores de ameaça.

O guia de ransomware da CISA emhttps://www.cisa.gov/stopransomware/ransomware-guide, a Estrutura de Segurança Cibernética do NIST emhttps://www.nist.gov/cyberframeworke o NIST SP 800-61 Rev. 3 emhttps://csrc.nist.gov/pubs/sp/800/61/r3/finalfornecem contexto geral para resposta a incidentes, recuperação, comunicação e melhoria. Não são provas privadas sobre a ION. Ajudam a definir o que uma resposta madura deve documentar.

O artigo, portanto, mantém um limite firme. Pode dizer que o evento foi discutido publicamente como ransomware porque o relatório pós-ação da FIA usa esse enquadramento. Pode dizer que a Reuters reportou alegações de hackers. Não pode dizer que o resgate foi pago, que dados específicos foram roubados, que uma vulnerabilidade específica foi explorada ou que um ator específico foi definitivamente responsável, a menos que uma fonte pública primária o estabeleça.

A resposta da CFTC mostra como a conformidade em modo degradado pode funcionar

As declarações públicas da CFTC são úteis porque não fingem que os relatórios continuaram normalmente. Reconhecem que algumas empresas não tinham informações suficientes para preparar completamente os relatórios diários de grandes traders. Permitem melhores estimativas, exigem coordenação com a equipe e exigem relatórios revisados após os sistemas se tornarem operacionais. Atrasam o relatório Commitments of Traders até que as negociações possam ser relatadas e os dados validados. Esse é um modelo pragmático de conformidade em modo degradado.

Isso é importante porque os mercados regulados não podem esperar pela recuperação perfeita antes de cada obrigação ser retomada. Ao mesmo tempo, não podem tratar as estimativas como definitivas. A resposta da CFTC criou uma ponte: melhores esforços agora, revisões depois, publicação após validação, recuperação sequencial. Esse modelo é aplicável além dos relatórios de derivativos. Em qualquer incidente cibernético de mercado financeiro, os reguladores precisam de uma maneira de receber dados provisórios sem perder o registro probatório final.

A inferência apoiada é que as empresas devem ter manuais de 'estimar e revisar' para relatórios regulamentados. O manual deve definir quando as estimativas são permitidas, como são rotuladas internamente, quais fontes de dados as suportam, quem as aprova, qual nível de confiança é atribuído, como os relatórios revisados são gerados, como as diferenças são explicadas e como o registro final é preservado. Sem esses controles, as estimativas podem se tornar palpites descontrolados. Com controles, as estimativas podem manter os reguladores informados enquanto preservam a obrigação de corrigir.

O registro público não mostra como cada empresa de relatórios afetada implementou a instrução da CFTC. Não mostra se as estimativas foram materialmente imprecisas, quantos relatórios revisados foram arquivados, quantas empresas foram afetadas ou se alguma ação de execução se seguiu para um relator específico. O artigo não reivindica esses resultados. Identifica as declarações da CFTC como evidência de um modo degradado gerenciado pelo regulador.

A lição mais ampla de responsabilidade é que reguladores e órgãos da indústria devem predefinir categorias de relatórios degradados para incidentes de terceiros. Se um fornecedor crítico estiver inativo, as empresas devem saber quais campos podem ser estimados, quais campos não podem, quais relatórios devem ser arquivados tardiamente, quais revisões são obrigatórias e quais relatórios públicos devem esperar pela validação. O incidente da ION mostrou que essas questões não são teóricas.

A coordenação da indústria foi necessária porque nenhuma empresa era dona de todo o problema

O papel da FIA é importante porque nenhum membro compensador poderia resolver sozinho uma interrupção de fornecedor com múltiplas empresas. A FIA coordenou comunicação e compartilhamento de informações, realizou chamadas com as partes relevantes, avaliou empresas impactadas, explorou mitigação e buscou clareza sobre obrigações regulatórias e relatórios. Mais tarde, a FIA criou uma força-tarefa de risco cibernético e emitiu conclusões e recomendações. Esse é um modelo de responsabilidade em nível de indústria: quando as dependências são compartilhadas, a coordenação deve ser compartilhada.

A declaração do Comissário da CFTC em 8 de março emhttps://www.cftc.gov/PressRoom/SpeechesTestimony/johnsonstatement030823é útil porque colocou o incidente da ION em uma discussão mais ampla sobre resiliência operacional, resposta a incidentes graves, proteção de ativos e informações de clientes, provedores de serviços terceirizados e a criação da força-tarefa da FIA. Também conectou a discussão à Estratégia Nacional de Segurança Cibernética, disponível emhttps://www.whitehouse.gov/wp-content/uploads/2023/03/National-Cybersecurity-Strategy-2023.pdf, que enfatizou o reequilíbrio de responsabilidades e o realinhamento de incentivos.

A inferência apoiada é que a concentração de fornecedores precisa de exercícios coordenados antes de incidentes. Um bom exercício incluiria o provedor, principais clientes, câmaras de compensação, bolsas, reguladores, órgãos da indústria e talvez destinatários críticos de dados. Testaria notificação de incidentes, priorização de clientes, exportação de dados, processamento manual, relatórios regulatórios, critérios de reconexão, comunicação pública e evidências pós-ação. Se a primeira chamada de coordenação completa acontecer após o incidente, a indústria já está atrasada.

A coordenação da indústria também tem que preservar limites de responsabilidade. Um órgão da indústria pode compartilhar informações e coordenar chamadas, mas não pode substituir a obrigação de um fornecedor de restaurar e evidenciar seus sistemas. Um regulador pode permitir melhores estimativas, mas não pode completar os registros de um membro compensador. Um cliente pode criar soluções alternativas, mas não pode ver dentro do ambiente forense do provedor. Cada ator tem um domínio de controle diferente. Um bom registro pós-ação deve tornar esses domínios explícitos.

O caso ION é valioso porque as fontes públicas mostram as camadas juntas: declaração da empresa, declarações do regulador, coordenação da indústria, relatório pós-ação e discussão política. Muitos incidentes cibernéticos deixam apenas um aviso escasso da empresa. Aqui, o público pode ver como um incidente de fornecedor terceirizado se moveu através das operações de mercado e evidências regulatórias.

A automação de segurança deve incluir reconstrução de registros de negociações e relatórios

O manifesto inclui automação de segurança, e o incidente da ION mostra por que a automação não pode parar na detecção de endpoints. Para um provedor de fluxos de trabalho de derivativos compensados, a automação deve suportar contenção, reconstrução limpa, verificações de integridade de dados, comunicação com o cliente, exportação de registros de negociações, reconstrução de relatórios, sequenciamento de acúmulos e evidência de reconexão. Se a recuperação depender inteiramente da descoberta manual de registros perdidos, o mercado paga pela lacuna.

O relatório da FIA diz que algumas empresas precisaram de trabalho intensivo para reunir e processar registros de negociações perdidos. Essa frase é operacionalmente importante. Sugere que os sistemas normais não forneceram um pacote de recuperação limpo e imediatamente utilizável para cada empresa impactada. Isso pode ser compreensível durante um evento de ransomware, mas é exatamente o que a engenharia de resiliência deve melhorar. A identificação de registros perdidos deve ser rápida, estruturada e auditável.

A inferência apoiada é que provedores e clientes devem manter visualizações de dados independentemente recuperáveis para obrigações críticas de compensação e regulatórias. Isso não significa duplicar todos os sistemas de produção em cada ambiente de cliente. Significa identificar os dados mínimos necessários para reconstruir negociações, posições, relatórios, alocações, transferências, submissões de compensação e conciliações se o ambiente do fornecedor estiver indisponível. Também significa testar se essas exportações podem ser usadas por equipes operacionais reais sob pressão de tempo.

As orientações de resposta a incidentes do NIST e as orientações de ransomware da CISA são úteis aqui porque enfatizam preparação, comunicação, contenção, erradicação, recuperação e lições aprendidas. Mas os provedores de tecnologia de mercado financeiro precisam de sobreposições específicas de domínio. Um backup genérico não é suficiente se não puder suportar relatórios regulatórios. Um ticket de incidente genérico não é suficiente se os clientes precisarem de linhagem de dados em nível de campo.

Um status de restauração genérico não é suficiente se os membros compensadores precisarem saber quais negociações estão faltando e quais relatórios exigem revisão.

Desconhecidos permanecem em torno da arquitetura da ION e controles do cliente. O registro público não divulga design de backup, design de exportação de dados, cobertura de registro, segmentação, acesso privilegiado, regras de detecção, método de reconstrução ou validação externa. O artigo não infere esses detalhes. Diz que o incidente demonstra o tipo de automação e evidência que deveria existir para fornecedores críticos pós-negociação.

Como seria um reparo responsável para um fornecedor crítico de mercado

As fontes públicas não publicam o roteiro de remediação interno da ION, e este artigo não afirma conhecê-lo. Ainda assim, o registro da CFTC e da FIA identifica o que o reparo responsável deve ser capaz de provar. O primeiro requisito é um mapa de serviços útil em uma emergência. Deve mostrar quais fluxos de trabalho do cliente dependem de cada serviço, quais relatórios dependem de cada conjunto de dados, quais bolsas e locais de compensação estão conectados, quais clientes precisam de notificação imediata e quais exportações de dados suportam operações degradadas.

Um catálogo de serviços genérico não é suficiente quando os clientes precisam saber quais registros de negociações estão faltando.

O segundo requisito são dados de recuperação portáveis. Clientes críticos não devem ter que esperar por uma restauração completa do fornecedor antes de identificar suas próprias lacunas de relatório. Um provedor pode proteger a segurança e a confidencialidade enquanto ainda projeta exportações de emergência, relatórios de integridade e dicionários de dados que permitem aos clientes reconstruir negociações, posições, alocações, transferências, submissões de compensação e relatórios regulatórios.

Essas exportações devem ser testadas com usuários reais, porque um arquivo que apenas engenheiros podem interpretar não suportará um prazo de conformidade real.

O terceiro requisito é um padrão de reconexão. A discussão sobre reconexão no relatório da FIA mostra por que isso é importante. Os clientes precisam saber quais evidências serão fornecidas antes que as interfaces sejam restauradas: status de contenção, escopo do ambiente afetado, evidência de erradicação de malware, método de reconstrução, verificações de integridade, revisão de acesso privilegiado, status de patches, status de monitoramento, validação de terceiros e problemas residuais conhecidos. Se esses elementos forem negociados durante um incidente, a recuperação desacelera e a confiança se torna desigual.

O quarto requisito é um manual compartilhado de relatórios em modo degradado. As instruções de melhor estimativa e relatório revisado da CFTC foram pragmáticas, mas as empresas não devem ter que inventar a mecânica durante um evento de ransomware. O manual deve definir rótulos de estimativa, proprietários de aprovação, gatilhos de revisão, rastreamento de variação, comunicações com o regulador e retenção final de evidências. Também deve identificar quais campos de dados são muito sensíveis ou muito incertos para estimar sem coordenação explícita com o regulador.

O quinto requisito é exercício da indústria. Um incidente de provedor com múltiplos clientes não pode ser totalmente testado dentro de uma empresa. Fornecedores, membros compensadores, bolsas, câmaras de compensação, reguladores e associações da indústria devem ensaiar notificação, exportação de dados, processamento manual, atraso de relatório, comunicação pública e reconexão. O objetivo não é publicar todos os controles sensíveis. O objetivo é tornar a próxima resposta menos improvisada e reduzir a quantidade de evidências críticas de mercado presas dentro de um ambiente prejudicado.

Fatos confirmados, inferência apoiada e desconhecidos

Fatos públicos confirmados incluem que a ION Cleared Derivatives, uma divisão da ION Markets, sofreu um evento de segurança cibernética com início em 31 de janeiro de 2023 que afetou alguns serviços; que a ION disse que o incidente foi contido a um ambiente específico; que os servidores afetados foram desconectados; e que a remediação estava em andamento.

Fatos públicos confirmados também incluem que a FIA disse que o evento afetou a negociação e compensação de derivativos negociados em bolsa pelos clientes da ION em mercados globais e que a FIA coordenou comunicação com membros impactados, empresas de compensação, bolsas, reguladores e outros.

Fatos públicos confirmados incluem que a equipe da CFTC disse que o incidente afetou a capacidade de alguns membros compensadores de fornecer dados oportunos e precisos, atrasou dados exigidos por registrantes, atrasou o relatório Commitments of Traders, exigiu que as empresas afetadas usassem as melhores estimativas para relatórios diários de grandes traders e exigiu relatórios revisados assim que os sistemas se tornassem operacionais.

Fatos públicos confirmados incluem a declaração de 10 de fevereiro de que os problemas de relatório persistiram mesmo após o impacto ter sido mitigado, e a declaração de 16 de fevereiro descrevendo um relatório CoT adiado e recuperação sequencial planejada.

Fatos públicos confirmados incluem as conclusões pós-ação da FIA de que um ataque de ransomware a um único provedor terceirizado usado por muitos corretores de compensação globalmente desencadeou uma interrupção significativa no processamento de negociações executadas em múltiplas bolsas, que o ataque mostrou como uma interrupção de um único provedor de serviços pode danificar uma ampla gama de empresas e ameaçar o funcionamento ordenado, e que algumas empresas impactadas precisaram de até duas semanas de trabalho intensivo para reunir e processar registros de negociações perdidos e reconectar sistemas.

A inferência apoiada inclui a visão de que concentração de fornecedores terceirizados, continuidade de relatórios, conformidade em modo degradado, portabilidade de dados, evidência de reconexão, controle de trabalho alternativo manual, ônus de recuperação do lado do cliente e coordenação da indústria são todas superfícies de responsabilidade neste incidente. A inferência apoiada também inclui a visão de que fornecedores críticos devem fornecer dados de recuperação testados e garantia de reconexão fortes o suficiente para que clientes regulamentados cumpram obrigações sob estresse.

Desconhecidos permanecem importantes. O registro público não divulga o vetor de acesso inicial, atribuição definitiva do atacante de uma fonte primária, demanda de resgate, pagamento de resgate, roubo de dados, número exato de clientes afetados, todos os produtos e bolsas afetados, lacunas de relatório empresa por empresa, perdas específicas de clientes, cronograma completo de restauração, termos de contrato, créditos de serviço, resultados de seguros, conclusões forenses privadas ou correspondência regulatória final com a ION ou empresas afetadas. O artigo não preenche essas lacunas com acusação.

O teste de responsabilidade duradouro

O teste de responsabilidade duradouro é se um mercado pode manter sua cadeia de evidências intacta quando um fornecedor crítico pós-negociação é interrompido. A declaração pública da ION mostra o quadro de contenção do provedor. As declarações da CFTC mostram a degradação de relatórios gerenciada pelo regulador e a recuperação. Os materiais da FIA mostram coordenação da indústria, risco de concentração, ônus de reconexão e a necessidade de assumir que futuros ataques terão sucesso. Juntas, essas fontes mostram um caso de responsabilidade de tecnologia financeira, não uma interrupção estreita de fornecedor.

Para membros compensadores, a lição é que a dependência de fornecedores deve ser acompanhada de dados de recuperação independentes, procedimentos manuais testados e estimativas e revisões de relatórios pré-planejadas. Para fornecedores, a lição é que a contenção é apenas o primeiro dever; os clientes precisam de acesso a registros de negociações, sequenciamento de recuperação, evidência de reconexão e comunicações claras. Para reguladores, a lição é que os relatórios em modo degradado devem ser projetados antes de um incidente de fornecedor e devem incluir mecânica de validação e revisão.

Para órgãos da indústria, a lição é que dependências compartilhadas exigem exercícios compartilhados e canais de resposta compartilhados.

A ION Cleared Derivatives tornou o ransomware um teste de responsabilidade de continuidade de compensação porque revelou como a interrupção de um provedor terceirizado pode se mover através do processamento de negociações para dados regulatórios e evidências públicas de mercado. O provedor controlou o ambiente afetado e a remediação. Os clientes controlaram suas próprias soluções alternativas e obrigações de relatório. Os reguladores controlaram as expectativas de relatório e o tempo de publicação.

A responsabilidade exigiu que todos os três trabalhassem juntos, com evidências suficientes para provar não apenas que os sistemas voltaram, mas que negociações, relatórios, reconexões e dados acumulados estavam completos e confiáveis.