9.2. Применение основного подхода
Основной подход предназначен для определения минимального набора средств для защиты системы ИТ организации или ее части. Используя данный подход, возможно применение основной защиты повсеместно в организации, при этом защищая критические для работы или с высокой степенью риска системы ИТ при помощи детального анализа риска. Применимость основного подхода для защиты определяется по результатам классификации компонентов системы по уровню риска, т.е. если требуемый уровень защиты для некоторой компоненты выше, чем может обеспечить применение основного подхода, то следует применить детальный анализ риска для данной компоненты. Также для основного подхода возможно увеличение уровня обеспечиваемой безопасности, однако необходимо помнить, что в данном случае резко возрастает уровень капиталовложений для оценки системы ИТ.
Требования по защите с использование основного подхода могут быть определены из каталогов СЗ, которые рекомендуют определенный набор СЗ системы ИТ против наиболее общих угроз. Детальная оценка риска угроз, уязвимых мест и риска не требуется. Все, что требуется для применения основного подхода - найти в каталоге систему ИТ соответствующую рассматриваемой и сравнить перечисленные в каталоге СЗ с уже имеющимися. Те СЗ, которые не установлены, но перечислены в каталоге, должны быть реализованы.
Существуют каталоги СЗ двух видов: каталоги реальных механизмов защиты и каталоги соответствия между требованиями по безопасности и необходимыми СЗ. Каталоги обоих видов могут быть получены из следующих организаций:
- международных и отечественных комитетов по стандартизации;
- предприятий, разрабатывающих промышленные стандарты и рекомендации в этой области;
- других организаций, использующих подобную систему ИТ и предъявляющих подобные требования по безопасности.
Конечно, кроме того, существует возможность самостоятельного составления каталогов средств обеспечения безопасности, наиболее подходящих для организации.
9.3. Применение детального анализа
Как указано в части 8.3, детальный анализ риска для системы ИТ включает определение относительного риска и его величины. Это делается с помощью определения последствий нежелательного события и оценки вероятности происхождения данного события. Оценка последствий нежелательного события определяется из степени важности ценностей подверженных риску, степени серьезности угроз и характеристик соответствующих уязвимых мест. Вероятность появления зависит от того, насколько привлекательной для потенциального злоумышленника является данная ценность, насколько просто она может быть превращена во что-нибудь менее ценное, от вероятности появления угрозы и от легкости использования уязвимых мест злоумышленником. Результаты анализа риска являются основной информацией, необходимой для определения и выбора СЗ, которые могут быть использованы для уменьшения уровня определенного риска до приемлемого. Составные части детального анализа риска, показанные на рис. 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.6. Политика безопасности системы ИТ
Политика безопасности системы ИТ должна содержать подробности устанавливаемых СЗ и описывать, почему они необходимы. План по безопасности ИТ описывает порядок установки этих СЗ.
Некоторые компоненты системы могут потребовать написания своей собственной политики, которая далее могла бы основываться на результатах анализа риска. Такая ситуация чаще всего случается в больших и сложных системах или в системах, с уникальными по требованиям и характеристикам компонентами. Политика безопасности системы ИТ обычно также базируется на и отражает суть общей (корпоративной) политики безопасности ИТ, т. е. политика безопасности системы ИТ имеет дело с документами более низкого уровня, чем те, с которыми имеет дело общая политика безопасности ИТ. В общем случае, политика безопасности системы ИТ основана на результатах анализа риска и определения требуемых для системы СЗ.
Основная документация, используемая при составлении политики безопасности системы ИТ, вне зависимости от используемого используемой стратегии анализа риска, должна содержать описание СЗ и процедур, необходимых для достижения соответствующего уровня защиты для рассматриваемой системы. Все документы, относящиеся к политике безопасности системы ИТ, вместе должны включать:
- определение рассматриваемой системы ИТ, описание ее компонент и границ (это описание должно содержать описание всей аппаратуры, программного обеспечения, окружения и основной работы системы);
- определение бизнес-целей системы ИТ - они могут существенным образом повлиять на политику безопасности ИТ, выбор подхода анализа риска и на выбор СЗ;
- определение целей обеспечения безопасности данной системы;
- характеристику зависимости нормальной работы организации от рассматриваемой системы;
- уровень капиталовложений в ИТ в терминах цены разработки, поддержки и замены системы ИТ;
- выбранный подход анализа риска;
- список ценностей данной системы ИТ, которые организация желает защитить;
- значение (важность) этих ценностей для организации;
- описание уязвимых мест системы ИТ;
- описание возможных угроз для системы ИТ, включая примерную вероятность их появления;
- значение риска для системы ИТ;
- список устанавливаемых СЗ; и
- предполагаемые расходы, связанные с реализацией данной системы защиты.
Даже, в случае применения основного подхода к защите ИТ, политика безопасности системы ИТ должна содержать информацию по каждому из вышеперечисленных пунктов, однако в некоторых случаях она, возможно, будет менее детальной, чем в случае применения подхода детального анализа.