На SOC Forum Олеся Шелестова в своей второй презентации должна была привести некоторые интересные цифры, до которых, она к сожалению, не до дошла, потратив все время на демонстрацию своего решения. А цифры были достаточно интересные и я позволю себе их привести. Только один источник для SIEM/SOC обладает следующими временными характеристиками:
В одной из прошлых заметок я приводил статистику Cisco и Symantec по числу используемых в одной организации средств защиты различных вендоров - от 54 до 75. У того же JSOC 82 разных системы ИБ в эксплуатации. И это только средств защиты, которые могут быть разбросаны по всей сети не в единственном экземпляре. То есть источников, с которых можно брать данные для анализа и реагирования может быть ооооочень много (посмотрите, как пример, на Cisco). Будете ли вы вручную анализировать эти события? Вопрос “а зачем это все анализировать вообще?” я оставлю за рамками сегодняшней заметки; как и вопрос “что делать, если SOC не показывает ни одного инцидента?”. Вроде бы как становится понятно, что нечто для мониторинга нам нужно.
Будет ли это SIEM или SOC - не суть важно; с терминами все равно полная неразбериха. Например, представители “Перспективного мониторинга” считают, что настроенный и поддерживаемый SIEM, сопровождаемый регламентами реагирования на инциденты, - это и есть SOC. А вот в презентации “Инфосистемы Джет” SIEM рассматривается только как один из инструментов SOC, который выполняет гораздо больше функций, которые не все могут покрыты даже самым разрекламированным SIEMом. Ну да и фиг с ним. SOC, SIEM, CERT, СОПКА… Примем как аксиому, что нечто для мониторинга и реагирования нам нужно. Вопрос в другом. Нам нужен свой SOC (будем его для краткости называть так) или аутсорсинговый? Или вообще понадеяться на государственный (FinCERT и ГосСОПКА)? Ситуацию с запретом на внешний SOC по требованиям регулятора я не рассматриваю. Исходим из того, что мы стоим на распутье - свой или чужой?
Задумываясь о своем центре, попробуйте ответить себе всего на два следующих вопроса:
Если на оба вопроса ответ отрицательный, это еще не значит, что вам надо бросать эту затею и идти за помощью к внешнему поставщику услуг. Не случайно тот же Positive Technologies на SOC Forum вышел с идеей внешнего центра компетенций (PT ESC), который может взять на себя часть задач как у аутсорсинговых SOCов, так и у собственных, не обладающих еще полным набором компетенций и знаний. Денег они, конечно, вам не дадут, но экспертизой поделятся.
Но не стоит думать, что я подвожу вас к мысли об аутсорсинге SOC. Это не так. В каждом случае это выбор делается только вами и на основе ваших текущих исходных данных и планов развития. С внешними аутсорсинговыми SOCа (и тем же центром компетенций PT ESC) тоже не все так просто и очевидно. Поэтому вам стоит задаться такими вопросами:
Поскольку универсального ответа по вынесенному в заголовок вопросу нет, я попробовал подготовить небольшую обзорную табличку с критериями, на которые стоит обратить внимание, задумавшись о SOCе.
А может податься в государственный CERT или ГосСОПКУ? Нууууу… Этот вопрос вообще не имеет отношения к вынесенному в заголовку. Строя свой или покупая услуги чужого SOC вы решаете свои задачи. Государственный центр мониторинга решает только свои. Вам он ничего не должен, не обязан, не гарантирует, и ни за что не отвечает. Не путайте свои интересы и интересы государства. Работа с государственными центрами имеет свои задачи и свою область применения - не смешивайте ее с темой SOC (если вы не госорган, конечно, но и тут есть нюансы).
- До 15 секунд на аутентификацию
- 5-15 секунд на открытие журнала событий (от себя добавляю - если речь идет о логах, а не о потоках)
- 2-7 минут на беглый обзор лога за сутки с помощью парсера.
В одной из прошлых заметок я приводил статистику Cisco и Symantec по числу используемых в одной организации средств защиты различных вендоров - от 54 до 75. У того же JSOC 82 разных системы ИБ в эксплуатации. И это только средств защиты, которые могут быть разбросаны по всей сети не в единственном экземпляре. То есть источников, с которых можно брать данные для анализа и реагирования может быть ооооочень много (посмотрите, как пример, на Cisco). Будете ли вы вручную анализировать эти события? Вопрос “а зачем это все анализировать вообще?” я оставлю за рамками сегодняшней заметки; как и вопрос “что делать, если SOC не показывает ни одного инцидента?”. Вроде бы как становится понятно, что нечто для мониторинга нам нужно.
Будет ли это SIEM или SOC - не суть важно; с терминами все равно полная неразбериха. Например, представители “Перспективного мониторинга” считают, что настроенный и поддерживаемый SIEM, сопровождаемый регламентами реагирования на инциденты, - это и есть SOC. А вот в презентации “Инфосистемы Джет” SIEM рассматривается только как один из инструментов SOC, который выполняет гораздо больше функций, которые не все могут покрыты даже самым разрекламированным SIEMом. Ну да и фиг с ним. SOC, SIEM, CERT, СОПКА… Примем как аксиому, что нечто для мониторинга и реагирования нам нужно. Вопрос в другом. Нам нужен свой SOC (будем его для краткости называть так) или аутсорсинговый? Или вообще понадеяться на государственный (FinCERT и ГосСОПКА)? Ситуацию с запретом на внешний SOC по требованиям регулятора я не рассматриваю. Исходим из того, что мы стоим на распутье - свой или чужой?
Задумываясь о своем центре, попробуйте ответить себе всего на два следующих вопроса:
- У вас есть сотрудники, обладающие компетенциями и знаниями для работы в своем SOC?
- У вас есть ресурсы для разработки архитектуры, документов и процессов своего SOC?
Если на оба вопроса ответ отрицательный, это еще не значит, что вам надо бросать эту затею и идти за помощью к внешнему поставщику услуг. Не случайно тот же Positive Technologies на SOC Forum вышел с идеей внешнего центра компетенций (PT ESC), который может взять на себя часть задач как у аутсорсинговых SOCов, так и у собственных, не обладающих еще полным набором компетенций и знаний. Денег они, конечно, вам не дадут, но экспертизой поделятся.
Но не стоит думать, что я подвожу вас к мысли об аутсорсинге SOC. Это не так. В каждом случае это выбор делается только вами и на основе ваших текущих исходных данных и планов развития. С внешними аутсорсинговыми SOCа (и тем же центром компетенций PT ESC) тоже не все так просто и очевидно. Поэтому вам стоит задаться такими вопросами:
- А как будете оценивать квалификацию внешнего SOC и компетенцию его сотрудников? А какова ротация кадров во внешнем SOC?
- А SOC может вам предоставить копию своих регламентов для изучения?
- А у SOC есть резервный канал и резервная площадка? А как докажут? “Зуб даю” тут не прокатит.
- Как давно выбираемый SOC в бизнесе? Как у них с репутацией?
- SOC готов вас свести с заказчиками, похожими на вас? А как долго они сами пользуются услугами SOC?
- А что будет после завершения контракта с SOC?
- Какие гарантии дает и какую ответственность несет SOC, если что-то пошло нет так (не увидел атаку, не смог среагировать, заблокировал не того)?
- Вообще рекомендую посмотреть мой чеклист по выбору облачного провайдера с точки зрения безопасности. Любому аутсорсинговому партнеру можно задать вопросы оттуда и внешний SOC не исключение.
Поскольку универсального ответа по вынесенному в заголовок вопросу нет, я попробовал подготовить небольшую обзорную табличку с критериями, на которые стоит обратить внимание, задумавшись о SOCе.
А может податься в государственный CERT или ГосСОПКУ? Нууууу… Этот вопрос вообще не имеет отношения к вынесенному в заголовку. Строя свой или покупая услуги чужого SOC вы решаете свои задачи. Государственный центр мониторинга решает только свои. Вам он ничего не должен, не обязан, не гарантирует, и ни за что не отвечает. Не путайте свои интересы и интересы государства. Работа с государственными центрами имеет свои задачи и свою область применения - не смешивайте ее с темой SOC (если вы не госорган, конечно, но и тут есть нюансы).
А вот над вопросом использования гибридного SOC стоит подумать более серьезно. Но уже не сейчас :-)
