Osquery/Fleet: видимость должна быть безопасной для хоста
Синтетический research-shot: схема проблемы, контроля, evidence и ретеста в фирменной лабораторной стилистике Virusologia.
Коротко: Хороший security visibility слой задаёт не только вопрос 'что можно спросить у хоста', но и 'какой ценой'. В зрелой среде инвентаризация, hardening и compliance-запросы отделены от тяжёлых ad hoc checks.

Проблема

User-formed queries и слишком агрессивные интервалы легко превращают visibility в источник деградации. Особенно это заметно на process/file/event tables и на флоте, где одна неудачная scheduled query уходит на тысячи устройств.

Вторая проблема - отсутствие ownership. Когда никто не отвечает за query pack, вопросы копятся, но никто не знает, какие из них реально используются, какие шумят, а какие уже дублируются другим telemetry source.

Решение

Полезно ввести query budget: таблица, примерный cost, интервал, target labels, владелец, expected use и критерий отключения. Это делает visibility управляемой инженерией, а не бесконечным списком SQL.

Для security teams важно различать inventory, compliance, incident triage и experiment packs. Тогда тяжёлые запросы не попадают в baseline, а необычные ad hoc checks не живут вечно в production schedule.

Что проверить руками

  • Разделить scheduled queries по классам: inventory, hardening, compliance, triage.
  • Проверить интервалы, target labels и необходимость evented tables.
  • Убрать редкие или дорогие запросы из global baseline.
  • Для каждого query pack назначить владельца и дату review.

Типичные ошибки

  • Пихать incident triage queries в общий baseline.
  • Оценивать полезность только по количеству таблиц, а не по ответам на реальные вопросы.
  • Не тестировать performance impact на разных типах хостов.

Defensive checklist

  • Есть query ownership и review date.
  • Heavy queries вынесены из baseline.
  • Intervals и label targeting соответствуют назначению пакета.
  • Есть тестовый хост/канарейка для новых паков.

Безопасный пример кода

Мини-pack с безопасным query budget. Пример рассчитан на owned/lab-среду и показывает инженерную логику проверки, а не эксплуатационную цепочку.

{
  "queries": {
    "listening_ports_inventory": {
      "query": "select pid, port, protocol, address from listening_ports;",
      "interval": 3600,
      "description": "Inventory of externally relevant listening ports",
      "platform": "linux,darwin,windows",
      "snapshot": true
    },
    "sshd_hardening_check": {
      "query": "select key, value from ssh_configs where key in ('PermitRootLogin','PasswordAuthentication');",
      "interval": 21600,
      "description": "Low-cost SSH hardening verification",
      "platform": "linux"
    }
  }
}

Как это должно попасть в отчёт

  • Visibility design: baseline packs, heavy packs, ownership, budgets.
  • Evidence: host class, query cost notes, target labels, false-positive/false-load notes.
  • Retest: new pack answers its question without measurable host degradation.
Этическая рамка: материал предназначен для defensive security, исследования собственных систем, controlled labs и подготовки remediation. Здесь нет вредоносных payload-цепочек, persistence-инструкций и шагов для несанкционированного доступа.