- PVSM.RU - https://www.pvsm.ru -
Уже завтра стартует V SOC-Форум — крупнейшее мероприятие по практикам выявления и анализа инцидентов в России. Уверен, что многие читатели этого хаба окажутся там и услышат немало профессиональных докладов по этому направлению информационной безопасности. Но помимо терминов, определений и устоявшейся практики, которая освещается на SOC-Форуме, в реальной жизни каждый из вас наверняка слышал массу разных мнений о функционировании SOC, защите от APT-атак и т. д. Сегодня мы обсудим несколько популярных мифов и легенд.
Нам интересно и ваше мнение по поводу каждого из них, поэтому ждем ваших комментариев. Добро пожаловать под кат.
Очень часто, обсуждая с заказчиком комплексную защиту от внешних злоумышленников, мы слышим: «А у нас стоит железка А, она обогащена экспертизой вендора и информацией о новых угрозах, и она нас целиком защищает от внешних атак». И ладно, если бы после этих слов нам явили многомодульное Anti-APT-решение — вопросы бы остались, но их стало б куда меньше. Чаще же всего за этим «универсальным устройством» скрывается обыкновенный IDS, иногда с базовым функционалом анализа https-траффика. Мы не ставим под сомнение экспертизу вендоров в области кибербезопасности и их осведомленность о деятельности хакеров, как и полезность записи и анализа сетевого трафика (эта тема точно будет неоднократно подниматься на Форуме), но хотим, тем не менее, сделать акцент на ограничениях подхода, при котором SOC ориентируется только на события сети.
Одна из самых любимых нами легенд. Шутки про SOC, где работает всего 1 человек, поэтому он немного 1-ая, немного 2-ая и немного 3-я линия поддержки, уже заполонили интернет. Но очень многие заказчики, наслушавшись разных докладов и начитавшись статей, начинают говорить о том, что нужна волшебная железка/процедура/технология (нужное подчеркнуть), которая автоматизирует и решит все проблемы 1-ой линии. А поскольку зачастую в голове заказчика 1-я линия равнозначна режиму работы 24*7 (все остальные, как правило, работают уже по стандартному графику), это автоматически создает ощущение существенного снижения расходов на персонал и порождает разговоры в ключе «1-я линия не нужна, давайте начнем строить сразу со второй».
Ключевой проблемой этой легенды, на наш взгляд, является путаница в терминологии. Зачастую, когда докладчик говорит о 1-й линии, он руководствуется практиками ITIL, где действительно в руки операторов попадают атомарные задачи:
Когда речь идет о такого рода задачах, конечно, никакая выделенная первая линия не нужна: данные процессы хоть и непросто, но вполне автоматизируемы. Что мы со своей стороны понимаем под 1-ой линией, мы уже несколько раз писали – например здесь [2]). Все-таки 1-ая линия — это не замена автоматизации, и даже не команда, работающая исключительно по playbook. Это сотрудники пытливые и ищущие, хотя и обладающие лишь базовым навыком в анализе событий и расследовании инцидентов. В терминах ITIL такая линия бы называлась 2-й, что сразу снимает все вопросы и расхождения.
Не хотелось бы обойти стороной и вопросы 24*7. Про организацию смены, эффективность работы операторов и аналитиков в ночные часы, психологическую слепоту при просмотре событий сказано тоже достаточно немало. Интегральные выводы примерно те же – 1-ая линия SOC и круглосуточная смена становятся неэффективными и ненужными. Мы со своей стороны за долгие годы тоже испробовали разные методики и на текущий момент федеральный уровень SOC позволяет нам минимизировать риски усталости специалиста в ночную смену (критичный инцидент просто направляется в другой часовой пояс), тем не менее хотелось бы отметить несколько тезисов.
И в завершение — как бы далеко не зашла автоматизация, на любом критичном производстве принято оставлять специалиста, контролирующего ситуацию с машинами и роботами. И если ваша развилка в данном случае в том, «может ли автоматизация помочь мне не выделять 5–6 ставок на дежурную смену», то наш ответ однозначный: не может.
Чем больше ты занимаешься построением SOC или работаешь с MSSP/MDR-провайдером, тем больше хочется идеального. Сейчас очень много заказчиков прошли через огонь, воду и медные трубы первых самостоятельных подходов к снаряду или пилотов/контрактов с внешними поставщиками и все так или иначе пытаются стремиться к идеалу. А идеал в глазах руководителя/ответственного за внешний сервис обычно выражается фразой «каждое оповещение — это подтвержденный инцидент» или «мы следим не за подозрениями — мы фиксируем атаки». И с точки зрения ключевых аспектов эффективности сложно спорить с этим утверждением. Но, как всегда, дьявол в деталях.
Большинство SOC-ов нацелены на эффективный, максимально глубокий анализ инцидента по всей доступной информации. И они все сильнее приближаются к совершенству, когда у них есть возможность получать снаряды логи для нее. Разберем на примере инцидента по фактам срабатывания сетевых индикаторов вирусного ПО (адреса связи с центром управления) – для их выявления достаточно лишь какой-то информации по сетевым потокам в интернет, например, логов межсетевого экрана, но они довольно часто дают ложный результат. Достаточно злоумышленнику спрятать свой сервер управления ВПО на
Итого: чтобы SOC приблизился к возможности выявления исключительно атак, без ложных срабатываний, нам необходимо обеспечить максимальное покрытие инфраструктуры мониторингом — в идеале собирать ВСЕ журналы со ВСЕХ объектов.
Это приводит нас сразу к нескольким проблемам.
a. IDKFA – полного боезапаса в виде бесконечных серверных мощностей на сбор и хранение событий и, что с точки зрения экономики много печальнее, – бесконечных лицензий на SIEM и прочие инструменты SOC.
b. IDDQD – огромную и бессмертную команду SOC, которая в каждом инциденте сможет проанализировать все его явные и косвенные признаки.
Совпадение таких факторов, задач и объема бюджетов на информационную безопасность считается случаем встречи зеленого слона и поэтому не рассматривается как типовая ситуация в жизни SOC. А значит, выявление только подтвержденных атак (при всем желании анализировать максимально глубоко автоматическими инструментами) является чуть фантастической мечтой современных безопасников.
Мы постарались обсудить только наиболее частые мифы тематики SOCостроения. Поэтому в сложных заводях запуска процессов мониторинга и реагирования на инциденты советуем вам максимально скептически относиться к поступающей информации, верифицировать ее в разных источниках и максимально опасаться контрафакта неподтвержденных опытом суждений.
И да пребудет с вами Сила;).
Автор: Solar_JSOC
Источник [4]
Сайт-источник PVSM.RU: https://www.pvsm.ru
Путь до страницы источника: https://www.pvsm.ru/informatsionnaya-bezopasnost/337038
Ссылки в тексте:
[1] ранее: https://habr.com/ru/company/solarsecurity/blog/469235/
[2] здесь: https://habr.com/ru/company/solarsecurity/blog/350474/
[3] хостинге: https://www.reg.ru/?rlink=reflink-717
[4] Источник: https://habr.com/ru/post/476006/?utm_source=habrahabr&utm_medium=rss&utm_campaign=476006
Нажмите здесь для печати.