Что часто делают вместо управления рисками?
Как обещала в предыдущем посте, рассказываю о практиках, которые распространены, и нацелены на снижение рисков, но к снижению рисков имеют мало отношения. По сути они - преувеличение нормальных мероприятий в ИБ. Но, как и во всём, вопрос в умеренности и последовательности действий.
🍔 Бездумный комплаенс
- Почему нужно сделать это сложное и дорогое мероприятие, для которого нужно переругаться со всей командой?
- Так сказали консультанты, это нужно для комплаенса! (с)
Покажите мне хоть одну компанию, которая на 100% соответствует требованиям нормативки. Скорее всего это будет мёртвая компания, которая ничего не делает.
Живая компания никогда не может соответствовать всему на 100%. Потому что:
- Для того, чтобы обеспечить комплаенс, нужно понять, где его не хватает. Ко времени внедрения мер результаты аудита будут уже неактуальными.
- Нормативка придумана, чтобы взвалить на бизнес обязательства, которые он не хочет делать. А собственный интерес компании всегда - зарабатывание денег и экономия, а не комплаенс.
- Ущерб от некомплаенса меньше выгод от нарушающей деятельности
- В компании всё меняется ежеминутно, невозможно контролировать всё.
Как добавить риск-ориентированности?
- Поставить в приоритет комплаенс, который можно увидеть снаружи (политики на сайте, защищенное соединение, соответствие сайта уведомлению РКН и т.п.)
- Понять сценарии обнаружения некомплаенса и их реалистичность
- Если комплаенс какому-то требованию требует больших затрат, проверить, нужно ли ему соответствовать, а если нужно - сделать оценку выгод и затрат.
- Понять, может ли комплаенс принести выгоду (например, новых клиентов)
🍳 Внедрение лучших практик и стандартов
А кто сказал, что эти практики - лучшие?
Серьёзно, есть ли исследования, что следование конкретной практике, конкретному фреймворку повышает безопасность? Иногда выполнение операций в конкретном фреймворке занимает кучу времени дорогостоящих специалистов, а к повышению уровня реальной безопасности не приближает.
Часто "лучшие практики" внедряются "чтобы было". Без понимания, какой цели мы хотим достичь, и без оценки, действительно нужны ли все эти телодвижения.
Rule of the thumb - если стандарт/фреймворк/лучшая практика очень конкретный и специфичный, и это не стандарт настройки какой-то конкретной технической штуки - скорее всего он вам не подойдет в том виде, в каком он есть. Потому что он не учитывает ваш контекст, и его нужно адаптировать. Это понимает даже ФСТЭК, который допускает замену мер из своих приказов на иные компенсирующие меры.
Как добавить риск-ориентированности?
- Понять, какие риски закрываем лучшей практикой/фреймворком/стандартом, оценить их, и насколько они снизятся - в деньгах в год. Также - какие выгоды принесет нам внедрение (например, новые контракты на сумму Х в год). Сравнить с полной стоимостью внедрения и ежегодного поддержания.
- Понять, каких целей хотим добиться. Оценить, всё ли нам нужно из того, что мы хотим внедрить, для достижения цели. Есть ли другие способы добиться цели?
Продолжение ⬇️
5August 8, 2024 1.3K 30
