Программного обеспечения
Логико-аналитические методы контроля безопасности
При проведении анализа безопасности с помощью логико-аналитических методов (см. рис. 65) строится модель программы и формально доказывается эквивалентность модели исследуемой программы и модели РПС. В простейшем случае в качестве модели программы может выступать ее битовый образ, в качестве моделей вирусов множество их сигнатур, а доказательство эквивалентности состоит в поиске сигнатур вирусов в программе. Более сложные методы используют формальные модели, основанные на совокупности признаков, свойственных той или иной группе РПС.
Рис. 65. Схема анализа программы логико-аналитическим методом
Формальная постановка задачи анализа безопасности логико-аналитическими методами может быть сформулирована следующим образом.
Выбирается некоторая система моделирования программ, представленная множеством моделей всех программ – Z. В выбранной системе исследуемая программа представляется своей моделью М, принадлежащей множеству Z. Должно быть задано множество моделей РПС V={vi|i=1,...,N}, полученное либо путем построения моделей всех известных РПС, либо путем порождения множества моделей всех возможных (в рамках данной модели) РПС. Множество V является подмножеством множества Z.
Кроме того, должно быть задано отношение эквивалентности определяющее наличие РПС в модели программы, обозначим его Е(x,y). Это отношение выражает тождественность программы x и РПС y, где x - модель программы, y – модель РПС, и y принадлежит множеству V.
Тогда задача анализа безопасности сводится к доказательству того, что модель исследуемой программы М принадлежит отношению E(M,v), где v принадлежит множеству V.
Для проведения логико-аналитического анализа безопасности программы необходимо:
1. Выбрать способ представления и получения моделей программы и РПС.
2. Построить модель исследуемой программы и попытаться доказать её принадлежность к отношению эквивалентности, задающему множество РПС.
На основании полученных результатов можно сделать заключение о степени безопасности программы.
Ключевыми понятиями здесь являются «способ представления» и «модель программы». Дело в том, что на компьютерную программу можно смотреть с очень многих точек зрения – это и алгоритм, который она реализует, и последовательность команд процессора, и файл, содержащий последовательность байтов и т.д. Все эти понятия образуют иерархию моделей компьютерных программ. Можно выбрать модель любого уровня модели и способ ее представления, необходимо только чтобы модель РПС и программы были заданы одним и тем же способом, с использованием понятий одного уровня. Другой серьезной проблемой является создание формальных моделей программ, или хотя бы определенных классов РПС. Механизм задания отношения между программой и РПС определяется способом представления модели. Наиболее перспективным здесь представляется использование семантических графов и объектно-ориентированных моделей.
В целом полный процесс анализа ПО включает в себя три вида анализа:
· лексический верификационный анализ;
· синтаксический верификационный анализ;
· семантический анализ программ.
Каждый из видов анализа представляет собой законченное исследование программ согласно своей специализации.
Результаты исследования могут иметь как самостоятельное значение, так и коррелировать с результатами полного процесса анализа.
Лексический верификационный анализ предполагает поиск распознавания и классификацию различных лексем объекта исследования (программа), представленного в исполняемых кодах. При этом лексемами являются сигнатуры. В данном случае осуществляется поиск сигнатур следующих классов:
· сигнатуры вирусов;
· сигнатуры элементов РПС;
· сигнатуры (лексемы) «подозрительных функций»;
· сигнатуры штатных процедур использования системных ресурсов и внешних устройств.
Поиск лексем (сигнатур) реализуется с помощью специальных программ-сканеров.
Синтаксический верификационный анализ предполагает поиск, распознавание и классификацию синтаксических структур РПС, а также построение структурно-алгоритмической модели самой программы.
Решение задач поиска и распознавания синтаксических структур РПС имеет самостоятельное значение для верификационного анализа программ, поскольку позволяет осуществлять поиск элементов РПС, не имеющих сигнатуры. Структурно-алгоритмическая модель программы необходима для реализации следующего вида анализа – семантического.
Семантический анализ предполагает исследование программы изучения смысла составляющих ее функций (процедур) в аспекте операционной среды компьютерной системы. В отличие от предыдущих видов анализа, основанных на статическом исследовании, семантический анализ нацелен на изучение динамики программы – её взаимодействия с окружающей средой. Процесс исследования осуществляется в виртуальной операционной среде с полным контролем действий программы и отслеживанием алгоритма ее работы по структурно-алгоритмической модели.
Семантический анализ является наиболее эффективным видом анализа, но и самым трудоемким. По этой причине методика сочетает в себе три перечисленных выше анализа. Выработанные критерии позволяют разумно сочетать различные виды анализа, существенно сокращая время исследования, не снижая его качества.
Руководящий документ «Защита от НСД. Часть 1. Программное обеспечение средств защиты. Классификация по уровню контроля отсутствия недекларированных возможностей»
Требования проверки ПО по защите от недекларированных возможностей (НДВ) представлены в РД «Защита от НСД. Часть 1. Программное обеспечение средств защиты. Классификация по уровню контроля отсутствия недекларированных возможностей».
Данный РД устанавливает классификацию ПО средств защиты информации (СЗИ) по уровню контроля отсутствия в нём недекларированных возможностей. Действие документа не распространяется на программное обеспечение средств криптографической защиты информации.
Устанавливается четыре уровня контроля отсутствия недекларированных возможностей. Каждый уровень характеризуется определенной минимальной совокупностью требований. Для ПО, используемого при защите информации, отнесенной к государственной тайне, должен быть обеспечен уровень контроля не ниже третьего. Самый высокий уровень контроля – первый, достаточен для программного обеспечения, используемого при защите информации с грифом «Особая важность». Второй уровень контроля достаточен для программного обеспечения, используемого при защите информации с грифом «Совершенно секретно». Третий уровень контроля достаточен для программного обеспечения, используемого при защите информации с грифом «Секретно». Самый низкий уровень контроля – четвёртый, достаточен для программного обеспечения, используемого при защите конфиденциальной информации.
Перечень требований к уровню контроля представлен в таблице 17.
Табл. 17. Требования к уровню контроля доступа
| № | Наименование требования | Уровень контроля | |||
| Требования к документации | |||||
| Контроль состава и содержания документации | |||||
| 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) | + | = | = | = |
| Требования к содержанию испытаний | |||||
| Контроль исходного состояния ПО | + | = | = | = | |
| Статический анализ исходных текстов программ | |||||
| 3.1 | Контроль полноты и отсутствия избыточности исходных текстов | + | + | + | = |
| 3.2 | Контроль соответствия исходных текстов ПО его объектному (загрузочному) коду | + | = | = | + |
| 3.3 | Контроль связей функциональных объектов по управлению | - | + | = | = |
| 3.4 | Контроль связей функциональных объектов по информации | - | + | = | = |
| 3.5 | Контроль информационных объектов | - | + | = | = |
| 3.6 | Контроль наличия заданных конструкций в исходных текстах | - | - | + | + |
| 3.7 | Формирование перечня маршрутов выполнения функциональных объектов | - | + | + | = |
| 3.8 | Анализ критических маршрутов выполнения функциональных объектов | - | - | + | = |
| 3.9 | Анализ алгоритма работы функциональных объектов на основе блок-схем, диаграмм и т.п., построенных по исходным текстам контролируемого ПО | - | - | + | = |
| Динамический анализ исходных текстов программ | |||||
| 4.1 | Контроль выполнения функциональных объектов | - | + | + | = |
| 4.2 | Сопоставление фактических маршрутов выполнения функциональных объектов и маршрутов, построенных в процессе проведения статического анализа | - | + | + | = |
| Отчётность | + | + | + | + |
Вопросы для самоконтроля
1. Охарактеризуйте средства анализа системы защиты ПО по данным. Как защититься от данных средств?
2. Охарактеризуйте средства анализа системы защиты ПО по алгоритмам. Как защититься от данных средств?
3. Охарактеризуйте средства преодоления систем защиты ПО. Как защититься от данных средств?
4. Охарактеризуйте средства обхода систем защиты ПО. Как защититься от данных средств?
5. Что понимают под опосредованным НСД?
6. Дайте определение программы с потенциально опасными последствиями. Какие функции свойственны данным программам?
7. Перечислите основные классы программ с потенциально опасными последствиями. Дайте их сравнительную характеристику.
8. Что понимают под активизирующим событием? Перечислите основные виды активизирующих событий для РПВ.
9. Перечислите и охарактеризуйте основные модели взаимодействия прикладной программы и РПВ.
10. Опишите основные группы деструктивных функций, свойственных программным закладкам.
11. Охарактеризуйте компьютерные вирусы как один из классов РПВ. Перечислите основные свойства компьютерного вируса.
12. Какие стадии и этапы включает в себя жизненный цикл компьютерного вируса?
13. Какие вирусы называют полиморфными?
14. Опишите средства борьбы с компьютерными вирусами.
15. Перечислите общие и специализированные методы борьбы с РПВ.
16. Что понимают под изолированной программной средой?
17. Укажите основные элементы поддержки ИПС.
18. Согласно какому РД выполняется тестирование ПО на наличие НДВ?
19. Сколько существует уровней контроля отсутствия НДВ?
20. Как осуществляется контроль исходного состояния программного обеспечения?
21. Какой уровень контроля необходим для ПО, обрабатывающего информацию «Особой Важности»?
22. Какой уровень контроля необходим для ПО, обрабатывающего информацию «Совершенно секретно»?
23. Какой уровень контроля необходим для ПО, обрабатывающего информацию «Секретно»?
24. Какой уровень контроля необходим для ПО, обрабатывающего конфиденциальную информацию?
25. На каком из уровней контроля осуществляется больше проверок – первом или четвертом?