Воронежский государственный технический университет

УДК 621.3

Д.А. Кабанов

контроль целостности прикладнОГО программнОГО ОБЕСПЕЧЕНИЯ АСУ КРИТИЧЕСКОГО ПРИМЕНЕНИЯ

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

Основной формой реализации угроз безопасности информации в АСУ критического применения (АСК) являются программные атаки, под которыми понимается способ получения НСД к информационным объектам посредством использования программного обеспечения (ПО).

Программные атаки могут осуществляться локально (источник атаки размещен в локальной вычислительной сети (ЛВС)) или удаленно (с использованием каналов связи транспортной сети). В ряде случаев программные атаки могут быть реализованы в обход КСЗИ, что является важным фактором, так как получив НСД к элементам АСК, злоумышленник получает возможность контролировать работу сети в течении длительного времени.

Инициаторами программных атак могут выступать как авторизованные пользователи, так и внешние злоумышленники. Для реализации программных атак используются ошибки или недокументированные возможности штатного ПО или внешние деструктивные программные средства, объединяемые общим понятием «программы с потенциально опасными последствиями» [1].

Под программой с потенциально опасными последствиями понимается некоторая самостоятельная программа (набор инструкций), которая способна выполнить любое непустое подмножество перечисленных ниже функций:

1. Скрывать признаки своего присутствия в программно-аппаратной среде.

2. Обладать способностью к самодублированию, ассоциированию себя с другими программами и/или переносу своих фрагментов в иные области оперативной (ОП) или внешней памяти.

3. Разрушать (искажать произвольным образом) код программ в ОП.

4. Сохранять фрагменты информации из ОП в некоторой области внешней памяти прямого доступа (локальной и удаленной).

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

6. Подавлять информационный обмен в телекоммуникационных сетях, фальсифицировать информацию.

7. Нейтрализовать работу тестовых программ и систем защиты информационных ресурсов.

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

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

Для АСК ПЗ имеют достаточно специфические цели внедрения: нападения исследования систем защиты элементов вычислительной среды и т.д..

Таким образом, ПЗ представляют наиболее опасный класс программных средств вследствие возможности управления их работой со стороны злоумышленника и высокой сложности защиты от них с использованием «традиционных» средств и методов защиты [2].

Вирусы и ПЗ, объединяемые понятием «деструктивный код» предполагают решение злоумышленником задачи их внедрения и активизации.

«Деструктивный код» может быть внедрен в АСК тремя основными способами:

включением ПЗ в аппаратные и программные средства импортируемых средств вычислительной техники и периферийного оборудования, и при небрежном проектировании прикладного ПО;

агентурным путем (через авторизованных субъектов доступа АСК);

в результате выполнения локальных или удаленных программных атак.

Классификация угроз активизации деструктивного кода представлена на рис. 1.

Рис. 1. Классификация угроз активизации «деструктивного кода»

Активизация деструктивного кода возможна по следующим каналам: электромагнитному (подачей электромагнитного импульса); электропитания (по цепям электропитания); программному (посредством программного воздействия).

По способу инициализации деструктивного кода, различают автономный и принудительный способы. Автономная инициализация может проводиться автоматически, по истечении определенного времени или при достижении АСК определенного состояния (по событию).

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

при определенных действиях пользователя;

при получении удаленного сигнала.

По технологии реализации, активизация деструктивного кода (ДК) может осуществляться посредством атак, направленных на переполнения буфера, программных и аппаратных закладок, а также в результате вирусного заражения.

Наиболее распространенным и эффективным способом внедрения и активизации ДК являются программные атаки, направленные на переполнения буфера [2].

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

Реализация переполнения буфера требует решения двух подзадач:

подготовки кода, который будет выполняться в контексте привилегированной программы;

изменения последовательности выполнения программы с передачей управления подготовленному коду.

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

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

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

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

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

Рис. 2. Схема атаки «срыв стека»

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

4. Искажение указателей данных. Данный способ не предусматривает явной передачи управления подготовленному коду, но предполагает, что передача происходит на основании оригинального алгоритма программы. Другими словами, подготовленный код запускается в ходе обычной, не искаженной, последовательности исполнения программы.

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

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

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

Таким образом, существует реальная угроза несанкционированного изменения хода выполнения прикладных программ, защита от которой существующими средствами защиты информации не обеспечивается в полной мере. В связи с этим возникает необходимость контроля целостности прикладных программ пользователя во время их выполнения, то есть обнаружения в программе отклонений от маршрута выполнения функциональных объектов. Функциональный объект – элемент программы, осуществляющий выполнение действий по реализации законченного фрагмента алгоритма [2].

Литература

1. Оптимальный синтез и анализ эффективности комплексов средств защиты информации: Монография / В.Г. Кулаков и др. Воронеж: Воронеж. гос. техн. ун-т, 2006. 137 с.

2. Методы и средства автоматизированной оценки и анализа качества функционирования программных систем защиты информации: Монография / М.А. Багаев др. Воронеж: Воронеж. гос. техн. ун-т, 2004. 181 с.

ВВТУ ФСО РОССИИ

УДК 621.3

О.И. Перетокин

Анализ процесса сертификации программных

систем защиты информации АСУ критического

применения

Производится анализ процесса сертификационных испытаний программных систем защиты информации АСУ критического применения. Для повышения эффективности сертификационных испытаний ПСЗИ АСК необходимо совершенствование существующего и разработка нового и информационного обеспечения

Анализ нормативной документации [1-9], определяющей базовые требования к разработке, испытаниям и эксплуатации КСЗ, в том числе и ПСЗИ, показывает, что сертификационные испытания являются необходимым этапом при создании и комплексировании ПО АСК. Так руководящий документ [5] содержит требования, в соответствии с которым обработка секретной, ценной и особо ценной информации разрешается только с использованием сертифицированных средств и систем защиты. Таким образом, этап сертификации, содержащий соответствующие испытания, проверки и исследования, обязательно должен входить в число работ при создании ПО АСК.

Исследования, проверки, испытания и приемка защищенных АС, в том числе и программных средств, проводятся в установленном порядке в соответствии с ГОСТ В15.307-77, ГОСТ В15.210-78, ГОСТ 23773-88 и НД по ИБ. Требования и порядок проведения процесса сертификации регламентируются в [1,5,6]. Перечень требований, предъявляемых при сертификации ПСЗИ и ПО в защищенном исполнении, и необходимых проверок приведен в [3,7-9].

Результаты анализа НД [1-9] и литературных источников показывают, что в процессе сертификации ПАСЗИ АСК должны решаться три основные задачи:

исследования и контроль отсутствия недекларированных возможностей;

проверка на соответствие реальных и декларируемых функций;

проверка защитных функций ПСЗИ и ПО АС и оценка класса защищенности АС (СВТ) в соответствии с РД ГТК.

Контроль отсутствия недекларированных возможностей осуществляется по четырем уровням, характеризующимся определенной минимальной совокупностью требований к составу и содержанию испытаний для ПО АСК должен быть обеспечен уровень контроля не ниже третьего [7]. При этом под недекларированными возможностями понимаются функциональные возможности ПО, не описанные или не соответствующие описанным в документации, при использовании которых возможно нарушение конфиденциальности, доступности или целостности обрабатываемой информации. Особое внимание уделяется выявлению программных закладок.

Такой контроль включает в себя следующие этапы:

контроль состава и содержания документации: спецификации, описания программы, исходных текстов программ, пояснительной записки (для импортного ПО состав документации должен соответствовать по содержанию);

контроль исходного состояния ПО;

статический анализ исходных текстов программ;

динамический анализ исходных текстов программ.

По результатам испытаний оформляется протокол.

Результаты испытаний на соответствие реальных и декларируемых функций представленного на испытания образца ПО должны дать возможность сделать обоснованные выводы:

• о степени соответствия образца ПО требованиям по разработке программных средств (используемые показатели: правильность организации разработки, полнота отработки);

• о соответствии реальных и декларируемых функций испытываемого образца по основному назначению программного образца (используемые показатели Полнота выполнения ТУ, Полнота реализации функций, Корректность реализации функций);

• оценка качества программных средств по показателям, определенным в ГОСТ 28195-89 (используемые показатели: Устойчивость функционирования, Легкость освоения, Удобство эксплуатации и обслуживания, Сравнение с известными аналогами).

Такие испытания включают в себя следующие этапы.

Проверка паспортных (исходных) данных образца ПО и состава технической документации.

Проверка производится сопоставлением фактической комплектности поставленной на испытания образца ПО технической документации на него. Проводится анализ на соответствие требованиям ГОСТ 27201-87, стандартам ЕСПД, ГОСТ 34.201, Руководящих документов 50-34.698 и включает оценку документов: эксплуатационных (Общее описание системы, Паспорт, Ведомость эксплуатационных документов, Ведомость машинных носителей информации, Руководство пользователя) и конструкторских (Технические условия (ТЗ на разработку, постановки задач на разработку и т.п.), Программа и методика испытаний (компонентов, комплексов средств автоматизации (КСА), подсистем, систем).

Оценка документации проводится путем анализа и сравнения с реальными свойствами представленного образца ПО по шкале:

• "Удовлетворительно",

• "Неудовлетворительно",

• "Отсутствует".

Проверка считается успешной, если комплектность поставленной для испытаний образца ПО соответствует заявленной в технической документации, требованиям ЕСПД и формуляра. Результаты проверки оформляются протоколом проверки.

Проверка соответствия свойств и функций отраженных в документации на образец ПО ее свойствам и функциям определяемых (анализом исходных текстов программ образца ПО, тестированием функций на испытательном стенде).

Проверка соответствия свойств и функций ПО по основному назначению производится по следующим пунктам:

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

Оценка качества образца ПО по устойчивости функционирования, легкости освоения, удобства эксплуатации и обслуживания.

Стандартность построения интерфейса (интуитивно понятный интерфейс);

Логичность и полнота руководства пользователя;

Сложность настройки параметров операционной системы для работы образца ПО;

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

Проверка по данному пункту оформляется в виде мнения экспертов и рекомендаций экспертов по доработке образца ПО.

Специальные испытания свойств и функций.

Специальные испытания функций образца ПО производятся в объеме, руководящих документов МО РФ (Гостехкомиссии при президенте РФ) по обеспечению защиты информации от несанкционированного доступа в образце ПО. Специальные испытания проводятся по показателям позволяющим определить класс защищенности образца ПО.

Проверка защитных функций ПСЗИ и ПО АС и оценка класса защищенности АС (СВТ) в соответствии с РД ГТК.

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

Результаты испытаний должны дать возможность сделать обоснованные выводы:

• о степени соответствия КСЗ от НСД типовой системы требованиям эксплуатационной документации;

• о степени соответствия КСЗ от НСД типовой системы требованиям РД по безопасности информации

Такие испытания включают в себя следующие этапы.

Проверка паспортных (исходных) данных образца ПО и состава технической документации.

По аналогии с предыдущей задачей.

Проверка соответствия документированных свойств КСЗ типовой системы второму классу защищенности.

Проверка производится изучением реализованных защитных функций по документации на КСЗ системы:

• модели защиты;

• описания принципов работы;

• описания ПРД;

• описания КСЗ;

• тестов;

• отчетов о проведенных исследованиях и других документов.

Сравнением их с требованиями РД [8,9].

Специальные испытания защитных функций и механизмов ЗИ в типовой системы от НСД.

Специальные испытания защитных функций и механизмов ЗИ типовой системы от НСД производятся в объеме, соответствующем рассматриваемому классу защищенности [8,9]. Для проведения сертификационных испытаний строятся условные или реальные модели систем на базе типовой системы, описанные в соответствующих пунктах настоящего документа.

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

В процессе испытаний, при необходимости, проводится декомпозиция показателей защищенности на элементы.

Каждый элемент показателя защищенности оценивается по двухуровневой шкале:

• "соответствует";

• "не соответствует".

Каждый показатель защищенности на основе оценки элементов оценивается по трехуровневой шкале:

• "соответствует" - при наличии соответствия у всех элементов;

• "соответствует не полностью" - при отсутствии соответствия хотя бы у одного элемента;

• "не соответствует" - при наличии не соответствия у всех элементов.

Оценка дополнительных возможностей по защите КСЗ типовой системы от НСД.

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

По результатам всех этапов производится сопоставление фактических характеристик КСЗ системы требованиям определенного класса защищенности. В случае если на всех этапах оценки эффективности КСЗ проверка осуществилась успешно, делается вывод о соответствии системы с КСЗ от НСД требованиям данного класса защищенности.

По результатам оценки составляется техническое заключение, в котором излагаются:

• описание комплекса средств защиты;

• оценка класса защищенности в соответствии с заданными показателями;

• наличие и соответствие дополнительных требований;

• аргументация данной оценки: объяснение соответствия КСЗ требованиям данных показателей, посредством каких средств обеспечивается выполнение каждого требования;

• описание испытаний, которым подвергалось ПО (с указанием состава технических и программных средств);

• вывод о соответствии ПО АС и ПСЗИ соответствующему классу защищенности;

• другие положения и выводы, необходимые по мнению экспертов оценочной комиссии.

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

Литература

1. ГОСТ 28.806-90. Качество программных средств. Термины и определения.

2. ГОСТ 50.922-96. Стандартизованные термины и определения в области защиты информации.

3. ГОСТ Р 50992-96. Защита информации. Основные термины и определения.

4. ГОСТ Р 51275-99. Защита информации. Объект информатизации. Факторы, воздействующие на информацию. Общие положения.

5. Гостехкомиссия РФ. Руководящий документ. Автоматизированные системы. Защита от несанкционированного доступа к информации. Классификация автоматизированных систем и требования по защите информации. М.: Воениздат, 1992.

6. Гостехкомиссия РФ. Руководящий документ. Временное положение по организации разработки, изготовления и эксплуатации программных и технических средств защиты информации от несанкционированного доступа в автоматизированных системах и средствах вычислительной техники. М.: Воениздат, 1992.

7. Гостехкомиссия РФ. Руководящий документ. Защита от несанкционированного доступа к информации. Термины и определения. М.: Воениздат, 1992.

8. Гостехкомиссия РФ. Руководящий документ. Концепция защиты средств вычислительной техники от несанкционированного доступа к информации. М.: Воениздат, 1992.

9. Гостехкомиссия РФ. Руководящий документ. Средства вычислительной техники. Защита от несанкционированного доступа к информации. Показатели защищенности от несанкционированного доступа к информации. М.: Воениздат, 1992.

ВВТУ ФСО РОССИИ

УДК 621.3

К.Н. Бирюков

МОДЕЛЬ ДИНАМИКИ ФУНКЦИОНИРОВАНИЯ

ПРОГРАММНЫХ СИСТЕМ ЗАЩИТЫ ИНФОРМАЦИИ

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

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

Одним из основных этапов при моделировании систем является формализация моделируемых процессов. Адекватность формализации динамики функционирования ПСЗИ АС существенным образом определяет качество модели. Результаты анализа существующих способов формализации и особенностей функционирования ПСЗИ показывают, что наиболее приемлемым формальным аппаратом для представления динамики функционирования ПСЗИ являются оценочные сети [1].

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

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

Для формализации функционирования ПСЗИ при её автоматизированном проектировании производится иерархическая структуризация этой системы. Функционирование ПСЗИ есть последовательность реализаций определенных сервисных задач защиты информации (ЗИ). Сервисные задачи разбиваются на функции, реализующие конкретный алгоритм ЗИ в конкретной сервисной задаче. Это позволяет представить процесс ЗИ в виде последовательной смены состояний функционирования ПСЗИ.

Возможным состояниям функционирования ПСЗИ соответствуют совокупности позиций сети. Каждый возможный переход между состояниями формализуется соответствующей элементарной сетью. Разрешающие процедуры реализуют случайные переходы между состояниями функционирования ПСЗИ. Положение объекта в сети, а также, возможно, его атрибуты характеризуют текущее состояние процесса функционирования ПСЗИ. Момент времени появления данного объекта в сети соответствует моменту времени обращения к ПСЗИ. Момент времени выхода данного объекта из сети соответствует моменту времени окончания реализации функций ПСЗИ по данному обращению. Перемещение объекта из одной позиции в другую, которое в общем случае сопровождается модификацией его атрибутов с помощью процедуры преобразования π, соответствует изменению состояния функционирования ПСЗИ. Длительность изменения состояния определяется процедурой временной задержки τ.

Для адекватности моделирования динамических процессов ЗИ в АС предлагается использовать следующий набор типов элементарных сетей: Т (простой переход), J (объединение) и X (переключатель) Основное отличие сети типа X от сетей типа Т и J заключается в наличии разрешающей позиции.

На основе данного базового набора типов элементарных сетей, можно построить оценочную сетевую формализацию динамики функционирования любой ПСЗИ так, что в любой элементарной сети такой формализации все входные простые позиции соответствуют одному и тому же состоянию функционирования ПСЗИ. Каждая элементарная сеть взаимно однозначно соответствует состоянию функционирования ПСЗИ (оно определяет входные простые позиции данной элементарной сети), поэтому число элементарных сетей оценочной сетевой формализации равно числу состояний. Математическую модель динамики функционирования ПСЗИ, в соответствии с её оценочной сетевой формализацией, в общем случае можно описать матрицей , произвольный элемент которой есть вероятность того, что ПСЗИ, оказавшаяся в состоянии i, перейдет из него в состояние j, причем за время, меньшее τ [2].

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

Литература

1. Костин А.Е. Принципы моделирования сложных дискретных систем. М.: МИЭТ, 1984.

2. Методы и средства автоматизированной оценки и анализа качества функционирования программных систем защиты информации / А.С. Дубровин, И.И. Застрожнов, Е.А. Рогозин и др. Воронеж: ВГТУ, 2004. 181 с.

Воронежский государственный технический университет

УДК 681.3.06

А.Ю. Зеленин, А.В. Муратов

УПРАВЛЕНИЕ РАЗВИТИЕМ РЕГИОНАЛЬНОЙ СИСТЕМЫ

ТЕЛЕРАДИОВЕЩАНИЯ НА ОСНОВЕ ИМИТАЦИОННОГО

МОДЕЛИРОВАНИЯ ИНВЕСТИЦИОННЫХ ПРОЦЕССОВ

Рассматривается реализация имитационной модели процессов инвестирования региональной системы телерадиовещания, входящей в систему управления развития этой системы

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

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

Тогда математическая интерпретация закона развития имеет следующий вид:

,

где - потенциал системы на j-ом (1, 2, …, n) этапе жизненного цикла; – потенциал системы в i-ой области (экономика, техника, финансы) на j-ом этапе.

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

Закон развития относится к объективным законам организации, поэтому его реализация зависит от установок руководства организации и ее персонала.

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

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

Основой для графического построения схемы математической модели управления инвестициями принимаем ориентированный мультиграф с некоторыми дополнениями и уточнениями.

Введем понятия:

• «субъект» - объект, осуществляющий преобразование ресурса;

• «ресурс» - объект, преобразовываемый в ходе выполнения инвестиционного процесса;

• «преобразование ресурса» - процесс замены одного ресурса другим;

• «переход ресурса» - процесс передачи ресурса от одного субъекта другому;

• «операция с ресурсами» - элементарное преобразование двух ресурсов друг в друга, производимое двумя субъектами;

• «маршрут» (прямой, обратный) - совокупность упорядоченных операций, обеспечивающих решение целевой функции процесса: прямой - от первой операции к последней; обратный - от последней операции к первой;

• «процесс преобразования ресурсов» - совокупность маршрутов.

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

,

где: S - множество субъектов-участников процесса;

D - множество переходов;

I- функция инцидентности, показывает, соединяет ли переход субъект 1 - 1-й участник процесса преобразования ресурса с субъектом 2 ;

R - множество параметров, характеризующих множество переходов D.

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

Решение задачи моделирования процессов требует решения следующего набора задач:

• проектирование графического изображения сложных схем организационно-экономических процессов как совокупности элементарных схем;

• информационное наполнение данными схем процессов;

• отображение результатов обработки схем в реальном масштабе времени.

• моделировать распределение основных финансовых потоков регионального телерадиоцентра в зависимости от принятой системы налогообложения и влияния других необходимых платежей;

• анализировать результаты прогнозирования при реализации выбранной стратегии распределения финансовых средств регионального телерадиоцентра.

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

При выборе средств моделирования к ним предъявляются следующие требования:

• наличие средств ввода параметров модели операции;

• наличие средств ввода числовых значений факторов, влияющих на функционирование модели;

• хранение введенных значений.

Исходные данные и функциональные зависимости

имитационной модели

Из набора пеков прикладных программ особый интерес для специалистов по имитационному моделированию представляет инструмент MATLAB/Simulink [2], разработанный специально для моделирования динамических систем. Он имеет библиотеку стандартных графических блоков со встроенными математическими функциями [3]. Используется для исследования, анализа, планирования и прогнозирования экономической динамики.

Процесс моделирования содержит следующие стадии: планирование машинных экспериментов; собственно моделирование; анализ результатов моделирования и принятие решений.

Моделируемые показатели, как показано на рисунке, выводятся в виде функциональных зависимостей от времени. Перечислим некоторые из них:

• производственные показатели (объем производства, объем продаж, цена реализации и т.п.);

• финансовые показатели (материальные затраты, выплачиваемые налоги, выручка, фонд оплаты труда, прибыль);

• характеристики производственных фондов;

• индексы качества продукции и сырья и др.

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

Литература

1. Бусленко Н.П. Моделирование сложных систем. М.: Наука, 1978. 400 с.

2. Дэбни Дж.Б., Харман Т.Л. Simulink 4. Секреты мастерства / Пер. с англ. М.Л. Симонова. М.: БИНОМ. Лаборатория знаний, 2003. 403 с.

3. Дьяконов В.П. MATLAB 6.5 SP1/7+Simulink 5/6. Основы применения. М.: СОЛОН-Пресс, 2005. 800 с.

Воронежский областной радиотелевизионный передающий центр

Воронежский государственный технический университет

УДК 621.3