Курс МСЗИ4 (1027401), страница 3

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

Текст из файла (страница 3)

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

Моралью этого параграфа является правило "семь раз отмерь – один отрежь" на этапе разработки собственного программного обеспечения.

Назад | Содержание | Вперед

Ошибки, приводящие к возможности атак на информацию

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

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

Для целых и дробных чисел, значений времени и тому подобных типов данных запись производится всегда в фиксированном объеме (2 байта, 4 байта, 10 байт). А вот для строк и массивов данных проверки длины перед операциями записи необходимы. Для того, чтобы заставить ЭВМ выполнить код или записать данные туда, куда у него нет прав записи, злоумышленник специально заставляет систему обрабатывать строки очень большой длины, либо помещать в массив количество элементов большее, чем его объем. В случае успеха возможно либо попадание части строки в сегмент кода или стека с последующим исполнением, либо модификация каких-либо служебных данных, что позволит затем злоумышленнику войти в систему в обход системы защиты. Естественно, что содержимое конца строки (оказывающееся после переполнения буфера в ненадлежащей области памяти) подбирается специальным образом. Сами данные или строки можуг быть абсолютно бессмысленными.

Проблема ограничений, которые разработчик программы считает само собо разумеющимися, но которые на самом деле могут не выполняться, встречается гораздо чаще, но реже приводит к каким-либо серьезным последствиям. Чаще всего результатом обработки подобных данных становится прерывание работы программы с сообщением об ошибке или просто "зависание". То есть данный класс атак используется с целью проведения атаки "отказ в сервисе".

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

Назад | Содержание | Вперед

Основные положения по разработке ПО

Общие рекомендации по написанию устойчиво работающих алгоритмов (необходимое, но не достаточное условие их информационной безопасности):

• не используйте экзотические и недокументированные возможности языка программирования : Вы не уверены в том, как они реализуются на самом деле

• оформляйте исходный текст ясно и четко, используйте необходимые комментарии

• используйте скобки для явного указания порядка операций : компилятор может оптимизировать выполнение выражений и начать, скажем, сложение F(1)+F(2)+F(3) со второго знака "+", тем самым вызвав сначала функцию F от 2, затем от 3, а только затем от 1 – если в функции изменяются какие-либо глобальные переменные это может привести к непредсказумым последствиям

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

• используйте структурное программирование : разбивайте сложные блоки кода на процедуры с ясной структурой и легко контролируемым набором параметров

• никогда не программируйте недокументированные возможнности : технология "reverse engineering" – дизассемблирование и обратная компиляция" – на сегодняшний день достигла огромных результатов, особенно в отношении высокоуровневых языков программирования

• закрывайте файлы сразу же по окончании работы с ними, а если Вы записываете важную информацию в течение долгого времени – периодически вызывайте функции сброса файлового буфера на дисковый накопитель

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

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

• старайтесь как можно сильнее сократить время записи в совместно используемые файлы, а, следовательно, и время их блокирования

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

• при работе с внешними и сетевыми устройствами и дисками стройте циклы ожидания таким образом, чтобы из них был возможен выход по истечении определенного периода ожидания ответа – тайм-аута

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

• тщательно проверяйте алгоритмы на синдром "мертвой петли" – это ситуация, когда процесс A, начав изменять объект 1 и заблокировав его в связи с этим, ожидает снятия блокирования с объекта 2, в то время как процесс B, в то же самое время начавший изменять объект 2 и заблокировав его, ожидает снятия блокировки с объекта 1 – подобная проблема при такой схеме синхронизации теоретически неразрешима, единственный выход из нее – рассматривать объекты 1 и 2 как единое целое с возможностью только совместной блокировки

• аккуратно выделяйте и очищайте объекты в динамической памяти

• при необходимости используйте криптографию

• никогда не передавайте пароль открытым текстом

• используйте криптостойкие алгоритмы шифрования и хеширования

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

• всегда проверяйте длины строк и массивов перед началом работы с ними

• встрайвайте в Ваши системы требование регистрации каждого оператора с уникальным паролем и записью как можно большего количества информации о сеансе в лог-файл, недоступный для изменения операторам

• тщательно тестируйте Ваши приложения, в том числе на больших и неправильных входных данных

Назад | Содержание | Вперед

Комплексная система безопасности

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

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

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

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

Назад | Содержание | Вперед

Классификация информационных объектов

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

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

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

Назад | Содержание | Вперед

Классификация по требуемой степени безотказности

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

Параметр	класс 0	класс 1	класс 2	класс 3
Максимально возможное непрерывное время отказа	1 неделя	1 сутки	1 час	1 час
В какое время время отказа не может превышать указанное выше ?	в рабочее	в рабочее	в рабочее	24 часа в сутки
Средняя вероятность доступности данных в произвольный момент времени	80%	95%	99.5%	99.9%
Среднее максимальное время отказа	1 день в неделю	2 часа в неделю	20 минут в неделю	12 минут в месяц

Назад | Содержание | Вперед

Классификация по уровню конфиденциальности

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

Класс	Тип информации	Описание	Примеры
0	открытая информация	общедоступная информация	информационные брошюры, сведения публикававшиеся в СМИ
1	внутренняя информация	информация, недоступная в открытом виде, но не несущая никакой опасности при ее раскрытии	финансовые отчеты и тестовая информация за давно прошедшие периоды, отчеты об обычных заседаниях и встречах, внутренний телефонный справочник фирмы
2	конфиденциальная информация	раскрытие информации ведет к значительным потерям на рынке	реальные финансовые данные, планы, проекты, полный набор сведений о клиентах, информация о бывших и нынешних проектах с нарушениями этических норм
3	секретная информация	раскрытие информации приведет к финансовой гибели компании	(зависит от ситуации)

Назад | Содержание | Вперед

Политика ролей

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

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

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

Характеристики

Список файлов лекций