Лес и цифра. Опыт внедрения SOC в деревообрабатывающей отрасли

Лес и цифра. Опыт внедрения SOC в деревообрабатывающей отрасли

BIS Journal попросил директора по информационной безопасности Segezha Group рассказать, зачем, как и с каким результатом происходило подключение к удаленному SOC в одном из крупнейших в отечественной лесной промышленности холдинге.

ДИСПОЗИЦИЯ

Segezha Group – ведущий российский лесопромышленный холдинг с полным циклом собственной лесозаготовки, деревообработки и выпуска широкой линейки продукции, представленной на рынках более 80 стран мира. Особенность компании в ее географической распределенности – десятки предприятий и офисов разбросаны по всей стране от Карелии до Иркутской области. Больше 20 тыс. сотрудников в десяти регионах в разных часовых поясах. Но проблема не только в разнице во времени, а в том, что каждое предприятие холдинга – самостоятельная бизнес-единица. Активы присоединялись в разное время, у каждого из них свой уровень зрелости IT-инфраструктуры и, соответственно, информационной безопасности. 

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

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

ПОЧЕМУ МЫ ВЫБРАЛИ ВНЕШНИЙ SOC

Итак, задача максимального закрытия рисков очевидна. У нас была своя SIEM-система для оперативного управления информацией о текущем состоянии безопасности и управления инцидентами. Но с учетом стоящих перед холдингом бизнес-задач она требовала срочной модернизации. Во-первых, её настройка находилась в зачаточном состоянии. Какие-то правила были предустановлены вендором, какие-то интегратором, что-то пытались настраивать наши предшественники. Это была огромная база данных, генерировавшая более 10 тыс. событий в сутки. Необходима была основательная настройка и общая оптимизация работы. 

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

И последнее. В холдинге есть объекты КИИ, к ним особое отношение, а взаимодействие с НКЦКИ жестко регламентировано и требует специфических навыков. То есть нам нужна была помощь в организации и упрощении такого взаимодействия. 

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

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

КАК МЫ ПОДКЛЮЧАЛИСЬ

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

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

Но самое интересное было дальше.

ЧТО МЫ ПОЛУЧИЛИ СРАЗУ

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

Что касается выявления вредоносной активности, то после подключения к SOC мы стали более быстро понимать, что происходит в нашей инфраструктуре–все проблемы предстали как на ладони.

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

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

Отдельно отмечу отчёты и регулярные рассылки, в том числе от НКЦКИ и ФСТЭК. По новым уязвимостям получаем дополнительную информацию от коллег – они оперативно подсвечивают критичные моменты. Ну и последнее в списке, но не по значимости, – передача информации в координационный центр. Нас также успешно подключили к ГосСОПКА, теперь нам не надо переживать о соблюдении всех требований регулятора. 

КАК МЫ РАЗВИЛИ СЕРВИС ЗА ПЕРВЫЙ ГОД

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

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

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

Кроме того, большая работа была проделана в части фильтрации поступающих событий. Данных должно быть необходимое и достаточное количество, чтобы не перегружать ресурсы и каналы и в то же время не рисковать потерей важных событий. Тут я снова хочу отметить экспертизу инженеров SOC, совместно с которыми настраивались все подписки. Без их опыта это был бы либо огромный поток данных (как с нашей собственной SIEM), либо бесполезный поток. 

ПОДВЕДЕНИЕ ИТОГОВ

Правильно ли мы сделали, когда отказались от идеи развития собственных систем и обратились к сервисам внешнего SOC? На слайде всё очевидно (рис. 1). Чтобы эффективно обрабатывать такой поток событий, необходимо большое количество ресурсов. И речь даже не столько о вычислительных ресурсах, это решаемый вопрос, сколько о человеческих. Чтобы настроить, поддерживать и развивать собственную систему требуется много специалистов. Найти и удержать их весьма проблематично. В нашем случае наиболее оптимальным и эффективным решением стало подключение к внешнему SOC. 

Рисунок 1. Какими ресурсами должно обладать ИБ-подразделение компании, чтобы справляться с таким количеством работы?

Кроме того, в истории нашего взаимодействия с SOC уже существует целый ряд критичных инцидентов, риск развития которых мог бы стать катастрофическим. После каждого из них мы понимаем, что сделали правильный выбор. Какие это были инциденты? Например, детектирование сигнатуры ETHERNAL BLUE с компьютера администратора, работающего через VPN. Максимальный приоритет инциденту, оповещение от дежурного, сбор данных о затронутых хостах – и угроза остановлена. Появление в сети недоменных устройств и детектирование вирусной активности с них. Так была обнаружена нелегитимно установленная wifi-точка на отдаленном предприятии, через которую сотрудники сидели с личных устройств в интернете. Кроме того, у нас в компании на регулярной основе проводятся пентесты, по результатам которых SOC не пропускает ни одного критичного инцидента. 

ЧТО СЕЙЧАС?

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

Я уже упоминал про постоянную работу над правилами корреляции, развитием интеграции и подключением новых систем как источников данных. Эта работа не останавливается, при внедрении новых систем одна из первоочередных задач – подключение их к SOC. К этому добавляются новые задачи по настройке и интеграции со специализированными системами безопасности АСУ ТП. В связи с определенными трудностями в приобретении современного телекоммуникационного оборудования, добавляются задачи по получению данных со всё более широкого спектра устройств (рис. 2).

Рисунок 2. Удаленный SOC меньше чем за год стал неотъемлемой частью ИБ холдинга Segezha Group.