Every request is a decision

In NIST’s model a request meets three parts. The policy engine decides whether to grant access to a resource. The policy administrator carries the decision out, by telling the enforcement point to open or close the connection. The policy enforcement point sits in front of the resource and does what it is told. The diagram above is that picture with a real decision behind it.

The engine does not work from the request alone. NIST lists the data sources it consults, from the device-management system and threat intelligence to activity logs, the access policies themselves, the certificate authority, the identity store and the security event log. The hub’s diagram shows all eight; here the three you can change are the authenticator, the device and the context.

Toggle the network between office, home and a public hotspot and watch the decision. Nothing changes, on purpose. One of NIST’s tenets is that network location implies no trust, so the evaluator in this page never reads that field; a check in the repository fails if it ever does.

A decision is not only yes or no. NIST’s discussion of the trust algorithm has the engine grant access, deny it, or grant it with reduced rights, and a contextual engine can ask for more proof when a request looks unusual. The four outcomes here are allow, allow with reduced rights (read but not write), step up (ask for a stronger factor) and deny. Those four names are this site’s labels for NIST’s outcomes.

NIST describes two ways to weigh the inputs. A criteria-based algorithm needs every box ticked. A score-based one adds up weighted inputs and compares the sum with a threshold, so a strong signal can offset a weak one. Flip the switch to see the same request decided both ways. NIST leaves the weights and thresholds to each enterprise, so the ones in this page’s sliders are illustrative.

It also describes a singular engine, which judges each request alone, and a contextual one, which also looks at the subject’s recent history. NIST’s own example is an HR user who normally opens 20 to 30 records a day, where an alert above 100 makes sense. Switch to contextual and drag records today past 100: the same request that a singular engine allows now steps up.

The example rules are adapted from Google’s BeyondCorp paper, recast generically: an issue tracker for full-time engineers on an engineering device, a finance app for the finance group on managed devices, and viewing something needing less than updating it. The four people, the device tiers and every threshold on this page are illustrative.