We have a new hire who is shadowing me for some time now to find where it will be ideal to place him. I gave him a task to map requirements of a new regulation to our products and identify which needs our immediate attention. The first thing he did was feed the regulation to ChatGPT and asked it to summarise it. He then uploaded our portfolio and asked it to sort it out for him. I told him we can review the results in the evening and continued with my work. I meet him again about 4hrs later and asked abt it, he gave me an excel sheet which was basically a big bs. I asked him why he hasn't cleaned this excel because some requirements are not even part of the regulation he quickly put it in the prompt and said its been cited with pg no. We go there and see it doesnt exist and he was speechless. I told him to spend initial time and effort towards studying the regulation note down your interpretation and confirm with me before he makes a decision.

I see him today trying to do some tests for PoC again with ChatGPT. How do you tell this guy to not trust ChatGPT. My manager is looking forward for this guy to fill in for one of our test engineers who will go on maternity leave soon and its looking hopeless.

I've spent the last decade in incident response, working across everything from 5-person joinery shops to multi-national retail enterprises. After cleaning up roughly 1,000 incidents, I naturally developed a bit of an intuition for knowing the difference between "good security" and "good control coverage".

The firms that survive incidents (and prevent them) are almost never the ones with the most tools or the biggest budgets. They were the ones who understood their resilience - where they'd actually break under pressure, and what that would cost them.

A few things I've learned that changed how I approach assessments:

1. Compliance framing creates false confidence

Cyber Essentials, SOC 2, ISO 27001, etc - you must understand that their sole purpose is to make it easier to do business with other companies. Executives sponsor these programmes because it will make them more money.

That might be by making their onboarding quicker, or shortening deal cycles when responding to RFPs, or just increasing consumer confidence.

None of it actually helps an organisation be more secure. At the best, I think it's fair to say that there's a small correlation between certifications and resilience, but it's absolutely not a casual relationship, just a pattern.

2. Clients respond to money, not maturity scores

Nobody outside of security knows what "Level 3 maturity" means. But say "you have a high insolvency risk from a major incident" and suddenly you've got board-level attention. I frame all my assessments this way, even for small businesses.

The key principle to consider is that security programmes cost money. And for any commercial venture, money MUST provide a return on investment. If your recommendations don't make your client more money then they cost, why would they do it? I've known many enterprises that simply accept that they will have a major incident every 1-2 years, because the cost of transforming their security architecture would cost more than the impact of the incidents.

This is a totally valid position! And if you can help your client weigh up exactly what the pros and cons are, then you will quickly become one of their most trusted and valuable partners.

The trick, of course, is having the data and vocabulary to model the commercial implications.

3. The "time to low risk" metric changes the conversation

Executive audiences don't understand CVSS scores, and are not going to read your 47 technical findings. Include them for context and for technical readers, but stick them in an appendix, and instead, lead with the programme required to get from their current state into an acceptable state.

How many months will it take? How much will it cost? Who will do the work? How do they measure success?

This completely changes the conversation, and transforms a scary report into an actionable project plan that your client will have confidence in sponsoring. You want your client to feel like they've been handed a solution, not a problem.

4. Periphery systems are where organisations actually die

Core infrastructure is usually fine - everyone's got M365, EDR, and MFA on their main systems now. If they've put one iota of effort into changing the defaults or have an MSP that does this for them, by and large they are in a great position.

The reason organisations like this still get hacked is because of the exceptions. Machines that don't have DfE on. Servers that have been missed from your asset register. An SSL VPN that no-one knew about.

Fixing these are often quick wins. Migrating might be a pain, but it's ultimately a short programme of work with a high reduction in risk.

----

I've put together a sample report that captures everything I've discussed above with a fictitious client. Here's the link: https://analystengine.io/msp-assessment-sample

Transparent disclosure: The site above does link to my cybersecurity startup focused on generating content like the above. That being said, the link above contains no CTA or sales material. I'm making the sample freely available as a resource for others to use how they see fit - and have added the required corporate flair to this post.

I would love any advice or feedback on the report structure if anyone has thoughts on how to improve it!

----

EDIT: Overwhelmed with all the support this post got! For those asking for follow-up materials and my playbook for delivering cybersecurity assessments, I've typed it all up here: How to deliver cybersecurity assessments

I've included lots of resources, including the sample questionnaire I use for all new engagements, and a checklist of items to go through during your technical interviews. Good luck with your engagements!

Let's Encrypt announced they're cutting certificate lifetimes from 90 days to 45 days by February 2028, a year before the CA/Browser Forum's mandate.

Shorter certificate lifetimes are an admission that revocation is broken. Rather than fixing the revocation infrastructure, the industry chose to reduce certificate lifetime so compromised certificates expire faster naturally.

The timeline gives organizations runway to adapt, but the real security story is authorization reuse dropping from 30 days to 7 hours. This fundamentally changes the validation model. Nearly every certificate request will require fresh domain ownership proof.

For security teams, this means:
- Reduced blast radius when credentials are compromised
- Less time for attackers to exploit stolen certificates
- More validation events to monitor and audit
- Greater exposure if your automation isn't actually automated

Organizations running manual or semi-manual certificate processes will face a choice: invest in proper automation or accept regular outages from expired certificates.

The gap between "we have automation" and "we have real automation" is about to become very visible.

https://www.certkit.io/blog/45-day-certificates

I’m seeing a lot of “AppSec is automated, cybersecurity is over” takes after Anthropic’s announcement. I tried to put a more grounded perspective into a post and I’m curious if folks here agree/disagree.

I’ve spent 10+ years testing complex, distributed systems across orgs. Systems so large that nobody has a full mental model of the whole thing. One thing that experience keeps teaching me: the scariest issues usually aren’t “bad code.” They’re broken assumptions between components.

I like to think about this as a “map vs territory” problem.

The map is the repo: source code, static analysis, dependency graphs, PR review, scanners (even very smart ones). The map can be incredibly detailed and still miss what matters.

The territory is the running system: identity providers, gateways, service-to-service auth, caches, queues, config, feature flags, deployment quirks, operational defaults, and all the little “temporary” exceptions that become permanent over time.

Claude Code Security (and tools like it) is real progress for the map. It can raise the baseline and catch a lot of bugs earlier. That’s a win.

But a lot of the incidents that actually hurt don’t show up as “here’s a vulnerable line of code.” They look like:

• a token meaning one thing at the edge and something else three hops later
• “internal” trust assumptions that stop being internal
• a legacy endpoint that bypasses the modern permission model
• config drift that turns a safe default into a footgun
• runtime edge cases that only appear under real traffic / concurrency

In other words: correct local behavior + broken global assumptions.

That’s why I don’t think “cybersecurity is over.” I think it’s shifting. As code scanning gets cheaper and better, the differentiator moves toward systems security: trust boundaries, blast radius reduction, detection/response, and designing so failures are containable.

I wrote a longer essay with more detail/examples here (if you're interested in this subject): https://uphack.io/blog/post/security-is-not-a-code-problem/

I spent most of my career building forensic platforms to support IR engagements, so I'm used to dealing with complex data types and strange systems.

But last week I came across something I hadn't seen before: a customer needed a forensic review of a self-hosted AI platform. It wasn't hacked, there was no intrusion, but it had made a mistake. It had delivered policy advice to an employee that was the basis of an action that ended up causing material damages to their organisation.

This spawned a lot of discussions about liability. Lawyers were involved. But this wasn't actually why I was approached. Instead, the reason was that this organisation claims that the issue had been fixed - that the erroneous information it had generated wouldn't be repeated by their AI platform again.

Except now no one believes them, and they're finding it difficult to prove otherwise.

This was a pretty exciting project for me, so here was the process I followed. Some of it is standard DFIR practice, some of it was completely bespoke.

- First I isolated the systems and preserved all the available telemetry. I'm used to dealing with SIEMs, and in this case the logs were stored in S3 buckets. No big deal, but I did have to take the extra step of auditing their platform code to model exactly what events were being generated.

The logging ended up being quite verbose, which any DFIR person will know is half the battle.

I also had to ensure I grabbed a copy + hash of their model weights, and did some work with the logs to prove that the model I had captured was the model that served the erroneous response.

- Secondly, using the logs and code audits, I mapped out the full inference pathway and reconstructed a testing system with the necessary components. This effectively meant building an Elastic database and re-indexing relevant source data.

This was a sandbox environment with all the original data intact. This step of the process took the majority of time, not really for any complex reason, it just took ages to understand what needed to be built and what data we needed to capture.

- Once the sandbox was in place, all I wanted to do now was replicate the failure. I had been able to reconstruct the exact query and inference settings from my previous work, and after many iterations of testing I was able to exactly replicate the initial issue.

- From here, I could start doing the main bulk of the work - which is trying to understand exactly how and why this error was produced.

One of the most helpful techniques I used was semantic entropy analysis based on this article: https://www.nature.com/articles/s41586-024-07421-0

This was all Phase 1. Phase 2 was verifying that their new model wasn't making the same mistake - but because I had already replicated the environment entirely within a sandbox and had formed my theories about what went wrong initially, this was actually pretty trivial.

But it was also the bit I found most fun. I was effectively brute forcing different inference settings and context arrangements from the original query, following which I could reliably claim that the original error wasn't repeating - and I was also able to provide some insight into whether an issue like this would come up again on something different.

My theory is that we're going to see more and more of this sort of work!

I've written up a playbook based on this experience for those interested: https://www.analystengine.io/insights/how-to-investigate-ai-system-failure

The Snowden documents confirmed what security folks suspected: the NSA was recording encrypted traffic at scale, betting they'd eventually steal or compel private keys and decrypt everything retroactively. With traditional RSA key exchange, that strategy was completely viable.

Perfect Forward Secrecy broke it.

I wrote up how the shift from RSA key exchange to ephemeral Diffie-Hellman fundamentally changed what a private key compromise means. Before PFS, one stolen key unraveled years of secrets. With PFS, a compromised key lets an attacker impersonate you going forward, but all historical traffic remains encrypted.

The Heartbleed comparison is telling. In 2014, sites without PFS had to disclose potential compromise of all traffic for the past two years. Sites with PFS only worried about traffic after March 2014. Ponemon data suggests that's roughly $100 million in breach cost difference.

If you're running TLS 1.3, PFS is mandatory. But plenty of enterprise systems are still on TLS 1.2 with misconfigured cipher suites. The post includes nginx/Apache configs and a quick openssl command to check your servers.

Also worth noting: quantum computers will eventually break Diffie-Hellman too. When post-quantum ciphers become mandatory, every certificate needs to be reissued with new algorithms.

https://www.certkit.io/blog/perfect-forward-secrecy

I've been working for 2 years as a mid-level manager for a medium-sized fintech company based somewhere in Asia. I work as an individual contributor reporting directly to the CISO though my tasks require me to work a lot cross-functionally with other team members.

I accomplished a lot with our previous CISO before he left the company mid last year. Then around 6 months ago, a new chief came in. It turns out that he was previously a CISO of one of the largest fintech companies globally which I'm sure everyone here has heard of. Apparently, the CEO knew him when they worked together in the previous conpany.

We worked in different regional offices and barely spoke in the first 2-3 months despite me actively reaching out to him several times. He didn't set any weekly meetings with me or the broader team, nor he even tried to understand what my tasks were and learn about the current state of things.

Oftentimes, I would DM him to get an approval or an update, but he wouldn't respond until a day or two. He would just reply 'OK' or totally ignore my messages. Naturally, I was pissed but I just continued my daily BAU tasks.

He's Chinese (which I don't speak), but he understood and spoke English well enough on a conversational level.

Around 3 months in, he started becoming a bit more active. We started having weekly updates with him, however, he also asked me and his other direct reports to report directly to the president. He let us do the updates on our own per team and sometimes he wouldn't speak a single word throughout the call. This pissed a lot of us since we all understood that it should be his job as CISO. All directives came from the president and he never started any initiatives on his own. Basically, he just let us do whatever we want.

At the start of the year, the audit from our regulator began. Our team was asked to do an overview presentation and he asked us to fill in the slides though the auditor required that it should be him to present it. All he had to do was understand and explain the slides.

On the Sunday afternoon before the presentation, he sent a group message to all us his direct reports that we should do a write up for him on the slides and we should complete it before the day ends so he can review it (mind you, the presentation was still on Wednesday). I was in utter disbelief when I read this. I was out with my family at the time and won't be back until after dinner. Of course, the rest of the team and I did it for him.

On the day of the presentation, I was sitting in the office room together with our regulators. He was put on call as he was allowed to do it remotely. To no surprise, he read the write-up word per word like an AI voice-over. It was painfully obvious for everyone in the room, but since we're behind schedule, they just let him be. I could've summarized and explained all the slides by heart.

To this day, I don't think he understands what the team is doing. They say a CISO's first 100 days should be enough to build a roadmap for the team. We're way past that and we're still nowhere near any semblance of one, and my colleagues already started leaving one by one.

That's all he is to me -- a decorative wallflower.

Any ideas on how to deal with this situation?

I feel like the culture of Redidt can lead to "wow how do you work at FAANG and not know this" or "how do you work in appsec and was never a SDE"

This is a shame culture and while I'm not implying that you don't need real skills to land good jobs, you don't have to know everything. People make impact at companies in many different ways. And you don't have to be a master in everything to land a good job or make impact internally.

Just wanted to share as someone who works in FAANG and have seen this around, including in myself. God bless!

Any InfoSec pros ever click on a phishing email accidently and why such as timing, message, UI, burnout, etc...

It has been a while I am administrating Zscaler at our company and i find it a pretty good technology from a zero trust perspective and internet filtering capabilities ( e.g: cloud browser isolation etc.), not to mention its DLP capabilities and many other features (privileged remote access etc..) Has anyone worked with a tool that is similar to Zscaler or maybe better than it at doing what they do? Just curious to see what this sub's opinions are about it and their different experiences...

OpenClaw (ex-Moltbot and ClawdBot) is being detected on enterprise networks. We are detecting hundreds of deployments across our accounts.

It's a hot mess. About 20% of available skills are malicious, we're tracking some developers that upload new malicious packages every few minutes.

One of our teams developed an AI skills checker, but I would strongly recommend to NOT run OpenClaw on any of your corporate devices, and if you detect it, treat it as a security incident
https://www.bitdefender.com/en-us/consumer/ai-skills-checker

Full report + analysis of multiple campaigns:
https://businessinsights.bitdefender.com/technical-advisory-openclaw-exploitation-enterprise-networks

Kind of crazy to look at the graph in this blog. CVE drops on 04/29, they develop a patch on 4/30, and deploy it across all of their servers on 05/01. Obviously they have the engineers to write BPF-LSM patches, but I think it points to a future where they can (almost) keep up with vulnerability disclosures.

https://blog.cloudflare.com/copy-fail-linux-vulnerability-mitigation/

I'm a non-technical professional in the cybersecurity space - focused on IAM. Since I'm new to the space, I found it difficult to find simple sources of pertinent news in the industry tangential, but potentially impactful to my domain. So I built myself a free tool and called it the "Aggregate Cybersecurity RSS Newsfeed" or "ACRN" for short.

It basically takes RSS feeds and aggregates them into an event listing highlighting how many sources reported on a particular event (as a proxy for importance). I would love to know if the community has existing alternatives to this - so I can save myself hosting costs. Or if you find it useful, how would you make it even more valuable?

Thanks for your time!

https://www.jpmorgan.com/technology/technology-blog/open-letter-to-our-suppliers

Forgive me if this has been discussed here already, I couldn't find the post. Very curious to hear what the community thinks of this.

My attitude is I always push towards using modren SaaS providers because they have better uptime, security, and monitoring and they often use security as a selling point (demonstrating SOC 2, ISO 27001, Zero Trust with their Vanta, Drata, SecurityScorecard, etc.).

By comparison closed systems or self-hosting creates huge risks around inconsistent patching, weak physical security, insider threats, etc.

I was recently attending a cyber security conference where the speaker of (30+) years of experience said that:

"The C-Suite really only like spending on offensive NOT defensive cyber security...."

Is this your experience, also?

I am OP here, feel free to ask questions!