Стейкхолеры – это заинтересованные стороны. Кого только не готовы включать в этот список: регуляторов, законодателей, контролирующие органы – всех, кто имеет хоть какое-то отношение к системе. 

А вы бы включили в список стейкхолдеров хакеров и мошенников – у них интерес к системе существует по определению? Разумеется, речь не идёт об «АРМе хакера», в котором они были бы пользователями.

На первый взгляд – нет. Не для хакеров же пишется система, да и кто будет принимать результат.

ISO/IEC/IEEE 12207-2017

Вот что говорит стандарт ISO/IEC/IEEE 12207-2017 «Systems and software engineering — Software life cycle processes» - см. примечание к п. 2.3. радела 6.4.

«Некоторые заинтересованные стороны имеют интересы, которые противоречат интересам заказчика (например, рыночные конкуренты, хакеры, террористы) или противоречат друг другу. 

Когда интересы заинтересованных сторон противоречат друг другу, но не противоречат программной системе, этот процесс направлен на достижение консенсуса среди классов заинтересованных сторон для установления общего набора приемлемых требований. 

Намерения или желания тех, кто противостоит заказчикам или является противниками системы, решаются через 

·      процесс управления рисками, 

·      процесс анализа угроз в рамках системного анализа или 

·      cистемные/программные требования по безопасности, адаптируемости или устойчивости. 

В этом случае, потребности заинтересованных сторон не удовлетворяются, а рассматриваются таким образом, чтобы обеспечить надёжность и целостность системы в случае действий со стороны противников.»

Таким образом, стандарт видит этих лиц как заинтересованные стороны, и даже предлагает «рассматривать» (addressed - в оригинале) их потребности – написано явно. 

Предположим, что это не очень удачная формулировка – лучше бы сказать: противодействовать их потребностям. В любом случае  - противодействие, согласно стандарту, следует описывать в других разделах требований, например, в Нефункциональных требованиях, в подразделе Требований к безопасности.

Однако в таком подходе есть и недостаток. Часто разделы безопасности Требований пишутся достаточно формально, как будто под копирку. Требования безопасности есть везде, и люди-«безопасники», которые эти требования проверяют, – серьёзные. Только – базы сливаются, СДЭКи (имеется ввиду последний инцидент) перестают работать, а хакеры прекрасно делают свою работу. 

Анти-сценарии имеет смысл прописывать явно

Когда мы указываем стейкхолдеров, нам важны их сценарии использования системы. Точно также, идентификация анти-пользователей позволит перечислить и явно описать их анти-сценарии, причём в классической модели user story. Чем больше и точнее описаний – тем лучше.

- Как «мошенник» я хочу ввести украденный или подобранный логин и пароль для входа в интернет-магазин для того, чтобы сделать покупки/получить другие данные пользователя и в дальнейшем использовать для социального инжиниринга.

- Как «продажный админ» я хочу скачать базу клиентов, для того чтобы продать её.

- Как «недобросовестный клиент» я хочу ввести фейковый промокод, для того чтобы получить скидку. 

Более того, такие бизнес-сценарии должны собираться и тщательно анализироваться. Ещё лучше - публиковаться в составе национального/международного стандарта или своду лучших практик по информационной безопасности и противодействию угрозам.

Всё давно известно в стандартах по безопасности?

Действительно, существуют стандарты безопасности, например ISO/IEC 27001 и ISO/IEC 27002, NISP SP800-53, списки критических рисков OWASP. Просто отметим:

·      Стандарты, политики, технические правила – внедряются на уровне компании, существуют при выборе инструментов и паттернов разработки. Далеко не у всех компаний существует  культура информационной безопасности и ресурсы.

·      Внедрение целого стандарта – отдельная большая история, в то время как существует локальная задача - разработать/доработать конкретное приложение.

·      Анти-user story – это скорее бизнес-взгляд, а информационная безопасность – технические и орагнизационные практики.

Вывод

Пока практики введения стейкхолдеров–вредителей нет. Международные стандарты рассматривают анти-user story среди мер риск-менеджмента и нефункциональных требований в части безопасности. Однако бизнес-смысл выделения девиантного (криминального) поведения существует.