SOC'и России. Есть проблемы. И не будем этого скрывать!
ВВЕДЕНИЕ
Почти 20 лет назад – 2 ноября 1988 года – состоящий всего из 99 строк кода червь Морриса (получивший прозвище Великий Червь) заразил 6 000 компьютеров ARPANET, создав существенные проблемы более чем десятку университетов и корпораций. Отразив атаку и «вылечив» компьютеры, организация, создавшая ARPANET, – Агентство перспективных оборонных исследований (DARPA) вместе с Университетом Карнеги-Меллон создала компьютерную команду реагирования на чрезвычайные ситуации (CERT – Computer Emergency Response Team), ставшую фактически первым Security Operations Center.
Перед первым SOC были поставлены задачи реагирования на инциденты кибербезопасности, проведения исследований, сбор информации об уязвимостях и повышения осведомленности пользователей о новейших угрозах. Со временем, ввиду интеграции разрозненных инфраструктур и оцифровки бизнес-процессов предприятий, задачи реагирования на инциденты (управления инцидентами) и управления уязвимостями многократно укрупнились, разветвились и стали краеугольными камнями понятия security operations.
СЕРВИСЫ И ПОТРЕБИТЕЛИ СЕРВИСОВ SOC
C годами обязанности SOC расширялись, и CERT Карнеги-Меллон выделяет уже 17 сервисов ИБ (рисунок 1).
Рисунок 1. Сервисы SOC по версии CERT Карнеги-Меллон
Российские SOC на практике предоставляют 4 базовые услуги внешним или внутренним потребителям:
- Поддержка средств защиты (в первую очередь сенсоров).
- Мониторинг кибератак и реагирование на инциденты (управление инцидентами в узком смысле).
- Сканирование и контроль закрытия уязвимостей инфраструктур и ПО (управление уязвимостями в узком смысле).
- Киберразведка (мониторинг уязвимостей, последних атак как минимум на основе публично доступной информации от ключевых ИБ-вендоров).
Цикл запуска сервиса SOC возможно поделить на ряд этапов (Таблица 1).
Таблица 1. Этапы запуска нового сервиса SOC
Корпорации создают или заказывают сервисы SOC по заказу одной или нескольких заинтересованных сторон (потребителей сервисов). Таких типовых заинтересованных сторон 5:
- Генеральный директор. Цель – защита стоимости акций, репутации, капитала, интеллектуальной собственности и доходов компании.
- Финансовый директор. Цель – соответствие требованиям (например, SOX).
- ИТ-директор. Цель – обеспечение непрерывности предоставления ИТ-услуг.
- Директор по безопасности. Цель – обеспечение сохранности корпоративных активов.
- Региональный менеджмент. Цель – получение доступа к корпоративным централизованным ИТ-сервисам (что иногда невозможно без заказа централизованных сервисов SOC).
Иногда SOC создается как часть проекта по централизации функций поддержки бизнеса, т.е. в целях снижения затрат. Его функции могли выполнять отделы ИБ во всех регионах и странах присутствия корпорации, а теперь за счет централизации будет возможно повышение качества и снижение удельных затрат. Кстати, более 75% компаний из списка Fortune 500 (а в нефтяной отрасли 90%) уже реализовали у себя программы централизации предоставления услуг. Из публичных российских примеров в части информационной безопасности это Росатом, Роснефть, Газпром, Сбербанк, Норникель, Северсталь. Однако, стоит отметить, что степень централизации может быть разной. Где-то, как в одном из дивизионов нефтегазового чемпиона, реализован единообразный SOC-сервис на 20 000 рабочих станций, где-то, как в федеральном госоргане, централизована только часть функций, и полная централизация невозможна ввиду застарелого конфликта ИТ и ИБ – всегда будут нужны специалисты ИБ на местах, поскольку ИТ не соглашается взять на себя даже самые мелкие задачи.
Внешними клиентами коммерческих SOC остаются 3 основных типа организаций:
- Крупные глобальные организации в рамках проектов по аутсорсингу функций поддержки бизнеса.
- Организации в регулируемых сферах бизнеса – публичные, платежные организации (SOX, PCI DSS, etc.).
- Организации среднего размера, масштаб которых делает избыточным найм, содержание и удержание квалифицированного персонала SOC.
ОРГАНИЗАЦИОННАЯ МОДЕЛЬ SOC
Определив тип SOC (внешнийвнутренний), портфель и заказчиков сервисов, становятся понятны зона ответственности и предпосылки к формированию организационной структуры, географической модели предоставления сервисов, стандартов компетенций персонала, программ набора и удержания персонала, все то, что в совокупности именуется операционнойорганизационной моделью SOC, позволяющей стабильно предоставлять сервисы SOC заказчикам с предсказуемым качеством и объёмом.
Рассмотрим несколько примеров крупных SOC. Ввиду специфики нашей отрасли только один SOC согласился выступить «с открытым забралом» - это Solar Security. Были направлены запросы и двум другим коммерческим SOC (Лаборатория Касперского и Позитив Технолоджис), но они не согласовали визит.
Пример 1. Глобальный SOC, сфокусированный на предоставлении сервиса киберразведки внешним заказчикам. Присутствие в 12 странах на всех континентах. Организационная структура основного бизнеса типа «спрут» разделена на 4 блока – Customer Care (отношения с потребителями), Global Analytics (аналитики и служба контроля качества), Special Operations (технические сервисы – форензик, реверс-инжиниринг, реагирование на инциденты), Global Intelligence (сбор информации). Первые 3 блока в итоге были централизованы в головной стране, блок Global Intelligence состоял из локальных Risk Management Centers + центр технической компетенции в европейской штаб-квартире. Организационная структура Risk Management Center – «кольцо» - все делают все, но есть и зачатки специализации: кто-то специализируется на уязвимостях, кто-то аналитике, кто-то на fraud intelligence. Источники персонала – студенты, национальные CERTы, отставники правоохранительных органов и спецслужб.
Пример 2. Топовая нефтегазовая корпорация России (А). SOC предоставляет сервисы мониторинга атак, уязвимостей и поддержки средств защиты для всех российских предприятий (20 000 ПК). Организационная структура SOC – «двойной спрут» – методологическое ядро и служба контроля качества в Москве, операционное ядро в Рязани, технический сервис сперва в Рязани, потом в Саратове (вслед за наличием редкой компетенции), задачи реагирования на инциденты на местах выполняли службы ИБ-предприятий. Организационная структура операционного ядра – «паутина» - по каждой значимой системе ИБ работало 2 человека, так же 2 человека решали вопросы отчетности, управления, мотивации и найма. Источник персонала – студенты, системные и сетевые администраторы с рынка. Кстати, рядом с «классическим» SOC работал распределенный центр мониторинга бизнес-транзакций, фактически «антифрод-SOC» (контроль фрод-рисков в продажах нефтепродуктов на АЗК) – численность персонала, организационная структура и географическое распределение работ было в целом аналогичным.
Пример 3. Топовый телеком оператор России. SOC предоставляет сервисы мониторинга атак и уязвимостей в рамках SOX-критичной области. Весь SOC расположен в Москве, организационная структура «пирамида» (аналитики 1-ого уровня приоритезируют инциденты и решают что могут, иначе эскалируют, аналитики 2-го уровня решают инциденты, аналитики 3-го уровня вносят изменения в правила мониторинга). Задачи реагирования на инциденты на местах выполняли менеджеры по ИБ макрорегионов. Технический сервис и служба контроля качества отсутствуют. Источник персонала – повышение квалификации существующих специалистов службы ИБ, найм с рынка.
Пример 4. Топовая нефтегазовая корпорация России (Б). SOC предоставляет сервисы мониторинга атак и поддержки средств защиты в рамках московского сегмента инфраструктуры (до 6 000 ПК), региональная инфраструктура не входила в объем мониторинга. Технический сервис и служба контроля качества отсутствуют. Организационная структура простая, нет ярко выраженного разделения на аналитиков по уровням, задачи реагирования на инциденты на местах закрывались службами ИБ предприятий. Источник персонала – студенты, повышение квалификации существующих специалистов службы ИБ, найм с рынка.
Пример 5. Топовый банк России. SOCи предоставляют сервисы поддержки средств защиты, мониторинга атак и уязвимостей в рамках московского и региональных сегментов инфраструктуры. Московский и региональные SOCи оперируют фактически самостоятельно, даже не ведут полноценную единую техническую политику. Технический сервис и служба контроля качества отсутствуют, но привлекается на аутсорсинг технический сервис для помощи в расследованиях хищений со счетов клиентов (ДБО и т.п.). Организационная структура простая, нет ярко выраженного разделения на аналитиков по уровням, задачи реагирования на инциденты на местах закрывались службами ИБ подразделений филиалов. Источники персонала – не предоставляется возможным определить, SOCи формируются стихийно.
Пример 6. Коммерческий SOC Solar Security. Предоставляет сервис мониторинга атак и уязвимостей для внешних клиентов (из публичных – Тинькофф банк, СТС Медиа). Организационная структура SOC – распределенные на Москву и Нижний Новгород «песочные часы». Увеличено количество аналитиков 3-ей линии для более полного технического понимания инфраструктуры клиентов, аналитики 1-ой линии расположены в Нижнем Новгороде, 3-ей в Москве. Существуют технический сервис и служба контроля качества, задачи реагирования на инциденты у клиентов распределены между 3-ей линией и службами ИБ клиентов.
С точки зрения лучших практик CERT (CERT Карнеги-Меллон, Европейского агентства по информационной и сетевой безопасности) организационная структура CERT должна начинаться с института triage officer (в переводе «распределяющий офицер»), который, обладая знаниями последних угроз, трендов и актуальных векторов атак, должен произвести первичную обработку каждого инцидента и определить не является ли он «ложно положительным». Однако, на практике в российских и глобальных SOC эту функцию возлагают на 1-ую линию, иногда подпирая ее последующим ревю кейсов службой контроля качества (Пример 6).
На основе анализа вышеприведенных примеров возможно выделить ряд компонентов SOC, целесообразность которых необходимо рассмотреть при создании эффективного и полноценного подразделения:
- Управленческий орган SOC для координации как рабочих процессов, так и критичных вопросов найма, оценки, мотивации и удержания персонала SOC.
- Методологический блок SOC.
- Операционное ядро SOC – 1-ая линия (операторы), 2-ая и 3-я – аналитики.
- Дополнительные блоки SOC – технический сервис, институт службы контроля качества (может быть реализован силами аналитиков SOC).
ПОРТРЕТ АНАЛИТИКА SOC
Даже самые лучшие организационные практики не позволят построить устойчиво эффективный SOC без качественного человеческого капитала – сотрудников. Объединяющими различные SOC минимальными требованиями к операторам и аналитикам будут 3 профессиональных и 3 личных. Среди профессиональных - знания сетевой архитектуры и протоколов (стека TCPIP и др.), знания UNIX (основы современных средств защиты) и знания используемых SOC средств защиты (IDS, FW, web proxy, AV). Среди личных – мотивация к обучению, стрессоустойчивость, склонность к командной работе.
Многие другие качества (знания ландшафта угроз, специфики корпоративных ландшафтов и процессов ИТ и ИБ, хакерских практик и утилит) тоже будут ценным подспорьем, но их возможно «добрать» в процессе работы.
Крупный SOC с штатом в десятки человек выводит на уровень оператора за 1,5 месяца, на уровень полноценного аналитика 2-ой линии – за 1,5 года (данные Solar Security).
7 ОРГАНИЗАЦИОННЫХ ПРОБЛЕМ SOC
Руководители признаются, что даже в существующих годами крупнейших SOC с отстроенными процессами и успешной практикой, бывают и проблемы. Сколько и какие? 7 типовых описаны ниже:
1. Предопределенность решений культурной спецификой.
В ряде организаций отсутствует рабочий диалог между ИТ и ИБ. Это выявляется в невозможности поручить ИТ даже самые простые и небольшие по объёму задачи, а без этого сложно централизовать сервисы ИБ – сманеврировать, создав мощный SOC без увеличения штата. В каждом регионе России приходится держать локальных специалистов, размывая тем самым человеческий капитал службы ИБ по всей стране. Рецептом решения проблемы (из Примеров 2, 3) будет установление максимально возможных добрососедских отношений с коллегами из ИТ.
2. Отсутствие высококвалифицированных специалистов.
Квалифицированных аналитиков SOC в стране всего несколько десятков, это штучные специалисты и иногда их просто негде взять. Рецептом решения проблемы (из Примеров 2,6) будет разработка стандартов компетенции должностей, запуск программ стажировок и привлечения студентов.
3.«Охота за головами».
Начиная как минимум с 2008 года в России каждый год открывается либо существенно реорганизуется крупный корпоративный SOC. Процесс начинает приобретать лавинообразный характер. Подчеркну, что SOC в данном случае – это не просто SIEM и 2 аналитика, а полноценная организация с четкими целями, сервисами и заказчиками, полноценными процессами и практиками. Открывающиеся SOCи ведут активную «охоту за головами» из уже существующих. Рецептом решения проблемы (из Примеров 2, 3, 5) будет повышение компенсации ключевым сотрудникам, выделение сотрудников SOC в отдельную ИТИБ дочернюю компанию.
4.Текучка.
Квалифицированные аналитики SOC могут применить свои знания и на других участках работы службы ИБ (в частности несколько аналитиков из Примера 2 доросли до уровня директоров по ИБ) и являются востребованными на рынке труда. Дополнительный фактор риска – рутинная работа на 1-ой линии, которая может просто наскучить специалистам. Рецепт решения проблемы (из Примеров 2, 6) – формирование и внедрение программы взаимодействия с вузами для формирования кадрового студенческого резерва.
5.Малая емкость рынка кадров.
Открытие SOC в городах с малым количеством крупных предприятий и представительств федеральных корпораций может привести к вынужденной ориентации исключительно на студентов. Рецепт решения проблемы (из Примеров 4,5,6) – открывать SOC в крупных городах с развитыми университетскими сообществами – в Москве, Нижнем Новгороде, Казани, Новосибирске и т.д.
6.Слабая автоматизация.
Слабую автоматизацию деятельности SOC в России можно назвать нормой. На одном из важных участков с ней точно проблемы – нет развитой SIEM, нет workflow cистемы, нет базы знанийCMDB, нет sandbox решений или то, что есть, устарело и толком не поддерживается. Рецепты решения проблемы (из Примеров 2, 3) – использование «легких» open source решений (OTRS, сuckoo), использование скриптов, перенос рутинных операций в регионы с более низкими компенсациями.
7.Отсутствие ежегодного повышения квалификации.
Инвестиции в обучение персонала SOC часто сдерживаются текучкой: «Вот мы их учим, а они все уходят». С другой стороны, а что будет, если не учить? Рецепты решения проблемы (из Примеров 2, 3, 6) – план развития персонала, стандарты компетенций (от какой точки до какой мы ведем сотрудника), обучение одного сотрудника с последующим трансфером знаний.
ЗАКЛЮЧЕНИЕ
«Нет худа без добра» - классическая пословица как нельзя более применима к текущему ландшафту угроз, когда участившиеся инциденты выступают драйвером создания SOC. Они стимулируют не только создавать SOCи, но и активно ориентироваться на результат – жестко тестировать новые подходы к управлению и организации SOC и служб ИБ в целом, пересматривать существующее историческое наследие в процессах и технологиях ИБ. Этот шанс может оказаться последним перед тем, как международные игроки и зарубежные партнеры кардинально изменят расстановку на российском кадровом ИБ-рынке.
.png)