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

2.1.3 Человеческий фактор

Чтобы завершить наш обзор самых-самых основ, давайте рассмотрим наиболее частую причину всех проблем безопасности – людей.

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

Рис. 2.2 особо выделяет, до какой степени служащие организации влияют на безопасность в целом. Более 80% инцидентов в системе безопасности обусловлены своими (служащими организации), в отличие от менее чем 20% от вирусов и внешних атак. Интересно заметить, что из этих 80% проблем, возникших изнутри, 55% обусловлены служащими, которые вовсе не стремились сознательно причинить вред.

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

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

Многие системы были скомпрометированы из-за системных администраторов, которые своевременно или должным образом не пропатчили серверы организации, сделав их уязвимыми даже для известных видов атак.

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

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

2.1.4 Выбор методологии

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

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

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

2.2 ISO1779

ISO17799 разработана Международной организацией по стандартизации (ISO), которая является сетью национальных институтов по стандартам в 146 странах мира, по принципу: один член на одну страну, с Центральным секретариатом в Женеве, Швейцария, который координирует всю систему.

ISO – неправительственная организация: ее члены не делегированы национальными правительствами, как в случае системы Объединенных Наций. Тем не менее ISO занимает особое положение между частным и государственным секторами. Это, с одной стороны, обусловлено тем, что многие из входящих в нее институтов являются частью правительственных структур своих стран или подмандатными правительству. С другой стороны, корни других членов произрастают из частного сектора, основанные на национальных партнерских программах индустриальных ассоциаций.

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

Web-сайт ISO находится по адресу:

http://www.iso.org

Стандарт ISO номер 17799 (более точно определяемый как ISO/IES 17799:2000) официально называется Информационные технологии – сводка правил по управлению информационной безопасностью на практике (Information technology – Code of practice for information security management). Это одноязычный (т. е. только на английском языке) документ в 71 страницу, предоставляемый Международной организацией по стандартизации. Сам по себе этот документ можно скачать за некоторую плату по следующему адресу:

http://www.iso.org/iso/en/CatalogueDetailPage.CatalogueDetail?CSNUMBER=33441ICS1=35ICS2=40ICS3=

Данная методология организована в виде двух независимых частей и является всеобъемлющей подборкой рекомендаций, составленной из самых лучших наработок в области информационной безопасности. Первая часть – это сама сводка правил [ISO17799]. Вторая часть – спецификация системы управления информационной безопасностью [BS7799-2].

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

2.2.1 Немного истории

У ISO17799 есть целая история. Впервые он был опубликован как практические правила DTI в Соединенном Королевстве (United Kingdom, UK), а затем в феврале 1995 г. переименован и опубликован как первая версия BS7799. Однако BS 7799 не был широко принят по целому ряду причин, главной из которых была его недостаточная гибкость, что сделало его трудноприспосабливаемым к конкретным частным условиям организаций, которые пытались применить его для защиты своих ИТ-инфраструктур.

В свете такого вялого приема в сообществе ИТ-безопасности была предпринята глобальная переработка стандарта BS7799, что привело к появлению версии 2, которая была опубликована в мае 1999 г. Однако тот факт, что в именах стандартов ISO и BS четыре последние цифры одинаковы, привел к большой путанице. Мы надеемся внести ясность в этот вопрос последующим объяснением.

BS 7799 – это состоящий из двух частей стандарт управления безопасностью, который был разработан Институтом британских стандартов (British Standards Institution, BSI) и широко использовался в Соединенном Королевстве при спонсорской поддержке правительства Великобритании. Две части BS 7799 следующие:

Для того чтобы расширить методологию BS 7799 и сделать ее доступной большей международной аудитории, в 1999 г. были выпущены схемы формальной сертификации и аккредитования, а также оперативно проявила инициативу ISO, что привело к появлению в декабре 2000 г. первого стандарта ISO и к опубликованию в 2002 г. части 2. Инструментарий ISO 17799 был также опубликован в 2002 г.

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

2.2.2 Что в ISO 1779 есть

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

И наконец, в каждом разделе даны подробные формулировки, которые обобщают стандарт.

2.2.3 Чего в ISO 1779 нет

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

2.3 Общие критерии (Международный стандарт 154 08)

Стандарт Общие критерии для оценки безопасности информационных технологий (CC, Common Criteria for Information Technology Security Evaluation) определяет общие концепции и принципы оценки ИТ-безопасности, а также представляет основную модель для оценок. Он предлагает конструкции для выражения целей ИТ-безопасности, для выбора и определения требований к ИТ-безопасности и для написания высокоуровневых спецификаций для продуктов и систем.

CC представляет собой результат серии усилий по разработке критериев для оценки ИТ-безопасности, которые очень полезны в международном сообществе. В начале 1980-х гг. в Соединенных Штатах были разработаны Критерии оценки доверия к компьютерной системе (TCSEC, Trusted Computer System Evaluation Criteria). В начале 1990-х гг. Европа разработала Критерии оценки безопасности информационной технологии (ITSEC, Information Technology Security Evaluation Criteria), которые построены на базе концепций TCSEC. В 1990 г. ISO попыталась разработать набор международных стандартных критериев оценки для общего использования. Проект CC был начат в 1993 г., чтобы сложить все эти (и другие) разработки вместе в один единый международный стандарт для оценки ИТ-безопасности. Новые критерии должны были удовлетворять необходимости всеобщего понимания стандартизированных результатов оценки безопасности на глобальном ИТ-рынке. Рис. 2.3 показывает путь, приведший к Общим критериям.

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

Относительно своего содержания Общие критерии представлены как набор различных, но связанных частей, а именно:

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

Полная информация об Общих Критериях, включая копии документов самих Общих критериев (в виде PDF-файлов), находится по следующему адресу:

http://www.commoncriteria.org/

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

2.4 Метод построения решений для обеспечения безопасности (MASS, Method for Architecting Secure Solutions)

У IBM есть метод, который используется сотрудниками IBM Global Services (IGS) для создания систем безопасности. Он называется методом по разработке решений безопасности (MASS, Method for Architecting Secure Solutions). Он помогает проанализировать и разложить по категориям связанные с безопасностью проблемы и обсуждения в нынешнем электронном бизнесе, управляемом корпоративными ИТ-инфраструктурами. Содержание этого раздела изначально было вынесено в специальное издание журнала по системам IBM о сквозной безопасности (IBM Systems Journal on End-to-End Security, Volume 40, N 3). Эта статья находится по следующему адресу:

http://www.research.ibm.com/journal/sj/403/whitmore.html

2.4.1 Постановка задачи

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

В IBM Global Services требования к методу по дизайну решений безопасности обусловлены следующими моментами:

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

Логичный и систематический метод для разработки решений безопасности имеет потенциальную ценность не только для IBM Global Services, но и для следующих категорий пользователей:

2.4.2 Анализ

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

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

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

Специфичные для безопасности таксономии, модели и методы

Стандарт ISO 7498-2[6] является широко используемым документом на тему дизайна решений ИТ-безопасности. Его цель состоит в том, чтобы расширить применимость семиуровневой системной модели OSI (Open Systems Interconnection, взаимодействие открытых систем) до возможностей безопасных коммуникаций между системами. Раздел 5 этого документа описывает набор служб и механизмов системы безопасности, который мог бы быть реализован на соответствующем уровне системной модели OSI в соответствующих сочетаниях для удовлетворения требованиям политики безопасности. В разделе 8 говорится о необходимости непрерывного управления службами и механизмами безопасности OSI, куда входит управление криптографическими функциями, маскирование сетевого трафика и обработка событий.

Многие специалисты в сфере безопасности используют службы безопасности OSI: аутентификацию, контроль доступа, конфиденциальность данных, целостность данных и невозможность отказа от авторства – как полную таксономию для требований безопасности ИТ-решений. Однако в преамбуле к ISO 7498-2 особо подчеркивается, что "система безопасности OSI не занимается мерами безопасности, которые требуются в конечных системах, установках и организациях, кроме тех случаев, когда подразумевается, что выбор и размещение служб безопасности видятся в OSI. Эти последние аспекты безопасности могут быть стандартизированы, но не в рамках рекомендаций OSI".

Критерии оценки безопасности. Агентства и комитеты по стандартам в правительствах нескольких стран разработали оценочные критерии для безопасности компьютерной технологии. В Соединенных Штатах этот документ называется "Критерии оценки безопасности надежных компьютерных систем" (TCSEC, Trusted Computer System Security Evaluation Criteria). Европейская Комиссия опубликовала Критерии оценки безопасности информационных технологий, известные как ITSEC (Information Technology Security Evaluation Criteria), а канадское правительство опубликовало Критерии оценки надежных канадских компьютерных продуктов, или CTCPEC (Canadian Trusted Computer Product Evaluation Criteria). В 1996 г. эти начинания были официально объединены в единый документ, известный как Общие критерии, или CC (Common Criteria) [7]. В 1999 г. данный документ был принят Международной организацией по стандартизации в качестве стандарта [7-9]. Этот шаг открывает дорогу взаимному пониманию результатов оценки продуктов во всем мире.

Общие критерии

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

В Общих критериях 11 функциональных классов требований:

Эти 11 функциональных классов далее разбиты еще на 66 семейств, каждая из которых содержит набор компонентных критериев. В настоящий момент задокументировано порядка 130 компонентных критериев с оглядкой на то, что дизайнеры могут добавить в конкретный дизайн какие-то дополнительные компонентные критерии. Для проведения компонентных критериев через административные органы Общих критериев существует формальная процедура, которую можно найти по адресу:

http://www.commoncriteria.org

Правительства и индустриальные группы при помощи Общих критериев разрабатывают функциональные описания для оборудования и программного обеспечения безопасности. Эти документы, известные как профили защиты [10], описывают группирование функций безопасности, соответствующих данному компоненту или технологии безопасности. Одна из основных мотиваций для разработки профилей защиты – желание поставщиков предоставить в своих продуктах безопасности стандартную функциональность и уменьшить риск при поставке информационной технологии. Вместе с работой по определению профилей защиты производители связанных с безопасностью компонентов компьютерного оборудования и программного обеспечения создают документацию, которая объясняет функциональность их продуктов относительно принятых профилей защиты. Эта документация называется "Цели безопасности". Производители могут передать свои продукты и цели безопасности на оценку независимым лицензированным организациям-тестировщикам для получения сертификатов совместимости.

Общие критерии как таксономия для требований/решений

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

Общие критерии как эталонная модель

Общие критерии вводят несколько архитектурных конструкций [8]: цель оценки (или TOE, Target Of Evaluation) представляет компонент в стадии разработки; документация по функциям безопасности TOE (или TSF, TOE Security Functions) представляет ту часть TOE, которая ответственна собственно за безопасность. По Общим критериям рассматриваемая система или компонент является "черным ящиком"; он демонстрирует только некоторую функциональность в плане безопасности и некоторые защитные механизмы для встроенных функций безопасности.

Резюме анализа

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

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

Чтобы выработать гибкий метод для разработки решений безопасности, требуется дополнительная работа по выработке:

2.4.3 Системная модель безопасности

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

Для целей нашего проекта тип рассматриваемых ИТ-решений совместим с сетевой информационной системой (NIS, Networked Information System). Более того, общая архитектура представлена архитектурой безопасности, находящейся внутри NIS, а архитектура безопасности представлена структурой системной модели безопасности. С обобщенной системной моделью для безопасности в NIS-окружении архитекторы могли бы создавать такие системные модели, которые основывались бы на детальных требованиях к управлению функциональностью и риском. Рехтин выделяет шаги для создания модели следующим образом:

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

В нашем проекте Общие критерии рассматривались как описание законченной функции модели системы безопасности. Классы и семейства в Общих критериях являются объединением требований; однако после тщательного рассмотрения было определено, что описанные в Общих критериях структуры классов и семейств не позволяют использовать себя как часть таксономии для всеохватывающей безопасности. Объединение больше подходит абстрактным вопросам безопасности, таким, как криптографические операции и защита данных, нежели безопасности в контексте работающей ИТ-функции. Для целей этого проекта функциональные критерии Общих критериев были пересмотрены и пересобраны, при этом были убраны структуры классов и семейств. Анализ 130 требований компонентного уровня по отношению к их функции в NIS-решении предполагает разбиение на пять операционных категорий: аудит, контроль доступа, контроль потока, подлинность и мандаты, целостность решения. Суммарная топография CC-классов по функциональным категориям приведена в табл. 2.1.

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

2.4.4 Подсистемы безопасности

Руководство по уровню компонентов Общих критериев документирует правила, критерии принятия решений, функции, действия и механизмы. Эта структура поддерживает утверждение, что пять категорий, описанных в табл. 2.1, представляют набор взаимосвязанных процессов, или подсистем, для системы безопасности. Идея подсистемы безопасности уже была предложена ранее; авторы книги "Доверие в киберпространстве" описали функции в компонентах контроля доступа в операционную систему как принадлежащие к подсистеме принятия решений или к правоприменительной подсистеме. Пять предложенных здесь и показанных на рис. 2.4 взаимосвязанных подсистем безопасности расширяют концепцию операционной системы и предполагают, что функция и взаимозависимость связанных с безопасностью функций, сверх централизованного контроля доступа, могут быть также смоделированы.

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

Подсистема аудита безопасности

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

Замкнутый процесс подсистемы аудита безопасности представлен на рис. 2.5.

Подсистема целостности решения

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

Замкнутый процесс для подсистемы целостности решения представлен на рис. 2.6.

Подсистема контроля доступа

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

Замкнутый процесс для подсистемы контроля доступа представлен на рис. 2.7.

Подсистема контроля информационного потока

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

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

Замкнутый процесс для подсистемы контроля информационного потока представлен на рис. 2.8.

Подсистема подлинности и мандатов

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

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

Замкнутый процесс для мандатной подсистемы представлен на рис. 2.9.

Резюме по модели системы безопасности

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

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

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

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

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

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

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

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

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

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

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

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

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

2.4.8 Документирование концептуальной архитектуры безопасности

Если заданы согласованные цели разработки, можно создать концептуальную модель для безопасности в ИТ-решении. На рис. 2.12 и 2.13 как раз представлена концептуальная архитектура безопасности. Для ясности функции безопасности объединены в группы по цели разработки.

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

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

Такой тип концептуальной модели формирует основу для разработки и оценки "подтверждения концепции" и дальнейшего усовершенствования функциональных аспектов безопасности в целевом окружении.

2.4.9 Интеграция безопасности в архитектуру общего решения

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

Модели решения

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

Структура корпоративных решений (ESS, Enterprise Solutions Structure) предоставляет целый ряд шаблонных архитектур для решений электронного бизнеса.

Документирование архитектурных решений

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

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

Примеры архитектурных решений включают:

2.4.10 Варианты использования

Архитектурные решения также будут проводить оценку прототипов и моделей функций в решении. Одна форма прототипа называется вариантом использования. При помощи вариантов использования можно проверить как угрозы для безопасности, так и нормальные взаимодействия и потоки.

Пример 1. Перехват ошибочного пакета или потока сообщения

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

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

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

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

Пример 2. Трехъярусный клиент-серверный входной поток

Рис. 2.15 иллюстрирует входной поток для трехъярусного клиент-серверного процесса, т. е. типичной интеграции компьютерной системы предприятия в интернет-окружение.

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

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

Усовершенствование функционального дизайна

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

Пример 3. Регистрация цифрового сертификата инфраструктуры открытого ключа (PKI)

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

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

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

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

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

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

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.5.2 Фаза 1. Оценка

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

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

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

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

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

2. Выполнить анализ риска

Для анализа риска используется следующая формула:

Риск = Последствия + Угрозы + Вероятность.

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

В процессе анализа на риск пять шагов:

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

3. Выполнить анализ угроз

В процессе анализа угроз выделяют два отдельных шага:

На первом шаге необходимо задать несколько простых, но эффективных вопросов: что представляют собой уязвимые места? где эти места расположены? какова вероятность воздействия на них? и каковы могут быть последствия для ИТ-инфраструктуры и бизнеса?

На втором шаге задаются такие вопросы: какие способы контроля подходят для выявленных "дыр"? сколько эти способы контроля будут стоить? и подходят ли эти способы контроля (в плане затрачиваемых усилий и средств)?

4. Разбить информацию по категориям

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

5. Определить политики и процедуры

Здесь для бизнеса создается политика безопасности. Политика безопасности содержит все относящиеся к безопасности политики и процедуры в организации.

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

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

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

2.5.3 Фаза 2. Построение

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

6. Определить контрмеры

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

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

7. Выполнение политики безопасности и ее документирование

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

Этот шаг может быть разбит на 4 ключевые фазы:

2.5.4 Фаза 3. Управление

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

8. Обучение пользователей

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

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

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

9. Проверка соответствия

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

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

10. Обратная связь результатов

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

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

2.6 Резюме

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

Мы затронули следующие темы:

Остальная часть курса построена именно на этих методологиях.