Dac Cyber Security
You set up dac cyber security by letting resource owners assign read and write rules. In this model, the owner of a file or table picks who can use it. Most teams start with this setup because operating systems and databases support it out of the box. Still, resource owners often grant broad group permissions just to get work done fast. Over time, these wide rules leave sensitive data open to too many users and scripts. How dac cyber security works in practice Discretionary access control, or
Cyber Insurance: the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
You set up dac cyber security by letting resource owners assign read and write rules. In this model, the owner of a file or table picks who can use it. Most teams start with this setup because operating systems and databases support it out of the box. Still, resource owners often grant broad group permissions just to get work done fast. Over time, these wide rules leave sensitive data open to too many users and scripts.
How dac cyber security works in practice
Discretionary access control, or DAC, puts the data creator in charge of rule making. Every file, folder, or database table has a clear owner attached to it. That owner manages an access control list tied to the specific object. The list holds user names or group names along with their allowed actions.
When a user tries to open a file, the system checks that list. It compares the user identity against the entries stored on the object. If the user has a read or write flag, the system allows the action. If no match exists, the system blocks the request right away.
The key trait of DAC is that owners can pass rights to others. A user with admin rights on a folder can hand those rights to a coworker. They do not need a central security team to approve the change. This makes sharing fast for small teams, though it creates tracking problems at scale.
What native owner permissions solve and where they fall short
Native DAC rules give teams a simple way to divide resources on shared servers. File systems on Linux and Windows rely on owner, group, and public flags every day. Database engines also let table owners grant select or update rights to specific app roles. This setup stops random users from reading files they have no business touching.
Yet this model creates major blind spots once a team grows past a few people. Because owners can pass permissions around, central admins lose track of who can read what. A developer might grant read rights to a whole team to fix a bug. Months later, nobody remembers to remove that rule after the fix ships.
Cyber Insurance: architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
Worse, native DAC only checks who logs in or opens the resource at the start. Once a user has read rights on a table, every column is open to them by default. The system does not check what individual queries or commands do in flight. A single bad query can pull thousands of emails, phone numbers, or card numbers at once. Native file and table lists also fail to mask national IDs in query results. If malware runs under an owner account, it inherits all of that owner's rights.
How to tighten owner based permission rules
To keep discretionary rules safe, teams must limit who holds full owner rights. Assign resource ownership to service accounts rather than personal user accounts whenever you can. Use group roles for daily work so you do not manage long lists of names. Run regular checks on your servers and databases to spot wide public permissions. Pull back write and admin flags from users who only need to read data. Finally, pair static permission lists with runtime checks that inspect commands and rewrite sensitive fields in results.
Govern statements and responses across databases and APIs
Good config and scoped roles are needed setup. They do not check single queries in flight or mask sensitive fields in returned rows. Across Postgres, MySQL, SQL Server, MongoDB, ClickHouse, Kubernetes APIs, SSH, and internal HTTP endpoints, hoop.dev sits inline in the protocol beside each supported service as an open-source proxy, a sidecar for your database or API. For every query or command an AI agent or engineer runs against production, hoop.dev decides to pass, mask, block, or hold it for human approval.
First, hoop.dev guardrails block banned queries before they run or hold risky ones for review, and hoop.dev data masking rewrites matched sensitive values in responses in memory. Furthermore, hoop.dev holds SOC 2 Type II and is open source on GitHub.
Frequently asked questions
What is the main difference between DAC and MAC?
In DAC, the file owner decides who gets permission to read or change a resource. In Mandatory Access Control, a central admin sets strict system labels that owners cannot change.
Why is discretionary access control risky for large teams?
Owners can hand out permissions to other users without asking a central security team first. This leads to permission sprawl, making it hard to audit who holds rights to sensitive data.
Where do teams use DAC most often today?
Teams use it every day in standard Linux, Unix, and Windows file systems. It also runs inside relational databases where table creators grant read or write rights to others.