5.2 - Protecting Applications and Data: Managerial Controls and Access Controls
Data Classification and Security
Data States
Data at rest (stored on drives or media) faces threats like physical theft, unauthorized account access, and improper disposal of unwiped drives. Protection includes encrypting drives, physical security like locked cabinets, requiring authentication, and secure disposal through wiping or physical destruction. For example, encrypting a healthcare database's backup tapes means even if they're physically stolen, they can't be read without the decryption key.
Data in transit (moving between devices or networks) faces threats like network eavesdropping, man-in-the-middle attacks, and interception over unsecured wireless. Protection includes encrypting connections with TLS, VPN, or IPsec, securing physical cabling, validating certificates to block MITM attempts, and sticking to trusted networks. For example, HTTPS encrypts a customer's credit card number as it travels from their browser to a website's server, preventing interception along the way.
Data in use (actively being processed) faces threats like unauthorized viewing, privilege escalation, memory scraping, and old-fashioned shoulder surfing. Protection relies on access controls, authentication and authorization, privacy screens, and advanced techniques like secure enclaves. A key limitation here is that data has to be decrypted to actually be used or processed, so security during this state depends heavily on controlling exactly who's allowed access while it's unlocked. For example, hospital access controls ensure that only the treating medical staff, not general administrative staff, can view a patient's record while it's actively open for treatment.
Data Sensitivity Classification
Organizations typically classify data into tiers like public (freely shareable), internal (employees only), confidential (restricted), and highly confidential (strictly controlled), applying progressively stronger protection as sensitivity increases.
Regulated Data Types
Laws and regulations can require certain types of data to be stored, transmitted, and handled according to specific rules. That means the types of data an organization collects, stores, processes, and transmits decide which security controls it has to put in place to stay legal. Three categories come up the most:
PII (Personally Identifiable Information) is any data that allows someone to be identified, including things like a name, signature, phone number, address, biometric data (like fingerprints), Social Security number, birth date, or email. It's governed by regulations like the Privacy Act of 1974 (federal handling of PII), COPPA (the Children's Online Privacy Protection Act of 1998, for children under 13), GDPR (EU residents), and CCPA (California residents), generally requiring consent for collection, rights to access or deletion, breach notification, and reasonable security safeguards.
PHI (Protected Health Information) is any data related to a person's health, treatment, or payment for health care, at any point in time. It covers things like test results, treatment records, hospital and admission records, prescriptions, doctor's notes, insurance claims and other health care payment records, and mental health records, governed by HIPAA (the Health Insurance Portability and Accountability Act of 1996). Requirements include encrypting electronic PHI, minimum-necessary access controls, audit trails, business associate agreements, and breach notification within 60 days, with penalties reaching more than $2 million per violation category per year (the cap started at $1.5 million and goes up with inflation every year).
PCI (Payment Card Information) is the data organizations collect to process payments by card (like credit cards). It covers cardholder name, card (account) number, expiration date, CVV, and billing address, governed by PCI-DSS (the Payment Card Industry Data Security Standard). Requirements include never storing the CVV after authorization, encrypting cardholder data both at rest and in transit, maintaining a secure network with firewalls and no default passwords, restricting access, regular security testing, and quarterly scans by approved vendors, with compliance obligations scaling based on transaction volume.
Sensitive documents are typically labeled clearly (like marking something "Confidential, PII, HIPAA Protected") with matching handling rules covering encryption requirements, transmission restrictions, access limits, and secure disposal after the required retention period.
Managerial Controls
Cryptography Policy
A cryptography policy defines which algorithms, key lengths, and key management practices are actually acceptable. For example, it might approve AES-256 for data at rest while prohibiting outdated algorithms like DES or 3DES, approve TLS 1.3 or 1.2 for data in transit while banning older insecure TLS versions and SSL entirely, and approve SHA-256 or SHA-512 for hashing while banning MD5 and SHA-1 due to known collision vulnerabilities.
Key length requirements typically call for at least 128 bits (256 preferred) for symmetric encryption, at least 2048 bits (4096 for long-term protection) for RSA, and strong password hashing algorithms like bcrypt with plenty of rounds or Argon2. Keys should always be generated with a cryptographically secure random number generator, never reused across different purposes, and never hardcoded into source code or based on predictable patterns. Storage should use hardware security modules for the most valuable keys, encrypted key stores for application keys, logged access, and regular rotation, never stored in plaintext config files, version control, email, or unencrypted USB drives.
Example: a policy might require AES-256-GCM with 90-day HSM-managed key rotation for customer payment data to satisfy PCI-DSS, AES-256-CBC with annual rotation through an encrypted key vault for employee PII, and just AES-128 minimum with OS-level key storage for lower-sensitivity internal documents.
Web Application Security Policy
This policy defines when and how web apps get security tested and how quickly issues get fixed. Assessments are typically required before any production deployment, after major updates, quarterly for anything public-facing, immediately after a security incident, and annually via full penetration testing for critical apps.
Remediation timelines usually scale with severity: critical vulnerabilities like SQL injection or authentication bypass need fixing within about 7 days (with a workaround within 24 hours if a full patch isn't ready), high-severity issues like XSS within 30 days, medium issues within 90 days, and low-severity cosmetic issues can wait until the next major release or around 180 days. Testing typically uses standard tools like dynamic scanners, static code analysis, and dependency checking, following recognized frameworks like the OWASP Top 10, and every assessment gets documented with a test plan, a vulnerability report with severity scores, verification testing after fixes, and an executive summary. For example, a customer-facing portal handling payment data might get quarterly automated scans plus an annual pentest with tight remediation timelines, while a low-risk marketing site might only need an annual automated scan with more relaxed timelines.
Access Control Models
Access control governs which subjects (users or applications) can perform which operations (access, modify, add, remove) on which objects (files or applications).
An access control model is a method for deciding which subjects get what type of access to which objects. The models below each decide it a different way: by job role (RBAC), by conditions like time or location (RuBAC), by the owner's choice (DAC), or by levels an administrator assigns (MAC).
Role-Based Access Control (RBAC) assigns users to roles and defines what each role can access. For example, an accountant role gets read/write on accounting software and read on budget documents but no access at all to HR or IT systems, while a manager role gets access to their own department's files and a read-only summary view of financials but nothing from other departments. If someone gets promoted from accountant to manager, their access automatically shifts along with their new role, which makes RBAC easy to manage and audit since permissions map cleanly to actual job functions.
Rule-Based Access Control (RuBAC) layers conditional rules on top of another model. Examples include denying access to a financial database outside business hours, requiring MFA if a login comes from outside the corporate network, denying access entirely from unregistered devices, or blocking contractors from confidential data regardless of role. Layered on top of RBAC, someone with a role that normally grants database access might still get blocked if they're logging in at 11 PM from home instead of during business hours from the office, even though their role alone would otherwise allow it.
Discretionary Access Control (DAC) lets the actual owner of an object control who can access it. For example, someone creating a document can grant a colleague read and write access, give another colleague read-only, and leave everyone else with no access at all, and they can change these permissions any time they want. Administrators or super users can still override an owner's settings when needed, like for backups, legal holds, or security investigations. DAC is common on personal computers and shared file servers, but its main weakness is that security depends entirely on individual users making good decisions about who they grant access to.
Mandatory Access Control (MAC) uses strict, externally assigned clearance levels that individual users can't change themselves, common in government and military settings. Generally, subjects can read at or below their own clearance level and write at or above it, which is designed specifically to prevent classified information from leaking down to lower clearance levels.
The Bell-LaPadula model is a specific, well-known MAC implementation with two core rules: "no read up" (you can't read anything classified above your own level) and "no write down" (you can't write to anything classified below your own level), summarized as "write up, read down." For example, someone with Secret clearance can read Secret and lower documents but not Top Secret ones, can write to Secret or higher documents, but cannot write down to a Confidential document, since that could leak Secret information into a lower classification tier. This restriction on writing downward exists specifically to prevent classified information from accidentally or deliberately ending up somewhere less protected.
The two rules have official names. The Simple Security Property says subjects may not read objects above their level (no read up). The * (Star) Security Property says subjects may not write to objects below their level (no write down). Together they're summarized as WURD, "write up, read down."
Choosing a model: when a question asks which model fits, look at who should be in control of access.
Model | Who decides access | Good fit when | Example |
RBAC | An administrator, by job role | Many people share the same job functions | Only subjects in the "accountant" role can use the payroll software |
RuBAC | A set of rules (time of day, location, device type), usually layered on another model | Access should also depend on conditions, not just who you are | No one can open a certain database outside local working hours, even people who normally have access |
DAC | Each object's owner (administrators or super users can override) | Flexible sharing, like personal files and shared folders | Bob lets Alice edit his file, lets Frank only view it, and blocks everyone else |
MAC | An external administrator, who assigns levels to subjects and objects | Strict, high-security settings like government and military | Bell-LaPadula: a user with Secret clearance can read Confidential files but can't write to them |
The principle of least privilege means granting only the minimum access someone actually needs for their job and nothing more. A database administrator gets admin rights on database servers only, not on web servers or domain controllers. A help desk technician gets rights to reset passwords and view accounts, but not to delete accounts or change group memberships. An application server gets read-only database access for its queries, not the ability to update, delete, or drop tables. Giving every developer full production admin access "for convenience," for example, means that if just one developer's account gets compromised, the attacker gets full control of the entire production environment, whereas giving developers only read-only production access with admin requiring manager approval, MFA, and logging means the same compromised account only grants an attacker limited, read-only exposure.
Linux File Permissions
Authorization is when an entity is granted permission to have a certain type of access to a resource. Access controls are what put those decisions into practice, controlling which users have what types of access to which data. On a Linux system, the main access control is the set of permissions on every file and directory.
Linux permissions come in three types, always in the same order: read (view a file or list a directory), write (modify a file or add/remove files in a directory), and execute (run a file as a program or enter a directory), notated as
rwx (all three) with a dash standing in for any missing permission.These apply to three entities, also always in the same order: owner (the user who owns the file), group (the group assigned to the file), and others (everyone else). A full permission string like
rwxr-xr-- means the owner has full read/write/execute, the group has read and execute, and everyone else just has read.Running
ls -l shows this breakdown directly, where the very first character indicates file type (a dash for a regular file, "d" for a directory) followed by the nine permission characters for owner, group, and others in order.For example, running
ls -l in a project folder might show this:$ ls -l total 12 -rwxr-x--- 1 maria research 2140 Mar 3 09:15 analyze.sh -rw-r-----+ 1 maria finance 812 Mar 3 09:20 budget.csv drwxr-xr-x 2 maria research 4096 Mar 3 09:10 reports
Reading the first line:
- means a regular file, then rwx for the owner (maria), r-x for the group (research), and --- for everyone else. The d at the start of the last line marks a directory. The + at the end of -rw-r-----+ means extra permissions were set on budget.csv beyond the usual owner, group, and others. To see them, use the getfacl command:$ getfacl budget.csv # file: budget.csv # owner: maria # group: finance user::rw- user:jchen:r-- group::r-- mask::r-- other::---
The line
user:jchen:r-- gives one more user, jchen, read access, even though jchen isn't the owner, isn't in the finance group, and everyone else gets ---. So when you're checking who can reach a sensitive file, a + means ls -l isn't telling the whole story.Changing permissions numerically with
chmod, read is worth 4, write is worth 2, and execute is worth 1, added together for each entity. So 7 means full read/write/execute, 6 means read plus write, 5 means read plus execute, and so on down to 0 for no access at all, with three digits total covering owner, group, and others in that order. For example, chmod 750 project.sh gives the owner full access, the group read and execute, and others nothing at all; chmod 644 document.txt gives the owner read/write and everyone else read-only; chmod 777 gives everyone full access, which is a serious security red flag since it's world-writable; and chmod 000 blocks access entirely, even for the file's own owner (though root can still override it).Every digit from 0 to 7 stands for exactly one combination, so it's worth knowing them all:
Digit | Adds up to | Permissions |
0 | 0 | --- (none) |
1 | 1 | --x |
2 | 2 | -w- |
3 | 2 + 1 | -wx |
4 | 4 | r-- |
5 | 4 + 1 | r-x |
6 | 4 + 2 | rw- |
7 | 4 + 2 + 1 | rwx |
Reading an unusual one:
chmod 543 test gives the owner r-x (5 = 4 + 1), the group r-- (4), and everyone else -wx (3 = 2 + 1), so ls -l would show -r-xr---wx. Nothing forces the owner to have the most access, so always read each digit on its own. To go the other way, turn each set of three characters into a digit: rw-r----- is 4 + 2 = 6, then 4, then 0, so it's chmod 640.Changing permissions symbolically uses
chmod entity±permission filename, where the entity is u (owner), g (group), o (others), or a (all), the operator is + to add, - to remove, or = to set exactly, and the permission is r, w, or x. For example, chmod u+x script.sh adds execute for the owner, chmod g-w report.txt removes write from the group, and chmod ug+rw data.csv adds read and write for both owner and group at once, with combined statements like chmod ug+rx,o-rwx sensitive.sh letting you set multiple changes across multiple entities in a single command.Good practice: avoid 777 (world-writable, a real risk) and 666 (anyone can modify) entirely, use 644 for most regular documents, 755 for most executables that need to run for everyone but only be edited by the owner, 700 for sensitive scripts meant for the owner alone, and 750 for team-shared directories that shouldn't be publicly accessible.
Summary
Protecting data well means thinking about its state (encrypting it at rest, encrypting connections in transit, and tightly controlling access while it's in use), its sensitivity (public through highly confidential, plus regulated categories like PII, PHI, and PCI), and the specific compliance obligations that come with each. Access control models each strike a different balance between security and usability: RBAC is the most common enterprise approach based on job roles, RuBAC adds conditional rules on top of another model, DAC gives flexibility through owner discretion, and MAC/Bell-LaPadula provides the strictest, most rigid protection for high-security government and military contexts. Across all of these, the principle of least privilege, granting only the minimum access truly necessary, is what keeps the potential damage from any single compromise as small as possible, and on Linux systems specifically, that principle gets enforced directly through read/write/execute permissions for owner, group, and others, set either numerically or symbolically with chmod.