Преподаватель который помогает студентам и школьникам в учёбе.

Оценка рисков на различных этапах жизненного цикла ИС

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

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

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

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

1. ЖИЗНЕННЫЙ ЦИКЛ ИС

1.1. Структура жизненного цикла ИС

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

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

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

1.2. Модели жизненного цикла ИС

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

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

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

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

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

В этой модели особое внимание уделяется начальным этапам разработки – выработке стратегии, анализу и проектированию, где реализуемость тех или иных технических решений проверяется и обосновывается посредством создания прототипов (макетирования). Каждый виток спирали предполагает создание фрагмента (компонента) или версии программного продукта. На них уточняются цели и характеристики проекта, определяется его качество и планируются работы следующего витка спирали. Таким образом, углубляются и последовательно конкретизируются детали проекта и в результате выбирается обоснованный вариант, который доводится до реализации. На практике наибольшее распространение получили две основные модели жизненного цикла:
каскадная модель (характерна для периода 1970-1985 гг.);
спиральная модель (характерна для периода после 1986.г.).

1.3. Достоинства и недостатки моделей жизненного цикла ИС

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

Можно выделить следующие положительные стороны применения каскадного подхода:

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

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

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

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

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

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

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

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

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

1.4. Стадии жизненного цикла ИС

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

Согласно методологии, предлагаемой Rational Software, жизненный цикл информационной системы подразделяется на четыре стадии.

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

1) Начальная стадия

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

2) Стадия уточнения

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

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

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

3) Стадия конструирования

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

По окончании этой стадии определяется работоспособность разработанного программного обеспечения.

4) Стадия передачи в эксплуатацию

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

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

1.5 Стандарты жизненного цикла ИС

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

Среди наиболее известных стандартов можно выделить следующие:

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

ISO/IEC 12207(International Organization of Standardization /International Electrotechnical Commission )1995 - стандарт на процессы и организацию жизненного цикла. Распространяется на все виды заказного ПО. Стандарт не содержит описания фаз, стадий и этапов.

Rational Unified Process (RUP) предлагает итеративную модель разработки, включающую четыре фазы: начало, исследование, построение и внедрение. Каждая фаза может быть разбита на этапы (итерации), в результате которых выпускается версия для внутреннего или внешнего использования. Прохождение через четыре основные фазы называется циклом разработки, каждый цикл завершается генерацией версии системы. Если после этого работа над проектом не прекращается, то полученный продукт продолжает развиваться и снова минует те же фазы. Суть работы в рамках RUP - это создание и сопровождение моделей на базе UML.

Microsoft Solution Framework (MSF) сходна с RUP, так же включает четыре фазы: анализ, проектирование, разработка, стабилизация, является итерационной, предполагает использование объектно-ориентированного моделирования. MSF в сравнении с RUP в большей степени ориентирована на разработку бизнес-приложений.

Extreme Programming (XP). Экстремальное программирование (самая новая среди рассматриваемых методологий) сформировалось в 1996 году. В основе методологии командная работа, эффективная коммуникация между заказчиком и исполнителем в течение всего проекта по разработке ИС, а разработка ведется с использованием последовательно дорабатываемых прототипов.

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

2.1 Общие положения

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

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

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

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

По отношению к выявленным рискам возможны следующие действия:

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

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

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

Этапы (6) и (7) относятся к выбору защитных средств (нейтрализации рисков), остальные — к оценке рисков.

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

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

инициация;
закупка (разработка);
установка;
эксплуатация;
выведение из эксплуатации.

Кратко опишем, что может дать управление рисками на каждом из перечисленных этапов.

На этапе инициации известные риски следует учесть при выработке требований к системе вообще и средствам безопасности в частности.

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

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

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

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

2.2. Подготовительные этапы управления рисками

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

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

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

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

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

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

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

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

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

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

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

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

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

2.3. Анализ угроз и оценка рисков

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

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

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

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

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

После идентификации угрозы необходимо оценить вероятность ее осуществления. Допустимо использовать при этом трехбалльную шкалу (низкая (1), средняя (2) и высокая (3) вероятность).

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

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

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

После того, как накоплены исходные данные и оценена степень неопределенности, можно переходить к обработке информации, то есть собственно к оценке рисков. Вполне допустимо применить такой простой метод, как умножение вероятности осуществления угрозы на предполагаемый ущерб. Если для вероятности и ущерба использовать трехбалльную шкалу, то возможных произведений будет шесть: 1, 2, 3, 4, 6 и 9. Первые два результата можно отнести к низкому риску, третий и четвертый — к среднему, два последних — к высокому, после чего появляется возможность снова привести их к трехбалльной шкале. По этой шкале и следует оценивать приемлемость рисков. Правда, граничные случаи, когда вычисленная величина совпала с приемлемой, целесообразно рассматривать более тщательно из-за приближенного характера результата.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Тестирование является проактивным средством безопасности. Тестовый инструментарий включает:

автоматические средства сканирования;
средства тестирования и оценки;
тестирование проникновением.

3.3. Идентификация угроз

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

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

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

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

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

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

3.4. Определение рисков

Для определения рисков можно, оставаясь в рамках трехбалльной шкалы, выбрать для вероятностей реализации угроз значения 0.1, 0.5 и 1.0, а для уровней воздействия — 10, 50 и 100. Тогда, если произведение вероятности на воздействие не превосходит 10, риск можно считать низким. Значения от 10 до 50 соответствуют умеренному риску, свыше 50 — высокому.

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

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

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

3.5. Рекомендуемые контрмеры

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

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

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

3.6. Нейтрализация рисков

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

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

В процессе управления рисками могут использоваться различные возможности:

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

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

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

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

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

Реализацию приведенного правила целесообразно оформить в виде процесса со следующими шагами:

Шаг 1 — ранжирование действий. При выделении ресурсов высший приоритет должен отдаваться неприемлемо высоким рискам, требующим немедленных корректирующих действий. Результат шага 1 — упорядоченный по убыванию приоритетов перечень действий.
Шаг 2 — оценка возможных способов реализации рекомендованных контрмер. Цель состоит в том, чтобы выбрать наиболее подходящие контрмеры, минимизирующие риски. Результат шага 2 — список пригодных регуляторов безопасности.
Шаг 3 — оценка экономической эффективности, выбор наиболее практичных контрмер. Результат шага 3 — отчет об экономическом анализе, описывающий затраты и выгоды от реализации контрмер или от отсутствия таковой.
Шаг 4 — выбор контрмер. По результатам технического и экономического анализа руководство организации выбирает оптимальный способ нейтрализации рисков. Результат шага 4 — список выбранных регуляторов безопасности.
Шаг 5 — распределение обязанностей. Выбираются должностные лица, обладающие достаточной квалификацией для реализации выбранных контрмер. На этих сотрудников возлагаются обязанности по реализации регуляторов безопасности. Результат шага 5 — список ответственных и их обязанностей.
Шаг 6 — разработка плана реализации контрмер. План должен содержать по крайней мере следующие сведения:
- риски (пары уязвимость/угроза) и их уровни, полученные в результате оценки рисков;
- рекомендованные регуляторы безопасности;

действия, упорядоченные по <span class="dash041e_0431_044b_0447_043d_044b_0439__Char" style=" font-family: 'Times New Roman', 'Arial'; font-size: 14pt; text-d

Список литературы

Интуит: Управление рисками http://www.intuit.ru/studies/courses/10/10/lecture/308?page=1
Elibrary: https://elibrary.ru/item.asp?id=28311644
Kazedu: https://www.kazedu.kz/referat/94546/13