InformationSecurity05_2020

www.itsec.ru

№ 5, ноябрь 2020 Издание компании

9–11

2021

Спецпроект

SOC Роль SOC в безопАсности Кии АнАтоМиЯ SOC КАДРовое обеспечение РАботы SOC особенности сбоРА, АгРегАции и РАнжиРовАниЯ инДиКАтоРов КоМпРоМетАции КАК буДут РАзвивАтьсЯ SIEM-систеМы в ближАйшие тРи гоДА КАК пеРейти нА безопАснуЮ РАзРАботКу: истоРиЯ оДного пРоеКтА сМысл и безопАсность лоКАлизАциЯ технологий КАК инстРуМент эффеКтивного иМпоРтозАМещениЯ

Александр Дворянский, Алексей Юдин

Что нам стоит SOC построить?

Реклама

www.itsec.ru

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

Амир Хафизов, выпускающий редактор журнала “Информационная безопасность”

Одним из наиболее известных центров является ФинЦЕРТ, входящий в структуру Центробанка. В начале ноября "Коммерсантъ" поделился новостью1 о том, что департамент информационной безопасности ждет реструктуризация, в результате которой ФинЦЕРТ может быть ликвидирован, а его функции перераспределены между другими управлениями, в том числе и новыми. Артем Сычев, первый заместитель директора департамента информационной безопасности Банка России, правда, сразу поспешил успокоить2 руководителей российских банков, высказавшись в том духе, что деятельность ФинЦЕРТ по обеспечению информационной безопасности в кредитнофинансовой сфере востребована, а значит центр так или иначе продолжит свою работу. А банки со своей стороны отметили3, что функционал ФинЦЕРТ требует доработки, повышения оперативности реагирования на поступающие события и автоматизации процессов. Будем с интересом наблюдать за грядущей перестройкой, ведь ФинЦЕРТ как элемент национальной системы обеспечения информационной безопасности в финансовой сфере объективно необходим, особенно с учетом появления в поле зрения российского законодательства криптовалют. Криптофинансы по сравнению с традиционными финансами технологически более сложны, менее контролируемы и более уязвимы, хотя бы с точки зрения социальной инженерии, на долю которой приходятся 70% всех преступлений в традиционных финансах, по сообщению самого Центробанка. С точки зрения принципов и практики организации может оказаться полезным опыт ЦУП, одного из в первых на территории нашей страны центров мониторинга и реагирования, обслуживающего весьма критическую инфраструктуру. Центру управления полетами исполнилось этой осенью 60 лет. И пусть ЦУП борется не с внешними злоумышленниками, а с техническими неполадками и агрессивной внешней средой вокруг защищаемых систем, но тем не менее исправно выполняет SLA 24 х 7, успешно реагирует на нештатные ситуации и налаживает взаимодействие с аналогичными центрами в других странах. В этом номере журнала авторы и эксперты постарались всесторонне рассмотреть особенности построения, деятельности и оптимизации SOC. А я в дополнение темы упомяну две части статьи Алексея Лукацкого "Измерение эффективности SOC" о многообразии метрик для центров мониторинга и реагирования, опубликованные в предыдущих номерах журнала.

https://www.kommersant.ru/doc/4566802 https://www.finanz.ru/novosti/aktsii/izmeneniya-v-departamente-cb-rf-po-bezopasnosti-ne-oznachayutprekrashchenie-raboty-fincert-cb-1029809880 3 https://iz.ru/1086910/natalia-ilina/uskorit-pomoshch-banki-nashli-sposob-bystree-blokirovat-perevodymoshennikov 1 2

• 1

СОДЕРЖАНИЕ ПРАВО И НОРМАТИВЫ Анастасия Заведенская Обзор изменений законодательства в сентябре и октябре 2020 года . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4 стр.

12

В ФОКУСЕ ИМПОРТОЗАМЕЩЕНИЕ Олег Ассур Кому нужны сертифицированные средства управления мобильностью . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9 Александр Зубарев Локализация технологий как инструмент эффективного импортозамещения . . . . . . . . . . . . . . . . . . . . . . . . . .10

стр.

12

ПЕРСОНЫ Алексей Юдин, Александр Дворянский Что нам стоит SOC построить? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .12

СПЕЦПРОЕКТ – SOC Константин Саматов Роль SOC в безопасности критической информационной инфраструктуры . . . . . . . . . . . . . . . . . . . . . . . . . .16 стр.

Группа компаний Angara стирает границы между коммерческим и корпоративным SOC . . . . . . . . . . . . . . . . .18

20

Всеслав Соленик Анатомия SOC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .20 Юрий Сергеев Особенности сбора, агрегации и ранжирования индикаторов компрометации . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .22 Александр Пирожков Фиды для SOC. Осведомлён – значит вооружён . . . . . . . . . . . . . . .24 Вячеслав Половинко, Виктория Стерлядева, Анастасия Лазарева стр.

Однонаправленные шлюзы для подключения объектов технологической сети к SOC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .26 2 •

36

СОДЕРЖАНИЕ Алексей Юдин В сети обнаружен шифровальщик. Как планировать реагирование? . . . . . . . . . . . . . . . . . . . . . . . . . . . . .28

Журнал "Information Security/Информационная безопасность" № 5, 2020 Издание зарегистрировано в Минпечати России Свидетельство о регистрации ПИ № 77-17607 от 9 марта 2004 г. Учредитель и издатель компания "ГРОТЕК"

Алексей Андреев, Роман Ванерке Как будут развиваться SIEM-системы в ближайшие три года . . .30 Ксения Темникова Кадровое обеспечение работы SOC: поиск и подбор персонала, формирование и развитие команд . . . . . . . . . . . . . . . . . . . . . . . . . . .32 Александр Подобных Платформа SICP для отслеживания подозрительных транзакций и обеспечения безопасности блокчейнов . . . . . . . . . .34 Сергей Рысин Про SOC Круглый стол заказчика, провайдеров, вендоров и интеграторов . . .36

ТЕХНОЛОГИИ

Генеральный директор ООО "ГРОТЕК" Андрей Мирошкин Издатель Владимир Вараксин Выпускающий редактор Амир Хафизов Редактор Светлана Хафизова Корректор Галина Воронина Дизайнер-верстальщик Ольга Пирадова Фото на обложке Анна Степанова

Андрей Пинчук Graph Representation Learning для повышения эффективности противодействия мошенничеству . . . . . . . . . . . . .42 Надежда Мозолина Дубликатом бесценного груза: "Паспорт ПО" . . . . . . . . . . . . . . . . .46 ЗАЩИТА СЕТЕЙ

Юрисконсульт Кирилл Сухов, lawyer@groteck.ru Департамент продажи рекламы Зинаида Горелова, Ольга Терехова Рекламная служба Тел.: +7 (495) 647-0442, gorelova@groteck.ru

Иван Чернов UserGate Management Center для управления парком межсетевых экранов . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .48 БЕЗОПАСНАЯ РАЗРАБОТКА Дарья Орешкина Создание ценности на каждом этапе . . . . . . . . . . . . . . . . . . . . . . . . .50 Алексей Жуков Как перейти на безопасную разработку: история одного проекта . . .52 КРИПТОГРАФИЯ Валерий Конявский Смысл и безопасность . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .54

НОВЫЕ ПРОДУКТЫ И НЬЮСМЕЙКЕРЫ Новые продукты и услуги . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .57 Ньюсмейкеры . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .60

Отпечатано в типографии ИП Морозов, Москва, ул. Зорге, 15 Тираж 10 000. Цена свободная Оформление подписки Тел.: +7 (495) 647-0442, www.itsec.ru Департамент по распространению Тел.: +7 (495) 647-0442 Для почты 123007, Москва, а/я 26 E-mail: is@groteck.ru Web: www.groteck.ru, www.itsec.ru Перепечатка допускается только по согласованию с редакцией и со ссылкой на издание За достоверность рекламных публикаций и объявлений редакция ответственности не несет Мнения авторов не всегда отражают точку зрения редакции © "ГРОТЕК", 2020

• 3

ПРАВО И НОРМАТИВЫ

Обзор изменений законодательства в сентябре и октябре 2020 года Анастасия Заведенская, аналитик Аналитического центра Уральского центра систем безопасности

Сентябрь-2020

В Лицензирование видов деятельности по защите информации ФСТЭК России 9 сентября 2020 г. опубликовала проект постановления Правительства РФ "О внесении изменений в Положение о лицензировании деятельности по разработке и производству средств защиты конфиденциальной информации (СЗКИ)", утвержденный постановлением Правительства РФ от 3 марта 2012 г. № 1711 (далее – Проект). Разработка этого Проекта обусловлена вступлением в силу с 1 января 2021 г. изменений, вводимых Федеральным законом от 27 декабря 2019 г. № 478-ФЗ "О внесении изменений в отдельные законодательные акты Российской Федерации в части внедрения реестровой модели предоставления государственных услуг по лицензированию отдельных видов деятельности" (далее – закон № 478-ФЗ). Проект направлен на приведение Положения о лицензировании деятельности по разработке и производству СЗКИ в соответствие с внедренной законом № 478-ФЗ реестровой моделью предоставления государственных услуг по лицензированию отдельных видов деятельности. Кроме того, Проектом исключаются из Положения о лицензировании деятельности по разработке и производству СЗКИ ссылки на утратившие силу пункты Федерального закона "О лицензирова1 2 3 4 5

сентябре 2020 г. произошло несколько значимых событий: ФСТЭК России инициировала изменения по приведению в соответствие реестровой модели оказываемых ей государственных услуг по лицензированию; Минцифры России (в прошлом – Минкомсвязь России) разработало проект федерального закона, предлагающего изменения в законодательстве о персональных данных; в области обеспечения безопасности значимых объектов критической информационной инфраструктуры выпущены изменения в приказ ФСТЭК России от 25 декабря 2017 г. N 239 и новый приказ о порядке согласования подключения значимых объектов к сетям связи общего пользования.

нии отдельных видов деятельности" от 04.05.2011 г. № 99-ФЗ.

10 сентября 2020 г. был опубликован аналогичный проект постановления Правительства РФ "О внесении изменений в Положение о лицензировании деятельности по технической защите конфиденциальной информации" 2 , утвержденный постановлением Правительства РФ от 3 февраля 2012 г. № 79. Предлагаемые этим проектом изменения также направлены на приведение деятельности по лицензированию в соответствие с новой реестровой моделью предоставления государственных услуг. Реестровая модель подразумевает переход от предоставления результата госуслуги в виде бумажного документа к записи в электронном реестре. Следствием указанных инициатив стали проекты изменений в административные регламенты по предоставлению государственной услуги ФСТЭК России в связи с вводом реестровой модели, а именно: l проект приказа ФСТЭК России "О внесении изменений в Административный регламент Федеральной службы по техническому и экспортному контролю по предоставлению государственной услуги по лицензированию деятельности по технической защите конфиденциальной информации, утвержденный приказом ФСТЭК России от 17 июля 2017 г. № 134"3;

https://regulation.gov.ru/Projects/List#npa=108153 https://regulation.gov.ru/Projects/List#npa=108180 https://regulation.gov.ru/Projects/List#npa=108900 https://regulation.gov.ru/Projects/List#npa=108901 https://regulation.gov.ru/projects?type=ListView#npa=108156

4 •

l проект приказа ФСТЭК России "О внесении изменений в Административный регламент Федеральной службы по техническому и экспортному контролю по предоставлению государственной услуги по лицензированию деятельности по разработке и производству средств защиты конфиденциальной информации, утвержденный приказом ФСТЭК России от 17 июля 2017 г. № 133"4.

Персональные данные 9 сентября 2020 г. Минцифры России опубликовало проект федерального закона "О внесении изменений в Федеральный закон "О персональных данных" в части установления основ правового регулирования обязательных требований"5 (далее – Проект ФЗ). Проект ФЗ определяет конкретный перечень областей регулирования, связанных с обработкой персональных данных (ПДн), требования которых определяются как обязательные, а именно: l соблюдение принципов обработки ПДн; l установление правовых оснований обработки ПДн; l поручение оператором обработки ПДн другому лицу; l соблюдение конфиденциальности ПДн; l согласие субъекта ПДн на обработку его ПДн; l обработка специальных категорий ПДн; l обработка биометрических ПДн; l трансграничная передача ПДн;

Zavedenskaya_part1 11/23/20 9:17 PM Page 5

www.itsec.ru

Реклама

ПРАВО И НОРМАТИВЫ

l обработка ПДн в государственных или муниципальных информационных системах ПДн; l предоставление субъекту ПДн информации, касающейся обработки его ПДн; l обработка ПДн в целях продвижения товаров, работ, услуг на рынке, а также в целях политической агитации (в части установления правовых оснований для осуществления такой обработки и ее прекращения); l защита прав субъектов ПДн при принятии решений на основании исключительно автоматизированной обработки их ПДн; l действия оператора при сборе ПДн; l обеспечение выполнения оператором обязанностей, предусмотренных Федеральным законом "О персональных данных" от 27.07.2006 г. № 152-ФЗ; l действия оператора при обращении к нему субъекта ПДн либо при получении запроса субъекта ПДн или его представителя; l устранение нарушений законодательства, допущенных при обработке ПДн, по уточнению, блокированию и уничтожению ПДн; l уведомление уполномоченного органа по защите прав субъектов ПДн о намерении осуществлять обработку ПДн; l порядок и условия назначения лица, ответственного за организацию обработки ПДн в организации; l полномочия лица, ответственного за организацию обработки ПДн в организации; l хранение и уничтожение ПДн; l обработка ПДн, осуществляемая без использования средств автоматизации; l обеспечение безопасности ПДн при их обработке; l обезличивание ПДн.

Следует отметить, что была получена отрицательная оценка регулирующего воздействия Проекта ФЗ. В частности, отмечается, что используемые разработчиком в Проекте ФЗ формулировки не позволяют систематизировать обязательные нормы в полной мере, поскольку перечень групп обязательных требований не является закрытым. Кроме того, отмечается, что систематизация обязательных требований должна иметь четкую структуру и определять все конкретные требования, которые будут полноценно раскрыты в подзаконных актах.

Обеспечение безопасности значимых объектов КИИ 14 сентября 2020 г. официально опубликован приказ ФСТЭК России от 20.02.2020 № 35 "О внесении изменений в Требования по обеспечению безопасности значимых объектов критической информационной инфраструктуры Российской Федерации, утвержденные приказом Федеральной службы по техническому и экспортному контролю от 25 декабря 2017 г. № 239"6 (далее – приказ № 35). Приказ № 35 был подписан ФСТЭК России еще 20 февраля 2020 г., но регистрацию в Минюсте России прошел только в сентябре. В целом основные изменения, вводимые приказом № 35, были представлены еще в проекте приказа ФСТЭК России, который рассматривался в обзоре изменений законодательства за февраль7. Из новых положений в области защиты значимых объектов критической информационной инфраструктуры (КИИ), вводимых приказом №35 и вступивших в

силу с 25 сентября 2020 г., можно выделить следующие: 1. Модернизацией теперь официально считается изменение архитектуры значимого объекта КИИ, в том числе подсистемы его безопасности, в соответствии с отдельным техническим заданием (ТЗ) на модернизацию значимого объекта КИИ и/или ТЗ (частным ТЗ) на модернизацию подсистемы безопасности значимого объекта.

2. Оценка выполнения требований по безопасности, предъявляемых к программным и программно-аппаратным средствам, в том числе средствам защиты информации (СрЗИ), должна включаться в программы и методики предварительных испытаний.

3. Удаленный доступ к программным и программно-аппаратным средствам, в том числе СрЗИ, для обновления или управления можно предоставлять не только работникам субъекта КИИ, как это было раньше, но также работниками его дочерних и зависимых обществ. При этом сделано послабление и для предоставления удаленного доступа другим лицам, кроме вышеупомянутых, однако только при условии наличия компенсирующих мер по защите, установленных приказом № 35.

3. Теперь на территории РФ должны размещаться не только технические средства, осуществляющие хранение и обработку информации, значимых объектов КИИ первой категории, но и технические средства объектов КИИ второй категории значимости. С 1 января 2023 г. вступят в силу требования приказа № 35 к оценке соответствия СрЗИ в форме приемки или испытаний, а также к прикладному программному обеспечению (ПО) значимых

http://publication.pravo.gov.ru/Document/View/0001202009140010 См. Заведенская А.А. Начинаем год с новых требований законодательства // Information Security/Информационная безопасность. 2020. № 1. С. 11–13.

6 7

• 5

ПРАВО И НОРМАТИВЫ объектов КИИ. Не встроенные в общесистемное и прикладное ПО СрЗИ, оценка соответствия которых проводится в форме испытаний или приемки, дополнительно должны будут соответствовать шестому или более высокому уровню доверия. Таким образом, в действующей редакции приказа ФСТЭК России № 239 оценку соответствия СрЗИ необходимо проводить только по тем требованиям к функциям безопасности, которые были установлены в ТЗ на создание значимого объекта КИИ и/или ТЗ (частное ТЗ) на создание подсистемы безопасности значимого объекта КИИ. Для СрЗИ, планируемых к внедрению в рамках создания (модернизации или реконструкции, ремонта) значимых объектов КИИ, после 1 января 2023 г., кроме описанной выше оценки соответствия, необходимо будет проводить оценку соответствия по шестому или более высокому уровню доверия.

8

Прикладное ПО значимых объектов КИИ с января 2023 г. должно будет соответствовать требованиям: l по безопасной разработке ПО; l к испытаниям по выявлению уязвимостей в ПО; l к поддержке безопасности ПО.

Подключение значимых объектов КИИ к сетям связи общего пользования Следом, 15 сентября 2020 г., был официально опубликован приказ ФСТЭК России от 28.05.2020 г. № 75 "Об утверждении Порядка согласования субъектом критической информационной инфраструктуры Российской Федерации с Федеральной службой по техническому и экспортному контролю подключения значимого объекта критической информационной инфраструктуры Российской Федерации к сети связи общего пользования"8 (далее – Порядок).

Порядок вступил в силу 26 сентября 2020 г. и устанавливает процедуру согласования со ФСТЭК России подключения значимых объектов КИИ к сети связи общего пользования. При этом, если значимый объект КИИ с подключением к сети связи общего пользования уже был внесен в реестр значимых объектов КИИ с соответствующей информацией до 26 сентября 2020 г., согласование со ФСТЭК России не нужно. Для согласования необходимо будет также предоставить во ФСТЭК России: l копии моделей угроз безопасности информации значимого объекта КИИ; l копии протоколов испытаний, содержащих результаты оценки соответствия СрЗИ (для СрЗИ, прошедших оценку соответствия в форме испытаний, приемки); l схему организации связи (в случае предоставления оператором связи субъекту КИИ цифровых каналов связи).

http://publication.pravo.gov.ru/Document/View/0001202009150068

Октябрь-2020

В

октябре 2020 г. были внесены изменения в требования к порядку реализации мероприятий на этапах жизненного цикла государственных информационных систем, а ФСТЭК России сообщила об изменениях в требованиях к уровням доверия для сертификации средств защиты информации. До конца ноября можно принять участие в общественном обсуждении нормативных актов, которые опубликовало Минцифры России, их содержание касается импортозамещения для объектов критической информационной инфраструктуры. В этом обзоре рассмотрим нормотворческую деятельность Банка России в области защиты информации.

Государственные информационные системы 14 октября 2020 г. официально опубликовано и вступило в силу постановление Правительства Российской Федерации от 10.10.2020 г. № 1650 "О внесении изменений в требования к порядку создания, развития, ввода в эксплуатацию, эксплуатации и вывода из эксплуатации государственных информационных систем и дальнейшего хранения содержащейся в их базах данных информации"1 (далее – ПП № 1650). ПП № 1650 вносит изменения в постановление Правительства РФ от 06.07.2015 г. № 676, в котором установлены требования к порядку реализации мероприятий на этапах жизненного цикла государственных информационных систем (ГИС), осуществляемых федеральными органами исполнительной власти и органами исполнительной власти субъектов РФ.

1 2

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

2. В случае если в соответствии с технико-экономическим обоснованием объем требуемого федеральным органом исполнительной власти финансирования на реализацию мероприятий для создания ГИС составляет более 100 млн руб., то ТЗ на ГИС необходимо согласовать с Минцифры России.

3. Сроки согласования моделей угроз безопасности информации и ТЗ на ГИС со ФСТЭК России, а также ТЗ на ГИС с Минцифры России (в случае необходимости) теперь не могут превышать 10 рабочих дней.

4. Установлены условия запрета ввода ГИС в эксплуатацию без надлежащего оформления прав на использование ее компонентов, являющихся объектами интеллектуальной собственности.

Новые требования к уровням доверия Информационным сообщением от 15 октября 2020 г. № 240/24/42682 ФСТЭК России уведомляет об утверждении новой редакции Требований по безопасности информации, устанавливающих уровни доверия к средствам технической защиты информации и средствам обеспечения безопасности информационных технологий (далее – Требования к уровням доверия). С 1 января 2021 г. признается утратившей силу предыдущая версия Требований к уровням доверия, установленных приказом ФСТЭК России от 30.07.2018 г. № 131. Новая версия Тре-

http://publication.pravo.gov.ru/Document/View/0001202010140044 https://fstec.ru/normotvorcheskaya/informatsionnye-i-analiticheskie-materialy/2124-informatsionnoe-soobshchenie-fstek-rossii-ot15-oktyabrya-2020-g-n-240-24-4268

6 •

www.itsec.ru

Реклама

ПРАВО И НОРМАТИВЫ

бований к уровням доверия утверждена приказом ФСТЭК России от 02.06.2020 г. № 76 и вступает в силу с 1 января 2021 г., за исключением некоторых положений, вступающих в силу с 1 января 2022 г., 2024 г. и 2028 г. соответственно. Приказ ФСТЭК России от 02.06.2020 г. № 76, как и предыдущая версия Требований к уровням доверия, носит ограничительную пометку "ДСП". Отмечается, что Требования к уровням доверия предназначены для организаций, осуществляющих работы по созданию программных, программно-технических средств технической защиты информации, средств обеспечения безопасности информационных технологий, включая защищенные средства обработки информации, заявителей на осуществление сертификации, а также для испытательных лабораторий и органов по сертификации, выполняющих работы по сертификации средств на соответствие обязательным требованиям по безопасности информации. Однако применение Требований к уровням доверия с 1 января 2023 г. является обязательным в том числе при проведении работ по оценке соответствия в форме испытаний или приемки для средств защиты информации (СрЗИ) значимых объектов критической информационной инфраструктуры (КИИ). Изготовителям средств, сертифицированных по схеме сертификации для серийного производства, необходимо привести средства в соответствие Требованиям к уровням доверия в сроки, установленные приказом ФСТЭК России от 02.06.2020 г. № 76, и проинформировать об этом ФСТЭК России для переоформления сертификатов соответствия. Новая версия Требований к уровням доверия также вводит обязательность соответствия уровням контроля, соот-

3 4 5 6

ветствующим уровням доверия, которые определяют процессы исследования по выявлению уязвимостей и недекларированных возможностей.

Стандарты управления доступом 13 октября ФСТЭК России опубликовала окончательные редакции проектов национальных стандартов ГОСТ Р, разрабатываемых в соответствии с Программой разработки национальных стандартов на 2019 и 2020 гг. в рамках работы технического комитета по стандартизации "Защита информации" (ТК 362): l Защита информации. Формальная модель управления доступом. Часть 1. Общие положения3 . l Защита информации. Формальная модель управления доступом. Часть 2. Рекомендации по верификации формальной модели управления доступом4. Стандарты предназначены для разработчиков СрЗИ, реализующих политики управления доступом, а также для органов по сертификации и испытательных лабораторий при проведении сертификации СрЗИ, реализующих политики управления доступом. Стандарты представляют собой рекомендации по верификации с применением инструментальных средств формальных моделей управления доступом, на основе которых разрабатываются СрЗИ, реализующие политики управления доступом (дискреционная, ролевая, мандатная или другие виды политик управления доступом).

Импортозамещение в критической информационной инфраструктуре Минцифры России 29 октября 2020 г. представило к публичным обсуждениям проект указа Президента Российской Федерации "О мерах по обеспечению информационной безопасности в эко-

номической сфере при использовании программного обеспечения и оборудования на объектах критической информационной инфраструктуры" (далее – проект указа)5. Предыдущая версия проекта указа размещалась для общественного обсуждения в мае 2020 г6., текущая версия проекта указа представлена для публичного обсуждения до 26 ноября 2020 г. Проектом указа предусматривается наделение Правительства РФ полномочиями по утверждению требований к программному обеспечению и оборудованию, используемому на объектах КИИ, и порядка перехода на преимущественное использование российского ПО и оборудования. Под преимущественным использованием понимается приоритетное использование российского ПО и/или оборудования при наличии соответствующих российских аналогов. При этом, как ни странно, по проекту указа такие требования Правительство РФ должно было утвердить до 1 сентября 2020 г. По проекту указа субъекты КИИ должны будут до 1 января 2024 г. осуществить переход на преимущественное использование российского ПО и до 1 января 2025 г. осуществить переход на преимущественное использование российского оборудования. К проекту указа прилагается проект постановления Правительства РФ, согласно которому надзорным органом по контролю использования субъектами КИИ российского ПО будет Минцифры России, а по использованию российского оборудования – Минпромторг России. При этом при использовании и/или планировании использования иностранного ПО и/или оборудования на объектах КИИ субъект КИИ должен будет направить на согласование перечень такого ПО и/или оборудования в соответствую-

https://fstec.ru/component/attachments/download/2826 https://fstec.ru/component/attachments/download/2829 https://regulation.gov.ru/Projects/List#npa=109874 https://regulation.gov.ru/projects#npa=102172

• 7

ПРАВО И НОРМАТИВЫ Новое положение Банка России

щий надзорный орган: если это ПО – в Минцифры России, если это оборудование – в Минпромторг России. Рассмотрение перечней ПО и /или оборудования должно будет осуществляться совместно Минцифры России, Минпромторгом России, ФСБ России и ФСТЭК России в течение 30 рабочих дней с момента поступления в уполномоченный орган перечней. В конечном итоге, с учетом сроков перехода на преимущественное использование российского ПО и оборудования, установленных проектами, субъекту КИИ необходимо будет до 1 июля 2021 г. подготовить и утвердить план перехода на преимущественное использование российского ПО и/или оборудования. Копию плана в течение 30 рабочих дней с момента его утверждения необходимо направить в Минцифры России и Минпромторг России.

Обеспечение безопасности операторами финансовых платформ 6 октября 2020 г. Банк России опубликовал проект указания "О ведении Банком России реестра операторов финансовых платформ, о требованиях к юридическому лицу, намеревающемуся получить статус оператора финансовой платформы, по защите информации и о требованиях к порядку регистрации Банком России изменений в правила финансовых платформ" (далее – проект указания Банка России)7. Проект указания Банка России в том числе устанавливает требования по защите информации к юридическому лицу, намеревающемуся получить статус оператора финансовой платформы, а также требования к документам по защите информации, подтверждающим их выполнение таким юридическим лицом. Оператор финансовой платформы должен предоставить регламентированные проектом указания Банка России сведения, подтверждающие выполнение соискателем требований по защите информации.

7 8

Заполнение сведений осуществляется по результатам проведения оценки соответствия по следующим направлениям: l оценка выполнения требований к технологическим мерам защиты информации (направление "Технологические меры"); l оценка выполнения требований к безопасности прикладного ПО автоматизированных систем и приложений (направление "Безопасность ПО"); l оценка выполнения требований к обеспечению защиты информации информационной инфраструктуры (направление "Безопасность информационной инфраструктуры"). При этом заполнение сведений об оценке выполнения требований по направлению "безопасность информационной инфраструктуры" по проекту указания Банка России должно осуществляться в соответствии с требованиями к методике оценки соответствия защиты информации, установленными разделом 7 ГОСТ Р 57580.2–2018 "Безопасность финансовых (банковских) операций. Защита информации финансовых организаций. Методика оценки соответствия" (далее – ГОСТ Р 57580.2–2018). В рамках направления "Безопасность информационной инфраструктуры" проводится оценка применения организационных и технических мер процессов системы защиты информации, указанных в ГОСТ Р 57580.1–2017 "Безопасность финансовых (банковских) операций. Защита информации финансовых организаций. Базовый состав организационных и технических мер" (далее – ГОСТ Р 57580.1– 2017). По проекту указания Банка России оценка соответствия по направлению "Безопасность информационной инфраструктуры" должна осуществляться с привлечением сторонних организаций, имеющих лицензию на деятельность по технической защите конфиденциальной информации.

https://regulation.gov.ru/projects#npa=109072 https://cbr.ru/Queries/UniDbQuery/File/90134/1119

8 •

Банком России 2 октября 2020 г. официально опубликовано положение Банка России от 4 июня 2020 г. № 719 "О требованиях к обеспечению защиты информации при осуществлении переводов денежных средств и о порядке осуществления Банком России контроля за соблюдением требований к обеспечению защиты информации при осуществлении переводов денежных средств"8 (далее – 719-П).

719-П вступает в силу с 1 января 2022 г., за исключением положений, для которых установлены иные сроки вступления их в силу (1 января 2024 г. и 1 января 2031 г.). Со дня вступления в силу 719-П признается утратившим силу положение Банка России от 9 июня 2012 г. № 382-П "О требованиях к обеспечению защиты информации при осуществлении переводов денежных средств и о порядке осуществления Банком России контроля за соблюдением требований к обеспечению защиты информации при осуществлении переводов денежных средств" (далее – 382-П). Согласно 719-П требования по обеспечению защиты информации при переводе денежных средств будут распространяться не только на операторов по переводу денежных средств, банковских платежных агентов (субагентов), операторов платежных систем, но и на операторов услуг информационного обмена и поставщиков платежных приложений. Из основных отличий 719-П от "старого" 382-П можно выделить следующие: l обязательная реализация уровней защиты информации для объектов информационной инфраструктуры, определенных ГОСТ Р 57580.1–2017; l необходимость проведения сторонней организацией-лицензиатом оценки соответствия уровням защиты информации в соответствии с ГОСТ Р 57580.2–2018; l обязанность операторов по переводу денежных средств выполнять требования положения Банка России от 17 апреля 2019 г. № 683-П; l для прикладного ПО автоматизированных систем и приложений, с учетом особенностей, проведение оценки соответствия по требованиям к оценочному уровню доверия (ОУД) не ниже, чем ОУД 4, в соответствии с требованиями ГОСТ Р ИСО/МЭК 15408-3–2013, либо сертификация в системе сертификации ФСТЭК России. При этом стоит отметить, что 719-П ссылается на требования к уровням доверия, установленные приказом ФСТЭК России от 30.07.2018 г. № 131, который будет отменен в январе 2021 г.; l установлены требования к банковским платежных агентам и субагентам. l Ваше мнение и вопросы присылайте по адресу

is@groteck.ru

www.itsec.ru

ИМПОРТОЗАМЕЩЕНИЕ

Кому нужны сертифицированные средства управления мобильностью Олег Ассур, главный инженер НИИ СОКБ

П

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

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

– Согласно постановлению Правительства РФ № 676 от 6 июля 2015 г., ни одна государственная информационная система (ГИС) не может быть введена в эксплуатацию без аттестации по требованиям безопасности информации. Если в ГИС используются мобильные устройства для доступа, хранения и обработки информации, то они должны быть защищены средствами защиты и управления мобильными устройствами (MDM/EMM/UEM), имеющими сертификат ФСТЭК России. Возможна альтернатива – реализовать функции MDM/EMM/UEM в прикладном ПО ГИС и сертифицировать его во ФСТЭК России, но это долго и дорого. В процессе аттестации проверяется корректность использования и правильность настройки средств защиты информации, включая MDM/EMM/UEM. Корректность настройки проверяется по документам, на соответствие которым были сертифицированы решения, – техническим условиям, техническому заданию или заданию по безопасности.

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

– Для управления и защиты различных типов мобильных устройств и операционных систем в настоящее время сертифицировано единственное решение – это наша платформа SafePhone1. Платформа SafePhone включена в реестр отечественных программ Минцифры России. Кроме

того, применение SafePhone обеспечивает выполнение требований ГОСТ Р 57580.1–2017 "Безопасность финансовых (банковских) операций. Защита информации финансовых организаций".

– Каким еще организациям обязательно требуется сертифицированная MDM-система?

– Кроме компаний, эксплуатирующих государственные информационные системы с удаленным доступом с мобильных устройств, применять сертифицированные MDM-системы обязаны компании, являющиеся владельцами объектов критической информационной инфраструктуры. Конечно, если субъекты хотят получать к ним удаленный доступ. Организациям, обрабатывающим персональные данные (ПДн), пока только рекомендовано использование сертифицированных средств защиты. Тем не менее многие такие компании уже сейчас выбирают решения, сертифицированные ФСТЭК, чтобы в случае возникновения инцидентов иметь необходимые аргументы. Также над применением сертифицированных MDM-систем следует задуматься финансовым организациям, которые согласно ГОСТ Р 57580 должны использовать MDM-системы, если предоставляют своим сотрудникам удаленный доступ с мобильных устройств. ЦБ РФ использует наше решение SafePhone, и это еще один аргумент для того, чтобы обратить на него внимание.

– Правда ли, что удаленный доступ к ГИС и КИИ с мобильных устройств на Android и iOS невозможен?

– Нет, это неправда. Сегодня на улицах нашего города трудятся тысячи медицинских работ-

ников с планшетами на Android, подключенными к ЕМИАС. Аналогичными планшетами оснащаются врачи Московской и Калужской областей. И на всех этих мобильных устройствах установлен SafePhone, что позволило выполнить требования регуляторов в области информационной безопасности. Планшетами на iOS врачей, конечно, не оснащают, но они используются многими государственными ведомствами для организации удаленного доступа руководителей к данным, нужным им для работы. Чтобы делать это не из-под полы, пересылая необходимые данные на личную почту, нужны сертифицированные решения. Опыт использования SafePhone для решения подобных задач у нас также имеется.

Сертифицированные MDM-системы обязаны иметь компании, являющиеся владельцами объектов критической информационной инфраструктуры. Конечно, если субъекты

– Как можно снизить стоимость системы удаленного мобильного доступа к корпоративным данным?

– Типовой комплекс средств защиты мобильных устройств включает в себя VPN, MDM и антивирус. Чтобы оптимизировать затраты своих заказчиков, мы недавно встроили2 в свою платформу антивирусные библиотеки "Лаборатории Касперского". Теперь заказчикам нужно покупать на одно решение меньше. Еще одним способом оптимизации затрат является приобретение сервиса на базе сертифицированного продукта из защищенного ЦОД3, аттестованного по требованиям безопасности информации. Такую услугу на базе SafePhone мы также предоставляем. l

хотят получать к ним удаленный доступ.

1 https://safephone.ru/system/ 2 http://mtd.safephone.ru/ 3 https://safedc.ru/

NM

Реклама

АДРЕСА И ТЕЛЕФОНЫ "НИИ СОКБ" см. стр. 60

• 9

В ФОКУСЕ

Локализация технологий как инструмент эффективного импортозамещения Александр Зубарев, директор по информационной безопасности компании Huawei в России

П

Прямые запреты импорта могут стимулировать местное производство, но не способны скрыть технологическое отставание, особенно в области ПО АСУ ТП, системного ПО и оборудования.

1

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

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

Заместить любой ценой? Напомним, что импортозамещение сегодня – не прихоть отдельных компаний, а государственная программа с четко определенными целями. Переход на отечественные разработки предусмотрен в национальной программе "Цифровая экономика Российской Федерации", утвержденной еще в 2018 г. Согласно целевым показателям нацпроекта, к 2024 г. доля российского ПО в госструктурах должна составлять 90%, в госкомпаниях – 70%. Аналогичные планы приняты и в отношении оборудования – от 80% до 100% к 2021 г. Появляется все больше специализированных игроков, развивается Реестр российского ПО и телекоммуникационного оборудования. Наиболее успешно проходит замена иностранных решений в сегментах офисного ПО, системах экономической (финансово-хозяйственной) деятельности и системах информационной безопасности.

https://techcrunch.com/2020/09/15/china-tops-110-million-5g-users-in-less-than-a-year/

10 •

Структура ИКТ для возможного импортозамещения схематично показана на рисунке. В то же время следует признать, что шесть лет импортозамещения все же не привели к серьезному изменению рынка ИКТ. Пример тому – отставание в развитии технологии связи нового поколения 5G. В России 5G пока не выходит за пределы небольших пилотных зон, где связь пятого поколения разворачивают в демонстрационных целях. Тем временем в Китае, например, количество абонентов коммерческих сетей 5G на сентябрь 2020 г. уже превысило 100 млн1. Кроме того, по данным Счетной палаты (2019 г.), в госкомпаниях продолжают оставаться иностранными 99% СУБД, 96% ОС и 82% почтовых систем. Эти данные показывают, что нескольких лет недостаточно, чтобы компенсировать отсутствие сложных технологий. Прямые запреты импорта могут стимулировать местное производство, но не способны скрыть технологическое отставание, особенно в области ПО АСУ ТП, системного ПО и оборудования. Необходимость быстро закрыть потребности рынка приведет к потерям в функционале и появлению нишевых продуктов вместо комплексной экосистемы разработки и поддержки. Итоговая стоимость такого перехода может быть слишком высокой. Поэтому важно не только установить измеряемую цель, но и определить способы ее достижения, эффективные в долгосрочной перспективе.

www.itsec.ru

ИМПОРТОЗАМЕЩЕНИЕ

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

На правах рекламы

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

Таблица Способ

Преимущества

Недостатки

Вывод

Новая разработка

Максимальная независимость от иностранных решений

Риск неуспешного результата

Применим для новых технологий или специальных сегментов рынка

Продолжительность разработки Высокие затраты на разработку

Реализация уникальных особенностей продукта, включая требования по безопасности Адаптация свободного ПО

Необходимость создания экосистемы

Наличие экосистемы разработки и поддержки

Реализуемо не для всех задач Проблемы с масштабированием

Возможность разработки в короткие сроки

Проблемы с надежностью и безопасностью

Конкурентоспособная функциональность

Локализация технологий

Применим для некоторых массовых сегментов ИКТ

Сложность поддержки и актуализации

Возможность разработки и выхода на рынок в сравнительно короткие сроки

Необходимость договариваться с вендорами для выполнения локальных требований

Наличие экосистемы разработки и поддержки Современная функциональность

Универсальный и эффективный подход

Не достигается максимальная независимость

Возможность реализации специальных требований по безопасности

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

2. Набор требований, предъявляемых к продуктам российского происхождения, сформулирован однозначно и не предполагает каких-либо промежуточных статусов. Установление более гибких критериев или разработка системы уровней локализации

могли бы обеспечить постепенный и качественный процесс импортозамещения.

3. Создание российских R&Dцентров иностранных компаний необоснованно не рассматривается сегодня как существенный вклад в процесс обретения технологической независимости, несмотря на то, что они являются важными участниками процесса импортозамещения. Регулирование в этой области отсутствует. Уточнение статуса R&D-центров и создание возможностей для переноса отдельных циклов разработки и верификации в Россию – еще один важный стимул локализации современных информационнокоммуникационных технологий. В заключение следует отметить, что импортозамещение – комплексная проблема, издержки и первоначальное отставание здесь неизбежны. Важно, чтобы результатом этого процесса стала не изоляция, а укрепление доверия сторон, открытость и доступность наиболее перспективных технологий, соответствующих при этом самым высоким стандартам безопасности. Автор выражает благодарность своим коллегам Илье Трифаленкову и Юлии Чернокожиной за участие в работе над статьей. l

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

Ваше мнение и вопросы присылайте по адресу

is@groteck.ru

• 11

В ФОКУСЕ

Что нам стоит SOC построить? Алексей Юдин, директор центра мониторинга компании “Инфосекьюрити” (ГК Софтлайн) Александр Дворянский, директор по маркетингу компании “Инфосекьюрити” (ГК Софтлайн)

– Расскажите, пожалуйста, немного о вашей биографии. Алексей, давайте начнем с вас. Алексей Юдин: Я закончил факультет прикладной математики в Московском государственном университете леса. После выпуска работал в различных компаниях отрасли: почти десять лет проработал в Positive Teсhnologies, где занимался развитием и созданием продуктов, после чего был техническим директором по развитию продуктов в Bi.ZONE и директором Центра кибербезопасности и защиты в "Ростелекоме". Сейчас я являюсь директором центра мониторинга и реагирования на инциденты в "Инфосекьюрити". Александр Дворянский: Я в этой отрасли уже больше пятнадцати лет, начинал с защиты дистанционного банковского обслуживания в компании BCC. В компании "Инфосекьюрити" работаю с 2015 года. В 2018 году, когда мы стали частью группы компаний "Софтлайн", я стал курировать стратегические коммуникации: маркетинг, PR и взаимодействие с ключевыми партнерами. Однако по образованию я гуманитарий. Первое образование – Высшая школа экономики, менеджмент организаций, а второе – Финансово-юридическая ака-

12 •

демия, банковское дело. Специального ИТ- или ИБ-образования у меня нет, однако могу с уверенностью сказать, что в теме я разбираюсь.

– А как вы считаете, какими навыками должны обладать современные специалисты по информационной безопасности? Алексей Юдин: Все зависит от специализации. Если речь о глубоко технических экспертах, у которых нет необходимости общаться непосредственно с заказчиками, то они, безусловно, должны отлично владеть Hard Skills и экспертными техническими знаниями. Если же мы говорим о специалистах, которые в процессе своей деятельности в том числе взаимодействуют с заказчиками, то им, помимо технической базы, необходимо еще иметь хороший уровень Soft Skills для правильных и грамотных коммуникаций.

– Переходя к основной теме, расскажите, при каких обстоятельствах вы пришли к решению построить собственный SOC? Алексей Юдин: Необходимость построения собственного SOC возникла после нескольких высококритичных инцидентов, возникших в рамках

нашей работы с большим финансовым холдингом. Процессы выявления инцидентов и попытки их оперативного расследования у заказчика были осложнены внутренними распорядками и регламентами холдинга. Например, не было точного понимания, к кому необходимо обращаться для блокировки учеток или изолирования узлов в сети, что серьезно отражалось на скорости реакции на серьезные инциденты. В какой-то момент нам потребовалось собирать, обрабатывать и хранить все происходившие события в течение пяти лет. Как вы понимаете, это очень большой объем данных, требующий соответствующей инфраструктуры. Сначала мы тестировали типовые решения, присутствовавшие на рынке, но рано или поздно мы упирались в их функциональные ограничения. Причем ни одно SIEM-решение не могло справиться с таким масштабом, а если и гипотетически могло, то обходилось в огромные деньги, которые заказчик не был готов вкладывать. В дополнение к этому возникали проблемы с оперативными запросами в базу событий, когда на простой запрос, например "На какие серверы входил пользователь за три месяца?", система не могла выдать ответ в течение нескольких дней. Также для выявления вредоносных активностей требовался сбор информации с рабочих станций и серверов, при этом часть действий в процессе должен был осуществлять администратор. Но бывают ситуации, в которых даже малейшее промедление может привести к серьезным последствиям. Поэтому в своем продукте мы решили автоматизировать этот процесс. В то время мы были одними из первых, кто активно внедрил эту технологию. Теперь это отдельный класс продуктов, который называется Endpoint Detection and Response. Вся совокупность этих факторов окончательно убедила нас в необходимости создания собственного центра реагирования на инциденты информационной безопасности на базе технологий больших данных (Big Data). Сейчас наше решение основывается на стеке технологий Hadoop и механизме пассивного сбора событий, который в автоматическом режиме отправляет нам информацию о событиях, исключая временные затраты на проверку сетевых доступов, учетных записей и т.д.

www.itsec.ru

ПЕРСОНЫ

– Какие еще подходы и технологии вы используете? Алексей Юдин: С точки зрения технологий мы выбрали не совсем стандартный путь, отличающийся от тех, по которым обычно идут производители программных решений и поставщики сервисов. Для большей части наших компонентов мы использовали открытое ПО, так называемые Open Source решения. Мы определили два критерия: использовать то, что есть и поддерживается на рынке, не изобретая велосипед, и то, что беспроблемно встраивается в наши процессы. Основной целью было сделать удобный инструмент, который при необходимости можно масштабировать и на который мы не будем тратить ресурсы своих или сторонних разработчиков. Особенность и сложность нашей работы состоит в интеграции всех компонентов в единую цепочку обработки, выявлении инцидентов в потоке событий и, соответственно, их расследовании. Эти задачи как раз для SOC, а не для SIEM. – Вы используете MSSP-модель предоставления сервиса. Насколько она применима в России? Александр Дворянский: MSSP – это модель управляемых сервисов, когда услуга предоставляется по подписке, при этом объем оказываемых сервисов заказчик может регулировать самостоятельно. Эта модель пришла к нам из-за рубежа и постепенно становится востребованной. В высокотехнологичных компаниях, например, эта технология уже входит в привыч-

ную практику, позволяя передавать на аутсорсинг большую часть своих бизнес-процессов. Со временем рынок пришел к тому, что теперь и услуги SOC стали предоставляться по модели MSSP. Это более чем удобный формат, поскольку провайдер предоставляет исключительно необходимый вам объем высокотехнологичных услуг с четко обозначенным уровнем сервисного обслуживания (SLA), не говоря об отсутствии у заказчика капитальных затрат и необходимости поиска и найма команды профессионалов. Думаю, что в ближайшее время мы увидим полноценный расцвет направления MSSP в России.

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

матически классифицируется, а человек на него реагирует.

– В чем ключевые различия внутреннего SOC, SOC as a Serviсe и гибридного SOC? Александр Дворянский: Если говорить простым языком, то внутренний SOC – это построение собственного полноценного центра мониторинга и реагирования на инциденты информационной безопасности у заказчика. Обычно построение собственного SOC неразлучно с огромными капитальными затратами и кадровыми вопросами, как сложностями в создании команды, так и высокими рисками потери ключевых сотрудников. Наверное, такой формат SOC могут позволить себе крупные госструктуры либо очень крупный бизнес.

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

• 13

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

– Если компания решила, что нужен SOC, с чего следует начать? Алексей Юдин: Сначала нужно ответить себе на вопрос: зачем? Потому что то время, когда иметь SOC было модно, уже прошло. Подход несколько лет назад был следующим: а давайте соберем все данные, будем их хранить и они нам потом, возможно, когда-нибудь пригодятся или давайте включим 300 правил корреляции и будем реагировать на все. Но через некоторое время обязательно возникал вопрос: деньги мы потратили, а что в итоге получили? К счастью, ситуация изменилась. Сейчас в основном все компании понимают, что SOC – это необходимость, а основные вопросы касаются окупаемости затрат на построение и эксплуатацию SOC. А начать всегда можно с формулировки целей SOC, какой выделен бюджет, на каких решениях он будет построен, какие регуляторные требования должен закрыть, кто его будет эксплуатировать, с какими внутренними системами его нужно интегрировать, кто будет выявлять и реагировать на инциденты и в каком режиме.

ламенты, прописываются процедуры реагирования. В результате на базе этого SIEM достраиваются процессы SOC. – Решение каких задач и какие возможности получает потребитель услуг SOC? Алексей Юдин: Это очень зависит от заказчика, его желаний, возможностей и даже от зрелости внутренних процессов. Большая часть заказчиков, которые еще не пробовали такой сервис, но которым нужно достаточно быстро решить задачу мониторинга (причиной могут быть регуляторные или внутренние требования), настаивает просто на получении уведомлений. То есть мы

14 •

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

– Можете ли вы рассказать о публичных внедрениях вашего решения? Александр Дворянский: На сегодняшний день мы имеем возможность рассказать лишь о двух, но зато интересных, кейсах. Гибридную схему подключения к SOC использует государственная транспортная лизинговая компания, ПАО "ГТЛК". Проект интересен тем, что в 2017 году компания купила PT SIEM. Затем вместе с развитием компании появилась необходимость контролировать несколько разрозненных площадок, включая международные, а следовательно пришло понимание, что простого SIEM уже недостаточно. То есть нужны регламенты, методология, структурированные и отлаженные процессы реагирования на инциденты, а главное –

www.itsec.ru

ПЕРСОНЫ

сотрудники под эти задачи. В результате в середине 2020 года мы официально завершили подключение ПАО "ГТЛК" к центру реагирования на инциденты SOC. И второй кейс – это подключение к нашему облачному сервису SBI Bank, одного из крупнейших японских банков, который работает в России.

– Есть ли практика обмена опытом российскими и зарубежными коллегами? Алексей Юдин: Да, безусловно. Мы входим в международную ассоциацию FIRST, которая объединяет группы по выявлению инцидентов. Наша команда на постоянной основе обменивается информацией и опытом с иностранными коллегами. Основное направление деятельности FIRST – это участие в расследовании и реагирование на наиболее масштабные инциденты, затрагивающие не одного заказчика, а группу или даже отрасль. Мы плотно работаем с регистраторами доменных имен и другими организациями в части блокировки подозрительных и вредоносных серверов и доменов. На российском рынке мы также сотрудничаем с большим количеством игроков в отрасли: обмениваемся информацией об угрозах, делимся опытом расследований инцидентов, взаимодействуем по вопросам выявления новых экземпляров вредоносного ПО и другим моментам.

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

"любителями", которым было интересно себя показать, то сейчас это полноценные группировки, хорошо финансируемые и снабжаемые. Сейчас это бизнес, криминальный бизнес. Алексей Юдин: Стоит также учитывать и историю с коронавирусом, которая перевела большую часть компаний на работу в удаленном формате. При этом мало кто знает, как правильно сохранить контроль над данными. Если раньше все находилось в закрытом периметре, можно было поставить антивирус, межсетевой экран и спать спокойно. Сейчас же компании сильно задумались над тем, как это безопасно организовать и контролировать.

– Видите ли вы перспективы продвижения российских решений и сервисов на зарубежные рынки? Алексей Юдин: Перспективы движения на зарубежные рынки есть всегда, вопрос – на какие. Потому что есть достаточно зрелые рынки Америки и Европы, на которых уже давно и успешно работает большое количество компаний. Есть рынки Азии, Латинской Америки и других развивающихся стран, где уровень зрелости в части информационной безопасности отстает от лидирующих рынков приблизительно на пять лет. Сейчас до них тоже доходит необходимость создания центров SOC.

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

– Какие у вас планы развития SOC? Алексей Юдин: Помимо развития основного направления сервиса в России, есть планы по развитию сервиса в Индии и созданию полноценного деливери-центра не только для Индии, но и для стран Европы. Возможно создание аналогичных центров в странах Латинской Америки по похожей технологии. Отдельно мы также выделяем направление по созданию SOC на базе разработанного нами технологического стека,

мы готовы начать активную работу по этому направлению уже в следующем году. Дело в том, что на российском рынке есть решения класса SIEM, IRP, сканеры безопасности и другие инструменты, но готового комплекса решений для построения SOC мы, к сожалению, на нашем рынке не видим. Получается, нужно покупать множество продуктов, собирать из них мозаику, нанимать архитектора, который будет этот комплекс интегрировать. А квалифицированных архитекторов на рынке можно буквально пересчитать по пальцам, их очень мало. Особенно остро этот вопрос стоит для регионов с их традиционно более низким уровнем зарплат по сравнению с Москвой. Александр Дворянский: Я бы хотел добавить еще один важный момент. Мы обсудили Латинскую Америку, обсудили Европу, но в последнее время достаточно большой интерес к вопросам кибербезопасности проявляют и страны СНГ. У нас уже есть несколько совместных проектов, поскольку менталитет, уровень зрелости и характер угроз в России и странах СНГ достаточно схожи. По сути, технологии у нас плюс-минус одни и те же. Беларусь, например, очень сильно похожа на Россию инфраструктурой и технологиями, и в этот регион мы тоже планируем продвигаться.

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

is@groteck.ru

• 15

СПЕЦПРОЕКТ

Роль SOC в безопасности критической информационной инфраструктуры Константин Саматов, эксперт по кибербезопасности Уральского центра систем безопасности, руководитель комитета по безопасности КИИ, член правления Ассоциации руководителей служб информационной безопасности, преподаватель дисциплин информационной безопасности в УрГЭУ и УРТК им. А.С. Попова

В

опросами, связанными с созданием и функционированием SOC (Security Operations Center), сейчас активно интересуются практически все организации, попавшие под действие Федерального закона “О безопасности критической информационной инфраструктуры”. В этой статье я расскажу о роли SOC в выполнении требований данного федерального закона, уделяя внимание наиболее часто встречающимся в его практике вопросам.

Обязателен ли SOC для выполнения требований по КИИ?

Требования 187-ФЗ не содержат обязанности субъекта КИИ по созданию центров мониторинга и реагирования.

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

Федеральный закон "О безопасности критической информационной инфраструктуры Российской Федерации" от 26.07.2017 № 187-ФЗ (далее – закон о безопасности КИИ) возложил на субъекты критической информационной инфраструктуры обязанности, связанные с реагированием на компьютерные атаки на принадлежащие им объекты КИИ и информированием уполномоченного органа (ФСБ России) о компьютерных инцидентах. В рамках исполнения перечисленных выше обязанностей резкий стимул к развитию получило направление центров мониторинга и реагирования на инциденты информационной безопасности, продвигаемое маркетологами провайдеров данной услуги под аббревиатурой SOC (Security Operations Center). Для правильного понимания сущности SOC1 мне хотелось бы обратить внимание на два момента: 1. Центры мониторинга и реагирования – это не новация, про них известно уже много лет, и многие зрелые с точки зрения информационной безопасности компании (например, ГК "Росатом", ПАО "Газпром", ГК "Ростех")2 имели такие центры еще до принятия закона о безопасности КИИ.

2. Для выполнения требований закона о безопасности КИИ на текущий момент можно обойтись без SOC. Так, закон о безопасности КИИ содержит следующие нормы, касающиеся событий и инцидентов информационной безопасности: 1. Ст. 9 закона о безопасности КИИ: l незамедлительно информировать о компьютерных инцидентах ФСБ России и (или) Центральный Банк России в порядке, установленном приказом ФСБ России от 19.06.2019 № 282; l оказывать содействие должностным лицам ФСБ России в обнаружении, предупреждении и ликвидации последствий компьютерных атак, установлении причин и условий возникновения компьютерных инцидентов; l в случае установки на объектах КИИ средств, предназначенных для обнаружения, предупреждения и ликвидации последствий компьютерных атак и реагирования на компьютерные инциденты, обеспечивать выполнение порядка технических условий установки и эксплуатации таких средств, их сохранность; l реагировать на компьютерные инциденты в порядке, утвержденном приказом ФСБ России от 19.06.2019 № 282, принимать меры по ликвидации последствий компьютерных атак, проведенных в отношении значимых объектов КИИ.

2. Ст. 10 закона о безопасности КИИ предусматривает обеспечение непрерывного взаимодействия с государственной системой обнаружения, предупреждения и ликвидации последствий компьютерных атак на информационные ресурсы Российской Федерации. Таким образом, видно, что указанные требования не содержат обязанности субъекта КИИ по созданию центров мониторинга и реагирования. Возникает вопрос: какова роль SOC в безопасности КИИ и почему с принятием закона о безопасности КИИ к теме центров мониторинга и реагирования повысился интерес?

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

1 Вопросы, касающиеся того, что такое SOC, какова его структура и функции, рассматривались в статье: Саматов К.М. SOC в действии // Information Security/Информационная безопасность. 2019. № 5. С. 24–25.

2 Петренко С.А., Ступин Д.Д. Национальная система раннего предупреждения о компьютерном нападении: научная монография / под общей редакцией С.Ф. Боева. Университет Иннополис. – Иннополис: “Издательский Дом “Афина", 2017. – С. 16.

16 •

www.itsec.ru

SOC

2. Государственная система обнаружения, предупреждения и ликвидации последствий компьютерных атак на информационные ресурсы Российской Федерации (ГосСОПКА), основной организационно-технической составляющей которой являются центры обнаружения, предупреждения и ликвидации последствий компьютерных атак3, непрерывное взаимодействие с которой обязан обеспечить субъект КИИ в рамках исполнения обязанностей, возложенных на него законодательством. Таким образом, несмотря на то, что закон о безопасности КИИ не содержит прямого указания на создание центров мониторинга и реагирования, обеспечить оперативный ответ на происходящую на критическую информационную инфраструктуру компьютерную атаку на ранних этапах и обеспечить оптимальное взаимодействие с ГосСОПКА для субъектов КИИ, имеющих множество взаимосвязанных между собой объектов информационной инфраструктуры, без участия SOC будет невозможно. Из вышеизложенного вытекает вопрос о том, в каких же все-таки случаях создание центра мониторинга и реагирования необходимо, а в каких без него можно обойтись.

Кому действительно нужен SOC и какие варианты реализации выбрать? Основными критериями для ответа на этот вопрос будут служить масштаб организации, то есть количество принадлежащих ей объектов КИИ, и наличие связи указанных объектов с внешними сетями. Так, если все объекты представляют собой изолированные от внешних сетей системы, то создание для них системы мониторинга (по сути, связывание в единую систему) приведет к появлению новых угроз: все системы станут взаимосвязаны и неблагоприятное воздействие на одну из них (например, заражение вредоносным кодом со съемного носителя) может привести к воздействию на все остальные. Если количество объектов КИИ невелико (5–10) и они находятся в пределах одной контролируемой зоны, то осуществлять контроль за ука-

занной инфраструктурой можно и без создания отдельного специализированного центра. Если же субъект КИИ обладает большим количеством объектов, они территориально распределены и имеют подключение к сетям связи общего доступа, то вопрос создания собственного центра мониторинга и реагирования или передачи функций в части мониторинга и управления событиями (инцидентами) провайдеру услуг SOC уже становится актуальным, потому что обеспечить адекватный мониторинг и своевременное реагирование на компьютерные атаки и компьютерные инциденты в большой и сложной информационной инфраструктуре без использования Security Operations Center становится невозможным. Следует отметить, что создавать собственный центр мониторинга и реагирования даже в этом случае не обязательно, можно воспользоваться услугами провайдера SOC, которых на рынке существует множество. Следовательно, для многих субъектов КИИ актуальным становится вопрос о том, какой из указанных вариантов всетаки выбрать. В каждом конкретном случае, исходя из особенностей деловых процессов организации, имеющегося бюджета на информационную безопасность и сроков, должно приниматься отдельное решение. В качестве сильных и слабых сторон обоих вариантов можно отметить следующие моменты.

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

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

Обеспечить оптимальное взаимодействие с ГосСОПКА для субъектов КИИ, имеющих множество взаимосвязанных между собой объектов информационной инфраструктуры, без участия SOC будет невозможно.

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

3 П. 9. Выписки из Концепции государственной системы обнаружения, предупреждения и ликвидации последствий компьютерных атак на информационные ресурсы Российской Федерации (утв. президентом РФ 12.12.2014 г. № К 1274).

• 17

СПЕЦПРОЕКТ

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

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

Создание собственного центра мониторинга и реагирования субъектом КИИ В качестве основного плюса такого подхода можно отметить создание единого центра компетенций по обеспечению без-

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

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

is@groteck.ru

Группа компаний Angara стирает границы между коммерческим и корпоративным SOC

В портфеле SOC, помимо собственной запатентованной платформы ACR Platform, находятся решения класса SIEM, IRP/SOAR, Security Intelligence (BI для ИБ) и аналитический программный комплекс Dataplan.

NM

Группа компаний Angara объявила о слиянии сервисного направления предоставления услуг SOC на базе собственного центра киберустойчивости ACRC с практикой мониторинга и реагирования на инциденты ИБ. Новое направление в формате единого окна будет решать клиентские запросы вне зависимости от степени укомплектованности технической и экспертной базы путем замещения любых функциональных ролей SOC по подписной модели (MDRS), а также предоставит клиентам возможность подключить Red team, Blue team, Purple team и SOC L1/L2 в любом формате на любом этапе и платформе. "На сегодняшний день в России у функционального заказчика есть два варианта: отдать мониторинг ИБ на аутсорсинг комРеклама

АДРЕСА И ТЕЛЕФОНЫ "Группы компаний Angara" см. стр. 60

18 •

мерческому SOC либо обеспечивать его на своих средствах защиты, наняв экспертизу для их настройки. Во втором случае заказчики нередко сталкиваются с проблемой, когда технические решения работают, а трудовых ресурсов на обеспечение самого процесса нет. Здесь сказывается как высокая стоимость ФОТ, так и кадровый дефицит в этой области. При этом передать эту функцию подрядчикам не представляется возможным, поскольку они отказываются работать на чужих системах. И это одно из немногих ограничений, которые существуют в рамках сложившегося разделения между практиками. Мы решили стереть границу между SOC onpremise и SOC outsource и предложить заказчикам самим выбирать, как "перемешивать" эти направления в соответствии со стоящими перед ними задачами", – комментирует Тимур Зиннятуллин, вступивший в должность директора Центра киберустойчивости ACRC.

Запустить модель MDRS позволяет накопленная экспертиза как коммерческого SOC компании, так и отдела систем мониторинга и реагирования. Центр киберустойчивости ACRC группы компаний Angara будет оказывать услуги и с использованием своих систем мониторинга, и с использованием систем заказчика. В портфеле SOC, помимо собственной запатентованной платформы ACR Platform, находятся решения, занимающие остальные основные доли сегодняшнего рынка средств класса SIEM, а также решения класса IRP/SOAR, Security Intelligence (BI для ИБ) и аналитический программный комплекс Dataplan, позволяющий работать с большими данными и, применяя алгоритмы машинного обучения и статистического анализа, строить по этим данным метрики, покрывая дополняющую SOC деятельность по ретроспективному анализу больших данных. l

Реклама

DialogNauka 11/23/20 9:21 PM Page 19

СПЕЦПРОЕКТ

Анатомия SOC Всеслав Соленик, директор центра экспертизы R-Vision

Е Сырые данные Первое, что мы должны направить в "черный ящик" SOC, – это сырые данные нескольких типов.

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

2. Информация об известных атаках и угрозах. Она нужна для того, чтобы выявлять эти атаки в общем потоке событий по паттернам. Уточним, что информация, приходящая из внешних источников, помогает находить только известные атаки и угрозы. Как правило, на сегодняшний день, если где-то кто-то столкнулся с некой угрозой, информация об индикаторах атаки, включая вирусные сигнатуры, становится доступной через различные CERT, обновления баз сигнатур или фиды. Сигнатуры и индикаторы компрометации в рамках Threat Intelligence (TI) – это второй поток данных, приходящих в SOC. 3. Информация об уязвимостях. Данные об уязвимостях поступают из нескольких источников и, несмотря на видимую структурированность, для SOC они тоже являются сырыми, поскольку: l они не учитывают контекст защищаемой организации; l в каждом источнике данные имеют свою нотацию, формат, полноту и пр.

20 •

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

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

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

Обработка данных Когда в SOC заведены все необходимые потоки данных, необходимо прове-

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

1. Правила агрегации и нормализации. Данные приходят в SOC разрозненными из многочисленных источников, и необходимо выработать и обязательно апробировать правила агрегации и актуализации, чтобы сделать системной последующую работу с ними. Данные, поступающие в хаотическом виде и порядке, невозможно сделать полезными, их нужно нормализовать. Поэтому необходимо создать правила агрегации и нормализации – фундамент для накопления знаний и практик в SOC. 2. Ресурсно-сервисная модель (РСМ). Она строится на основе информации о бизнесе, рисках, хостах, системах и сетях – по сути, на традиционных сведениях об инвентаризации, поступающих в SOC. Необходимо реализовать полноценную модель взаимосвязей между всеми активами организации, чтобы в случае, если с любым из активов произошел инцидент, четко понимать ландшафт этого инцидента. Важно построить процесс так, чтобы в SOC была актуальная информация о защищаемых активах. Построенная РСМ также является знанием SOC, и ее наличие позволяет в случае инцидента начать реагирование максимально оперативно, не тратя времени на сбор информации. К слову, реализация полноценной РСМ невозможна без использования платформы для ее сбора и актуализации, например SGRC или IRP. 3. Правила корреляции. Эта экспертиза должна быть выработана в SOC, и она заключается в документированных знаниях о том, какое сочетание различных событий и их атрибутов свидетельствует о потенциальном инциденте. Соответствующие правила корреляции создают-

www.itsec.ru

SOC

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

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

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

1. Сценарии реагирования. В SOC должна быть создана и накоплена экспертиза по конкретным шагам расследования инцидента каждого типа, она может поступить из внешних источников (например, консалтинга) либо формироваться своими силами. Эта экспертиза в виде пошаговой инструкции и есть сценарий реагирования. Он может быть написан на бумаге, может существовать только в голове у аналитиков SOC или может присутствовать в автоматизированном виде, но сами знания о том, как реагировать на конкретные инциденты, должны быть выработаны до того, как наступил инцидент. Как правило, для этого методологически прорабатываются сценарии атак, моделируются угрозы и нарушители, чтобы в дальнейшем уже смотреть, где, каким образом мы выявляем эти атаки по killchain, реагируем и пр.

2. Процесс обработки уязвимостей и угроз. Информация об уязвимостях пришла в SOC в виде сырых данных из NVD, сканеров уязвимостей или от пентестеров. SOC должен построить этот процесс как часть своей экспертизы. Аналогично он должен обработать, обогатить и распространить на средства защиты индикаторы компрометации из внешних фидов, чтобы выявлять их в защищаемой инфраструктуре и оперативно реагировать. Результат – понимание, что делать с данными об уязвимостях и угрозах и четкий процесс применения этих данных, снижающий риск инцидентов и повышающий эффективность работы SOC. Для автоматизации этих процессов используются системы класса Vulnerability Management (в том числе как часть SGRC/IRP) и Threat Intelligence Platform.

3. Отсеивание ложных срабатываний (False Positive). Это крайне важный тип знаний для аналитиков, ведь ложные срабатывания – бич любого SOC. Как бы качественно мы ни старались обрабатывать сырые данные, всегда будет присутствовать некоторый поток ложных срабатываний. Если не научиться их выявлять, группировать и отсеивать, то работа SOC будет быстро парализована: все будут заняты обработкой тысяч неактуальных инцидентов, а реальные инциденты останутся без внимания.

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

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

2. Плейбуки. Это те самые сценарии реагирования, которые реализованы в виде настроенных автоматизированных процессов и в которых используются скрипты и коннекторы. Если сценарий реагирования – это логическая сущность, то плейбук – это уже программная сущность, реализованная в системе класса SOAR (или IRP).

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

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

is@groteck.ru

• 21

СПЕЦПРОЕКТ

Особенности сбора, агрегации и ранжирования индикаторов компрометации Юрий Сергеев, RST Cloud

В Программа Threat Intelligence включает много организационных мероприятий. Часть программы стратегическая и закрывает, например, такие вопросы, как инвестиции в средства защиты в соответствии с актуальностью угроз. А другая часть программы – операционная, она включает в себя технические мероприятия, например работу с индикаторами компрометации (IOC) – объектами, наблюдаемыми в сети или операционной системе, которые с большой долей вероятности указывают на взлом устройства или ПО. В процессе насыщения ИБ-систем наиболее полными данными о существующих угрозах встает два вопроса. Первый – откуда получать эту информацию, второй – как проверить ее актуальность, то есть как информацию сделать знанием, имеющим под собой эмпирическую основу. Дело в том, что индикатор компрометации, который указывал на вредоносный домен неделю назад, сегодня уже может потерять свою актуальность. Например, из-за уязвимости в плагине CMS взломан легальный сайт, в результате чего злоумышленники залили на него фишинговую страницу для получения учетных данных пользователей для того или иного интернет-банкинга. Через неделю владелец сайта обнаруживает взлом и устраняет уязвимость. Таким образом, этот индикатор теряет свою ценность в настоящем. Эти и ряд других важных условий мы учитывали в первую очередь при разработке облачного сервиса RST Threat Feed1, решив задачи сбора, агрегации, верификации и ранжирования индикаторов.

Сбор индикаторов На данном этапе важно определить, какие источники должны стать частью вашей базы индикаторов. Нужно учитывать, что источники часто имеют пере1

https://www.rstcloud.net/profeed

22 •

се больше компаний сегодня структурируют свои подходы к использованию CTI (Cyber Threat Intelligence), чтобы снизить риски ИБ, уменьшить затраты на устранение последствий от инцидентов и освободить время персонала, занимающегося их расследованием. В современной компании можно найти множество решений и технологий, направленных на обнаружение и предотвращение вредоносной активности злоумышленников: SIEM, SOAR, EDR, IPS, NGFW, SWG, SEG, CASB и т.д. В этой статье поговорим о программе Threat Intelligence.

сечения, так как многие ресурсы копируют информацию друг у друга. Это не критично для самой фазы сбора, однако влияет на последующий скоринг собранной информации, поэтому важно исключать ресурсы, "вслепую" копирующие индикаторы без публикации дополнительной информации по ним, и стараться собирать сведения из независимых источников. В любом случае будут иметь место некоторые пересечения, так как зачастую одна и та же угроза может быть обнаружена специалистами независимо друг от друга в Китае, США, Иране и России. Следует отдельно отметить, что есть ряд уважаемых malwareисследователей, которые делятся информацией о найденных индикаторах в Twitter, Pastebin и на других платформах. Такие результаты чаще всего будут уникальными и представляют реальный интерес. Сбор подобных сведений позволяет получать индикаторы, которые еще "зеленые" в VirusTotal и неизвестны многим antimalware-компаниям. Каждый источник имеет свою историю ошибок первого (false positive) и второго (false negative) рода и специализацию. При формировании списка таких источников желательно определить, какой из них является более, а какой менее доверенным. Такой первоначальный скоринг может быть сформирован после сбора и анализа пересечений потенциальных ошибок первого рода с учетом устаревания индикаторов в течение продолжительного времени, когда накапливается достаточная статистика. Кроме того, важно учитывать специализацию источника. Есть источники, которые ведут список хостов, которые пытаются подобрать пароли на открытых ssh-портах, а есть такие, которые публикуют информацию по C2-серверам определенного семейства троянов. Другой тип источников ведет списки узлов, участвующих в проверках веб-эксплойтов "по площадям", используя роботов

для "проверки боем" на актуальные уязвимости. Такая "заточенность" на определенные виды угроз также помогает определить место источника с точки зрения важности предоставляемых им результатов и необходимости включения в "общий котел" для последующей обработки в скоринговой модели. Одной из дополнительных сложностей сбора является необходимость нормализации данных, так как каждый источник публикует их в своем "любимом формате": текстовые файлы, csv, json, XML, STIX, MISP event, openioc и др. Формат живых сообщений исследователей зачастую требует лингвистического анализа и преобразования человеческого текста в язык машины.

Ранжирование индикаторов В процессе ранжирования индикаторов может быть выбрано много подходов и формул для вычисления степени доверия к индикатору. Если охарактеризовать степень доверия неким числом, то оно будет меняться во времени из-за динамического характера использования компьютерных ресурсов атакующими. Например, в код вредоноса может быть спрятана функция, вычисляющая доменное имя в зависимости от времени. Скажем, на октябрь это будет список из одних 100 доменов, а на ноябрь это уже будет список других доменов. Нередко те или иные замеченные IP-адреса перестают использоваться и доменные имена перерегистрируются на другие, как только злоумышленник видит, что эффективность его "деятельности" снижается. При этом часто инфраструктура, находящаяся во временном владении злоумышленника, может быть "переиспользована": по истечении некоторого времени он может решить, что данный IPадрес давно не "работал" и пора его снова пустить в дело. Одним из способов отслеживания устаревания индикаторов является мони-

www.itsec.ru

SOC

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

Обогащение индикаторов Основная задача постанализа при работе с индикаторами – объяснить суть угрозы, продемонстрировать, что известно из окружения о данной сущности, с кем она связана и как это можно применить для снижения рисков. Базовые интерпретации, включающие сбор whois, asn, геоданных, принадлежности к хостинг-платформам или tor и другую подобную информацию об индикаторах, полезны в случаях атрибуции и при сравнении с другими взаимодействиями, которые считаются нормой в системе, для определения вероятности возникновения именно этого взаимодействия как легального. Есть ряд компаний, которые фокусируются на определенном регионе и не ожидают подключений из неожиданных локаций либо используют вероятностную модель при определении доверия к тем или иным подключениям или транзакциям, исходя из статистических данных. Для них эта информация о владельце или местоположении будет одной из определяющих. Но все же базовый сценарий предполагает, что главным фактором, формирующим доверие к индикатору, является принадлежность к определенной и насущной угрозе. Возьмем, к примеру, топ-10 шифровальщиков. Знают ли мои средства защиты индикаторы для блокировки такого рода проблем? Как это проверить? Я не хочу бороться с последствиями, хочу, чтобы, даже если удастся обойти мои endpoint-системы через уязвимости zero day, была возможность просто блокировать взаимодействия с вредоносными серверами на этапе загрузки вредоносного контента или управления им. В этих случаях важна связь между непосредственным значением индикатора и тем или иным вредоносным программным обеспечением или угрозой. Такого рода информацию получить уже на порядок сложнее, чем просто узнать, кто непо-

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

если индикатор не обогащен такой информацией, скорее всего в результате обработки инцидента вы придете к выводу об ошибке первого рода (false positive) из-за того, что произошло детектирование подключения к легальному сайту на этом же адресе.

Блокировка

Не секрет, что существует проблема реактивности защиты. Снижение времени реагирования на случившиеся события ИБ часто представляется важной задачей. Однако предотвращение таких событий всегда воспринимается как более позитивный результат. Такого рода задачи стоят и в том числе при использовании индикаторов компрометации в различных компаниях и организациях. Обычно можно выделить следующие основные сценарии применения индикаторов компрометации: l детектирование; l блокирование; l ретроспективный анализ; l расследование.

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

Детектирование

Ретроспективный анализ

Наиболее очевидный сценарий – детектирование. Я хочу иметь дополнительный уровень контроля моих превентивных мер и следить за качеством их работы, а также реагировать в случаях, когда та или иная проблема не была решена на более низком инфраструктурном уровне. Зачастую такого рода действия реализуются на базе SIEMсистем. Основными проблемами при применении подобного сценария являются поиск и определение false positive среди всего множества срабатываний. Сервисы, доступные из сети Интернет, подвергаются мелким атакам ежедневно. Роботы тестируют сотни разных эксплойтов каждый день в поисках того неудачного для защищающего случая, когда его сервис не получил обновление. Такого рода детектирование создает информационный шум, требующий фильтрации, либо обработки не в realtime, а на периодической основе, либо корреляции с другими событиями – запуском Shellcode, созданием дополнительного пользователя в ОС или в БД и т.п. Важно правильно сформировать правила детектирования, чтобы была возможность избегать такого рода последствий. Это, в свою очередь, накладывает определенные требования к составу и качеству обогащения индикаторов. Например, информация о том, что IP-адрес является вредоносным, важна сама по себе, но она, весьма вероятно, будет лишь информацией, а не знанием, если известно, что на данном адресе существует еще десяток тысяч других доменов. В этом случае,

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

Способы применения индикаторов

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

is@groteck.ru

• 23

СПЕЦПРОЕКТ

Фиды для SOC.

Осведомлен – значит вооружен Александр Пирожков, руководитель группы по развитию бизнеса в СНГ и Грузии компании ESET

С Достойно подготовленным к отражению киберугроз принято считать SOC, который укомплектован элементами управления информацией о безопасности и управления событиями безопасности (SIEM), системами анализа трафика на уровне внутренней сети (NTA), системой обнаружения угроз конечных точек и реагирования на них (EDR). Такой комплекс, как авиация, флот и сухопутные силы, позволяет обнаружить угрозу, в том числе на ранней стадии атаки, локализовать вредоносную активность и контролировать соблюдение регламентов ИБ. Но для стабильности и уверенности в завтрашнем дне также необходимо быть на шаг впереди злоумышленников в киберпространстве. Ведь без разведки и налаженного канала передачи критически важной информации любые вооруженные силы рискуют оказаться в затруднительном положении. Разведка в сфере ИБ – это подключение потоков данных об угрозах. Рано или поздно каждый современный SOC осваивает данный инструмент. Все зависит от зрелости центра мониторинга и от его финансовых возможностей. При этом SOC может столкнуться с проблемой возросших трудозатрат, если каналов поставки индикаторов компрометации стало много и на их обработку уходит драгоценное время аналитиков. В ESET мы решили сосредоточиться на наилучшем соотношении количества и качества собранных индикаторов угроз. Для потоков данных, или, другими словами, фидов, мы постоянно обновляем применяемые правила фильтрации.

24 •

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

Предварительно отсортированные данные являются самым удобным форматом получения информации об угрозах. Качество фидов обеспечено надежными и оперативными источниками сбора информации. В одной только Европе ESET сотрудничает с 46 национальными группами реагирования на чрезвычайные ситуации в киберпространстве, именуемыми CERT. Массив данных также формируется с помощью 110 млн собственных датчиков ESET, расположенных по всему миру, и системы трекера ботнетов LiveGrid. Комплектуя фиды, мы задумываемся не только о том, какой вред может нанести необнаруженное вредоносное ПО, но и о головной боли, вызванной ложным срабатыванием (FP). Ошибочные решения, когда чистые объекты маркируются как вредоносные, могут стать причиной более масштабных сбоев в ИТ-инфраструктуре, чем заражение вирусом. Приведу один из разрушительных сценариев: из-за FP решение безопасности заблокировало или удалило программное обеспечение производственной линии, что в свою очередь нарушило весь производственный цикл компании. Цена такой ошибки может исчисляться миллионами долларов. В непроизводственных организациях FP зачастую приводят к чрезмерной нагрузке на персонал по ИТ-безопасности, что впоследствии негативно сказывается на уровне готовности компании к инцидентам ИБ. Поэтому вместо поставки большого объема сырых данных мы делимся фидами с первоклассной категоризацией и

предварительно отфильтрованной информацией для использования клиентами в соответствии с их предпочтениями, сферой деятельности и регионом работы. О качестве телеметрии ESET свидетельствует наглядный тест компании Whalebone – провайдера сервиса фильтрации нежелательных ресурсов по их доменным именам (DNS). Whalebone ранее использовала индикаторы компрометации, полученные с помощью запуска в изолированной среде (песочнице), анализа сетевого трафика и на основе известных образцов вредоносного ПО. В рамках тестирования телеметрического сервиса компания дополнительно включила в данные обнаружения индикаторы компрометации от ESET. Общее число инцидентов в тесте DNS-фильтрации достигло 1,75 млн. Примерно половина инцидентов (866 тыс.) была обнаружена только на основе индикаторов компрометации, предоставленных ESET Threat Intelligence. Фактически без данных ESET 49,51% инцидентов остались бы незамеченными. При этом из 866 тыс. обнаруженных инцидентов ложной оказалась лишь одна блокировка домена. 50,02% инцидентов обнаружены Whalebone без помощи ESET. Всего 0,47% инцидентов потребовали для обнаружения одновременно данные и ESET, и Whalebone. Исследование Whalebone демонстрирует, что жесткая категоризация данных, имеющая первостепенное значение для ESET, способствует высокой точности обнаружения и близкому к нулю числу ложных срабатываний.

eset 11/23/20 9:17 PM Page 25

www.itsec.ru

SOC

Malicious file feed Этот канал содержит хеши вредоносных исполняемых файлов и связанные с ними данные. Основной вариант использования – идентифицировать, какие хеши в настоящее время видны в киберпространстве, и потенциально заблокировать их во внутренней среде до того, как они там появятся. Или определить вредоносные хеши в системе и провести дальнейшее расследование в соответствии с дополнительными данными, если они уже причинили вред.

Domain feed Канал использует вредоносный домен и связанные с ним данные. Определяется, какие вредоносные домены сейчас распространены. Блокируются домены с высокой степенью угрозы или выявляются домены с меньшей степенью угрозы.

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

Botnet feed Этот канал содержит все данные ESET о сети ботнета. Данные собираются с использованием нашей запатентованной технологии LiveGrid. Она позволяет проникать внутрь сети ботнетов и фиксировать данные о целях кибератак, используемом вредоносном ПО, доменах и многом другом. Помимо основной ленты ботнета, существуют специализированные каналы подачи копий (cc) и фид-целей (target), которые являются подмножеством основного канала и специализируются только на определенном аспекте общих данных. Первый позволяет блокировать недавно просмотренные URL, а второй содержит данные о конкретных целях ботнета. Для корректной интеграции каналов данных необходимо соединение с сервером TAXII. TAXII – это бесплатный и

открытый транспортный механизм, который стандартизирует автоматизированный обмен информацией о киберугрозах. В настоящее время ESET использует TAXII 1.1. Применяется модель совместного использования "источник/подписчик", где ESET является источником, а клиент – подписчиком. Поскольку сторонние приложения в значительной степени зависят от качества поставляемой информации, обычно клиентам предоставляется функционал, который помогает интегрировать формат STIX или JSON. Наши каналы создаются следующим образом: как только мы поделимся индикатором компрометации (IoC), мы не будем делиться им повторно в течение следующих 24 часов. Процесс дедупликации избавляет подписчика от поступления большого объема одинаковых данных. Но в случае, если определенный IoC по-прежнему преобладает и через 24 часа, то мы повторно поделимся им. В одной только Европе ESET сотрудничает с 46 национальными группами реагирования на чрезвычайные ситуации в киберпространстве, именуемыми CERT. Массив данных также формируется с помощью 110 млн собственных датчиков ESET, расположенных по всему миру, и системы трекера ботнетов LiveGrid.

Раньше у нас были общие каналы в форматах JSON и STIX 1.2. JSON удобен и понятен, легко читается и легко интегрируется в различные системы. Проблема с JSON в том, что он не стандартизирован и интегратору необходимо сопоставить каждое поле с соответствующим полем в своем стороннем решении. В свою очередь, STIX является отраслевым стандартом, который поддерживает большинство приложений SIEM/TIP и может читаться автоматически. Но версия 1.2 оказалась сложной в чтении и восприятии. Версия 2.0 дружелюбнее к пользователю. Именно поэтому мы решили предоставлять наши ленты именно в таком формате. К слову, и JSON, и STIX 2.0 используют одни и те же данные. За 15 лет работы на рынке ИБ мы научились правильно оценивать потребности заказчиков, а заказчики, в свою очередь, положительно оценили наши решения. В России и на постсоветском пространстве у компании уже есть крупные успешные внедрения. А новый заказчик всегда имеет возможность взять триал на 90 дней и полноценно ознакомиться с существующими решениями по противодействию инцидентам в ИБ. l Ваше мнение и вопросы присылайте по адресу

is@groteck.ru

Реклама

Какие фиды для SOC мы предоставляем?

• 25

СПЕЦПРОЕКТ

Однонаправленные шлюзы для подключения объектов технологической сети к SOC Вячеслав Половинко, руководитель направления собственных продуктов АМТ-ГРУП Виктория Стерлядева, инженер группы информационной поддержки АМТ-ГРУП Анастасия Лазарева, инженер группы информационной поддержки АМТ-ГРУП

К

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

Что такое SOC? Для обнаружения и обработки инцидентов многие организации выделяют в своей инфраструктуре центр мониторинга и управления информационной безопасностью, то есть SOC (Security Operations Center), или, другими словами, ситуационный центр информационной безопасности. Концепция SOC направлена на обеспечение непрерывного анализа возникающих рисков и угроз, выбора эффективных мер защиты, своевременной реакции на инциденты и успешного взаимодействия подразделений в рамках обеспечения безопасности. Следует отметить, что для мониторинга всей ИТ-инфраструктуры требуется отслеживать и обеспечивать корреляцию для достаточно большого объема событий. При этом неизбежно возникает и целый ряд технически сложных задач, среди которых можно выделить следующие: 1. Сбор событий из самых разных источников информации – средств защиты, АРМ, бизнес-систем, баз данных, серверов... И все это с учетом возможных ограничений по каналам связи, ресурсам хранения данных и т.п.

2. Поступление событий от источников на разных языках прикладного уровня и доставляемых до системы анализа по разным протоколам; каждый тип такого события должен быть корректно прочитан и обработан для последующего анализа и соответствующей реакции.

3. Необходимость проведения комплексной корреляции событий и выстраивание правильных и значимых с точки зрения ИБ взаимосвязей.

26 •

Технической основой SOC является система управления событиями информационной безопасности – SIEM (Security Information and Event Management).

SIEM предназначена для анализа поступающей информации от различных устройств, подключенных к ней, и дальнейшего выявления возникающих инцидентов, в том числе в отдельном (защищаемом) сегменте сети. Она работает с большим потоком разнородной информации от различных источников. Данная система служит инструментом для сбора, фильтрации, унификации, хранения и поиска, корреляции, создания оповещений об инцидентах, визуализации, разбора и расследования инцидентов информационной безопасности. Рассмотрим пример работы SIEM в части сбора событий от источников в защищаемом сегменте сети (см. рис. 1). На рисунке показано схематическое взаимодействие источников событий, расположенных в защищаемом сегменте сети, с приемником событий SIEM ситуационного центра. Источники могут быть как активными, то есть умеющими самостоятельно передавать данные в SIEM, и им достаточно указать сетевой адрес приемника событий, так и пассивными, то есть к которым SIEM сама должна обратиться. Примеры активных источников – устройства, передающие данные, например, по протоколам Syslog или Netflow. Пассивные источники – это устройства, которые только принимают сетевые подключения, например, по протоколам FTP, CIFS, HTTP, SCP для выгрузки своих файлов журналов. Поскольку защищенный сегмент, как правило, отделен от остальных корпоративных и внешних сетей, то он может представлять собой "слепую" или "полу-

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

www.itsec.ru

SOC

Рис. 1. Пример сбора событий от источников в защищаемом сегменте сети имущественно в рамках стека протоколов TCP/IP. Помимо стандартных угроз прямого получения злоумышленником доступа к критическому объекту и последующего нанесения ущерба, примерами известных реализуемых угроз, в основе которых лежит двунаправленный характер информационного обмена, являются WannaCry, Petya, EternalRocks и др. Отдельный значимый риск для защищаемой инфраструктуры – это возможность направления, загрузки чего-либо в критический сегмент, например вредоносного кода, шпионского ПО и т.п., для целей мониторинга, сбора информации, нанесения отложенного ущерба. Безусловно, атаки могут носить и однонаправленный характер. Так, используя протоколы без обратной связи UDP или ICMP, злоумышленник может попытаться не захватить контроль над объектом, но вывести его из эксплуатации, например, с помощью DoS-атаки. Однако в действительности такие атаки распространены существенно меньше. Для решения подобных проблем и подключения к SOC источников без повышения рисков воздействия на важный объект и защиты со стороны злоумышленника целесообразно применять технические решения на основе устройств однонаправленной передачи данных, например таких, как аппаратный комплекс InfoDiode (АК InfoDiode) или аппаратно-программный комплект InfoDiode (АПК InfoDiode).

Решения АК InfoDiode и АПК InfoDiode Наиболее распространенными сценариями применения АПК InfoDiode как шлюза между сегментом значимого объекта и сегментом SOC могут быть: l сценарий передачи информации от пассивных источников защищаемого объекта с последующим их чтением коллекторами SOC; l сценарий передачи информации от активных источников защищаемого объекта на коллекторы SOC; l сценарий анализа сетевого трафика от компонентов защищаемого объекта (например, на базе продуктов PT ISIM); l отправка оповещений по e-mail.

Рис. 2. Односторонняя передача информации во внешнюю систему мониторинга

Сценарий передачи информации от пассивных источников защищаемого объекта с последующим их чтением коллекторами SOC В этом сценарии данные передаются по протоколам FTP/CIFS c сервера In-Proxy через аппаратный комплекс InfoDiode на сервер Рис. 3. АК InfoDiode устанавливается на границе Out-Proxy. Файлы, которые критического сегмента, подключаясь к порту необходимо пере- зеркалирования коммутатора сегмента защищаемого дать из защищае- объекта и к PT ISIM, находящемуся во внешнем сегменте мого сегмента, помещаются на сервер In-Proxy, проходят Отправка оповещений по e-mail через АПК InfoDiode и отправляются Данный сценарий позволяет передачу в конечную папку Out-Proxy сервера, уведомлений через АПК InfoDiode от к которой сможет обращаться внешняя системы мониторинга, находящейся система мониторинга (например, SIEM) в закрытом сегменте, с помощью почтоили сотрудники SOC. вого трафика: 1. SMTP-клиент передает на SMTP-сервер InProxy сообщение электронной почты. Сценарий передачи информации от 2. InProxy пересылает сообщение на активных источников защищаемого OutProxy. объекта на коллекторы SOC 3. SMTP-клиент OutProxy пересылает В этом случае передача событий из сообщение на внешний SMTP-сервер. защищаемого сегмента происходит Каждый из представленных сценариев с использованием Syslog и Netflow на позволяет построить комплексную систевнешнюю систему мониторинга SOC. му защиты, базирующуюся на исключеПередача UDP-трафика через АПК Infoнии воздействия на защищаемый объект Diode позволяет обеспечить односторонсо стороны менее доверенного сегмента, нюю автоматическую передачу инфорв том числе такого, в котором находится мации во внешнюю систему мониторинга SOC и функционирующая в нем система или на файловый сервер (см. рис. 2).

SIEM. В каждом из сценариев однонаправленные шлюзы InfoDiode позволяют Сценарий анализа сетевого трафика от обеспечить безопасную интеграцию техустройств защищаемого сегмента нологической и корпоративной сетей, а Данный сценарий обеспечивает реатакже непрерывный мониторинг функлизацию защиты закрытого сегмента ционирования технологической сети из в случае организации сбора и последругих сегментов, в том числе возмождующего анализа копии технологиченость реагирования со стороны служб ского трафика внешней системой мониSOC на инциденты ИБ. l торинга (например, IDS) через однонаправленный шлюз. Одним из примеров реализации данного сценария является Ваше мнение и вопросы совместное решение АК InfoDiode и Posiприсылайте по адресу tive Technologies Industrial Security Incident is@groteck.ru Manager (PT ISIM)1 (см. рис. 3).

• 27

СПЕЦПРОЕКТ

В сети обнаружен шифровальщик. Как планировать реагирование? Алексей Юдин, директор центра мониторинга компании “Инфосекьюрити” (ГК Софтлайн)

В Какие ваши дальнейшие действия? Реакция пользователя или администратора чаще всего напоминает реакцию страуса: если я скажу, что "оно само" , меня никто не накажет. Пользователи пробуют разобраться сами: перезапускают рабочую станцию, пытаются самостоятельно удалить шифровальщика и т.д. Если вымогаемые суммы небольшие, то пользователи или администраторы пробуют заплатить выкуп в надежде, что им удастся восстановить данные. Такие действия, как правило, приводят к еще большим проблемам при последующих действиях по анализу и восстановлению после заражения. Рассмотрим основные этапы, которые необходимо пройти после выявления шифровальщика.

1. Обнаружение шифровальщика. Сотрудник организации или администратор сервера сообщает о проблеме в техническую поддержку.

2. Расследование. Необходимо определить вид шифровальщика, способ заражения и границы заражения, а также скорость и способ его распространения внутри сети.

3. Предотвращение последующего заражения других серверов и рабочих станций, изоляция и блокировка зараженных узлов.

4. Восстановление серверов и данных после заражения.

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

28 •

последние несколько лет существенно увеличилось количество и сложность вредоносных программ класса Ransomware (вымогатели). За примерами далеко ходить не надо, достаточно вспомнить CryptoWall, нашумевшие в 2017 г.

WannaCry, NotPetya или более современные Ryuk, REvil/Sodinokibi, Maze/ChaCha, Phobos, Dharma и др. Вымогатели получили широкое распространение одновременно с развитием цифровых валют, позволяющих злоумышленникам оставаться полностью анонимными и минимизировать риски быть пойманными при получении выкупа. Давайте представим себе ситуацию: возникла проблема с критичным сервером, вы заходите в консоль управления и видите: “Attention! All your files have been encrypted!”

Что должен делать пользователь при выявлении шифровальщика?

1. Не паниковать и делать все максимально быстро!

2. Не выключая компьютер, как можно быстрее отключить его от сетевой инфраструктуры.

3. Сфотографировать экран с использованием телефона, зафиксировать предупреждение вымогателей, информацию по зашифрованным файлам.

4. Зафиксировать все действия, которые могли привести к заражению, в том числе ответив на нижеследующие вопросы: l Какие странности в поведении компьютера или программ вы заметили? l Что вы делали перед тем, как обнаружили заражение (работали с файлами, внешними носителями, сетевыми папками, открывали письма в почте, работали в Интернете)? l Как часто, и каким образом проявляются признаки заражения? l К какой сети вы были подключены в момент заражения (домашняя сеть, публичный Wi-Fi, Интернет, VPN и т.д.)? l Какая операционная система используется на компьютере, как давно она обновлялась? l Сетевое имя вашего компьютера? l Из какой учетной записи вы работали в этот момент? l К каким данным у вас есть доступ? l Кому вы сообщили об инциденте и в какой форме?

3. Свяжитесь с технической поддержкой и уточните, кому передать данные по инциденту.

4. Помогайте команде технической поддержки оперативными и, главное, максимально честными ответами на

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

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

Расследование Вначале необходимо идентифицировать тип шифровальщика, для этого нужно собрать максимальное количество информации: l скриншоты экрана и графические интерфейсы вредоносного ПО; l список текстовых файлов и HTMLстраниц, которые открываются после шифрования данных, графические файлы, которые в ряде случаев устанавливаются шифровальщиком фоном на рабочий стол; l всплывающие сообщения при попытке открытия зашифрованных файлов; l адреса электронной почты или другие контактные данные в зашифрованных файлах и сообщениях; l используемые цифровые валюты и адреса оплаты; l язык, используемый в сообщениях шифровальщика; l схема переименования файлов (.crypt, .cry, .locked и т. д.);

www.itsec.ru

На правах рекламы

SOC

l типы зашифрованных файлов; l под какой учетной записью производилось шифрование файлов (системная, пользовательская, сервисная). Для помощи в анализе типа ВПО могут помочь специализированные сервисы, например id-ransomware.malwarehunterteam.com. После выявления типа вредоносного ПО необходимо собрать по нему все возможные технические признаки компрометации (имена процессов, устанавливаемые сетевые соединения, названия и хеши файлов, учетные записи, адреса почты, с которых производилась рассылка писем, и т.д.). Данную информацию можно получить либо из описания шифровальщика, либо при более глубоком анализе его образца. Можно отправить образец для анализа в VirusTotal (www.virustotal.com), в HybridAnalysis (www.hybrid-analysis.com) либо в антивирусную лабораторию, с которой сотрудничает ваша организация. В процессе анализа следует также определить векторы заражения и "нулевого пациента" для того, чтобы оперативно ограничить дальнейшее распространение шифровальщика. Основными векторами распространения могут быть: l эксплуатация уязвимостей по сети (аналогично сетевым червям и вирусам); l протоколы удаленного доступа (RDP и другие); l вложения в электронной почте; l заражение через файлы и документы (внешние устройства, сетевые папки); l распространение в качестве дополнительной нагрузки к другому вредоносному ПО, например через загрузчики. Распространение вымогателей-шифровальщиков в основном происходит автоматически, но бывают и ситуации полуручного шифрования данных и последующего вымогательства, когда злоумышленник осуществляет проникновение в сеть и запускает соответствующую программу для шифрования вручную. Дальше необходимо определить границы заражения, для этого можно использовать сетевые средства защиты, антивирусные средства или средства мониторинга серверов и рабочих станций, чтобы определить, на каких узлах были обнаружены признаки компрометации. На межсетевых экранах, в DNS и прокси-серверах можно посмотреть, кто обращался к командным центрам вредоносного ПО или осуществлял попытку массового заражения внутри сети. В этом случае очень полезными бывают системы класса SIEM, которые позволяют быстро проанализировать большой объем событий и сформировать правила мониторинга и выявления новых зараженных узлов. На рабочих станциях и серверах нужно использовать антивирусные средства. Большая часть современных решений

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

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

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

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

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

1. Проводить регулярное резервное копирование пользовательских данных и данных критичных бизнес-систем с хранением на внешнем носителе или максимально изолированном от инфраструктуры сервере или СХД.

2. Сформировать перечень ответственных за эксплуатацию инфраструктуры и средств защиты.

3. Разработать и протестировать инструкции по оперативному выявлению, идентификации и предотвращению распространения вредоносного ПО.

4. Сформировать инструкции и провести обучение специалистов технической поддержки для оперативного сбора информации по заражению.

5. Провести обучение пользователей (инструкция/видеоролики/курсы повышения грамотности в области информационной безопасности).

6. Регулярно устанавливать критичные обновления безопасности на рабочие станции и серверы.

7. Использовать антивирусное ПО, которое может предотвратить заражение от типового вредоноса.

8. Организовать взаимодействие с антивирусными лабораториями и компаниями, занимающимися расследованием инцидентов.

9. Провести учения, имитировав заражение шифровальщиком на одном из узлов в сети организации. l Ваше мнение и вопросы присылайте по адресу

is@groteck.ru

• 29

СПЕЦПРОЕКТ

Как будут развиваться SIEM-системы в ближайшие три года Алексей Андреев, управляющий директор департамента исследований и разработки Positive Technologies

Роман Ванерке, технический директор АО “ДиалогНаука”

С

прос на SIEM-системы 1 в мире остается достаточно высоким. По данным The Insight Partners, этот зрелый и высококонкурентный рынок, несомненно, продолжит свое развитие и вырастет с $2,597 млрд в 2018 г. до $6,24 млрд в 2027 г. В этой статье мы попробуем спрогнозировать, какими будут SIEM через три года, а также определим популярные технологические тренды, которые помогут таким системам лучше выявлять киберинциденты и предотвращать их последствия.

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

описания правил детектирования, плейбуки. Например, в 2018 г. в решении MaxPatrol SIEM2 появилась возможность загружать пакеты экспертизы – набор тематических правил обнаружения угроз, а с 2019 г. пользователи ежемесячно получают новые пакеты экспертизы. Каждый пакет в интерфейсе сопровождается подробным описанием с рекомендациями по настройке правил и реагированию на инциденты (см. рис. 1). По оценке экспертов Positive Technologies, в целом на мировом рынке каждый второй производитель развивает собственную экспертизу для дальнейшей ее передачи пользователям SIEM.

Автоматизация реагирования на инциденты Согласно опросу3, проведенному Positive Technologies, 25% специалистов по ИБ проводят в SIEM-системе от двух до четырех часов ежедневно. К наиболее трудоемким задачам участники опроса отнесли работу с ложными срабатываниями (донастройку правил корреляции) и разбор инцидентов, их отметили 58% и 52% респондентов соответственно. У 30% специалистов по информационной безопасности много времени отнимают настройка источников данных и отслеживание их работоспособности. Эти проблемы дают стимул для развития SIEM-систем в область продуктов другого класса – оркестрацию событий безопасности и автоматическое реагирование, или SOAR (Security Orchestration, Automation and Automated Response).

Развитие поведенческого анализа пользователей и сущностей

Рис. 1. Описание пакета экспертизы в базе знаний MaxPatrol SIEM 1 2 3 4

Стремление получить на одном экране единую картину происходящего в инфраструктуре будет способствовать добавлению к возможностям SIEM инструментов UEBA4 – поведенческого анализа пользователей и сущностей (процессов, узлов сети, сетевых активностей). Главное отличие SIEM от UEBA в том, что SIEM-система выступает в качестве своего

Security Information and Event Management (SIEM) – управление событиями информационной безопасности. https://www.ptsecurity.com/ru-ru/products/mpsiem/ https://www.ptsecurity.com/ru-ru/research/analytics/siem-report-2019/ User and Entity Behavioral Analytics (UEBA) – поведенческий анализ пользователей и сущностей.

30 •

www.itsec.ru

SOC

рода конструктора для сбора логов, а решение UEBA строит поведенческие модели. Алгоритмы поиска и обработки аномалий могут включать различные методы, а именно статистический анализ, машинное обучение, глубокое обучение (Deep Learning), которые подсказывают оператору, какие пользователи и сущности в сети стали вести себя нетипично и почему это поведение для них нетипично.

Cloud Platform, Microsoft Azure) в список поддерживаемых SIEMисточников (за счет подключения коннекторов к облакам), а с другой стороны – научиться и самим предоставлять SIEM по модели As a Service посредством добавления специфичных для облачной инфраструктуры способов развертывания, конфигурирования и дирижирования SIEM (виртуальных, облачных аплайнсов6) (см. рис. 2).

Облака

Куда ведут эти тренды

Согласно исследованию5, проведенному Enterprise Strategy Group по заказу Dell Technologies и Intel, в 2019 г. примерно две трети предприятий планировали увеличить по сравнению с предшествующим годом расходы на публичные облачные платформы. Такой подход, с одной стороны, заставляет вендоров добавлять самые популярные облачные сервисы (AWS, Google

Исходя из вышеизложенного, можно с уверенностью сказать, что все эти тренды уже заметны на рынке, а примерно через три года станут must-have для любой SIEM. Их развитие приведет к тому, что улучшится качество мониторинга и реагирования на инциденты и сократится объем ручной работы операторов, так как большая часть операций будет автоматизирована. l

Рис. 2. Процент покрытия. Данные являются экспертной оценкой Positive Technologies. Тренды актуальны для лидеров рынка SIEM (в определении числа лидеров специалисты руководствовались данными IDC7).

NM

Реклама

АДРЕСА И ТЕЛЕФОНЫ АО "ДиалогНаука" см. стр. 60

АО "ДиалогНаука" выполнило НИР по созданию вертикально интегрированной системы взаимодействия Федерального фонда обязательного медицинского страхования с ГосСОПКА Компания "ДиалогНаука", системный интегратор в области информационной безопасности, завершила научно-исследовательскую работу в сфере обязательного медицинского страхования для нужд Федерального фонда обязательного медицинского страхования (ФОМС) по разработке предложений по созданию вертикально интегрированной системы взаимодействия ФОМС и ТФОМС с ГосСОПКА. ФОМС реализует государственную политику в области обязательного медицинского страхования граждан как составной части государственного социального страхования и является самостоятельным государственным некоммерческим финансово-кредитным учреждением. Вопрос противодействия компьютерным атакам и реагирования на них для ФОМС является одним из значимых, поэтому было принято решение о реализации научно-исследовательской работы в сфере обязательного медицинского страхования "Проведение исследований и разработка научно обоснованных предложений по созданию вертикально интегрированной системы взаимодействия ФОМС и ТФОМС с ГосСОПКА".

Для достижения целей проекта специалистами АО "ДиалогНаука" были выполнены следующие работы: l исследование предпосылок создания системы; l проведение обследования ФОМС и ТФОМС с целью сбора информации о текущем уровне готовности фондов к созданию и дальнейшей эксплуатации системы; l разработка научно обоснованных предложений по порядку и формам взаимодействия ФОМС и ТФОМС при создании и функционировании системы, а также при взаимодействии с ГосСОПКА; l разработка научно и экономически обоснованных концептуальных предложений по созданию системы; l проектирование системы; l разработка дорожной карты реализации мероприятий по созданию системы; l проведение экспертной апробации полученных научных результатов в ТФОМС. В рамках НИР был осуществлен анализ нормативных правовых актов, устанавливающих полномочия и функции ФОМС по созданию системы, и анализ опыта создания аналогичных отраслевых, ведомственных и корпоративных систем управ-

ления и обеспечения информационной безопасности, а также проведено обследование текущего уровня обеспечения информационной безопасности ФОМС и ТФОМС и уровня готовности к эксплуатации вертикально интегрированной системы. Были сформированы предложения по вариантам построения системы с описанием ее функциональной и организационной структуры и разработан порядок и формы участия ФОМС и ТФОМС в создании и функционировании системы, которые легли в основу предложений по порядку создания и дальнейшему обеспечению функционирования системы. По результатам работы над проектом специалистами АО "ДиалогНаука" был подготовлен научный отчет о выполнении НИР, в котором также содержится концепция создания системы, техническое задание и технический проект на создание системы. "Результаты НИР послужат основой для дальнейшего формирования условий, позволяющих обеспечить высокий уровень информационной безопасности ФОМС путем построения взаимодействия с ГосСОПКА", – отметил Леонид Лобейко, начальник Управления информационной безопасности ФОМС. l

https://www.tadviser.ru/index.php/Статья:Облачные_вычисления_(мировой_рынок) Виртуальное устройство – готовый образ виртуальной машины, предназначенный для работы в среде виртуализации (на облачной платформе).

7 https://www.ptsecurity.com/upload/corporate/ru-ru/products/mpsiem/IDC-SIEM-research-rus.pdf 5 6

• 31

СПЕЦПРОЕКТ

Кадровое обеспечение работы SOC: поиск и подбор персонала, формирование и развитие команд Ксения Темникова, к.э.н., доцент кафедры “Информационная безопасность” Московского политехнического университета, эксперт ООО “Профконсалт ИСМ”, консультант в области систем менеджмента информационной безопасности, систем менеджмента непрерывности бизнеса, Thomas International (РРА)

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

Основные проблемы кадрового обеспечения Отсутствие квалифицированного персонала является наиболее распространенной причиной неэффективной работы, ограничивая возможности SOC2. Вакансии в командах SOC размещены на многих сайтах и в специализированных группах в социальных сетях. Зачастую они получают достаточное количество просмотров, но остаются без откликов. Например, вакансия руководителя центра информационной безопасности (SOC), выбранная автором в качестве объекта наблюдения, в течение двух месяцев с момента публикации так и осталась открытой. Однако подобная проблема кадрового рынка в сфере SOC не единственная. Другая проблема заключается в том, что многие SOC не тратят время на исследование эффекта выгорания сотрудников и не создают среду для профилактики этого явления. Между 1 2 3

а прошедшем SOC Forum 2019, в исследованиях SANS SOC 2018 и SANS SOC 2019 поднималась проблема кадрового обеспечения. На сегодняшний день это одна из самых актуальных проблем в сфере информационной безопасности. В данной статье мы рассмотрим основные задачи, проблемы и трудности, с которыми можно столкнуться при формировании команды SOC, а также способы их решения.

тем в исследовании SANS SOC 2019 подчеркивается, что с растущей нехваткой специалистов в области кибербезопасности вопрос сохранения кадров, сейчас работающих в SOC, будет становиться все более важным. Следующая проблема связана с отсутствием кадрового резерва, а зачастую и со сложностями его формирования. При оценке команды SOC внимание фокусируется, как правило, на обеспеченности персоналом и уровне его квалификации. Используются следующие метрики: количество пройденных аналитиками SOC тренингов и процент эффективных Playbook. Но такой подход не позволяет ответить на следующие вопросы: 1. Является ли команда SOC сплоченной, подготовленной и мотивированной?

2. Способна ли команда SOC адаптироваться под меняющиеся требования регуляторов и стандартов (становиться более зрелой; охватывать больше систем; использовать новые методы выявления атак3)?

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

С чего начать решение проблем? Как подступиться к решению проблем кадрового обеспечения работы SOC?

Ключ к решению этой задачи – прямой и обоснованный ответ на два вопроса.

1. Зачем нужен SOC? 2. Какой подход будет применяться для кадрового обеспечения SOC: подход "закрытия" вакансий или ответственный подход к формированию и развитию сплоченной, подготовленной и мотивированной команды? В зависимости от ответов на эти вопросы должны определяться дальнейшие шаги.

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

https://media.kaspersky.com/ru/business-security/enterprise/brochure-soc-powered-by-kl.pdf The Definition of SOC-cess? SANS 2018 Security Operations Center Survey. P. 15. https://www.pwc.ru/ru/services/technology/cyber-security/soc.html

32 •

www.itsec.ru

SOC

витию команды SOC, формированию системы управления знаниями. В такой ситуации потребуется корректировка действий по кадровому обеспечению вновь созданного SOC. Для подбора команды важно соблюдать принцип "при выборе из близких по уровню кандидатов ключевой фактор – личные качества каждого"4. Для этого потребуется применение оценок по системе Thomas International, а именно: l профильный анализ личности (PPA); l оценка 360. Может также потребоваться формирование/корректировка профиля должности. Диагностический аудит займет не более одного месяца. Полученные результаты послужат основой для управленческих решений, обоснования текущих и будущих инвестиций, формирования дорожной карты и развития команды SOC, установления KPI. Важное значение имеют выявление и устранение проблем, которые снижают эффективность работы SOC (непродуктивная работа, ошибки). К числу таких проблем относятся5: l недостаточная автоматизация (аналитики вынуждены тратить время на рутинные операции, которые могут быть автоматизированы); l отсутствие интеграции (использование узкопрофильных инструментов, не интегрированных друг с другом; аналитики вынуждены переключаться между различными инструментами и панелями управления); l избыток оповещений (переизбыток информации приводит к тому, что некоторые уведомления остаются без внимания); l отсутствие общего представления о происходящем на предприятии (команда SOC не видит полную картину событий); l отсутствие контекстных данных (недостаточное понимание мотивации, тактик и методов, используемых атакующими, может помешать команде SOC правильно приоритизировать инциденты для расследования). Вполне вероятно, что потребуется анализ коренных причин несоответствий/ происшествий (АКП, англ. – Root Cases Analyses, RCA). После этого можно переходить к выстраиванию процессов.

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

вательных и взаимосвязанных мер, включая проведение диагностического аудита кадрового обеспечения SOC, выявление и устранение проблем, которые снижают эффективность работы команды SOC, определение целевого состояния и существующего разрыва, формирование/корректировку текстов вакансий, профиля должности и т.п. Для формирования и развития сплоченной, подготовленной и мотивированной команды SOC важное значение имеет работа с профильными факультетами университетов, в том числе подготовка кадров в магистратуре по специально разработанным программам. Критерием выбора университета для развития стратегического сотрудничества является проектная деятельность студентов начиная с самого первого курса. Только в этом случае студенты готовы к командной работе, что является обязательным условием работы в SOC. Привлечению новых высококвалифицированных специалистов и, что не менее важно, удержанию имеющихся членов команды SOC будет способствовать выстраивание процессов, внедрение и совершенствование системы финансовой и нефинансовой мотивации, применение методик Thomas International (оценка 360, PPA и др.), анализ коренных причин несоответствий, управление знаниями, управление талантами. Для того чтобы команда SOC глубоко и всесторонне понимала контекст деятельности, подходы к приоритизации угроз, целесообразно повышать осведомленность в отношении политики и целей системы менеджмента информационной безопасности в соответствии с международным стандартом ISO/IEC 27001:2013, а также в отношении политики и целей системы менеджмента непрерывности бизнеса в соответствии с международным стандартом ISO 22301:2019, проводить обучение команды SOC передовым методам борьбы с киберугрозами, включая специализированные курсы повышения квалификации, экспертные тренинги, и, что особенно важно, проводить учения по непрерывности бизнеса. Проблема сохранения членов команды, которые уже работают в SOC, может быть решена за счет: l проведения дополнительных мероприятий, направленных на выявление высокопрофессиональных специалистов, способных и готовых обучать молодое поколение, разрабатывать новые методики обучения;

https://antalrussia.ru/candidates/thomas-test/ Источник: Составлено по данным: Решение “Лаборатории Касперского" для центров анализа событий ИБ (SOC) [Электронный ресурс] URL: https://media.kaspersky.com/ru/business-security/enterprise/brochure-soc-poweredby-kl.pdf (дата обращения: 20.10.2020).

6 https://soc-forum.ib-bank.ru/files/files/SOC2019/31%20Zlobin.pdf 7 https://www.bsigroup.com/ru-RU/About-BSI/media-centre/BSI-CISNews/2020/october/bsi-cis-recertified-sberbank-soc-iso-iec-27001-smart-glasses/ 4 5

l ротации кадров, распространения практики "дополнительных" проектов6, а также проведения специальных тренингов для предотвращения выгорания, по командообразованию с фокусом на деятельность SOC; l развития навыков внешней и внутренней коммуникации с фокусом на деятельность SOC, помощи в совершенствовании устного и письменного английского языка по тематике информационной безопасности и непрерывности бизнеса с фокусом на деятельность SOC. Меры, направленные на решение первых двух проблем, будут способствовать решению проблемы формирования кадрового резерва. Так, например, привлечение выявленных в действующей команде SOC высокопрофессиональных специалистов, способных и готовых обучать молодое поколение, к обучению студентов и новых членов команды на основе специально разработанных новых методик обучения, очень быстро даст стабильно высокий результат (при условии работающей системы финансовой и нефинансовой мотивации). Решению задач формирования кадрового резерва SOC будет способствовать развитие взаимодействия с университетами, а именно: проектная деятельность, стажировки, чтение открытых лекций для студентов, разработка и запуск совместно с университетом специальных магистерских программ, программ дополнительного профессионального образования (ДПО), сфокусированных на работу SOC.

Подтверждение успешной работы команды SOC В заключение следует отметить, что есть немало примеров успешного развития команд SOC. Приведем пример, когда успешная работа SOC получила подтверждение на международном уровне. BSI, компания по улучшению бизнеса, провела ресертификационный аудит системы менеджмента информационной безопасности операционного центра реагирования на кибератаки Сбербанка на соответствие требованиям международного стандарта ISO/IEC 27001:2013 с помощью технологии смарт-очков7. В этом примере интересен не столько опыт применения иммерсивных технологий, сколько опыт работы команды SOC. Важно, чтобы примеров успешной работы SOC становилось больше. Создание сплоченной, подготовленной и мотивированной команды SOC – это стратегическая задача управления талантами в условиях цифровизации. l Ваше мнение и вопросы присылайте по адресу

is@groteck.ru

• 33

СПЕЦПРОЕКТ

Платформа SICP для отслеживания подозрительных транзакций и обеспечения безопасности блокчейнов Александр Подобных, независимый эксперт по ИБ в SICP.ueba.su

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

июля 2020 г. Государственная Дума приняла в третьем чтении закон “О цифровых финансовых активах”, новые правила вступят в силу с 1 января 2021 г. К концу 2020 г. ожидается рассмотрение закона “О цифровой валюте”, в 2019 г. были приняты закон “О цифровых правах” и закон “О привлечении инвестиций с использованием инвестиционных платформ”. Таким образом, с начала 2021 г. в России будет осуществляться идентификация владельцев цифровых активов, внедряться скоринг транзакций и реализовываться мониторинг криптовалютных транзакций.

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

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

Основой платформы можно считать возможность оценки криптовалютных кошельков и транзакций

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

с помощью динамического скоринга.

SICP Платформа SICP1 уже более двух лет разрабатывается и совершенствуется группой экспертов из различных отраслей – экономической безопасности,

информационной безопасности, форензики, финтеха, рисков и аудита. В настоящее время эта работа происходит на базе отдела специальных разработок Технопарка Санкт-Петербурга, созданного для взаимодействия по модели государственно-частного партнерства. Изначально платформа SICP создавалась как реализация технологии UEBA (User and Entity Behavior Analitics) и основывалась на выявлении киберугроз криптокошелькам с учетом поведения пользователей, устройств, приложений и объектов в информационной системе. Однако очень быстро проект перерос в разработку собственных методов и методик анализа транзакций и оценки криптовалютных кошельков. Основой платформы можно считать возможность оценки криптовалютных кошельков и транзакций с помощью динамического скоринга. Всего в системе определены пять уровней риска, от низкого до критического, они соотнесены с CIS Controls 7.1. и визуализируются в SICP подсветкой от зеленого до красного цветов. Политика безопасности платформы SICP учитывает положительный опыт CIS в сфере управления активами, передовых методов защиты от кибератак и повышения эффективности программы кибербезопасности.

Сервисы в составе SICP На платформе SICP доступны четыре сервиса: СмартЭхо, КриптоСонар, МетаСфера и КриптоЦЕРТ.

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

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

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

4. О сервисе КриптоЦЕРТ (CryptoCERT) расскажем более подробно.

1 Security Intelligence Cryptocurrencies Platform (SICP), или в русскоязычном варианте когнитивная система аналитики Транзакция Криптовалюта Актив (КосаТКА), sicp.ueba.su.

34 •

www.itsec.ru

SOC

КриптоЦЕРТ В конце июля 2020 г. командой SICP был анонсирован запуск КриптоЦЕРТ, первого российского коммерческого центра мониторинга криптовалютных транзакций, решающего задачи выявления рисков криптокошельков и реагирования на инциденты в сфере оборота криптовалют. Это первый подобный сервис, работающий в России и странах СНГ. Любой гражданин или организация могут направить в КриптоЦЕРТ сведения о мошенничестве, связанном с криптовалютами, а также о другой угрозе или риске. На общедоступной интерактивной карте отображаются отпрофилированные криптокошельки в разрезе по странам. Платформа КриптоЦЕРТ не только позволяет вести мониторинг финансовых операций в блокчейн-системах и проводить исследование сущностей, но и предоставляет обширный функционал мониторинга нод блокчейнов, автоматизированного аудита субъектов, анализа защищенности веб-сервисов и аудита смарт-контрактов. Непрерывно ведутся работы по совершенствованию авторских алгоритмов динамического скоринга (настраиваемая поверхность скоринга), выявлению мошенников, усиливается интеграция с модулями машинного обучения, а также искусственного интеллекта, ведутся тестирования и исследования в данной области. Более того, платформа SICP поддерживает различные модели скоринга с возможностью их быстрой загрузки для использования в различных юрисдикциях с учетом требований локальных регуляторов. КриптоЦЕРТ осуществляет неформальное взаимодействие с ФинЦЕРТ Центробанка России. Это сотрудничество планируется продолжить, несмотря на структурные изменения в Центробанке, и даже расширить за счет документального, а затем и законодательного закрепления процедур взаимодействия. В настоящее время ведутся переговоры с регуляторами по обучению и применению платформы КриптоЦЕРТ в рамках работы в сфере оборота виртуальных активов и цифровых финансовых активов, проводятся консультации по вопросам налогообложения.

Взаимодействие с федеральными органами исполнительной власти осуществляется посредством заключения соглашений о взаимодействии и соглашений о неразглашении. По запросу федеральных органов исполнительной власти и ассоциации судебных экспертов командой SICP прорабатывается вопрос хранения во внутреннем блокчейне доказательств с контрольными суммами для возможности верификации юридически значимых доказательств из любой точки мира. На настоящий момент налажено неформальное взаимодействие КриптоЦЕРТ с другими аналогичными платформами и антифрод-системами в Европе, Южной Корее, США. Мы отмечаем заинтересованность в КриптоЦЕРТ со стороны банков, страховых компаний, инвестиционных фондов, криптовалютных бирж, платежных шлюзов, силовых ведомств, нотариусов и оценщиков.

Правовой фон работы SICP Не секрет, что основная системная проблема, связанная с использованием криптовалют, заключается в возможности их применения для проведения незаконных операций, в частности для легализации криминальных доходов, а также для финансирования запрещенных видов деятельности. Наиболее значимым в России законом в части противодействия отмыванию преступных доходов является 115-ФЗ "О противодействии легализации доходов, полученных преступным путем, и финансированию терроризма". В 2018 г. Советом ЕС была принята директива, регулирующая европейские правила по предотвращению отмывания денег и финансирования терроризма. Эти правила являются пятым по счету и последним обновлением Европейской "антиотмывочной" директивы, за что и получили условное название The Fifth Anti-Money Laundering Directive, или 5AMLD. В свете этой директивы уже с начала 2020 г. у субъектов должны быть внедрены процедуры KYC (Know Your Customer) и AML/CFT (AntiMoney Laundering, Counter-Terrorist Financing), и многие компании в Европе уже используют эти инструменты с 2019 г. Практически все ведущие криптобиржи и процессинговые

сервисы внедрили стандарты ISO/IEC 27001, равно как и GDPR, KYC-политики или сторонние решения, AML/CFT-сервисы и процедуры. Тяготеющие к американским финансовым рынкам компании также прошли аудит SOC2 (Service and Organization Controls 2). Основная системная про-

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

SICP обеспечивает операционную, транзакционную безопасность и реализацию следующих процедур: l идентификация/верификация (KYC); l дью-дилидженс пользователей и компаний (DD); l ответственное должностное лицо (CCO); l мониторинг транзакций (KYT); l оценка рисков AML/CFT; l учет страновых рисков. И несомненно, стоит отметить тот факт, что сегодня к квалификационным требованиям к ИБспециалистам финансовой сферы добавляется обязательное наличие навыков анализа больших данных и оптимизации алгоритмов машинного обучения. l

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

Практически все ведущие криптобиржи и процессинговые сервисы внедрили стандарты ISO/IEC 27001, равно как и GDPR, KYCполитики или сторонние решения, AML/CFT-сервисы и процедуры.

Сегодня к квалификационным требованиям к ИБ-специалистам финансовой сферы добавляется обязательное наличие навыков анализа больших данных и оптимизации алгоритмов машинного обучения.

Ваше мнение и вопросы присылайте по адресу

is@groteck.ru

• 35

СПЕЦПРОЕКТ

Про SOC

Круглый стол заказчиков, вендоров и интеграторов Сергей Рысин, эксперт по ИБ Участники: Роман Ванерке, технический директор АО “ДиалогНаука” Тимур Зиннятуллин, директор Центра киберустойчивости ACRC группы компаний Angara

Илья Кондратьев, заместитель директора департамента ИБ АМТ-ГРУП Виктор Куратов, руководитель отдела поддержки продаж компании ESET Иван Лопатин, технический эксперт АО “ДиалогНаука” Максим Павлунин, руководитель центра мониторинга Angara Professional Assistance

Руслан Рахметов, генеральный директор Security Vision Всеслав Соленик, директор Центра экспертизы R-Vision Ксения Темникова, к.э.н., доцент кафедры “Информационная безопасность” Московского политехнического университета, эксперт ООО “Профконсалт ИСМ”, консультант в области систем менеджмента информационной безопасности; систем менеджмента непрерывности бизнеса, Thomas International (РРА) Никита Цыганков, руководитель направления внедрения средств защиты информации АО “ДиалогНаука” Алексей Юдин, Директор центра мониторинга ISOC, Infosecurity a Softline company

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

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

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

Комментарии экспертов Алексей Юдин, Infosecurity a Softline company: Первые заказчики формируют основы сервиса, но не всегда имеют приоритет в реализации своих идей. Видение сервиса фиксируется в договоре между участниками, все дальнейшие доработки идут с учетом дорожной карты сервиса и взаимоотношений с заказчиком. Причем неважно, первый это заказчик или десятый, сервис может изменяться со временем в зависимости от потребностей любого заказчика. Мы, например, ко всем заказчикам относимся одинаково. Никита Цыганков, АО "ДиалогНаука": Безусловно, первые заказчики обладают определенными привилегиями, ведь

36 •

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

www.itsec.ru

SOC

всем, – это все равно что купить обувь, отталкиваясь от обещаний маркетологов, и рассчитывать, что она будет "как раз". В реальности при подключении нового клиента к сервису еще до заключения контракта целесообразно проводить сбор информации о его инфраструктуре и процессах и формировать предлагаемый пакет услуг с учетом этих ограничений. Ведь каждая инфраструктура уникальна, и даже зрелый коммерческий SOС с большим количеством клиентов не может быть заранее готов ко всем на свете особенностям. Всеслав Соленик, R-Vision: Я бы сказал так: первые заказчики формируют стандартные подходы к решению задач. У сильного вендора в команде есть хороший менеджер продукта, который определяет логику развития решения с учетом обратной связи от заказчиков, но все же исходя из лучших практик, опыта экспертов и универсальных механизмов. Он понимает, что любая функциональность или сервис в целом должны быть полезны не одному заказчику, а всем. Поэтому важно оценивать не только функциональность универсального решения, но и наличие высококвалифицированной команды, способной его настроить и внедрить. Виктор Куратов, ESET: Зачастую маркетологи стараются донести до заказчика ту информацию о решении, которую он хочет услышать, даже когда предлагаемое решение не обладает указанным функционалом. Поэтому процесс выбора решения должен быть правильно проработан как со стороны заказчика,

Важен личный контакт с командой SOC Если мы используем собственный SOC, наша задача – сформировать команду. А если используется коммерческий SOC, то мы обязаны быть на одной волне с тем коллективом, время которого мы приобретаем. В SOC критически важно взаимодействие команд сервиса и заказчика. Только в этом случае получится симбиоз, который позволит

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

Ксения Темникова, Московский политех: В фокусе внимания – команда, которая профессионально знает специфику ИБ-сервиса, конкретный функционал, способы донастройки используемого решения (не только техническую часть, но и коммуникации с заказчиком). Командам важно иметь системные знания об ожиданиях потребителя, мониторинге и измерении удовлетворенности потребителя. Для этого можно применять итерационный подход к доработке продукта, опираться на рекомендации ISO 10004:2018.

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

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

Комментарии экспертов Илья Кондратьев, АМТ-ГРУП: Важно сбалансированно сочетать технические компетенции и коммуникативные навыки членов команды SOC. Что касается сервиса модификации под клиента, то это действительно очень важно, особенно в части адаптации средств автоматизации работы аналитиков SOС, что, в свою очередь, повышает скорость и качество их работы, и, как следствие, растет удовлетворенность заказчика. Никита Цыганков, АО "ДиалогНаука": Конечный результат любого проекта всегда зависит не только от качества предоставляемой услуги и скорости реализации, но и от способности слышать заказчика. Только при работе сообща возможно достижение всех целей и задач построения SOC. Однако на потребности по той или иной доработке необходимо смотреть через призму необходимости такой доработки и ее пользы прежде всего для самого заказчика. Алексей Юдин, Infosecurity a Softline company: Конечно, важно слышать друг друга и говорить на одном языке, чтобы быстро решать конкретные задачи, важно получать обратную связь и настроиться с командой на одну волну. Виктор Куратов, ESET: Поддержу, что Soft Skills важны, но нужно не впадать в крайности и уметь соблюдать баланс.

В сегменте SOC нужен индивидуальный подход к нуждам заказчика и профессиональная команда, которая сможет предоставить лучшее решение. Руслан Рахметов, Security Vision: Безусловно, гибкость при решении задач и готовность подстроиться под ожидания и потребности клиентов являются очевидными преимуществами. Но стоит задуматься о целесообразности подобного подхода: инвестиции должны рано или поздно окупаться. Что действительно критически важно – это умение наладить конструктивные и доверительные отношения со всеми сотрудниками, принимающими участие в работе SOC, как со стороны исполнителя, так и со стороны клиента. Ксения Темникова, Московский политех: Для коммерческих SOC вопрос о взаимодействии команд сервиса и заказчика является критически важным. Целесообразно проводить обучение и учения по согласованным программам с учетом требований серии стандартов ISO 270XX, стандарта ISO 22301. Это позволит командам быть на одной волне, в том числе в понимании актуальных технических и социально-психологических аспектов информационной безопасности, модифицировать и усовершенствовать функциональность SOC под клиента.

• 37

СПЕЦПРОЕКТ Зачем вам SOC Когда я говорю, что у нас есть SOC, часто в ответ слышу: а зачем он тебе нужен? Мол, это просто выброшенные деньги. Но ведь у вас в компании установлена круглосуточная система охраны? На машине стоит сигнализация? А почему информация, с которой вы работаете, не нуждается в таком же мониторинге? Часто топ-менеджеры не думают об информационной безопасности до тех пор, пока не потеряют деньги. Деньги можно потерять, просто заплатив мошенникам выкуп за пароль в случае шиф-

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

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

Комментарии экспертов Руслан Рахметов, Security Vision: На мой взгляд, создавать собственный SOC целесообразно в случае, если поток боевых инцидентов диктует необходимость их обработки в непрерывном режиме силами выделенного подразделения. И при условии, что в компании уже создана зрелая система управления кибербезопасностью и отлажены ИБ-процессы, которые станут надежной основой эффективно работающего SOC. А аутсорсинг услуг SOC может пользоваться спросом в SMB-сегменте или при осознанной потребности в разделении части киберрисков в соответствии с договорными обязательствами. Алексей Юдин, Infosecurity a Softline company: Проводя параллель с физической безопасностью, отмечу, что каждый заказчик сам выбирает, строить ли собственную систему физической безопасности, нанимать и обучать людей или отдать сервис в ЧОП. Ровно так же обстоят дела и с сервисом SOC. Виктор Куратов, ESET: SOC – достаточно молодое направление в ИБ по сравнению с другими решениями. Еще несколько лет назад, приходя на SOC-форум, я видел работу команд маркетологов без каких-либо реальных Use Case и Best Practice. Сегодня уже видно развитие данного направления и то, что все больше и больше компаний смотрит в эту сторону. Илья Кондратьев, АМТ-ГРУП: Отмечу опасность заблуждения о выводе ответственности за пределы компании

SOC как вершина пирамиды SOC – это надстройка над всей информационной безопасностью, которая, как спрут, собирает данные со всей инфраструктуры, анализирует и выдает в конеч-

38 •

в случае подключения к коммерческому SOC. Например, ответственность за инциденты ИБ сохраняется как за субъектом КИИ, так и за оператором ПДн. Просто переложить ответственность на подрядчика, оказывающего услугу SOС, не получится.

Ксения Темникова, Московский политех: Остановка части бизнес-процессов, потеря доступа к информационной системе может привести к потере бизнеса. Чтобы информационная безопасность не была "лоскутной", деятельность SOC может развиваться на основе системы менеджмента информационной безопасности (ISO/IEC 27001:2013) и системы менеджмента непрерывности бизнеса (ISO 22301:2019). Процессы мониторинга и реагирования на киберугрозы входят в топ-3 глобальных рисков для бизнеса, важно соответствовать требованиям международных стандартов. При аудите SOC могут применяться иммерсивные технологии. Всеслав Соленик, R-Vision: На мой взгляд, SOC в широком смысле нужен в качестве инструмента достижения основной цели информационной безопасности – снижения рисков и ущерба от инцидентов. Есть целый ряд процессов и систем по предотвращению инцидентов, но они все равно рано или поздно происходят и приводят к последствиям самого разного масштаба. Как раз для выявления таких ситуаций и управления ими, включая снижение последствий, и нужен SOC.

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

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

www.itsec.ru

SOC

Комментарии экспертов Всеслав Соленик, R-Vision: Это популярное мнение, но важно, что именно мы называем SOC. По факту даже отдел из трех человек, вручную обрабатывающих инциденты – это уже Security Operations Center. Но если под SOC подразумевать выделенное ИБ-подразделение с процессами высокого уровня зрелости и автоматизацией, то, конечно, такое решение требует и затрат, и компетенций, а значит целесообразно только при больших масштабах инфраструктуры. При этом зрелость процессов является не показателем потребности в SOC, а скорее критерием его качества. Алексей Юдин, Infosecurity a Softline company: SOC нельзя считать вершиной ИБ, но он является важной частью процессов ИБ, сильно зависящей от смежных процессов. Замечу также, что даже для небольшой, но высококритичной инфраструктуры в 20 серверов обычного логирования может оказаться недостаточно. Тимур Зиннятуллин, группа компаний Angara: На практике SOC может начаться и с трех инженеров, защищающих небольшую инфраструктуру, но предоставляющих оценку актуальных угроз и рисков, информацию о злоумышленниках и их активностях, позволяющую самим защитникам и их организации снизить возможный ущерб благодаря более корректному принятию решений. А в теории – с пяти понятных, но непростых шагов: выбора "свой или outsource", набора услуг и задач, полномочий, ситуационной осведомленности, PDCA по всем направлениям деятельности. Никита Цыганков, АО "ДиалогНаука": Несомненно, задумываться о создании SOC следует, только достигнув определенного уровня зрелости компании в выстраивании процессов управления и реагирования на инциденты, повышении компетентности персонала и пр. Илья Кондратьев, АМТ-ГРУП: Соглашусь, что с ростом обслуживаемой инфраструктуры эффект от SOС становится все более ощутимым. При этом становится целесообразным

применение средств автоматизации процессов, за счет чего появляется возможность концентрации аналитиков на узкоспециальных задачах. Роман Ванерке, АО "ДиалогНаука": На мой взгляд, автор немного запутался. С одной стороны, корректен вывод о том, что если инфраструктура невелика, то корреляция не нужна, а скорее нужен грамотный ИБ-специалист, который сможет закрыть большую часть вопросов. С другой стороны, у автора прослеживается некорректная мысль, что SOC = SIEM (корреляция). SOC – это не только SIEM, но и множество других подсистем информационной безопасности, каждая из которых выполняет свою задачу в рамках реализованных в SOC процессов (киберразведка, аналитика, расследование и т.д.). Руслан Рахметов, Security Vision: Не будем забывать, что SOC – это люди, процессы и технологии. Безусловно, для решения ограниченного числа задач в малых масштабах подойдет и система лог-менеджмента, и SIEM. Но по достижении определенного уровня сложности процессов ИБ в SOC, в частности при обработке киберинцидентов, нужны будут уже IRP/SOAR-решения. Можно сказать, что показателем зрелости центра SOC будет осознанная потребность в таких продуктах, позволяющих существенно ускорить обработку инцидентов и упростить решение рутинных задач ИБ. У нас есть авторская точка зрения на развитие систем автоматизации информационной безопасности, где SIEM – это начальная точка зрелости и впереди большой путь развития, вплоть до автоматического контроля и роботизации ИБ и ИТ. Ксения Темникова, Московский политех: Команда SOC выдает готовые знания, этими знаниями необходимо управлять. То есть в системе финансовой и нефинансовой мотивации команды SOC важно предусмотреть участие каждого члена этой команды в формировании системы управления знаниями. Это критически важно как для удержания тех, кто сейчас работает в SOC, так и для формирования кадрового резерва.

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

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

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

• 39

СПЕЦПРОЕКТ Комментарии экспертов Алексей Юдин, Infosecurity a Softline company: Я считаю, что сравнивать подобные вещи некорректно, так как ситуационные центры не заменяют собой полноценный сервис SOC. Ситуационный центр решает больше задачи физической безопасности и только отчасти затрагивает вопросы ИТ и ИБ. Никита Цыганков, АО "ДиалогНаука": К сожалению, многие специалисты ИБ упускают физическую безопасность из вида. Как следствие, угрозы, стоящие на стыке физической и информационной безопасности, остаются невыявленными, что ведет к возможным инцидентам. Одни и те же события, которые по отдельности не будут являться инцидентами, после корреляции от различных типов источников уже будут ими являться. Классический пример инцидента: событие аутентификации с учетной записью сотрудника на АРМ (события домена) при отсутствии самого сотрудника в здании офиса (информация от СКУД). Ксения Темникова, Московский политех: Добавить в SOC элементы классического ситуационного центра 24 х 7 заставят конкуренция и требования зарубежных деловых партнеров.

Кадры для SOC Многое упирается в подготовку кадров. Специалистов много, а работать некому, поэтому для того, чтобы найти человека на вакантную позицию, приходится провести собеседование больше чем с сотней человек! Иной раз

Илья Кондратьев, АМТ-ГРУП: Современная SIEMсистема, являющаяся ядром SOС, уже сейчас позволяет подключать самые разнообразные источники данных. И в этом направлении важно сохранить баланс, дабы не перегрузить SOС информацией о событиях, с которыми специалисты по ИБ все равно не смогут ничего сделать: например, информация о температуре у сотрудника слабо коррелирует с его действиями как пользователя ИТ-системы. Скорее, необходимо обеспечить агрегацию информации из SOС и отправку ее в том виде, который позволит ситуационному центру более эффективно выполнять свои функции. Руслан Рахметов, Security Vision: Заведение в SOC разнородных событий от всего спектра источников в масштабной гетерогенной среде решается техническими средствами, которые получают и обрабатывают машиночитаемую информацию, будь то температура сотрудника или факт его прохода и присутствия на территории офиса. Современные SIEM/SGRCрешения интегрируются с системами СКУД, видеонаблюдения, специализированными системами телеметрии, выдавая информацию для аналитики в программное ядро SOC. IRP/SOARрешения полноценно и автоматически отрабатывают сценарии реагирования.

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

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

Комментарии экспертов Всеслав Соленик, R-Vision: Личностные качества развиваются сложнее, чем компетенции. Знания можно нарастить, но человек редко меняется с точки зрения Soft Skills и отношения к работе. Опыт показывает, что готовых специалистов практически не бывает, их нужно выращивать, но это в итоге оказывается даже выгоднее. Ведь всегда есть определенная специфика организации, инфраструктуры, подходов и процессов. Нужно не бояться обучать людей, дотягивать до нужного уровня, брать на вырост и давать им задачи чуть выше текущей квалификации, стимулируя таким образом их развитие. Максим Павлунин, Angara Professional Assistance: Действительно, ситуация с подготовкой кадров для подразделений SOC достаточно сложная. Вузы, как правило, не имеют в штате преподавателей с большим опытом работы в ИБ и, в частности, в подразделениях SOC, из-за чего не могут давать студентам актуальные знания по данному направлению. При этом технологии развиваются, появляются новые угрозы, усложняются системы защиты информации. Разрыв между фактическими знаниями выпускников и требованиями работодателей растет. Устранение данного разрыва невозможно без участия самих SOC. Для обеспечения потребностей в кадрах необходимо как сотрудничество с вузами для обмена практическим опытом, так и выстраивание внутренних программ обучения молодых специалистов. Илья Кондратьев, АМТ-ГРУП: Согласен, кадровый голод в ИБ наблюдается уже давно, но тем не менее проблему надо решать. У нас, к примеру, есть многолетний опыт

40 •

сотрудничества с вузами в части организации практики для студентов. И это дает свои плоды – многие практиканты приходят потом на работу: сначала на полставки, потом на полный день, и к моменту выпуска уже становятся способными выполнять "боевые" задачи, конечно, с обязательным наставничеством со стороны более опытных коллег. Кто-то из ребят трудится в проектных подразделениях, а кто-то в смене TAС и в SOC. Руслан Рахметов, Security Vision: На помощь приходят технологии: оркестровка и автоматизация рутинных операций позволяют специалистам высвобождать время для развития и решения стратегических вопросов ИБ. Однако фундаментальные знания и практические навыки специалистам по-прежнему необходимы. В помощь подготовке кадров мы разработали авторский курс и лабораторные работы по дисциплине "Автоматизация процессов управления информационной безопасностью". Наши эксперты читают его в крупнейших профильных вузах. Ксения Темникова, Московский политех: Подготовка кадров для SOC – это прежде всего целенаправленная работа с вузами, в которых развита проектная деятельность с первого курса. Наряду с этим большие возможности имеются в формировании программ дополнительного профессионального образования. Разработаны программы ДПО "Система менеджмента непрерывности бизнеса в соответствии с требованиями ISO 22301:2019 в условиях цифровизации", которая учитывает специфику SOC (объем 16 часов, 40 часов, 72 часа). Кроме того, создана специальная магистерская программа для обучения команд SOC в течение двух лет.

SOC

www.itsec.ru

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

Комментарии экспертов Алексей Юдин, Infosecurity a Softline company: Мы согласны с тезисом о регулярности тестировании работы SOC, особенно когда тестирование проводится сторонними компаниями. Но следует учитывать, что SOC не всегда контролирует всю инфраструктуру организации, что в итоге может сыграть против него самого. Реальный анализ результатов такого тестирования показывает пробелы не только в сервисах SOC, но и в инфраструктуре заказчика и используемых мерах защиты. Иван Лопатин, АО "ДиалогНаука": Как сказал один из наших заказчиков, "найм Red Team в штат – это лучшая покупка". "Пурпурные команды" повышают уровень любого SOC. Но следует учитывать, что необходимо использовать современные методы атак и эксплуатации уязвимостей, так как в Blue Team всегда несколько запаздывает развитие собственного контента и выявление угроз, и Red Team должны выступать важным катализатором развития SOC.

Илья Кондратьев, АМТ-ГРУП: Добавлю, что при регулярных мероприятиях подобного рода стоит приглашать различные команды пентестеров, чтобы реализовать большее

разнообразие используемых технических и тактических приемов. Ксения Темникова, Московский политех: Существуют методики проведения учений команды SOC и заинтересованных сторон с учетом требований ISO/IEC 27001:2013, 22301:2019, рекомендаций ISO 10004:2018 и лучших практик. Применение таких методик позволит отработать взаимодействие участников, команде SOC – профессионально расти, превращаясь в сплоченный, подготовленный и мотивированный коллектив, информационным системам – оставаться защищенными.

Руслан Рахметов, Security Vision: Без сомнения, киберучения, работа команд Red и Blue Team, анализ выученных уроков и последующее внесение изменений в процедуры реагирования на инциденты важны, как и любые тренировки. Не менее важно осознавать, что масштабные утечки и кибератаки происходят порой из-за простого несоблюдения базовых правил кибербезопасности. Поэтому не следует забывать о непрерывном совершенствовании системы управления ИБ, включая банальный патч-менеджмент, минимизацию полномочий, сегментирование сети и обучение сотрудников.

ТЕХНОЛОГИИ

Graph Representation Learning как способ повышения эффективности противодействия мошенничеству Андрей Пинчук, исполнительный директор, начальник Отдела аналитической экспертизы Сбербанка

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

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

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

характер – затрагивают вершину и ближайшее ее окружение (см. рис. 1). Также расчет эвристик более высоких порядков и длин путей в моделях real-time на объемах банка невозможен (~12 000 транзакций в секунду со временем SLA <100 мс). Поэтому необходим механизм, который позволял бы извлекать информацию из структуры графа автоматически и использовать ее для моделей фрод-мониторинга.

Почему графы?

Машинное обучение на графах

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

Зачастую для извлечения структурной информации из графов и передачи в традиционные ML-модели (регрессии, деревья решений и пр.) используется набор статистических данных, описывающих граф, kernel-функции для графов или разработанные аналитиками признаки. Ограничения такого подхода заключаются в том, что разработанные признаки не адаптируются под имеющиеся данные во время обучения, а создание новых признаков требует много времени. В настоящее время разработано множество алгоритмов, направленных на обучение представлений (Representation Learning) графов. Суть Representation Learning – закодировать структурную информацию о графе в пространство меньшей размерности (так называемый embedding), например представить вершины графа или целиком граф (подграфы) как точки в новом графе. При этом цель алгоритма/модели – чтобы в получившемся пространстве геометрические соотношения отражали структуру исходного графа, например близкие вершины в пространстве были также близки (связаны ребром, имели небольшой кратчайший путь) в графе. Ключевое отличие подходов Representation Learning от традиционных состоит в том, что последние самостоя-

. https://www.researchgate.net/publication/318916726_Weisfeiler-Lehman_Neural_Machine_for_Link_Prediction

1

42 •

www.itsec.ru

ТЕХНОЛОГИИ

тельно на основании данных о графе ищут оптимальное представление в пространстве меньшей размерности (embedding), а не полагаются на заранее заданные эвристики.

Graph Representation Learning можно разделить на два класса – unsupervised и supervised (semi-supervised). Цель первых методов – выучить представление low-dimensional с сохранением структуры начального графа, вторых – получить представление low-dimensional, но только для определенной последующей задачи классификации, например классификации вершин графов или самих графов. В supervised-методах помимо самого графа передается дополнительная информация, описывающая вершины (так называемая Node Features).

Формулировка задачи и особенности графа Сбербанка Для оценки эффекта от использования GRL-методов было принято решение взять несколько real-time-моделей, осуществляющих проверки переводов между клиентами банка или на сторонние реквизиты, дополнить их признаками по результатам работы GRL-моделей и оценить прирост эффективности. При этом использовались текущие промышленные модели, в которых приводились некоторые графовые метрики (наличие прямых связей, общие соседи). Это было сделано для того, чтобы оценить добавочный эффект, который могут дать GRL-методы в дополнение к базовым графовым эвристикам. Тут важно отметить, что далеко не все GRL-методы хорошо масштабируются на большие графы (свыше нескольких сотен тысяч вершин). В экспериментах мы использовали граф из 250 млн вершин и 2,2 млрд ребер. Большинство разработанных GRL-методов не в состоянии обработать такой граф. Для решения задачи нами был проанализирован и отобран ряд решений, которые по своей временной сложности и архитектуре разрабатывались именно для задачи работы на гигантских графах. По результатам анализа мы выбирали из решений Open Source GraphSAGE, SEAL, Pytorch BigGraph и решили остановиться на последнем решении, о причинах – ниже.

l многопоточных вычислений; l поддержки распределенного параллельного обучения на множестве машин на разных частях партиционированного графа; l реализации пакетной обработки для операции негативного сэмплирования ребер (существенно ускоряет процесс обучения). При этом все вычисления работают с использованием ресурсов исключительно CPU и не требуют специализированных GPU-серверов (для GraphSAGE и SEAL требуются GPU, поскольку в их основе лежат графовые сверточные сети), хотя возможность использовать GPU для обучения в последнем релизе также появилась. Решение относится к unsupervised классу GRL (тогда как SEAL и GraphSAGE относятся к supervised). Соответственно, для получения embedding представления графа не требуется никаких дополнительных данных, описывающих вершины, что позволяет быстрее провести эксперименты и оценить результаты.

PBG поддерживает работу с мультисущностными и мультиреляционными графами, то есть позволяет обрабатывать графы, в которых представлены вершины разных типов и разные типы связей, например граф связей физических и юридических лиц (разные типы сущностей), а связи – финансовые транзакции и факт владения юридическим лицом. Решение является законченным, стабильным, и оно было неоднократно опробовано на больших графах в сотни миллионов вершин как разработчиками, так и сообществом. Оно показало хорошие результаты по скорости работы и качеству результата. Имплементации GraphSAGE и SEAL присутствуют в виде библиотек или как часть более общих

фреймворков для работы с графами (например, Pytorch Geometric), но всетаки это незаконченные продукты, и для их использования придется дополнительно реализовать часть функционала по обработке графа. В результате мы решили для первых экспериментов с GRL остановиться на решении Pytorch BigGraph.

Данные для эксперимента и подход к оценке эффекта от GRL В Сбербанке уже давно реализован и активно используется для противодействия мошенничеству граф связей, содержащий более 800 млн вершин и более 3 млрд ребер, а также свыше 30 различных типов связей. При этом граф обновляется на ежедневной основе, а исторические слепки графов с заданным шагом хранятся в Hadoop-кластере, что очень важно для разработки моделей и получения корректных оценок эффективности. Для нашей задачи на первом этапе мы отобрали в графе только тип связи "переводы" и вершины, соответствующие клиентам банка и сторонним реквизитам (карты, счета в других банках). Глубину транзакций ограничили одним годом. Таким образом мы получили граф G (V, E), где V – это множество вершин, а E – множество ребер. Ребро между вершиной i и j существует, если в отобранном временном промежутке проводилась хотя бы одна подходящая транзакция. На этом этапе мы не стали фильтровать ребра ни по суммам, ни по количеству переводов, хотя такая возможность присутствует. Общее число вершин в получившемся графе – свыше 250 млн, а ребер – свыше 2,2 млрд. Оценку эффекта решено было провести на основных real-time-моделях

Pytorch BigGraph (PBG) Pytorch BigGraph – решение Open Source от компании Facebook. PBG – это распределенная система для получения embedding для очень больших графов (по информации от разработчиков, до миллиардов вершин и триллионов ребер), что достигается за счет некоторых функций, а именно: l партиционирования графа (позволяет обучать модели без необходимости загрузки всего графа в оперативную память); 2

Рис. 2. Основные компоненты решения PyTorch BigGraph, использующиеся для распределенного обучения2

https://arxiv.org/pdf/1903.12287.pdf

• 43

ТЕХНОЛОГИИ

Рис. 3. Зависимость ROC AUC от числа групп вершин обучения модели оценки риска переводов в ДБО, которые находятся в промышленной эксплуатации. Были выбраны именно модели переводов, потому что в них присутствуют отправитель и получатель, которые как раз являются вершинами в нашем графе. Для обучения этих моделей использовались их же конвейеры (Pipelines) формирования обучающей выборки, подготовки и отбора признаков (включая графовые эвристики), подбор гиперпараметров. Глубина обучающей выборки – четыре месяца (с мая по август 2020 г.), в нее включены все мошеннические переводы клиентов в каналах ДБО (выявленные и пропущенные текущим финансовым мониторингом) и случайная выборка переводов в соотношении 50:1. Для оценки прироста эффективности был выработан следующий поэтапный подход: 1. Производится обучение модели через существующие конвейеры, затем на отложенной по времени части выборки оценивается эффективность моделей (точность при заданном уровне полноты выявления мошенничества, ROC AUC).

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

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

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

5. Производится сравнение эффективностей моделей без GRL-признаков и с ними.

44 •

Рис. 4. Зависимость функции потерь модели (ranking loss по умолчанию) от числа групп вершин обучения модели

Эксперименты по построению Graph Embedding Для применения Pytorch BigGraph сначала необходимо сконвертировать граф в специальный формат, с которым работает решение. К сожалению, в самом решении реализован только базовый метод конвертации, работающий крайне медленно и в однопоточном режиме. Конвертации среза нашего графа этим методом, по оценкам, заняла бы семь дней. Авторы решения пишут, что реализация механизмов конвертации остается за пользователем решения (изза большого числа разных систем хранения и форматов) и в документации подробно описан необходимый формат файлов. Поэтому мы сами реализовали метод, который конвертирует срезы нашего графа из Hadoop в требуемый формат. В результате конвертация среза графа выполняется всего за тридцать минут. Для проведения экспериментов с Pytorch BigGraph использовался сервер следующей конфигурации: 7 CPU с 8 ядрами и 750 GB RAM. С учетом доступной оперативной памяти сервера и других запущенных на сервере процессов при конвертации слепков нашего графа в требуемый формат мы партиционировали его на 20 частей. При серверах с меньшей доступной памятью или большими по размеру графами можно увеличить данный параметр.

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

Подготовив первый срез графа, мы сначала посмотрели, какое время у нас займет одна эпоха обучения. С учетом описанной конфигурации сервера и параметров одна эпоха обучения заняла приблизительно 1,5 дня. Затем мы решили посмотреть, сколько эпох обучения потребуется, чтобы модель Pytorch BigGraph обучилась и с какого момента качество модели (ROC AUC в данном случае) перестанет расти. Для этого мы запустили обучение модели PBG на шести эпохах и получили следующие графики ROC AUC/loss-функции (одна эпоха – примерно 210 групп вершин) (см. рис. 3 и 4). Из графиков видно, что в целом уже после трех эпох обучения (около 650 групп вершин) значения ROC AUC и loss-функции выходят на плато и практически не изменяются. Поэтому для построения embedding на срезах графа мы решили обучать модели в течение трех эпох, таким образом на построение embedding одного среза графа уходит примерно четыре-пять дней. Сам embedding графа размерностью 256, то есть представление каждой вершины графа в виде вектора из 256 веще-

Рис. 5. Отображение случайного 1 млн вершин на плоскость (с помощью алгоритма снижения размерности umap)

ТЕХНОЛОГИИ

www.itsec.ru

Выводы и перспективы развития Полученные результаты показывают, что применение методов Graph Representation Learning в задачах противодействия мошенничеству дает существенный прирост эффективности, и это даже при условии, что базовые графовые эвристики использовались в моделях фродмониторинга. Если графовые данные не используются, то эффект от GRL-методов будет еще сильнее. При этом существующие инструменты Оpen Source уже достигли той степени зрелости, когда при минимальных доработках они позволяют строить эмбеддинги для очень больших графов (сотни миллионов верРис. 6. Сопоставление embedding вершин на обучающую выборку шин и миллиарды ребер). Соответственно, для внедрения подобных технологий требуются минимальные затраты вычисственных чисел, занял около 300 Гбайт Мы также рассмотрели, какие из лительных и временных ресурсов. на HDD. Для примера мы визуализиродобавленных GRL-признаков по резульСейчас мы проводим миграцию развали 1 млн случайно выбранных вершин татам отбора попали в финальную работанного решения для промышленна плоскости с помощью алгоритма снимодель и на каких позициях. Оказалось, ной эксплуатации и регулярного расчета жения размерности umap. В целом даже что сами по себе embedding вершины embedding и по результатам обновим на 1 млн случайных вершин видны клане информативны для модели выявления процессы обучения и сами модели фродстеры плотно взаимодействующих вермошеннических транзакций (не прошли мониторинга дополнительными GRL-пришин (см. рис. 5). отбор признаков), но близости между знаками. У нас также в планах после вершинами, участвующими в транзаквывода решения в промышленную эксциях, вошли в пять наиболее значимых Построение embedding на срезах плуатацию провести еще серию экспепризнаков моделей. И это при том, что графа и применение в моделях риментов в разных направлениях: в модели и так в явном виде присутскоринга переводов l попробовать другие размерности ствуют признаки, описывающие предыС учетом времени, которое требуется embedding, функций потерь и мер блидущие взаимодействия между отправидля получения embedding среза графа зости, доступных в PBG; телем и получателем (число операций, (4-5 дней), мы решили поступить слеl при построении графа учитывать не длительность связи). дующим образом: было выбрано четыре только транзакционные, среза графа на конец каждого месяца но и иные типы связей, (апрель, май, июнь, июль). Для каждого а также проводить фильтсреза рассчитывался его embedding. рацию по ребрам/учитыЗатем векторные представления из превать суммы как дополнидыдущего месяца добавлялись в качетельные веса ребер; стве дополнительных признаков к верl воспользоваться пока шинам из переводов обучающей выборэкспериментальной функки следующего месяца (см. рис. 6). цией PBG, которая позПосле добавления векторных представволяет к вершинам добалений к вершинам в переводах вычисвить описывающие их лялись близость между вершинами, векторы (например, воза для этого использовались две функраст, оборот и пр.), то ции – косинусная близость и скалярное есть использовать решепроизведение. ние уже в supervisedДоля покрытия переводов, когда и для виде. отправителя, и для получателя нашлись Вероятно, в результате соответствующие им embedding, при таком будут найдены параметподходе составила около 80%. Непокрыры, которые дадут еще тые переводы возникают из-за появления больший положительный новых клиентов/реквизитов, которых не эффект для моделей. было в графе. Для непокрытых переводов Рис. 7. График зависимости полноты и точности Кроме того, мы также значения признаков embedding заполняодной из моделей (синяя – без использования исследуем применимость лись NULL (алгоритмы градиентного PBG, красная – с использованием PBG) уже полученных embedбустинга умеют работать с отсутствуюding и для других задач противодействия Разработанный подход может быть щими значениями напрямую). Полученная мошенничеству. Например, используя использован в real-time-моделях, потому таким образом обучающая выборка содерэту информацию, можно провести клачто embedding рассчитываются заранее, жит в себе результаты GRL-моделей. стеризацию клиентов, отметить вершины а для скоринга транзакции на потоке по уже известным мошенникам и опредополнительно нужно по участвующим Результаты делить кластеры с высокой долей их в транзакции вершинам найти соответСравнив результаты моделей (без концентрации. Другие вершины в данном ствующие им embedding, а также расобогащения GRL-моделями и с обогакластере могут быть еще не известными считать скалярное произведение и косищением) на валидационной отложенной нам мошенниками. l нусную меру между найденными вектопо времени выборке, мы получили средрами. Все это при использовании inний прирост Gini в 1,5–2%. В отдельных Ваше мнение и вопросы memory-базы данных может быть выполслучаях прирост в точности работы присылайте по адресу нено очень быстро и не влиять на SLA модели при заданной полноте составлял is@groteck.ru моделей/фрод-мониторинг.

10–15% (см. рис. 7).

• 45

ТЕХНОЛОГИИ

Дубликатом бесценного груза: "Паспорт ПО" Надежда Мозолина, руководитель отдела программирования ОКБ САПР

С

реди вопросов построения систем защиты информации есть один, в ответе на который нет разногласий: их создание начинается с анализа текущего состояния информационной системы (ИС), далее следует определение объектов защиты и построение модели угроз, а завершающим этапом является сопровождение разработанной системы, ее непрерывный мониторинг, а также контроль состояния и конфигураций, причем этот контроль должен осуществляться в течение всей жизни ИС, вплоть до ее ликвидации 1 . "Паспорт ПО", разработанный для анализа программной среды компьютеров под управлением ОС Windows.

Контроль состояния и конфигураций необходим не только компонентам системы защиты, но и всем элементам информационной системы. Об этом нам говорят и требования, утвержденные приказами ФСТЭК России № 17 и 21 (АНЗ.2, АНЗ.4, ОЦЛ.1, ЗИС.18), а также 239 (АУД.1, ОЦЛ.1, ОДТ.8, ОПО.2). Рассмотрим особенности контроля изменений на рабочих местах пользователей с точки зрения повышения защищенности системы. Для большинства ИС характерны постоянные изменения: установка нового программного и аппаратного обеспечения, его обновление или удаление, создание документов, баз данных и т.д. Изменения, происходящие на рабочих местах пользователей, могут быть как результатом санкционированных действий (например, обновление версии программных модулей администратором), так и результатом работы некоторого вредоносного ПО, случайного или намеренного внесения нежелательных изменений пользователем. Последствиями несанкционированных изменений могут быть нерациональное использование рабочего времени, угрозы безопасности и промышленный шпионаж и даже полное нарушение работоспособности системы. Для своевременного обнаружения и предотвращения таких изменений недостаточно организационных мер (инструкций, регламентов), необходим постоянный мониторинг состояния рабочих мест пользователя. Обеспечить такой контроль может продукт ОКБ САПР

Основные функции "Паспорт ПО" Рассматривать возможности программного модуля интересно в сопоставлении с принципами управления конфигурациями, ориентированном на безопасность (Security-Focused Configuration Management of Information Systems, SecCM) – одной из концепций повышения защищенности информационной системы за счет управления ее конфигурациями. Реализация принципов SecCM заключается в: l идентификации и записи конфигураций, которые влияют на состояние безопасности системы и организации; l учете рисков безопасности при утверждении начальной конфигурации; l анализе последствий изменения конфигурации системы для безопасности; l документировании одобренных и внедренных изменений2. Стандарт указывает основные шаги, выполнение которых позволяет реализовать корректное управление конфигурациями в информационной системе. Так, ключевыми этапами являются: l планирование SecCM (разработка политик применения средства SecCM); l внедрение SecCM (определение базовых конфигураций и их утверждение); l контроль изменений конфигурации (использование некоторой панели управления конфигурацей для рассмотрения и утверждения изменений в ИС) и мониторинг уже утвержденных конфигураций. "Паспорт ПО" предназначен для автоматизации контроля целостности состоя-

ния программной среды (основных характеристик файлов программного обеспечения) и контроля изменений состава ПО (установленных на средство вычислительной техники системных и прикладных программных продуктов). Фиксация состояния конфигурации СВТ (программной среды вместе с совокупностью состава ПО) выполняется через создание записей специального вида – проектов паспортов ПО. Заверенный проект паспорта называется паспортом ПО и представляет эталонное состояние конфигурации СВТ. Для формирования паспорта ПО пользователь должен обладать в рамках "Паспорт ПО" правом на подпись проекта. Основные элементы "Паспорт ПО": 1. Серверный компонент (Сервер) с базой данных.

2. Компонент управления (АРМ управления).

3. Клиентский компонент (Клиент), устанавливаемый на подконтрольные объекты (ПКО) – рабочие места (СВТ), конфигурацию которых контролирует программный модуль.

4. Сервис обмена сообщениями RabbitMQ, обеспечивающий взаимодействие по сети между всеми элементами. Подготовка системы для работы "Паспорт ПО" заключается в выполнении следующих нескольких действий: 1. Регистрация учетных записей административного персонала, отвечающего за контроль целостности программной среды в АРМ управления, формирование ролей и назначение их учетным записям.

2. Формирование списка ПКО с разбиением на логические группы (подразделения).

1 ГОСТ Р 51583–2014. Защита информации. Порядок создания автоматизированных систем в защищенном исполнении. Общие положения.

2 Guide for Security-Focused Configuration Management of Information Systems [Электронный ресурс]. URL: https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-128.pdf.

46 •

www.itsec.ru

ТЕХНОЛОГИИ

Таблица. Соответствие между основными процессами и объектами 3. Формирование общей базы шаблонов (прототипов конфигураций рабочих мест пользователей).

4. Назначение шаблонов подконтрольным объектам.

5. Проведение опроса на ПКО (сканирования конфигурации СВТ в соответствии с назначенным шаблоном) и формирование его паспорта ПО. Эти действия соответствуют этапам планирования и внедрения SecCM. В результате подготовки системы в базе данных "Паспорт ПО" формируются записи об эталонном состоянии конфигурации СВТ с установленным Клиентом. В ходе дальнейшей работы выполняется сканирование подконтрольных объектов по заданному для СВТ расписанию или по запросу управляющего персонала "Паспорт ПО". В ходе сканирования Клиент определяет конфигурацию СВТ и отправляет информацию на Сервер, который автоматически сверяет полученные данные о текущем состоянии ПКО с эталонным и информирует управляющий персонал "Паспорт ПО" о выявленных нарушениях. Для каждого ПКО в случае обнаружения нарушений должен быть выполнен анализ возникших изменений, в результате которого возможно обновление паспорта ПО в случае санкционированных модификаций или же принятие мер по устранению причин возникших несоответствий, разбор инцидента безопасности. Данные операции являются третьим этапом реализации SecCM. Информация обо всех действиях по формированию как проектов паспортов ПО, так и самих паспортов ПО сохраняется в журнале событий "Паспорт ПО". Анализ сообщений из журнала событий позволяет производить выявление изменений в уже утвержденных паспортах, реализовав тем самым этап мониторинга SecCM.

SecCM и "Паспорт ПО" Рассмотрев основные функции "Паспорт ПО" и сопоставив этапы его применения с этапами реализации концепции SecCM, выполним сравнение основных процессов и объектов, на которые опирается стандарт SecCM, и процессов и объектов, которыми оперирует программный модуль. Результат представлен в таблице. Стоит отметить, что "Паспорт ПО", который, как мы увидели, реализует управление конфигурациями, ориентированное на безопасность, является наложенным средством, целесообразность применения которого, при наличии аналогичной встроенной функциональности, время от времени все еще вызывает дискуссии. Использование большого числа компьютеров под управлением ОС Windows почти всегда сопровождается их объединением с использованием службы каталогов Active Directory (AD) в единый домен. Эта служба позволяет управлять

NIST.SP.800-128

"Паспорт ПО"

Управление конфигурацией, Configuration Management (CM) – набор действий, направленных на создание и поддержание целостности продуктов и систем посредством контроля процессов создания, изменения и мониторинга конфигураций этих продуктов и систем

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

Элемент конфигурации, Configuration Item (CI) – идентифицируемая часть системы (например, аппаратное обеспечение, программное обеспечение, встроенное ПО, документация или их комбинация), которая является дискретной целью процесса управления конфигурацией

Подконтрольный объект (ПКО) – СВТ с установленным на него Клиентом "Паспорт ПО", однозначно идентифицируется именем ПКО. Обеспечение контроля целостности конфигурации ПКО является целью применения "Паспорт ПО"

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

Паспорт ПО – заверенный проект паспорта ПО, содержащий информацию о конфигурации СВТ.

План управления конфигурацией, Configuration Management Plan (CM Plan) – полное описание ролей, обязанностей, политики и процедуры, применяемых при управлении конфигурацией продуктов и системы

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

Процесс заверения проекта заключается в его подписи пользователем "Паспорт ПО". Формирование нового паспорта ПО для СВТ возможно лишь в результате формирования нового проекта паспорта ПО, его сопоставления с действующим паспортом, а также подписи данного проекта

различными объектами (рабочими компьютерами, серверами, принтерами, пользователями и т.д.) из единой точки (контроллера домена), а также получать сведения о состоянии объектов и об их изменениях, то есть выполнять мониторинг конфигураций. Хотя использование встроенных в AD технологий и позволяет осуществлять контроль изменений рабочих мест, применение данной службы каталогов суперпользователя", смешения прав и порождает "проблему суперпользоваобязанностей системного администратора и администратора ИБ, поэтому, теля", то есть сосредоточения максинесмотря на частичное дублирование мальных привилегий в рамках одной встроенной функциональности, именно роли, в данном случае – в рамках роли наложенное средство является необхоадминистратора домена. Обладая полдимым компонентом защищенной ными правами, он может вносить любые информационной системы. l изменения, что делает бессмысленным возложение на него же еще и обязанностей по контролю этих Реклама изменений.

NM Применение же налоАДРЕСА И ТЕЛЕФОНЫ женного средства контро"ОКБ САПР" ля изменений позволяет см. стр. 60 избежать "проблемы

• 47

ТЕХНОЛОГИИ

UserGate Management Center для управления парком межсетевых экранов Иван Чернов, менеджер партнерского отдела UserGate

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

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

Решение для филиальной сети

Управляемые области и шаблоны

Не секрет, что уровень обеспечения информационной безопасности в головной организации и в филиалах может существенно различаться. Это актуально и для госсектора, например в случае подведомственных организаций министерств. Часто на местах не хватает ресурсов для поддержания ИБ-решений в актуальном состоянии с точки зрения безопасности вообще и с точки зрения соответствия стандартам головной организации в частности. Внедрение централизованно управляемых систем, примером которых служит UGMC, может быть хорошим и оправданным решением для организаций с большой численностью сотрудников, развитой региональной структурой и прочими атрибутами "большого игрока".

UGMC вводит понятие управляемой области – логического объекта, представляющего одно предприятие или группу предприятий, обслуживаемых группой или отделом администраторов. Каждой области назначается отдельный администратор, который может управлять только одной назначенной ему областью. Администратор сервера UGMC имеет полномочия создавать управляемые области и назначать в них администраторов, не имея при этом доступа к объектам самой области. Разделение полномочий происходит на уровне управляемых областей. Шаблоны и группы шаблонов являются ключевым инструментом для настройки и управления парком устройств. Шаблон – это базовый блок, с помощью которого настраиваются все параметры работы межсетевого экрана – сетевые настрой-

UserGate Management Center как решение UserGate Management Center (UGMC) разработан как технологичный ответ на поставленные выше вопросы. UGMC позволяет управлять большим количеством межсетевых экранов и предоставляет единую точку управления, из которой администратор может выполнять мониторинг устройств UserGate, применять необходимые настройки, создавать политики, применяемые к группам устройств для поддержания безопасности корпоративной сети. Использование UGMC позволяет улучшить эффективность управления и поддержки распределенного парка межсетевых экранов UserGate.

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

48 •

Внутри каждой управляемой области настройки и правила создаются в шаблонах и группах шаблонов.

www.itsec.ru

ЗАЩИТА СЕТЕЙ

ки, правила межсетевого экранирования, контентной фильтрации, системы обнаружения вторжений и др. Группы шаблонов объединяют несколько шаблонов в единую конфигурацию, которая применяется к управляемому устройству. Группы упрощают централизованное управление, поскольку позволяют задать базовую конфигурацию для всех МЭ с помощью одного или нескольких шаблонов, входящих в группу, оставив при этом возможность специфической настройки каждого МЭ, дополняя специфичные настройки требуемыми шаблонами. Результирующие настройки, применяемые к устройству, формируются в результате слияния всех шаблонов, входящих в группу. Это позволяет определить группы шаблонов на основе функции географического расположения (например, Москва, Екатеринбург, Новосибирск и т.п.) или функциональной принадлежности (например, офис продаж, офис разработки, производство и т.п.). Централизованное управление межсетевыми экранами можно разделить на четыре этапа: 1. Создание управляемой области.

2. Создание одного или нескольких шаблонов, каждый из которых опишет свою часть настроек МЭ.

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

4. Добавление управляемого межсетевого экрана и применение к нему группы шаблонов.

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

забытые DHCP-серверы, которые провоцируют конфликты в IP-адресации, приводя к проблемам с доступностью сетевых узлов. Чтобы избежать подобных проблем, UGMC позволяет систематизировать подход к составлению настроек через применение шаблонов, а также прозрачно применить эти настройки на выбранной части парка межсетевых экранов.

Управление кластерами и применение к ним политик UGMC позволяет объединять несколько межсетевых экранов в кластер. Поддерживаются два типа кластеров: 1. Кластер конфигурации. Узлы, объединенные в кластер конфигурации, поддерживают единые настройки в рамках кластера.

2. Кластер отказоустойчивости. До четырех узлов кластера конфигурации могут быть объединены в кластер отказоустойчивости, поддерживающий работу в режиме "актив-актив" или "активпассив". Самих кластеров отказоустойчивости может быть несколько. В режиме "актив-пассив" один из МЭ выступает в роли мастер-узла, обрабатывающего трафик, а остальные – в качестве резервных. Для кластера указывается один или более виртуальных IP-адресов. Переключение виртуальных адресов с главного на один из запасных узлов происходит, если: l запасной МЭ не получает подтверждения о том, что главный МЭ находится в сети, например, если он выключен или отсутствует сетевая доступность узлов; l на главном МЭ настроена проверка доступа в Интернет; l происходит сбой в работе ПО UserGate. В режиме "актив-актив" один из МЭ выступает в роли мастер-узла, распределяющего трафик на все остальные узлы кластера. Мастер-узел обеспечивает равномерное распределение трафика на все узлы кластера, учитывая при этом необходимость неразрывности пользовательских сессий. Для кластера указывается один или более виртуальных IP-адресов. Аналогичным образом и сами устройства UGMC могут при необходимости быть объединены в кластеры для увеличения производительности или для повышения отказоустойчивости.

Советы по внедрению

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

2. Разделять различные группы настроек в разные шаблоны. Например, общие настройки устройств стоит хранить в одном шаблоне, политики контентной фильтрации – в другом, политики межсетевого экранирования – в третьем, политики СОВ – в четвертом и т.д. Разнесение блоков настроек по разным шаблонам позволит избежать конфликта настроек и сделает централизованное управление проще.

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

4. Помнить про полномочия локальных администраторов. Если предполагается наличие локальных администраторов, то их полномочия будут ограничены настройками тех параметров, которые не заданы через шаблоны UGMC, а правила, созданные локальными администраторами, всегда помещаются между пре- и пос-правилами, применяемыми из UGMC. При необходимости настройки, заданные в шаблонах, можно изменять, чтобы эти изменения применялись ко всем МЭ, к которым применимы данные шаблоны.

Форматы исполнения UGMC поставляется в виде программно-аппаратного комплекса (ПАК, Appliance) либо в виде образа виртуальной машины (Virtual Appliance), предназначенного для развертывания в виртуальной среде.

UserGate Management Center Virtual Appliance позволяет быстро развернуть виртуальную машину, с уже настроенными компонентами. Образ создан в формате OVF (Open Virtualization Format), который поддерживают такие вендоры, как VMWare, Oracle VirtualBox. Для Microsoft Hyper-V и Linux KVM поставляется образ диска виртуальной машины. l

Развертывание UGMC на предприятии требует предварительного планирования. От того, насколько качественно продумана архитектура шаблонов, зависит простота и гибкость применения политик управления на межсетевых экранах. UGMC позволяет эффективно применять Реклама NM общие политики, группиАДРЕСА И ТЕЛЕФОНЫ руя их по географическокомпании "UserGate" му, функциональному или см. стр. 60 смешанному принципам.

• 49

ТЕХНОЛОГИИ

Создание ценности на каждом этапе Дарья Орешкина, директор по развитию бизнеса компании Web Control

Р 2020 год выдался нелегким для бизнеса. Клиенты компаний – разработчиков ПО в условиях сокращения бюджетов требуют снижения стоимости поставки программных продуктов. Разработчикам как никогда необходимо оптимизировать процессы, развивать сотрудников, одновременно повышая качество и скорость реакции на запросы клиентов, при этом увеличивая прибыль. Системы управления потоком создания ценности конечного продукта (Value Stream Management, VSM) для разработки программного обеспечения помогают принимать взвешенные, соответствующие бизнес-целям решения, а также управлять качеством и вовремя осуществлять выпуски. В течение последних нескольких лет, и особенно ярко в 2020 г., мы наблюдаем переход от индустриальной экономики, основанной на производстве, к цифровой экономике – экономике знаний на базе ИТ. В новых реалиях главная роль отводится производству цифровых продуктов. Разработке ПО как самостоятельной отрасли приходится непрерывно изыскивать способы оптимизации процессов поставки ПО, чтобы удержаться на высококонкурентном рынке. В поисках таких способов она обращается к методологическим наработкам промышленности – зрелой отрасли, для которой выработаны системные подходы к оптимизации производства, например такие, как конвейер Форда, менеджмент качества Деминга, бережливое производство и концепция

аньше кто громче кричал, тот и продвигал свои запросы в роадмап, а потом появился VSM.

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

Простое и быстрое изменение требований к функционалу разрабатываемого продукта стало возможным благодаря практикам Agile, ориентированным на результат, а не на процессы, которые стали логическим развитием методик бережливого производства и Канбана. Непрерывная доставка с автоматизированными сборками и развертываниями стала возможной благодаря методологии DevOps, которая позволяет повысить скорость создания программных продуктов в тысячи раз. Затем ожидаемо возник вопрос о повышении эффективности процесса создания ценности (то есть разработки программного обеспечения), чтобы на высококонкурентном рынке можно было снизить стоимость разработки, предоставляя при этом функционал, наиболее полно отвечающий требованиям заказчика. Так начал формироваться и относительно недавно увидел свет новый класс решений – Value Stream Management, управление потоком создания ценности. Под потоком создания ценности понимается совокупность всех действий, которые требуется совершить, чтобы определенный товар или услуга прошли стадии от разработки концепции до готового продукта. Решения этого класса объединяют Agile-планирование и DevOps в единый поток и делают его видимым, "материальным". VSM-инструменты отслеживают прогресс, статус и изменение состояния эпиков, пользовательских историй, задач разработки, артефактов, перемещающихся в потоке создания ценности, а также визуализируют процессы, генерируют отчеты, предоставляют практические рекомендации на основе аналитики и алгоритмов AI и ML. Все это позволяет связывать разные события в процессе и получать своевременную обратную связь для управления процессами планирования и разработки. Давайте рассмотрим, что дает VSM для DevOps на примере функциональных групп возможностей решения Digital.ai Agility, уже проявившего себя как эффективного помощника в создании успешных программных продуктов.

Планирование продукта Рисунок. Стадии производства программного обеспечения

50 •

Наверное, все помнят картинку-мем про разработку качелей, которая показывает, насколько порой расходится

webcontrol 11/23/20 9:18 PM Page 51

www.itsec.ru

БЕЗОПАСНАЯ РАЗРАБОТКА

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

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

VSM располагает расширенными возможностями по отслеживанию соответствия стратегических идей, запросов от клиентов и соотнесения их с фактическим исполнением.

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

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

Agile-управление проектами и командами Методология Аgile сформулирована очень просто, но реализовать ее на практике нелегко. Для этого должна быть четкая координация всех изменений и детальное понимание текущей ситуации в любой момент у всех ответственных лиц. Как правило, без специальных инструментов эта информация

фрагментирована в голове у разных людей и пропущена через призму субъективного восприятия. С помощью инструмента VSM команды разработки могут оперативно планировать и вносить скоординированные изменения в план работ, менять приоритеты задач и при этом в любой момент времени иметь актуальный срез состояния проектов для принятия обоснованных управленческих решений. Достигается это таким набором инструментов совместной работы, как комнаты обсуждений, доски планирования спринтов и итераций, карты показателей эффективности команд, хранилища описаний работ и наработанных практик.

Agile-метрики и аналитика Как оценить эффективность разработки без точных показателей и всесторонней аналитики? Часто такая оценка сводится к субъективному мнению.

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

VSM – это не только Agile, но и оркестрация релизов, автоматизация развертывания, защита приложений изнутри, аналитика на основе искусственного интеллекта и многое другое, о чем я расскажу в следующих статьях. Управление потоком создания ценности продукта – это не просто стратегия сокращения затрат, а основа развития. l Ваше мнение и вопросы присылайте по адресу

is@groteck.ru

Реклама

VSM – это не только Agile, но и оркестрация релизов, автоматизация развертывания, защита приложений изнутри, аналитика на основе искусственного интеллекта и многое другое

• 51

ТЕХНОЛОГИИ

Как перейти на безопасную разработку: история одного проекта Алексей Жуков, эксперт отдела систем защиты приложений, Positive Technologies

В

среднем на одно приложение приходятся 1 22 уязвимости, при этом 82% уязвимостей содержится в исходном коде, а устранить их можно было бы еще на самых ранних этапах создания приложения. Такой подход называется безопасной разработкой (SSDL, SDL, SDLC 2 ). Почему анализ безопасности кода необходим бизнесу и как организовать SSDL-процесс на предприятии, разберем на примере проекта ИТ-компании, которая занимается заказной разработкой ПО. включает применение не только технологий, но и ряда организационных мер. Разберем, как перейти на SSDL на примере работы одной ИT-компании.

Кто созрел для SSDL Анализ3 защищенности веб-приложений, проведенный нами в этом году, показал, что каждая пятая уязвимость имеет высокий уровень риска. Эксплуатация таких уязвимостей может привести к краже важных данных, временным простоям или полному выводу системы из строя. Все это – серьезные финансовые и репутационные риски для любой компании. Раннее выявление уязвимостей, во-первых, минимизирует перечисленные риски, а во-вторых, экономически выгоднее, чем их устранение на более поздних стадиях разработки. Согласно исследованию Applied Software Measurement, Capers Jones, исправление ошибок на этапе написания кода обойдется компании до $10, а вот за их устранение на этапе эксплуатации ПО компания заплатит уже свыше $10 000. Эти цифры с каждым годом будут только расти. Приходится соглашаться с тем, что в качественном соотношении представленная картина и в будущем сохранит свою актуальность (см. рис. 1). По данным GBKSoft4, в среднем разработка одного приложения занимает 4,5 месяца, такие темпы не позволяют выделить время на выявление всех уязвимостей вручную. Для обеспечения высокого уровня защищенности приложений компаниям необходимо построить процесс безопасной разработки, который

Мы построили процесс безопасной разработки с нуля, последовательно внедрив его ключевые компоненты, в том числе периодическое проведение как ручного, так и инструментального анализа защищенности приложения, встраивание автоматизированного поиска уязвимостей в конвейеры сборки, разработку документации, проведение обучения разработчиков, консультирование по выявленным проблемам. Наш клиент – крупная ИT-компания, занимающаяся разработкой ПО по заказам более 20 лет. В команду входят свыше 1 тыс. сотрудников. Помимо внешних, заказных проектов, организация развивает и свои внутренние решения – обучающие программы для персонала, HR-инструменты, корпоративный портал.

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

Первый помощник в SSDL – анализатор кода Анализаторы кода помогают найти типичные ошибки, которые допускают программисты, проводя множество рутинных проверок. Это снижает нагрузку на команду разработки. Внедрение анализатора кода стало для нас задачей первой важности. Поскольку в проектах клиента уже использовались практики CI/CD5, необходимо было интегрировать его в действующие процессы. Мы провели тщательную подготовку и начали строить решение на базе нашего анализатора кода PT Application Inspector.

Командная работа и security champions

Рис. 1. Стоимость устранения уязвимостей в коде в зависимости от этапа разработки

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

https://www.ptsecurity.com/ru-ru/research/analytics/web-vulnerabilities-2020/ Процесс, обеспечивающий возможность поддержки необходимого уровня безопасности создаваемой системы как на этапе разработки, так и в ходе эксплуатации. Ключевыми аспектами этого подхода является обеспечение безопасности приложения, идентификация рисков и управление ими.

3 https://www.ptsecurity.com/ru-ru/research/analytics/web-vulnerabilities-2020/ 4 https://gbksoft.com/blog/how-long-does-it-take-to-develop-a-web-app 5 Continuous Integration & Continuous Delivery, CI/CD – комбинация непрерывной интеграции и непрерывной доставки или непрерывного развертывания.

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

1 2

52 •

www.itsec.ru

БЕЗОПАСНАЯ РАЗРАБОТКА

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

Как настроить доступ к коду Один раз проанализировать код несложно. Достаточно просто скачать его или скопировать на USB-накопитель и доставить до компьютера, на котором установлен анализатор. Однако если вы хотите автоматизировать этот процесс и проверять код регулярно, то помимо технических вопросов возникают и организационные, например, как дать анализатору кода доступ к набору репозиториев исходного кода. Предоставить доступ сразу ко всем проектам небезопасно, а открывать его к каждому проекту по отдельности – значит перегрузить ИT-отдел заявками. У этой проблемы есть простое и эффективное решение: интегрировать анализатор кода в систему CI, для которой проблема контролируемого доступа к коду уже решена.

Что делать со сторонним кодом Сегодня при создании приложений разработчики используют внешние библиотеки и фреймворки. Таким образом, анализируя приложение, важно знать и об уязвимостях, которые имеются в сторонних компонентах. В нашем случае нужно было найти эффективное решение, которое позволило бы работать с такими зависимостями. Типовой выход – автоматизированная загрузка используемых компонентов на основе данных, определенных в специализированных файлах (pom.xml, composer.json и т.д.). Но это потребовало бы предоставления доступа в Интернет к открытым репозиториям артефактов (например, MVN Repository) с хостов, на которых выполняется анализ кода. Мы нашли другое решение – интеграцию с системами CI/CD, которая позволила избежать такого шага.

На правах рекламы

Как обрабатывать результаты Анализ для нас не являлся самоцелью. Это лишь часть подхода, который помогает решить основную задачу – сделать разрабатываемое приложение безопасным. Мы хотели, чтобы данный процесс был удобным для пользователя. PT Application Inspector идеально подошел для этой цели, поскольку обеспечил инкре-

ментальный7 анализ и наследование статусов уязвимостей. Это обеспечило быструю реакцию и низкое потребление ресурсов, которые помогли свести как автоматический процесс анализа кода, так и процесс ручной обработки результатов к некоторому устоявшемуся виду, в котором работа с продуктом требует разумного минимума ресурсов.

Как обучить сборщика В отличие от человека системам CI/CD требуются строгие критерии оценки результатов на каждом этапе сборки. Если хотя бы один из шагов не проходит успешно, останавливается весь процесс сборки. Для каждого пилотного проекта мы разработали уникальные наборы правил для интеграции анализа кода в CI/CD. В большинстве случаев, если в ходе важной сборки (например, релиз-кандидата) обнаруживалась критическая ошибка, сборка останавливалась. Это позволило снизить трудозатраты разработчиков: теперь не было необходимости смотреть в каждый отчет анализатора и вручную принимать решение о дальнейшей судьбе сборки, все было автоматизировано.

Первое внедрение ИT-компания выбрала около 20 проектов, над которыми работали 10 команд разработчиков. Наша задача состояла в том, чтобы проверить жизнеспособность и надежность системы в ее текущей реализации. На этом этапе мы выполнили следующие задачи: 1. Подключили пилотные проекты к развернутому решению и проверили его работоспособность.

2. Написали руководства по самостоятельному развертыванию системы для сотрудников компании.

3. Помогли разработчикам добавить решение в другие проекты. После этого процесс SSDL заработал в полную мощь! Оставалось только передать нашу экспертизу по анализу результатов.

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

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

Результаты Переход на безопасную разработку на базе PT Application Inspector позволил ИT-компании обеспечить раннее выявление уязвимостей в коде, снизить трудозатраты команд разработки на их устранение, повысить осведомленность и заинтересованность в безопасности кода. Эти рекомендации будут полезны для любого жизненного цикла разработки приложений, но лучше всего они работают в проектах CI/CD. l Убедитесь в том, что руководство понимает важность внедрения SSDL, заручитесь его поддержкой и зафиксируйте цели внедрения. l Каждая команда разработчиков должна выбрать своего security champion – лидера по вопросам безопасности. Этот человек будет основным драйвером в процессе внедрения практик безопасной разработки. l Изучите анализаторы кода, имеющиеся на рынке, и выберите тот, который лучше всего подходит для ваших целей. l Сделайте так, чтобы весь ваш код, включая сторонние компоненты, был доступен для инструментального анализа. l Настройте анализатор кода. Проверьте результаты его работы и отрегулируйте настройки сканирования, чтобы добиться приемлемого числа ложных срабатываний. l Определите критерии нарушений безопасности, которые будут вызывать автоматическую остановку сборки. l Протестируйте решение на небольшом количестве проектов. Это даст вам обратную связь, которая позволит провести тонкую настройку решения. l Напишите точные и краткие инструкции для команд, которые начнут работать с SSDL после завершения пилотной стадии проекта. l Проведите обучение по безопасности для сотрудников и затем проверьте их понимание принципов SSDL и знание технических деталей. l Запланируйте и проведите дальнейшие шаги по последовательному тиражированию решения на остальные команды разработки. l Ваше мнение и вопросы присылайте по адресу

is@groteck.ru

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

• 53

ТЕХНОЛОГИИ

Смысл и безопасность Валерий Конявский, д.т.н., заведующий кафедрой “Защита информации” МФТИ

Я Бессмысленность в безопасности Статья (доклад? стенограмма?) Владимира Иванова "Электронная подпись на мобильных устройствах и облачные решения: секреты должны оставаться секретами", рассказывает о новом решении компании "Актив" для электронной и облачной подписи. В чем актуальность научного поиска? Автор постулирует: "сейчас стоит задача отделить ключи подписи от устройства, но при этом не прибегать к контактным интерфейсам, сделать это по разумной цене и при этом с хорошей криптографией. И решением является их новое устройство – дуальная смарт-карта Рутокен ЭЦП 3.0 с интерфейсом NFC" (Здесь и далее: орфография, пунктуация и стиль изложения сохранены. Текст приведен в оригинале. – Прим. ред.). Возникают вопросы: 1. "Отделить ключи подписи от устройства". Зачем? От какого устройства? От любого? А как их потом использовать? И как вообще они туда попали? Может, чтобы не отделять, не стоило туда их помещать?

2. "Не прибегать к контактным интерфейсам". Почему? Чем они провинились? Тем, что не используют уязвимые радиоканалы?

3. "Сделать это с хорошей криптографией". Что сделать? "Отделить ключи подписи от устройства"? А что означает "хорошая криптография"? Вспоминается М. А. Булгаков с отрицанием осетрины второй свежести. Ну что же, задачи поставлены, хотя и невнятно. Но, может быть, эти задачи уже решены с использованием других средств? "Нет" – утверждает автор, – "У других решений много недостатков". Автор отмечает, что мобильное приложение, мобильное устройство, токены и симкарты в качестве носителей имеют слиш-

54 •

ркой приметой времени являются дискуссии по мобильным решениям. Рассмотрим одно типичное выступление, представленное журналом "Информационная безопасность банков" в разделе "Энциклопедия безопасности". Возможно, эта "энциклопедическая" статья основана на неумелой стенограмме выступления. Устная речь отличается от литературной, это понятно, но нельзя же публиковать под рубрикой "Энциклопедия" совершенно сырой непричесанный материал! Это дело журнала, конечно, но впечатление от сумбурного выступления остается очень тяжелое, портящее мнение и о выступающем, и о журнале, позволяющем себе такие публикации. Но оставим форму, обратимся к содержанию. Попытаемся найти смысл. ком большое количество недостатков, и, следовательно, подразумевается, что новое решение недостатков лишено. Напомним, что в качестве такового идеального решения предлагается рассмотреть смарт-карту "Рутокен ЭЦП 3.0" с интерфейсом NFC. О каких же недостатках идет речь? Автор рассматривает несколько вариантов: СКЗИ как приложение, СКЗИ на базе сим-карты, токены и облачная подпись. Автор критикует эти подходы (мы с ним в его пафосе солидарны, но критика должна быть объективной и предметной, в профессиональном дискурсе). Вслед за автором перечисленные варианты рассмотрим и мы.

"Мобильная подпись непосредственно в мобильном приложении" СКЗИ в целом и подпись в частности, реализованные в виде приложения, – это программное СКЗИ. Значит, оно должно использоваться в доверенной среде функционирования криптографии, то есть как минимум на доверенном устройстве. Использовать недоверенное устройство нельзя, и вопрос тут не в мобильности терминала или мобильности подписи (кстати, что это?), а в отсутствии возможности поддержки доверенной среды функционирования криптографии (СФК). Если мысль в журнальном изложении нам удалось уловить правильно, то нельзя не согласиться с автором. Только, повторим еще раз, дело тут не в мобильности, а в незащищенности среды, в невозможности обеспечить нужные условия. Приложение в незащищенной среде не может быть приемлемым решением для СКЗИ. Этот факт общеизвестен и понятен всем, и вряд ли требуется это пояснять. Классификация внутренних нарушителей начинается с Н2, и поэтому рассматри-

вать класс защищенности КС1 для защиты от внутренних нарушителей – по меньшей мере непрофессионально. Автор прав. Но чем мотивирует автор? Не приводя ужасную цитату, выберем из текста слова, похожие на используемые в технической защите информации: l защита генератора случайных чисел; l безопасность ключей; l хранение ключей в доверенном хранилище; l мобильные устройства не поддерживают по умолчанию российскую криптографию. О каком генераторе случайных чисел в смартфоне вообще идет речь? От чего его нужно защищать? Качество случайных последовательностей, используемых для ключа подписи играет важную роль, но где взять отсутствующий генератор, чтобы потом его защищать? Видимо, автор ненароком процесс обеспечения качества случайных последовательностей назвал "защитой". Но это не слишком корректно, если не сказать яснее. Не нужно так делать. Защита и обеспечение – это разные процессы. Профессионалы должны это понимать. "Безопасность ключей": они что, ощущают незащищенность и в связи с этим неуверенность в завтрашнем дне? Или они сами опасны? Ключи нужно правильно изготавливать, хранить и правильно применять. Страшиться не стоит. "Доверенное хранилище ключей" – правильно, хранение ключей принципиально важно. Хранить ключи в файловой системе или в коде приложения – совершенно недопустимо, здесь с автором нужно согласиться, если его мысль понята нами правильно. "Мобильные устройства не поддерживают по умолчанию российскую криптографию" – вот эта мысль нам не понятна. А стационарные устройства поддерживают? А как это – "по умолчанию"? Не

www.itsec.ru

КРИПТОГРАФИЯ

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

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

"Специальные сим-карты стоят денег" Справедливо. Но означает ли указание на этот недостаток то, что предлагаемые автором решения не стоят денег? Интересненько. Раньше нам казалось, что в аппаратном смысле смарт-карты и сим-карты не сильно отличаются. Почему же решение "Актива" ничего не стоит? Странный способ маркетинга.

"Идентификация и УЦ" Это серьезная проблема, и ее стоит обсудить. Причем с самого начала, от 1-ФЗ до нынешних времен. Дело в том, что в общественном сознании укрепился миф (как минимум, заблуждение, а может, и фейк), что УЦ призван изготавливать ключ подписи. Но это не так! Это лишь одна из услуг, которую УЦ может (может!) оказать, но окажет только в том случае, если гражданин внезапно проникнется огромным и ничем необъяснимым доверием к УЦ и его персоналу. А главная, основная функция УЦ – изготовление сертификата ключа проверки подписи. Вот и все. И ничего другого.

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

2. С использованием СКЗИ генерируется ключ подписи и вычисляется ключ проверки подписи.

3. Ключ подписи записывается на выбранные пользователем носители, один или несколько – здесь пользователь ничем не ограничен, кроме собственных представлений о безопасности.

4. Ключ проверки подписи также записывается на носитель, но уже другой. Этот носитель понадобиться для визита в УЦ.

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

6. УЦ изготавливает сертификат ключа подписи и записывает его на носитель, который удобен для пользователя. Как мы видим, этот процесс никак не связан с тем, является ли оператор связи заодно и удостоверяющим центром. Оператор связи продает оборудование, а УЦ изготавливает СКП. И совершенно необязательно объединять эти две разные услуги. А функцию записи ключа на носитель должен реализовать вендор СКЗИ. Очевидно, что УЦ излишне настойчиво предлагают пользователю услугу, которая заключается в полном цикле, от генерации ключа подписи до изготовления СКП. Наверное, можно и так, хотя в результате безопасность информационного взаимодействия выглядит сомнительной. Такой подход аналогичен тому, что при визите в паспортный стол мы просили бы паспортистку не зафиксировать нашу подпись, а придумать ее и самостоятельно внести в паспорт и учетную карточку. Согласитесь, похоже на бред. И почему же мы не видим аналогии в просьбе к УЦ изготовить ключ подписи за нас? Проблема очевидна. Разрешается она, с одной стороны, созданием правильных СКЗИ, позволяющих пользователю реализовать описанную выше процедуру, и повышением грамотности пользователей, которые сейчас бредут по извилистой тропинке, навязываемой УЦ. И уж совсем ни при чем тут мнимые недостатки сим-карты.

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

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

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

Смарт-карта Вот это главное. Вот это Владимир Иванов и предлагает. Что ж, давайте рассмотрим. Вот как описывается предложение в журнале (прошу прощения за длинную цитату). " … Мы сегодня представляем наше новое устройство – это дуальная смарткарта Рутокен ЭЦП 3.0 с интерфейсом NFC. …И у нас получается, что неизвлекаемые ключи подписи лежат на смарт-карте. Мы можем подписывать на этой карте данные и от прило-

• 55

ТЕХНОЛОГИИ Смысл и безопасность

Рисунок. Взаимодействие при использовании облачных ключей. (Зеленым обозначены доверенные элементы, красным – недоверенные) жений, и от браузера, и на мобильном приложении – фактически, где угодно. И плюс к тому, если мы работаем в облачной среде, мы эту смарт-карту можем использовать для аутентификации пользователя на облачном сервисе. Таким образом, ключи подписи продолжают лежать в облачном сервисе, а доступ к ним осуществляется по защищённым протоколам, с хорошей мощной аутентификацией на аппараты криптографии", – пояснил Владимир Иванов. Оставим на совести автора странный для профессионала дискурс (типа "мощная аутентификация на аппараты криптографии"), рассмотрим суть предложения. Итак: 1. Пользователь работает на недоверенном терминале (смартфоне, компьютере, планшете и др.), у которого есть NFC. 2. Рядом кладется смарт-карта с NFC, на которой реализовано СКЗИ с неизвлекаемым ключем подписи.

3. По NFC из терминала на смарткарту направляется документ.

4. Документ подписывается за счет СКЗИ на смарт-карте.

5. И отправляется по NFC снова на недоверенный компьютер. Вот как это выглядит графически (см. рис). Это типичная сервисная модель. ЭП – как сервис. И все бы хорошо, но такие модели работают только в том случае, если все участники взаимодействия являются доверенными, и не могут использоваться, если хотя бы один из участников информационного взаимодействия использует недоверенные системы. Проиллюстрируем этот тезис совсем простым примером: 1. На недоверенном устройстве формируется платежное поручение, в котором фиксируется ваше волеизъявление перечислить 100 руб.

56 •

2. Естественно, на экране вы видите цифру 100 и инициируете отправку этого документа на сервис СКЗИ.

3. Вредоносное ПО (ВрПО), которое точно есть на недоверенном смартфоне, добавляет к указанной вами сумме три нуля, и посылает на сервис 100 000 руб.

4. Доверенный сервис немедленно подписывает вашей подлинной подписью модифицированную сумму и отправляет документ обратно.

5. ВрПО получает этот документ, убирает лишние три нуля и посылает на отображение.

6. Вы видите "правильный" подписанный документ, и инициируете передачу его в банк.

7. Передается, конечно, не то, что вы видите, а то, что подписано, то есть 100 000 с вашей подлинной подписью. Простейшая атака, но чрезвычайно эффективная. И хорошо иллюстрирующая, что сервисная схема может применяться только тогда, когда используется доверенное оборудование, как минимум – доверенное средство отображения. Странно, что до сих пор приходится это объяснять. Мне казалось, что достаточно прочесть ФЗ об электронной подписи и стараться потом в своей деятельности его не нарушать. Что мы имеем в итоге? Никакая сервисная схема не обеспечит безопасности, если используются недоверенные устройства, даже если сервис предоставляет доверенная "дуальная смарткарта Рутокен ЭЦП 3.0 с интерфейсом NFC". Все дело в том, что карта – это просто вычислитель, маленькая машина Тьюринга, которая вычисляет все, что угодно, а вовсе не то, что мы от нее ожидаем. Целое – это единство формы и содержания, а машина Тьюринга ничего не знает о содержании, она оперирует формой, числами, а не тем, о чем эти числа. Мы разорвали единство и получили проблемы.

Огромная часть успешных хакерских атак связана с нарушением смысла выполняемых операций. Обычно атака развивается следующим образом: l S1 – внедряется ВрПО, например подменяется обработчик прерываний; l S2 – организуется скрытый канал связи; l S3 – инициируется событие, вызывающее внедренное прерывание; l S4 – подмененный обработчик реализует атаку. Есть меры противодействия каждому из этих вредоносных шагов, реализуемые известными в технической защите информации средствами. Каждому, кроме одного, а именно S3. Покажем это. Допустим, подменен обработчик прерываний, обрабатывающий деление на ноль. Чтобы инициировать атаку, злоумышленник должен инициировать в используемой программе эту ситуацию. Но программу пишут люди, знающие основы компьютерных операций, и тестируют, и проверяют тоже не люди с улицы. Такие ситуации контролируют и компиляторы, и интерпретаторы, и все иные инструментальные средства. Просто так добиться деления на ноль непросто. Но злоумышленнику это не мешает. Ведь в здравом уме никто не добавит к времени, оставшемуся до конца рабочего дня (5 минут, например), нехватку вилок в столовой (-5 штук, например). Семантически неверно ко времени добавлять вилки, интуитивно это ясно всем. Но машина Тьюринга (то есть любая сегодня) эту операцию охотно выполнит. Вот и ноль, на который вполне в этой же логике можно разделить вес помидоров. Из этого примера ясно, что семантическая определенность данных способна резко, на порядки сократить количество успешных атак. Как это сделать – в одной из следующих статей.

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

is@groteck.ru

НОВЫЕ ПРОДУКТЫ И УСЛУГИ

НОВЫЕ ПРОДУКТЫ ETHIC – сервис выявления угроз для бизнеса

Производитель: Инфосекьюрити Назначение: мониторинг сети Интернет и выявление информационных событий Особенности: предоставляется как веб-сервис Возможности: мониторинг широкого круга источников, как в открытом сегменте сети Интернет, так и в Darknet, а также Telegram-каналах; автоматическая классификация выявленных сведений и уведомление заказчика о событиях Подробная информация: in4security.com/?do=ethic Фирма, предоставившая информацию: ИНФОСЕКЬЮРИТИ См. стр. 28

l Подготовка материалов судопроиз-

Характеристики:

водства l Интеграция с системами электронного документооборота, системами управления печатью, системой электронной почты Характеристики: Форматы защищаемых документов: l Документы, сформированные с помощью офисных пакетов Microsoft Office и OpenOffice: doc, docx, rtf, xls, xlsx, ppt, pptx, odt, ods, odp, xps, ps, eps l Документы формата PDF, включая различные подмножества, такие как PDF/A, PDF/X, PDF/A-1b и др. Допускается загрузка PDF в редактируемом формате l Файлы PostScript, подготавливаемые драйверами большинства принтеров в процессе предпечатной подготовки Ориентировочная цена: по запросу Время появления на российском рынке: новая версия – июнь 2020 г. Подробная информация: safe-copy.ru Фирма, предоставившая информацию: НИИ СОКБ См. стр. 9

l Управляет мобильными устройствами

Платформа централизованного управления мобильными устройствами EMMSafePhone 4.4

Система защиты конфиденциальных документов SafeCopy

Производитель: НИИ СОКБ Сертификат: № 310, выдан Anti-Malware.ru Назначение: защита документов от несанкционированного копирования, тиражирования и фотографирования Особенности: система SafeCopy осуществляет незаметную маркировку копий документов. В случае утечки маркировка позволяет гарантированно определить получателя копии по ее изображению, включая скан-копии, фотографии печатных копий, фотографии экранов, на которых отображена копия, а также фотографии низкого разрешения, публикуемые в социальных сетях и новостных каналов мессенджеров Возможности: l Ведение единого реестра конфиденциальных документов l Маркировка документов и учет выдачи электронных и печатных копий l Выявление канала утечки с вероятностью до 0,99 l Проверка подлинности документов по наличию маркировки

www.itsec.ru

Производитель: НИИ СОКБ Сертификат: № 4157, выдан ФСТЭК России Назначение: автоматизация процессов безопасного централизованного управления мобильными устройствами компании Особенности: платформа EMMSafePhone сертифицирована ФСТЭК России, включена в реестр отечественного программного обеспечения Минцифры России, а также соответствует требованиям ГОСТ Р 57580.1–2017 "Безопасность финансовых (банковских) операций. Защита информации финансовых организаций" Возможности: l Безопасное централизованное управление большинством современных мобильных устройств, работающих на всех мобильных платформах, представленных на российском рынке l Автоматизация жизненного цикла мобильных приложений – установка, обновление, настройка и удаление приложений на устройствах пользователей l Безопасное разделение корпоративных и личных данных на мобильном устройстве l Мониторинг местоположения мобильных устройств

на базе iOS, Android, Аврора, Windows, macOS l Реализует мобильные стратегии: BYOD, COPE, COBO Ориентировочная цена: по запросу Время появления на российском рынке: ноябрь 2020 г. Подробная информация: safe-phone.ru Фирма, предоставившая информацию: НИИ СОКБ См. стр. 9

Аккорд-АМДЗ (ТУ 26.20.40.140-079-37222406-2019)

Производитель: ОКБ САПР Сертификат: № 4299, выдан ФСТЭК России: СФ/527-3214, выдан ФСБ России Назначение: средство доверенной загрузки уровня платы разрешения, АПМДЗ класса 1Б Особенности: количество и тип идентификаторов, модификация контроллера и съемника оговариваются при поставке комплекса. Персональные идентификаторы и съемники информации заказываются отдельно Возможности: комплекс начинает работу сразу после выполнения кода системного BIOS компьютера – до загрузки операционной системы. Контроллеры семейства "Аккорд-АМДЗ" обеспечивают доверенную загрузку ОС, поддерживающих наиболее распространенные файловые системы, включая: FAT12, FAT16, FAT32, NTFS, HPFS, Ext2, Ext3, Ext4, ReiserFS, FreeBSD UFS/UFS2, Solaris UFS, QNX4, MINIX. Это, в частности, ОС семейств MS DOS, Windows, QNX, OS/2, UNIX, LINUX, BSD и др. Характеристики: Аккорд-АМДЗ (ТУ 26.20.40.140-079-37222406–2019) выпускается на базе контроллеров АккордGX, Аккорд-GXMH, Аккорд-GXM.2 Ориентировочная цена: 12 000 – 15 000 руб. Время появления на российском рынке: III квартал 2020 г. Подробная информация: www.okbsapr.ru/products/accord/accordamdz/ Фирма, предоставившая информацию: ОКБ САПР См. стр. 46

• 57

НОВЫЕ

ПРОДУКТЫ И УСЛУГИ

МЭ-TrusT

Производитель: ОКБ САПР Сертификат: № 4066, выдан ФСТЭК России Назначение: аппаратный межсетевой экран Особенности: реализован на базе специализированного компьютера с аппаратной защитой данных m-TrusT Возможности: l Возможность одновременной работы в режиме фильтрации сетевого трафика на уровне L2 в режиме коммутатора и на уровне L3 в режиме маршрутизатора l Фильтрация сетевого трафика по основным полям сетевого пакета l Фильтрация по доменным именам, по расписанию l Логирование правил фильтрации l Синхронизация правил фильтрации с другими устройствами l Возможность агрегации правил фильтрации в группы Характеристики: скорость МЭ – до 50 Мбит/с, порты 2xRJ45 GbE LAN, память до 2 Гбайт Ориентировочная цена: 42 000 руб. Время появления на российском рынке: 2020 г. Подробная информация: www.okbsapr.ru/products/newharvard/mtrust/METrusT/ Фирма, предоставившая информацию: ОКБ САПР См. стр. 46

Паспорт ПО

Производитель: ОКБ САПР Сертификат: не подлежит сертификации Назначение: инвентаризация и контроль версий ПО, установленного на рабочих местах пользователей

58 •

Особенности: позволяет выполнить требования, утвержденные приказами ФСТЭК России № 17 и 21 (АНЗ.2, АНЗ.4, ОЦЛ.1, ЗИС.18), а также № 239 (АУД.1, ОЦЛ.1, ОДТ.8, ОПО.2) Возможности: l Автоматически (или вручную, при необходимости) формируется список ПКО с разбивкой по подразделениям l Формируется общая база ПО, которое в принципе может быть допущено к установке и использованию в организации l Формируется общая база шаблонов – типовых конфигураций рабочих мест разных типов (это важно, если в основном рабочие места унифицированы по функциональности) l Шаблоны назначаются рабочим местам, будущим подконтрольным объектам (ПКО) l Формируются "паспорта" ПО на ПКО l Проводится сканирование (по регламенту или по запросу) и обработка его результатов l Полученный в результате сканирования новый "паспорт" сверяется "Паспортом ПО" с ранее утвержденным, и различия визуализируются l Решение по каждому рабочему месту – принять изменения и зафиксировать новый "паспорт" или эскалировать дальнейший разбор ситуации и принятие мер – принимает управляющий персонал Характеристики: в качестве ПКО могут выступать автоматизированные рабочие места и серверы под управлением ОС Windows Ориентировочная цена: зависит от состава системы Время появления на российском рынке: 2020 г. Подробная информация: www.okbsapr.ru/products/management/softwarepassport/ Фирма, предоставившая информацию: ОКБ САПР См. стр. 46

ESET Secure Authentication

Производитель: ESET Назначение: средство двухфакторной аутентификации, которое обеспечивает безопасный доступ к важной или конфиденциальной информации компании

Особенности: решение позволяет за 10 минут защитить подключение, что снижает риск утечки данных, обусловленный выбором ненадежных паролей Возможности: l Надежное и простое средство двухфакторной аутентификации l При каждом подключении формируется дополнительный временный пароль для предотвращения утечки конфиденциальных данных l Полностью программный продукт, нет необходимости в управлении аппаратными устройствами l Никаких дополнительных затрат, продукт легко интегрируется в существующую инфраструктуру l Идеальное решение для удаленных сотрудников l Мультиплатформенное решение на базе мобильных устройств l Безопасный доступ к ресурсам системы 1С Характеристики: Совместимость с операционными системами: l Сервер: Windows Server 2008/2008 R2/2012/2012 R2/2012 Essentials/2012 R2 Essentials/2016/2016 Essentials/2019/2019 Essentials и Windows Small Business Server 2008/2011 l Клиент: Windows 7/8/8.1/10 (включая обновление Fall Creators или Redstone 3) l Мобильные ОС: iOS 9 и выше, Android 4.1 и выше, Windows Phone 8.1 и выше Поддерживаемые веб-приложения: l Microsoft Exchange 2007 (Outlook Web Access – Exchange Client Access Server), 2010 (Outlook Web App – Exchange Mailbox Server Role, панель управления Exchange), 2013 (Outlook Web App – Exchange Mailbox Server Role, центр администрирования Exchange), 2016 (Outlook Web App – Exchange Mailbox Server Role, центр администрирования Exchange) l Microsoft Dynamics CRM 2011, 2013, 2015, 2016 l Microsoft SharePoint 2010, 2013, 2016 l Microsoft SharePoint Foundation 2010, 2013 l Веб-доступ к удаленному рабочему столу Microsoft l Веб-доступ к службам терминалов Microsoft l Удаленный веб-доступ Microsoft Ориентировочная цена: l на 5 узлов – 19 031 руб. l на 50 узлов – 99 083 руб. Время появления на российском рынке: доступно Подробная информация: www.esetnod32.ru/business/products/esa/ Фирма, предоставившая информацию: ESET См. стр. 25

www.itsec.ru

НОВЫЕ ПРОДУКТЫ И УСЛУГИ

Аналитическая платформа кибербезопасности R-Vision SENSE

Производитель: R-Vision Сертификат: не подлежит сертификации Назначение: аналитическая платформа кибербезопасности для детектирования нарушений в состоянии систем, выявления угроз и аномалий Особенности: l Объектно-центричный подход к мониторингу состояния безопасности l Динамическая скоринговая оценка угроз и аномалий l Технология адаптивной корреляции событий, требующая минимального участия со стороны пользователя l Многоуровневая система программных экспертов с возможностью тонкой настройки под специфические задачи Возможности: l R-Vision SENSE обеспечивает непрерывный мониторинг событий безопасности, анализируя данные из различных источников, включая системы логменеджмента, SIEM и др. Изучая поведение объектов, R-Vision SENSE формирует профили нормального поведения и фиксирует подозрительную активность в случае отклонений l Продвинутая аналитика собранных логов для снижения ложных срабатываний и выявления ранее не обнаруживаемых инцидентов l Непрерывный контроль и выявление изменений в состоянии безопасности, раннее предупреждение об угрозах l Выявление скрытых и неочевидных угроз, детектирование ранее неизвестных атак l Приоритизация угроз для реагирования, фокус на объектах с высоким рейтингом опасности l Анализ последовательности событий с помощью таймлайна для первичного понимания причин инцидента Характеристики: l Универсальный формат данных для анализа обеспечивает гибкость и адаптивность, независимо от источника данных l Продвинутые аналитические инструменты с использованием статистического и поведенческого анализа и методов машинного обучения l Оптимизация ресурсов при анализе за счет использования обработанных и структурированных данных на вход Ориентировочная цена: по запросу Время появления на российском рынке: октябрь 2020 г. Подробная информация: www.rvision.pro/sense Фирма, предоставившая информацию: R-Vision См. стр. 5

UserGate Log Analyser

Производитель: UserGate Назначение: продукт дополняет функциональность серверного решения UserGate и предназначен для агрегации данных, связанных с анализом инцидентов безопасности, а также для осуществления мониторинга событий и создания отчетов Особенности: UserGate Log Analyzer развертывается отдельно от шлюза безопасности UserGate, что позволяет обеспечивать высокую надежность и хорошую масштабируемость системы и агрегировать данные с нескольких серверов. Использование отдельного сервера для анализа данных снижает нагрузку на межсетевые экраны и позволяет обрабатывать больший объем данных Возможности: на основании полученных данных решение UserGate Log Analyzer осуществляет глубокий анализ произошедших событий безопасности, определяет и отслеживает подозрительные активности отдельных пользователей или хостов, что в том числе необходимо для соответствия современной концепции SOAR (Security Automation, Orchestration and Response) Характеристики: l Уменьшение нагрузки на шлюзы UserGate l Обработка журналов и создание отчетов l Объединение журналов с нескольких шлюзов для общего анализа l Увеличение глубины журналирования l Увеличение размера хранилища на серверах LogAn l Сбор и анализ информации со сторонних устройств Подробная информация: www.usergate.com/ru/products/usergate-logan-e, www.usergate.com/ru/products/usergatelogan-f Фирма, предоставившая информацию: UserGate См. стр. 48

Назначение: оркестрация инструментов и процессов DevOps, автоматизация развертывания релизов Особенности: l XebiaLabs предоставляет единую платформу для всех инструментов в вашем конвейере l встроенные средства интеграции с распространенными (250+) инструментами DevOps l простота и легкость развертывания, использования и масштабирования инфраструктуры выпуска ПО Возможности: l ускоренный выпуск релизов l оркестрация всех DevOps-инструментов и процессов, в том числе включая ручной режим l автоматизация и "самообслуживание" развертывания l обнаружение узких мест и предупреждение срыва сроков выпусков Характеристики: l самостоятельный быстрый запуск кода в тестовой и производственной среде l архитектура системы построена на основе Templates и Blueprints l гибкая настройка процессов l предназначен для средних и крупных компаний, которые управляют множеством релизов различных приложений в разных средах и инфраструктурах Время появления на российском рынке: февраль 2020 г. Подробная информация: xebialabs.com Фирма, предоставившая информацию: WEB CONTROL (официальный дистрибьютор в России) См. стр. 51

УСЛУГИ

"DLP как сервис" Отрасль: без ограничений Регион: РФ Описание: услуга по предотвращению утечки конфиденциальных сведений и выявлению других внутренних рисков в формате ежемесячной подписки; закупка специализированного ПО и аппаратных мощностей не требуется, все необходимое уже включено в стоимость Фирма, предоставившая информацию: ИНФОСЕКЬЮРИТИ См. стр. 29

Digital.ai (XebiaLabs DevOps Platform)

"Контроль сотрудников"

Производитель: XebiaLabs, Inc Сертификат: изделие не подлежит сертификации

Отрасль: без ограничений Регион: РФ Описание: услуга по оценке продуктивности, лояльности сотрудников и выявлению других внутренних рисков в формате ежемесячной подписки; закупка специализированного ПО и аппаратных мощностей не требуется, все необходимое уже включено в стоимость. Фирма, предоставившая информацию: ИНФОСЕКЬЮРИТИ См. стр. 29

• 59

НЬЮС МЕЙКЕРЫ

ГРУППА КОМПАНИЙ ANGARA

ОКБ САПР

POSITIVE TECHNOLOGIES

121096, Москва, ул. Василисы Кожиной, 1, к. 1, БЦ "Парк Победы" Тел.: +7 (495) 269-2606 E-mail: info@angaratech.ru www.angaratech.ru См. ст. "Группа компаний Angara стирает границы между коммерческим и корпоративным SOC" на cтр. 18

115114, Москва, 2-й Кожевнический пер., 12 Тел.: +7 (495) 994-7262 okbsapr@okbsapr.ru E-mail: www.okbsapr.ru См. ст. "Дубликатом бесценного груза: "Паспорт ПО" на cтр. 46–47

107061, Москва, Преображенская пл., 8 Тел.: +7 (495) 744-0144 E-mail: pt@ptsecurity.com www.ptsecurity.com/ru-ru/ См. ст. "Как перейти на безопасную разработку: история одного проекта" на cтр. 52–53

R-VISION

СПЛАЙН-ЦЕНТР, ЗАО

109544, Москва, бульвар Энтузиастов, 2 Тел.: +7 (499) 322-8040 E-mail: sales@rvision.pro www.rvision.pro См. стр. 5

105005, Москва, ул. Бауманская, 5, стр. 1 Тел.: +7 (495) 580-2555 E-mail: cons@debet.ru www.debet.ru, сплайн.рф См. стр. 7

USERGATE

ESET ИНФОСЕКЬЮРИТИ 107140, Москва, ул. Русаковская, 13, этаж/офис 10/10-01 Тел.: +7 (499) 677-1000 E-mail: iss@in4security.com www.in4security.com См. ст. "В сети обнаружен шифровальщик. Как планировать реагирование?" на cтр. 28–29

115280, Москва, ул. Ленинская слобода, 26, этаж 4, пом. XXXVII, ком. 29–68 Тел.: +7 (495) 803-3616 E-mail: partner@esetnod32.ru www.esetnod32.ru См. стр. 25

HUAWEI НИИ СОКБ 117246, Москва, Научный пр-д, 17 Тел.: +7 (495) 646-7563 E-mail: info@niisokb.ru www.niisokb.ru См. ст. "Кому нужны сертифицированные средства управления мобильностью" на стр. 9

121614, Россия, Москва, ул. Крылатская, 17, к. 2 Тел.: +7 (495) 234-0686 huawei.com См. ст. "Локализация технологий как инструмент эффективного импортозамещения" на cтр. 10–11

9–11 60 •

2021

630090, Новосибирск, Центр Информационных Технологий, Технопарк Академгородка, ул. Николаева, 11, 6 этаж Тел.: 8 (800) 500-4032, +7 (383) 286-2913 E-mail: sales@usergate.ru usergate.ru См. ст. "UserGate Management Center для управления парком межсетевых экранов" на cтр. 48–49

WEB CONTROL 107023, Москва, ул. Электрозаводская, 24 Тел.: +7 (495) 925-7794 E-mail: info@web-control.ru web-control.ru См. стр. 51

Реклама

ДИАЛОГНАУКА, АО 117105, Москва, ул. Нагатинская, 1 Тел.: +7 (495) 980-6776 E-mail: info@dialognauka.ru, marketing@dialognauka.ru www.dialognauka.ru См. стр. 19

Реклама

2021

Реклама

9–11