Три часа ночи. В окне дежурного — очередь событий, и одно подсвечено красным: успешный вход в учётную запись сотрудницы отдела продаж. Логин верный, пароль верный, страна — не та, где стоит офис. Время входа — 03:12 по местному времени, когда в офисе никого нет.

Аналитик не знает главного. Может быть, она в отпуске и зашла с телефона. Может быть, пароль подобрали и сейчас читают её почту. Может быть, ошиблась геолокация: сервис иногда определяет не ту страну, если подключение идёт через мобильного оператора или корпоративный VPN. Все три версии правдоподобны, а данных, чтобы выбрать одну, нет.

И всё же решение принимать нужно сейчас, потому что от него зависит не «кто прав», а конкретное действие: заблокировать учётную запись и разбудить дежурного инженера или отложить проверку до утра. Ошибиться здесь можно в обе стороны, и обе ошибки чего-то стоят: промедление может обернуться утечкой, а лишняя блокировка — сорванной работой и раздражением коллег. Именно в этот момент видно, чем на самом деле является работа в центре мониторинга: не погоней за хакерами, а выбором в условиях, когда информации всегда меньше, чем хотелось бы.

Сцена не про конкретную компанию. Похожее происходит каждую ночь в любом центре мониторинга — меняются имена, адреса и системы, но не суть. Поэтому дальше будем разбирать не исключительный случай, а обычную смену: с её очередью, усталостью и вечной нехваткой данных.

Почему SOC — это процесс, а не комната с экранами

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

Аббревиатура SOC расшифровывается как security operations center, центр мониторинга и реагирования. Но важнее расшифровки другое: SOC — это не помещение и не набор программ, а повторяемый процесс. Он состоит из нескольких шагов, и каждый из них обязателен: собрать данные о том, что происходит в системах, заметить среди них необычное, оценить, насколько это опасно, отреагировать и записать, что сделал и почему.

Если этот цикл повторяется каждую смену одинаково, центр работает. Если он держится на героизме одного сильного специалиста, центр разваливается в первый же его отпуск. Разница не в талантах, а в том, что процесс не зависит от настроения и самочувствия конкретного человека.

Зачем всё это нужно? Угрозу дешевле заметить раньше, чем она станет ущербом. Пока чужой вход в систему — это строчка в журнале, с ним можно работать спокойно: проверить, заблокировать, сменить пароль. Когда тот же вход превратился в выгрузку базы клиентов, вариантов остаётся мало, и все они дорогие: уведомлять людей, объясняться с регулятором, восстанавливать репутацию. Мониторинг покупает компании время, а время в инциденте и есть главный ресурс.

Проще всего представить приёмное отделение больницы. Врач не ставит окончательный диагноз первому вошедшему и не пытается вылечить всех сразу. Он смотрит, кому плохо прямо сейчас, кого можно подождать, и передаёт тяжёлого профильному специалисту. Дежурный SOC устроен так же: он не обязан знать всё, он обязан правильно расставить порядок. Второй образ — пост охраны в здании: человек не задерживает всех подозрительных, он смотрит на движение и реагирует, когда что-то не совпадает с обычным распорядком.

Из этого следует неочевидная вещь. Сила центра мониторинга измеряется не тем, сколько атак он «поймал», а тем, насколько предсказуемо он работает в три часа ночи, когда никто не в форме и все устали. А начинается эта предсказуемость с входа: с событий, которые приходят в систему.

Откуда берутся события и почему их слишком много

Событие — это запись о том, что что-то произошло. Серверы рассказывают, кто вошёл в систему, какая программа запустилась и какие права попросила. Сайт фиксирует, кто и с какими параметрами обратился к странице. Антивирус на устройствах сотрудников отмечает файлы, которые показались ему подозрительными. Сеть добавляет картину соединений: межсетевой экран и прокси знают, кто с кем и куда ходил. Каждый источник пишет по-своему, своим форматом, в своём месте, и по отдельности почти бесполезен.

Поэтому журналы сводят в одно место. Система, которая забирает их из источников, приводит к общему виду и прогоняет через правила, называется SIEM. Правило — это фактически вопрос, который инженер заранее задал машине: «покажи случаи, когда вход в учётную запись произошёл из страны, где у компании нет сотрудников» или «покажи, как обычный сотрудник повысил себе права». Когда данные совпадают с вопросом, система создаёт оповещение — алерт, и он попадает в очередь к аналитику.

Звучит разумно, но здесь и начинается главная проблема профессии. Правил таких много, и каждое написано с запасом, чтобы не пропустить худшее. А поведение людей в компании разнообразно: кто-то работает из отпуска, кто-то меняет часовой пояс, кто-то ночью запускает обновление сервера. В результате большая часть алертов оказывается ложными срабатываниями, и настоящая работа состоит не в том, чтобы найти атаку, а в том, чтобы не утонуть по дороге к ней.

Важно. Ложное срабатывание — не поломка и не признак плохого специалиста. Это нормальная плата за попытку заметить ненормальное: правило, которое ловит редкое, неизбежно ловит и просто необычное. Проблема начинается не от шума, а от привычки.

Привычка — главный риск. Если человек в сотый раз видит одно и то же оповещение, ему всё труднее смотреть на него внимательно, и однажды он закроет не глядя то единственное, которое было настоящим. Есть и противоположная крайность: инженер устал от шума и добавил столько исключений, что правило перестало видеть реальные случаи. Настройка правил, или тюнинг, — это поиск баланса между двумя способами потерять бдительность, и занимает он больше времени, чем принято думать.

Вернёмся к ночному алерту. Вход из другой страны — как раз шумный сценарий: он срабатывает на командировки и на VPN. Именно поэтому от аналитика ждут не догадки, а действия по порядку: проверить, кто такой пользователь, заходил ли он раньше с этого адреса, где он должен быть по календарю, что говорит его руководитель. Часть этих ответов придёт из журналов, часть — из разговора с людьми. И вот тут становится видно, зачем в центре мониторинга несколько линий.

Три уровня, или как растёт самостоятельность

Линии в SOC различаются не «крутостью» и не количеством выученных команд, а тем, сколько неизвестного человек берёт на себя. Это важное различие: на первой линии работают не «неудачники, до которых не дошло», а люди, которые держат поток и отсекают то, что не требует разбора. И горизонт у линий разный: одни отвечают за сегодняшнюю очередь, другие — за то, что в эту очередь пока не попало.

Первый уровень занимается триажем, то есть быстрой сортировкой. Он смотрит на оповещение и по инструкции отвечает на несколько простых вопросов: что за система, кто пользователь, похоже ли это на то, что уже было раньше, есть ли сценарий действий для такого случая. Типовое закрывает сам по готовому сценарию — это не унижение, а экономия времени: тратить полчаса на случай, который описан инструкцией, значит отнимать эти полчаса у настоящего инцидента. Всё непонятное он передаёт выше. Ключевой навык первой линии — не «разобраться любой ценой», а вовремя понять, что дальше без посторонней помощи не продвинуться.

Второй уровень разбирается вглубь. Он строит гипотезы и проверяет их: действительно ли пользователь в отпуске, что ещё происходило на его устройстве, связан ли этот вход с другими событиями в той же подсети, не появилось ли похожих случаев у коллег. Он общается с администраторами, потому что часть ответов лежит не в журналах, а в настройках и в головах людей. Он же настаивает на блокировке учётной записи, смене пароля или изоляции машины, а потом пишет вывод так, чтобы его поняли и инженер, и руководитель.

Третий уровень начинает не с оповещения, а с вопроса. «Если бы я хотел забрать данные из этой компании и не попасться, что бы я сделал?» Дальше он проверяет по журналам, видно ли это, — и часто обнаруживает, что видно плохо. Такая работа называется охотой за угрозами. Кроме неё на третьем уровне живут сложные расследования, настройка правил и обучение первой линии: человек, который научил дежурного отличать шум от сигнала, приносит больше пользы, чем человек, который просто закрывает больше всех заявок.

Получается, что рост здесь — это рост зоны неопределённости. Первый уровень работает с известным: есть инструкция, есть ответ. Второй — с вероятным: есть гипотезы, которые надо проверить. Третий — с неизвестным: надо самому придумать, где искать. Поэтому опытного аналитика узнают не по тому, сколько инструментов он перечислит, а по тому, можно ли отдать ему задачу без готового ответа.

Как проходит смена: очередь, приоритеты и разговоры

Смена начинается с передачи дел. Предыдущий дежурный рассказывает, что открыто, что ждёт ответа от инженеров, что выглядит странно, но пока не доказано. Если этого не сделать, следующий человек начинает с нуля и теряет именно то время, которого в инциденте всегда не хватает. Поэтому передача — не формальность, а способ не изобретать заново то, что уже знала предыдущая смена.

Дальше — очередь. Она почти никогда не обрабатывается по порядку поступления. Приоритет зависит от того, что быстрее может стать ущербом: критичная система важнее личного ноутбука, данные клиентов важнее внутренней переписки, признаки того, что чужой уже действует, важнее того, что он только стучится в дверь. Всё остальное ждёт, и это нормально. Умение отложить несрочное — часть профессии, а не её отсутствие.

Эскалация тоже устроена сложнее, чем кажется со стороны. Плохая выглядит так: «там что-то странное, посмотри». Хорошая содержит контекст: что произошло, что уже проверено, что исключено, что подозревается, что предлагается сделать. Разница здесь не в вежливости, а в скорости: хорошая передача экономит второму человеку часы, плохая заставляет его начинать сначала и заново проходить весь путь.

И ещё одна часть смены, о которой почти не говорят в описаниях вакансий, — разговоры. С инженером, когда нужны логи, доступ или блокировка. С руководителем, когда надо объяснить риск без технического жаргона: «учётная запись сотрудника, вероятно, в чужих руках, мы её заблокировали, нужно решить, кого предупредить». С самим сотрудником, когда надо не обвинить человека, а попросить сменить пароль и проверить устройство. Каждый из этих разговоров требует своей интонации, и ошибиться в ней так же дорого, как ошибиться в анализе.

Поэтому едва ли не половина работы — это письменная речь. Отчёт за смену, описание инцидента, разбор после него. Правило, которое не записали, не существует для следующей смены. Вывод, который не сформулировали, невозможно проверить. А красивый «подвиг» без записи через неделю не отличить от случайности — и тогда непонятно, можно ли на него опираться.

Ночной случай из начала статьи закончился к обеду следующего дня. Учётную запись заблокировали, пароль сменили, а потом нашли причину: за неделю до этого сотрудница открыла письмо от «службы доставки» и ввела пароль на странице, которая лишь выглядела знакомой. Никакого взлома в киношном смысле не было — была чужая страница, чужой пароль и три часа ночи, в которые кому-то пришлось принимать решение.

Что нужно уметь и как войти в профессию

Навыки для этой работы выглядят скромнее, чем ожидают, но каждый из них закрывает конкретную дыру в рассуждении. Начнём с сетей. Аналитик видит строку вроде «соединение с адреса 10.0.3.15 на порт 443» и должен мгновенно понимать, кто здесь клиент, а кто сервер, внутренний это адрес или внешний, нормально ли, что сотрудник ходит на этот порт, и не является ли «подозрительный внешний адрес» обычным прокси компании. Без этих знаний разбор превращается в угадывание по названиям, а угадывание в три часа ночи почти всегда ошибается.

Второе — операционные системы, прежде всего Linux и Windows. Не на уровне администратора, а на уровне уверенного пользователя: где лежат журналы, как найти в них нужную строку, что такое права и почему запуск программы от имени сервисной учётной записи — это отдельный сюжет. Третье — чтение логов как отдельный навык: замечать несоответствия, а не просто просматривать текст. Пользователь вошёл в семь утра, а его ноутбук в это время был выключен? Такого не бывает, и именно на таких мелочах держится анализ.

Четвёртое — язык описания атак. Есть открытая база техник, которую называют MITRE ATT&CK: в ней собраны способы, которыми злоумышленники получают доступ, закрепляются в системе, крадут данные. Аналитику она нужна не для экзамена, а чтобы говорить с коллегами на одном языке и проверять, какие техники вообще видны в его компании, а какие проходят мимо. Пятое — английский: значительная часть документации и описаний угроз выходит на нём, и ждать перевода можно дольше, чем длится атака. И шестое, самое недооценённое, — письменная речь. Короткий точный текст про инцидент ценится выше, чем красивая догадка, потому что на него опираются другие люди.

Теперь о входе. Первое, что действительно помогает, — домашняя лаборатория. Виртуальная машина, на ней открытая SIEM, в неё собираются журналы с вашего же компьютера, и дальше вы смотрите, как обычные действия выглядят в данных. Потом устраиваете учебную атаку на собственную машину: например, имитируете подбор пароля к собственному серверу и проверяете, появилось ли событие, сработало ли правило, что в журнале осталось. Такое упражнение даёт то, чего не даёт чтение: понимание, как выглядит атака с точки зрения того, кто её должен заметить.

Второе — два-три разобранных кейса. Не «я прошёл материал», а «вот событие, вот какие версии я рассматривал, вот что проверил, вот что подтвердилось, вот что сделал бы иначе». Такие записи на собеседовании весят больше списка инструментов, потому что показывают ход мысли. Третье — стажировка в центре мониторинга: настоящая очередь, настоящие ложные срабатывания и наставник, который поправит. Именно там становится ясно, выдерживаете ли вы темп, и это честнее любых курсов.

И последнее, что стоит сказать прямо. График в SOC часто сменный, включая ночные смены, а работа поначалу однообразная. Первые месяцы человек в основном сортирует поток и учится не спешить. Ночные смены сбивают сон, рутина выматывает, и выгорание здесь — не выдумка авторов вакансий, а реальный риск. Он снижается, если в компании есть нормальная передача смен, ротация и возможность перейти на другую линию, и повышается, если «героизм» считается нормой. Это стоит выяснить на собеседовании раньше, чем соглашаться.

Главная мысль

Работа аналитика SOC — это не про героизм и не про спасение мира в одиночку. Это про дисциплину: собрать данные, заметить необычное, оценить по порядку, отреагировать и записать. Каждый шаг скучен по отдельности и незаменим вместе. Именно поэтому сильный центр мониторинга выглядит не как место, где работают гении, а как место, где даже в три часа ночи решение принимается по понятной логике.

Второе, что стоит унести из этой сцены: хорошее решение не обязано быть правильным. Аналитик, который заблокировал учётную запись и ошибся, потерял рабочий вечер сотрудницы, но сохранил возможность разобраться. Аналитик, который не сделал ничего и ошибся, потерял данные. Профессия устроена так, что при нехватке информации выбирают не «идеальный» вариант, а тот, цена ошибки которого меньше, — и записывают, почему выбрали именно его. Записанное обоснование превращает ошибку в опыт, а незаписанное — в повод для разноса.

Поэтому SOC и держится на процессах. Процесс не делает людей умнее, но он не даёт им забыть то, что они уже знают, устать в самый неподходящий момент или решить важное дело наспех. Технологии меняются, инструменты устаревают, а привычка действовать по порядку и объяснять свои решения остаётся.

Что делать дальше. Если хочется проверить, ваша ли это работа, начните с плана входа в профессию и посмотрите, как устроена профессия целиком: SOC — лишь одно из направлений. Затем сравните его с другими в материале как выбрать направление и загляните в словарь, чтобы термины вроде SIEM и триажа перестали быть заклинаниями. Дальше решает практика: одна собранная своими руками лаборатория и два разобранных кейса весят больше, чем ещё один прочитанный текст.