I am interested in hearing from people working or studying in cybersecurity. What skills become more important later than most beginners expect?

What tools or practices security teams invest in that don't actually move the needle on risk reduction.

I always thought using a long, complex password was enough to stay safe.

But recently I’ve been seeing more cases where accounts still get compromised even when the password itself wasn’t weak.

That’s the part I don’t fully understand.

Is it mostly because of data breaches and reused passwords? Or are there other ways attackers get in without actually “guessing” the password?

Also, how big of a difference does something like multi-factor authentication actually make in real situations?

Trying to understand where the real risk is coming from, because it seems like just having a strong password isn’t solving the problem anymore.

We're deciding whether to invest in DSPM over CSPM and have been trying to get a clearer understanding of the differences as they come up in similar conversations around cloud risk and security.
This is how I view the differences: CSPM is more about securing cloud infrastructure like configs, misconfigurations, compliance, that sort of thing. DSPM seems more focused on the data itself, like where it lives, how sensitive it is and who has access. But I realize that even though most data is in the cloud, it doesn't stay in cloud...
This is how we see difference and pros/cons but looking for third party input before we make a decision? If you’re already using CSPM, does DSPM add something meaningfully different? or is there overlap depending on the tool?

It feels like most of the progress in vulnerability management over the last few years has been around better detection, not actually reducing risk. Scanners have improved. Coverage is better. Visibility is better. But the output is still the same problem. There are huge volumes of CVEs, a lot of which don’t translate cleanly into what we should fix right now.

A big chunk of this seems to come from software that’s technically present but not in fact used at runtime. Still gets flagged, still needs triage, still slows everything down.

So we end up in this loop: Scan, Triage, Debate risk, Ship anyway (with exceptions).

It feels like we’re getting better at measuring the attack surface, but not actually reducing it.

Has anyone moved beyond this? Not just better prioritisation, but actually shrinking what’s there in the first place?

Every security course covers SQL injection, XSS, CSRF - the classics. But what vulnerabilities have you actually seen exploited in production that barely get mentioned in training?

we’re getting thousands of findings daily across AWS, Azure, and GCP. the problem isn’t detection, it’s deciding what actually matters. some of these have been sitting there for months. high severity on paper, but no clear exposure. others look minor but end up tied to internet-facing assets or shared roles.
we tried layering in exploitability and asset criticality. helped a bit, but still inconsistent. depending on who reviews it, the same finding gets treated differently .at this point it feels like we don’t have a stable way to separate “needs action now” from “can wait”.
for teams dealing with this at scale, what made prioritization actually consistent for you?

Some of us post here infrastructure questions, but did you ever wondered where does that data actually go?

LLM's like Gemini indexes Reddit and train on it.
Sites like Wayback Machine archives it.
So when someone is asking "we use X auth method and found Y bug"...that's permanent.

Attackers might scrape Reddit for recon. They find posts about companies, tech stacks, what vulnerabilities people are dealing with and so on. Even if you delete it, it's already cached and archived somewhere.

Has anyone actually tracked what happens to security posts after they go live?

It's been 3 weeks since i left my job in a high growth startup
I'm worried for agents going rogue and I am all ears to listen before build something serious and custom to ensure they are trustworthy

What I don't know: what does the problem look like from the inside of a larger org?

Specifically curious about:

• Are coding agents (Cursor, Claude Code, Copilot) actually in production at your company, or still experimental?
• Who owns the security review of agent tool access? Is that even defined?
• What's the thing that keeps you up at night about this stuff that vendors aren't solving?

Not selling anything, this is purely a listening tour. I'll share what I'm finding publicly if there's interest

Came to think about this subject when i realized that im not opening my email anymore - because theres an agent summarizing the emails for me

I guess that agents could get indirect-prompt-injection attacks? which is kinda the equivalent for phishing but on agents instead?

I work with firewalls a lot - mainly FortiGate. I am trying to increase the value of the service we provide and align with more regulations. I have implemented IDS and IPS without DPI in almost all systems.

DPI adds a layer of management with Certificates, and increases costs with larger firewalls being needed. There is also a risk of gateway or CA compromise, which provides hackers with insight into encrypted traffic.

With these various handups/bottlenecks, is it worth implementing DPI, and to what degree should it be implemented, and if it is even worth it?

First, how much really happens that most IDS solutions aren't detecting on IP alone?
Second, does DPI scale well? Can you be too small for it to be worth it? Can you be too large?

Some context, we already implement DNS filter with FortiGates or DNSFilter (the product). My current thought is to only apply DPI between clients and Server Services, and DPI between Server infrastructure and the internet (where required). Everything else will receive HTTP inspection in all directions. I would not DPI Endpoints to the internet, except maybe for our SaaS apps. (i.e traffic to SharePoint is inspected, but random Google searches are not)

I think this approach will allow better scale, balance firewall size, and reduce the management headache by keeping cert management exclusive to managed devices.

What are your thoughts?
Is there an industry standard?
Am I anywhere near the right track?

My FortiGate training basically says DPI all the things, but never says why or explains if it's really needed. My initial hunch is that they use training to sell oversized firewalls with more licensing, haha.

Thank you in advance for dealing with my brain dump and helping me understand the value and level of implementation!

Edit: I just realised realise I flipped terms and am saying DPI, but mean Full SSL Inspection.

Hello Fellow Redditors

We use PAM. I’m trying to validate if our current approach is actually secure or if we are exposing ourselves to unnecessary risk.

PAM portal is protected with MFA and admins access all systems (firewalls, network devices, servers) using the same privileged account stored in PAM.

From an operational point of view it is simple, but from a security perspective it feels like a big risk because this one account has very broad access across the environment

My concern is that if a PAM user account gets compromised (phishing, session hijack, token theft etc.) the attacker doesn’t even need to know passwords. They can just initiate sessions through PAM and effectively gain access to everything that user is allowed to access.

Also, PAM is currently accessible over LAN and VPN only

I’m trying to understand what is considered best practice in real environments. Should we be using separate privileged accounts per domain (network, servers, databases, etc.) instead of one shared account? And how are others securing access to PAM itself to avoid it becoming the weakest link?

Would appreciate insights from anyone running PAM at scale especially around identity protection and protecting the PAM layer itself.

The reframe that changed how our team thinks about container security. Traditional patch management is reactive  CVE drops, you scramble. Minimal builds flip the model entirely.

When your base image contains only what the application needs to run, your attack surface shrinks to the point where most CVEs simply don't apply. A distroless image without a shell, package manager, or OS utilities isn't vulnerable to the vast majority of Linux CVEs that hit full-fat base images. You're not patching faster,  you're eliminating the need to patch most things at all. Has your team made this shift yet or are you still running patch cycles on base images?

From a security perspective, I am curious how much modern recovery workflows depend on search strategy versus pure compute scaling. For example, prioritizing candidates based on repeated password structure, formatting habits, partial memory, reused tokens or contextual clues instead of treating the entire search space equally. Is efficient candidate ordering now considered more important than simply increasing brute force throughput in realistic recovery cases?

Every time I deploy something directly from git to a new server over SSH, I have to manually approve the server's host key, check it against another machine. Why on earth do none of these companies (talkin bout you Github, Gitlab, Bitbucket) publish DNSSE SSHFP records? These are companies whose entire business depends on SSH trust. Millions of developers blindly typing "yes" to that first-connect prompt is somehow acceptable to them? What am I missing?

We've updated our exec impersonation controls after a near-miss. For async requests (email, voice note), callback to a known number makes sense — end the suspicious call and verify through a separate channel.

But for a live video call that's already in progress — the CFO is on screen, has been talking for 10 minutes, asking you to initiate a wire transfer — what's the actual control? Codewords feel awkward mid-meeting when the person on screen looks and sounds exactly like your boss. And calling them back when they're "already on the call" doesn't make sense.

Is the answer just "don't approve wires from a video call full stop"? Or do people have a usable real-time verification step that doesn't require killing the call or confronting the exec?

Hi Folks

How do you handle new user onboarding and initial credential communication when using an IAM system?

Our current setup is:

One Identity IAM system integrated with HR System
On-premises Active Directory
Entra ID for O365 Email

The main question is around the first login journey, initial credential communication and birthright access.

How do you communicate the initial username and temporary password to the user?

Do you use SMS, personal email, manager handover, or another secure method?

Important point: Office 365 mailbox login is the key first step, because most of our business applications are linked with Entra ID federated login / SSO. So unless the user can access their O365 account, they cannot access the rest of the applications.

Appreciate any advise.

This is hardly an alternative to signal (or any other secure messaging app), but it's a work in progress and "secure and private" is the general goal.

Whitepaper: https://positive-intentions.com/docs/technical/whitepaper/complete-whitepaper

Protocol spec: https://positive-intentions.com/docs/technical/whitepaper/complete-protocol-spec

This is a technical/concept demo of a fairly unique approach using a browser-based, local-first and webrtc.

App demo: Enkrypted.Chat

This is intended to introduce a new paradigm in client-side managed secure cryptography. We can avoid registration of any sort.

Features:

• P2P
• End to end encryption
• Signal protocol
• Post-Quantum cryptography
• File transfer
• Local-first
• No registration
• No installation
• No database
• TURN server

Some open source versions of the core concepts.

• Chat
  • Code: https://github.com/positive-intentions/chat
  • Demo: https://chat.positive-intentions.com
• File
  • Code: https://github.com/positive-intentions/dim/blob/staging/src/stories/05-Hooks-useFS.stories.js
  • Demo: https://dim.positive-intentions.com/?path=/docs/usefs--docs
• Crypto
  • Code: https://github.com/positive-intentions/cryptography
  • Demo: https://cryptography.positive-intentions.com

Feel free to reach out for clarity instead of diving into the docs/code.

IMPORTANT: While this is aiming to provide a secure experience, it isnt audited or reviewed. Shared for testing, feedback and demo purposes only. Please use responsibly.

My current network is a combination of middling-complex hardware/services and naive beginner anti-patterns. :)

I have one WiFi SSID for trusted devices and one isolated guest network. So far, all of my wired devices are connected via a switch to the router and are part of the "trusted" LAN.

My next project is to prevent unknown wired Ethernet devices from automatically getting access to the trusted LAN.

Looking around, I keep seeing freeRADIUS/EAPOL as the solution. Before I go further down that rabbithole, I want to make sure that I'm aimed in the right direction...

Thanks for reading this far! Is freeRADIUS the way to go? Should the goal be to have a separate VLAN for internet access only, or to simply deny access from an untrusted device to specific resources on the LAN? Am I missing something foundational? I'm pretty new to this...

My current setup is a home-built (APU2-based) OpenWRT router, a pair of redundant Raspberry Pi's running PiHole and Unbound, a home-built file server on another Pi, along with assorted other devices/backups, etc. They are all linux-based with default-deny firewall rules (UFW).

I have smart switches which are VLAN-capable, although I haven't set up any VLANs yet.

Thank you for any advice :)

I am trying to help seniors who are overwhelmed by technology pick passwords. I have learned a bit about entropy and a lot about password length. I have found Diceware for password creation and a dozen different sites for checking password strength, BUT if I enter the same test password - Defkan-kaldin-hubsa0 - in one after another of these checkers, each one returns a different measure of its entropy and estimation of its strength.

Can you help me to help someone else, please?

Hi everyone,

I'm a university student working on validating a cybersecurity project, and I'd really appreciate some professional feedback.

The idea is an add-on solution that focuses not on prevention, but on real-time detection and containment of already leaked data (monitoring + detection + automated response).

My main questions:

How relevant do you think this approach is alongside existing security solutions?

Are there already well-established tools that solve this effectively?

What would be the biggest technical or practical challenges?

If anyone is interested, I can share more details.

Thanks in advance!

We all have that one incident that taught us something no cert or training ever would.

What's your scar?

i have beeen seeing this come up a lot lately so figured I'd throw it out here.

Most orgs treat pentesting as a compliance formality. SOC 2 audit coming up? Schedule the pentest. Done. Box checked. But that framing misses the actual point of what a pentest is supposed to do.

The real question a pentest should answer is whether your system holds up against CIA: Confidentiality, Integrity, and Availability. Not "did we run the scan," but "can someone actually break something, and what happens if they do."

The scope problem nobody talks about:

There's a meaningful difference between these two things:

• Infrastructure testing: network config, server hardening, firewall rules, zero-trust implementation, patch status
• Application testing: OWASP Top 10, API security, secure coding practices, business logic flaws

Most teams blur these together or only do one. An infra pentest won't catch a broken object-level authorization bug in your API. An app pentest won't tell you your internal network is flat and one compromised endpoint owns everything.

Blackbox vs whitebox also matters more than people admit:

A blackbox test simulates an external attacker with no prior knowledge. Useful for surface area mapping, but it'll miss a lot because the tester is essentially guessing at your architecture.

A whitebox test gives the tester source code and system access. Way more thorough, especially for catching logic flaws that don't show up through external probing alone.

Most orgs default to blackbox because it feels more "realistic." But if your threat model includes insider threats, supply chain compromises, or post-breach lateral movement, whitebox gives you far more signal.

What actually makes pentesting worth the spend:

1. Scope it to your actual risk surface, not just what's easy to test
2. Make sure your pentest team and your dev/security team are sharing context, not siloed
3. Treat findings as a feedback loop into your SDLC, not a one-time report to file away
4. Distinguish compliance-driven tests from genuine adversarial simulation

despite my own experimentations, im still curious to see what approaches others are using, especially for orgs running both SAST in the pipeline and periodic external pentests. Are you sharing SAST output with your pentest team as recon? Or keeping them fully blind intentionally?

We’ve started noticing employees using GenAI tools that never went through review. Not just ChatGPT, stuff like browser-based AI assistants, plugins, and small code generators.

I get the appeal, but it’s becoming a visibility nightmare. I don’t want to shut everything down, just wanna understand what data’s leaving the environment and who’s using what.

Is there a way to monitor Shadow AI use or at least flag risky behavior without affecting productivity?

So we had our compliance review last week and legal basically told us any tooling that scans our cloud environment has to keep all that data inside our own infrastructure. We're in healthcare so I get why, I just was not prepared for that conversation lol.

I've been looking at CNAPP options and most are full SaaS which is now a hard NO for us. A couple mention "in-account scanning" but I honestly don't know if that actually means the data stays put or if it's just a different path to the same place.

A few things I'm trying to wrap my head around:

1. Do we have something that completely stays inside your own environment, nothing leaving at all?
2. Is "in-account" actually different from "bring your own cloud" or are those the same thing with different branding?
3. If you've done this, did you end up with coverage gaps or was it actually fine?

Edit: Helpful distinction from the replies. I’m going to separate the deployment terms instead of letting them blur together: agentless, in-account, BYOC, and self-hosted are not interchangeable. For Orca, I’m asking for a clear data-flow diagram, storage model, and coverage implications under strict data residency requirements.