Программно-аппаратная защита информации

 

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

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

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

   Для защиты от вирусов наиболее часто  применяют антивирусные мониторы, сканнеры, ПА средства, не допускающие заражение вирусами объектов операционной среды, не допускающие проникновение в КС.

   Наиболее  часто используемые пути проникновения  вируса в КС:

1. носитель информации с зараженным объектом;
2. электронная почта;
3. компьютерная сеть.

Методы  борьбы с РПВ

1. Контроль целостности, системных событий, прикладных программ, используемых данных
2. Контроль цепочек прерываний и фильтрация вызовов, критических для безопасности систем прерываний
3. Создание изолированной программной среды
4. Предотвращение результатов воздействия РПВ, например, аппаратная блокировка записи на диск
5. Поиск РПВ по свойственным им или характерным последовательностям – сигнатурам

Сигнатура – уникальная последовательность кода, свойственная вирусу, её присутствие  в исполняемом коде говорит об однозначном присутствии РПВ. Можно поступить по-другому: разрешить запускать системе только те модули, которые имеют известную сигнатуру.

6. Поиск критических участков кода, путем его синтаксического анализа, выявление синтаксических характерных конструкций с точки зрения РПВ, например, вирусов.
7. Тестирование программ и компьютерной техники на испытательных стендах, в испытательных лабораториях, идентификация условий, возникающих в ПА среде, при которых она начинает вести себя некорректно.
8. Метод Мельсона – тестирование всех путей переходов программе.

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

Изолированная программная среда

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

   ИПС характеризуется выполнением следующих  условий:

1. на ЭВМ с проверенным BIOS-ом установлена проверенная ОС;
2. достоверно установлена неизменность ОС и BIOSа для текущего сеанса работы пользователя;

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

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

   Идентификацию и аутентификацию пользователя желательно также выполнять на аппаратном блоке.

ИПС при запуске программы пользователя одновременно выполняет проверку условий:

• их принадлежность к списку разрешенных для записи
• их целостность

 
 

Лекция  № 11

Сертификация  программного обеспечения  по уровню контроля отсутствия НДВ

 

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

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

     Проверка  ПО на наличие НДВ осуществляется согласно РД ФСТЭК 1998 г. «Защита от НСД. Часть 1. ПО средств защиты. Классификация по уровню контроля отсутствия НДВ». Согласно этому РД выделяется 4 уровня контроля, 1-высокий, 4 – низкий.

1 –  системы, обрабатывающее информацию  «Особой Важности»

2 -  системы,  обрабатывающее информацию «Совершенно  Секретно»

3- системы, обрабатывающее информацию «Секретно»

4 - системы,  обрабатывающее конфиденциальную  информацию

 

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

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

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

     На  основании проведенного контроля делается вывод о соответствии документации требованиям руководящего документа и о возможности ее использования в процессе эксплуатации программного обеспечения.

     Контроль  исходного состояния  программного обеспечения.

     Контроль  заключается в фиксации исходного состояния ПО и сравнении полученных результатов с приведёнными в документации.

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

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

     Проверенное программное обеспечение фиксируется  – т.е. со всех модулей снимаются контрольные суммы.

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

Лекция  № 12 

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

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

• контроль полноты и отсутствия избыточности исходных текстов ПО на уровне файлов;
• контроль соответствия исходных текстов ПО его объектному (загрузочному) коду.

     1. Контроль полноты и отсутствия  избыточности

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

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

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

     2. Контроль соответствия исходных текстов программного обеспечения

     Контроль  соответствия исходных текстов ПО его  объектному (загрузочному) коду осуществляется методом создания загрузочных модулей из представленных исходных текстов ПО, и их сравнением полученных модулей с модулями, входящими в состав дистрибутива.

     Берутся предоставленные исходные тексты (*) и производится их контрольная сборка – т.е. они компилируется и полученные модули сравниваются по контрольным суммам с модулями зафиксированного ПО (см. пункт 2)

     В случае отсутствия исходных текстов используются два подхода:

     1. С восстановлением исходных текстов:

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

     При использовании данного подхода, возможно, потребуется итеративное  дизассемблирование – с постепенными уточнениями.

     2. Без восстановления исходных  текстов – использование эмуляторов