Helpdesk to cybersecurity engineer: a 6-7 year update
Posted by ThePr0phet_@reddit | sysadmin | View on Reddit | 15 comments
My past post: https://www.reddit.com/r/sysadmin/s/drhMqvlhGo
Below is a long post on my cybersecurity career so far and what I’ve learned since posting my first threads here some years ago. Sorry for the length, but it may help someone!
About 6/7 (haha) years ago I posted here about starting out in helpdesk. Two years later I posted again, still in a sysadmin-ish role, climbing the ladder. Well, the ladder kept going. I'm now a cybersecurity engineer with a few years of experience across a lot of different environments. Here's an update for anyone getting into the field or trying to move up.
I went full security about 4-5 years ago. I started as a security analyst after 3-4 years in general IT, and since then I've worked across MSSP ("SOC as a service"), healthcare, a startup, retail, food/restaurant, entertainment, and sports. I've touched most of the major tools along the way: EDR (CrowdStrike, Defender, SentinelOne, Cylance), WAFs, PAM (BeyondTrust, CyberArk), "zero trust" (ZScaler, Cisco), SIEM in every flavor (on-prem, cloud, managed, unmanaged), and MDR/XDR. Plenty of GRC too, with audits both internal and external, across SOC 2, HIPAA, ISO 27001, GDPR, CCPA, and SOX.
How to actually transition into security
This is the question I get asked most, so let's start here. It usually takes a few years in general IT first, and that's not wasted time. Those years are where you learn the basics and, more importantly, where you learn what the point of IT even is and what it is you'll eventually be securing. Security is very technical, so your foundation matters a lot.
You don't need to be an expert at everything. What you need is to understand the tools, people, and processes behind most orgs. That means the corporate network, endpoints, websites (usually built by devs, but IT manages the infrastructure and security manages the security stack), identities and users and OAuth, and vendors. If you understand how those pieces fit together, you understand what you're protecting.
To break in, you usually start as an analyst. If you can, make your way into an MSSP for a stretch. The client-facing part can be a headache, but you learn a ton of both people skills and technical skills, and you get exposed to way more than you would in a single in-house environment. The pay is good too, often $125,000+.
One skill that's worth more than people realize: learning to simplify technical things into executive-friendly language. What is needed, what does it cost, how long does it take, what resources does it require. The people who can translate between the technical and the business side move up the fastest.
Here's what else actually stuck.
Most companies run a "one-man SOC." One analyst or engineer holds the program together, usually with an MDR or managed service bolted on for after-hours coverage. That's not a failure state. It's the norm at most orgs.
Every product promises the same thing. Fancy dashboards, alerts, solid detection and response. What you actually get comes down to budget, which stays low right up until the company eats a serious incident and suddenly takes security seriously. The exception is leadership that's already been through one. Those people are worth their weight in gold.
Your stack is only as good as three things: the log sources you feed it, the experience of the team running it, and the hours spent tuning it. Once you hit a decent maturity level, you lean harder on SOAR (playbooks, SOPs, automation) because that's what keeps the program running and keeps you ready for incidents.
Incidents happen more than people think. The good news is that most should die at the single-user or single-device level, usually phishing or the occasional malware install. That means your stack needs to contain both identity and endpoint incidents fast. Occasionally you draw an advanced actor abusing some tiny misconfig, or very rarely a zero day. The attack surface is the same as always, so good hygiene (patch and vulnerability management) is what stands between you and ransomware on every endpoint.
And let's be clear about where the incidents come from: most of them start with phishing. Probably half or more. You can push out as much training as you want, but users are never going to be as focused on learning security as you are, and that's just reality. What does help is making your phishing training and campaigns as realistic as possible. The closer they mirror what attackers actually send, the more your users actually learn and the more cautious they get.
Every environment is different, but the attack surface isn't. It's always user, device, websites, code. Documentation is rare unless you're at an MSP/MSSP, so you baseline the environment for a few months and build intuition for what's normal. Alert severity also varies by vendor. The same event can be "Critical" in one product and "Informational" in another, which is exactly why knowing your environment beats trusting the dashboard.
Learn to build a SIEM. Nearly every product generates alerts from logs, so understanding how that works under the hood puts you ahead of people who only click through alerts. And keep your hygiene tight: patch often, scan often, daily if you can. Nessus on-prem is the cheapest solid option (not affiliated).
Learn detection engineering too. It's symbiotic with SIEM work and best learned alongside it. It's also genuinely one of the more fun parts of the job and a seriously valuable skill to have. Writing detections that actually catch real behavior, then tuning them so they fire on the right things and stay quiet on the rest, is the kind of work that makes you better at everything else in security. It's the difference between reacting to whatever a tool hands you and actually shaping what your program can see.
Experience lets you see through the marketing. Plenty of vendors spend more on the pitch than the product, then charge 3-5x for the same thing a competitor offers. Time in the trenches is your BS detector.
On AI, since you knew it was coming. I've used Claude, ChatGPT, and Copilot Enterprise, and Claude and ChatGPT lead. In security it's genuinely useful for triage, investigation, and SOAR. Can it replace pen testing? I don't think so. The tools themselves are built on human logic, and pen testing is a deep craft full of very smart people. AI helps, but it's being overhyped because private equity is convinced it'll print trillions.
On pen testing: most companies outsource it annually or so. It's standard practice, stress-tests your tools, and exposes your gaps. It's also genuinely fun from the defender's chair. You get cat-and-mouse with talented people, a rare look at real-world TTPs, and a great excuse to write new detections.
A note on titles and career moves. Most execs can't tell a security engineer from an analyst from a red teamer, which is why nearly every in-house role gets labeled "security analyst." MSP/MSSPs are usually better about real leveling. If you can swing it, do a tour at an MSSP or MDR provider at least once. You get to see how an entire enterprise SOC is built, with analysts, engineers, incident responders, and red teamers all coming together, and you learn to build one from scratch. That's a huge advantage walking into an in-house role.
Where security is now: mostly the same. EDR + SIEM + MDR + WAF. Vendors are cramming AI into everything, but right now it's little more than SOAR facilitation with a shinier label. Know how to build a SOC and you can hit the same results for far less, because AI burns through money fast.
Where it's going: AI gets baked into more products, but the fundamentals won't change much. Pen testing might get faster, but not easier. It'll lower the barrier so less-skilled people can launch attacks, though that's really just script kiddies with a new toy, same as ever. The field will keep growing because the scale of attacks keeps growing, and some companies will start replacing entry-level roles with AI's SOAR capabilities. Still a great field to be in.
TL;DR: helpdesk → sysadmin → analyst → engineer. Tools change, marketing lies, hygiene saves you, and the one-man SOC is far more common than anyone admits. Get a few years of IT under your belt first, build a SIEM, learn detection engineering, do a tour at an MSSP if you can. AI is a useful intern, not your replacement.
I only have a Security+ cert with a lot of hands on engineering experience. Aiming for CISSP soon.
TL;DR: 7ish year update on old posts I made on this subreddit talking about my life and career progress. I started in help desk and now a cybersecurity engineer with a good salary. It’s a fun field to be in if you really enjoy cybersecurity. It will burn you out fast if you don’t enjoy it.
There’s a lot to cover, but I hope this gives valuable context and insight to someone.
BCIT_Richard@reddit
I can't imagine wanting to be in Cybersecurity in the birth of the AI age, thought it's not all doom and gloom, it's pretty bleak.
https://www.bleepingcomputer.com/news/security/glassworm-botnet-disrupted-after-resilient-c2-infrastructure-takedown/
when I first read about this c2c setup, I couldn't think of a good way to fight it, was impressed to see this happen.
Frothyleet@reddit
It's interesting you say this, because my experience interacting with cybersec folks is that this is absolutely not the case for many roles, which are really closer to bureaucratic / compliance-focused positions.
E.g., the security analysts might highlight "hey we see these CVEs on the vulnerability dashboard!", but they'd bounce remediation (and investigation to see whether it's a real issue) over to the infrastructure or networking or dev team.
AddendumWorking9756@reddit
The signal not skill line is what most readers will miss. Anyone using this thread as a roadmap should run actual investigations on CyberDefenders alongside the IT-first sequence, otherwise the certs feel hollow when they pivot.
ThePr0phet_@reddit (OP)
I agree, good point. Certs do not equal skill.
A good team will recognize this and ask the right questions during interviews to see if you know what you’re talking about.
A bad team will filter you out because you don’t have 10 certs. Stay away from those. This is a red flag and usually points to leadership not knowing what security is. I know a lot of people that don’t have certs and are red teaming. Some get one cert and never renew because it helps them land an entry role. I’ve ran into people with a CISSP that don’t know vulnerability scanning is a core feature of a security program/or don’t know how to scan at all.
At the end of the day, your skills and resume speak for themselves!
coukou76@reddit
SOC definitly zoning out of core IT, I dont know what these jobs will become once everything is automated regarding analysis, détection and remediation.
Despite working for a fortune 10 company most of our SOC is helpdesk without any core system knowledge, they simply don't understand what they are reporting. What is the job in SOC past the warning triages for CVE? Because to me cyber is a IT lite department
ThePr0phet_@reddit (OP)
I don't think it'll be much different, because most orgs will still run the "one-man SOC" approach. If anything, it just adds an "AI" line to most job descriptions so people are at least familiar with what it is.
On the SOC skill gap, I've seen that too, and it comes down to the hard skill cutoffs in a strict SOC. An analyst typically doesn't do an engineer's or incident responder's job, so they rarely get exposure to those skills. The only way to develop is to take it on yourself by reading through tickets to see how everything came together, but that's tough when alerts are pouring in. You end up putting out fires instead of learning.
The heaviest impact will land on big SOCs and MSSPs, where entry-level and triage roles get automated. In-house teams will stay about the same, in my opinion.
OriginalMeet7987@reddit
Good job and good luck in future.
I'm in a point where I'm thinking about a change to SoC also. After years of learning and implementing from scratch mdm solutions (Soti Mobicontrol and MS Intune), uem, gpo management for Windows clients, managing printer fleet, EPM implementation (Beyond Trust), a part of me wants to go in the cybersecurity direction :)
ThePr0phet_@reddit (OP)
You should do it — you have a solid foundation for it! I would apply to roles that don’t fall too far from your experience.
Look for something that adds a few things you don’t have extensive experience in, so that you can add more security skills to your resume and make it easier to move up. For example, managing EDR/Antivirus 🙌
T_Thriller_T@reddit
This is great.
I haven't read it all yet, but this is very interesting even when not at your path, great format, and wonderfully condensed which I have to admire because I'm shit at it.
And it's good to know that my coarse expression that most companies run a SOC with 2"ish" folks seems to not be wrong!
(Any mistakes are a gratuity of a tired brain and may be kept or left)
ThePr0phet_@reddit (OP)
Yea unfortunately big security teams are rare unless you have a good leadership team that’s able to fight for it.
Even then, it’s hard to justify a big team due to the capabilities security tools have nowadays. Usually only heavy regulated industries or very profitable ones have big teams.
The good thing is you get a lot of experience out of it because of how much you’re in charge of in small SOCs
j1mmyava1on@reddit
Bro this is the exact path I want to take. I firmly believe that the best cybersecurity professionals come from a sysadmin/network engineering background (sys admin is blue team coded - network engineering is red team coded I don’t make the rules) and the path from help desk to sys admin to sec engineer is what I want to do.
Currently in L1 help desk trying to climb the ladder like you did. I’m saving this post so I can make one of my own in a couple of years.
ThePr0phet_@reddit (OP)
Yup, most security ppl come from the same background. The only ones I’ve seen that go directly into security right away are those that are very skilled in red teaming. Usually folks that have years of research experience and self taught or come from prestigious universities.
You can do it!
One thing I forgot to mention: Make sure every job you take has a skill that you don’t have yet. Think of it like Pokémon — your objective is to gain as much skills as possible for your resume. Every job I took wasn’t just because of money, it was also because it had responsibilities that helped me add skills to my resume.
One BIG skill to look for in job descriptions is managing EDR/Antivirus and also patching endpoints.
Those two skills can help you land an entry role in security because it’s part of the foundation and many orgs assign these duties to entry level roles. Managing EDR/antivirus also is a gateway into SIEM because you will have to review alerts
Comfortable-Site8626@reddit
what did the jump from sysadmin to security analyst actually look like in practice?what did the jump from sysadmin to security analyst actually look like in practice?
ThePr0phet_@reddit (OP)
In practice, you basically start handling security specific tools only, reviewing alerts, and reviewing the architecture’s configuration and deployment instead of actually deploying it. Deploying the tools, updating them, ensuring your assets are all covered by them (e.g. making sure your EDR is deployed on every endpoint upon provisioning).
For example, if a new resource is deployed, is it following your security standards? If it’s a website, is it behind a WAF? Did they deploy using an up to date/patched image? Has the resource been added to your vulnerability scan schedule? Did you scan before deploying? Did they test in staging and was it reviewed prior to production?
There can be a lot of ghost assets that your team doesn’t know were deployed, so a good amount of your job is to hunt for unmanaged assets. For example, developer teams often deploy stuff without notifying you — custom alerts and discovery scans can help catch this.
This can be automated by having templates and policies (e.g. Azure Policy) to prevent people from creating resources that don’t follow your security guidelines. You can also use infrastructure as code (Terraform, Cloud Formation) to automate deployment. However, a lot of orgs put this on the back burner and end up doing manual deployments all the time.
Aside from that, you are now in charge of monitoring alerts from your SIEM and security products 24/7/365. If you are a one man SOC, this is why it’s important to have SOAR capabilities — if you’re on PTO, it can help triage stuff.
Your MDR provider may not be reliable all the time.
A lot of info, but hope that helps
alinfrk@reddit
Good job and good luck in future.
I'm in a point where I'm thinking about a change to SoC also. After years of learning and implementing from scratch mdm solutions (Soti Mobicontrol and MS Intune), uem, gpo management for Windows clients, managing printer fleet, EPM implementation (Beyond Trust), a part of me wants to go in the cybersecurity direction :)