В моей предыдущей статье «Что такое безопасность» Я писал о безопасности программного обеспечения.
В ней я попытался проиллюстрировать два утверждения.
Первое утверждение заключается в том, что безопасность — это нефункциональное свойство программы и определяется не тем, что программа делает, а тем, чего она не делает. Второе утверждение, очень тесно связанное с первым, заключается в том, что «функции безопасности» являются антифункциями: они лишают пользователей возможностей, которые не должны иметь доступа к некоторым функциям программного обеспечения.
В частности, это означает, что функции безопасности, как одно из средств достижения этой самой безопасности, не могут быть описаны так же, как описывается «обычный» базовый функционал.
Для этой цели необходимо использовать другие подходы.
На сегодняшний день предложено несколько методов решения этой проблемы.
Одним из наиболее популярных из них является метод случаев злоупотребления, которому посвящена данная статья.
Где это описано Метод описания и анализа требований безопасности с использованием случаев злоупотреблений был впервые предложен более 10 лет назад. Ее авторами являются два специалиста: Гутторм Синдре и Андреас Лоте Опдал [1].
Впоследствии они существенно развили этот метод [2,3,4].
Другой специалист, Ян Александер, дополнил подход автора и предложил новые приложения [5,6,7].
Рекомендую прочитать статьи по ссылкам всем, кто интересуется и хотел бы серьезно познакомиться с использованием вариантов злоупотреблений.
Я также рекомендую воспользоваться поиском в Интернете и посмотреть новейшие материалы, так как метод продолжает исследоваться и развиваться.
В остальном я попытаюсь кратко описать этот подход и продемонстрировать его использование на очень простом, тривиальном примере.
Расширение вариантов использования Я думаю, каждый, кто читает эту статью, теперь знает, что функциональные требования к программному обеспечению часто описываются с помощью вариантов использования.
Каждый вариант использования представляет собой последовательность действий, в ходе которых от начала до конца законный пользователь решит одну из своих задач, достигнет одной из своих целей, используя функции программы.
То есть варианты использования описывают, что должна делать программа.
Но мы хотим описать то, чего программа делать не должна.
Вот для чего нужны варианты злоупотреблений.
Варианты злоупотреблений являются расширением вариантов использования.
Каждый из этих вариантов описывает способ, с помощью которого злоумышленник может достичь одной из своих целей, нанеся при этом ущерб владельцу системы.
Наряду со случаями злоупотреблений создаются варианты использования, описывающие работу функций безопасности, предназначенных для предотвращения нежелательного использования программы.
Как и в случае с вариантами использования, случаи злоупотреблений могут быть представлены либо в графической, либо в тестовой форме.
Конечно, как и в случае чистого использования, приемлема любая комбинация графических диаграмм и текста.
При графическом представлении информации случаи злоупотреблений объединяются со вариантами использования.
Чтобы дифференцировать их, добавляются несколько новых элементов и несколько отношений между ними, представляющих первые.
Сначала добавляется элемент, обозначающий нарушителя.
Если один и тот же человек может выступать и как легитимный пользователь, и как злоумышленник, то он появляется на диаграмме дважды: один раз как легитимный пользователь и один раз как злоумышленник.
Графически нарушитель обозначается так же, как и легитимный пользователь, но выделяется другим цветом.
Во-вторых, добавляется элемент, обозначающий цель злоумышленника.
Этот элемент, вариант злоупотребления, помечен так же, как и цель законного пользователя, вариант использования.
Чтобы отличить вариант использования от случая злоупотребления, последний обозначается другим цветом, как и нарушитель.
В-третьих, добавляются два отношения.
Отношение «угрожать» означает тот факт, что заданная цель злоумышленника может быть достигнута с использованием заданной функциональности системы.
Отношение «смягчение» означает тот факт, что данная функция безопасности используется для уменьшения опасности данного варианта злоупотребления.
При представлении вариантов злоупотреблений в тексте вводятся шаблоны, соответствующие новым графическим элементам, и новые поля в шаблонах, соответствующие новым связям.
Этих расширений оказывается вполне достаточно для описания функциональных требований безопасности.
Самая простая система Для знакомства с методом рассмотрим предельно упрощенный пример.
Допустим, у нас есть программа, которая позволяет читать определенный документ. 
Очевидно, что любой, включая неавторизованных пользователей, может прочитать один и тот же документ, используя одни и те же функции.
Добавим описание этого факта на диаграмму.
Так мы получили описание существующей в нашей программе уязвимости: возможность неавторизованному пользователю получить доступ к конфиденциальному документу.
И мы хотим найти способ устранить это.
Мы можем решить, что контроль доступа может предотвратить использование функций во вред нам.
Чтобы контролировать доступ, мы должны предварительно аутентифицировать пользователя.
Мы потребуем от пользователя ввести имя и пароль.
Проанализировав получившийся проект, мы заметим, что аутентификацию можно обойти, подобрав пароль.
Добавим этот факт на диаграмму.
Для устранения обнаруженной уязвимости мы потребуем, чтобы программа обнаружила несколько последовательных неудачных попыток ввода пароля и заблокировала соответствующего пользователя.
Анализ получившегося проекта показывает, что злоумышленник, возможно, отличный от первого, смог заблокировать работу авторизованного пользователя.
Предположим, на этом этапе мы решаем, что можем терпеть такую блокировку.
Поскольку уязвимостей, требующих устранения, не осталось, анализ можно считать завершенным.
Таким образом, мы получили описание: функционала программы, слабых мест, связанных с этим функционалом и функций безопасности, призванных снизить уязвимость программы.
На диаграмме также указаны уязвимости программы, существование которых считается допустимым.
Чего не хватает в этом примере Пример, приведенный в предыдущем разделе, крайне примитивен и неполн.
Чтобы проиллюстрировать, как работать с методом, большего и не нужно.
Но хотелось бы все же обратить внимание на недостающую информацию, которая принципиально необходима для адекватного анализа требований функциональной безопасности.
Не хватает делового контекста.
Давайте помнить, что с помощью вариантов злоупотреблений мы описываем способы, которыми обидчик:
- достигает своих целей;
- вредит владельцу системы.
Может существовать несколько групп потенциальных нарушителей, различающихся по этим параметрам.
Нам также необходимо понять, какие события могут нанести ущерб владельцу программы и оценить степень их вредоносности.
Очевидно, что бизнес-контекст необходимо понять и описать до начала моделирования.
Архитектура моделируемого приложения не определена.
Прежде всего отметим, что в примере мы решили использовать контроль доступа в качестве механизма безопасности, а это повлекло за собой необходимость аутентификации.
Мы могли бы решить, что в этой ситуации можно использовать шифрование данных.
Предоставив всем легитимным пользователям ключи, мы получим систему, которая по безопасности будет сравнима с той, что получена в примере.
То есть очевидно, что два решения не равнозначны, но до сих пор не предоставлено никакой информации, позволяющей сделать выбор между двумя возможными вариантами защиты.
Действительно, давайте рассмотрим два варианта архитектуры.
В первом случае пусть на схеме описывается система, которая будет работать на сервере, расположенном в защищенном помещении; пользователи будут иметь только удаленный доступ и использовать только описанный функционал.
Контроль доступа в этом случае, вероятно, будет лучшим решением.
Во втором случае представим, что программа будет работать на личном ноутбуке пользователя и ее основной задачей будет защита документа в случае кражи носителя.
В этом случае шифрование, вероятно, будет лучшим из двух решений.
Заметим, что зависимость от архитектуры — это одно из проявлений нефункциональной природы безопасности.
В нашем простом примере эта связь очевидна и ее легко заметить.
В более сложной ситуации взаимозависимость может быть более тонкой и трудной для выявления.
Безопасность может зависеть от физических характеристик системы: куда вводится информация, где она хранится, обрабатывается и как передается.
Безопасность также может зависеть от логической архитектуры: от функциональности отдельных компонентов системы и их взаимосвязей.
Часть архитектуры известна в самом начале проекта и остается неизменной.
Другая часть архитектуры разрабатывается на основе анализа функциональных требований, и эта часть архитектуры может незначительно меняться в ходе реализации проекта.
В свою очередь, эти изменения могут потребовать возврата к анализу требований к функциям безопасности.
Преимущества и недостатки Преимущества Одним из важнейших преимуществ метода является то, что он построен как расширение уже существующего, проверенного временем, понятного многим метода описания функциональности.
Это значит, что описание, сделанное с использованием абьюз-опций, будет понятно как разработчикам, так и заказчику.
Еще одним очень важным преимуществом является то, что метод позволяет легко проследить зависимость между основной функцией и функциями безопасности, которые следует добавить в программу для предотвращения злоупотреблений.
Таким образом, мы можем отложить внедрение функции безопасности до тех пор, пока она действительно не понадобится.
Недостатки Недостатком этого метода является то, что он расширение стандартный способ описания.
И, если у вас применение вариантов использования автоматизировано, то может оказаться, что сама программа, которую вы используете, не поддерживает это расширение.
Тогда вам придется либо отказаться от вариантов злоупотреблений, либо отказаться от автоматизации, хотя бы частично.
Но главным недостатком метода, на мой взгляд, является чрезмерная сосредоточенность на описании функциональности.
Большой объем информации, от которого существенно зависит принятие того или иного решения о защитных мерах, находится в других документах, на других схемах.
Этот метод может заставить принимать решения без учета всей доступной информации или даже до того, как будут приняты решения по архитектуре критически важных приложений.
Заключение Метод опционов злоупотребления — это инструмент со своими преимуществами и недостатками.
Как и любой другой инструмент, он хорош для решения определенного круга задач и при правильном использовании.
Существуют и другие методы описания и анализа требований безопасности.
Их можно использовать как альтернативу описанному, так и в сочетании с ним.
Но это тема для других статей.
Литература
- Г.
Синдре и А.
Л.
Опдал, «Выявление требований безопасности в случаях неправомерного использования», Proc. ИНСТРУМЕНТЫ Pacific 2000, ноябрь 2000 г.
- Г.
Синдре и А.
Л.
Опдал, «Шаблон описания случая неправомерного использования» Материалы международного семинара по разработке требований: Фонд качества программного обеспечения (REFSQ 2001), 2001.
- Г.
Синдре, А.
Л.
Опдал и Г.
Ф.
Бревик, «Обобщение/специализация как механизм структурирования случаев неправомерного использования» Материалы симпозиума по разработке требований для информационной безопасности, 2002 г.
- Г.
Синдре и А.
Л.
Опдал, «Выявление требований безопасности в случаях неправильного использования» Журнал разработки требований, 10 (1): 34–44, 2005 г.
- И.
Александр, «Моделирование взаимодействия конфликтующих целей со случаями использования и неправильного использования» , Материалы восьмого международного семинара по разработке требований: Фонд качества программного обеспечения, сентябрь 2002 г.
- И.
Александр, «Первоначальный промышленный опыт случаев неправильного использования в анализе компромиссов» , Материалы совместной международной конференции по разработке требований IEEE, сентябрь 2002 г.
- И.
Александр, «Случаи неправильного использования: случаи использования с враждебными намерениями» Программное обеспечение IEEE, 2003 г.
-
Парсинг Google Карт
19 Oct, 24 -
Как Вырастить Менеджера Проекта: Pdu Майнинг
19 Oct, 24 -
Украшаем Рабочий Стол В Windows 7
19 Oct, 24
