Измерение кибербезопасности глазами бизнеса. Продолжение
Давайте продолжим тему, начатую в прошлом номере, посвященную взгляду бизнеса на кибербезопасность. Тогда мы обсудили тему потерь от ИБ-инцидентов, которые могут быть представлены по-разному, в зависимости от того, с какой целевой аудиторией мы будем общаться и показывать различные формы потерь. Но очевидно, что инцидент инциденту рознь и последствия от него могут иметь разное значение для бизнеса. Поэтому одни инциденты более опасные и, как следствие, более приоритетные, чем другие. Как пример можно привести следующую градацию инцидентов по сумме ущерба от них. Если какой-то инцидент попадает в левую часть таблицы, он бизнесу менее интересен, чем инциденты из правой части таблицы.
|
|
Несущественно |
Незначительно |
Умеренно |
Значительно |
Катастрофически |
|
Финансовый ущерб на более чем Y миллионов рублей |
₽1М |
₽5М |
₽10М |
₽50М |
₽100М |
Если не рублем, то чем?
А если нельзя посчитать инциденты непосредственно «рублем»? Имеет ли смысл попробовать оперировать иными метриками? Разумеется. Вот несколько примеров таких «универсальных» метрик и их градаций, которые вы можете показывать своему бизнесу и которые он готов воспринимать и воспринимает, так как они ему понятны.
|
|
Несущественно |
Незначительно |
Умеренно |
Значительно |
Катастрофически |
|
Перебой в работе для более чем X заказчиков |
10 заказчиков |
100 заказчиков |
500 заказчиков |
1000 заказчиков |
5000 заказчиков |
|
Прерывание бизнес операций на Z часов |
1 час |
4 часа |
8 часов |
2 дня |
5 дней |
|
Нанесение вреда жизни и здоровью A человек |
0 человек |
0 человек |
1 человек |
10 человек |
50 человек |
|
Утечка данных B заказчиков |
100 заказчиков |
1000 заказчиков |
5000 заказчиков |
10000 заказчиков |
100000 заказчиков |
|
Отток C заказчиков |
5 заказчиков |
10 заказчиков |
25 заказчиков |
50 заказчиков |
100 заказчиков |
|
Потеря доли рынка на D% |
0% |
0% |
1% |
3% |
7% |
|
Снижение продуктивности на E% |
0% |
1% |
3% |
5% |
10% |
Хотя, что значит «нельзя посчитать рублем»? Потеря доли рынка, снижение продуктивности, отток заказчиков... Все они прекрасно транслируются в финансовые показатели компании путем проведения ряда математических расчетов. Кроме этих «универсальных» метрик, можно привести пример и отраслевого показателя (например, для электроэнергетики) или показателя, который я встретил в одной из финансовых организаций.
|
|
Несущественно |
Незначительно |
Умеренно |
Значительно |
Катастрофически |
|
Снижение мощности электрогене-рации на F мегаватт |
Снижение мощности допустимо |
Снижение мощности допустимо |
100 МВт |
1000 МВт |
10000 МВт |
|
Публикация в СМИ |
Отсутствуют |
В местных потребительских печатных изданиях |
По местному ТВ или в местных отраслевых печатных изданиях |
По национальному ТВ или в национальных потребительских печатных изданиях |
Выделенная передачи или репортаж по национальному ТВ или в национальных отраслевых печатных изданиях |
Уровни зрелости интеграции ИБ и бизнеса
Но не думайте, будто все так просто. Когда вы задаетесь вопросом, что остановит или замедлит операции в вашей компании, вы должны не просто ответить на него. Вы должны понимать, что скрывается за понятием «операция» и как бизнес зарабатывает свои деньги. В деталях.
Возьмем в качестве примера защиту от DDoS-атак, которые могут вывести из строя сайт вашей компании. Нужно ли это бизнесу? Это зависит от того, сможете ли вы увязать данную ИБ-задачу с вашим бизнесом. Давайте попробуем применить к этому кейсу идею с пятью уровнями зрелости, которая многим знакома по различным стандартам управления ИТ или ИБ (COBIT, ITIL, ISO 27001 и т. п.). На самом низшем уровне зрелости специалист по ИБ обычно вообще не думает об оценке ущерба от той или иной атаки, следуя принципу Портоса «я дерусь, потому что я дерусь», то есть «я защищаю, потому что надо защищать (или потому что так сказал регулятор)». К бизнесу это не имеет никакого отношения.
На втором уровне представитель службы ИБ начинает задумываться о том, зачем организации нужен сайт и понимает, что через него идут продажи компании. Поэтому, делает вывод наш герой, чтобы продажи не падали, надо бороться с DDoS-атаками. Проявляются зачатки бизнес-сознания, что уже хорошо. Но этого мало, чтобы говорить о безопасности с точки зрения бизнеса.
Третий уровень уже больше напоминает бизнес-ориентацию. Мы обращаемся к службе ИТ (или к хостинг-провайдеру) и получаем от них данные по времени простоя сайта в результате DDoS-атак за прошедший год (или иной период времени). Затем мы просто перемножаем эти цифры на размер доходов от продаж через сайт и получаем... фанфары... размер ущерба от DDoS-атак. Но... Есть небольшое «но». Такой простой расчет исходит из предположения, что график продаж через сайт представляет собой обычную прямую, параллельную оси абсцисс. Ни взлетов, ни падений. Каждую минуту происходит одинаковое число сделок – и так в течение года. В идеальном мире действительно предложенная формула будет работать. Но мир неидеален...
Что влияет на выбор
Многие виды бизнеса являются сезонными. Турагентства продают большинство путевок перед майскими, летними и зимними каникулами. У интернет-магазинов также происходят сезонные всплески – перед Рождеством, перед Новым годом, перед 14 и 23 Февраля, а также 8 Марта. К тому же не нужно думать, будто посетитель, столкнувшись с простоем сайта, навсегда забудет о нем и откажется от покупки. Он может прийти через 15 минут и совершить покупку. Он может позвонить по телефону в отдел продаж или написать по электронной почте, а потом вернуться на сайт. Поведение пользователя и цикл продаж — два важных параметра, которые вам потребуется узнать у вашего коммерческого подразделения, прежде чем вы снова возьметесь за калькулятор.
Но можно (а временами и нужно) пойти дальше. Помимо учета множества показателей, связанных с циклом продаж, профилем пользователя, временными спадами и пиками, размером средней сделки, количеством транзакций и т. п., мы должны оценить и финансовые показатели приобретаемого средства защиты от DDoS. Понятно, сумма не должна превышать размер ущерба, но это совсем уж поверхностное суждение. Борьба с DDoS может быть представлена в виде облачного или on-prem-решения (то есть продаваться по модели OpEx или CapEx соответственно). Купить такое решение можно, поставив его на баланс, или воспользоваться лизингом. Оплата может быть произведена либо за год использования (типичная схема для большинства средств защиты), либо помесячно или в пиковые интервалы продаж/спроса со стороны клиентов, а также по схеме on-demand, то есть во время самой атаки. При этом последний вариант тоже может быть реализован по-разному – оплата «за атаку» или оплата «за полосу пропускания». И вот собрав воедино все финансовые, маркетинговые и айтишные показатели, можно уже заниматься расчетом ущерба от DDoS-атак и его оценкой применительно к конкретной организации. И только в этом случае следует говорить о том, нужна ли конкретному бизнесу защита от DDoS-атак или можно принять данный риск, поскольку с точки зрения бизнеса он будет незначителен.
Факторы успеха
В качестве заключения попробую выделить ключевые факторы успеха, которые позволяют показать бизнесу, что ИБ действительно учитывает его интересы и способна развивать его:
-
Вы должны понимать, что вы делаете в области ИБ. Это вроде очевидный факт, но его все равно следует упомянуть.
-
Вы должны понимать бизнес своего предприятия. Именно это позволит применить знания из предыдущего пункта списка конкретно в вашей организации.
-
Вы должны понимать свою целевую аудиторию. Для разных топ-менеджеров (финансы, HR, логистика, ИТ, бухгалтерия, операции...) значение имеют разные показатели, и это надо учитывать, выбирая и демонстрируя им свои метрики.
-
Вы должны уметь совмещать эти три элемента вместе.
-
Вы должны знать, где лежат данные (и как получить к ним доступ).
-
Вы должны уметь программировать, чтобы объединить все данные вместе и произвести над ними необходимые вычисления. Полная автоматизация в этом вопросе сегодня пока невозможна – а потому от вас и требуется умение программировать, чтобы объединить данные из разрозненных систем и визуализировать их правильным образом.
Смотреть все статьи по теме "Информационная безопасность"
Опубликовано 09.12.2019
