Unit Scenarios

Scenario 5A: Protecting Sensitive Data

The Situation

As part of the security team at a pharmaceutical company, the task is protecting proprietary R&D data for a new product on an air-gapped (fully network-isolated) computer, with access limited to the R&D team and select IT staff.

Setting Up Access Control

For the top-level /RandD/ directory, the R&D team gets full read/write/execute access while everyone else gets read and execute only, set with chmod 775 /RandD, resulting in drwxrwxr-x. This allows some general visibility for coordination purposes without granting outsiders any ability to modify anything.

For the /RandD/Research/ subdirectory, the R&D team keeps full access while everyone else gets completely cut off, set with chmod 770 /RandD/Research, resulting in drwxrwx---. This fully isolates ongoing research from anyone outside the R&D group.

For the /RandD/Formula/ subdirectory, holding the most sensitive data of all, the head researcher (as the file's owner) gets full read/write/execute access, the rest of the R&D team (as the group) gets read and execute only (so they can view but not modify), and everyone else gets nothing at all, set with chmod 750 /RandD/Formula, resulting in drwxr-x---. This is the strictest tier, ensuring only one specific person can actually change the formula data.

Implementation

The process starts with checking current permissions using ls -l on each directory, then setting ownership appropriately (assigning the head researcher as owner of the Formula directory specifically, and making sure the R&D team group owns the other directories), then applying the actual chmod commands, and finally verifying with ls -ld on each directory that the permissions came out exactly as intended.

Here's what that looks like on the command line, assuming the R&D team's group is named rnd and the head researcher's account is headres:


$ sudo chgrp rnd /RandD /RandD/Research
$ sudo chown headres:rnd /RandD/Formula
$ sudo chmod 775 /RandD
$ sudo chmod 770 /RandD/Research
$ sudo chmod 750 /RandD/Formula
$ ls -ld /RandD /RandD/Research /RandD/Formula
drwxrwxr-x 4 root    rnd 4096 Mar  3 09:12 /RandD
drwxr-x--- 2 headres rnd 4096 Mar  3 09:15 /RandD/Formula
drwxrwx--- 2 root    rnd 4096 Mar  3 09:14 /RandD/Research

Reading the output: the first d marks each one as a directory, and the nine characters after it match the plan (rwxrwxr-x for 775, rwxrwx--- for 770, and rwxr-x--- for 750). Since others have r-x on /RandD, they can see that Research and Formula exist, but they can't open either one.

Why This Setup Makes Sense

Being air-gapped already removes the risk of network-based attacks entirely, so the remaining risk is really about internal access control. Layering permissions this way, general visibility at the top, full isolation for ongoing research, and the tightest possible control on the actual formula, follows the principle of least privilege at every level, with each directory granting only the minimum access actually needed for that specific group of people.

Scenario 5B: Sending Encrypted Messages

The Situation

As a security engineer at a utility company, the task is setting up a secure communication channel with a remote colleague for a classified project using PGP-style asymmetric encryption.

The Overall Flow

Each engineer generates their own key pair (a public key and a secret private key), then they exchange public keys openly (safe to do, since public keys are meant to be shared). When one engineer wants to send a secret message, they encrypt it using the recipient's public key and send the resulting ciphertext, which the recipient then decrypts using their own private key to read the message. Both sides can do this in either direction using each other's public keys.

Setting It Up

Generating a key pair can be done with GPG (gpg --full-generate-key, choosing RSA at 4096 bits with an appropriate expiration) or with OpenSSL (openssl genrsa -out my_private.pem 4096 followed by openssl rsa -in my_private.pem -pubout -out my_public.pem), producing a private key file to keep secret and a public key file safe to share.

Sharing public keys means exporting your own (with something like gpg --export --armor your@email.com > my_public_key.asc, or just sharing the already-exported OpenSSL public key file), sending that file to your partner through email or a shared drive, and importing whatever public key file they send back to you.

Encrypting and sending a message means composing the message, then encrypting it with the recipient's public key (gpg --encrypt --recipient partner@email.com message.txt or the equivalent OpenSSL command), producing an encrypted file that's completely safe to send over any channel since only the recipient's private key can decrypt it.

Receiving and decrypting works the same way in reverse: taking the encrypted file you received and decrypting it with your own private key (gpg --decrypt received_message.txt.gpg > decrypted_message.txt or the equivalent OpenSSL command), which restores the original readable message.

What This Demonstrates

This setup provides real confidentiality, since only the intended recipient's private key can ever decrypt the message, and it requires no pre-shared secret at all, since public keys can be exchanged completely openly without any secure channel needed in advance. Optionally, digital signatures can be layered on top to also verify who actually sent a message. This mirrors real-world secure communication used for coordinating critical infrastructure, government classified communications, confidential corporate projects, and protecting journalist-source communications.

Testing this setup just means confirming the encrypted file is genuinely unreadable gibberish until decrypted, and confirming that trying to decrypt a message without the correct matching private key simply fails, proving the encryption is actually doing its job.

Unit 5 Summary

Scenario 5A shows practical Linux access control in action: least privilege enforced directly through file permissions, with owner, group, and others each getting exactly the access level appropriate to their role, layered across directories to protect increasingly sensitive R&D data. Scenario 5B shows practical asymmetric cryptography in action: generating key pairs, distributing public keys openly, and using them to establish genuinely secure communication without ever needing a pre-shared secret.

The common thread across both: defense in depth (physical isolation plus access controls in 5A), the principle of least privilege, and practical, hands-on cryptography and access control implementation, all balanced against real operational needs like coordination and communication.

BackNext