Как построить защищенную информационную систему. Книга
Рефераты >> Программирование и компьютеры >> Как построить защищенную информационную систему. Книга

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

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

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

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

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

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

Рассмотрим подробнее перечисленные этапы с точки зрения возможности появления ошибок, приводящих к возникновению ИЗ.

3.3.2.1. Возникновение ИЗ в процессе разработки системы

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

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

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

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

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

Таблица 3 2 Классификация ИЗ по этапу возникновения

     

Количество примеров

Индексы в Приложении IV

Этап внедрения ошибки и

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

На стадии разработки

Ошибки в требованиях и спецификациях

22

I1, I2, I3, I4, I5, I6

Ошибки в исходных текстах программ

15

MT1,MT4,MU1,MU2,

MU5,MU7,MU8, DT1,U2,U3,U4

Ошибки в исполняемом коде

1

Ul

В ходе сопровождения

3

D1,MU3,MU9

В ходе эксплуатации

9

I8, PC1, PC2, PC3, PC4, MA1, MA2, CA1, AT1

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

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

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

Преднамеренные ошибки могут быть внесены в сис­тему по целому ряду причин. Программист может вне­дрить в систему код, не предусмотренный ее специфика­циями, но необходимый ему для отладки и тестирования разрабатываемой программы. Однако, если по заверше­нию разработки этот код не будет удален из системы, он превратится в реальный канал утечки информации и может быть использован злоумышленником. Самый из­вестный пример такого рода — программа sendmail, по­зволившая широко распространиться сетевому вирусу Морриса (U10 в Приложении IV).

3.3.2.1.3. Генерация исполняемого кода

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

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

3.3.2.2. Возникновение ИЗ в процессе сопровождения и развития системы

Случайные ошибки, внесенные в систему во время ее сопровождения, чаще всего обусловлены неправиль­ным представлением программистами каких-либо ас­пектов функционирования системы в целом. Любые изменения, вносимые ими в систему, потенциально}) мо­гут превратиться в каналы утечки информации.! По­этому каждое вносимое в ПО изменение должно со­провождаться тщательной проверкой всей системы так, как если бы это было испытанием абсолютно но­вой системы.

3.3.2.3. Возникновение ИЗ в процессе функционирования системы

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

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


Страница: