Рисунок 1. Модель анализа безопасности информационных систем при отсутствии злоумышленных угроз.
При любом виде деятельности людям свойственно непредумышленно ошибаться, результаты чего проявляются в процессе создания или применения изделий или систем. В общем случае под ошибкой подразумевается дефект, погрешность или неумышленное искажение объекта или процесса. При этом предполагается, что известно правильное, эталонное состояние объекта, по отношению к которому может быть определено наличие отклонения — ошибки. При любых фиксированных исходных данных программы исполняются по определенным маршрутам и выдают совершенно определенные результаты, однако многочисленные варианты исполнения программ при разнообразных исходных данных представляются для внешнего наблюдателя как случайные. В связи с этим дефекты функционирования информационных систем, не имеющие злоумышленных источников, проявляются внешне как случайные, имеют разную природу и последствия. В частности, они могут приводить к катастрофическим последствиям, соответствующим нарушению безопасности использования ИС.
Последующий анализ безопасности ИС при отсутствии злоумышленных дестабилизирующих факторов базируется на модели взаимодействия основных компонент, представленных на Рис. 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] при взаимодействии между как закупаемыми, так и вновь разрабатываемыми компонентами ИС, а также при их взаимодействии с внешней средой.
Таким образом, для обеспечения безопасности функционирования зарубежных ПС и БД в отечественных ИС прежде всего следует полностью отказаться от применения нелегальных импортных программ и баз данных. Процессы закупки, контроля и применения импортных ПС и БД для отечественных крититических ИС должны быть организованы и поддержаны дополнительными испытаниями. Использование лицензионно чистых ПС и БД и тесное взаимодействие с зарубежными фирмами-поставщиками позволяет эффективно продолжать тестирование изделий при их комплексировании в отечественных ИС, оценивать и повышать безопасность применения.
Четкое экономическое и юридическое взаимодействие с определенными фирмами-поставщиками ПС и БД позволяет держать под контролем не только алгоритмическую и программно-технологическую безопасность ИС, но и значительно снижает вероятность злоумышленных аномалий в поставляемых ими изделиях. Так как каждая фирма дорожит своей репутацией, обнаружение и публикация сведений о предумышленных негативных компонентах в их изделиях способны нанести значительный ущерб репутации и бизнесу этой фирмы.
|
|
|
| Программно-технологическая безопасность информационных систем | Содержание | Определение реальной технологической безопасности информационных систем |
| Copyright ╘ 1993-2000, Jet Infosystems |
