Zusammenfassung

  • RFC 5209 versteht Assessment als Erfassung der Haltung bestimmter Endgerätefähigkeiten und deren Bewertung gegen eine Richtlinie. Aussagekraft entsteht aus Umfang, Richtlinienstand und Zeit.
  • Reassessment gehört zum Kernmodell, weil sich Endgerät und Richtlinie nach einer positiven Entscheidung ändern können. Das Abschalten einer vorgeschriebenen Host-Firewall ist das Beispiel des RFC.
  • Bewertung, Autorisierung und Enforcement haben verschiedene Eigentümer. Ein globales Positivergebnis beweist weder die Installation einer Zugriffsregel noch die heutige Konformität.

Eine korrekte Entscheidung überlebt ihre Gegenwart

Um 9 Uhr antwortet ein verwaltetes Notebook auf eine Haltungsbewertung. Der Firewall-Collector meldet aktiven Schutz, der Update-Collector den vorgeschriebenen Patchstand. Zwei Validatoren wenden Richtlinie 42 an. Der Server-Broker bildet daraus „konform“, ein benachbartes Zugangssystem gestattet normalen Verkehr.

Um 9:17 Uhr schaltet der Nutzer für einen Test die Firewall ab. Der Collector erkennt die Änderung, doch der Client-Broker startet gerade neu. Die Meldung geht verloren. Um 9:25 Uhr bleibt das Assurance-Dashboard grün. Der Datensatz von 9 Uhr ist echt, die Sitzung war fehlerfrei und das damalige Urteil richtig.

Falsch ist allein der unmarkierte Sprung in die Gegenwart. Aus „um 9 Uhr mit diesen Beobachtungen unter Richtlinie 42 als konform bewertet“ wurde „ist konform“. Ein historischer Befund erhielt eine unbelegte Dauer.

Das Beispiel ist konstruiert und keinem realen Produkt zugeordnet. Seine Veränderung nennt RFC 5209 selbst: Ein zunächst konformes System kann nicht mehr konform sein, wenn ein Nutzer eine erforderliche Host-Firewall deaktiviert. Reassessment ist daher kein Eingeständnis eines schwachen Modells, sondern dessen Zeitachse.

Die Begrenzung steckt schon im Begriff

RFC 5209 erschien 2008 als Informational. Er beschreibt Problem, Terminologie, Referenzmodell, Anwendungsfälle und Anforderungen für NEA-Protokolle. Er ist kein vollständiges Produkt und kein einzelnes Drahtprotokoll für jede Stufe der Compliance.

Assessment bedeutet, Haltung für eine Menge von Fähigkeiten zu sammeln, damit zuständige Validatoren sie gegen eine Richtlinie bewerten. Eine Menge muss nicht alle Fähigkeiten enthalten. Haltung ist der für die Richtlinie relevante Hardware- oder Softwarezustand, nicht die Gesamtrealität des Geräts. Bewertung bringt eine lokale Regel samt Version und Geltungszeit ein.

Auch Attribute haben verschiedene Verben. Posture Attributes beschreiben Beobachtungen. Request Attributes fordern Angaben an. Result Attributes übermitteln ein Urteil. Remediation Attributes enthalten Korrekturanweisungen. Eine Anfrage ist kein Erhalt, eine Anweisung keine Ausführung und ein Ergebnis nicht die Beobachtung selbst.

Nach RFC 5209 zeigt das Result Attribute normalerweise am Ende, ob das Endgerät als konform „angesehen“ wurde. Diese Formulierung ist präzise. Das Urteil entsteht aus Eingaben und Richtlinie; es ist keine unveränderliche Geräteeigenschaft.

Getrennte Rollen verhindern geliehene Gewissheit

Der NEA Client besteht aus Posture Collectors, einem Posture Broker Client und Posture Transport Clients. Auf der Serverseite stehen Posture Validators, ein Posture Broker Server und Posture Transport Servers.

Der Collector beobachtet eine Funktion, liefert Attribute und kann Änderungen melden. Der Client-Broker registriert Collectors, verteilt Anforderungen und bündelt Antworten. Der Transport Client stellt den geschützten Kanal bereit.

Der Validator wertet Attribute aus, fordert Ergänzungen an und erzeugt Ergebnis und gegebenenfalls Remediation. Der Server-Broker führt Validatoren und berechnet aus Teilergebnissen und Richtlinie die globale Entscheidung. Der Transport Server trägt den Dialog.

Ein geschützter Kanal beweist nicht, dass alle nötigen Collectors vorhanden waren. Ein Broker kann vier Antworten fehlerfrei bündeln und über die fünfte Fähigkeit nichts wissen. Ein Validator kann eine Regel korrekt anwenden, ohne einen späteren Zustandswechsel zu sehen.

Darum muss der Beleg Soll-Inventar, registrierte und antwortende Komponenten, Beobachtungszeiten, Attribute, Validator, Richtlinienversion und die Behandlung von Lücken, Fehlern und Ausnahmen enthalten.

Nicht beobachtet heißt nicht gesund

RFC 5792 konkretisiert PA-TNC und erlaubt unterschiedliche Mengen herstellerspezifischer Attributtypen. Nicht unterstützte Typen können einen Fehler auslösen; unter den beschriebenen Bedingungen kann ein Collector alle, einige oder keine angeforderten Attribute liefern. Einige Felder kennen ausdrücklich unbekannte oder nicht verfügbare Werte.

Diese Offenheit ist für Interoperabilität nötig. Sie macht Coverage jedoch zum Bestandteil des Urteils. Sind fünf Fähigkeiten vorgeschrieben und antworten vier Collectors, liegen vier Befunde und eine Lücke vor. Die Lücke kann Datenschutz, fehlende Unterstützung, Störung, Konfiguration oder fehlende Funktion bedeuten.

Lokale Richtlinie darf ablehnen, isolieren, beschränken, eine frühere Assertion befristet akzeptieren oder eine verantwortete Ausnahme zulassen. Doch eine akzeptierte Lücke ist keine positive Beobachtung. „Vier von fünf; Ausnahme bis 10 Uhr“ ist ehrlich, compliant=true nicht ausreichend.

Ergebnis, Evidenzabdeckung und politische Behandlung gehören in getrennte Felder. Wer sie zusammenzieht, gewinnt eine einfache Anzeige und verliert die Grundlage der nächsten Entscheidung.

Neubewertung hält die Aussage zeitlich zusammen

RFC 5209 nennt Reassessment nach der Zugangsbewertung als zweiten wichtigen Anwendungsfall. Endgerätehaltung und Richtlinien ändern sich. Neben der abgeschalteten Firewall nennt er einen neu veröffentlichten Patch, den eine aktualisierte Richtlinie nun fordert.

Der Impuls kann vom Client kommen, wenn ein Collector die Änderung meldet. Er kann vom Server kommen, wenn ein Validator außerhalb des Protokolls eine Richtlinien- oder Bedrohungsänderung erfährt. Zeitgeber, Zugriff auf eine kritische Anwendung oder Administration können weitere Auslöser sein.

Damit gehört der Trigger-Pfad zur Aussage fortlaufender Konformität. War der Collector auf das Ereignis abonniert? Überlebte die Nachricht einen Neustart? Wurde Reassessment eingereiht, begonnen und abgeschlossen? Erreichte die neue Richtlinie alle relevanten Validatoren?

Wer positive Assessments dauerhaft speichert und fehlgeschlagene Trigger verwirft, baut ein grünes Gedächtnis: Das Bestehen bleibt, sein Ablaufgrund verschwindet.

Assertion Attributes dürfen ein früheres Assessment datiert und signiert für eine Zeit wiederverwendbar machen. Die Optimierung braucht Herausgeber, Endgerätebindung, abgedeckte Fähigkeiten und Richtlinien, Ausgabe, Ablauf und Ereignisse, die eine neue Messung erzwingen. Eine starke Signatur heilt keine Annahmeregel, die bekannte Änderungen ignoriert.

Integrität vergrößert den Beobachtungsumfang nicht

NEA schützt Dialog und Attribute und betrachtet Manipulation, Replay und Diebstahl. Ein altes Positivergebnis darf nicht als neu wiedergegeben werden.

Doch auch eine frische Nachricht bleibt so schmal wie der Sensor. Ein Collector für eine Funktion belegt eine Funktion. Authentisierung des Endgeräts macht dessen Sensorik nicht vollständig. Transportintegrität beweist nicht die Gesundheit des lokalen Messprozesses. Kryptografie bewahrt eine Aussage; sie fügt ihr keinen unbeobachteten Satz hinzu.

Die Evidenzfolge lautet:

Endgerät und Sitzung gebunden → erwartete Collectors → Attribute beobachtet → Broker liefert → Validatoren urteilen → globale Entscheidung → Autorisierung → Regel durchgesetzt → Änderung überwacht → Reassessment beendet.

Jeder Pfeil wechselt die Kontrollfläche. Fehlt der nächste Beleg, bleibt der nächste Zustand unbekannt.

Das Assessment bedient nicht selbst das Tor

RFC 5209 sagt, ein Ergebnis könne eine Zugangsentscheidung beeinflussen, die an Enforcement-Mechanismen provisioniert wird. Gleichzeitig liegen Mechanismen und Protokolle des Enforcement außerhalb des Umfangs. Auch die Darstellung gegenüber Zugangstechnologien wird nicht festgelegt.

NEA bewertet. Ein Autorisierungssystem entscheidet. Ein Enforcement-Punkt installiert und hält die Regel. Verkehr und Anwendung zeigen die Wirkung. Diese Trennung ist eine Sicherheitsgrenze, keine Lücke.

Ein positives Ergebnis garantiert daher keinen Zugang; andere Bedingungen können ihn verhindern. Vorhandener Zugang beweist umgekehrt nicht, dass jede Haltung bestand: Beschränkung, Ausnahme oder andere Signale sind möglich. Eine Remediation-Anweisung beweist keine ausgeführte Reparatur.

Für die Behauptung „durchgesetzt“ braucht es Verbraucher, Eingangsurteil, Entscheidungsabbildung, Endgeräte- und Sitzungsbindung, Enforcement-Punkt, Regelkennung, Installationsbestätigung, Zeitpunkt und beobachtete Wirkung. Ohne sie endet die Aussage am NEA-Ergebnis.

Ein Betriebsbeleg für die Gegenwartsform

Der Datensatz beginnt mit Assessment- und Session-ID, Endgerätebindung, Netzanschluss, Trigger und Zeiten. Er vergleicht erwartete, registrierte und antwortende Collectors und Validators samt Versionen und Konfigurationshashes. Anforderungen, Attribute, Beobachtungszeit, nicht unterstützte Typen, Unbekanntes, Auslassungen und Fehler bleiben erhalten.

Jedes Teilergebnis nennt Validator, Richtlinienstand, Eingangsdaten, Regel und Begründung. Die globale Entscheidung dokumentiert Aggregation, Ausnahmen und Unbekannt-Behandlung. Wiederverwendete Assertions behalten Umfang, Herausgeber, Gültigkeit und Widerrufsbedingungen.

Erst danach ergänzen andere Systeme mit eigenen Belegen Autorisierung, installierte Regel, ausgeführte Reparatur und neue Messung. Zuletzt gehören jüngste Haltungs- und Richtlinienänderung, letztes Reassessment, ausgefallene Trigger und Evidenzalter dazu.

Im Beispiel würde eine brauchbare Anzeige sagen: „9 Uhr bestanden; Firewall 9:17 geändert; Trigger nicht zugestellt; aktueller Status unbekannt; alte Zugangsregel aktiv.“ Das ist keine hübsche Ampel, aber eine genaue Arbeitsanweisung.

Ein datierter Erfolg bleibt ein Erfolg

Die begrenzte Lesart schwächt NEA nicht. Beobachtung, Austausch, Validierung, Aggregation und Remediation sind reale Leistungen. RFC 5792, RFC 5793, RFC 6876 und RFC 7171 konkretisieren unterschiedliche Schichten.

Schwach wird das System, wenn Assurance ein historisches Urteil in dauerhafte Geräteidentität verwandelt. Ohne Zeit, Coverage und Richtlinienversion erhält „konform“ symbolische Macht und kann laufenden Code überstimmen. Dann wirkt der aktuelle Firewallzustand falsch, obwohl der Datensatz alt ist.

Laufender Code, aktuelles Collector-Inventar, Reassessment-Warteschlange, Richtlinienepoche und Enforcement-Bestätigung müssen Vorrang haben. Das Urteil von 9 Uhr bleibt in seinem Rahmen wahr.

Um 9:25 Uhr lautet die präzise Antwort vielleicht nicht „nicht konform“, sondern „nach relevanter Änderung nicht neu bewertet; aktuell unbekannt“. Wer Unbekannt anzeigen kann, kann die nächste richtige Messung auslösen.

Quellen