Московский Государственный Университет им. Ломоносова
Факультет Вычислительной Математики и Кибернетики

"Методология построения системы управления безопасностью ИТ"

Содержание

  1. Область применения
  2. Нормативные ссылки
  3. Определения
  4. Сокращения
  5. Цель документа
  6. Структура документа
  7. Начальный этап проектирования
    1. Формулировка целей построения СУБ ИТ
    2. Формулировка стратегий построения СУБ ИТ
    3. Создание общей политики безопасности ИТ
  8. Методы оценки риска для СУБ ИТ
    1. Основной подход
    2. Неформальный подход
    3. Детальный анализ риска
    4. Комбинация разных подходов
  9. Анализ системы ИТ
    1. Классификация компонентов системы по уровню риска
    2. Применение основного подхода
    3. Применение детального анализа
    4. Выбор СЗ
    5. Оценка приемлемости остаточного риска
    6. Политика безопасности системы ИТ
    7. Создание плана по обеспечению безопасности ИТ
  10. Порядок осуществления плана безопасности ИТ
    1. Установка СЗ
    2. Обучение персонала
    3. Аккредитация СУБ ИТ
  11. Сопровождение СУБ ИТ
    1. Поддержание системы в рабочем состоянии
    2. Порядок проведения ревизии и проверки согласованности системы
    3. Пересмотр СЗ
    4. Мониторинг
  12. Резюме

1. Область применения

Данный документ применим как к отдельным ЭВМ, так и к системам, связанным с работой в функциональной среде взаимосвязи открытых систем (ВОС). Он предлагает руководящие принципы по созданию систем управления безопасностью информационных технологий (СУБ ИТ).

2. Нормативные ссылки

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

  • ИСО/МЭК DTR 13335-1,2,3. ИТ. Защита информации. Руководство по управлению и административным мерам. Ч.1. Концепции и модели защиты информации. Ч.2. Управление и планирование защиты информации. Ч.3. Средства управления защитой.
  • 3. Определения

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

    4. Сокращения

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

    5. Цель документа

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

    6. Структура документа

    Документ разделен на 12 частей. В части 7 обсуждается важность корпоративной политики безопасности ИТ и ее состав. Часть 8 дает краткий обзор четырех различных подходов, которые организация может использовать, чтобы идентифицировать требования к своей безопасности. Часть 9 подробно описывает рекомендуемый подход, сопровождаемый обсуждением реализации СЗ в части 10. Эта часть также включает детальное обсуждение программ обучения персонала технике безопасности ИТ и процесса аккредитации системы защиты. Часть 11 показывает суть действий по сопровождению системы, которые являются необходимыми для гарантии того, что СЗ работают эффективно. Наконец, в части 12 дается краткое резюме всего документа.

    7. Начальный этап проектирования

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

    Рис. 1. Управление безопасностью ИТ

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

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

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

    7.1. Формулировка целей построения СУБ ИТ

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

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

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

    7.2. Формулировка стратегий построения СУБ ИТ

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

    7.3. Создание общей политики безопасности ИТ

    При определении и поддержании общей (корпоративной) политики безопасности ИТ, необходима согласованность с:

    • корпоративной рабочей политикой;
    • корпоративной политикой управления организацией;
    • корпоративной политикой общей безопасности; и
    • корпоративной политикой применения ИТ.

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

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

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

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

    В случае если необходима более детальная корпоративная политика безопасности ИТ, то должны рассматриваться следующие проблемы:

    • модели и процедуры по безопасности организации;
    • использование стандартов;
    • процедуры для реализации СЗ;
    • подход к ревизии и проверке согласованности безопасности;
    • подход к контролю СЗ;
    • подход к обработке происшествий, связанных с безопасностью;
    • подход к контролю использования системы ИТ; и
    • обстоятельства, при которых внешние специалисты по безопасности будут использоваться.

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

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

    8. Методы оценки риска для СУБ ИТ

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

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

    8.1. Основной подход

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

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

    8.2. Неформальный подход

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

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

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

    8.3. Детальный анализ риска

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

    Если все же этот подход выбран, то возможно либо использование стандартного метода, который удовлетворяет требованиям, отраженным в данном документе (например, метод, описанный в части 9.3), либо использование "техники моделирования риска", соответствующей данной организации. (Если произведен детальный анализ риска, и СЗ определены, то может быть построена "модель риска", основанная на полученных данных. Модель риска содержит общие элементы системы и может сэкономить время при оценке требований безопасности при изменении системы ИТ или при анализе других подобных систем.)

    8.4. Комбинация разных подходов

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

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

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

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

    9. Анализ системы ИТ

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

    9.1. Классификация компонентов системы по уровню риска

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

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

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

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

    9.2. Применение основного подхода

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

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

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

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

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

    9.3. Применение детального анализа

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

    Рис. 2. Детальный анализ риска

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

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

    9.3.1. Определение границ обзора системы

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

    9.3.2. Определение существующих ценностей

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

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

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

    9.3.3. Комплексное определение важности ценностей

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

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

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

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

    Существует правило получения комплексной оценки из обычной оценки, по которому:

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

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

    9.3.4. Определение уже установленных СЗ

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

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

    Результатом данного процесса является список все уже установленных СЗ с указанием статуса их реализации и использования.

    9.3.5. Оценка уязвимых мест

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

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

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

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

    9.3.6. Оценка угроз

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

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

    Для каждой угрозы необходимо определить следующее:

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

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

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

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

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

    9.3.7. Оценка риска для системы

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

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

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

    9.4. Выбор СЗ

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

    9.4.1. Определение требуемых СЗ

    Основу для определения всех рассматриваемых СЗ составляет мера риска, т.е. на данном этапе следует использовать результаты оценки риска для системы ИТ.

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

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

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

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

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

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

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

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

    Физическую защиту обеспечивают стены здания, дверные замки, противопожарные системы и, конечно, охрана помещения. Персональная защита включает проверку правильности работы персонала и реализация программ по обучению персонала технике безопасности. Административные (процедурные) СЗ имеют дело с документацией по СУБ ИТ, разработкой программного обеспечения и процедур, предназначенных для обеспечения нормальной работы всех СЗ и правильной обработки происшествий. Следует отметить, что планирование происшествий и составление стратегий восстановления системы после таких происшествий (сбоев) должны выполняться для каждой компоненты системы. Стратегия восстановления включает описание ключевых функций и приоритетность их выполнения при возникновении конкретного происшествия.

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

    При выборе требуемых СЗ необходимо принять во внимание следующие факторы:

    • простота использования СЗ;
    • прозрачность для пользователя;
    • относительная прочность защиты; и
    • тип выполняемой функции (исправление, обнаружение, предотвращение, восстановление, мониторинг и т. д.).

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

    9.4.2. Архитектура безопасности ИТ

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

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

    Домены защиты различаются по одному или нескольким из следующих атрибутов:

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

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

    Существуют и другие, имеющие отношение к архитектуре безопасности ИТ, документы. Например:

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

    9.4.3. Определение ограничивающих факторов

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

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

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

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

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

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

    9.5. Оценка приемлемости остаточного риска

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

    9.6. Политика безопасности системы ИТ

    Политика безопасности системы ИТ должна содержать подробности устанавливаемых СЗ и описывать, почему они необходимы. План по безопасности ИТ описывает порядок установки этих СЗ.

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

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

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

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

    9.7. Создание плана по обеспечению безопасности ИТ

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

    • цель защиты в терминах конфиденциальности, целостности, доступности, учетности, подлинности и надежности;
    • подход к анализу риска для данной системы ИТ (см. ч. 8);
    • оценку остаточного риска, приемлемого после реализации выбранных СЗ;
    • список уже установленных СЗ и средств, выбранных как описано в ч. 9.4, включая оценку их эффективности;
    • ожидаемый уровень капиталовложений в установку и поддержку всех выбранных СЗ; и
    • детальный план работ по установке, включая их приоритет, ответственности персонала, порядок проведения обучения персонала и порядок проведения работ по поддержке СЗ.

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

    10. Порядок осуществления плана безопасности ИТ

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

    10.1. Установка СЗ

    При установке СЗ необходимо строго следовать плану безопасности ИТ. Ответственный за план (обычно это начальник отдела безопасности системы ИТ) должен быть гарантом того, что установка СЗ происходит в соответствии с разработанным планом.

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

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

    10.2. Обучение персонала

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

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

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

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

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

    10.2.1. Анализ новых требований к знаниям персонала по безопасности

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

    10.2.2. Подход организации к обучению

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

    Интерактивные методы (обучающие курсы и т. д.) обеспечивают двустороннюю связь, которая позволяет персоналу, реализующему СУБ ИТ, проверить концепции и требования, которые были получены из анализа требований по безопасности. Содействующие методы (видеокурсы, доска объявлений и т. д.) - это методы обучения, обеспечивающие только одностороннюю связь, которые позволяют отделу, занимающемуся безопасностью, доносить информацию до сотрудников организации в легко доступной форме.

    10.3. Аккредитация СУБ ИТ

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

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

    Аккредитация гарантирует, что меры защиты, реализованные и поддерживаемые в организации, обеспечивают соответствующий уровень защиты. Это верно для определенного окружения и для определенного периода времени, обозначенных в политике или плане безопасности системы ИТ. Любые значительные изменения в установленных СЗ или изменения в процедурах защиты, могут привести к необходимости в повторной аккредитации. Критерии для проведения повторной аккредитации должны быть указаны в план безопасности системы ИТ.

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

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

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

    11. Сопровождение СУБ ИТ

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

    11.1. Поддержание системы в рабочем состоянии

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

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

    Действия сопровождения СУБ ИТ включают:

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

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

    11.2. Порядок проведения ревизии и проверки согласованности системы

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

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

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

    СЗ, защищающие систему ИТ могут быть проверены с помощью:

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

    Важная для выполнения ревизии / проверки согласованности информация относительно работы данной системы ИТ может быть получена с использованием:

    • пакетов программ для записи событий; и
    • контрольных журналов для отслеживания всей хронологии событий.

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

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

    Существует много вещей, требующих определения, например:

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

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

    Защита персонала. Принимаются ли ссылки фактически во внимание? Проверяются ли промежутки в занятости персонала? Действительно ли персонал имеет соответствующую квалификацию в сфере защиты? На сколько сильно зависит выполнение ключевых функций от конкретного сотрудника?

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

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

    Защита средств связи. Есть ли требуемая избыточность? Какова эффективность используемого алгоритма шифрования и определения подлинности сообщений, если это необходимо?

    Ревизия / проверка согласованности является сложной задачей и требует наличия хорошего опыта и знаний у обслуживающего персонала для ее успешного выполнения.

    11.3. Пересмотр СЗ

    Пересмотр СЗ - это процесс, используемый для определения новых требований к системе защиты после проведения изменений в системе ИТ.

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

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

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

    11.4. Мониторинг

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

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

    Мониторинг ценностей системы ИТ проводится для обнаружения изменений в их значении и изменений целей обеспечения безопасности системы ИТ. Возможные причины для этих изменений - это изменения:

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

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

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

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

    Чтобы гарантировать согласованность СЗ с политикой безопасности системы ИТ, должны будут использоваться соответствующие ресурсы для поддержки соответствующего уровня мониторинга:

    • существующих СЗ;
    • введения новых систем или услуг; и
    • запланированных изменений в существующих системах или услугах.

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

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

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

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

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

    12. Резюме

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