Руководящий документ

Защита от несанкционированного доступа к информации Часть 1. Программное обеспечение средств защиты информации

Утверждено решением председателя Государственной технической комиссии при Президенте Российской Федерации от 4 июня 1999 г. N 114

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

Действие документа не распространяется на программное обеспечение средств криптографической защиты информации.

Уровень контроля определяется выполнением заданного настоящим РД набора требований, предъявляемого:
— к составу и содержанию документации, представляемой заявителем для проведения испытаний ПО СЗИ;
— к содержанию испытаний.

Руководящий документ разработан в дополнение:
— РД «Средства вычислительной техники. Защита от несанкционированного доступа к информации. Показатели защищенности от несанкционированного доступа к информации», М., Военное издательство, 1992 г.;
— РД «Автоматизированные системы. Защита от несанкционированного доступа к информации. Классификация автоматизированных систем и требования по защите информации», М., Военное издательство, 1992 г.;
— РД «Средства вычислительной техники. Межсетевые экраны. Защита от несанкционированного доступа к информации. Показатели защищенности от несанкционированного доступа к информации», М., 1997 г.

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

1. ОБЩИЕ ПОЛОЖЕНИЯ

1.1. Классификация распространяется на ПО, предназначенное для защиты информации ограниченного доступа.

1.2. Устанавливается четыре уровня контроля отсутствия недекларированных возможностей. Каждый уровень характеризуется определенной минимальной совокупностью требований.

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

1.4. Самый высокий уровень контроля — первый, достаточен для ПО, используемого при защите информации с грифом «ОВ».

Второй уровень контроля достаточен для ПО, используемого при защите информации с грифом «CC».

Третий уровень контроля достаточен для ПО, используемого при защите информации с грифом «C».

1.5 Самый низкий уровень контроля — четвертый, достаточен для ПО, используемого при защите конфиденциальной информации.

2. ТЕРМИНЫ И ОПРЕДЕЛЕНИЯ

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

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

2.2. Программные закладки – преднамеренно внесенные в ПО функциональные объекты, которые при определенных условиях (входных данных) инициируют выполнение не описанных в документации функций ПО, приводящих к нарушению конфиденциальности, доступности или целостности обрабатываемой информации.

2.3. Функциональный объект – элемент программы, осуществляющий выполнение действий по реализации законченного фрагмента алгоритма программы.

В качестве функциональных объектов могут выступать процедуры, функции, ветви, операторы и т.п.

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

2.5. Маршрут выполнения функциональных объектов – определенная алгоритмом последовательность выполняемых функциональных объектов.

2.6. Фактический маршрут выполнения функциональных объектов – последовательность фактически выполняемых функциональных объектов при определённых условиях (входных данных).

2.7. Критический маршрут выполнения функциональных объектов – такой маршрут, при выполнении которого существует возможность неконтролируемого нарушения установленных правил обработки информационных объектов.

2.8. Статический анализ исходных текстов программ – совокупность методов контроля (не)соответствия реализованных и декларированных в документации функциональных возможностей ПО, основанных на структурном анализе и декомпозиции исходных текстов программ.

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

3. ТРЕБОВАНИЯ К УРОВНЮ КОНТРОЛЯ
3.1. ПЕРЕЧЕНЬ ТРЕБОВАНИЙ

Таблица 1

3.2. ТРЕБОВАНИЯ К ЧЕТВЕРТОМУ УРОВНЮ КОНТРОЛЯ

3.2.1.Контроль состава и содержания документации

В состав документации, представляемой заявителем, должны входить:

Спецификация (ГОСТ 19.202-78), содержащая сведения о составе ПО и документации на него;

Описание программы (ГОСТ 19.402-78), содержащее основные сведения о составе (с указанием контрольных сумм файлов, входящих в состав ПО), логической структуре и среде функционирования ПО, а также описание методов, приемов и правил эксплуатации средств технологического оснащения при создании ПО;

Описание применения (ГОСТ 19.502-78), содержащее сведения о назначении ПО, области применения, применяемых методах, классе решаемых задач, ограничениях при применении, минимальной конфигурации технических средств, среде функционирования и порядке работы.

Исходные тексты программ (ГОСТ 19.401-78), входящих в состав ПО.

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

3.2.2. Контроль исходного состояния ПО

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

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

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

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

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

3.2.4. Отчетность

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

3.3.ТРЕБОВАНИЯ К ТРЕТЬЕМУ УРОВНЮ КОНТРОЛЯ

3.3.1.Контроль состава и содержания документации

Требования полностью включают в себя аналогичные требования к четвертому уровню контроля.

Кроме того, должна быть представлена «Пояснительная записка» (ГОСТ 19.404-79), содержащая основные сведения о назначении компонентов, входящих в состав ПО, параметрах обрабатываемых наборов данных (подсхемах баз данных), формируемых кодах возврата, описание используемых переменных, алгоритмов функционирования и т.п.

3.3.2.Контроль исходного состояния ПО

Требования полностью включают в себя аналогичные требования к четвёртому уровню контроля.

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

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

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

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

3.3.5. Отчетность

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

3.4. ТРЕБОВАНИЯ КО ВТОРОМУ УРОВНЮ КОНТРОЛЯ

3.4.1.Контроль состава и содержания документации

Требования полностью включают в себя аналогичные требования к третьему уровню контроля.

3.4.2.Контроль исходного состояния ПО

Требования полностью включают в себя аналогичные требования к третьему уровню контроля.

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

Кроме аналогичных требований, предъявляемых к третьему уровню контроля, дополнительно предъявляются следующие требования:
— контроль полноты и отсутствия избыточности исходных текстов контролируемого программного обеспечения на уровне функциональных объектов (функций);
— синтаксический контроль наличия заданных конструкций в исходных текстах ПО из списка (базы) потенциально опасных программных конструкций;
— формирование перечня маршрутов выполнения функциональных объектов (ветвей);
— анализ критических маршрутов выполнения функциональных объектов (процедур, функций) для заданных экспертом списков информационных объектов;
— построение по исходным текстам контролируемого ПО блок-схем, диаграмм и т.п., и последующий сравнительный анализ алгоритма работы функциональных объектов (процедур, функций) и алгоритма работы, приведенного в «Пояснительной записке”.

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

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

3.4.5 Отчетность

Кроме аналогичных требований, предъявляемых к третьему уровню контроля, дополнительно отчет (протокол) должен содержать результаты:
— контроля полноты и отсутствия избыточности исходных текстов контролируемого программного обеспечения на уровне функциональных объектов (функций);
— синтаксического контроля наличия заданных конструкций в исходных текстах ПО из списка (базы) потенциально опасных конструкций;
— формирования перечня маршрутов выполнения функциональных объектов (ветвей);
— анализа критических маршрутов выполнения функциональных объектов (процедур, функций) для заданных экспертом списков информационных объектов;
— построения по исходным текстам контролируемого ПО блок-схем, диаграмм и т.п., и последующего сравнительного анализа алгоритма работы функциональных объектов (процедур, функций) и алгоритма работы, приведённого в «Пояснительной записке”;
— контроля выполнения функциональных объектов (ветвей);
— сопоставления фактических маршрутов выполнения функциональных объектов (ветвей) и маршрутов, построенных в процессе проведения статического анализа.

3.5. ТРЕБОВАНИЯ К ПЕРВОМУ УРОВНЮ КОНТРОЛЯ

3.5.1. Контроль состава и содержания документации

Требования полностью включают в себя аналогичные требования ко второму уровню контроля.

3.5.2. Контроль исходного состояния ПО

Требования полностью включают в себя аналогичные требования ко второму уровню контроля.

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

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

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

Требования полностью включают в себя аналогичные требования ко второму уровню контроля.

3.5.5. Отчетность

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

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

ГОСУДАРСТВЕННАЯ ТЕХНИЧЕСКАЯ КОМИССИЯ
ПРИ ПРЕЗИДЕНТЕ РОССИЙСКОЙ ФЕДЕРАЦИИ

УТВЕРЖДЕНО
решением председателя
Государственной технической комиссии
при Президенте Российской Федерации
от 30 марта 1992 года

РУКОВОДЯЩИЙ ДОКУМЕНТ

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

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

Принятые сокращения

АC — автоматизированная система
КД — конструкторская документация
КСЗ — комплекс средств защиты
НСД — несанкционированный доступ
ПРД — правила разграничения доступа
СВТ — средства вычислительной техники

1.1. Данные показатели содержат требования защищенности СВТ от НСД к информации.

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

1.3. Требования к показателям реализуются с помощью программно-технических средств.
Совокупность всех средств защиты составляет комплекс средств защиты.
Документация КСЗ должна быть неотъемлемой частью конструкторской документации на СВТ.

1.4. Устанавливается семь классов защищенности СВТ от НСД к информации. Самый низкий класс — седьмой, самый высокий — первый.
Классы подразделяются на четыре группы, отличающиеся качественным уровнем защиты:
первая группа содержит только один седьмой класс;
вторая группа характеризуется дискреционной защитой и содержит шестой и пятый классы;
третья группа характеризуется мандатной защитой и содержит четвертый, третий и второй классы;
четвертая группа характеризуется верифицированной защитой и содержит только первый класс.

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

1.6. Применение в комплекте СВТ средств криптографической защиты информации по ГОСТ 28147-89 может быть использовано для повышения гарантий качества защиты.

Требования к показателям защищенности

2.1. Показатели защищенности.

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

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

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

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

Системы первого типа наиболее удобны для производителя ПО, так как легко можно защитить уже полностью готовое и оттестированное ПО (обычно процесс установки защиты максимально автоматизирован и сводится к указанию имени защищаемого файла и нажатию «Enter»), а потому и наиболее популярны. В то же время стойкость этих систем достаточно низка (в зависимости от принципа действия СЗ), так как для обхода защиты достаточно определить точку завершения работы «конверта» защиты и передачи управления защищенной программе, а затем принудительно ее сохранить в незащищенном виде.
Системы второго типа неудобны для производителя ПО, так как возникает необходимость обучать персонал работе с программным интерфейсом (API) системы защиты с вытекающими отсюда денежными и временными затратами. Кроме того, усложняется процесс тестирования ПО и снижается его надежность, так как кроме самого ПО ошибки может содержать API системы защиты или процедуры, его использующие. Но такие системы являются более стойкими к атакам, потому что здесь исчезает четкая граница между системой защиты и как таковым ПО.
Наиболее живучими являются комбинированные системы защиты. Сохраняя достоинства и недостатки систем второго типа, они максимально затрудняют анализ и дезактивацию своих алгоритмов.

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

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

Для защиты ПО используется ряд методов, таких как:

1. Алгоритмы запутывания — используются хаотические переходы в разные части кода, внедрение ложных процедур — «пустышек», холостые циклы, искажение количества реальных параметров процедур ПО, разброс участков кода по разным областям ОЗУ и т.п.
2. Алгоритмы мутации — создаются таблицы соответствия операндов — синонимов и замена их друг на друга при каждом запуске программы по определенной схеме или случайным образом, случайные изменения структуры программы.
3. Алгоритмы компрессии данных — программа упаковывается, а затем распаковывается по мере выполнения.
4. Алгоритмы шифрования данных — программа шифруется, а затем расшифровывается по мере выполнения.
5. Вычисление сложных математических выражений в процессе отработки механизма защиты — элементы логики защиты зависят от результата вычисления значения какой-либо формулы или группы формул.
6. Методы затруднения дизассемблирования — используются различные приемы, направленные на предотвращение дизассемблирования в пакетном режиме.
7. Методы затруднения отладки — используются различные приемы, направленные на усложнение отладки программы.
8. Эмуляция процессоров и операционных систем — создается виртуальный процессор и/или операционная система (не обязательно реально существующие) и программа-переводчик из системы команд IBM в систему команд созданного процессора или ОС, после такого перевода ПО может выполняться только при помощи эмулятора, что резко затрудняет исследование алгоритма ПО.
9. Нестандартные методы работы с аппаратным обеспечением — модули системы защиты обращаются к аппаратуре ЭВМ, минуя процедуры операционной системы, и используют малоизвестные или недокументированные её возможности.

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

По принципу функционирования СЗ можно подразделить на упаковщики/шифраторы; СЗ от несанкционированного копирования и СЗ от несанкционированного доступа (НСД).

Упаковщики/шифраторы

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

Положительные стороны:

1. В рамках периода безопасного использования данные системы обеспечивают высокий уровень защиты ПО от анализа его алгоритмов.
2. Методы упаковки/шифрации намного увеличивают стойкость систем защиты других типов.

Отрицательные стороны:

1. Практически все применяемые методы замедляют выполнение кода ПО.
2. Шифрование/упаковка кода ПО вызывает затруднения при обновлении (update) и исправлении ошибок (bugfix, servicepack).
3. Возможно повышение аппаратно-программных требований ПО.
4. В чистом виде данные системы не применимы для авторизации использования ПО.
5. Эти системы применимы лишь к продуктам небольшого объема (до 1 мегабайта).
6. Данный класс систем уязвим, так как программный код, в конечном итоге, распаковывается или расшифровывается для выполнения.
7. Обладают небольшим сроком безопасного использования, ввиду п.4
8. Упаковка и шифрование исполняемого кода вступает в конфликт с запрещением самомодифицирующегося кода в современных ОС.

СЗ от несанкционированного копирования

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

Положительные факторы:

1. Затруднение нелегального копирования и распространения ПО;
2. Защита прав пользователя на приобретённое ПО.

Отрицательные факторы:

1. Большая трудоёмкость реализации системы защиты;
2. Замедление продаж из-за необходимости физической передачи дистрибутивного носителя информации;
3. Повышение системных требований из-за защиты (наличие накопителя);
4. Снижение отказоустойчивости ПО;
5. Несовместимость защиты и аппаратуры пользователя (накопитель, контроллер);
6. На время работы ПО занимается накопитель;
7. Угроза кражи защищённого носителя;

СЗ от НСД

СЗ от НСД осуществляют предварительную или периодическую аутентификацию пользователя ПО или его компьютерной системы путём запроса дополнительной информации. К этому типу СЗ можно отнести системы парольной защиты ПО, системы «привязки» ПО к компьютеру пользователя, системы с » ключевыми дисками» и аппаратно-программные системы с электронными ключами. В первом случае «ключевую» информацию вводит пользователь, во втором — она содержится в уникальных параметрах компьютерной системы пользователя, в третьем — она хранится на диске и в четвертом случае «ключевая» информация считывается с микросхем электронного ключа.

Парольные защиты

Этот класс СЗПО, на сегодняшний день, является самым распространённым. Основной принцип работы данных систем заключается в идентификации и аутентификации пользователя ПО путём запроса дополнительных данных, это могут быть название фирмы и/или имя и фамилия пользователя и его пароль либо только пароль/регистрационный код. Эта информация может запрашиваться в различных ситуациях, например, при старте программы, по истечении срока бесплатного использования ПО, при вызове процедуры регистрации либо в процессе установки на ПК пользователя. Процедуры парольной защиты просты в реализации и, поэтому, очень часто применяются производителями ПО. Большинство парольных СЗПО использует логические механизмы, сводящиеся к проверке правильности пароля/кода и запуске или не запуске ПО, в зависимости от результатов проверки. Существуют так же системы, шифрующие защищаемое ПО и использующие пароль или производную от него величину как ключ дешифрации, большинство таких систем использует слабые или простейшие алгоритмы шифрования, нестойкие к направленным атакам. Это происходит из-за сложности корректной реализации стойких криптоалгоритмов и нецелесообразности их применения для защиты недорогих условно-бесплатных программных продуктов, составляющих большинство ПО, использующего парольные защиты. Лишь в последнее время разработаны парольные СЗПО, реализующие стойкие криптоалгоритмы типа DES и RSA, они реализованы в виде защитного модуля и вспомогательных библиотек и устанавливаются на уже скомпилированные модули ПО.

Слабым звеном парольных защит является блок проверки правильности введённого пароля/кода. Для такой проверки можно сравнивать введённый пароль с записанным в коде ПО правильным либо с правильно сгенерированным из введённых дополнительных данных паролем. Возможно так же сравнение производных величин от введённого и правильного паролей, например их ХЭШ-функций, в таком случае в коде можно сохранять только производную величину, что повышает стойкость защиты. Путём анализа процедур проверки можно найти реальный пароль, записанный в коде ПО, найти правильно сгенерированный пароль из введённых данных либо создать программу для перебора паролей для определения пароля с нужной ХЭШ-суммой. Кроме того, если СЗПО не использует шифрования, достаточно лишь принудительно изменить логику проверки для получения беспрепятственного доступа к ПО.
Шифрующие системы более стойки к атакам, но при использовании простейших или некорректно реализованных криптоалгоритмов есть опасность дешифрации ПО.

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

Положительные стороны:

1. Надёжная защита от злоумышленника-непрофессионала.
2. Минимальные неудобства для пользователя.
3. Возможность передачи пароля/кода по сети.
4. Отсутствие конфликтов с системным и прикладным ПО и аппаратным обеспечением.
5. Простота реализации и применения.
6. Низкая стоимость.

Отрицательные стороны:

1. Низкая стойкость большинства систем защиты данного типа.
2. Пользователю необходимо запоминать пароль/код.

Системы «привязки» ПО

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

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

Положительные факторы:

1. Не требуется добавочных аппаратных средств для работы защиты.
2. Затруднение несанкционированного доступа к скопированному ПО.
3. Простота применения.
4. «Невидимость» СЗПО для пользователя.

Отрицательные факторы:

1. Ложные срабатывания СЗПО при любых изменениях в параметрах ПК.
2. Низкая стойкость при доступе злоумышленника к ПК пользователя.
3. Возможность конфликтов с системным ПО.

Программно-аппаратные средства защиты ПО с электронными ключами

Этот класс СЗПО в последнее время приобретает все большую популярность среди производителей программного обеспечения (ПО). Под программно-аппаратными средствами защиты, в данном случае, понимаются средства, основанные на использовании так называемых «аппаратных (электронных) ключей». Электронный ключ — это аппаратная часть системы защиты, представляющая собой плату с микросхемами памяти и, в некоторых случаях, микропроцессором, помещенную в корпус и предназначенную для установки в один из стандартных портов ПК (COMM, LPT, PCMCIA, USB … ) или слот расширения материнской платы. Так же в качестве такого устройства могут использоваться СМАРТ-карты. По результатам проведенного анализа, программно-аппаратные средства защиты в настоящий момент являются одними из самых стойких систем защиты ПО от НСД.

Электронные ключи по архитектуре можно подразделить на ключи с памятью (без микропроцессора) и ключи с микропроцессором (и памятью).

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

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

Положительные факторы:

1. Значительное затруднение нелегального распространения и использования ПО;
2. Избавление производителя ПО от разработки собственной системы защиты;
3. Высокая автоматизация процесса защиты ПО;
4. Наличие API системы для более глубокой защиты;
5. Возможность легкого создания демо-версий;
6. Достаточно большой выбор таких систем на рынке;

Отрицательные факторы:

1. Затруднение разработки и отладки ПО из-за ограничений со стороны СЗ;
2. Дополнительные затраты на приобретение системы защиты и обучение персонала;
3. Замедление продаж из-за необходимости физической передачи аппаратной части;
4. Повышение системных требований из-за защиты (совместимость, драйверы);
5. Снижение отказоустойчивости ПО;
6. Несовместимость систем защиты и системного или прикладного ПО пользователя;
7. Несовместимость защиты и аппаратуры пользователя;
8. Ограничения из-за несовместимости электронных ключей различных фирм;
9. Снижение расширяемости компьютерной системы;
10. Затруднения или невозможность использования защищенного ПО в переносных и блокнотных ПК;
11. Наличие у аппаратной части размеров и веса (для COMM/LPT = 5х3х2см ~ 50гр);
12. Угроза кражи аппаратного ключа

Средства защиты ПО с «ключевыми дисками»

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

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

Положительные и отрицательные стороны данного типа СЗПО практически полностью совпадают с таковыми у систем с электронными ключами:

Положительные факторы:

1. Значительное затруднение нелегального распространения и использования ПО;
2. Избавление производителя ПО от разработки собственной системы защиты;
3. Высокая автоматизация процесса защиты ПО;
4. Возможность легкого создания демо-версий;

Отрицательные факторы:

1. Затруднение разработки и отладки ПО из-за ограничений со стороны СЗ;
2. Дополнительные затраты на приобретение системы защиты и обучение персонала;
3. Замедление продаж из-за необходимости физической передачи носителя;
4. Повышение системных требований из-за защиты;
5. Снижение отказоустойчивости ПО;
6. Несовместимость систем защиты и системного или прикладного ПО пользователя;
7. Несовместимость защиты и аппаратуры пользователя;
8. Снижение расширяемости компьютерной системы;
9. Затруднения или невозможность использования защищенного ПО в переносных и блокнотных ПК;
10. Угроза кражи ключевого носителя

Необходимо отметить, что пользователем явно ощущаются лишь отрицательные стороны систем защит. А производители ПО рассматривают только относящиеся к ним «плюсы» и «минусы» систем защиты и практически не рассматривают факторы, относящиеся к конечному потребителю.

По результатам исследования был разработан набор показателей применимости и критериев оценки СЗПО.

Показатели применимости:

Технические

Соответствие СЗПО функциональным требованиям производителя ПО и требованиям по стойкости, системные требования ПО и системные требования СЗПО, объём ПО и объём СЗПО, функциональная направленность ПО, наличие и тип СЗ у аналогов ПО — конкурентов.

Экономические

Соотношение потерь от пиратства и общего объёма прибыли, соотношение потерь от пиратства и стоимости СЗПО и её внедрения, соотношение стоимости ПО и стоимости СЗПО, соответствие стоимости СЗПО и её внедрения поставленным целям.

Организационные

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

Критерии оценки:

Защита как таковая

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

Стойкость к исследованию/взлому

Применение стандартных механизмов, новые/нестандартные механизмы

Отказоустойчивость (надёжность)

Вероятность отказа защиты (НСД), время наработки на отказ, вероятность отказа программы защиты (крах), время наработки на отказ, частота ложных срабатываний.

Независимость от конкретных реализаций ОС

Использование недокументированных возможностей, «вирусных» технологий и «дыр» ОС

Совместимость

Отсутствие конфликтов с системным ПО, отсутствие конфликтов с прикладным ПО, отсутствие конфликтов с существующим АО, максимальная совместимость с будущим АО и ПО.

Неудобства для конечного пользователя ПО

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

Побочные эффекты

Перегрузка траффика, отказ в обслуживании, замедление работы защищаемого ПО, замедление работы ОС, захват системных ресурсов, перегрузка ОЗУ, нарушение стабильности ОС.

Стоимость

Стоимость/эффективность, стоимость/цена защищаемого ПО, стоимость/ликвидированные убытки.

Доброкачественность

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

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

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

Использованная литература:

• О сайте • Моя RSS-Лента • Карта сайта • 1. ЧЕЛОВЕК И СРЕДА ОБИТАНИЯ • 1. 1. ПЕРВАЯ МЕДИЦИНСКАЯ ПОМОЩЬ • 1.1.1. Рекомендации для экстремальных ситуаций • 1.1.2. Первая медицинская помощь при кровотечениях • 1.1.3. Особенности оказания первой помощи при некоторых кровотечениях • 1.1.4. Первая помощь при вывихах • 1.1.5. Первая помощь при переломах • 1.1.6. Оказание первой помощи при ожогах • 1.1.7. Электроожоги • 1.1.8. Первая помощь при отравлениях угарным газом (окись углерода) и синильной кислотой • 1.1.9. Первая помощь при боли в области сердца • 1.1.10. Первая помощь при утоплении • 1.1.11 Асфиксия • 1.1.12. Сердечно- легочная реанимация • 1.1.13. Правила оказания первой помощи при родах в отсутствие медицинских работников • 1.1.14. Терминальные состояния • 1.1.15. Первая помощь при судорожных состояниях (эпилепсии) • 1.1.16. Первая помощь при болях в области живота • 1.1.17. Острая боль в грудной клетке • 1.1.18. Первая помощь при ранениях • 1.1.19. Десмургия • 1.1.20. Черепно-мозговая травма • 1.1.21. Первая помощь при электротравмах • 1.2. АВТОНОМНОЕ СУЩЕСТВОВАНИЕ • 1.2.1. Выживание в природной среде • 1.2.2. Выживание в автономных условиях • 1.2.3. Снаряжение • 1.2.4. Выживание в условиях холодного климата • 1.2.5. Ситуации • 1.3. ЗАЩИТА ОТ ЖИВОТНЫХ • 1.3.1. Комары и москиты • 1.3.2. Ядовитые насекомые • 1.3.3. Ядовитые членистоногие • 1.3.4. Собаки • 1.3.5. Ядовитые змеи • 1.4. БЕЗОПАСНОСТЬ В МОРЕ • 2. ТЕХНОГЕННЫЕ ОПАСНОСТИ • 2. 1. ЧЕРЕЗВЫЧАЙНЫЕ СИТУАЦИИ НА ТРАНСПОРТЕ • 2.2. БЕЗОПАСТНОСТЬ ПРИ ПОЖАРЕ • 2.2.1. Горение • 2.2.2. Тушение пожара • 2.2.3. Действия при возгорании • 2.3. ЭЛЕКТРИЧЕСКИЙ ТОК • 2.3.1. Поражение электрическим током • 2.3.2. Опасные напряжения, токи, частоты • 2.3.3. Подготовка к отсутствию электрического напряжения в сети • 2.4 . МЕРЫ БЕЗОПАСТНОСТИ ПРИ ВОДНЫХ ПЕРЕПРАВАХ • 2.5. БЕЗОПАСТНОСТЬ ПРИ ИСПОЛЬЗОВАНИИ ОГНЕСТРЕЛЬНОГО ОРУЖИЯ • 2.6. ПЕРЕЧЕНЬ МЕДИКАМЕНТОВ ПЕРВОЙ ПОМОЩИ • 2.7. ВИБРАЦИЯ И АКУСТИЧЕСКИЕ КОЛЕБАНИЯ • 2.7.1 Вибрации • 2.7.2 Акустические колебания • 2.8. ЭЛЕКТРОМАГНИТНЫЕ ПОЛЯ И ИЗЛУЧЕНИЯ • 3. ЗАЩИТА НАСЕЛЕНИЯ И ТЕРРИТОРИЙ В ЧРЕЗВЫЧАЙНЫХ СИТУАЦИЯХ • 3.1. Стихийные бедствия • 3.2. Действия в экстремальных ситуациях • 3.3. Радиация и безопасность • 3.3.1. Радиоактивность и свойства излучений • 3.3.2. Измерение радиоактивности и доз излучения • 3.3.3. Источники радиации на Земле • 3.3.4. Ядерное оружие • 3.4. Характеристика особо опасных инфекций • 4. АНТРОПОГЕННЫЕ ОПАСНОСТИ И ЗАЩИТА ОТ НИХ • 4.1. Рекомендации к поведению в криминальной обстановке • 4.2. Наркомания • 4.2.1. Чем опасна наркомания? • 4.2.2. Классификация наркотических веществ • 4.2.3 Действие наркотиков • 4.3 Алкоголизм • 5. Организация труда на рабочем месте при использовании персонального компьютера • 5.1. Организация рабочего места и ее особенности при использовании ПЭВМ • 5.2 Профессиональные заболевания при работе с ПЭВМ и их профилактика • 5.3. Защитные фильтры для дисплеев • 6. Научная организация труда на предприятиях информационного обслуживания • 6.1 Понятие научной организации труда • 6.2 Планирование и внедрение научной организации труда на предприятиях ИО • 6.3. Создание благоприятных условий труда • 7. ОХРАНА ТРУДА И ТЕХНИКА БЕЗОПАСНОСТИ НА ПРЕДПРИЯТИЯХ ИНФОРМАЦИОННОГО ОБСЛУЖИВАНИЯ • 7.1. Производственный травматизм и профессиональные заболевания • 7.2. Электробезопасность на предприятиях ИО • 7.3. Пожарная безопасность на предприятиях ИО • 8. ОРГАНИЗАЦИЯ РАБОТЫ ПО ОХРАНЕ ТРУДА • 8.1. Основы законодательства Российской Федерации об охране труда • 8.2. Основные принципы системы управления охраной труда • 8.3. Нормативные акты по охране труда • 8.4 Анализ организации труда на рабочем месте » 9 Обеспечение безопасности информации • Особенности современных информационных систем, существенные с точки зрения безопасности • Информационный ресурс » Критерии информационной безопасности • 9.1 Угрозы информационной безопасности • 9.2 Классификация программно-аппаратных комплексов защиты информации • 9.2.1 Идентификация и аутентификация • 9.2.2 Управление доступом • 9.2.2.1 Ролевое управление доступом • 9.2.3 Протоколирование и аудит • 9.2.3.1 Активный аудит • 9.2.4. Шифрование • 9.2.5. Контроль целостности • 9.2.5.1. Цифровые сертификаты • 9.2.6. Экранирование • 9.2.6.1. Архитектурные аспекты • 9.2.6.2 Классификация межсетевых экранов • 9.2.7. Анализ защищенности • 9.2.8 Туннелирование • 9.2.9. Управление • 9.2.10 Возможности типичных систем • 9.3 Нормативно-правовые требования к созданию средств ЗИ • 9.3.1 Общие критерии • 9.3.2 Обзор руководящих документов Федеральной службы по техническому и экспортному контролю (ФСТЭК России) • 9.4 Развитие программно-аппаратных комплексов защиты информации в РФ • 10.1. Основные требования по обеспечению безопасности труда и регламентирующие их документы • 10.2 Паспортизация инженерно-технических средств безопасности • 10.3. Аттестация рабочих мест по организации труда на рабочем месте • 11.1. Оградительные устройства • 11.2 Предохранительные устройства • 11.3 Защита от источников тепловых излучени • 11.4 Защита от электромагнитных полей • 11.5. Защита от ионизирующих излучений • 11.6 Защита от шума, вибрации и ультразвука • 11.7 Защита от электрического тока • 12.1 Порядок выдачи средств индивидуальной защиты