Зегжда Д.П. Информационная безопасность

Подождите немного. Документ загружается.

Знание истории атак на вычислительные системы и понимание причин, по которым

они имели место и были успешно осуществлены является одним из необходимых

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

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

обобщения, классификации и выявления причин и закономерностей их, появления и

существования. Эффективность такого подхода обуславливается тем, что при разработке

и создании защищенных систем основные усилия концентрируются именно на

устранении этих причин и учете в механизмах защиты выявленных недостатков

Очевидно, что основой данного подхода является глубокое исследование частных

случаев нарушения безопасности и слабых сторон систем защиты, сделавших

возможным их осуществление. Для этого необходимо провести анализ и обобщение

существующих данных о нарушении безопасности ВС и создать их классификацию. Эта

задача являлась целью ряда зарубежных исследований [1, 4, 5, 6, 11, 12, 13, 16, 17].

Наибольший интерес представляет одно из новейших направлений исследований в

данной области, предложенное в работе "Таксономия нарушений безопасности

программного обеспечения с примерами" [1] Данная глава опирается на результаты этого

исследования и представляет собой его обобщение и развитие с точки зрения объяснения

причин нарушения безопасности и создания защищенных систем.

Любая атака на вычислительную систему (подразумеваются успешные атаки, в

результате которых происходит нарушение информационной безопасности) опирается на

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

— использует имеющиеся недостатки средств обеспечения безопасности. Для

обозначения таких недостатков в [1] применяется более емкий английский термин "flaw",

определенный в [8] следующим образом "Flaw — error of commission, omission or

oversight in an information technology product that may allow protection mechanism to be

bypassed", что в развернутом переводе означает "ошибка в предоставлении полномочий

(подразумевается как предоставление избыточных полномочий, так и их необоснованное

лишение), ошибка в средствах контроля за их использованием или другое упущение в

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

В контексте изучения истории атак на вычислительные системы и построения

таксономии нарушений информационной безопасности для наиболее точного отражения

сущности термина "flaw" представляется целесообразным ввести понятие потенциальной

бреши в системе обеспечения безопасности (ПББ). Под ПББ понимается как

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

может привести к нарушению нормального функционирования ВС и нарушению

безопасности информации (несанкционированный доступ, ознакомление, уничтожение

или искажение данных), так и особенности построения входящих в состав ВС

программных средств обеспечения безопасности, которые не в состоянии противостоять

атакам и обеспечивать безусловное выполнение возложенных на них задач по

обеспечению безопасности.

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

известных случаев нарушения безопасности ВС. Для того чтобы были понятны

приведенные в этой главе результаты исследования [1], и чтобы подкрепить реальными

фактами предлагаемую авторами таксономию причин возникновения ПББ, Приложение

1 содержит список имевших место случаев нарушения безопасности ВС,

заимствованный из [1].

3.2. История исследования

нарушений безопасности

компьютерных систем.

Особенно важными и значимыми научными работами в области выявления,

исследования и систематизации ПББ являются труды [2,12] и одна из последних

публикаций в данной области [1]. Представляется целесообразным кратко рассмотреть

работы [2,12,17] и затем подвергнуть подробному анализу результаты, полученные в

последних зарубежных научных исследованиях. Наиболее серьезные усилия по

выявлению ПББ в системах защиты с помощью экспериментов по их преодолению

нашли свое отражение в разработанной в начале 70-х т.н. методологии гипотетического

выявления ПББ (Flaw Hypothesis Methodology) [12]. Данная методология

предусматривает проведение исследований в три этапа. Первый этап состоит в изучении

системы, причем особое внимание уделяется принципам функционирования механизмов

защиты. На втором этапе происходит выдвижение предположений (гипотез) о

потенциально уязвимых узлах, которые затем тщательно проверяются на основании

анализа документации по системе, реальных особенностей и деталей ее

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

подтвердить или опровергнуть присутствие предполагаемой бреши в системе защиты.

Наконец на третьем, заключительном этапе полученные результаты обобщаются и

формируются списки (перечни) выявленных ПББ и успешных атак. Хотя в [12]

присутствует перечень ПББ исследованных систем и разработанных и успешно

осуществленных атак, систематизация полученных данных выполнена не была.

В середине 70-х годов подобные исследования проводились по проектам RISOS

(Research in Secured Operating System) [2] и PA (Protection Analysis)[5]. В обоих проектах

были предприняты попытки формального описания и систематизации информации о

ПББ.

В заключительном отчете по проекту RISOS [2] приведено описание следующих

категорий ПББ в защищенных операционных системах:

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

2. Противоречия в проверке допустимости значений критичных параметров.

3. Неявное совместное использование несколькими пользователями

конфиденциальной информации.

4. Асинхронный контроль параметров/неадекватная последовательность действий

5. Недостаточно надежная идентификация/аутентификация/авторизация.

6. Возможность нарушения запретов и ограничений

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

Отчет [2] описывает разработанные примеры атак для каждого из типов ПББ и

содержит детальную информацию по семнадцати реально выявленным ПББ в трех

операционных системах: IBM MVT, Univac 1100 и TENEX. Каждая из ПББ четко

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

Целью проекта РА был сбор информации и построение абстрактных моделей,

которые в дальнейшем могли бы быть применены для автоматизированного поиска ПББ.

В соответствии с приведенными в [5] данными, более ста ПББ, способных привести к

несанкционированному проникновению в систему, были обнаружены в шести различных

операционных системах (GCOS, Multics, Unix, IBM MVT, Univac 1100 и TENEX). Хотя

ни подробная информация о них, ни даже их список не был опубликован, была

разработана классификационная таблица ПББ. Изначально в ней было предложено

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

1. Ошибки выделения областей (доменов), включающие незащищенное (в

открытом виде) хранение и представление данных, неполное уничтожение объектов или

их окружения;

2. Ошибки контроля и проверки, состоящие в некорректной проверке значений

параметров и границ объектов;

3 Ошибки назначения имен, допускающие возможность использования нескольких

имен для одного объекта и неполное запрещение доступа к уничтоженным объектам;

4. Ошибки в последовательности действий, влекущие за собой некорректное

использование множественных ссылок (указателей) на объект и ошибки прерывания

атомарных операций

Предлагаемые в работе [5] методики поиска ошибок безопасности в операционных

системах реально достаточно ограничены в применении. Это можно объяснить

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

сказалось на возможности их развития и адаптации для новых ОС. С другой стороны,

усилия исследователей слишком рано были перенаправлены от изучения ПББ в сторону

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

свободных от подобных ошибок.

В настоящей работе преследуется более определенная и реальная цель: на

основании опубликованной информации о ПББ разработать их детальную

иерархическую классификацию и сопоставить полученные результаты с современными

достижениями технологии разработки защищенных систем.

3.3. Таксономия ПББ.

Таксономия, в отличие от классификации, представляющей собой абстрактную

структуру разнесенных по категориям экземпляров, включает в себя комплексное

исследование предметной области и создание теоретической модели полного множества

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

в основу той или иной классификации. На основании предложенной модели таксономия

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

любой выбранной классификации.

С точки зрения технологии создания защищенных систем наибольшее значение

имеют следующие вопросы, на которые должна дать ответ таксономия ПББ:

1. Каким образом ошибки, приводящие к появлению ПББ, вносятся в систему

защиты (классификация ПББ по источнику появления)

2. Когда (на каком этапе) они вносятся (классификация ПББ по этапу

возникновения.)

3. Где (в каких узлах) системы защиты (или ВС в целом) они возникают и

проявляются (классификация ПББ по размещению в системе ).

Каждый вопрос предопределяет наличие соответствующего подраздела

таксономии, в котором должен быть рассмотрен каждый случай нарушения

безопасности.

3.3.1.Классификация ПББ по источнику появления.

Как следует из определения ПББ, источником ее появления является ошибка или

недоработка в системе безопасности. Исследованию ошибок, тем или иным образом

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

можно привести работы [2,3,4,11,12,13,16,17]. Исследования [1,2,4] показывают, что

подобные ошибки носят неслучайный характер. Классификация ПББ по источнику

появления, приведенная в работе [1] показана в таблице 3.1.

Под источником появления (эквивалентный перевод емкого английского термина

genesis), в[1] понимается основа существования ПББ, т.е. либо характеристики ВС,

которые обуславливают ее существование, либо принцип функционирования средств,

использующих ПББ для осуществления атаки. С точки зрения авторов данный подход

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

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

Действительно, (см. таблицу 3.1) классификация преднамеренных ПББ фактически

представляет собой таксономию РПС по принципам функционирования, а

непреднамеренных — классификацию ошибок, возникающих в ходе программной

реализации системы, и являющихся основой существования ПББ. Для решения

практических задач наибольший интерес представляет таксономия ПББ по причинам

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

результаты которого будут представлены далее.

Ошибки, служащие источником появления ПББ, могут быть внесены в систему

защиты специально (преднамеренно), либо возникнуть неумышленно, непреднамеренно.

Для выявления таких непреднамеренных, в определенном смысле случайных, ошибок

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

ошибок может быть выявлено и устранено при увеличении времени и глубины анализа и

тестирования кода системы защиты. Но в отношении наиболее серьезных преднамеренно

внесенных (и вероятней всего замаскированных) ошибок этот способ, скорее всего,

окажется малоэффективным. Для того чтобы сделать процесс поиска таких ошибок более

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

попытках проникновения в систему и проведения атак на систему защиты. Одной из

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

аргументированный выбор эффективной стратегии выявления ошибок в системах

обеспечения безопасности путем проведения экспериментальных атак на ВС.

Характеристика преднамеренности является в определенной мере относительной.

В некоторых случаях определенные функции, специально добавленные в программное

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

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

может привести к появлению ПББ. Такая ошибка может быть классифицирована как

преднамеренная, но не имеющая деструктивной функции.

Хотя определенные злоумышленные, преднамеренные ошибки могут

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

"троянскую" программу. В спорных случаях при классификации ошибок по их

происхождению в работе [1] рекомендуется обратиться к другим классификационным

признакам, например, к этапу внесения ошибки. Как правило, случайные ошибки

вносятся в систему при разработке требований к безопасности и спецификаций системы

защиты (откуда они автоматически попадут в средства, их реализующие), а также в

процессе сопровождения системы (обновления версии, поставки новых утилит и т.п.).

Напротив, преднамеренные ошибки внедряются в систему именно на этапе ее

применения (если, конечно, среди разработчиков системы не было лица,

заинтересованного в ее компрометации).

Преднамеренные и злоумышленные ошибки являются достаточно трудно обнаруживаемыми

потому, что они специально скрыты, замаскированы именно с целью не быть обнаруженными. Эти

являются самыми опасными: специально внесенные 'ошибки с деструктивными функциями могут

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

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

Кол-

во

приме

ров

Индексы в

приложени

и 1

Ошибки в

системах

защиты,

служащие

источнико

появления

ПББ.

преднаме

ренные

С наличием

деструктивных

функций

РПС Несамовоспроизводя

щиеся РПС

(троянские кони)

3 PC1, PC3,

Самовоспроизводящи

еся РПС (вирусы)

7 U1, PC2,

PC4, MA1,

MA2, CA1,

AT1

Черные ходы, люки, скрытые

возможности проникновения в

систему.

2 U1, U10

Без

деструктивных

функций

(пассивные)

Скрытые

каналы

утечки

информации

использованием

памяти

1 DT1

использованием

времени

2 I9, D2

другие 5 I7, B1, U3,

U6, U10

Непредна

меренные

(случайн

ые)

Ошибки контроля допустимых значений

параметров

10 I4, I5, MT1,

MU2, MU4,

MU8, U7,

U11, U12,

U13

Ошибки определения областей (доменов) 7 I3, I6, MT2,

MT3, MU3,

UN1, D1

Ошибки последовательности действий и

использования нескольких имен для одного

объекта (в т.ч. TOCTTOU)

2 I1, I2

Ошибки идентификации/аутентификации 5 MU1, U2,

U4, U5,

U14

Ошибки проверки границ объектов 4 MT4,MU5,

MU6, U9

Другие ошибки в логике функционирования 4 MU7, MU9,

U8, IN1

Таблица 3.1. Таксономия ПББ по источнику появления.

Преднамеренное внедрение ПББ с наличием деструктивных функций.

Преднамеренно (злоумышленно) внесенные в систему защиты ПББ и связанные с

ними каналы утечки информации по сути дела являются результатом функционирования

предварительно внедренных специальных средств — РПС, о которых говорилось выше.

Общей характерной чертой РПС является активный характер их функционирования —

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

Как правило, они имеют жаргонные названия, подчеркивающие их суть, например,

"троянский конь", "логическая бомба", "часовая мина". Подробные сведения о РПС

приведены в первой главе данной книги.

"Логические бомбы" и "часовые мины" — это РПС, которые не выполняют

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

"срабатывают", что, как правило, заключается в серьезных нарушениях работы системы,

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

проявления данного вида преднамеренно внедренного кода является отсутствие

маскировки выполнения деструктивных функций. Последствия "срабатывания" чаще

всего носят катастрофический характер и могут привести к полному уничтожению

системы и/или данных. С учетом сказанного в первой главе, РПС являются одним из

самых опасных и самым разрушительным видом ПББ.

"Черным ходом" называется скрытая (замаскированная) возможность получения

доступа к ресурсам в обход стандартных механизмов контроля Например, разработчик

программы проверки уникального идентификатора может при совпадении

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

осуществление некоторые непредусмотренных действий, скажем, отменить контроль

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

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

Преднамеренно внедренные ПББ без деструктивных функций.

РПС могут осуществлять взаимодействие с атакующим систему злоумышленником

через т.н. "скрытые каналы" утечки информации. Под скрытым каналом следует

понимать любую возможность обмена информацией с процессами или другими

компонентами системы, не предусмотренную ее разработчиками (и, как следствие,

неконтролируемую системой защиты) [10] Отнести скрытые каналы к непреднамеренно

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

В силу отсутствия контроля за скрытыми каналами со стороны системы защиты они

широко используются злоумышленниками. Фактически скрытые каналы являются

типичными примерами ПББ.

Для использования скрытых каналов требуется наличие двух процессов" один (как

правило, РПС) осуществляет сбор информации, интересующей злоумышленника, и

помещает ее в скрытый канал, как уже было сказано, неконтролируемый системой

защиты. Другой процесс осуществляет прослушивание канала в ожидании поступления

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

сохранение.

Скрытые каналы утечки в зависимости от способа кодирования информации,

передаваемой между этими процессами, подразделяются на два типа: с использованием

памяти и с использованием времени.

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

область памяти, не имеющая важного значения (например, установление характерных

признаков в имени и атрибутах файла), либо вообще неиспользуемая область (например,

зарезервированные поля в заголовке сетевого пакета).

Во втором случае, более сложном для реализации, информация кодируется

определенной последовательностью и длительностью событий, происходящих в системе

(например, с помощью модуляции интервалов обращения к устройствам, введения

задержек между приемом и посылкой сетевых пакетов и т.д.).

Кроме скрытых каналов, в системе могут присутство| вать и другие

преднамеренно внесенные ошибки, не влекущие за собой разрушительных последствий.

К их появлению автоматически приводит любое расхождение между требованиями по

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

уникальности и трудности выделения общих особенностей более подробная их

классификация не проводилась.

Непреднамеренные (неумышленные) ошибки и ПББ.

Непреднамеренные ПББ могут возникнуть в системе изза наличия ошибок на этапе

разработки требований к безопасности, при разработке спецификаций и на этапе их

реализации, т.е. в процессе написания программ. Ошибки такого типа были подробно

исследованы и классифицированы в работах [2,4]. Хотя большинство из них

обнаруживается и устраняется во время тестирования, ряд ошибок может остаться

незамеченным и вызвать определенные проблемы на этапе эксплуатации системы.

Наиболее трудно выявляются такие ошибки в сложных системах, состоящих из

многочисленных компонент, разработанных при участии большого коллектива

специалистов. Одна из неотъемлемых проблем таких систем — невозможность

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

документирования. Недостатки проектной документации в процессе сопровождения и

эксплуатации приводят к тому, что при попытке устранения одних ошибок в нее

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

их использованию и нарушению безопасности системы, это является лишь вопросом

времени.

Неумышленные ПББ могут быть классифицированы в соответствии со

следующими группами ошибок, предопределяющих их существование:

1. Ошибки контроля допустимых значений параметров.

2. Ошибки определения областей (доменов).

3. Ошибки последовательности действий и использования нескольких имен для

одного объекта.

4. Ошибки идентификации/аутентификации.

5. Ошибки проверки границ объектов.

6. Ошибки в логике функционирования.

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

соответствующим механизмом неправильного заключения о соответствии проверяемого

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

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

Ошибки контроля можно рассматривать как неадекватную реакцию механизмов защиты

на возникающие в системе события.

Ошибки определения областей (доменов) выражаются в наличии

открытого(неконтролируемого) способа доступа в защищенную область. Например,

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

к которому запрещен, посредством доступа к его физическому представлению на

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

(скажем, доступ к остаточной информации в занимаемой объектом области памяти после

ее освобождения).

Наличие ошибок последовательности действий предопределяется асинхронным

функционированием компонент системы, которое может быть использовано для

нарушения безопасности. Выявить такие ошибки в системе достаточно трудно. Их суть

заключается в том, что в силу невозможности представления каждой из функций

системы единственной атомарной операцией, многие из функций выполняются как

некоторая асинхронная последовательность действий (операций), возможно

осуществляемых несколькими компонентами системы. Например, одной из операций

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

соответствующих полномочий, или, проверка допустимости параметра, а затем — его

использование. Асинхронность может быть использована злоумышленником для обмана

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

проверки его допустимости, но перед использованием. Данная ошибка носит название

TOCTTOU[16](time-of-check to time-of-use) — возможность подмены параметра между

моментом проверки и моментом использования (смотри 11 в Приложении 1).

Ошибки идентификации/аутентификации приводят к тому, что неуполномоченный

на соответствующие действия пользователь получает доступ к защищенным объектам в

объеме полномочий другого лица. Эти ошибки в принципе можно рассматривать как

ошибки контроля в том смысле, что происходит неправильная проверка параметров

идентификации и подлинности пользователя и объекта. Однако по причине

значительного числа случаев нарушений безопасности из-за неправильной

идентификации/аутентификации целесообразно вынести данную категорию ошибок

отдельно.

Ошибки проверки границ объектов и связанные с ними каналы утечки обычно

возникают из-за игнорирования проверок того, что определенный объект пересек

границы области памяти, отведенной для его хранения (контроль длины строки, размера

массива, размера и положения файла и т.д.). Самый известный пример — программа

Finger в ОС Unix (смотри пример U12 в Приложении 1).

Существуют также другие ошибки, не попадающие непосредственно ни в одну из

перечисленных категорий. В целом их можно назвать ошибками логики

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

использованы злоумышленниками для проникновения в систему и нарушения

безопасности.

3.3.2. Классификация ПББ по этапам внедрения.

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

возникают ПББ, анализу этапа появления ошибок уделяется недостаточное внимание.

Результаты исследования данного вопроса подробно изложены в нескольких работах,

наибольший интерес из которых представляет [2], в которой проблема выявления этапа

внедрения ошибок рассматривается по отношению к жизненному циклу программного

обеспечения.

Существует большое число моделей жизненного цикла программных систем и

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

ПББ относительно времени их внедрения необходимо построить простую абстрактную

схему, соответствующую широкому спектру технологий разработки ПО.

На самом верхнем уровне представления жизненного цикла систем можно

выделить три фазы:

— фазы разработки, которая охватывает весь период создания исходной рабочей

версии системы;

— фазы сопровождения, в ходе которой происходит модификация,

совершенствование, развитие системы и появление ее очередных версий;

— фазы эксплуатации, то есть непосредственного функционального применения конкретной

версии системы. Хотя на практике фазы сопровождения и эксплуатации перекрываются во времени, им

присущи различные особенности, которые позволяют четко выделить соответствующие категории ПББ

Таксономия ПББ по этапу внедрения, основанная на этих положениях, приведена в таблице 3.2.

Количество

примеров

Индексы в

приложении 1

Этап внедрения

ошибки и

возникновения

ПББ

На стадии разработки Ошибки в

требованиях и

спецификациях

22 I1, I2, I3, I4, I5, I6

Ошибки в

исходных

текстах

программ

15 MT1, MT4, MU1,

MU2, MU5, MU7,

MU8, DT1, U2, U3,

Ошибки в

исполняемом

коде

1 U1

В ходе сопровождения 3 D1, MU3, MU9

В ходе эксплуатации 9 I8, PC1, PC2, PC3,

PC4, MA1, MA2,

CA1, AT1

Таблица 3.2. таксономия ПББ по этапу возникновения.

Возникновение ПББ в процессе разработки системы.

Процесс разработки любой программной системы включает в себя несколько

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

требований разрабатываются спецификации, на основании спецификаций создаются

исходные тексты программ, которые затем компилируются и превращаются в

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

внесены ошибки, которые приводят к возникновению ПББ.

Составление требований и спецификаций.

Требования к программному обеспечению описывают что должна делать каждая из

программ в составе системы Спецификации же определяют то, каким образом эти

действия должны выполняться. Требования и спецификации взаимосвязаны настолько

тесно, что относить обусловленные ими ПББ к разным категориям представляется

нецелесообразным.

Маловероятно, что требования или спецификации могут содержать положения,

явно обуславливающие преднамеренные ошибки и каналы утечки информации. И

требования, и спецификации достаточно открыты и понятны и позволяют относительно

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

Более реально присутствие ошибок, обусловленных необходимостью

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

требований к системе. Конкуренция этих требований и неизбежно возникающие

противоречия требуют от разработчиков принятия компромиссных решений, в которых

предпочтение может быть отдано функциональности системы в ущерб ее безопасности.

В качестве примера можно привести выполнение пользователем программ в режиме

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

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

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

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

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

Большинство ошибок (но не все) в исходных текстах, как случайных, так и внесенных

преднамеренно, может быть обнаружено при тщательном их изучении.