Cyber Security Dacs
You set up cyber security dacs by letting data owners assign read and write rules. In discretionary access control, each resource owner picks who can open or change a file. Teams often start with this model on servers and shared drives because setup is fast. Still, broad permissions pile up fast when owners grant full rights to whole groups. One shared role can soon read or change every table and file on the host. How cyber security dacs work in practice Discretionary rules tie permissions st
Cyber Insurance: the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
You set up cyber security dacs by letting data owners assign read and write rules. In discretionary access control, each resource owner picks who can open or change a file. Teams often start with this model on servers and shared drives because setup is fast. Still, broad permissions pile up fast when owners grant full rights to whole groups. One shared role can soon read or change every table and file on the host.
How cyber security dacs work in practice
Discretionary rules tie permissions straight to an account or group list on each object. Every file, folder, or table holds its own list of allowed users and actions. When an engineer tries to open a file, the system checks that local list. If the user name matches an entry with read rights, the system opens the file.
The person who makes a file or table becomes its owner right away. That owner can hand out read, write, or run rights to any other user. They do not need approval from a central security team to share their data. In database setups, an owner can also let other users pass those rights along.
To manage this at scale, admins put users into groups for each job type. Then data owners give folder or table rights to those groups instead of single people. When a new developer joins the team, an admin adds them to the group. The developer gets all the rights that the group holds across every shared host.
Why owner-led rules leave runtime gaps
Native discretionary lists work well for simple file sharing and basic login checks. They give project owners quick control over who can enter a folder or database. The host operating system or database engine blocks anyone who is not on the list. This stops unknown users at the front door before a session can even start.
Yet this model fails once a valid user logs in and runs commands. Because owners can share rights at will, permissions spread across teams over time. Few owners go back to remove old grants after a bug fix finishes. Soon, dozens of accounts hold standing write rights to live data.
Worse, file and table lists only check who starts the session at login time. They cannot inspect what a specific command or query does while it runs. If an engineer has read rights, a native list lets them pull every row. It will not rewrite emails, phone numbers, card numbers, or national IDs in results.
Cyber Insurance: architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
The same problem applies when an admin has write rights to fix a bug. The system cannot tell a safe one-row update apart from a full table drop. Both actions use the same standing write bit on the access control list. Teams also lose clear audit trails when several people share one group login.
How to tighten discretionary rules for live systems
Start by removing permission-sharing rights from regular user accounts on production hosts. Only system admins should have the right to change access lists in live apps. Next, replace broad user groups with narrow roles tied to single tasks. Review these lists every month to drop unused accounts and old team grants.
Even with clean lists, static rules cannot govern live queries or shell commands alone. Teams need controls that check each action in flight and mask sensitive fields. Modern setups pair strict role lists with runtime checks on every query and command.
Check database and API queries on the wire
Identity tools, roles, and network rules decide who opens a session. Setup alone cannot check what each query does or mask sensitive values in a response once a session starts. When workflows touch Postgres, MySQL, SQL Server, MongoDB, ClickHouse, Kubernetes APIs, SSH, or internal HTTP APIs, hoop.dev runs beside those services as an open-source proxy, a sidecar for your Postgres or API. It inspects requests coming in and results going back on the wire.
Your login details and client tools stay as they are while hoop.dev guardrails refuse bad deletes or drops before they run. On responses, hoop.dev data masking rewrites matched sensitive values in memory. Furthermore, hoop.dev holds SOC 2 Type II, is MIT licensed, and writes every query and decision to an audit trail that generates evidence for HIPAA, GDPR, and PCI DSS. See the source on GitHub.
Frequently asked questions
What does DAC stand for in security?
DAC stands for discretionary access control in computer security. It is a model where the owner of a file or table decides who gets permissions.
How is discretionary control different from role-based control?
In a discretionary model, any resource owner can hand out permissions to other users. In a role-based model, central admins assign rights based on job functions instead.
Why is discretionary access risky for production databases?
Owners can pass rights to others without central review, which leads to permission sprawl. Also, static table grants cannot block bad queries or mask card numbers in results.