Тема реагирования на инциденты сегодня является не просто модной, и не только описанной в нормативных актах, но и важной с практической точки зрения. Несмотря на внедряемые меры защиты и непрекращающуюся гонку вооружений, число инцидентов не снижается, а растет. Вдаваться в причины этого явления я не буду, я думаю стоит поговорить о другом - что делать, если инцидент произошел? Реагировать! Именно этому посвящен мой курс и выложенная презентация. В них приводится немало полезной и практической информации о том, как выстраивать процесс управления инцидентами. И одним из безусловно важных вопросов этого процесса является: "Сколько человек необходимо иметь в корпоративном SOC/CSIRT?"
Если посмотреть на презентацию курса, то в ней есть следующие цифры:
Немало людей. Вряд ли кто-то способен содержать такие службы у себя в штате. Но... есть и положительный момент. SOC и CSIRT - это не одно и тоже. SOC - это по сути витрина CSIRT, которая позволяет собирать и визуализировать данные от разнородных средств защиты и сетевого оборудования. От эффективности работы SOC зависит, сколько инцидентов будет спущено на CSIRT и насколько загружены будут аналитики группы реагирования на инциденты.
В более менее крупной организации с разветвленной ИТ-инфраструктурой в день от различных источников может поступать миллионы и даже миллиарды событий. Представьте, что у вас всего 100 ПК (я даже не говорю о сетевом оборудовании). Каждый ПК генерит одно событие в секунду (не важно какое). В день набегает 8 640 000 событий. А если приплюсовать маршрутизаторы, коммутаторы и точки доступа? "Сырых данных" действительно будет очень много. Отсечь просто события от событий ИБ должны помочь технологии SIEM или Threat Defense. Они же могут помочь скоррелировать события из разных источников и показать нарушения политики ИБ, разведку перед атакой, уязвимости и т.п. Таких событий должно быть уже несколько сотен тысяч в месяц. Добавляя контекстную информацию и собственноручно написанные правила можно сократить число нарушений до нескольких тысяч в месяц. И наконец оператор SOC должен иметь дело с десятком-других событий в месяц, которые являются подтвержденными инцидентами, требующими дальнейшего расследования и передачи в CSIRT. При хорошо настроенной системе сбора, анализа, корреляции и отсеивания информации для эффективного управления SOC достаточно одного квалифицированного человека. Не забыв про 8-мичасовую рабочую смену окажется, что SOC, контролирующий из центра всю корпоративную инфраструктуру, может быть обслужен от 1-го до 3-х человек.
Поэтому SOC - это вполне подъемная задача для многих компаний. Но если вы не готовы строить такую систему, то что делать? События ИБ надо же как-то собирать, анализировать и принимать решения. Можно поручить эту работу "SOC'у на доверии", т.е. отдать эту функцию на аутсорсинг. Не могу сказать, что в России эта услуга популярна, но и предложения не единичны. В частности я знаю о двух таких услугах от Инфосистемы Джет и Step Logic. C реагированием ситуация похуже. Остается либо выстраивать процесс самостоятельно, либо привлекать внешние силы. Из небольшого множества CERTов в России, коммерческие услуги предлагает, пожалуй, что только CERT-GIB от Group-IB. Возможно в России в ближайшее время появится еще парочку CERTов. А пока решать вопрос реагирования на инциденты приходится самостоятельно...
ЗЫ. Кстати, посмотрите на результаты опроса на тему "Что бывает после инцидента ИБ?"
Если посмотреть на презентацию курса, то в ней есть следующие цифры:
- 1 полностью загруженный «технический» сотрудник CSIRT может отработать 1 новый «усредненный» инцидент в день и 20 открытых и уже расследуемых инцидентов. Учитывайте, что это именно аналитик, который занимается обработкой инцидентов в течение 8-мичасового рабочего дня. Если аналитики должны работать в режиме 24х7, то вам понадобится не менее 3-х человек (без резерва на время болезни).
- При реализации всего двух сервисов CSIRT (уведомления об инцидентах и обработка инцидентов) требуется задействовать 4-х человек.
- При реализации полного спектра активностей только в рабочее время понадобится уже 6-8 человек, а в режиме 24х7 - уже 12 полностью загруженных сотрудников.
Немало людей. Вряд ли кто-то способен содержать такие службы у себя в штате. Но... есть и положительный момент. SOC и CSIRT - это не одно и тоже. SOC - это по сути витрина CSIRT, которая позволяет собирать и визуализировать данные от разнородных средств защиты и сетевого оборудования. От эффективности работы SOC зависит, сколько инцидентов будет спущено на CSIRT и насколько загружены будут аналитики группы реагирования на инциденты.
В более менее крупной организации с разветвленной ИТ-инфраструктурой в день от различных источников может поступать миллионы и даже миллиарды событий. Представьте, что у вас всего 100 ПК (я даже не говорю о сетевом оборудовании). Каждый ПК генерит одно событие в секунду (не важно какое). В день набегает 8 640 000 событий. А если приплюсовать маршрутизаторы, коммутаторы и точки доступа? "Сырых данных" действительно будет очень много. Отсечь просто события от событий ИБ должны помочь технологии SIEM или Threat Defense. Они же могут помочь скоррелировать события из разных источников и показать нарушения политики ИБ, разведку перед атакой, уязвимости и т.п. Таких событий должно быть уже несколько сотен тысяч в месяц. Добавляя контекстную информацию и собственноручно написанные правила можно сократить число нарушений до нескольких тысяч в месяц. И наконец оператор SOC должен иметь дело с десятком-других событий в месяц, которые являются подтвержденными инцидентами, требующими дальнейшего расследования и передачи в CSIRT. При хорошо настроенной системе сбора, анализа, корреляции и отсеивания информации для эффективного управления SOC достаточно одного квалифицированного человека. Не забыв про 8-мичасовую рабочую смену окажется, что SOC, контролирующий из центра всю корпоративную инфраструктуру, может быть обслужен от 1-го до 3-х человек.
Поэтому SOC - это вполне подъемная задача для многих компаний. Но если вы не готовы строить такую систему, то что делать? События ИБ надо же как-то собирать, анализировать и принимать решения. Можно поручить эту работу "SOC'у на доверии", т.е. отдать эту функцию на аутсорсинг. Не могу сказать, что в России эта услуга популярна, но и предложения не единичны. В частности я знаю о двух таких услугах от Инфосистемы Джет и Step Logic. C реагированием ситуация похуже. Остается либо выстраивать процесс самостоятельно, либо привлекать внешние силы. Из небольшого множества CERTов в России, коммерческие услуги предлагает, пожалуй, что только CERT-GIB от Group-IB. Возможно в России в ближайшее время появится еще парочку CERTов. А пока решать вопрос реагирования на инциденты приходится самостоятельно...
ЗЫ. Кстати, посмотрите на результаты опроса на тему "Что бывает после инцидента ИБ?"
ОтветитьУдалитьДобавлю следующие моменты:
- инциденты могут быть типовыми, а могут быть и новыми (не знаешь как реагировать), что сильно влияет на время реакции
- важно не только количество людей, но и их квалификация (распределять инциденты по уровню квалификации)
- очень важно подстроить количество обнаруживаемых инцидентов под способности людей (нет смысла обнаруживать сразу все и заваливать людей; привели в порядок одну тему нарушений - можно браться за другую )
Так же добавлю, что инциденты можно решить в рамках компании, а иногда требуется привлечение гос.органов (чтобы довести дело до суда или найти внешнего нарушителя) и тут потребуется 4й человек, для общения с ними...
ОтветитьУдалитьАлексей, а вам не сложно читать темы, в которых у вас нет практического опыта?
ОтветитьУдалитьКак тебе моя оргструктура на 14 слайде?
ОтветитьУдалитьhttp://www.slideshare.net/ksiva/soc-siem
Иван, а кто сказал, что у меня нет опыта? Вы же не знаете, чем я занимаюсь в российском офисе Cisco :-)
ОтветитьУдалитьДенис, а сканирование, это operations?
ОтветитьУдалить