Журнал ПЛАС » Архив » 2017 » ЖУРНАЛ ПЛАС №8 »

SOC. Худшая стратегия развития – бездействие

Финансовая сфера и сфера телекоммуникаций все глубже интегрируются, что приводит к созданию новых продуктов и каналов продаж для финансовых организаций. Цифровой бизнес, под которым мы подразумеваем обращение клиента (или – устройства IoT от его имени) напрямую к сервисам финансовой организации и встречную активность банков и страховых компаний, нацеленную на получение доступа к текущим данным клиента (локация, предпочтения из социальных сетей, приложений и пр.), позволяет финансовым организациям создавать продукты, таргетированные под конкретных клиентов, предлагая их в реальном времени. Доля таких продуктов, например, в розничном банкинге постоянно растет. При этом на фоне снижения продаж банковских продуктов через традиционные каналы цифровой бизнес уверенно закрепляет позиции в банковской сфере.

SOC. Худшая стратегия развития – бездействие

Константин Смирнов, консультант по информационной безопасности, IBM Россия и СНГ
Константин Смирнов, консультант по информационной безопасности, IBM Россия и СНГ

Однако у такой гибкости есть как минимум две отрицательные стороны. Традиционный периметр финансовой организации размывается, им становятся мобильные устройства клиентов, которые трудно защитить (не забываем и про BYOD (bring your own device, принеси собственное устройство) – термин, описывающий ситуацию, когда сотрудник организации вместо корпоративного компьютера использует для работы собственное коммуникационное устройство, будь то ноутбук, планшет или смартфон)). Доходы финансовой организации все больше зависят от предоставления сервисов здесь и сейчас (добавьте к этому снижающуюся лояльность клиентов). Ликвидация последствий случившихся инцидентов и предотвращение будущих становятся гонкой на время с конкурентами.

Дополнительно к этому мы можем сказать, что все большую угрозу составляют так называемые unknown unknowns – те моменты, о которых «не знаем ни мы, ни кто другой». Традиционный подход с возведением «стены» по периметру организации и контролю за известными угрозами внутри стены больше не работает.

На этом фоне именно Security Operations Center (SOC) является ответом на эти новые вызовы.

Что такое SOC?

SOC может быть переведен как центр мониторинга информационной безопасности или как центр оперативного реагирования на инциденты ИБ. Если попытаться найти четкое определение этого термина в принятых стандартах, то мы потерпим неудачу. Существует масса удачных определений, в которых авторы определяют термин, как говорят философы, остенсивным способом. То есть путем непосредственного показа или обсуждения предмета. Попробуем последовать этому пути.

С точки зрения компании IBM, SOC – организационная единица подразделения информационной безопасности, объединяющая в себе сотрудников, процессы и технологии, предназначенная для получения ситуационной осведомленности о текущих и новых угрозах и реагирования на них в соответствии с установленными приоритетами.

45Если говорить проще, то SOC нужен для того, чтобы оперативно узнавать о новых угрозах ИБ, оценивать, насколько они релевантны для компании, предпринимать меры, чтобы эти релевантные угрозы не реализовались, и реагировать на инциденты ИБ в соответствии с их приоритетами.

Если говорить о сотрудниках, то мы видим как минимум несколько команд:

  • команда реагирования на инциденты (разделяется на несколько уровней, как в ИТ);
  • команда анализа и поиска киберугроз;
  • поддерживающая команда (разработка правил и сценариев корреляции, поддержка систем SOC и т. п.).

Процессы условно делятся на следующие группы:

  • реагирование на инциденты (от момента получения информации о потенциальном инциденте до закрытия инцидента или его эскалации в органы кризисного управления);
  • анализ и поиск киберугроз (управление источниками информации, поиск и оценка релевантности киберугроз, принятие решений по обнаруженным угрозам и т. п.);
  • поддерживающие процессы (управление изменениями, источниками данных, правилами и сценариями SIEM (Security information and event management) – объединение двух терминов,обозначающих область применения ПО: SIM – управление информационной безопасностью и SEM (Security event management) –управление событиями безопасности), разработка регламентов и процедур и т. п.).

Если посмотреть на технологическую составляющую, то мы видим следующие системы:

  • SIEM – для нормализации, анализа и корреляции событий ИБ (из журналов событий);
  • система управления заявками;
  • системы анализа и поиска угроз;
  • система реагирования на инциденты.

Просмотрев эти три списка, любой читатель может задать вопрос: «Выглядит неплохо, но как это можно реализовать?»

SOC – организационная единица подразделения ИБ, объединяющая в себе сотрудников, процессы и технологии

SOC – комплексная система, которую невозможно запустить в один заход. Это утверждение может быть справедливым для любых систем, но в силу сложности и новизны концепции для SOC оно справедливо в особенности. Не хотелось бы говорить очевидные вещи по поводу проектного управления, поэтому я остановился на важных моментах, с которыми мы сталкивались в ходе выполнения проектов.

Глоссарий

С нашей точки зрения, важным является создание адекватного глоссария, который определяет базовые понятия SOC: инцидент, угроза, заявка, реагирование, сценарий, событие, дежурная процедура, мандат на действия и т. д. Зачастую использование «ложных друзей переводчика» (терминов, которые, как кажется, один в один переводятся с английского) приводит к ошибкам и неточностям. Ведь известно, что ясность в мыслях приводит к ясности в делах.

Дело даже не в том, чтобы формулировки точно соответствовали стандартам, а в том, чтобы разработчики SOC и заказчик – финансовая организация понимали эти термины одинаково и корректно.

SOC нужен для того, чтобы оперативно узнавать о новых угрозах ИБ, оценивать, насколько они релевантны, и предпринимать адекватные меры

Архитектура и концепция

Как и любая другая система, SOC начинается с концепции. В основе концепции лежит архитектура – разбиение SOC на функциональные области (например – SIEM/Мониторинг, анализ угроз, реагирование на инцидент, отчетность и пр.). Концепция – это определение целевого состояния для каждой из этих областей. Но само по себе определение целевого состояния не позволяет определить путь его достижения. Важным условием является определение реалистичной «дорожной карты» по переходу из текущего к целевому состоянию.

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

Сложность можно легко недооценить – со всеми вытекающими последствиями. Однако есть возможность управлять этой сложностью.

46«Дорожная карта»

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

Что влияет на «дорожную карту»? Рассмотрим несколько факторов.

1. Требования бизнеса – какие угрозы входят в зону ответственности SOC. От этого зависит разработка сценариев, что в свою очередь влечет необходимость проверки – есть ли источники событий. Например, можете ли вы получать в SIEM события из системы контроля доступа в здание? Можно ли получать события от вашего ПО процессинга? Что делать, если ПО «из коробки» не дает такой возможности?

2. Ограничения бюджета. Сколько процессов мы внедрим сейчас, а сколько – через год? Сколько людей наймем? Какие функции реализуем сейчас, а какие – потом?

3. Размер организации и уровень предоставления услуг SOC. Сколько людей нужно направлять в дежурную смену сейчас и через год? Сколько и каких систем мы хотим подключить к SOC сейчас, а сколько – в следующем году? Хотим ли мы уровень 8/5 или 24/7/365? Какая будет киберразведка и каковы будут ее функции?

4. Первоочередные приоритеты. Например, процесс управления дежурными процедурами можно отложить «на потом», но невозможно отложить процессы реагирования на инциденты.

5. Взаимные зависимости процессов и систем.

6.Интеграция с другими системами. Например, с Service Desk, Fraud Management, UBA, источниками информации по угрозам – как с коммерческими, так и с публичными.

7. КПЭ/SLA SOC и требования к отчетности, как для SOC, так и для организации в целом.

Несмотря на наличие большого количества отраслевых бенчмарков по зрелости ИБ, зрелость ИБ финансовой организации – довольно индивидуальная вещь. Поэтому не существует никакого готового рецепта по формированию дорожной карты. Однако несколько соображений по поводу планирования внедрения SOC все-таки можно привести.

1. По нашим оценкам, внедрение SOC «с нуля» занимает около трех лет. В зависимости от текущей степени зрелости «дорожная карта» может изменяться, отдельные ее направления (по каждой из функциональных областей) могут иметь разную длительность и разное наполнение.

2. В зависимости от бизнес-стратегии финансовой организации могут использоваться разные банковские продукты и каналы продаж. Это автоматически означает изменение релевантности угроз, изменение состава сценариев SIEM и очередность покрытия информационных систем мониторингом ИБ.

3.В зависимости от продуктов и каналов продаж финансовой организации большую роль может играть киберразведка. Определение процессов и модели использования систем для киберразведки может быть существенной частью объема работ.

4.Подход «Концепция – внедрение основных процессов – внедрение остальных процессов – тонкая настройка» по-прежнему актуален, остается только определить, что и в каком количестве будет разработано и внедрено на каждом этапе, какой опыт будет передаваться, где и кому.

Практичный подход по внедрению SOC сводится к прагматичной расстановке приоритетов и постепенному повышению планки – с точки зрения количества сотрудников и графика их работы, внедренных и автоматизированных процессов, источников событий, сценариев SIEM, ключевым КПЭ (времени реагирования на инциденты, например). Перепрыгнуть сразу через несколько уровней зрелости, как правило, не удается никому.

Можно ли обойтись без SOC?

Давайте вспомним про концепцию Kill Chain. Ее составляющие: разведка, вооружение, доставка, запуск, инсталляция, управление и действия. Теперь давайте вспомним, какова традиционная картина ИБ: происходит атака или заражение, и с ним героически борется отдел ИБ. Невольно вспоминается знаменитое «не было никогда, и вот опять». То есть как минимум уже что-то запустилось и уже навредило (действия) или вот-вот навредит (запуск, инсталляция и далее). Таким образом, традиционная концепция ИБ подразумевает реагирование на уже произошедший инцидент. Основное отличие SOC от традиционной концепции заключается в ситуационной осведомленности – возможности обнаружения вредоноса на как можно более ранней стадии (еще тогда, когда злоумышленники только производят разведку вашей или даже сторонней организации или только планируют новые виды кибероружия). Кроме того, что не менее важно, SOC подразумевает превентивное применение мер (если это оружие может потенциально навредить вашей организации).

Основное отличие SOC от традиционной концепции заключается в ситуационной осведомленности

Итак, можно ли обойтись без SOC и еще долго оставаться в традиционной концепции ИБ? Можно. В том случае, если бизнес финансовой организации подобен застрявшим в прошлом генералам, которые готовятся к уже закончившейся войне. Вокруг уже вовсю летают дроны, управляемые искусственным интеллектом, а они всё еще строят ПВО из зенитных пушек. И наращивают выпуск истребителей-перехватчиков для борьбы с бомбовозами, в то время как противник вовсю собирается использовать крылатые ракеты. Иными словами, можно обойтись, если бизнес не заточен под транзакции в реальном времени, а кража, потеря или искажение информации ничтожно мало влияют на способность компании выполнять обязательства перед клиентами, регуляторами или партнерами. Возможно, что такие финансовые организации все еще существуют, однако шансы встретить их в реальном мире исчезающе малы.

Что же делать остальным? Надо оценить свои риски и угрозы, последствия от реализации угроз (хотя бы на качественном уровне – «сильно/средне/слабо»). Провести классификацию информационных активов (в частности, данных) и систем. Провести анализ уровня зрелости ИБ. Разработать концепцию и «дорожную карту». У разных вендоров существуют референтные модели (логические, технические, процессные), которые могут помочь разработать концепцию, дорожную карту и оценить объем и длительность проекта. Однако может возникнуть ситуация, когда организации нужен SOС, но размер организации и/или доступный бюджет не позволяют внедрить в нужном объеме. Как быть в этом случае?

Кому и какой нужен SOC?

System Security Specialist Working at System Control Center. Room is Full of Screens Displaying Various Information.SOC можно рассматривать как услугу, которую отдел ИБ оказывает другим подразделениям бизнеса. Аналогично ИТ-инфраструктуре с концепциями SaaS (ПО как сервис), IaaS (ИТ-инфраструктура как сервис), PaaS (платформа как сервис), SOC может быть реализован различными способами. Давайте рассмотрим некоторые из них.

1. Полностью собственный SOC, когда сотрудники, оборудование и ПО принадлежат финансовой организации. Такой SOC могут позволить себе организации с большим оборотом и численностью (вспомним метрику Gartner – на 100 сотрудников приходится 10 сотрудников ИТ и 1 сотрудник ИБ). Приведем пример – для работы собственного SOC минимального размера (три линии, базовые процессы, работа 24/7) нужно минимум 25 человек в штате. Далее считайте сами, учитывая, что в ИБ есть и другие сотрудники, не входящие в SOC. Стоимость и сложность внедрения – главный минус. Плюсами же являются высокая управляемость, гарантии конфиденциальности, большая синергия, которую можно достичь от работы с другими подразделениями организации (например – ИТ, антифрод и пр.). Зачастую такие SOC используются в крупных организациях с большим количеством дочерних организаций, когда головной офис оказывает услуги SOC всем остальным.

2. Передача функций SOC на аутсорсинг. Предоставляется как услуга со стороны третьих лиц. Привлекательная опция для небольших организаций – отсутствуют капитальные расходы, быстрое внедрение. Минусы – по мере роста такой SOC может стать невыгодным, ограниченная синергия с другими отделами организации, ограниченный круг поставщиков (только отечественные), непрозрачность цено-образования, опасения относительно конфиденциальности. Одним из дополнительных существенных плюсов является синергия, которая достигается благодаря «мульти-арендности» поставщика SOC – если атака произошла на одного из клиентов поставщика услуг, индикаторы компрометации, сигнатуры, правила и сценарии SIEM становятся доступными и для других клиентов, подготавливая к отражению будущей атаки.

3. Гибридный SOC – когда на аутсорсинг передается только часть функций, например – Линия 1 и 2 реагирования на инциденты, киберразведка или иная функция или часть технологической архитектуры SOC. Плюсы очевидны – быстрый старт, экономия на ФОТ и капитальных затратах, возможная синергия. Минусы – сложность организации взаимодействия, разработки и контроля соблюдения SLA, отчетности.

Заключение

Как уже отмечалось, SOC – это совокупность сотрудников, процессов и технологий, предназначенная для получения ситуационной осведомленности о текущих и новых угрозах и реагирования на них в соответствии с установленными приоритетами. В отличие от традиционной системы ИБ, SOC не только реагирует на инциденты ИБ, но и обнаруживает угрозы на ранних подступах и обеспечивает принятие превентивных мер.

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

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

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

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

Подписывайтесь на наши группы, чтобы быть в курсе событий отрасли.

Читайте в этом номере:


Перейти к началу страницы

Подпишитесь на новости индустрии

Нажимая на кнопку "подписаться", вы соглашаетесь с


политикой обработки персональных данных