Когда компания только начинает проект по внедрению SIEM или подключению к SOC, разговор обычно крутится вокруг выбора вендора и сценариев корреляции. А вот о EPS (events per second) вспоминают редко. И зря: от этой метрики напрямую зависит эффективность обработки событий и, как следствие, надежность всей системы защиты.

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

В этом гайде мы разберем:

• почему компании полезно знать свой EPS;

• как этот показатель влияет на архитектуру SOC и стоимость лицензирования SIEM;

• как определить свой EPS без «угадывания на глаз» и ошибок в расчетах;

• и, наконец, что стоит спросить у провайдера SOC, прежде чем подписывать договор.

Зачем компании знать свой EPS

EPS — это не просто техническая метрика, а инструмент понимания «пропускной способности» SIEM. Он помогает понять, насколько эффективно SOC справляется с потоком событий и где проходят реальные границы производительности инфраструктуры.

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

На практике расчет EPS помогает решить сразу несколько задач:

1. Прогнозирование нагрузки. Каждая организация генерирует разное количество событий — от попыток входа в систему до сетевых соединений и срабатываний антивируса. EPS помогает оценить, сколько событий будет поступать в SOC и потянет ли инфраструктура такую нагрузку. 

2. Оптимизация бюджета. Услуги SOC и лицензии SIEM-систем часто тарифицируются исходя из уровня EPS. Точный расчет помогает выбрать оптимальный тариф и избежать двух крайностей: переплаты за избыточные мощности и недофинансирования, которое приведет к перегрузке систем. 

3. Минимизация рисков. Недооценка EPS приводит к «слепым зонам», когда часть событий не попадает в мониторинг и инциденты остаются незамеченными. В результате растут риски утечек данных, простоя бизнес-систем, финансовых и репутационных потерь.

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

Какие факторы влияют на EPS

На уровень EPS влияет не только количество подключенных систем, но и специфика самого бизнеса. Чтобы правильно оценить нагрузку на SOC, важно учитывать несколько факторов:

• Количество и тип источников событий. Каждый элемент инфраструктуры генерирует свой поток данных. Рабочие станции создают относительно небольшой поток событий, но их много. Серверы и сетевое оборудование формируют меньше логов, но каждый из них может быть критически важен. Дополнительную нагрузку вносят приложения — системы документооборота, почтовые сервисы, CRM, ERP, облачные платформы. Чем разнообразнее источники, тем выше итоговый EPS.

• Пики активности бизнеса. EPS почти всегда отражает ритм компании. В период сезонных пиков (например, распродажи в ритейле или квартальная отчетность в финансовом секторе) объем событий может вырасти в разы. Даже внутри дня нагрузка скачет: активность пользователей днем и ночью сильно отличается, и это тоже нужно учитывать при расчете.

• Внешние источники событий. Федеративные сервисы, облачные источники, удаленка, VPN-доступ, SaaS — каждый новый элемент инфраструктуры приносит новый поток логов.

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

Как рассчитать EPS: пошаговая методика

Шаг 1. Определите источники событий

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

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

Шаг 2. Оцените частоту генерации событий и их размер

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

Чтобы получить реальные значения, можно провести тест: направить потоки логов на коллектор (например, Windows Event Forwarding или syslog в Linux) и подсчитать количество событий за выбранный интервал.

Если SIEM разворачивается внутри компании, а не используется как внешняя услуга SOC, учитывайте не только количество событий, но и их размер: разные системы генерируют логи разного объема и по-разному нагружают инфраструктуру. 

Шаг 3. Рассчитайте базовый EPS

Формула:

Базовый EPS показывает, какую минимальную производительность SOC нужно обеспечить, чтобы обработка событий была своевременной и без задержек.

Шаг 4. Учтите пики нагрузки

В реальной эксплуатации нагрузка колеблется: рабочие часы, массовые обновления ПО, сезонные пики и инциденты могут резко увеличивать поток событий. Планируйте запас +20–30% к расчетному EPS.

Шаг 5. Сведите результаты в таблицу

На последнем этапе оформите расчеты в таблицу. Для наглядности приведем пример из нашего собственного проекта по подключению крупной организации (около 800 сотрудников) к SOC. Чтобы не перегружать таблицу, часть источников мы опустили, оставив только самые типичные.

В приведенном примере EPS составил 9421 событий в секунду. С запасом 30% для пиковых нагрузок получится уже около 12 200 EPS.

Теперь, когда базовые принципы расчета понятны, поговорим о том, как не наломать дров на практике.

Ошибки в расчете EPS и как их избежать

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

Учли только часть инфраструктуры

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

Не учли потенциальное расширение инфраструктуры

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

Неверно оценили емкости хранилищ

При расчете EPS часто фокусируются только на скорости обработки событий, забывая, что объем логов растет с течением времени. Планируйте емкость хранилища с запасом, чтобы сохранить возможность ретроспективного анализа и не потерять важные события при достижении лимита хранения.

Не учли специфику расчета EPS в выбранной SIEM

Даже при точных внутренних расчетах итоговые значения могут не совпасть с тем, как сам SIEM считает события. Некоторые решения учитывают только те логи, что дошли до коррелятора, а агрегированные или ненормализованные — игнорируют. В результате фактический EPS, отраженный в лицензии, оказывается ниже или выше ожидаемого. Чтобы избежать несостыковок и переплаты, уточняйте у вендора или SOC-провайдера, какие именно события участвуют в расчете EPS и как они обрабатываются внутри платформы.

Забыли про настройки журналирования

При расчете EPS на основе сетевых данных часто предполагают, что все рабочие станции, серверы или другие источники одного типа генерируют одинаковое количество событий. На практике настройки журналирования могут отличаться из-за разных политик аудита, уровней логирования или обновлений ПО. В результате фактический EPS для отдельных источников может оказаться выше или ниже расчетного. Чтобы избежать перекосов, сверяйте параметры журналирования и проверяйте данные выборочно на реальных логах.

Не сверили расчетный EPS с реальными данными

Теоретические оценки EPS без сверки с историческими логами часто дают завышенные или заниженные значения. Не забудьте сравнить расчетные данные с фактической активностью за последние 30–60 дней, чтобы выявить скрытые пики и корректно определить требования к SOC.

Чек-лист для клиента SOC: что спросить про EPS

1. Расчет EPS

   • Корректно ли мы рассчитали уровень EPS в нашей инфраструктуре? 

   • Как скорректировать расчет с учетом того, что со временем нагрузка вырастет, и поток событий увеличится?

2. Запас мощности

   • Какой запас по EPS нужно заложить в системе?

   • Что произойдет, если реальный EPS превысит договорный лимит?

3. Стоимость услуг SOC и тарифы

   • Будет ли стоимость услуг SOC зависеть от объема EPS?

   • Есть ли скрытые расходы при росте нагрузки (например, при пике событий из-за атаки)?

   • Насколько просто будет увеличить лимит EPS, если бизнес вырастет?

4. Критические источники событий

   • Какие источники (AD, почта, сетевое оборудование, облако) обязательно нужно включить в расчет EPS?

   • Что будет, если часть систем не подключить (например, Linux-сервера или IoT)?

5. Хранение и анализ логов

   • В течение какого срока должны храниться события?

   • Будет ли система предусматривать возможность анализа старых логов при расследовании инцидентов?

6. Практика реагирования

   • Что происходит, если SOC фиксирует резкий рост EPS (например, при атаке)?

   • Как быстро SOC реагирует на всплески нагрузки? Есть ли гарантии, что при пиковом EPS события не будут потеряны? 

Заключение

TL;DR:

• EPS — это количество событий в секунду, ключевая метрика для SOC и SIEM.

• Определяет нагрузку на SOC и стоимость услуг. 

• Рассчитывается по источникам событий, с учетом пиков и возможного расширения инфраструктуры в будущем.

• Ошибки в расчете → переплата или потеря данных.

Практические рекомендации:

• Начинайте с пилота: подключите часть инфраструктуры и измерьте фактический EPS.

• Работайте с вендором: уточните, как именно считается EPS для конкретной SIEM.

• Учитывайте не только события, но и правила корреляции — сложные запросы увеличивают нагрузку.

• Планируйте «горячее» и «холодное» хранилище событий (например, 3 месяца быстрый доступ + 1 год в архиве).

• Для SMB-компаний разумно использовать встроенные средства (например, Defender + базовый SIEM) с ограничением по EPS.

EPS — это не формальность и не «внутренняя кухня» SOC. Это метрика, от которой напрямую зависит, эффективность системы мониторинга. Чем точнее вы оцените её на старте, тем более предсказуемым будет поведение SIEM в боевых условиях. Грамотно рассчитанный EPS — это не просто экономия бюджета, а гарантия, что в критический момент система сработает, как должна.

Бастион — защищаем бизнес от киберугроз

t.me/bastiontech — делимся собственным опытом, экспертизой, результатами исследований и прогнозами