Zum Hauptinhalt springen
Elementary Threat · BSI IT-Grundschutz

G 0.32 — Abuse of Permissions

Updated on 4 min Reviewed by: Cenedril Editorial
A.5.3A.5.9A.5.15A.5.16A.5.17A.5.18A.5.23A.5.24A.5.25A.5.26A.5.27A.5.29A.5.34A.6.2A.6.4A.6.5A.6.6A.6.7A.6.8A.7.13A.8.1A.8.2A.8.3A.8.4A.8.5A.8.7A.8.15A.8.16A.8.18A.8.19A.8.20A.8.21A.8.22A.8.26A.8.27A.8.28A.8.29A.8.31 BSI IT-GrundschutzISO 27001ISO 27002

An HR employee has read access to the salary data of all staff — technically necessary for her role in payroll. One day she specifically searches through the salary data of executive management and of the new colleague she is having a conflict with. The access is technically permitted but out of purpose — a classic case of permission abuse.

Abuse of permissions (G 0.32) belongs to the insider threats that are especially hard to detect. The acting person has valid credentials, moves within the technically permitted limits and leaves log entries that appear unremarkable at first glance.

What’s behind it?

People are granted permissions to perform specific tasks. Abuse occurs when these options are deliberately used outside their intended scope — whether to obtain personal advantages, satisfy curiosity or cause harm to an organisation or person.

Enabling factors

  • Historically grown rights (privilege creep) — In department changes, new rights are granted but old ones are not revoked. After several changes, a person has a multiple of the actually needed permissions.
  • Lack of fine granularity — The coarser the authorisation model, the greater the scope for abuse. If “read access to all HR data” is granted instead of “read access to payroll data of the own organisational unit”, an unnecessary attack surface arises.
  • Weak logging — When accesses are not logged, or not logged in an analysable way, there is neither deterrence nor the possibility to investigate.
  • Lack of segregation of duties — When the same person can grant, use and control permissions, there is no checking authority.

Impact

The damage depends directly on the reach of the abused permissions. A clerk who views customer data without authorisation causes a limited confidentiality breach. An administrator who uses their root rights for data theft or sabotage can cause existential damage. In both cases, the organisation’s trust in its own access control is shaken.

Practical examples

IT administrator copies customer database. An administrator with full access to production databases regularly creates complete database exports — officially for backup purposes. In reality, he stores copies of the customer database on a private medium. The abuse is only discovered when he leaves the company and customer lists appear at a competitor.

Former project lead retains access rights. A project lead transfers to another department. His project rights — including access to confidential financial planning — are not revoked. Months later he accesses project documents irrelevant to his new role and shares information about upcoming budget cuts with colleagues on the project team.

Access rights in a shared application. A specialist application stores access rights in a system area that other users can also access. A technically skilled employee discovers this and changes his own permissions to access data actually reserved for executive management.

Relevant controls

The following ISO 27001 controls mitigate this threat. (You’ll find the complete list of 38 mapped controls below in the section ‘ISO 27001 Controls Covering This Threat’.)

Prevention:

Detection:

Response:

BSI IT-Grundschutz

G 0.32 is linked by the BSI IT-Grundschutz catalogue to the following modules:

  • ORP.4 (Identity and access management) — Requirements for fine-grained authorisation models and regular review.
  • DER.2.3 (Remediation of far-reaching security incidents) — Procedures for handling insider attacks.
  • ORP.2 (Personnel) — Personnel measures in case of abuse, including employment-law consequences.
  • OPS.1.1.5 (Logging) — Requirements for the traceability of accesses.

Sources

ISO 27001 Controls Covering This Threat

A.5.3 Segregation of duties A.5.9 Inventory of information and other associated assets A.5.15 Access control A.5.16 Identity management A.5.17 Authentication information A.5.18 Access rights A.5.23 Information security for use of cloud services A.5.24 Information security incident management planning and preparation A.5.25 Assessment and decision on information security events A.5.26 Response to information security incidents A.5.27 Learning from information security incidents A.5.29 Information security during disruption A.5.34 Privacy and protection of PII A.6.2 Terms and conditions of employment A.6.4 Disciplinary process A.6.5 Responsibilities after termination or change of employment A.6.6 Confidentiality or non-disclosure agreements A.6.7 Remote working A.6.8 Information security event reporting A.7.13 Equipment maintenance A.8.1 User endpoint devices A.8.2 Privileged access rights A.8.3 Information access restriction A.8.4 Access to source code A.8.5 Secure authentication A.8.7 Protection against malware A.8.15 Logging A.8.16 Monitoring activities A.8.18 Use of privileged utility programs A.8.19 Installation of software on operational systems A.8.20 Networks security A.8.21 Security of network services A.8.22 Segregation of networks A.8.26 Application security requirements A.8.27 Secure system architecture and engineering principles A.8.28 Secure coding A.8.29 Security testing in development and acceptance A.8.31 Separation of development, test and production environments

Frequently asked questions

Why is the abuse of permissions so hard to detect?

The abuse is carried out with legitimate credentials and within the technically permitted limits. The actions appear in logs as normal access. Only an analysis of the context (timing, frequency, data accessed relative to the task) makes the abuse visible. User Behaviour Analytics (UBA) systems help with this.

How do excessive permissions arise in practice?

Often through inherited rights during department changes: an employee is granted rights for the new role without the old ones being revoked (privilege creep). Other causes: group permissions that are too broadly defined, temporary additional rights that are never withdrawn, and default profiles with too many privileges.

What is the least-privilege principle?

Every user and every process receives only the permissions actually required for the specific task -- and no access beyond that. The principle minimises the impact of an abuse and simultaneously reduces the attack surface for external attackers who compromise a user account.