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