Анастасия Харыбина (AKTIV.CONSULTING) провела очередной выпуск подкаста «Безопасный выход». «Зачем управлять рисками ИБ? Как это делать эффективно? Какие методики использовать?» — гость студии Александр Кондратенко, заместитель директора департамента информационной безопасности, руководитель управления рисков и процессов ИБ и Agile-команды Росбанка обсудил с ней эти и некоторые другие актуальные вопросы.
Анастасия Харыбина (далее Анастасия): Александр возглавляет в Росбанке Agile-команды. Верно?
Александр Кондратенко (далее Александр): Точнее, одну комплексную Agile-команду, состоящую из двух частей, возможно, единственную в России со специализацией в сфере ИБ, в такой конфигурации. Так что я очень горд званием product owner, service owner этой Agile-команды. Помимо этого, в моем ведении есть отдельное подразделение — Управление информационной безопасности, рисков развития процессов информационной безопасности.
Зачем управлять ИБ-рисками?
Анастасия: Тема нашего выпуска подкаста — это управление рисками информационной безопасности. Убеждена, пока руководители организаций и ИБ-специалисты не ответят на этот вопрос, постановкой процессов анализа рисков заниматься не стоит. Предлагаю проговорить, что такое риски информационной безопасности и каковы их границы? Определений много, и они разные. Кто-то относит к рискам ИБ киберриски, кто-то убежден, что это не так. Есть мнение, что риски ИТ втянули в свою орбиту ИБ-риски и что к ним нужно приплюсовать риски операционной надежности. Что ты включаешь в периметр рисков информационной безопасности?
Александр: Хороший вопрос. Оценка рисков — это базовый подход в менеджменте. Существует огромное количество рисков, который необходимо анализировать. Профильные руководители сталкиваются с управлением рисками информационной безопасности сразу же, как только занимают эту должность и начинают взаимодействовать со своим топ-менеджером. А с позиций рисков ИБ для организации они взаимодействуют со всем банком.
Тут все зависит от того, выделено ли управление рисками в организации в самостоятельное направление, доросла ли она до риск-ориентированного подхода, выстроила ли модель работы с учетом рисков.
Базой являются операционные риски. Это набор факторов, воздействие которых может привести к проблемам в операционной деятельности. Их можно поделить на несколько направлений, риски информационной безопасности одно из них.
Анастасия: Риски информационной безопасности — это подсегмент операционных рисков?
Александр: По большому счету, да. Есть ещё ИТ-риски, они тоже относятся к операционным. Есть еще другие риски, специфические для каждой отрасли. К примеру, в банках — это кредитные риски.
А поскольку операционные риски нужно учитывать всем, рисками ИБ необходимо управлять всем организация, бизнес-процессы которых базируются на ИТ-решениях. Исключение составляет только очень небольшое количество компаний, которые преимущественно работают без ИT-инструментов.
Не только руководители служб ИБ занимаются рисками. Обычные инженеры, к которым каждый день обращаются, к примеру, с заявками на доступ в корпоративные информационные системы, выполняют их с учетом рисков — взвешивают разные варианты наступления негативных последствий, но это не системная работа.
А когда в организации появляется потребность систематизации именно рисков информационной безопасности, тогда и возникает потребность выделить их и структурировать для того, чтобы корректно доносить до руководства организации.
Анастасия: То есть, исходя из сказанного тобой, постановка процессов мониторинга рисков ИБ, их анализа и управления ими — это инициатива CISO, Chief Information Security Officer?
Александр: Потребность в корректном и более серьезном анализе таких рисков идет именно от CISO, потому что намного проще взять базовые подходы к операционным рискам, проводить их экспертный анализ и предоставлять информацию уже в подразделение, которое ими ведает. Но иногда выгоднее для функции ИБ делать это системно и более качественно на силами CISO уровне компании.
Анастасия: А зачем подразделению ИБ управлять рисками?
Александр: Для обеспечения информационной безопасности организации, в первую очередь. А во вторую — оценка рисков ИБ помогает CISO определиться, как решать эту задачу, какие подходы, методы, решения для этого использовать, на чем фокусировать усилия команды и ресурсы.
Анастасия: Получается, основная задача управления рисками информационной безопасности — это выполнение функций ИБ? Тут я с тобой, наверное, не соглашусь. По большому счету, риски-то оцениваются самой организации? Как-то хочется верить, что топ-менеджменту важно учитывать риски информационной безопасности, потому в деятельности организации лежат высокотехнологичные цифровые процессы, остановка которых угрожает операционной надежности.
Александр: Действительно, руководству важен результат, но главное — ему нужно принимать решения, взвешенные и оптимальные. И руководитель департамента информационной безопасности — это человек, который готовит варианты решения, с учетом рисков. При этом самому CISO анализ рисков ИБ помогает еще и выстроить продажи отдельных сервисов информационной безопасности другим подразделениям компании.
В общем, в топ-менеджмент руководитель службы ИБ обращается при необходимости обсуждать вопросы финансирования. В этом случае учет рисков необходим, также очень полезен будет ИТ-инструмент, который помогает и в приоритизации задач в сфере ИБ, и для обоснования запросов на выделение дополнительного финансирования для защиты особо высокорисковых направлений. Тогда действия CISO по оценке рисков ИБ будут максимально эффективны. А топ-менеджеры решат, как им поступить: либо принять риски и продолжить двигаться в выбранном направлении, либо, оценив их как серьезные, изменить его.
Если задача топ-менеджера — принять решение, изучив отчеты по рискам, то те, кто их готовит, должны погружаться в процесс глубже и развивать это направление. Итак, работа с рисками необходима службе внутренней информационной безопасности точно так же, как оценка ИТ-рисков необходима директору по ИТ. Это, в общем-то, очень схожая история.
Бизнес в свою очередь должен ответить на вопрос, как использовать результаты рискового анализа для реализации стратегии или для решения отдельных точечных проблем.
Как эффективно управлять ИБ-рисками?
Анастасия: Предлагаю обсудить, как выстроить процессы управления ИБ-рисками. Должны ли быть в подразделении риск-менеджмента компетенция по информационной безопасности или в службе ИБ компетенции по рискам? Как построить эффективное взаимодействие с другими подразделениями?
Александр: Я убежден, что у функции по информационной безопасности потребность в качественной оценке рисков есть. Этот процесс очень выгоден, как для нее, так и для всей компании, поэтому мы старались сформировать все эти компетенции внутри службы информационной безопасности, привнести в нее знание рисков.
А дальше развивали эти компетенции, строили их матрицу, старались заполнить в ней пробелы. Широта знаний очень важна в сфере ИТ, поэтому каждому сотруднику, который занимается риск-анализом, мы давали возможность приобрести недостающие компетенции, даже проводили отдельные внутренние тестирования. А наши ИБ-специалисты приобрели знания подходов в риск-менеджменте, в области операционных рисков и рисков ИТ.
Анастасия: А как выстроить взаимодействие с подразделениями, чьи процессы попадают в выборку оценки рисков?
Александр: Это не такая сложная задача. Как только у людей появляются знания подходов к оценке рисков, они начинают разговаривать как члены одной команды, понимать друг друга. По крайней мере у нас не было никакой сложности дальше интегрироваться с функцией управления операционными рисками и с другими подразделениями.
Есть еще одна область, которую мы рассматриваем отдельно и которую пришлось дополнительно развивать, — это компетенции бизнес-направлений, на периметре которых анализируются риски. Речь идет о рисках, возникающих в системах, автоматизирующих процессы, например, в ипотеке. Ипотечный мир специфический. Он сильно отличается от мира автокредитования. Кредитование, кредитные карты — это третий продукт, там другие подходы и другие риски. Более того, стандартные киберриски в разных продуктовых направлениях схожи по сценарию, но отличаются по способу реализации. Системы, которые используются подразделениями, и то, как их сотрудники с ними работают, тоже разные.
Руководители каждого из этих продуктовых направлений должны уметь грамотно и корректно анализировать риски. Для этого мы проводим бизнес-встречи и показываем им, на что надо обращать внимание при оценке рисков ИБ в продукте. А поскольку мы должны прекрасно знать, как работают продукты, в матрицу компетенций были добавлены знания продукта каждого бизнес-направления, обязательные для рисковиков. Как только все компетенции собираются хотя бы на верхнем уровне, проблем в коммуникациях не возникает.
Анастасия: А если на нулевой этап посмотрим, исходя из парадигмы, о которой ты говорил? Очевидно же, что сотрудники департамента ИБ не будут только свои процессы анализировать, им нужны бизнес-подразделения, их бизнес-процессы, наложенные на процессы технологические. Значит, бизнесу нужно включиться в процесс управления рисками ИБ, но у него изначально нет в этом потребности. И когда к ним обращаются из департамента ИБ с просьбой выделить ресурсы для изучения их бизнес- и технологических процессов, они отвечают: а нам ничего такого не надо. Как обосновать на этом этапе важность анализа рисков ИБ?
Александр: Ответ очень простой. Компания не статична, она развивается, и каждая ее функция тоже. Если вы начали заниматься управлением рисками ИБ «с нуля», у вас ничего еще не выстроено, но есть задача построить риск-ориентированные подходы, то сначала нужно найти способы анализа собранных рисков, понять, как доносить его результаты до руководства и так далее. Потом искать единомышленников в других поддерживающих подразделениях, думать, чем управление рисками ИБ может быть полезно другим направлениям компании. И только тогда идти к бизнесу.
Мы сами еще пять лет назад были довольно обособленными, но постепенно начали встраиваться в изменения банка, в его проектные направления. Приходили к прожект-менеджерам в организации, обсуждали стандарты, подходы к управлению проектом, сценарии, в которых необходимо анализировать риски ИБ, разбирали, где имеет смысл на них смотреть. Если результат нашего анализа понятен, то коллеги воспринимают его с радостью.
Потом приходим в подразделение, которое занимается операционными рисками. Они тоже регулярно риски анализируют и бизнес-подразделения опрашивают. И с ними можно договориться о сотрудничестве для того, чтобы реализовать потребности функции информационной безопасности.
Такие же договоренности достигаются при запуске нового продукта или модернизации старого: продуктовым подразделениям предлагается опираться в своей работе на результаты анализа разных рисков, включая риски ИБ.
С таким подходом встраиваться в работу бизнес-подразделений легко. Вопрос только в качестве такого анализа рисков и возможности функции ИБ его поддерживать. Ведь анализ деятельности всего банка с точки зрения рисков — очень объемная задача, для решения которой нужны люди и время.
Анастасия: Правильно я понимаю, что отсутствие выстроенного сверху риск-ориентированного подхода не означает, что подразделению ИБ не нужно начинать создавать систему управления рисками информационной безопасности и пытаться распространить свои компетенции в этой области на всю организацию?
Александр: Конечно. Более того, можно привнести анализ ИБ-рисков даже туда, где вообще никакие риски не учитывают. Например, прожект-менеджеры спокойно управляют проектами, не имея реестра рисков, которые в этих проектах возникают. Предложите им создать такой реестр — они с радостью согласятся. Сначала там будут только риски ИБ, но потом войдут во вкус и начнут обращать внимание на айтишные риски, на другие риски.
Важно, чтобы было понимание, зачем вам это нужно. Если оно есть, надо так выстроить систему управления рисками, чтобы за рисками что-то было: сами по себе они не нужны. Можно проанализировать риски, увидеть определенный сценарий атаки, кстати, один из миллиона возможных, погрузиться в его детали, а затем представить его руководству.
А топ-менеджмент должен принять решение, что с этим риском делать, какие инвестиции необходимы для смягчения его последствий? Причем, вариантов ответа на этот вопрос может быть несколько, в том числе и позволяющий свести затраты практически к минимуму. Можно оставить риски на среднем уровне и не вкладывать в его снижение много средств, а можно их принять и вообще не инвестировать в смягчение последствий. И когда выявление и анализ рисков ведут к решению вопроса о финансировании, получается вполне понятная конструкция.
Анастасия: По большому счету, имеет смысл этим заниматься только если функция ИБ готова выдвигать предложения? У нас, к сожалению, не все хотят брать на себя ответственность и предоставлять несколько вариантов решения проблемы. А без аналитической работы, на основе которой оформляются предложения, заниматься рисками, в том числе информационной безопасности, наверное, нет никакого смысла.
Александр: Надо понимать, что риск-анализ проводится в два этапа. По итогам первого готовится отчет для менеджмента, в котором описывается риск и предлагается несколько способов его снижения. А на втором, ты приходишь к одному прожект-менеджеру и на очень интересных моделях показываешь детально проработанный риск ИБ. Он его оценивает, делает какую-то калькуляцию, чтобы ты мог количественно оценить. Но, зачастую, после этого в ходе проекта ничего не меняется. И тут возникает вопрос: какой смысл выполнять анализ, моделировать риск, если это ни на что не влияет?
Важно, чтобы рассмотрение ваших моделей вело к изменениям в организации, в этом ценность анализа рисков. И увидев ее, в следующий раз прожект-менеджер сам придет и спросит о том, какие есть риски, чтобы при необходимости поменять дорожную карту проекта. Если риск-анализ привносит ценность для команд, для проектов и их спонсоров и, в целом, для организации, то они сами начнут его запрашивать.
Методики работы с ИБ-рисками
Анастасия: А теперь предлагаю поподробнее поговорить о методиках управления рисками. Есть разные фреймворки, международные и предложенные кредитно-финансовым организациям Банком России. Насколько они универсальны, применимы в наших условиях и кому подходят?
Александр: Вначале, когда система управления рисками только выстраивается, надо выбрать базу — какую-то методологию, предварительно опробованную. При этом допустимо «скрестить» несколько подходов, ознакомиться с разными и что-то из каждого использовать.
Эта база помогает в дискуссиях, при демонстрации рисков, чтобы ты и прожект-менеджер, которому ты какие-то ИБ-риски в проект несешь, знали одни и те же подходы и общую терминологию. Это лучше получается при использовании международных стандартных подходов. Но каждая компания и даже каждая команда внутри компании будет проводить анализ риска по-своему, так что иметь вначале общий подход хорошо, а позже этот подход всегда меняется.
Анастасия: Получается, что основной вопрос в выборе методик и в управлении рисками, в частности, информационной безопасности, — это как анализировать риск?
Александр: Не только. В стандартах есть терминология, базы с прямым описанием этапов работы с рисками, шаблоны риск-анализа. Все это можно взять и изучить. Но я не рекомендую брать какой-то стандарт целиком и полностью погружаться в его детали: риск-анализ — это большая история, и в ней закопаться очень глубоко.
Представьте себе, вы сделали глубокий анализ, построили модель, собрали инциденты и на базе них построили расчет. Из операционных рисков взяли информацию об активах и о возможных ущербах — словом, сделали классную аналитику. Но есть второй шаг: нужно показать ее топ-менеджменту, и на это у вас есть 5 минут с учетом дискуссии о деньгах, о том, как минимизировать и устранить риски. (По нашему опыту, она может занять 3-4 минуты). Получается, на само изложение результатов риск-анализа остается очень мало времени. Вот почему мы рекомендуем начинать с базовых конструкций, концепций и подходов, понятных всем стейкхолдерам риск-анализа.
Мы для себя тоже детализируем сценарии не сразу. Для принятия основных решений по финансированию или минимизации тех или иных рисков нужна одна глубина анализа этого сценария, на следующих этапах необходимо вникнуть в него поглубже, при реализации каких-то конкретных задач для внесения настроек в системы защиты нужна еще более детальная проработка. Так что риск-анализ одного и того же сценария ведется нами постоянно.
Анастасия: Анализ рисков включает в себя оценку вероятности их реализации. И одна из самых больших проблем, как говорят, заключается в необходимости накопления большого массива статистических данных. А поскольку мы, специалисты, работающие в сфере ИБ, склонны скрывать все серьезные происшествия, связанные с информационной безопасностью, таких массивов данных по различным видам инцидентов, атакам и другим событиям ИБ не так много. Получается, что организация ограничена только своим опытом и не видят опыт коллег по рынку.
Александр: Не соглашусь, хотя это действительно один из основных сдерживающих риск-анализ факторов, и, кстати, не только ИБ, это в ИТ-риск-анализе, в операционных рисках, в том числе. С одной стороны, организации не хватает собственных данных и опыта, особенно, если учесть, что события не всегда сохраняются должным образом: классифицируются, обогащаются. Бывает, что у компании вообще нет детализации собственных событий, и ей довольно сложно использовать в анализе только свою базу инцидентов.
С другой стороны, на рынке ИБ исследовательскими компаниями регулярно выпускается множество аналитических отчетов. Даже если и мы, и другие компании стараются максимально завуалировать данные об инцидентах, в профессиональном сообществе информация о них ходит. Так или иначе собрать базу внешних историй возможно. В операционных рисках это вообще очень принятая история. Единственное, что это трудозатратно, но мы у себя поставили процесс обогащения базы событий внешними инцидентами.
Раньше можно было пользоваться аналитикой по ИБ со всего мира, сейчас, это в основном отечественные отчеты. С другой стороны, в России сейчас сфере кибербезопасности очень активно развивается. К тому же, представители банковской сферы могут получать информацию и аналитику через ФинЦЕРТ. Я думаю, что со временем в России появится какое-то промышленное решение, собирающее информацию про инциденты, на западе такие аналоги есть.
Анастасия: Как сервис?
Александр: Как сервис. У нас пока каждая крупная компания пытается обогащать свои базы инцидентов самостоятельно. В большинстве случаев, когда вы анализируете сценарий, вы пытаетесь предотвратить событие кибербезопасности, которое уже случилось у других. В ваших интересах обогащать свои системы опытом коллег по рынку. У нас такая практика внедрена.
Автоматизация управления ИБ-рисками
Анастасия: Предлагаю поподробнее поговорить о таких амбициозных проектах, как разработка и внедрение системы SGRC (Security, Governance, Risk, Complience), автоматизирующей построение комплексной системы управления ИБ. Ни для кого не секрет, что Росбанк очень далеко продвинулся в разработке собственного решения этого класса. Но начать я хотела бы с определения SGRC-систем и с того, чем она отличается от систем GRC. Есть мнение, что SGRC — это GRC, дополненная функцией безопасности. Так ли это? Или GRC-система верхнеуровневая, а SGRC — это отдельные модули, частный случай.
Александр: Да, если брать терминологию, то GRC — governance, risk и compliance — три основные блока в кредитных организациях, их основные направления. При этом governance — это автоматизация различных процессов в организациях и управление этими процессами. А модули рисков и модули комплайенсов могут использоваться в комбинации.
Так что GRC — это универсальная система, применимая в информационной безопасности. Просто игроки российского рынка ИБ делали специализированную фокусную историю и добавили в название решения слово Security и, соответственно, в аббревиатуру букву S. Постепенно термин «Security governance risk compliance» был признан и принят рынком.
Хотя по мере развития такие системы, с проработанными модулями безопасности, трансформировались в IRP-системы (Incident Response Platform), предназначенные для автоматизации реагирования на киберинциденты, работы с ними, или в SOAR (Security Orchestration, Automation and Response), выполняющие функцию автоматизации координации действий нескольких специалистов по кибербезопасности.
При этом по конструкции SGRC- и GRC-системы схожи. Просто первые больше «заточены» под конкретное направление безопасности. Но при их внедрении важно использовать услуги консалтинга для ее адаптации к процессам и задачам вашей компании, а также опираться на опыт других компаний. Чем более точечно вы определите место конкретного модуля системы в корпоративной ИБ-инфраструктуре, тем более успешным будет его внедрение, поэтому сейчас на рынке SGRC-систем узко направленное позиционирование.
А систему GRC спокойно могут использовать аудиторы с функцией внутреннего контроля, которые занимаются в принципе аудитом всей организации. Там и риски необходимо анализировать, связанные с аудитом, и проводить различные контроли соблюдения требований, и все это автоматизируется с помощью GRC.
Для автоматизации управления операционными рисками ведется реестр их событий. Такая система должна отражать эти операционные риски, классифицировать их. В банковской сфере, к примеру, множество требований: как и что собирать, строить, классифицировать, отчитываться. И эти задачи де-факто тоже решает GRC-система. Иными словами, по функционалу GRC — намного шире, чем информационная безопасность.
Анастасия: Бытует такое мнение, что системы SGRC со временем вытеснят и заменят ECM и SOC. Я даже вижу ее в роли грендайзера, собравшего все лучшее из того, что есть у систем других классов. А ты что об этом думаешь?
Александр: Мне кажется, так не получится. В Росбанке GRC-система пришла на смену SGRC. Мы уже автоматизируем процессы внутреннего аудита — разработали необходимые для этого программные модули. Эта система используется теперь для нескольких заказчиков в компании. И это, помимо решения ИБ-задач. А сейчас мы изучаем возможность сделать в этой системе модули для других контрольных процессов. По сути, нам требуется набор контролей и направление инвестиционно-банковских услуг, CМIB. Такая работа тоже ведется. По большому счету мы уже переросли GRC-истории.
Анастасия: Это тот уникальный случай, который наглядно подтверждает пользу функции информационной безопасности?
Александр: Это результаты работы Agile-команды, которая изначально ориентировалась на разработку функционала для всех внутренних заказчиков. Сначала, когда мы изучали возможность создания такого всеобъемлющего инструмента, куда можно все риски занести и планировали создавать его силами нашей команды с нуля. Но при ближайшем рассмотрении выяснилось, что на это уйдет очень много ресурсов, и что взять хорошо проработанный модуль от вендора будет дешевле и проще.
Анастасия: А тогда вопрос, когда вы начинали делать свою SGRC-систему, вы не обращались к вендорским решениям?
Александр: Обращались. Попробовали очень много разных продуктов и убедились в том, что на российском рынке есть достойные решения, которые нужно адаптировать под себя.
Анастасия: И что пошло не так?
Александр: Какое-то время мы пользовались вендорским решением, а когда порог по производительности был пройден, решили дальше развивать эту систему сами. У нас, во-первых, более сложные процессы, а во-вторых, собственную разработку можно будет экстраполировать на другие подразделения. К тому же были определенные ожидания от автоматизации, в том числе и того, что она должна появиться в нескольких системах. У нас больше десятка интеграций, и внедрение обновленного решения должно было произойти по всему банку. С учетом этих требований адаптированное к нашим особенностям вендорское решение становилось очень дорогим и невыгодным. Так что мы вынуждены были использовать внутреннюю разработку.
Зрелость вопросов управления рисками ИБ
Анастасия: Ну, и предлагаю поговорить о зрелости процессов управления рисками информационной безопасности. У меня есть ощущение, что за последние несколько лет эта тема немножко пересобралась. Понятно, что крупные организации не останавливались в развитии этого направления. Но если шире посмотреть на то, что происходит на рынке и внутри самих организаций, возникает ощущение, что интерес со стороны всех компаний возобновлен. Как думаешь, почему сейчас?
Александр: Это очень просто: сами риски, в целом, выросли и стали более значимыми. Увеличилось количество инцидентов, причем в разных отраслях. Та же самая кибервойна, которая идет сейчас, этому способствует. Об инцидентах кибербезопасности мы слышим, о них пишут СМИ, и, как результат, у компаний сложилось понимание, что рисками ИБ надо заниматься.
С другой стороны, несмотря на уход западных поставщиков, на рынке сейчас огромное количество компаний-разработчиков, много специализированных технологий, которые можно задействовать для минимизации таких рисков. Решений много, они дороги, и внедрить их все в одной компании невозможно.
А с третьей стороны, риски объективно есть. Это не что-то из области фантастики, это реальность. Есть конкретные инциденты. И даже если вы на бумаге не проанализировали риски глубоко, не сделали серьезную аналитику, не использовали модели, руководство примерно поймет, о каком риске вы говорите. А если вы будете еще и те же самые термины использовать, то вы с менеджментом будете говорить на одном языке. И вы вместе сможете обсудить, какие риски анализировать, что можно сделать, а что не делать.
В общем, драйвер возобновления интереса к управлению рисками ИБ – текущая ситуация.
Анастасия: Финансовая отрасль намного оторвалась от других отраслей в вопросах управления рисками ИБ?
Александр: Изначально именно финансовая отрасль привлекала злоумышленников больше всего, которые стремились похитить деньги там, где они хранятся. Долгое время удачная кибератака на финансовую организацию позволяла заработать больше всего. Так что, в принципе, уровень рисков ИБ в этой отрасли был несоизмерим с другими.
А сейчас у атакующих появились новые сценарии. Они связаны не с хищением денег, а с реализацией других негативных событий. К примеру, можно парализовать работу сайта компании или вывести из строя те или иные ее информационные системы определенной организации и получить выплату за успешно выполненный заказ. Тут достаточно совершить какое-то одно негативное воздействие, и не нужно для этого выводить из строя всю ИТ-инфраструктуру или забирать деньги из организации. Так, можно атаковать не только банки, но и крупный ритейл, страховые компании, и получать за это средства другим способом. Когда актуализировались такие угрозы и актуальность темы управления рисками ИБ сразу выросла.
Словом, поскольку кредитно-финансовые организации всегда атаковали, уровень зрелости процессов обеспечения информационной безопасности и управления рисками ИБ в банках выше, в том числе благодаря требованиям регулятора. Кроме того, у кредитно-финансовых организаций всегда был фокус на рисках из-за кредитных рисков, без анализа которых просто невозможно выдавать финансовые продукты.
Анастасия: Есть что-то, что на твой взгляд, сейчас необходимо сделать государству или бизнесу для того, чтобы повысить скорость внедрения риск-ориентированного подхода в ИБ?
Александр: Наверное, скорость. Регулятор выпускает полезные направления в области рисков, и они поддерживаются отраслью. Вопрос в скорости, хотя мы понимаем, что это сложно ее увеличить, так как есть определенная процедура, в том числе предусматривающая сбор мнения поднадзорных организаций. Кроме этого, нужно состыковать новые законы с существующими, чтобы избежать правовых коллизий или противоречий нормативных документов. Это большая задача, учитывая количество документов. Это все удлиняет процесс принятия тех или иных регулирующих документов.
Но скорость важна. Здесь можно упомянуть мою любимую тему — SGRC. Автоматизация процессов compliance и регуляторики в этой области позволяет перейти от бумажной безопасности к полностью цифровой с множеством интересных решений. Автоматизация может повысить скорость. Это важно, потому что сценарии меняются, подходы атак тоже. Злоумышленники не связаны процессами и могут менять свои методы атаки в любой момент. Мы должны быстрее перестраиваться. Нужна автоматизация, больше технических и интеграционных решений.
Анастасия: Можешь рассказать о сервисных моделях и решениях, связанных с GRC?
Александр: Конечно, такие небольшие решения существуют и применяются. Но опять же, GRC — это инструмент.
Анастасия: Понятно, что этот не процессы.
Александр: Именно так. У вас есть процесс, и когда вы устаете от Excel, который не дает нужного результата, вы переходите на специализированный инструмент, выбираете то, что проще и удобнее для вас. Облачные решения не всегда подходят в случае, если нужны интеграции с другими системами. Для каких-то компаний они применимы, для крупных организаций, таких, как наша, это довольно сложно.
Заключение
Анастасия: Мы уже подходим к завершению нашего выпуска о управлении рисками ИБ. И я прошу тебя сделать неблагодарное дело — дать прогноз на будущее. Как, по-твоему, будет развиваться тема управления рисками ИБ в нашей стране, не только в рамках вашей организации?
Александр: Мне кажется, всё будет становиться только интереснее. Я оптимист, и действительно, все области ИБ развиваются семимильными шагами. Мы видим даже IPO компаний, которые выпускают софт для информационной безопасности.
Анастасия: И железо…
Александр: Да, железо тоже. Эта область активно входит в наш мир, набирает обороты и становится масштабнее, появляются много интересных решений. ИБ будет развиваться стремительно. Сейчас это одна из ключевых составляющих любого ИТ-решения. Иногда даже основной. Например, когда вы пользуетесь какой-то системой, вы хотите быть уверены в её конфиденциальности.
Если взять корпоративные системы, например, почту. Существование корпоративной почты обусловлено исключительно вопросами безопасности. Вы могли бы использовать личную почту, но не делаете этого, потому что не хотите, чтобы переписка была вне организации, а хотите её контролировать и обезопасить. Вся ИТ-инфраструктура создается ради безопасности.
Эту мысль можно развивать дальше. Зачем компании вкладывают столько средств в ИТ? Для того, чтобы всё было безопасно. Можно было бы получить многие вещи бесплатно, но безопасность требует инвестиций.
Анастасия: Отлично. Значит, развитие рисков ИБ не остановится, а будет продолжаться и набирать обороты, как это было в последние годы. Спасибо огромное, что нашел время, было очень интересно. Надеюсь, что нашим зрителям и слушателям тоже понравилось. Спасибо, что посмотрели. Ставьте лайки, подписывайтесь, дискутируйте с нами, пишите, на какие темы еще хотите посмотреть наши выпуски. Всем спасибо, всем пока!
ваша подписка
оформлена. Назад
к нам. В ближайшее время
мы с вами свяжемся. Назад
Мы будем оповещать вас
о встречах дискуссионного клуба. Назад
на дегустационную
консультацию