5.2 Protecting Applications and Data: Managerial Controls and Access Controls

Protecting data isn't just about installing fancy software. It's about knowing what kind of data you have, what laws apply to it, who should be able to touch it, and how to enforce those rules at the system level. This topic walks through how organizations classify data, the policies that guide how it's protected, the access control models that decide who gets in, and finally how to actually set file permissions on a Linux machine.

Data States and Classification

Not all data is equal. A company's lunch menu doesn't need the same protection as a customer's social security number. To figure out the right security, you first need to know what state the data is in and what category it falls into.

The Three States of Data

Data exists in one of three states at any moment, and each state has its own security concerns.

Data at rest is data sitting on a storage device. Think files saved on a hard drive, a USB stick, or a cloud server. The two main risks are physical (someone steals or destroys the drive) and digital (someone copies the files). Protection usually means locking up the physical hardware and encrypting the files so a thief can't read them.

Data in transit is data moving between devices, like an email being sent or a webpage loading. If it travels over cables, you protect the cables. Either way, you encrypt the data so anyone who intercepts it just sees scrambled junk.

Data in use is data being actively processed, either by software or by a person reading it on screen. Here's the catch: data has to be unencrypted to actually be used. So you can't rely on encryption alone. Instead, you use access controls to limit who can view or edit it.

Categories of Regulated Data

Some types of data are protected by law, which means organizations face real consequences for handling them carelessly.

Personally identifiable information (PII) is anything that can identify a specific person. Names, signatures, phone numbers, addresses, biometric data like fingerprints, social security numbers, dates of birth, and email addresses all count. The Privacy Act of 1974 protects PII in general. For kids under 13, the Children's Online Privacy Protection Act of 1998 (COPPA) adds extra rules.

Protected health information (PHI) covers anything tied to a person's health, treatment, or healthcare payments. Test results, hospital records, doctor's notes, and insurance payment records all qualify. The Health Insurance Portability and Accountability Act of 1996 (HIPAA) sets the rules here.

Payment card information (PCI) is the data needed to process card payments: cardholder name, account number, expiration date, billing address, and CVV code. The Payment Card Industry Data Security Standard (PCI-DSS) regulates how this is handled. Note that PCI-DSS is an industry standard, not a law, but companies that don't follow it can lose the ability to process card payments.

Why Classification Matters

Organizations sort data by sensitivity and apply stronger security to the more sensitive stuff. A marketing brochure might be public, while customer credit card numbers get encrypted, logged, and access-restricted. When data falls under a law like HIPAA or PCI-DSS, the organization usually labels it (tags it as "PHI" or "Confidential") and writes policies that match the legal requirements for storing, sending, and handling it.

Managerial Controls for Applications and Data

Technical tools alone don't keep data safe. Organizations need written policies that tell employees and developers exactly what's allowed. These are called managerial controls, and two of the most important ones deal with cryptography and web applications.

Cryptography Policy

A cryptography policy spells out the encryption rules for the entire organization. Instead of letting every developer pick their own algorithm, the policy says exactly what's acceptable. A typical cryptography policy includes:

• A list of approved encryption algorithms for specific uses (for example, AES-256 for encrypting files, TLS 1.3 for data in transit)
• Minimum or maximum key lengths (like "RSA keys must be at least 2048 bits")
• Cryptographic key-generation requirements (how keys must be created, what randomness source to use)
• Cryptographic key-storage requirements (where keys are kept and who can access them)

The point is consistency. If one team uses strong encryption and another uses outdated algorithms, the weak link puts everyone at risk.

Web Application Security Policy

A web application security policy lays out how the organization tests and fixes vulnerabilities in its web apps. It usually covers:

• When an application has to undergo a security assessment (for example, before every major release)
• Timelines for fixing vulnerabilities based on risk level (critical bugs might need a fix in 24 hours, low-risk ones in 90 days)
• How assessments must be done, including specific tools (like Burp Suite) or frameworks (like the OWASP Testing Guide)

This policy makes sure security testing actually happens on a predictable schedule instead of being skipped when deadlines get tight.

Access Control Models

Access control is the system that decides which subjects (users or applications) can perform which operations (read, modify, add, delete) on which objects (files or applications). An access control model is just the strategy used to make those decisions. There are four main models you need to know, plus one specific model used by governments.

Role-Based Access Control (RBAC)

In role-based access control (RBAC), every subject gets assigned to a role, and permissions are tied to roles instead of individual people. So if you're hired as an accountant, you automatically get access to whatever accountants need.

Example: A company creates a role called "accountant." The payroll software is an object. RBAC ensures that only people in the accountant role can open the payroll software. When a new accountant joins, they get the role and instantly have the right access. When someone leaves accounting, you remove the role and their access disappears.

Rule-Based Access Control (RuBAC)

Rule-based access control (RuBAC) uses a set of rules to allow or deny access. It's usually layered on top of another model like RBAC, adding extra conditions.

Example: A rule says no one can access the customer database outside of 9 AM to 5 PM local time. Even if you're an authorized accountant trying to log in at 2 AM, the rule denies you. RBAC says "yes, you have the role," but RuBAC overrides that with "not right now."

Don't mix up RBAC and RuBAC. RBAC = role-based. RuBAC = rule-based.

Discretionary Access Control (DAC)

In discretionary access control (DAC), individual users decide who can access the files they own. If you create a document, you choose who can read or edit it. Administrators or super users can override these settings if needed.

Example: Bob creates a file. He gives Alice permission to edit it, gives Frank read-only permission, and blocks everyone else. Bob is in charge because he owns the file. This is how Google Docs sharing works in practice.

Mandatory Access Control (MAC)

Mandatory access control (MAC) is much stricter. Subjects and objects are assigned security levels by an outside administrator, and access follows rigid rules based on those levels. Individual users can't change permissions, even on files they create.

The Bell-LaPadula Model

The Bell-LaPadula model is a specific MAC model used heavily by governments and the military to protect classified information. It has two key properties:

1. Simple Security Property: A subject cannot read an object that is above their level. (No reading up.)
2. Star Security Property (* Property): A subject cannot write to an object that is below their level. (No writing down.)

The shortcut to remember this is "write up, read down" (WURD). You can write to things at or above your level, and read things at or below your level. The "no writing down" rule prevents someone with high clearance from accidentally leaking secrets to a lower-level file where unauthorized people could see them.

Principle of Least Privilege

No matter which model you use, you should always follow the principle of least privilege: give each subject exactly the access they need to do their job and nothing more. An intern doesn't need admin rights. The marketing team doesn't need access to source code. Less access means less damage if an account gets compromised.

Configuring Access Controls in Linux

Linux uses file permissions to enforce access control. Authorization is the moment a user gets permission to access a resource, and Linux handles this through a simple permission system you set on every file.

Reading Linux Permissions

Every file has three types of access that can be granted or denied, always in this order:

1. Read (r): view the file's contents
2. Write (w): make changes to the file
3. Execute (x): run the file as a program (for binaries or scripts)

If a permission is missing, you see a - in its place. So r-x means read and execute, but no write.

Permissions are set for three default entities, always in this order:

1. The file owner (the user who owns it)
2. The file group (a group of users)
3. Other users (everyone else)

You'll see all three sets smushed together with no spaces, like rwxrwxrwx (everyone can do everything) or rwxr-x--- (owner has full access, group can read and execute, others have nothing).

Viewing Permissions

To see permissions, use:

</>Code
ls -l

This lists files with their current permissions for owner, group, and others. If you see a + at the end of the permissions string, it means extra permissions have been set beyond the defaults. To view those, use:

</>Code
getfacl filename

Changing Permissions with chmod (Numeric Method)

The chmod command modifies permissions. The numeric method uses three digits, one for each entity (owner, group, other). Each digit is the sum of the values for the permissions you want:

• 0 = no permissions
• 1 = execute
• 2 = write
• 4 = read

Add them up to get combinations:

• 3 = write + execute (2+1)
• 5 = read + execute (4+1)
• 6 = read + write (4+2)
• 7 = read + write + execute (4+2+1)

Syntax: chmod ### filename

Examples:

</>Code
chmod 750 test

Owner gets read, write, execute (7). Group gets read and execute (5). Others get nothing (0).

</>Code
chmod 543 test

Owner gets read and execute (5). Group gets read only (4). Others get write and execute (3).

</>Code
chmod 777 test

Everyone gets full access to the file test. (Generally a bad idea in real systems.)

Changing Permissions with chmod (Symbolic Method)

The symbolic method uses letters instead of numbers. It's better when you want to add or remove a single permission without rewriting the whole set.

Entities:

• u = user owner
• g = group
• o = others
• a = all

Operators:

• + = add the permission
• - = remove the permission

Permissions:

• r = read
• w = write
• x = execute

Syntax: chmod entity+permission filename (or - to remove)

Example: to add read and execute permissions for both the user owner and the group on a file called testfile:

</>Code
chmod ug+rx testfile

You can combine entities and permissions in one command, which makes the symbolic method really flexible for quick tweaks. If you wanted to remove write access from others, you'd just run chmod o-w testfile. No need to recalculate the whole numeric value.