МОДЕЛИРОВАНИЕ ОЦЕНКИ ПРИ АУДИТЕ БЕЗОПАСНОСТИ ИНФОРМАЦИОННЫХ СИСТЕМ - Студенческий научный форум

VII Международная студенческая научная конференция Студенческий научный форум - 2015

МОДЕЛИРОВАНИЕ ОЦЕНКИ ПРИ АУДИТЕ БЕЗОПАСНОСТИ ИНФОРМАЦИОННЫХ СИСТЕМ

Красникова Т.В. 1, Невежин В.П. 2
1Федеральное государственное образовательное бюджетное учреждение высшего профессионального образования "Финансовый университет при Правительстве Российской Федерации”, Москва, Россия
2Федеральное государственное образовательное бюджетное учреждение высшего профессионального образования "Финансовый университет при Правительстве Российской Федерации” Москва, Россия
 Комментарии
Текст работы размещён без изображений и формул.
Полная версия работы доступна во вкладке "Файлы работы" в формате PDF

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

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

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

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

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

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

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

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

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

    • представление клиентом объектов, которые необходимо проанализировать;

    • детализированное описание задачи аналитиком;

    • проверка корректности и полноты документация, представленной для анализа;

    • мероприятия по выявлению рисков, (осуществляется, например, в форме семинара) возглавляемые аналитиками;

    • оценка вероятностей и последствий инцидентов информационной безопасности;

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

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

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

  • все существующие риски определены;

  • уязвимости идентифицированы и оценены их уровни;

  • угрозы определены и их уровни оценены;

  • контрмеры показывают себя эффективно;

  • расходы, связанные с информационной безопасностью, оправданы.

Исследование состояния информационной безопасности системы с применением метода CRAMM осуществляется в три стадии:

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

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

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

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

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

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

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

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

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

В процессе разработки стратегии обеспечения безопасности и плана сокращения рисков:

  • описывают текущую стратегию безопасности,

  • выбирают подходы сокращения рисков,

  • разрабатывают план сокращения рисков,

  • определяют изменения в стратегии обеспечения безопасности,

  • определяют перспективные направления обеспечения безопасности.

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

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

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

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

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

Оценка метода OCTAVE. Мониторинг рисков не является сильной стороной метода OCTAVE , несмотря на то, что так же, как и две другие методологии, полностью отвечает критериям категории «Риски». Он предусматривает регулярное проведение оценки рисков и обновление их величин, как части процесса оценки рисков. В случае, когда стратегия управления рисками определена, методика предполагает использование в качестве способов снижения рисков только их снижение и принятие. В методе не используется такой способ управления рисками, как обход (исключение).

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

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

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

Оценка метода CRAMM. Эта методология не учитывает, например, наличие или отсутствие «программ по повышению информированности сотрудников в области информационной безопасности», сопроводительной документации, такой как описание бизнес-процессов или отчетов по проведенным оценкам IT-рисков. В отношении стратегии работы с рисками метод CRAMM предполагает использование только методов их снижения. Такие способы управления рисками, как «обход» или «принятие», не рассматриваются.

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

Анализ метода CRAMM выявил следующие существенные недостатки. В ней отсутствуют:

  • процесс интеграции способов управления и описании назначения того или иного способа;

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

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

Практическое применение метода CRAMM сопряжено:

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

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

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

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

Кроме того, следует отметить высокую стоимость лицензии.

Вывод

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

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

В случае если требуется выполнить только разовую оценку уровня рисков в компании любого размера, целесообразно применять метод CORAS. Для управления рисками на базе периодических оценок на техническом уровне лучше всего подходит метод CRAMM. Метод OCTAVE предпочтителен для использования в крупных компаниях, где предполагается внедрение управления рисками на базе регулярных оценок на уровне не ниже организационного и требуется разработка обоснованного плана мероприятий по их снижению.

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

Варианты доработки методик

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

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

  • мониторинг БИС

  • работа с персоналом

  • возможность переноса рисков (страхование)

  • повторная переоценка

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

  • обход рисков

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

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

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

  • регистрации событий системы

  • мониторинг использования информационной системы

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

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

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

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

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

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

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

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

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

  1. Выявления угроз

  2. Предотвращения угроз

  3. Восстановления системных файлов и баз данных

  4. Исправления системных файлов и баз данных

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

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

  • устранение только последней возникшей ошибки

  • устранять ошибки по цепочке от конца к началу или от начала к концу

  • устранение ошибки, которая находилась в промежутке между самой первой и последней ошибками

  • устранение только первой ошибки

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

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

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

Просмотров работы: 2571