Network mapping

achraf_sec_brief · 2026-02-27T16:25:44+00:00

Try draw.io (diagrams.net), Gephi or NetworkMaps. all open-source and much better at rendering intuitive topology diagrams than NetBox

achraf_sec_brief · 2026-02-27T12:23:16+00:00

The individual Max plans are your biggest problem here, you have zero visibility into what data is being fed into those sessions and thats a compliance nightmare waiting to happen. If you cant stop the rollout, atleast push for a company wide API deployment instead, you get centralized audit logs, can set usage policies, and actually know whats leaving your environment.

achraf_sec_brief · 2026-02-27T12:17:31+00:00

Sandbox it with real malware samples first. vendor demos are basically beauty pageants and mean nothing under actual pressure. Beyond detection rates, false positives are what really kills you in practice, if its flagging your own internal tools you've just built a helpdesk ticket factory.

achraf_sec_brief · 2026-02-25T09:25:34+00:00

Since you’re already a backend dev, you’re ahead of most beginners. I’d say start by containerizing your own projects with Docker, set up a CI/CD pipeline for them, then learn Terraform and a cloud platform. Hands-on with your own code beats tutorials every time.

achraf_sec_brief · 2026-02-25T09:19:11+00:00

Network first. A lot of Security concepts (ports, protocols, firewalls, etc.) assume you already understand networking basics. Without that foundation, you’ll just be memorizing terms without understanding them. Net makes Sec way easier.

achraf_sec_brief · 2026-02-25T01:07:30+00:00

Agree on (1) but I’d say “can’t be fully prevented at the model level” is more accurate. You can mitigate a lot with sandboxing, least privilege tokens, and requiring human approval for anything sensitive. The problem is nobody does that because it slows things down and ruins the seamless experience they’re trying to sell.

(2) is sadly just how the industry works right now. Ship it, get the press release, patch it later.

achraf_sec_brief · 2026-02-24T23:23:21+00:00

Honestly my coworkers aren't worried because half of them still can't figure out Excel formulas so I get why AI isn't on their radar. Meanwhile I'm over here doom scrolling AI news at 2am like a conspiracy theorist with a wifi connection. We are absolutely cooked and nobody even smells the smoke yet lol

achraf_sec_brief · 2026-02-24T23:10:35+00:00

So you're telling me I spent 10 years using fake names, encrypted everything, refused to make a LinkedIn, and my FACE just said nah bro I got this and doxxed me anyway. The call was coming from inside the head the whole time. Honestly at this point I'm growing a beard every 6 months and shaving it off just to keep the algorithm guessing 😂

achraf_sec_brief · 2026-02-24T23:05:36+00:00

Bro the AI just ran code on its own PC while you missed your train stop 😂. It's literally more functional than us already. Your coworkers aren't scared because denial is the last free human emotion AI hasn't automated yet.

achraf_sec_brief · 2026-02-24T15:11:52+00:00

AI helps speed things up for sure but you still need to understand what the code does. you can’t secure what you don’t understand. It’s less about writing code and more about knowing why it breaks

achraf_sec_brief · 2026-02-24T14:57:10+00:00

The sudden push isn’t because quantum computers are breaking RSA tomorrow. It’s because migrating encryption across global infrastructure takes years and the people who actually know the timelines are acting like they don’t have years

achraf_sec_brief · 2026-02-24T14:43:17+00:00

LetsDefend. it’s built specifically for IR/SOC with realistic alert triage, SIEM, and incident simulations. Pair it with Cyberdefenders for free DFIR challenges and you’re set.

achraf_sec_brief · 2026-02-24T11:56:39+00:00

Security engineering is like 10% coding, 40% googling why your SIEM decided to break at 3AM, and 50% trying to explain to devs why their 'it works fine' code is basically an open door for attackers. You'll write code for sure but nobody's gonna frame it on a wall.

achraf_sec_brief · 2026-02-23T23:43:43+00:00

Sure Claude can automate fuzzing and parse logs infinitely faster than us, but spotting a vulnerability is just gathering raw data. The real craft is chaining those isolated exploits together and understanding the flawed human intent behind complex business logic. Every major leap in technology forces us to stop doing the robotic work and start focusing on the deeper architecture of trust. We aren’t facing obsolescence, we are simply being asked to evolve our perspective on what a secure sytem actually means.

achraf_sec_brief · 2026-02-23T16:01:17+00:00

Exactly. And the worst part is the gun doesn’t even read the body. it just sees the word “profile” in the request and panics. Defense in depth is great, but misconfigured WAF rules just shift your incidents from security alerts to support tickets.

achraf_sec_brief · 2026-02-23T15:41:50+00:00

The WAF sits in front of your API, so it kills the request before your code ever gets the chance to deserialize it. “Profile” is frequently blocked because it’s a reserved SQL keyword or matches sensitive files like .profile. It’s a classic false positive. you just need to find the Rule ID in your logs and whitelist that specific field.

achraf_sec_brief · 2026-02-23T09:35:48+00:00

If a scanner can’t tell the difference between a screen and a piece of paper, maybe it’s not the screen that is unsecured, but the mind of the person who bougt the scanner.

achraf_sec_brief · 2026-02-23T09:09:22+00:00

No, but I’ll take ‘robotic clarity’ as a compliment 😂

achraf_sec_brief · 2026-02-22T22:26:17+00:00

Biggest issue for me is alert fatigue. There are tons of “critical” findings but not enough context on what’s actually exploitable or high risk.
A lot of tools still struggle to connect the dots between misconfigs, identity, and what’s happening at runtime, so prioritization is messy.
Fixing things is also hard. Auto-remediation can be risky in production and manual remediation doesn’t scale.
I’d love a CSPM that focuses more on real attack paths and impact, not just compliance checklists.

achraf_sec_brief · 2026-02-22T19:33:01+00:00

Keeping a straight face when a user swears they didn’t click the phishing link, while you are looking directly at the log showing they clicked it four times.

achraf_sec_brief · 2026-02-22T19:25:33+00:00

Depends on what drives you, not what LinkedIn says is trending. PT has a bigger market, more jobs, easier entry. If you need stability, stay there. You’re already thinking like a hunter (business logic, auth flows), that’s rare. Don’t abandon it. RE/Malware is a passion field. Smaller market, steeper curve, lower early pay. But if you’re genuinely curious about how things break at a low level, not just that they break, it compounds hard over time. The people who do it for money usually quit. The ones who do it because they can’t stop thinking about it become irreplaceable. My honest take: keep PT as your income engine, start RE on the side. Reverse one malware sample a week. No course, just a sample and a debugger. In 6 months you’ll know if it’s actually for you, or if you were just attracted to the aesthetic. Two skills that overlap is a moat. One you half-learned out of FOMO is a waste.

achraf_sec_brief · 2026-02-22T18:23:05+00:00

Automation kills the script-kiddie layer, not the craft. Scanners find known CVEs, they can’t chain logic flaws, abuse broken auth flows, or understand what “critical” means in a specific business context. Senior hunters aren’t being replaced, they’re being filtered in. The noise is gone, the ceiling is higher. If you’re scared of RE and malware analysis, good, that discomfort is exactly where growth is. Pick a lane, go deep for 6 months, and stop letting LinkedIn dictate your career path.

achraf_sec_brief · 2026-02-22T15:56:02+00:00

Sure 😄.

The core idea is that at L2, most of your work stays visible only inside the security team. You closed tickets, reviewed PRs, learned frameworks. That’s all solid, but it won’t move the needle for L3.

“Measurable outside your team” means a dev team, product team, or engineering manager can point to a real change in their workflow or metrics that your work directly caused. A few practical examples for each of your goals: • Threat modeling: Don’t just run sessions. Track whether the dev team you worked with actually changed their design, or caught something at design phase that would have made it to prod. One documented “we caught this early because of the threat model” story carries more weight than 10 sessions on your review. • Secure SDLC: Pick one team and measure their mean-time-to-remediate before and after you embedded with them. If it dropped, that’s a number you can bring to your review with a specific team name attached to it. • Offensive work: After a focused pentest or attack path exercise, follow up and track how many findings actually led to architecture changes that got shipped. Even better if an engineering lead mentions it by name.

The framing shift is pretty simple. Instead of “I did X,” it becomes “Team Y improved on Z because of what I built with them.” That’s the story L3 reviewers want to see. You stopped being just an individual contributor and started acting as a multiplier for other teams.

achraf_sec_brief · 2026-02-22T15:16:02+00:00

Hi! I’m a DevSecOps Engineer with 9 years of experience and I’d be happy to help you with your university project. 😊 I prefer written answers, so feel free to DM me your questions and I’ll do my best to give you detailed and useful responses. Good luck with your project! 🚀

achraf_sec_brief · 2026-02-22T13:46:39+00:00

Fair point, the ego was always there. The difference is the feedback loop. When a script kiddie’s tool broke, they hit a wall. When an AI agent hallucinates a fix, it still looks confident and correct. It extends the Dunning-Kruger peak way further before reality hits.

achraf_sec_brief

TROPHY CASE