среда, 22 июня 2011 г.

Оценка рисков нарушения ИБ (ISO/ГОСТ Р 13569)

Расскажу об очередном "российском" стандарте ГОСТ Р ИСО/ТО 13569. Финансовые услуги. Рекомендации по информационной безопасности.
Процесс оценки рисков ИБ состоит из следующих трех этапов:
1. Оценка рисков потенциальных угроз для каждой зоны уязвимостей.
2. Присвоение комбинированного уровня риска каждой зоне уязвимости.
3. Определение подходящих политик ИБ и защитных мер.
Сразу и не поймешь, что нужно делать то!? И в памяти всплывает бородатый анекдот: "Американцы у русских купили самолет. Первый раз собирают - получается трактор, второй раз - трактор и третий раз - трактор. Пригласили русского Ваню. Он говорит: "дайте мне напильник и закройте в ангаре на сутки". Дали напильник. Приходят через сутки - стоит самолет. Американцы спрашивают - а как так получилось. Ваня отвечает - внимательно читайте инструкцию - после сборки тщательно обработать напильником".

Я вооружился "напильником" и вот что получилось. В процессе оценки рисков ИБ необходимо осуществить следующие действия:
1. Описать информационную систему (классический процесс, о нем писать не буду).
2. Идентифицировать уязвимости (в качестве уязвимостей стандарт предлагает рассматривать уязвимости персонала, помещений, оборудования, приложений и программные средства среды - если есть желание, то этот список можно расширить, но мне кажется он довольно исчерпывающий).
3. Идентифицировать угрозы ИБ (для каждой уязвимости, предлагается по четыре одинаковых угрозы ИБ, сразу скажу, что этого не достаточно для того что бы получить полную картину состояния ИБ организации и как следствие, придется перечень угроз расширять).
4. Определение вероятности реализации угрозы (экспертный подход с использованием комбинированной шкалы "качественно-количественной", хочу отметить что предлагаемая шкала является простой и привязана к такому параметру как возможность возникновения в интервале времени, например, "пренебрежимо мало - один раз в 1000 лет или реже", "возможна - один раз в 5-ть лет" и т.д., всего 9 границ градации).
5. Определение степени влияния угрозы на репутацию, финансовые показатели, качество обслуживания и т.д. (экспертный подход с использованием качественно-количественной шкалы, приведу только один пример так как остальные можно посмотреть в стандарте, "очень незначительное влияние - нападки на банковскую систему в местном радио и местной прессе и/или незначительное количество эксплуатационных проблем, не оказывающих влияние на качество обслуживания клиентов и/или правовые обязательства от участника клиринга не выполняются в установленные законом сроки и/или убытки в размере $1000" и т.д., всего 9 границ градации)
6. Оценить и проранжировать риск по каждой угрозе ИБ (классическая таблица позиционирования вероятности и влияния, по которой выбирается ранг риска).
7. Исходя из 4-го этапа, оценить обобщенный риск для уязвимости (не информативное действие, результат которого можно использовать только в качестве иллюстрации для топов при обосновании бюджета по ИБ).
8. Выбрать защитные меры для снижения уровня риска (об этом позже).
Вот как-то так получилось из трех этапов - 8 :).

Преимущества подхода:
1. Интуитивно понятную градацию в шкалах оценки вероятности и влияния угроз ИБ;
2. Применение подхода к ранжированию рисков, что дает представление о том, на какие риски нужно обратить внимание в первую очередь, а какими можно пренебречь в настоящий момент. Понравилось следующее выражение в стандарте: "Оцениваемые уровнем 5 (максимальным) риски, подлежат немедленному устранению, а не продолжению оценки рисков".
Недостатки:
1. Узкая направленность стандарта на финансовый сектор. Применять в чистом виде, например, шкалу влияния угроз для организаций других видов - не получится.

4 комментария:

Andrew Petukhov комментирует...

С удовольствием читаю ваши публикации.
По этой вот даже комментарий появился:
методически что первично, а что вторично: угрозы или уязвимости?
Не первый раз вижу, что в начале идет поиск уязвимостей, а потом - оценка угроз. Главный недостаток этого подхода, как мне представляется - это неконтроллируемый параметр "строгости" процесса анализа на уязвимости. Т.е. есть риск осуществить поиск уязвимостей дороже, чем это требуется (например, применить методы формальной верификации), что может оказаться overkill'ом.

Мне представляется, что поиск уязвимостей логично делать составным процессом этапа оценки угроз. Действительно, вероятность осуществления угрозы напрямую зависит от количества, очевидности и эксплуатируемости уязвимостей. Т.е. чтобы посчитать этот параметр по-любому придется искать уязвимости. Но. На этом этапе уже будет оценка impact'а реализации угрозы, что позволит проконтролировать "строгость" и полноту vulnerability assessment.

Что скажете?

Сергей Ерохин комментирует...

Что первично, а что вторично - это философский вопрос, также как и что первично: "яйцо или курица?". Для меня первична - угроза, так как отсутствие ее реализации, не говорит нам о том, что она не может проявиться через год, два, пять лет. Уязвимость - это то, через что может быть реализована угроза. Можно сказать, что уязвимость создает предпосылки к реализации угрозы - да, это так, но такой процесс скорее исключение из правил, чем само правило.
Можно рассмотреть такой пример, в организации "А" работает человек, который обрабатывает информацию ограниченного доступа, зп человека 30 т.р.. Организация "Б" хочет получить эту информацию и готова заплатить за нее 40 т.р. Если сотрудник компании "А" согласился продать информацию, то угроза реализована и уязвимостью является человек (со всеми своими проблемами, комплексами и мотивациями). Но стоит не забывать о том, что человек может отказаться от такого предложения и тогда компания "Б" начнет искать другие подходы - уязвимости. Если подвести итог, то угроза - нарушение конфиденциальности информации компании "А" компанией "Б". Если компании "Б" эта информация действительно необходима, то она будет использовать весь возможный арсенал и преребирать все возможные уязвимые места организации "А". Если даже уязвимые места отсутствуют, то угроза остается :).
А вот вероятность реализации угрозы ИБ действительно зависит от такого параметра как количество уязвимостей. Чем их больше, тем выше вероятность. Но четкую зависимость между количеством уязвимостей и вероятностью реализации угроз ИБ я пока не встречал. Например, пять уязвимостей - на сколько уменьшают вероятность? Есть различные подходы которые позволяют оценить уязвимости, например CVSS. Но, честно говоря, я на столько детально в них не вникал.

Andrew Petukhov комментирует...

Ну я немного другой аспект все-таки имел в виду.

Есть конкретная задача - найти уязвимости в используемом ПО.
При решении этой задачи есть небольшой нюанс: если какой-то метод (средство) не нашло уязвимостей, это еще не значит, что их нет :)

Соответственно, все методы можно отранжировать по строгости анализа. Стоимость анализа прямо пропорциональна строгости. В итоге, у нас есть практическая задача: как выбрать такой метод анализа уязвимостей, который даст нам fine enough уверенность в отсутствии уязвимостей? При этом мы не хотим переплачивать.

Есть две крайности:
1. Использовать только бесплатные point&click продукты. Так, чтобы от оператора не требовалась высокая компетентность. Как итог - у нас появляется увернность в отсутсвии ну самых известных и "тупых" уязвимостей.

2. Вторая крайность (самая дорогая и дающая максимальную уверенность в качестве ПО) - это использование методов формальной верификации.

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

Вот что я имел в виду, но, наверное, выразился непонятно :)

Сергей Ерохин комментирует...

Выбирать метод анализа уязвимостей программного обеспечения на основании возможного нанесенного ущерба от реализации угроз к конкретной информации - можно попробовать.
Риск = вероятность угрозы * вероятность уязвимости * цена информации.
Угрозы для программного обеспечения известны и стоимость информации можно оценить. Вероятность наличия в программном обеспечении уязвимостей можно определить.
Далее отбросить все уязвимости риск по которым "допустимый" (для так называемых, известных, но не опасных) и анализировать ПО по конкретным уязвимостям для которых риск "недопустимый". Вполне пригодный вариат. Но не стоит забывать, что процеес оценки рисков, так же занимает время специалиста и влияет на конечную стоимость таких работ :).