Security Concepts: Foundations and the Attack Landscape
These are notes I've built up studying security concepts across certifications, labs, and real-world work. Same approach as the networking and identity series — my notes handed off to LLMs with instructions on what to include and how to write it. This post covers the conceptual foundations and the attack landscape. Part 2 covers defenses, assessment, incident response, and frameworks.
The CIA Triad
The CIA triad is the foundational framework for thinking about what security is actually protecting. Three properties:
Confidentiality: Sensitive data must not be disclosed to unauthorized parties. Encryption is the primary technical control here.
Integrity: Data must remain consistent and unmodified from source to destination. Hashing is the primary tool — if the hash of data at the destination doesn't match the hash at the source, something changed in transit.
Availability: Authorized parties must be able to access systems and data when they need them. DDoS attacks, ransomware, and hardware failures all threaten availability.
A reasonable argument exists for a fourth property: non-repudiation — the idea that actions taken by any party should be traceable back to them and cannot be denied. If a change is made to a system, logs should record who made it, when, and what they changed. Digital signatures in asymmetric cryptography support this technically: if an action or document is signed with a private key that only one party controls, the signature can be used as evidence that it came from that party.
Cryptography
Cryptography is the practice of securing data by transforming it into a form that's unreadable without the appropriate key or secret. It covers three distinct mechanisms, each addressing a different part of the CIA triad.
Symmetric Encryption
One key. The same key encrypts and decrypts. Faster than asymmetric encryption, which makes it the choice for bulk data transfer once a secure channel has been established.
Common algorithms:
AES (Advanced Encryption Standard): The current standard. Strong security, fast performance, widely deployed everywhere.
DES (Data Encryption Standard): An older standard, now considered insecure due to a short key length (56 bits). Don't use it.
3DES (Triple DES): Applies DES three times in succession to increase effective key strength. More secure than DES but significantly slower. It was used as a transition away from DES, but it is now legacy cryptography. NIST deprecated three-key TDEA encryption through 2023 and disallowed it for encryption after 2023 unless another specific NIST guidance allows it.
Blowfish and Twofish: Symmetric block ciphers known for speed and efficiency. Twofish was a finalist in the AES selection process.
Asymmetric Encryption
Two mathematically related keys: a public key and a private key. What one key encrypts, only the other can decrypt. Slower than symmetric, but enables capabilities that symmetric encryption cannot provide on its own.
Two usage patterns:
For confidentiality: encrypt with the recipient's public key. Only their private key can decrypt it. Anyone can send something to you, but only you can read it.
For authentication and non-repudiation: encrypt (sign) with your own private key. Anyone with your public key can decrypt it and confirm it came from you. This is digital signatures.
Common algorithms:
RSA (Rivest-Shamir-Adleman): The most widely used asymmetric algorithm. Used for both encryption and digital signatures. Security relies on the computational difficulty of factoring the product of two large prime numbers.
ECC (Elliptic Curve Cryptography): Achieves equivalent security to RSA with significantly smaller key sizes. More efficient on mobile and embedded devices. Increasingly the preferred choice.
Diffie-Hellman (DH): A key exchange protocol rather than an encryption algorithm. It allows two parties to establish a shared secret over an insecure channel without transmitting the secret itself. That shared secret then becomes the symmetric encryption key. ECDH (Elliptic Curve Diffie-Hellman) is the modern variant.
RSA vs Diffie-Hellman
The distinction is frequently tested and worth being precise about. RSA is a general-purpose asymmetric algorithm — it can encrypt data directly and create digital signatures. Diffie-Hellman is specifically for key exchange. Its only job is to allow two parties to agree on a shared secret that neither has to transmit in the clear. DH doesn't encrypt anything itself; it creates the secret that symmetric encryption then uses.
In practice, many protocols use DH (or ECDH) to establish session keys and then use those keys for symmetric encryption of actual traffic. RSA may be used alongside it to authenticate the parties.
Hashing
A one-way transformation that produces a fixed-size output (the hash or digest) from an input of any size. Two important properties: the same input always produces the same output, and any change to the input produces a completely different output.
Hashing addresses integrity. You hash data at the source, transmit the hash alongside the data, and hash it again at the destination. If the hashes match, the data arrived unchanged. This is often called a CRC (Cyclic Redundancy Check) in networking contexts, though that's technically a simpler form of error detection. In an adversarial setting, the hash also needs to be protected with something like an HMAC or digital signature, otherwise an attacker could modify both the data and the hash.
Common algorithms: SHA-256, SHA-512, MD5 (now considered weak due to hash collisions — different inputs producing the same output).
Hash collisions matter: if a hashing algorithm can produce the same output for two different inputs, it's no longer reliable for integrity checking. A strong hashing algorithm should make collisions computationally infeasible.
Encoding, Encryption, and Hashing
Three related but distinct things that are frequently confused:
Encoding converts data from one format to another for compatibility. Base64 encoding, URL encoding, ASCII — these transform data so it can travel through systems that expect certain formats. Encoding is easily reversible and provides no security. It's not secret and not intended to be.
Encryption uses a secret key to transform data into an unreadable form. Only someone with the appropriate key can reverse it. Encryption provides confidentiality.
Hashing is a one-way transformation with a deterministic output. It cannot be reversed. It provides integrity, not confidentiality. Hashing the same input always yields the same hash, and any modification produces a different hash.
The practical distinction: if you need to recover the original data, you encrypt it. If you only need to verify the data hasn't changed, you hash it. If you need to represent data in a different format for transmission, you encode it.
Compression Before Encryption
When you need to both compress and encrypt data, compress first.
Encryption is designed to make data appear random — it eliminates predictable patterns. Compression algorithms work by finding and eliminating redundancy and patterns in data. If you encrypt first, the data looks random, and compression has nothing to work with. The compressed output will be roughly the same size as the encrypted input, meaning you got no benefit.
If you compress first, you reduce the data size before encryption. Less data means faster encryption, less bandwidth, and less compute. The security of the encryption is unaffected by the order.
Block Ciphers and Stream Ciphers
Two fundamental approaches to symmetric encryption:
Stream ciphers encrypt data one bit or byte at a time in a continuous stream. Fast and efficient, suitable for real-time applications like voice and video encryption where latency matters. Vulnerable if the same keystream is reused, which usually happens when the same key and nonce/IV combination is reused.
Block ciphers encrypt data in fixed-size chunks (typically 128 or 256 bits). If the plaintext doesn't fill a complete block, padding is added to reach the required size. More structured than stream ciphers and generally considered more secure, but slower. AES is a block cipher. Block ciphers are more commonly used for file encryption and data at rest.
Salting
Passwords stored in databases should be protected with a modern password-hashing algorithm, never stored in plaintext. That means slow, purpose-built algorithms like Argon2id, bcrypt, scrypt, or PBKDF2, not fast general-purpose hashes like plain SHA-256. The problem with naive hashing: two users with the same password produce the same hash. An attacker who compromises a database can run a precomputed list of common password hashes against the database and immediately identify accounts using those passwords. This is a rainbow table attack.
Salting fixes this. Before hashing, a short randomly generated string (the salt) is concatenated with the plaintext password. The combined value is then hashed. The salt itself is stored in the database alongside the hash — it's not secret. Its only job is to make each user's hash unique even if their passwords are identical.
Because each hash was computed with a different salt, precomputed rainbow tables are useless. An attacker would need to compute a new rainbow table for every unique salt in the database, which is computationally prohibitive at scale.
Forward Secrecy
Forward secrecy (sometimes called Perfect Forward Secrecy or PFS) is a property of cryptographic protocols that ensures past communication sessions cannot be decrypted even if the server's long-term private key is compromised in the future.
Without forward secrecy, a single private key is used to derive session keys. If an attacker records encrypted traffic today and later obtains the private key, they can decrypt all past sessions.
With forward secrecy, unique session keys are generated for each session using a Diffie-Hellman key exchange, and those keys are discarded after the session ends. The server's long-term private key is used only for authentication, not for deriving session keys. Compromising the private key later reveals nothing about past sessions because the ephemeral session keys were never stored.
TLS 1.3 mandates forward secrecy. TLS 1.2 supports it but doesn't require it.
Black Hat vs White Hat Hackers
The distinction is authorization. Both groups use overlapping techniques and tools. White hat hackers are employed or commissioned by organizations to attempt to breach their systems — the goal is to find vulnerabilities before someone malicious does. The activity is authorized, documented, and conducted within a defined scope. Black hat hackers conduct the same activities without authorization, typically for personal gain, financial extortion, espionage, or disruption. The technical skills may be similar; the authorization and intent are not.
Brute Force Attacks
A brute force attack exhausts all possible combinations to crack a password, PIN, or encrypted data. No sophistication required — just computational power and time. Dictionary attacks are a related technique using lists of common words and known passwords rather than truly exhaustive enumeration.
Prevention:
- Long passwords over complex ones. A 20-character passphrase is harder to brute-force than an 8-character password with special characters. Set minimum length requirements in the 20-30 character range to naturally push users toward passphrases (where feasible, of course).
- MFA. Even if a password is compromised, a second factor prevents access.
- Account lockout policies. Lock an account after a threshold of failed attempts. Rate limiting serves the same function for API endpoints.
Phishing, Spear Phishing, and Pharming
Phishing: Attackers send fraudulent messages — emails, texts, fake websites — designed to trick users into revealing credentials, downloading malware, or performing other unintended actions. The deception relies on impersonating a trustworthy entity.
Spear phishing: Targeted phishing. The attacker researches a specific individual or organization and crafts a message tailored to that target. A generic phishing email sent to thousands of addresses is fishing with a wide net. Spear phishing is a more precise, more convincing approach against a single target.
Pharming: Rather than tricking users into clicking a malicious link, pharming manipulates DNS or local configuration to redirect them to a fraudulent site automatically — even when they type a legitimate URL directly. Two primary methods:
- Compromising DNS servers to return malicious IP addresses for legitimate domain names.
- Modifying the victim's local
hostsfile to point domains at attacker-controlled IPs. - Installing malware that alters browser or network settings to reroute traffic.
Pharming requires no action from the victim beyond opening their browser. The redirect happens invisibly.
Cross-Site Scripting (XSS)
XSS exploits a vulnerability in how a web application handles user-supplied input. If the application fails to sanitize inputs, an attacker can inject JavaScript that runs in other users' browsers.
Reflected XSS: The attacker crafts a malicious URL containing JavaScript as a query parameter. When a victim clicks the link, the server reflects that input back in the response without sanitizing it, and the browser executes it. A common use is to exfiltrate session cookies by encoding a script that sends the victim's cookies to an attacker-controlled server. The attacker then replays that cookie value to impersonate the victim — this is session hijacking.
Stored XSS: The attacker injects malicious JavaScript into a form field that gets stored in the application's database — a comment field on a forum, a user profile, a message inbox. Every user who loads that content subsequently executes the injected script in their browser without any interaction with the attacker.
Prevention:
- Output encoding: When user-supplied data is rendered back in HTML, encode it so characters like
<script>are displayed as literal text rather than parsed as HTML. - Input sanitization: Validate and sanitize all user-supplied input. Special characters like
<,>, and"should be handled as data, not markup. - Content Security Policy (CSP): A response header that tells the browser which domains are allowed to load scripts, styles, and other resources. Scripts from unlisted sources are blocked.
- HTTP-only flag on cookies: Prevents JavaScript from accessing cookies via
document.cookie, blocking cookie theft even if a script is injected successfully. - Security awareness training.
SQL Injection
SQL injection attacks a web application's database by inserting malicious SQL commands into input fields. If the application passes user input directly into a SQL query without validation, the attacker's input becomes part of the query itself.
A classic example: a login form that constructs a query like SELECT * FROM users WHERE username = '[input]'. If the attacker enters ' OR 1=1; -- as the username, the query becomes SELECT * FROM users WHERE username = '' OR 1=1; --. The 1=1 condition is always true, the -- comments out the rest of the query, and the attacker bypasses authentication entirely.
Beyond authentication bypass, SQL injection can dump entire tables, modify or delete records, and in some configurations execute OS commands.
Prevention:
Parameterized queries (prepared statements): The query structure is defined before any user input is supplied. Input is passed as a parameter and treated as data, never as executable SQL code.
cursor.execute("SELECT * FROM users WHERE username = ? AND password = ?", (username, password))
Stored procedures: Precompiled SQL logic stored in the database itself. User input is passed as parameters into predefined logic rather than being concatenated into queries.
Input validation: Limit input to expected formats where possible, such as numbers, dates, known enum values, or allowed character sets. Do not rely on blocking SQL metacharacters as the main defense; parameterized queries are the main defense.
Least privilege: The database account the application uses should have only the permissions it needs. A read-only application should connect with a read-only DB account. If injection occurs, the blast radius is limited.
Monitoring and logging: Anomalous query patterns, unusual access times, and unexpected data volumes are detectable signals.
Buffer Overflow
A buffer overflow occurs when more data is written to a memory buffer than the buffer was allocated to hold. The excess data overwrites adjacent memory, which can include a function's return address on the call stack.
An attacker who can control what goes into the overflow crafts input to overwrite the return address with a pointer to their own malicious code — shellcode they've also planted in memory. When the function returns, execution jumps to the attacker's code instead of the legitimate return destination. The code runs with the privileges of the vulnerable process.
Buffer overflows arise from code that doesn't validate input length before writing to a fixed-size buffer. Common in older C and C++ programs.
Prevention:
Bounds checking: Verify that input length doesn't exceed the buffer before writing. Reject or truncate input that exceeds the limit.
Modern memory-safe languages: Java, Python, Rust, and Go perform automatic memory management. Buffer overflows are much harder or impossible to exploit in these languages because the runtime handles allocation and boundary enforcement. They are not magic, and unsafe code, native extensions, or runtime bugs can still create memory issues, but the default risk is much lower.
Stack canaries: A known value (the canary) is placed in memory just before the return address. Before a function returns, the program checks whether the canary value has changed. If a buffer overflow overwrote it, the program terminates rather than executing the attacker's redirect.
DEP (Data Execution Prevention): Marks regions of memory like the stack as non-executable. Even if an attacker overwrites the return address, injected code placed in those regions cannot be executed.
ASLR (Address Space Layout Randomization): Randomizes the memory addresses where the stack, heap, and libraries are loaded at runtime. An attacker who has crafted a payload pointing to a specific memory address finds that address is different every execution, making reliable exploitation far harder.
Man-in-the-Middle Attacks
A MITM attack positions an attacker in the communication path between two parties. The attacker can read, modify, or inject traffic in both directions while both parties believe they're communicating with each other directly.
Common contexts: public Wi-Fi, ARP poisoning on local networks, rogue access points, and compromised DNS.
Prevention: use TLS or another authenticated encryption protocol so intercepted traffic is unreadable and tampering is detectable. Validate certificates properly. Use mutual authentication where both sides need to prove identity. IDS/IPS and firewalls can help detect known patterns, but they do not replace proper cryptographic protection.
DNS Attacks
DNS is a high-value target because it underlies nearly all internet communication. Several attack categories:
DNS cache poisoning: The attacker sends forged DNS responses to a resolver before the legitimate response arrives, poisoning its cache with a false IP mapping. Subsequent users querying that resolver are directed to the attacker's server instead of the legitimate one. Used to redirect victims to phishing sites.
DNS amplification: The attacker sends DNS queries with the source IP spoofed to the victim's address. The DNS server sends its (often large) response to the victim rather than the attacker. Repeating this at scale floods the victim with DNS traffic. The amplification factor — response size vs query size — can be substantial.
DNS tunneling: Data is exfiltrated by encoding it into DNS queries. The attacker controls a domain and a server that listens for these queries. Outbound DNS traffic is commonly allowed through firewalls with minimal inspection, making this an effective covert channel for command-and-control (C2) communication or data theft.
Detecting DNS tunneling: a domain with an unusually high number of unique subdomains is a strong indicator of compromise (IOC), especially when combined with long random-looking labels, unusual query volume, high NXDOMAIN rates, or traffic to newly seen domains. Legitimate domains — outside of CDNs — don't generate hundreds or thousands of distinct subdomain lookups. Tools like RITA (Real Intelligence Threat Analytics) can identify this pattern in DNS logs automatically.
DNS reflection: The attacker spoofs the victim's source IP so DNS servers send replies to the victim instead of the attacker. Similar to DNS amplification discussed above, which is a reflection attack where the replies are much larger than the original queries, multiplying the traffic volume.
DNS monitoring matters because recon activities also use DNS. Attackers may enumerate NS records and attempt zone transfers, which if successful hand them a complete copy of an organization's DNS records — a detailed inventory of infrastructure. Monitoring for unusual query volumes, abnormal subdomain patterns, and zone transfer attempts provides visibility into reconnaissance and active attacks.
Replay Attacks
An attacker captures valid network traffic — an authentication token, a session cookie, a signed request — and retransmits it later to gain unauthorized access. The content is legitimate; the timing is not.
Defense requires that captured traffic be unusable after its original context. Timestamps with strict validity windows, one-time tokens, and nonces (numbers used once) make replayed traffic detectable and rejectable. Short-lived session tokens and the state/nonce mechanisms in OIDC (covered in the identity series) address this for authentication flows specifically.
Botnets
A botnet is a network of compromised devices — called bots or zombies — controlled remotely by an attacker. Devices are compromised through malware without the owner's knowledge. The controller (botmaster) issues commands to the infected fleet, typically through a C2 (command-and-control) server.
Common uses: DDoS attacks (coordinating thousands of devices to flood a target simultaneously), spam campaigns, credential stuffing, cryptocurrency mining on the victim's hardware, and data theft. Large botnets can number in the millions of infected devices.
Viruses vs Worms
Two distinct categories of self-replicating malware:
Virus: Attaches to or embeds inside a legitimate file. Requires human action to execute — opening an infected document, running an infected executable. The virus activates when the file is opened, not when it's downloaded. It can spread by infecting other files on the same system or by being shared.
Worm: Self-contained and self-propagating. Requires no human interaction and no host file. A worm exploits network vulnerabilities or system weaknesses to replicate itself across connected devices. A device can be infected simply by being on the same network as a compromised machine.
The practical difference in threat modeling: viruses require user behavior (opening files) as part of the attack chain. Worms don't, which makes them substantially harder to contain once they're in a network.
Polymorphic Viruses
Standard antivirus software detects malware by matching code against a database of known malicious signatures. A polymorphic virus defeats this by mutating its own code with each infection. The core malicious payload remains intact, but the code surrounding it is rewritten — encryption, instruction reordering, insertion of junk instructions — producing a different binary signature every time.
Defending against polymorphic malware requires behavioral detection rather than signature matching. Heuristic analysis identifies suspicious behaviors: abnormal system calls, attempts to disable security software, unusual file access patterns. EDR solutions use this approach, building a behavioral baseline for each endpoint and flagging deviations.
Null Sessions
A null session is an unauthenticated connection to a Windows system's IPC$ (Inter-Process Communication) share using blank credentials. Historically exploitable via the SMB (Server Message Block) protocol in older Windows versions.
The attack command:
net use \\[IP_address]\ipc$ "" /user:""
Once established, a null session can be used to enumerate usernames, groups, network shares, and system configurations — valuable reconnaissance for further exploitation. The IPC$ share was originally designed for administrative purposes. Leaving null session access enabled exposes that administrative interface to unauthenticated queries.
Mitigation: keep SMB updated, disable null session authentication in registry settings, restrict anonymous access, enforce strong authentication, and audit regularly.
Spyware and Cookies
Spyware can use tracking cookies and other browser storage mechanisms to gather information about browsing behavior, but spyware is broader than cookies. It can also include software that logs keystrokes, captures screenshots, monitors files, or exfiltrates data from the device.
Third-party tracking cookies: Set by domains other than the one currently visited. Advertising networks use these to build profiles of browsing activity across multiple sites. Spyware can exploit them to monitor and exfiltrate browsing habits.
Zombie cookies: Persistent and difficult to remove. Even after a user deletes their cookies, zombie cookies can regenerate themselves — typically by using multiple storage mechanisms simultaneously (browser cookies, localStorage, ETags, cached images). They ensure continuity of tracking even after active deletion attempts.
Rubber-Hose Cryptanalysis
The term for extracting cryptographic secrets through physical coercion or threats — compelling someone to reveal their key or passphrase through intimidation, violence, or torture. A reminder that strong encryption doesn't help if the human holding the key can be threatened into giving it up. Legal protections, key escrow policies, and multi-party key custody arrangements are the organizational mitigations.
Data Leakage
Data leakage is the unauthorized transmission or exposure of sensitive data from within an organization to an external destination. Three categories:
Accidental: Human error or misconfiguration. An email sent to the wrong recipient, an S3 bucket left publicly accessible, a file shared with the wrong permissions. No malicious intent.
Intentional: A malicious insider deliberately exfiltrating data. Uploading to personal cloud storage, copying to USB drives, emailing to personal accounts. Motivated by financial gain, competitive advantage, or intent to harm the organization.
Systemic: Vulnerabilities or weaknesses in systems, integrations, or APIs allow unauthorized access. Exploitable bugs, misconfigured interfaces, or inadequate security controls expose data without necessarily requiring any insider action.
Public Wi-Fi Risks
Public Wi-Fi is an uncontrolled environment. Several risks exist by default:
MITM attacks: If traffic is unencrypted, an attacker on the same network can intercept and read it. Packet sniffing requires nothing more than a laptop and freely available tools.
Rogue hotspots: An attacker creates a Wi-Fi access point with a name similar to a legitimate one — "Coffee_Shop_Free" vs "CoffeeShopFree." Users connect to the attacker's AP instead of the real one, routing all traffic through the attacker's device.
Session hijacking: By sniffing traffic, an attacker can capture session cookies or tokens. With a valid session token, they can authenticate to services without knowing the password. This is the same mechanism behind reflected XSS session hijacking but achieved through network-level interception instead.
Mitigation: prefer HTTPS/TLS-protected services, validate certificate warnings instead of clicking through them, use a trusted VPN when you do not trust the local network, keep devices and software updated, and run a local firewall.
ARP
ARP (Address Resolution Protocol) resolves IP addresses to MAC addresses on a local network. Before sending a frame, a device that knows only the destination IP needs to find its Layer 2 address.
The requesting device broadcasts an ARP request to all devices on the segment: "Who has IP address X? Reply with your MAC." The device with that IP unicasts a reply containing its MAC address. The requester caches this mapping in its ARP table for future use.
ARP has no authentication. Any device can respond to an ARP request, including malicious ones. ARP poisoning exploits this: an attacker sends unsolicited ARP replies associating their own MAC address with a legitimate IP (such as the default gateway). Devices that accept this update route traffic to the attacker instead of the real destination — a foundation for MITM attacks on the local network.
HTTP and HTTPS Default Ports
HTTP operates on TCP port 80. HTTPS operates on TCP port 443. HTTPS is HTTP over TLS — the connection is encrypted using the TLS handshake covered in the TLS/SSL blog. The protocol logic is identical; the transport is secured.
Part 2 covers defenses, detection tools, assessment, incident response, risk management, and security frameworks.