CC BY
40
Научная статья УДК 004.056
https://doi.org/10.24412/2073-0454-2023-1 -308-314 NIION: 2003-0059-1/23-595 MOSURED: 77/27-003-2023-01-794
Безопасность цифровых продуктов и услуг: принципы и элементы безопасного дизайна
Марина Юрьевна Пакляченко
Московский университет МВД России имени В.Я. Кикотя, Москва, Россия, marina_lion@mail.ru
Аннотация. Предлагаются подходы (принципы и элементы), основанные на правилах менеджмента, моделировании и риск-ориентированном подходе, преследующие цель обеспечения применимости требований информационной безопасности к различным секторам и направлениям. Выделенные и охарактеризованные категории ориентированы на область проектирования (дизайна) цифровых продуктов, сервисов, решений и услуг. Генезис ключевых категорий определяется лучшими практиками и передовым опытом лидеров отрасли (группа Сбер, Cisco, Kaspersky и др.).
Тематика востребована преимущественно для разработчиков программного и аппаратного обеспечения, облачных и системных решений (вендоров), потребителей цифровых продуктов, специалистов в области кибербезопасности, офицеров информационной безопасности.
Ключевые слова: информационная безопасность, кибербезопасность, методология защиты информации, цифровой продукт, безопасный дизайн
Для цитирования: Пакляченко М. Ю. Безопасность цифровых продуктов и услуг: принципы и элементы безопасного дизайна // Вестник Московского университета МВД России. 2023. № 1. С. 308-314. https://doi.org/10.24412/2073-0454-2023-1-308-314.
Original article
Security of digital products and services: principles and elements of secure design
Marina Yu. Paklyachenko
Moscow University of the Ministry of Internal Affairs of Russia named after V.Ya. Kikot', Moscow, Russia,
marina_lion@m ail.ru
Abstract. Approaches (principles and elements) based on management rules, modeling and a risk-based approach, aimed at ensuring the applicability of information security requirements to various sectors and areas are proposed. The identified and characterized categories are focused on the field of engineering (design) of digital products, services, solutions and services. The genesis of key categories is determined by the best practices and best practices of industry leaders (Sber Group, Cisco, Kaspersky, etc.).
The subject is in demand mainly for developers of software and hardware, cloud and system solutions (vendors), consumers of digital products, cybersecurity specialists, information security officers
Keywords: information security, cybersecurity, information security methodology, digital product, secure design
For citation: Paklyachenko M. Yu. Security of digital products and services: principles and elements of secure design. Bulletin of the Moscow University of the Ministry of Internal Affairs of Russia. 2023;(1):308-314. (In Russ.). https://doi.org/10.24412/2073-0454-2023-1-308-314.
Введение. Сущность и терминология безопасного дизайна
Снижение уязвимости может быть выполнено посредством обеспечения безопасности не только при эксплуатации [1], но и на этапе проектирования (дизайна) и в период жизненного цикла продукта (программного обеспечения, оборудования, системы, модуля или сервиса). Применение безопасности в дизайне требует эволюционного, гибкого подхода, который позволяет технологиям приспосабливаться к развивающимся процессам и расширяюще-
© Пакляченко М. Ю., 2023
муся ландшафту угроз за счет обнаружения новых уязвимостей.
Сказанное предполагает обновление внутренних процессов, ресурсов и возможностей, которые относятся к взаимосвязанным концепциям, продолжающим развиваться, например, в направлении обеспечения безопасности с помощью дизайна, безопасности по умолчанию, формированию жизненного цикла разработки с изначальным учетом требований безопасности и надежности. Несмотря на то, что все они коррелируют с разработкой продуктов с учетом тре-
ECONOMIC SCIENCE
бований безопасности (что актуально в рамках сертификации [2]), операционным управлением и методами снижения угроз, определенными регуляторами и профессиональным сообществом, в отрасли не существует согласованных унифицированных принципов как таковых. Термины часто используются взаимозаменяемо, хотя могут иметь разное значение в контексте менеджмента безопасности, что сказывается, в свою очередь, на качестве продукта.
Таким образом, актуально установление общего понимания концепций обеспечения безопасности, а также определение и описание некоторых связанных с ними принципов, лежащих в основе техник и практик, применимых в области разработки и эксплуатации цифровых продуктов.
Основная часть. Концепции безопасного дизайна
1. Базовые принципы безопасного дизайна 1.1. Принцип безопасности по замыслу цифрового продукта
Безопасность по замыслу — это проектирование с учетом правил безопасности: устранение рисков на ранней стадии создания продукта и в период всего жизненного цикла его разработки. Ее можно понимать как процесс проектирования с изначальным управлением безопасностью. Она применяется к проектированию, разработке, развертыванию и обслуживанию программного обеспечения, оборудования и услуг; а также к системной интеграции с помощью процесса инкапсуляции инструментов защиты, таких как, например, брандмауэры или средства мониторинга.
Безопасность по замыслу как принцип должна быть комплексным и всеобъемлющим решением: учитывать проектирование, специфику деятельности потребителя; ее реализация должна проводиться с участием инженеров, специалистов по безопасности и руководителей высшего звена. Например, соглашение о технологиях кибербезопасности в своем существе предлагает партнерам взять на себя обязательство проектировать, разрабатывать и поставлять продукты, в которых приоритет отдается безопасности: конфиденциальности, целостности и надежности, и, в свою очередь, снижать вероятность использования уязвимостей. Предлагается, что партнерские отношения между заинтересованными сторонами по проприетарным технологиям и технологиям с открытым исходным кодом должны стремиться к улучше-
нию совместной работы, обеспечению скоординиро-ванности действий по раскрытию уязвимостей и обмену информацией об угрозах с целью сведения к минимуму количества и вариаций вредоносного кода, формирующего небезопасное киберпространство.
1.2. Принцип безопасности по умолчанию в цифровом продукте
Безопасность по умолчанию базируется на безопасности по замыслу и ориентируется на процесс доставки предварительно настроенного продукта безопасным способом. Данный принцип можно понимать как использование настроек безопасности в функционале продукта для отказа. Необходимо, чтобы вендоры цифровых продуктов брали на себя ответственность за управление средствами безопасности, тем самым снижая зависимости от клиентов, которые, как правило, не участвуют во включении, управлении и контроле политик безопасности продукта. Вместе с тем, потребители могут снять с себя ответственность и применить меры безопасности посредством конфигурации цифровых решений, исходя из собственных целей, основанных на риске.
Безопасность по умолчанию является необходимым условием защиты, поскольку возможность настройки безопасности продукта должна быть добавлена на этапе проектирования. Например, в случае отраслевой интеграции или разработки на вторичном рынке, безопасность по умолчанию может потребоваться в части реализации адекватных экономичных средств управления безопасностью или настройки дополнений к небезопасным устаревшим (небезопасным) системам.
Прикладным воплощением данного принципа выступают следующие процессы: идентификация для безопасного подключения и аналогичные процедуры безопасного входа в систему, функции резервного копирования, документационное обеспечение безопасности, защищенные процессы обновления систем, сброс их настроек.
1.3. Принцип интеграции безопасности в жизненный цикл разработки продукта
Указанный фреймворк (Software Development Life Cycle, SDL/SDLC) представляется как некая модель реализации безопасности по замыслу и безопасности по умолчанию путем выполнения соответствующих мероприятий на каждом этапе жизненного цикла раз-
работки цифрового продукта [3]. SDL гарантирует, что риски безопасности моделируются и понимаются как производителями, так и потребителями, что позволяет принимать своевременные решения.
Изначально данный фреймворк как концепция был специально разработан для программного обеспечения, ныне он применяется в облачных службах и устройствах Интернета вещей (IoT). Примерами активно работающих SDL являются: Microsoft Security Development [4], Cisco (CSDL) [5]. Они представляют собой набор методов, поддерживающих обеспечение безопасности и выполняющих требования соответствия, способствуют созданию более безопасного программного продукта, уменьшая количество и серьезность уязвимостей, а также снижая затраты на разработку. Кроме того, они позволяют повысить отказоустойчивость и надежность продуктов. Сочетание инструментов, процессов и актуализации осведомленности, введенных в течение жизненного цикла разработки, продвигает многоуровневую защиту, обеспечивает целостный подход к отказоустойчивости продукта и формирует культуру осведомленности о безопасности. В SDL реализуется обучение сотрудников стандартам и принципам, проверенным решениям, обеспечение их осведомленности об угрозах. Таким образом, безопасность по умолчанию является частью дизайна, в частности, базовых требований к безопасности продукта.
1.4. Принцип надежности цифрового продукта
Надежность продуктов стала возможной благодаря строгому следованию принципам дизайна в процессе реализации упорядоченного и структурированного алгоритма, формирующего требуемые свидетельства и прозрачность для управления с учетом рисков. Вместе с тем, надежность можно рассматривать и в более широком смысле: как свежий взгляд на разработку безопасного программного обеспечения. Он опирается на SDLC, предусматривает нетехнические вопросы, такие как внутренние и репута-ционные процессы.
Принцип подразумевает сочетание методов повышения безопасности цифровых продуктов и инженерных технологий (например, программа управления уязвимостями, проверка и оценка третьей стороной), а также стратегии по увеличению доверия к программному обеспечению и повышению прозрачности и надежности их создании и эксплуатации. В
случае с программным продуктами это можно охарактеризовать наличием элементов, включенных в так называемые «Центры прозрачности» (Kaspersky Global Transparency Initiative [6]) для проверки исходного кода и в отношении технологий вендора, его инфраструктуры и методов обработки данных.
Система кибербезопасности E2E (end-to-end, сквозное тестирование), характерная для Huawei [7], объединяет аспекты корпоративных политик, организационных структур, бизнес-процессов, технологий и практик в 12 корпоративных процессах и бизнес-модулях: стратегия и управление, законы и правила, исследования и разработки, управление взаимоотношениями с поставщиками, производство и логистика, обслуживание и доставка, проверка и сертификация, прослеживаемость, устранение дефектов и уязвимостей, восстановление работоспособности и аудит.
Центр управления безопасностью Microsoft уделяет особое внимание безопасному обращению с данными клиентов в соответствии с принципами конфиденциальности и нормативными требованиями. В частности, поддержание целостности данных в облаке основано на следующих ключевых позициях: защита от киберугроз со встроенной автоматизацией и интеллектом; соблюдение требований конфиденциальности вместе с возможностью для клиентов контролировать их данные; соответствие национальным, региональным и отраслевым требованиям; ведение аудита для проверки технических требований к соответствию и контролю.
Таким образом, безопасный дизайн цифровых продуктов должен применяться в отношении его программной и аппаратной частей: оборудования и систем. Как правило, каждый компонент продукта тем или иным образом тестируется по настройкам по умолчанию, но когда они интегрируются в конечные решение, настройки меняются и могут появиться новые уязвимости. Следовательно, для цифровых продуктов необходимо тестирование как до, так и после внедрения, которое должно включать проверку конфигурации безопасности, тестирование на уязвимости и т. д.
2. Основные элементы безопасного дизайна
2.1. Моделирование угроз
Моделирование угроз — структурированный подход к сценариям угроз; инженерный метод идентификации возможных угроз, атак, уязвимых обла-
ECONOMIC SCIENCE
стей и определение мер противодействия, которые могут повлиять на продукт или связанную среду (сеть, архитектуру и т. д.). Это практика, которая позволяет разработчикам рассматривать, документировать и обсуждать последствия дизайна безопасности в контексте их запланированного конечного проекта в структурированном виде. Моделирование угроз следует использовать для проверки безопасности продукта и в средах, где существует значительный риск безопасности. Его необходимо применять на уровне компонента, приложения или системы. Непрерывное моделирование направлено на изучение меняющегося ландшафта угроз, тем самым на постепенное уточнение модели угроз путем оценки новых опасностей с помощью количественных показателей, а также добавления их в профиль рисков, если они существенны.
Поскольку моделирование угроз приводит к конкретным цифрам и последствиям, а также проясняет ценность и стоимость безопасности как таковой, в этом процессе должны быть задействованы различные организационные структуры вендора. Участвовать в моделировании должно высшее руководство: принимать решения об уровне приемлемых рисков и одобрять выделение ресурсов и действий по снижению рисков при разработке цифрового продукта. На оперативном уровне разработчики, специалисты по кибербезопасности и анализу угроз должны постоянно привлекаться к мониторингу среды: как с точки зрения информационной безопасности, так и с точки зрения безопасности цифрового продукта.
Модели угроз также находятся в зависимости от конечных потребителей продукта, способов его внедрения и реализации. Клиенты обладают разными уровнями необходимых требований безопасности и приемлемых показателей риска. Например, для вендора может быть приемлема определенная уязвимость, в то время как его клиенты могут счесть этот риск критическим из-за собственных бизнес-моделей. Кроме того, продукты в сети или интегрированной среде являются отдельным источником уязвимостей: они взаимодействуют и вместе настраиваются на работу как целостная среда, что порождает дополнительные риски.
Моделирование угроз предполагает, среди прочего, наблюдение за контекстом, в котором будет использоваться продукт или услуга. Это требует участия заказчиков и потребителей продуктов, которые часто не имеют необходимого представления о технологическом потоке производства цифрового решения, его
«ингредиентах», системной архитектуре и необходимых/возможных сторонних компонентов. Указанная ситуация снова подтверждает актуальность принципа прозрачности со стороны разработчиков цифровых продуктов.
Могут быть рекомендованы следующие шаги для моделирования угроз, характерных для цифровых продуктов (практика Cisco [5]): определение активов, построение схемы работы системы, индикация и анализ угроз, управление рисками и расстановка приоритетов, определение исправлений. На практике отслеживают поток данных в системе и определяют границы доверия и точки перегиба, где данные могут быть скомпрометированы. Как только потенциальные уязвимости и угрозы выявлены, могут быть реализованы «стратегии смягчения» для минимизации риска.
Для разработки программного обеспечения можно выделить иные алгоритмы моделирования угроз (практика Microsoft [4]): определение требований безопасности, создание диаграмм приложений, идентификация угроз, смягчение угроз, верификация смягчения. В отраслевых средах и экосистемах, для которых существенной является интегративная безопасность системы в целом, а не фокус на безопасности отдельных компонентов, должны быть учтены не только риски безопасности, допускающие некоторое время для их анализа и реакции, но и риски, требующие немедленной реакции в случае крупного инцидента.
Очевидно, учесть все вероятные угрозы невозможно, что делает затруднительным эффективное выделение и распределение ресурсов для борьбы с ними. Востребована стратегия повсеместного использования количественной оценки рисков и карты агрегированных тактик субъектов угроз, их методов и процедур, аналогично фреймворкам MITRE ATT&CK или моделям CVSS, которые позволяют приоритизи-ровать риски при разработке продукта или во время его жизненного цикла. Это дает возможность вендору увидеть вероятный арсенал злоумышленника, устранить известные уязвимости, которые возможно использовать в преступных целях.
2.2. Цепочка поставок и безопасность третьих сторон
Общепринятой отраслевой практикой является включение как проприетарных, так и сторонних компонентов с открытым исходным кодом в предложения продуктов: будь то программное обеспечение, облач-
ные сервисы, устройства или интегрированные системы от третьих сторон. Термин «третья сторона» используется для обозначения участника цепочки поставок продукта, который может находиться или не находиться в прямых отношениях с вендором, он влияет на критичность отдельной функции или совокупную работу продукта. Слабое внедрение и контроль соблюдения стандартов безопасности во всей цепочке поставок может создать условия для возникновения уязвимостей итоговой экосистемы. Таким образом, третьи лица можно считать одним из рисков кибербе-зопасности цифрового продукта. Для защиты процессов разработки продуктов от непреднамеренного или злонамеренного вмешательства третьих лиц, требуется внедрение общеотраслевого многостороннего подхода к управлению рисками цепочки поставок (supply chain risk management, SCRM).
Общий риск-ориентированный подход к цифровой цепочке поставок предполагает, что одним из основных стандартов для цепочки, помимо управления идентификацией и доступом, а также шифрования, должна быть непрерывная защита: компании должны предлагать обновления и исправления в течение разумного временного интервала жизненного цикла своих продуктов, систем и услуг с помощью безопасного механизма обновления.
Подобная идеология «заботы как обязанности» в ключе цепочки поставок все чаще обсуждается на соответствующих форумах и вебинарах. Предполагается, что вендоры должны убедиться, что их собственные компоненты безопасны и соответствуют современным требованиям и стандартам. Кроме того, поставщики должны придерживаться принципа прозрачности в отношении того, какие сторонние компоненты они используют в своих продуктах, и предоставлять сведения об обеспечении безопасности сторонних компонентов в интегративных цифровых продуктах.
2.3. Риск-ориентированный подход
Суть подхода как элемента безопасного дизайна к цепочке поставок компонентов цифрового продукта заключается в соблюдении основных условий: базовые требования, критичность поставщика, верификация.
Базовые требования — общие для всех вендоров, определяют основы, на которых поставщики должны функционировать, с целью обеспечить ос-
новы кибербезопасности для продукта отдельного направления или сферы. Например: защита персональных данных; политики безопасности; реагирование на инциденты; поддержка сотрудников и потребителей и др.
Критичность поставщиков учитывает тот факт, что разные поставщики (третьи стороны) оказывают на конечного потребителя разное воздействие; уровень воспринимаемой критичности зависит от факторов риска, т. е. от контекста со стороны пользователя цифрового продукта.
Верификация базовых требований зависит от критичности потребителя. Оптимальное решение возможных проблем в данном направлении — составления корректного договора между сторонним поставщиком и заказчиком, где будут четко определены сроки и ответственность в отношении установки исправлений и других обязанностей, связанных с безопасностью цифрового продукта и его отдельных компонентов.
2.4. Безопасная разработка и развертывание
Одним из ключевых элементов безопасного дизайна являются безопасная разработка и развертывание цифровых продуктов. Безопасность должна быть встроена во все компоненты «конвейера»: от разработки, сборки и тестирования, выпуска и развертывания, до проверки соответствия и иного контроля. В случае разработки программного обеспечения автоматизированные непрерывные интеграция и поставка должны включать правила безопасности и проверки, такие как ответственное кодирование, сканирование исходных кодов на уязвимости, динамический анализ кода, проверка зависимостей от уязвимостей и модульные тесты.
В качестве примера можно привести соблюдение стандартов безопасного кодирования (практика Cisco [5]) как единых наборов правил, руководств и лучших практик для программистов, обучение и опыт сотрудников — для обеспечения защиты кода от угроз. Сюда же может быть отнесено использование растущего числа проверенных общих модулей безопасности — библиотек, расширяющих возможности инженеров, обеспечивающих уверенность в развертывании функций безопасности (например, библиотеки, ориентированные на безопасные коммуникации, кодирование и хранение информации).
ECONOMIC SCIENCE
В то же время, необходимо улучшить навыки и внимание разработчиков безопасного кодирования посредством обучения и тренинга, в том числе в игровом формате и на киберполигонах. Перспективным видится создание облачных центров передового опыта, которые могут предоставлять сертифицированные продукты и сервисы различным командам (от киберполигонов) для поддержки создания облачных приложений.
2.5. Тестирование и проверка безопасности
Непрерывное и автоматизированное тестирование уменьшает векторы риска и помогает устранять уязвимости до выхода продукта на рынок. Тем не менее, автоматизированные инструменты по-прежнему ограничены в эффективном поиске уязвимостей.
В случае программного обеспечения, тестирование на уязвимости и проверка включают в себя статическое и динамическое тестирование, оценку уязвимости, фаззинг и пентест [9].
Интегрированные системы также нуждаются в тестировании, поскольку инкапсуляция множества продуктов и их конфигурация в конечной системе или среде являются основной причиной уязвимостей в итоговом цифровом продукте. Привлечение третьих лиц в процесс проведения тестов должно быть типовой практикой. Сюда могут входить программы вознаграждения за обнаружение уязвимостей, тестирование на проникновение или другие тесты, проводимые внешними командами.
В области объектов критической инфраструктуры тестирование и проверка должны быть обеспечены независимой стороной, обладающей официально подтвержденными полномочиями (прошедшей аккредитацию). Важно обозначить соответствующую проблематику: сложность выбора заслуживающей доверия стороны; ограниченная эффективность разовых внешних аудитов; баланс соблюдения конфиденциальности и прозрачности в отношении результатов аудитов (организации, проводящие аудит, должны гарантировать соблюдение соответствующей тайны).
2.6. Исправление и поддержка
Идеализированной ситуацией является та, при которой совершившийся инцидент информационной безопасности приводит к разработке и выпуску
исправлений со стороны производителя. Однако, проблемой может стать способность и готовность вендора распространить патч и организовать информационное обеспечение своих потребителей о случившемся происшествии. Некоторые клиенты могут пропустить оповещения, поэтому потребуется раскрытие информации через общедоступные каналы. В некоторых регулируемых средах могут существовать определенные стандарты, правила и требования о распространении соответствующей информации, обновлений и исправлений цифрового продукта.
Развертывание исправления представляет собой особую проблему: многие клиенты не устанавливают обновления по разным причинам (из-за отсутствия знаний и навыков; не могут позволить себе простои или иным образом ограничены правилами; исправление может привести к новым рискам или системным неисправностям, зависящим от исправляемого продукта). Кроме того, иногда изменение настроек требует и физических исправлений.
Заключение
Всемирно распространен и часто упоминается тезис об усилении кибербезопасности, но редки случаи конструктивных предложений о действенных стратегиях реализации желаемого.
В одном из направлений цифровизации общества и государства предлагается концепция повышения кибербезопасности, заключающаяся во внедрении, соблюдении, поддержке и контроле базовых принципов и элементов безопасности для производства цифровых продуктов и услуг, т. е. менеджмент кибербезопасности.
Подходы, основанные на принципах менеджмента, моделировании и риск-ориентированном подходе, имеют важное значение для обеспечения применимости требований информационной безопасности к различным секторам и направлениям (индивидуальное использование цифровых продуктов, эксплуатация в бизнесе, на объектах критической инфраструктуры и др.).
Предлагаемый краткий набор ограниченных, но универсально применимых принципов и элементов, преследует цель в виде гармонизации базовых требований для большинства игроков рынка (вендоров) и поддержке базовой кибергигиены потребителей цифровых продуктов, сервисов и услуг, расширению цифрового доверия и безопасности.
Список источников
1. ГОСТ Р ИСО/МЭК 27002-2021: Информационные технологии. Методы и средства обеспечения безопасности. Свод норм и правил применения мер обеспечения информационной безопасности // URL://https://docs.cntd.ru/document/1200179669.
2. Приказ ФСТЭК России от 3 апреля 2018 г. № 55 «Об утверждении Положения о системе сертификации средств защиты информации» // URL:// https://docs.cntd.ru/document/542622316.
3. Arthur M. Langer. Analysis and Design of Next-Generation Software Architectures: 5G, IoT, Bloc-kchain. Springer, 2020.
4. Operational Security Assurance (OSA) // URL:// https://www.microsoft.com.
5. Cisco Secure Development Lifecycle // URL:// https://blogs.cisco.com/tag/csdl?dtid=osscdc000283.
6. Прозрачность процессов в «Лаборатории Касперского» // URL://https://www.kaspersky.ru/blog/ transparency-update-2022/33099.
7. End-to-End Performance Measurement Scenarios // URL://https://support.huawei.com/enterprise.
8. David R. Bell. Location is (Still) Everything: The Surprising Influence of the Real World on How We Search, Shop, and Sell in the Virtual One. Amazon Publishing, 2022.
9. Building Secure and Reliable Systems. Best Practices for Designing, Implementing and Maintaining Systems. Google LLC. O'Reilly Media, Inc., 2020.
References
1. GOST R ISO/IEC 27002-2021: Information technology. Methods and means of ensuring security. Code of norms and rules for the application of information security measures // URL://https://docs.cntd.ru/do-cument/1200179669.
2. Order of the FSTEC of Russia dated April 3, 2018 No. 55 «On Approval of the Regulations on the Certification System for Information Security Tools» // URL://https://docs.cntd.ru/document/542622316.
3. Arthur M. Langer. Analysis and Design of Next-Generation Software Architectures: 5G, IoT, Bloc-kchain. Springer, 2020.
4. Operational Security Assurance (OSA) // URL://https://www.microsoft.com.
5. Cisco Secure Development Lifecycle // URL:// https://blogs.cisco.com/tag/csdl?dtid=osscdc000283.
6. Transparency of processes in Kaspersky Lab // URL://https://www.kaspersky.ru/blog/transparency-up-date-2022/33099.
7. End-to-End Performance Measurement Scenarios // URL://https://support.huawei.com/enterprise.
8. David R. Bell. Location is (Still) Everything: The Surprising Influence of the Real World on How We Search, Shop, and Sell in the Virtual One. Amazon Publishing, 2022.
9. Building Secure and Reliable Systems. Best Practices for Design, Implementing and Maintaining Systems. Google LLC. O'Reilly Media, Inc., 2020.
Информация об авторе
М. Ю. Пакляченко — доцент кафедры специальных информационных технологий учебно-научного комплекса информационных технологий Московского университета МВД России им. В.Я. Кикотя, кандидат технических наук.
Information about the author
M. Yu. Paklyachenko — Associate Professor of the Department of Special Information Technologies of the Educational and Scientific Complex of Information Technologies of the Moscow University of the Ministry of Internal Affairs of Russia named after V.Ya. Kikot', Candidate of Technical Sciences.
Статья поступила в редакцию 11.07.2022; одобрена после рецензирования 12.09.2022; принята к публикации 29.11.2022.
The article was submitted 11.07.2022; approved after reviewing 12.09.2022; accepted for publication 29.11.2022.
