НОВАЯ ПАРАДИГМА ИНФОРМАЦИОННОЙ БЕЗОПАСНОСТИ: ВЗГЛЯД ОСНОВОПОЛОЖНИКОВ

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

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

 Consider changing the paradigm of information security associated with the formulation of properties of trust in a telecommunications system, introduced a measure of trust, depending on the roles and actions in the system and it is shown that the validation of the properties of trust are possible in a system of distributed registries.

Keywords: information and telecommunication system(s), information security, trust, role, validation, blockchain

Введение

Анализ научных публикаций в области информационных технологий за последние несколько лет свидетельствует о том, что активное развитие информационно-телекоммуникационных систем (ИТС) как систем массового  обслуживания, формирование больших, по  количественному составу, групп пользователей таких систем, привело к новым запросам к свойствам по защищенности и качеству обрабатываемой информации, выходящих за пределы классической триады «конфиденциальность- целостность-доступность». Как следствие, начинают появляться системы, в которых реализовано обеспечение, пусть и в неявном виде возникших требований, которые не учитывались в системах предыдущих поколений [1].

Появление технологии распределенных реестров и её общественное признание свидетельствует о реализации явочным порядком новых подходов к обеспечению информационной безопасности (в широком смысле понятия). Так, в [2] утверждается, что технология блокчейн помогает решить т.н. задачу византийских генералов, т.е. в определенной степени обеспечивает децентрализованный консенсус. Говоря другими словами, можно утверждать, что блокчейн обеспечивает доверие одних узлов сети к результатам работы других узлов.

Необходимо отметить, в научной и методической литературе последних лет все чаще встречаются термины «доверие» и «доверенные системы». Этот процесс отражает объективные закономерности в развитии науки о компьютерных системах. Отечественные источники, в частности ГОСТ Р ИСО/МЭК ТО 13335-5-2006, рекомендуют использовать термин «доверительные отношения» и «доверительная среда».

Термин «доверие» в применении к ИТС означает эволюцию от узкого понимания надежности и безопасности компонентов системы в сторону общеметодологических вопросов обеспечения выполнимости целевой функции ИТС, той функции, для которой она предназначена и создается.

Доверие – свойство системы, объективно, обоснованно и документально выраженное основание того, что элемент системы (в терминах стандартов - изделие ИТ, продукт ИТ, компонентов ИТС, ИТС в целом) отвечает априорно заданной (регламентациями высшего уровня) целевой функции на всем протяжении своего жизненного цикла и во всех режимах функционирования.

Представляется, что на современном уровне технологий и развития ИТС для большинства пользователей доверие представляет из себя триаду, схематично изображенную на рисунке.

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

Доверие к средствам обработки информации с методической точки зрения на настоящий момент проработано наиболее детально. В том случае, если постулируется необходимость того, что ИТС должна точно соответствовать той целевой функции, для реализации которой она создается, то естественным является рассмотрение жизненного цикла ИТС, начиная с формулирования корректной, непротиворечивой целевой функции и рассмотрения архитектуры ИТС, как заданной в терминах системного анализа целостности компонентов ИТС и связей между ними. Считается, что разработанная в соответствии с определенными требованиями к процедуре разработке программно-аппаратная среда является доверенной.

Доверие к механизмам разрешения конфликтов является относительно новым требованием со стороны пользователей ИТС, хотя раздел 13.2.6 «Обработка инцидентов» ГОСТ Р ИСО/МЭК ТО 13335-5- 2006 описывает факт наличия «документированных и осуществимых схем действий при обработке инцидентов». Вместе с тем, данное требование носит общий характер и не может быть непосредственно реализовано при разработке конкретных систем.

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

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

В качестве примера рассмотрим модифицированную задачу, которую для отличия от классической, назовем задачей византийских адмиралов.

Византийский флот, поделенный на n эскадр, каждая из которых возглавляется своим адмиралом, осаждает морскую цитадель, окруженную m фортами (m≥n). Пройти напрямую к цитадели, не взяв форт, нельзя. Время осады дискретно и отсчитывается в световых днях (ночью осада не ведется). Во время k-того светового дня i-тая эскадра, осаждающая соответственно j-тый форт, имеет три возможности:

1.        Передислоцироваться к другому форту (при этом считается, что две эскадры не могут одновременно атаковать один форт).

2.        Обстреливать форт из корабельных орудий.

3.        Высаживать десант морской пехоты.

Защита фортов ведется, используя маневр силами защитников. Под покровом ночи защитники могут:

1.        Вывести силы из форта (в этом случае обстрел из орудий наносит минимальный ущерб, но форт уязвим для атаки морской пехоты).

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

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

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

Основное отличие от задачи о византийских генералов заключается в том, что адмиралы, в случае предательства, могут преследовать свои цели двояким образом – как с использованием сообщений, так и путем истощения ресурсов своей эскадры (например, запасов снарядов для орудий) и последующим выводом ее из участия в осаде. Считается, что выход как минимум одной эскадры из состава атакующих резко снижает потенциал атакующих. Задача лояльных адмиралов состоит в формировании такого алгоритма действий, который, как и в классической задаче, позволял выявлять предателей, или в терминах настоящей статьи, разрешать конфликты.

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

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

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

В представленной выше таблице описаны шесть возможных действий при эксплуатации системы, ее атаки злоумышленником, расследовании инцидентов. Очевидно, что полный набор составляет 26=64 сочетаний, поэтому в качестве иллюстрации приводится только пять сочетаний, включая штатную работу. Обратите внимание, что две колонки озаглавлены «Защита…», а две колонки «Угроза …». Для ситуации «защита» мнение экспертов подтверждает мнение пользователя о совершенном действии, при «угрозе» мнение пользователя и экспертов разняться.

Задав перечень ролей и перечень действий как двоичную функцию, принимающую значение «истинно»/«ложно», мы можем в виде предикатов описать случаи, на которые требуется организовать реакцию системы. При этом множество случаев, на которые требуется реализовать реакцию системы, можно описать в виде предикатного выражения, по аналогии с функциями булевой алгебры.

Опишем это формально. Пусть ri – i-я базовая роль в проектируемой системе, aj – j-е базовое действие. Тогда

двоичная переменная, описывающая факт выполнения i-й базовой ролью j-го базового действия. С учетом введенных переменных, описание отношений R между ролями в проектируемой ИТС может быть описано как

Если отношение выполнения базовыми ролями базовых действий в формуле R не заданы, то считается, что требование по реагированию на сочетание данных действий в ИТС не предъявляется.

Если в системе задано n базовых ролей, а базовых действий m, то всего двоичных переменных будет задано n+m, а значений булевой (двоичной) функции 2n+m.

Для приведенной таблицы n=5 (пользователь, администратор, разработчик, эксперт (аудитор), злоумышленник) и m=6, таким образом значений функции 211 = 2048. Тогда функцию, как указано выше, можно задать в виде дизъюнктивной нормальной формы или в виде эквивалентного полинома Жегалкина.

Можно утверждать, что функция f будет зависеть не менее, чем от n+m переменных, в противном случае реагирование не зависит от каких-либо действий или ролей.

Таким образом, базовая теорема доверенной системы (базовая теорема Правикова-Щербакова) формулируется следующим образом.

При наличии в системе n базовых ролей и m базовых действий, функция реагирования зависит ровно от n+m двоичных переменных, а значений этой функции равно 2n+m

В приведенной таблице задано 6 реакций из 2048 возможных.

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

D=(Nr/Nf), где

Nr – число описанных реакций (описанных предикатом значений),

Nf=2n+m – общее количество значений функции реагирования.

Система будет тем более доверенной, чем больше количество описанных предикатом значений будет стремиться к числу значений функции, т.е. мера доверия будет стремиться к 1. Говоря неформально, при сформулированном подходе, доверенная система позволяет обеспечить соблюдение интересов легальных пользователей ИТС.

Выводы

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

Список литературы

1.    М.Р. Биктимиров, А.Ю. Щербаков Проблемы синтеза доверенных систем // Труды ИСА РАН, т.53, 2012 - с. 264-271

2. Равал С. Децентрализованные приложения. Технология Blockchain в действии. СПб.: Питер, 2017.