Основные этапы управления рисками

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

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

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

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

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

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

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

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

Ключевые  роли в процессе управления рисками

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

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

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

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

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

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

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

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

Детальное рассмотрение процесса оценки рисков

Процесс оценки рисков можно подразделить на девять основных этапов:

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

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

На  Рис. 1 показаны основные этапы процесса оценки рисков вместе с входной и выходной информацией для каждого из них.

Рисунок 1. Основные этапы процесса оценки рисков, их входная и выходная информация.

Опишем  выделенные этапы более детально.

Определение характеристик  информационной системы

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

О системе необходимо собрать следующую информацию:

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

Требуется также собрать информацию об эксплуатационном окружении системы:

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

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

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

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

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

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

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

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

Идентификация уязвимостей

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

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

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

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

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

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

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