Файл: Оценка рисков на различных этапах жизненного цикла ис.pdf
ВУЗ: Не указан
Категория: Не указан
Дисциплина: Не указана
Добавлен: 12.01.2024
Просмотров: 42
Скачиваний: 2
ВНИМАНИЕ! Если данный файл нарушает Ваши авторские права, то обязательно сообщите нам.
НЕГОСУДАРСТВЕННОЕ ОБРАЗОВАТЕЛЬНОЕ ЧАСТНОЕ УЧРЕЖДЕНИЕ
ВЫСШЕГО ОБРАЗОВАНИЯ
«МОСКОВСКИЙ ФИНАНСОВО-ПРОМЫШЛЕННЫЙ УНИВЕРСИТЕТ
«СИНЕРГИЯ»
Направление/Специальность 09.03.02
(код)
Кафедра ИТ технологий
(аббревиатура)
ЭССЕ
На тему
«
Оценка рисков на различных этапах жизненного цикла ИС»
Обучающийся Жаров Александр Михайлович
Преподаватель Селиверстов Егор Игоревич
Москва 2023
ВВЕДЕНИЕ
Темпы развития современных информационных технологий и основанных на них информационных систем намного опережают разработку рекомендаций и нормативно-правовой базы по оценке рисков на различных этапах жизненного цикла. Поэтому возникает насущная задача оценки уровня безопасности информационной системы, связанная с оценкой рисков: по каким критериям следует оценивать эффективность защиты, как оценивать риски. Поэтому, помимо требований рекомендаций и нормативных актов, мы должны адаптироваться к нашим условиям и применять международные стандарты, а также применять методы количественного анализа рисков в сочетании с оценками экономической эффективности обеспечения безопасности и защиты информации в информационных системах на разных этапах жизненного цикла.
Целью данной работы является изучение и оценка влияния факторов риска на различных этапах информационных систем. Задачи, которые я ставлю перед собой, таковы: ознакомиться с факторами риска; как проводится анализ рисков; какие типы рисков существуют; как риски можно минимизировать.
ЖИЗНЕННЫЙ ЦИКЛ СИСТЕМЫ
Жизненный цикл информационных систем - это период их создания и использования, который охватывает различные состояния, с момента возникновения необходимости в такой системе до момента ее полного вывода из эксплуатации пользователями.
Жизненный цикл информационных систем включает в себя четыре этапа: предварительный проект, планирование проекта, внедрение, функционирование.
Модель жизненного цикла системы включает в себя все фазы жизненного цикла, от создания системы до ее эксплуатации.
Таким образом, жизненный цикл информационной системы включает в себя все этапы ее создания, сопровождения и развития:
- Предпроектный анализ;
- проектирование системы;
- Проектирование системы;
- интеграция и монтаж системы, проведение тестов;
- эксплуатация и техническое обслуживание системы;
- разработка системы.
Модель ИС понимается как структура, которая определяет последовательность выполнения и взаимосвязь процессов, действий и задач, которые выполняются вовремя ИС. Модель ИС зависит от специфики ИС и специфики условий, в которых последняя создается и функционирует.
В настоящее время наиболее широко используются следующие модели
(стратегии) жизненного цикла:
- каскадная;
- поэтапная;
- спиральная.
Каскадная модель подразумевает линейную последовательность шагов по созданию информационной системы. Другими словами, переход от одного этапа к следующему происходит только после того, как работа на текущем этапе полностью завершена.
Эта модель используется при разработке информационных систем, для которых в начале разработки все требования могут быть сформулированы достаточно точно и полно.
Поэтапная стратегия предполагает разработку информационной системы с линейной последовательностью этапов, но в несколько этапов, т.е. с планируемым улучшением продукта. В начале работы над проектом определяются все основные системные требования, а затем он
разрабатывается в виде последовательности версий. Каждая версия представляет собой законченный и функциональный продукт. Первая версия реализует часть запланированных функций, следующая версия реализует дополнительные функции и т.д., пока не будет восстановлена полная система.
Такая модель жизненного цикла характерна для разработки сложных систем, для которых существует четкое видение (как со стороны заказчика, так и со стороны разработчика) того, каким должен быть конечный результат
(информационная система).
Спиральная модель предполагает разработку в виде последовательности версий, но не все требования определены в начале проекта. Требования уточняются при разработке версий.
Такая модель жизненного цикла характерна для разработки инновационных (нетипичных) систем. В начале проектной работы у клиента и разработчика нет четкого представления о конечном продукте (требования не могут быть четко определены) или стопроцентной уверенности в успешной реализации проекта (риски очень велики). В связи с этим принимается решение разрабатывать систему по частям, с возможностью изменения требований или отказа от ее дальнейшей разработки. Разработка проекта может быть завершена не только после этапа внедрения, но и после анализа рисков.
Проанализировав все модели жизненного цикла, мы можем сделать вывод, что разработанная автоматизированная информационная система относится к каскадной модели.
Хорошо известно, что большая часть ИТ-проектов не являются успешными с точки зрения достижения целей, бюджетов или сроков. Во многом такие проблемы связаны с неадекватным и качественным управлением рисками.
Такая модель жизненного цикла характерна для разработки сложных систем, для которых существует четкое видение (как со стороны заказчика, так и со стороны разработчика) того, каким должен быть конечный результат
(информационная система).
Спиральная модель предполагает разработку в виде последовательности версий, но не все требования определены в начале проекта. Требования уточняются при разработке версий.
Такая модель жизненного цикла характерна для разработки инновационных (нетипичных) систем. В начале проектной работы у клиента и разработчика нет четкого представления о конечном продукте (требования не могут быть четко определены) или стопроцентной уверенности в успешной реализации проекта (риски очень велики). В связи с этим принимается решение разрабатывать систему по частям, с возможностью изменения требований или отказа от ее дальнейшей разработки. Разработка проекта может быть завершена не только после этапа внедрения, но и после анализа рисков.
Проанализировав все модели жизненного цикла, мы можем сделать вывод, что разработанная автоматизированная информационная система относится к каскадной модели.
Хорошо известно, что большая часть ИТ-проектов не являются успешными с точки зрения достижения целей, бюджетов или сроков. Во многом такие проблемы связаны с неадекватным и качественным управлением рисками.
РИСКИ И ИХ ТИПЫ
Информационные риски — это потенциальная, измеряемая численно возможность возникновения неблагоприятных ситуаций и связанных с ними последствий в виде ущерба, потерь и неблагоприятных изменений наиболее важных управляемых параметров проекта.
ИТ-риски можно разделить на две группы: риски, связанные с обеспечением непрерывности бизнеса, и риски для новых проектов.
Управление рисками, конечно, охватывает весь цикл проекта, от подготовки до завершения, но самым важным (особенно для контрактов с фиксированными сроками и затратами) будет правильная и "честная" оценка будущих рисков на этапе подготовки проекта.
При анализе проекта можно выявить несколько рисков:
- утечка конфиденциальной информации, утрата интеллектуальной собственности университета в виде научных работ;
- сбои в передаче информации, отказ оборудования. Ни у кого из клиентов нет доступа к серверу и возможности вводить и получать информацию о научных работах, что является нарушением эффективности;
- риск реорганизации научной библиотеки, в результате которой автоматизированная система может прийти в негодность.
АНАЛИЗ УГРОЗ И ОЦЕНКА РИСКОВ
Этапы, предшествующие анализу угроз, можно считать подготовительными, поскольку, строго говоря, они впрямую не связаны с рисками. Риск появляется там, где есть угрозы.
Перечень наиболее распространенных угроз предполагается известным.
К сожалению, с практической точки зрения число угроз оказывается бесконечно большим, причем далеко не все из них носят компьютерный характер. Так вполне реальной угрозой является наличие мышей и тараканов
в помещениях, занимаемых организацией. Первые могут повредить кабели, вторые — вызвать короткое замыкание.
Как правило, наличие той или иной угрозы является следствием уязвимостей в защите информационной системы, которые, в свою очередь, объясняются отсутствием некоторых сервисов безопасности или недостатками в реализующих их защитных механизмах. Опасность прогрызания кабелей исходит не только от мышей, но и от недостаточной прочности защитной оболочки или ее отсутствия.
Первый шаг в анализе угроз — их идентификация. Анализируемые виды угроз следует выбрать из соображений здравого смысла (оставив вне поля зрения, например, землетрясения, однако не исключая возможности захвата организации террористами), но в пределах выбранных видов провести максимально полное рассмотрение.
Целесообразно выявлять не только сами угрозы, но и источники их возникновения, это поможет в выборе дополнительных средств защиты.
Например, нелегальный вход в систему может стать следствием воспроизведения начального диалога, подбора пароля или подключения к сети неавторизованного оборудования. Очевидно, для противодействия каждому из перечисленных способов нелегального входа нужны свои механизмы безопасности.
После идентификации угрозы необходимо оценить вероятность ее осуществления. Допустимо использовать при этом трехбалльную шкалу
(низкая (1), средняя (2) и высокая (3) вероятность).
Кроме вероятности осуществления, важен размер потенциального ущерба. Например, пожары бывают нечасто, но ущерб от каждого из них, как правило, велик. Тяжесть ущерба также можно оценить по трехбалльной шкале.
Оценивая тяжесть ущерба, необходимо иметь в виду не только непосредственные расходы на замену оборудования или восстановление информации, но и более отдаленные, такие как подрыв репутации, ослабление позиций на рынке и т.п. Пусть, например, в результате дефектов в управлении
Как правило, наличие той или иной угрозы является следствием уязвимостей в защите информационной системы, которые, в свою очередь, объясняются отсутствием некоторых сервисов безопасности или недостатками в реализующих их защитных механизмах. Опасность прогрызания кабелей исходит не только от мышей, но и от недостаточной прочности защитной оболочки или ее отсутствия.
Первый шаг в анализе угроз — их идентификация. Анализируемые виды угроз следует выбрать из соображений здравого смысла (оставив вне поля зрения, например, землетрясения, однако не исключая возможности захвата организации террористами), но в пределах выбранных видов провести максимально полное рассмотрение.
Целесообразно выявлять не только сами угрозы, но и источники их возникновения, это поможет в выборе дополнительных средств защиты.
Например, нелегальный вход в систему может стать следствием воспроизведения начального диалога, подбора пароля или подключения к сети неавторизованного оборудования. Очевидно, для противодействия каждому из перечисленных способов нелегального входа нужны свои механизмы безопасности.
После идентификации угрозы необходимо оценить вероятность ее осуществления. Допустимо использовать при этом трехбалльную шкалу
(низкая (1), средняя (2) и высокая (3) вероятность).
Кроме вероятности осуществления, важен размер потенциального ущерба. Например, пожары бывают нечасто, но ущерб от каждого из них, как правило, велик. Тяжесть ущерба также можно оценить по трехбалльной шкале.
Оценивая тяжесть ущерба, необходимо иметь в виду не только непосредственные расходы на замену оборудования или восстановление информации, но и более отдаленные, такие как подрыв репутации, ослабление позиций на рынке и т.п. Пусть, например, в результате дефектов в управлении
доступом к бухгалтерской информации сотрудники получили возможность корректировать данные о собственной заработной плате. Следствием такого состояния дел может стать не только перерасход бюджетных или корпоративных средств, но и полное разложение коллектива, грозящее развалом организации.
Уязвимости обладают свойством притягивать к себе не только злоумышленников. Не всякий устоит перед искушением немного увеличить свою зарплату, если есть уверенность, что это сойдет в рук. Поэтому, оценивая вероятность осуществления угроз, целесообразно исходить не только из среднестатистических данных, но учитывать также специфику конкретных информационных систем. Если в подвале дома, занимаемого организацией, располагается сауна, а сам дом имеет деревянные перекрытия, то вероятность пожара, к сожалению, оказывается существенно выше средней.
После того, как накоплены исходные данные и оценена степень неопределенности, можно переходить к обработке информации, то есть, собственно, к оценке рисков. Вполне допустимо применить такой простой метод, как умножение вероятности осуществления угрозы на предполагаемый ущерб. Если для вероятности и ущерба использовать трехбалльную шкалу, то возможных произведений будет шесть: 1, 2, 3, 4, 6 и 9. Первые два результата можно отнести к низкому риску, третий и четвертый — к среднему, два последних — к высокому, после чего появляется возможность снова привести их к трехбалльной шкале. По этой шкале и следует оценивать приемлемость рисков. Правда, граничные случаи, когда вычисленная величина совпала с приемлемой, целесообразно рассматривать более тщательно из-за приближенного характера результата.
Если какие-либо риски оказались недопустимо высокими, необходимо их нейтрализовать, реализовав дополнительные защитные меры. Как правило, для ликвидации или нейтрализации уязвимости, сделавшей реальной опасную угрозу, существует несколько механизмов безопасности, отличающихся эффективностью и стоимостью. Например, если велика вероятность
Уязвимости обладают свойством притягивать к себе не только злоумышленников. Не всякий устоит перед искушением немного увеличить свою зарплату, если есть уверенность, что это сойдет в рук. Поэтому, оценивая вероятность осуществления угроз, целесообразно исходить не только из среднестатистических данных, но учитывать также специфику конкретных информационных систем. Если в подвале дома, занимаемого организацией, располагается сауна, а сам дом имеет деревянные перекрытия, то вероятность пожара, к сожалению, оказывается существенно выше средней.
После того, как накоплены исходные данные и оценена степень неопределенности, можно переходить к обработке информации, то есть, собственно, к оценке рисков. Вполне допустимо применить такой простой метод, как умножение вероятности осуществления угрозы на предполагаемый ущерб. Если для вероятности и ущерба использовать трехбалльную шкалу, то возможных произведений будет шесть: 1, 2, 3, 4, 6 и 9. Первые два результата можно отнести к низкому риску, третий и четвертый — к среднему, два последних — к высокому, после чего появляется возможность снова привести их к трехбалльной шкале. По этой шкале и следует оценивать приемлемость рисков. Правда, граничные случаи, когда вычисленная величина совпала с приемлемой, целесообразно рассматривать более тщательно из-за приближенного характера результата.
Если какие-либо риски оказались недопустимо высокими, необходимо их нейтрализовать, реализовав дополнительные защитные меры. Как правило, для ликвидации или нейтрализации уязвимости, сделавшей реальной опасную угрозу, существует несколько механизмов безопасности, отличающихся эффективностью и стоимостью. Например, если велика вероятность
нелегального входа в систему, можно приказать пользователям выбирать длинные пароли, задействовать программу генерации паролей или закупить интегрированную систему аутентификации на основе интеллектуальных карт.
Если имеется вероятность умышленного повреждения сервера баз данных, что грозит серьезными последствиями, то можно врезать замок в дверь серверной комнаты или поставить около каждого сервера по охраннику.
ЗАКЛЮЧЕНИЕ
Таким образом, я очень надеюсь, что структура бизнес-процессов предприятия будет автоматизирована в соответствии с общепринятыми рекомендациями и рядом статусных и отраслевых стандартов. Для прикладного программного обеспечения с целью снижения рисков рекомендуется создать набор стандартов на основе архитектуры приложений, шлюзов и интерфейсов. На уровне системы управления базами данных рекомендуется определить требования к интерфейсу для поддержки нужд распределения и интернет-использования. Точно так же должен быть сформирован весь спектр стандартов на уровне операционных систем в телекоммуникациях.
Стандартная поддержка изначально включена в решение, и в будущем, вероятно, будет потрачено наименьшее количество денег на увеличение функциональности системы.
Для минимизации технических рисков обычно рекомендуется поэтапный подход: как можно раньше разработать план работ по выполнению работ, связанных с наибольшим риском; использовать моделирование, создать модели для распознавания технических решений; разработать альтернативы для устранения фактора риска.
Если имеется вероятность умышленного повреждения сервера баз данных, что грозит серьезными последствиями, то можно врезать замок в дверь серверной комнаты или поставить около каждого сервера по охраннику.
ЗАКЛЮЧЕНИЕ
Таким образом, я очень надеюсь, что структура бизнес-процессов предприятия будет автоматизирована в соответствии с общепринятыми рекомендациями и рядом статусных и отраслевых стандартов. Для прикладного программного обеспечения с целью снижения рисков рекомендуется создать набор стандартов на основе архитектуры приложений, шлюзов и интерфейсов. На уровне системы управления базами данных рекомендуется определить требования к интерфейсу для поддержки нужд распределения и интернет-использования. Точно так же должен быть сформирован весь спектр стандартов на уровне операционных систем в телекоммуникациях.
Стандартная поддержка изначально включена в решение, и в будущем, вероятно, будет потрачено наименьшее количество денег на увеличение функциональности системы.
Для минимизации технических рисков обычно рекомендуется поэтапный подход: как можно раньше разработать план работ по выполнению работ, связанных с наибольшим риском; использовать моделирование, создать модели для распознавания технических решений; разработать альтернативы для устранения фактора риска.
Используя строгие стандарты управления проектами при планировании, регистрации хода выполнения проекта, внедрении процедур контроля и управлении изменениями, можно снизить риски управления.
СПИСОК ЛИТЕРАТУРЫ
1.
Управление рисками проекта // Сравни URL: https://www.sravni.ru/
(дата обращения: 24.03.2023).
2.
Риски проекта и все, что нужно о них знать // Elma - система управления бизнес-процессами URL: https://www.elma-bpm.ru/ (дата обращения: 23.03.2023).
3.
Жизненный Цикл Проекта: Простая Формула для Эффективного
Управления // GanttPRO URL: https://blog.ganttpro.com/ (дата обращения:
23.03.2023).
4.
Боронина Л. Н., Сенук З. В. Основы управления проектами. -
Екатеринбург: Изд-во Урал. ун-та, 2020. - 112 с.
5.
В. И. Денисенко, Н. М. Филимонова Управление проектами. -
Владимир: Изд-во ВлГУ, 2020. - 118 с.