O verdadeiro custo do risco de terceiros: a lição de £1,9 bilhão da Jaguar Land Rover

Por Carlos Cabral

Em agosto do ano passado, um invasor entrou na rede da Jaguar Land Rover. A montadora ficou semanas com a produção parada. O impacto financeiro direto, segundo o próprio balanço trimestral divulgado pela empresa, foi de £485 milhões em prejuízo antes de itens excepcionais. Trata-se de uma reversão brusca frente ao lucro de £398 milhões do mesmo trimestre do ano anterior.

A própria JLR atribui essa reversão principalmente ao incidente cibernético, somado a fatores como tarifas americanas sobre importação de veículos e queda no volume de vendas. Além disso, a empresa registrou mais £196 milhões em custos excepcionais ligados diretamente à contenção e resposta ao incidente. Muita gente diz que “quem converte não se diverte”, então vou reservar a vocês o espanto de converter esses valores para reais, mas o total ultrapassa £680 milhões.

Até aí, este foi mais um caso de ransomware. No entanto, observá-lo como “apenas” mais um caso envolvendo uma categoria de ameaça cibernética tira um pouco do impacto que um incidente como este causa em uma indústria com cadeia de suprimentos grande e diversa, como o setor automobilístico.

O que deveria incomodar todo executivo, sobretudo o CIO, pois é pra você (e para seu time) que eu escrevo aqui no IT Forum, é o que veio depois. O Cyber Monitoring Centre do Reino Unido estimou o dano à economia britânica em £1,9 bilhão, quase três vezes o prejuízo direto da Jaguar Land Rover.

Já o Banco da Inglaterra, em seu relatório trimestral de política monetária de novembro do ano passado, atribuiu o crescimento do PIB britânico abaixo do projetado no terceiro trimestre em parte à “disrupção ligada ao ataque cibernético contra a Jaguar Land Rover”. E o governo britânico garantiu um empréstimo de £1,5 bilhão para manter viva a cadeia de mais de cinco mil fornecedores que dependem da montadora e não tinham nenhuma responsabilidade pelo incidente. Segundo a BBC, acredita-se que é a primeira vez na história que tal ajuda é concedida no Reino Unido.

Ficou claro o tamanho do dano agora?

Uma empresa é atacada e o prejuízo dela é relevante, mas quem quase quebra é a rede de terceiros que depende dela. O risco de fornecedor, nesse caso, correu na direção contrária de tudo que os comitês de risco brasileiros ainda desenham em seus mapas de calor.

Não quero dizer que o inverso não é relevante. Muito pelo contrário: o próprio vetor de ataque à Jaguar Land Rover pode ter tido origem em um terceiro (a JLR nunca confirmou publicamente como o invasor entrou). No entanto, sob a perspectiva do impacto financeiro, pouco importa o caminho do atacante.

Essa história serve para sair do óbvio e entender que o que faz do risco de terceiros o tema de maior aquecimento no radar executivo recente é algo muito maior do que colocar cláusulas em contrato e marcar caixas em planilhas de compliance.

O risco de terceiros deixou de ser unidirecional e a sua due diligence pode não ter sido desenhada para isso

Durante anos, gestão de risco de terceiros significou uma pergunta: “esse fornecedor pode me contaminar?”. O caso Jaguar Land Rover demanda a pergunta inversa, igualmente relevante: “se eu parar, quantos dos meus fornecedores quebram comigo?”.

Leia mais: Daniela Santos redesenha a gestão de pessoas na Simpress

O Gartner projeta que até 2028 metade dos programas de Third-Party Cybersecurity Risk Management (TPCRM) vai abandonar o modelo de prevenção baseado em questionários e migrar para o monitoramento contínuo, porque muitas organizações ainda confiam demais em respostas de due diligence que nem sempre têm um pé na realidade

Assim como acontece em diversos outros processos, estamos caminhando para um due diligence automatizado por IA. No entanto, automatizar o preenchimento de um formulário não aumenta a confiança nele. Só aumenta a velocidade com que uma resposta ruim circula. É preciso somar a isso outra mudança: o fim do perímetro de segurança como o concebíamos antes da computação em nuvem, algo que ainda teima em habitar a mente de muitos profissionais da velha guarda.

O perímetro virou conceito histórico

A governança de TI tradicional foi desenhada para um mundo de ativos relativamente estáveis: você inventariava o que tinha, avaliava risco, aplicava controles e auditava de novo dali a alguns meses. Se a “foto” estivesse igual ao que foi definido no momento do estabelecimento dos controles, muito bem. Caso contrário, isso gerava um “ponto de auditoria” que deveria ser remediado. Tal modelo pressupõe um perímetro identificável: algo que possa ser mapeado, congelado por tempo suficiente para ser avaliado e revisado em ciclos previsíveis. Esse pressuposto não existe mais.

Quando a infraestrutura crítica está hospedada em ambientes que você não controla fisicamente, quando uma dependência de um pacote de software pode ser alterada por um terceiro sem que ninguém na sua empresa saiba e quando o próprio processo de desenvolvimento depende de dezenas de ferramentas externas atualizadas continuamente, a auditoria periódica passa a avaliar uma fotografia que já estava desatualizada no momento em que foi tirada.

É preciso estar preparado para analisar o “streaming” da vida real e não mais as “fotos” de um passado que se expande rapidamente à medida que múltiplos elementos vivos de seu ecossistema estão continuamente mudando. O problema não é a frequência da auditoria. É que a auditoria pressupõe um objeto estável para auditar e esse objeto não existe mais da forma como era.

Três mudanças que não são nada cosméticas

O caminho para proteger sua organização passa por uma reformulação na governança que exige atuação em três frentes. Nenhuma delas se resolve com mais um framework em cima da estrutura atual.

De auditoria periódica para visibilidade contínua. O SBOM (Software Bill of Materials) deixou de ser boa prática para virar pré-requisito básico para saber o que está rodando dentro da própria operação. Isso ajuda as áreas de TI e de segurança a monitorar pacotes vulneráveis, desatualizados ou cujo desenvolvimento foi abandonado entre os componentes que seu software precisa para funcionar. E se algo mudar (seja em uma dependência de software, nos privilégios de um usuário de serviço ou em outras características relevantes da ferramenta), o alerta precisa ser automático.

De perímetro para identidade como unidade de confiança. Quando não há mais fronteira física para proteger, a arquitetura que faz sentido é a que verifica continuamente quem está acessando o quê, e não a que assume confiança implícita dentro de um perímetro que não existe mais. Zero trust, nesse contexto, não é posicionamento de marketing de fornecedor, é a única lógica arquitetural coerente com a realidade atual.

De risco de terceiros tratado como cláusula contratual para risco de terceiros tratado como risco próprio. Risco não se terceiriza. No entanto, muitas empresas ainda gerenciam fornecedores de software e de cloud através de questionários de compliance preenchidos uma vez por ano. Mas quando um fornecedor é comprometido, o impacto recai integralmente sobre quem usa tal serviço, não sobre quem o presta. Tente explicar para seu cliente que o risco não é seu e veja o resultado. Garantir níveis adequados de saúde em termos de segurança exige monitoramento ativo da cadeia de fornecedores, não apenas avaliação documental no momento da contratação.

O caso Jaguar Land Rover nos oferece muito para pensar em termos das dependências que temos com fornecedores e também com os nossos clientes, sobretudo em termos de negócios, para além das questões técnicas. Se você se vê como um responsável pela saúde da segurança de sua organização, vale a pena se fazer três perguntas: você tem visibilidade contínua sobre o que roda na sua cadeia de software, ou ainda confia em auditoria anual? Sua arquitetura de acesso verifica identidade a cada solicitação, ou ainda pressupõe um perímetro que não existe mais? E se o seu fornecedor mais crítico sair do ar amanhã, quem paga essa conta, ele ou você?

Siga o IT Forum no LinkedIn e fique por dentro de todas as notícias!