Почитал подход к оценки рисков нарушения ИБ в международном стандарте ISO 27005-2008 "Управление рисками информационной безопасности" (знаю, что есть редакция от 2011г., но исходные тексты не получилось достать) он же британский стандарт BS7799-3 в первоисточнике.
Оценка рисков нарушения ИБ проводится в соответствии со следующими этапами:
1. Идентификация активов (необходимо выделить конкретные активы (люди, информация, сервисы, техника), которые являются критичными в организации - ни чего нового :) ).
2. Идентификация нарушителей ИБ (необходимо построить "модель нарушителей", указав тип нарушителя, его мотивацию и возможные последствия от действий такого нарушителя, например тип нарушителя - "хакер", мотив - "самоутвердиться в определенном кругу лиц", последствия - "взлом веб-сервера организации и подмена главной страницы").
3. Идентификация существующих требований ИБ законодательства и партнеров (в процессе оценки рисков, необходимо учитывать как собственный опыт и статистику инцидентов ИБ в конкретной области, так и требования законодательства по ИБ и требования партнеров организации).
4. Идентификация угроз ИБ (в приложении C стандарта 27005 есть таблица с типовым перечнем угроз ИБ, например, тип - "отказ в обслуживании сервисов ", угроза - "отказ каналов связи", может быть - "преднамеренный" или "случайный" и т.д.).
5. Оценка вероятности реализации угроз ИБ (предлагает использовать качественную шкалу с ранжированием вероятности на низкую - "маловероятно, что угроза осуществится, так как не существует объективных предпосылок (инцидентов в прошлом, мотивов и статистики) к ее реализации, среднюю - "..." и высокую "...."").
6. Идентификация уязвимостей (в приложении D стандарта есть таблица с типовыми уязвимостями, например, уязвимость "аппаратных средств" - "неэффективное конфигурирование" - "в результате ошибки в использовании" и т.д. ).
7. Оценка уязвимостей (аналогичная трехуровневая качественная шкала вероятности использования уязвимости: очень вероятно - "уязвимость легко использовать, и существует слабая защита или защита вообще отсутствует"......).
8. Оценка стоимости актива ( шкалу оценки стоимости предлагается разработать самой организации с учетом специфики ее функционирования, но в примере предлагается использовать четыре значения от 0 до 4 без привязки к конкретной стоимости).
9. Вычисление рисков ИБ (риск вычисляется по таблице позиционирования значений вероятности угроз, вероятности использования уязвимости и стоимости актива. Значение риска может изменятся в диапазоне от 0 до 8. В результате, по каждому активу вы получите список угроз с различными значениями риска).
10. Ранжирование рисков ИБ или ранжирование угроз ИБ (для того чтобы определить каким рискам необходимо уделить внимание, а какие можно отложить, существует таблица и шкала ранжирования рисков. Ранги рисков - "низкий (0-2)", "средний (3-5)" и высокий(6-8). Либо можно отранжировать угрозы по значению риска, но для этого вероятность реализации угроз должна быть определена количественно. Основной принцип ранжирования заключается в присвоении высшего ранга той угрозе, по которой значение риска выше, и низшего ранга той угрозе, по которой значение риска меньше).
Преимущества подхода:
1. Наличие шаблона типовых нарушителей ИБ, из которых организация может выбрать актуальных для своей деятельности; наличие самого факта идентификации нарушителей ИБ :).
2. Наличие типовых угроз и уязвимостей, что позволяет специалистам сократить время на сбор и изучение информации о существующих уязвимостях.
Недостатки:
1. Пока что это стандарт ISO, а не ГОСТ Р ИСО/МЭК, хотя тут утверждают, что 01.12.2011 мы увидем "российскую" редакцию ;).
2. Если значение риска по 10-ти угрозам - одинаковое, что делать? Такой тривиальный подход к ранжированию не будет работать.
6 комментариев:
А в чем проблема с одинаковыми рисками? Обыденная ситуация (активов больше 300), и ничего.
Проблема в следующем: если у вас получилось 150 рисков с рангом "1", что вы будете делать? Как вы, по указанному подходу определите какой из 150 рисков лучше обработать сразу, а какие позже? Ведь все 150 сразу вы не обработаете ;).
RTP выполняется год, а не моментально.
Финансы и загрузку людей действительно приходится планировать, и согласовывать с партнерами, и корректировать по ходу, но и это - нормальное явление для реальной жизни-то.
Конечно реальное явление, но вы же какие-то риски снижаете проводимыми мероприятиями в январе, а какие-то в декабре. Так вот отсюда и вопрос, как вы определяете то что необходимо делать в январе, а что лучше перенести на более поздний срок? Настоящий стандарт предлагает ранжировать по степени значимости риски. Таким образои риски с рангом "1" необходимо планировать на январь, а риски с рангом "6" на декабрь. А вот если у вас 150 рисков с рангом "1", какие из них луччше выполнить в январе, а какие в декабре?
Методика предназначена для определения значимости, а не очередности. Принятие решений за ее рамками находится. И слава богу, а то бы она напринимала, не зная динамики ресурсов (когда инвестпрограмма кончается, когда еще один работник из декрета выходит, когда sla перепродлевать и т.п.)
Знаете, например, самую популярную сортировку задач срочная&важная, срочная&неважная, несрочная&важная, несрочная&неважная. Она ж не расставляет их за Вас по календарю, она просто дает признак, на основе которого это можно делать на какой-то осмысленной основе.
Если какая-то методика RA на выходе дает приоритетность, это плохая методика, шарлатанская.
Значимость - это и есть приоритетность. Ведь вы не будете угрозу с риском в 1 млн. руб. обрабатывать позже чем угрозу с риском в 1 руб? Если кто-то так делает, то стоит задуматься о компетентности этого человека.
Отправить комментарий