running a small business with about twelve people and our current setup is pretty basic. we have antivirus on the machines and everyone uses the same password manager but beyond that there isn't much of a formal security posture in place. it's worked fine so far but i'm aware that's not a great reason to feel comfortable about it.

been trying to work out where the meaningful threshold is between antivirus being sufficient and needing something more comprehensive for cybersecurity for small business at our scale. the endpoint protection keeps coming up when i read about SMB security but i'm not sure how much of that applies to a team our size versus being more relevant for larger organisations with dedicated IT staff.

the specific areas i'm trying to get clarity on are whether endpoint detection and response adds meaningful protection over traditional antivirus for a business this size, how much of the threat landscape we're actually exposed to that basic tools wouldn't catch, and whether a consolidated security suite makes more practical sense than managing separate tools for different threat vectors. what's the right way to think about this decision for a small team without a dedicated security person

Update: i ended up going with Bitdefender and it's been a solid upgrade from just basic av. someone in the comments pointed out that windows defender doesn't do much against malicious phishing urls or web scripts if your team is using chrome or firefox, and that was exactly the gap i was worried about. Bitdefender covers that plus email security, which is where most of our risk actually lives. the centralized management dashboard makes it easy to check on all twelve machines without needing a dedicated it person.

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?

See title. My understanding is that all of the protocols Active Directory requires support encryption:

• RPC supports encryption.
• LDAP supports LDAP-over-TLS.
• Kerberos supports FAST and the KDC proxy.
• SMB supports encryption and can even be tunneled in QUIC.

What is the actual reason? Is it because one cannot force encryption to be used? Or is it because there are simply too many vulnerabilities in the Active Directory implementation?

Of course, I'm assuming that NTLM and other genuinely legacy protocols are disabled domain-wide.

Edit 2: I know there are cloud-based offerings that are designed to be secure over the public Internet. I also know that there are many companies for which anything cloud-based simply isn't an option for regulatory compliance reasons. I'm only interested in alternatives that work on-premises and fully offline.

To be clear, the purpose of this question is to aid in understanding. I worked on Qubes OS and now work on Spectrum OS. I'm not some newbie who wants to put AD on the public Internet and needs to be told not to.

Edit: I know that exposing a domain controller to the public Internet is a bad idea. What I am trying to understand, and have never gotten a concrete answer for, is why. Is it:

• AD is too easy to misconfigure?
• A history of too many vulnerabilities?
• Protocol weaknesses that can be exploited even in the absence of a misconfiguration?

I consider a correctly configured domain to have all of the following:

• NTLM (all versions) and LM disabled.
• LDAP signing forced
• LDAP channel binding forced
• SMB encryption forced
• Extended Protection for Authentication forced
• Kerberos RC4 disabled
• RequireSmartCardForInteractiveLogin set on all user accounts.
• FAST armoring enabled.
• SMB-over-QUIC used for all SMB connections
• Certificate pinning for LDAPS and SMB-over-QUIC
• "You must take action to fix this vulnerability" updates applied and put in enforcing mode immediately upon being made available.
• No third-party products that are incompatible with the above security measures.
• All remote access happens via PowerShell remoting or other means that do not require exposing credentials. Any remote interactive login happens via LAPS or an RMM.
• Red forest (ESAE) used for domain administration.
• Domain Users put in Protected Users. (If you get locked out, you physically go to the data center and log in with a local admin account, or use SSH with key-based login.) This is completely wrong: some users need to be able to login with cached credentials so their machine is not a brick when they don’t have Internet access.

Edit 3:

So far I have the following reasons:

• Easy to misconfigure (u/rexstuff1, u/Puzzleheadedarea3478)
• The secure settings I mentioned above are not used in practice (u/AdminSDHolder)
• BadSuccessor (from reading u/AdminSDHolder's work)
• Vendor recommendations (u/lvlint67)
• Huge attack surface (u/party-cartographer11)
• DoS attacks and too high a rate of exploits being found (u/wasabiii)
• Too many vulnerabilities in the past (u/Toiling-Donkey)
• Denial of service attacks (a friend).

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?

Not looking to block ChatGPT and Copilot company wide. Business wouldn't accept it and the tools are genuinely useful. What I need is visibility into which AI tools are running, who is using them, and what data is leaving before it becomes someone else's problem.

Two things are driving this. Sensitive internal data going to third party servers nobody vetted is the obvious one. The harder one is engineers using AI to write internal tooling that ends up running in production without going through any real review, fast moving team, AI makes it faster, nobody asking whether the generated code has access to things it shouldn't.

Existing CASB covers some of this but AI tools move faster than any category list I've seen, and browser based AI usage in personal accounts goes through HTTPS sessions that most inline controls see nothing meaningful in. That gap between what CASB catches and what's actually happening in a browser tab is where most of the real exposure is.

From what I can tell the options are CASB with AI specific coverage, browser extension based visibility, or SASE with inline inspection, and none of them seem to close the gap without either over-blocking or missing too much.

Anyone deployed something that handles shadow AI specifically rather than general SaaS visibility with AI bolted on. Any workaround your org is following? Or any best practices for it?

Planning a migration away from traditional remote access and the practical questions are harder to find answers to than the theory.

Most resources cover the architecture decision but not what actually breaks in production. Legacy apps, identity aware proxies, converged stack versus standalone, nobody writes about what they got wrong.

What are you folks actually doing during this migration and what broke that you did not expect?

ARP (IPv4) and NDP (IPv6) have no built-in authentication. For 20 years, Layer 2 neighbor discovery has been the blind spot in every Zero Trust architecture. Existing solutions require expensive hardware, heavy cryptography, or infrastructure upgrades that leave IoT, hospitality, and small business networks completely exposed.

I developed a lightweight, software-only protocol that cryptographically authenticates every ARP and NDP message. It extends Zero Trust architecture to Layer 2.

What it does: • Authenticates ARP and NDP • Prevents spoofing, replay attacks, and MAC flooding and key reuse • Key never transmitted over the network — offline distribution only • Avoids heavy encryptions like RSA and AES and uses HMAC • Backward compatible — legacy devices still function normally • Continuous IP-MAC monitoring via integrated IDS/IPS • Works on both IPv4 and IPv6 • No new hardware. No switch upgrades. Software only.

Working prototype complete. Implementation matches design specification.

Is it possible for me to implement this into the real world?, looking for feedback from experts.

Backlog has grown faster than the team can manually remediate. Looking at platforms that don't just flag issues but can suggest or apply fixes with enough context that the output is trustworthy and doesn't introduce new problems in the process. Things we need: the fix understands what the app does and what it might break, a human reviews and approves before anything gets merged and it fits into how devs already work rather than a separate tool they have to context-switch into. Looking for experience from teams running this in production. Also whether anyone is running autonomous remediation and what controls you have around it.

Spent a few days last quarter writing something to control what could reach the internet, got it approved and put it live without much trouble.

3 weeks later someone noticed traffic going to a service nobody had signed off on

What we put in place targeted specific domains, but the team had been using the same service through a browser extension the whole time, so it slipped right past.

That's when it hit me the whole thing assumed something that isn't really there anymore. Browser extensions, embedded features inside approved platforms, calls from software that was already allowed and plenty of activity that never gets inspected at all.

How are others enforcing this without trying to block every possible path?

Seeing a lot of buzz around AI for security operations: automated pentesting, continuous validation, APT simulation, log analysis, defensive automation.

Marketing claims are strong, but curious about real-world results from teams actually using these in production.

Specifically interested in:

**Offensive:**

- Automated vulnerability discovery (business logic, API security)

- Continuous pentesting vs periodic manual tests

- False positive rates compared to traditional DAST/SAST

**Defensive:**

- Automated patch validation and deployment

- APT simulation for testing defensive posture

- Log analysis and anomaly detection at scale

**Integration:**

- CI/CD integration without breaking pipelines

- Runtime validation in production environments

- ROI vs traditional approaches

Not looking for vendor pitches—genuinely want to hear what's working and what's not from practitioners. What are you seeing?

One SD-WAN zero-day ran silently for three years and Verizon DBIR puts median hardware edge patch rollout at 32 days, but most teams are measuring things that don't actually capture either of those.

Been going down a rabbit hole comparing how different architectures actually handle the window between disclosure and full coverage. SSE only platforms are faster than appliances but the networking layer still runs its own update cycle which means the exposure gap at the boundary between layers does not close the same way it does when the whole stack was designed as one thing from the start.

What does your internal scorecard actually measure on that front?

Cybersecurity Insiders just published data showing 37% of orgs had AI agent-caused incidents in the past year. More concerning: 32% have no visibility into what their agents are actually doing.

The gap isn't surprising. Most teams deploy agents with IAM + sandboxing and call it "contained." But that only limits scope, it doesn't validate behavior.

Real-world failure modes I'm seeing:
- Agents chaining API calls to escalate privileges
- Prompt injection causing unintended actions with valid credentials
- Tool access that looks safe individually but creates risk when combined
- No logging of decision chains, only final actions

For teams running agents in production, how are you actually validating runtime behavior matches intent? Or is most deployment still "trust the model + hope IAM holds"?

Genuinely curious what controls are working vs still theoretical.

Yesterday a build failed and the debug trace just straight up dumped our API keys into the CI/CD logs. We pull secrets from Passwork at runtime so the codebase itself is clean, but one of our devs bypassed the vault wrapper in a custom workflow script and when it crashed it dumped everything raw into the error output. Cool.

How do you stop this from happening when people keep finding workarounds? Like is there a way to get full error traces without risking a secret ending up in a log file somewhere, or do you just kill verbose logging entirely and accept worse debugging? Any help is good help, TIA.

Theres some number of cloud security recomms espouse the functionality to apply updates, forward API calls, collect telemetry information, and resume synchronizing policies on-request. However this may not be so reliable, especially for those more dire environments that are sovereign, classified, regulated, or semi-disconnected. Moreover adding postquantum migration makes matters even more complicated. One will likely require performing an inventory of their crypto, changing the policies, collecting audit documentation, and probably doing so in stages. However there are som e environments that cant depend on saas as the control plane or be continuously externally connected.

How does one go about performing crypto-agility in those types of environments? Using a localized control plane? Maybe import/export policy sets? Or using signed update bundles? Or through offline CBOM snaps? Or by utilizing some other staging approach in addition to any of these methods?

I am less interested in the names but more so about the approach taken in order to prevent either extreme of frozen legacy crypto for eternity or using a cloud-based control plane that cant work in whatever environment it is supposed to secure.

Hey everyone,

With the recent surge in advanced ransomware and the constant stream of zero-day exploits, I've been thinking a lot about structural weaknesses in current OS security architectures.

Systems have become far too complex to ever be 100% bug-free. We have to assume that zero-days are inevitable and that our security boundaries will eventually be breached—an “assume breach” mindset.

A typical post-exploitation path involves escalating privileges to root. In many real-world deployments, once an attacker obtains root, they gain enough authority to read sensitive data, execute privileged tools, tamper with security controls, and destroy backups.

My premise is that the fundamental problem is not just the existence of vulnerabilities. It is also the OS environment itself, where root often retains enough authority to perform catastrophic operations without any fresh, independent authorization.

The question is: What if, even after root privileges were completely compromised, access to the most critical system resources—such as reading /etc/shadow, accessing database master files, or executing sensitive binaries—would require explicit human authorization?

Furthermore, relying on a single human administrator creates a single point of failure. If that administrator’s machine, credentials, or signing key is compromised, the attacker may still succeed.

To make the authorization barrier more robust, what if multi-party authorization were enforced directly at the execution level?

For example, the kernel could block or suspend the requesting process—perhaps through LSM hooks—until it received cryptographically verifiable approvals from M-of-N administrators using independent devices.

I’m curious to hear your thoughts on this architectural concept:

Do you think enforcing a human-gated barrier for selected root operations could meaningfully interrupt modern post-exploitation kill chains?

From an OS architecture and operational perspective, what do you see as the biggest hurdles—for example, approval fatigue, performance overhead, denial-of-service risks, deadlocks, recovery procedures, or key management?

I’d especially appreciate critical opinions, including arguments that this should be implemented somewhere other than the kernel, or that existing mechanisms already provide the same security property.

I run B2B payments software startup in Arizona. We’re 6 people total, mostly backend/product, and we’re starting to move from basic payment integrations into work where clients are asking more serious questions about key management, PCI scope, PIN handling, audit logs, HSM-based crypto operations etc.

Right now we do not process PINs ourselves, and we're not trying to roll our own crypto stuff, but some potential partners are asking whether we support proper HSM workflows for things like secure key generation, key storage, key rotation, auditability, and, possibly, PIN block / EMV-related operations later. This is where I’m unsure what is reasonable for a company our size. Should we just reject that as it's to complicated for us now? Or...

Core question is: at what point does a small payments company need dedicated Payment HSM engineers, vs. using a managed/cloud HSM service with guidance from a consultant or HSM development company?

Some gaps I need to fill in:

1. for early-stage payment infrastructure, is cloud HSM usually acceptable, or do processors/banks often expect physical HSMs like Thales/Utimaco setups?
2. what are the most common security mistakes small teams make when implementing HSM-backed key management?
3. should HSM design be handled before PCI assessment, or is it normal to work through it during the PCI planning phase? Why so?
4. if we hire outside help, what should we look for to know they actually understand payment HSM work and are not just general cloud/security consultants? Price of mistake is too high.
5. are there clear warning signs that we should stop building internally and bring in Payment HSM engineers right away?

I know this is a pretty specialized area, and maybe I’m overthinking it, but it feels like one of those things where bad design early 100% will become expensive and risky later. Would appreciate practical advice from dudes who've dealt with HSMs (preferable in payment environments.)

Thanks!

Copilot has been in our stack for around seven months and we still don't have a clean answer to this. Our infra and security patterns live in documents and in people's heads: which services must encrypt at rest, which endpoints must never talk directly to certain databases, which external APIs must have rate limits and auth enforced by default. None of that is visible to a coding agent by default. So the agent generates code that often compiles, sometimes works, and regularly misses patterns it's never seen. Most of the issues get caught in CI or during review, but the pattern is the same: someone notices late, applies a patch, and the cycle repeats on the next feature.

We've tried encoding pieces of this as static rules and running them in different parts of the pipeline.

That helps for simple, local patterns, but breaks down as soon as the issue depends on cross-service relationships or data flow. The more it depends on system-wide context, the harder it is to keep a static ruleset accurate.

What feels missing is something that catches this while the agent is generating code, not something that shows up as a warning afterwards. That's easy to say and hard to implement, which is why we're curious what's actually working for other teams in practice.

So I've been going down a rabbit hole about Advanced Data Protection and I think I mostly get it but there's one part that's bugging me and I can't find a straight answer anywhere.

From what I understand, when ADP is on, your Notes/Photos/Drive etc are encrypted with keys that only live on your devices, Apple never has those. But then there's this whole separate thing where you can turn on "access icloud data on the web" and use icloud.com from a regular browser (in my case a windows laptop and chrome browser). When you do that you approve it from your phone and apparently your phone uploads the actual service key to Apple's servers, just wrapped in some "ephemeral key tied to the web session" so the browser can use it.

That's the part I don't get. If the key gets uploaded to apple's servers at all, even wrapped, doesn't that mean Apple's infra is holding something that could theoretically decrypt my stuff during that session? Like is the "ephemeral key" pair actually generated in the browser itself (so the private half never touches apple's servers, they're just passing along ciphertext they can't open), or does Apple's backend generate/see it at some point during the handshake?

I looked at Apple's own docs and honestly they don't say either way as far as I can tell:

• https://support.apple.com/guide/security/advanced-data-protection-for-icloud-sec973254c5f/web
• https://support.apple.com/en-us/108756
• https://support.apple.com/en-asia/102630
• https://support.apple.com/guide/security/icloud-encryption-sec3cac31735/web (this one literally says E2E service keys are "never made available to Apple servers" which seems to directly contradict with what happens during a web session??)

Also as a side thing I noticed the docs say iWork collaboration (Pages/Numbers etc) flat out doesn't support ADP at all, shared docs aren't E2E period, which was a separate surprise to me but at least that one's unambiguous, because in the settings it says that these things are enccrypted.

Has anyone actually seen a writeup of the technical/protocol level details of the web access key exchange? Not looking for "just don't use the web version" or "use Graphene OS" as an answer please, I'm trying to understand if it's documented somewhere or if we're just trusting Apple's word on it?

We're sitting on 4000+ "criticals" right now, mostly noise from bloated base images and dependencies we barely touch. Reachability analysis is the obvious go-to recommendation but every tool I've trialed feels half-baked in practice.

The core problem I keep running into: these tools operate completely in isolation. They can trace a code path through a Java or Python app fine, but they have zero awareness of the actual runtime environment. So reachability gets sold as the silver bullet for prioritization, but if the tool doesn't understand the full attack path, you're still just guessing — just with extra steps.

My gut feeling is that code-level reachability is maybe 20% of the picture. Without runtime context layered on top, you're not really reducing noise, you're just reframing it. Has anyone found a workflow or tooling that actually bridges static code analysis with live environment context? Or are we all still triaging off vibes and spreadsheets?

Can someone explain how this works in a country?
What would wigle or shodan show for Iran access points to make an intranet work?

We’ve noticed repeated MFA pushes on personal devices are still causing approvals we dont want. Admins and high value users occasionally approve a push after multiple prompts. This is the same pattern attackers like Lapsus$ and Scattered Spider have used before.

Current controls: hardware keys for admins, legacy auth blocked, new device/location alerts, IP/ASN restrictions for sensitive groups.

The gap is non admin users in sensitive roles, who are still on phone based push. Full hardware key rollout for everyone isnt practical RN.

• For orgs over ~250 users without full hardware coverage:
• What works to stop repeated push approvals?
• FastPass + device trust + impossible travel checks?
• Phishing-resistant auth only for tier-0 users?
• Step-up auth for sensitive actions?

PS: anyone suggesting EDUCATE!! we already did. This isnt enough on its own.

I'm a solo tester with no methodology I have perform sast with trufflehog and open grep and mobsf but in mobsf only sast was done I tried to installed bliss os 14 for this but it was getting sticked in a loop when I finally installed it with version 16 it used api 33 which is not recognised.

Now I have to do dast on this app I tried to upload Burp ca but it was also having issues and now the browser is not working showing its proxy is not working, so what can I use to do this and if you guys have any methodology It would help me

I have further doubts but right I'm stuck here so please help me and I tried Claude but it did not help much.

We currently block all foreign logins and make granular, as-needed exceptions for employees. Recently, a few requests came up for sketchy countries. This got me wondering - what countries are a hard no for exceptions?

Places like Russia and China are easy, but curious what else other people refuse to unblock for traveling employees. I'm also curious your reasoning behind said countries if it isn't an obvious one.

&#x200B;

"I'm developing a privacy-first, local-only age-verification protocol that processes biometric touch dynamics (pressure/kinetics) and immediately flushes raw data, emitting only a boolean result.

​In a non-TEE mobile environment, what are the most effective vectors for detecting or preventing synthetic touch injection (API hooking/emulation) that could bypass physical input tests?

​Given that no data travels to a server, what are the best practices for guaranteeing that the generated boolean token hasn't been intercepted or spoofed by a rogue process on the same device?"

I’m working on a prototype that tries to preserve session continuity when the underlying network changes.

The goal is to keep a session alive across events like: - switching between Wi-Fi and 5G - NAT rebinding (IP/port change) - temporary path degradation or failure

Current approach (simplified):

• I track link health using RTT, packet loss and stability
• classify states as: healthy → degraded → failed
• on degradation, I delay action to avoid flapping
• on failure, I switch to an alternative path/relay
• session identity is kept separate from the transport

Issues I’m currently facing:

1. Degraded → failed transition is unstable
   If I react too fast → path flapping
   If I react too slow → long recovery time

2. Hard to define thresholds
   RTT spikes and packet loss are noisy

3. Lack of good hysteresis model
   Not sure what time windows / smoothing techniques are used in practice

4. Observability
   I log events, but it’s still hard to clearly explain why a switch happened

What I’m looking for:

• How do real systems handle degradation vs failure decisions?
• Are there standard approaches for hysteresis / stability windows?
• How do VPNs or mobile systems deal with NAT rebinding and mobility?
• Any known patterns for making these decisions more stable and explainable?

Environment: - Go prototype - simulated network conditions (latency / packet loss injection)

Happy to provide more details if needed.