DEV Community: TiltedLunar123

How to answer Security+ incident response questions when every option looks correct

TiltedLunar123 — Sun, 21 Jun 2026 23:17:35 +0000

If you have taken a Security+ practice test, you know the incident response questions have a particular kind of cruelty to them. You read the scenario, you look at the four options, and all four are things a security team would actually do. Isolate the host. Reimage the machine. Notify management. Update the firewall rules. Every one of them is reasonable. So how is one of them the answer and the other three wrong?

The trick is that these questions are almost never asking "what is a good idea here." They are asking "what comes next, right now, given where we are in the process." Once you read them that way, a whole category of questions stops being a guessing game.

The phases, in the order CompTIA cares about

SY0-701 lists the incident response process as preparation, detection, analysis, containment, eradication, recovery, and lessons learned. Memorizing the list is the easy part. The exam tests whether you understand that the order is not negotiable.

Preparation happens before anything goes wrong: the policies, the tooling, the runbook, the contact list. Detection is when something trips an alert. Analysis is confirming it is real and scoping how far it reached. Containment is stopping the spread. Eradication is removing the cause. Recovery is getting back to normal operations. Lessons learned is the retro after the dust settles.

Here is the part that catches people. Containment comes before eradication. You stop the bleeding before you treat the wound. A scenario where a workstation is actively beaconing out to a command and control server is not asking you to wipe the disk. It is asking you to pull that machine off the network first. Reimaging is eradication, and if you reimage before you have contained and analyzed, you have destroyed your evidence and possibly left the rest of the environment exposed.

So when every option looks correct, ask one question: which phase are we in? The scenario almost always tells you. "An analyst notices unusual outbound traffic" puts you at detection or analysis. "The malware has been confirmed on three hosts" means you are ready to contain. The right answer is the next step from where the scenario drops you, not the most thorough step on the list.

The forensics version of the same trap

There is a sibling concept that runs on the exact same logic: order of volatility. When you collect evidence, you collect the most fragile data first, because it vanishes the fastest. That means CPU registers and cache, then RAM and running processes, then network connections and the ARP cache, then temporary files, then the disk, and finally archived logs and backups.

The classic wrong answer is to image the hard drive first, because the disk feels like the big important artifact. But memory is gone the moment the machine powers off, while a disk image will still be sitting there an hour from now. The exam rewards you for grabbing the volatile data first. It is the same skill as the incident response question: not "what matters most," but "what has to happen before the window closes."

How to practice this so it sticks

You cannot cram sequencing the way you cram a port number. What works is repetition against questions that force you to place yourself in the timeline. When you miss one, do not just read the correct answer and move on. Write down which phase the scenario was in and which phase your wrong answer belonged to. Most of the time you will find you picked a step that was correct but premature.

If you want a quick read on where you stand, the free diagnostic at secplusmastery.com/diagnostic will tell you whether security operations is a weak area before you pour hours into it. From there I have been grinding the incident response and forensics questions on secplusmastery.com, and the pattern above held across almost all of them: the scenario tells you where you are, and the answer is the next move.

One habit that makes it automatic

Before you read the options on any incident response question, cover them and answer in your head first: what phase is this, and what is the single next action. Then uncover the choices and find the one that matches. It feels slow the first few times you do it. By exam day it turns four plausible answers into one obvious choice and three traps, and it hands you back the time you need for the questions that are genuinely hard.

The vocabulary is the entry fee. The order is the exam.

Public key or private key? The Security+ crypto direction trap

TiltedLunar123 — Sat, 20 Jun 2026 23:15:49 +0000

A lot of people walk into the SY0-701 exam able to recite that asymmetric encryption uses a key pair. Then a question asks "you want to send a confidential file to a coworker, which key do you use?" and the whole thing falls apart. The keys are not the hard part. The direction is.

Here is the trap in one sentence: the key you reach for depends on whether you are protecting confidentiality or proving who sent something. Those are two different goals, and they use the key pair in opposite directions. If you only memorized "public key and private key," you memorized the nouns and skipped the verbs.

Let me lay out both directions, because the exam tests both and it loves to mix them up.

Confidentiality: encrypt with the recipient's public key

You want only your coworker to read the file, so you encrypt it with their public key. Public keys are public on purpose, so anyone can grab one, including you. The math only works in one direction: anything locked with a public key can only be opened with the matching private key. Your coworker is the only person holding that private key, so they are the only one who can decrypt it.

Read that twice, because here is where people slip. They think "I am the sender, so I use my key." Wrong. For confidentiality you never touch your own keys. You use the recipient's public key. The real question is "who should be able to read this," and the answer is "the person whose private key opens it."

Authenticity and non-repudiation: sign with your own private key

Now flip the goal. You do not care about hiding the message. You care about proving it actually came from you and was not changed in transit. That is a digital signature.

To sign, you take a hash of the message and encrypt that hash with your own private key. Anyone can verify it using your public key. Because only you hold your private key, a signature that checks out against your public key could only have come from you. That gives you non-repudiation: you cannot credibly claim later that you did not send it.

Notice the direction is reversed from confidentiality. Confidentiality uses the recipient's keys. Signing uses your keys. Same key pair concept, opposite owner.

The one question that keeps it straight

I stopped memorizing four separate rules and started asking a single question: what am I protecting?

If the goal is "only the right person can read it," the answer involves the reader's keys. Lock with their public key, they open with their private key.

If the goal is "prove it came from me and was not tampered with," the answer involves my keys. Sign with my private key, anyone verifies with my public key.

Public keys encrypt and verify. Private keys decrypt and sign. The owner of the key pair flips depending on the goal, and that ownership is the part the exam is really testing.

What about both at once

Real systems usually want confidentiality and authenticity together, and yes, the exam will ask. You sign with your private key, then encrypt with the recipient's public key. The recipient decrypts with their private key, then verifies your signature with your public key. Two key pairs, four operations, but each step still follows the same logic: reader's keys for secrecy, sender's keys for proof.

One more thing that catches people. Asymmetric encryption is slow, so in practice it rarely encrypts a whole file. It encrypts a randomly generated symmetric key, and that symmetric key encrypts the bulk data. That is exactly what TLS does on every HTTPS connection. If a question mentions a "session key" or "wrapping a key," that hybrid model is what it is pointing at.

How to actually drill this

Definitions will not save you here, because the exam never asks "what is a public key." It hands you a scenario and asks you to pick the key, and those scenarios are written to punish anyone who skipped the direction. The only fix is reps on scenario-style questions until "what am I protecting" becomes the first thing you think.

That is the kind of distinction I built secplusmastery.com around, with practice questions phrased the way the real exam phrases them instead of the way a glossary does. If you want a quick gut check on where you stand before you grind, there is a free diagnostic at secplusmastery.com/diagnostic that will show you fast whether crypto direction is one of your weak spots.

Get the direction reflex down and a whole category of questions stops being scary. Public to lock, private to unlock. Private to sign, public to verify. Decide what you are protecting first, and the key picks itself.

Every Security+ control answers two questions, not one

TiltedLunar123 — Fri, 19 Jun 2026 23:18:28 +0000

A firewall is a technical control. It is also a preventive control. If a Security+ question asks you to classify it and you only give one of those answers, you can still miss the point, because the exam loves to ask about the label you forgot.

This is one of the quietest traps in Domain 1 of SY0-701. A lot of people study security controls as a single flat list and memorize the definitions. Then a question shows up that wants two things at once, and the second axis is the one that slips.

Here is the fix. Every control sits on two separate axes, and you should be able to place any control on both.

Axis one: the category (what kind of thing enforces it)

CompTIA groups controls into four categories:

Technical: enforced by technology. Firewalls, encryption, antivirus, access control lists, MFA prompts.
Managerial: enforced by policy and management decisions. Risk assessments, security policies, change management.
Operational: carried out by people in their day to day work. Security awareness training, guard patrols, incident response handling.
Physical: tangible things that protect tangible spaces. Locks, fences, bollards, badge readers, cameras.

Quick gut check for the category: ask who or what actually carries it out. A machine, a document, a person, or a wall.

Axis two: the control type (when it acts and what it does)

CompTIA lists six control types, and these describe the job a control does relative to an incident:

Preventive: stops the event from happening. A firewall rule, a locked door.
Deterrent: discourages someone from trying. A visible camera, a warning sign, a fence.
Detective: notices that something happened. Logs, IDS alerts, an access review.
Corrective: fixes things after the fact. Restoring from backup, isolating an infected host.
Compensating: a stand in when you cannot use the control you actually want.
Directive: tells people what they are supposed to do. An acceptable use policy, posted procedures.

Why the two axes get tangled

People learn one list and assume a control carries one label. It does not. A control almost always has a category and a type at the same time, and the exam writes questions that pin you on whichever one you were not thinking about.

Walk through a few:

A firewall is technical and preventive.
An IDS is technical and detective. It does not block anything, it tells you something happened.
A nightly backup is technical and corrective. It does nothing to prevent an attack, it helps you recover from one.
A security guard is operational, and depending on the scenario the guard can be deterrent, preventive, or detective.
An acceptable use policy is managerial and directive.
A bollard outside a building is physical and usually deterrent or preventive.

Notice the guard. The same control changes type based on what the question emphasizes.

The part that actually trips people: context changes the type

A security camera recording quietly in a back room is detective. The same camera mounted in plain sight with a sign that says you are being recorded is doing deterrent work. Nothing about the hardware changed. The scenario decided the answer.

This is why memorizing "camera equals detective" burns you. Read what the control is doing in that specific question, not what it usually does.

Compensating controls have the same flavor. A compensating control is not a kind of device, it is a role a control plays because the primary option is off the table. If a legacy system cannot support MFA and you wrap it in extra network segmentation and tighter monitoring instead, that segmentation is compensating in that scenario.

A two question habit that fixes this

For any control in a question, ask both:

What kind of control is it? Technology, policy, people, or physical.
When does it act? Before the event it is preventive, deterrent, or directive. At the moment it is detective. After the fact it is corrective. Standing in for something else, it is compensating.

Answer both every time and the double label questions stop being a coin flip.

How to drill it without burning hours

Make a list of twenty common controls and label both axes for each from memory, then check yourself. The ones you hesitate on are your real weak spots, not the whole domain.

Practice questions matter more than rereading here, because this distinction only shows up under the pressure of a worded scenario. If you want to find which Domain 1 ideas are shaky before you sink a week into the wrong thing, the free diagnostic at https://secplusmastery.com/diagnostic is a fast way to surface them, and the full question bank at https://secplusmastery.com drills these control type questions directly.

Two labels, every control, every time. Once that habit is automatic, a whole flavor of Domain 1 question stops being able to surprise you.

Most Security+ port questions are secretly asking one thing

TiltedLunar123 — Thu, 18 Jun 2026 23:22:27 +0000

If your SY0-701 study plan includes a stack of 40 port flashcards, I want to save you some time. You probably do not need most of them.

Early on I spent a week drilling port numbers cold. 21, 22, 23, 25, 53, 80, 110, 143, 389, 443, 636, and on it went. Then I sat a practice exam and the question did not mention a port number at all. It described a packet capture where an auditor could read directory lookups in plain text, and it asked what the team should switch to. The number on the flashcard was useless. The relationship behind it was the whole point.

Here is the reframe that made ports click for me. Most Security+ port questions are not testing whether you memorized a number. They are testing one idea: is this traffic encrypted, and if it is not, what is the encrypted version of the same thing?

Learn the twins, not the list

Almost every protocol the exam cares about comes as a pair. There is an older cleartext version and a newer secured version that does the same job. Once you see the pairs, the list stops being random trivia and starts being a story about the industry slowly wrapping everything in encryption.

Here are the pairs worth knowing cold:

Telnet on 23 and SSH on 22. Remote shell, insecure then secure.
HTTP on 80 and HTTPS on 443. Web traffic, cleartext then TLS.
FTP on 21 and FTPS on 990, with SFTP riding on SSH at 22. File transfer.
LDAP on 389 and LDAPS on 636. Directory queries.
IMAP on 143 and IMAPS on 993. Mail you keep on the server.
POP3 on 110 and POP3S on 995. Mail you pull down.
SMTP on 25 and SMTP submission with TLS on 587. Sending mail.
DNS on 53 and DNS over TLS on 853. Name resolution.

Notice the pattern in the secure column. A lot of them just add an S and pick a new port. LDAP becomes LDAPS, IMAP becomes IMAPS, POP3 becomes POP3S. The exam leans on the 389 to 636 jump and the 143 to 993 jump because that is exactly where students blank.

How the exam actually asks it

The trap is that the question rarely says "which port is LDAPS." It hands you a symptom and expects you to walk it back to the fix:

An analyst captures traffic and reads usernames in the clear during authentication against the directory service. What should replace it? You are being asked for LDAPS on 636.
A legacy switch is managed over a protocol that sends the admin password unencrypted across the network. What should the team use instead? Telnet to SSH, 23 to 22.
A login form submits credentials and they show up in a proxy log as readable text. The site is on port 80. The answer lives on 443.

Read for the cleartext symptom first. Exposed credentials, readable queries, a sniffed password. Then reach for the secure twin. The port number is the last thing you fill in, not the first.

A few loners that have no twin

Some ports show up on their own and you do just learn them flat. RDP on 3389. Kerberos on 88. SNMP on 161, where the security upgrade is the version, SNMPv3, rather than a brand new port. That version detail is exactly the kind of thing a question will poke at. Keep a short list of the loners and treat them apart from the twins so they do not muddy the pattern.

Drill the relationship, then prove it

Build your flashcards around the pair, not the single number. On the front, put the insecure protocol and what goes wrong with it. On the back, put the secure twin and its port. You are encoding the reason, and the reason is what the scenario questions reward.

Then test the framing under exam conditions. Plain recall in a quiet room feels great and lies to you. The skill the exam wants is reading a messy scenario, spotting the cleartext tell, and landing on the fix in under a minute. I built a free diagnostic that throws scenario-style questions at you so you can find the gap before exam day at secplusmastery.com/diagnostic. If you want the structured version with reading lessons and hands-on labs that build the same instinct across every domain, that lives at secplusmastery.com.

Ports are one of the easiest places to bleed points to memorization, and one of the easiest to fix once you stop memorizing and start pairing. Learn the twins, read for the cleartext symptom, and let the number be the easy part.

Whaling vs spear phishing on Security+: it's about the target, not the technique

TiltedLunar123 — Wed, 17 Jun 2026 23:17:06 +0000

If you have taken a Security+ practice test, you have hit this question: a scenario describes an email attack, and all four answers are real social engineering terms. Phishing, spear phishing, whaling, business email compromise. They are all "kind of right." Only one matches the scenario. That is the whole trap in Domain 2, and once you see how it is built, you stop guessing.

Here is the mental model that fixed it for me.

Social engineering questions test three different axes

When SY0-701 asks you to name a social engineering attack, it is almost always testing one of three things: who the target is, what channel was used, or what mechanism made it work. Most people study the vocabulary as a flat alphabetical list. The exam reads it as three separate dimensions, and the wrong answers are usually pulled from a different dimension than the one the question cares about.

Sort the terms by axis and the scenarios get a lot easier.

Axis 1: the target (this is the one people get backwards)

Phishing is the wide net. Generic message, sent to thousands, no personalization.
Spear phishing is targeted. It names you, your role, or your company. The attacker did homework first.
Whaling is spear phishing aimed at a "big fish," a senior executive who can authorize money or access.

The classic trap: a scenario where an email pretends to be the CEO and asks a finance clerk to wire money. People pick whaling because they see "CEO." But whaling is about who the victim is, not who is being impersonated. The victim here is the clerk, so the attack is spear phishing, the flavor usually called business email compromise (BEC). Read for who gets fooled, not whose name is in the From field.

Axis 2: the channel

Vishing is voice. A phone call or a voicemail.
Smishing is SMS. A text message.
Plain phishing defaults to email.

These are easy points if you slow down enough to notice the delivery method in the scenario. The exam loves to bury "she received a text message" in the middle of a paragraph and then offer phishing as a tempting distractor.

Axis 3: the mechanism

Pharming redirects victims to a fake site, usually by poisoning DNS or a local hosts file. The key tell: the victim typed the correct address and still landed on the fake page. No lure, no click required.
Watering hole compromises a legitimate site the target group already visits, then waits for them to show up.
Typosquatting registers lookalike domains and waits for a fat finger.

If a scenario stresses that the user did nothing wrong and still got redirected, it is pointing at pharming, not phishing.

The layer underneath: principles of influence

Here is the part a lot of study guides skim. SY0-701 also tests why social engineering works, and in those questions the answer choices are not attacks at all. They are psychological levers: authority, intimidation, urgency, scarcity, consensus (social proof), familiarity, and trust.

A question can describe a textbook phishing email and then ask what principle made it effective. "Your account will be locked in 10 minutes" is urgency and scarcity. "This is the IRS, comply now" is authority and intimidation. If the four answers are pressures and emotions rather than attack names, the question quietly switched axes on you. Recognize that and you answer it in five seconds.

How to actually study this

Flashcards that say "whaling = phishing a high-value target" will not save you, because the exam never hands you the definition. It hands you a paragraph and makes you classify it under pressure. The fix is to practice on scenarios, not definitions, and to force yourself to name the axis before you pick an answer: target, channel, or mechanism?

I have been building practice questions around this exact failure mode at secplusmastery.com, where the social engineering items are written as scenarios with plausible distractors from a different axis, the way the real exam does it. If you want a quick read on where you actually stand before you start grinding, the free diagnostic is a no-signup way to find out which domains are leaking points.

Get the three axes straight and Domain 2 stops being a coin flip. The terms were never the hard part. Knowing which question you are actually being asked is.

A password and a PIN aren't multifactor: the Security+ authentication trap

TiltedLunar123 — Wed, 17 Jun 2026 09:47:21 +0000

If you have spent any time on SY0-701 practice questions, you have hit at least one that looks trivial and then quietly fails you. Authentication factor questions are a favorite for this. The scenario sounds secure, the answer feels obvious, and the obvious answer is wrong.

Here is the version that catches people. A login asks for your password, then a PIN, then your mother's maiden name. Three prompts, three steps. Is that multifactor authentication?

No. It is single-factor wearing a costume.

Factors are categories, not steps

The exam wants you thinking about authentication in terms of categories, not how many boxes you fill in. There are three classic factors:

Something you know (knowledge): a password, a PIN, a security question, a passphrase.
Something you have (possession): a phone running an authenticator app, a hardware token, a smart card, a code texted to a device you are holding.
Something you are (inherence): a fingerprint, a face scan, an iris pattern, a voiceprint.

Multifactor authentication means pulling from different categories. A password (know) plus a code from your authenticator app (have) is two factors. A password plus a PIN plus a security question is still one factor, because all three are things you know. Stacking more knowledge on top of knowledge never changes the category.

That is the entire trick. The question piles on prompts so it feels layered, and the count baits you into answering "three things, must be multifactor." Read for the category, not the quantity.

The two factors people forget

SY0-701 also expects you to recognize two more that sit just outside the classic three:

Somewhere you are (location): access is allowed or blocked based on geolocation or which network you are on. A login permitted only from inside the corporate IP range leans on this.
Something you do (behavioral): how you type, your gait, the rhythm of your swipe. This is the fuzziest one, and the exam treats it as a real but supporting signal.

You will not see these as often, but when a question mentions "access granted only from the on-site network" or "keystroke dynamics," you need to drop it in the right bucket without hesitating.

Authentication is not authorization

While we are here, the other word the exam loves to swap on you: authorization. Authentication answers "are you who you claim to be." Authorization answers "now that I know who you are, what are you allowed to touch." Someone can authenticate perfectly and still be denied authorization to a file. When a question describes a user proving identity, that is authentication. When it describes the permissions they get afterward, that is authorization. Both live in the IAAA model (identification, authentication, authorization, accounting), and the test rewards you for not blurring them.

How to handle these under exam pressure

When a factor question shows up, run three steps:

List every credential the scenario actually uses.
Tag each one with its category: know, have, are, where, or do.
Count the distinct categories. Two or more, it is multifactor. One, it is not, no matter how many prompts there were.

It takes about five seconds once it is reflex, and it turns a trap question into a free point.

The deeper lesson fits most of SY0-701: the exam is rarely checking whether you can recite a definition. It is checking whether you can apply that definition to a scenario written to make the wrong answer feel natural. The fix is not more flashcards. It is practicing on questions built the same sneaky way the real ones are.

That is the reason I built SecPlus Mastery, a practice platform for SY0-701 with questions phrased to mirror how the real exam sets these traps, plus reading lessons and hands-on labs for the concepts underneath them. If you want to see where your authentication and access-control instincts actually stand, the free diagnostic exam is a no-signup way to find your weak domains before you pour hours into the wrong ones.

Get the factor question right by reading for the category instead of the count, and you have already beaten the version of it that beats most people.

I couldn't test my VM sizing math without spinning up a real VM

TiltedLunar123 — Tue, 16 Jun 2026 16:18:06 +0000

WhonixAutoSetup is a PowerShell project i keep poking at while studying for Security+. it stands up Whonix on Windows: one VM runs Tor (the gateway), a second VM routes all its traffic through the first (the workstation), so the workstation never has a path to the internet that isn't Tor. four scripts, run in order.

one of those scripts, configure-vms.ps1, decides how much RAM and how many cores each VM gets. the gateway is fixed at 1 core and 1 GB because Tor doesn't need more. the workstation scales with the host: 2 to 4 cores, 25 to 40 percent of available RAM, with a floor so it never boots into something unusable and a ceiling so it doesn't swallow the whole machine.

that's the only part of the script with real logic in it. tiers, a floor, a ceiling, a rounding step. and until last week it had zero tests.

why it had no tests

the function read the hardware and did the math in the same breath:

function Get-ResourceAllocation {
    $totalRam = (Get-CimInstance Win32_ComputerSystem).TotalPhysicalMemory
    $cores    = (Get-CimInstance Win32_Processor).NumberOfLogicalProcessors
    # ...then ~30 lines of tiering, flooring, and rounding on those two values
}

to exercise that, you need a real Windows host handing back real numbers from CIM. so the only way to check whether, say, the 6 GB tier rounded the way i intended was to find a 6 GB machine and run the whole thing. i don't own a shelf of machines at different RAM sizes. i own my laptop. so the math got checked exactly once, at exactly one memory size, and everyone else got my crossed fingers.

that's backwards. the CIM call is the part i can't control and shouldn't be testing, it's Microsoft's. the arithmetic is the part i wrote and the part that actually breaks. the one piece i cared about was welded to the one thing that made it impossible to test in isolation.

the fix is boring, which is the whole point

pull the math into a function that takes numbers instead of a machine:

function Get-VmResourceAllocation {
    param(
        [long]$TotalRamBytes,
        [int]$CoreCount
    )
    # same tiering, flooring, rounding, now operating on parameters
    # returns the same allocation hashtable as before
}

configure-vms.ps1 still does the CIM reads and the logging. it just hands those two numbers to this helper. same inputs, same hashtable that came out before, so a real run behaves identically. nothing changed for anyone running it for real.

what changed is i can now do this with no VM, no VirtualBox, nothing, on a clean CI runner:

It 'leaves a core for the host and never drops below one' {
    (Get-VmResourceAllocation -TotalRamBytes 8GB -CoreCount 1).Cores | Should -Be 1
    (Get-VmResourceAllocation -TotalRamBytes 8GB -CoreCount 4).Cores | Should -Be 3
}

twelve cases now cover the three RAM tiers, the 2 GB workstation floor, the 8 GB ceiling, the 128 MB rounding step, and the core caps. they run under Pester on every push, and they mock VirtualBox and the filesystem so the suite runs anywhere without a hypervisor installed.

the case i was least sure about was a single-core host, the kind of cheap cloud box someone might try this on. i'd genuinely never confirmed what the old function did when handed one core. writing the test was how i finally checked: the "leave one for the host" branch returns 1, not 0. it does the right thing. but "it probably does the right thing" is not what you want to be shipping in the code that decides whether a VM can boot, and that's the state it had been in.

what's still not great

the CIM reads are still untested. i mock them, which means if Windows ever hands back TotalPhysicalMemory in a different shape or unit, my tests stay green while a real run breaks. i'm trusting the boundary i drew. that's the normal cost of this kind of split, but it's worth saying out loud instead of letting a green checkmark imply more coverage than exists.

the RAM percentages are also still magic numbers sitting inside if-branches. 25 here, 40 there. they're tested now, so changing them is safe, but they belong in a small table at the top of the file, not buried in the logic. haven't done that one yet.

the thing i keep relearning

if a chunk of code can only be tested by running the entire program against real infrastructure, that's usually not a testing problem, it's a seam problem. the logic and the I/O are fused, and the fix is to cut them apart, not to build a bigger test rig around the outside.

i knew that going in. i still shipped the fused version first, because it was fewer lines and it ran fine on my machine. it runs fine on more machines now, and i can prove it without owning them.

repo if you want the actual code: github.com/TiltedLunar123/WhonixAutoSetup

How Security+ actually tests access control models (and why memorizing the definitions doesn't save you)

TiltedLunar123 — Tue, 16 Jun 2026 16:15:49 +0000

If you have studied for the SY0-701 exam for more than a week, you can probably recite the four access control models in your sleep. Discretionary, mandatory, role-based, attribute-based. The problem is that the exam almost never asks you to define DAC. It hands you a three-sentence workplace scenario and expects you to name the model that fits. That is a completely different skill, and it is where a lot of otherwise-prepared people lose easy points.

Here is the way I learned to read these questions, plus the two traps that catch most folks.

The four models, one line each

Strip the textbook language down to the single decision each model makes about who gets access.

DAC (Discretionary Access Control): the owner of the resource decides. If a person can grant other people access to a file they created, that is discretionary. Standard file permissions on Windows and Linux work this way.
MAC (Mandatory Access Control): the system decides, based on labels and clearances. Users cannot hand out access even if they want to. This is the classified-data model: Top Secret, Secret, Confidential.
RBAC (Role-Based Access Control): access follows the job. You are a Nurse or an Accountant, and the role carries the permissions. A new hire in that role inherits the same access on day one.
ABAC (Attribute-Based Access Control): access is evaluated from attributes and conditions at request time. Department, device type, time of day, location. Allow if the user is in Finance AND on a managed laptop AND inside business hours.

That is the knowledge half. Now the exam half.

The scenario tells you the model. Find who decides.

Almost every access control question hides the answer in one phrase. Train yourself to hunt for who is making the decision.

"The file's creator can choose to share it with a coworker." Someone owns it and chooses, so that is DAC.
"Access is governed by security labels and a central policy that users cannot override." Labels plus no override is MAC.
"When an employee moves from Sales to Support, their access changes to match the new position." Access tied to position is RBAC.
"Access is granted only if the user is a manager, on a corporate device, connecting from the office network." A stack of conditions is ABAC.

The vocabulary repeats. Owner and discretion point to DAC. Labels and clearance point to MAC. Job title or position points to RBAC. A list of if-conditions points to ABAC.

Trap one: RBAC vs ABAC

This is the pair that separates careful readers from the rest, so the exam leans on it hard. Both can produce the same outcome.

The tell is whether access depends on a single thing (the role) or on several things evaluated together (attributes). "A billing clerk can access billing records" is role driven, so RBAC. "A billing clerk can access billing records only during their shift and only from the office" added time and location, which are attributes, so the better answer is ABAC.

When a question stacks two or more conditions that are not just the job title, the writers are steering you toward ABAC. When it is purely this role gets this access, stay with RBAC.

Trap two: rule-based is not role-based

Read slowly. Rule-based access control applies the same rule to everyone regardless of identity. A firewall that blocks all traffic on a port after 6 PM is rule-based. It sounds almost identical to role-based out loud, and the exam knows it. If the control applies to everyone by a fixed rule rather than by who you are, it is not RBAC.

How to actually drill this

Definitions you can passively reread. Scenario matching you have to practice actively, because the skill is parsing the sentence, not reciting the term. The habit that helped me most was reading the question, then checking why each wrong option was wrong, since the distractors teach you the boundary between two models better than any definition does.

If you want a stack of practice questions and reading lessons mapped to the SY0-701 objectives, that is what I built secplusmastery.com around. There is also a free diagnostic at secplusmastery.com/diagnostic that scores you by domain, so you can tell whether access control is genuinely a weak spot for you or just felt like one.

The one habit that helps most

Before you pick an answer on any access control question, say out loud who or what is making the access decision. The owner, the system labels, the job role, or a set of attributes. That one question collapses four intimidating models into a short decision, and it turns a category of tricky questions into some of the most reliable points on the exam.

my sigma scanner can't count, so i wrote that down instead of faking it

TiltedLunar123 — Mon, 15 Jun 2026 16:26:32 +0000

i've got a small python tool called SIEMForge. you point it at a log file and a folder of sigma rules and it tells you which rules fire on which events, no SIEM involved. it's at v3.1, 10 bundled rules, and the only runtime dependency is pyyaml.

most of what it does is one-event-at-a-time matching. read an event, run every rule against it, print the ones that hit. that model is dead simple, and it's most of the reason the tool is useful for actually writing rules. you tweak a rule, rerun, see the result in under a second. that loop is the whole point.

then i hit the one rule that doesn't fit that model at all.

the rule that's supposed to wait

one of the bundled rules is an ssh brute-force rule. the intent is normal: fire after ten failed logins from the same source ip in a short window. that's a count over time. the sigma rule even carries a custom.threshold_count field that says exactly that.

my scanner has no memory between events. it looks at event 1, forgets it, looks at event 2, forgets it. so when it reaches the first failed ssh login that matches the rule's pattern, it fires. immediately. on failure number one.

which is wrong. an analyst seeing that alert would assume ten failures happened. one did. a single failed ssh login is a tuesday, not an incident.

i sat with this for a while, because there were a few honest ways to go and only one of them was any good.

option one: actually build the counting

i could give the scanner state. keep a dict keyed on (rule, source ip) holding a list of timestamps, and only alert once the count inside the window crosses the threshold. that's real correlation.

it's also a real feature with real edge cases. where's the window boundary. what about clock skew between the log's timestamps and anything else. when do you evict old entries so the dict doesn't grow forever. what's the memory footprint when someone points this at a 90MB jsonl with a million distinct source ips, which, given the tool reads logs that might come off a compromised box, is not a hypothetical.

i started sketching it and realized i was about to build a worse version of the exact thing a SIEM already does well. correlation across time is the part you genuinely want a real engine for. the reason this tool exists is the fast local authoring loop, and bolting a half-working correlator into the hot path would make the simple thing slower to serve the one rule that needs it.

option two: lie a little

i could have made the scanner honor the threshold in some half-baked way and just not mention it. nobody would catch it on the sample data. it would demo fine.

that's the option that bugs me most in hindsight, because detection tooling that quietly does the wrong thing is the worst kind of broken. a web app that breaks throws a 500. a detection rule that breaks just stops alerting, and a missed alert looks identical to a quiet day. there's no error to grep for.

what i actually did

i wrote it down. there's a section in the readme now called "Stateless Matching and Thresholds" that says, in plain words, the scanner evaluates one event at a time, holds no state, and a rule with a threshold_count fires on the first matching event instead of after the count. the threshold fields stay on the rules on purpose, because when you deploy them to wazuh or splunk or elastic, those engines honor them. locally, treat it as a known gap.

here's roughly what the per-event loop looks like, state-free by design:

def scan_events(events, rules):
    alerts = []
    for i, event in enumerate(events):
        for rule in rules:
            if rule.matches(event):          # pure function of one event
                alerts.append(Alert(rule, event, index=i))
    return alerts

rule.matches(event) is a pure function of a single event. no accumulator, no lookback at the events before it. a threshold_count of 10 sits on the rule object, but matches never reads it, so it physically can't wait for the tenth anything.

writing the limitation into the docs felt like admitting the tool is incomplete. it is. but a documented gap is something a user can plan around. an undocumented one is a trap you set for whoever trusts your output.

the part i'd still change

the honest version of this isn't "docs forever." if i build correlation later, i'd do it as a second pass over the alerts the matcher already produced, not by stuffing state into the per-event matcher. keep matches pure. then a separate stage groups matched alerts by rule and source, sorts them by time, and only emits when a window actually has enough. the simple path stays simple, and the stateful path becomes opt-in and testable on its own instead of tangled into everything.

there's a smaller thing the stateless model exposes too. with no state, the scanner can't dedupe. if one noisy process-creation event matches forty times, you get forty alerts. for authoring rules that's fine, you want to see every hit. for anything resembling triage it's just noise. same fix, same hypothetical second pass.

why i bothered writing this up

i'm studying for security+ and aiming at soc analyst work, and the thing that's stuck with me hardest building this isn't a clever piece of code. it's that the distance between "a rule matched an event" and "this is a real alert worth a human's time" is mostly state and context, and that's exactly where a SIEM earns its keep. my little scanner makes that line really visible, mostly because it sits right on the wrong side of it.

repo's here if you want to poke at it or tell me the second-pass design is wrong: https://github.com/TiltedLunar123/SIEMForge

if you've built detection tooling: where do you draw the line between "this authors rules" and "this is a SIEM"? i keep moving mine.

SLE, ARO, ALE: the Security+ risk math that looks easy until the question inverts it

TiltedLunar123 — Mon, 15 Jun 2026 16:13:38 +0000

Most people studying for SY0-701 can recite the quantitative risk formulas in their sleep. Then the exam hands them a word problem where the frequency is phrased as "once every four years" instead of a clean decimal, and half the room writes down a different answer. The math is not hard. The wording is where points leak out.

Here is the whole chain, in order, with no shortcuts.

The five values, in the order they build on each other

AV (Asset Value) is what the thing is worth. A server, a database, a building. Say a customer database is valued at $200,000.

EF (Exposure Factor) is the percentage of that value you lose in one bad event. Not every incident destroys the whole asset. A ransomware hit might cost you 40 percent of the database's value in downtime, recovery, and lost records. EF is 0.40.

SLE (Single Loss Expectancy) is the dollar cost of one event:

SLE = AV x EF
SLE = $200,000 x 0.40 = $80,000

ARO (Annualized Rate of Occurrence) is how many times per year you expect the event. This is the one that bites people. "Twice a year" is 2. "Once every four years" is not 4. It is 1 divided by 4, which is 0.25.

ALE (Annualized Loss Expectancy) is what you expect to lose per year:

ALE = SLE x ARO
ALE = $80,000 x 0.25 = $20,000

That $20,000 is the number a security program actually budgets against. It answers "how much is this risk costing us per year, on average."

Where the points actually leak

Inverting ARO. When the question says "once every five years," the rate is 0.2, not 5. Read the sentence twice. If the event is rare, ARO is a fraction. If it happens several times a year, ARO is a whole number bigger than one.

Stopping at SLE. A question gives you AV, EF, and a frequency, then asks for annual loss. If you answer with SLE you answered a different question. Annual means you multiply by ARO. Every time.

EF as a percent vs a decimal. Forty percent is 0.40 in the formula. Plugging in 40 inflates your SLE by a factor of one hundred, and the answer will not match any option, which is at least a useful signal that you slipped.

The cost-benefit trap. The exam loves to follow the math with a proposed control that costs some amount per year, then ask whether it is worth deploying. The rule is simple: if the annual cost of the control is less than the reduction in ALE, it is justified. If a control costs $25,000 per year but only drops your ALE from $20,000 to $12,000, you spent $25,000 to save $8,000. That is a bad trade, and the question wants you to say so.

A second pass, because repetition is the point

A warehouse is valued at $1,000,000. A fire would destroy an estimated 25 percent of it. Records suggest a fire of that size every ten years. Find the ALE.

EF  = 0.25
SLE = $1,000,000 x 0.25 = $250,000
ARO = 1 / 10 = 0.1
ALE = $250,000 x 0.1 = $25,000

If you got $250,000 you forgot to annualize. If you got $2,500,000 you multiplied by 10 instead of 0.1. Both are the exact mistakes the distractor answers are built from.

How this shows up on test day

SY0-701 puts this in the risk management material (Domain 5), and it can appear as a straight calculation or buried inside a performance-based question where you have to pick the justified control. You will not get a calculator surprise: the numbers are usually clean once you set ARO correctly. The skill being tested is whether you can read a sentence, assign each number to the right letter, and not stop one step early.

The fastest way to make this automatic is to grind a handful of these with different phrasings until the "once every N years means 1/N" move is reflex. Mixed practice beats re-reading the formula sheet, because the formula was never the hard part.

If you want to see where you actually stand on this and the rest of the objectives, there is a free diagnostic at secplusmastery.com/diagnostic that maps your weak spots to specific domains, and the question bank on secplusmastery.com has plenty of these risk problems with worked solutions if you want to drill them.

One last sanity check you can carry into the exam: ALE is a per-year number, and it should be smaller than SLE unless the event happens more than once a year. If your ALE comes out larger than your SLE and the event is rare, you inverted ARO. Catch that and you have caught the single most common mistake on this topic.

you can run my soc triage tool without an api key, and that was kind of the point

TiltedLunar123 — Sun, 14 Jun 2026 17:52:51 +0000

i've been building a thing called triagelens. you give it security logs, it finds the suspicious stuff, maps it to mitre att&ck, scores the whole run 0-100, and writes a short analyst-style report. but the feature i keep coming back to isn't a detection. it's that you can run the entire thing with no api key, no account, and no config file. sounds small. it took me two wrong turns to get there.

here's what kicked it off. i showed an early build to a friend who's also grinding through security certs. i said "just clone it and run it, it's easy." about twenty minutes later he texts me asking where the api key goes. there was a .env step. the readme mentioned it somewhere near the bottom. by the time he found it he'd already lost interest. the tool worked. the first thirty seconds of using it didn't, and that's the part that decides whether anyone sticks around.

that annoyed me more than a real bug would have. the detections were the part i actually cared about, and nobody was getting far enough to see them because setup ate the curiosity first.

so i changed what happens by default. there are three ways to run the report-writing layer now, and the one that loads first needs nothing:

demo: rule-based text, no key, no network call. this is the default.
ollama: a model running locally, so the logs never leave your machine.
claude: cloud, writes the nicest summaries, needs a key.

you pick the provider in the ui and it saves to localStorage. no editing files. i went back and forth on that because storing config in the browser feels a little hacky, but the alternative was making every new person stop and edit a dotfile before they'd seen the tool do anything, and i'd just watched that kill it once.

the ai doesn't decide anything

quick architecture note, because it's the reason a no-key provider can even exist. the model never picks the findings. parsing, the detection rules, the att&ck mapping, the scoring, all of that is plain typescript with no model involved. same logs in, same findings out, every run. the provider only writes the prose at the end from findings that already exist. swap demo for ollama for claude and the findings and severities don't move, only the wording does.

so the default "demo" provider just templates the existing findings into readable text and skips the api entirely. the ai is an upgrade to the writing, not the thing doing the work.

a rule is just a function

the rules live in one file as pure functions. each looks at the parsed events and returns evidence strings, empty array if it didn't fire. here's roughly the encoded-powershell one:

{
  id: 'encoded-powershell',
  title: 'PowerShell launched with an encoded command',
  severity: 'high',
  techniques: techniques('T1059.001', 'T1027'),
  detect: (events) =>
    events
      .filter(
        (e) =>
          /powershell(\.exe)?/i.test(e.process ?? '') &&
          /\s-e(nc(odedcommand)?)?\b/i.test(e.commandLine ?? ''),
      )
      .map((e) => `encoded powershell on ${e.host}: ${e.commandLine}`),
}

nothing clever. -enc (or -e, or -encodedcommand) on a powershell process line is the tell, mapped to T1059.001 and T1027. because it's a plain function i can unit test it with five fake events and know it fires on exactly the case i want and stays quiet otherwise. no prompt tuning, no "please return valid json."

right now there are seven of these: encoded powershell, office spawning a child process (the classic malicious-doc chain), living-off-the-land binaries, execution out of a temp directory, windows log clearing, ssh brute force, and a successful login right after a brute-force burst. small list. it catches the obvious stuff and misses plenty.

why local actually matters

the ollama option isn't just a checkbox. the logs you'd most want to triage are exactly the ones you would not paste into some random cloud model. real auth logs, internal hostnames, usernames. with ollama the whole pipeline runs on your machine and nothing ships anywhere. for a learning tool that's a nice-to-have. for the actual job it's the difference between something you could use and something compliance would never let near a real log.

what's still rough

the honest list. it only reads evtx if you've already exported it to json, there's no native binary .evtx parser yet, so that export is an annoying manual hop. seven rules is not a lot. it is not a siem and i'm not pretending it is, it doesn't replace tuned detection content or a person deciding what actually matters. and the risk score is a weighted sum i tuned by hand on a handful of samples, so treat the exact number as a vibe, not gospel.

next on the list is sigma import, so nobody's stuck writing detections in my format, plus ioc extraction and exportable reports.

you can try it in the browser with the demo provider, no signup, sample log already loaded: triagelens.netlify.app
source: https://github.com/TiltedLunar123/triagelens

built with react, typescript, vite, and vitest for the rule tests. it works. not perfect but it works. if you write detections, tell me which of my seven rules is the weakest. that's the feedback i want most.

If you can decode it, it was never encryption: untangling encoding, hashing, and encryption for Security+

TiltedLunar123 — Sun, 14 Jun 2026 16:36:38 +0000

Three words show up constantly on the SY0-701 exam and in real security work, and they get blended together more than almost anything else: encoding, hashing, and encryption. All three turn readable data into something that looks scrambled, so people treat them as interchangeable. The exam writes questions specifically to catch you doing that.

Here is the clean mental model that finally fixed it for me.

Encoding is for compatibility, not secrecy

Encoding changes the format of data so a system can store or transport it safely. Base64, URL encoding, and ASCII are encoding schemes. There is no key. Anyone who knows the scheme can reverse it instantly, and that is the entire point.

If a question shows Base64 and an answer choice says "the data is protected," that choice is wrong. Base64 is reversible by design. Attackers use it to slip payloads past simple filters, not to hide anything from someone competent. When a phishing attachment contains a Base64 blob, decoding it is step one of analysis, not a wall.

Rule of thumb: no key, and the goal is "make this readable by another system," means encoding.

Hashing is one-way, and that is the whole feature

Hashing runs data through a function like SHA-256 and produces a fixed-length digest. You cannot reverse it back to the original. The same input always gives the same output, and changing the input by even one character produces a completely different digest.

That one-way property is why hashing protects integrity, not confidentiality. You hash a downloaded file and compare it against the published value to confirm nothing changed in transit. You store password hashes so a database breach does not hand over plaintext passwords.

Two traps the exam loves here:

Hashing is not encryption. There is no key and no decryption step. If an answer says "decrypt the hash," it is wrong.
Hashes need salt. A salt is random data added before hashing so two users with the same password get different digests. Without salt, attackers lean on precomputed rainbow tables. If a question describes identical hashes for identical passwords, the missing control is salting.

Encryption is the only one built for confidentiality

Encryption uses a key to transform data, and the correct key transforms it back. That reversible-with-a-key behavior is what makes it real protection. An attacker can know the algorithm and still get nowhere without the key.

Inside encryption, the split that trips people up is symmetric versus asymmetric:

Symmetric (AES) uses one shared key for both directions. It is fast, so it does the heavy lifting on bulk data. The hard part is sharing that key safely.
Asymmetric (RSA, ECC) uses a public key and a private key. Anyone can encrypt to your public key, but only your private key decrypts. It solves key exchange but is slow.

Real systems use both. TLS uses asymmetric encryption to exchange a symmetric session key, then switches to symmetric for the actual data transfer. If you can explain that one sentence, you have already answered a surprising number of exam questions.

A 10-second sorting test

When a question describes data being transformed, ask two things:

Is there a key? No key points to encoding or hashing. A key points to encryption.
Can it be reversed? Reversible with no key is encoding. Not reversible is hashing. Reversible with a key is encryption.

That two-question filter resolves most of the crypto items in Domain 1 without memorizing every algorithm on the objectives.

Where people actually lose the points

It is rarely the definitions. It is the application questions, like "A developer stores user passwords using AES. What is the problem?" The trap is that AES is a strong algorithm, so the answer feels correct. But passwords should be salted and hashed, not encrypted, because the system never needs to recover the original password, only verify it. Encrypting passwords means one stolen key exposes every account at once.

You only catch that kind of distinction by working application-style questions, not by flipping flashcards. I built SecPlus Mastery (https://secplusmastery.com) partly because I kept missing these until I drilled enough of them to see the pattern. If you want to find your own crypto gaps quickly, the free diagnostic at https://secplusmastery.com/diagnostic will surface them in a few minutes.

Get these three straight and a whole cluster of Domain 1 and Domain 3 questions stops being guesswork. Encoding for compatibility, hashing for integrity, encryption for confidentiality. Key or no key, reversible or not. That is the entire map.