• Все разделы
  • Статьи
  • Медиа
  • Новости
  • Нормативные материалы
  • Конференции
  • Глоссарий

Статьи по теме: «Информационная безопасность»

Главная Специалистам Статьи Интервью с экспертом: «Ростелеком-Солар» адаптирует сервисы ИБ для региональных госзаказчиков

Интервью с экспертом: «Ростелеком-Солар» адаптирует сервисы ИБ для региональных госзаказчиков

Владимир Дрюков, директор центра мониторинга и реагирования на кибератаки Solar JSOC компании «Ростелеком-Солар», в интервью порталу «Безопасность пользователей сети Интернет» (www.safe-surf.ru) рассказал о развитии сервисов мониторинга инцидентов и контроля защищенности для государственных заказчиков в регионах Российской Федерации.

Интервью с экспертом: «Ростелеком-Солар» адаптирует сервисы ИБ для региональных госзаказчиков

Какие сервисы Solar JSOC предлагает сегодня региональным госзаказчикам? Отличаются ли они от тех же сервисов для коммерческих организаций?

Задача наших сервисов – это обеспечение именно реальной, а не «бумажной» безопасности заказчиков, включая защиту от внешних атак, отпор внутренним злоумышленникам и противодействие киберпреступности в широком смысле этого слова. И здесь у нас возникает поле для взаимодействия с организациями, подпадающими под действие закона о защите критической информационной инфраструктуры (КИИ), потому что букву этого закона можно трактовать по-разному, но дух подзаконных нормативных актов и методических рекомендаций нацелен именно на реальную безопасность, борьбу со злоумышленником вне зависимости от уровня его подготовки.

Конечно, наше предложение для коммерческих предприятий отличается от предложения, адресованного государственным организациям, которые несколько ограничены регуляторными требованиями, например, импортозамещением и сертификацией. Мы учитываем эти особенности. Если клиенту требуется сервис, основанный на отечественных решениях, или набор услуг, удовлетворяющий нормативным требованиям, у нас есть для этого стек соответствующих технологий. Но также мы предлагаем и альтернативные решения, в состав которых включены наиболее эффективные зарубежные системы информационной безопасности (ИБ). Так, если мы говорим о мониторинге инцидентов, то можем предложить заказчику сервис, основанный на решении ArcSight SIEM компании Micro Focus Security. А тем, кто обязан выполнять требования по импортозамещению, мы предложим сервис, базирующийся на отечественном продукте MaxPatrol SIEM компании Positive Technologies. Причем на текущий момент мы не видим технологических ограничений по использованию этого продукта. Обе платформы постепенно выравниваются с точки зрения необходимой нам функциональности и нашей экспертизы по их использованию.

Целиком ли предложение Solar JSOC покрывает запросы и потребности госзаказчиков в области мониторинга инцидентов, контроля защищенности ИТ-ресурсов?

Наше сервисное предложение на базе Solar JSOC охватывает практически все актуальные задачи заказчика, связанные с защитой от кибератак: мониторингом, реагированием и защитой периметра в широком смысле. Для задач мониторинга и реагирования на самые сложные кибератаки у нас есть сервисы Managed Detection and Response (MDR). Для более стандартных задач по защите инфраструктуры в массовом сегменте у нас имеется Solar MSS — экосистема управляемых сервисов кибербезопасности, технологическим ядром которой является наша Единая платформа сервисов кибербезопасности (ЕПСК), решающая задачи сетевой безопасности.

Совокупно все это достаточно полно покрывает запросы клиентов, но мы готовы и слегка дотачивать сервис, адаптировать под заказчика. Если у него есть задача, допустим, закрыть нормативные требования ГосСОПКА, мы соберем для него такой пакет сервисов и выполним задачу «под ключ». В середине 2018 года мы подписали соглашение с Национальным координационным центром по компьютерным инцидентам (НКЦКИ) и оказываем соответствующие услуги федеральным заказчикам из различных отраслей экономики, а также органам госвласти. Если запросы заказчика на информационную безопасность шире требований закона, и ему помимо внешних угроз интересен мониторинг действий подрядчиков или мониторинга бизнес-приложений, наш сервис может быть дополнен соответствующими сценариями и адаптирован под задачу. А если потребности клиента скромнее и не касаются напрямую нормативной базы, наше предложение тоже корректируется соответствующим образом.

Работа Solar JSOC с региональным госзаказчиком – это в большей степени готовый сервис или проект? Если проект, то каковы его основные этапы?

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

В процессе подключения к сервису можно выделить несколько активных этапов, частично перекрывающих друг друга. В первую очередь мы обеспечиваем техническую связанность наших с заказчиком инфраструктур: устанавливаем на площадке клиента сенсоры, систему сбора, анализа и обработки событий, иногда и сканер защищенности, если он требуется для оказания услуги. А подчас строится и интеграционная шина. Затем мы подключаемся к площадке заказчика по каналам прямой связи. Если речь идет о госзаказчиках, то эти каналы защищаются шифрованием на основе ГОСТ-криптографии.

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

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

На втором этапе, когда мы уже получаем информацию о событиях ИБ, начинается процесс профилирования информационных систем. Что это такое и зачем оно нужно? Дело в том, что очень часто заказчик сам не до конца понимает, как устроена его ИТ- и ИБ-инфраструктура, какие разрешения и запреты есть в организации, что является нарушением политики безопасности, а что нет. Яркий пример инцидента, вызванного нарушением политик, это запуск инструментов удаленного администрирования (Remote Administration Tools и Remote Access Tools, RAT) на рабочих станциях. Строго говоря, это должно быть запрещено. Если некто за пределами компании получает доступ в корпоративную сеть, это должно трактоваться как серьезный инцидент, поскольку все чаще удаленное администрирование становится частью инструментария внутренних злоумышленников и хакерского программного обеспечения (ПО).

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

Параллельно идет согласование матрицы оповещения – определяются получатели тревожных сигналов: служба безопасности, ИТ-департамент, отдел обслуживания ЛВС и др. В матрице указывается минимальное время оповещения для каждого типа инцидентов: о каких-то заказчика необходимо уведомить в течение получаса, в других случаях допустимо сообщить об инциденте через два часа. Так, определяя наши совместные темпы движения к заданному уровню безопасности, мы в итоге приходим к базовому состоянию сервиса. Обычно поначалу у заказчика запускается 30-40 сценариев. Это обеспечивает ему хороший базовый уровень защищенности: сформирован первый уровень соответствия нормативным требованиям, и в круглосуточном режиме действует система оповещений о результатах мониторинга.

Затем начинается сам процесс обслуживания. На этом этапе тоже могут возникать дополнительные задачи, например, по подключению новых компонентов ИТ-систем или СЗИ с запуском дополнительных сценариев мониторинга. Далее, если контракт с заказчиком это предусматривает, в процессе сервисного обслуживания мы двигаемся вглубь – смотрим на соседние сегменты ИТ-инфраструктуры, подключаем не только ее критичную часть (автоматизированные рабочие места), но и другие элементы: серверы, системы документооборота и так далее. Все это такое постепенное движение к цели – в течение полугода перейти от базового состояния защищенности заказчика, определенного контрактом, к некоторому практическому состоянию, когда мы считаем, что клиент закрыт от основных угроз информационной безопасности.

Что вы обычно видите после начального обследования критичных систем регионального госзаказчика? Каков набор типичных проблем и пробелов в защите КИИ региональных госструктур? В чем природа этих проблем?

Проблемы у заказчиков более-менее похожие, к сожалению. Они как правило связаны с низким уровнем цифровой гигиены. Обычно мы сразу же выявляем разношерстный набор прикладного ПО, установленного на серверах и рабочих станциях. Среди прочего обнаруживаются и программы-майнеры, причем иногда даже на серверах. А у одного клиента мы нашли майнер на гипервизорах в системе виртуализации!

Вторая проблема: очень редко у заказчика нормально выстроен процесс управления обновлениями программного обеспечения. Поэтому у нас есть отдельный процесс информационного взаимодействия с заказчиками, когда мы оперативно оповещаем их о самых критичных уязвимостях. Например, в этом году была волна атак, связанная с новой уязвимостью и ее реализацией в протоколе RDP (Remote Desktop Protocol). Сначала это был эксплоит BlueKeep, потом появилась его же реинкарнация для новых версий Windows - Deja Blu. Как только появлялась информация об этих угрозах, мы моментально оповещали заказчиков, и это помогло уберечь многих из них от успешной атаки киберпреступников.

Третье: к сожалению, мы очень редко видим у заказчика нормальные политики доступа в Интернет. В лучшем случае он ограничен прокси-сервером с базовыми настройками, но чаще всего открыт фактически прямой доступ в сеть. Это порождает множество проблем. Если доступ в Интернет ограничен хорошо продуманными политиками, злоумышленнику для того, чтобы внедрить ВПО и связаться с центром управления, нужно изрядно потрудиться – использовать DNS-туннелинг (техника, позволяющая передавать произвольный трафик поверх DNS-протокола), использовать сайты WordPress, чтобы как-то замаскироваться под легитимный трафик. А когда вместо политик — открытый выход в Интернет с любой рабочей станции, каждая атака автоматически заканчивается компрометацией сети организации.

Еще одна важная деталь – инфраструктура у заказчиков очень редко сегментирована. Обычно изолированы только те сегменты, которые используются для обработки чувствительной информации, такой, как гостайна. Но когда мы поднимаемся выше, структура разделения на демилитаризованную зону и корпоративную сеть встречается крайне редко, как и нормально выстроенные политики, описывающие сетевое взаимодействие. Это очень ограничивает полноту обзора, потому что чем хуже мы видим движение трафика внутри инфраструктуры, тем сложнее понять, как развивается атака злоумышленника, если он пробился через периметр. А знать это крайне важно. Поэтому одно из направлений нашей работы сегодня – поиск технологического решения класса NTA (анализа сетевого трафика), которое сможет запустить компенсирующие механизмы там, где нет сегментации. Хотя бы с помощью NTA мы сможем анализировать сетевые потоки у заказчика и повышать для себя уровень прозрачности его инфраструктуры.

Какие критичные уязвимости обычно вскрываются позже, в процессе обслуживания?

Как правило, мы находим системы Teleport. По умолчанию в большинстве компаний и государственных организаций есть инфраструктурный сегмент, возможность удаленного доступа к которому должны быть полностью исключена. Это сегменты защиты критической информации, автоматизированные системы управления технологическими процессами (АСУ ТП) и тому подобное. Но для определенного удобства у заказчика в большинстве случаев есть смычка этого сегмента с Интернетом — сервер с двумя интерфейсами в разные стороны. Подобное встречается регулярно. Понятно, что при базовом аудите и опросе заказчика, а также при первом сканировании этого не видно. Такие вещи можно выявить только в процессе глубокого анализа потоков, распределения учетных записей и так далее. А возможность провести глубокий анализ появляется, как правило, ближе ко второму полугодию совместной работы с заказчиком.

Вторая типичная проблема — это ролевой доступ, системы управления правами пользователей, учетными записями. Зачастую мы видим, как выдаются избыточные права удаленного доступа к инфраструктуре из Интернета. Много таких нюансов вскрывается по дороге. Плюс у каждого заказчика встречаются какие-то индивидуальные особенности. Казалось бы, клиенты из числа госорганов в значительной степени похожи друг на друга. Однако каждый ИТ-администратор придумывает свой способ «упростить» себе жизнь, да еще при этом обмануть службу ИБ.

Что показывает мониторинг? Какие инциденты чаще всего фиксируются вами в процессе обслуживания? Какие из инцидентов представляют наибольшую угрозу?

Мы видим колоссальный объем фишинга. Примерно 80% атак начинаются с социальной инженерии, с фишингового письма и последующего внедрения ВПО в инфраструктуру. Но раньше у киберпреступников была определенная специализация — например, группировки Cobalt и Silence атаковали только банки. Теперь же такой специализации нет – все злоумышленники рассылают фишинговые письма повсюду, подкрепляя атаку трояном и ВПО. Впоследствии тот же самый вирус, написанный Silence, может многократно перепродаваться на хакерских форумах от одной группировки к другой и в дальнейшем использоваться уже для взлома органов госвласти. Это массовая история.

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

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

Много ли инцидентов связано с атаками, направленными на отказ в обслуживании?

Вообще DDoS-атак становится все больше. Это связано в основном с удешевлением самого процесса. Но сказать, что статистика по DDoS растет теми же темпами, что и по киберугрозам в целом, наверное, нельзя. Показатели первых укладываются в классические 40–50% годового прироста, а совокупное число кибератак ежегодно удваивается. Мы фиксируем попытки DDoS-атак на заказчиков, но в силу текущего положения нам достаточно легко им противодействовать: мы оператор связи, и у нас есть свои системы очистки.

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

Утечка базы с данными внешних пользователей из органов госвласти – довольно редкая история. Причина, на мой взгляд, не столько в высоком уровне защищенности органов госвласти, сколько в низком интересе злоумышленников к этой информации. Скомпрометировать учетные записи клиентов банков, например, — это прямой путь к монетизации атаки. А в органах госвласти основная угроза все-таки связана со шпионажем и кражей конфиденциальной информации иного рода.

Кто обычно берет на себя функции расследования инцидентов и технического реагирования на них? Solar JSOC или заказчик?

Обычно это совместный процесс. Если мы говорим про базовую атаку, где реагирование заключается в изоляции рабочей станции и перезаливке ПО (чисто технических работах), то заказчик обычно выполняет их самостоятельно. Однако наша команда, конечно, дает подробные рекомендации по противодействию атаке, причем, благодаря широкому региональному присутствию «Ростелеком-Солар», это делается в самые короткие сроки вне зависимости от часового пояса заказчика и времени суток.

Если требуется глубокое расследование инцидента, есть ключевая развилка: инициирован он внешним или внутренним нарушителем. В случае внешней атаки для корректного восстановления цепочки событий и вектора атаки требуется специализированная экспертиза по форензике – расследованию компьютерных инцидентов. Сюда входит анализ дампов памяти, жестких дисков, восстановление намеренно удаленных файлов и др. Заказчик такими компетенциями не обладает, а у нас накоплена внутренняя экспертиза для решения этих задач. Более того, если речь о центрах ГосСОПКА, подобные задачи необходимо решать для выполнения нормативных требований, поэтому они по умолчанию включены в состав комплексной услуги Solar JSOC.

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

Работа в процессе реагирования построена немного по-другому – стандартные инциденты мы можем блокировать самостоятельно, но в случае со сложными атаками без вовлечения заказчика для согласования ключевых работ не обойтись. Ведь эти работы могут сказаться на доступности систем (когда мы изолируем атакованные сегменты) или повлиять на бизнес-процессы (например, удаление ПО, блокировка учетных записей и более сложные способы противодействия). Поэтому, как правило, это командная работа специалистов заказчика и Solar JSOC.

Как проходит взаимодействие Solar JSOC с ИТ-департаментами региональных госзаказчиков? У них ведь свои заботы – они постоянно заняты оптимизацией ИТ-инфраструктуры. Это сильно осложняет задачи мониторинга и контроля защищенности?

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

Каковы основные условия SLA для региональных госзаказчиков? И как заказчики могут проконтролировать качество сервисов Solar JSOC?

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

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

Как именно это происходит?

Приведу пример. У одного из наших заказчиков из банковской сферы безусловным инцидентом считалась любая активность, касающаяся АРМ КБР (это банковская система взаимодействия с Центральным банком). И он раз в две недели ночью, в районе двух часов, запускал в этой области какой-нибудь скрипт, пытался удалить системную службу и так далее. Причем мы уже знали, что это имитация инцидента, но ведь процесс должен быть отработан. Поэтому дежурная смена нашего центра поднимала среди ночи сервис-менеджера, аналитика, меня, наконец. А я поднимал со стороны заказчика вице-президента по ИБ… То есть отрабатывали по полной программе. После чего заказчик оценивал оперативность нашего реагирования на инцидент: молодцы, сработали за 15 минут. Это довольно популярная история, многие так делают.

Есть еще один способ проверки качества сервиса SOC – тестирование на проникновение. Для этого заказчик приглашает внешнюю команду, либо к нему приходит регулятор в рамках плановых работ по анализу защищенности. Это уже настоящая боевая история, полноценные киберучения, особенно если на стороне нападающих работает сильная квалифицированная команда. Мы не знаем, что они ведут эту работу, а они знают, что мы занимаемся мониторингом и защитой клиента. И они пытаются максимально эффективно пройти ниже наших «радаров» и не попасть в поле зрения сенсоров SOC. Это всегда очень творческая история, в которой для заказчика ключевым часто является даже не то, поймали ли мы нарушителей, а то, насколько мы были близки к тому, чтобы видеть каждый их шаг. Такие учения очень полезны, они позволяют нам оптимизировать настройки контента и сценариев, выбрать у заказчика дополнительные источники на подключение, доработать наши с клиентом процессы по реагированию. Каждые такие учения завершаются работой над ошибками. Но наши специалисты уже сейчас демонстрируют хорошую реакцию во время тестов на проникновение — примерно 85% шагов, предпринимаемых злоумышленниками, мы обычно видим прямо в процессе атаки. И, следовательно, имеем возможность моментально реагировать, останавливая развитие атаки.

Кто обычно инициирует такие киберучения у ваших заказчиков?

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

Мы готовы вместе со службой ИБ отвечать перед бизнесом за показатели качества сервиса, потому что от них зависит репутация Solar JSOC. Любая пропущенная атака на нашем еще не до конца сформировавшемся рынке аутсорсинга ИБ достаточно быстро становится известна экспертному сообществу, в котором все друг друга знают. Это немедленно скажется на нашем собственном бизнесе, поэтому мы стараемся держать качество на высоком уровне.

Что касается государственных заказчиков, то они нечасто проводят подобные киберучения. За последние два года нас предупреждали о пентестах у госзаказчиков лишь дважды, а в целом за это время таких учений прошло более восьми десятков.

Четыре года назад правительство Самарской области создало собственный Центр обнаружения, предупреждения и ликвидации последствий компьютерных атак. Solar JSOC тоже продвигается в регионы, создавая там свои центры, например, в Нижнем Новгороде. Как правильно распределить роли коммерческого SOC и местного SOC администрации? Стоит ли вообще региональным администрациям создавать собственные SOC?

Я всегда приветствую развитие экспертизы. Если у заказчиков начинает формироваться такая экспертиза, и они в состоянии собрать и удержать у себя команду высококвалифицированных специалистов, это всегда отрадно. Модели сотрудничества тут могут быть разными. Например, сначала мы можем предложить региональному заказчику сформировать свою команду по реагированию на инциденты и ликвидации их последствий. То есть создать фокусную группу из четырех-пяти специалистов, глубже нас понимающих локальную инфраструктуру, и готовых самостоятельно обслуживать средства защиты, решая задачи обеспечения безопасности на первом уровне. Функции мониторинга и экспертизу по аналитике мы при этом оставляем за собой. Это модель базовая, и она встречается очень часто.

Если же заказчик понимает, что он в состоянии удержать у себя этих специалистов, сохранить и развить свою экспертизу, мы иногда входим в проекты по построению в регионах местных центров мониторинга. Переходим к такой гибридной модели: пока команда набирается и растет, мы закрываем потребности заказчика в ИБ своими сервисами, но в процессе роста команды начинаем ее потихоньку обучать, передаем ей сначала первую линию SOC, затем потенциально – вторую. Иногда мы уходим на третий-четвертый уровень и в этом случае помогаем заказчику в отражении новых атак, разборе сложных инцидентов, в проведении расследований, обогащаем информацией по угрозам. Но операционную деятельность оставляем у самого заказчика. Это тоже допустимая модель. А целевая (предпочтительная) конфигурация для нас такова: реагирование осуществляется на стороне заказчика, а мониторинг и обеспечение этого процесса в режиме 24х7 мы берем на себя.

Однако в реальности заказчикам из регионов крайне сложно самостоятельно сформировать и удерживать на должном уровне даже первую и вторую линии SOC, и именно это остается ключевой проблемой. Хорошая новость в том, что деньги – не единственный способ ее решения. Встречаются весьма харизматичные лидеры, способные создать сильную команду и очень быстро перестраивать ее под изменившиеся условия. Тут работает такой комплекс факторов - «руководитель-коллектив-микроклимат». Зарплаты, конечно, тоже важны, но не настолько. Мы сами, когда были маленькой коммерческой компанией, испытали прессинг со стороны лидеров российского ИТ-рынка, но ушло от нас всего трое из сорока человек.

На сегодняшний день клиентами Solar» (JSOC являются десяток региональных администраций и ведомств. Очевидно, число заказчиков будет расти. Насколько остро стоят вопросы масштабирования самого Solar» (JSOC, особенно с учетом дефицита кадров?

Мы достаточно давно ушли от попыток и желания переманить людей с рынка двойными и тройными окладами. Вместо этого мы с 2015» (года активно работаем с вузами. Во всех городах нашего присутствия (в Самаре, Хабаровске, Нижнем» (Новгороде) у нас заключены соглашения с вузами. И мы приглашаем студентов оттуда на стажировки. Набираем группы по 15» (человек, учим сначала основам, теории. Потом пускаем их в нашу большую лабораторию для отработки практических навыков. На своем полигоне мы генерируем инциденты, и стажеры их анализируют. Иногда вручную, а местами с помощью автоматизированных систем. Цель обычной стажировки длительностью один-два месяца в том, чтобы у ребят появились фундаментальные знания по информационной безопасности. Причем это будут практические знания, а не те, которые прописаны в нормативных актах или даются в вузах. Мы показываем стажерам, как реально устроены сейчас атаки и угрозы. И второе – у них набивается рука. Совокупно у нас сейчас по трем городам (плюс мы запускаемся в Ростове-на-Дону) стоит задача прогнать через такие стажировки где-то четыреста человек. На работу к себе мы возьмем человек пятьдесят. Остальные разойдутся по рынку либо останутся в нашем кадровом резерве. Дальше, «приземлившись» в коллектив, на объем задач наших заказчиков и ежедневных инцидентов, человек не сможет не расти. Если ему интересно и есть желание развиваться, это дает свои плоды. Вот сейчас у нас в цикле возгонки с первой линии SOC на вторую талантливый сотрудник проходит обучение за три месяца, со второй на третью — примерно за полгода. Расти до аналитика (до четвертого уровня) нужно года полтора-два, правда, это редкость, уникальные случаи. Но мы нацелены на то, чтобы за два года из молодого специалиста, заинтересованного в развитии, сделать высококлассного профессионала.

В прошлом году наша команда выросла в два раза, но с рынка SOC мы взяли только четырех человек. А более сорока новых сотрудников вырастили самостоятельно. Наши задачи другого подхода скорее не приемлют. Мы не в состоянии насыщаться кадрами с рынка и, как коммерческая компания, не хотим переманивать специалистов сумасшедшими деньгами. Люди у нас получают достойную зарплату согласно своей экспертизе. Но деньги мы считаем хорошо, потому что инвестиции в персонал в конечном счете сказываются на стоимости нашего сервиса для заказчика.

Расскажите о перспективах развития сервисного портфеля Solar JSOC для госзаказчиков. Как в процессе развития сервисов будет меняться сам Solar JSOC, его технологическое оснащение, компетенции, процессы?

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

Третье важное направление связано с тем, что мы сейчас очень активно работаем с федеральными и региональными заказчиками и пытаемся адаптировать наш сервис под их специфические задачи. На большом корпоративном рынке мы всегда работали в режиме «всё включено», когда заказчик, подключившись к Solar JSOC, получал готовое решение в ответ на практически любой запрос. Но у региональных клиентов объем актуальных задач и запросов значительно меньше, поэтому мы хотим оптимизировать для них наше сервисное предложение. Для этого планируется автоматизировать выполнение некоторых типовых задач и в чем-то ограничить функционал. Но таким образом мы сможем оптимизировать и стоимость нашего сервиса, сделав его доступнее для большего числа региональных клиентов.

Третье направление развития связано с совершенствованием инструментов управления. Я уже говорил о создании личного кабинета для большей прозрачности нашей деятельности для заказчика. Мы прорабатываем возможность дать заказчикам единую среду работы с инцидентами. Это будет некий аналог технологии IRP (консоли управления и реагирования), чтобы они, получив от нас уведомление об инциденте, могли прямо в своей консоли единой работы проанализировать его, оперативно отреагировать и мгновенно дать нам обратную связь. Это тоже большая задача. Она требует очень тонкой интеграции и понимания того, как устроено реагирование на стороне заказчика. Сейчас мы накапливаем статистику, чтобы выбрать оптимальные инструменты для решения этой задачи. числа региональных клиентов.

И, конечно, мы очень много работаем над масштабированием своей команды. Еще четыре года назад нас было около 40 человек, а сейчас Solar JSOC – это больше двух сотен сотрудников. В период бурного роста бизнеса мы стараемся удержать не только качество услуг, но и сложившийся характер внутренних коммуникаций, и благоприятный микроклимат в компании. Собственно, в процессной части мы стараемся соблюсти внутренний баланс, сохранить уникальную корпоративную культуру. И пусть Solar JSOC тиражируется уже на тысячи клиентов, он тем не менее остается сервисом с человеческим лицом.
Нормативные требования к аттестации АС/ИС по ГОСТ–РО 0043-003-2012 года Практический опыт построения корпоративного SOC