И вновь вернусь к одной из дискуссий, поднятых на форуме директоров ИБ. Была поднята тема измерения эффективности ИБ. Нередко упоминались метрики ИБ, KPI ИБ и т.д. Но... стоило копнуть глубже и тема сдувалась. Выступающие, как правило, приводили в пример простейшие метрики ИБ. Вроде времени реагирования на рассмотрение заявки на доступ к ресурсам. Правильная ли это метрика? Безусловно. Важна ли она? Нет. Она никак и ни на что не влияет. Это пример технической метрики, которая нужна только для внутренней деятельности службы ИБ (я таких примеров приводил десятки). И даже не службы, а оценки конкретного процесса или даже продукта. Но...
На всех мероприятиях все выступающие говорят правильные слова о том, что надо разговаривать с бизнесом на его языке. Замечательно. А какой язык понимает бизнес? Риски и деньги. Причем деньги в первую очередь. А помогает ли метрика, упомянутая выше, заработать или не потерять деньги? Нет. Демонстрирует ли она снижение каких-нибудь рисков? Тоже нет. И в чем тогда ее потаенный смысл? И такой же вопрос касательно метрик, связанных с числом обнаруженных вирусов, процентом заблокированного спама, попыток НСД, числом утечек и т.д. и т.п. Ни одна из них никак не влияет на бизнес, а значит она не помогает службе ИБ демонстрировать свою эффективность.
Разумеется, это не значит, что их не надо измерять и применять на практике. Просто надо четко понимать, что эти примеры - не более чем низкоуровневые метрики для оценки эффективности продуктов. Это полезно, чтобы знать, насколько хорош тот или иной продукт, но совсем недостаточно, чтобы демонстрировать эти метрики бизнесу.
На всех мероприятиях все выступающие говорят правильные слова о том, что надо разговаривать с бизнесом на его языке. Замечательно. А какой язык понимает бизнес? Риски и деньги. Причем деньги в первую очередь. А помогает ли метрика, упомянутая выше, заработать или не потерять деньги? Нет. Демонстрирует ли она снижение каких-нибудь рисков? Тоже нет. И в чем тогда ее потаенный смысл? И такой же вопрос касательно метрик, связанных с числом обнаруженных вирусов, процентом заблокированного спама, попыток НСД, числом утечек и т.д. и т.п. Ни одна из них никак не влияет на бизнес, а значит она не помогает службе ИБ демонстрировать свою эффективность.
Разумеется, это не значит, что их не надо измерять и применять на практике. Просто надо четко понимать, что эти примеры - не более чем низкоуровневые метрики для оценки эффективности продуктов. Это полезно, чтобы знать, насколько хорош тот или иной продукт, но совсем недостаточно, чтобы демонстрировать эти метрики бизнесу.
12 коммент.:
Наверное буду не оригинален, но:
1. Главные критерии для бизнеса - деньги, риски. деньги наверху пирамиды - это 1 уровень
2. Связь между риском и деньгами - вероятностная, значит уже тут проблема каких либо измерений (а до метрик по ИБ еще далеко)
3. Применили знания MBA - связь установили (допустим)
4. Теперь требуется перечень рисков для бизнеса. Большой перечень. Подробный, с отраслевыми подсистемами. Риски - 2 уровень
5. Составляем перечень предпосылок/причин возникновения к определенным (написанным) рискам для бизнеса. Предпосылки - 3 уровень
6. Под предпосылками будут В ТОМ ЧИСЛЕ все возможные инциденты по ИБ (конечно они тоже делятся/классифицируются на технические, документальные, человеческие, психологические, социальные и т.д.).
7. Каждый инцидент имеет свою количественную оценку.
8. Анализируем влияние инцидента на каждый из уровней пока не доберемся до денег
9. Каждая связь имеет свою вероятность и вес. Их и надо считать.Считать через статистику.
10. Набираем статистику по связям и вероятностям наступления событий. Анализируем, составляем "лучшие практики". Мониторим. Корректируем.
Чтение книжек из Америки (к сожалению только в переводе) подсказывает, что они не заморачиваются сложностью - на это автоматизация есть. И оказывается все достаточно просто. PMBoK тому один из примеров.
Возникает резонный вопрос - "а кто это все будет делать?", ответ - "я не знаю чему конкретно учат в MBA, но по идее именно этому, причем такой спец должен иметь несколько образований (тех, эконом, юрист) либо быть любознательным перфекционистом". Таких надо выращивать.
Единственно, что на мой взгляд НЕ надо делать - это создавать все это на бумаге, как документ. Плоская двумерная структура убивает многоаспектность. Можно было бы рисовать все это в виде интеллект карты (со ссылками, весами, количеством, автоматическими расчетами) в трехмерке - но продуктов пока таких (хотя бы только рисования)найдено не было.
Наверное буду не оригинален, но:
1. Главные критерии для бизнеса - деньги, риски. деньги наверху пирамиды - это 1 уровень
2. Связь между риском и деньгами - вероятностная, значит уже тут проблема каких либо измерений (а до метрик по ИБ еще далеко)
3. Применили знания MBA - связь установили (допустим)
4. Теперь требуется перечень рисков для бизнеса. Большой перечень. Подробный, с отраслевыми подсистемами. Риски - 2 уровень
5. Составляем перечень предпосылок/причин возникновения к определенным (написанным) рискам для бизнеса. Предпосылки - 3 уровень
6. Под предпосылками будут В ТОМ ЧИСЛЕ все возможные инциденты по ИБ (конечно они тоже делятся/классифицируются на технические, документальные, человеческие, психологические, социальные и т.д.).
7. Каждый инцидент имеет свою количественную оценку.
8. Анализируем влияние инцидента на каждый из уровней пока не доберемся до денег
9. Каждая связь имеет свою вероятность и вес. Их и надо считать.Считать через статистику.
10. Набираем статистику по связям и вероятностям наступления событий. Анализируем, составляем "лучшие практики". Мониторим. Корректируем.
Чтение книжек из Америки (к сожалению только в переводе) подсказывает, что они не заморачиваются сложностью - на это автоматизация есть. И оказывается все достаточно просто. PMBoK тому один из примеров.
Возникает резонный вопрос - "а кто это все будет делать?", ответ - "я не знаю чему конкретно учат в MBA, но по идее именно этому, причем такой спец должен иметь несколько образований (тех, эконом, юрист) либо быть любознательным перфекционистом". Таких надо выращивать.
Единственно, что на мой взгляд НЕ надо делать - это создавать все это на бумаге, как документ. Плоская двумерная структура убивает многоаспектность. Можно было бы рисовать все это в виде интеллект карты (со ссылками, весами, количеством, автоматическими расчетами) в трехмерке - но продуктов пока таких (хотя бы только рисования)найдено не было.
Так вот настоящие метрики Деньги-...-инцидент появятся тогда, когда появятся описанные системы.
> Она никак и ни на что не влияет.
Влияет, на время начала исполнения заявителем его бизнес-функций. Перегрев этой метрики может привести к тому, что бизнес понесет потери, особенно там, где скорость бизнес-реакций должна быть высокой.
Вот тебе и деньги.
Хотя в общем то предыдущий пост Алексея об этом.
Что-то никто не прокомментил, что у РКН новый начальник!?
Глава Роскомнадзора Сергей Ситников перешел на должность губернатора Костромской области. Вместо него службой будет руководить его заместитель Олег Иванов, который осенью перешел в Роскомнадзор из Минобороны.
Ну Иванов... И что? Он какое отношение к ПДн имеет? Никакого.
Да? А чего не РКН уже проводки проверки по ПДн?
Метрика, приведенная тобой в посте как ненужная, на самом деле очень важна, так как напрямую влияет на время начала исполнения бизнес-функции заявителем. Перегрев этой метрики приводит к тому, что человек, получая зарплату но не работая с ресурсами, реально просаживает бабло и не зарабатывает его. Особенно важно это там, где скорость принятия бизнес-решений должна быть высока. Вот тебе и деньги, живые.
Алексей, тогда и метрика должна быть другой ;-)
В классике при проведении оценки рисков надо в том числе учитывать эффективность имеющихся защитных мер. а метрики в свою очередь могут как раз отражать то, насколько эти самые меры эффективны.
Отправить комментарий