10 blue team interview questions and answers

A blue team protects an organisation: it keeps logging in place, writes and tunes detections, investigates alerts, and helps contain and recover from incidents. A red team plays an authorised attacker to test whether those defences actually work. The two goals meet in the middle: red team findings should turn into better blue team detections. In an interview, show you understand that defence is continuous work across the detect, respond and recover functions, not a single tool you switch on.

Worked example: In a home lab, run a harmless authorised test such as creating a new local admin account, then confirm whether your logging recorded it and how long it took you to notice.

1. Define the defender's goal.
2. Contrast it with authorised attack testing.
3. Explain how findings feed back into detections.

Common mistake: Describing the blue team as only 'watching a SIEM screen' ignores tuning, hardening and recovery work.

Follow-up: Name one red team finding that should lead to a new detection.

• NIST Cybersecurity Framework 2.0Final · February 2024
• MITRE ATT&CK version historyv19.2 shown at review; living knowledge base

ATT&CK is a shared catalogue of attacker techniques. A blue team uses it to describe what an alert might represent, to check which techniques current detections cover, and to plan which gaps to close first. It is a vocabulary and a planning map, not a checklist that proves you are safe. A good answer picks one technique, names the data source that would show it, and admits that coverage depends on logging actually being turned on and tested.

Worked example: Pick the technique for scheduled task creation, list which Windows events or endpoint records would show it, and test in your lab whether they appear.

1. Choose one technique.
2. Name the data source.
3. Check that the data really arrives.
4. Write or review the detection.

Common mistake: Claiming '100% ATT&CK coverage' sounds impressive but no real team can evidence it.

Follow-up: Which data source would you need before you could detect that technique?

• MITRE ATT&CK version historyv19.2 shown at review; living knowledge base

First confirm whether any of the alerts were real, because tuning away a true attack is worse than noise. Group the alerts by user, host, process and source to see what drives the volume. If one approved business activity explains most of it, propose a narrow exception with an owner and a review date, rather than disabling the rule. Record the change, measure the alert volume afterwards, and keep a sample of the excluded events so the decision can be checked later.

Worked example: In a lab SIEM, generate repeated harmless logins from a backup service account, then write an exclusion scoped only to that account and host, and show the remaining alerts still fire.

1. Check for true positives.
2. Group by the fields that drive volume.
3. Propose a narrow, owned exception.
4. Measure and record the change.

Common mistake: Turning the whole rule off to stop the noise removes the detection for everyone.

Follow-up: Who should approve an exception, and when should it be reviewed?

• NIST SP 800-61 Rev. 3: Incident ResponseFinal · April 2025; supersedes Rev. 2

Read what the alert claims and which evidence triggered it. Confirm the basic facts: the user, the host, the time and time zone, and whether the activity is still happening. Add context, such as whether the account is privileged or the system is business critical. Decide whether it is a likely false positive, needs more investigation, or should be escalated now. Write down what you checked and what you could not see, so the next person does not repeat the work. Act only within the actions your role is allowed to take.

Worked example: Take a synthetic 'suspicious PowerShell' alert from a lab and write a five-line triage note: claim, evidence checked, context, decision, open questions.

1. Read the claim and trigger.
2. Confirm user, host and time.
3. Add business context.
4. Decide and document.

Common mistake: Closing an alert as 'false positive' without recording what was checked leaves no trail for review.

Follow-up: What would make you escalate immediately instead of investigating further?

• NIST SP 800-61 Rev. 3: Incident ResponseFinal · April 2025; supersedes Rev. 2

Process creation records are the starting point. On Windows, event 4688 records a new process when the audit policy is enabled, and command-line details appear only when that extra setting is on. Look at the parent process, the account, the command line and the time, and compare them with normal activity for that host. Endpoint tools may give richer records. Always say what depends on configuration: if auditing was off, the absence of an event proves nothing.

Worked example: In your lab, enable process creation auditing, start Notepad from a command prompt, and find the matching 4688 event with its parent process.

1. Confirm auditing is enabled.
2. Find the process creation record.
3. Check parent, account and command line.
4. Compare with normal behaviour.

Common mistake: Assuming an event ID will always exist ignores audit policy settings that may switch it off.

Follow-up: Which parent-child process pair would worry you on an office laptop?

• Microsoft Windows: event 4688Audit policy and field availability matter

Treat it as a question, not a verdict. Check the sign-in log for the user, application, result, multi-factor details, device and IP information. Travel, VPNs and mobile networks often explain unusual locations. Look at what happened after the sign-in: new mailbox rules, permission changes or large downloads matter more than the location alone. If the evidence points to compromise, escalate with what you found, and only revoke sessions or reset access if your role allows it.

Worked example: Sign in to a lab tenant through a VPN, then read the sign-in record and explain which fields show it was you.

1. Read the full sign-in record.
2. Look for innocent explanations.
3. Review activity after sign-in.
4. Escalate with evidence.

Common mistake: Blocking the account immediately on location alone can lock out a travelling employee and miss the real signal.

Follow-up: Which activity after sign-in would raise your concern most?

• Microsoft Entra sign-in logsLiving vendor documentation

A good note lets someone else understand and continue your work without asking you. It states the alert, the time window with time zone, the evidence you looked at with where it came from, what you concluded and how confident you are, what you could not see, and what you recommend next. It separates facts from guesses. Short and specific beats long and vague. Interviewers ask this because clear notes are a daily part of blue team work.

Worked example: Rewrite a vague note such as 'looked suspicious, escalated' into a version that names the log source, the time and the reason for escalation.

1. State the alert and window.
2. List evidence and sources.
3. Give a conclusion and confidence.
4. Name gaps and next steps.

Common mistake: Writing opinions like 'definitely malware' without the evidence that supports them.

Follow-up: How do you show your confidence level in a note?

• NIST SP 800-61 Rev. 3: Incident ResponseFinal · April 2025; supersedes Rev. 2

Incident response is how a team prepares for, handles and learns from security incidents. Current NIST guidance links it to the wider cybersecurity framework: govern, identify, protect, detect, respond and recover. In practice that means having plans and contacts ready, spotting and confirming incidents, limiting the damage, removing the cause, restoring normal service, and then improving so it is less likely to happen again. A junior analyst mostly helps with detection, evidence and clear handovers.

Worked example: Write a one-page lab plan for a phishing incident: who you tell, what evidence you keep, and how you confirm recovery.

1. Prepare.
2. Detect and confirm.
3. Contain and remove the cause.
4. Recover and improve.

Common mistake: Reciting an old list of phases without explaining what you would personally do in each.

Follow-up: What is your role as an L1 analyst during an active incident?

• NIST Cybersecurity Framework 2.0Final · February 2024
• NIST SP 800-61 Rev. 3: Incident ResponseFinal · April 2025; supersedes Rev. 2

Thank the user, because fast reporting helps. Collect the email and its headers, and ask what they clicked or entered. Check whether others received the same message and whether anyone signed in or ran something afterwards. If credentials may have been entered, follow the approved process for resetting them and reviewing sessions. Block or remove the message only through approved tools. Record the timeline, and escalate if there is evidence of account misuse or malware.

Worked example: Use a synthetic phishing sample in a lab mailbox and practise extracting the sender, links and delivery time without opening the links.

1. Collect the email and headers.
2. Find other recipients.
3. Check for sign-ins or execution.
4. Follow approved containment.

Common mistake: Blaming the user discourages future reporting, which is the team's earliest warning.

Follow-up: How would you find out if other employees received the same email?

• NIST SP 800-61 Rev. 3: Incident ResponseFinal · April 2025; supersedes Rev. 2

Some organisations in India must report certain cyber incidents to CERT-In within the time set in its directions, and data protection rules may add duties when personal data is involved. Whether a specific incident must be reported depends on the organisation, the incident type and legal advice. A junior analyst does not decide this alone. The right answer is to preserve evidence and accurate timestamps, and to escalate quickly so the people responsible can decide in time.

Worked example: Read the CERT-In directions and list which details a reporting team would need from your investigation notes.

1. Preserve evidence and time.
2. Escalate quickly.
3. Let the responsible owner decide on reporting.

Common mistake: Quoting a reporting deadline as if it applies to every company without checking applicability.

Follow-up: Which details from your notes would the reporting team need first?

• CERT-In Directions under IT Act section 70B28 April 2022 · applicability must be assessed
• MeitY: data protection legislation and notificationsAct 2023 / Rules 2025; phased commencement