информационная безопасность. Лекции ИБ. Учебник для вузов В. Г. Олифер, Н. А. Олифер 2е изд. Спб. Питер 2009 669 с ил. Межсетевое экранирование учеб пособие О. Р. Лапонина М. Интернет Ун т Информ. Технологий бином. Лаб знаний 2007 343 с ил
 Скачать 0.82 Mb.
|
|
Общий риск = угроза х уязвимость х ценность актива Остаточный риск = (угроза х уязвимость х ценность актива) х недостаток контроля Необходимо учитывать, что только переоценивая риски на периодической основе можно обеспечить постоянную эффективность защитных мер и поддерживать уровень рисков информационной безопасности на приемлемом уровне. Если риск не изменился и защитные меры внедрены и хорошо работают, значит, риски снижены достаточно. Продолжение анализа уязвимостей и выявления, нуждающихся в защите активов также является важной задачей управления рисками. 5.12. Обработка риска Когда компания рассчитала величину общего и остаточного риска, она должна принять решение о дальнейших действиях. Существует 4 варианта действий, которые можно предпринять в отношении риска: перенести, избежать, уменьшить или принять риск. Если общий или остаточный риск слишком высок для компании, она может купить страховку, чтобы перенести риск на страховую компанию. Если компания решает прекратить деятельность, которая вызывает риск, это называется исключением риска. Например, компания может запретить использование сотрудниками программ передачи мгновенных сообщений (IM – Instant Messenger), вместо того, чтобы бороться с множеством рисков, связанных с этой технологией. Другим подходом является снижение риска до уровня, считающегося приемлемым для компании. Примером может быть внедрение межсетевого экрана, проведение обучения сотрудников и т. д. И последний подход заключается в осознанном принятии риска компанией, которая осознает его уровень, размеры потенциального ущерба, и, тем не менее, решает жить с этим риском и не внедрять контрмеры. Для компании целесообразно принять риск, когда анализ затрат / выгоды показывает, что расходы на контрмеры превышают размеры потенциальных потерь. Ключевым вопросом при принятии риска является понимание того, почему это является наилучшим выходом из конкретной ситуации. К сожалению, в наше время многие ответственные лица в компаниях принимают риски, не понимая в полной мере, что они принимают. Обычно это связано с относительной новизной процессов управления рисками в области безопасности, недостаточным уровнем образования и опытом работы этих людей. Когда руководителям бизнес-подразделений вменяются обязанности по борьбе с рисками в их подразделениях, чаще всего они принимают любые риски, т.к. их реальные 40 цели связаны с производством компанией готовой продукции и выводом ее на рынок, а вовсе не с рисками. Они не хотят увязать в этой глупой, непонятной и раздражающей безопасности... Принятие риска должно быть основано на нескольких факторах. В частности, нужно ответить на следующие вопросы. Потенциальные потери меньше стоимости контрмер? Сможет ли компания жить с теми потерями, которые причинит ей принятие этого риска? Второй вопрос имеет отношение, в том числе и к бесплатным решениям. Например, если компания примет этот риск, она должна будет добавить еще три шага в свой производственный процесс. Имеет ли это смысл для нее? В другом случае, принятие риска может привести к возрастанию количества инцидентов безопасности – готовы ли компания справиться с этим? Человек или группа, принимающая риск, должны понимать потенциальные последствия этого решения. Предположим, было установлено, что компания не нуждается в защите имен клиентов, но она должна защищать другие сведения, такие как номера социального страхования, номера счетов и т.д. При этом ее деятельность останется в рамках действующего законодательства. Но что будет, если ее клиенты узнают что компания не защищает должным образом их имена? Ведь они из-за отсутствия знаний по этому вопросу могут подумать, что это может стать причиной «кражи личности», что приведет к серьезному удару по репутации компании, с которым она может и не справиться. Восприятие клиентов часто не обосновано, и всегда существует вероятность, что они перенесут свой бизнес в другую компанию, и вам нужно считаться с этой потенциальной возможностью. Рис. 8 показывает, как может быть создана программа управления рисками, которая объединяет все понятия, описанные в настоящем разделе. 41 Рис. 8. - Вариант программы управления рисками 6. Персонал Многие обязанности персонала имеют прямое отношение к безопасности компании. Хотя общество стало чрезвычайно зависимым от технологий, люди остаются ключевым фактором успеха компании. В безопасности чаще всего именно человек является слабейшим звеном. Это является следствием человеческих ошибок, недостатков в обучении и приводит к мошенничеству, несанкционированным или небезопасным действиям. Человек во многих случаях является причиной успеха хакерских атак, шпионажа, повреждения оборудования. Хотя будущие действия людей нельзя предсказать, можно внедрить определенные превентивные меры, которые помогут минимизировать риски. Такими превентивными мерами могут быть следующие: прием на работу только квалифицированного персонала, контрольные мероприятия, детальные должностные инструкции, обучение персонала, строгий контроль доступа, обеспечение безопасности при увольнении сотрудников. 6.1. Структура Если компания хочет иметь эффективную безопасность на уровне персонала, руководство должно внедрить четкую структуру и следовать ей. Эта структура включает в себя четкое 42 описание обязанностей, разграничение полномочий, ответственность (например, объявление выговоров) за определенные действия. Четкая структура исключает непонимание, кто и что должен делать в различных ситуациях. Есть несколько аспектов, которые должны быть внедрены для снижения возможностей для мошенничества, саботажа, краж, неправильного использования информации, а также уменьшения вероятности возникновения других проблем безопасности. Одним из таких аспектов является разделение обязанностей (separation of duties), которое гарантирует, что один человек не сможет самостоятельно выполнить критичную задачу. Разделение обязанностей также снижает вероятность ошибок – если один человек ошибся, другой, скорее всего, увидит ее и исправит. Разделение обязанностей снижает риски мошенничества, так как сотрудник не может выполнить самостоятельно критичную операцию и ему необходимо вступить в сговор с другим сотрудником, а вероятность сговора двух и более людей существенно ниже вероятности действий отдельного человека. При разработке программного обеспечения должно быть явное разделение между средой разработки, средой тестирования, библиотекой программного обеспечения и производственной средой. Программистам должна быть доступна только среда разработки, в которой они могут разрабатывать программное обеспечение и производить его предварительное тестирование. После разработки исходные тексты передаются другому человеку, который проводит контроль качества кода и тестирование его работы в отдельной среде, являющейся копией производственной среды. Только когда код прошел все необходимые тесты, он размещается в библиотеке программного обеспечения. Для внедрения в производственную среду, программное обеспечение берется только из библиотеки. Код ни в коем случае не должен попадать напрямую от программиста в производственную среду без тестирования и сохранения в библиотеке! Тестовая среда должна быть полностью отделена от производственной, чтобы непроверенное еще программное обеспечение не нанесло вреда данным и системам, находящимся в реальной работе. Программист не должен «латать» свои программы непосредственно в процессе их эксплуатации! Должны быть внедрены простые и эффективные методы, не позволяющие вносить изменения в программное обеспечение компании небезопасными способами. 7. Выводы Программа безопасности должна учитывать вопросы со стратегической, тактической и оперативной точки зрения, как показано на рис. 9. Управление безопасностью включает в себя административные и процедурные мероприятия, необходимые для поддержки и защиты информации, а также активов в рамках компании в целом. Кроме того, управление безопасностью включает в себя разработку и внедрение политик безопасности и их вспомогательных механизмов: процедур, стандартов, базисов и руководств. Также, оно включает в себя управление рисками, обучение по вопросам безопасности, выбор и внедрение эффективных контрмер. Деятельность, связанная с персоналом (прием на работу, увольнение, обучение и структура управления) и его функциями (ротация и разделение обязанностей), должна проводиться надлежащим образом в целях создания безопасных условий. Руководство должно уважать и соблюдать необходимые правовые и этические нормы. Безопасность – это задача бизнеса, она должна рассматриваться именно в этом качестве. Она должна быть интегрирована в бизнес-цели и задачи компании, так как вопросы безопасности могут негативно сказаться на тех ресурсах, от которых зависит компания. Все большее и большее количество компаний, не уделявших должного внимания, поддержки и финансирования безопасности, несут колоссальные убытки. Хотя мы живем в прекрасном и удивительном мире, в нем может случиться всякое. Те, кто понимает это, могут не только выживать, но и процветать. 43 Рис. 9 – Компоненты программы безопасности. 44 8. Основы обеспечения информационной безопасности компьютерных систем. Программные и аппаратные механизмы защиты Многие механизмы защиты могут быть реализованы как на программном, так и на аппаратном уровне, однако более стойкими считаются аппаратные реализации. Это связано со следующими причинами: Целостность программной защиты легко нарушить, это дает возможность злоумышленнику изменить алгоритм функционирования защиты необходимым образом, например, заставить процедуру контроля электронно-цифровой подписи всегда выдавать верные результаты. Нарушить целостность аппаратных реализаций зачастую невозможно в принципе в силу технологии их производства. Стоимость аппаратных средств защиты во многом повышается благодаря сокрытию защитных механизмов на аппаратном уровне, злоумышленник при этом не может их исследовать в отличие от программной защиты. 9. Защита от изменения и контроль целостности программного обеспечения 9.1. Защита программного обеспечения от несанкционированного использования Включает в себя: 1. Организационно-правовые меры. 2. Правовые меры (распространение на программное обеспечение авторского права). 3. Технические меры. 9.2. Модульная архитектура технических средств защиты ПО от несанкционированного копирования Особенностью всех технических мер защиты является то, xто их реализация построена на выделении, либо принудительном введении каких – либо идентифицирующих элементов в среде функционирования программы, на которые настраивается система защиты. В качестве таких характеристик среды может быть использованы серийный номер, ключевой файл, информация в реестре, в конфигурации файлов, конфигурация аппаратуры, физический дефект носителей информации. Основные требования к системе защиты ПО от несанкционированного копирования: 1. такая система должна достоверно выявлять факт несанкционированного использования программы 2. реагировать на факт несанкционированного использования 3. противодействовать возможным атакам, направленным на нейтрализацию защитных механизмов 45 Рис. 10 – Структура системы защиты ПО Система защиты ПО от несанкционированного копирования работает по следующему алгоритму: 1. разработчик ПО разрабатывает и внедряет защитные механизмы в исполнительную программу 2. в эти защитные механизмы закладываются эталонные характеристики среды, которые идентифицируют конкретную копию программы и относительно которой будет проверяться легальность запуска 3. при каждом запуске программы выполняются следующие действия: снимают текущие характеристики среды, они сравниваются с эталонными. Если сравнение дало положительный результат, то запуск программы считается санкционированным. Программа запуска продолжает работать. Если сравнение дало отрицательный результат, то запускается блок ответной реакции. За установку текущих характеристик среды отвечает блок ответной реакции. Выход этого блока поступает на блок сравнения характеристик среды, который сравнивает текущие характеристики среды с эталонными. По способу внедрения защитного кода в защищаемую программу различают встроенную и пристыковочную защиты. Встроенные механизмы защиты основываются на том, что система как самостоятельный программный модуль отсутствует. Эти механизмы защиты внедряет сам разработчик в исходный текст программы, используя, например набор готовых API- функций защиты. Преимущества: 1. Простота. С помощью библиотек и функций, поставляется совместно с ПА средствами защиты, от ПА средства можно добиться максимальной эффективности 2. при реализации встроенной защиты, разработчик может запрограммировать любую ответную реакцию программы на несовпадение характеристик с эталонными, что в свою очередь позволяет более хорошо реализовать маркетинговые функции. Например, 46 при отсутствии электронного ключа, может запускать программу в демонстрационном режиме. 3. защита производится не по детерминированному алгоритму. Разработчик сам определяет, когда и каким образом будут вызываться API-функции с ПА устройствами защиты, как будут обрабатываться возвращаемые ими результаты. Недостаток: сложная реализация. Модуль противодействия нейтрализации защитных механизмов затрудняет анализ злоумышленником защитного кода, противодействует вмешательству в его работу и выполняется по 2 направлениям: 1) статическое 2) динамическое При статической нейтрализации злоумышленник дизассемблирует программу с помощью таких средств, как Ida Pro, по полученному коду, разбирается с работой механизмов, как их грамотно отключить. При динамической нейтрализации вмешательство в работу программы производится в момент работы в реальном времени с помощью существующих средств отладки, например, Soft Ice. Пристыковочные механизмы защиты внедряются непосредственно в исполнительный код, реализуется непосредственно некого автоматического обработчика исполнительных файлов. Эти обработчики заключают исполнительный код программы в некую защитную оболочку, которой при старте программы передается управление. При старте программы запускается защитная оболочка, реализующая все защитные функции, проверки, по результатам которых принимается решение о запуске/незапуске программы. Они поставляются в виде неких wizad-ов. При использовании подобных wizard-ов от пользователя требуется минимум действий, например, указать программу, требующую защиту и способ защиты. 9.3. Защита программного обеспечения от исследования Исследование исполняемого кода программы позволяет злоумышленнику разобраться с логикой работы защитных механизмов, что дает возможность отключить их либо обойти. При работе с аппаратными средствами защиты в исполняемом коде программы достаточно часто хранится конфиденциальная информация, например, коды доступа к электронному ключу, который не должен знать злоумышленник. Иначе говоря, возможность исследования кода является необходимым условием взлома программных продуктов. В связи с этим исполняемый код необходимо защищать от исследования. Для защиты ПО от исследования необходимо обеспечить защиту от статического и динамического анализа. В первом случае злоумышленник пытается получить листинг программы на каком- либо языке для возможности дальнейшего изучения и исследования логики защитных механизмов с использованием таких средств как Ida Pro, Soucer. Большая часть средств защиты от отладки основывается на обнаружении отладчиков в оперативной памяти с целью дальнейшего противодействия отладке, либо на включенных в исполняемый код механизмов, которые не могут быть корректно выполнены под отладкой в режиме трассировки. 9.4. Классификация средств атаки на средства защиты программного обеспечения 47 Программы-каталогизаторы Программы поиска данных и файлов Средства поиска и замены данных Программы копирования областей оперативной памяти на внешние устройства Средства эмуляции процессора Отладчики Декомпиляторы Средства дизассемблирования Программы-распаковщики и дешифраторы Мониторы активных окон и задач Мониторы портов ввода/вывода, сетевой активности Мониторы файловой системы Средства редактирования ресурсов Средства динамической модификации Симуляторы аппаратных средств Средства модификации контекстных процессов Средства криптоанализа Средства перехвата клавиатурного ввода Средства восстановления удаленных файлов Программы побайтового копирования дисков Эмуляторы ОС (виртуальные машины) Средства пакетной обработки команд Средства генерации паролей и ключей Программы-каталогизаторы – оболочки файловых систем, например, Far, Total Commander. С помощью данных средств возможно: - выполнить сравнение дат создания файлов в каталоге, в котором установлено приложение. Если средства защиты используют какие-то файлы для хранения, например, информации об оставшемся количестве запусков, то ее дата будет отличаться от остальных. Программы поиска файлов и текстовых последовательностей: HIEW, позволяющие искать в прикладных программах и файлах данных требуемые последовательности. Злоумышленник, таким образом, может локализовать участки кода, ответственные за выполнение функций по безопасности. Мониторы файловых операций (FileMon, RegMon, PortMon). Данные средства позволяют злоумышленнику проанализировать активность программы, «общение» программы с файлами, реестром, устройствами через порты ввода/вывода. 48 Мониторы вызова подпрограмм и системных функций (Spy++). С помощью данных средств можно определить, какие API-функции используются разработчиком для вызова решения определенных задач. Программы копирования областей оперативной памяти на внешние устройства (Advanced Memory Dumper). Средства декомпиляции (Cordon swf) представляют собой средства статического анализа исполняемого кода для изучения исходных текстов программ. Хорошо работают для Basic, Flash. Средства редактирования ресурсов (Passolo, Resource Hacker). Средства программы эмуляции аппаратных средств (Virtual CD). Средства эмуляции ЦП и ОС (VM Wave) 9.5. Сертификация программного обеспечения по уровню контроля отсутствия НДВ Программное обеспечение, системы защиты, которые работают с конфиденциальной информацией, либо с информацией, составляющей государственную тайну, должно пройти проверки на наличие в них НДВ. Под НДВ понимается функциональная возможность ПО, не описанная в документации, либо не соответствующая описанным в документации., которая может привести к нарушению конфиденциальности, целостности, доступности информации. Проверка ПО на наличие НДВ осуществляется согласно РД ФСТЭК 1998 г. «Защита от НСД. Часть 1. ПО средств защиты. Классификация по уровню контроля отсутствия НДВ». Согласно этому РД выделяется 4 уровня контроля, 1-высокий, 4 – низкий. 1 – системы, обрабатывающее информацию «Особой Важности» 2 - системы, обрабатывающее информацию «Совершенно Секретно» 3- системы, обрабатывающее информацию «Секретно» 4 - системы, обрабатывающее конфиденциальную информацию. № Наименование требования Уровень контроля 4 3 2 1 Требования к документации 1 Контроль состава и содержания документации 1.1 Спецификация (ГОСТ 19.202-78) + = = = 1.2 Описание программы (ГОСТ 19.402-78) + = = = 1.3 Описание применения (ГОСТ 19.502-78) + = = = 1.4 Пояснительная записка (ГОСТ 19.404-79) - + = = 1.5 Тексты программ, входящих в состав ПО (ГОСТ 19.401-78) + = = = Требования к содержанию испытаний 2 Контроль исходного состояния ПО + = = = 3 Статический анализ исходных текстов программ 3.1 Контроль полноты и отсутствия избыточности исходных текстов + + + = 3.2 Контроль соответствия исходных текстов ПО его объектному (загрузочному) коду + = = + 49 3.3 Контроль связей функциональных объектов по управлению - + = = 3.4 Контроль связей функциональных объектов по информации - + = = 3.5 Контроль информационных объектов - + = = 3.6 Контроль наличия заданных конструкций в исходных текстах - - + + 3.7 Формирование перечня маршрутов выполнения функциональных объектов - + + = 3.8 Анализ критических маршрутов выполнения функциональных объектов - - + = 3.9 Анализ алгоритма работы функциональных объектов на основе блок-схем, диаграмм и т.п., построенных по исходным текстам контролируемого ПО - - + = 4 Динамический анализ исходных текстов программ 4.1 Контроль выполнения функциональных объектов - + + = 4.2 Сопоставление фактических маршрутов выполнения функциональных объектов и маршрутов, построенных в процессе проведения статического анализа - + + = 5 Отчётность + + + + Для программного обеспечения импортного производства состав документации может отличаться от требуемого, однако содержание должно соответствовать требованиям, указанных в ГОСТ. Контроль состава документации проводится группой экспертов путем сравнения перечня представленных документов с требованиями руководящего документа для заявленного уровня контроля. При этом проверяется наличие обязательных (в соответствии с ГОСТ) разделов в представленных документах (полное соответствие ГОСТам не обязательно, однако, содержание должно им соответствовать. В частности, это имеет смысл для ПО импортного производства, где понятие ГОСТов не так осмысленно. Эти проверки не автоматизируются). Контроль содержания документации осуществляется, как по соответствию формальным требованиям ГОСТ к содержанию составных частей документов, так и по соответствию реальным возможностям программного обеспечения. На основании проведенного контроля делается вывод о соответствии документации требованиям руководящего документа и о возможности ее использования в процессе эксплуатации программного обеспечения. Контроль исходного состояния программного обеспечения. Контроль заключается в фиксации исходного состояния ПО и сравнении полученных результатов с приведёнными в документации. Результатами контроля исходного состояния ПО должны быть рассчитанные уникальные значения контрольных сумм загрузочных модулей и исходных текстов программ, входящих в состав ПО. Контрольные суммы должны рассчитываться для каждого файла, входящего в состав ПО. Проверенное программное обеспечение фиксируется – т.е. со всех модулей снимаются контрольные суммы. 50 Для представленных загрузочных модулей исходных текстов контрольное суммирование должно осуществляться с использованием программного обеспечения фиксации и контроля исходного состояния. Результаты контрольного суммирования оформляются в виде отчетов, являющихся приложением к протоколу испытаний. Статический анализ исходных текстов программ Статический анализ исходных текстов программ должен включать следующие технологические операции: контроль полноты и отсутствия избыточности исходных текстов ПО на уровне файлов; контроль соответствия исходных текстов ПО его объектному (загрузочному) коду. 1. Контроль полноты и отсутствия избыточности Полнота представленных исходных текстов ПО подтверждается фактом успешной компиляции и сборки исследуемого программного обеспечения с учетом результатов контроля соответствия исходных текстов загрузочному коду. Для проверки полноты специальных средств автоматизации не требуется – достаточно факта успешной компиляции. Для контроля избыточности исходных текстов на уровне файлов, с помощью анализатора исходных текстов определить список файлов, составляющих ПО и на основе анализа полученных исходных данных определить избыточные файлы, проанализировать их назначение и обоснованность включения в состав программного обеспечения. 2. Контроль соответствия исходных текстов программного обеспечения Контроль соответствия исходных текстов ПО его объектному (загрузочному) коду осуществляется методом создания загрузочных модулей из представленных исходных текстов ПО, и их сравнением полученных модулей с модулями, входящими в состав дистрибутива. Берутся предоставленные исходные тексты (*) и производится их контрольная сборка – т.е. они компилируется и полученные модули сравниваются по контрольным суммам с модулями зафиксированного ПО (см. пункт 2) В случае отсутствия исходных текстов используются два подхода: 1. С восстановлением исходных текстов: дизассемблирование; статический анализ; динамический анализ; с использованием отладчиков; с использованием датчиков (датчики встраиваются в исходный текст, из которого потом заново собирается программный продукт, который подвергается тестированию). При использовании данного подхода, возможно, потребуется итеративное дизассемблирование – с постепенными уточнениями. 2. Без восстановления исходных текстов – использование эмуляторов Для контрольной сборки, помимо собственно исходных файлов, желательно иметь и среду сборки (т.е. все компиляторы и компоновщики, которые использовал разработчик – иначе, при полностью самостоятельной сборке в лаборатории, расхождения по контрольным суммам почти гарантированно (т.е. собранные модули будут отличаться от модулей зафиксированного ПО). Наилучший вариант – когда контрольная сборка 51 производится либо на стенде разработчика (один или несколько компьютеров необходимых для cборки ПО, предоставляемые разработчиком и полностью готовые к сборке ПО), либо непосредственно у разработчика. Последовательность действий при выполнении трансляции исходных текстов, версия транслятора, а также исходные данные (директивы) для транслятора должны соответствовать приведённым в сопроводительной документации. Автоматизация здесь подразумевается на уровне командных файлов для сборки или автоматизации, предусмотренной в самих средствах сборки. 3.2.4. Отчётность По окончании испытаний оформляется отчёт (протокол), содержащий результаты: контроля исходного состояния программного обеспечения; контроля полноты и отсутствия избыточности исходных текстов контролируемого программного обеспечения на уровне файлов; контроля соответствия исходных текстов программного обеспечения его объектному (загрузочному) коду. 3.3. Требования к третьему уровню контроля 3.3.1. Контроль состава и содержания документации Требования полностью включают в себя аналогичные требования к четвертому уровню контроля. Кроме того, должна быть представлена «Пояснительная записка» (ГОСТ 19.404- 79), содержащая основные сведения о назначении компонентов, входящих в состав программного обеспечения, параметрах обрабатываемых наборов данных (подсхемах баз данных), формируемых кодах возврата, описание используемых переменных, алгоритмов функционирования и т.п. 3.3.2. Контроль исходного состояния программного обеспечения Требования полностью включают в себя аналогичные требования к четвёртому уровню контроля. 3.3.3. Статический анализ исходных текстов программ Кроме аналогичных требований, предъявляемых к четвёртому уровню контроля, дополнительно предъявляются следующие требования: контроль полноты и отсутствия избыточности исходных текстов ПО на уровне функциональных объектов (процедур); контроль связей функциональных объектов (модулей, процедур, функций) по управлению; контроль связей функциональных объектов (модулей, процедур, функций) по информации; контроль информационных объектов различных типов (например, локальных переменных, глобальных переменных, внешних переменных и т.п.); формирование перечня маршрутов выполнения функциональных объектов (процедур, функций). Перечень типовых дефектов программного обеспечения Рассмотрим перечень типовых дефектов программного обеспечения. 1. Неполная проверка параметров и разброса переменных; нестрогий контроль границ их изменений. 52 2. Скрытое использование приоритетных данных. 3. Асинхронное изменение интервала между временем проверки и временем использования. 4. Неправильное преобразование в последовательную форму. 5. Неправильные идентификация, верификация, аутентификация и санкционирование задач. 6. Отказ предотвращения перехода за установленные в программе пределы доступа и полномочий. 7. Логические ошибки (например, больше логических выражений или результатов, чем операций перехода). 8. Незавершённые разработка и описание. 9. Недокументированные передачи управления. 10. Обход контроля или неправильные точки контроля. 11. Неправильное присвоение имен, использование псевдонимов. 12. Неполная инкапсуляция или неполное скрытие описания реализации объекта. 13. Подменяемые контрольные журналы. 14. Передача управления в середине процесса. 15. Скрытые и недокументированные вызовы из прикладных программ, команд ОС и аппаратных команд. 16. Не устранение остаточных данных или отсутствие их адекватной защиты. 17. Неправильное освобождение ресурсов. 18. Игнорирование отключения внешних приборов. 19. Неполное прерывание выполнения программ. 20. Использование параметров ОС в прикладном пространстве памяти. 21. Не удаление средств отладки до начала эксплуатации. Формы проявления программных дефектов. (Вариант 1) 1. Выполнение арифметических операций и стандартных функций: деление на 0; переполнение разрядной сетки; отличие результатов арифметических операций от ожидаемых; обращение к стандартным функциям с недопустимыми значениями параметров. 2. Ошибки, связанные с затиранием команд и переменных. 3. Ошибки управления: зацикливание – бесконечное повторение одной и той же части программы; последовательность прохождения участков программы не соответствует ожидаемому; потеря управления, приводящая к ошибкам разного рода (обращение к запрещенной области памяти, попытка выполнить запрещенную программу или «не команду». 4. Ошибки ввода-вывода: «странный» вывод (на печать, на монитор и т.д.); сообщения об ошибках от системных программ ввода-вывода. (Вариант 2) 1. Ошибки, приводящие к прекращению выполнения основных или части функций управляющей системы на длительное и или неопределенное время: зацикливание, то есть последовательная повторяющаяся реализация определенной группы команд, не прекращающаяся без внешнего вмешательства; останов и прекращение решения функциональных задач; 53 значительное искажение или потеря накопленной информации о текущем состоянии управляемого процесса; прекращение или значительное снижение темпа решения некоторых задач вследствие перегрузки ЭВМ по пропускной способности; искажение процессов взаимного прерывания подпрограмм, приводящее к блокировке возможности некоторых типов прерываний. 2. Ошибки, кратковременно, но значительно искажающие отдельные результаты, выдаваемые управляющим алгоритмом: пропуск подпрограмм или их существенных частей; выход на подпрограммы или их части, резко искажающиеся результаты; обработка ложных или сильно искаженных сообщений. 3. Ошибки, мало и кратковременно влияющие на результаты, выдаваемые управляющим алгоритмом. Этот тип ошибок характерен, в основном, для квазинепрерывных величин, в которых возможны небольшие отклонения результатов за счёт ошибок. Эти ошибки в среднем мало искажают общие результаты, однако отдельные выбросы могут сильно влиять на процесс управления и требуется достаточно эффективная защита от таких редких значительных выбросов. Системные вопросы защиты программ и данных. 9.6. Защита сетей от программных закладок. Воздействие программных закладок на компьютеры. Закладкой (или программной закладкой) в информационной безопасности называют скрытно внедренную в защищенную систему программу, либо намеренно измененный фрагмент программы, которая позволяет злоумышленнику осуществить несанкционированный доступ к ресурсам системы на основе изменения свойств системы защиты. Часто программные закладки выполняют роль перехватчиков паролей, трафика, а также служат в качестве проводников для компьютерных вирусов. Программные закладки невозможно обнаружить при помощи стандартных антивирусных средств, их выявление возможно только специальными тестовыми программами. Данные программы доступны в специализированных компаниях, которые занимаются сертификацией и стандартизацией компьютерного программного обеспечения. Защита от программных закладок осуществляется в следующих вариантах: защита от внедрения закладки в систему; Защита от внедрения программных закладок в большинстве случаев осуществляется путем создания изолированного персонального компьютера, защищенного от проникновения программных закладок извне. Для того, чтобы считаться изолированным, компьютер должен удовлетворять следующим условиям: - BIOS не должен содержать программных закладок; - установленная операционная система должна быть проверена на наличие программных закладок; - должна быть установлена неизменность BIOS и операционной системы; - на персональном компьютере не должны были запускаться и не запускаются программы, которые не прошли проверку на наличие в них программных закладок; - должен быть исключен запуск проверенных программ вне персонального компьютера. выявление внедренной закладки; Выявление внедренных программных закладок осуществляется путем обнаружения признаков их присутствия в системе, которые делятся на: - качественные и визуальные; - обнаруживаемые средствами диагностики. 54 К качественным и визуальным относят признаки, которые могут быть идентифицированы пользователем во время работы с системой. Это могут быть как отклонения от привычной работы системы, так и изменения в пользовательских и системных файлах. Наличие данных признаков свидетельствует о необходимости проведения проверки на наличие программных закладок в системе. Признаки, обнаруживаемые средствами диагностики, идентифицируются специальным тестовым программным обеспечением, сигнализирующим о наличии вредоносного программного кода в системе. удаление внедренной закладки. Модели воздействия программных закладок на компьютеры: Метод удаления внедренных программных закладок зависит от метода их внедрения в систему. При обнаружении программно-аппаратной закладки необходимо перепрограммировать ПЗУ компьютера. При обнаружении загрузочной, драйверной, прикладной, замаскированной закладки или закладки-имитатора необходимо произвести их замену на соответствующее программное обеспечение от доверенных источников. При обнаружении исполняемой закладки следует убрать текст закладки из исходного текста программного модуля и откомпилировать модуль заново. |