четверг, 20 мая 2021 г.

Аутсорсинг сервисов и роль бизнес анализа в проектах Internet of Things

 Темы: Business Analysis, Domain Analysis, Internet of Things


В апреле 2021 г. маркетинговым агентством IoT Analytics опубликовало статью The 7 Most Demanded IoT System Integration Services.  Я предлагаю разобраться с тем, какие сервисы и почему являются критически важными для успеха IoT проектов в 2021, и в чем состоят особенности бизнес анализа для этого домена.

Семь сервисов, наиболее востребованных в IoT

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



источник


Статистика говорит о том, что 78% компаний, реализующих IoT проекты, прибегают к помощи сторонних сервисов при интеграции. Почему сторонние сервисы в интеграции IoT проектов являются настолько востребованными? Одной из причин является то, что технологии IoT являются более сложными по сравнению с другими IT-технологиями. Кроме того, IoT требуют владения такими навыками в смежных областях, которые находятся несколько в стороне от традиционного IT (например, встроенные системы и их информационная безопасность), и, как правило, не изучаются инженерами и программистами. К этому следует добавить навыки в управлении подключением устройств, облачных сервисах, больших данных и разработке приложений.


Ключевые ценности создаются на этапах проектирования и реализации. Как видим, наиболее важными для IoT проектов являются семь сервисов:


Этап разработки стратегии

  1. Привлечение и удержание талантов.
    Спрос на специалистов в области IoT повышается. По данным некоторых HR-порталов (например, SimplyHired), в апреле 2021 г. количество вакансий для IoT превысило на 15% до-ковидное количество вакансий. Вопросы, относящиеся к удаленной работе, цифровой культуре, привлечению в профессию поколения Z и т.п., в домене IoT не отличаются от традиционного подхода в  IT.


Этап проектирования:

  1. Приоритезация и выбор юз-кейсов.
    Именно под этим сервисом подразумевается вся деятельность, связанная с фазой Discovery (сбор требований с целью уточнения объема, сроков и бюджета проекта). Поэтому, этот сервис будет рассмотрен далее более подробно с точки зрения работы бизнес аналитика.

  2. Проект решения.
    Далеко не все компании могут самостоятельно проектировать IoT системы и сервисы. Поэтому, проектирование решений является основой аутсорсинговых сервисов в области IoT. Примером такого подхода является, например, разработка компанией HCL Technologies микро-сервисной архитектуры для оптимизации и повышения отказоустойчивости сети датчиков. Это решение было применено  в системе управления орошением, но уже другим разработчиком, специализирующемся в точном земледелии. 

  3. Оптимизация процесса.
    Данный сервис подразумевает анализ и улучшение производственных, логистических, операционных и других  процессов с точки зрения их эффективности. В качестве одного из таких кейсов можно назвать участие Infosys в оптимизации производственных процессов для авиационной отрасли. На реорганизуемом предприятии выпускаются композитные материалы, и целью проекта являлось повышение качества и обслуживания деталей самолетов, включая управление запасами. Для этого применялись технологии виртуальной и дополненной реальности, методы мониторинга состояния и предиктивного обслуживания.

  4. Коммерциализация продукта.
    Данный сервис подразумевает вывод на рынок новых решений. Важную роль в этом играет так называемая servitization («сервисизация»), то есть, усиление сервисных функций продукта со стороны производителя оборудования. Большинство компаний, предлагающих новые IoT продукты, говорят о допущенных ошибках с точки зрения адаптации бизнес моделей под нужды пользователей. По данным отчета «2020 IoT Commercialization & Business Model Adoption Report» от IoT Analytics, на вопрос: «что является наиболее важным фактором для принятия клиентами новых подключенных решений Интернета вещей?» большинство лидеров рынка ответили: «неустанный упор на ценностное предложение для клиентов» и «дополнительные усилия по согласованию процессов продаж и маркетинга с новым подключенным продуктом».


Этап реализации

  1. Интеграция.
    Общими тенденциями интеграции IoT решения являются миграция в облачные сервисы, а также подключение разнородных устройств, приложений и платформ. По мере того, как системы становятся все более взаимосвязанными, возможность сквозной интеграции становится критически важной для системных интеграторов, стремящихся удовлетворить потребности клиентов. Рынок поставщиков системной интеграции IoT в настоящее время является свидетелем беспрецедентной активности слияний и поглощений из-за потребности крупных компаний в масштабировании своего потенциала. Например, Cognizant Technology Solutions Corp. в 2021 г. инвестирует на приобретение других компаний более 1 млрд. долларов.

  2. Бизнес аналитика.
    Данный сервис подразумевает аналитику больших данных с использованием искусственного интеллекта. В 2020 г. появился новый «хайповый» термин (buzzword), «AIoT», означающий конвергенцию технологий искусственного интеллекта (AI) и интернета вещей. В настоящий момент эту концепцию продвигают многие компании. Американский разработчик программного обеспечения Aspen Technology анонсировал создание нового центра AIoT для Индустрии 4.0. Швейцарская компания Wisekey,  специализирующаяся на кибербезопасности, запустила новую цифровую стратегию, основанную на AIoT. Сингапурская компания ASM Pacific Technology разрабатывает концепцию умного машинного зрения, основанного на  AIoT.

Приоритезация и выбор юз-кейсов

Как было отмечено, именно под этим сервисом подразумевается применение процедур бизнес анализа на фазе для сбора требований к создаваемой IoT системе. С точки зрения бизнес анализа, юз-кейс является один из вариантов представления пользовательских требований.


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


Качественное проведение Discovery для разрабатываемого IoT приложения должно учитывать следующие моменты:

  • должен быть проведен анализ бизнес процессов заказчика;

  • выбор юз-кейсов должен быть подтвержден их соответствием заявленным бизнес требованиям;

  • юз-кейсы должны быть дополнены требованиями к их кастомизации для заказчика;

  • анализ юз-кейсов проводится с использованием, в первую очередь, таких инструментов, как метод персон, CJM (customer journey map) и Value Proposition Canvas;

  • должен быть сформирован бэклог с приоритезацией юз-кейсов и выявленных требований к их реализации;

  • должны быть выявлены требования к адаптации бизнес модели заказчика с учетом внедрения нового IoT приложения;

  • при выявлении требований критичным является уровень понимания бизнес аналитиком особенностей домена IoT с точки зрения технологий, бизнес приложений, особенностей обеспечения информационной и функциональной безопасности.


Цикл разработки требований и проектирования уместно проиллюстрировать диаграммой из BABOK Guide, где учитываются четыре категории требований:

  • Business Requirements или бизнес требования (уровень концепции);

  • Stakeholders Requirements или пользовательские требования (уровень юз-кейсов);

  • Solution Requirements или технические требования, включая функциональные и нефункциональные (уровень спецификации или бэклога);  

  • Transition Requirements или переходные (временные) требования, под которыми подразумеваются условия и возможности, которые должны быть реализованы при переходе от текущего состояния к требуемому, но которые не будут нужны после завершения изменений.


источник


Некоторые компании создают специальные фреймворки, чтобы помочь клиентам приоритезировать и выбрать юз-кейсы для IoT. Например, Siemens Advanta Customer Value Co-Creation процесс направлен на анализ идей заказчика относительно дигитализации бизнеса, на выявление персон и ценностного предложения. Затем эти положения валидируются на основе адаптации бизнес модели и CJM, в результате чего заказчик получает готовую к внедрению концепцию будущего решения.


Еще один подход - это использование Индекса зрелости Индустрии 4.0, разработанного немецкой академией acatech. В данном случае возможности внедрения технологий определяются культурой компании и ее готовностью к изменениям.

Выводы

В сложившейся ситуации интернет вещей остается технически сложным доменом, а технологии предлагают существенное разнообразие конкурирующих решений. Востребованность сторонних сервисов для IoT приводит к тому, что многие вендоры наращивают ресурсы именно в области интеграции решений, при этом, бизнес анализ назван одним из важнейших факторов успеха в проектах IoT.  Прогноз от IoT Analytics говорит о том, что рынок сторонних сервисов для IoT будет расти на 19% в год в течение следующих пяти лет. Успехов на этом рынке смогут добиться те компании, которым удастся зарекомендовать себя в качестве знающих и надежных партнеров на протяжении всего жизненного цикла проекта и всей цепочки создания ценности.

вторник, 11 мая 2021 г.

Безопасность блокчейн операций: новые возможности = новые риски

 

источник



Анализ уязвимостей, зафиксированных NIST (National Institute of Standards and Technology) в 2020 г., показывает устойчивый тренд роста в сравнении с предыдущими годами. В среднем, каждый день  фиксировалось 50 новых уязвимостей, 57% которых относились к критическому либо к высокому уровню серьезности последствий. Развитие технологии блокчейн, речь о безопасности которой пойдет в данной статье, не является исключением с точки зрения подверженности киберугрозам. Подход, который изначально создавался, как альтернатива недостаткам существующей банковской системы и должен быть открыть новые возможности для бизнеса, не избежал рисков, присущих финансовым онлайн операциям. С 2012 по 2020 гг. блокчейн-индустрия лишилась более $13,6 млрд в результате 330 хакерских атак.

В статье мы рассмотрим, в чем заключаются причины уязвимости решений на базе блокчейн.


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

  • криптографические алгоритмы;

  • ключи (кошельки);

  • алгоритмы консенсуса;

  • смарт-контракты;

  • ноды (узлы) сети;

  • компоненты пользовательского интерфейса и приложений.


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


Уязвимые компоненты

Возможные уязвимости

Примеры атак

Криптографические алгоритмы

Bitcoin & Etherium используют криптографический алгоритм Elliptic Curve Digital Signature Algorithm (ECDSA). В случае некорректной реализации генератора случайных чисел, используемого для подписи, при наблюдении за публично доступными транзакциями может быть восстановлен закрытый ключ, используемый для подписания транзакции. Некорректной реализацией может быть, например, использование константы в качестве случайного числа или повторное использование одного и того же случайного числа

В 2018 г. злоумышленники похитили  более $4 млн с кошельков пользователей IOTA. Все пострадавшие пользовались услугами вредоносного сайта для генерации секретных фраз

Ключи (кошельки)

В случае потери ключа пользователю невозможно предоставить доступ к своему аккаунту. При компрометации ключа невозможно перезаписать цепочку блоков. Возможна атака по словарю на закрытый ключ (полный перебор паролей




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

Алгоритмы консенсуса

Proof of work (PoW) подвержен атаке 51%. Если в руках злоумышленника находится больше половины всех вычислительных мощностей в сети, то он получает контроль над ее ресурсами, включая переписывание истории, проведение транзакций с двойным расходованием, блокировку чужих  транзакций, подтверждение своих блоков и т.п.

Консенсус Proof of Stake (PoS) атака Long Range

злоумышленник с незначительным минорным количеством средств может создать большое альтернативное количество блоков, которые по длине превзойдут основной блокчейн. Основной блокчейн может быть после этого подменен.

В случае использования алгоритма консенсуса Byzantine Fault Tolerance (BFT) атака возможно, если скомпрометирована одна треть вычислительных ресурсов сети

Реорганизация блокчейна и двойное расходование токенов  Ethereum Classic на сумму $460 тыс. (2019 г.)

Смарт-контракты

Смарт контракт по сути является компьютерной программой, которая может содержать ошибки и уязвимости. Особенностью является сложность внесения исправлений после распространения смарт-контракта в сети. Источниками уязвимостей являются: несоответствие стандарту ERC20 (токен Ethereum), некорректная генерация случайных чисел, неверное определение области видимости, некорректная верификация отправителя транзакции, целочисленное переполнение (integer overflow), ошибки в бизнес-логике, использования уязвимых внешних библиотек

Инцидент с проектом DAO в 2016 г., в результате которого была похищена криптовалюта на сумму $50 млн

Ноды (узлы) сети

Ошибки, допущенные при настройке инфраструктуры, развертывании блокчейн платформы, удаленном вызове процедур, настройке политики безопасности может привести к эксплуатации известных злоумышленнику уязвимостей с последующим несанкционированным добавлением транзакций в блокчейн

Возможность проведения атаки DNS rebinding

Компоненты пользовательского интерфейса и приложений

Блокчейн реализуется в веб среде и подвержен всем уязвимостям, присущим десктопным, мобильным и веб приложениям.

При проведении Initial Coin Offering (ICO) возможны дополнительные уязвимости, позволяющие провести атаку на организаторов ICO и уязвимости, позволяющие провести атаку на инвесторов

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

кража учетных данных для авторизации в приложении,

ввод пользователя в заблуждение путем подмены отображаемых цен


Блокчейн, как и любая веб технология подвержен влиянию человеческого фактора, а также уязвимостям, присущим мобильным и веб приложениям. Проблемой является и нехватка опытных разработчиков, имеющих опыт запуска проектов блокчейн. С одной стороны, блокчейн совершенствуется, и новые проекты, подобные Free TON или Ethereum 2.0, заявляют о новых качествах, таких как снижение энергопотребления, повышение скорости обработки транзакций, повышение эффективности протоколов консенсуса и т.д. Решит ли это все вопросы с безопасностью? Скорее всего, что нет. Поэтому, стоит помнить о базовых организационных приемах обеспечения безопасности, таких, как обучение персонала, аудит и анализ приложений, пентестинг, мониторинг и анализ  защищенности инфраструктуры, применение SIEM-систем для обнаружения и предотвращения атак.

пятница, 25 декабря 2020 г.

Assurance Case: аргументированное обоснование безопасности

 

source

Как наиболее полно оценить безопасность, и ничего при этом не упустить? Возможно ли собрать в одном документе (или диаграмме) все разнообразие артефактов, относящихся к безопасности, и организовать их таким образом, чтобы можно было наглядно представить любой аспект с понятным уровнем детализации?

Технические специалисты были бы рады изобретению такого «философского камня», который, если даже не обеспечил бы безопасность, то, по крайней мере, оценил бы ее с требуемым уровнем полноты. Подобные наработки существуют уже более 20 лет, однако, практически не известны русскоязычному читателю. Речь пойдет о методологии Assurance Case (или Safety Case), под которой подразумевается структурированный набор аргументов и документальных подтверждений, обосновывающих соответствие системы или сервиса заданным требованиям.

Введение


Перед прочтением статьи хотел бы обратить ваше внимание на пару важных моментов. Изложенный материал применим, в первую очередь, для объектов критической информационной инфраструктуры (КИИ). Для таких объектов, в частности, для информационных и управляющих систем, должен быть выполнен анализ безопасности. Результаты анализа безопасности представляются в виде соответствующих отчетов. Все это выполняется уже десятки лет, однако, отчеты, как правило, имеют произвольную текстовую форму, в логике которой не всегда просто разобраться.

Основная идея излагаемого подхода состоит в том, что результаты анализа безопасности могут быть представлены в графическом виде с использованием полуформальных нотаций, со всеми вытекающими отсюда преимуществами. Таким образом, Assurance Case является способом интегрального представления всех мер по обеспечению и оцениванию безопасности, не заменяя и не отменяя такие частные методы, как, например, тестирование, статический анализ кода, расчет надежности, FMEA, анализ рисков и т.п. Данная статья продолжает ранее опубликованную серию статей по безопасности.

Карты аргументов и их философские истоки


Как мы можем понять или утверждать, что некоторый объект является безопасным? Очевидно, для этого надо ввести ряд критериев. Однако, для этих критериев нам необходимо определить, насколько наше знание об объекте является достоверным? Почему мы можем этому знанию доверять? Что делает наши доводы и рассуждения действительно заслуживающими доверия? Углубившись в подобные проблемы, нельзя обойтись без философских дисциплин, таких как, онтология, гносеология, эпистемология, логика, а также, без великих мыслителей, которых волновали эти вопросы. В античном мире таковыми являлись Аристотель и Платон, а в эпоху «нового времени» основоположником современного научного метода считается Френсис Бэкон.

Что же можно сделать для обоснования или оценки безопасности разумным и логичным путем? В основе такого подхода лежит теория аргументации. Новый импульс современному развитию аргументации был дан в работе британского философа Стивена Тулмина под названием «The Uses of Argument», изданной в 1958 году. Тулмин расширил логический импликативный вывод дополнительными параметрами и предложил представлять эту операцию в графической форме. Нотация Тулмина оперирует следующими сущностями: data (D) – исходные данные для анализа, claim (С) – цель логического импликационного вывода (If D So C), warrant (W) – дополнительный аргумент, qualifier (Q) – степень уверенности в результатах логического вывода, rebuttable (R ) – дополнительный контраргумент (Рисунок 1).


Рисунок 1. Нотация Стивена Тулмина

Карты аргументов или аргументации (Argument Map) использовались в целях визуализации рассуждений и до Тулмина, но именно он наиболее удачно обобщил структурную модель для анализа и верификации аргументов. Отметим, что в современных картах аргументов, как правило, не используется нотация Тулмина, все упрощено, например, как на рисунке ниже. Это нотация, используемая платным онлайн сервисом Rational (бесплатная версия существует, но она крайне ограничена по функционалу) (Рисунок 2). Платная версия умеет преобразовывать полученные диаграммы в логически структурированный текст. На сайте также доступны бесплатные guides & tutorials по критическому мышлению и составлению карт аргументов.


Рисунок 2. Карта аргументов, разработанная при помощи сервиса Rational

Как видим, все довольно прозрачно, существуют всего четыре сущности и три типа связи между ними. Результат логического ввода называется Contention, подтверждающий аргумент – Reason (связь because), контраргумент – Objection (связь but), а вот контраргумент для контраргумента имеет специальное название – Rebuttal (связь however).

На данный момент не существует общепринятой нотации для составления карт аргументов. Нет единства и в обозначениях, применяемых для структуры аргументов. Например, результат логического вывода может называться claim, contention, conclusion, goal. Аргументы могут называться premise, justification и т.д. В области моделирования аргументов существует ряд международных инициатив и сообществ (например, Argument Interchange Format, AIF), но вопросы унификации они не решили. Существуют исследования, проводящие параллели между картами аргументов и ментальными картами (Mind Map, наверно, все о них слышали). Действительно, возможности Mind Map редакторов позволяют построить аналог карты аргументов.

История и концепция Assurance Case


Какое отношение имеет все это к безопасности? Чтобы ответить на этот вопрос, обратимся ко второй половине ХХ века, именно там берет свое начало современная теория и практика обеспечения безопасности. Тогда, в результате развития сложных техногенных отраслей, таких, как атомная энергетика, космическая техника, нефтегазовая и химическая промышленность, транспорт, человечество столкнулось с техногенными катастрофами невиданных ранее масштабов.

Тогда и появилась первые отчеты по анализу безопасности, в которых сводились воедино вся релевантные требования, а, также, информация, подтверждающая их соблюдение. Позже появился термин Safety Case (по сути, аналитический отчет по безопасности), который являлся предшественником Assurance Case. Отметим, что термины «Safety Case» или «Assurance Case» напрямую перевести термин на русский язык невозможно, в данном контексте, наиболее логичным переводом является «обоснование безопасности». Хотя, например, в российских переводах серии стандартов ИСО/МЭК 15026 (Systems and software engineering – Systems and software assurance) «Assurance Case» переведен, как «гарантийный случай».

Следует отметить, что в некоторых отраслях термин Safety Case применяется и в настоящий момент, наравне с Assurance Case. Assurance Case, будучи более современным термином, противопоставляется Safety Case в том смысле, что на сегодняшний день система должна соответствовать не только требованиям safety (функциональная безопасность), но, также, и security (информационная безопасность). Поэтому, предлагается использовать понятие Assurance Case, а Safety Case считать его частным случаем.

Под Assurance Case, в современном понимании этого термина, подразумевается отчет о выполненном анализе безопасности, включающий визуальное представление в виде графа или таблицы, полученных с применением полуформальных нотаций (о нотациях речь пойдет ниже). При этом, получается некоторое разночтение одного и того же термина, поскольку возможно трактовать Assurance Case, с одной стороны, как некоторый документ (отчет об анализе безопасности или отчет об обосновании безопасности), а, с другой стороны, как систему аргументации с использованием полуформальной нотации. В идеале, Assurance Case, может включать оба компонента, то есть документ, оценивающий безопасность, строится на основании модели аргументов.

Вернемся, однако, в ХХ век. Первым нормативным документом, требующим разрабатывать и анализировать Safety Case для потенциально опасных индустриальных объектов, стал «CIMAH (Control of Industrial Major Accidents Hazards) Regulations», первоначально выпущенный в Великобритании в 1984 году, а затем адаптированный и в ряде других стран. Более широкое внедрение Safety Case в практику стало происходить после небывалой аварии на нефтяной платформе Piper Alpha в Северном море, унесшей в 1988 году жизни 167 человек.

В 1990-х годах исследователи продолжают искать новые подходы к оцениванию безопасности. Идея, вроде бы, лежит на поверхности: давайте разработаем специальную нотацию для обоснования соответствия техногенных объектов и систем требованиям по безопасности. За дело взялись две британские университетские команды, лондонский университет Сити (City, University of London), где была создана спин-офф компания Adelard, и университет Йорка (University of York). Надо сказать, что и в наши дни Adelard и университет Йорка занимают лидирующие позиции в области продвижения Assurance Case.

Для разработки нотаций упор был сделан на логическую аргументацию того, что свойство или компонент системы соответствует заявленным требованиям. В качестве теоретической основы были выбраны уже рассмотренные нами труды Стивена Тулмина. Будучи гуманитарием, Тулмин вряд ли он думал о техногенных системах, однако, в историю, он вошел, в том числе, и как основоположник аргументации для Assurance Case.

Взяв за основу, нотацию Тулмина, британцы вскоре разработали методологию Assurance Case (называемую в то время Safety Case) и довели результаты до практических индустриальных внедрений. В университете Йорка, была разработана Goal Structuring Notation (GSN), эту тему продвигал PhD студент Tim Kelly под руководством профессора John McDermid. В результате произошел тот редкий случай, когда диссертация «Arguing Safety: A Systematic Approach to Managing Safety Cases. PhD thesis. University of York, 1998» уже больше 20 лет считается классическим трудом, и ее продолжают активно цитировать. Однако, подход к решению проблемы безопасности был, на мой взгляд, в большей степени академический, и, как результат, не был почему-то сделан вроде бы понятный и логичный шаг, связанный с разработкой программного средства для поддержки Assurance Case.

Adelard же, под руководством Robin Bloomfield и Peter Bishop, напротив, в первую очередь стремился к коммерциализации результатов. Параллельно с Йорком, в Лондоне была разработала нотация Claim, Argument and Evidence (CAE), а также программный инструмент Adelard ASCE (Assurance and Safety Case Environment), который поддерживает и CAE, и GSN. В Великобритании разработка Assurance Case (Safety Case) требуется законами и стандартами во многих областях, связанных с безопасностью, поэтому ASCE имеет здесь довольно устойчивый рынок. ASCE был и остается наиболее используемым инструментом разработки Assurance Case. Основной частью инструмента является графический редактор, в котором к графическим блокам может быть прикреплена дополнительная текстовая или гиперссылочная информация (Рисунок 3). Самостоятельно загрузить программное обеспечение ASCE с веб-сайта Adelard не получится. Вы должны заполнить запрос на 30-дневную пробную версию или академическую лицензию, после чего запрос будет рассмотрен компанией.


Рисунок 3. Интерфейс программы Adelard ASCE

Теперь рассмотрим две базовые нотации, применяемые для разработки Assurance Case (CAE и GSN).

Нотация CAE (Claim, Argument and Evidence)


Нотация CAE (Claim, Argument and Evidence – цель, аргумент, подтверждение) оперирует тремя указанными сущностями: цели указывают на достижение требуемых свойств системы, подтверждения предоставляют документированный базис для аргументации, демонстрирующей достижение либо не достижение целей, аргументы строятся при помощи правил вывода и связывают подтверждения с целями. Обычно применяются такие аргументы, как детерминистские (или логические), вероятностные и качественные. Для обозначения целей, аргументов и доказательств вводятся графические примитивы, имеющие различную форму (Рисунок 4).

Рисунок 4. Нотация Claim, Argument and Evidence (CAE): основные компоненты

Построение иерархии целей и подцелей является первым этапом разработки Assurance Case. Как показано на схеме, структура целей, аргументов и подтверждений не обязательно является трехуровневой, например, для поддержки аргументации могут использоваться дополнительные подцели. CAE нотация также легко трансформируется в табличный вид. Столбцами такой таблицы будут являться все те же цели, аргументы и подтверждения, между которыми теперь будут установлены связи в пределах табличных записей. Подобный подход к разработке Assurance Case используется, например, компанией exida.

Нотация GSN (Goal Structuring Notation)


GSN оперирует такими компонентами, как цель (goal, обозначается прямоугольником и является аналогом claim в CAE), стратегия аргументации (strategy, обозначается параллелограммом и является аналогом argument) и решение (solution, обозначается кругом и является аналогом evidence) (Рисунок 5). Контекст (context) применяется для информационной поддержки целей. Для поддержки аргументации могут применяться предположение (assumptions) и обоснование (justifications). Структура целей имеет иерархический характер.


Рисунок 5. Нотация Goal Structuring Notation (GSN): основные компоненты

Если сравнивать между собой CAE и GSN, то следует отметить, что CAE уделяет больше внимания обоснованию отдельных аргументов. Для этого выполняется детальное конструирование шагов аргументации. GSN больше фокусируется на типовых структурах (паттернах) аргументов. За счет большего числа сущностей, GSN является менее строгой, и, в то же время, при более лаконичном описании она может быть сведена к CAE. Применение каждой из нотаций может быть в достаточной мере субъективным, поскольку подход к конструированию аргументов зависит от лица, которое выполняет эту задачу. Некоторые практики Assurance Case отмечают, что в нотациях существует ряд пробелов, связанных с полнотой определения элементов семантики.

Сложилось так, что на сегодняшний день более распространенной является GSN. Формат GSN закреплен в стандарте «Goal Structuring Notation (GSN) Community Standard», а также в метамодели данных «Structured Assurance Case Metamodel (SACM)» от Object Management Group (OMG).

База знаний: отрасли, стандарты, исследования, инструменты, альтернативные нотации


Assurance Case используется, в первую очередь, в тех отраслях, в которых его применение регламентировано нормативными документами. Лидером здесь является Великобритания и некоторые другие страны Британского содружества. В отчете британской Health Foundation «Using safety cases in industry and healthcare» (2012) говорится об опыте нормативного применения Assurance Case (Safety Case) в здравоохранении, авиации, атомной энергетике, автомобильной, оборонной, нефтехимической и железнодорожной отраслях.

Если рассматривать требования к применению Assurance Case за пределами Великобритании, то следует отметить:
  • автомобильный стандарт ISO 26262:2011, Road vehicles – Functional safety, входящий в семейство стандартов по функциональной безопасности, детализирующих требования МЭК 61508;
  • документы European Organisation for the Safety of Air Navigation (EUROCONTROL): “Safety Case Development Manual, 2006”, “EAD (European Aeronautical Information System Database) Safety Case, 2009”, “EAD (European Aeronautical Information System Database) Safety Case Guidance, 2010”;
  • документированную общую позицию регулирующих организаций по ядерной безопасности в области лицензирования ПО для ядерных реакторов “Licensing of safety critical software for nuclear reactors – Common position of international nuclear regulators and authorised technical support organisations, 2018”, согласована девятью странами (Бельгия, Германия, Канада, Испания, Корея, Китай, Великобритания, Швеция, Финляндия);
  • стандарты серии ISO/IEC 15026, Systems and software engineering — Systems and software assurance, которая включает четыре части: Part 1: Concepts and vocabulary (2019); Part 2: Assurance case (2011); Part 3: System integrity levels (2015); Part 4: Assurance in the life cycle (2012).

Также следует отметить ряд организаций (помимо уже упомянутых Adelard и High Integrity Systems Engineering Group из университета Йорка), которые активно работают в области Assurance Cases. К ним относятся:
  • US-CERT (United States Computer Emergency Readiness Team), свою методологию они называют Security Assurance Cases;
  • SEI/CMU (Sofrware Engineering Institute – Carnegie Mellon University), в первую очередь, CERT Division, входящий в состав SEI, осуществляет исследовательскую и академическую поддержку для развития методологии Assurance Case и активно сотрудничает с US-CERT;
  • NASA (National Aeronautics and Space Administration) в рамках программы Scientific and Technical Information (STI) применяет Assurance Case для оценивания безопасности беспилотников и некоторых космических аппаратов;
  • среди всех академических публикаций, на мой взгляд, своей практической направленностью выделяются исследования John Rushby, выполненные по программам исследовательского института SRI International (бывший Stanford Research Institute), и особенно, отчет “The Interpretation and Evaluation of Assurance Cases”, к которому мы еще обратимся.

Из программных средств поддержки Assurance Case наиболее известным остается Adelard ASCE (Case Case and Safety Case Environment). Большинство проектов, упоминаемых в разные годы, так и не вышли на какой-либо серьезный уровень. NASA заявило о создании ПО AdvoCATE, но они применяют его в собственных целях, и не планируют выпускать на рынок. Учитывая простоту нотации, для составления диаграмм Assurance Case и их дополнения гиперссылками можно использовать, например, MS Visio.

Из альтернативных подходов к разработке Assurance Case можно также упомянуть программный инструмент NOR-STA. Он бы разработан польской компанией Argevide (spinoff Гданьского технологического университета). NOR-STA поддерживает собственную нотацию TRUST-IT. Разница состоит в том, что вместо графического представления NOR-STA использует структурированный иерархический список (Рисунок 6).



Рисунок 6. Нотация Trust-IT: основные компоненты и пример использования

Сущности в иерархическом списке целей Assurance Case обозначаются разными значками. Для подтверждения соответствия заявлению используется стратегия аргументации, а факты или наблюдения, обоснования, предположения и дополнительные утверждения используются в качестве аналога подтверждений. В отличие от десктопного Adelard ASCE, NOR-STA используется онлайн и поддерживает распределенную командную работу.

Кроме того, Assurance Case применяется для решения следующих прикладных задач:
  • оценивание атрибутов комплексных свойств, таких, как Quality, Dependability, Security;
  • поддержка сертификации и стандартизации путем преобразование требований стандартов в структуру аргументов;
  • Assurance Based Development (ABD) или разработка продукта, основанная на гарантиях, является разновидностью Model-Based Development (MBD);
  • управление знаниями, например, моделирования структуры документации либо определение структурных связей в какой-либо области деятельности (бизнес процессы, документооборот, управления изменениями и т.д.).

Применение Assurance Case в области информационной безопасности


Security (Trustworthiness) Case известен, как одна из разновидностей Assurance Case. При необходимости, Security Case может быть дополнен компонентами Safety Case. Собственно говоря, идея Assurance Case и состоит в объединении атрибутов safety & security. В области сертификации существуют наработки для стандарта ISO/IEC 15408 (Общие критерии), для которого было выполнено преобразование требований в структуру, совместимую со структурой Assurance Case. Такое преобразование может быть выполнено и для других релевантных стандартов, например, для ISO 27000, или IEC 62443, или любых других фреймворков.

В качестве примера приведен фрагмент Security Assurance Cases, размещенный на сайте US-CERT. В этом фрагменте рассмотрено подтверждение реализации безопасного цикла разработки ПО (Software Development Life Cycle, SDLC). Фокус сделан на устранение дефектов кодирования (в частности Buffer Overflow), для чего применяются такие методы, как обучение программистов, ревью кода, статический анализ и тестирование. Можно, конечно, поспорить с полнотой этого фрагмента, но он приведен лишь в качестве иллюстрации (Рисунок 7).


Рисунок 7. Фрагмент Security Assurance Cases

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

Пример практического применения Assurance Case


И, наконец, давайте рассмотрим на примере, как это все может работать. В основу положен подход, основанный на разработке структурированных аргументов.

Структурированные аргументы


Представим процесс разработки аргументов в виде двух последовательных шагов (Рисунок 8). Первый шаг, называемый шагом рассуждения (Reasoning Step, RS), – это анализ подцелей (SC), которые направлены на достижение основной цели (С). На этом шаге развивается структура аргументации. На втором шаге, называемом шагом подтверждения (Evidential Step, ES), формулируются подтверждения (Evidece, E) в поддержку подцелей (SC), выработанных на предыдущем шаге. Для дальнейшей формализации шагов RS и ES используются типовые шаблоны структурированного текста (Structured Text, ST).


Рисунок 8. Шаги и компоненты структурированных аргументов

Иерархия требований


Представим иерархию или пирамиду требований, которые образуют структуру, соответствующую графу Assurance Case. В большинстве нормативных требований к компьютерным системам или к ПО структура требований включает 3 или 4 уровня (Рисунок 9).


Рисунок 9. Иерархия требований и ее связь с шагами аргументации

Нулевой уровень – это мета-цель, согласно которой оцениваемая система должна соответствовать всем требованиям безопасности. На первом уровне достигаются глобальные цели безопасности, например, из требований МЭК 61508 к функциональной безопасности вытекают следующие цели:
  • должна быть реализована система управления безопасностью;
  • во время разработки системы (или ПО) должен быть применен жизненный цикл безопасности;
  • для системы должен быть применен достаточный комплекс мер защиты от случайных отказов;
  • для системы (или ПО) должен быть применен достаточный комплекс мер защиты от систематических и программных отказов, включая защиту от кибератак.

На втором уровне группы требований поддерживают ту или иную глобальную цель. Например, требования к управлению безопасностью (согласно МЭК 61508) включают группы требований к управлению персоналом, управлению конфигурацией, управлению документацией и другие. Структура связей между нулевым, первым и вторым уровнями представляет собой достаточно простое дерево. Такая структура не требует детальной проработки аргументов, поскольку аргументы эти являются типовыми и многократно проверенными в различных проектах. Однако при переходе со второго уровня на более низкие требуются структурированные аргументы. При этом требования нижних уровней могут быть составными (то есть, включать ряд отдельных требований) или простыми (атомарными). Если все требования атомарные (составные требования отсутствуют), то данный уровень становится третьим, и тогда он напрямую связан с подгруппами требований. Если имеются составные требования, то получаем более сложную четырехуровневую структуру.

Для самого нижнего уровня, помимо RS, также следует применять ES. Поскольку неудобно добавлять подробную информацию о содержании аргументов в структуру графа, каждый из узлов графа Assurance Case, начиная со второго уровня, размечается описанием аргументов с использованием структурированного текста (ST). Граф Assurance Case на нижнем уровне уже не является деревом, потому что одно и то же подтверждение (E) может поддерживать разные подцели (SC).

Assurance Case для группы требований к управлению персоналом (МЭК 61508)


В качестве иллюстрации рассмотрим фрагмент Assurance Case применительно к требованиям МЭК 61508 к управлению персоналом (МЭК 61508-1, раздел 6).

Структурированный текст, описывающий и объединяющий шаги рассуждения (RS) для всех релевантных требований
Reasoning Step (Human Resource Management)
Context
Connection between the group of Human Resource Management requirements of the Assurance Case Level 2 and composite and separate requirements of Level 3
Docs
Human Resource Management Plan
Claim
Human Resource Management complies with IEC 61508 requirements
Subclaim SC1 (IEC 61508-1, 6.2.1), SEPARATE
Persons responsible for specific activities shall be appointed
Subclaim SC2 (IEC 61508-1, 6.2.3), SEPARATE
Project participants shall understand their roles and responsibilities
Subclaim SC3 (IEC 61508-1, 6.2.4), SEPARATE
Communications of the project participants shall be defined
Subclaim SC4 (IEC 61508-1, 6.2.13), SEPARATE
Evaluation and assurance of the project participants’ competencies shall be performed
Subclaim SC5 (IEC 61508-1, 6.2.14a,…,k), COMPOSITE
Competencies shall be considered in relation to the particular application, taking into account all relevant factors
Subclaim SC6 (IEC 61508-1, 6.2.15), SEPARATE
Competencies of all responsible persons shall be documented
Subclaim SC7 (IEC 61508-1, 6.2.16), SEPARATE
Human resource management activities shall be implemented and monitored
Justification
Structure and content of the Human Resource Management Plan
END Reasoning Step

Всего из МЭК 61508 было извлечено семь требований, связанных с управлением персоналом. С точки зрения структурированной аргументации, эти требования являются подцелями (SС1,…,SС7). Лишь одна из подцелей (SС5) является составной, все остальные — атомарные. Для того, чтобы перейти от составной подцели (SС5) к атомарным (SС5.1,…,SC5.11), выполняется еще один шаг рассуждения (RS). При этом подразумевается, что согласно требованиям МЭК 61508, для проекта, связанного с созданием какого-либо абстрактного продукта, был разработан Human Resource Management Plan. Этот план интерпретирует требования стандарта в контексте проекта.

Структурированный текст для шагов подтверждения (ES)
Evidential Step ES1,…,ES6
Context
Connection with the subclaims of the Levels 3 and the Level 4
Docs
Human Resource Management Plan; Communications Plan; Training Plans; Training Reports
Claim
SC1,…, SC7
Evidence E1
Organizational Chart
Evidence E2
Project Roles Description
Evidence E3
Participants and Signature List
Evidence E4
Participants Communications Plan
Evidence E5
Competency Matrix
Evidence E6
Training Plans and Reports
Claim -> Evidence
SC1 -> E1&E2; SC2 -> E3; SC3 -> E4; SC4 -> E5&E6; SC5 -> E5&E6; SC6 -> E5&E6; SC7 -> E1&E2
Justification
Structure and content of E1,…,E6
END Evidential Step

Для выполнения всех шагов подтверждения (ES) предлагается использовать общий структурированный текст с указанием связей между подцелями (SG) подтверждениями (E). Будем использовать отношение SG -> E, чтобы обозначить взаимосвязь между соответствующей подцелью (SG) и поддерживающими ее подтверждениями (E).

Анализ составного требования SC5

Все полученные отношения SG -> E могут быть трансформированы в граф Assurance Case, согласно нотации GSN, модифицированной для структурированной аргументации (Рисунок 10). Этот граф отражает всю группу требований, связанных с управлением персоналом согласно МЭК 61508. Также данный граф можно использовать в качестве шаблона для выполнения оценивания на соответствие требованиям МЭК 61508.


Рисунок 10. Граф Assurance Case, полученный на основе структурированных аргументов для группы требований по управлению персоналом (МЭК 61508)

На первый взгляд все это долго и сложно, но, тем не менее, Assurance Case имеет свое практическое применение. Именно такой подход мы использовали при сертификации ПЛК RdICS на соответствие МЭК 61508.

Заключение


Метод Assurance Case (Safety Case) применяется на протяжении более 20 лет для анализа безопасности объектов КИИ. Наибольшее распространение данный метод получил в Великобритании и ряде стран Британского содружества для таких отраслей, как здравоохранение, авиация, атомная энергетика, автомобилестроение, оборонная, нефтехимическая и железнодорожная промышленность.

К достоинствам Assurance Case следует отнести все плюсы, достигаемые визуализацией отношений в сложной предметной области, за счет улучшения нашего восприятия и понимания. Недостатки обусловлены субъективностью метода в части его зависимости от экспертности лиц, выполняющих оценивание. Наиболее известный «epic fail» в применении Assurance Case описан здесь. Вкратце: 2 сентября 2006 г. в Афганистане произошел пожар на борту самолета Nimrod Британских ВВС. Проблема возникла из-за утечки топлива. Погибли все 14 человек, находившиеся на борту. Выпущенный ранее отчет Safety Case подтверждал безопасность воздушного судна. Расследование показало, что на серийных самолетах была не вполне корректно выполнена модификация топливной системы, и подобные проблемы возникали раньше, но почему-то никто не обратил на них внимания, как на системную ошибку. В выпущенном 600-страничном отчете это происшествие было названо не иначе, как «a failure of leadership, culture and priorities».

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

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