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

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

Стандартизированные в ISO 9126 характеристики качества ПС различаются по степени влияния на системную эффективность применения комплексов программ по прямому назначению. Высшие приоритеты, естественно, должны присваиваться свойствам и атрибутам функциональной пригодности, необходимым для достижения основных стратегических целей использования ПС. Все остальные стандартизированные характеристики ПС должны способствовать обеспечению тактических целей выбранных конструктивных требований. Решение этих задач должно быть направлено на обеспечение высокой функциональной пригодности ПС путем сбалансированного улучшения остальных конструктивных характеристик качества (и безопасности) в условиях ограниченных ресурсов на ЖЦ . Для этого в процессе системного анализа при подготовке технического задания и требований спецификаций, значения различных факторов, характеристик качества и безопасности должны выбираться с учетом их влияния на функциональную пригодность. На Рис. 1 представлена основная совокупность факторов и действий по обеспечению функциональной безопасности систем и ПС.

Рисунок 1

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Термины, используемые далее и связанные с функциональной безопасностью систем и ПС , аналогичны тем, которые содержатся в стандартах ГОСТ 27.002 — 89, IEC 61508, ISO 15408 и др. Эти определения базируются на понятии отказа как события, заключающегося в нарушении работоспособного состояния объекта. Определение отказа является базовым для оценки функциональной безопасности и надежности технических систем:

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

Для оценивания свойств функциональной безопасности и надежности систем и ПС необходимо регистрировать, измерять, обобщать и упорядочивать реальные характеристики отказовых ситуаций и их последствия для безопасности. С этой целью в стандарте ГОСТ Р 51904 рекомендуются категории отказовых ситуаций систем и ПС , в зависимости от серьезности их влияния на качество функционирования программ или данных объекта управления [8]. Необходимый для безопасного функционирования уровень качества ПС рекомендуется определять исходя из опасности отказовых ситуаций и возможного при этом ущерба для программ, системы и потребителя. Стандартом установлена следующая классификация отказовых ситуаций ( Рис. 2):

• категория А — катастрофическая: отказовая ситуация, которая препятствует полной работоспособности и функционированию системы или ПС в соответствии с требованиями и способна нанести недопустимый по последствиям и величине ущерб системе или пользователям;
• категория B — опасная/критическая: отказовая ситуация, которая приводит к значительному снижению работоспособности, возможностей применения и функционирования системы или к отсутствию способности персонала справиться с неблагоприятными эксплуатационными режимами, при которых возникают:
  • крайне тяжелые ситуации или перегрузки системы, которые могут вызвать неточное или неполное выполнение основных, функциональных задач с большим ущербом;
  • недопустимо большое снижение характеристик функциональной пригодности, реализуемых функций и конструктивных характеристик качества системы или ПС;
  • неблагоприятные или потенциально фатальные воздействия системы или ПС для окружающей внешней среды;
• категория C — существенная: отказовая ситуация, которая приводит к снижению возможностей применения и функциональной пригодности системы или к сокращению способности персонала справиться с неблагоприятными эксплуатационными режимами, при продолжении которых может возникать, например, большое искажение информационных ресурсов или сокращение функциональных возможностей, перегрузки или условия, вызывающие существенное ухудшение работоспособности системы или персонала;
• категория D — несущественная: отказовая ситуация, незначительно уменьшающая безопасность функционирования и применения объекта, но отражающаяся на его надежности или требующая действий персонала, которые осуществимы в пределах их возможностей для восстановления нормальной работоспособности, такая ситуация может включать в себя, например, некоторое увеличение рабочей нагрузки, неудобство применения или задержки информации для персонала;
• категория Е — невлияющая: отказовая ситуация, которая практически не воздействует на работоспособность, эксплуатационные характеристики и возможности объекта или не увеличивает рабочую нагрузку персонала.

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

Рисунок 2.

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

Рисунок 3.

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

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

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

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

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

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

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

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

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

Внутренними источниками угроз безопасности функционирования системы и ПС являются:

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

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

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

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

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

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

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

Потребителя-заказчика, прежде всего, интересуют функции, безопасность и качество готового конечного продукта — системы и программного средства, и обычно не очень беспокоит, как они достигнуты. Требуемую функциональную безопасность при разработке системы и ПС, как и любой продукции, можно обеспечить двумя методами [7], [10], [14]:

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

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

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

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

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

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

Поэтому высокая функциональная безопасность программных продуктов достигается и определяется преимущественно за счет технологий обеспечения качества на всех этапах жизненного цикла систем и ПС. Для этого в стандартах, регламентирующих функциональную безопасность систем и комплексов программ, значительное внимание уделяется технологическим процессам и инструментальным системам обеспечения безопасности и качества ЖЦ ПС [7], [8], [9]. В стандарте IEC 61508 третья и шестая части полностью посвящены требованиям и регламентированию процессов обеспечения функциональной безопасности встроенных комплексов программ аппаратно-программных систем. Жизненный цикл процессов обеспечения безопасности ПС структурирован схемой этапов и работ, компонентов и объектов, а также снабжен рекомендациями по выбору и реализации методов создания безопасных ПС. Третья часть стандарта ISO 15408 почти целиком посвящена детальным требованиям по обеспечению гарантий качества при создании и применении систем информационной безопасности комплексов. Совокупность этих требований отражает традиционные методы технологии поддержки жизненного цикла сложных ПС с акцентом на особенности реализации функций безопасности, которые применимы и для обеспечения функциональной безопасности. Технологии и типовые процессы создания безопасных систем и программных средств отражены также в стандартах ISO 13335 и IЕС 60880 . Таким образом, значительная часть требований стандартов, посвященных функциональной безопасности, акцентирована на технологических процессах создания безопасных систем и программных средств, однако без выделения и описания процессов измерения достигаемых при этом критериев безопасности программных продуктов.

содержание       назад       вперед