Privileged access: the insider threat matters more than the outer perimeter
Why controlling privileged accounts is the most underrated security lever for a manager, and how to set up sensible protection.
Most security conversations in companies revolve around external threats: viruses, breaches, phishing. These are real risks. But there is a category of incidents that happens without any perimeter breach at all - and that tends to cost more.
An employee with broad access - a system administrator, a developer with access to the production database, a consultant with rights to modify configuration - can copy data, alter records, or disrupt systems. No breach required. Simply because they have the authorisation.
After the Snowden disclosures in 2013, this scenario stopped being abstract. The question "which of our own people could do something like that" became quite concrete.
Why this is a systemic problem
Privileged access accumulates gradually. A system administrator received elevated rights three years ago for a specific task - the task was completed long ago, the rights remain. A developer asked for direct database access "just for debugging" - six months have passed. A departed employee can sometimes still log in for weeks after leaving, because nobody deactivated the account.
This is not malice. It is ordinary accumulation of technical debt in the domain of access management. But the result is the same: people effectively have more permissions than their work requires, and nobody knows exactly who has what.
The other part of the problem is the absence of a log. What exactly a user with elevated rights was doing - querying data, modifying configuration, copying files - is not recorded in many companies. An incident can be detected, but what actually happened cannot be reconstructed.
Three minimum controls
I am not a proponent of loading companies with security tools that are expensive to maintain. But there are three things without which privileged access remains unmanageable.
An inventory of privileged accounts. Who has administrative access to which systems? This list must exist and be current. Without it, neither risk management nor incident investigation is possible.
Minimum necessary rights. Access should be granted for a specific task and a bounded time period. Revoked when the task is done. This is inconvenient. But it is the only way to hold back the accumulation of excess access.
Logging of privileged actions. What an administrator does inside a system should be recorded. Not just the fact of login, but the actions: which queries were run, which files were opened, which changes were made. Storage is expensive - but this is what allows you to reconstruct an incident.
Who should own this question
In most mid-sized companies, this question belongs to no one in particular. IT manages access as an operational necessity. Security exists somewhere nearby. The audit comes once a year.
The problem is that a privileged access incident is an operational, legal, and reputational risk all at once. That is a director-level concern, not just an IT one.
A reasonable structure: designate a specific person as responsible for privileged access policy, run an audit of the current state, and establish a quarterly review process for access rights. This does not require large expenditure. It requires a decision.
A few questions for self-assessment
- Can you right now name every person with administrative access to your critical systems?
- Are there former employees or contractors among them whose access was not revoked in time?
- If an incident occurred - could you reconstruct what a user with elevated rights was actually doing?
- Who in the company is responsible for keeping the privileged account list current?
If even one of these questions has no clear answer - this is work worth starting before it becomes necessary.