Resumo

  • RFC 5209 define avaliação como a coleta de postura para um conjunto de capacidades do endpoint, seguida da comparação com a política. O parecer é delimitado por cobertura, regra e instante.
  • Reavaliar é parte principal do modelo porque a postura e a política mudam. Um firewall pode ser desativado depois do aceite; um patch novo pode tornar a versão anterior insuficiente.
  • O resultado da avaliação, a autorização e o mecanismo que aplica a regra são superfícies distintas. Um verde no broker não comprova que o gateway agiu ou que o endpoint ainda está conforme.

Quando a fotografia virou transmissão ao vivo

Às 9h, um notebook gerenciado responde à avaliação. O Posture Collector do firewall observa proteção ativa; o coletor de atualização informa a versão exigida. Os Posture Validators usam a política 42, aprovam as duas funções e o Posture Broker Server calcula a decisão global de conformidade. Um sistema externo concede acesso normal.

Às 9h17, o usuário desliga o firewall para testar um programa. O coletor detecta a mudança e emite uma notificação, mas o broker cliente está reiniciando. O evento se perde. Às 9h25, o painel ainda está verde. O registro das 9h é autêntico, o protocolo funcionou e a decisão daquele momento fazia sentido.

O erro está no tempo verbal. “Considerado conforme às 9h, com estes atributos e a política 42” foi reduzido a “conforme”. A fotografia passou a ser apresentada como transmissão ao vivo sem que outra observação tivesse ocorrido.

Esse é um cenário construído, não um incidente atribuído a uma organização. O tipo de mudança, porém, está no próprio RFC 5209: um sistema antes conforme pode deixar de sê-lo se alguém desativar uma proteção obrigatória. O parecer antigo não precisa ser apagado; precisa conservar a hora.

A definição contém seus limites

RFC 5209 foi publicado em 2008 como Informational. Ele oferece terminologia, um modelo de referência, casos de uso e requisitos para o desenvolvimento de protocolos NEA. Não descreve uma plataforma universal nem faz de um protocolo a cadeia inteira de conformidade.

Assessment é o processo de coletar postura para um conjunto de capacidades e permitir que validadores apropriados comparem essa postura com a política. Um conjunto não é necessariamente o todo. Postura é configuração ou estado de hardware e software pertinente à política, não uma cópia integral do endpoint. E avaliar envolve a versão da regra adotada localmente.

Os atributos têm funções diferentes. Posture Attribute relata o observado. Request Attribute pede um dado. Result Attribute comunica um julgamento. Remediation Attribute contém instruções para correção. Um pedido não comprova resposta, uma instrução não comprova execução e o julgamento não substitui a observação.

O RFC diz que o Result Attribute normalmente surge no fim da avaliação e indica se o endpoint foi “considerado” conforme. O verbo registra a natureza do resultado: uma conclusão produzida por entradas e política, não uma essência permanente da máquina.

Seis componentes, seis fronteiras de conhecimento

No cliente, o modelo tem Posture Collectors, um Posture Broker Client e Posture Transport Clients. No servidor há Posture Validators, um Posture Broker Server e Posture Transport Servers.

O Collector observa uma função, fornece atributos, recebe resultado ou remediação e pode avisar sobre mudança. O broker cliente registra coletores, distribui mensagens e reúne respostas. O transport client mantém um canal confiável e protegido.

O Validator aplica política a atributos, pede informação adicional, produz resultado e instrução. O broker servidor encaminha mensagens e combina decisões parciais com a política para criar uma decisão global. O transport server sustenta a conversa.

Nenhuma função ganha conhecimento das demais por proximidade. Transporte protegido não prova que todos os coletores obrigatórios existem. O broker pode juntar quatro respostas corretas sem enxergar a quinta função ausente. O Validator pode interpretar com exatidão um atributo que envelhece logo depois.

O recibo operacional deve guardar inventário esperado, componentes registrados, respostas, horários, atributos, Validator e política usados, além do tratamento dado a ausência, erro, exceção e desconhecido.

Silêncio não é postura positiva

RFC 5792, que especifica PA-TNC, admite conjuntos distintos de atributos proprietários. Um tipo não suportado pode gerar erro. Nas condições descritas, um Collector pode enviar todos, alguns ou nenhum dos atributos solicitados. Há campos que registram explicitamente informação desconhecida ou indisponível.

Essa flexibilidade permite interoperabilidade, mas exige uma política de cobertura. Se cinco funções são obrigatórias e apenas quatro têm resposta, existem quatro julgamentos e uma lacuna. A lacuna pode representar tipo não suportado, recusa por privacidade, falha, configuração errada ou ausência da capacidade.

A organização pode negar, colocar em quarentena, limitar a rede, aceitar uma assertion anterior por prazo curto ou aprovar uma exceção. Isso é decisão local legítima. O que ela não deve fazer é reescrever “não observado” como “saudável”.

“Quatro de cinco; exceção aprovada até 10h” permite ação e revisão. compliant=true esconde cobertura, risco aceito e vencimento. Resultado, cobertura e disposição política precisam de campos diferentes.

Reavaliação é o relógio do sistema

RFC 5209 chama reassessment de segundo uso importante após o exame na entrada. Políticas e endpoints mudam. O documento menciona tanto o usuário que desativa o firewall quanto a publicação de um patch que muda o requisito da política.

O impulso pode nascer no cliente, quando um Collector percebe alteração e chama o broker. Pode nascer no servidor, quando um Validator recebe uma atualização externa de política ou ameaça. Uma implantação pode ainda reagir ao tempo, à abertura de uma aplicação crítica ou a uma ação administrativa.

Logo, a saúde dos disparadores faz parte de qualquer alegação de continuidade. O coletor assinou o evento certo? A notificação sobreviveu ao reinício? A reavaliação entrou na fila, começou e terminou? A política nova alcançou os Validators relevantes?

Guardar somente avaliações bem-sucedidas e descartar disparadores falhos cria um histórico enviesado. O verde possui persistência; o fato que deveria encerrá-lo não.

Assertion Attributes podem resumir uma avaliação anterior em uma peça datada e assinada, reutilizável durante certo período. Isso economiza trabalho, mas continua exigindo emissor, vínculo ao endpoint, funções e políticas cobertas, emissão, validade e condições que exigem nova medição. Uma assinatura forte não torna aceitável uma regra que ignora mudança conhecida.

Canal íntegro, observação ainda limitada

O modelo protege diálogo e atributos contra modificação, replay, interceptação e roubo. Impedir que um resultado antigo seja reproduzido como atual é indispensável.

Mesmo assim, mensagem nova não significa visão completa. Um Collector que enxerga uma função entrega evidência de uma função. Autenticar o endpoint não garante que o sensor local seja abrangente. A integridade do transporte não demonstra a saúde do processo que mediu. A criptografia conserva uma afirmação; não acrescenta fatos que ela não contém.

A cadeia pode ser escrita assim:

endpoint e sessão vinculados → coletores esperados → atributos observados → broker entrega → Validators julgam → decisão global → autorização → regra aplicada → mudança monitorada → reavaliação concluída.

Cada seta muda o responsável. A ausência do próximo recibo deve aparecer como desconhecido.

O resultado não abre nem fecha a catraca

RFC 5209 diz que a avaliação pode influenciar uma decisão de acesso enviada a mecanismos de enforcement. Em seguida, deixa esses mecanismos e protocolos fora do escopo. Também não especifica como o resultado é representado para a tecnologia de acesso.

NEA avalia postura. O sistema de autorização interpreta a avaliação. O ponto de enforcement instala e mantém uma regra. Tráfego e aplicação mostram o efeito. Esse desenho impede que um componente afirme a ação de outro.

Um resultado conforme não assegura acesso, pois outra condição de autorização pode falhar. Acesso ativo também não prova que tudo passou: pode haver rede limitada, exceção ou sinal externo. Receber remediação não prova que ela foi realizada; uma nova observação precisa confirmar.

Para declarar enforcement, registre consumidor, entrada, mapeamento de decisão, endpoint e sessão, ponto aplicador, identificador da regra, confirmação de instalação, tempo e efeito. Sem isso, a conclusão termina na fronteira NEA.

Um recibo que sustenta o presente

O registro começa com assessment ID, session ID, vínculo ao endpoint, conexão, disparador e horários. Compara coletores e validadores esperados, registrados e respondentes, incluindo versão e configuração. Preserva pedidos, atributos, instante de observação, tipo não suportado, valor desconhecido, omissão e erro.

Cada resultado parcial aponta Validator, versão da política, entradas, regra e motivo. O global documenta agregação, exceções e tratamento do desconhecido. Uma assertion reutilizada guarda escopo, emissor, validade e cancelamento.

Depois, sistemas externos acrescentam suas provas: decisão de autorização, regra instalada, remediação executada, nova medição. Por fim vêm última mudança de postura, última mudança de política, última reavaliação, disparadores perdidos e idade da evidência.

No cenário, o painel útil diria: “aprovado às 9h; firewall alterado às 9h17; disparador não entregue; conformidade atual desconhecida; regra anterior ainda ativa”. A frase é maior, porém aponta exatamente para a fila e o processo que precisam de reparo.

Respeitar o aprovado exige datá-lo

A leitura estreita não desvaloriza NEA. Coletar postura, encaminhar atributos, avaliar política, combinar decisões e oferecer remediação são funções reais. RFC 5792, RFC 5793, RFC 6876 e RFC 7171 concretizam camadas dessa comunicação.

O risco aparece quando a camada de assurance transforma decisão histórica em identidade permanente. Sem hora, cobertura e política, “conforme” ganha poder simbólico e pode contrariar a máquina que está rodando. O estado atual do firewall parece errado diante do banco, quando é o banco que está antigo.

O código em execução, o inventário atual, a fila de reassessment, a época da política e a confirmação de enforcement devem prevalecer. O passe das 9h permanece válido dentro de sua moldura.

Às 9h25, a resposta rigorosa talvez não seja “reprovado”, mas “não reavaliado após mudança relevante; estado atual desconhecido”. Exibir esse desconhecido é condição para produzir a próxima evidência correta.

Fontes