Pages - Menu

Страницы

18.11.15

Свой SOC или аутсорсинговый? А может быть государственный?

На SOC Forum Олеся Шелестова в своей второй презентации должна была привести некоторые интересные цифры, до которых, она к сожалению, не до дошла, потратив все время на демонстрацию своего решения. А цифры были достаточно интересные и я позволю себе их привести. Только один источник для SIEM/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 стоит подумать более  серьезно. Но уже не сейчас :-)

1 комментарий:

  1. Как-то сумбурно и не пойми о чем. Критерии странные, скажем в строке "Выделенный персонал" - напротив аутсорсинга стоит нет, хотя персонал се равно выделять надо (как минимум менеджера для связи, а еще админа для решения проблем, а еще безопасника, а еще...).

    Опять же про масштабируемость странный посыл. Тот же JSOC заявил, что может вывести панель управления CPB в свою консоль. На вопрос - что уже подключали, ответили - Дозор. И уж свой сок точно быстрее отмасштабируешь, узы там купишь или потоков.

    Главное, что эти критерии не позволяют сравнить аутсорсинг и инсорсинг SOC... :(

    ОтветитьУдалить

Примечание. Отправлять комментарии могут только участники этого блога.