Permission Misconfigurations in Critical Information Systems: A Sociotechnical Review

1. Introduction

There is a reason why governments keep certain information classified. If the wrong people would get access to certain documents, national security could be at risk, which is also why they are protected so strictly. Servers holding such material sit inside tightly controlled regulatory frameworks and buried at the core of every one of those frameworks is a deceptively simple demand. Each user and each process should possess exactly the permissions its duties require, nothing beyond that [1,2]. This is easy to say, but much harder to actually put off. So what does make this really hard in practice? Because permissions are not a switch you flip once. They are a living, sprawling tangle of file-system access control lists, role assignments, nested group memberships, directory inheritance rules, and application-layer entitlements, all of which must track a security policy that itself mutates whenever staff rotate, projects wrap up, or the org chart gets reshuffled. A single mistake made or even one wrong checkbox, can create an opening between classification levels that should be completely separate.

We've also had real-world proof of what goes wrong. Chelsea Manning, 2010. Edward Snowden, 2013. Both accessed classified materials well beyond anything their actual job functions warranted [3,4]. When investigators eventually looked into both cases, they found not only failures in personnel vetting, but also serious gaps in the technical controls supposed to limit what each user could access. In these cases, no fancy hacking was needed. They were, at bottom, permission problems.

In this paper, we look at incorrect permission configuration as what we call a "sociotechnical vulnerability". It is not purely a technical problem, and it is not purely a human one either. It sits in between, where technical complexity meets failures in organizational processes. The argument we develop across the following sections is that meaningful mitigation demands an integrated response: mandatory access control enforcement layered with continuous monitoring, privileged access management, rigorous change control, and (this part tends to get neglected) a security culture in which getting permissions right is treated as genuinely important, not as paperwork to rush through [5,7].

We organize the paper in the following way: Section 2 sets out the conceptual groundwork, walking through access control models and the regulatory backdrop for classified information. Section 3 dissects the risks that materialize when permissions go awry. Section 4 investigates why misconfigurations keep occurring. Section 5 pivots to prevention and mitigation. Section 6 pulls these threads into a wider discussion, and Section 7 wraps up with conclusions.

This paper frames classified servers as a specific category of critical information systems, where permission misconfigurations may have consequences that extend beyond local data exposure and affect national security, operational resilience and institutional accountability.

2. Conceptual Framework

This section establishes the conceptual foundations required to understand permission management in critical and classified information systems. It reviews the regulatory context, major access control models, and fundamental security principles that underpin the subsequent analysis.

2.1. Classified Information and the Regulatory Landscape

In the United States, Executive Order 13526 carves classified information into three tiers: Top Secret, Secret, and Confidential. What separates them is the anticipated severity of harm from unauthorized disclosure, stretching from plain "damage" at the Confidential end to "exceptionally grave damage" at Top Secret [1]. NATO runs a parallel scheme under its security policy document C-M(2002)49, using four markings: "COSMIC TOP SECRET", "NATO SECRET", "NATO CONFIDENTIAL", and "NATO RESTRICTED" [2]. Even though the terminology and institutional backgrounds are different, both frameworks share one core principle. Access hinges on two gates: holding the right clearance and also demonstrating a concrete need-to-know tied to one's official duties. But what does all of this actually mean for the servers where classified data is stored and processed? Executive Order 13526 spells it out like this: automated information systems handling classified information must block unauthorized persons from getting in and must safeguard the integrity of what is stored [1]. In daily operations for instance, meeting both of those requirements depends almost completely on whether the permissions on files, directories, databases, and network shares are set up correctly. A single botched access control entry can let someone cleared only at Secret stumble into Top Secret material. In classified parlance, that is a spillage event, and even an accidental one can trigger a formal investigation, forensic analysis, and even expensive remediation [6].

2.2. Access Control Models

At its core, access control is about deciding who is allowed to use which resources [7]. The models for making those decisions have been dissected in the academic literature since at least the early 1970s, and they cluster into several families that each handle the problem differently.

With Discretionary Access Control (DAC), the person owns a resource gets to decide who can access it. The owner specifies, usually via access control lists, which users or groups may read, write, or execute. It is easy to understand and works well enough when the stakes are low. However, it carries a fatal flaw for classified environments. A user who owns a file can share it with anyone, and the system itself imposes no ceiling on that discretion [8]. That level of freedom is simply not acceptable when national security information is involved. Mandatory Access Control (MAC) works in a completely different way. Here, every subject (user, process) and every object (file, record) gets a security label, and the operating system enforces access rules based on those labels, rules that no individual user can override. The intellectual backbone here is the Bell-LaPadula model, published in 1973, which codifies two properties: "no read up" (a subject cannot read an object classified above the subject's clearance) and "no write down" (a subject cannot write information to an object at a lower classification) [9]. Real-world implementations include SELinux and trusted operating systems evaluated under Common Criteria [10]. For obvious reasons, classified environments rely heavily on MAC.

Mandatory Access Control (MAC) works in a completely different way. Here, every subject (user, process) and every object (file, record) gets a security label, and the operating system enforces access rules based on those labels, rules that no individual user can override. The intellectual backbone here is the Bell-LaPadula model, published in 1973, which codifies two properties: "no read up" (a subject cannot read an object classified above the subject's clearance) and "no write down" (a subject cannot write information to an object at a lower classification) [9]. Real-world implementations include SELinux and trusted operating systems evaluated under Common Criteria [10]. For obvious reasons, classified environments rely heavily on MAC.

On top of that, Role-Based Access Control (RBAC) adds a middle layer between users and their permissions. Rather than granting permissions user by user, an administrator bundles permissions into roles and then assigns people to whichever roles match their job functions [11]. Sandhu, Coyne, Feinstein, and Youman laid the formal groundwork in 1996 with the RBAC96 model family, adding role hierarchies and constraints such as separation of duties [12]. NIST later standardized the concept (ANSI/INCITS 359-2004) [11]. The advantage is quite clear. If someone changes positions for instance, you just change their role instead of going through hundreds of individual permissions.

2.3. Key Security Principles

There are several key security principles that directly affect on how permissions should be configured. Least privilege, formalized in NIST SP 800-53 as control AC-6, says that users and processes should receive only the bare minimum access rights their authorized tasks demand [7]. Need-to-know goes a step further: even if someone holds the correct clearance, they still should not see specific classified material unless their duties genuinely require it [1]. Combine these together and these two principles create a “double check”. The permissions on any given system must faithfully enforce both gates.

Another important principle that is worth mentioning is separation of duties. The idea is that sensitive operations should be divided among different people, so that no single person carry out the whole process alone. The Clark-Wilson model, dating to 1987, formalizes this by distinguishing the certification of a transaction (confirming it preserves integrity) from its execution, insisting that different people fill each role [14]. When it comes to managing permissions, this means that whoever requests an access change should not also be the one who approves or implements it. There is also the issue of privilege creep, which tends to happen gradually, and it is also easy to overlook. Someone transfers to a new role. New permissions arrive to support the new duties. But the old permissions often stay in place, where either nobody thinks to remove them, or the process for doing so is so cumbersome that it keeps getting postponed [15]. Months and years pass. Over time, the result can be an account with access across multiple compartments or special programs. Each individual permission was justified when it was given, but the total violates least privilege in ways that stay hidden until an incident occurs.

3. Risk Analysis

3.1. Accidental Disclosure and Data Spillage

The most obvious risk when permissions are misconfigured is that someone ends up accessing classified material they should never have seen in the first place. In the classified world, the technical term for this is spillage, which means information ending up on a system or medium not authorized to hold it at that classification tier [6,16].

The problem with spillages is that, unlike a deliberate theft, they can go completely unnoticed for a long time. The user who wanders into an improperly locked-down directory may not even realize those files carry a higher classification. And from the admin side, nothing triggers an alert because the access was authenticated, the credentials checked out, and no failed-login event was ever generated.

3.2. Insider Threat Amplification

But permission misconfigurations do not just lead to accidental exposure. They also give insiders, whether they are acting with bad intentions or just being careless, a much wider capacity to cause harm. The Verizon 2024 Data Breach Investigations Report, built on analysis of more than 30,000 security incidents, found that non-malicious human error played a part in 68 percent of breaches and that privilege misuse had climbed to the second most frequent breach pattern [17]. In healthcare specifically, insiders drove 70 percent of cases [17]. Those numbers come from commercial sectors though. In classified settings, a single breach can affect national security and not just finances or brand reputation, so the consequences per incident are on a completely different level. Both the Manning and Snowden incidents demonstrate this quite clearly. Manning, a junior intelligence analyst deployed to Iraq, could reach diplomatic cables and battlefield reports far beyond any single analyst's operational needs. Result: roughly 250,000 cables and 480,000 field reports released to WikiLeaks [3]. Snowden, a systems administrator at an NSA facility, not only enjoyed broad access by virtue of his role but reportedly coaxed colleagues into sharing their own credentials, multiplying the problem [4]. In both episodes, the sheer volume of material exfiltrated traced directly back to how many files the individual could reach. Better configured permissions would not have stopped all wrongdoing, of course. But the amount of damage would have been way smaller than what actually happened.

3.3. Privilege Escalation and Lateral Movement

When an attacker manages to get an initial access point on a network, the damage they can do depends mainly on how much that access point can reach.

Privilege escalation (obtaining permissions above what the compromised account should hold) and lateral movement (hopping across the network to additional systems) are the two phases that convert a minor intrusion into a catastrophe [18]. Permission misconfigurations make both of these phases much easier for the attacker. An account enrolled in too many groups, or a directory whose children inherit wide-open parent ACLs, can hand an attacker paths to administrative interfaces, domain controllers, or sensitive file shares without any additional exploit being required. For classified networks, this kind of scenario is even more alarming. These networks are architected with hard segmentation between classification levels and between compartments within a level. A permission error that bridges two compartments, even if it originated from careless administrative housekeeping rather than malice, lets a compromised process access a security domain it was never designed to touch. One such error can essentially break down the MAC boundaries the whole security architecture is built on. NIST SP 800-207 treats privilege escalation as evidence that zero-trust boundaries have collapsed, calling for continuous re-evaluation of access to contain the blast radius [13].

3.4. Data Exfiltration Pathways

Data exfiltration also gets a lot simpler when the staging account has access to a wide pool of data. An attacker funneling material through a tightly scoped account must compromise fresh credentials for every new data source. An attacker working through an over-permissioned account can simply browse. Snowden made this painfully concrete: one privileged account was leveraged to access and extract an estimated 1.5 million classified documents, and the NSA subsequently spent years and considerable resources overhauling its access architecture [4]. Of course, data loss prevention tools and network sensors can intercept some exfiltration attempts. But those are really a backup, not the primary defence. The first line is the permission model itself: if an account can only reach what it legitimately needs, the ceiling on what can be stolen through that account is low by design. If that first line fails though, the other controls need to pick up the slack, and in most cases they simply cannot do it completely.

4. Root Causes and Contributing Factors

4.1. Human Error and Cognitive Complexity

Ask a system administrator what causes permission misconfigurations, and nine times out of ten the answer will be human error. Not because administrators are sloppy. Because the task itself is genuinely hard. Configuring access on a modern server means juggling file-system ACLs, group policy objects, role assignments, directory service attributes, and application-specific permission layers, often spanning multiple interconnected systems [5]. The cognitive load is real. Mistakes multiply under time pressure or when the permission model is documented poorly, if it is documented at all.

OWASP's Top 10 has flagged security misconfiguration as one of the most prevalent web application vulnerabilities for years running. Their 2021 analysis found that 90 percent of the applications tested exhibited some form of misconfiguration [19]. Those numbers are from commercial web applications, not classified servers, but they point to a broader truth: people consistently make configuration mistakes regardless of the domain or how sensitive the data might be. There is also an imbalance in how feedback works here that makes things even worse. Grant too much access and nothing visibly breaks, everything hums along. Grant too little and users start complaining within minutes that they cannot do their work. This lopsided dynamic pushes administrators towards giving more access than necessary. When under pressure, an admin will often grant wide access with every intention of restricting it later on. But that restriction almost never actually happens.

4.2. Poor Change Management and Configuration Drift

Permissions do not just stay correct over time without active effort. Each ad hoc tweak, each emergency exception, each undocumented shortcut nudges the actual system state a little further from whatever the policy document says it should be. This phenomenon, configuration drift, compounds over time [20]. After a year of small changes that seemed harmless individually, the permission state of a server can end up looking nothing like what the security policy actually describes. The Center for Internet Security Benchmarks flag this explicitly, identifying drift as one of the primary mechanisms by which a system's security posture degrades after initial hardening [20]. In classified environments the impact of drift is more serious than in regular IT settings. The documented policy is usually the foundation on which the system's security accreditation rests. When the live configuration drifts away from that baseline, the system is effectively operating outside its authorization, whether or not anyone has noticed.

4.3. Legacy Systems and Technical Debt

Many classified networks still run systems designed and accredited under older security standards. Some of these systems offer only blunt permission models: perhaps a binary split between administrator and standard user, nothing in between. Trying to implement least privilege on such a platform is not merely difficult; it may be architecturally impossible without ripping the whole thing out and starting over [5].

Replacement, though, is its own kind of headache. Re-certification requirements for classified systems are demanding, procurement cycles stretch on, and migrating active intelligence or defence workloads carries operational risks that nobody takes lightly. So workarounds gets piled up. Shared service accounts appear because the legacy application cannot handle individual credentials. Restrictive policies get disabled to keep an older component functional. Users end up lumped into broad administrative groups because the system offers no finer-grained option. Each compromise is individually defensible. Together, they produce a permission landscape that flatly contradicts the principles the organization claims to follow.

4.4. Weak Auditing and Monitoring Gaps

When no one bothers to verify that permissions are set correctly, errors simply go undetected. NIST SP 800-137 outlines a framework for Information Security Continuous Monitoring (ISCM) covering ongoing awareness of threats, vulnerabilities, and the real-world effectiveness of security controls [21]. Yet plenty of organizations, even some that handle classified material, focus their monitoring on login events and network traffic while largely ignoring whether the permission state on each server still matches the authorized baseline. The danger here is that permission errors do not produce any obvious warning signals. No failed login attempts. No anomalous traffic patterns. A user reading files they should not have access to looks, from the logs, exactly like a user performing a routine legitimate read. Standard alerting rules miss it entirely. To catch these kinds of issues, organizations need a completely different approach: regularly comparing actual permissions against a known-good baseline, which is something that many organizations have either not implemented or only done in a very superficial way [19].

4.5. Unclear Responsibility and Organizational Culture

In big organizations, it is often unclear who actually has the responsibility to make sure permissions are correct.

The system administrator configures them. The information security officer drafts the policy. The data owner decides who needs access to specific information. The line manager certifies that a subordinate's access is still warranted. If each of these people assumes that someone else is checking, the end result is that no one checks at all. ISO/IEC 27001 Annex A.9 insists that organizations define access control policies and assign clear ownership over access management processes [22]. In practice, that ownership is frequently muddled. The culture of the organization also has an effect. In organizations where security is seen as a drag on getting the mission done, administrators face pressure to grant access quickly and to treat restrictions as bureaucratic annoyances to be sidestepped. That kind of culture creates the exact conditions where permission errors are not only likely to happen but also likely to go unfixed for a long time. On the other hand, organizations that see following least privilege as a professional standard rather than a burden, tend to catch and fix mistakes before they become serious problems.

Taken together, these factors illustrate that permission misconfigurations cannot be explained solely as technical failures. Instead, they emerge from the interaction between technology, organizational processes, governance mechanisms and human decision-making, reinforcing the need for a sociotechnical perspective in critical and classified information systems.

5. Prevention and Mitigation Strategies

5.1. Secure Baselines and Hardened Configuration Management

The best time to get permissions right is before the server even goes live. NIST SP 800-123 recommends documenting the intended security configuration of every server prior to deployment, covering all access control settings, and then treating that document as a living reference baseline throughout the system's operational life [5]. The Center for Internet Security publishes detailed configuration benchmarks for major platforms, split into Level 1 (general environments) and Level 2 (high-security environments). The Level 2 benchmarks are directly applicable to classified systems [20]. Automated configuration management tools can enforce these baselines continuously, spotting deviations and, where policy allows, correcting them without waiting for a human to notice. In classified environments, any such tooling must itself be accredited, and the automation logic must be reviewed to ensure it does not introduce new attack surface. When done right though, automation provides repeatable and auditable configuration management, which by itself already eliminates many of the errors caused by drift.

5.2. Periodic Access Reviews and Recertification

The main way to fight privilege creep is through regular access reviews. NIST SP 800-53 control AC-2 calls for organizations to review accounts for compliance with account management requirements at a defined frequency [7]. In classified settings, doing these reviews at least once per quarter is a reasonable baseline. Each review ought to address both the technical dimension (does the user's actual access match what is documented?) and the business dimension (does the user still have a legitimate need-to-know for every resource they can reach?). Looking only at individual user accounts during reviews is not going to be enough though. A user's effective permissions often result from nested group memberships, inherited ACLs from parent directories, and cross-system entitlements invisible in a simple account listing. Tooling capable of resolving all these layers and presenting the full effective-access picture for each user is not optional if the review is to be anything more than a pro forma exercise [15].

5.3. Privileged Access Management and Multi-Factor Authentication

Privileged Access Management (PAM) wraps a control envelope around accounts with elevated permissions. Session recording, just-in-time elevation, credential vaulting, automated credential rotation: all serve one objective, ensuring that administrative access is temporary and monitored rather than permanent and invisible [23]. Standing privileges, the kind that accumulate through creep, are precisely what PAM targets. NIST SP 1800-18 provides implementation guidance for PAM in sensitive contexts, emphasizing integration with the broader identity and access management infrastructure [23].

Multi-factor authentication (MFA) does not fix misconfigurations on its own, but it raises the cost of exploiting them. If a misconfigured account requires both a credential and a hardware token (the Common Access Card in U.S. defence environments, for instance) before granting entry, then a stolen password by itself is not enough to capitalize on whatever excess permissions that account holds. MFA is a compensating control rather than a root-cause fix, but it meaningfully shrinks the odds that misconfigurations will be exploited by unauthorized parties.

5.4. Logging, Monitoring, and Security Information and Event Management

Logging without analysis is just wasted disk space. NIST SP 800-53 control AU-2 mandates logging of events significant to system security: changes to access control configurations, privilege escalation attempts, access to sensitive resources [7]. A Security Information and Event Management (SIEM) platform aggregates those logs and hunts for patterns, an account touching resources outside its usual scope, a sudden burst of file reads from a normally quiet directory, a new process running under an account that should lack execute permissions [24].

The snag is that SIEM rules must target the right threat model. A SIEM tuned to catch brute-force login attempts will sail right past the quiet, perfectly authenticated access that a permission misconfiguration enables. In classified environments, detection rules need to be calibrated for cross-compartment access, access to resources above the user's clearance level, and anomalous data retrieval volumes that might signal staging for exfiltration. NIST SP 800-137 provides the overarching framework for weaving these monitoring activities into a continuous programme that sustains situational awareness of the system's security posture [21].

5.5. Incident Response for Permission-Related Breaches

Even the best prevention system is not going to catch everything. When an incident related to permissions occurs, the response needs to quickly move through containment, identification of affected systems, and fixing the problem. For a classified spillage, that might entail isolating affected systems, tracking down every storage location and device that touched the spilled material, revoking and re-provisioning compromised accounts, and conducting a formal damage assessment under the relevant classification authority [6]. The cost of this process, measured in time, money, and operational disruption, is substantially heavier than the equivalent in an unclassified environment. Just as important though is what the organization does after the incident is resolved. If the takeaway is merely "patch the ACL and move on," the same kind of incident will recur. If, instead, the root cause feeds back into the configuration management process, the access review schedule, and the training programme, the organization builds genuine resilience. Permission-related incidents are not just failures to correct. They are diagnostic signals revealing where the broader security governance is falling short.

6. Discussion

If we take a step back and look at what has emerged across every section of this analysis, a clear pattern shows up. The technical mechanisms for controlling access to classified information are mature. They have been studied for decades, and in several cases formally verified. MAC, RBAC, ABAC, least privilege, need-to-know, separation of duties: all well-established members of the security canon. And yet the misconfigurations keep happening. The reason is that the gap between having a good model on paper and actually keeping every server correctly configured, day after day, while staff changes, pressure builds, and systems grow more complex, is just enormous. There is a fundamental tension in this area, and there is no easy way to resolve it. Strict enforcement of least privilege slows operations. Access reviews eat administrative hours. Automated configuration management demands investment that competes with a dozen other budget priorities. In regular IT environments, it might be acceptable to trade some permission risk for operational speed. Classified environments do not have that luxury though. Unauthorized disclosure of classified information can damage national security, burn intelligence sources and methods, and trigger legal liability under classification statutes [1]. In a classified context, accepting higher permission risk is not a reasonable trade-off. It is a failure of governance.

As we have argued throughout this paper using a sociotechnical perspective, improvement needs to happen on two fronts at the same time. On the technical side: mandatory access control enforcement, privileged access management, continuous configuration monitoring, and SIEM integration supply the tools to prevent, detect, and respond. On the organizational side: unambiguous ownership of access management, disciplined change control, regular recertification of access rights, and a culture that treats least privilege as a professional obligation. One without the other is simply not going to work. The cases we reviewed demonstrate that technical controls are rendered toothless when organizational processes fail to maintain them, and that organizational willpower cannot substitute for absent technical enforcement.

Zero trust architecture, as laid out in NIST SP 800-207, points toward a promising future direction [13]. By replacing implicit trust with continuous, context-aware evaluation, zero trust limits the damage any single misconfiguration can cause. But calling it a silver bullet would be premature. Deploying zero trust in classified environments introduces its own difficulties: integration with legacy systems, new categories of configuration that must themselves be managed correctly, and the sheer complexity of running dynamic policy evaluation at scale. Regardless of which architectural paradigm an organization adopts, the foundational principles of least privilege, need-to-know, and separation of duties remain non-negotiable.

A few limitations of this analysis deserve mention. The classified nature of the systems we discuss means that detailed technical information about specific incidents and configurations is often unavailable in open literature. We have leaned on publicly reported cases and general-purpose standards rather than data drawn from classified-specific assessments. Our scope has also been restricted to server-level permissions; we have not tackled the related challenges of network-level access control, cross-domain solutions, or the physical security measures that complement logical controls. Future work could fruitfully investigate how permission management practices interact with the broader risk management frameworks, such as the NIST Risk Management Framework applied to national security systems under CNSSI 1253, that govern the accreditation and ongoing monitoring of classified systems [25].

7. Conclusions

This review examined permission misconfigurations in critical and classified information systems through a sociotechnical perspective, highlighting how technical vulnerabilities are frequently reinforced by organizational processes, governance weaknesses and human factors. The literature consistently demonstrates that incorrect permission configurations can contribute to accidental disclosure, insider threat amplification, privilege escalation and large-scale data exfiltration.

The analysis suggests that effective mitigation requires more than the implementation of access control technologies. Organizations must combine technical safeguards, including mandatory access control, privileged access management and continuous monitoring, with robust governance mechanisms, clearly defined responsibilities, periodic access reviews and a security-oriented organizational culture.

The findings are relevant not only for classified servers, but also for critical information systems in which access control failures may affect essential services, sensitive operations and organisational resilience.