Detection over dashboards
Every detection I write maps to a MITRE ATT&CK technique, gets tested against telemetry from my own lab, then gets tuned. A rule that fires on everything protects nothing.
IT Support Engineer moving into Security Operations
I build blue team environments in a home lab and learn them by breaking them. Most recently a full SOC stack, from the log pipeline through to a written investigation on every alert it raised. Four certifications earned, four lab projects finished, and a roadmap I am still working through in order.
Most security work fails quietly. Logs nobody reads, alerts nobody tunes, playbooks nobody tests. I work the other way around. Build the pipeline, write the detection, break it on purpose, then prove it catches what it was written for.
Every detection I write maps to a MITRE ATT&CK technique, gets tested against telemetry from my own lab, then gets tuned. A rule that fires on everything protects nothing.
I built the domain before I built the sensors. Users, groups, Group Policy, and audit logging came first, because you cannot detect abuse of a directory you have never set up yourself.
Enrichment, case creation, notification. If an analyst does it the same way twice it belongs in a workflow, and humans keep the judgement calls. This is the layer I am building right now.
Every project ships with a writeup covering what broke, what I fixed, and how I investigated. If I cannot explain the failure, I do not claim the skill.
Fundamentals first, then analyst level detection, then the SIEM platform, then cloud architecture and cloud security. Everything below is marked honestly. Earned means passed and verifiable on Credly. In progress means I am sitting it next.
A blue team environment assembled from nothing, in order. Lab, identity, telemetry, detection. Four are finished and documented. The last three are where I am working now, and they are labelled as such. All of it is a personal home lab, not production work, and I would rather say that here than have you find out in the interview.
Everything in this section comes from a project I finished or a certification I hold. What I am still learning is in its own block underneath, kept separate on purpose.
Writing, mapping, and tuning the logic that separates an incident from background noise. Learned by building the rules in my own lab and testing them against simulated attacks.
Triage, investigation, and the writeup that makes the next analyst faster. Practised end to end on a lab queue, and backed by CySA+ on the theory side.
Domain design, Group Policy, and the audit configuration that makes directory abuse visible in the first place.
Traffic flow, segmentation, and trust boundaries. The part that decides whether a compromised host can reach anything worth reaching.
Building, breaking, and rebuilding environments on demand. Every lab on this page was stood up and torn down more than once.
Using models deliberately as part of the workflow, with the output checked before it counts. Detailed in the panel below.
Listed separately because it has not earned a place above yet. This is the next stretch of the roadmap, in the order I am working through it.
I treat AI the way I treat every other tool in the stack. Deliberately, with my hand on the wheel, and with the output verified before it counts for anything. This entire site was designed and built with Claude, directed by me through iteration rather than a single lucky prompt.
The same workflow runs through my security work. Drafting and stress testing detection logic, turning raw investigation notes into a writeup somebody else can follow, and working through concepts faster than reading alone would allow. The skill is not typing a question into a box. It is knowing what to ask, what to throw away, and where the model is confidently wrong. Security teams that figure that out early move faster than the ones still arguing about whether to allow it.
A support and operations foundation, rebuilt deliberately toward security. The helpdesk years are not a detour. They are where the instinct for how systems actually break came from.
Competency based programme covering networking, systems administration, scripting, applied statistics, and IT project management. Accelerated with transfer credit.
Graduate work bridging technical security operations and the business side of risk. Governance, budgeting, and communicating security posture to people who do not read alert queues.
Front line troubleshooting across hardware, networking, and remote access. Daily practice at the thing security interviews actually test: isolating a fault from incomplete information, then explaining it to someone who is not technical.
End user support and device management at scale across a large public institution. Imaging, account administration, and connectivity issues across multiple sites.
Continuous build and break work on my own time. Every completed project on this site was designed, deployed, documented, and tuned by me.
Identity and telemetry get built and understood first. Nothing gets automated on top of a system I cannot explain.
Every project carries the failure, the fix, and the investigation path. The writeup is part of the build, not an afterthought.
Certifications and projects are sequenced on purpose. Nothing gets skipped because it looks slow or unglamorous.
In progress is labelled in progress. A portfolio that overstates itself falls apart in the first technical interview.
I am looking for my first security seat, and I have done the homework to be useful on day one rather than starting from zero. I have built the stack myself, written and tuned the detections, worked a queue end to end in the lab, and I bring a few years of real support experience with users, escalation, and troubleshooting under pressure. I am not going to tell you I have production SOC time, because I have not had the seat yet. What I will tell you is that I am the person who spends an evening figuring out why one rule fired twice, and then writes it up so nobody else has to.
Working toward Cloud Security Analyst and Security Operations Engineer as the Splunk and Azure certifications land.
Whether you are hiring, comparing notes on detection work, or just curious how something on this page was put together, I would genuinely like to hear from you.
No form, no autoresponder, no recruiter funnel. Just my inbox, and I read all of it.
sharpleynate@gmail.comI usually reply within a day
Thanks for scrolling all the way down here. If any of this was useful to you, that
already made it worth building.
Nate