APRENDER. PRATICAR. EVOLUIR.Traduzir necessidades numa matriz de fluxos
A rede administrativa precisa de consultar relatórios, mas não de contactar diretamente todos os controladores. Descreve cada comunicação necessária com origem, destino, direção, protocolo, porta, finalidade, responsável e janela. Agrupa ativos por função, confiança e consequências antes de escolher fronteiras. Uma VLAN dá separação lógica; a política aplicada entre zonas determina que tráfego atravessa. Um serviço intermédio pode reduzir acessos diretos, mas continua a precisar de endurecimento, gestão e observação. No laboratório, quatro contentores partilham uma bridge interna. O filtro atua no input do servidor sintético; não implementa uma rede industrial encaminhada, uma DMZ completa ou um modelo Purdue. Esta limitação permite estudar uma decisão concreta de origem e porta sem atribuir ao ensaio uma arquitetura que não existe.
Observar recusas e serviço disponível
O serviço sintético escuta em três portas TCP. Antes da política, a máquina office alcança telemetria e operator alcança manutenção. Depois, só operator pode iniciar ligações de telemetria na porta 15020. A ligação de office falha, mas uma verificação local confirma que o serviço adicional continua a escutar. Assim, o diagnóstico não depende apenas de um timeout isolado: compara estado do serviço, origem autorizada, origem recusada e contadores do filtro. Estes contadores contam pacotes, não utilizadores nem tentativas únicas. Retransmissões podem aumentar o total. Os registos da aplicação mostram pedidos que chegaram ao serviço; não registam automaticamente todos os pacotes descartados. Preserva hora, configuração e contexto de teste para distinguir uma recusa intencional de uma falha de rota ou de aplicação.
Delimitar o acesso de manutenção
A janela abre uma permissão para a origem vendor e a porta 15021. O mesmo fornecedor continua sem acesso à telemetria e à terceira porta; office continua sem acesso à manutenção. Na operação real, uma regra por endereço não identifica a pessoa nem comprova autorização contratual. Complementa a arquitetura com identidades individuais, autenticação adequada, aprovação limitada à tarefa, supervisão e possibilidade de retirar acesso. Define início, fim, destino e ações permitidas, considerando compatibilidade do equipamento. O ensaio não implementa MFA, bastion ou contas de fornecedor. O seu contributo é verificar que a combinação de origem e porta não se transforma inadvertidamente numa permissão mais ampla. Uma janela agendada também precisa de evidência de fecho, incluindo o tratamento de sessões que começaram antes do fim.
Separar novas ligações de tráfego estabelecido
A fixture mantém uma sessão vendor a trocar mensagens. Retirar a regra temporária impede novas ligações, mas a sessão continua a comunicar pela regra anterior que aceita estado established. O fim da permissão para iniciar não é, neste conjunto de regras, o fim de todo o tráfego existente. Em seguida, o exercício insere uma recusa específica antes dessa aceitação de estado. O cliente deixa de receber respostas e termina por timeout; não se afirma que foi enviado um TCP reset nem que a entrada conntrack desapareceu. Em produção, escolhe o mecanismo de retirada considerando sessões, aplicação, identidade e efeitos operacionais. A ordem das regras faz parte da evidência. Testa também o fluxo obrigatório depois da contenção, porque bloquear tudo poderia satisfazer a recusa sem preservar o serviço necessário.
Entregar evidência com limites de interpretação
As duas execuções guardam versões, hashes dos programas, regras, contadores, resultados e remoção dos recursos temporários. Um resultado local é reproduzível dentro deste âmbito; não comprova latência, capacidade, redundância ou segurança física de uma instalação. TCP exige tráfego de resposta: este filtro não é um díodo de dados unidirecional. O estado established também não demonstra que o utilizador continua autorizado. Para o handover, associa cada requisito a um ensaio positivo e negativo, responsável, resultado e lacuna. Acrescenta testes de recuperação, perda de dependências e acesso de emergência no ambiente adequado. A decisão de aceitar risco residual pertence à autoridade definida, com participação do operador. Usa os resultados para preparar melhores perguntas de aceitação, sem apresentar dr.pt como fornecedor oficial da certificação ou o laboratório como aprovação de produção.
docker build -t dr-securityx-ot:20261008 content/labs/securityx-ot-boundaries
python3 content/labs/securityx-ot-boundaries/run.py --output /tmp/securityx-ot.json
# Disposable internal Docker network only; no physical OT devices.Retirar a permissão vendor bloqueia novas sessões; uma recusa colocada antes de established interrompe a troca de dados da sessão existente.
Armadilhas comuns
Porta aberta como identidade autorizada; contador de pacotes como número de pessoas; regra removida como sessão terminada; TCP como díodo.
Tópicos relacionados: Inventário e dependências OT · Segmentação e acesso remoto · Segurança física e operação
A fronteira só está demonstrada para os fluxos, estados e condições efetivamente ensaiados.
Referência: Guide to Operational Technology Security, SP 800-82 Rev. 3 · CAS-005 / SecurityX V5; objectives 3.0; launched 2024-12-17