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

2.4.5 Разработка архитектур безопасности

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

Рис. 2.10. Окружение сетевой информационной системы

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

Исходя из бизнес-перспективы, можно выделить две цели:

1. Гарантировать, что протекание желаемого ИТ-бизнес-процесса выдает корректные и надежные результаты.
2. Гарантировать, что потенциальные уязвимости и исключительные ситуации т. е. опасности) в протекании ИТ-бизнес-процесса обрабатываются таким образом, который совпадает с целями управления риском.

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

2.4.6 Модель бизнес-процесса

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

увеличить изображение
Рис. 2.11. Нормальный и подверженный опасностям ИТ-бизнес-потоки

Цели дизайна системы безопасности

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

1. Необходимо контролировать доступ к компьютерным системам и их процессам согласно предопределенным ролям и системе ответственности.
2. Необходимо контролировать доступ к информации согласно информационной классификации и приватным политикам.
3. Необходимо контролировать поток информации согласно информационной классификации и приватным политикам.
4. Необходимо управлять надежностью и целостностью компонентов.
5. Необходимо обеспечить защиту от злонамеренных атак.
6. Необходимы надежные механизмы идентификации и проверки подлинности для удовлетворения требований системы доступа к системам, процессам и информации.
7. Необходимо не допустить мошенничества во время бизнес-процессов и транзакций или обнаружить и ответить на попытки мошенничества.

2.4.7 Выбор и количество подсистем

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

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