The Source Count Went Up. The Detection Count Runs on a Different Clock.

One of these two jobs has a finish line

Treat the pairing in the title as an illustration. The claim is about shape, and CWS is reporting no ratio: a source list that grew every sprint, and a set of rules of your own that grew when somebody had a quiet week.

Connecting a source has a definition of done a project manager can verify. The broker or the collector is configured, the data arrives, it parses into the fields the data model expects, the ticket closes. Writing a rule that reads that source ends when somebody decides it is good enough. You can write one that fires within the hour. Whether an analyst at two in the morning can act on what lands in the queue gets answered over weeks of real volume, and by then the source list has moved on without it.

Cortex XSIAM is built to work across every customer's estate at once, which is what a platform in this category is for. Analytics BIOCs are the vendor-authored side of it. Palo Alto Networks builds and maintains them, and they raise an issue, the platform's term for a detection that has fired, when behavior departs from a baseline the engine builds out of your own telemetry over time. The rules your team writes sit on the other side of that line: IOC rules, BIOC rules and correlation rules, each authored against your own estate. Which of your systems earns one, and in what order, is a judgment about your business and your threat model. That judgment belongs to the people who own the estate, and it is slower work than booking the change window was.

So the source count is what travels upward. It moves every week, anyone can verify it, and it sounds like coverage when it is read out. Detection engineering produces a number that moves in quarters, and the progress inside a quarter is hard to explain outside the team.

Count the sources with a named consumer, and put that number on the same page as the ingestion figure.

How the order gets inverted without anyone choosing it

The order inverts through ordinary pressures, each of them defensible on its own, and it becomes visible only once a year of them has stacked up. Read the five below as the mechanics of a program under normal load. Four of them are things a well-run program does on purpose.

• Onboarding is schedulable. A source has an owner in another team, a change window and a date. Once the window is booked the work happens, because a booked window is hard to move.
• Deferring sources during deployment is how deployment scopes are meant to work. The deferred list is real work with real value, and it lands at go-live as a queue with the ordering still to be done.
• The source list is the artifact everyone already has. It came out of the deployment, it is complete, and it doubles as a work queue. A detection roadmap starts on a blank page, written by somebody who understands the business.
• Detection engineering competes with the alert queue for the same three people, and the queue is loudest in the months right after cutover, which is exactly when the roadmap should be getting written.
• Steering committees ask what moved this month. Sources connected moves. A correlation rule rewritten twice because the first two versions flooded the case queue reads as churn in a status deck.

What the gap costs while it stays open

Storage is the cost people reach for first, and it is the least interesting of the three, because it is visible: somebody can see the line, ask about it and decide. The two that do more damage stay invisible by construction, and they compound for as long as the gap stays open.

A source that arrived ahead of its roadmap entry is still doing part of a job. Analytics BIOCs may well be reading it, and telemetry from one more source can improve the accuracy of what they already detect. The part still owed is the one your own team was going to write, and the three costs below are what that debt is made of.

• Storage is a scoping decision your program makes. Data the organization ingests is data it keeps and pays to keep, and that conversation belongs in planning. Where it gets held instead is a finance review, with the decision already taken and the bill already running.
• The second cost is assurance resting on the wrong check. Someone asks whether you have visibility into a system, the check performed is whether the log arrives, it does, and the answer goes back as yes. What that answer covers is whatever Analytics BIOCs already detect, now with one more source feeding them. The specific behavior the question was about is a separate question with a separate answer, and it went unasked.
• The third is silent decay. The system gets upgraded, the log format shifts, a field gets renamed, and the parsing stops mapping into the data model. A source with a rule of your own on it announces the change within a day: the rule floods or falls silent, and somebody investigates. A source whose only reader is vendor-authored content surfaces the change more slowly, because surfacing it depends on somebody noticing a shift in volume.

Ordering onboarding by the detection that will consume it

This ordering comes out of three Cortex XSIAM deployments where CWS did the post-deployment work. Different verticals, different levels of in-house maturity, and in each of them the useful move was the same one: start from the detection you intend to run, work backward to the sources it needs, and onboard in that order.

Ingestion is the half with a definition of done, and it reaches it. The half with no finish line is written by your people, against your estate, and it is the half that needs an owner and a date.

That runs against the instinct, because the source list is already on the shared drive and the detection roadmap starts blank. Writing the roadmap is a week of work with a security lead and whoever knows what the business runs on, and it produces the one thing the source list omits: a reason each source is being connected this quarter.

The rule that carries it through the year is that every source gets a named consumer before it gets a change window. Five things count as a consumer, and the first is the one people forget to write down: Analytics BIOCs. They read what is onboarded, their coverage and accuracy improve as more of the estate reaches them, and they cost your team no authoring. That improvement accrues across a quarter. Palo Alto documents a floor of telemetry before the engine initializes at all, endpoint or network logs from at least thirty endpoints across at least two weeks, or at least five days of cloud audit logs, followed by a baseline period. After that come a rule your own team intends to write, a required report, an investigation path an analyst walks, and a retention obligation somebody can point at. Any of the five is a legitimate answer, and the answer goes in the field before the ticket moves.

Onboarding sequence, detection ownership and post-deployment reporting are CWS positions, recorded as opinion with no measurement behind it. They come down to four moves.

• Write the detection roadmap against the systems the business runs on and the paths an attacker would take through them. It will be short at the start, which is the correct length for something written from evidence.
• Work backward from each entry to the sources it needs, and mark the sources that serve more than one entry or that also feed Analytics BIOCs. Those go to the front of the queue.
• Onboard the source and stand up its consumer inside one piece of work, with one owner and one completion date. Splitting them across two teams and two quarters is what opens the gap in the first place.
• Where Analytics BIOCs are the only consumer, write that in the field and move on. Where the field is empty, park the source and record why. A parked source with a reason against it is a decision the program made, and a decision can be reopened by another one.

A source with an empty consumer field still costs storage every month, and the bill is the only place it appears.

If the order already inverted

If you are reading this some way past the start, the picture is a running platform, a long source list, a set of correlation rules that has not kept pace, and a reasonable question from a finance review about what all of it is doing. The recovery is duller than the prevention, and it opens with an uncomfortable hour.

Sort the source list in one room with the people who know the estate: sources with a rule of your own reading them today, sources with a rule already scheduled, sources carried by Analytics BIOCs alone, and sources for which nobody present can name any consumer at all. The last group is where the discomfort lands, and that discomfort is most of the value of the exercise.

Then change the number you report. A source count answers a question about the platform. What belongs in front of a steering committee is how many connected sources carry a named consumer, and which rules of your own came online this quarter against which systems. That number falls when a new source connects, which is uncomfortable the first time and is the number behaving correctly.

This is an argument about sequence inside your own program, and about which half of the work gets the attention the other half gets automatically. Three moves close the gap.

• Work the unnamed group on the spot. Retention obligations stay. Investigation paths that only matter after an incident stay, with the reason recorded next to them. What remains is a genuine choice, and a program able to make it in the meeting has its arms around its own estate.
• Pair every open onboarding ticket with the detection work that will consume it, under one owner and one date.
• Report coverage as connected sources with a named consumer, and hold that measure steady for four quarters so the trend means something.

The half of the work with no finish line is the half that needs the owner and the date.