Walk me through how you triage a security alert from the moment it lands in your queue.

Start by confirming what the detection actually fired on, then enrich before you judge. Pull the raw log, identify the host, user, process and network context, and check the asset criticality. Compare against known good behavior and recent change tickets. Decide true positive, false positive or benign true positive, document the reasoning, and either close with tuning feedback or escalate with a timeline.

First thing I do is read the rule logic, not just the alert title, because the title is often stale. Then I enrich: host, user, parent and child process, command line, destination IP and its reputation, and whether the user has a change ticket open. At my last place I had an alert for encoded PowerShell on a finance workstation. The command line decoded to a blob that turned out to be a legitimate vendor installer, but the parent process was Outlook, which is exactly the pattern I care about, so I did not close it there. I checked the mailbox, found the message came from a known supplier domain with a valid signature, and confirmed with the user by phone rather than email in case their account was owned. Benign true positive. I wrote it up, then sent the detection engineer a suggestion to exclude that specific vendor hash rather than the whole encoded PowerShell rule, which would have blinded us.