Инженерное проектирование систем информационной безопасности

Инженерное проектирование систем информационной безопасности

Раздел 1. Предисловие

Проблема информационной безопасности в России в последнее время занимает все более значимые позиции. Правительство Российской Федерации, уделяя особое внимание Федеральной программа «Электронная Россия» требует широкое внедрение информационных систем во все аспекты жизни общества. В том числе сегодня на стимулируется переход на безбумажные технологии бизнеса. Так в 2011 году благодаря изменениям в законодательстве регулирующим отношения связанными с электронной подписью и Приказом Министерства экономики уже сегодня возможен безбумажный обмен основными документами между хозяйствующими субъектами.

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

На сегодняшний день качество программного обеспечения производимого в мире, с точки зрения обеспечения информационной безопасности, в том числе и с точки зрения надежности функционирования и обеспечения целостности хранимых данных не находится на должном уровне. Так по данным аналитического агентства Gartner 65% классов данных обрабатываемых в некоторых информационных системах требуется только в 5%, а около 12% не участвует в формировании ответов в течении последних 12 месяцев, при этом на хранения такого вида данных в мире за 2010 год было потрачено около 129 млрд долларов.

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

Обучение принципам и правилам построения систем информационной безопасности позволяет решить ряд проблем в области информационных технологий поставленных президентом Российской Федерации в «Доктрине информационной безопасности Российской Федерации». В частности:

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

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

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

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

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

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

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

Тема 2.7. Выводы

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

1. управление персоналом

2. обнаруживаемые уязвимости,

3. мониторинг выпущенных исправлений установленного программного обеспечения управление и анализ передаваемых данных

4. управление распространение информации внутри системы.

Параграф. 2.1. Структура ПБ

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

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

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

Тема 3.3. Модель нарушителя

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

Параграф. 3.4. Вывод

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

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

Тема 4.1. Основные определения и критерии классификации угроз

Угроза — это потенциальная возможность определенным образом нарушить информационную безопасность. Попытка реализации угрозы называется атакой, а тот, кто предпринимает такую попытку, — злоумышленником. Потенциальные злоумышленники называются источниками угрозы.
Чаще всего угроза возникает из-за уязвимостей в защите информационных систем (таких, например, как возможность доступа посторонних лиц к критически важному оборудованию или ошибки в программном обеспечении). Промежуток времени от момента, когда появляется возможность использовать уязвимость, и до того, когда она ликвидируется, называется окном опасности, ассоциированным с данной уязвимостью. Пока существует окно опасности, возможны успешные атаки на информационную систему.
Если речь идет об ошибках в ПО, то окно опасности образуется с появлением средств использования ошибки и ликвидируется при наложении "заплат", ее исправляющих. Для большинства уязвимостей окно опасности существует довольно долго (несколько дней, иногда — недели). За это время должны произойти следующие события:
• появляется информация о средствах использования уязвимости;
• выпускаются соответствующие "заплаты";
• "заплаты" устанавливаются в защищаемой информационной системе.
Новые уязвимости и средства их использования появляются постоянно. Это означает, что, во-первых, почти всегда существуют окна опасности, и во-вторых, отслеживание таких окон должно производиться непрерывно, а выпуск и наложение "заплат" — как можно более оперативно.
Отметим, что некоторые угрозы нельзя назвать следствием каких-то ошибок или просчетов; они существуют в силу самой природы современных ИС. Например, угроза отключения электричества или выхода его параметров за допустимые границы происходит по причине зависимости аппаратного обеспечения информационных систем от электропитания.
Рассмотрим наиболее распространенные угрозы, которым подвержены современные информационные системы. Существует много мифов в информационных технологиях о возможных угрозах и уязвимостях (вспомним хотя бы пресловутую "Проблему-2000"). Незнание в данном случае ведет к перерасходу средств и, что еще хуже, к концентрации ресурсов там, где они не особенно нужны, за счет ослабления действительно уязвимых направлений.
Рассмотрим отношение к угрозам с точки зрения типичной (по нашему мнению) организации. Их можно классифицировать по нескольким критериям:
• аспект информационной безопасности, против которого они (угрозы) направлены в первую очередь;
• компонент информационных систем, на который угрозы нацелены (данные, программы, аппаратура, поддерживающая инфраструктура);
• способ осуществления угроз (случайные/преднамеренные действия природного/техногенного характера);
• расположение источника угроз (внутри/вне рассматриваемой ИС).
В качестве основного критерия мы будем использовать первый (аспект ИБ), привлекая при необходимости остальные.

Параграф. 1.6. Выводы

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

Раздел 6. Инсталляция СЗИ

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

Раздел 7. Эксплуатация СЗИ

Процесс эксплуатации рассматривается на примере защиты персональных данных* согласно требованиям 152-ФЗ.

*персональные данные - любая информация, относящаяся к прямо или косвенно определенному или определяемому физическому лицу (субъекту персональных данных)

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

Тема 8.9. Планирование перехода на аварийный режим

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

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

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

Тема 8.10. Выводы

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

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

Тема 9.5. Выводы

Во многих крупных компаниях внедрена служба поддержки Service Desk, в обязанности которой входит управление инцидентами в области информационных технологий. Процедура управления ИТ-инцидентами регулируется стандартом ISO/IEC 20000:2005, пришедшим на смену BS 15000:2002, который, в свою очередь, взял за основу библиотеку ITIL. Заметим, что все ISO/IEC серий 9000, 14000, 20000, 27000 и другие стандарты ISO/IEC, описывающие правила создания систем управления различными процессами, гармонично сочетаются друг с другом. Все они в качестве основы управления подконтрольными процессами используют процессный подход, который рассматривает управление как процесс, а именно как набор взаимосвязанных непрерывных действий. Процессный подход акцентирует внимание на достижении поставленных целей, а также на ресурсах, затраченных для этого. Кроме этого, стандарты указанных серий используют модель PDCA как структуру жизненного цикла всех процессов системы управления.

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

Раздел 10. Аудит системы защиты информации

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

В общем случае под аудитом понимают независимую экспертизу отдельных областей функционирования организации. Различают внешний и внутренний аудит. Внешний аудит – это, как правило, разовое мероприятие, проводимое по инициативе руководства организации или акционеров. Рекомендуется проводить внешний аудит регулярно, а, например, для многих финансовых организаций и акционерных обществ это является обязательным требованием. Внутренний аудит представляет собой непрерывную деятельность, которая осуществляется на основании «Положения о внутреннем аудите» и в соответствии с планом, подготовка которого осуществляется подразделением внутреннего аудита и утверждается руководством организации. Аудит безопасности информационных систем является одной из составляющих ИТ аудита. Целями проведения аудита безопасности являются:
• анализ рисков, связанных с возможностью осуществления угроз безопасности в отношении ресурсов ИС
• оценка текущего уровня защищенности ИС;
• локализация узких мест в системе защиты ИС;
• оценка соответствия ИС существующим стандартам в области информационной безопасности;
• выработка рекомендаций по внедрению новых и повышению эффективности существующих механизмов безопасности ИС.

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

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

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

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

Тема 10.9. Подготовка отчетных документов

Аудиторский отчет является основным результатом проведения аудита. Его качество характеризует качество работы аудитора. Структура отчета может существенно различаться в зависимости от характера и целей проводимого аудита. Однако определенные разделы должны обязательно присутствовать в аудиторском отчете. Он должен, по крайней мере, содержать описание целей проведения аудита, характеристику обследуемой ИС, указание границ проведения аудита и используемых методов, результаты анализа данных аудита, выводы, обобщающие эти результаты и содержащие оценку уровня защищенности АС или соответствие ее требованиям стандартов, и, конечно, рекомендации аудитора по устранению существующих недостатков и совершенствованию системы защиты.
Для примера, приведем образец структуры аудиторского отчета по результатам анализа рисков, связанных с осуществлением угроз безопасности в отношении обследуемой информационной системы.
Структура отчета по результатам аудита безопасности ИС и анализу рисков
1. Вводная часть
1.1 Введение
1.2 Цели и задачи проведения аудита
1.3 Описание ИС
1.3.1 Назначение и основные функции системы
1.3.2 Группы задач, решаемых в системе
1.3.3 Классификация пользователей ИС
1.3.4 Организационная структура обслуживающего персонала ИС
1.3.5 Структура и состав комплекса программно-технических средств ИС
1.3.6 Виды информационных ресурсов, хранимых и обрабатываемых в системе
1.3.7 Структура информационных потоков
1.3.8 Характеристика каналов взаимодействия с другими системами и точек входа
1.4 Границы проведения аудита
1.4.1 Компоненты и подсистемы ИС, попадающие в границы проведения аудита
1.4.2 Размещение комплекса программно-технических средств ИС по площадкам (помещениям)
1.4.3 Основные классы угроз безопасности, рассматриваемых в ходе проведения аудита
1.5 Методика проведения аудита
1.5.1 Методика анализа рисков
1.5.2 Исходные данные
1.5.3 Этапность работ
1.6 Структура документ
2. Оценка критичности ресурсов ИС
2.1 Критерии оценки величины возможного ущерба, связанного с осуществлением угроз безопасности
2.2 Оценка критичности информационных ресурсов
2.2.1 Классификация информационных ресурсов
2.2.2 Оценка критичности по группам информационных ресурсов
2.3 Оценка критичности технических средств
2.4 Оценка критичности программных средств
2.5 Модель ресурсов ИС, описывающая распределение ресурсов по группам задач
3. Анализ рисков, связанных с осуществлением угроз безопасности в отношении ресурсов ИС
3.1 Модель нарушителя информационной безопасности
3.1.1 Модель внутреннего нарушителя
3.1.2 Модель внешнего нарушителя
3.2 Модель угроз безопасности и уязвимостей информационных ресурсов
3.2.1 Угрозы безопасности, направленные против информационных ресурсов
3.2.1.1 Угрозы несанкционированного доступа к информации при помощи программных средств
3.2.1.2 Угрозы, осуществляемые с использованием штатных технических средств
3.2.1.3 Угрозы, связанные с утечкой информации по техническим каналам
3.2.2 Угрозы безопасности, направленные против программных средств
3.2.3 Угрозы безопасности направленные против технических средств
3.3 Оценка серьезности угроз безопасности и величины уязвимостей
3.3.1 Критерии оценки серьезности угроз безопасности и величины уязвимостей
3.3.2 Оценка серьезности угроз
3.3.3 Оценка величины уязвимостей
3.4 Оценка рисков для каждого класса угроз и группы ресурсов
4. Выводы по результатам обследования
5. Рекомендации
5.1 Рекомендуемые контрмеры организационного уровня
5.2 Рекомендуемые контрмеры программно-технического уровня

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

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

Параграф. 10.1. CRAMM

Метод CRAMM (the UK Goverment Risk Analysis and Managment Method) [16] был разработан Службой Безопасности Великобритании (UK Security Service) по заданию Британского правительства и взят на вооружение в качестве государственного стандарта. Он используется, начиная с 1985 г. правительственными и коммерческими организациями Великобритании. За это время CRAMM приобрел популярность во всем мире. Фирма Insight Consulting Limited занимается разработкой и сопровождением одноименного программного продукта, реализующего метод CRAMM.
Метод CRAMM выбран нами для более детального рассмотрения и это не случайно. В настоящее время CRAMM – это довольно мощный и универсальный инструмент, позволяющий, помимо анализа рисков, решать также и ряд других аудиторских задач, включая:
• Проведение обследования ИС и выпуск сопроводительной документации на всех этапах его проведения;
• Проведение аудита в соответствии с требованиями Британского правительства, а также стандарта BS 7799:1995 — Code of Practice for Information Security Management BS7799;
• Разработка политики безопасности и плана обеспечения непрерывности бизнеса.
В основе метода CRAMM лежит комплексный подход к оценке рисков, сочетая количественные и качественные методы анализа. Метод является универсальным и подходит как для больших, так и для мелких организаций, как правительственного, так и коммерческого сектора. Версии программного обеспечения CRAMM, ориентированные на разные типы организаций, отличаются друг от друга своими базами знаний (profiles). Для коммерческих организаций имеется Коммерческий профиль (Commercial Profile), для правительственных организаций – Правительственный профиль (Government profile). Правительственный вариант профиля, также позволяет проводить аудит на соответствие требованиям американского стандарта ITSEC («Оранжевая книга»).[17]
Грамотное использование метода CRAMM позволяет получать очень хорошие результаты, наиболее важным из которых, пожалуй, является возможность экономического обоснования расходов организации на обеспечение информационной безопасности и непрерывности бизнеса. Экономически обоснованная стратегия управления рисками позволяет, в конечном итоге, экономить средства, избегая неоправданных расходов.
CRAMM предполагает разделение всей процедуры на три последовательных этапа. Задачей первого этапа является ответ на вопрос: «Достаточно ли для защиты системы применения средств базового уровня, реализующих традиционные функции безопасности, или необходимо проведение более детального анализа?» На втором этапе производится идентификация рисков и оценивается их величина. На третьем этапе решается вопрос о выборе адекватных контрмер.
Методика CRAMM для каждого этапа определяет набор исходных данных, последовательность мероприятий, анкеты для проведения интервью, списки проверки и набор отчетных документов.
Если по результатам проведения первого этапа, установлено, что уровень критичности ресурсов является очень низким и существующие риски заведомо не превысят некоторого базового уровня, то к системе предъявляются минимальный набор требований безопасности. В этом случае большая часть мероприятий второго этапа не выполняется, а осуществляется переход к третьему этапу, на котором генерируется стандартный список контрмер для обеспечения соответствия базовому набору требований безопасности.
На втором этапе производится анализ угроз безопасности и уязвимостей. Исходные данные для оценки угроз и уязвимостей аудитор получает от уполномоченных представителей организации в ходе соответствующих интервью. Для проведения интервью используются специализированные опросники.
На третьем этапе решается задача управления рисками, состоящая в выборе адекватных контрмер.
Решение о внедрении в систему новых механизмов безопасности и модификация старых принимает руководство организации, учитывая связанные с этим расходы, их приемлемость и конечную выгоду для бизнеса. Задачей аудитора является обоснование рекомендуемых контрмер для руководства организации.
В случае принятия решения о внедрении новых контрмер и модификации старых, на аудитора может быть возложена задача подготовки плана внедрения новых контрмер и оценки эффективности их использования. Решение этих задач выходит за рамки метода CRAMM.

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

Процедура аудита в методе CRAMM является формализованной. На каждом этапе генерируется довольно большое количество промежуточных и результирующих отчетов.
Так, на первом этапе создаются следующие виды отчетов:
• Модель ресурсов, содержащая описание ресурсов, попадающих в границы исследования, и взаимосвязей между ними;
• Оценка критичности ресурсов;
• Результирующий отчет по первому этапу анализа рисков, в котором суммируются результаты, полученные в ходе обследования.
• На втором этапе проведения обследования создаются следующие виды отчетов:
• Результаты оценки уровня угроз и уязвимостей;
• Результаты оценки величины рисков;
• Результирующий отчет по второму этапу анализа рисков.
• По результатам третьего этапа обследования создаются следующие виды отчетов:
• Рекомендуемые контрмеры;
• Детальная спецификация безопасности;
• Оценка стоимости рекомендуемых контрмер;
• Список контрмер, отсортированный в соответствии с их приоритетами;
• Результирующий отчет по третьему этапу обследования;
• Политика безопасности, включающая в себя описание требований безопасности, стратегий и принципов защиты ИС;
• Список мероприятий по обеспечению безопасности.
Грамотно применять метод CRAMM в состоянии только высококвалифицированный аудитор, прошедший обучение. Если организация не может себе позволить содержать в штате такого специалиста, тогда самым правильным решением будет приглашение аудиторской фирмы, располагающей штатом специалистов, имеющих практический опыт применения метода CRAMM.
Обобщая практический опыт использования метода CRAMM при проведении аудита безопасности, можно сделать следующие выводы, относительно сильных и слабых сторон этого метода.[17]

К сильным сторонам метода CRAMM относится следующее:
• CRAMM является хорошо структурированным и широко опробованным методом анализа рисков, позволяющим получать реальные практические результаты;
• Программный инструментарий CRAMM может использоваться на всех стадиях проведения аудита безопасности ИС;
• В основе программного продукта лежит достаточно объемная база знаний по контрмерам в области информационной безопасности, базирующаяся на рекомендациях стандарта BS 7799;
• Гибкость и универсальность метода CRAMM позволяет использовать его для аудита ИС любого уровня сложности и назначения;
• CRAMM можно использовать в качестве инструмента для разработки плана непрерывности бизнеса и политик информационной безопасности организации;
• CRAMM может использоваться в качестве средства документирования механизмов безопасности ИС.
К недостаткам метода CRAMM можно отнести следующее:
• Использование метода CRAMM требует специальной подготовки и высокой квалификации аудитора;
• CRAMM в гораздо большей степени подходит для аудита уже существующих ИС, находящихся на стадии эксплуатации, нежели чем для ИС, находящихся на стадии разработки;
• Аудит по методу CRAMM – процесс достаточно трудоемкий и может потребовать месяцев непрерывной работы аудитора;
• Программный инструментарий CRAMM генерирует большое количество бумажной документации, которая не всегда оказывается полезной на практике;
• CRAMM не позволяет создавать собственные шаблоны отчетов или модифицировать имеющиеся;
• Возможность внесения дополнений в базу знаний CRAMM не доступна пользователям, что вызывает определенные трудности при адаптации этого метода к потребностям конкретной организации.

Параграф. 10.2. RiskWatch