Осенью 2024 года в Москве прошла Третья межотраслевая конференция по регуляторике в сфере информационной безопасности, организованная Ассоциацией пользователей стандартов по информационной безопасности (АБИСС). Обсуждались актуальные вопросы организации процессов ИБ, безопасной разработки ПО, аудита ИБ и управления рисками.
В этом обзоре мы рассмотрим доклад Александра Моисеева, ведущего консультанта по информационной безопасности AKTIV.CONSULTING. Его выступление было посвящено практике внедрения процессов операционной надежности при взаимодействии с поставщиками услуг в финансовых организациях (далее – «ФО») по требованиям Банка России, детально изложенным в «Процессе 4» ГОСТ Р 57580.4. Александр рассказал о действующих законодательных требованиях, а также дал рекомендации интеграции их реализации в процессы ФО.
Цепочки поставок в финансовой отрасли
Ответим на вопрос: кто чаще всего выступает в роли подрядчиков по предоставлению ИТ-услуг для кредитных и некредитных финансовых организаций (далее – «КО» и «НФО» соответственно), и какие услуги они оказывают? Обычно это услуги облачных сервисов, ЦОД, техническое обслуживание ПАК и ПО, консалтинг, заказная разработка, а также предоставление специфичных финансовых сервисов, таких как процессинг, обслуживание банкоматов и предоставление информации – системы противодействия отмыванию доходов (ПОД/ФТ/ФРОМУ) или же готовые информационные системы (далее – «ИС») и приложения (к примеру, ДБО, АБС и т. д. ).
Интересно, что КО среднего размера традиционно более сдержанны в использовании облачных сервисов и вычислительных ресурсов ЦОД. Как правило, они используют их для хостинга некритичных информационных ресурсов вроде сайта или продуктовых лендингов или же для организации резервной ИТ-инфраструктуры, тестовых зон, развертывания решений Disaster Recovery и т. п. НФО же, наоборот, охотно используют арендуемые ресурсы и managed-сервисы для развертывания своих высоконагруженных приложений, т. к. зачастую основой их бизнес-модели является передача всей непрофильной деятельности поставщикам, а усилия внутренней команды сосредоточены на ключевых бизнес-функциях.
Эти и другие внешние сервисы и услуги образуют цепочки поставок, которые можно разделить на две категории: «Взаимодействие ИТ-инфраструктур» и «Взаимодействие программных компонент».
В первой цепочке происходит подключение к ИТ-инфраструктуре заказчика из инфраструктуры поставщика с целью обеспечения технической поддержки ИТ-решений и пользователей. Это может происходить посредством различных технологий, таких как: «site-to-site» или «remote access» VPN, всевозможных программ удаленного администрирования, различных видов интеграций ИС: API-шлюзов, файловых интеграций, шин данных, веб-сервисов и т.п).
При этом зачастую из-за стремления поставщиков снизить себестоимость работ, из-за повышения стоимости средств защиты информации (далее – «СЗИ») или из-за кадрового дефицита на рынке труда могут возникнуть следующие риски:
- «Низкий уровень зрелости ИБ». У поставщика услуг процессы ИБ могут быть значительно ниже, чем у заказчика (к примеру, нет оптимального состава СЗИ или же они не настроены должным образом). Соответственно, такой поставщик услуг становится легкой добычей и транзитной точкой для атакующего перед целевой атакой на ИТ-инфраструктуру заказчика.
- «Скрытый подряд». Подрядчик без ведома заказчика может привлекать сторонних, внештатных работников, работающих без каких-либо договоров и соглашений, а также выполнять подключение с домашних компьютеров, где, разумеется, нет никаких корпоративных политик безопасности и СЗИ. Даже если сам подрядчик обеспечивает защиту информации в периметре своей организации, такие сторонние работники им меньше контролируются. Они могут работать ещё с 5-10 такими же организациями и быть подключены к их сетям, что увеличивает вероятность реализации таких негативных сценариев, как распространение вирусного заражения, проведение компьютерных атак (далее – «КА») из недоверенных сетей и социальная инженерия.
- «Небезопасная» передача/хранение секретов. Всевозможная аутентификационная информация (пароли, токены, сертификаты) может передаваться от заказчика к подрядчику или внутри подрядчика в небезопасном виде. Это, в свою очередь, может привести к её утечке и дальнейшему её использованию злоумышленниками.
Вторая цепочка предполагает взаимодействие программных компонент различного происхождения и разной степени доверия к их надежности и безопасности. В современных корпоративных приложениях и ИС используются как программные модули собственной разработки, так и привнесенные в проект извне компоненты и зависимости: от внешних организаций, команд разработки или комьюнити «open source». Этот подход во многом оптимизирует и удешевляет разработку: не надо заново разрабатывать такие стандартные компоненты, как журналирование событий, аутентификация, брокеры сообщений, мониторинг и т. п. При таком подходе собственная команда разработки заказчика может сфокусироваться на реализации бизнес-функций или бизнес-логике, отдав при этом на подряд реализацию специфичной математики. Однако подход также несет в себе риски привнести в свой проект чужие уязвимости, недекларированные возможности (НДВ), вредоносные зависимости, политические банеры, раскрытие секретов в публичных репозиториях и т. п.
Действующие требования Банка России
За последний год к требованиям Положений Банка России №787-П и №779-П добавились требования Методических рекомендаций того же регулятора №7-МР, которые предписывают на протяжении нескольких лет осуществить внедрение требований ГОСТ Р 57580.4 по обеспечению операционной надежности, где рассматриваемому аспекту отдан целый раздел «Процесс 4. Взаимодействие с поставщиками услуг». Требования «Процесса 4» описывают меры по управлению различными рисками операционной надежности: рисками реализации информационных угроз и рисками технологической зависимости.
Вдобавок к существующим требованиям в техническом комитете №122 Банка России ведется разработка специализированного стандарта организационных и технических мер при аутсорсинге ИТ и использовании облачных услуг. Кроме того, существует огромное количество международных стандартов и фреймворков, которые можно использовать в качестве референсов, к примеру: ISO/IEC 27036, NIST SP 800-161, SCS 9001, NCSC Supply chain security, NIST SP 800-218 SSDF, BSIMM, IEC 62443, OWASP SAMM, PCI SSLC, CNCF Software Supply Chain Best Practices и т. п.
Меры по управлению рисками реализации информационных угроз направлены, по сути, на предотвращение вторжений и компьютерных атак на ИТ-инфраструктуру заказчика из ИТ-инфраструктуры поставщика. Тезисно данные требования можно описать следующим образом:
1. Организация защиты от компьютерных атак.
2. Меры по обеспечению безопасности цепочки поставок:
- оценка репутации и благонадежности поставщиков;
- обеспечение транспарентности и оценки уровня зрелости процессов поставщиков;
- проведение независимого аудита;
- оценка программ безопасности на этапах жизненного цикла объектов информационной инфраструктуры (далее – «ОИИ»), в т. ч. контроль отсутствия НДВ.
3. Обеспечение операционной надёжности технологических процессов, переданных на аутсорсинг:
- заключение соглашений о конфиденциальности и уровне сервиса (т. н. «NDA» и «SLA» соответственно);
- заблаговременная проработка альтернативных поставщиков и гарантий технической поддержки.
Меры по управлению рисками технологической зависимости направлены прежде всего на диверсификацию рисков между несколькими поставщиками. Формула проста и не теряет своей актуальности: «Не храним все яйца в одной корзине»:
1. Диверсификация риска по государственной (страновой) принадлежности.
2. Обеспечение гарантийной технической поддержки (далее – «ТП») на весь срок эксплуатации ОИИ (к примеру, т. н. уровень поддержки «next business day»).
3. Установление требований защиты информации (далее – «ЗИ») и операционной надежности (далее – «ОН») к приобретаемым ОИИ.
4. Выявление ОИИ с близким сроком завершения жизненного цикла (т. н. «end-of-life»).
5. Организация самостоятельной технической поддержки применяемых ОИИ.
6. Организация технического обслуживания (далее – «ТО») ОИИ прикладного и инфраструктурного уровней, а именно:
- регистрация всех событий безопасности при ТО;
- проведение ТО в соответствии с техническими требованиями;
- тестирование работоспособности ОИИ после завершения ТО.
7. Контроль удаленной ТП:
- применение многофакторной аутентификации (МФА);
- регистрация всех событий безопасности при ТП;
- гарантированное завершение сессий по завершении ТП;
- подключение через VPN с ОИИ с аналогичным уровнем защиты, что и у ОИИ заказчика.
8. Определение квалификационных требований к ТП.
Данная работа должна выстраиваться системно, начиная от установки требований по ЗИ и ОН в явном виде, требований к квалификации персонала, и заканчивая усиленным контролем за действиями конкретного инженера ТП поставщика, регистрацией всех событий безопасности, контролем за его действиями. Участвовать в данных процессах должны многие подразделения ФО, как основные структурные подразделения, так и специализированные (обеспечивающие экономическую безопасность и финансовый контроль).
Рекомендации по реализации требований «Процесса 4»
Разумеется, каждое требование можно реализовать десятком способов, исходя из имеющегося стека ИТ-технологий, кадровых и финансовых ресурсов. Мы же в данной статье ограничимся пятью рекомендациями, содержащими правовые, организационные и технические меры, которые по правилу Парето способны дать 80% результата.
Прежде всего необходимо создать правильные правовые основы для обмена конфиденциальной информации с поставщиком: перед взаимодействием, во время исполнения договорных обязательств и после их завершения. В хорошем соглашении о конфиденциальности (NDA) однозначно должны определяться четыре вещи:
- Перечень конфиденциальной информации для обмена, правила ее классификации и маркировки (в т.ч при отображении в интерфейсе ИС или отчуждении на носителях различного рода);
- Требование о трансляции персональных обязательств о соблюдении конфиденциальности на конкретных исполнителей, сотрудников поставщика. Необходимо выработать механизмы учета и актуализации этих обязательств;
- Порядок предоставления и прекращения доступа к конфиденциальной информации, а также его учета и аудируемости;
- Наличие удобных каналов обмена конфиденциальной информации. Это будет хорошей профилактикой появления различного рода «теневых ИТ», которые зачастую появляются по инициативе сотрудников самого заказчика при недостаточном контроле или форс-мажорных обстоятельствах по проектам.
Говоря о содержимом соглашений об уровне сервиса с поставщиками (т. н. «SLA»), лучше вспомнить об опроснике Банка России, который не так давно был направлен в поднадзорные организации. Можно выделить ряд аспектов, на которых делает акцент регулятор:
- Предоставление доступов и осуществление обработки конфиденциальной информации, как охраняемой законом, так и являющейся коммерческой тайной самой ФО, в т. ч. описание механизмов ее гарантированного удаления.
- Проработка «Стратегии разрыва отношений», т. е. определение процедуры выхода из договорных отношений с поставщиком: по обоюдному решению, в одностороннем порядке по инициативе поставщика или в одностороннем порядке по инициативе заказчика, а, возможно, и из-за каких-либо недопустимых инцидентов ЗИ и ОН. Также важно заранее продумать то, как ФО будет отключаться от сервиса, заменять программные компоненты или переключаться на другого поставщика, перемещать оборудование, за какую временную дельту эти процессы будут завершены.
- Закрепление обязательств поставщика об уведомлении заказчика о привлечении к работам субподрядчиков, т. е. третьей стороны во взаимоотношениях, и, соответственно, транслирование им всех требований и обязательств.
- Закрепление обязательств поставщика о привлечении к надзорным мероприятиям регуляторов (Банк России, РКН, ФСТЭК и ФСБ России), предоставлении им свидетельств по процессам, взаимодействии при реагировании и расследовании инцидентов ЗИ и ОН (к примеру, передача дампов данных из системы источника).
- Регламентация правил удаленного подключения и формирование перечня ресурсов удаленного доступа.
Дополнительно рекомендуем проверить в SLA наличие: глоссария, описания сервисов, параметров сервисов, порядка обращений и эскалации. Это позволит лишний раз убедиться, что все стороны однозначно трактуют параметры SLA, и тем самым повышается обозначенная транспарентность. Нелишним будет также наличие «антикоррупционной оговорки», которая позволит митигировать репутационные риски от внутреннего фрода, аффилированности, недобросовестной конкуренции и т. п.
Заказчик имеет возможность предъявлять к сервисам широкий спектр требований, причем даже небольшие КО и НФО могут предъявлять специфические требования. К примеру, при выборе поставщиков перед рассмотрением ТКП можно требовать оформлять т. н. «security appendix», т. е. концептуальное описание мер и процессов безопасности, функционирующих у поставщика.
Теперь перейдем к организационным мерам, а именно к процессу выбора поставщика. Он, как правило, разделен на две фазы: «предконтроль», на которой формируется шорт-лист финалистов, и «постконтроль», когда по мере движения к завершению договора отслеживается состояние поставщика.
Проверки, которые можно применить на фазе предконтроля:
- На самых ранних этапах должна быть выполнена т. н. проверка на «должную осмотрительность». Это хорошо знакомая по требованиям ФНС проверка финансового состояния компании. Она выполняется как по данным специализированных сервисов проверок контрагентов, так и при запросе комплекта документации и аудиторской отчетности. В ходе этой проверки можно понять, какие у контрагента обороты; соответствуют ли они «истории успеха», которую он транслирует рынку; нет ли риска кассового разрыва; какова среднесписочная численность персонала; нет ли аномальных финансовых показателей и т. п. Выполняют ее, как правило, финансово-экономические подразделения.
- Далее рекомендуем обратить внимание на историю арбитражей, особенно на те, где поставщик был ответчиком по ненадлежащему исполнению обязательств. Эти данные, как правило, проверяются юридическими службами.
Описанные шаги будут хорошим базовым минимумом для данной фазы. Далее, по мере отбора поставщиков, могут быть добавлены следующие дополнительные проверки:
- Анализ истории изменений в юридическом лице: кем были учредители, кто владельцы сейчас, как распределяются доли, какие управляющие органы, как часто меняются и т. д. Тут обычно действуют уже подразделения экономической безопасности.
- При необходимости можно подключать специалистов по ИБ, которые методами OSINT и конкурентной разведки смогут поискать упоминание подрядчика в СМИ, осуществить поиск по выдаче поисковых систем с новостями об инцидентах, партнерстве, успехах и неудачах.
- Также на данном этапе могут подключаться команды ИТ и бизнеса для проведения пресейл-встреч, во время которых важно выяснить опыт, компетенцию исполнителей контрагента, обсудить кейсы и даже в игровой форме проговорить, как бы они реагировали на нештатные ситуации и инциденты, как бы взаимодействовали с заказчиком. Это, на самом деле, и есть та самая транспарентность, при которой, общаясь с командой ИТ поставщика, узнавая об их процессах и практиках, можно сделать выводы об обеспечении надежности и безопасности. Особенно важно понимать, как у поставщика устроены процессы администрирования, управления изменениями и конфигурацией, управление уязвимостями, как осуществляется мониторинг ИТ-инфраструктуры и т. п.
По сути, если на фазе «предконтроля» вы проверяете гипотезу «способен ли выполнить обязательства контрагент в принципе», то на фазе «постконтроля» проверяется гипотеза «не произошли ли у контрагента такие изменения, которые ставят под угрозу выполнение обязательств перед нами». То есть фактически осуществляется мониторинг сообщений об изменениях у контрагента в специализированных информационных системах проверки контрагентов, оценка рисков и, при необходимости, реагирование.
Далее, ещё одним важным аспектом является управление требованиями. Это краеугольный камень многих процессов, и в стандарте TOGAF по управлению корпоративной архитектурой, упоминаемом в ГОСТ 57580.4, он занимает центральное место. Подавляющее большинство неудач, инцидентов и потерь бизнеса связано как раз с недостатками в данном процессе.
Существуют отечественные и зарубежные стандарты по управлению требованиями, в их основе лежит одна простая идея – разделение бизнес-требований на «первичные», понятные и простые потребности, и преобразование их в «проектные» требования, понятные ИТ-специалистам. К привычным ролям «администратора ИБ» и «администратора ИТ» настоятельно рекомендуем добавлять роль «бизнес- администратора» ИС. Соответственно, требования валидируются (происходит оценка, покрывают ли они все потребности) и верифицируются (происходит проверка, качественно ли разработаны и сформулированы сами требования). Также происходит и с итоговыми ИТ-системами и ОИИ. Ведение записей по процессам управления требованиями осуществляется в различных ИС, с присвоением атрибутивной информации о статусах жизненного цикла. Быстрая адаптация требований под конкретную ситуацию: финансовую, технологическую и т. п. способствует формированию палитры вариантов архитектур ИС.
И последнее, о чем стоит упомянуть, это технические меры «укрепления защищенности» ОИИ. К ним можно отнести, прежде всего, базовую ИТ- и ИБ- гигиену. Она достигается зачастую не столько вендорскими решениями, сколько хорошим пониманием собственной ИТ-инфраструктуры: какое состояние системы изначально задумано (спроектировано), какие порты должны быть открыты, какие сервисы на них работают, какие процессы их запускают, какие интерфейсы имеются. Далее регулярно средствами ИТ-мониторинга собирается актуальная статистика, контролируется целостность этих данных, осуществляется их профилирование. И в дальнейшем уже можно какими-либо средствами автоматизации сравнивать эти данные с текущей картиной в системе, с данными со средств инвентаризации или сканеров, выявлять аномалии и несанкционированые изменения.
Далее уже можно проводить «харденинг», зная, как он повлияет на работоспособность и надежность системы. К данным мероприятиям можно отнести укрепление УЗ и доступов, ужесточение сетевых политик, журналирование событий безопасности и т. п. Сюда же следует отнести «управление поверхностью атаки», когда мы производим тираж уязвимостей, и, конечно, «реагирование». Важно постоянно проводить тренинги по реагированию и улучшать эти процессы по результатам. Кроме того, важно заблаговременно готовить многие рабочие процедуры и мероприятия реагирования. К примеру, в организации следует заблаговременно подготовить детальные описания процедур съема дампов оперативной памяти и изменений файловой системы, дампов траффика, политики изоляции атакующего – блокировку средствами СЗИ или добавлением в обособленный VLAN, отключением порта коммутатора и т. д.
Также важно учитывать различия в степени зрелости процессов ИБ: от поставщика к поставщику она может быть у кого-то «фрагментарной», а у кого-то иметь хороший базовый набор СЗИ (АВЗ, UTM/NGFW, сканер, СЗИ от НСД), но со стандартными настройками. А у кого-то зрелость позволяет расти ИБ как в ширину за счет количества СЗИ (TI, EDR, Sandbox, WAF), так и в глубину (написание своих правил, политик, детектов).
Заключение
Подводя итог всему вышесказанному, хочется еще раз подчеркнуть ключевые мысли, отраженные в данной статье:
- С публикацией рекомендаций Банка России №7-МР внедрение ГОСТ Р 57580.4 становится все ближе.
- Процессы операционной надежности охватывают многие подразделения ФО, не только ИТ или ИБ.
- Проверки поставщиков должны быть не разовыми акциями, а предполагать систематический процесс, схожий с мониторингом.
- Системное выстраивание в ФО процесса управления требованиями даст на дистанции ощутимый эффект по многим направлениям деятельности.