В своей предыдущей статье «Что такое безопасность» я писал о безопасности программного обеспечения. В ней я постарался проиллюстрировать два утверждения.
Первое утверждение состоит в том, что безопасность является нефункциональным свойством программы, и определяется не тем, что программа делает, а тем, чего она не делает.
Второе утверждение, очень тесно связанное с первым, состоит в том, что «функции безопасности» являются антифункциями: они отбирают возможности у пользователей, которые не должны иметь доступа к некоторой функциональности программного обеспечения.
В частности, это означает, что функции безопасности, как одно из средств достижения этой самой безопасности, нельзя описывать теми же самыми методами, которыми описывается «обычная», основная функциональность. Для этой цели должны быть использованы другие подходы. К настоящему времени для решения этой задачи было предложено несколько методов. Одним из самых популярных из них является метод вариантов злоупотребления — misuse cases, — которому и посвящена данная статья.
Метод описания и анализа требований безопасности с использованием вариантов злоупотребления был впервые предложен более 10 лет назад. Авторами его являются два специалиста: Guttorm Sindre и Andreas Lothe Opdahl [1]. Впоследствии они же существенно развили этот метод [2,3,4]. Другой специалист, Ian Alexander дополнил авторский подход, предложил новые его применения [5,6,7]. Всем, кто заинтересовался и хотел бы серьезно познакомиться с применением вариантов злоупотребления, рекомендую почитать статьи по ссылкам. Также рекомендую воспользоваться поиском в интернете и посмотреть самые свежие материалы, поскольку метод продолжает исследоваться и развиваться.
Для остальных же постараюсь кратко описать данный подход и продемонстрировать его использование на очень простом, тривиальном примере.
Я думаю, все, кто сейчас читает эту статью, знают, что функциональные требования к программному обеспечению часто описывают с помощью вариантов использования, use cases. Каждый вариант использования представляет собой последовательность действий, при выполнении которой от начала до конца легитимный пользователь решит одну из своих задач, достигнет одну из своих целей, задействовав функции программы. То есть, варианты использования описывают то, что программа должна делать.
Но мы хотим описать, чего программа делать не должна. Для этого и служат варианты злоупотребления.
Варианты злоупотребления являются расширением вариантов использования. С помощью каждого такого варианта описывается способ, которым нарушитель может достичь одну из своих целей, нанеся при этом ущерб владельцу системы.
Вместе с вариантами злоупотребления создаются варианты использования, описывающие действие функций безопасности, призванных предотвратить нежелательное использование программы.
Как и в случае вариантов использования, варианты злоупотребления могут быть представлены как в графической, так и в тестовой форме. Конечно, как и в случае чистых вариантов использования, допустимы любые комбинации графических диаграмм и текста.
При графическом представлении информации варианты злоупотребления рисуются совместно с вариантами использования. Чтобы они различались между собой, для представления первых добавляется несколько новых элементов и несколько отношений между ними.
Во-первых, добавляется элемент, означающий нарушителя. Если один и тот же человек может выступать и как легитимный пользователь, и как нарушитель, то он появляется на диаграмме дважды, один раз в качестве легитимного пользователя, второй раз — в виде нарушителя. Графически нарушитель обозначается так же, как и легитимный пользователь, но выделяется другим цветом.
Во-вторых, добавляется элемент, обозначающий цель нарушителя. Этот элемент — вариант злоупотребления — обозначается так же, как и цель легитимного пользователя — вариант использования. Для того чтобы отличать вариант использования от варианта злоупотребления, последний обозначается другим цветом, как и нарушитель.
В-третьих, добавляется два отношения. Отношение «threaten» обозначает тот факт, что данная цель нарушителя может быть достигнута с использованием данной функциональности системы. Отношение «mitigate» обозначает тот факт, что данная функция безопасности используется для уменьшения опасности данного варианта злоупотребления.
При текстовом представлении вариантов злоупотребления вводятся шаблоны, соответствующие новым графическим элементам, и новые поля в шаблонах, соответствующие новым отношениям.
Этих расширений оказывается вполне достаточно для описания функциональных требований безопасности.
Чтобы познакомится с методом, давайте рассмотрим крайне упрощенный пример.
Пусть у нас есть программа, которая дает возможность читать некий документ.
Очевидно, любой, в том числе и неавторизованный, пользователь может читать этот же документ, используя ту же функциональность. Добавляем к диаграмме описание этого факта.
Так мы получили описание существующей в нашей программе уязвимости: возможность неавторизованному пользователю получить доступ к конфиденциальному документу. И мы хотим найти возможность устранить ее.
Мы можем решить, что управление доступом может предотвратить использование функций вредным для нас способом. Для управления доступом мы должны провести предварительную аутентификацию пользователя. Потребуем от пользователя ввести имя и пароль.
Проанализировав получившийся проект, мы заметим, что аутентификацию можно обойти, подобрав пароль. Добавим этот факт к диаграмме.
Для устранения обнаруженной уязвимости потребуем от программы обнаруживать несколько последовательных неудачных попыток ввода пароля и блокировать соответствующего пользователя.
Анализ полученного проекта показывает, что нарушитель, возможно, отличающийся от первого, получил возможность заблокировать работу авторизованного пользователя.
Предположим, на этом этапе мы решили, что можем допустить такую блокировку. Поскольку не осталось уязвимостей, которые должны быть устранены, анализ можно считать законченным.
Таким образом, мы получили описание: функциональности программы, связанных с этой функциональностью слабостей и функций безопасностями, призванных уменьшить уязвимость программы. На диаграмме также обозначены уязвимости программы, существование которых признано допустимым.
Пример, приведенный в предыдущем разделе, крайне примитивен, не полон. Для иллюстрации работы с методом большего и не надо. Но хотелось бы все же обратить внимание на отсутствующую информацию, которая принципиально необходима для адекватного анализа функциональных требований безопасности.
Не хватает бизнес контекста.
Давайте вспомним, что с помощью вариантов злоупотребления мы описываем пути, которыми нарушитель:
Поэтому, прежде всего мы должны понимать, кто может быть заинтересован в атаке на разрабатываемую программу, и каковы его цели, ресурсы, возможности. Может существовать несколько групп потенциальных нарушителей, различающихся по этим параметрам.
Мы также должны понимать, какие события могут нанести ущерб владельцу программы, оценить степень их вредоносности.
Очевидно, что бизнес контекст должен быть понят и описан до того, как начинается моделирование.
Не определена архитектура моделируемого приложения.
Заметим сначала, что в примере мы решили использовать в качестве механизма защиты управление доступом, и это повлекло за собой необходимость проведения аутентификации. Мы могли бы решить, что в данной ситуации можно использовать зашифровывание данных. Снабдив всех легитимных пользователей ключами, мы получили бы систему, которая по защищенности была бы сравнима с той, что была получена в примере. То есть, очевидно, что два решения не эквивалентны, но пока не было представлено никакой информации, которая бы позволила выбрать из двух возможных вариантов защиты.
Действительно, давайте посмотрим на два варианта архитектуры.
Пусть в первом случае диаграмм описывает систему, которая будет работать на сервере, расположенном в защищенном помещении; пользователи будут иметь только удаленный доступ и только с использование описанной функциональности. Разграничение доступа в этом случае, вероятно, будет оптимальным решением.
Во втором случае представим себе, что программа будет работать на персональном ноутбуке пользователя и основной задачей ее будет защита документа при краже носителя. Вероятно, в этом случае шифрование — лучшее из двух решений.
Заметим, что зависимость от архитектуры является одним из проявлений нефункционального характера безопасности.
В нашем простом примере эта зависимость очевидна, и ее легко заметить. В более сложной ситуации взаимозависимость может оказаться более тонкой, и ее выявление будет сложной задачей. Безопасность может зависеть от физических характеристик системы: где информация вводится, где она храниться, обрабатывается, как она передается. Безопасность может зависеть и от логической архитектуры: от функциональности отдельных компонентов системы, от их взаимосвязей.
Часть архитектуры известна уже в самом начале проекта, и остается неизменной. Другая часть архитектуры разрабатывается на основе анализа функциональных требований, и эта часть архитектуры может несколько изменятся в ходе реализации проекта. В свою очередь, эти изменения могут вызвать необходимость вернуться к анализу требований к функциям безопасности.
Достоинства
Одним из важнейших достоинств метода является то, что он построен как расширение уже существующего, проверенного временем, понятного многим метода описания функциональности. Это означает, что описание, сделанное с применением вариантов злоупотребления, будет понятно как разработчикам, так и заказчику.
Другим очень важным достоинством является то, что метод позволяет легко отследить зависимость между основной функцией и функциями безопасности, которые должны быть добавлены в программу, чтобы предотвратить злоупотребления. Таким образом, мы можем отложить реализацию функции безопасности до того момента, когда она действительно будет необходима.
Недостатки
Недостатком метода можно назвать то, что он является расширением стандартного способа описания. И, если у вас применение вариантов использования автоматизировано, то может оказаться, что именно та программа, которую задействуете вы, не поддерживает этого расширения. Тогда вам придется либо отказаться от вариантов злоупотребления, либо отказаться от автоматизации, хотя бы частично.
Но главным недостатком метода, на мой взгляд, является излишняя сосредоточенность на описании функциональности. Большое количество информации, от которой в существенной степени зависит принятие того или иного решения по мерам защиты, располагаются в других документах, на других диаграммах.
Метод может спровоцировать принятие решений без учета всей имеющейся информации, или даже до того, как важные с точки зрения безопасности решения по архитектуре приложения будут приняты.
Метод вариантов злоупотребления является инструментом со своими достоинствами и недостатками. Как любой другой инструмент он хорош для решения определенного круга задач и при правильном его использовании.
Существуют и другие методы описания и анализа требований безопасности. Их можно применять как в качестве альтернативы описанному, так и совместно с ним. Но это уже тема для других статей.
Первое утверждение состоит в том, что безопасность является нефункциональным свойством программы, и определяется не тем, что программа делает, а тем, чего она не делает.
Второе утверждение, очень тесно связанное с первым, состоит в том, что «функции безопасности» являются антифункциями: они отбирают возможности у пользователей, которые не должны иметь доступа к некоторой функциональности программного обеспечения.
В частности, это означает, что функции безопасности, как одно из средств достижения этой самой безопасности, нельзя описывать теми же самыми методами, которыми описывается «обычная», основная функциональность. Для этой цели должны быть использованы другие подходы. К настоящему времени для решения этой задачи было предложено несколько методов. Одним из самых популярных из них является метод вариантов злоупотребления — misuse cases, — которому и посвящена данная статья.
Где описывается
Метод описания и анализа требований безопасности с использованием вариантов злоупотребления был впервые предложен более 10 лет назад. Авторами его являются два специалиста: Guttorm Sindre и Andreas Lothe Opdahl [1]. Впоследствии они же существенно развили этот метод [2,3,4]. Другой специалист, Ian Alexander дополнил авторский подход, предложил новые его применения [5,6,7]. Всем, кто заинтересовался и хотел бы серьезно познакомиться с применением вариантов злоупотребления, рекомендую почитать статьи по ссылкам. Также рекомендую воспользоваться поиском в интернете и посмотреть самые свежие материалы, поскольку метод продолжает исследоваться и развиваться.
Для остальных же постараюсь кратко описать данный подход и продемонстрировать его использование на очень простом, тривиальном примере.
Расширение вариантов использования
Я думаю, все, кто сейчас читает эту статью, знают, что функциональные требования к программному обеспечению часто описывают с помощью вариантов использования, use cases. Каждый вариант использования представляет собой последовательность действий, при выполнении которой от начала до конца легитимный пользователь решит одну из своих задач, достигнет одну из своих целей, задействовав функции программы. То есть, варианты использования описывают то, что программа должна делать.
Но мы хотим описать, чего программа делать не должна. Для этого и служат варианты злоупотребления.
Варианты злоупотребления являются расширением вариантов использования. С помощью каждого такого варианта описывается способ, которым нарушитель может достичь одну из своих целей, нанеся при этом ущерб владельцу системы.
Вместе с вариантами злоупотребления создаются варианты использования, описывающие действие функций безопасности, призванных предотвратить нежелательное использование программы.
Как и в случае вариантов использования, варианты злоупотребления могут быть представлены как в графической, так и в тестовой форме. Конечно, как и в случае чистых вариантов использования, допустимы любые комбинации графических диаграмм и текста.
При графическом представлении информации варианты злоупотребления рисуются совместно с вариантами использования. Чтобы они различались между собой, для представления первых добавляется несколько новых элементов и несколько отношений между ними.
Во-первых, добавляется элемент, означающий нарушителя. Если один и тот же человек может выступать и как легитимный пользователь, и как нарушитель, то он появляется на диаграмме дважды, один раз в качестве легитимного пользователя, второй раз — в виде нарушителя. Графически нарушитель обозначается так же, как и легитимный пользователь, но выделяется другим цветом.
Во-вторых, добавляется элемент, обозначающий цель нарушителя. Этот элемент — вариант злоупотребления — обозначается так же, как и цель легитимного пользователя — вариант использования. Для того чтобы отличать вариант использования от варианта злоупотребления, последний обозначается другим цветом, как и нарушитель.
В-третьих, добавляется два отношения. Отношение «threaten» обозначает тот факт, что данная цель нарушителя может быть достигнута с использованием данной функциональности системы. Отношение «mitigate» обозначает тот факт, что данная функция безопасности используется для уменьшения опасности данного варианта злоупотребления.
При текстовом представлении вариантов злоупотребления вводятся шаблоны, соответствующие новым графическим элементам, и новые поля в шаблонах, соответствующие новым отношениям.
Этих расширений оказывается вполне достаточно для описания функциональных требований безопасности.
Простейшая система
Чтобы познакомится с методом, давайте рассмотрим крайне упрощенный пример.
Пусть у нас есть программа, которая дает возможность читать некий документ.
Очевидно, любой, в том числе и неавторизованный, пользователь может читать этот же документ, используя ту же функциональность. Добавляем к диаграмме описание этого факта.
Так мы получили описание существующей в нашей программе уязвимости: возможность неавторизованному пользователю получить доступ к конфиденциальному документу. И мы хотим найти возможность устранить ее.
Мы можем решить, что управление доступом может предотвратить использование функций вредным для нас способом. Для управления доступом мы должны провести предварительную аутентификацию пользователя. Потребуем от пользователя ввести имя и пароль.
Проанализировав получившийся проект, мы заметим, что аутентификацию можно обойти, подобрав пароль. Добавим этот факт к диаграмме.
Для устранения обнаруженной уязвимости потребуем от программы обнаруживать несколько последовательных неудачных попыток ввода пароля и блокировать соответствующего пользователя.
Анализ полученного проекта показывает, что нарушитель, возможно, отличающийся от первого, получил возможность заблокировать работу авторизованного пользователя.
Предположим, на этом этапе мы решили, что можем допустить такую блокировку. Поскольку не осталось уязвимостей, которые должны быть устранены, анализ можно считать законченным.
Таким образом, мы получили описание: функциональности программы, связанных с этой функциональностью слабостей и функций безопасностями, призванных уменьшить уязвимость программы. На диаграмме также обозначены уязвимости программы, существование которых признано допустимым.
Чего не хватает в этом примере
Пример, приведенный в предыдущем разделе, крайне примитивен, не полон. Для иллюстрации работы с методом большего и не надо. Но хотелось бы все же обратить внимание на отсутствующую информацию, которая принципиально необходима для адекватного анализа функциональных требований безопасности.
Не хватает бизнес контекста.
Давайте вспомним, что с помощью вариантов злоупотребления мы описываем пути, которыми нарушитель:
- достигает свои цели;
- наносит ущерб владельцу системы.
Поэтому, прежде всего мы должны понимать, кто может быть заинтересован в атаке на разрабатываемую программу, и каковы его цели, ресурсы, возможности. Может существовать несколько групп потенциальных нарушителей, различающихся по этим параметрам.
Мы также должны понимать, какие события могут нанести ущерб владельцу программы, оценить степень их вредоносности.
Очевидно, что бизнес контекст должен быть понят и описан до того, как начинается моделирование.
Не определена архитектура моделируемого приложения.
Заметим сначала, что в примере мы решили использовать в качестве механизма защиты управление доступом, и это повлекло за собой необходимость проведения аутентификации. Мы могли бы решить, что в данной ситуации можно использовать зашифровывание данных. Снабдив всех легитимных пользователей ключами, мы получили бы систему, которая по защищенности была бы сравнима с той, что была получена в примере. То есть, очевидно, что два решения не эквивалентны, но пока не было представлено никакой информации, которая бы позволила выбрать из двух возможных вариантов защиты.
Действительно, давайте посмотрим на два варианта архитектуры.
Пусть в первом случае диаграмм описывает систему, которая будет работать на сервере, расположенном в защищенном помещении; пользователи будут иметь только удаленный доступ и только с использование описанной функциональности. Разграничение доступа в этом случае, вероятно, будет оптимальным решением.
Во втором случае представим себе, что программа будет работать на персональном ноутбуке пользователя и основной задачей ее будет защита документа при краже носителя. Вероятно, в этом случае шифрование — лучшее из двух решений.
Заметим, что зависимость от архитектуры является одним из проявлений нефункционального характера безопасности.
В нашем простом примере эта зависимость очевидна, и ее легко заметить. В более сложной ситуации взаимозависимость может оказаться более тонкой, и ее выявление будет сложной задачей. Безопасность может зависеть от физических характеристик системы: где информация вводится, где она храниться, обрабатывается, как она передается. Безопасность может зависеть и от логической архитектуры: от функциональности отдельных компонентов системы, от их взаимосвязей.
Часть архитектуры известна уже в самом начале проекта, и остается неизменной. Другая часть архитектуры разрабатывается на основе анализа функциональных требований, и эта часть архитектуры может несколько изменятся в ходе реализации проекта. В свою очередь, эти изменения могут вызвать необходимость вернуться к анализу требований к функциям безопасности.
Достоинства и недостатки
Достоинства
Одним из важнейших достоинств метода является то, что он построен как расширение уже существующего, проверенного временем, понятного многим метода описания функциональности. Это означает, что описание, сделанное с применением вариантов злоупотребления, будет понятно как разработчикам, так и заказчику.
Другим очень важным достоинством является то, что метод позволяет легко отследить зависимость между основной функцией и функциями безопасности, которые должны быть добавлены в программу, чтобы предотвратить злоупотребления. Таким образом, мы можем отложить реализацию функции безопасности до того момента, когда она действительно будет необходима.
Недостатки
Недостатком метода можно назвать то, что он является расширением стандартного способа описания. И, если у вас применение вариантов использования автоматизировано, то может оказаться, что именно та программа, которую задействуете вы, не поддерживает этого расширения. Тогда вам придется либо отказаться от вариантов злоупотребления, либо отказаться от автоматизации, хотя бы частично.
Но главным недостатком метода, на мой взгляд, является излишняя сосредоточенность на описании функциональности. Большое количество информации, от которой в существенной степени зависит принятие того или иного решения по мерам защиты, располагаются в других документах, на других диаграммах.
Метод может спровоцировать принятие решений без учета всей имеющейся информации, или даже до того, как важные с точки зрения безопасности решения по архитектуре приложения будут приняты.
Заключение
Метод вариантов злоупотребления является инструментом со своими достоинствами и недостатками. Как любой другой инструмент он хорош для решения определенного круга задач и при правильном его использовании.
Существуют и другие методы описания и анализа требований безопасности. Их можно применять как в качестве альтернативы описанному, так и совместно с ним. Но это уже тема для других статей.
Литература
- G. Sindre and A. L. Opdahl, “Eliciting Secutiry Requirements by Misuse Cases”, Proc. TOOLS Pacific 2000, Nov 2000.
- G. Sindre and A. L. Opdahl, “Template for Misuse Case Description” Proceedings of the International Workshop Requirements Engineering: Foundation for Software Quality (REFSQ 2001), 2001.
- G. Sindre, A. L. Opdahl, and G. F. Brevik, “Generalization/Specialization as a Structuring Mechanism for Misuse Cases” Proceedings of the Symposium on Requirements Engineering for Information Security, 2002.
- G. Sindre and A. L. Opdahl, “Eliciting Security Requirements with Misuse Cases” Requirements Engineering Journal, 10(1):34–44, 2005.
- I. Alexander, “Modelling the Interplay of Conflicting Goals with Use and Misuse Cases”, Proceedings Eighth International Workshop on Requirements Engineering: Foundation for Software Quality, September 2002
- I. Alexander, “Initial Industrial Experience of Misuse Cases in Trade-Off Analysis”, Proceedings of IEEE Joint International Requirements Engineering Conference, September 2002
- I. Alexander, “Misuse Cases: Use Cases with Hostile Intent” IEEE Software, 2003
