Случай неправильного использования
Случай неправильного использования — это инструмент моделирования бизнес-процессов , используемый в индустрии разработки программного обеспечения. Термин «случай неправильного использования» или «случай неправильного использования» произошел от варианта использования и является его противоположностью . [1] Этот термин впервые был использован в 1990-х годах Гуттормом Синдре из Норвежского университета науки и технологий и Андреасом Л. Опдалом из Бергенского университета , Норвегия. Он описывает процесс выполнения вредоносного действия против системы, а вариант использования может использоваться для описания любого действия, предпринятого системой. [2]
Обзор [ править ]
Варианты использования определяют требуемое поведение программного обеспечения и других разрабатываемых продуктов и, по сути, представляют собой структурированные истории или сценарии, подробно описывающие нормальное поведение и использование программного обеспечения. С другой стороны, случай неправильного использования выявляет то, чего не должно происходить (т. е. негативный сценарий), и выявленные таким образом угрозы помогают определить новые требования, которые выражаются как новые варианты использования.
Этот инструмент моделирования имеет несколько сильных сторон:
- Это позволяет придать равный вес функциональным и нефункциональным требованиям (например, требованиям безопасности, требованиям платформы и т. д.), что может быть невозможно с помощью других инструментов.
- Это подчеркивает безопасность с самого начала процесса проектирования и помогает избежать поспешных проектных решений.
- Это инструмент для улучшения взаимодействия между разработчиками и заинтересованными сторонами, который ценен для обеспечения согласия по критическим системным решениям и анализу компромиссов. [3]
- Создание случаев неправильного использования часто запускает цепную реакцию, которая облегчает выявление функциональных и нефункциональных требований. Обнаружение случая неправильного использования часто приводит к созданию нового варианта использования, который действует как контрмера. Это, в свою очередь, может стать предметом нового дела о неправомерном использовании. [4]
- По сравнению с другими инструментами он лучше относится к вариантам использования и UML и облегчает беспрепятственное использование модели.
Его самый большой недостаток – простота. Его необходимо сочетать с более мощными инструментами для разработки адекватного плана реализации проекта. Еще одним недостатком является отсутствие структуры и семантики.
От случая использования к неправильному использованию [ править ]
В отрасли важно описать поведение системы, когда она отвечает на запрос, исходящий извне: варианты использования [5] стали популярными из-за требований [1] Между инженерами благодаря таким функциям, как техника визуального моделирования, они описывают систему с точки зрения актера, и ее формат явно передает цели каждого актера и потоки, которые система должна реализовать для их достижения. [6]
Уровень абстракции модели вариантов использования делает ее подходящей отправной точкой для проектирования благодаря использованию диаграмм вариантов использования UML и языка конечного пользователя или эксперта в предметной области. Но при анализе безопасности программного обеспечения разработчикам следует обращать внимание на негативные сценарии и понимать их. зародилось понятие «обратный вариант использования» Именно поэтому в 1990-е годы в Норвегии .
Контраст между случаем неправильного использования и вариантом использования является целью: случай неправильного использования описывает потенциальное поведение системы, которое заинтересованные стороны системы считают неприемлемым или, как сказали Гутторм Синдре и Андреас Л. Опдал, «функцию, которую система не должна допускать». [1] Это различие есть и в сценариях: «позитивный» сценарий — это последовательность действий, ведущих к достижению Цели, желаемой человеком или организацией, а «негативный» — сценарий, цель которого нежелательна для реализации рассматриваемой организацией. или желаемый враждебным агентом (не обязательно человеком). [7]
Другое описание разницы [8] который определяет вариант использования как завершенную последовательность действий, которая дает повышенную ценность для пользователя, можно определить вариант неправильного использования как завершенную последовательность действий, которая приводит к убыткам для организации или какой-либо конкретной заинтересованной стороны.
В «хорошем» и «плохом» случае язык представления сценария является общим: диаграммы вариантов использования формально включены в два языка моделирования, определенные OMG : унифицированный язык моделирования (UML) и язык системного моделирования (SysML). ), и такое использование рисования агентов и случаев неправильного использования сценария явно помогает сосредоточить вниманиена этом. [9]
Область использования [ править ]
Случаи неправильного использования чаще всего используются в сфере безопасности. [10] В связи с постоянно растущей важностью ИТ-систем для каждой компании стало жизненно важно развивать возможности защиты своих данных. [11]
Следовательно, например, случай неправильного использования может быть использован для определения того, что хакер хотел бы сделать с системой, и определения его или ее требований. Затем разработчик или дизайнер может определить требования пользователя и хакера в одной и той же диаграмме UML, что, в свою очередь, помогает выявить риски безопасности системы. [12]
Основные понятия [ править ]
Диаграмма вариантов использования создается вместе с соответствующей диаграммой вариантов использования. В модели представлены две новые важные сущности (в дополнение к сущностям традиционной модели вариантов использования — варианту использования и субъекту ):
- Случай неправильного использования : последовательность действий, которые может выполнить любое физическое или юридическое лицо с целью нанести вред системе.
- Злоумышленник : Лицо, инициирующее случай неправомерного использования. Это может быть сделано намеренно или случайно.
Диаграммы [ править ]
Модель вариантов использования использует те типы отношений, которые имеются в модели вариантов использования; включать , расширять , обобщать и связывать . Кроме того, он вводит два новых отношения, которые будут использоваться в диаграмме:
- смягчает
- Вариант использования может снизить вероятность успешного завершения варианта неправильного использования.
- угрожает
- Случай неправильного использования может угрожать варианту использования, например, используя его в своих целях или препятствуя достижению целей.
Эти новые концепции вместе с существующими из варианта использования дают следующую метамодель, которая также представлена на рис. 2 в Синдре и Опдале (2004). [2]
Описания [ править ]
Существует два разных способа текстового описания случая неправильного использования; одно из них встроено в шаблон описания варианта использования, куда дополнительное поле описания под названием «Угрозы» можно добавить . Это поле, в котором могут быть заполнены шаги случая неправильного использования (и альтернативные шаги). Это называется упрощенным режимом описания случая неправильного использования.
Другой способ описания случая неправильного использования — использовать только для этой цели отдельный шаблон. Предлагается наследовать некоторые поля из описания варианта использования ( Имя , Краткое описание , Автор и Дата ). Он также адаптирует поля «Базовый путь» и «Альтернативный путь» , где они теперь описывают пути случаев неправильного использования, а не вариантов использования. Помимо этого, предлагается использовать еще несколько полей:
- Название случая неправомерного использования
- Краткое содержание
- Автор
- Дата
- Основной путь
- Альтернативные пути
- Точки смягчения последствий
- Точки расширения
- Триггеры
- Предварительные условия
- Предположения
- Гарантия смягчения последствий
- Связанные бизнес-правила
- Потенциальный профиль злоумышленника
- Заинтересованные стороны и угрозы
- Терминология и пояснения
- Объем
- Уровень абстракции
- Уровень точности
Как можно понять, приведенный выше список слишком обширен, чтобы каждый раз заполнять его полностью. Не все поля обязательны для заполнения вначале, поэтому его следует рассматривать как живой документ. Также ведутся споры о том, начинать ли с диаграмм или с описаний. Рекомендация, данная Синдре и Опдалом по этому поводу, заключается в том, что это следует делать так же, как и в случае со сценариями использования.
Синдре и Опдал предлагают следующие 5 шагов по использованию случаев злоупотребления для определения требований безопасности:
- Определить критические активы в системе
- Определите цели безопасности для каждого актива
- Определите угрозы для каждой из этих целей безопасности, определив заинтересованные стороны, которые могут захотеть причинить вред системе.
- Выявляйте и анализируйте риски угроз, используя такие методы, как оценка рисков.
- Определить требования безопасности для рисков.
В качестве поддержки в этом пятиэтапном процессе предлагается использовать хранилище повторно используемых случаев неправильного использования.
Исследования [ править ]
Текущая область исследований [ править ]
Текущие исследования случаев неправильного использования в первую очередь сосредоточены на улучшениях безопасности, которые они могут привнести в проект, в частности в проекты программного обеспечения. Рассматриваются пути более широкого внедрения практики разработки сценариев неправильного использования на более ранних этапах разработки приложений: чем раньше обнаружен недостаток, тем легче найти исправление и тем меньше это повлияет на конечную стоимость продукта. проект.
Другие исследования направлены на улучшение ситуации со злоупотреблением для достижения конечной цели: [13] «Есть недостатки в процессе подачи заявок, а результаты слишком общие и могут привести к недоопределению или неправильному толкованию их концепций». Кроме того, они предлагают «рассмотреть случай неправильного использования в свете эталонной модели управления рисками безопасности информационных систем (ISSRM)», чтобы получить процесс управления рисками безопасности.
Будущее улучшение [ править ]
Случаи неправильного использования хорошо известны исследователям. Множество исследований по этому вопросу демонстрируют знания, но за пределами академического мира случай злоупотребления не получил широкого распространения.
Как предполагают Синдре и Опдал (родители концепции случаев неправомерного использования): «Еще одной важной целью дальнейшей работы является содействие более широкому промышленному внедрению случаев неправомерного использования». [2] В той же статье они предлагают встроить случай неправильного использования в инструмент моделирования вариантов использования и создать «базу данных» стандартных случаев неправильного использования в помощь архитекторам программного обеспечения. Заинтересованные стороны системы должны создать свои собственные таблицы случаев неправильного использования для требований, специфичных для их собственных проблемных областей. После разработки база данных знаний может уменьшить количество стандартных недостатков безопасности, используемых лямбда-хакерами.
Другие исследования были сосредоточены на возможных недостающих конкретных решениях в случае неправильного использования: как [14] написал: «Хотя этот подход может помочь в выявлении требований безопасности на высоком уровне, он не показывает, как связать случаи неправомерного использования с законным поведением и конкретными активами; поэтому неясно, какой случай неправомерного использования следует рассматривать и в каком контексте ". Эту критику можно было бы устранить с помощью предложений и улучшений, представленных в разделе о прецедентах.
Стандартизация случая неправильного использования как части нотации UML может позволить ему стать обязательной частью разработки проекта. «Может быть полезно создать специальную нотацию для функций безопасности или контрмер, которые были добавлены для уменьшения уязвимостей и угроз». [15]
См. также [ править ]
- Диаграмма вариантов использования
- Действия бизнес-аналитика по сбору требований безопасности на основе случаев неправомерного использования [1]
- Обработка исключений
- Модель угроз (программное обеспечение)
Ссылки [ править ]
- ^ Jump up to: Перейти обратно: а б с Синдре и Опдал (2001). « Учет требований безопасности на основе случаев неправомерного использования »
- ^ Jump up to: Перейти обратно: а б с Синдре и Опдал (2004). « Выявление требований безопасности в случаях неправильного использования. Архивировано 16 июля 2011 г. на Wayback Machine ».
- ^ Первоначальный промышленный опыт случаев неправильного использования в анализе компромиссов (2002, Ян Александр). Архивировано 30 апреля 2008 г. в Wayback Machine.
- ^ Ян Александер, Случаи неправильного использования: случаи использования с враждебными намерениями. Программное обеспечение IEEE , Том 20, № 1, январь-февраль 2003 г., 58–66. DOI: 10.1109/MS.2003.1159030
- ^ Джейкобсон, «Объектно-ориентированная разработка программного обеспечения: подход, основанный на сценариях использования», 1992 Аддисон-Уэсли, Бостон
- ^ Гуннар Петерсон, Джон Стивен «Определение неправильного использования в процессе разработки», IEEE SECURITY & PRIVACY, НОЯБРЬ/ДЕКАБРЬ 2006 г.
- ^ Ян Александр «Случай неправильного использования: случаи использования с враждебными намерениями», презентация
- ^ Гутторм Синдре, Андреас Л. Опдал, «Шаблоны для описания случаев неправомерного использования»
- ^ Ян Александр «Случай неправильного использования: случаи использования с враждебными намерениями»
- ^ Асоке К. Талукдер; Маниш Чайтанья (17 декабря 2008 г.). Архитектура безопасных программных систем . ЦРК Пресс. п. 47. ИСБН 978-1-4200-8784-0 . Проверено 5 октября 2016 г.
- ^ Йеспер М. Йоханссон; Стив Райли (27 мая 2005 г.). Защитите свою сеть Windows: от периметра до данных . Аддисон-Уэсли Профессионал. п. 491 . ISBN 978-0-321-33643-9 . Проверено 5 октября 2016 г.
- ^ Асоке К. Талукдер; Маниш Чайтанья (17 декабря 2008 г.). Архитектура безопасных программных систем . ЦРК Пресс. п. 50. ISBN 978-1-4200-8784-0 . Проверено 5 октября 2016 г.
- ^ Раймундас Матулявичюс, Николас Майер, Патрик Хейманс, «Согласование случаев неправомерного использования с управлением рисками безопасности»
- ^ Фабрисио А. Браз, Эдуардо Б. Фернандес, Майкл ВанХильст, «Выявление требований безопасности посредством неправомерного использования»
- ^ Лилиан Рёстад, «Расширенное обозначение случаев неправильного использования: включая уязвимости и внутреннюю угрозу»
