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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

9.4. Выбор СЗ

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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