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

Показатели технологической безопасности информационных систем

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

Наиболее полно безопасность ИС характеризует величина ущерба, возможного при проявлении дестабилизирующих факторов и реализации конкретных угроз безопасности, а также среднее время между проявлениями угроз, нарушающих безопасность. Однако описать и измерить в достаточно общем виде возможный ущерб при нарушении безопасности для критических ИС разных классов практически невозможно, поэтому реализации угроз целесообразно характеризовать интервалами времени между их проявлениями, или наработкой на отказы, отражающиеся на безопасности. Это сближает понятия и характеристики степени безопасности с показателями надежности ИС. Различие состоит в том, что в показателях надежности учитываются все реализации отказов, а в характеристиках безопасности следует регистрировать только те отказы, которые отразились на безопасности. Статистически таких отказов может быть в несколько раз меньше, чем учитываемых в значениях надежности, однако методы, влияющие факторы и реальные значения показателей надежности ПС и БД могут служить ориентирами при оценке безопасности критических ИС. Поэтому ниже методы и оценки технологической безопасности ИС базируются на концепции надежности программ и баз данных [8], [9], [10], [11].

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

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

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

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

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

В теории надежности работоспособным называется такое состояние объекта, при котором он способен выполнять заданные функции с параметрами, установленными требованиями технической документации [8]-[11], [37]. Надежность является внутренним свойством систем, проявляющимся только во времени. Критерии качества становятся динамическими и преимущественно стохастическими, характеризующими функционирование ИС в целом или крупных групп программ. Измеряемые интегральные показатели качества программ в этом случае более определенные и могут достаточно точно оцениваться экспериментально.

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

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

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

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

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

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

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

Высокие темпы роста основных ресурсов аппаратных средств (приблизительно на порядок каждые пять лет) и сохраняющаяся потребность в их увеличении со стороны пользователей приводят к необходимости адекватного совершенствования технологий создания программ и баз данных. Одним из важнейших и эффективных путей решения этой проблемы являются концепция и совокупности стандартов открытых систем [12], [13], [14].

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

Продуманная и упорядоченная структура ПС и БД непосредственно отражается на достигаемом качестве и безопасности ИС, а также на трудоемкости их разработки [11], [15], [16]. При строгом соблюдении правил структурного построения значительно облегчается достижение высоких показателей качества и безопасности, так как, с одной стороны, сокращается число возможных ошибок, а с другой — упрощается их диагностика и локализация.

Такие ИС могут иметь длительный жизненный цикл с множеством базовых и пользовательских версий программ и баз данных. Далее в понятие "базовые версии ИС" включаются завершенные комплексы программ и базы данных, которые успешно прошли испытания у заказчика или сертификацию, снабжены комплектной документацией и могут поставляться как готовые к применению изделия. Пользовательские версии формируются из базовых по инструкциям, изложенным в документации, путем адаптации к конкретным характеристикам среды применения. При проектировании каждый комплекс программ или база данных некоторого функционального назначения может иметь несколько рабочих версий, различающихся уровнем технологической безопасности, составом и характеристиками компонент [36].

Гибкость модификации ИС и технологическая безопасность при развитии обеспечиваются рядом принципов и правил структурного построения ИС и ее компонент, а также взаимодействия между ними. Эти правила направлены на стандартизацию и унификацию структуры и взаимодействия компонент разного ранга и назначения в пределах проблемной области. Некоторая часть принципов и правил имеет достаточно общий характер и может применяться практически всегда. Другая часть отражает проблемную и машинную ориентированность класса ИС и подлежит отработке для эффективного применения в соответствующей области. Основные принципы и правила можно объединить в группы, которые отражают:

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

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

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

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

Целесообразно разделять ресурсы, необходимые для непосредственного решения основных функциональных задач ИС, и ресурсы, требующиеся для обеспечения безопасности функционирования ПС и БД. Соотношение между этими видами ресурсов в реальных ИС зависит от сложности и состава решаемых функциональных задач, степени их критичности и требований к безопасности всей информационной системы. В различных ИС ресурсы на обеспечение надежности и безопасности могут составлять от 5-20% до 100-300% от ресурсов, используемых на решение функциональных задач, то есть в особых случаях (критические военные системы) могут превышать последние в 2-4 раза. В большинстве гражданских систем средства обеспечения безопасности обычно требуют 5-20% всех видов ресурсов. Ниже внимание акцентируется на ресурсах для обеспечения технологической безопасности без учета ресурсов на функциональные задачи ИС.

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

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

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

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

Аппаратурная оснащенность разработки конкретной ИС определяется прежде всего ресурсами и другими характеристиками реализующей и технологической ЭВМ.

Тип реализующей ЭВМ, ее ресурсы, определяют возможность размещения на ней создаваемых ПС и БД и средств обеспечения безопасности.

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

Для размещения средств обеспечения технологической безопасности ИС в реализующей ЭВМ, необходимы программная и информационная избыточности в виде ресурсов внешней и внутренней памяти ЭВМ. Кроме того, для функционирования средств защиты необходима временная избыточность — дополнительная производительность ЭВМ. Эти виды избыточности вычислительных ресурсов при обеспечении технологической безопасности используются для:

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

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

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

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

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

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

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

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

Последующий анализ безопасности ИС при отсутствии злоумышленных дестабилизирующих факторов базируется на модели взаимодействия основных компонент, представленных на Рис. 1. В качестве объектов уязвимости рассматриваются:

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

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

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

Внешними дестабилизирующими факторами, создающими угрозы безопасности функционирования перечисленных объектов уязвимости ИС являются:

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

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

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

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

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

В результате важной особенностью процесса выявления ошибок в программах и данных сложных, критических ИС является отсутствие полностью определенного эталона, которому должны соответствовать текст и результаты функционирования разработанной программы [9], [10], [28]. Поэтому установить наличие и локализовать ошибку непосредственным сравнением с программой или данными без дефектов в большинстве случаев невозможно. При отладке и тестировании обычно сначала обнаруживаются вторичные ошибки, то есть последствия и результаты проявления некоторых дефектов, которые следует квалифицировать как первичные ошибки или причины обнаруженных аномалий. Локализация и корректировка таких первичных ошибок приводит к устранению ошибок, первоначально обнаруживаемых в результатах функционирования программ.

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

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

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

• оценивать реальное состояние проекта и планировать трудоемкость и длительность его завершения;
• выбирать методы и средства автоматизации тестирования программ, адекватные текущему состоянию разработки ПС и наиболее эффективные для устранения определенных видов ошибок;
• прогнозировать эффективность средств оперативной защиты от невыявленных первичных ошибок;
• оценивать требующиеся дополнительные ресурсы ЭВМ с учетом затрат на устранение ошибок.

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

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

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

Убывание числа ошибок в ИС и интенсивности их обнаружения в процессе разработки не беспредельно. После отладки в течение некоторого времени интенсивность обнаружения ошибок при самых жестких условиях тестирования снижается настолько, что коллектив, ведущий разработку, попадает в зону нечувствительности к ошибкам и отказам. При такой низкой интенсивности отказов трудно прогнозировать затраты времени, необходимые для обнаружения очередной ошибки. Создается представление о полном отсутствии ошибок, о невозможности и бесцельности их поиска, вследствие чего усилия на отладку сокращаются и интенсивность обнаружения ошибок еще больше снижается. Этой предельной интенсивности обнаружения отказов соответствует наработка на обнаруженную ошибку, при которой прекращается улучшение характеристик ПС на этапах отладки или испытаний [5], [9], [22], [28].

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

Методы снижения угроз безопасности ИС, вызванных дефектами программных средств и баз данных

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

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

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

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

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

При создании критических ИС высокой сложности важная проблема состоит в правильном системотехническом и информационно-технологическом проекте, обеспечивающем высокие потребительские свойства и безопасность ИС. Одновременно в силу высокого качества проработки и документирования проекта создается основа для снижения трудоемкости отладки, испытаний и особенно сопровождения и развития прикладной ИС. Совместное применение современных CASE-технологий и языков четвертого поколения способно снизить трудоемкость разработки сложных программных средств до 10 раз и сократить длительность их проектирования с 2-3 лет до нескольких месяцев.

Базовым принципом современных методов и технологий создания прикладных программных средств и баз данных является многократное использование отработанных технических решений на различных аппаратных и операционных платформах. В настоящее время по некоторым оценкам только 10-15% прикладных программ создается вновь, в то время как основная часть программных средств переносится с других платформ, комплексируется и собирается из готовых, испытанных, повторно используемых компонент гарантированного качества. Это обеспечивает многократное повышение производительности труда разработчиков информационных систем, сокращение сроков их создания, высокое качество и безопасность проектов.

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

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

Непосредственной целью тестирования является обнаружение, локализация и устранение ошибок в программах и данных. Важной особенностью тестирования сложных критических ИС является необходимость достаточно полной их проверки при ограниченной длительности испытаний. Это определяет целесообразность тщательного планирования тестирования с учетом всех результатов, полученных на предыдущих этапах разработки. При планировании основная задача состоит в достижении максимальной достоверности испытаний, определении качества и безопасности ИС при ограниченных затратах ресурсов всех видов на проведение тестирования [16], [21], [28].

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

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

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

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

Оперативные методы повышения безопасности функционирования программных средств и баз данных

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

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

Временная избыточность состоит в использовании некоторой части производительности ЭВМ для контроля исполнения программ и восстановления (рестарта) вычислительного процесса [9], [28]. Для этого при проектировании ИС должен предусматриваться запас производительности, который будет затем использоваться на контроль и повышение надежности и безопасности функционирования. Величина временной избыточности зависит от требований к безопасности функционирования критических систем управления или обработки информации и находится в пределах от 5-10% производительности до трех-четырехкратного дублирования в мажоритарных вычислительных комплексах.

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

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

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

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

• при искажениях программ и данных в памяти ЭВМ;
• при перегрузках по производительности.

В зависимости от степени проявления и причин обнаружения искажений возможны следующие оперативные меры для ликвидации их последствий, восстановления информации и сохранения безопасности процессов обработки данных и управления (см. Рис. 2):

• игнорирование обнаруженного искажения вследствие слабого влияния на весь процесс функционирования и выходные результаты;
• исключение сообщения из обработки вследствие его искажения или трудности предстоящего восстановления вычислительного процесса;
• повторение функциональной группы программ при тех же исходных данных или восстановление данных в процессе последующей обработки;
• кратковременное прекращение решения задач данной группы прикладных программ до обновления исходных данных;
• перестройка режима работы или структуры ИС для снижения влияния перегрузки или в связи с потерей информации о ходе процесса обработки данных и управления;
• переход на резервную ЭВМ с накопленной информацией о ходе процесса управления или восстановление информации за счет ее дублирования;
• восстановление процесса управления или обработки информации с режима начального пуска всей ИС с оперативным вмешательством обслуживающего персонала.

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

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

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

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

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

При использовании зарубежных ПС и БД, в принципе, возможны как злоумышленные, так и случайные, непредумышленные искажения вычислительного процесса, программ и данных, отражающиеся на безопасности их применения [3], [4], [29]. Злоумышленные вирусы и "закладки", хотя и маловероятные в серийных, широко тиражируемых в мире ПС и БД, тем не менее требуют особых методов и средств целенаправленного их обнаружения и устранения [2], [4], которые в данной работе не рассматриваются. Внимание акцентируется на случайных воздействиях на программы и данные и методах снижения их влияния на безопасность ИС.

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

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

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

Оперативные методы повышения безопасности функционирования ПС и БД предусматриваются в некоторых зарубежных изделиях и, прежде всего, в реляционных СУБД в механизмах обеспечения целостности информации баз данных. Однако разнообразие условий функционирования ПС и БД в отечественных, критических ИС не позволяет удовлетвориться только штатными методами оперативного обнаружения аномалий и восстановления вычислительного процесса, программ и данных. Методы и средства для этого могут быть в ряде случаев достаточно автономными и ориентированными на оперативное повышение безопасности конкретной ИС в целом, а не только отдельных используемых ПС и БД. Эти специализированные методы и средства могут разрабатываться отечественными специалистами на базе концепции обеспечения комплексной безопасности и всех используемых для конкретной ИС импортных компонентов. Такой подход позволяет обеспечить комплексирование разнородных ПС и БД различных зарубежных поставщиков и специализированной отечественной системы оперативной защиты в единой ИС. При этом важно использовать концепцию и стандарты открытых систем [12], [13], [14] при взаимодействии между как закупаемыми, так и вновь разрабатываемыми компонентами ИС, а также при их взаимодействии с внешней средой.

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

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

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

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

Значительную помощь в повышении технологической безопасности сложных, критических ИС может оказать систематизация видов тестирования и упорядоченное их проведение при испытаниях. Эти виды тестирования ориентированы на дифференцированное выявление определенных классов дефектов. Для каждого вида тестирования целесообразно разрабатывать методику его выполнения с указанием контролируемых параметров и ожидаемых, эталонных результатов. Кроме того, при заключительных испытаниях или сертификации должно проводиться интегральное тестирование при максимально широком варьировании тестов в условиях, соответствующих нормальной эксплуатации [9], [21], [28].

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

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

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

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

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

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

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

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

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

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

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

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

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

Перечисленные требования определяют необходимость разработки соответствующих проблемно-ориентированных интегрированных систем, способных достаточно полно заменить испытания программ и баз данных с реальными объектами внешней среды. При этом высокая стоимость и риск испытаний с реальными объектами почти всегда оправдывает значительные затраты на такие интегрированные системы, если предстоят испытания критических ИС с высокими требованиями к надежности и безопасности функционирования программ и длительным жизненным циклом с множеством развивающихся версий [19], [20], [36].

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

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

Обработка результатов испытаний

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

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

Обработка результатов испытаний ИС реального времени может быть разделена на две автономные части: оперативную и обобщающую.

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

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

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

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

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

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

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

Если интенсивное тестирование программ в течение достаточно длительного времени не приводит к обнаружению ошибок, ИС передается в эксплуатацию. Экспериментальное исследование характеристик обнаружения ошибок в сложных ИС [9] позволило оценить темп обнаружения ошибок, при котором сложные комплексы программ передаются в регулярную эксплуатацию: 0,002-0,005 ошибок в день на человека, то есть специалисты по отладке, испытаниям или пользователи выявляют только около одной ошибки каждые два месяца использования ИС. Интенсивность обнаружения ошибок ниже 0,001 ошибок в день на человека, то есть меньше одной ошибки в год на трех-четырех специалистов, непосредственно участвующих в тестировании, по-видимому, может служить эталоном высокого качества отладки для ИС обработки информации и управления. При использовании этого критерия обычно учитывается календарное время отладки и испытаний, включающее длительность непосредственного тестирования как для обнаружения, так и для локализации ошибок, а также длительность корректировки программ и других вспомогательных работ.

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

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

Технологическая безопасность и жизненный цикл информационных систем

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

На величину интервала времени между отработанными версиями влияют также административные планы, запаздывание оформления полной документации и инерционность в передаче версий пользователям. В худшем случае возможно явление распада системы, когда чрезмерный рост доработок в версии системы делает ее развитие неуправляемым и резко ухудшает эксплуатационные характеристики и безопасность. Период колебаний объема изменений и соответствующих им характеристик качества для больших ИС в разных проектах операционных систем [32] составляет 1-2 года. Это можно объяснить некоторой моделью административной деятельности при сопровождении ИС. Для сопровождения коллектив специалистов имеет ограниченные ресурсы, которые обобщенно можно характеризовать бюджетом. Для введения новых функций и программных компонент необходимы усилия, которые должны увеличиваться по мере роста сложности ИС. Прогрессивному развитию программ способствует пропорциональный рост числа вносимых при этом ошибок. Рост сложности ПС способствует увеличению энтропии, которая требует затрат на "антирегрессионную" деятельность — борьбу с ошибками и отставанием корректировок документации, затрат на повышение квалификации специалистов и т.д. Пренебрежение "антирегрессионной" деятельностью приводит к накоплению потребностей в этой работе в условиях повышающейся сложности программ и ограниченного бюджета. В результате приходится временно снижать деятельность по развитию программ, с тем чтобы не выйти за допустимые ресурсы. При ограниченных трудовых ресурсах возможна предельная критическая сложность сопровождаемых программ, при которой устанавливается динамическое равновесие между доработками и вносимыми ошибками, вследствие чего качество и безопасность ИС не улучшается.

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

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

Ниже представлены некоторые, наиболее важные группы международных стандартов (Таб. 1), регламентирующих:

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

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

Выводы и рекомендации

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

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

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

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

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

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

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

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

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

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

Литература

1. Л.Дж Хоффман -- Современные методы защиты информации -- М.: Сов. радио, 1980
2. В.А Герасименко -- Защита информации в автоматизированных системах обработки данных. Книги 1 и 2 -- М.: Энергоатомиздат, 1994
3. Республиканский н.-т. совет по направлению Информатизация России, НИИ Квант -- Концепция развития безопасных информационных технологий: обеспечение защиты информации в проектах информатизации России -- М., 1992
4. Р.М Юсупов , Б.П. Пальчун -- Безопасность компьютерной инфосферы систем критических приложений. — Вооружение. Политика. Конверсия -- М., 1993, # 2, с.52-56, # 3, с. 23-31.
5. Parnas -- Software aspects of strategic defence systems — Communications of the ACM , 1985, v. 28, n 12. p. 1326-1335
6. Информатика и вычислительная техника. Научно-технический сборник -- М.: ВИМИ , 1994 # 2-3
7. Владимир Галатенко -- Информационная безопасность — обзор основных положений -- JetInfo, 1-3, 1996
8. Б Боэм , Х Каспар Пер. с англ. Е.К. Масловского (ред.) -- Характеристики качества программного обеспечения -- М.: Мир, 1981
9. В.В Липаев -- Отладка сложных программ -- М.: Энергоатомиздат, 1993
10. Г Майерс -- Искусство тестирования программ: Пер. с англ -- М.: Финансы и статистика, 1982
11. Б.У Боэм -- Инженерное проектирование программного обеспечения: Пер. с англ. под ред. А.А. Красилова -- М.: Радио и связь, 1985
12. Open systems handbook: A guide to building open systems -- Digital Equipment Corparation, USA, 1991
13. J.S Quarterman -- Unix, Posix and open systems: The open standards puzzle -- N.Y.: Addison — Wesley Publishing Company, 1993
14. Открытые системы. Материалы к программе развития и применения открытых систем в Российской Федерации -- Казань, 1994
15. В.В Липаев -- Оценка затрат на разработку программных средств -- М.: Финансы и статистика, 1988
16. В.В Липаев -- Управление разработкой программных средств. Методы, стандарты, технология -- М.: Финансы и статистика, 1993
17. A.S Fisher -- CASE: using the newest tools in software development -- N.Y.: John Wiley & Sons, 1988
18. P.A Ng R.T Yeh (ред.) -- Modern software engineering. Foundations and current perspectives. -- N.Y.: Van Nostrand Reinhold, 1990
19. В.В Липаев , А.А Штрик -- Технология сборочного программирования -- М.: Радио и связь, 1992
20. Stradis. Product description -- McDonnell Douglas Corporation, 1990
21. J.D. Musa , A. Iannino , K. Okumoto -- Software Reliability: Measurement, Prediction, Application -- N.Y.: McGraw Hill, 1987
22. R Charett -- Software engineering risk analysis and management -- N.Y.: McGraw Hill, 1989
23. Методические документы ИСО/МЭК по сертификации продукции, оценке систем обеспечения качества продукции и аккредитации испытательных лабораторий -- М.: Изд. стандартов, 1988
24. Сертификация программного обеспечения. Документ радиотехнической комиссии по аэронавтике. RTCA/DO-178. Пер. с англ -- ВЦП, 1981
25. Сертификация продукции. Международные стандарты и руководства ИСО/МЭК в области сертификации и управления качеством -- М.: Изд-во стандартов, 1990
26. В.В Липаев -- Методические основы сертификации информационных технологий -- ВНИИ ПВТИ, 1995
27. В.К Щербо -- Международная стандартизация в области информационной технологии -- Проблемы информатизации, 1992, # 4, с. 47-51
28. W.E Howden -- Functional program testing and analysis -- N.Y.: McGraw Hill, 1987
29. Ю.М Батурин -- Компьютерная преступность и компьютерная безопасность -- М.: Юридическая литература, 1991
30. В.В Липаев -- Распределение ресурсов в вычислительных системах -- М.: Статистика, 1979
31. А.С Шаракшанэ , В.П. Шахин , А.К Халецкий -- Испытания программ сложных автоматизированных систем -- М.: Высшая школа, 1982
32. М.М Леман -- Программы, жизненные циклы и законы эволюции программного обеспечения. - ТИИЭР, Техника программного обеспечения: Пер. с англ -- М.: Мир, 1980, т.68, # 9, с. 26-45
33. A Spector -- The Space Shuttle primary computer system -- Communication of the ACM, 1984, v. 27, n 9, p. 874-890
34. А.В Спесивцев , В.А Вегнер , А.Ю Крутяков , В.А Сидоров -- Защита информации в персональных ЭВМ -- М.: Радио и связь, 1992
35. В.И Савицкий -- Автоматизированные системы управления воздушным движением. Справочник -- М.: Транспорт, 1986
36. J.K Buckle -- Software configuration management -- London: Macmillan Press, 1982
37. A Waters , J Vincent , J Sinclair -- Software quality assurance. Vol. II. A programme guide -- Englewood Cliffs, New Yersey: Prentice-Hall, 1988
38. А.И Костогрызов , В.В Липаев -- Сертификация качества функционирования автоматизированных информационных систем -- Вооружение.Политика.Конверсия, 1996