How a security question becomes a decision

Monday morning. Several employees at a company we will call ACME receive an email titled Important Payroll Update. It asks them to click a link and sign in before noon or their pay will be delayed.

One of them reports it to the help desk. The security team confirms quickly that ACME did not send it. That part is easy.

Here is the part that is not easy. The security manager has to decide whether blocking the email is enough, or whether ACME also has to reset employee passwords and sign people out of their accounts. Those are very different mornings. One is a filter rule. The other is a disruption that reaches every person who got the message, and it needs a reason.

Nothing about that decision is answered by knowing the email is fake.

The mistake is starting with the attacker

The instinct at this point is to find out everything about the message. Who sent it. What infrastructure is behind the link. Whether the domain has been seen before, whether it matches a known campaign, what the malware does if there is any.

All of that is interesting. On Monday morning, almost none of it changes what the security manager does.

The manager is not deciding whether to write a report about a phishing campaign. The manager is deciding whether to reset passwords. So the useful question is not what is this attack. It is did it work.

Look at the whole situation before you write the question

Before an analyst writes down what needs to be known, it is worth taking a minute on the situation as a whole. In the book this runs under the shorthand MATATC, and for an incident like this one each element is a sentence:

• Mission. What has to succeed? Protect employee accounts and keep payroll running normally.
• Adversary. Who could interfere? Someone using a fake payroll email to collect employee passwords.
• Terrain. Where could this happen? Employee email, the fake website, ACME's sign-in services, and the accounts themselves.
• Assets. What can ACME use? Email records, web-filter logs, sign-in records, the help desk, and the security team.
• Time. When is an answer needed? Quickly. A stolen password gets used quickly.
• Customer. Who needs the answer? The security manager, who is the one who can order resets and sign-outs.

Six sentences, and the gap falls out of them on its own. ACME knows the email is fake. ACME does not know whether anybody gave away a password.

That gap is the whole problem. Everything else on the list, the team already knows or can reach.

Turn the gap into one question

A gap is not yet a requirement. A requirement is a question specific enough that someone can go and answer it, and consequential enough that the answer changes what happens next.

For ACME it comes out as: did any employee click the fake payroll link or enter an ACME password?

Notice what that question is not. It is not about the attacker, the campaign, or the infrastructure. It is about ACME's own people and ACME's own systems, which is also what makes it answerable within the hour. The team is not waiting on an external source to tell them something.

It is worth stating the trigger out loud as well, before anyone goes looking: one confirmed password submission, or a sign-in to an account after that account visited the fake site, means reset and sign out. Writing the threshold down in advance is what stops the finding being argued about once it arrives, when somebody is tired and the clock is running.

Three tests before you spend anyone's time

A requirement that survives these three is worth collecting against. One that fails any of them is a research project.

• Does the answer change a decision? Here, yes. It decides whether accounts get reset.
• Is it time sensitive? Yes. A stolen password is useful to whoever took it immediately.
• Can it actually be collected? Yes. Employee reports, email records, web-filter records and sign-in records are all in reach.

The first test is the one that quietly fails most often. Plenty of questions worth answering eventually are not worth answering now, and a requirement that no decision is waiting on is a requirement that will sit in a queue while something else burns.

Collect narrowly

With the question written, collection gets small. Four sources, each because it speaks to the question and not because it happened to be available: who reported opening or clicking, who received the message and whether the link was followed, which devices reached the fake site, and whether any affected account showed an unusual sign-in.

That is a deliberately short list. The temptation in an incident is to pull everything and sort it out afterwards, which is how an hour becomes a day.

The answer, and what it decides

Two employees clicked. One stopped when the site asked for a password. The other entered one, and the sign-in records show an unfamiliar sign-in to that account ten minutes later.

Now the decision makes itself, which is the point. Reset that employee's password, sign the account out of every session, review its recent activity, and block the fake site. Tell the employee who clicked but did not hand over a password what happened, and keep watching.

The team never did learn who was behind the email. It did not need to. It needed to know whether anyone had surrendered a password, and that is a different question with a much shorter answer.

What actually happened here

Read back, the sequence is plain enough. The mission came first, so protecting accounts and keeping payroll working set the terms. Looking at the situation as a whole exposed one gap that mattered. That gap became a focused question with a threshold attached. Collection went only where the question pointed. And the answer caused an action, which is the part that makes it intelligence rather than information.

That is the cycle: understand the problem, work out what has to be known, collect the answer, support the decision. It scales up to a quarterly strategic assessment and down to a Monday morning, and it is the same shape either way.

The version that does not work is the one that starts at collection and hopes a decision emerges from the pile.

Adapted from the Worked ACME Starter Example by Christopher G. Ruel and Ajay Menendez, authors of Cyber Threat Intelligence Planning: A Special Forces Approach. ACME is fictional.