A Day in Life of Security Analyst

Posted on February 10, 2025  •  4 minutes  • 737 words

As I continue to mentor new people that want to get into cybersecurity, there is one common question that I get which is, “What do you do everyday?” I have gottten this question so many times that I decided to write a blog post about it.

The role I have on my team is a incident responder. On paper, my role is to respond to any type of digital threat that happens on any digital asset that the company has. Incident responders are alerted to threats in different types of ways, but usually, the threat that my team and I respond to is through the alerts that our tools gives us, or through emails that come to my team. My role is to figure out the root cause of the alert, and figure out whether the alert is a true threat, and if it is to remediate the threat, or if it is not a true threat, figure out why the alert was generated, and if possible, figure out a way to stop the alert from generating again.

The first thing to do when I log in, is to figure out what alerts need immediate attention. What alerts needs to be worked first comes from experience, knowing the environment, and the maturity of the team. There are alerts everyday that are generated by people in the company, but most of the time, I try to pick up an alert that I have not seen before so I can learn something new.

I also try to mentor the more junior people on my team by writing playbooks on how to work certain alerts. These playbooks take time to write because instructions have to be clear so that anyone can do independently.

Depending on the day, I also try to write tooling to make my job easier, or to find gaps our ecosystem that exist. I also spend some time learning about new technologies and see how threat actors can exploit it.

One of the things that I like about my job is that there are no two days that are the same and I get to learn new things everyday.

Job Updates

As my team has begun to mature, I’ve found myself taking on more SIEM engineering responsibilities in addition to incident response. This includes identifying which logs we need to ingest, determining which alerts can be automatically closed through Microsoft Defender automations, and evaluating the overall fidelity of the alerts being sent to the incident response team.

One of the most challenging aspects of detection engineering is determining whether a rule remains relevant after it has been written. As a detection rule author, I need to assess whether historical rule logic is firing as expected and whether it still aligns with the threats the incident response team actually cares about. Because our team does not have a dedicated detection engineering function, alert fidelity becomes even more critical.

In general, high-fidelity alerts share a few key characteristics.

1. Clear rule names with actionable context.

Based on the rule name alone, an incident response analyst should understand what behavior is being detected and what they should be looking for during an investigation. The rule should clearly convey what it is detecting, where the intelligence comes from, and provide enough context to guide analysis within the environment.

For example, earlier in my security career, I encountered a rule that fired on a Sliver payload. I downloaded the host artifacts and simply searched for the string “Sliver.” A more senior analyst later explained what Sliver actually is and why my analysis was incomplete. That experience highlighted how important clear detection context is for both effective investigations and for helping analysts grow their understanding of threats.

2. Reliance on Static Indicators

Unless a detection is intentionally built around very specific, newly observed indicators or short-lived IOCs, effective detection logic should be broad enough to identify anomalous behavior even as attackers change tools or techniques. Indicators such as IP addresses and file hashes are trivial for attackers to change (unless you are using a TLSH hash), and detections that rely heavily on them can be easily bypassed. When this happens, defenders risk missing malicious activity entirely once the indicator becomes stale.

For this reason, static indicators should generally be used as supporting context or enrichment, rather than serving as the primary signal for a detection. Behavioral logic provides far more durable coverage against evolving threats.