Про недостаток — это сложившееся из моего опыта мое представление. Не буду на нем настаивать, это просто мое мнение.
По поводу терминологии. В зарубежной литературе есть два понятия: «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. Но спорить на деньги я бы не стал.
Метод относится к неформальным, то есть, огромное значение играют знания и опыт того, кто производит анализ.
Мне кажется, я понимаю, чего хотелось бы Вам. Хочется иметь некий критерий, который бы позволил однозначно сказать, какая функциональность является вредоносной. Наиболее близко к решению этой задачи можно подойти при использовании формальных методов, которые подразумевают построение модели системы и доказательства того, что она обладает необходимыми свойствами. Хотя и эти методы не гарантируют, что полученная программа будет невзламываемой. Так само построение корректной модели — задача не самая тривиальная. По крайней мере, такого положение дел на сейчас.
Да, использование формальных методов позволяет решить многие проблемы. Но они требуют больших затрат и денег, и времени. При разработке комерческих продуктов такие затраты компании не могут себе позволить.
Требования безопасности по своей природе являются отрицательными: они описывают, что система делать не должна. В этом «прелесть» безопасности.
Но требовать от программы, чтобы она не делала всего, что не предусмотрено вариантами использования, было бы крайне неосторожно. Слишком много возможной функциональности попадает под это определение. В этом Вы правы.
С помощью вариантов злоупотребления мы описываем, какая функциональность программного обеспечения, будучи реализованной, сможет быть использована для нанесения ущерба. То есть, из всего огромного множества возможного поведения мы выбираем только относительно маленький объем, и говорим о необходимости предотвратить именно это поведение, а не вообще любое, не предусмотренное вариантами использования. В этой избирательности и есть конструктивность метода.
Ну я и сам немного программист, как минимум, у меня есть в трудовой книжке соответствующая запись. Так что, здесь все вполне искренне. :-)
А вообще в этих примерах я хотел всеми способами показать, что такой подход, который я считаю, скажем так, не совсем удобным при анализе, разделяют люди с интеллектом и образованием очень выше среднего.
Думаю, здесь webzest отвечала на мой комментарий, а не на статью. Я забыл упомянуть в нем важность корректной эксплуатации. Просто последние лет 10 я, в основном, нахожусь на строне разработчика…
Краткость — сестра таланта :-)
Слова, явно, криптографа.
Я так коротко не могу. Поэтому я бы перефразировал:
Безопасность ПО – это не только шифрование данных и каналов связи, не только предотвращение несанкционированного доступа к данным путём разделения доступа, но и:
— тщательный анализ потребности в защищенности;
— выбор адекватных средств защиты;
— тщательное планирование архитектуры;
— безопасное кодирование;
— тщательное тестирование.
Наверно, подумав, можно еще написать многое.
По поводу терминологии. В зарубежной литературе есть два понятия: «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. Но спорить на деньги я бы не стал.
Мне кажется, я понимаю, чего хотелось бы Вам. Хочется иметь некий критерий, который бы позволил однозначно сказать, какая функциональность является вредоносной. Наиболее близко к решению этой задачи можно подойти при использовании формальных методов, которые подразумевают построение модели системы и доказательства того, что она обладает необходимыми свойствами. Хотя и эти методы не гарантируют, что полученная программа будет невзламываемой. Так само построение корректной модели — задача не самая тривиальная. По крайней мере, такого положение дел на сейчас.
Да, использование формальных методов позволяет решить многие проблемы. Но они требуют больших затрат и денег, и времени. При разработке комерческих продуктов такие затраты компании не могут себе позволить.
Я здесь не разбираю конкретных методов защиты, я разбираю метод анализа требований и выбора средств защиты.
Но требовать от программы, чтобы она не делала всего, что не предусмотрено вариантами использования, было бы крайне неосторожно. Слишком много возможной функциональности попадает под это определение. В этом Вы правы.
С помощью вариантов злоупотребления мы описываем, какая функциональность программного обеспечения, будучи реализованной, сможет быть использована для нанесения ущерба. То есть, из всего огромного множества возможного поведения мы выбираем только относительно маленький объем, и говорим о необходимости предотвратить именно это поведение, а не вообще любое, не предусмотренное вариантами использования. В этой избирательности и есть конструктивность метода.
А вообще в этих примерах я хотел всеми способами показать, что такой подход, который я считаю, скажем так, не совсем удобным при анализе, разделяют люди с интеллектом и образованием очень выше среднего.
Слова, явно, криптографа.
Я так коротко не могу. Поэтому я бы перефразировал:
Безопасность ПО – это не только шифрование данных и каналов связи, не только предотвращение несанкционированного доступа к данным путём разделения доступа, но и:
— тщательный анализ потребности в защищенности;
— выбор адекватных средств защиты;
— тщательное планирование архитектуры;
— безопасное кодирование;
— тщательное тестирование.
Наверно, подумав, можно еще написать многое.