Современные информационные системы (ИС) постоянно подвергаются атакам, целью которых является реализация угроз нарушения конфиденциальности, целостности и доступности ее информационных ресурсов [1, 2]. Для противодействия этому создается система обеспечения информационной безопасности (СОИБ), к которой предъявляются соответствующие требования, направленные на предотвращение вышеотмеченных нарушений. Однако современные нарушители используют все множества каналов атаки, включая сетевые (например, сниффинг), физические (например, несанкционированное проникновение в серверную), социальные [3] (например, выведывание пароля администратора средствами социальной инженерии) и др. [4]. Такое многообразие угроз приводит и к качественно разным типам требований, например, может потребоваться одновременно установка антивирусного программного обеспечения (ПО) на сервер, системы контроля и управления доступом (СКУД) в серверную, решеток на окна ее помещения и огнетушителей внутри и по периметру.А исходя из очевидной сложности и многогранности любой ИС и обеспечивающих ее работоспособность и устойчивое функционирование средств (например, источников питания, обслуживающего персонала и т.п.), количество требований оказывается внушительным. Для выполнения каждого такого требования необходимо определенное количество ресурсов (например, финансовых или человеческих), оно имеет сроки выполнения, которые не всегда могут укладываться в допустимые (например, требуется согласование закупки средства защиты, его установка и настройка занимают длительное время), а также приводит к качественному или количественному результату (например, устанавливается новый брандмауэр [5], или закрываются порты на старом), что с неизбежностью ведет к некоторой внутренней коллизии (аналогично взаимодействию организмов живой природы [6–9]) требований в достижении единой цели СОИБ – обеспечению информационной безопасности ИС. И все это в условиях дефицита времени, кадров и средств. Отсюда возникает задача ранжирования требований, включая обоснованный выбор последовательности их выполнения [10, 11].Решение указанной задачи усложняется следующими причинами. Во-первых, возможная противоречивость некоторых требований в принципе не позволит их выполнить напрямую (например, наличие решеток на окнах серверной, с одной стороны, не позволит туда попасть злоумышленнику, а с другой стороны, окажется препятствием для покидания помещения персоналом в случае пожара). Во-вторых, требования, если их рассматривать как некоторые математические множества X и Y, могут находиться в следующих отношениях: отсутствие пересечения – выполнение X не влияет на выполнение Y; равенство – выполнение X автоматически приведет к выполнению Y и наоборот; собственное включение – выполнение X приведет к частичному выполнению Y, однако выполнение Y приведет к полному выполнению X; пересечение (без их равенства и включения) – выполнение одного из X и Y приведет к частичному выполнению другого и наоборот. Ситуация окажется сложнее и менее предсказуема, когда в комбинировании участвуют несколько пересекающихся требований-множеств [12], потребляющих разные ресурсы и имеющих различные дедлайны (от англ. deadline – крайний срок выполнения), с учетом того, что совместное выполнение комбинаций группы требований будет приводить к выполнению других требований (например, что эффективнее – внедрить полноценную систему защиты информации от сетевых атак или установить несколько подсистем, обеспечивающих защиту в своих секторах?); а для выбора «идеального» их состава необходимо будет применять соответствующие оптимизационные методы. В-третьих, формулировка требований на различных понятийных аппаратах в принципе не позволит осуществлять какие-либо совместные логические операции (например, защита от сетевых атак может оперировать понятиями логических потоков и портов, а защита от проникновения – субъектами и характеристиками их физического перемещения в пределах контролируемой зоны). И, в-четвертых, следуя общепринятой практике, формирование и выбор требований часто ложится на плечи экспертов, которые в принципе не могут быть специалистами в различных областях (тех, к которым относятся угрозы ИС) [13] и, следовательно, при совмещении соответствующих требований могут быть допущены критические ошибки.Исходя из вышеизложенных причин, для взаимоувязывания всех требований по обеспечению информационной безопасности ИС, а также определения рационального (в идеале – оптимального) состава и порядка их выполнения требуется создание некоторого формализованного вида, который позволит как записывать все разнородные требования в единой нотации, так и проводить над ними строгие (то есть лишенные влияния субъективизма) оптимизационные мероприятия, что и является задачей текущего исследования.В интересах этого произведем аналитический обзор научных публикаций российских ученых на предмет различных подходов к формальной записи требований к различным объектам и системам. Анализ результатов обзора позволит понять текущее состояние поставленной задачи и возможности по ее решению.Обзор релевантных работДля обзора работ, посвященных различным аспектам формализации требований, воспользуемся базой РИНЦ. Формализации требований посвящено множество работ – журнальных статей, диссертаций, монографий, научных отчетов, докладов на конференциях, патентов: согласно поисковому запросу в научной электронной библиотеке eLIBRARY.RU – 10 341 (из 44 943 243 хранящихся в ней публикаций). Это говорит о значительном научном интересе к поднятому в статье вопросу и актуальности проводимого исследования. Произведем выборку 10 наиболее релевантных работ из найденных по поисковому запросу «формализация требований».Статья Р.Д. Гутгард, Е.И. Провилкова [14] посвящена формализации функциональных требований, предъявляемых к ИС при их создании. В ней приводится анализ ряда соответствующих подходов, и делаются следующие выводы. Во-первых, применение языка UML позволит формализовать задачи для разработчиков ПО, вплоть до уровня формата входных и выходных параметров, а также алгоритмов их преобразования. Во-вторых, использование карты влияний (в англоязычной литературе – Impact Mapping) и карты историй (Story Mapping) позволит упростить сам процесс разработки функциональных требований. Суть первой карты заключается в определении цели проекта и анализе того, какие изменения необходимы для ее достижения, суть же второй – в организации, визуализации и приоритизации пользовательских историй (применяется, как правило, при разработке ПО). В-третьих, разработка требований должна быть в форме, понятной как пользователям (то есть находящимся с внешней стороны ПО), так и разработчикам (то есть находящимся с внутренней стороны ПО). Сама формализация требований имеет вид нескольких таблиц, например, содержащей алгоритмы обработки информации. Указывается, что данный подход подойдет для случая слабой взаимной зависимости требований. В-четвертых, применение шаблонов может также частично решить задачу формализации требований. Приводятся следующие примеры шаблонов (жирным шрифтом отмечены переменные): типичное требование – «пользователь имеет возможность»; ограничительное требование – «пользователь не попадает под действие закона», «система выполняет функцию не менее чем число объектов, функционируя в условиях»; периодически-ограничительное требование – «система выполняет функцию каждые число единица измерения периода». В-пятых, классическим является документирование требований, для чего могут быть использованы следующие элементы: внешние и внутренние интерфейсы, бизнес-процессы и иная сложная логика, состояния системы и ее объектов, пользовательские задачи, нефункциональные показатели. И, в-шестых, рекомендуется строгое следование документу IEEE 830-1998, специфицирующему структуру и содержание документации с требованиями к ПО. Также в документе говорится о языках формализации требований, частично уменьшающих неоднозначность трактовки описаний на естественном языке. Авторы статьи предлагают следующую поэтапную последовательность формализации требований: 1) выявление информации о требованиях; 2) получение из информации формальных текстовых конструкций; 3) формирование функциональной части требований; 4) составление спецификации из атомарных действий.Автор статьи М.В. Харлов [15] исследует проблему несоответствия между уровнем подготовки специалистов и предъявляемым к ним требованиями. Модель данной предметной области анализируется на предмет формализации таких требований (в виде уровней усвоения учебной информации). Предлагается графическая схема порядка формализации, состоящая из пяти следующих этапов, на каждом из которых присутствует от одного до нескольких параллельно выполняемых шагов: 1) анализ предметной области деятельности и нормативно-квалификационных документов; 2) создание информационной модели предметной области; 3) определение весов связей в модели; 4) определение значимости уровней усвоения учебной информации; 5) формализация требований и их согласование.Диссертация М.Л. Глухарева [16] ставит своей целью «повышение оперативности и полноты выявления недекларированных возможностей в ограничениях целостности и триггерах реляционных баз данных». В интересах этого предлагается применять формализацию требований реляционных баз данных, для чего разрабатывается соответствующий научно-методический аппарат. Используемая для этого метамодель позволяет формировать требования двух классов – к состоянию и переходу. Каждое требование в метамодели характеризуется множеством таблиц – T, и конкретных столбцов – C. При этом требования к состоянию характеризуются множеством C, включающим только основные таблицы БД. Требования к переходу также характеризуются множеством T, но могут включать еще и псевдотаблицы с информацией о модифицированных строках. Также требование к переходу включает множество операций вставки/обновления/удаления строки, которые и активизируют переход.Общие вопросы формализации требований, предъявляемых к ИС экономической сферы, рассматриваются в статье [17]. Указывается, что собственно задача формализации сводится к применению уже известных методик проектирования и управления требованиями в области ПО; однако подчеркивается, что такой подход впоследствии приводит к необходимости постоянной доработки разработанных программных средств. Указывается одна из основных причин – формирование требований к ИС в виде требований к параметрам ее объектов, а именно – невозможность составления списка таких параметров, которые бы не менялись за короткий промежуток времени. При этом требуется хранение «исторических» значений этих параметров, отражая тем самым динамичность реального мира, свойства которого они содержат. В качестве решения предлагается учесть такие изменения при создании спецификации, которые априори не должны быть фиксированными.В статье В.В. Андреевой [18] для формирования требований к ПО предлагается использовать дивергентный подход, применяемый к квалификациям программистов. В его рамках вводится понятие «задача» в виде процесса разработки с неограниченным количеством применяемых решений, имеющего следующие компоненты: исходные данные – I, процесс получения результата – D и достижение цели – R. Каждый из компонентов может решаться как единственным вариантом (закрытый тип – С), так и их множеством (открытый тип – O). Путем некоторых комбинаций компонентов задач и вариантов решения (вида , где – компонент, – вариант) вводятся несколько уровней знаний, умений и навыков разработчиков – ученический (), алгоритмический (), эвристический (), исследовательский (, где – новое, полученное в процессе деятельности) и творческий (). Указывается снижение эффективности ПО вследствие противоречивости предъявляемых к нему требований (например, уменьшения доступной для использования памяти при повышении общей производительности работы). Также упоминается и то, что ошибки в требованиях могут приводить к отказам ПО.Похабов Ю.П. рассматривает вопрос формализации требований надежности, предъявляемых к механическим устройствам, применимым на космических аппаратах. Приводится большое разнообразие таких требований (массогабаритных, жесткость, прочность, стойкость к воздействиям и т.п.); при этом подчеркивается, что их выбор делается на основании квалификации и опыта экспертов, а также ряда «Best Practices». Для безотказного функционирования автор указывает на необходимость установки требований в виде качественных и количественных критериев. Трактовка надежности как непрерывной работоспособности детали, всесторонне испытанной перед и правильно используемой во время эксплуатации, закладывается в основу формализации требований [19].Статья [20] посвящена задаче тестирования ПО, для чего необходимо формирование требований к его составу и функциональным возможностям. Подчеркивается важность формы изложения требований, поскольку она используется разработчиками при непосредственном использовании языков программирования. В частности, формализация исходных данных (как основы требований) сделает документ спецификации более понятным конечному пользователю-читателю. В качестве положительных сторон данного документа указывается использование диаграмм, логических условий и математических формул, а в качестве отрицательных – использование естественного языка. Перечисляются основные инструменты, позволяющие частично снизить недостатки получаемых требований: Unified Modeling Language (язык для визуализации и документирования объектно-ориентированных систем и бизнес-процессов), UNIMOD (система для применения аппаратной парадигмы программирования), SDL (язык для разработок систем на базе конечных автоматов), ДРАКОН (язык визуального моделирования, позволяющий одновременно разрабатывать продукты инженерам и программистам).Авторы статьи [21] исследуют проблему оформления текстовых документов согласно заданным нормам, для чего определяют основные этапы алгоритма по формализации требований к ним. Суть алгоритма заключается в обработке текстового представления документа определенного стандарта, и всех на которые он ссылается, выявлении в стандартах требований к оформлению текстов, классификации структурных элементов документов (например, с применением машинного обучения), сопоставлении всех выявленных требований и элементов, систематизации и формализации результатов, а также создании итогового, уже программного алгоритма проверки по полученным результатам. Тем самым текстовое описание требований, собранное из множества стандартов и систематизированное по разделам посредством алгоритма, может быть переведено в соответствующее программное средство.Статья [22] посвящена упрощению и ускорению производства деталей на металлорежущих станках путем концентрации операций – то есть обработки множества различных деталей на одном станке различными инструментами. Для этого требуется задание требований к геометрии деталей с прямыми цилиндрическими поверхностями в формализованном виде. Приведены три примера, в которых сопряжение присоединяемой детали к базовой возможно: 1) без переустановки и нарушения целостности; 2) c переустановкой, но без нарушения целостности; 3) с нарушением целостности (переустановка тут может не рассматриваться). Требования к сопрягаемой поверхности детали даются в формализованном виде с помощью системы математических функций поверхностей для каждого участка Z-оси станка и деталей. Проверка факта сопряжения для каждого из примеров осуществлялась путем исследования указанных функций по «классической» методике, изложенной в работе [23].В статье [24] описывается формализация основной группы требований к учебному расписанию вузов в виде математических соотношений. В предлагаемую аналитическую модель, описывающую учебный процесс, вводятся следующие параметры (и их типы): группа (индекс) и ее студенты (число); группа (бинарная матрица); поток (матрица); аудитория (индекс), ее вместимость (число) и тип (перечисление); количество всех аудиторий (число); пара в неделю (порядковый номер) и их максимальное количество в день (число); преподаватели (индекс) и их общее количество (число); факт проведения преподавателем определенного занятия у подгруппы в аудитории. Затем выделяются четыре класса нормативно-ограничительных и внутривузовских требований: обязательные, важные, эффективностные и рекомендательные. Используя параметры модели, все указанные классы переводятся в формализованную форму (в статье рассматривается только первый класс). В рамках первого класса рассмотрены такие требования, как «Законодательные и нормативные ограничения» и «Ограничения, связанные с работой руководства вуза». Так, например, приводится запись требования о максимальной недельной загрузке студентов путем суммирования всех пар за неделю для всех подгрупп и преподавателей и сравнения результата с числом, указанным в образовательном стандарте и/или другом нормативном документе.Анализ результатовСистематизируем результаты обзоров релевантных работ в табличном виде (табл.) и произведем их анализ по ряду параметров. Для этого, помимо названий статей и годов публикаций, будем указывать область применения требований, форму их записи (а в случае отсутствия – ключевые особенности) и степень автоматизации при составлении требований. В случае нескольких значений параметра в одной статье – укажем их через запятую.ТаблицаСистематизация результатов обзора релевантных работСсылкаГод публикацииПредметная областьФорма/особенность записиСтепень автоматизации[14]2019Проектирование ИСДиаграммаКартаТаблицаТекстовый шаблонТекстовое описаниеЧастичная формализацияСредняяНизкаяНизкаяСредняяНизкаяСредняя[15]2019Подготовка специалистовИнформационная модельНизкая[16]2011Безопасность БДАналитическая модельВысокая[17]2007Экономическая сфераУчет темпоральностиСредняя[18]2005Разработка ПОСхема, частичная формализацияНизкая[19]2012Механические устройства (в космических аппаратах)Качественные и количественные критерииНизкая[20]2013Тестирование ПОЯзыки визуализациии визуального программирования.Аппаратная парадигма программирования.Язык разработки на базе конечных автоматовСредняя  Средняя Средняя[21]2021Нормоконтроль документовРучная программная модельНизкая[22]2015Производство металлодеталейМатематические функцииВысокая[24]2019Составление учебного расписанияАналитическая модельСредняя Результаты анализа (табл.) позволяют сделать следующие предварительные выводы. Во-первых, у публикаций (с учетом того, что, согласно поисковой выдаче, они являются наиболее релевантными к запросу) разброс годов публикаций достаточно большой – от 2005 до 2019, то есть около 15 лет, что говорит о постоянной актуальности решаемой задачи. При этом какого-либо существенного изменения в данном «тренде» не наблюдается; всплеск интереса в 2019 г. (когда было опубликовано сразу три работы вместо одиночных или их отсутствия в другие годы) можно считать статистическим «выбросом» (или совпадением). Во-вторых, затрагиваемые в статье области являются достаточно разнородными, хотя и с некоторым преобладанием сферы информационных технологий. Однако какого-либо единого или хотя бы обобщающего подхода как для формирования требований, так и для их записи обнаружено не было. В-третьих, применяемые или предлагаемые формы записи требований состоят из следующих: схемы различного рода, информационные и аналитические модели, категорирование, различные текстуальные и визуальные языки, базовая математическая логика и анализ; а в качестве особенностей записи можно отметить темпоральность (в части учета исторических изменений) и применение текстовых шаблонов. Отмечается некоторое преобладание аналитических моделей и программных языков, что, впрочем, нельзя считать «панацеей». И, в-четвертых, общую степень автоматизации при составлении требований в формализованной форме можно отметить как недостаточную: два подхода имеют высокий уровень, два – среднюю и семь – низкую. При этом подходы с высоким уровнем автоматизации (работы [3, 9]) относятся к узким областям применения.ЗаключениеИсходя из произведенного обзора, можно заключить, что предлагаемые подходы к формализации требований имеют, как правило, достаточно ограниченную область действия, высокую степень субъективности и с трудом поддаются применению строгих математических аппаратов. Как результат, ни один из них нельзя использовать для управления сложными процессами, состоящими из множества гетерогенных элементов – такими, как обеспечение информационной безопасности ИС. Таким образом, требуется создание нового подхода к формализации, по возможности учитывая озвученные выше наработки.Новизной проведенного исследования можно считать «пионерскую» попытку сбора и анализа накопленного научного опыта по решению указанной задачи с целью создания единой модели, что отличает исследование от аналогичных, направленных сразу на решение практических задач своей области по формированию требований. Теоретическая значимость работы заключается в базовой систематизации релевантных работ с целью последующего сравнения. Практическая значимость, уступая теоретической, также присутствует и заключается в формировании некоторых предпосылок для создания будущего метода (и, возможно, его реализации в виде программного средства) по переводу требований в полностью формальный вид.Продолжением исследования должно стать создание собственного математического инструментария как для единой формализации всех требований различного вида и назначения, так и для проведения над ними оптимизационных мероприятий по выбору перечня и порядка выполнения.