Содержание к диссертации
Введение
1 Анализ теоретических основ вероятностного оценивания риска 9
1.1 Теоретические подходы к определению вероятностных характеристик риска 9
1.1.1 Информационно-статистический подход 9
1.1.2 Экспертное оценивание 14
1.1.3 Марковский анализ 15
1.1.4 Событийно-логический подход 19
1.2 Основные положения нормативного подхода к вероятностной оценке риска 24
1.2.1 Краткий обзор нормативной базы 24
1.2.2 Рекомендуемые методы оценки риска 27
1.2.3 Анализ видов, последствий и критичности отказов (FMECA) 29
1.2.4 Анализ дерева неисправностей (FTA) 30
1.2.5 Анализ дерева событий (ЕТА) 32
1.3 Постановка задачи вероятностной оценки риска ИБ 34
2 Разработка метода вероятностной оценки риска ИБ 44
2.1 Общие положения метода оценки риска ИБ на основе сценарного логико-вероятностного моделирования 44
2.2 Определение факторов риска ИБ 47
2.3 Построение Л-функции риска ИБ 56
2.4 Определение В-полинома риска ИБ 59
3 Методика ЛВ-моделирования сценариев ситуаций риска ИБ 68
3.1 Анализ ДС ИБ 68
3.2 Анализ ДН ИБ инфокоммуникационной системы 81
3.3 Построение В-полинома и расчёт вероятностных характеристик риска 86
4 Разработка предложений по программной реализации вероятностной оценки риска ИБ 88
4.1 Принципы построения и характеристики ЭС 88
4.2 Разработка алгоритма работы интерпретатора ЭС оценки риска ИБ 100
Заключение 106
Литература 108
Приложение 116
- Анализ видов, последствий и критичности отказов (FMECA)
- Постановка задачи вероятностной оценки риска ИБ
- Определение факторов риска ИБ
- Построение В-полинома и расчёт вероятностных характеристик риска
Введение к работе
Важнейшей проблемой, определяющей подходы к построению, совершенствованию и перспективному развитию информационных систем, становится их безопасность. Анализ современных тенденций обеспечения безопасности в сфере инфокоммуникационных систем государственного и специального назначения показывает, что в основе повышения их защищенности лежит выявление потенциальных факторов угроз и уязвимостей информации, количество которых постоянно растет.
Современная нормативная база в области обеспечения информационной безопасности (ИБ) прямо указывает на необходимость постоянного использования оценок проявления потенциальных факторов угроз и уязвимостей информации в инфокоммуникационных системах для организации целенаправленных действий по их минимизации и устранению. Международное сообщество специалистов определяет такие действия как процесс менеджмента (управления) ИБ, а процедуры анализа и оценивания названных факторов — как менеджмент риска ИБ.
В соответствии с требованиями нормативной базы реализация процесса управления ИБ может осуществляться только в рамках документированной системы управления информационной безопасностью (СУИБ), построенной на основе менеджмента риска ИБ. Таким образом, базовым компонентом СУИБ согласно установившемуся подходу становится система менеджмента риска ИБ.
Практика обеспечения безопасности инфокоммуникационных систем также постепенно осознает необходимость применения процедур анализа и оценки риска ИБ. Так, деятельность по достижению требуемого уровня ИБ помимо основного и вспомогательного процессов (реакции на инциденты и обеспечение ресурсами безопасности) все чаще включает процесс управления ИБ, который охватывает не только правила управления (политики, инструкции и регламенты безопасности), разра- ботанные на основе выявленных угроз и уязвимостей, но и контроль их результативности, осуществляемый путем проведения аудита ИБ на базе анализа риска, с последующей корректировкой управляющих механизмов. Сегодня очевидно, что настраивать СУИБ инфокоммуникационной системы только по фактам проявления угроз и уязвимостей сложно и ресурсоемко, а следовательно, малоэффективно. Однако, практика вносит существенные уточнения в нормативный подход, показывая, что реальные результаты в повышении защищенности могут быть получены лишь на основе количественных оценок риска ИБ.
Вопросам анализа риска и безопасности в структурно сложных системах посвятили труды такие российские и зарубежные ученые, как Рябинин И.А., Черешкин Д.С, Соложенцев Е.Д., Rasmussen N.C., Van Malder G., Dugan J.B., Andrews J.D. и др. Разработано большое количество отечественных и зарубежных нормативных документов, регламентирующих вопросы анализа защищенности инфокоммуникационных систем и менеджмента риска ИБ.
Вместе с тем, теоретический подход к количественной оценке риска ИБ находится в стадии становления, а соответствующие методы приемлемой точности отсутствуют.
В связи с этим, целью диссертационной работы является разработка метода, обеспечивающего решение задач вероятностной оценки риска ИБ путем моделирования сценариев реализации угроз в инфокоммуникационной системе на основе событийно-логического подхода, построение алгоритмов автоматизации процедур оценки вероятностных характеристик риска, а также разработка рекомендаций по совершенствованию аудита инфокоммуникационных систем.
В соответствии с целью в работе поставлены и решены следующие задачи:
Анализ видов, последствий и критичности отказов (FMECA)
Процесс обеспечения ИБ в России регламентируется требованиями законодательства РФ, руководящих документов (РД) ФСТЭК [1,2,3,4,5,6,7,8] и ФСБ России, а также ряда национальных [9, 10,11,12,13,14,15,16,17,18,19], отраслевых [20, 21, 22] и международных [23, 24,25,26,27,27,28,29, 30, 31,32,33,34,35,36,37,38] стандартов.
До недавнего времени в российских нормативных документах, касающихся ИБ, понятия оценки рисков не существовало, хотя оно и могло использоваться в ходе обсуждения уровня защищенности объектов информатизации при аттестации.
Устранением этого недостатка стало появление стандартов серии ГОСТ Р ИСО/МЭК 13335 (КОЛЕС 13335) [16,17,18,19]. Исторически им предшествовали ГОСТ Р ИСО/МЭК 15408 [11,12,13], с сопровождающими ГОСТ Р ИСО/МЭК ТО 18044 [14] и ГОСТ Р ИСО/МЭК 18045 [15], а также ГОСТ Р ИСО/МЭК 27001 [10] и ГОСТ Р ИСО/МЭК 17799 [9].
Стандарты серии ГОСТ Р ИСО/МЭК 13335 [16,17,18,19] определяют принципы обеспечения ИБ, включающие менеджмент информационного риска. Вводятся понятия актива, угрозы, уязвимости, риска и защитной меры. Определяется общая модель безопасности системы, которая включает окружающую среду, активы, уязвимости присущие активам, меры защиты активов, приемлемые остаточные риски. Также определяются четыре основных подхода к анализу риска, реализуемых на этапах оценивания защищенности: - базовый (формальный) подход; - неформальный подход (анализ риска «высокого уровня»); - детальный анализ риска; - комбинированный анализ риска. Дано подробное описание каждого подхода. Приводятся перечни типовых угроз и уязвимостей, методики оценки активов, типология методов анализа рисков, таблицы ранжирования угроз и т.п. Следует отметить появление отраслевых стандартов Банка России СТО БР ИББС [20,21,22], дополнений к ним, а также методических указаний, регламентирующих вопросы управления информационными рисками в организациях банковской системы РФ. Все указанные стандарты являются переводами или переложениями международных стандартов. Вместе с тем международная нормативная база продолжает динамично развиваться: появляются новые документы, заменяющие ранние версии. Так, международной организацией по стандартизации недавно введены общие документы по менеджменту риска (ISO 31000 [23]) и технологиям его оценки (ISO/IEC 31010 [25]). С учетом содержания этих документов расширилась серия ISO/IEC 27000 [27,28], заменив серию КОЛЕС 13335. Стандарт ISO/IEC 17799 заменен стандартом КОЛЕС 27002 [26]. Среди новинок интересны стандарты ISO/IEC 27005 [27] и BS 7799-3 [29]. Стандарт КОЛЕС 27005 представляет собой руководство по управлению рисками ИБ. Стандарт основывается на общих концепциях, изложенных в ISO/IEC 27001, и предназначен для «содействия адекватному обеспечению ИБ на основе риск-ориентированного подхода». Стандарт BS 7799-3 гармонизирован с КОЛЕС 27002 относительно компонентов систем защиты и серией ISO 9000 (менеджмент качества) относительно требований к документированию. Стандарт, придерживаясь самого общего понятия риска (как комбинации вероятности со бытия и его последствий), допускает использование различных подходов к анализу рисков, в частности, изложенных в ISCMEC 27005. Дополняют международную нормативную базу хорошо известные документы Федерального агентства по информационной безопасности (BSI) Германии [30,31,32,33], национальные стандарты США NIST [34,35,36], Австралии и Новой Зеландии AS/NZS 4360 [37], а также, разработанный на их основе НВ 231:2000 [38]. Стандарты серии BSI содержат общие рекомендации по применению методов, процессов и процедур управления ИБ. BSI 100-3 [32] включает описание метода анализа рисков на основе предложенной универсальной технологии менеджмента IT-Grundschutz. В рамках IT-Grundschutz предполагается только качественная оценка рисков, где исходными данными выступают накопленные сведения о возможных угрозах и контрмерах, структурированные по разделам и организованные в виде общедоступного каталога - IT-Grundschutz Catalogue. Стандарт NIST SP 800-30 [34] подробно рассматривает вопросы построения системы управления информационными рисками, которая в соответствии с положениями стандарта, должна быть интегрирована в систему управления жизненным циклом ИТ-технологий. Стадии управления риском, в соответствии с документом, включают: описание системы; идентификацию угроз и уязвимостей; анализ управления ИС; оценку параметров угроз; анализ возможных последствий нарушений ИБ; определение рисков; разработку рекомендаций по управлению рисками; разработку отчетных документов. Стандарт дает рекомендации по выполнению работ на каждой стадии, приводит примеры опросных листов, отчетных документов, планов и т.п. Для анализа риска и оценки его вероятностных характеристик стандарты серии ISO 31000 [23,25] выделяют три категории методов: - сопоставительные: ведомости проверок, индексы опасностей и обзоры данных эксплуатации; - фундаментальные, основанные на использовании прогнозов и знаний экспертов для анализа вопросов типа «а, что если...?», примерами которых являются методы исследования опасности и работоспособности (HAZOP), анализа видов и последствий отказов (FMEA) и др.; - индуктивно-дедуктивные: логические диаграммы возможных последствий событий (деревья событий и т.п.) и др. В табл. 1 представлен перечень методов, рекомендуемых серией ISO 31000 для вероятностной оценки риска. Из анализа табл. 1.1 видно, что серия ISO 31000 не ограничивает спектр подходов к оценке вероятностных характеристик риска.
Здесь представлены методы качественной (HAZOP, Root Cause Analysis и др.) и количественной оценки (FTA, ЕТА и др.) в рамках событийно-логического подхода, методы Марковского анализа и методы, основанные на использовании информационно-статистического подхода (Monte-Carlo simulation и Bayes Nets). Активно рекомендуется использование экспертного оценивания (SWIFT, LOLA и др.).
Аналогичную позицию занимают отечественные документы ГОСТ Р 51901-2002 «Управление надежностью. Анализ риска технологических систем» и ГОСТ Р 51901.5-2005 «Менеджмент риска. Руководство по применению методов анализа надежности».
Постановка задачи вероятностной оценки риска ИБ
Вместе с тем, риск ИБ нельзя считать составной частью информационного риска вообще. Существуют категории информационного риска, которые нельзя связать с ИБ (они относятся к области инвестиционного менеджмента). Это, например, риски связанные с внедрением ИТ, т.е. с не обеспечением определенных стратегий развития организации преимуществами внедрения ИТ, или риски, связанные с реализацией новых ИТ-проектов, т.е. с возможностью возникновения неблагоприятных ситуаций и, как следствие, наступления ущерба от изменения основных управляемых параметров ИТ-проектов.
В соответствии с этим, под риском ИБ будем понимать категорию информационного риска, связанную с ИТ-операциями и ИТ-услугами (всеми возможными аспектами функционирования ИТ), которая является составной частью всех компонентов рисковой модели организации.
Под оценкой риска ИБ в соответствии с положениями стандарта ISCVIEC 27005 будем понимать часть процесса менеджмента риска ИБ, основанную на изучении событий (инцидентов) ИБ, вероятности их возникновения и определения степени влияния последствий их реализации. В общем случае менеджмент риска ИБ будем считать итеративным процессом, включающим определение контекста риска, его оценку и обработку, принятие, мониторинг и коммуникацию (рис. 1.6). Отметим, что итеративный подход позволяет получать более глубокие, детальные оценки на каждой итерации и минимизировать временные затраты при наличии гарантий того, что все наиболее высокие риски оценены соответствующим образом. Будем считать, что определение контекста в системе менеджмента риска ИБ подразумевает выбор базовых критериев риска и определение границ и области функционирования системы. Под критериями риска будем понимать набор правил, по которым может быть определена значимость риска. К основным критериям риска отнесем: критерий оценки риска, критерий воздействия и критерий принятия риска. Далее будем следовать известной схеме (рис. 1.6): после определения контекста осуществляется оценка риска. По результатам оценки необходимо принять решение о достаточности информации, полученной в ходе оценки для определения действий по снижению уровня риска (до допустимого). Если объем и содержание информации достаточны, то следует начинать обработку риска, в противном случае оценку необходимо производить заново (рис. 1.6, Точка принятия решения 1). Принято разделять понятия «оценка риска» (risk assessment) и «оценивание риска» (risk evaluation). ГОСТ Р 51897-2002 определяет оценку риска как процесс анализа риска и оценивания. Оценивание риска определяется как процесс сравнения количественно оцененного риска с выбранными критериями риска для определения его значимости. Эффективность обработки риска зависит от качества оценивания риска. Возможно возникновение ситуации, когда после обработки риска не удается снизить уровень риска до допустимого, в таком случае оценка риска производится заново (рис. 1.6, Точка принятия решения 2). Принятие риска подтверждает то, что остаточный риск принят. Это особенно важно в ситуациях, когда внедрение соответствующих мер или средств защиты откладывается на долгий срок, или не производится вообще, например, из-за высокой стоимости реализации технических решений. Важно обеспечить коммуникацию риска, которая заключается в периодическом обмене информацией о риске (источник, вероятность, приемлемость риска и т.п.) между сотрудниками организации, в пределах их компетенции. Разработка методологии анализа риска, включающей его идентификацию и количественною оценку, является одной из самых трудно-решаемых задач при создании систем риск-менеджмента. На этапе идентификации риска необходимо выполнить идентификацию активов, угроз, существующих мер защиты и уязвимостей системы, а также выявить последствия наступления событий риска. Идентификация активов заключается в составлении их перечней, причём в перечни включают не только аппаратные средства и программное обеспечение, но и другие типы активов. К ним относятся: информация/данные, оборудование для обеспечения связи, документы (например, контракты), фонды (например, в банковских автоматах), продукцию, услуги (например, информационные и вычислительные), конфиденциальность и доверие при оказании услуг (например, услуг по совершению платежей), персонал, а также престиж (имидж) организации. Также при идентификации активов определяют лиц ответственных за каждый идентифицированный актив и степень их ответственности.
Периметр идентифицированных активов организации определяет границы анализа риска и, соответственно, границы и области функционирования системы менеджмента риска.
На этапе идентификации угроз составляется перечень как случайных, так и преднамеренных угроз, с указанием источников их проявления. Исходные данные для идентификации угроз получают от владельцев или пользователей активов, служащих отделов кадров, специалистов по разработке оборудования и ИТ, а также лиц, отвечающих за реализацию защитных мер в организации. Если в организации накоплено достаточно статистической информации об инцидентах ИБ, перечень угроз составляют на основе данных статистики. Широко используются обобщенные каталоги наиболее вероятных угроз, доступные в сети Интернет. Использование таких каталогов для идентификации угроз в конкретной системе требует реализации процедуры дополнительной актуализации угроз на заданные условия функционирования системы. Также, все чаще разрабатываются и эффективно используются отраслевые типовые модели угроз, на основе которых организации в соответствующей отрасли строят частные модели угроз.
Идентификация защитных мер заключается в составлении перечня действующих и планируемых организационных и технических мер защиты, с указанием статуса их реализации и использования.
Определение факторов риска ИБ
Рассмотрим методику вероятностной оценки риска ИБ сегмента инфокоммуникационной системы. Известно, что существует три класса атак связанных с нарушением конфиденциальности, целостности и доступности информации в инфокоммуникационной системе: - атак на основе несанкционированного сбора информации о сегментах системы; - атак, направленных на генерирование и последующее внедрение новых объектов сетевого взаимодействия в сегменты системы; - атак, направленных на вывод из строя сетевых устройств (DoS-атак). К первому классу атак относятся атаки сканирования портов и атаки на основе анализа сетевого трафика. Цель атаки сканирования портов заключается в получении сведений о запущенных на атакуемой машине сервисах. Как правило, избыточность запущенных на компьютере сервисов и является причиной успешной реализации атаки. В результате сканирования открытых портов злоумышленник может определить название службы, которая использует данный порт, и тип операционной системы, под которой эта служба функционирует. Зная соответствующие уязвимости в определенных службах, злоумышленник может проникнуть на удалённый хост и получить права на доступ в систему.
Атака на основе сетевого трафика позволяет перехватить поток сетевых пакетов, которыми обмениваются абоненты инфокоммуникационной системы, что адекватно несанкционированному доступу к информации. Целью данной атаки не ставится модификация трафика, а исключительно его анализ. Анализ может осуществляться только внутри одно го доступного злоумышленнику сегмента сети и только в отсутствии коммутатора. Это обуславливается наличием селективной маршрутизации в IP-сетях, когда пакеты внутри подсети рассылаются всем её хостам, а уже каждый хост сам для себя определяет по адресу назначения, ему ли предназначен пакет или нет. В случае, если адрес совпадает, пакет обрабатывается, в противном случае пакет отбрасывается. Именно на этой уязвимости строится работа «снифера» (анализатора сетевого трафика), перехватывающего чужие пакеты в подсети и анализирующего их содержимое. Результатом перехвата могут быть пароли, ключи, персональные данные пользователей, пересылаемые в незашифрованном виде.
Второй класс атак, основанный на внедрении ложного доверенного объекта, реализуется различными способами, которые, как правило, обуславливаются тем или иным протоколом сетевого взаимодействия. В общем и самом распространённом случае рассматривается протокол IPv4. Применительно к этому протоколу возможны следующие виды атак внедрения ложного объекта сетевого взаимодействия: - подмена абонента сетевого соединения путём организации ложного TCP-соединения (ТСР-рукопожатия); - инкапсуляция данных в ICMP-пакеты, а как результат - создание запрещенного туннеля; - изменение ARP-таблиц соответствия IP и MAC адресов, результатом чего будет неверная адресация в подсети; - подмена DNS-запросов и/или изменение DNS-таблиц на DNS-серверах, а как результат - создание ложных сайтов; - внедрение вредоносного SQL-кода, в SQL-запросы, с некорректной обработкой входящих данных СУБД, как результат - перехват управления сервером БД. Третий класс атак, основывается на том, что большинство операционных систем способны поддерживать ограниченное число открытых виртуальных соединений, а также отвечать на ограниченное число запросов (ограничены длина очереди запросов на подключение, тайм-аут очистки очереди одновременно открытых соединений). Кроме того, ширина канала тоже ограничена. Эти ограничения устанавливаются индивидуально для каждой сетевой ОС. При отсутствии статической ключевой информации в инфокоммуникационной системе идентификация запроса возможна только по адресу его отправителя. Если в системе не предусмотрены средства аутентификации адреса отправителя, инфраструктура системы позволяет с какого-либо объекта системы передавать на атакуемый объект любое число анонимных запросов на подключение от имени других объектов (тем самым переполняя очередь запросов). Результатом является реализация атаки типа «отказ в обслуживании». К этому же классу относятся атаки переполнения буфера (ПБ) ПО. ПБ ПО - явление, возникающее когда компьютерная программа записывает данные за пределами выделенного в памяти буфера, в следствие чего аварийно завершает работу. Атака ПБ реализуется в случае отсутствия жесткой зашиты со стороны подсистемы программирования (компилятора или интерпретатора) и ОС. К атакам на основе отказа в обслуживании относятся следующие виды атак: - «смертельный ping» - отправка сообщений ICMP с большим, чем разрешено размером (разрешается иметь до 216, или 65 536 байт в секции данных пакета), как результат — аварийное завершение работы ОС; - «SYN-Flood» - «забрасывание» атакуемого узла множеством SYN-пакетов, в которых указаны ложные адреса, что вызы вает переполнение очереди соединений в стеке TCP/IP, результатом чего является отказ в поддержке соединений; - внедрение эксплойта ПБ, как результат - аварийное завершение работы системного и/или прикладного ПО. Выполним первый этап анализа ДС ИБ исследуемого сегмента инфокоммуникационной системы с учётом приведённых выше классов атак (рис. 3.1).
Построение В-полинома и расчёт вероятностных характеристик риска
Конкретные СОЗ могут принадлежать одновременно нескольким классам. Так, перспективным может оказаться пересечение классов 1, 2 и 5. Внутри него находятся СОЗ, использующие объектно-логические языки, фреймовые логики, логики транзакций и т.д. Последовательное сочетание объектно-ориентированного подхода с логическим программированием позволяет повысить эффективность последнего с сохранением свойств универсальности (полноты) и корректности обработки знаний.
Наиболее известными СОЗ являются экспертные системы (ЭС) — системы, использующие знания и процедуры вывода для решения задач, являющихся трудными для людей-экспертов. ЭС наиболее широко применяемого типа являются ЭС, основанные на правилах. В ЭС знания представлены не с помощью относительно декларативного, статического способа (как ряд истинных утверждений), а в форме многочисленных правил, которые указывают, какие заключения должны быть сделаны или не сделаны в различных ситуациях.
Структурными элементами ЭС являются (рис. 4.2): - база знаний (БЗ), предназначенная для хранения долгосрочных данных, описывающих рассматриваемую область и правил, описывающих целесообразные преобразования данных этой области. - рабочая память - глобальная база фактов, используемых в правилах. - машина логического вывода - программный компонент, который обеспечивает формирование логического вывода (принимая решение о том, каким правилам удовлетворяют факты или объекты), располагает выполняемые правила по приоритетам и выполняет правило с наивысшим приоритетом. рабочий список правил, созданный машиной логического вывода и расположенный по приоритетам список правил, шаблоны которых удовлетворяют фактам или объектам, находящимся в рабочей памяти. средство приобретения знаний - инструментальное средство, обучающее ЭС, путём выработки правил по методу индукции на основании примеров, или с использованием искусственных нейронных сетей и генетических алгоритмов. Также средство приобретения знаний автоматизирует процесс ввода знаний экспертами и инженерами по знаниям. средство объяснения - компонент, позволяющий объяснить пользователю ход рассуждений системы. Наличие средства объяснения, которое дает возможность пользователю задавать вопросы о том, как система пришла к определенному заключе нию и для чего ей требуется определенная информация, является отличительной особенностью ЭС основанной на правилах. Развитые средства объяснения дают возможность эксперту изучать альтернативные пути формирования рассуждений по принципу гипотетических рассуждений. — машина логического вывода (интерпретатор), работающая в режиме осуществления циклов («распознавание-действие», «выборка-выполнение», «ситуация-отклик», «ситуация-действие» и т.п.), выполняя группы задач до выявления определенных критериев, вызывающих прекращение выполнения. При этом решаются общие задачи, обозначенные в приведенном ниже псевдокоде как разрешение конфликтов, действие, согласование и проверка условий останова.
В течение каждого цикла могут быть активизированы и помещены в рабочий список правил многочисленные правила. В рабочем списке правил остаются результаты активизации правил от предыдущих циклов, если не происходит деактивизация этих правил в связи с тем, что их левые части больше не выполняются. Таким образом в ходе выполнения программы количество активизированных правил в рабочем списке правил изменяется. В зависимости от программы ранее активизированные правила могут всегда оставаться в рабочем списке правил, но никогда не выбираться для запуска. Аналогичным образом некоторые правила могут никогда не становиться активизированными. В подобных случаях повторно проверяется назначение этих правил, поскольку либо такие правила не нужны, либо их шаблоны неправильно спроектированы.
Машина логического вывода выполняет действия активизированного правила с наивысшим приоритетом из рабочего списка правил, затем - действия активизированного правила со следующим по порядку приоритетом и т.д., до тех пор, пока в списке не останется больше активизированных правил. Для инструментальных средств экспертных систем разработаны различные системы приоритетов, вместе с тем, все инструментальные средства позволяют инженеру по знаниям определять приоритеты правил.
В рабочем списке правил возникают конфликты, если различные активизированные правила имеют одинаковый приоритет и машина логического вывода должна принять решение о том, какое из этих правил необходимо запустить. В различных командных интерпретаторах для решения этой проблемы применяются разные способы. Например, применяют подход, при котором правила, введенные в систему в первую очередь, приобретают по умолчанию наивысший приоритет.
После завершения выполнения всех правил управление возвращается к интерпретатору команд верхнего уровня, чтобы пользователь мог выдать командному интерпретатору ЭС дополнительные инструкции. Работа в режиме верхнего уровня соответствует применяемому по умолчанию режиму, в котором пользователь взаимодействует с ЭС, и обозначается как задача «Принять новую команду пользователя». Прием новых команд происходит именно на верхнем уровне.
Верхний уровень представляет собой пользовательский интерфейс к командному интерпретатору в тот период, когда происходит разработка приложения ЭС. Но обычно разрабатываются более сложные пользовательские интерфейсы, позволяющие упростить работу с системой. В действительности проектирование и реализация пользовательского интерфейса могут потребовать больше усилий, чем создание базы знаний ЭС, особенно на стадии разработки прототипа. В зависимости от возможностей командного интерпретатора экспертной системы пользовательский интерфейс может быть реализован с помощью правил или с применением операторов на другом языке, вызываемых из ЭС.
