Вы хотите разработать Web-сервисы управления риском с помощью IBM Rational ClearQuest? В части 12 вы увидите, как следует увеличить жизненный цикл риска, чтобы вместить больший диапазон угроз, уязвимостей и рисков современного мира; и почему оркестраторы Web-сервисов должна занять важное место в новой версии жизненного цикла.
Введение
Часть 10, этой серии статей, была посвящена использованию глубокой защиты для обеспечения безопасности ваших SOA. Вам была продемонстрирована центрированная модель трехслойной системы защиты. Вы можете использовать эту модель для преодоления недостатков, характерных для некоторых технологий, и средств управления, динамично маневрируя между лучшими ресурсами.
То, что образует каждый слой, с учетом защитной позиции, зависит от бизнес-стратегии организации и концепции защиты SOA. Вы видели как стратегии защиты и средства контроля могут базироваться на основе технологий - и наоборот: как технологии и средства контроля могут базироваться на основе стратегий защиты и программ.
За пределами глубокой защиты
Вам нужно больше чем глубокая защита. Процесс разработки Web-сервисов в SOA всегда сопровождается неопределенностями. Неопределенность возникает, когда неизвестно распределение вероятностей (случайное распределение). Введите данные риска для установления распределения вероятностей. Риск - это вероятность фактора угрозы, пользующийся одной или несколькими уязвимостями.
В этой статье описывается традиционный жизненый цикл риска в SOA: Web-сервисы анализа риска, оценки риска и управления риска. Мы рассматриваем увеличение жизненного цикла для включения других Web-сервисов: прогнозирования риска, стратегий риска, технических требований риска и мониторинга риска. Вы увидите, почему для работы с файлами, которые своевременно динамически зависят от других, необходимы нелинейные очереди.
Традиционный жизненный цикл риска
Анализ риска - это метод идентификации рисков и оценки потенциальных повреждений для настройки средств контроля и мер безопасности.
Оценка риска - это процесс идендификации активов, угроз и уязвимостей, измерения рисков и их приоритезации. Вы можете использовать количественный или качественный подход для определения манеры возникновения угроз.
Примером количественного подхода является оценивание с помощью вероятностей. А отнесение риска к рискам повышенной (H), средней (M) или сниженной (L) степени - пример качественного подхода. Вам необходимо управлять рисками таким образом, чтобы каждая угроза эксплуатировала одну или несколько уязвимостей, и снизить риски до приемлемых уровней с наименьшими затратами на контрмеры.
Управление риском - это процесс снижения риска до приемлемого уровня и применения мер безопасности и средств контроля для поддерживания этого уровня риска и получения доходов от инвестиции (ROI). ROI для каждой меры безопасности - показатель того, насколько используемая вами мера безопасности оправдывает инвестиции в снижение рисков.
Применение мер безопасности не завершает процесс анализа, оценки и управления рисками. Процесс продолжает обратная связь с предыдущими этапами жизненного цикла, реагируя на экономически значимые изменения системных активов, уязвимостей, угроз, стратегий и требований.
Чтобы вместить больший диапазон угроз, уязвимостей и рисков современного мира, необходимо увеличить жизненный цикл риска. Для наглядности рассмотрим риск непредумышленной ошибки пользователя, когда некорректный ввод данных на экран приводит к системной ошибке.
Сниженный или повышенный риск?
До крупной системной ошибки степень риска непредумышленной ошибки пользователя можно считать низкой, благодаря корректному вводу данных пользователем ранее. Одна контрмера была применена с целью обратить внимание пользователя на некорректность вводимых данных. Другая контрмера обеспечила пользователей учебной программой. После первой ошибки системы степень риска возросла. Вследствие чего были приняты новые контрмеры, такие как кадровая безопасность в первой линии защиты и аттестация программного обеспечения на проведение процедур проверки достоверности для защиты системы от непредумышленной ошибки пользователя во второй линии защиты.
Прогнозирование необходимостей
Если бы мы спрогнозировали необходимость изменить рейтинг риска до того, как произошла непредумышленная ошибка системы, то степень риска непредумышленной ошибки пользователя была бы выше, и были бы приняты дополнительные контрмеры. Итак, пусть первой фазой жизненого цикла будет прогнозирование необходимостей управления риском. Перед фазой анализа риска необходимо добавить еще 2 фазы: стратегии и требования управления риском.
Данные о необходимости управления риском, полученные во время прогнозирования, включаются в стратегии управления риском. Стратегия должна быть четко задана таким образом, чтобы общую картину можно было преобразовать в задачи, которые вы можете использовать для измерения протекания каждой фазы цикла. Например, когда стратегия требует снижения риска авиакатастрофы до более приемлемого уровня, задачами, поддающимися измерению будут такие показатели как вычисление вероятности годовых убытков и ROI мер безопасности.
Планирование требований.
От задач мы переходим к планированию требований упраления риском, включая переоценку модифицируемой системы программного обеспечения в заданных временных рамках, как 3 года и меньше. В требованиях должен также указываться вид документации, соответствующий правилам техники безопасности оценки и управления рисками, для обеспечения защиты системы от непредумышленной ошибки пользователя.
По завершении задач по упралению риском мы добавляем к жизненному циклу еще одну фазу - мониторинг изменений. Необходимо контролировать качество реакции оркестраторов на изменения рисков, угроз, уязвимостей, требований и организационных структур. С помощью электронной почты мы можем получить предупреждение о критических моментах или опасности системных перегрузок в ходе операций.
Первичный оркестратор
Итак, мы увеличили жизненный цикл Risk Web-сервиса, состоящий из следующих Web-сервисов, каждый из которых представляет собой фазу цикла:
- Прогнозирование
- Стратегия
- Требования
- Анализ
- Оценка
- Управление
- Мониторинг
Risk Management Web-сервис (Web-сервис управления риском) одновременно является и частью жизненного цикла, и первичным оркестратором Web-сервисов первого уровня. Как показано на рисунке 1, эти сервисы динамично отвечают на его запросы ресурсов Risk Management (управления риском) в зависимости от потока деятельности и изменения параметров отслеживания.
Вы можете довершить это IBM Rational ClearQuest для иерархии оркестраторов.
Вторичный оркестратор
Пусть Risk Analysis Web-сервис (Web-сервис анализа риска) - вторичный оркестратор. См. рисунок 2.
Фазу анализа мы делим на:
- Asset identification Web-сервис (Web-сервис идентификации актива)
- Vulnerability identification Web-сервис (Web-сервис идентификации уязвимости)
- Threat identification Web-сервис (Web-сервис идентификации угрозы)
- Vulnerability-threat mapping Web-сервис (Web-сервис сопоставления угроз и уязвимостей)
Мировая компания может использовать оркестратор анализа для обновления информации об активах - людях, технологиях и средствах - из всех своих организационных единиц в разных SOA. Этот оркестратор можно запрограмировать на рассылку e-mail предупреждений о несостоятельности обновлений. То же самое можно сделать для Web-сервисов идентификации уязвимостей и угроз.
Web-сервис сопоставления угроз и уязвимостей
Самая интересная часть анализа риска - сервис сопоставления уязвимостей и угроз. Этот сервис сопоставляет уязвимость с несколькими угрозами, подразумевая, что одна и та же уязвимость может использоваться несколькими угрозами. Возможно также использование одной и той же уязвимости в создаваемой SOA одними угрозами в одной и другими угрозами в другой SOA.
Точно также этот сервис сопоставляет одну угрозу с несколькими уязвимостями, подразумевая, что одна и та же угроза может использовать несколько уязвимостей. Одна угроза может воспользоваться какой-либо группой уязвимостей в одной SOA и другой группой - в другой SOA. Угроза может быть непредумышленной, умышленной или созданной человеком.
Все усложняется, когда объекты перемещаются в сети из одной точки в другую и из одной SOA в другую, динамично изменяя диапазон угроз, уязвимостей и рисков. На рисунки 3 сервис сопоставления представлен как другой оркестратор для координирования этих изменений.
Рис. 3. Оркестратор третьего уровня
Использование Rational ClearQuest поможет вам проследить за изменениями в потоке деятельности Web-сервисов на этом уровне.
Нелинейные очереди оркестраторов
С возросшей сложностью Web-сервисов, зависящих от других при выполнении серии задач, всегда есть вероятность того, что один-два файла одного Web-сервиса не совметсимы с некоторыми файлами других Web-сервисов. Единственный способ справиться с такой нетерпимостью - создать нелинейные очереди в Web-сервисах, часто требующих связи с другими. Когда принимающая нелинейная очередь принимает файл из внешнего Web-сервиса, созданный Web-сервис перемещает этот файл в другую нелинейную очередь, которая доступна для немедленной связывающей оптимизации с другими файлами, которые ждали их в ближайшее время. Rational ClearQuest отслеживает изменения в способе связи файлов.
Выводы
Разработка Web-сервисов для управления рисками в SOA требует заранее составленного плана: прогнозирование необходимостей, составление концепции стратегии, формулировка требований, проведение анализа и оценки, преодоление риска и мониторинг результатов. Стадия планирования также включает в себя определение того, какие участки жизненного цикла должны быть оркестраторами на разных уровнях структуры жизненного цикла риска. Вам необходимо обсудить обеспечение адекватного управления рисками с группой системных администраторов, бизнес аналитиков и разработчиков.
Вы непременно найдете, что решение этих вопросов существенно облегчит разработку Web-сервисов для преодоления рисков. Вы можете использовать IBM Relational ClearQuest для автоматизации процессов разработки с помощью гибкого управления потоком действий и отслеживания дефектов и изменений. После разрешения этих вопросов работа администраторов по управлению и контролю Web-сервисов в жизненном цикле риска станет легче. Они смогут определить, сколько файлов может быть создано и использовано без системных прегрузок.