Перейти к:
МОДЕЛЬ ИДЕНТИФИКАЦИИ АГРЕССИВНЫХ ПРОГРАММНЫХ ЭЛЕМЕНТОВ
https://doi.org/10.35266/1999-7604-2024-1-4
Аннотация
Рассмотрены вопросы моделирования вычислительных процессов, позволяющих оценить потенциальные возможности используемых программных средств по негативному влиянию на работу различных видов человеко-машинных систем, в том числе обладающих признаками искусственного интеллекта. В ходе численного эксперимента анализировались программы, предоставляющие интеллектуальную поддержку роботам-ассистентам преподавателей и реализующие определенные функции в вычислительном комплексе «умного дома», с учетом их агрессивного поведения. Обсужден ряд вопросов, связанных с результатами этого эксперимента. Показан подход, позволяющий выделить группу операторов машинного языка программирования, имеющих потенциал для формирования программных закладок общего и специального видов, влияющих на информационную экологию и корректную работу компонентов «умного дома». Даны рекомендации по формированию набора признаков агрессивности в зависимости от специфики применения конкретных программных средств.
Ключевые слова
Для цитирования:
Дубровина А.И., Акперов Т.И., Александрова Т.С. МОДЕЛЬ ИДЕНТИФИКАЦИИ АГРЕССИВНЫХ ПРОГРАММНЫХ ЭЛЕМЕНТОВ. Вестник кибернетики. 2024;23(1):31-36. https://doi.org/10.35266/1999-7604-2024-1-4
For citation:
Dubrovina A.I., Akperov T.I., Aleksandrova T.S. A MODEL DETECTING AGGRESSIVE SOFTWARE ELEMENTS. Proceedings in Cybernetics. 2024;23(1):31-36. (In Russ.) https://doi.org/10.35266/1999-7604-2024-1-4
ВВЕДЕНИЕ
Определение агрессивных программных элементов в исследуемом программном средстве может быть осуществлено с помощью некоторой семантической модели, ориентированной на интерпретацию общих свойств программ, предположительно содержащих разрушающие функции. Основной задачей, решаемой такой моделью разрушающего программного средства (РПС), является выявление состояния вычислительного процесса, нарушающего безопасность и целостность программной среды в результате выполнения программы или отдельных ее участков. Кроме того, следует выделить и ряд дополнительных задач, способствующих решению основной задачи:
1) определение аномалий потока управления: «мертвого» (неисполняемого) [1] кода;
2) определение аномалий потока данных: побочного эффекта функций программного средства – изменения значений глобальных переменных в подпрограммах [1][2], неинициализированных переменных.
Исходя из специфики задач будем использовать конструктивный подход в теории семантики языков программирования. В соответствии с конструктивной точкой зрения язык определяется тем действием, которое он оказывает на машину, т. е. языком называется множество таких программ, выполнение которых на машине имеет совершенно определенные последствия. Построим семантическую модель анализа программы, используя основные идеи Венского метода, разработанного сотрудниками Венской лаборатории фирмы IBM [3].
МАТЕРИАЛЫ И МЕТОДЫ
Введем основные соглашения и обозначения.
В общем случае будем использовать символы для обозначения следующих компонент программы:
x – переменные;
v – выражения;
b – логические выражения;
Q – операторы;
C – списки операторов.
Пусть Х – множество всех возможных переменных, а Z – множество всех возможных значений переменных. Каждое из них может быть конечным или счетным. Неопределенное значение Λ также принадлежит Z: Λ ∈ Z.
Состояние памяти s определим как конечную функцию из Х в Z. Множество всех значений памяти обозначим через S, а его элементы – символами s, s1 и т. д. Множество S включает три подмножества состояний: Sл, Sн, S` – соответственно легитимное, нелегитимное и неустойчивое состояние (одновременное присутствие Sл и Sн).
Введем частичную функцию change:
Change: S × X × Z → S,
такую, что для всех s, s1, x и z:
s1 = change (s, x, z) ≡ s1 (x) = z & s =× s1.
Функция change описывает эффект изменения значения переменной х = z, когда машина находится в состоянии s. Эффект заключается в том, что переменной x теперь приписывается значение z, а значения остальных переменных не изменяются.
Семантическую структуру каждого оператора q представим в виде:
q = {fi; x1, …, xn; y1, …, ym}, (1)
где fi – одна из следующих функций (тип оператора):
function q:
x: = v → f1 (x, v);
b * q → f2 (b, q);
(C) → f3 (C).
f1, f2, f3 – выражения, определяющие желаемый результат в каждом случае;
x1, x2, …, xn – множество переменных, получающих новые значения при выполнении оператора q;
y1, y2, …, ym – множество переменных, используемых в операторе q и не изменяющих своего значения.
Условное выражение b может быть записано в виде:
(b → …
d → …).
Если b – истина, то результат берется из первой строчки, а в противном случае – из второй. Пустой оператор обозначим как Ω.
Опишем процесс вычисления программы в терминах модели-вычислителя [4][5]. В этой модели состояние машины не включает состояние «управление» как в модели-интерпретаторе. Состояние «управление», представляющее собой список операторов, которые предстоит выполнить после q, не влияет на семантику состояния si , получаемого в результате выполнения q. Модель определяется заданием функции, отображающей программу в ее вычислении. Под вычислением понимается конечная последовательность состояний памяти. Функция имеет следующий вид:
comp: S×Q → S* (S* = Sл ⋃ Sн ⋃ S`) (2)
comp: (s, Q) =
function Q:
Λ → (s`)
x: = v → (s; change (s, x, vs))
b * q → (bs → comp (s, Q),
d → (s))
(C) → comp (s, C)
Ω → (s).
Модель-вычислитель является основой построения операционной семантики языков программирования. Операционная семантика задается, как уже было показано, определением абстрактного «состояния машины» и смыслом конструкций языка с точки зрения их влияния на состояние, т. е. функции переходов из состояния в состояние:
Comp: S → S.
Уточним содержание понятия состояния памяти. S представляет собой вектор состояния, определяемый совокупностью множеств переменных X. В нашем случае вектор состояния S выглядит следующим образом:
S = {Xд, Xз, Xи, Xп},
где Xд = {xд1, xд2, …, хдn} – множество контролируемых глобальных системных переменных по критерию доступа (системные адреса, таблицы данных и т. п.);
Xз = {xз1, xз2, …, хзm} – множество контролируемых глобальных системных переменных по критерию запуска (значения системных регистров, размера свободной оперативной и виртуальной памяти, появления дополнительных переменных программы и т. п.);
Xи = {xи1, xи2, …, хиw} – множество контролируемых глобальных системных переменных по критерию использования ресурсов среды;
Xп = {xп1, xп2, …, хпt} – множество переменных программы.
Операционное определение исследуемой программы дадим в терминах функции Comp от двух аргументов – текста программы и вектора состояния, представляющего текущее состояние вычислений. Кроме того, введем дополнительно следующие функции:
- Znach, дающая значение выражения, соответствующего текущему состоянию: Znach: S× V → Z;
- End, дающая заключительный вектор состояния конечной последовательности состояний.
Подстановку значения в вектор состояния будем записывать следующим образом: если z – это значение, то вектор состояния s [x ← z] определяется как:
s [x ← z] {x} = z,
s [x ← z] {y} = s (y) для всех y ≠ x.
Смысл записи – «присвоить компоненте х вектора s значение z».
Функция Comp определяется для каждого из типов fi операторов:
Comp (x: = v, s) = s [x ← Znach (v, s)]; (3)
Comp (sл, sн; s) = Comp (sл, s) || Comp (Comp (sн, s), s);
Comp (s1; s2, s) = Comp (s1, s) || Comp (s2, End (Comp (s1, s))),
где || используется для обозначения конкатенации последовательностей состояний. Использование функцией Comp векторов состояний позволяет достаточно просто описать процесс функционирования программного средства.
Таким образом, основное преимущество операционной модели заключается в том, что операционное определение семантики программы может дать приемлемую реализацию [5][6].
РЕЗУЛЬТАТЫ И ИХ ОБСУЖДЕНИЕ
Цель эксперимента: идентификация конструкций, характерных для разрушающих программных средств с последующим формированием множества первичных признаков РПС.
В основе эксперимента лежит гипотеза о том, что разрушающие программные средства и обычные программы отличаются между собой по частоте использования некоторых конструкций применяемого языка программирования [7][8], характерного для человеко-машинных систем, например систем «умный дом», систем оценки уровня информационной экологичности информации в учебном процессе [8] и т. д. Исходя из специфики функций, выполняемых РПС, часть операторов и служебных идентификаторов (операндов), отвечающих за их реализацию, редко используется при написании обычных программ. При этом под обычными программами здесь будем понимать программы, не выполняющие совокупность указанных выше разрушающих функций и не имеющих механизмов исследования и маскировки в программной среде. Выявление такого различия позволяет определить первичные признаки РПС в программах, ориентируясь на которые можно повысить эффективность поиска, при этом получая минимальные временные затраты. От определения множества первичных признаков зависит результат идентификации разрушающих функций в программе.
План проведенного эксперимента:
- Выбор языка программирования, конструкции которого будут контролироваться в процессе анализа программ.
- Получение статистики применения операторов в программах на заданном множестве разрушающих программных средств и случайной выборки обычных программ.
- Обработка результатов анализа программ.
- Формирование множества первичных признаков – операторов программ.
Результаты выполнения программы характеризует гистограмма (рисунок), отображающая среднее арифметическое частот реализаций тех операторов, которые наиболее часто встречались в РПС по сравнению с обычными программами.
Рисунок. Результаты эксперимента
Примечание: составлено авторами на основании данных, полученных в исследовании.
Столбцы диаграммы темного цвета характеризуют результаты эксперимента на множестве разрушающих программных средств. Столбцы светлого тона – соответственно результаты эксперимента на обычных программных средствах.
Таким образом, эксперимент подтвердил предположение из [9] о том, что существует различие в реализации на операторном уровне между разрушающими программными средствами и обычными программами. Следует полагать, что данные операторы являются основой построения разрушающих программных конструкций и могут быть использованы в качестве «опорных» точек в методике идентификации программных закладок.
ЗАКЛЮЧЕНИЕ
- Разработанная методика идентификации программных закладок позволяет определять в исходных текстах программ неизвестные разрушающие функции (агрессивные программные элементы) на основе описанной логической системы распознавания.
- Предложенные методы семантического анализа программы, ее моделирования в рамках квантового представления являются универсальными с точки зрения стилистики программ, их реализации на любых языках программирования, особенностей ВС.
- Эксперимент с контрольной группой разрушающих программных средств позволил сформировать множество первичных признаков РПС и показал отличительные особенности реализации разрушающих функций в РПС.
Список литературы
1. Алекперов И. Д., Храмов В. В., Горбачева А. А. и др. Информационная безопасность и защита информации в цифровой экономике: элементы теории и тестовые задания. Ростов н/Д. : Южный университет (ИУБиП), 2020. 114 с.
2. Арапова Е. А., Бочаров А. А., Вострокнутов И. Е. и др. Возможности искусственного интеллекта в совершенствовании информационного образовательного пространства регионов России : моногр. М. : ООО «Издательский Центр РИОР», 2022. 140 с.
3. Храмов В. В. Особенности использования принципа информационного следа при поиске программных закладок // Вопросы защиты информации. 2001. № 3. С. 39–40.
4. Храмов В. В., Трубников А. Н. Модель специальной программной закладки // Вопросы защиты информации. 1998. № 1–2. С. 36–37.
5. Akperov I. G., Akperov G. I., Alekseichik T. V. et al. Soft models of management in terms of digital transformation. Vol. 2. Monograph. Rostov-on-Don: PEI HE SU (IUBIP); 2020. 256 p.
6. Линденбаум Т. М., Попов О. Р., Храмов В. В. Введение в информационную экологию: технологические предпосылки // Актуальные проблемы и перспективы развития транспорта, промышленности и экономики России : сб. науч. тр. Междунар. науч.-практич. конф., 09–11 ноября 2020 г., г. Ростов-на-Дону. Ростов н/Д. : Ростовский государственный университет путей сообщения, 2020. С. 136–139.
7. Khramov V. V., Trubnikov A. N. Analysis of the aggressiveness of a software product. Automatic Control and Computer Sciences. 1999;33(2):28–34.
8. Khramov V. V. Development of a human-machine interface based on hybrid intelligence. Modern Informa-tion Technologies and IT-Education. 2020;16(4):893–900.
9. Храмов В. В., Горбачева А. А., Фомичев Д. П. Моделирование недекларированной активности программного средства в условиях нечеткости исходных данных // Информационная безопасность: вчера, сегодня, завтра : сб. ст. по материалам III Междунар. науч.-практич. конф., 23 апреля 2020 г., г. Москва. М. : Российский государственный гуманитарный университет, 2020. С. 124–130.
Об авторах
А. И. ДубровинаРоссия
аспирант
Т. И. Акперов
Россия
аспирант
Т. С. Александрова
Россия
аспирант
Рецензия
Для цитирования:
Дубровина А.И., Акперов Т.И., Александрова Т.С. МОДЕЛЬ ИДЕНТИФИКАЦИИ АГРЕССИВНЫХ ПРОГРАММНЫХ ЭЛЕМЕНТОВ. Вестник кибернетики. 2024;23(1):31-36. https://doi.org/10.35266/1999-7604-2024-1-4
For citation:
Dubrovina A.I., Akperov T.I., Aleksandrova T.S. A MODEL DETECTING AGGRESSIVE SOFTWARE ELEMENTS. Proceedings in Cybernetics. 2024;23(1):31-36. (In Russ.) https://doi.org/10.35266/1999-7604-2024-1-4