Basta desconectar a internet
(computer.rip)- Depois de grandes incidentes de segurança como o da CrowdStrike, costuma surgir a reação de que “não deveria estar conectado à internet”, mas muitos sistemas de trabalho têm como função central a troca de informações, então não se resolve isso com um bloqueio simples
- Sistemas que atravessam fronteiras organizacionais e geográficas, como os de reservas e escalonamento de companhias aéreas, são mais próximos de uma infraestrutura de comunicação que substituiu telefone e telégrafo; se você remove a rede, também elimina seu valor original
- “Não conectado à internet” pode incluir desde equipamento isolado, air gap rigoroso, data diode, WAN privada, túnel VPN, roteamento restrito até uma AWS private VPC, então o modelo de ameaças muda bastante
- Em ambientes offline ou com conectividade limitada, tudo eleva tempo e custo: atualizações do SO, gerenciadores de pacotes, repositórios internos, armazenamento de confiança TLS, licenças em nuvem, atualizações de conteúdo e até o tratamento de imagens Docker
- Dá para aplicar políticas de rede restritivas a mais sistemas e criar software pensando em operação offline, mas o ecossistema de software atual ainda assume conectividade com a internet como padrão
O limite da ideia de “não conecte à internet”
- Sempre que um grande incidente de segurança vira notícia, volta a reação de que “esse tipo de sistema não deveria estar conectado à internet”
- Esse julgamento tem apelo intuitivo do ponto de vista de segurança e estabilidade, mas há poucos ambientes que realmente operam assim
- O problema central é que dizer apenas “não está conectado à internet” não especifica bem o bastante o projeto real, o custo operacional nem o modelo de ameaças
Sistemas corporativos modernos se parecem mais com dispositivos de comunicação
- Em abstrato, computadores podem criar valor por meio de computação, mas sistemas do mundo industrial têm um caráter mais forte de tecnologia da informação do que de cálculo
- Tecnologia da informação precisa receber e emitir dados, e o modelo antigo em que um operador colocava fitas é mais caro e mais lento do que comunicação em tempo real
- A maior parte dos computadores corporativos modernos funciona, na prática, como dispositivo de comunicação
- Não são muitos os sistemas que geram valor sem se conectar a outros sistemas de trabalho
- Essas conexões muitas vezes atravessam fronteiras organizacionais e geográficas
- Sistemas de reservas e escalonamento de companhias aéreas surgiram como substitutos de telefone e telégrafo, e a rede faz parte da própria função
Manutenção e operação também precisam de rede
- Mesmo quando comunicação em tempo real não é essencial para o objetivo do sistema, a conexão de rede traz grande valor operacional
- Sem conexão com a internet, já surgem bloqueios básicos: como buscar atualizações de software e como monitorar o sistema
- Mesmo que se decida que o sistema está “pronto” e não precisa de atualização nem de monitoramento em tempo real, as exigências do negócio mudam com o tempo
- A conectividade de rede reduz bastante o custo de lidar com essas mudanças
“Sem internet” tem vários níveis
- O estado de “não conectado à internet” não tem um significado único; é um conjunto de várias formas de implementação
- As formas possíveis vão de isolamento total a conectividade limitada
- Equipamento isolado sem qualquer conexão de rede
- Air gap rigoroso, sem conexão além de uma LAN privada e sem dados atravessando a fronteira de segurança
- Air gap em que os dados entram na zona segura por DVD-R
- Estrutura que move dados de uma rede de baixa segurança para uma de alta segurança com cross-domain solution ou data diode
- Estrutura que usa cross-domain solution sem certificação da NSA
- WAN privada também se divide em vários níveis
- WAN privada com infraestrutura física totalmente independente e medidas contra adulteração
- Uso de dutos compartilhados, leased dark fiber ou wavelength de lit fiber
- Virtual private ethernet baseada em MPLS
- Virtual private ethernet baseada em tunelamento com criptografia e autenticação
- Tráfego privado sobre rede pública também às vezes é chamado de “desconectado”
- Equipamentos de hardware estabelecendo túneis com criptografia e autenticação sobre uma common-carrier network como a internet
- Uso de equipamentos sem certificação da NSA
- Túnel de software validado, configurando a pilha de rede do sistema operacional em baixo nível para impedir bypass do túnel
- Túnel de software com menor nível de validação
- Combinação de WireGuard com scripts de
iptables
- Conectividade de internet restrita também entra no mesmo rótulo
- Rede privada que só permite fluxos de tráfego extremamente estreitos via roteamento baseado em política
- Estrutura em que os fluxos permitidos ficaram registrados em tickets antigos do Jira, e alguns foram adicionados só “para fazer funcionar”
- Estrutura baseada em firewall com outbound relativamente permissivo e inbound rígido
- Até em nuvem o escopo varia
- AWS private VPC sem roteamento externo
- VPC que se comunica com outras private VPC por PrivateLink e afins
- Estrutura em que parte das VPCs conectadas tem roteamento para a internet
- Estrutura com NAT Gateway e Internet Gateway, mas com security groups rigidamente configurados nos dois sentidos
- Todos esses formatos já foram chamados de “não conectado à internet”, mas a superfície de ataque e o risco são diferentes em cada um
- Ao dizer que um sistema de reservas aéreas “não deveria estar conectado à internet”, se isso não significar ausência total de rede, então na prática se está falando de um desses estágios intermediários, e cada um traz considerações operacionais diferentes
Ambientes offline aumentam muito custo e prazo
- Operar software em redes sem internet ou com acesso fortemente restrito aumenta bastante as estimativas de prazo e custo
- Formas mais brandas, como AWS private VPC, podem ser estimadas em algo como 3x a 5x
- Formas fortes, próximas de isolamento total, podem chegar a 10x ou muito mais
- Quase todo o ecossistema de software foi desenhado assumindo conectividade com a internet
- O sistema operacional tenta buscar atualizações em servidores online
- Fornecedores de SO pagos podem oferecer infraestrutura interna de atualização por uma licença paga separada
- Em SOs gratuitos dá para resolver por conta própria, mas isso pode virar um grande incômodo se você usar tecnologia mais nova
- No desenvolvimento e na entrega, vários problemas se repetem com gerenciadores de pacotes e repositórios internos
- O nível de suporte a repositórios privados internos varia entre os gerenciadores de pacotes
- A complexidade cresce com a combinação de vários gerenciadores, formas de chamada e ambientes de execução
- Certificados TLS de serviços internos também geram trabalho recorrente
- Serviços dentro da rede privada muitas vezes não usam certificados incluídos no programa de raízes de uma CA pública
- Alguns componentes, como o JRE, têm trust store próprio, e em certas stacks o comportamento muda conforme a biblioteca
- Mesmo com trust store do sistema operacional, ajustes separados podem ser necessários se cada ferramenta usa seu próprio armazenamento
- Verificação de licenças e entitlements em nuvem também vira obstáculo
- Alguns softwares tentam se conectar a serviços externos para confirmar licenças em nuvem
- As saídas variam de adicionar grandes exceções no firewall a emitir um esquema de licenciamento sob medida, e isso pode levar tempo
- Atualização de conteúdo offline pode se tornar complexa só pelos processos do fornecedor
- Em um caso de software corporativo, foi preciso passar por um portal antigo de suporte ao cliente e por um portal separado de entitlement
- Levaram mais de 3 meses para abertura de conta e escalonamento, e o portal final tinha certificado TLS inválido
- O procedimento documentado para aplicar a atualização já não funcionava mais, exigindo longas trocas de e-mails com engenheiros
- Pagou-se um valor de cinco dígitos por uma licença anual, mas ela quase expirou ainda na fase de preparação para uso, e o atraso na emissão da licença de renovação interrompeu o pipeline de CI
- A dificuldade de operar offline não vem de uma tarefa individual ser impossível, mas do fato de que tudo fica um pouco mais difícil: é uma espécie de death by a thousand cuts
- Produtos que não foram pensados para ambientes offline costumam ser adaptados com scripts temporários e remendos, e essa dívida técnica acaba sendo transferida para os clientes que operam offline
- A Red Hat lida relativamente bem com essa área, mas o tempo economizado acaba sendo pago em dinheiro
Esses ambientes são raros e concentrados em certos setores
- Formas fortes de ambiente sem internet aparecem principalmente em defesa e agências de inteligência
- Alguns bancos também mantêm práticas fortes de segregação de rede
- Defesa, inteligência e bancos também são conhecidos por serem setores caros e lentos, e isso não é desvinculado dessa forma de operação
- Formas mais brandas de conectividade restrita aparecem sobretudo em setores altamente regulados, como finanças e saúde
- Ocasionalmente, empresas comuns de software também fecham a rede de forma muito rígida por darem prioridade extrema à segurança
Respostas práticas possíveis agora
- Ter menos sistemas conectados à internet, por si só, não é uma má ideia
- Mas a indústria atual de software ainda não está preparada para operar com conforto em ambientes sem internet ou com conectividade restrita
- A resposta realista se aproxima mais de ampliar conectividade limitada e capacidade de operação offline do que de clamar por isolamento total
-
Restringir ao máximo as políticas de rede
- É preciso aplicar políticas de rede restritivas ao maior número possível de sistemas
- Provedores de nuvem hoje facilitam esse tipo de configuração mais do que no passado
- Na AWS, operar um ambiente prático sem roteamento para a internet não é exatamente fácil, mas também não é difícil a ponto de ser inviável
- Se você ficar dentro do escopo dos AWS managed service, em geral há menos dor, embora com custo
-
Criar software pensando em ambientes offline
- Recursos que precisam acessar serviços externos deveriam poder ser desativados sempre que possível
- Se desativar for difícil, o cliente deveria ao menos poder trocar o endpoint usado
- Se for possível trocar o endpoint, também é preciso oferecer uma forma de o cliente operar seu próprio endpoint
- Se for apenas arquivo estático, isso pode ser servido facilmente com algo como nginx e um diretório
- Se for uma API, talvez seja necessário entregar a implementação interna ao cliente, o que traz carga de manutenção
-
Reduzir suposições sobre TLS e dependências
- Em ambientes offline, pequenas suposições sobre conectar-se a outros serviços se tornam complexas
- Não se deve presumir acesso ao Let’s Encrypt
- Ambientes offline quase sempre envolvem uma autoridade certificadora interna
- Deve-se usar o system trust store
- Não se deve buscar requisitos ou dependências no momento do deploy
- O Docker tinha como vantagem tornar pacotes autocontidos, mas há contêineres que nem começam se não conseguirem acessar repositórios npm e semelhantes
- Às vezes é preciso alterar o TLS trust store em cada contêiner Docker, então em ambientes offline o Docker pode acabar dificultando ainda mais a administração
A relação entre o incidente da CrowdStrike e a conexão com a internet
- No caso do incidente da CrowdStrike, a reação “por que isso estava conectado à internet?” apareceu várias vezes, mas o fato de haver conexão com a internet é quase ortogonal ao problema ocorrido
- A atualização de conteúdo da CrowdStrike é justamente o tipo de atualização que, em um ambiente ideal, também deveria ser entregue rapidamente a ambientes offline
- Na prática, em ambientes offline fortes, o mirror interno de atualização da CrowdStrike pode ficar dias, semanas, meses ou anos atrasado
- Esse atraso pode até evitar o problema, mas isso se parece mais com duas falhas se anulando por acaso
1 comentários
Opiniões no Hacker News
Trabalho com segurança/sistemas/operações, mas discordo fundamentalmente dessa premissa. Entendo quando o autor diz que “não é tão fácil assim” e concordo totalmente, mas isso não significa que o trabalho esteja sendo bem feito
Infelizmente, a maioria não faz um bom trabalho, e o setor inteiro foi projetado para permitir que se sobreviva mesmo fazendo mal feito, ao mesmo tempo em que torna difícil fazer bem
Se você está implantando sinalização digital, o acesso de rede deveria ser tratado com lista de permissões apenas para o endereço IP do meu servidor, e só deveria aceitar conexões estabelecidas com atualizações assinadas e fixação de certificado (certificate pinning)
Isso torna quase impossível para um atacante remoto mexer no sistema. Olhando para a indústria de segurança que cresceu com a expansão da Internet das Coisas (IoT), certamente há sinalizações ou outros equipamentos IoT/SCADA/implantados por aí com portas abertas e senhas padrão
IoT é apenas um computador, mas também é um computador ainda mais abandonado do que servidores ou máquinas virtuais que já não são operados corretamente
Existem lugares que fazem bem, mas são uma minoria minúscula, porque a estrutura não recompensa fazer bem. Seguir “boas práticas” ou orientações de fornecedores muitas vezes não significa fazer bem, e sim fazer apenas o bastante para que o fornecedor dê suporte; em muitos casos, isso significa acesso irrestrito à rede
Ainda é preciso se preocupar com bugs de rede, vulnerabilidades criptográficas, erros de configuração e outros problemas que poderiam permitir a um atacante remoto explorar o sistema. Para sustentar esse argumento, é preciso dar um exemplo que literalmente não esteja conectado à internet, não apenas um caso mais bloqueado
Não entendo bem em que ponto você diverge do autor do blog. Ou você quer dizer que, como as pessoas não têm essa capacidade, é fundamentalmente impossível melhorar a segurança de sistemas conectados à internet?
Na Suécia existe uma rede privada separada da internet chamada Sjunet, usada por prestadores de serviços de saúde. O objetivo é tornar computadores dispositivos de comunicação úteis, sem expor a TI hospitalar à internet inteira
Espera-se que os membros da Sjunet conheçam suas próprias redes e mantenham controle rígido sobre a TI
A Sjunet também pode ser vista como um ambiente com air gap em nível de setor. Acredito que ela melhore a segurança e, ao mesmo tempo, custe menos do que cada organização operar sua própria rede com air gap e enormes listas de permissões
Isso dá uma falsa sensação de segurança e também vira desculpa para políticas de segurança ruins. A largura de banda é baixa e cara
É uma rede que conecta órgãos como repartições distritais e prefeituras, permitindo acesso a um banco de dados central onde ficam armazenados dados pessoais dos cidadãos. É usada para coisas como mudança de endereço, emissão de nova identidade e registro de nascimento ou casamento
Até onde sei, o aplicativo “Źródło” roda em um computador separado, com “air gap”; não tem internet, mas acessa a rede interna, e autentica usando um certificado criptográfico de cliente via smartcard
Todos estão com os patches mais recentes? Sabe-se que as pessoas não conectam qualquer dispositivo USB?
Algo parecido com Tor, mas sem as coisas suspeitas
Como engenheiro de controle, construí centenas de máquinas. Elas têm cabos Ethernet para redes de fieldbus, mas nunca devem ser conectadas à internet.
Em cada oficina de ferramentas e moldes do parque industrial local há máquinas CNC com portas Ethernet que não devem ser colocadas na internet. Toda fábrica com equipamentos sob medida, linhas transportadoras, prensas, robôs, CNCs, estações de bombeamento etc. usa Ethernet, mas também usa sistemas PLC e HMI que não são adequados para exposição à internet.
O texto diz que os computadores modernos de trabalho são quase principalmente dispositivos de comunicação, e que há poucos sistemas práticos que geram valor sem se conectar a outros sistemas de trabalho, mas ignora toda a manufatura e os dispositivos eletrônicos que essa manufatura produz.
Milhões de sistemas embarcados e PLCs verificam a cada 1 milissegundo se o estado de entradas digitais físicas e lógicas mudou e, se mudou, alteram o estado de saídas digitais físicas e lógicas, gerando valor o dia inteiro.
Não há necessidade de colocar um sistema de segurança de 2024 em uma máquina de solda por resistência cuja fundição foi feita há mais de 100 anos, e cuja última atualização, em 2003, foi adicionar um PLC e uma tela monocromática para configurar receitas. Basta ir até lá com uma prancheta, inserir os valores-alvo e derreter o aço com precisão.
Normalmente, para se conectar a essas máquinas, é preciso levar um notebook, pegar um cabo patch Ethernet e ir andando até a frente da máquina. Se for preciso mais do que isso, espera-se que o cliente as coloque em uma rede de tecnologia operacional (OT) com firewall, ou use equipamentos SCADA/VPN como Tosibox ou Ixon para fazer a ponte entre tecnologia da informação (IT) e OT.
O que você lida pode não ser algo que alguém queira explorar, mas PLCs são encontrados com frequência em infraestrutura crítica e instalações de manufatura avançada, o que os torna alvos atraentes para agentes maliciosos. Eles podem tentar explorar infraestrutura crítica ou infectar dispositivos com segurança fraca aos quais, em algum momento, um endpoint de alto valor, como um notebook de engenharia, possa se conectar diretamente.
https://www.cisa.gov/news-events/cybersecurity-advisories/aa... - Infra de água
https://claroty.com/team82/research/evil-plc-attack-using-a-...
Ainda não me convence o argumento de que não se deve isolar um sistema em air gap porque isso impede o uso de práticas de desenvolvimento centradas na internet. Acho esse argumento absurdo.
Se é um sistema cujas portas Ethernet deveriam ser seladas com epóxi, ele nunca deveria ter sido programado usando práticas de desenvolvimento centradas na internet. Uma máquina de MRI busca dependências JS no NPM ao iniciar? Cadeia na hora. Não é metáfora, é literalmente isso.
Depois de ver um vídeo de alguém mexendo em um quiosque do McDonald’s, comecei a tentar fazer a mesma coisa com equipamentos que via em vários lugares.
Em uma praça de alimentação havia um quiosque com Windows instalado e acesso total à internet. Alguém poderia ter baixado malware e roubado dados de cartão de crédito. Toda vez que eu usava, desligava a energia ou deixava uma mensagem na tela, e no fim eles passaram a colocá-lo em modo quiosque.
Outro era um quiosque de estacionamento, que não tinha nenhum endurecimento de segurança. Parece que os criminosos ainda não perceberam.
O terceiro era um display interativo de uma marca de cerveja. Não era algo que pudesse causar grande dano, mas era bom abrir o Bloco de Notas e deixar escrito “Drink water”. No fim desligaram, o que também é uma solução.
“Não dar dinheiro a pedestres aleatórios” deveria estar bem no alto da lista de requisitos, mas na prática não estava.
Essa parte faz muito sentido para mim. Eu estava tentando fazer o trust store do JRE do IntelliJ entender que precisava usar um novo certificado para o zscaler; havia dois ou três JDKs selecionáveis, e eu coloquei o novo certificado no trust store de cada um, mas ainda assim não funcionava, e eu não conseguia descobrir por quê.
Também existe a hamnet. Sobre o bloco de IPs 44Net, parte dele pode ser roteada pela internet e parte não.
https://hamnetdb.net/map.cgi
Como usa faixas de frequência de radioamador, há restrições interessantes. Uso comercial é totalmente proibido.
Esse é o contrato social dessas faixas de frequência: você pode ter acesso barato a muitas bandas, de 136 kHz a 241 GHz, mas não pode ganhar dinheiro com isso.
Só é razoavelmente difundida na Holanda e na Alemanha: https://hamnetdb.net/map.cgi . Aqui na Espanha não dá para usar em nenhum lugar perto de mim.
Parece bastante óbvio que o sistema de reservas de companhias aéreas pelo menos precisa estar conectado a uma rede, e não ouvi muita gente dizer que tudo deveria ficar offline. Mas também ouvi, por exemplo, que máquinas de torno em oficinas pararam por causa deste incidente.
Vale pensar se elas realmente precisavam estar online. Claro que deve haver motivos, mas esses motivos precisam ser ponderados contra os riscos.
Além disso, há muitos exemplos ainda mais absurdos conectados à internet, como geladeiras, chaleiras e portas de garagem. Não sei se essas coisas foram afetadas pelo incidente da CrowdStrike, mas, mesmo que não tenham sido, na próxima é só questão de tempo.
Quanto à afirmação de que sistemas desconectados são “muito, muito irritantes”, pela minha experiência como usuário, toda segurança é “muito, muito irritante”. Autenticação em dois fatores, troca obrigatória de senha, dispositivos bloqueados, scanners de malware, sanitizadores de links — alguns são necessários e outros são bobagem, mas não tenho credenciais para distinguir qual é qual, e é certo que todos criam atrito.
A grande conclusão que tirei não foi “todos esses sistemas não devem ser conectados à internet”, mas algumas outras coisas.
Primeiro, sistemas assim não devem permitir fluxos de rede de saída. Isso bloquearia todas as atualizações automáticas, e depois elas poderiam ser gerenciadas por um canal interno de distribuição.
Segundo, mesmo sem fazer isso, muitos produtos de software corporativo permitem desativar atualizações automáticas. O Windows é o exemplo mais conhecido, e o próprio CrowdStrike também é assim. Ouvi dizer que, entre os clientes da CS, houve quem escapasse do impacto ao desativar as atualizações automáticas e fazer a distribuição manual.
Terceiro, além do item 2, as atualizações devem ser distribuídas gradualmente depois de passar por alguns smoke tests. Vai que, né. Também ouvi dizer que, entre os clientes da CS, houve quem fizesse distribuição gradual e conseguisse limitar o impacto a apenas alguns equipamentos.
É um texto que resume muito bem a época em que eu entregava soluções de IA de ponta para clientes militares. 80% do esforço era gasto para fazer com que ferramentas que pressupunham internet rodassem de forma fluida em ambientes air-gapped.