Vendor Detection Content Covers What Every Company Has. Your Estate Has More.

Two kinds of detection content, and two different authors

Cortex XSIAM ships with Analytics BIOCs that Palo Alto Networks builds and maintains. They raise an issue, which is what the platform calls a detection that has fired, when behavior departs from a baseline the engine builds out of your own telemetry over time. Related issues get stitched into a case by causality, so what an analyst opens is a chain the platform has already assembled. Every one of those is authored by the vendor and arrives with the platform, and Marketplace content packs extend the same idea per source type and per technique that recurs in intrusion reporting, bundling correlation rules, parsing rules, playbooks, dashboards and issue types together. Content of that kind has to hold true in a bank, a hospital group and a parts manufacturer on the same release.

The second kind is authored by somebody who works for you. Three rule types sit on that side of the line, IOC rules, BIOC rules and correlation rules, the last of them written in XQL, the Cortex Query Language, against your own datasets. What they have in common is that the environment they describe exists exactly once. The claims application your team wrote in-house and has extended every year since. The service account created for a migration that finished, still credentialed, still signing in at three in the morning because something downstream would break if it stopped. The link between the ordering system and the warehouse that one contractor wired up and one person understands. Each of those is singular, which is precisely the property the vendor-authored half is built to look past.

Content built to hold true in every estate that bought the platform is built the only way it can be built. The half that describes a system only your company runs gets written by the people who run it, and that half is the subject here.

So the split is clean, and it follows from what each half is for. One party writes what generalizes and maintains it across releases. The other writes what applies here and nowhere else, and that second author sits inside your organization whether or not anyone has been named to the job.

The application three teams depend on. The service account created in 2018. The transaction sequence that should never appear. Each of those has exactly one author, and they work for you.

The part of the estate only your people can describe

Ask an application owner what a bad day looks like on their system, and the answer comes back fluent, specific and completely undocumented: the refund path that should never run twice against one order, the export function with a normal volume and a normal set of users. It is local knowledge, held by whoever has watched the system longest.

The same conversation with a platform engineer produces the non-human identities. An estate accumulates them faster than its inventory gets updated, because each one is created to solve a problem in front of somebody, and the register entry is a separate act that somebody else performs later. Each carries a history: what it was created for, whether that reason still holds, what it should never be seen doing. That last part is the detection. A service account that reads one database every night and then one evening enumerates a file share has stepped outside its own history, and that history lives in your estate.

Written down, the estate-specific layer sorts into a handful of groups.

• Applications your organization built, and the sequences through them that mean something is wrong. An approval taken out of order, a refund against a closed account, a bulk export by a user who has never run one. These become correlation rules written against the datasets those applications land in.
• Non-human identities, with the reason each one exists recorded beside it, down to the API key issued to a supplier during a project that has since closed.
• Business process abuse shaped by how your organization works. Fraud in your ordering system runs through steps that exist only in your ordering system.
• The exceptions your organization granted and then kept. A legacy protocol permitted on one segment, a network path opened for one supplier, a policy carve-out still in force three reorganizations later.

A system only your company runs can only be described by the people who run it.

What the three engagements had in common

The post-deployment detection work on three Cortex XSIAM deployments is what CWS is drawing on here. Those three sat in different verticals at very different levels of in-house maturity, and the estate-specific half looked close to identical in all of them.

In each one, the layer existed before anyone wrote it down. It sat with application owners, platform engineers and one or two long-serving analysts, all of them outside the security team's regular meetings. The first deliverable was a written list, and producing it took interviews before it took engineering. Those interviews go outside security by necessity: the head of the finance systems team is the one who knows which transaction sequence should never appear. Turning what that person knows into a rule an engineer can maintain is where most of the effort goes, and a schedule that budgets the work as engineering will be wrong by the width of the interviews.

A few patterns held in all three.

• The list was shorter than the team expected once it was on paper, and long enough that it needed a schedule of its own.
• Ranking it was a business decision. Which systems the organization cannot afford to have quietly misused is a question that belongs above the engineering team.
• The layer arrived unowned. In each of the three, a name went against it only once one had been written into the operating model.
• The rationale mattered more than the logic. A rule carrying one sentence about why it exists gives the next engineer something to weigh against the noise it makes on a bad day, and that sentence decides whether the rule gets tuned or switched off.

The order the list goes in

The order matters more than the pace. A list worked in capture order spends its first quarter on whatever the most talkative interviewee raised.

The sequencing below, and the argument that ownership of this content sits inside the security team, are CWS positions. The ranking turns on what your organization would find hardest to explain afterward, so argue about it with the people who own the systems.

• Start where the money moves and where the regulated data sits. Payment paths, payroll, the systems holding customer records a regulator can ask about. The threshold for what counts as worth looking at belongs far lower here than anywhere else.
• Take the non-human identities next. They are well defined and their normal behavior is narrow, and a rule written against narrow behavior needs less maintenance than one written against human variety.
• Then the applications you built that customers or regulators can see. Their sequences are harder to specify, and specifying them is where the interviews pay for themselves.
• Then the granted exceptions. Part of the value arrives before any content does, when somebody has to write down why the exception still exists and discovers the reason expired two years ago.
• Leave the long tail unwritten on purpose, and record the date you decided to. An undocumented decision to skip something reads a year later as an oversight.

What the waiting costs, and when the bill arrives

The failure mode is a quiet one, which is why the work waits. The platform runs, issues arrive grouped into cases, analysts work them, and the Analytics BIOCs do their job on schedule. The estate-specific list moves from one quarterly plan to the next, and each quarterly plan has a louder item at the top of it.

Picture the cost landing, because it lands once and it lands late. An intrusion runs through the internal application. The investigation reconstructs it afterward and the timeline is complete: every step was recorded, parsed and stored exactly as configured. The line that would have made it actionable at the time is the one saying that this sequence, on this system, was worth waking somebody for. The example above is a construction, built to state the argument in one scene. The delivery CWS claims in this article is the three deployments described earlier.

The prevention is unglamorous. It is ownership, written down.

• A named owner for the list, with time on their calendar for it. Collective ownership by the security team puts the list at the bottom of four separate personal queues.
• A rationale line against every entry, in the words of the person who asked for it. Logic separated from its reason gets deleted in the first quiet quarter.
• A review trigger tied to change in the estate. An application going live, a migration completing, an acquisition closing, a supplier integration switched on.
• A record of what you left out, dated, with the reasoning beside it. That record is what makes it a decision when somebody reads it back.

Nothing breaks while this work is waiting, which is why it keeps waiting.

The half you are holding

The content that came with the platform will keep covering what every organization has in common, and it will keep getting better at it. The rest of the estate is yours to describe, and it was yours to describe before the platform arrived. That is the shape of the problem, and it sits inside your organization because that is where the knowledge sits.

In those three deployments, two conditions went with the description getting written: one person's name against the list, and a decision from somebody above them about which entries came first. The size of the security team varied widely across the three. Settle the two conditions and the engineering is the easy part.