Security approvals
/security. Needs module.security and the ThreatLocker
connector.
Application approval requests from ThreatLocker, surfaced where the ICT team actually works.
What you can do
Section titled “What you can do”| Action | Notes |
|---|---|
| See pending requests | With their details |
| Approve or deny | Sent back to ThreatLocker |
| Attach to a ticket | An existing submission, or raise a new one |
| See per-device history | Previous approvals and decisions on that machine |
Why approvals belong in a service desk
Section titled “Why approvals belong in a service desk”Because an approval request is a service desk request, and treating it as one fixes the two things that go wrong with allowlisting in a school.
It gets actioned. Requests that live only in a security console get looked at when somebody remembers. In the queue alongside everything else, they get worked.
It gets a reason. Ticket-linking means the record of why an application was approved sits next to who asked and who decided.
Six months later, when somebody asks why a piece of software is allowed on the science department’s machines, there is an answer that is not “somebody clicked approve”.
Working a request
Section titled “Working a request”Open the request, see what is being asked for and on which machine, check the device history for whether this has come up before, and decide.
The device history is the part people underuse. A machine generating a request a week is telling you something about how it is being used.
If ThreatLocker is not connected
Section titled “If ThreatLocker is not connected”The page links you to Connectors to set it up. See the ThreatLocker connector.
Demo mode gives you sample requests to approve, deny and ticket, which is worth running through with the team before real requests start arriving.
Isolation
Section titled “Isolation”The connector also supports isolating a computer, cutting it off the network. That is the right response to a compromised device and the wrong response to almost everything else.
Treat it the way you treat a wipe: few people should hold the permission, and every use is audited.
Permissions
Section titled “Permissions”Covered by the security module. See roles and permissions.
Auditing
Section titled “Auditing”Every approval and denial is written to the audit log, in addition to ThreatLocker’s own record.