Где проходит граница между настоящим управлением рисками (SGRC) и автоматизацией бумажного комплаенса? Российский рынок — это все еще про «галочки» для регулятора?
— Российский рынок давно отошел от так называемой «бумажной безопасности» — мы наблюдаем, как из года в год увеличивается уровень зрелости организаций, и, как следствие, усложняются требования к целевому функционалу.
R-Vision SGRC появился еще тогда, когда российский рынок решений этого класса только формировался. За это время мы прошли путь от автоматизации отдельных процессов комплаенса и аудитов до комплексного управления ИБ-рисками. Поэтому сегодня хорошо видим, как меняется сам запрос заказчиков: от необходимости соответствовать требованиям к необходимости понимать реальные риски бизнеса и управлять ими. Я бы сказала, что в современных реалиях девизом многих заказчиков стало «не можешь избежать процесса — возглавь его» — на проектах мы сталкиваемся с очень интересными авторскими методиками, которые пытаются извлечь максимальную выгоду из комплаенса, моделирования угроз и управления рисками. Более того, если раньше комплаенс и управление рисками часто реализовывались как независящие друг от друга процессы, сейчас они все чаще объединяются в единый, более глобальный процесс – «управление ИБ».
Если говорить о границе между «бумажной» и «настоящей» безопасностью в контексте SGRC, на мой взгляд, она заключается в видении целевого результата процесса. Если целью является пакет отчетных документов – это «бумажная» безопасность, если же цель – набор задач по совершенствованию системы ИБ, формирование роадмапа и защита стратегии – это ближе к управлению «реальной» безопасностью.
Если убрать за скобки регуляторику, зачем глобальному бизнесу сегодня вкладываться в платформу SGRC вместо набора разрозненных инструментов?
— Один из факторов — скрытые расходы на поддержание такой инфраструктуры. Разрозненные инструменты выглядят дешевле, пока не посчитать роль интеграционного слоя. Часто в такой схеме ее выполняет человек: аналитик руками сводит выгрузки, сверяет перечни, переносит статусы. Альтернативно проводятся дополнительные работы по написанию интеграций, порталов и других средств по объединению данных.
Однако ключевое, что дает единая платформа и чего не дает набор инструментов, — единый контекст. В платформе информационная система, ее владелец, поддерживаемый процесс, связанные с ней угрозы и требования — это один объект, а не пять записей в пяти системах. Каждое решение отвечает на узкий вопрос — сканер знает про уязвимость, программа для отчетности МУ ФСТЭК — про актуальные угрозы, но они не подсветят, какое влияние это окажет на бизнес.
Как следствие, другое преимущество SGRC-платформы — результат одного процесса становится источником данных для другого. Реестр активов — основа для моделирования угроз, модель угроз — для оценки рисков, а реализованные в рамках плана обработки защитные меры заполняют аудиты по требованиям.
С увеличением уровня зрелости в компании будет формироваться видение того, как необходимо развивать ИБ. Опираясь исключительно на выделенные инструменты, компания столкнется с тем, что они будут развиваться несогласованно друг с другом или не будут вообще, оставаясь в рамках своей узкой специфики. Платформа позволяет масштабировать решение под растущие потребности и воплотить амбициозные идеи заказчика.
Разрозненные инструменты отвечают на вопрос «что происходит» в рамках специфики, покрываемой их функционалом. SGRC позволяет собрать эти данные в общую картину и ставит вопрос шире: «что это значит» и «что с этим делать». Другими словами, платформа SGRC дает основу для принятия решений.
В какой момент компания психологически готова сказать: нам мало просто закрыть требования ФСТЭК или PCI DSS, мы хотим управлять реальными рисками бизнеса?
— У каждой организации этот переход происходит по-разному, но в качестве примеров причин можно привести следующие:
- Банально, но появление в команде опытного методолога, который готов поделиться лучшими практиками. Это один самых комфортных для организаций вариантов, поскольку такой человек имеет в голове четкую целевую картинку и опыт, чтобы ее достичь.
- Усиление контроля бюджета со стороны руководства. Оно хочет лучше понимать, на что расходуются ресурсы департамента информационной безопасности, и CISO приходится выстраивать диалог с бизнесом на понятном для него языке.
- Ресурсы, затрачиваемые на обеспечение комплаенса, не защищают компанию от инцидентов. В какой-то момент происходит понимание, что необходимо внедрять проактивный подход и готовиться к реализации угроз заранее.
- Эксперты провели достаточное количество итераций по моделированию угроз и хотят сделать с результатами нечто большее, чем составить отчет для регулятора.
Во всех этих сценариях объединяющим элементом является не уровень зрелости, а появление новой потребности. Требования регулятора указывают, что нужно сделать, но не отвечают на вопрос «на что выделить ресурсы в первую очередь» и «что произойдет, если мы этого не сделаем». Как только эти вопросы появляются в компании, она готова сделать первые шаги в сторону оценки рисков.
Что на практике ломается первым при попытке внедрить количественную оценку рисков вместо чек-листа — люди, процессы или данные об активах?
— Данные об активах, а именно, определение их ценности — это краеугольный камень количественной оценки рисков, из-за которого ее все еще боятся активно использовать.
Понятие «ценность актива» находится на стыке техники и бизнеса. Владелец актива не может единолично принять решение об ущербе и не хочет подписываться под денежными данными, а представители бизнеса не понимают, как оценить ущерб от «потери доступности».
Некоторые организации идут по пути анкетирования участников процесса. Однако проработать опросник и методику обработки полученных данных — довольно сложная задача. Она также требует хороших софт-скиллов от сотрудника департамента ИБ – например, владельцы активов могут занижать ценность, чтобы избежать лишней ответственности, или завышать – чтобы повысить приоритет выделения ресурсов. Наконец, возникает ресурсная проблема – активов слишком много, чтобы провести индивидуальный опрос по каждому. Возникают «типовые» системы с усредненными ответами, и весь смысл упражнения теряется.
Другой подход, набирающий популярность – использование BCM (или управление непрерывностью бизнеса) как источник данных. Однако в нем тоже все упирается в оценку ущерба от простоя процессов, их взаимного влияния друг на друга и зависимости от систем – при отсутствии сильной методики уровень доверия к данным будет низким.
Моя позиция – лучше не ждать идеальную методологию, а пробовать, начиная с простого. Не получается оценить количественно? Оцените качественно. Нет сложного опросника? Используйте простой. В оценке рисков и без ценности актива есть вокруг чего нарастить опыт. Каждая последующая итерация сделает процесс немного понятнее.
Как превратить стандарты ISO 27001 внутри компании из настольной книги аудитора в живой операционный процесс?
— Проверка по ISO 27001 остается «настольной книгой аудитора», пока оценки соответствия замкнута сама на себя. Проверка проводится, результат оформляется в отчет, отчет кладется на полку до следующего цикла. Формально процесс реализован, но он ни на что не влияет за пределами самого себя, и поэтому воспринимается исключительно как внешняя обязанность.
Работа по стандарту становится живым операционным процессом, когда у результата проверки появляется продолжение. Несоответствие не остается строчкой в отчете, а превращается в задачу с владельцем и сроком, ее выполнение подтверждается повторной проверкой, а изменение отражается на общей картине защищенности. Это цикл PDCA, который описан в ISO 27001, но на практике почти никогда не доводится до конца, потому что каждый его шаг живет в отдельном месте: проверка в файле, задача в почте, итоговая картинка — в голове у ответственного.
Дополнительно «оживить» процесс можно, связав его с рисками. Сам ISO 27001 требует определять применимость мер, исходя из оценки рисков, но на практике она часто делается один раз под сертификацию и дальше существует отдельно. R-Vision SGRC позволяет объединить комплаенс и риски в общий цикл через защитные меры: оценка рисков позволяет сформировать план их внедрения, а результаты реализации этого плана влияют на оценку соответствия стандарту.
Как следствие, в организации меняется восприятие результатов работы по стандарту. Итогом становится не комплект документов к аудиту, а показатель соответствия, который зависит от реальных действий.
ИТ-риски и ИБ-риски до сих пор живут в разных вселенных у большинства компаний. Как ваша платформа физически склеивает эти два мира в одну модель?
— Разделение здесь историческое. ИТ и ИБ пришли к управлению рисками с разных сторон и выработали разные подходы. ИТ чаще рассматривает риск в контексте отказа компонента и оценивает последствия с точки зрения времени недоступности и сроков восстановления. ИБ работает со сценарием реализации угрозы нарушителем и ее влиянием на конфиденциальность, целостность и доступность.
Особенно заметно сближение этих подходов в финансовом секторе, где ИБ-риски все чаще рассматриваются в более широком контексте операционных рисков. Для бизнеса важно уже не только понимать вероятность реализации киберугрозы, но и видеть, как потенциальный инцидент повлияет на непрерывность процессов, доступность критичных сервисов и в конечном счете на бизнес-результат.
Попытка привести всех к одной методике обычно проваливается и не потому, что это технически невозможно, а потому, что в каждом подразделении сформировалась своя практика работы, в перекраивании которой мало ценности.
Поэтому мы подошли к решению задачи иначе. Мы унифицируем не методику, а точку сбора итоговых результатов. Каждое подразделение продолжает работать по своему подходу — использует свою методику оценки, шкалы и критерии. Объединяющим фактором служат активы: любой риск, независимо от методики оценки, привязывается к конкретному объекту в общем реестре.
Далее все актуальные риски собираются в раздел «Карта рисков», где видно общую картину как в разрезе одного актива, так и в целом по организации. Именно на этом уровне становится заметным то, что в разделенной модели не видно никогда: часть рисков ИТ и ИБ описывают одно и то же негативное событие с разных сторон, а часть мер может закрывать несколько рисков сразу.
Аналогичный принцип действует и для раздела «План обработки». Он дает единую картину задач по всем рискам независимо от их типа. Раздел не требует, чтобы все участники работали в одном интерфейсе: отдельные задачи можно передавать во внешние таск-трекеры, синхронизируя статусы и описание. Контроль исполнения остается в системе, а основная работа идет в привычном для подразделений месте.
Спор о различиях ИТ и ИБ-рисков и подходах работы с ними можно вести бесконечно, но на уровне бизнеса он не несет большой ценности. Главное, чтобы подразделения могли обосновать полученные результаты и принимать решения на их основе.
Приведите пример функции в R-Vision SGRC, которая появилась благодаря обратной связи и кардинально изменила приоритеты вашей дорожной карты, хотя изначально не планировалась к реализации.
— «Сводные аудиты» — это функционал, позволяющий объединить несколько проверок в одну комплексную. В нашем продукте всегда уделялось большое внимание связи проверки с активом, в отношении которого она проводится. В целом мы ориентировались, что функционал аудита покрывает все базовые шаги процесса: выбрать область оценки, оценить требования, завести замечания, обработать их — и этого достаточно. Однако мы стали сталкиваться с кейсами сложнее базового подхода. Например: что, если аудитор едет с проверкой в командировку и хочет объединить несколько аудитов в один, чтобы посмотреть итог по локации? Или проверяется актив, состоящих из нескольких компонентов, каждый из которых оценивается по собственным опросным листам? А когда нужно одновременно оценить десяток активов на соответствие одному опросному листу? А что, если нужно смоделировать два сценария степени соответствия и сравнить их?
Сводные аудиты стали гибким инструментом, который позволяет закрывать подобные кейсы. Его разработка потребовала по-новому взглянуть на каждый шаг процесса и подняться на уровень выше базового «оценить требование». Мы рады, что итоговый результат имеет очень широкое применение и нередко позволяет творчески подойти к решению задач заказчика.
Источник: SecPost