A platform team owning your Kubernetes audit feed wants their engineers' debug execs out of a report tagged with an adversary technique — how do you respond?
answer
- who actually owns the feed
- three different claims got conflated
- the report caused the harm, not the tag
- never accept a filtered stream
- make authorised work attributable
basics
~20 sConcede the report, not the label or the feed. A technique identifier is a taxonomy of what a rule looks for, and it should never appear beside a named engineer in a management report. Then remove the friction: give authorised execs an attributable path so they close themselves.
solid answer
~50 sThree things got conflated and separating them ends most of the argument: the rule's technique label, which describes the logic and stays; the outcome recorded on each firing, which said these were authorised; and what the SOC publishes outside itself, which is where the harm was actually done. Concede the third immediately — a monthly report to a director should carry counts and investigated cases, never named engineers under an adversary-technique heading. Do not concede the label or the feed, and say why: the platform team owns the audit stream and can withdraw it, so the trade you are making is report content for continued visibility. Then attack the cause. Agree a pre-declared break-glass path so authorised execs carry an attributable ticket reference, which lets most of them auto-close as benign true positives; narrow any sub-technique claim the rule cannot support down to the parent; and put a platform engineer on the rule as a named reviewer so the label is theirs too.
go deeper
Understand that the team producing a log source can stop producing it, and that a security team consuming someone else's telemetry depends on that relationship.
Be able to separate what a rule's label claims from what an individual firing turned out to be, and say which of the two belongs in anything published outside the team.
Show that you would fix the volume at source with an attribution path for authorised work, rather than suppressing the rule or arguing about the taxonomy.
Rank the demands: give away the report, hold the feed absolutely, and be explicit that a source-side exclusion for a privileged group destroys the detection you most need.
## Why this is hard, and why it is not really about labelling The technical content is small. The difficulty is that the party objecting **owns the telemetry**. In a multi-tenant Kubernetes platform the audit stream is configured, shipped and paid for by the platform team; the SOC consumes it. There is no technical way to compel a feed you do not own, so a relationship failure here costs you the visibility, not just the argument. And the objection is reasonable. An engineer who shelled into a payments pod at 02:14 to unstick a queue has now appeared in a document their director reads, under a heading naming an adversary behaviour. Nothing in the SOC's model says that person did anything wrong, but the document does not carry the SOC's model. ## Separate the three claims **The rule's label** says what the logic was written to catch. It is a statement about the query, not about any person, and it should not move because a firing turned out to be legitimate. Give this up and you lose the ability to answer "what do we have for this behaviour" across the rule set. **The outcome recorded on the firing** already said the right thing: the behaviour genuinely happened and it was authorised. That record exists and is what should reach anyone outside the SOC. **What the SOC publishes** is the thing that caused the harm. A report that lists individual firings, with names, grouped by technique identifier, is presenting rule metadata as if it were findings about people. That was a reporting choice, not a labelling necessity. ## What to concede Concede the report, quickly and without trading for it. Publish counts and trends, and name only investigated cases with an actual verdict. Nobody outside a detection team needs to see the technique taxonomy applied event by event, and no defensible purpose is served by it. ## What not to concede **Do not remove the label.** The rule is still a detection for that behaviour, and an intrusion using the same path is exactly what it exists to catch. **Do not accept a filtered feed.** "Send us everything except execs by the platform group" sounds like a compromise and is the worst possible outcome: an intruder using a platform identity is precisely the case you most need to see, and the filter is invisible in your own data. If you take one thing to a negotiation, take this. **Do not silence the rule for the group.** Same objection, moved one layer later. ## Fix the cause rather than the symptom Most of the heat comes from volume: a stream of firings that all resolve the same way and none of which are cheap to close. Reduce it at the source. - **Make authorised work attributable.** Agree that a break-glass exec is preceded by a declared change or carries a ticket reference — through an annotation, a dedicated purpose-bound identity, or a request path the platform team already uses. Firings that match a declared window close in seconds; firings that do not are now genuinely interesting, which is a better detection than you had. - **Narrow an overclaiming label.** If the rule was carrying a sub-technique its condition cannot distinguish, this is the moment to drop it to the parent. It is the one labelling change that is both a concession and correct. - **Make the platform team a stakeholder in the rule.** A named reviewer from that team on the rule turns "the SOC is watching us" into "this is our rule too," and they will improve it: they know which service accounts exec legitimately and which namespaces never should be touched. ## The judgment being tested An interviewer is watching for whether you can tell the difference between a demand that is *correct* (stop putting my staff in a report under an adversary heading), a demand that is *survivable* (narrow an overclaiming label), and a demand that is *fatal* (filter the feed). Weak answers either capitulate to all three to keep the relationship, or refuse all three on principle and lose the telemetry within a quarter. The strong answer gives away the report immediately, holds the feed absolutely, and spends the goodwill it bought on an attribution path that makes the next hundred firings cheap.
- They offer to keep sending the feed if you exclude execs performed by their on-call group. Do you take it?No, and this is the one point to hold absolutely. An intruder operating with a platform identity is the highest-value case that rule will ever see, and a source-side exclusion is invisible in your own data — six months later nobody remembers the carve-out exists. Offer anything else: report changes, joint rule ownership, a suppression you own and review, but not a filtered stream.
- The director asks why the technique identifiers disappeared from the monthly report. What do you say?That the identifiers describe what our rules look for, not what our colleagues did, and presenting them per-event with names implied an accusation the data never made. The report now carries detection volume, how many were investigated, and the verdicts of those investigations — which is the information a director can actually act on.
- How would you know the attribution path is working rather than just quieting the queue?Watch the ratio, not the volume. If declared-and-matched execs fall and undeclared ones stay flat, the path is being used and the residual is genuinely interesting. If total firings drop with no matching rise in declarations, someone has found a way to exec that the rule no longer sees, and that is a detection failure wearing a success's clothes.
saying these in an interview costs you the question
- Removes the rule's technique label to settle the argument
- Accepts a source-side filter to keep the feed
- Insists a taxonomy cannot offend anyone and changes nothing
- Escalates to leadership before offering an attribution path
- Suppresses the rule for the whole platform group