Методологии построения систем безопасности

Внедрение требований безопасности в архитектуру

Функции безопасности в дизайне необходимо распределять по решению. Однако многие службы и механизмы ИТ-решения, реализующие функциональность безопасности, работают в незащищенных компонентах, например: системы баз данных, прикладные системы, клиенты, серверы и операционные системы. Задача адаптации функции безопасности к сети, к приложению, к межплатформенному ПО, к системе безопасности, к общему управлению системами и к архитектурам инфраструктуры разделена между несколькими архитекторами и специалистами по интеграции, во-влеченными в проект дизайна. Этот процесс включает в себя структурированный подход, рассматривающий целевое распределение функций и требований в компонентных архитектурах:

• по мандатам на основании требований соответствия юридическим и контрактным положениям;
• опытным критериям наилучшей безопасности или баланса безопасности и бизнес-процесса;
• возможностям компонентов, исходя из знания факта существования механизма, поддерживающего требуемый процесс или действие;
• месторасположению в конфигурации на основании взаимодействия с компонентами и потоками;
• влиянию, рассматривая риск, цель безопасности и возможности компонента;
• необходимости за неимением лучшей альтернативы.

Резюме по процессу дизайна

В этом разделе описан процесс перевода решения безопасности на уровне концепций в набор подробных спецификаций для встроенной системы контроля ИТ-безопасности методом построения подсистем безопасности. Дизайн хорошо документирован, отшлифован и подтвержден относительно бизнес-процессов посредством вариантов использования и сценариев. Подробные требования к безопасности, выраженные через элементы уровня компонентов Общих критериев, распределены по операционной модели ИТ-решения. На этом с деталями уровня интеграции можно закончить и перейти к плану реализации.

2.4.11 Выводы метода (MASS)

В этом разделе рассмотрены вопросы и обстоятельства, влияющие на дизайн функций всеобъемлющей системы безопасности компьютерного решения. Сделан набросок системной модели и систематического процесса для разработки безопасности с международным стандартом Общие критерии в своем основании.

Относительно предложенной модели и процесса можно сделать несколько общих наблюдений:

• Безопасность – это общая ответственность всех дисциплин ИТ-дизайна.
• Разработка безопасности связана с задачами бизнеса не только необходимостью защиты от атак. И наоборот, защита от атак сама по себе не отвечает всем требованиям бизнеса к безопасности.
• Многие, если не все, контрольные точки безопасности в ИТ-решениях находятся в таких частях решений, которые обычно нельзя рассматривать как защищенные компоненты.

Надежная и правильная работа решений, использующих защищенные протоколы обмена данными, такие, как IPSec и SSL (Secure Socket Layer), основывается на функциях во всех пяти подсистемах безопасности, определенных в предлагаемых модели и процессе дизайна. Эти протоколы базируются на надежных проверках подлинности, которые используют криптографические ключи, требующие целостности хранилища, надежных протоколов обмена ключами, мощных механизмов контроля доступа, надежных протоколов обмена данными и надежных контрольных записей системы аудита для управления регистрацией и жизненным циклом ключей.

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

Практика и дальнейшее изучение

Концепции и подробная сопроводительная информация, представленные в этом разделе, были в этом году включены в тренировочные курсы для архитекторов IBM Global Services. Для разработки нотаций, моделей и техник визуализации, которые улучшают их адаптацию к родственным методам и архитектурным дисциплинам, ведется дополнительная работа. По системе и процессу, обозначенными как метод построения решений для обеспечения безопасности (MASS), зарегистрирован патент.

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

2.5 Методология ISSL

Методология IBM Software Services for Lotus (ISSL), которой мы будем следовать до конца этого курса, основана на знаменитой фразе Брюса Шнайера (криптограф, создатель Blowfish и Twofish): "Криптография – это процесс, не продукт".

Именно здесь входит в игру ISSL-методология. Но прежде чем погрузиться в реализацию и использование всеобъемлющей инфраструктуры безопасности, важно в общих чертах понять все аспекты ее безопасности. Чтобы сделать это, необходимо использовать и поместить в надлежащее ей место некую методологию безопасности. Цель этой методологии безопасности – разобраться, что, когда, где, кем, почему и самое главное как.

2.5.1 Краткое введение в методологию

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

Как говорится, эта методология-пример вертится вокруг трех видов деятельности: 1) что мне делать? 2) как мне это соорудить? и 3) как мне этим управлять? Которые можно перевести следующими тремя словами: оценка, построение и управление. Как показано на рис. 2.17, это циклический процесс, который является тем, что должна предлагать действительно хорошая безопасность.

Эти три фазы могут быть разбиты еще на 10 шагов, как показано на рис. 2.18. Подробности о каждом шаге изложены в оставшейся части этой лекции.

Рис. 2.17. Три фазы нашей методологии безопасности примера

Рис. 2.18. Десять шагов методологии ISSL

2.5.2 Фаза 1. Оценка

Первая фаза – это то место, где осуществляется все планирование. Действия на этой фазе включают как оценку текущего состояния дел, так и планирование будущей инфраструктуры безопасности. Далее следует подробный разбор относящихся к безопасности действий, которые надо выполнить на этапе оценочной фазы.

1. Понять бизнес-клиента

Этими действиями мы убеждаемся, что выработано твердое понимание бизнеса клиентской организации. Для определения соответствующих механизмов безопасности сначала вам нужно понять некоторые базовые вещи об организации, такие, как основной бизнес, заинтересованные стороны, демография бизнеса, продавцы, деловые партнеры (если таковые имеются), конкуренция и индустриальные тенденции, а также стандарты, в пределах которых организация действует. Это создаст прочное основание, на котором будет делаться остальная часть работы по построению системы безопасности.

Полный процесс обзора безопасности может быть разделен на следующие отдельные шаги:

1. Рассмотреть текущее состояние бизнеса:
   • определить основной бизнес;
   • определить заинтересованные стороны;
   • составить демографию бизнеса;
   • определить продавцов;
   • определить любых бизнес-партнеров;
   • определить конкуренцию;
   • определить индустриальные тенденции и стандарты.
2. Выполнить первичный обзор инфраструктуры:
   • рассмотреть инфраструктуру с аппаратной точки зрения;
   • рассмотреть инфраструктуру с точки зрения программного обеспечения.
3. Выполнить первичный анализ риска (более подробный будет в последующих шагах).
4. Рассмотреть политику безопасности с позиции, заданы ли:
   • цели и задачи политики;
   • границы;
   • ответственности;
   • физическая безопасность;
   • сетевая безопасность;
   • классификация данных;
   • контроль доступа;
   • политики и процедуры для работы с паролями;
   • процедуры обработки инцидентов;
   • приемлемые политики пользования;
   • контроль изменений;
   • обучение;
   • соответствие.

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