«Бумажная» и «практическая» безопасность – что правильней?

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

«Бумажная» (стратегическая) безопасность возникла в 2003–2004 году, когда для некоторых государственных и финансовых организаций (слабо зарегулированных на тот момент) появилось множество различных документов и стандартов, которые не могли быть применены в реально практике нефинансовых организаций. Среди специалистов был сформировался такой термин, как «бумажная безопасность» или выполнение стандартов, которые к той отрасли, из которой эти специалисты вышли, не имеют практически никакого отношения.

В некоторых компаниях зависимости от формы собственности и объема регуляторики до половины времени работы службы ИБ может тратиться на исполнение комплаенса, причем именно для формального выполнения требований, чтобы пройти аудит и «отбиться» от надзорных органов.

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

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

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

Во многом имеющиеся здесь несовпадения или противоречия искусственны, т.к. одно плавно перетекает в другое. На примере Data Privacy и IT Security хорошо видно, что идеологически они между собой очень сильно перекликаются в очень многих доменах. На примере анализа 27001 и 27701 можно увидеть, что «обе безопасности» могут уживаться между собой.

Как выстроить процесс управления ИБ в соответствии с требованиями стандартов?

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

У многих компаний, когда они решают привести ИБ в соответствие стандартам, могут быть требования ISO 27001. Помимо этого – ФЗ-152, а если обрабатываются персональные данные граждан Евросоюза – то GDPR, ФЗ-187 – для КИИ.

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

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

Есть много рекомендательных стандартов, вроде NIST, SANS, CIS. Это лучшие практики, на которые можно опираться при построении систем управления безопасностью и выборе мер. Когда речь идет о стандартах и фреймворках, вопрос не только в удовлетворении требований ФСТЭК или банковских регуляторов, это еще и основа, на которой можно строить всю безопасность. Можно для себя еще брать национальные стандарты: английские, австралийские, французские. Из всех них брать лучшее и на основе этого выстраивать уже свою систему безопасности.

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

Основная проблема, с которой все сталкиваются – как не утонуть во всем этом массиве требований (потому что как правило, компания попадает под несколько направлений, к примеру, ИСПДн и указания Банка Росси, и еще внутренние требования) и как перейти от этих требований к практике?

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

Каким образом из этой массы требований грамотно сформировать процесс compliance?

Пример: в крупном банке провели анализ 15 стандартов, по которым банк проходил аудиты. Из 1500 различных критериев около 1000 были уникальными, а остальные 500 повторялись из стандарта в стандарт. Если выстраивать соответствие сразу по всем ним, применяя автоматизацию, то объем работы можно существенно сократить, практически на 1/3.

Начинать при этом желательно с реализации тех мер, которые актуальны с точки зрения рисков ИБ («практическая» безопасность), но при этом закрывают требования комплаенса. Это оптимальная стратегия. И все же стоит учитывать реальную модель рисков для организации: что для нее актуальнее – хакерские атаки или последствия несоответствий. Часто при этом регулятор позволяет заложить основу, которую уже потом можно развивать по риск-ориентированной модели.

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

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

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

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

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

Еще одно применение комплаенса – при поглощении или объединении компаний. Если есть выстроенный процесс и набор требований, то применив его к новому блоку инфраструктуры можно довольно быстро привести его в соответствие. Это удобно и экономит время.

Какие решения можно использовать для автоматизации этого процесса?

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

На примере КИИ:

Агрегация сведений:

• Формирование сведений об угрозах безопасности информации

• Формирование возможных последствий

• Расчет категории значимости ОКИИ

• Формирование организационных и технических мер

• Процесс пересмотре категорий значимости

Приведение к соответствию:

• Контрольные мероприятия (чек-лист) базового набора мер ЗОКИИ на основе присвоенной категории

• Создание задач (подпроцесс) по реализации необходимых (недостающих) мер

Вывод из эксплуатации:

• Процедура вывода из эксплуатации ОКИИ

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

Она онлайн или обязательно ставить себе внутрь? Система ставится внутри сети и не требует большого количества ресурсов.

Насколько оправдан риск-ориентированный подход на практике?

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

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

Риск-ориентированный подход начинается с понимания активов их ценности. Как правило, в компаниях нет даже полноценных моделей активов, нет владельцев. Без этого полноценный риск-ориентированный подход невозможен.

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

Еще одной трудностью является частое отсутствие выстроенной стратегии развития бизнеса и поставленных целей, исходя из которых можно строить стратегии развития IT и информационной безопасности, и, в частности, модель операционных рисков. Частично решить эту проблему можно коммуникацией с представителями бизнес-подразделений на одном, понятном им языке, для того чтобы иметь возможность обосновать конкретные риски и их степень исходя из четких и понятных критериев. При этом большой и часто допускаемой ошибкой являются попытки «запугать» бизнес. Риски должны быть оценены максимально четко.

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

При оценке рисков всегда следует обращать внимание на то, кто является заинтересованной стороной и какие риски оцениваются. На примере ISO 27701 – есть privacy риски, связанные с нарушением обработки и защиты персональных данных, а есть отдельные риски для субъектов персональных данных, и это два отдельных набора рисков, которые управляются и обрабатывают разным образом.

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

Пример влияния рисков комплаенса на информационную безопасность

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

Чем может быть полезна концепция SGRC?

Не следует забывать, что ИБ-это процесс, и достижения комплаенса один раз недостаточно, требования должны периодически пересматриваться и соответствие им оцениваться заново.

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

Есть ли различие комплаенс-подхода и риск-ориентированного подхода?

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

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

Какие есть возможности для автоматизации управления рисками?

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

Сценарии применения продуктов SecurityVision в компаниях

SecurityVision – это платформа автоматизации. Большая часть компаний занимается управлением инцидентами, и поэтому основные сценарии – это оркестрация, автоматизация реагирования (SOAR). При этом есть компании, которые имеют большое количество регуляторных требований и занимаются управлением рисками, и это второй сценарий – SGRC.

По сути, сейчас на рынке не так много инструментов для автоматизации управления безопасностью. Из дорогостоящих enterprise решений это SecuriyVision, R-Vision, E-platform.

Однако систему следует выбирать по уровню зрелости. Начинать можно с excel, но начиная с какого-то момента надо переходить на более технологичные решения.

Риск реализовался, что делать?

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

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

В компании должны быть планы реагирования на инциденты и регулярное обучение сотрудников по их реализации в кризисной ситуации (а киберучения на Код ИБ ПРОФИ научат как их составлять😊)

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

В целом, какой бы подход в компании ни применялся, комплаенс или риск ориентированный, как бы ни делилась безопасность на «бумажную» (стратегическую) и реальную – настоящему руководителю службы ИБ все равно придется этим заниматься, а инструменты автоматизации упростят эту задачу.