Современная индустрия информационной безопасности построена на концепции управления рисками: защищаться от угроз нужно в силу их вероятности и возможных последствий. То есть, все элементарно: Риск = Вероятность * Ущерб. Сложности начинаются, когда мы приступаем к оценке Ущерба и Вероятности.
И ущерб, и вероятность можно оценивать двумя способами: количественно и качественно. В первом случае величина выбирается из диапазона значений вроде "Высокий, Средний, Низкий", во втором - величина составляет (приблизительное, местами очень) цифровое значение (В = 0,02-0,05; У = 100-300 млн. долл.)
При всей сложности правильного выбора значений ущерба и вероятности, обсуждение которой выходит за рамки сегодняшней темы, этот выбор практически всегда удается сделать. В результате строятся корпоративные СУИБ согласно ISO/IEC 27001:2005, внедряются системы внутренних контролей ИБ, а космические корабли бороздят просторы мирового океана. И кажется все в порядке и тревожится нечего, но только где-то глубоко внутри остается чувство неразрешенности некоторых задач. Будто часть вопросов осталась без ответа.
Если вы, как и я, не раз испытывали это неприятное чувство, то следующая новость вам понравится. Оказывается, использование привычных техник управления рисками, которые основываются на вычислении риска как продукта возможного ущерба и вероятности, совершенно неприменимо во враждебной среде. Враждебной средой мы называем условия, в которых угрозу представляет мотивированный и целенаправленный злоумышленник.
Перед тем как подолжить, я сделаю небольшое <ЛИРИЧЕСКОЕ ОТСТУПЛЕНИЕ>: сдается мне, что RSA, Comodo, HBGary Federal, MySQL и Epsilon выполняют управление рисками в той или иной форме. Основная причина, по которой традиционный риск менеджмент оказался слабо применим в их случаях, это сложность оценки вероятности выполнения хакером конкретного сценария атаки. Возьмем RSA - атака была осуществлена с использованием трех факторов успеха:
- актуальной уязвимости в Adobe Flash (который, в прочем, уязвим перманентно),
- уязвимости человеческого фактора, и
- чувствительности продукта SecurID к угрозам конфиденциальности.
То есть, другими словами, если бы Flash был неуязвим или отключен, все сотрудники были обучены не открывать вложения к спаму, а SecurID был open source решением, то атака бы не удалась. Зато удалась бы другая атака, например подкуп релиз-инженера крупной суммой денег и внедрение в код SecurID злого бекдора. Улавливаете, к чему я клоню? На каждый один неудавшийся из N возможных сценариев инцидента в колоде хакера остается N-1 вариант. На этом </ЛИРИЧЕСКОЕ ОТСТУПЛЕНИЕ> закончено.
Все изложенное выше подкрепляется результатами недавних исследований рабочей группы, составленной из представителей четырех научных академий США, которая была озадачена оценкой применимости техники анализа рисков к защите объектов атомной энергетики. С незначительными изменениями эти результаты можно перенести на ИБ: управление рисками очень эффективно для защиты от естественных или неумышленных угроз (например, сбоя оборудования в серверной), и не очень эффективно для защиты от умышленных угроз (хакерских атак). То есть, что хорошо для BCP, не подходит для кибер-атак. Очень рекомендую ознакомиться с отчетом (бесплатно, нужна регистрация) всем, кто в теме управления рисками. Также, советую прослушать последний эпизод подкаста Risky Business , в котором эта тема обсуждается очень подробно.
Итак, что же делать?Как быть, когда идти с опросником не к кому, и когда до боли родные методы управления рисками оказываются бесполезны? Ответ прозвучал в подкасте, я его озвучу: прорабатывать сценарии атаки и защищаться от них на этапе начального дизайнасистем, а также тестировать системы на проникновениедо и после их перевода в промышленную эксплуатацию. Мы все давно знаем, и отчет британскихамериканских ученых это подчеркивает, что во враждебных условиях защитить систему можно только исследуя, проверяя и испытывая ее безопасность с точки зрения предполагаемого злоумышленника.
