The CIA triad

Almost every security control, policy, and incident ultimately traces back to one of three properties: Confidentiality (only the people who should see the data can see it), Integrity (the data hasn't been altered in a way that wasn't authorized, and you can verify that), and Availability (the systems and data are actually reachable when someone legitimately needs them). It's the first framework taught in nearly every entry-level security course, not because it's simple, but because it gives you a fast way to categorize what's actually at stake in any given incident.

Mapping real incidents onto the triad makes it click. A stolen customer database is a confidentiality failure. A ransomware attack that encrypts files without stealing them is primarily an availability failure — the data still exists, but no one can use it. A tampered financial record that changes a number without anyone noticing is an integrity failure, often the hardest of the three to detect precisely because nothing looks obviously wrong. Most real breaches touch more than one leg of the triad at once, which is part of why they're expensive to clean up.

Authentication vs. authorization

These two words get used almost interchangeably in casual conversation, but they answer different questions. Authentication answers "are you who you say you are?" — a password, a fingerprint, a code from an authenticator app. Authorization answers a separate question that only makes sense once identity is established: "now that we know who you are, what are you allowed to do?" A logged-in employee is authenticated; whether that employee can access the payroll database is a matter of authorization.

Multi-factor authentication (MFA) strengthens the first question by requiring more than one type of proof — something you know (a password), something you have (a phone or hardware key), or something you are (a fingerprint) — so that a stolen password alone isn't enough to get in. On the authorization side, the guiding principle is usually least privilege: give an account only the access it actually needs to do its job, nothing more, so that if it's ever compromised, the blast radius is as small as possible. Most access-related breaches trace back to one of these two principles being skipped, not to some exotic technical flaw.

Encryption and hashing, without the math

Encryption comes in two main flavors. Symmetric encryption uses the same key to lock and unlock data — fast, but it creates a hard problem: how do you get that key to the other person without someone intercepting it along the way? Asymmetric encryption solves that by using a mathematically linked pair of keys — a public key anyone can use to encrypt a message, and a private key, kept secret, that's the only thing that can decrypt it. This pairing is what makes HTTPS possible: your browser and a website can agree on a secure connection without ever having met before.

Hashing is a different tool entirely, and one of the most commonly confused with encryption. A hash function takes data of any size and produces a fixed-length string that's effectively impossible to reverse back into the original — it's a one-way street, not a lock-and-key. That makes it useful for exactly the situations where you never want to get the original data back: storing passwords (a website should never be able to see your actual password, only its hash) and verifying that a downloaded file hasn't been tampered with, since changing even one byte produces a completely different hash.

IP addressing, the ten-minute version

Every device on a network needs a unique address to be reachable — the digital equivalent of a street number. An IPv4 address, written as four numbers separated by dots (for example, 192.168.1.24), is that address. Alongside it travels a subnet mask, typically something like 255.255.255.0, which tells the network which portion of the address identifies the network itself and which portion identifies the individual device sitting on it.

There are two ways a device gets its address. Static configuration means someone types the address in by hand — common for servers, printers, and networking equipment that need a predictable, unchanging address. DHCP (Dynamic Host Configuration Protocol) means a server on the network assigns the address automatically when a device connects, which is why most laptops, phones, and home devices never need manual setup at all.

The fastest way to see any of this in practice is the command line. Running ipconfig on Windows (or ifconfig / ip addr on Linux and macOS) shows the address, subnet mask, and default gateway a device is actually using right now — usually the first thing worth checking any time something on a network isn't behaving the way it should.

Based on a Cisco Packet Tracer networking lab, "Basic Network Information."

Reading packets with Wireshark

Every other topic on this page describes traffic in the abstract — an IP address, a TCP handshake, an encrypted session. A packet analyzer like Wireshark is what makes all of that literal: it captures every frame crossing a network interface and lets you open one up to see exactly what's inside, header by header. It's the tool that turns "the network is slow" or "something looks suspicious" from a guess into something you can actually verify.

The clearest place to see this is the TCP three-way handshake, the exchange that opens every TCP connection: a SYN packet from the client, a SYN-ACK back from the server, and a final ACK from the client confirming the connection is open. Below is a real capture of that exchange — the highlighted row is the initial SYN, and the pattern repeats for every TCP session on the network. If the SYN-ACK never comes back, that's usually the first sign a server is unreachable rather than just slow.

A single minute of ordinary browsing can generate thousands of packets, which is where display filters earn their keep — typing http, dns, or tcp.port==443 narrows that flood down to exactly the conversation that matters, and filters can be combined with AND/OR/NOT to get specific fast. The other thing that becomes viscerally clear the first time you use one of these tools: unencrypted protocols like HTTP and FTP are completely readable in plain text, usernames and passwords included, while HTTPS traffic shows up as unreadable ciphertext. It's the difference between a postcard and a sealed envelope, and seeing it firsthand makes the case for encryption better than any lecture does.

Based on a personal Wireshark lab exercise, "Tech Exploration Reflection."

The incident response lifecycle

When something goes wrong, "figure it out as you go" is how a bad day turns into a bad week. The standard framework, drawn from NIST guidance, breaks response into six phases: Preparation (having playbooks, contact lists, and tools ready before anything happens — the phase most often skipped, and the one that matters most), Detection & Analysis (noticing something is wrong and figuring out what it actually is), Containment (stopping it from getting worse, often by isolating affected systems), Eradication (removing the actual cause, not just the symptom), Recovery (safely restoring normal operations), and Lessons Learned (documenting what happened so the same gap doesn't get exploited twice).

The order matters more than it looks. Skipping straight to eradication before containment can tip off an attacker and cause them to accelerate or destroy evidence. Skipping the final phase means the organization pays the same cost again the next time a similar incident happens — and post-incident reviews consistently show that most breaches exploit a gap that a previous incident should have already closed.

Malware, and what actually separates the types

"Malware" is an umbrella term, and the differences between its categories usually come down to two questions: how does it spread, and does it need a person to help it along? A virus attaches itself to a legitimate file and needs that file to actually be opened or run before it activates and spreads — it depends on human action. A worm does away with that requirement entirely, self-replicating and spreading across a network on its own, which is why worm outbreaks can escalate far faster than viruses. A trojan doesn't self-replicate at all; it disguises itself as legitimate software and relies purely on deception to get installed in the first place, at which point it can open a backdoor or deliver something else.

Ransomware and spyware describe what the malware does rather than how it spreads, which is why either one can arrive via a trojan, a worm, or a phishing attachment. Ransomware encrypts a victim's files and demands payment for the key; spyware quietly monitors activity and exfiltrates data without the victim ever noticing anything changed. Knowing the category matters operationally — a worm outbreak calls for immediate network segmentation, while a trojan calls for figuring out how it got permission to install in the first place.

Social engineering: attacking the person, not the system

Not every attack targets a machine. Social engineering targets the person operating it, using the same psychological levers that work in any con: urgency ("your account will be locked in 10 minutes"), authority ("this is IT, we need your password to fix an issue"), and trust ("click here, it's from your manager"). It works because it routes around technical defenses entirely — a perfectly patched, perfectly firewalled system is still vulnerable if someone with legitimate access can be talked into handing over a credential.

Phishing (email), vishing (voice calls), and smishing (text messages) are the same underlying tactic delivered through different channels. Spear phishing narrows the target to one specific, researched individual — often using details pulled from exactly the kind of OSINT covered further down this page — which makes it far more convincing than a generic mass email. Technical filters catch a meaningful share of these attempts, but the last line of defense is always a person recognizing that something feels off, which is precisely why security awareness training matters as much as any firewall rule. More on that line of thinking is in the Teaching & Training section of the main site.

What is OSINT?

OSINT stands for open-source intelligence — the practice of building a picture of a person or organization using only information that's already public. That includes social media profiles, code repositories, domain registration records, indexes of previously leaked data, and metadata quietly left inside ordinary files. No single piece needs to be sensitive on its own. The value comes from connecting many small, public details until a pattern emerges: a username reused across a professional profile and an old forum account, or a subdomain nobody remembered was still running.

Security professionals use OSINT in two directions. On the offensive side, it's the first phase of a penetration test — mapping an organization's exposure before anything active ever touches its systems, because acting on public information alone is far less likely to trigger alarms or cause damage. On the defensive side, organizations run OSINT against themselves to find out what an attacker would already know for free, and fix what shouldn't be visible.

A few tools worth knowing by name: SpiderFoot, which automates queries across more than a thousand open data sources and organizes results by data type; and Recon-ng, a modular framework where individual reconnaissance tasks are loaded as separate modules inside their own workspace, keeping different investigations cleanly separated. Both reflect the same underlying discipline — passive gathering first, always.

Based on a Cisco Networking Academy lab, "Using OSINT Tools."

How steganography hides data in plain sight

Cryptography and steganography solve different problems. Cryptography scrambles a message so it can't be read without a key — an observer can see that something secret exists, just not what it says. Steganography instead hides the message so no one suspects it's there at all. The name comes from Greek: "covered writing." The practice is ancient, but the digital version is very much a live concern in modern security work.

The most common digital technique is called Least Significant Bit (LSB) substitution. A digital image stores each pixel's color as numbers — in a standard image, three values per pixel, one each for red, green, and blue, ranging from 0 to 255. The last binary digit of each of those numbers — the "least significant bit" — barely affects the visible color at all; changing it shifts the value by just 1 out of 255. Replace that invisible bit, across millions of pixels, with the bits of a secret message, and you can hide a surprising amount of data with zero visible change to the image.

This matters beyond novelty. Malware authors use steganographic techniques to smuggle command-and-control instructions inside innocent-looking images, slipping past filters that only inspect file types and obvious signatures. Digital forensics investigators, in turn, need tools to detect and reverse it: steghide embeds and extracts hidden data in JPEG and BMP files, zsteg scans PNG and BMP files for LSB-encoded data, binwalk detects entire files concatenated inside other files, and exiftool checks a completely different hiding spot — the metadata layer, where a hidden message can sit in a comment field or GPS tag with no bit-level manipulation at all.

Adapted from a steganography tutorial written for hands-on practice with these tools.

What Active Directory actually is

Active Directory is, at its core, a directory service — a structured database of every user, computer, and resource on a network, along with the rules governing who can do what. The server that hosts this database is called a domain controller, and the network of accounts and machines it governs is a domain (something like lab.local in a small lab setup, or a company's real internal domain in production).

The detail that surprises most people learning this for the first time: Active Directory cannot function without DNS. It isn't an optional add-on — a domain controller automatically becomes a DNS server, because AD uses DNS to locate other domain controllers, authenticate users, and let computers find network services in the first place. Promote a server to a domain controller and DNS configuration happens automatically alongside it, precisely because one is meaningless without the other.

Organizational Units and security groups

An Organizational Unit (OU) is a container — typically mapped to something real, like a department (IT, HR, Finance) — used to organize users and computers logically and to apply policy to a specific slice of the organization rather than everyone at once. A security group solves a different problem: rather than granting permissions to individual people one at a time, you grant permissions to a group, then add or remove members from that group as their role changes.

This is role-based access control (RBAC) in practice. Instead of an administrator manually tracking which of two hundred employees can access the finance server, they grant that access once to a "Finance_Team" group — adding someone to the team automatically grants the access, and removing them automatically revokes it. The permission logic lives in one place instead of being scattered across two hundred individual decisions.

Group Policy: configuration at scale

A Group Policy Object (GPO) is a set of configuration rules that gets applied automatically to every user or computer within the OU it's linked to — password complexity requirements, account lockout thresholds, who's allowed to log on locally, which software runs, which USB ports are disabled. Once a GPO is linked to a domain or OU, it applies to everything underneath it without anyone touching an individual machine.

The part that takes some getting used to is inheritance: policies flow downward from domain to OU to sub-OU, and a more specific policy can override a broader one further up the chain. This is powerful — a global password policy for the whole company, with a stricter one layered on top just for IT admins — but it also means OU structure has to be planned before it's built, since reorganizing afterward can quietly change which policies apply to whom.

The Protected Users group, as a case study

Active Directory ships with a built-in security group called Protected Users, and it's a genuinely useful example of what "defense in depth" means in practice rather than as a buzzword. Adding a privileged account to this group changes several things about how that account behaves at once: it can no longer authenticate using weaker legacy protocols like NTLM, its credentials are never cached locally on the machines it logs into, and it becomes resistant to delegation-based attacks.

That combination directly closes off pass-the-hash, a technique where an attacker steals a password's cached hash from memory and uses it to authenticate without ever knowing the actual password. No single setting here is exotic — it's the layering of several unglamorous restrictions that makes a privileged account meaningfully harder to compromise, which is the actual definition of defense in depth.

Why Active Directory is the top target

Compromise a single laptop and you get that laptop. Compromise Active Directory and you potentially control every account, every machine, and every permission in the entire organization — which is exactly why it's consistently the top target in enterprise breaches rather than a side detail. A few named techniques come up constantly in this space: Pass-the-Hash (reusing a stolen credential hash instead of a real password), Kerberoasting (requesting service tickets for accounts with weak passwords and cracking them offline, away from any lockout policy), and Golden Ticket attacks (forging a ticket-granting ticket using a stolen key that lets an attacker impersonate any user, indefinitely).

What connects all three is that none of them require a flaw in Active Directory's code — they exploit how trust and authentication are designed to work by default. That's the real argument for treating AD security as its own discipline rather than an afterthought: privilege escalation and lateral movement, the two phrases that show up in almost every serious breach report, usually describe an attacker moving through exactly the trust relationships AD was built to provide.

Based on a personal Active Directory lab exercise, "Tech Exploration Reflection," researched using the MITRE ATT&CK framework.

Where to go deeper

A few resources worth starting with, in this order: Microsoft Learn's Introduction to Active Directory Domain Services for the authoritative "what" and "why," a hands-on video walkthrough for the "how" (John Savill's Active Directory tutorials are a solid starting point), and the MITRE ATT&CK framework once the fundamentals are solid, for the attacker's-eye view of how these systems actually get compromised in the wild.

What "the cloud" actually means

Strip away the marketing and cloud computing is a simple trade: instead of buying, racking, and maintaining physical servers, you rent computing capacity from someone who already has it running at enormous scale — and you only pay for what you actually use. AWS's version of this rests on a handful of properties that all point the same direction: on-demand access (spin resources up when you need them, stop paying when you don't), elasticity (capacity adjusts automatically as load changes), and global reach (the same infrastructure is available from data centers around the world without you building any of it).

The practical effect is that a two-person startup and a Fortune 500 company can rent the exact same underlying infrastructure — the difference is how much of it they use and how they configure it. That last part, configuration, is where nearly all of cloud security actually lives.

The core building blocks: compute, storage, and databases

EC2 (Elastic Compute Cloud) is a virtual server — you choose the operating system, the hardware profile, and what runs on it, and AWS handles the physical machine underneath. S3 (Simple Storage Service) is object storage built for durability and scale, commonly used for backups, static websites, and data lakes; by default, everything in it is private, and staying that way requires an active decision to open it up rather than an active decision to lock it down. RDS (Relational Database Service) takes a familiar relational database engine — PostgreSQL, MySQL, SQL Server, and others — and manages the tedious parts for you: backups, patching, failover, and scaling.

What ties these together is VPC (Virtual Private Cloud) — a logically isolated network you define yourself, with its own subnets, IP ranges, and routing rules, that closely mirrors how a traditional data center network is laid out. Every EC2 instance and RDS database lives inside a VPC, which is what makes network-level access control possible in the first place.

Security groups and the principle of least privilege

A security group acts as a virtual firewall attached to individual resources, controlling exactly what traffic is allowed in and out — by default, everything is denied, and access is granted explicitly rather than assumed. A common real pattern: a database's security group is configured to accept connections only from the specific application server's security group, not from "the internet" or even "the VPC" broadly — so a database instance can be completely unreachable directly, even though the application that talks to it works fine.

Underneath all of this sits IAM (Identity and Access Management), which defines who — which person, service, or application — is allowed to do what, without ever having to share a password or a permanent key. AWS STS (Security Token Service) extends this with temporary credentials that expire automatically, and CloudHSM handles encryption key management in dedicated hardware for organizations with strict compliance requirements. All three are different angles on the same principle covered elsewhere on this site: grant the minimum access actually needed, nothing more, by default.

You can't secure what you can't see

Two AWS services answer two different but related questions. AWS Config answers "what exists, and how is it configured right now?" — a continuously updated inventory of every resource and its settings, which matters enormously when trying to spot a misconfiguration before it becomes a breach. AWS CloudTrail answers a different question: "who did what, and when?" — logging every API call made against the account, which is exactly the record an investigator needs after an incident to reconstruct what actually happened.

Neither tool prevents anything by itself. Their value is entirely in making the invisible visible — turning "we think this is how our infrastructure is configured" into "here is the actual, current, auditable state of it."

AWS's own security tooling

AWS ships several purpose-built services that map directly onto specific threats. GuardDuty is a threat detection service that continuously analyzes account activity and network traffic for signs of compromise. Shield defends against distributed denial-of-service (DDoS) attacks — the kind that try to knock a service offline through sheer traffic volume rather than exploiting a flaw. Inspector automatically scans for software vulnerabilities and unintended network exposure. Trusted Advisor checks an account's configuration against AWS's own best-practice recommendations and flags where it falls short.

None of these replace the fundamentals covered elsewhere on this page — they're what those fundamentals look like automated and running continuously, rather than checked manually once and forgotten.

Incident response, when the infrastructure is someone else's

The incident response lifecycle covered earlier on this page still applies in the cloud — preparation, detection, containment, eradication, recovery, lessons learned — but the tools change. Good cloud incident response starts before any incident: identifying key personnel in advance, pre-provisioning the access and tools responders will actually need, and running "game days" — deliberate simulated incidents — so the team has already made the hard decisions once before a real one forces them to.

When something does happen, automation is what makes containment fast rather than manual: AWS Systems Manager can isolate or reconfigure resources at scale, AWS Lambda runs response code automatically the moment a trigger fires, CloudFormation can redeploy a known-clean environment from a template rather than trying to manually clean a compromised one, and Step Functions and SNS chain these pieces together and make sure the right people are notified at the right point in the process. The throughline is the same idea that shows up everywhere in cloud security: anything done manually under pressure is done slower and less reliably than the same thing automated in advance.

Based on personal AWS Cloud Security and Cloud Foundations coursework, and the AWS Certified Cloud Practitioner curriculum.

Putting it into practice

All of the above stops being theoretical once it's actually built. Below is a walkthrough of a real, segmented AWS environment — a three-tier VPC with a working WordPress site, a domain controller, and a monitored honeypot.

The design

The network splits into three subnets, each with a distinct job. The Screened Subnet is the only one exposed to the internet — it holds a NAT instance (so private resources can reach the internet without being reachable from it) and a Windows Bastion host, the single controlled entry point for administrative access. The Production Subnet holds the domain controller, database server, and file share — the resources that need protecting most, and that never talk to the internet directly. The Userspace Subnet holds the actual web-facing application. Every arrow on the diagram is a deliberate decision about what's allowed to reach what.

Access control happens at two layers simultaneously: route tables decide which subnets can reach the internet at all, and security groups decide which specific resources can talk to which other specific resources, by name rather than by broad IP range. The Windows Bastion accepts RDP only — nothing else gets an inbound rule to it — and every other service's security group is scoped to allow traffic only from the specific resource that legitimately needs it, not from "the VPC" generally.

The diagram above is the design; this is the AWS console confirming it was actually built — the same subnets and route tables, live.

A working site, not just infrastructure

The Userspace Subnet's EC2 instance runs Docker with a WordPress deployment behind it, backed by the MariaDB database sitting in the Production Subnet — proof that the network segmentation actually works end to end, not just on paper. Separately, three static websites were deployed to S3, each demonstrating a different access-control configuration (a bucket with a policy, a bucket with an ACL, and one behind CloudFront).

Adding a honeypot as an extra layer

Beyond the assignment's requirements, a dedicated security group and EC2 instance were added in the Screened Subnet running Cowrie, an SSH honeypot that logs every login attempt, command, and credential an attacker tries against it — deliberately exposed so it attracts exactly that traffic while everything real stays isolated behind it. A small Flask dashboard was built on top to visualize the results, since raw log files are far less useful than a summary a non-technical reader can glance at.

The value of a honeypot isn't stopping an attack — it's intelligence. Which usernames get tried the most (unsurprisingly: admin, root, ubuntu) and which IPs keep coming back both feed directly into tightening firewall rules and password policy elsewhere in the environment. It's a small-scale version of exactly the "visibility before defense" principle covered earlier on this page.

Should companies adopt the cloud?

"Companies should adopt the cloud with caution — it's important to evaluate things like vendor lock-in, migration complexity, and what happens if the cloud provider itself goes down, alongside the overall cost of operating there." The technology is genuinely powerful, but "powerful" and "the right default choice for every situation" aren't the same claim, and treating cloud adoption as a considered decision rather than an obvious one is itself a security-minded habit worth keeping.

Based on a personal AWS cloud project (CIS 336), built as a three-tier VPC with a live application and monitoring layer.