The Making of a Security Analyst

The Making of a Security Analyst

The Making of a Security Analyst

Sanket's Story at Hackstack Security

From monitoring alerts to owning the portfolio — a complete account of how one analyst learned everything.

Before the First Login

Every security analyst remembers their first dashboard.

Not because it was impressive. Because it was overwhelming. Hundreds of alerts, dozens of columns, numbers refreshing every thirty seconds, and somewhere in all of that noise — the instruction: watch it, and tell us if something looks wrong.

Sanket arrived at Hackstack Security in April 2024 with a Master's degree in Cybersecurity from Laurentian University, a G.P.A of 9.10, certifications in Security+ and I.S.C.2 C.C, and approximately zero experience knowing what 'something looks wrong' actually looked like in production.

He had studied threats in classrooms. He had built encryption applications in labs. He had read nist C.S.F until the framework lived in his memory like a song.

None of it prepared him for the specific feeling of staring at a real seem dashboard for the first time and understanding — with the particular clarity of a person who has just realized how much they don't know — that theory and practice are different countries.

This is the story of how he learned to live in the second one.

Part One

The Dashboard

Chapter 1 — The First Week

hackstack Security, Remote — April 2024, Week 1

Hackstack Security was a small but serious operation — a managed security services provider serving clients across Canada. When Sanket joined, the team was lean: a senior analyst named Priya who had been there four years, a detection engineer named Jordan who wrote rules and didn't talk much, and a Director named Reza who had the specific kind of calm that comes from having seen every possible security incident at least twice.

Sanket's onboarding instructions were delivered in a single email from Reza on his first morning:

Reza: "Welcome. Your job this week: log into the seem, learn the dashboard, read every alert that came in this month, and write me a summary of what you see. Don't touch anything. Don't change anything. Just read."

The seem was Splunk. Sanket had studied Splunk in his master's program. He had run queries in a sandboxed environment. He had passed the theory.

He logged in. The production environment was different from the sandbox the way a hospital is different from a diagram of a hospital.

There were sixty-two active alerts in the last 24 hours. He opened the first one.

Alert Id 4471 — Medium Severity — Failed Login Attempts

The alert had fired at 3:47 am. The details: 23 failed authentication attempts against a client's V.P.N gateway from a single I.P address, followed by silence.

Sanket read it three times. He wrote in his notebook: 'Could be a brute force attempt. Could be a user who forgot their password and gave up. Could be an automated scan. How do I know which one?'

He didn't know. He kept reading.

By end of day one he had read fourteen alerts. He had understood maybe half of them well enough to describe what had happened. The other half had left him with more questions than the alert itself contained.

He wrote his questions down. All of them. Every gap in his understanding became a question in his notebook. By Friday he had forty-one questions.

On Friday afternoon he sent Reza his week-one summary. At the bottom he attached the list of forty-one questions.

Reza replied in six minutes:

Reza: "Good questions. Better than your summary. Come to the team call Monday — bring the list."

[ The first skill Sanket learned at Hackstack was not technical. It was epistemic — knowing the difference between what he understood and what he only thought he understood. The forty-one questions were more valuable than any answer he could have fabricated. In security, an analyst who knows what they don't know is safer than one who doesn't. ]

Chapter 2 — Learning to Read Alerts

Month 1 — the Alert Triage Education

Priya took Sanket through the alert taxonomy on his second Monday. She pulled up a week of alerts on her screen and walked through each category.

Priya: "Every alert falls into one of four buckets. True positive — real threat, real action needed. False positive — rule fired, no threat. True negative — nothing happened, nothing fired, correct. False negative — something happened, nothing fired, this is the dangerous one. Your job is to correctly identify which bucket every alert belongs to. Getting it wrong in either direction has consequences."

Sanket: "What's the consequence of calling a false positive a true positive?"

Priya: "You waste time and resources on something that isn't a threat. Annoying but survivable. What's the consequence of calling a true positive a false positive?"

Sanket thought.

Sanket: "You miss a real attack."

Priya: "Now you understand why we're cautious about suppressing alerts."

Alert Triage The process of determining whether a security alert represents a genuine threat (true positive) or a benign event that triggered a detection rule (false positive). Good triage requires: understanding the rule that fired and what behavior it's designed to detect, contextual knowledge of the asset or user involved, correlation with other events in the same timeframe, and threat intelligence to assess whether the pattern matches known attacker behavior. Triage speed matters — but accuracy matters more.

Sanket spent his first month doing nothing but triage. Every morning: open Splunk, work through the overnight alert queue, classify each alert, document the reasoning. Every afternoon: Priya reviewed his classifications and corrected the ones he got wrong.

Week one: he misclassified 34% of alerts.

Week two: 21%.

Week three: 12%.

Week four: 8%.

By the end of month one he had read and classified over eight hundred alerts. He had been wrong on sixty-four of them. He remembered most of the sixty-four more clearly than the ones he got right. Getting something wrong in a way that could have mattered had a way of engraving itself.

The First False Negative

It happened in week three. An alert fired for a single failed login on a client's M.3.6.5 environment. Sanket classified it as a false positive — one failed login, probably a user mistyping their password. He moved on.

Two hours later, Priya flagged him.

Priya: "That M.3.6.5 alert you closed — look at it again. This time look at the context window. What happened in the two hours before that alert?"

Sanket looked. In the two hours before the single failed login, there had been forty-seven successful logins from a completely different I.P range. Same account. Different country.

The failed login wasn't a mistyped password. It was an attacker who had already been in the account for two hours, changed the password, and locked the legitimate user out. The failed login was the legitimate user trying to get back in.

Sanket sat with that for a moment.

Sanket: "I only looked at the alert in isolation. I didn't look at what came before it."

Priya: "An alert is never just an alert. It's a moment in a story. Your job is to read the story, not just the sentence."

[Context is the difference between a false positive and a missed attack. A single event means almost nothing. The same event in the context of what happened before and after it can mean everything. Sanket learned to always expand the time window — never evaluate an alert in isolation.]

Part Two

The First Real Threat

Chapter 3 — The D.DoS That Wasn't

Month 2 — First Independent Investigation

It was a Tuesday morning in his second month. Sanket was working through the overnight queue when an alert caught his attention — not because of its severity rating, but because of the pattern.

A client's web-facing asset was showing a high frequency of connection attempts from a single I.P address. The alert was labelled medium severity. The pattern looked like the opening of a D.DoS attack — high-volume, repetitive, automated.

For the first time, Reza was not in the office. Priya was on a client call. Sanket was the only analyst looking at the queue.

He opened the alert. He pulled the I.P address. He did what Priya had taught him: expand the context, don't evaluate in isolation.

He ran the I.P through VirusTotal. Clean. No malicious reputation.

He ran it through Abuse I.P.D.B. Clean.

He pulled the I.P's whois registration. It was registered to Microsoft Corporation.

He paused. A Microsoft I.P generating D.DoS-like traffic against a client asset. That was not an attacker pattern. That was a service pattern.

He dug deeper. He cross-referenced the I.P range against Microsoft's published service I.P ranges. It fell in the range assigned to Microsoft Defender's security scanning service — a built-in function that periodically sends probe requests to verify asset availability and endpoint responsiveness.

False positive. But Sanket did not close the alert.

He documented everything first: the I.P, the whois, the Microsoft I.P range confirmation, the Defender scanning service identification. He wrote a one-paragraph summary explaining exactly what had happened and why it was not malicious. Then he added the I.P range to the seem's whitelist with a specific label: 'Microsoft Defender Security Scanning Service — confirmed non-malicious, verified [date].'

Then he updated the S.O.C runbook: if alerts fire from this I.P range in future, analysts should check the label before investigating. This pattern has been confirmed as benign.

He sent the documentation to Priya and Reza.

Reza replied that evening:

Reza: "Good work. You found it, you verified it, you documented it, you prevented it from happening again. That's the full cycle. Most junior analysts stop at finding it."

[The difference between a good analyst and an average one is not finding the answer. It is doing something useful with the answer. Closing an alert is the minimum. Documenting the investigation, updating the runbook, and preventing the same false positive from consuming future analyst time — that is the work that compounds over time.]

False Positive Management When an alert is confirmed as a false positive, the work is not done. The analyst should: document the investigation trail with evidence, add the known good indicator to the seem whitelist with a specific descriptive label and date, update the S.O.C runbook so other analysts recognize the pattern, and consider whether the underlying rule needs tuning to reduce future noise. An undocumented false positive is one that will be investigated again next week by a different analyst.

Chapter 4 — The First seem Rule

Month 3 — Detection Engineering Begins

Jordan the detection engineer had been watching Sanket from a careful distance for two months. He said very little. He wrote rules. He tuned rules. He deleted rules that weren't working and built new ones. He communicated primarily through Splunk queries.

In Sanket's third month, Jordan appeared on a Teams call with one sentence:

Jordan: "You want to learn how to write a rule?"

Sanket: "Yes."

Jordan: "Then tell me: what is the purpose of a detection rule?"

Sanket thought about the question carefully before answering.

Sanket: "To identify a specific behavior in the log data that indicates a threat or a policy violation."

Jordan: "Close. The purpose of a detection rule is to find a specific behavior while generating as few false positives as possible. The best rule in the world is useless if the S.O.C ignores it because it fires constantly on benign activity. You're not just writing a query. You're writing a signal that someone has to act on. Make it worth acting on."

Jordan shared his screen. He opened a blank Splunk search window.

Jordan: "We're going to write a rule for privileged account authentication outside business hours. Start with the policy. What does the policy say?"

Sanket: "Privileged accounts should only authenticate interactively during business hours — 7 am to 7 pm weekdays."

Jordan: "Good. Now — what does a violation of that policy look like in the logs?" Sanket thought through it methodically.

Sanket: "An authentication event — Windows Event Id 4624 — from an account that is in our privileged account list — during a timestamp that falls outside 7 am to 7 pm on a weekday."

Jordan: "Build it."

Sanket typed his first detection rule:

Jordan looked at it. He said nothing for fifteen seconds.

Jordan: "Run it. See what fires."

Sanket ran it against the last seven days. Forty-three results.

Sanket: "That seems high."

Jordan: "It is high. Why?"

Sanket looked through the results. Most of them were the same three accounts — service accounts running scheduled tasks that fired at 2 am every night. Not attackers. Automation.

Sanket: "Service accounts. Scheduled tasks. They run at night on a fixed schedule."

Jordan: "So what do you do?"

Sanket: "Exclude them. Add a filter for accounts with 'svc' in the name — our service account naming convention. Or better — exclude specific accounts that are known to run overnight tasks, with a documented reason for each exclusion."

Jordan: "Better is correct. Never exclude by pattern if you can exclude by name. A pattern can be spoofed. A specific named exclusion is auditable. Do it."

Sanket added the exclusions with documented reasons. Forty-three results became four. He reviewed the four: two were legitimate I.T staff who had worked late. One was a test account that had been left active. One was unfamiliar.

The unfamiliar one became his first genuine escalation.

seem Rule Tuning Writing a detection rule is step one. Tuning it is the ongoing work. After a rule is deployed, monitor false positive rate for the first week. Any account, service, or system that fires the rule repeatedly and is confirmed benign should be explicitly excluded with a documented reason — not suppressed by broad pattern. Track the false positive rate as a metric: a rule generating more than 15 to 20% false positives needs tuning before analysts lose trust in it and stop acting on its alerts.

Part Three

Expanding the Portfolio

Chapter 5 — The Risk Register

Month 4 — G.R.C Work Begins

Reza called Sanket into a one-on-one in his fourth month.

Reza: "You've been doing good work on alert triage and you've started learning detection. I want to expand your scope. Have you done G.R.C work before?"

Sanket: "Governance, Risk, and Compliance. I studied it in my master's and did some work at Infopercept — risk registers, I.S.O 27001 compliance documentation."

Reza: "We have a client — a mid-sized financial services firm in Ottawa — who needs their risk register rebuilt from scratch. The current one is a spreadsheet with fifteen rows, half of them outdated. I want you to own this. Not assist. Own it."

This was the first time Reza had used the word 'own' with Sanket. He felt the weight of it.

Sanket: "What does that mean specifically?"

Reza: "It means when the client's auditor asks about risk management, you're the person who answers. It means when a new risk is identified, you're the person who documents it. It means when a risk is closed, you verify the closure evidence. It means this register reflects your judgment about what is and isn't a risk in their environment."

Sanket built the risk register over three weeks. He started by doing something that turned out to be the most important step: he read the client's existing security policies, system inventory, and the last two years of their incident logs before he wrote a single row.

[A risk register built without reading the organization's history is a list of generic security concerns, not an assessment of actual risk. Before documenting what might go wrong, you have to understand what has gone wrong, what is currently weak, and what the organization actually cares about protecting.]

What he found in the incident logs: three phishing incidents in 18 months, all successful. Two access control violations were terminated employees had active accounts for more than 30 days post-termination. One failed backup restoration during a D.R test.

He built the register around those real findings first. Then he added the framework-required items. Then he mapped everything to nist C.S.F subcategories.

The finished register had 38 entries. Every entry had a named owner — not a team, a person. Every entry had a target date. Every high and critical risk had a remediation plan with specific steps.

The client's auditor reviewed it four weeks later. She said it was the most complete risk register she had seen from an organization of their size.

Reza forwarded Sanket the email without comment. He didn't need to say anything.

Risk Register Best Practice A risk register entry must answer six questions: What is the risk? What asset or process does it affect? How likely is it to occur and how severe would the impact be? What controls currently exist? What is the residual risk after controls? Who is responsible for managing it — named person, not team. Without a named owner, the risk will never be remediated because everyone assumes someone else is handling it.

Chapter 6 — Vulnerability Management

Month 5 — the nessus Education

Vulnerability management at Hackstack was Priya's domain. She had been running scan cycles for four years. In Sanket's fifth month she invited him in.

Priya: "We have a new client onboarding next week. I want you to run their initial vulnerability assessment. I'll be watching but you're driving."

The scan was straightforward. Sanket configured Nessus, ran an authenticated scan across the client's environment — 47 endpoints, 3 servers, 2 network devices — and waited.

The results came back: 312 findings.

Sanket: "Three hundred and twelve vulnerabilities."

Priya: "How many are critical?"

Sanket: "Fourteen."

Priya: "How many of those fourteen actually matter?"

Sanket looked at her.

Priya: "C.V.S.S score is not risk. C.V.S.S score is theoretical severity. Real risk is C.V.S.S plus exploitability plus asset criticality. Walk me through the fourteen."

Sanket pulled up the first critical finding. C.V.S.S 9.8. A remote code execution vulnerability in an Apache web server.

Sanket: "This one is on a web server. Internet-facing. C.V.S.S 9.8. There's a public exploit in Metasploit. This is actually critical."

Priya: "Next."

Sanket: "C.V.S.S 9.6. Same vulnerability class but this one is on an internal test server. Not internet-facing. No external access. The C.V.S.S is the same but the real risk is much lower — an attacker would need to already be inside the network to exploit it."

Priya: "So what's the actual priority order?"

Sanket spent an hour going through all fourteen. By the end he had a real priority list: three genuinely critical that needed patching within 72 hours, five high that needed action within 30 days, six that could wait for the regular patch cycle.

Priya: "That's the output the client needs. Not 312 findings. Not fourteen criticals. Three things that need to happen this week, five things that need to happen this month. Simple, actionable, honest."

Vulnerability Prioritization Raw vulnerability scan output is noise. Turning it into signal requires applying three filters: C.V.S.S base score (theoretical severity), exploitability (is there a public exploit? is it on C.I.S.A's Known Exploited Vulnerabilities list?), and asset criticality (is this an internet-facing system? does it handle sensitive data?). A C.V.S.S 9.8 on an air-gapped internal test server is lower priority than a C.V.S.S 7.0 on an internet-facing system with a public exploit and no patch applied.

Chapter 7 — The Client Onboarding

Month 6 — Building from Scratch

Six months in, Reza gave Sanket his most significant assignment yet: onboard a new client end-to-end. Not assist. Not support. Build their security monitoring program from the ground up.

The client was a small healthcare technology company — 80 employees, two office locations, a cloud-first infrastructure built on Microsoft 365 and Azure. They had never had a formal security program. They had never had a seem. They had been breached once, eighteen months ago, and had hired Hackstack as a result.

Reza: "You have four weeks. At the end of four weeks they should have a functioning seem with detection rules, a risk register, a vulnerability management baseline, and a security awareness program in motion. Questions?"

Sanket: "Who do I escalate to if I get stuck?"

Reza: "Me. But try not to get stuck."

Sanket started the way he always started now: with reading. He spent the first three days reviewing their existing documentation, interviewing their I.T manager, and mapping their environment. Before he configured a single tool, he knew exactly what they had, what they were most afraid of, and what their regulatory obligations were.

Week 1 — The Environment Map

The client's environment: Microsoft 365 Business Premium, Azure A.D, no on-premises infrastructure, 80 endpoints running Windows 11, one SharePoint environment containing customer data, and a customer-facing web application hosted in Azure.

Their breach eighteen months ago: a phishing email had compromised an executive's email account. The attacker had accessed the account for 11 days before detection. During that time they had read 340 emails and forwarded 23 to an external address. No financial loss, but significant reputational damage.

Sanket made a list of what that breach told him about their environment: email forwarding rule monitoring did not exist. Privileged account authentication monitoring did not exist. The phishing click rate was unknown. The awareness program did not exist.

He started with the breach. Always start with what already happened.

Week 2 — seem Configuration

The client's M.3.6.5 Business Premium licence included Microsoft Sentinel access. Sanket configured it in four days.

Day one: Connect data sources. Microsoft 365 audit logs, Azure A.D sign-in logs, Microsoft Defender for Endpoint telemetry, Azure activity logs. Four connectors. All active by end of day.

Day two: Build the foundational detection rules. He started with the five rules that would have caught their breach: email forwarding rule to external domain, successful login after multiple failures, login from a new country, privileged role assignment outside business hours, bulk email deletion.

Day three: Tune. He ran each rule against 30 days of historical data to identify false positive patterns before the rules went live. He found three service accounts that would have fired the privileged role assignment rule — documented and excluded.

Day four: Test. He worked with the client's I.T manager to confirm each rule fired correctly on a synthetic test event. All five confirmed.

He wrote up the detection logic for each rule in plain English for the client's I.T manager — not S.P.L, not technical documentation. Plain English. 'This rule fires when an email forwarding rule is created that sends emails to an address outside your company. This is one of the first things an attacker does after compromising an account.'

Week 3 — Risk Register and Vulnerability Baseline

The risk register for this client had 22 entries by the time Sanket finished. He identified seven risks that had not been on any of their previous documentation: the absence of M.F.A on three legacy applications, an admin account shared between two employees, a vulnerability in their Azure web application that had been unpatched for four months, and four vendor relationships with no security documentation.

The vulnerability scan found 89 findings across their environment. After applying his prioritization framework — C.V.S.S plus exploitability plus asset criticality — the actionable list was 11 items. Three critical. Eight high. He presented those 11 to the client's leadership with plain-language descriptions and specific remediation steps.

The critical finding that mattered most: the Azure web application was running a version of a component library with a known remote code execution vulnerability C.V.E-2024 to 1071). The C.V.S.S was 8.8. There was a public exploit. The application was internet-facing and handled customer data. Sanket's priority rating: Critical. Patch within 72 hours.

The client patched it within 48 hours.

Week 4 — Security Awareness

The awareness program was the piece Sanket was most personally invested in. He had read the research. He knew that phishing was the initial access vector in most breaches and that awareness programs reduced click rates — but only if they were designed correctly.

He enrolled all 80 staff in the NoBeFour platform. He ran a baseline phishing simulation — a fake I.T helpdesk notification — before any training was delivered. He wanted the honest number: how many people would click before they knew the program existed?

The result: 31 out of 80. 39% click rate.

He scheduled monthly simulations with templates specifically chosen to match the threats facing their industry — tech startup workers receive specific types of phishing.

He designed the training modules to be under five minutes. He configured just-in-time training to trigger immediately when someone clicked a simulation link.

The second simulation, run four weeks after training began: 18% click rate. A reduction of more than half in one month.

He reported this to Reza with the methodology. Reza forwarded it to the client. The client asked Hackstack to present the awareness program results at their next board meeting.

Sanket prepared a four-slide deck. It was the first time he had presented security metrics to a board. His hands shook slightly before he started. By the second slide they had stopped.

Security Awareness Program Baseline Before running any training or simulation, establish a baseline click rate through an unannounced simulation. This gives you the honest starting point against which all future improvement is measured. Without a baseline, you cannot demonstrate program effectiveness. The baseline simulation should use a template calibrated to the organization's actual threat model — not a generic bank phishing template. Measure three things over time: click rate (going down), report rate (going up), and training completion rate (staying high).

Part Four

The Full Portfolio

Chapter 8 — Access Controls and the Terminated Employee

Month 7 — the Access Review Cycle

Access reviews were a quarterly ritual at Hackstack for all managed clients. Sanket ran his first solo access review in month seven for the financial services client whose risk register he had built.

The process: export all active accounts from Azure A.D, cross-reference against the current employee list from H.R, flag any account that belongs to a terminated employee, any account with elevated privileges that can't be justified to a current job function, and any service account with no documented owner.

He ran the export. He began the comparison.

Twenty minutes in the found it: an account with Global Administrator rights in Azure A.D. The account belonged to someone named Marcus Okonkwo. He cross-referenced with the H.R list.

Marcus Okonkwo had resigned four months ago.

A former employee with Global Administrator rights had been sitting in the client's Azure A.D for four months. Global Administrator meant: full access to all Microsoft 365 services, all Azure resources, all user accounts, all email. The most privileged account in the environment.

Sanket escalated immediately.

Sanket: "Reza — access review finding. Former employee account with Global Admin rights, active for four months post-termination. Need to understand if this account has been accessed since their resignation."

He pulled the Azure A.D sign-in logs for the account. No sign-ins in four months. The account had been dormant.

Dormant but not gone. An attacker who found this account through credential stuffing or a dark web leak would have had unrestricted access to the entire M.3.6.5 environment.

The account was disabled within the hour. Sanket documented the finding in the risk register, added it to the client's incident log as a near-miss, and wrote a corrective action: implement automated offboarding integration between H.R system and Azure A.D so that account deprovisioning happens within 24 hours of termination, not never.

Reza: "Good catch. If that account had been discovered and used, the client's entire M.3.6.5 environment would have been owned. Write up the offboarding gap as a policy recommendation."

Sanket wrote the recommendation. The client implemented the automated offboarding integration within three weeks.

Privileged Account Lifecycle Every privileged account must have three things: a named human owner, a documented business justification, and a review date. When an employee is terminated, their account — especially any privileged accounts — must be disabled immediately. Automated deprovisioning via skim integration between the H.R system and identity provider (Azure A.D/Entra Id) eliminates the human error gap. A Global Administrator account belonging to a former employee is one of the highest-risk configurations in any M.3.6.5 environment.

Chapter 9 — Data Loss Prevention

Month 8 — the D.L.P Configuration One of the financial services clients had a specific concern: employees were sending sensitive client financial data via personal email. It had happened twice in the past year — both times accidentally, both times caught by accident. They wanted a technical control, not just a policy.

Sanket owned the D.L.P implementation. He configured Microsoft Purview Data Loss Prevention policies across M.3.6.5 — Exchange Online, SharePoint, OneDrive, and Teams.

The policy logic: detect documents or emails containing patterns that match financial data — account numbers, S.I.N's, specific keyword combinations associated with their client reports — and apply the appropriate control based on destination. Internal sharing: allow, log. External sharing to known business partners: allow, log, notify. External sharing to unknown destinations: block, alert analyst, notify sender.

He tested the policy in simulation mode for two weeks before enforcement. In simulation mode it logged what would have been blocked without actually blocking it. He reviewed the simulation logs daily.

What he found: eleven instances in two weeks where sensitive data would have been blocked. Eight were legitimate business communications that needed to be whitelisted. Three were exactly the problem the client was trying to prevent — sensitive client financial data being sent to personal Gmail addresses.

He refined the policy to exclude the eight legitimate patterns. He showed the three concerning instances to the client's compliance officer. She was unsurprised and relieved that the policy would have caught them.

The policy went live in enforcement mode. In the first month: four blocks. All four were confirmed as policy violations. None were false positives.

[ D.L.P policy deployment without a simulation period is a significant operational risk. Policies that block legitimate business communications without warning erode trust in the security program and generate escalations that consume analyst time. Always simulate first, review the simulation logs carefully, refine, and then enforce. ]

Microsoft Purview D.L.P Data Loss Prevention in Microsoft Purview works by scanning content across M.3.6.5 services for sensitive information types — credit card numbers, S.I.N's, custom keyword dictionaries, document fingerprints — and applying policy actions: allow, block, encrypt, alert, or notify. Policies should be deployed in simulation mode first to identify false positive patterns before enforcement. The most common false positive sources: internal templates that contain field names resembling sensitive data, legitimate external partner communications, and automated systems that process sensitive data programmatically.

Chapter 10 — Incident Response Leadership

Month 9 — Running the Tabletop

Reza asked Sanket to design and facilitate a tabletop exercise for a healthcare technology client in month nine. It was the first time Sanket would be in the facilitator seat rather than the participant seat.

He chose the scenario: ransomware. It was the most realistic threat facing their client and the scenario most likely to reveal gaps in their response plan.

He built four inject cards:

Inject 1: Your incident response lead is on annual leave and unreachable. Who makes the decision to isolate the affected network segment?

Inject 2: The S.O.C has confirmed the ransomware has been running for two hours before detection. Your backup system is on the same network segment as the affected systems. Who makes the call to check backup integrity before isolating the segment?

Inject 3: A journalist calls the main office phone asking about a 'data breach at your company.' Who speaks to the media? What do they say?

Inject 4: The attacker sends a ransom demand. Who decides whether to pay? What is the policy?

The tabletop ran for ninety minutes. What Sanket found:

Gap 1: The incident response plan assumed the I.R lead would always be available. No backup decision-maker was named.

Gap 2: The backup system was on the same network segment as production — a single ransomware event could encrypt both. This had not been identified as a risk.

Gap 3: Three people in the room believed they were authorized to speak to the media. No defined media spokesperson.

Gap 4: No ransom payment policy existed. The question had never been discussed at the leadership level.

Sanket's after-action report documented all four gaps with specific corrective actions, owners, and target dates. The client's C.E.O, who had been present during the tabletop, personally signed off on the corrective action plan.

Reza: "Four real gaps found and documented. That's a successful tabletop. The goal was never to run a perfect response. The goal was to find what was missing before an attacker found it for you."

Tabletop Exercise Value The purpose of a tabletop is not to practice a perfect response — it is to discover gaps in the response plan before a real incident exposes them. The most valuable outcomes are not the answers participants get right but the moments where participants discover they assumed different things, or that a resource they counted on doesn't exist, or that a decision nobody has ever thought about needs to be made in the first five minutes of a real incident. The after-action report with corrective actions converts the tabletop from a meeting into a security improvement.

Part Five

The Full Analyst

Chapter 11 — One Year In

Month 12 — the Conversation with Reza

It was April 2025. One year since Sanket had logged into his first Splunk dashboard with forty-one questions and a theory-heavy education.

Reza called him for a one-on-one. He pulled up a document on his screen — Sanket could see it was a list of competencies.

Reza: "I want to do an honest assessment of where you've arrived. Tell me what you own right now — not your job title, what you actually own."

Sanket thought about it for a moment. Then he answered.

Sanket: "I own the full security portfolio for three managed clients independently. That means: their risk registers, which I maintain and update quarterly and after every incident. Their seem monitoring — I write the detection rules, tune them, and manage the S.O.C relationship for two of the three. Their vulnerability management cycle — I run the scans, prioritize the findings, track remediation, and report to their leadership. Their access control reviews — quarterly for privileged accounts, annual for all staff, with automated offboarding integrations I configured. Their D.L.P policies. Their security awareness programs — I run the simulations, track the click rates, deliver the training, report the metrics. Their incident response plans — I led tabletops for two of them and wrote the corrective action plans. And their compliance documentation — nist C.S.F assessments, I.S.O 27001 aligned risk documentation, management and auditor reports."

He paused.

Sanket: "When I started, I was reading alerts and trying to figure out which bucket they belonged in. Now I'm building the systems that generate the alerts, writing the rules that define what gets alerted on, managing the people who respond to the alerts, and reporting the outcomes to boards and auditors. The portfolio grew as my competence grew. I think that was intentional."

Reza: "It was. The question I had about you in month one was not whether you were smart. It was whether you were the kind of person who, when you didn't know something, would write it down as a question rather than pretend you knew it. You sent me forty-one questions in your first week. That told me everything I needed to know."

Chapter 12 — The IoT Vendor Assessment

Month 13 — the $80 Decision

One of Hackstack's clients operated in the healthcare technology space. They used a third-party IoT platform to manage connected devices deployed at client sites — sensors, monitoring equipment, alert systems.

As part of their vendor risk assessment program, Sanket was reviewing the security of this platform. He had the vendor's S.O.C 2 report. He had their security questionnaire. He had their A.P.I documentation.

What he didn't have was confidence that the A.P.I was actually as secure as the documentation claimed.

The documentation said all A.P.I communications were authenticated using H.M.A.C-S.H.A.2.5.6. The documentation said data was encrypted in transit using T.L.S 1.2. The documentation said the platform was independently pen-tested annually.

Sanket read the documentation. Then he did something that nobody had asked him to do: he ordered the device.

It cost $80. He bought it with his own money. He wasn't going to expense it without being sure it was worth expensing.

He received the device, paired it with the vendor platform, and built a lightweight monitoring tool using Cloudflare Workers to intercept and examine the A.P.I calls between the device and the vendor's cloud service.

What he found: the H.M.A.C-S.H.A.2.5.6 implementation was correct. The signature was computed from the client Id, access token, and Unix timestamp exactly as documented. T.L.S 1.2 was in use. The data in transit was encrypted.

But he also found something the documentation hadn't mentioned: the device polled the A.P.I every sixty seconds, and each poll transmitted the device's exact G.P.S coordinates alongside the sensor data. The vendor's privacy documentation made no mention of location data collection.

He documented the finding. He added it to the client's vendor risk register as a medium-risk item: undisclosed location data collection by a vendor with IoT devices deployed at client sites. He sent the finding to the vendor with a request for clarification on their data retention and use policy for location data.

The vendor responded within 48 hours acknowledging the gap in their documentation and providing a full data retention policy.

Reza: "You spent $80 of your own money to verify a vendor's security claims. Most analysts would have taken the S.O.C 2 report at face value and moved on. That is the difference between a good vendor risk assessment and a real one."

[ Vendor documentation describes intended security behavior. Vendor testing verifies actual security behavior. Where the budget and scope allow, technical validation of vendor security claims — especially for vendors with access to sensitive data or systems — is always preferable to documentation review alone. A S.O.C 2 report tells you a third party audited the vendor's controls at a point in time. It does not tell you the controls work correctly for your specific deployment.]

Chapter 13 — The Python Automation Tool

Month 14 — Building Something

The weekly security reporting cycle was consuming three hours of Sanket's time every Monday. He pulled metrics from three different systems — Splunk, Nessus, NoBeFour — formatted them into a consistent report structure, wrote the narrative summary, and emailed it to three clients and two internal stakeholders.

Every week. The same process. Three hours.

He automated it.

He built a Python script that connected to the A.P.I of each platform, pulled the week's key metrics, applied consistent formatting, generated the narrative summary using an A.I integration, and emailed the finished report to the distribution list.

The script ran every Monday at 6 am. The reports arrived in client inboxes before their working day started. Sanket spent fifteen minutes reviewing the output and making any necessary adjustments rather than three hours building it from scratch.

He reclaimed those hours for detection engineering and client work.

When he showed Reza the tool, Reza asked one question:

Reza: "What do you do if the A.P.I is down on Monday morning?"

Sanket: "The script has error handling for each A.P.I connection. If any single A.P.I fails, the script sends me an alert rather than generating a partial report. I review the failed source manually and either pull the data myself or flag the metric as unavailable in that week's report. I never send a report with a missing metric that looks complete — it's clearly marked."

Reza: "Good. The only thing worse than a manual process is an automated process that fails silently."

Security Automation Principle Automation should reduce manual effort while maintaining or improving output quality. The risk of automation is silent failure — a process that breaks without alerting anyone and either produces no output or produces incorrect output that nobody notices. Every automated security workflow should have: explicit error handling that alerts a human when the automation fails, output validation that checks the result before delivery, and a documented manual fallback for when the automation is unavailable. Automate to save time, not to remove human judgment from critical processes.

Epilogue

The Analyst Sanket Became

Fourteen months after his first login to a production seem, Sanket Sorathiya owned what he described in an interview as an end-to-end security portfolio.

That description was accurate. But it didn't capture the distance traveled.

He had started by monitoring dashboards and writing daily reports. He had learned to triage alerts correctly by being wrong on sixty-four of them and remembering each one. He had learned to write detection rules from a detection engineer who communicated primarily through Splunk queries. He had built risk registers from scratch and had a client auditor describe one as the best she had seen.

He had run vulnerability scans, prioritized findings by actual risk rather than C.V.S.S score, and watched a client patch a critical vulnerability in 48 hours because the recommendation was specific and credible. He had configured D.L.P policies in simulation mode, found the false positives before enforcement caused problems, and gone live with a policy that caught real violations.

He had facilitated a tabletop exercise and found four gaps in an incident response plan that no one had known were there. He had caught a terminated employee's Global Administrator account that had been active for four months. He had spent $80 of his own money to verify a vendor's A.P.I security and found an undisclosed location data collection practice.

He had built an automation tool that gave him three hours back every week and redirected that time into detection engineering.

None of these things happened because Sanket was exceptional. They happened because Sanket was consistent — consistently curious, consistently honest about what he didn't know, consistently willing to do the work that nobody had specifically assigned him because he could see it needed doing.

The forty-one questions he wrote in his first week were still in his notebook. He still had the notebook. He looked at the questions occasionally, not to remind himself how far he had come but to remind himself of the posture that had gotten him there: know what you don't know, write it down, and find the answer.

That posture had taken him from a monitor-and-report role to a full security portfolio in fourteen months.

It would take him further still.

End of The Making of a Security Analyst This is your story, Sanket. Own it on Monday.