Unit 5: Securing Applications and Data

If files aren't encrypted, access controls are loose or regular users have admin rights, an attacker who gets in can read, steal or destroy data. Apps that don't validate input are open to injection attacks: SQL injection (sneaking database commands into an input field), cross-site scripting or XSS (planting code that runs in other people's browsers, reflected or stored), buffer overflows (sending more data than memory was set aside for) and directory traversal (using ../ in a URL to reach files outside the web folder).

Data can be at rest, in transit or in use. Sensitive kinds such as PII, PHI and payment card information (PCI) come with legal or industry rules, such as HIPAA for health data and the PCI DSS industry standard for card data. Access control models (role-based, rule-based, discretionary and mandatory, like Bell-LaPadula's "write up, read down") plus least privilege decide who can do what. On Linux you read permissions with ls -l and change them with chmod, in numbers (read 4, write 2, execute 1, as in chmod 640 file) or symbols (as in chmod g+r file).

Encryption turns plaintext into ciphertext using a key, and a bigger keyspace means guessing the key takes longer. Symmetric algorithms use one key to encrypt and decrypt, while asymmetric ones use two; block ciphers work on fixed-size chunks, while stream ciphers work on a continuous flow. AES, the most common symmetric cipher, encrypts 128-bit blocks and can use keys of different lengths, and you can run it with tools like OpenSSL or AES Crypt.

With asymmetric encryption, each receiver makes a key pair: a public key they publish and a private key they guard. To send someone a secret, you encrypt with their public key, and only their private key can decrypt it. Each extra bit of key length doubles the number of possible keys, so longer keys are stronger but slower; recommended lengths rise as computers get faster, and you can only compare lengths within one algorithm, such as RSA or elliptic curve cryptography (ECC).

Secure by design means building security in from the start: companies own their customers' security outcomes, are open about security problems and have leaders who put security first. Secure by default means security features come turned on out of the box. Programmers protect apps by sanitizing input, which means checking that it matches what's expected and removing or rejecting control characters like quotes and semicolons; this blocks many SQL injection, XSS and directory traversal attacks.

Accounting logs show who touched which data, so opening unusual files, activity outside a user's normal pattern, or attempts to copy or delete sensitive files are red flags. Honeypot files full of fake data raise an alert the moment someone opens them, data loss prevention (DLP) services watch how data is used and moved, and comparing a file's hash (with sha256sum or Get-FileHash) shows whether it changed. In web logs, quotes, OR 1=1, -- and SQL keywords suggest SQL injection, <script> tags suggest XSS, unusually long requests suggest a buffer overflow attempt, and ../ sequences suggest directory traversal.