Python для SOC: сколько строк кода реально нужно до перехода к Sigma-правилам

Пересчитал конструкции Python в 14 скриптах, которые написал за последний год работы в SOC: от парсинга auth.log до автоматического обогащения алертов через API AbuseIPDB. Ровно 18 уникальных конструкций покрывают все 14 скриптов — циклы, словари, requests, re, json. Ни одного класса. Ни одного декоратора. Ни одного генератора. При этом каждый скрипт экономит от 20 минут до 4 часов за смену. Ниже — конкретный разбор: какой минимум Python-синтаксиса действительно нужен аналитику, как выглядит рабочий скрипт автоматизации и в какой момент Python пора менять на Sigma-правила.

Почему для автоматизации в SOC не нужен полный курс Python

Типичная ошибка при входе в ИБ из смежной сферы — открыть учебник по Python и начать с ООП (объектно-ориентированное программирование — стиль кода, где всё строится на классах и наследовании). Через неделю наступает ступор на абстрактных классах, человек решает, что «программирование — не моё», и закрывает тему. Но Python для аналитика SOC — это не разработка ПО.

SOC-аналитик пишет не приложения, а «клей» между инструментами: вытащил логи из SIEM (Security Information and Event Management — система, которая собирает и коррелирует события безопасности со всей инфраструктуры), прогнал IP через репутационную базу, записал результат в тикет. По данным TechTarget, аналитики без навыков скриптования тратят 70–80% смены на ручной триаж ложных срабатываний. А согласно отчёту IBM X-Force 2025, атаки с использованием действительных учётных данных — техника Valid Accounts (T1078) из MITRE ATT&CK (открытая база тактик и техник атакующих; T-коды вроде T1078 — её идентификаторы) — выросли на 71% год к году. Объём алертов растёт быстрее, чем штат. Ручная обработка масштабируется ровно до момента, когда аналитик выгорает.

По данным Verizon DBIR 2025, 38% утечек связаны с кражей учётных данных, а 36% инцидентов начинаются с фишинга (T1566, Initial Access). Каждый такой инцидент генерирует десятки алертов. Без скриптов разгрести этот поток — нереально.

Python в SOC — это не про «выучить язык». Это про выучить 18 конструкций и начать писать.

18 конструкций Python для автоматизации логов — полный список

Каждая конструкция ниже привязана к конкретной задаче в SOC. Если чего-то нет в этом списке — для первых 6–12 месяцев работы оно не нужно.

Декораторы, генераторы, классы, метаклассы, asyncio — всё это можно добавить через год практики, когда появится потребность. По данным networkershome.com, шесть библиотек (requests, json, pandas, re, scapy, pymisp) покрывают 90% задач SOC-автоматизации. И каждая из них работает ровно на тех конструкциях, что в таблице.

Скрипт обогащения IP: автоматизация задач SOC аналитика за 25 строк

Самая частая задача на L1-дежурстве: SIEM выдал алерт с подозрительным IP, нужно проверить его репутацию. Вручную — открыть AbuseIPDB (сервис проверки репутации IP-адресов; бесплатный тариф — 1000 запросов в день), VirusTotal и Shodan в разных вкладках, скопировать IP, дождаться ответа, записать в тикет. По оценке networkershome.com, автоматизация одного такого цикла экономит 8–12 минут на алерт. При 150 алертах за смену — 4+ часа ручной работы. Скрипт делает то же самое за 3 секунды.

Предпосылки: Python 3.x установлен (на Kali/Ubuntu — уже есть, проверь python3 --version), установлен requests (pip install requests), нужен API-ключ AbuseIPDB (регистрация бесплатная), доступ в интернет.

import requests
import json

ABUSEIPDB_KEY = "your-api-key"  # заменить на свой

def enrich_ip(ip_address):
    url = "https://api.abuseipdb.com/api/v2/check"
    headers = {"Key": ABUSEIPDB_KEY, "Accept": "application/json"}
    params = {"ipAddress": ip_address, "maxAgeInDays": 90}
    resp = requests.get(url, headers=headers, params=params)
    data = resp.json()
    score = data["data"]["abuseConfidenceScore"]
    print(f"IP: {ip_address} | Abuse Score: {score}/100")
    return score

Что здесь происходит шаг за шагом:

1. import requests и import json подключают библиотеку для HTTP-запросов и работу с JSON. Если при запуске скрипт ругается ModuleNotFoundError: No module named 'requests' — выполни pip install requests в терминале.
2. ABUSEIPDB_KEY — API-ключ для аутентификации. Получить его просто: зарегистрируйся на abuseipdb.com, создай ключ в личном кабинете.
3. def enrich_ip(ip_address) — определяем функцию, которую можно вызвать для любого IP.
4. requests.get(url, headers=headers, params=params) — отправляем GET-запрос к API. Ожидаемый результат: HTTP 200 и JSON с полем abuseConfidenceScore.
5. data["data"]["abuseConfidenceScore"] — достаём числовую оценку от 0 до 100. Значение выше 75 — рекомендация к блокированию по документации AbuseIPDB.

Как понять, что получилось: при вызове enrich_ip("203.0.113.45") в терминале появится строка IP: 203.0.113.45 | Abuse Score: XX/100. Ошибка 401 — неверный API-ключ. Ошибка 429 — исчерпан лимит бесплатного тарифа (1000 запросов/день).

В этом скрипте — ровно 10 конструкций из таблицы. Ни одного класса, ни одного декоратора.

Python для парсинга логов: regex в auth.log и Windows Event ID

Вторая по частоте задача — вытащить из лог-файла конкретные события. Допустим, нужно найти все IP, с которых шли неудачные попытки SSH-авторизации. Это может быть признак Brute Force (T1110, Credential Access — техника перебора учётных данных). По данным CrowdStrike Global Threat Report 2025, 75% вторжений используют действительные учётные данные, а рекордное время lateral movement (перемещение по сети после первоначального проникновения) составило 51 секунду. Чем быстрее ты вычленишь источник из логов — тем больше шансов перехватить атакующего до эскалации.

Типичная строка в /var/log/auth.log: Jun 28 14:22:01 server sshd[12345]: Failed password for root from 185.220.101.50 port 22 ssh2. Чтобы вытащить все IP с неудачными попытками, хватит двух конструкций: with open() для чтения файла и re.findall() для поиска по шаблону.

Шаблон regex для IPv4-адреса после слова «Failed»: r"Failed.*from (\d{1,3}\.\d{1,3}\.\d{1,3}\.\d{1,3})". Функция re.findall() вернёт список всех найденных IP. Дальше Counter из стандартной библиотеки collections подсчитает количество попыток с каждого адреса. IP с 50+ попытками за короткий период — кандидат на блокирование или эскалацию на L2.

Для Windows — аналогичная логика, но вместо текстовых логов работаешь с Event ID. Ключевые ID для детекта брутфорса: 4625 (неудачная попытка входа) и 4624 (успешный вход; тип логона 3 — сетевой, 10 — RDP). Если SIEM экспортирует логи в CSV или JSON, написание скриптов для анализа логов сводится к json.loads() или .split(",") — тот же набор конструкций из таблицы.

Для работы с Linux-логами нужен доступ к файлу (обычно требуются права root или включение в группу adm командой sudo usermod -aG adm username). Для Windows-логов — экспорт из Event Viewer или запрос через API SIEM.

Переход от Python к Sigma-правилам: когда скрипт становится правилом

Вопрос, который задают все career-свитчеры: «Зачем мне Sigma, если я могу всё написать на Python?» Ответ — в масштабе и переносимости.

**Sigma** — язык описания детектирующих правил в формате YAML (текстовый формат для структурированных данных; если видел docker-compose.yml — это тот же синтаксис). Одно Sigma-правило конвертируется в запросы для Splunk (SPL), Elastic (KQL), QRadar (AQL) и десятков других SIEM. Python-скрипт привязан к конкретному формату данных и конкретному API.

По данным репозитория SigmaHQ на GitHub, только по технике T1110 (Brute Force) существует 40 готовых Sigma-правил. По T1078 (Valid Accounts) — 114 правил. Для типовых сценариев детекта Python-скрипт не нужен вовсе — бери готовое и адаптируй.

Правило перехода простое: если ты третий раз пишешь скрипт для одного и того же паттерна — пора формализовать его в Sigma-правило.

Sigma-правило для детекта брутфорса вместо Python-скрипта

Та же задача, что выше решалась regex-парсингом auth.log, — но теперь как Sigma-правило:

title: SSH Brute Force Detection
logsource:
    product: linux
    service: sshd
detection:
    selection:
        log_message|contains: "Failed password"
    condition: selection | count() > 10
    timeframe: 5m
level: medium
tags:
    - attack.credential_access
    - attack.t1110

Разберём по строкам:

1. logsource — указываем, что правило для Linux sshd-логов. При конвертации Sigma-конвертер подставит правильный sourcetype для конкретного SIEM.
2. detection.selection — ищем строки с «Failed password». Тот же паттерн, что и в Python-regex, но без кода.
3. condition: selection | count() > 10 с timeframe: 5m — срабатывание, если за 5 минут больше 10 совпадений. Порог 10 — стартовый; на практике его придётся подкрутить под свою инфраструктуру, потому что на публичных серверах бывает и 100 попыток в минуту фонового шума.
4. tags — привязка к MITRE ATT&CK: T1110, Credential Access. Любой аналитик в команде сразу понимает контекст алерта.

Конвертация: sigma convert -t splunk rule.yml сгенерирует готовый Splunk-запрос. Для Elastic — sigma convert -t elasticsearch rule.yml. Одно правило — десять SIEM. Для скриптинга для детекта угроз на постоянной основе Sigma объективно удобнее, чем Python.

Практический маршрут: от нуля до рабочего скрипта за выходные

Если ты осваиваешь Python для кибербезопасности с нуля и переходишь в SOC из смежной сферы, вот конкретный план на два дня.

Суббота, 3 часа:

1. Установи Python 3.x. На Linux (Kali, Ubuntu) он уже есть — проверь python3 --version в терминале. Ожидаемый вывод: Python 3.11.x или выше. На Windows — скачай с python.org, обязательно отметь галку «Add to PATH» при установке, иначе терминал не найдёт команду python.
2. Открой терминал, набери python3. Попробуй первые 5 конструкций из таблицы: задай переменную (ip = "8.8.8.8"), создай список (ips = ["8.8.8.8", "1.1.1.1"]), пройди по нему циклом (for addr in ips: print(addr)). Если в терминале появились оба адреса — всё работает.
3. Напиши скрипт из 5 строк: открой текстовый файл (with open("test.log") as f), прочитай строки (for line in f), выведи те, где встречается слово «Failed» (if "Failed" in line: print(line)). Создай тестовый test.log с парой строк — убедись, что фильтрация работает.

Воскресенье, 3 часа:

1. Установи requests: команда pip install requests в терминале. Ожидаемый вывод: Successfully installed requests-2.x.x.
2. Возьми скрипт обогащения IP из раздела выше. Подставь свой API-ключ AbuseIPDB. Запусти: python3 enrich.py. Ожидаемый вывод: строка с Abuse Score.
3. Добавь цикл: пусть скрипт читает список IP из файла ips.txt (по одному на строку) и проверяет каждый. Это 3 дополнительные строки: with open("ips.txt") as f, for line in f, enrich_ip(line.strip()).

Результат: два рабочих скрипта за 6 часов. Ни ООП, ни декораторов, ни asyncio.

Дальше — практика на учебных логах. SOC-датасет для тренировки: Boss of the SOC (BOTS) от Splunk — бесплатный набор данных с реальными сценариями атак. Скачиваешь, загружаешь в Splunk Free (лимит 500 МБ/день — для обучения хватает) и пишешь Python-скрипты для парсинга лог-файлов. Через месяц ежедневной практики будешь готов к написанию скриптов на рабочем месте. Через три — к формализации паттернов в Sigma.

Моя позиция может быть непопулярной: большинство курсов по основам Python для безопасности учат не тому. Они тратят недели на наследование и паттерны проектирования — вещи, которые SOC-аналитику на L1/L2 не нужны вообще. А потом выпускник приходит на дежурство и не может написать requests.get() к API, потому что три месяца рисовал UML-диаграммы.

За полтора года я видел десятки career-свитчеров — из сисадминов, из техподдержки, из QA. Те, кто начинал с таблицы «18 конструкций» и сразу писал рабочие скрипты, через 3 месяца автоматизировали половину рутины на смене. Те, кто «сначала выучу Python как следует» — через 3 месяца всё ещё читали главу про метаклассы и не написали ни одного полезного скрипта.

Граница между Python и Sigma тоже вызывает споры. Правильная точка перехода — не «когда освоишь Python», а «когда третий раз напишешь скрипт для одного и того же паттерна». Трижды парсил auth.log в поисках брутфорса разными скриптами — пора формализовать это в правило и забыть. Python останется для всего, что Sigma не покрывает: API-интеграции, отчёты, нестандартные расследования. Если хочешь пройти эту базу системно и не распыляться — на IB Basics как раз показывают, как джуны решают первые рабочие задачи в SOC.