crowmoor.se

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

On the 3rd of August Project Perception entered preview. It is a limited public preview, so only a selected group of customers have access for now. Here is how it actually works.

It lives in the Defender portal, with sections for an overview, chat, sessions, agents and playbooks.

Playbooks are reusable templates that describe how agents should handle a specific scenario. You start a playbook, or you describe the task in chat and Perception finds the right playbook, fills in the inputs and runs it.

A session is a piece of agentic work. You can watch work that is running or recently finished, see what started it, approve or reject actions when the agents ask, stop a session that is heading in the wrong direction and give the agents new guidance.

That supervision is the important part. It turns ‘the AI did something’ into ‘the AI proposed something, and I decided’. Every session is a record of what was done and why.

My advice if you get access: start with the red agents on a limited scope, so you see which attack paths they find in your environment. Then let the blue agents investigate incidents in parallel with your analysts and compare. Only then let the green agents act, and start with approval required for everything.

Measure as you go. How often are the agents right? How much time do they save? Where do they need more context?

Treat it like a new team member. Watch it closely before you trust it.

Tags: AI agents, Microsoft Defender, Project Perception