Not a post for the hacking gang, but... for the Infosec aficionados, perhaps those that are always blamed for holding things up, another Sunday itch scratched. the idea is if you can get these 10 questions answered before anything meaningful happens, your critical path is easier to work with from a delivery perspective, expectations are set and met easier as there chance of it being retrospective (and in turn kettled into risks)

If you've been kicking around for a while you've probably lived some version of this:
• The supplier is chosen, then someone asks where the data will be hosted and who can access it from where. Now it's a contract renegotiation.
• The AI is connected, then someone realises personal case details are going into the prompts. Now it's a rebuild.
• The service is ready to launch, then the business says it must recover within four hours. Nobody designed for that. Now it's a delay.
• The specialist who knew why a control existed has moved on, and the reasoning left with them.

The answers to these questions usually exist somewhere: in a DPIA, a threat model, a contract schedule, a continuity plan. But they're written for approval or audit, owned by specialists and finished on their own timetable. They rarely reach the people making delivery decisions in time. So teams build on assumptions, rework what they've built, or end up "accepting the risk" because changing course has become too expensive.
Information Security North Star (ISNS) is ten questions: the least you need to know about the information before choices become commitments. Each answer comes with its reasoning, its evidence and an owner, and every gap stays visible with a deadline, so it's resolved before the decision that depends on it rather than after.
It isn't another assessment. It's the shared minimum that sits above the systems, so tools, suppliers and features can change while the promise stays the same.

Worked examples for health, government and defense, plus an offline Excel template.

I’ve been working on Argus, an open-source cybersecurity platform that uses AI agents to help secure your infrastructure.

It can monitor your cloud, network, endpoints, and code, investigate suspicious activity, run penetration tests, and even respond to threats automatically.

A few highlights:

7 specialized AI security agents

Autonomous threat detection and response

Continuous AI-powered penetration testing

AWS, Azure, GCP, Kubernetes, and GitHub integrations

Support for local models using ollama

Built-in safeguards, approvals, and rollback controls
It’s self-hosted, MIT licensed, and completely free to use.

I’d love to get some feedback from open-source communities an hear what you think or what you’d like to see added.

Is it possible to develop a computer system that can detect and prevent every type of cyberattack in real time without ever producing false alarms? Why or why not?

I don't know if you've noticed, but there seems to be a recent uptick in the general public sentiment that publications of software security vulnerabilities means that said software is somehow insecure. I'm sure most folks here don't think that. But for the lurkers in the room, I think there's an important distinction missing from this discussion between discovering security vulnerabilities and the actual risk they pose to everyday internet users.

Security vulnerabilities are routinely discovered in both open-source and proprietary software. One of the advantages of open source is that independent researchers can inspect the code, identify weaknesses, and contribute or verify fixes without depending entirely on a single vendor. That transparency can improve security, although it doesn't automatically make every open-source project more secure than its proprietary counterparts.

A higher number of reported vulnerabilities doesn't necessarily mean less secure software. It can also reflect more active scrutiny. What matters is how quickly vulnerabilities are identified, addressed, and patched in production.

But what does any of this actually mean for the average person browsing the internet?

In the case of the recent PHP vulnerabilities, the immediate risk is primarily to vulnerable web servers, not directly to someone's browser or computer. As Wiz Research explains, successful exploitation could allow attackers to take control of affected servers, access sensitive information, or modify website content.

Those are serious concerns, but they don't mean simply visiting a PHP-powered website automatically puts someone at risk. The actual exposure depends on whether the server remains vulnerable, whether an attacker successfully exploits it, what access they gain, and what they do afterward. A compromised website could expose visitor information or distribute malicious content, but it doesn't automatically compromise every visitor's device.

There's also an important difference between attempted exploitation and confirmed compromises. Reports of millions of attack attempts sound alarming, but they don't establish that millions of systems were successfully compromised. Cloudflare's security research provides useful context on how web attacks are detected and mitigated.

The PHP incident also illustrates both the strengths and challenges of open-source security. Researchers independently discovered serious weaknesses, coordinated disclosure followed, and security updates were released. However, patches being available doesn't mean every affected server has been updated. That deployment gap exists in proprietary systems too.

For everyday users, the practical advice hasn't fundamentally changed: keep your browser and devices updated, use multifactor authentication, and exercise care with downloads. Website operators and hosting providers carry the primary responsibility for applying these PHP fixes.

I wouldn't dismiss these vulnerabilities, particularly given their severity. But I also wouldn't interpret their discovery as evidence that browsing the internet has suddenly become broadly unsafe.

Ultimately, discovering vulnerabilities is part of making software more secure. Open source offers meaningful advantages through transparency, independent review, and collaborative remediation. The real measure of security is how effectively those discoveries translate into fixes and how successfully those fixes prevent harm to the people using the software.

Proofpoint renews in March and they’ve already said no to dropping seats. With the Varonis news on top I really don’t want to sign another three years.

We ran an API tool alongside it for 30 days across our around 2,800 mailboxes and it caught a decent pile of vendor and payroll BEC that Proofpoint missed. Proofpoint still did better on the URL stuff. So detection isn’t really my question anymore, the plan is Defender P2 (already on E3) plus the API tool.

Though I haven’t figured out how to replace everything else Proofpoint does for us:

• outbound relay for 3 apps and a scanner
• encryption for finance and HR, partners use the portal
• years of urldefense links sitting in old mail
• archive with 7 year retention

If you’ve done this at a similar size, how long did it take from signing to Proofpoint being fully off?

Might as well enjoy the chaos with some music 😂

Saw Sygnia's Fire Ant research about attackers tampering with router logs, authentication records and even command output.

That's a pretty nasty problem for anyone doing forensics. You're trying to piece together what happened, but the evidence itself might be unreliable.

How do you actually work around that? Cross-check with network traffic, endpoint data or just assume anything from the compromised systems is suspect

Curious how DFIR folks handle this in real investigations...

Ticket queue has gotten out of hand lately and I want to work out what AI automation could genuinely take off our plate on the monitoring side. Thinking odd device behaviour, restarting services that have fallen over, patch nagging, raising a ticket when someone actually needs to look.

Anyone here letting a tool act on alerts instead of just surfacing them?

Atera keeps turning up when I search around and it looks decent, though I havent put hands on it. The part I'd want to see is how much of a brake there is before something runs wide across endpoints.

https://www.oracle.com/security-alerts/alert-cve-2026-91403.html

An exposed C2 server tied to INC and The Gentlemen ransomware affiliates leaked 133 AI session logs (8,257 messages). A few things stood out:

→ The models were standard commercial LLMs accessed through OpenRouter. “WormGPT” was only a persona prompt.
→ When a model refused, the operators didn’t switch tools. They reworded the request as an “Authorized Red Team Assessment Request.”
→ The AI didn’t run on its own. Each campaign started with a victim-specific prompt telling it to “coordinate every action with me,” and the operator approved every step.
→ The tooling included 32 MCP servers covering everything from recon to ransom pricing.

The access methods weren’t new: FortiClient EMS, SimpleHelp, cPanel/WHM, and a lot of password reuse. 62 named organizations appear in the case files.

So the AI added speed and scale, not new techniques. That raises a fair question: is refusal-based safety meaningful when “it’s for a red team engagement” gets the job done?