2.1 General Terms

ITDR

Identity threat detection and response (ITDR) is a security procedure for identifying, reducing, and responding to potential identity-based threats, such as compromised user accounts, leaked passwords, data breaches, and fraudulent activity. The primary aim of ITDR is to provide continuous visibility and control over identities' privileges and activities, ensuring they align with the principle of least privilege and zero standing access. When a threat is detected, the ITDR solution must provide the functionality to take actionable steps to mitigate damage.

Zero Standing Privilege

Whereas to have “standing privilege” means to always have access to a resource (whether you need it or not), Zero Standing Privilege (ZSP) describes the principal's state of having zero access or entitlement to a resource. If a principal has standing admin or root access to a production system, that principal can perform admin / root operations against that production system at all times. This is fine when that entity is your staff doing their jobs, but is really bad if its a bad actor who has managed to hack their way in. In the wrong hands, a principal with standing privileged access is a serious threat. But if an identity has zero standing access with no access permissions bound to it, it possesses no threat at all.

Least Privileged Access

Least privilege access (LPA) is the concept of giving a user exactly what they need to do their job access permission-wise – nothing more, and nothing less. Why is LPA recommended? With LPA, if an identity is compromised, or if a legitimate user assuming the identity makes a mistake while operating under the identity, the damage that can done with that identity is known and controlled.

JIT

JIT stands for "just in time". We use that term here mostly in the context of switching between a ZSP posture, and a LPA posture. The user has ZSP, but exactly when they need it (i.e., just in time), they can request, and be approved to gain, LPA. In order to JIT switch between ZSP and LPA postures on a resource, the Trustle User must participate in a Request Workflow.