crowmoor.se

Last Friday a researcher reported that the private keys of eight intermediate certificates from a certificate authority were broken. Not stolen. Broken. They had been generated with almost no randomness, so anyone could calculate them from the public certificate. The private keys had values between 4 and 237. A normal key for that curve has around 2³⁸⁴ possibilities. These had fewer than 256. You could guess them on a pocket calculator.

Six of the certificates could issue TLS certificates for any website. Two were used for code signing. And they had been trusted by browsers and operating systems for a year and a half.

The good news first. The browsers reacted fast. Chrome and Firefox blocked the certificates within hours, without users having to update or restart anything. Apple, Android and Microsoft followed within days. And because the browsers require every certificate to be logged in Certificate Transparency, and no certificates from these intermediates had been logged, there is no sign that anyone used them to fake a website.

So why am I writing about it? Because the browser was the easy part. The hard part is the long tail.

TLS isn´t only used by browsers. It is used by every server that calls an API, every Python script, every Go binary, every container image, every appliance, every IoT device and every VPN client. Many of them don´t use the operating system´s list of trusted roots. They carry their own copy, baked in when they were built. A container built last year still trusts what it trusted last year, until someone rebuilds it. One of the cryptography maintainers involved said the clean up could be bigger than Heartbleed. I think he is right about the shape, if not the danger: a very long tail of forgotten things.

To abuse the keys, an attacker still has to sit in the middle of the traffic. That isn´t trivial on the internet, but it is easy on a hotel network, a compromised router or inside a network the attacker already controls.

What to do this week

1. Update the trust stores you know about. Operating systems, Linux distributions and browsers first. Check with the test sites published for the incident that the certificates are really blocked.

2. Find the trust stores you don´t know about. Python certifi bundles, Node, Java keystores, Go binaries, curl bundles, container base images. Search your repositories and images for the root and intermediate certificates of the affected CA.

3. Rebuild and redeploy. Updated libraries are out for Go, Python, Rust and others. A library update doesn´t help a binary that was compiled last year. It has to be rebuilt.

4. Check your appliances and IoT. Firewalls, proxies, load balancers and anything doing TLS inspection have their own trust stores. Ask the vendors when they ship an update, and push for an answer.

5. Check if you have certificates from this CA yourself. If your own websites or services use them, they must be replaced, because the issuing certificates are revoked.

6. Look at code signing. Two of the keys signed code. Check if you allow software signed by them anywhere, for example in application control policies.

Where Defender helps, and where it doesn´t

This is exactly the kind of problem where inventory matters, and where many organisations discover they have none.

The Defender Vulnerability Management add-on, for clients with Defender for Endpoint Plan 2, includes certificate inventory. It shows which certificates are installed in the certificate stores on your devices, including root and intermediate certificates, who issued them and on which devices they are. That means you can search for the affected CA and see where it is trusted, and the same data is available in advanced hunting, so you can build a query that you rerun until the list is empty. The add-on also gives you a better software inventory and assessment, which helps you find the affected versions of runtimes and tools.

On the server side, you don´t need the add-on if you have Defender for Servers Plan 2. It includes the premium Defender Vulnerability Management capabilities, certificate assessment among them, for servers in Azure, other clouds and on-premises through Azure Arc. Plan 2 also adds agentless scanning, which can find vulnerable software in machines and container images without an agent.

But be honest about the limits. Certificate inventory sees what is installed in the system certificate stores. It won´t see a CA bundle compiled into a Go binary, a cacert.pem file inside a Python virtual environment or the trust store in a firewall. And it won´t see the IoT device that has no agent at all. For those, you need software inventory, image scanning, your development pipelines and good old questions to the vendors. Defender gives you the map of what is managed. The long tail is often exactly what isn´t.

The bigger lesson

In September 2024 I wrote that you should make an inventory of your cryptography before the quantum computers arrive. This week showed why. When trust breaks, the question isn´t only how to fix it. It is where it lives. Organisations that know where their certificates, trust stores and keys are will be done in days. The rest will be finding forgotten copies for years.

There is a compliance angle too. Under the new cybersecurity act you must be able to show that you act on known vulnerabilities in time. A certificate authority you trust being compromised is a known vulnerability. ‘We updated the browsers’ won´t be a complete answer.

Trust is only as strong as its longest tail. Go find yours.

Tags: Certificates, Defender, PKI, TLS, Vulnerability management

A last business post for now. If the SOC is becoming agentic, who should you recruit?

The traditional SOC was built like a pyramid. Many junior analysts at the bottom handling alerts, fewer experienced ones in the middle doing investigations, and a few experts at the top. The juniors learned by doing the routine work, and some of them became the experts of tomorrow.

Agents are taking over the bottom of the pyramid. That creates two problems. Where do the future experts learn, if the routine work is gone? And what skills do we need now?

Here is what I would look for. People who understand how attacks really work, not just how tools display them. People who can supervise automation: read what an agent did, judge if it was right and improve it. People with business understanding, who can weigh security against operations. Engineers who can build and maintain playbooks, detections and integrations. And people who communicate well, because explaining risk is becoming a bigger part of the job.

Keep hiring juniors. But give them a different path: let them learn alongside the agents, review their work and work on the hard cases with a senior. Otherwise there will be no seniors in ten years.

And look for every kind of mind, as I wrote in 2024. The person who notices half a second is still the one who finds what the agents miss.

Compliance plays in here too. The new cybersecurity act requires training for management and staff. Make it part of the plan, not a checkbox.

Recruit for judgement. The machines bring the speed.

Tags: Business, Recruiting, Skills

In April I predicted a wave of patches over two to three years, followed by a lower level than before. Half a year later, let´s look at the numbers.

This week Microsoft released 1,408 new CVEs in one Patch Tuesday. In all of 2025, Microsoft published 1,244. One month beat the whole of last year. From January to the 10th of October this year, Microsoft published 2,970 CVEs, against 936 in the same period of 2025.

It is the same across the industry. From January to July, 45,626 CVE records were published in total, two thirds more than in the same months last year. The monthly volume more than doubled between January and July.

So the wave is real, and steeper than I expected.

What about exploitation? This is the interesting part. Known exploitation has grown much less than the volume. CISA´s list of known exploited vulnerabilities grew from 196 to 255 entries over roughly the same period this year. Analysts describe it as bigger haystacks with not that many more needles. That fits my theory: much of the new volume is old bugs that AI can now see, not a sudden wave of new attacks.

Is there any sign of the downturn yet? Not in the numbers. We are still in phase one, the backlog. But scanning before release is now in production pipelines, and that is what will eventually bend the curve.

What does it mean for you? Stop measuring your patching against raw CVE counts. Prioritise on exploitation and exposure. Automate everything that can be automated. And plan for Patch Tuesday as a very large event for a while.

The curve is going up. Make sure your process can climb with it.

Tags: Patching, Statistics, Vulnerabilities

As I wrote at New Year, I am building a small gin distillery. I promised to keep security in it, and I have. Here is what security looks like when the whole IT department is me and three dachshunds.

The production side is OT. The still has sensors for temperature and flow that log the distillation. I keep them on their own network segment, separated from the office network and the guest Wi-Fi that visitors use. The sensors don´t need internet, so they don´t get it. If someone hacks my kettle, they should at least have to work for it.

The business side is cloud. Production records, batches, raw materials and the alcohol accounting live in a model driven app in the cloud. Every account has MFA. There are no shared accounts, not even for the dogs, despite their protests.

The interesting part is the input. The people who work in production aren´t IT people, so the goal is that they can talk to the system instead of typing. An agent asks for what is missing and checks for errors. Which means everything I have written about agents applies to my own distillery: own identity, least privilege, and a human approving anything important.

And then there is compliance. A distillery answers to the tax authority, the food safety authority and the retail monopoly. Every litre of alcohol must be accounted for. Records must be complete, correct and kept for years. Losing them isn´t an IT problem, it is a legal one. So the backups are tested, and the logs can´t be changed afterwards.

The quality control department, all three of them, has approved the security model. Mostly because they were promised treats.

Small business, same principles. Just more juniper.

Tags: Compliance, OT, Personal, Small business

Agents now triage alerts, investigate incidents, find attack paths and propose fixes. Some of them act on their own. So what remains for the human analyst? I get that question from colleagues, from students and, honestly, from myself.

Let me try an answer.

Judgement. Deciding which risk to accept, which action is worth its business impact, when the textbook answer is wrong for this organisation. Agents can propose. Someone has to decide.

Context. Knowing that the CFO is travelling this week, that the factory is running a critical batch, that the supplier is in the middle of a dispute. Much of that context never ends up in a log.

Supervision. Watching what the agents do, catching their mistakes, improving their playbooks and moving their limits. That is a skill of its own, and it will be one of the most important ones.

The hard cases. The new attack technique, the insider, the incident that crosses organisations and countries. The agents will handle the routine so that humans can spend their time on these.

Communication. Explaining to management, customers and authorities what happened and what it means. Trust is still built between people.

And curiosity. The 500 milliseconds that someone found strange. The agents find what they are built to find. People find what nobody expected.

The job isn´t disappearing. It is moving up a level. The analyst who learns to work with agents will be more valuable than ever. The one who refuses will find that the routine work they protected is gone anyway.

Stop doing what the machine can do. Start doing what only you can.

Tags: AI agents, Careers, SOC

For years, a proper SOC has been something for large organisations. You needed a SIEM, people around the clock, detection engineers and a lot of integration work. Smaller organisations bought a service, or did without.

This month Microsoft made an integrated SOC experience in Defender available to eligible Microsoft 365 E5 and E7 customers who don´t have their own Sentinel workspace. It brings XDR, SIEM capabilities, threat intelligence, automation and AI together in the Defender portal.

Why does this matter? Because many of the organisations that need it most are exactly the ones without the resources to build it. The small municipality I helped on my 50th birthday. The supplier with a two person IT team. The company that bought E5 for compliance reasons and never used half of it.

For them, the barrier to a functioning SOC drops considerably. The data sources they already have are connected, the detections are built in, and automation and agents can handle a large part of the routine work.

It isn´t magic. Someone still needs to own it, look at what it finds and act on the things the automation can´t handle. A partner can help with that. And you still need to get the basics right: identities, devices and patching.

There is a compliance angle as well. Under the new Swedish cybersecurity act, many smaller organisations now have to detect and report significant incidents within 24 hours. That is very hard without some kind of SOC.

Security shouldn´t depend on the size of your budget. This is a step in the right direction.

Tags: Microsoft Defender, Small organisations, SOC

This week the Swedish data protection authority fined the system supplier that was hit by ransomware in August last year. The attack affected a large share of the country´s municipalities, and sensitive data about employees was published. The fine was 1.8 million kronor, for not having appropriate technical and organisational security measures under the GDPR.

It is worth thinking about what that means, beyond the amount.

For suppliers, it is a clear signal. If you process sensitive data on behalf of others, you are responsible for protecting it, and you will be held accountable when you don´t. The authority looked at concrete things: how software was installed and checked, and whether there was monitoring that would detect an attack in time.

For the customers, it is just as important. Many municipalities thought they had outsourced the problem. They hadn´t. They still had to notify their employees, handle the consequences and explain to their own supervisory authorities what they had done to choose and follow up the supplier.

This is where compliance gets real. Data processing agreements, supplier assessments and security requirements in procurement are often treated as paperwork. This case shows that they aren´t. When something goes wrong, the question is what you actually checked, not what you signed.

So for management: look at the suppliers that hold your most sensitive data. Ask what you know about their security, and how you know it. Ask for evidence, not certificates alone.

The fine was paid by the supplier. The price was paid by everyone.

Tags: Business, Compliance, GDPR, Supply chain

I wrote about the EU AI Act in February and August last year. A lot has happened since, and I see a dangerous misunderstanding spreading, so let me check where we are.

In June the EU adopted an amendment to the AI Act, the so called digital omnibus on AI. It postponed the requirements for high risk AI systems. Standalone high risk systems now have until the 2nd of December 2027, and AI embedded in regulated products, like medical devices and machinery, until the 2nd of August 2028.

The misunderstanding is that the AI Act was postponed. It wasn´t.

The 2nd of August 2026 remained the general application date, and enforcement started then. The transparency obligations apply: people must be told when they interact with AI, and deepfakes and AI generated content must be labelled. The prohibitions have applied since February 2025, and the omnibus even added a new one, against AI generated sexual deepfakes and child sexual abuse material. The rules for general purpose AI models apply. And the fines are unchanged: up to 35 million euro or 7 % of global turnover for the prohibited practices.

So what should management do? Don´t pause your AI governance work. Use the extra time for high risk systems to do it properly, not to stop. Make sure the transparency requirements are met now, especially for chatbots and generated content. Keep your AI inventory up to date.

And watch the compliance trap again. A deadline that moves is still a deadline. Organisations that wait until late 2027 will find that everyone else is waiting too, and that the experts are fully booked.

The finish line moved. The race didn´t stop.

Tags: AI governance, Business, Compliance, EU AI Act

In February 2024 I wrote about multitenant management in Defender, which gave the SOC one view across several tenants. It solved the security operations side. The administration and configuration side stayed hard. In August, Microsoft Entra Tenant Governance became generally available, and it addresses exactly that. This post is longer than usual, because the topic deserves it.

First, the problem. Most large organisations have several Microsoft tenants. Some come from acquisitions. Some were created to separate sensitive workloads. Some are test environments. And many are shadow IT tenants, created by someone with a credit card and a good idea, that central IT has never heard of. Each tenant has its own admins, its own settings and its own risks. An attacker who finds a forgotten tenant with a trust to your main tenant has found a side door.

Tenant Governance has four main parts.

Related tenants. Discovery of the tenants connected to your organisation, including the ones you don´t administer, based on signals such as users from your organisation signing in to them or applications shared with them. You can then classify them: govern it, investigate it, or quarantine it if it looks risky.

Governance relationships. A directional relationship where one tenant, the governing tenant, governs another. The governed tenant has to accept the request, so it is a handshake, not a takeover. One tenant can govern many, and a tenant can be governed by several, but you can´t build chains where a governed tenant governs others. A policy template defines what is provisioned when the relationship is created.

Cross tenant delegated administration. This is the part I like most from a security perspective. Admins sign in with their accounts in the governing tenant and get least privilege roles in the governed tenants. No more local admin accounts or guest admin accounts in every tenant, each with its own password, its own MFA and its own risk of being forgotten. One identity, protected once, with Conditional Access and PIM from the governing tenant.

Configuration management. You define a baseline, the desired state of a tenant in a JSON format, covering more than 200 resource types across Entra, Intune, Exchange Online, Teams, Purview and Defender. A monitor compares the actual configuration with the baseline every six hours and shows the drift: which settings changed and how. You can take a snapshot of a known good tenant and use it as a starting point.

Secure tenant creation. You decide who may create new tenants, and new tenants automatically get a governance relationship to the central tenant, so you never lose administrative access to them.

How would I deploy it? Start with discovery. You will probably be surprised. Then create policy templates with a minimal set of roles. Establish governance relationships with the tenants you already administer and move their admin access to delegated administration, removing the local admin accounts. Set up configuration baselines for the most critical settings first: Conditional Access, admin roles and external collaboration. Then deal with the unknown tenants, one by one. Finally, lock down tenant creation.

Treat the governing tenant as Tier 0, or the control plane in the enterprise access model. Whoever controls it controls all governed tenants. Protect its admins with phishing resistant MFA, PAWs and PIM, and monitor it closely.

And the compliance benefit is real. Baselines and snapshots give you documented evidence of how each tenant is configured, and drift reports show when it changed. That is exactly what auditors and supervisory authorities ask for, and what is very hard to produce manually across ten tenants.

Every tenant you don´t govern is a tenant someone else might.

Tags: Microsoft Entra, Multitenant, Tenant Governance

Project Perception, like many AI services, uses consumption based pricing. You pay for what the agents do, measured in Security Compute Units, and more intensive tasks consume more units. That changes how a SOC is budgeted.

Traditionally, security costs are mostly fixed. Licences per user or device, a SIEM priced per gigabyte, and salaries. You know roughly what next year will cost.

Paying per task is different. A quiet month costs less. A month with a major incident, or a month when you run red agents across the whole estate, costs more. That is fair, but it is harder to predict.

So how should management think about it? First, compare the right things. The question isn´t what the agents cost, but what the same work would cost otherwise: analyst hours, consultants, delays. If an agent investigates an incident in minutes that would take an analyst two hours, the unit price is easy to judge.

Second, set budgets and limits. Decide how much capacity the agents may use per month, and what happens when it runs out. Nobody wants to discover in the middle of an incident that the budget is empty.

Third, prioritise. Use the agents where they create the most value: high volume triage, continuous exposure reduction and investigation of serious incidents.

Fourth, follow up monthly. Cost per incident, cost per closed attack path, time saved.

Variable costs need fixed rules.

Tags: AI agents, Business, Cost