As a product that adheres to the tenets of Honest Security, Kolide strives to strike the right balance between providing the data and capability IT and Security teams need to secure their endpoints, while respecting the privacy of the people that use those endpoints.

To help strike this balance, Kolide requires all sensitive actions that can be performed by Kolide administrators to be first authorized by the current assigned device owner through a process called Informed Consent.

What Is A Sensitive Action?

Kolide defines sensitive action as any action that, if misused, could violate someone's privacy or cause inadvertent denial, degradation, or destruction of their personal data. At the time of this writing these actions include:

  • Viewing the precise geolocation of a device

  • Receiving a notification when a device connects to the Internet.

  • Remotely erasing a device (only available in our upcoming MDM)

  • Remotely locking a device (only available in our upcoming MDM)

In general, Kolide applies the informed consent process when there is a chance lack of consent could damage the trust between the end-users and the security team.

Kolide applies special meaning to Informed Consent. Specifically, the workflow must contain the following properties:

  • The process is blocking, meaning authorization must be granted before the action can be performed.

  • The notification must plainly explain what the device sensitive action is, which Kolide administer is requesting it, and the consequences of authorizing it.

  • If the sensitive action is ongoing, the consent can be revoked.

Sensitive device actions require informed consent when the assigned device owner is a person. If the device is unassigned or assigned to a group, no informed consent process is required. In these cases, the action is simply allowed and a record of the action will appear in the Kolide Audit Log.

In certain situations, a Kolide administrator may be unable to get informed consent from the assigned device owner (for example, if the user no longer works for the organization). If this is the case, this process can be circumvented on an organization-owned device by simply un-assigning the device (this action will be audited and the original assigned user will be notified when the re-assignment occurs).

However, if the device is marked as user-owned, reassignment is not allowed and thus the consent process cannot be circumvented.

Did this answer your question?