// intermediate track

Intermediate

Инженерный уровень: api, secrets, containers, siem, sbom, dlp, tls fingerprints. Темы уровня: Cloud/Container / Network / Privacy / SOC / Secrets / Supply Chain / Web/API. Каждая карточка даёт назначение, риски, ручную проверку, частые ошибки и defensive-чеклист.

// method

Как проходить

Сначала понять протокол или риск, потом включать инструмент. Вести журнал действий: цель, команда, вывод, выводы, исправление. После каждой проверки формулировать критерий ретеста.
IntermediateWeb/API

API Security: inventory прежде сканирования

Стек: OpenAPI / HAR / auth roles

Методика проверки API через inventory endpoint-ов, ролей, object identifiers и бизнес-действий.

Развернуть практику

Зачем специалисту: Без карты API легко пропустить IDOR/BOLA, rate limits и скрытые administrative endpoints.

Какие риски закрывает: Доступ к чужим объектам, слабая авторизация, отсутствие лимитов, verbose errors.

Что проверить руками: Собрать OpenAPI или HAR своей тестовой системы и отметить endpoints: auth, account, billing, upload, admin.

Типичные ошибки: Проверять только unauthenticated surface, не иметь двух тестовых ролей, считать 403 достаточным доказательством.

Defensive-checklist

  • Минимум две роли
  • Object IDs в path/query/body
  • Read-only replay
  • Evidence без токенов и PII
IntermediateSecrets

Secrets scanning в коде и Git history

Стек: regex / entropy / SARIF

Как искать ключи, токены и connection strings без лавины ложных срабатываний.

Развернуть практику

Зачем специалисту: Один publish-токен или cloud key в истории Git способен превратить мелкую ошибку в полный supply-chain инцидент.

Какие риски закрывает: Утечка cloud credentials, webhook secrets, deploy keys, database URLs.

Что проверить руками: Проверить тестовый репозиторий, сравнить regex, entropy и allowlist-подход, затем подготовить процесс ротации.

Типичные ошибки: Удалить секрет из HEAD, но оставить в history; публиковать найденные токены в чат; не отзывать скомпрометированный ключ.

Defensive-checklist

  • Сканировать history
  • Редактировать evidence
  • Сразу отзывать ключ
  • Добавить pre-commit/CI gate
IntermediateCloud/Container

Docker security audit

Стек: Dockerfile / Compose / image scanning

Проверка контейнеров: base image, capabilities, user, secrets, volumes, network и update policy.

Развернуть практику

Зачем специалисту: Контейнер не является границей безопасности сам по себе; неправильный Compose часто открывает лишние привилегии.

Какие риски закрывает: Root внутри контейнера, docker.sock mount, секреты в image layers, открытые debug-порты.

Что проверить руками: Разобрать свой Dockerfile и compose-файл по checklist, убрать root и лишние capabilities.

Типичные ошибки: Класть .env в image, запускать privileged без причины, не фиксировать digest critical images.

Defensive-checklist

  • USER не root
  • read_only где возможно
  • no-new-privileges
  • secrets вне image
  • минимальная сеть
IntermediateSOC

SIEM dashboard: от логов к вопросам

Стек: logs / detection rules / dashboards

Как строить dashboard не ради графиков, а ради ответов: кто вошёл, что изменилось, где вырос шум, какие события требуют triage.

Развернуть практику

Зачем специалисту: Плохой SIEM показывает много данных, хороший помогает принять решение за минуты.

Какие риски закрывает: Пропущенные brute-force, lateral movement, privilege changes, unusual egress.

Что проверить руками: Составить 10 вопросов к инфраструктуре и под каждый выбрать источник логов, поле и порог.

Типичные ошибки: Собирать всё без нормализации, не иметь retention policy, делать alert на каждое harmless-событие.

Defensive-checklist

  • Inventory log sources
  • Нормализация полей
  • Runbook для alert
  • Review noise раз в неделю
IntermediateSupply Chain

SBOM и vulnerability matching

Стек: CycloneDX / SPDX / OSV

Как описывать состав приложения и связывать компоненты с уязвимостями, релизами и владельцами.

Развернуть практику

Зачем специалисту: Когда выходит новая CVE, команда должна быстро понять: используем ли мы компонент, где и в какой версии.

Какие риски закрывает: Невидимые transitive dependencies, устаревшие контейнеры, отсутствие владельца компонента.

Что проверить руками: Собрать SBOM для тестового сервиса, сопоставить с vulnerability feed и отметить владельцев пакетов.

Типичные ошибки: Хранить SBOM отдельно от релиза, не связывать с build artifact, игнорировать контейнерный слой.

Defensive-checklist

  • SBOM на каждый релиз
  • Связь с artifact digest
  • Owner для критичных компонентов
  • Периодический rescan
IntermediateNetwork

JA3/JA4 и TLS fingerprinting

Стек: TLS ClientHello / fingerprints

Понимание того, как TLS-метаданные помогают отличать обычные клиенты от необычного автоматизированного трафика.

Развернуть практику

Зачем специалисту: Даже при шифровании содержимого остаются метаданные, полезные для SOC и threat hunting.

Какие риски закрывает: Скрытый C2-трафик, нестандартные клиенты, массовая автоматизация под видом браузера.

Что проверить руками: На лабораторном трафике сравнить browser, curl и скриптовые клиенты по TLS fingerprints.

Типичные ошибки: Считать fingerprint доказательством вредоносности, блокировать без baseline и исключений.

Defensive-checklist

  • Собрать baseline
  • Коррелировать с SNI/DNS/UA
  • Не делать blind block
  • Хранить контекст расследования
IntermediatePrivacy

DLP scanner для чувствительных данных

Стек: PII / regex / classification

Как искать персональные данные, токены и конфиденциальные документы в файловых хранилищах без нарушения приватности.

Развернуть практику

Зачем специалисту: DLP нужен не для наказаний, а для понимания, где реально лежат данные и кто к ним имеет доступ.

Какие риски закрывает: Публичные backup, документы с PII, экспорт баз в общих папках, отсутствие retention.

Что проверить руками: Создать тестовый набор файлов и проверить правила классификации: персональные данные, ключи, договоры, dumps.

Типичные ошибки: Сохранять найденные PII в открытый отчет, сканировать production без согласованной политики.

Defensive-checklist

  • Redaction в отчетах
  • Минимизация доступа
  • Retention policy
  • Согласованный data owner
← все лабораториипрактические заметки →