Subject: [sacm] Provenance and the Slanderous Endpoint Problem

From: Clifford Kahn <[email-masked]>
Date: Mon, 26 Jan 2015 23:25:06 +0000

All,
The "lying endpoint problem" is the fact that the average endpoint, if compromised, can and will lie about its own compliance. (See http://www.scmagazine.com/solving-the-lying-endpoint-problem/article/136200/.)

The average endpoint had better not be able to lie about the compliance of *other* endpoints. Otherwise, a compromised endpoint could slander many others, distract the response systems and response teams, and hide a real attack. We could call this the "slanderous endpoint problem". As far as I know, we haven't addressed this. (If we have and I missed it, please help me out.)

How to solve it? We could say something like this:
In receiving an endpoint attribute assertion from an internal collector, a controller MUST authenticate the collector and MUST verify that the endpoint attribute assertion includes AVPs derived from the collector's authenticated credentials. (Derivation TBD.)

If two endpoint attribute assertions differ in authenticated AVPs, consumers SHOULD NOT treat the assertions as referring to the same endpoint.

Authenticated AVPs would need to be marked as such.

That is the core of an approach for internal attribute collectors. Some practical considerations:

*         In the real world, the only credential available is often a credential of the user. Then the user's certificate, username, or whatever (or possibly a hash thereof, for privacy) should constitute the authenticated AVP. One of my computers will be able to slander another of my computers. But my computer will not be able to slander yours. This brings the slander problem into bounds.

*         In case the endpoint has an organizationally assigned identifier that is preferred for SACM purposes, that organizationally assigned identifier can be an attribute of a device certificate. The collector can use the device certificate when authenticating to the controller. The organizationally assigned identifier can be the value of an authenticated AVP.  (Details TBD.)
External attribute collectors also can be involved in slander.

As Dave W points out, an external collector can learn an endpoint's attributes by querying the endpoint, using a management protocol (NETCONF, etc.) Such a collector is functionally very much like an internal collector, and is likely to be common. But the security considerations are different.

Two slander threats associated with such an external collector:

a)      An endpoint commits slander by misleading the collector.

b)      The collector has been compromised, and slanders on its own.
To threat a), we might say that an external collector of that sort SHOULD authenticate an endpoint. If it does so, the endpoint attribute assertions that it publishes about that endpoint MUST include AVPs derived from the endpoint's authenticated credentials.

To threat b), these collectors are less of a threat than internal collectors, because (a) they are fewer and (b) they are likely to be better protected. Administrators should be encouraged to run the host endpoints tightly, for example, disabling JavaScript(r) in web browsers.

Even so, sometimes one of these collectors will be compromised. For SACM or any large security deployment, compromise tolerance is important. It would be very good to limit which endpoints an external attribute collector can slander. This may be too hard. It would also be very good to have traceability, and *that* seems achievable. Traceability could be used in recovery. Assume that a slanderer (case b)) has been identified, by some unspecified method. If chains of custody and bases are stored, then it should be possible to delete every assertion by the slanderer. This could trigger reevaluation of whatever information elements were based on the slanderer's assertions.

Conclusion

Identity requires higher assurance than compliance. If an endpoint has been compromised, the compliance information that it provides typically has zero assurance.  But even then, some identity attributes must have assurance.

These considerations should affect how we model provenance.

Clifford Kahn
Principal Engineeer, Technical Lead