M0922: Restrict File and Directory Permissions
Restrict access by setting directory and file permissions that are not specific to users or privileged accounts.
Analyst context for executives and security teams
Restricting file and directory permissions is a basic but high-value ICS control because many related ATT&CK behaviors depend on reading, changing, deleting, or hiding files. For leaders, this is about limiting who can alter project files, operational documentation, configuration data, and other sensitive artifacts that support safe operations and incident response.
Executive priority
Prioritize this mitigation where ICS repositories, local system files, project files, and operational information are accessible to broad user groups or shared accounts. It supports least-privilege expectations reflected in the supplied IEC 62443 and NIST SP 800-53 AC-6 mappings, and it gives audit and risk owners concrete evidence to ask for: who can read, write, modify, or delete critical files, and how those permissions are reviewed.
Technical view
MITRE lists no platforms, tactics, or detection text for M0922, so validation must be environment-specific. SOC, IR, and engineering teams should identify directories and repositories containing ICS specifications, schematics, diagrams, project files, configuration files, local databases, and service-related data stores, then verify that permissions limit unnecessary read, write, modify, and delete access. Relationship context makes this especially relevant to Data Destruction, Data from Information Repositories, Data from Local System, Theft of Operational Information, Masquerading, Indicator Removal on Host, Project File Infection including Siemens project file formats, and Service Stop.
Likely telemetry
- File and directory permission inventories or access control lists for sensitive ICS assets and repositories
- Logs or audit records showing permission changes, ownership changes, and privileged access to protected directories
- File creation, modification, deletion, overwrite, and rename events for project files, configuration files, diagrams, schematics, and local databases
- Access records for information repositories that may contain ICS layouts, device information, or process documentation
- Service stop or disable events where service data stores or related files may be affected
Detection direction
- Because ATT&CK provides no official detection guidance for this mitigation, treat detection as control validation rather than a signature-based analytic.
- Baseline expected permissions on high-value ICS file locations and alert or review when broad groups gain write, modify, delete, or ownership rights.
- Tune monitoring around relationship-driven behaviors: unexpected deletion or overwrite of files, creation of non-native files, suspicious renaming or masquerading of files, unauthorized changes to project files, and access to operational repositories.
- Account for legitimate engineering work, vendor maintenance, software updates, and approved change windows to reduce false positives.
- Validate whether logs actually capture permission changes and file activity on the systems and repositories that matter; many gaps are caused by unmonitored shared locations or insufficient audit settings.
Mitigation priorities
- Start with an inventory of critical ICS file locations: project files, configuration stores, operational documentation, local databases, and information repositories.
- Apply least privilege so users and privileged accounts only have the access needed for their role, aligning reviews to the supplied IEC 62443 SR/CR 2.1 and NIST AC-6 references.
- Remove unnecessary broad read, write, modify, delete, and ownership permissions, especially on shared repositories and engineering-related file stores.
- Require change approval and periodic review for permission changes on sensitive directories and files.
- Use incident response and compliance testing to confirm that restricted permissions would limit the related ATT&CK behaviors, rather than assuming the setting exists everywhere.
Analyst notes and limits
This is a mitigation object, not a technique. Its value comes from reducing the opportunity for adversaries to access, alter, hide, or destroy files involved in multiple ICS ATT&CK techniques. The relationship set is broad, so local asset criticality should drive which directories and repositories receive the most attention.
The supplied ATT&CK object does not specify platforms, tactics, or official detection guidance. It also does not provide implementation detail for any specific operating system, vendor product, or ICS architecture. Local evidence is required to determine actual permission exposure and monitoring coverage.
Restrict File and Directory Permissions
Restrict access by setting directory and file permissions that are not specific to users or privileged accounts.
How security teams should use this page
Treat this object as behavior context, not an attribution claim. Validate the related groups, software, data sources, and mitigations against official ATT&CK relationships and your own telemetry before making control-coverage decisions.
Techniques used
This mirrors the MITRE pattern of making group, software, campaign, and technique relationships scannable. Relationship notes come from mirrored ATT&CK relationship text when available.
| Domain | ID | Name | Relationship / procedure |
|---|---|---|---|
| ICS | T0809 | Data Destruction | Protect files stored locally with proper permissions to limit opportunities for adversaries to impact data storage. CitationNational Institute of Standards and Technology April 2013 |
| ICS | T0882 | Theft of Operational Information | Protect files stored locally with proper permissions to limit opportunities for adversaries to interact and collect information from databases. CitationKeith Stouffer May 2015 CitationNational Institute of Standards and Technology April 2013 |
| ICS | T0873 | Project File Infection | Ensure permissions restrict project file access to only engineer and technician user groups and accounts. |
| ICS | T0881 | Service Stop | Ensure proper process and file permissions are in place to inhibit adversaries from disabling or interfering with critical services. |
| ICS | T0811 | Data from Information Repositories | Protect files with proper permissions to limit opportunities for adversaries to interact and collect information from databases. CitationKeith Stouffer May 2015 CitationNational Institute of Standards and Technology April 2013 |
| ICS | T0872 | Indicator Removal on Host | Protect files stored locally with proper permissions to limit opportunities for adversaries to remove indicators of their activity on the system. CitationKeith Stouffer May 2015 CitationNational Institute of Standards and Technology April 2013 |
| ICS | T0893 | Data from Local System | Protect files stored locally with proper permissions to limit opportunities for adversaries to interact and collect information from the local system. CitationKeith Stouffer May 2015 CitationNational Institute of Standards and Technology April 2013 |
| ICS | T0849 | Masquerading | Use file system access controls to protect system and application folders. |
| ICS | T0873.001 | Siemens Project File Format Sub-technique | Ensure permissions restrict project file access to only engineer and technician user groups and accounts. |
All related ATT&CK context
Object version and sync metadata
The fields below describe the current mirrored snapshot. When Glexia retains multiple ATT&CK source imports, you can open the table to compare the same object across releases (hashes and MITRE timestamps). For MITRE’s own release notes and roadmap, see ATT&CK resources — Updates .
Imported snapshots across ATT&CK releases (1)
| Release | Bundle imported | Object version | Modified | Status | Raw hash |
|---|---|---|---|---|---|
| 19.1 | 1.1 | Current bundle | 6979126884f5… |
Mirrored ATT&CK source object
The raw object is retained through the mirrored ATT&CK source bundle and object hash. The raw endpoint returns the exact object from the mirrored bundle when available.
External references and citations
MITRE external references are preserved separately from Glexia analysis so citations remain traceable to their original source records.
-
[1]
mitre-attack M0922Open source URL
Source: MITRE ATT&CK®. © 2026 The MITRE Corporation. This work is reproduced and distributed with the permission of The MITRE Corporation. MITRE ATT&CK and ATT&CK are registered trademarks of The MITRE Corporation. Glexia is not affiliated with or endorsed by MITRE.