OpenCyber AcademyMapa da aula
Aula 11 publicada. Mapa, exemplo, EX021.
flowchart TD
N0["11.1 O que o sistema operacional faz"]
N1["11.2 Tipos de SO nos serviços críticos"]
N2["11.3 Hardening"]
N3["11.4 Patches na operação"]
N4["11.6 Atividade prática"]
N5["Síntese do capítulo"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5
N5 --> EX["Exemplo resolvido"]
EX --> Q["Exercício EX021"]
Desenho lógico
flowchart LR
N0["11.1 O que o sistema operacional faz"]
N1["11.2 Tipos de SO nos serviços críticos"]
N2["11.3 Hardening"]
N3["11.4 Patches na operação"]
N4["11.6 Atividade prática"]
N5["Síntese do capítulo"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> Q["EX021"]
[11.1 O que o sistema operacional faz]
|
v
[11.2 Tipos de SO nos serviços críticos]
|
v
[11.3 Hardening]
|
v
[11.4 Patches na operação]
|
v
[11.6 Atividade prática]
|
v
[Síntese do capítulo]
|
v
[Exemplo resolvido] --> [Exercício EX021]
Objetivos de aprendizagem e conexão
Depois deste capítulo, você consegue (1) explicar processos, proteção de memória, permissões de arquivos e privilégio; (2) descrever como um sistema operacional impõe o menor privilégio e onde ele não consegue; (3) comparar sistemas operacionais de uso geral, de tempo real e embarcados nos serviços críticos; e (4) montar uma lista de hardening e uma decisão de patch para um dispositivo que não pode ser reiniciado à vontade. O capítulo se apoia nas camadas do Capítulo 2 e prepara o Capítulo 13 (identidade) e o Capítulo 24 (controles).
11.1 O que o sistema operacional faz
O sistema operacional (SO) reparte uma máquina entre muitos programas e usuários. Um processo é um programa em execução com a sua própria memória; o SO usa a proteção de memória do hardware para que um processo não consiga ler nem sobrescrever a memória de outro. O kernel é o núcleo privilegiado que gerencia o hardware; os programas de usuário pedem serviços a ele por meio de chamadas de sistema. Os arquivos têm permissões — em sistemas do tipo Unix, leitura, escrita e execução para o dono, um grupo e os demais — e o SO as confere a cada acesso. O privilégio é a capacidade de contornar essas verificações: a conta root do Unix, o Administrator do Windows. Os princípios de Saltzer e Schroeder do menor privilégio e da mediação completa — todo acesso conferido, todo programa recebendo só os direitos de que precisa — continuam sendo a base (Saltzer and Schroeder, 1975).
11.2 Tipos de SO nos serviços críticos
Os sistemas de uso geral (Windows, Linux, macOS) rodam servidores, estações de trabalho de operadores e PCs de escritório; são ricos em recursos, recebem patches com frequência e são amplamente atacados. Os sistemas operacionais de tempo real (RTOS) garantem que as tarefas cumpram prazos — um relé de proteção precisa agir em milissegundos — e rodam em controladores, relés e dispositivos médicos; são pequenos e recebem patches com menos frequência. O firmware embarcado em sensores e dispositivos simples pode não ter separação alguma entre programas. A consequência: as proteções de SO mais fortes existem nas máquinas mais fáceis de substituir, e as mais fracas, nas máquinas que duram mais.
11.3 Hardening
O hardening reduz o que um atacante pode usar. Uma lista prática: remover ou desativar serviços e softwares não usados; trocar contas e senhas padrão; rodar os serviços com contas sem privilégio; ativar os logs e enviá-los para fora do host; restringir mídias removíveis; ativar a allowlist de aplicações onde a carga de trabalho for estável (as estações de trabalho de operadores são boas candidatas — rodam os mesmos poucos programas por anos); manter o horário sincronizado para que os logs possam ser correlacionados. Cada item deve ser verificável — um padrão de hardening que não pode ser verificado é um desejo.
11.4 Patches na operação
Na TI de escritório, aplicar patches é rotina. Numa estação de trabalho de operador ou num controlador, um patch pode exigir validação do fornecedor, uma janela de manutenção e um plano de reversão, porque uma atualização que falha pode parar o processo. Uma decisão de patch baseada em risco pergunta: a falha é explorável neste dispositivo tal como está implantado (alcançável? exige acesso local?); ela é sabidamente explorada; o que o dispositivo controla; quais controles compensatórios existem; quando é a próxima janela? O resultado é um destes: aplicar agora (mudança emergencial), aplicar na próxima janela, mitigar e monitorar até a substituição, ou aceitar com um dono nomeado. O guia de TO do NIST discute esses trade-offs (SP 800-82 Rev. 3).
11.5 Exemplo resolvido: a estação de sinalização da CT (sintético)
Este caso é sintético. A estação de trabalho de controle de sinalização da Calder Transit roda um SO de uso geral. Uma atualização mensal corrige uma falha que permite a um usuário local de baixo privilégio tornar-se administrador. A estação não tem acesso à internet nem e-mail, tem a allowlist de aplicações ativada e só três sinaleiros nomeados fazem login nela. O fornecedor valida as atualizações do SO trimestralmente; o próximo pacote validado sai em sete semanas. Decisão: aplicar na próxima janela, porque a exploração exige uma conta local numa máquina rigidamente controlada; enquanto isso, confirmar que a allowlist está sendo imposta e revisar as três contas. Se a falha fosse explorável remotamente por um serviço de rede que a estação expõe, a resposta seria uma mudança emergencial ou a desativação desse serviço.
11.6 Atividade prática
No seu próprio computador, liste os processos em execução e a conta com que cada um roda; encontre um serviço que você não usa e descubra como ele poderia ser desativado (não desative nada sobre o que você tenha dúvida). Escreva uma lista de hardening de cinco itens para uma estação de atendimento de chamadas do CEDC, cada item com a forma de verificá-lo.
Para a estação do CEDC, escreva itens como "os atendentes fazem login com contas individuais sem direitos de administrador; verificação: listar os administradores locais todo mês" ou "armazenamento USB bloqueado; verificação: inserir um pendrive de teste durante a revisão trimestral".
11.7 Erros comuns e limites
- Rodar tudo como administrador "para evitar problemas de permissão".
- Fazer o hardening uma vez e nunca verificar o desvio.
- Aplicar a cadência de patches da TI de escritório à TO sem validação e reversão.
- Supor que um dispositivo sem interface de usuário de SO não tem SO.
A estação de sinalização da CT mostra as alternativas: allowlist e três contas nomeadas em vez de uso de administrador, um pacote trimestral validado pelo fornecedor em vez da cadência mensal do escritório, e uma revisão que confere se a allowlist ainda está sendo imposta. O quarto erro abrange as bombas de infusão do CVH, que rodam um RTOS que precisa de atualizações do fornecedor.
Exercícios — capítulo 11
EX021 — Decisão de patch. Objetivo: aplicar as perguntas baseadas em risco. Entradas: uma falha explorável remotamente na interface web de um controlador do BMS do CVH; a interface é alcançável a partir da rede corporativa; a correção do fornecedor exige reiniciar o controlador por 30 minutos; a ventilação do centro cirúrgico depende do BMS. Etapas: responda às cinco perguntas de decisão de patch baseada em risco deste capítulo e recomende. Evidência esperada: respostas e recomendação com controles provisórios. Rubrica: 3 = restringir imediatamente o acesso à interface, agendar a reinicialização com a manutenção predial e o centro cirúrgico numa janela planejada, monitorar; 2 = desfecho certo, controles provisórios fracos; 1 = "aplicar o patch imediatamente" sem considerar a ventilação; 0 = nada.
EX022 — Hardening verificável. Objetivo: tornar os controles verificáveis. Entradas: três itens vagos: "proteger as contas", "ligar os logs", "travar o USB". Etapas: reescreva cada um como uma afirmação específica e verificável, com a verificação. Evidência esperada: três itens reescritos. Rubrica: 3 = específicos, observáveis, com método de verificação; 2 = específicos, sem verificação; 1 = ainda vagos; 0 = nada.
Síntese do capítulo
O SO impõe separação, permissões e privilégio; o menor privilégio e a mediação completa são as suas ideias orientadoras. Nos serviços críticos, os dispositivos mais duráveis muitas vezes têm as proteções mais fracas, então o hardening precisa ser verificável e os patches precisam ser baseados em risco, agendados e reversíveis.