5.2 Protecting Applications and Data: Managerial Controls and Access Controls

TLDR

Protecting applications and data starts with knowing what data you have, what state it is in, and what laws apply, then layering on policies and access controls to limit who can touch it. This topic covers the three states of data, regulated data categories like PII, PHI, and PCI, managerial policies for cryptography and web apps, the main access control models, and how to set file permissions on a Linux system with chmod.

Why This Matters for the AP Cybersecurity Exam

This topic ties together a lot of defensive thinking you will use across the AP Cybersecurity exam. You need to classify data correctly, match it to the right legal or regulatory requirements, and pick an access control model that fits a scenario. The Linux permissions piece is hands-on: you should be able to read a permission string, calculate a numeric chmod value, and write a symbolic chmod command. Expect questions that give you a situation and ask you to choose the best protection, identify the data state, or fix a permissions problem.

Key Takeaways

• Data exists in three states: at rest, in transit, and in use. Data must be unencrypted to be used, so access controls protect data in use.
• Regulated data categories include PII (Privacy Act of 1974, COPPA), PHI (HIPAA), and PCI (PCI-DSS). Know which law or standard maps to which data type.
• Managerial controls are written policies. A cryptography policy sets approved algorithms and key rules; a web application security policy sets testing and remediation rules.
• The main access control models are RBAC (role), RuBAC (rule), DAC (owner decides), and MAC (strict levels set by an admin). Bell-LaPadula is a MAC model summarized as "write up, read down."
• The principle of least privilege means giving each subject only the access it needs and nothing more.
• In Linux, permissions are read (r=4), write (w=2), execute (x=1) for owner, group, and others. Use chmod with numeric or symbolic methods to change them.

Data States and Classification

Not all data is equal. A company's lunch menu does not 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, like files saved on a hard drive, a USB stick, or a cloud server. The two main risks are physical (someone steals or harms the drive) and digital (someone copies the files). Protection usually means locking up the physical hardware and encrypting the files so a thief cannot 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 is the catch: data has to be unencrypted to actually be used. So you cannot 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)](/ap-cybersecurity/key-terms/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)](/ap-cybersecurity/key-terms/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.

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 or standard like HIPAA or PCI-DSS, the organization usually labels it (tags it as "PHI" or "Confidential") and writes policies that match the requirements for storing, sending, and handling it.

Managerial Controls for Applications and Data

Technical tools alone do not keep data safe. Organizations need written policies that tell employees and developers exactly what is 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 is acceptable. A typical cryptography policy includes:

• A list of approved encryption algorithms for specific uses
• Minimum or maximum key lengths
• Cryptographic key-generation requirements and parameters
• Cryptographic key-storage requirements

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
• Timelines for fixing vulnerabilities based on risk level
• How assessments must be carried out, including specific tools or frameworks

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 (access, modify, add, remove) on which objects (files or applications). An access control model is the strategy used to make those decisions. There are four main models 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 are 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 is typically layered on top of another model like RBAC, adding extra conditions.

Example: A rule says no one can access the customer database outside of local working hours. Even if you are 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."

Do not 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. Some subjects are designated as administrators or super users, and they can override the access controls other subjects set.

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.

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 whether an object is above, at, or below the subject's level. Individual users cannot 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 may not read objects that are above their level. (No reading up.)
2. Star Security Property (* Property): A subject may not write to objects below their level. (No writing down.)

The shortcut to remember this is "write up, read down" (WURD). The "no writing down" rule prevents someone with high clearance from accidentally leaking secrets to a lower-level object where unauthorized people could see them.

Principle of Least Privilege

No matter which model you use, follow the principle of least privilege: give each subject exactly the access it needs to do its function and nothing more. An intern does not need admin rights. The marketing team does not 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 an entity gets permission to access a resource, and Linux handles this through a 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 a binary file such as a program

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
2. The file group
3. Other (all other users)

You will see all three sets 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

All three entities get read, write, and execute on 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 works well 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 +(or -) permission filename

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 flexible for quick tweaks. If you wanted to remove write access from others, you would run chmod o-w testfile. No need to recalculate the whole numeric value.

How to Use This on the AP Cybersecurity Exam

MCQ

• When a scenario describes data sitting on a drive, moving across a network, or being processed, identify the state (at rest, in transit, in use) and match it to the right protection. Remember that data in use cannot stay encrypted, so access controls carry the load.
• Match data types to their laws or standards: PII to the Privacy Act of 1974 and COPPA for children under 13, PHI to HIPAA, PCI to PCI-DSS.
• For access control questions, read the scenario for clues. If the file owner sets the permissions, that is DAC. If a role determines access, that is RBAC. If a condition like time of day decides, that is RuBAC. If an external admin assigns strict levels, that is MAC.

Problem Solving

• Practice converting between permission strings and numeric values. For example, rwxr-xr-- is 754: owner 7, group 5, others 4.
• Be ready to build a chmod command both ways. Numeric uses three digits (owner, group, other). Symbolic uses an entity (u, g, o, a), an operator (+ or -), and a permission (r, w, x).
• For Bell-LaPadula, apply "write up, read down." No reading above your level, no writing below it.

Common Trap

• Mixing up RBAC and RuBAC is easy. Tie RBAC to role and RuBAC to rule every time.
• Do not flip the Bell-LaPadula rules. The Simple Security Property is about reading (no reading up); the Star Property is about writing (no writing down).

Common Misconceptions

• "Encryption protects data in every state." Data in use must be unencrypted while it is being processed, so access controls, not encryption, protect it at that moment.
• "PCI-DSS is a law." PCI-DSS is an industry standard, not a federal law, though organizations that ignore it can lose the ability to process card payments.
• "RBAC and RuBAC are the same thing." RBAC assigns access by role; RuBAC allows or denies access based on rules and is usually layered on top of another model.
• "DAC means no one can override the owner." In DAC, administrators or super users can override the permissions an owner sets.
• "In Bell-LaPadula you can read anything above your clearance." It is the opposite. You read down (at or below your level) and write up (at or above your level).
• "A higher chmod number is always more secure." A higher number grants more access, not less. chmod 777 gives everyone full access, which is usually the least secure option.

Related AP Cybersecurity Guides

• 5.1 Application and Data Vulnerabilities and Attacks
• 5.3 Protecting Stored Data with Cryptography
• 5.4 Asymmetric Cryptography
• 5.5 Protecting Applications
• 5.6 Detecting Attacks on Data and Applications