Хабр Курсы для всех
РЕКЛАМА
Большая витрина: от крупнейших школ до частных авторов. Сравнивайте по цене, длительности, формату и выбирайте самый подходящий курс!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 13
Главный вопрос: функциональность программы описывается как операции, отражающие сформулированные потребности заказчика. Другими словами, это конечное счётное множество.
Откуда берутся misuse case'ы? Я бы назвал misuse case'ами все действия с ПО, которые не предусмотрены use case'ами, то есть как их дополнение.
Но тут возникает вопрос: а дополнением до чего? До всех вариантов конечной ленты у машины Тьюринга? Неконструктивненько как-то…
Откуда берутся misuse case'ы? Я бы назвал misuse case'ами все действия с ПО, которые не предусмотрены use case'ами, то есть как их дополнение.
Но тут возникает вопрос: а дополнением до чего? До всех вариантов конечной ленты у машины Тьюринга? Неконструктивненько как-то…
Требования безопасности по своей природе являются отрицательными: они описывают, что система делать не должна. В этом «прелесть» безопасности.
Но требовать от программы, чтобы она не делала всего, что не предусмотрено вариантами использования, было бы крайне неосторожно. Слишком много возможной функциональности попадает под это определение. В этом Вы правы.
С помощью вариантов злоупотребления мы описываем, какая функциональность программного обеспечения, будучи реализованной, сможет быть использована для нанесения ущерба. То есть, из всего огромного множества возможного поведения мы выбираем только относительно маленький объем, и говорим о необходимости предотвратить именно это поведение, а не вообще любое, не предусмотренное вариантами использования. В этой избирательности и есть конструктивность метода.
Но требовать от программы, чтобы она не делала всего, что не предусмотрено вариантами использования, было бы крайне неосторожно. Слишком много возможной функциональности попадает под это определение. В этом Вы правы.
С помощью вариантов злоупотребления мы описываем, какая функциональность программного обеспечения, будучи реализованной, сможет быть использована для нанесения ущерба. То есть, из всего огромного множества возможного поведения мы выбираем только относительно маленький объем, и говорим о необходимости предотвратить именно это поведение, а не вообще любое, не предусмотренное вариантами использования. В этой избирательности и есть конструктивность метода.
Я так и не понял, каким образом берётся «маленький объём». По каким алгоримтмам, по каким правилам? Или это всё на наитии «а я знаю что такое mim!»? В этом случае метод не описывает ровным случаем ничего — где-то подумал, где-то нет.
Метод относится к неформальным, то есть, огромное значение играют знания и опыт того, кто производит анализ.
Мне кажется, я понимаю, чего хотелось бы Вам. Хочется иметь некий критерий, который бы позволил однозначно сказать, какая функциональность является вредоносной. Наиболее близко к решению этой задачи можно подойти при использовании формальных методов, которые подразумевают построение модели системы и доказательства того, что она обладает необходимыми свойствами. Хотя и эти методы не гарантируют, что полученная программа будет невзламываемой. Так само построение корректной модели — задача не самая тривиальная. По крайней мере, такого положение дел на сейчас.
Да, использование формальных методов позволяет решить многие проблемы. Но они требуют больших затрат и денег, и времени. При разработке комерческих продуктов такие затраты компании не могут себе позволить.
Мне кажется, я понимаю, чего хотелось бы Вам. Хочется иметь некий критерий, который бы позволил однозначно сказать, какая функциональность является вредоносной. Наиболее близко к решению этой задачи можно подойти при использовании формальных методов, которые подразумевают построение модели системы и доказательства того, что она обладает необходимыми свойствами. Хотя и эти методы не гарантируют, что полученная программа будет невзламываемой. Так само построение корректной модели — задача не самая тривиальная. По крайней мере, такого положение дел на сейчас.
Да, использование формальных методов позволяет решить многие проблемы. Но они требуют больших затрат и денег, и времени. При разработке комерческих продуктов такие затраты компании не могут себе позволить.
Много букв, а о чем — не понятно. Имхо, плохо связаны куски
Делает/не делает — исходите от запрещающей политики или разрешающей. Если безопасность — то что не делает — имхо проблемы. Потому что описать всё то что не нужно делать пожалуй сложнее, чем наоборот.
И читая по диагонали я не понял — это такой метод описания модели угроз, или его применение
Делает/не делает — исходите от запрещающей политики или разрешающей. Если безопасность — то что не делает — имхо проблемы. Потому что описать всё то что не нужно делать пожалуй сложнее, чем наоборот.
И читая по диагонали я не понял — это такой метод описания модели угроз, или его применение
Да, сложноватый текст. Прошу прощения если не все правильно понял. А почему просто нельзя заобфусцировать (защитить код программы от анализа и взлома) программу, скрыть ее внутреннюю структуру + снабдить пользователя серийным номером для доступа (про юсб ключ не говорю — вчерашний день).
Серийник сгенирировать очень сложно. Возможно только если перебрать 1000 различных серийников. Без серийника программа не запускается и соответственно не может быть подвергнута анализу.
В серийник можно заложить модель поведения программы. Т.е. определенный серийник, открывает доступ к отпределенным функциям.
Просматриваемые в программе документы, например, тоже закриптованы и жестко привязаны к данной программе.
А вообще конечно неплохо было бы понимать от чего мы конкретно защищаемся.
Серийник сгенирировать очень сложно. Возможно только если перебрать 1000 различных серийников. Без серийника программа не запускается и соответственно не может быть подвергнута анализу.
В серийник можно заложить модель поведения программы. Т.е. определенный серийник, открывает доступ к отпределенным функциям.
Просматриваемые в программе документы, например, тоже закриптованы и жестко привязаны к данной программе.
А вообще конечно неплохо было бы понимать от чего мы конкретно защищаемся.
Довольно хороший способ анализа на высоком уровне необходимых средств безопастности на основе уже имеющегося Use Cases приложения или в процессе проектирования. Конечно он имеет смысл для сложных систем связанных с большими рисками (платежных, банковских и т.п.).
Спасибо. Отличное и логичное дополнение к инструментарию проектирования.
Вопрос по терминологии. Традиционно в литературе use-case переводится как сценарий использования, и такой перевод можно считать устоявшимся. Почему вы выбрали термин «вариант», а не «сценарий»?
главным недостатком метода, на мой взгляд, является излишняя сосредоточенность на описании функциональности. Большое количество информации, от которой в существенной степени зависит принятие того или иного решения по мерам защиты, располагаются в других документах, на других диаграммах.Я бы не назвал это недостатком. Такое описание никоим образом не может быть единственным и достаточным. Это всего лишь одно звено в цепочке, также как описание use-cases — одно звено цепочке проектирования.
Вопрос по терминологии. Традиционно в литературе use-case переводится как сценарий использования, и такой перевод можно считать устоявшимся. Почему вы выбрали термин «вариант», а не «сценарий»?
Про недостаток — это сложившееся из моего опыта мое представление. Не буду на нем настаивать, это просто мое мнение.
По поводу терминологии. В зарубежной литературе есть два понятия: «use cases» и «use/user scenarios». Различие между ними, насколько я понимаю, минимальное, но оно есть. Об этом можно подробне поискать в сети, например в этом обсуждении дается следующая интерпретация:
«USE CASE is a generic scenario, describing one kind of interaction with a particular interface.»
«USE/USER SCENARIO is a concrete description of a very specific interaction, but one that is chosen to be typical or representative. »
Поэтому чаще мне приходилось слышать и говорить именно о вариантах использования, как о переводе use cases. А сценарии использования оставить для перевода use/user scenarios. Но спорить на деньги я бы не стал.
По поводу терминологии. В зарубежной литературе есть два понятия: «use cases» и «use/user scenarios». Различие между ними, насколько я понимаю, минимальное, но оно есть. Об этом можно подробне поискать в сети, например в этом обсуждении дается следующая интерпретация:
«USE CASE is a generic scenario, describing one kind of interaction with a particular interface.»
«USE/USER SCENARIO is a concrete description of a very specific interaction, but one that is chosen to be typical or representative. »
Поэтому чаще мне приходилось слышать и говорить именно о вариантах использования, как о переводе use cases. А сценарии использования оставить для перевода use/user scenarios. Но спорить на деньги я бы не стал.
Спасибо. Очень основательно и толково. Люблю такой подход.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Misuse Cases