При выпуске мелких партий продуктов возможно использование защиты с использованием электронных ключей. Недостаток данного метода заключается в стоимости ключа. Самый надежный ключ - является самым дорогим и навороченным.
Разброс цен следующий: от 13,5 у.е. (самый дешевый ключ+большой объем поставки) до 270 у.е. (самый дорогой в кол-ве 1 штуки). Все зависит от модели ключа; сетевой он / не сетевой; размера поставки). В отличии от SF, у "Алладина" имеются сетевые ключи, что позволяет организовать доступ по принципу клиент-сервер.
Стоимость SDK варьируется 25 до 45 у.е., в зависимости от модели ключа - для ключей HASP; для Hardlock - DK - от 30 до 34 у.е., мастер-комплекты (отличаются от DK наличием криптоплаты) - до 104 у.е.
Устанавливать дешевый ключ не выгодно, так как независимо от устойчивости к взлому приложения, ключ очень уязвим. Для программного продукта необходимо выбирать ключ средней и высокой категории, используя все его возможности по максимуму. В итоге получается, что ключом можно защитить программное обеспечение стоимостью выше 200-400 долларов. Стоимость достаточна высока, поэтому данный тип защиты более ориентирован на корпоративный рынок дорогих программных систем.
Часто для реализации нераспространения продукта при его эксплуатации используются в электронные ключи (HASP) или Sentinel.
HASP представляет собой программно-аппартный комплекссодержащий код, процедуры или любые другие уникальные данные, по которым защита может идентифицировать легальность запуска.
Современные электронные ключи подключаются практически ко всем портам компьютера: от LPT до USB, а также слотам ISA и PCI, при возникновении такой необходимости.
Основой ключей HASP является специализированная заказная микросхема (микроконтроллер) - ASIC (Application Specific Integrated Circuit), имеющая уникальный для каждого ключа алгоритм работы.
Принцип защиты состоит в том, что в процессе выполнения защищённая программа опрашивает подключённый к компьютеру ключ HASP. Если HASP возвращает правильный ответ и работает по требуемому алгоритму, программа выполняется нормально. В противном случае (по усмотрению), она может завершаться, переключаться в демонстрационный режим или блокировать доступ к каким-либо функциям программы.
Большинство моделей ключей HASP имеют энергонезависимую программно-перезаписываемую память (так называемую EEPROM). В зависимости от реализации HASP память может быть от одного до четырех килобитов).
Наличие энергонезависимой памяти дает возможность программировать HASP, размещая внутри модуля различные процедуры, либо хранить дополнительные ключи, а также:
сдавать программы в аренду и распространять их демо-версии с ограничением количества запусков;
хранить в ключе пароли, фрагменты кода программы, значения переменных и другую важную информацию.
У каждого ключа HASP с памятью имеется уникальный опознавательный номер, или идентификатор (ID-number), доступный для считывания защищёнными программами. Идентификаторы позволяют различать пользователей программы. Проверяя в программе идентификатор HASP, пользователь имеет возможность предпринимать те или иные действия в зависимости от наличия конкретного ключа. Идентификатор присваивается электронному ключу в процессе изготовления, что делает невозможным его замену, но гарантирует надежную защиту от повтора. С использованием идентификатора можно шифровать содержимое памяти и использовать возможность ее дистанционного перепрограммирования.
Система HASP позволяет защищать программное обеспечение двумя различными способами: автоматически (стандартно) и вручную (через специальный API).
Подведем некоторый итог для каждой компании, так как явного победителя нам выбрать не удалось. Каждая из защит эффективна только для своего сегмента рынка.
Эффективное SDK.
Возможности реализации различных маркетинговых схем.
Данный подход заключается в формировании виртуальных драйверов устройств и имитации обращения к диску. Это уже чистой воды взлом, поскольку для нормальной работы вскрытого приложения в систему инсталлируется специальный драйвер, который имитирует обращение к нестабильной метке на диске и возвращает вскрытой программе именно те данные, которые она ожидает "увидеть". Подобный способ довольно часто применяется на первых порах, когда хакеру известен способ получения метки на диске, но ему не очень хочется разбираться с программой методом дизассемблирования.
Противодействием может служить работа с устройствами чтения/записи на низком уровне, когда невозможно перехватить вызовы к оборудованию. Здесь нужно еще внести одно пояснение: для того, чтобы защищенному приложению обратиться к CD, и проверить его на наличие специальной метки, необходимо воспользоваться одной из функций чтения/записи, которые предоставляет Windows. Хакерами уже наработан ряд механизмов, позволяющих перехватывать стандартные обращения к функциям Windows, а раз можно перехватить обращение, значит можно имитировать чтение, целиком заменяя стандартные вызовы на собственные. Как говорилось выше, противодействием данному способу взлома может быть только обращение к накопителю не через стандартные вызовы.
Эмулирование устройств данного типа осуществляется так же, как и для CD, однако основную сложность представляет собой эмулирование обмена ключ - драйвер - ключ. Одна из основных возможностей электронных ключей защиты заключается в кодировании с помощью ключа данных, используемых защищенным приложением.
Противодействием эмуляции является частое использование функций кодирования данных, применение декодированных данных непосредственно в работе защищенного приложения (без предварительного сравнения).
В случае аппаратной реализации алгоритмов кодирования полная эмуляция ключей защиты становится практически невозможна, злоумышленники стараются снять защиту путем взлома программного модуля.
Эмулирование данного типа устройств осуществляется так же, как и для CD, если не проще. Вызовы к электронному ключу проще (относительно) перехватить и построить эмулятор.
Противодействием является программирование доступа к ключу на низком уровне, без использования стандартных механизмов, но и тут необходимо быть осторожными.
Давайте ответим на простой вопрос: а зачем нужна защита для создаваемого ПО, если она в итоге ломается?
Ответ очень прост. При выпуске программного продукта (игрового или корпоративного) может случиться так, что кряк ил сломанная версия появятся на рынке даже раньше полноценного релиза (что зачастую и происходит). Эта судьба касается практически всех программных продуктов, независимо от того защищены они специальным образом или нет.
Что же получается? Компания производитель лишается своей прибыли. Если говорить о западных компаниях, то они все равно получают свою прибыль от легального сектора экономики, и пиратство для них, конечно же ощутимо, но не смертельно. Если мы возьмем нашу компанию, то получим полное банкротство, так как никто не будет покупать легальное ПО, когда рядом лежит тоже самое по цене несоизмеримо меньше.
Во-первых, устойчивая к взлому защита позволит существенно снизить цены на собственную продукцию со стороны производителей ПО, то есть сделать так, чтобы было бы не выгодно вкладывать деньги во взлом ПО со стороны пиратов. А для пользователей не имело бы смысла искать сломанную копию программного обеспечения.
Во-вторых, устойчивая защита позволяет производителю программного обеспечения гарантировать возврат инвестиций. Говоря простым языком, если защита вскрывается за 4-5 месяцев, то компания-производитель может продать достаточное количество копий своего продукта, чтобы покрыть все расходы на разработку и производство и получить прибыль. А если новая версия продукта выходит через 7-8 месяцев, то коммерческий успех можно повторять до бесконечности.
Иными словами недорогая и эффективная защита поможет компаниям-разработчикам в возврате вложенных средств. Также интересен такой аспект как управление продажами, при котором возможен индивидуальный подход к каждому клиенту.
Учитывая специфику каждого программного продукта, попробуем дать общие рекомендации для организации эффективной защиты без привязки к конкретному производителю.
В таблице Таблица 3 продемонстрированы цены и объект защиты.
Таблица 3. Стоимость услуг SF
Для семантически корректного вычислительного процесса в контексте данного оператора должны выполнятся следующие соотношения между абстрактными размерностями параметров (A, B, C, D, E, CONST_1):
Эти соотношения, так называемые инварианты подобия, позволяют однозначно определить эталон "правильного" функционирования некоторой распределенной вычислительной системы. При этом вычислительный процесс семантически корректен, если соответствующая система уравнений размерностей имеет среди множества векторов-решений хотя бы один, состоящий из всех ненулевых компонент. Действительно, предположим, что, это не так, и среди параметров вычислительного процесса определенной размерности появился параметр тождественно равный нулю при любых значениях других параметров. Это указывает на безразмерность нового параметра. Однако это невозможно, так как противоречит исходному условию определения размерностей параметров вычислительного процесса.
В результате становится возможным предложить универсальную методику обнаружения аномалий на основе инвариантов подобия. Основная идея этой методики заключается в распознавании аномалий вычислительных процессов с помощью сравнения значений инвариантов подобия реальных вычислительных процессов с эталонными значениями инвариантов. К достоинствам методики относится то, что удалось явно исключить шаг выделения независимых параметров вычислительного процесса на основе эвристических алгоритмов. Использование достаточно строгого требования отличия компонент вектора решения от нуля позволило разработать полностью автоматический детерминированный алгоритм обнаружения аномалий. В частности, для вывода инвариантов подобия семантически корректного вычислительного процесса необходимо построить матрицу R-вида:
где E - единичная матрица, k и n - количество строк и столбцов исходной матрицы коэффициентов размерностей S соответственно.
уменьшить количество вычислительных операций в ходе выделения единичной матрицы в левой части матрицы R.
Алгоритм требует дополнительного хранения перестановочной матрицы T на всем этапе контроля семантической корректности вычислительного процесса, что несколько замедляет доступ к элементам матрицы. Однако использование эффективных структур данных позволяет свести дополнительные расходы к минимуму.
Отметим, построение матрицы R в ходе контроля семантической корректности вычислительного процесса позволяет обнаружить семантическую ошибку до окончания всего построения (однако вовсе не обязательно, что критерий корректности нарушится именно в момент добавления информации об ошибочной строке процесса). Данный факт является определенным достоинством предлагаемой инженерной методики обнаружения аномалий в случае наличия в сети передачи данных большого количества ошибочных пакетов (умышленно либо неумышленно порожденных). В этом случае станция-получатель L, еще не декодировав сообщение полностью, может принять решение об его игнорировании. Данную особенность можно использовать при создании комплексной системы защиты от атак класса "отказ в обслуживании".
При этом в нормальных условиях функционирования досрочные отклонения пакетов не влияют на среднестатистическую вычислительную трудоемкость. В связи с тем, что доля аномальных реализаций процессов стека сетевых протоколов стремится к нулю.
Другая особенность рассмотренной методики - наличие нескольких независимых между собой групп размерностей переменных. Примером могут служить счетчики, обрабатываемые данные, сетевые адреса, параметры протоколов. В результате, почти для всех сетевых протоколов множество параметров можно разбить на подмножества общим числом от 2 до 5-10, в зависимости от специфики протокола. Аналогами данных подмножеств в пространстве образов отображения ? являются связные компоненты графа. Внутри каждого подмножества аналогично основному множеству можно выделить базисные и зависимые переменные. Отмеченная особенность позволяет с минимальными вычислительными затратами привести матрицу S путем перестановки строк и столбцов к блочно-диагональному виду:
Дальнейшая обработка матрицы S может производиться независимо для каждой из матриц S'i . При этом алгоритм построения матрицы вида (6) может применяться независимо к каждой из матриц S'i . В таком случае общий вид матрицы S имеет вид:
Причем если хотя бы для одной из матриц С'i не выполняется условие, справедливое для матрицы С в целом, то это говорит об аномалии вычислительного процесса и наличии семантической ошибки.
Рассмотрим систему размерностей в терминах теории графов. В этом случае процесс проверки существования нетривиального или не имеющего нулей решения системы линейных уравнений сводится к проверкам подсистем, имеющих ранг, равный количеству содержащихся в них переменных. В фактор-множестве (G/?)/?' подсистемам, обладающим подобными свойствами, соответствуют простые циклы (везде далее - циклы). Для проверки общей совместности системы, заданной матрицей s, достаточно проверить совместность некоторого подмножества подсистем, удовлетворяющего следующим критериям:
между любыми двумя циклами, соответствующими элементам подмножества, должен существовать путь, то есть цепь из других циклов, каждая соседняя пара циклов в которой имеет хотя бы одно общее ребро.
Возможность выбора подсистем множеством различных способов позволила разработать методику выбора подмножества подсистем, удовлетворяющего приведенным выше критериям и требующего минимального количества операций для проверки совместности. Припишем каждому циклу в графе ?'(w(s)) меру, пропорциональную вычислительной трудоемкости его проверки. Данный параметр можно принять прямо пропорциональным (например, равным) количеству ребер в цикле. Определим отображение ?: (G/?)/?' -> H, где H - множество гиперграфов, следующим образом. Сопоставим каждому ребру графа-прообраза вершину в графе-образе, а каждому циклу - ребро (возможно степени выше 2).
Таким образом, в новом пространстве каждому уравнению системы ограничений соответствует вершина, а каждой потенциально несовместной подсистеме - ребро гиперграфа. Рассмотрим, например, граф gX , изображенный на рис. 1, соответствующий системе с 5 переменными, 6 связанными уравнениями и 3 простыми циклами. Условная стоимость проверки циклов A, B и C соответственно равна 3, 4 и 5 единицам.
Рис. 1. Граф gX
Отображение ? переводит данный граф в гиперграф, изображенный на рис. 2.
При реализации стеков сетевых протоколов в современных операционных системах принят де-факто принцип разбиения обработки передаваемых данных на уровни, соответствующие функциональной нагрузке. На каждом этапе обработки к результату предыдущего уровня добавляется служебная информация, и весь блок данных как неделимое целое передается на следующий этап обработки. Кроме этого при переходе между уровнями обработки возможен выбор протокола, который будет реализовывать функциональность конкретного уровня. Поэтому согласно стандарту "Взаимодействие Открытых Систем" (Open Systems Interconnection - OSI) международного Института Стандартизации ISO разделим контролируемые вычислительные процессы на семь уровней. При этом обозначим процессы, соответствующие уровням обработки данных как "pK7", "pK6", … , "pK1" на передающей стороне, и "pL1", "pL2", … , "pL7" согласно очередности их исполнения в системе. Тогда алгоритм обнаружения аномалий на основе инвариантов подобия принимает следующий вид.
значения элементов матриц sKi.
Количество задействованных в системе переменных передается в двоичном коде. Позиции переменных передаются двумя векторами VP и VL. Каждый элемент VPi вектора VP соответствует смещению в битах от начала заголовка соответствующего уровня до начала поля соответствующей переменной и кодируется двоичным кодом. Каждый элемент VLi вектора VL соответствует длине в битах поля соответствующей переменной в заголовке и кодируется двоичным кодом.
Количество строк в каждой матрице кодируется двоичным кодом. Для эффективного построчного кодирования матриц sKi предлагается следующая методика исходя из:
группирования значений коэффициентов матриц вблизи числа 0.
Для каждой строки матрицы в пакет записываются векторы VN и VK. Каждый элемент вектора VN соответствует ненулевому коэффициенту текущей строки матрицы и хранит порядковый номер столбца с таким элементом в двоичном коде. Каждый элемент вектора VK хранит значение ненулевого коэффициента, соответствующего элементу вектора VN с тем же индексом, в каком-либо эффективном коде, например, коде Хаффмана.
Матрицы sK7 и sK6 (прикладного и представительского уровней модели OSI) передаются на станцию-получатель L однократно в момент установки соединения прикладного уровня. Для многих протоколов это соответствует установлению соединения сеансового уровня. Матрицы sK5 и sK4 вычисляются и передаются в начале каждого сообщения. Матрицы sK3 , sK2 , sK1 необходимо передавать для каждого пакета сообщения.
Произведем оценку объемов дополнительного трафика, необходимого к передаче на станцию-получатель L для реализации предлагаемого в данной работе метода.
Доля трафика, порождаемого СОАФ, в общем сетевом потоке вычисляется как отношение его объема к сумме трех основных компонент трафика:
дополнительному трафику СОАФ (TV(M)).
Пусть E - максимальный размер пакета сетевого уровня, VAVG и VMAX - средний и максимальный объем закодированной матрицы sKi , YAVG и YMIN - средний и минимальный объем служебной информации сетевого протокола i-го уровня, KAAVG и KAMIN - среднее и минимальное количество сессий сеансового уровня, приходящихся на одно соединение прикладного уровня. Тогда средняя (PAVG) и верхняя (PMAX) оценки доли дополнительного трафика как функции от величины M - длины передаваемого сообщения - будут иметь следующий вид:
где TVAVG и TVMAX - среднее и максимальное значения дополнительного трафика как функции от M (квадратные скобки означают округление в большую сторону).
Для расчета величины V, исходя из описанной выше методики кодирования, справедлива следующая формула:
где NС - количество строк в матрице sKi, KB - средняя энтропия одного символа эффективного кода для значений коэффициентов матрицы sKi, NK - среднее количество ненулевых коэффициентов в строке матрицы, NV - количество переменных в системе ограничений размерности, описываемой матрицей sKi. Для расчета величины Y воспользуемся следующей формулой:
где KP - доля переменных от общего числа, передаваемых в пакете, L - средняя длина одного поля (переменной) в пакете в битах.
Для определения VAVG, VMAX, YAVG, YMIN примем следующие значения данных коэффициентов (табл. 2.).
Исходя из этих данных, получаем значения, сведенные в таблицу 3.
Т а б л и ц а 3.
Графики зависимостей - на рис. 7 (шкала длины исходного сообщения - логарифмическая
Рис. 7. Зависимость средней (PAVG) и верхней (PMAX) оценок
Асимптотический предел средней оценки доли дополнительного трафика при длине сообщения стремящейся к бесконечности равен
асимптотический предел верхней оценки доли дополнительного трафика при тех же условиях равен
Таким образом, предложенная методика кодирования дополнительной информации обеспечивает приемлемый накладной прирост объема трафика при длинах сообщений, составляющих наибольшую долю в среднестатистическом сетевом трафике. Это подтверждает практическую применимость рассмотренной методики обнаружения аномалий на основе инвариантов подобия.
Для системы n уравнений с n неизвестными при отсутствии выборок из массива (хранящего информацию о перестановках строк и столбцов) общая вычислительная трудоемкость вывода инвариантов подобия равна количеству операций процессора
Здесь KMUL - коэффициент вычислительной трудоемкости операции целочисленного умножения по сравнению с операцией целочисленного сложения для данной аппаратной платформы. Например, для процессоров класса Intel Pentium значение этого коэффициента составляет 6-10 раз, для процессоров класса Intel 8086 может достигать 20-40 раз. При возможности реализации кэширования с высокой частотой попадания в кэш значение KMUL снижается до 2 раз.
Как следствие, выигрыш в вычислительной трудоемкости выделения инвариантов подобия в основном зависит от пропорций разбиения матрицы S на независимые компоненты. Так, например, при расслоении множества переменных на g подмножества равной мощности выигрыш K в вычислительной трудоемкости можно рассчитать по формуле:
2. В случае неравномерного разбиения множества переменных оценку полученного выигрыша можно рассчитать следующим образом. Пусть расслоение множества переменных на подмножества независимых переменных выделяет в нем подмножество мощности m. Тогда значение K определяется так:
Учитывая, что нашей задачей является отыскание наименьшего m, превращающего неравенство (17) в истинное, будем считать, что
Как уже было указано, минимальное значение KMUL с применением технологии кэширования составляет 2 раза, без кэширования на современных аппаратных платформах - 6 раз. С учетом этого коэффициент в знаменателе неравенства (20) для кэш-реализаций составляет 42 и более, для реализаций без кэширования - 100 и более раз, что на практике приводит к выигрышу в вычислительной трудоемкости выделения инвариантов подобия уже при отделении хотя бы одной независимой переменной.
Таким образом, при наличии в графе w(S) нескольких связных компонент использование методики обнаружений аномалий на основе инвариантов подобия практически оправдано. При этом вычислительные затраты на поиск и выделение связных компонент в алгоритме вычислительных процессов по сравнению с вычислительной трудоемкостью вывода инвариантов подобия не значительны.
Проверим вывод инвариантов подобия путем построения достаточного условия, например, на основании применения исчисления матрицы R по модулю простого числа. Для наличия в каждой строке матрицы C хотя бы одного ненулевого элемента достаточно, чтобы в каждой строке матрицы Cq , полученной из С путем вычисления остатка от деления соответствующего элемента на натуральное число q, существовал хотя бы один ненулевой элемент.
Действительно, пусть в i-й строке матрицы C все элементы равны нулю, тогда из определения матрицы Cq имеем
Тогда достаточным условием вывода инвариантов подобия является требование, чтобы матрица C в системе уравнений размерности, построенной для него с учетом числовых констант и приведенной к виду, производя вычисления по модулю произвольного натурального числа q, не содержала нулевых строк.
Для корректного функционирования процесса необходимо, чтобы матрица C в системе уравнений размерности, приведенной к виду (4), не имела нулевых строк. Ранее было показано, что для выполнения этого условия достаточно, чтобы матрица Cq , полученная из матрицы C вычислением по модулю произвольного натурального числа q, не имела нулевых строк. Однако, в силу дистрибутивности операции вычисления остатка от деления на произвольно число q относительно операций сложения и умножения, применение исчисления по модулю q возможно уже на этапе приведения матрицы S к виду (4).
Данное условие является достаточным, но не необходимым. Действительно, при наличии в матрице Сq нулевых строк некоторые элементы в соответствующих строках в матрице С могут быть отличными от нуля, а именно - кратными q, а, следовательно, сам критерий может быть истинным. Приведенное условие преобразуется в необходимое, если поиск нулевых строк в матрице C производится для всех простых q. Более того, принимая во внимание диапазон исходных значений в матрице S и размерность матрицы S, возможно определить верхнюю границу списка простых чисел, достижение которой обеспечивает необходимость условия.
В общем случае трансформирование системы линейных уравнений по модулю простого числа имеет в три раза более высокую скорость исполнения. Это обусловлено отсутствием операций умножения рациональных чисел, каждая из которых содержит три операции умножения натуральных чисел (полагаем, что операции переноса и сложения имеют на порядок меньшую вычислительную трудоемкость по сравнению с операцией умножения). Исключение составляют исчисление по модулю 2 и по модулю 3.
Преобразование системы линейных уравнений по модулю 3 на множестве (-1, 0, +1) позволяет исключить из набора выполняемых операций умножение натуральных чисел. Все преобразования будут реализуемы с помощью сложения и арифметического отрицания. Это сокращает вычислительную трудоемкость проверки условия в несколько раз (в зависимости от параметров архитектуры ВС). Преобразование системы линейных уравнений по модулю 2 позволяет достичь еще большего быстродействия. Это достигается за счет возможности обрабатывать строки матрицы R как битовые последовательности, тем самым расходуя на сложение и перестановку строк по одной-двум командам микропроцессора. Перестановка столбцов при этом производится циклическими сдвигами двоичных значений.
Недостатками применения малых значений q при проверке необходимого условия является рост вероятности невыполнения условия при истинности значения критерия. Двумя величинами, критически влияющими на вероятность PFN в подобной ситуации, являются величина q и разность между количеством переменных и количеством условий, их связывающими (n-k). В первом приближении (без учета корреляции между значениями элементов матрицы R) данная зависимость описывается следующим выражением:
Кроме того, специфика предметной области обуславливает наличие в начале преобразований в матрице S в подавляющем числе значений (0, -1, +1), так как высокостепенные зависимости между переменными здесь достаточно редки. Это приводит на практике к неприемлемо высокому уровню PFN при (q = 2) даже в случае достаточно больших значений параметра (n-k).
либо проверить условие для q=3 и для какого-либо простого q, большего трех, что увеличивает скорость вычислений примерно в 3 раза при выполнении условия и замедляет скорость вычислений в 1,33 раза при невыполнении условия.
(KMUL - коэффициент вычислительной трудоемкости операции целочисленного умножения по сравнению с операцией целочисленного сложения для данной аппаратной платформы).
Большее количество проверок с различными значениями q не приносит значимого увеличения средней скорости исчисления критерия. Выбор из предложенных вариантов производится на основе практических значений вероятности PFN и чаще всего обусловлен значением величины (n-k).
Выбор значения q, большего трех, для второго варианта проверки условия производится исходя из следующих соображений. Большие значения q более эффективны в связи с уменьшением вероятности PFN ложного невыполнения достаточного условия. Однако реализация линейных преобразований матрицы R по модулю q задействует предвычисления и хранение таблиц умножения и деления по модулю q, что требует определенных ресурсов вычислительной системы.
Понятие "обнаружение аномалий" возникло сравнительно недавно и сразу привлекло внимание специалистов в области сетевой безопасности. В середине 2003 года на рынке средств защиты информации появились первые западные и отечественные системы обнаружения аномалий, а поставщики услуг сетевой безопасности начали активно предлагать соответствующие решения. Согласно прогнозам Gartner, 85% крупнейших международных компаний с вероятностью 0.8 воспользуются к 2007 году функциями современных систем обнаружения аномалий. На каких инженерных принципах базируются эти перспективные системы? Какие методики и алгоритмы обнаружения аномалий могут быть полезны для практики отечественных служб защиты информации? Давайте посмотрим вместе.
С завидным постоянством тема обнаружения аномалий возглавляет списки и рейтинги наиболее актуальных проблем в различных федеральных и коммерческих целевых программах в области защиты информации. Так, например, в разработанном Научно-техническим советом НАТО ранжированном списке из 11 важнейших технических задач на период 2002-2007 гг. три первые ориентированы на разработку аппаратных и аппаратно-программных систем обнаружения аномалий вычислительных процессов в современных и перспективных распределенных вычислительных системах на основе TCP/IP. Актуальность этой задачи объясняется тем, что согласно стратегическим отчетам НАТО существующие системы обнаружения вторжений (IDS) ежедневно обнаруживают в среднем 400-600 попыток несанкционированного автоматического вторжения. При этом эксперты подчеркивают: данное число составляет не более 14-17% от общего числа реально осуществляемых атак и воздействий нарушителей. По понятным причинам эти факты настораживают и вызывают определенное беспокойство у специалистов в области защиты информации.
Более того, до сих пор считалось, что относительно просто решается лишь проблема обнаружения вторжений в сетях TCP/IP, которая сводится к задачам распознавания:
получение по совмещенному или выделенному каналу вектора (sK7 , sK6 , … , sK1);
проверка инварианта подобия семантически корректного вычислительныго процесса.
Рис. 3. Размещение датчиков СОАФ в широковещательных сегментах вычислительной системы
К достоинствам такой схемы системы обнаружения аномалий на основе инвариантов подобия относятся:
коррекция аномалий вычислительных процессов в реальном масштабе времени в контролируемром сегменте СПД;
минимальные затраты на организацию выделенного канала передачи инвариантов подобия.
Вместе с тем необходимо отметить следующие тенденции развития современных и перспективных вычислительных системах, которые существенно влияют на технологию обнаружения аномалий:
распространение систем шифрования трафика на сетевом уровне, в том числе разработка и пробное внедрение 6-й версии протокола сетевого уровня IP со встроенной поддержкой шифрования передаваемого трафика;
значительное превышение скорости роста сетевого трафика над скоростью развития вычислительных ресурсов систем;
возможность блокирования аномального сетевого трафика на этапе передачи его прикладному процессу;
возиожность контроля реального функционирования стека сетевых протоколов.
Поэтому во втором способе (рис. 4) - датчики обнаружения аномалий размещаются на каждой рабочей станции внутри контролируемого сегмента вычислительной системы.
проверка истинности критерия.
Рис. 4. Размещение датчиков СОАФ на станциях-получателях
Теперь рассмотрим возможные варианты внесения избыточности в виде инвариантов подобия. Первый - на основе использования выделенной среды передачи информации (аналогичного и иного типа). Второй - путем использования совмещенной среды передачи информации.
Во втором варианте возможны две модификации, характеризующиеся либо выделением вектора (sK7 , sK6 , … , sK1) в отдельное сообщение, либо интеграцией его с основным информационным сообщением.
Рис. 5. Выделенный дополнительный информационный канал инвариантов подобия
Рис. 6. Совмещенный дополнительный информационный канал инвариантов подобия
Схема с выделенным информационным каналом для передачи вектора обладает следующими преимуществами:
возможностью адаптивно управлять полосой пропускания, требуемой для передачи контрольной информации (в частности использовать физическую среду с меньшей пропускной способностью);
минимальным интервалом задержки между получением датчиком информационного и контрольного пакетов.
Схему с совмещенным каналом передачи информационных и контрольных пакетов характеризуют следующие достоинства:
надежность доставки контрольного сообщения (особенно для варианта интеграции его в информационное сообщение) - невозможна ситуация, когда из-за пропадания контрольного сообщения станции-получателю придется проигнорировать корректный информационный пакет;
меньшими затратами материальных ресурсов (особенно для схем с размещением датчика на станции-получателе).
Модификация данной схемы путем интегрирования контрольной информации в основное информационное сообщение обладает рядом дополнительных преимуществ.
возможность использования единой системы обеспечения целостности для информационной и контрольной частей сообщения.
Однако данная модификация применима не во всех случаях. Это связано с тем, что превышение ограничений на длину пакета, особенно на канальном и физическом уровнях, может быть некорректно обработано сетевым оборудованием. При этом даже при замене (или соответствующей корректировке) вычислительного процесса физического и канального уровня на приемной и передающей рабочих станциях возможен сбой со стороны промежуточного сетевого оборудования (модемов, концентраторов, коммутаторов).
Для протоколов сетевого уровня, поддерживающих дополнительную фрагментацию на произвольном сегменте маршрута пакета (к таким относится, например, протокол IP), данная проблема может быть решена на станции-отправителе K:
либо модификацией вычислительного процесса сетевого уровня с целью динамического определения длины текущего фрагмента.
Для протоколов сетевого уровня, не поддерживающих фрагментацию, данный метод неприменим. В любом случае, использование данной модификации возможно только в заранее проверенных системах передачи данных и при условии неизменности состава используемого сетевого оборудования.
Известно, что обнаружение аномалий вычислительных процессов в распределенных вычислительных системах на основе TCP/IP во многом определяет эффективность управления информационной безопасностью в отечественных структурах и организациях. Изучение специфики обнаружения аномалий указывает на необходимость построения некоторой метрики безопасности на основе эталонов или инвариантов семантически корректной (правильной с точки зрения безопасности) обработки данных. Метрики, которая позволяет измерять, учитывать, наблюдать, сравнивать и совершенствовать существующие корпоративные системы защиты информации. В настоящей статье обобщены, систематизированы и развиты практические результаты нового направления исследований в этой области на основе положений теории подобия. Важным моментом этого направления является возможность теоретически обнаруживать и парировать все виды внутренних и внешних воздействий (в том числе и ранее не известные), которые существенно влияют на функциональные свойства распределенных вычислительных систем на основе TCP/IP.
В случае передачи вектора (sK7 , sK6 , … , sK1) по открытому каналу передачи данных необходимо обеспечить требуемую целостность сообщений. Без дополнительных средств защиты рассматриваемый метод обнаружения аномалий на основе инвариантов подобия уязвим на этапе передачи вектора X и возможны фальсификации сообщений, а также атаки методом повтора (от англ. reply attack).
Поэтому для защиты сообщений от фальсификации предлагается использовать алгоритмы электронно-цифровой подписи (ЭЦП), основанные на методах асимметричной криптографии, или алгоритмы имитозащиты, основанные на методах симметричной криптографии. В силу требования очень высокой скорости процессов вычисления и проверки тегов целостности более приемлемыми являются симметричные криптопреобразования.
Согласно методу обеспечения имитозащиты над открытым сообщением, которым в данном случае является вектор X, выполняются симметричные криптопреобразования. В процесс необратимым образом вовлекается блок секретной информации, известный только агенту-отправителю и датчику СОАФ, - ключ выработки имитовставки. Результат преобразований - блок фиксированной длины (имитовставка) добавляется к открытому сообщению. В качестве практической реализации для выработки имитовставки может быть использован алгоритм ГОСТ 28147-89 согласно спецификации либо любой алгоритм криптостойкой хеш-суммы (например, MD5 или SHA-1). Во втором варианте ключ выработки имитовставки добавляется конкатенацией к защищаемым данным (вектору X) перед выполнением хеширования.
Атака методом повтора заключается в изменении или замене злоумышленником пакета (в данном случае - позволяющего обнаружить несанкционированную активность в сети) на значение, ранее уже передававшееся в сети и приводящее к исчислению положительного значения критерия (28). При реализации данной атаки злоумышленнику не требуется производить подбор имитовставки или ключа ее генерации, его цель - сокрытие от системы своей несанкционированной активности. Возможность проведения подобных действий без атаки криптоалгоритма имитовставки делает задачу защиты от подобного класса атак актуальной для разрабатываемого способа.
Для защиты от атаки методом повтора в защищаемое сообщение до выработки имитовставки добавляется:
либо штамп времени высокой точности (с необходимостью высокоточной синхронизации машинных часов всех станций-абонентов СПД).
Возможна комбинация первого и второго метода с соответствующим уменьшением разрядности порядкового номера и загрублением точности системы синхронизации времени.
Параметры алгоритма обеспечения целостности дополнительного информационного потока рассчитываются из следующих соображений. Ключ выработки имитовставки является долгосрочным (функционирует в неизменном виде в течение достаточно долгого периода), в силу этого на него должны распространяться общие требования для симметричных криптоалгоритмов. В частности, считается стойкой на современном этапе развития электронно-вычислительной техники длина ключа в 256 бит.
Само содержимое имитовставки не является предметом какой-либо из известных криптоатак. Однако, генерируя хаотичным образом имитовставку для несанкционированного пакета, злоумышленник может случайно создать валидное ее значение. Данная атака является определяющей для выбора минимальной длины имитовставки: между двумя станциями за разумный временной интервал при использовании максимальной пропускной способности сети не должно быть возможным случайно сгенерировать валидную имитовставку.
Максимальное количество пакетов, которые можно создать на данном физическом носителе за определенный интервал времени, определяется формулой
где BW - максимально возможная пропускная способность сети между злоумышленником и абонентом (в битах в секунду), Y - длина интервала времени (в годах), L - минимально необходимая для атаки длина пакета (в байтах). Для определения верхней границы NMAX примем значения BW = 109, Y = 20, L = 56. Тогда NMAX равняется (1,4·1015), что соответствует по порядку величины 250, и для достижения уровня надежности ? = 0,999 длина имитовставки должна быть не менее
С учетом требуемого аппаратной платформой округления данной величины до границы байта, получаем длину имитовставки в 8 байт. Данное дополнение является вполне приемлемым для предложенного способа. Так, например, при длине информационного сообщения в 16 кбайт, доля добавляемой информации об инвариантах будет составлять в среднем 5,43%, а доля векторов имитозащиты - 0,54% от общего трафика.
Таким образом, выбор конкретной схемы реализации СОАФ зависит от топологии сети и характеристик рабочих станций-абонентов. Задача обеспечения целостности дополнительного информационного потока является разрешимой на основе общеизвестных технологий и не несет критического увеличения требуемых ресурсов.
Североамериканская компания Authentica поставляет комплексное решение для всестороннего контроля над оборотом классифицированных сведений в корпоративной сети. Однако, в отличие от большинства своих конкурентов, фирма остановилась не на технологиях выявления и предотвращения утечек, а на управлении цифровыми правами в рамках предприятия (ERM - Enterprise Rights Management). Именно на примере основного продукта компании - Authentica Active Rights Management (ARM) Platform - будут рассмотрены достоинства и недостатки такого подхода. Полученные в результате анализа результаты применимы для всех остальных решений, призванных устранить проблему утечек посредством ERM-технологий. В частности, для продуктов компаний Adobe, Workshare, Liquid Machines, SealedMedia, DigitalContainers и Microsoft. Также необходимо отметить, что решение Authentica ARM Platform имеет очень много общего с Microsoft Rights Management Services (RMS).
В основе решения Authentica лежит запатентованная технология ARM (название которой входит в название самого продукта). С помощью ARM решение контролирует электронные документы, почтовые сообщения и вообще любые файлы. Дополнительные модули интегрируются с настольными приложениями (Microsoft Office и Outlook, Lotus Notes, Adobe Acrobat, Microsoft Explorer и Netscape) и внешними средствами аутентификации (LDAP, Windows Single Sign-on, X.509, RSA SecurID). Схема работы Authentica ARM Platform представлена на схеме 1.
. Схема работы Authentica ARM Platform
Функциональность Active Rights Protection подразумевает аутентификацию пользователей и их авторизацию для просмотра информации, контроль над печатью документов и стандартными операциями (копирование, редактирование, чтение), а также возможность работы с документами в режиме offline. В дополнение к этому вся чувствительная информация постоянно находится в зашифрованном виде и расшифровывается только на момент работы с ней. Шифрованию также подлежит обмен информацией между сервером политик ARM и клиентскими компонентами.
Таким образом, конфиденциальные данные всегда защищены от несанкционированного доступа - даже при передаче по коммуникационным каналам. Следует помнить, что и сама архитектура продукта тоже приспособлена именно для защиты от несанкционированного доступа, а не от утечки. Другими словами, инсайдер, обладающий правами доступа к конфиденциальному документу, может обмануть защиту. Для этого достаточно создать новый документ и переместить в него конфиденциальную информацию. Например, если инсайдером является сотрудник, в задачи которого входит подготовка отчета о прибыли, он будет создавать этот высокочувствительный документ "с нуля", а, следовательно, файл не будет зашифрован, так как для него еще не создана специальная политика. Соответственно, утечка становится вполне реальной. Если еще учесть, что весь почтовый трафик шифруется, то у инсайдера фактически есть готовый защищенный канал для пересылки конфиденциальных данных. При этом никакой фильтр не сможет проверить зашифрованный текст.
Тем не менее, решение Authentica ARM Platform представляется эффективным продуктом для защиты от несанкционированного доступа, поскольку ни один нелегальный пользователь действительно не сможет получить доступ к данным, пока не отыщет ключ шифрования.
Дополнительным недостатком продукта является отсутствие возможности хранить архивы корпоративной корреспонденции, что значительно усложняет процесс расследования инцидентов IT-безопасности и не позволяет вычислить инсайдера без лишнего шума.
В заключение необходимо отметить широкий комплекс сопроводительных услуг, которые Authentica оказывает заказчику: аудит и анализ IT-инфраструктуры с учетом бизнес-профиля компании, техническая поддержка и сопровождение, внедрение и развертывание решений "с нуля", корпоративные тренинги для персонала, разработка политики IT-безопасности.
Решение InfoWatch Enterprise Solution (IES) поставляется российской компанией InfoWatch, разработчиком систем защиты от инсайдеров. Оно позволяет обеспечить контроль над почтовым каналом и веб-трафиком, а также коммуникационными ресурсами рабочих станций. На сегодняшний день IES уже используется правительственными (Минэкономразвития, Таможенная служба), телекоммуникационными ("ВымпелКом"), финансовыми (Внешторгбанк) и топливно-энергетическими компаниями (ГидроОГК, Транснефть).
Архитектуру IES можно разделить на две части: мониторы, контролирующие сетевой трафик, и мониторы, контролирующие операции пользователя на уровне рабочих станций. Первые устанавливаются в корпоративной сети в качестве шлюзов и фильтруют электронные сообщения и веб-трафик, а вторые развертываются на персональных компьютерах и ноутбуках и отслеживают операции на уровне операционной системы. Принцип работы IES представлен на .
Сетевые мониторы IWM и IMM также могут быть реализованы в виде аппаратного устройства - InfoWatch Security Appliance. Таким образом, заказчику предлагается на выбор либо программное, либо аппаратное исполнение фильтров почты и веб-трафика. О преимуществах данного подхода более подробно написано в предыдущей статье, посвященной борьбе с утечками только "железными" средствами. На представлено комплексное решение IES, в состав которого входят аппаратные модули IWSA, в IT-инфраструктуре крупной компании, имеющей филиалы.
К мониторам уровня рабочей станции относятся InfoWatch Net Monitor (INM) и InfoWatch Device Monitor (IDM). Модуль INM отслеживает операции с файлами (чтение, изменение, копирование, печать и др.), контролирует работу пользователя в Microsoft Office и Adobe Acrobat (открытие, редактирование, сохранение под другим именем, операции с буфером обмена, печать и т. д.), а также тщательно протоколирует все действия с конфиденциальными документами. Вся эта функциональность логично дополнена возможностями модуля IDM, который контролирует обращение к сменным накопителям, приводам, портам (COM, LPT, USB, FireWire), беспроводным сетям (Wi-Fi, Bluetooth, IrDA) и т.
д. Вдобавок компоненты INM и IDM в состоянии работать на ноутбуках, а администратор безопасности может задать специальные политики, действующие на период автономной работы сотрудника. Во время следующего подключения к корпоративной сети мониторы сразу же уведомят специалиста отдела безопасности, если пользователь попытался нарушить установленные правила во время удаленной работы.
Все мониторы, входящие в состав IES, способны блокировать утечку в режиме реального времени и сразу же оповещать об инциденте сотрудника отдела безопасности. Управление решением осуществляется через центральную консоль, позволяющую настраивать корпоративные политики. Предусмотрено также автоматизированное рабочее место сотрудника безопасности, с помощью которого специальный служащий может быстро и адекватно реагировать на инциденты.
Важной особенность комплексного решения IES является возможность архивировать и хранить корпоративную корреспонденцию. Для этого предусмотрен отдельный программный модуль InfoWatch Mail Storage (IMS), который перехватывает все сообщения и складывает их в хранилище с возможностью проводить ретроспективный анализ. Другими словами, компании могут покончить с порочной практикой ареста рабочих станций служащих и ручного перебора папки "Входящие" в почтовом клиенте. Такие действия подрывают рабочий климат в коллективе, унижают самого сотрудника и часто не позволяют найти никаких доказательств вины служащего. Напротив, автоматизированная выборка сообщений из корпоративного архива приносит намного больше пользы, так как позволяет отследить динамику изменения активности пользователя.
Делая ставку на всесторонность своего решения, компания InfoWatch предлагает клиентам целый ряд сопроводительных и консалтинговых услуг. Среди них можно выделить: предпроектное обследование, помощь в формализации целей и средств IT-безопасности, создание ее эффективной политики, адаптацию решения под нужды клиента, сопровождение и техническую поддержку, включающую персонального менеджера каждому заказчику.
Таким образом, комплексное решение IES сочетает все аспекты защиты конфиденциальной информации от инсайдеров.
Далее приводится таблица, обобщающая основные характеристики рассмотренных продуктов. В качестве основных параметров взяты наиболее критические характеристики решений, однако для разумного выбора рекомендуется обязательно ознакомиться с описанием продукта в тексте статьи.
Как уже отмечалось в начале статьи, при выборе решения необходимо учитывать параметр комплексности - покрывает ли продукт все возможные каналы утечки. В противном случае данные утекут через оставленную открытой дверь. Следующим немаловажным моментом является возможность создавать и хранить архивы корпоративной корреспонденции. Такая функциональность позволяет провести служебное расследование, не беспокоя сотрудников и не привлекая внимания. Вдобавок к тому, что хранить электронные сообщения в течение нескольких лет требуют многие нормативные акты и законы, создание централизованного почтового архива избавляет от порочной практики ареста рабочих станций служащих. Наконец, последним важным параметром является возможность выбора между программной и аппаратной реализацией модулей, отвечающих за фильтрацию сетевого трафика. Преимущества такого подхода подробно рассматривались в статье об аппаратных решениях для борьбы с утечками.
Израильская компания Onigma специализируется на выявлении и предотвращении утечек конфиденциальной информации посредством мониторинга действий пользователей на уровне рабочих станций и фильтрации сетевого трафика. Любопытно отметить, что руководящие должности в отделе исследований и разработок фирмы занимают в основном бывшие сотрудники министерства обороны Израиля.
Компания предоставляет очень мало информации об архитектуре своего решения Onigma Platform и реализованных в нем технологиях. Тем не менее, сведений о реализованном функционале вполне достаточно для утверждения, что Onigma Platform - это программный продукт, покрывающий следующие каналы утечки данных: электронная почта, интернет-пейджеры, веб-трафик, физические устройства (USB-порты и принтеры). Последняя функциональность реализована с помощь специальных агентов, установленных на рабочих станциях и ноутбуках заказчика. Они следят за выполнением правил и соблюдением политики IT-безопасности, поддерживают централизованное управление через специальную консоль.
Одним из основных своих преимуществ компания Onigma считает тот факт, что ее решение быстро и легко развертывается и интегрируется в имеющуюся IT-инфраструктуру. Таким образом, по мнению поставщика, заказчик может существенно сэкономить на переобучении персонала, внедренческих и сопроводительных услугах.
Недостатком Onigma Platform является невозможность создавать архивы корпоративной корреспонденции, что значительно осложняет расследование инцидентов IT-безопасности, утечек, финансового мошенничества и подозрительной активности инсайдеров. К тому же хранение деловой документации, к которой относятся электронные сообщения, - это обязательное требование целого ряда законов и нормативных актов, регулирующих бизнес во многих странах.
Дополнительный недочет продукта - неглубокий контроль над операциями пользователей на рабочих станциях (в том числе мобильных). Решение Onigma Platform не позволяет осуществлять мониторинг действий служащих в офисных средах, на уровне файлов, а также работу с буфером обмена.
Продукт PC Activity Monitor (Acme) производится и продается компанией Raytown Corp. Он позволяет осуществлять всесторонний и максимально глубокий мониторинг операций пользователя на уровне рабочей станции. Следует сразу же отметить, что из всех представленных в обзоре программных решений только продукт PC Acme не удовлетворяет принципу комплексности и не покрывает одновременно сетевые каналы и ресурсы рабочих станций. Однако эта программа все равно заслуживает рассмотрения, так как у заказчиков часто возникает проблема сравнения ее функциональности с возможностями других продуктов, рассмотренных в статье. Заметим, что трудности заказчиков связаны с не совсем точным позиционированием PC Acme, в результате чего может показаться, будто продукт обладает активными (а не пассивными) функциями и некоторым аналогом комплексности. Чтобы прояснить ситуацию, необходимо оценить возможности PC Acme Professional - максимально функциональной редакции продукта.
Программа PC Acme фактически состоит из двух частей: средства централизованного управления и развертывания и многочисленные агенты, внедряемые в рабочие станции по всей организации. Как легко догадаться, с помощью первой компоненты можно централизованно распределить агенты по всей корпоративной сети, а потом управлять ими.
Агенты представляют собой программные модули, которые очень глубоко внедряются в Windows 2000 или Windows XP. Разработчики сообщают, что агенты располагаются в ядре операционной системе и пользователю практически нереально нелегально удалить их оттуда или отключить. Сами агенты тщательно протоколируют все действия пользователей: запуск приложений, нажатие клавиш, движение мышки, передачу фокуса ввода, буфер обмена и т. д. Можно сказать, что журнал событий, получающийся на выходе, по степени своей детализации напоминает результаты неусыпного видеонаблюдения за экраном компьютера. Однако получаемый журнал, естественно, представлен в текстовом виде.
Центральная консоль управления и позволяет собирать запротоколированные данные на один-единственный компьютер и анализировать их там.
Вот тут-то и проявляются два основных недостатка программы.
Во-первых, абсолютно непонятно, как в огромном множестве событий сотрудник безопасности сможет выделить те, которые являются нарушением политики IT-безопасности, привели к утечке и т. п. Другими словами, продукт PC Acme не работает с политиками вообще. Его задача лишь в том, чтобы составить максимально подробный протокол и скрытно передать его на центральный компьютер. Заметим, что в течение дня одна рабочая станция может сгенерировать десятки тысяч протоколируемых событий, а в корпоративной сети таких станций может быть несколько тысяч и даже больше. Очевидно, что проанализировать все это собственными руками невозможно. Между тем встроенные фильтры событий позволяют осуществлять лишь самые примитивные операции, например, отделить события, связанные с конкретным приложением (скажем, Microsoft Word).
Во-вторых, даже если сотруднику безопасности удастся обнаружить утечку, он все равно уже не сможет ее предотвратить. Ведь агент PC Acme зафиксировал совершенное в прошлом действие, и конфиденциальная информация уже давно дошла до получателя. Конечно, можно предъявить претензии самому инсайдеру, но блокировать утечку таким способом невозможно.
Итак, программа PC Acme не только не обладает комплексностью, но и не препятствует утечке в принципе. Более того, журналы событий, которые ведутся каждым представленным в обзоре продуктом, всегда достаточно подробны, чтобы вычислить инсайдера постфактум и служить доказательством при его обвинении. Причем в этих журналах, в отличие от протокола PC Acme, зафиксированы действия лишь с конфиденциальными данными, а не все системные события подряд.
Можно было бы предположить, что продукт PC Acme подойдет для маленьких компаний, где за действиями, например десяти пользователей, вполне реально проследить, периодически проверяя журнал событий. Однако выделение функций IT-безопасности в отдельную должность офицера для малого бизнеса - это нонсенс.
Озабоченность бизнеса проблемами внутренней IT-безопасности и защиты своих информационных активов постоянно подтверждается исследованиями ведущих организаций. Согласно опубликованному в январе 2006 года отчету 2005 FBI Computer Crime Survey, 44% американских компаний пострадали в течение года в результате серьезных инцидентов, происходивших во внутренней IT-безопасности, при этом инсайдеры крали конфиденциальные документы работодателя, пытались исказить информацию с целью финансового мошенничества, выносили из офиса оборудование и т. д.
Не менее остро проблема стоит в России, что подтверждается результатами исследования "Внутренние IT-угрозы в России '2005", проведенного компанией InfoWatch среди 315 представителей отечественного бизнеса. По результатам опроса, опубликованным в конце января 2006 года, 64% респондентов считают кражу информации самой опасной угрозой IT-безопасности (см. диаграмму 1). Сравнивая этот показатель с прошлогодним, можно с уверенностью утверждать, что проблема защиты конфиденциальных данных не только сохранила актуальность, но и приобрела гораздо большее значение, нежели такие распространенные угрозы, как вирусные и хакерские атаки.
. Наиболее опасные угрозы IT-безопасности (Источник: InfoWatch)
Следует обратить внимание, что утечка чувствительных сведений, как угроза IT-безопасности, не всегда является результатом злого умысла. История хранит немало примеров, когда конфиденциальные данные утекали по нелепой случайности или банальной человеческой ошибке. Так, в марте 2005 года информация о 4,5 тыс. больных СПИДом пациентов медицинского учреждения в Палм-Бич, штат Флорида, и еще о 2 тыс. людей, тест на наличие ВИЧ у которых оказался положительным, была разослана не по тем адресам электронной почты. Как оказалось, сотрудник, обрабатывающий статистику в министерстве здравоохранения округа, настолько "заработался", что отправил конфиденциальные файлы нескольким сотням получателей, не имевших права доступа к подобной информации.
Таким образом, при оценке актуальности внутренних угроз следует учитывать не только формальную кражу чувствительных документов, но и халатность сотрудников, озабоченность которой высказали, согласно исследованию InfoWatch, 44% респондентов.
. Каналы утечки данных (Источник: InfoWatch)
Для дальнейшего обзора решений в сфере выявления и предотвращения утечек очень важен еще один результат, отмеченный в исследовании "Внутренние IT-угрозы в России 2005", а именно анализ путей утечки (см. диаграмму 2). В этой связи наиболее популярным способом кражи данных, по мнению российских компаний, являются мобильные носители (91%), электронная почта (86%), интернет-пейджеры (85%) и Всемирная паутина (веб-почта, чаты, форумы и т. д. - 80%). Сравнивая эти показатели с аналогичными за прошлый год, можно заметить, что мобильные накопители теперь опережают электронную почту. Судя по всему, популярность портативных устройств, предназначенных для хранения данных, возросла за прошедший год. В результате служащие осознали, что копирование информации на мобильный накопитель оставляет меньше следов, чем отправка писем через корпоративную почтовую систему (ведущую журнал событий), и не связано с аномальной активностью, которая часто привлекает внимание администратора при пересылке больших объемов данных по сети.
Несмотря на несколько разнородный индекс популярности различных каналов утечки, только комплексная защита, покрывающая все виды коммуникации, способна эффективно обезопасить информационные активы. Ведь ничто не помешает инсайдеру переключиться на сетевые каналы передачи данных, если компания возьмет под контроль порты и приводы рабочей станции. Именно принцип комплексности взят за основу при рассмотрении решений для борьбы с утечками.
. Схема работы InfoWatch Enterprise Solution
. InfoWatch Enterprise Solution с аппаратными модулями IWSA
Американская компания Verdasys поставляет комплексное решение Digital Guardian, предназначенное для выявления и предотвращения утечек прямо на уровне рабочих станций. Кстати, продукт невозможно упрекнуть в отсутствии комплексности, поскольку Digital Guardian покрывает все каналы утечки, делая это в тех местах, где информация используется.
Реализацией такого подхода являются программные агенты, устанавливаемые на персональные компьютеры и ноутбуки в организации. Агенты поддерживают работу в операционной системе Windows, а также в среде Citrix Metaframe и Microsoft Terminal Server. Агенты отвечают за ведение подробных журналов; за контроль над приложениями, коммуникациями и данными; выявление нарушений политики; за фильтрацию событий, записанных в журнал, перед отправкой на сервер Digital Guardian.
Точно так же, как в случае PC Acme, агент Digital Guardian невидим для пользователя, поэтому может быть внедрен удаленно и централизованно. Однако в отличие от PC Acme в составе Digital Guardian появляется сервер, куда агенты отсылают протоколы событий. Третьим компонентом продукта является консоль управления, к которой можно получить доступ по сети. Консоль позволяет составлять отчеты, собирать и анализировать информацию, контролировать инсталляцию агентов, управлять политиками и т. д. Архитектура решения проиллюстрирована на схеме 4.
. Архитектура Digital Guardian
Продукты Verdasys отличаются широким спектром сопроводительных услуг. Так, поставщик оказывает консалтинговые услуги еще до внедрения проекта, разрабатывает и внедряет предварительные проекты (например, создается экспериментальная группа рабочих станций, осуществляется мониторинг действий пользователей этих станций и анализируются результаты), активно участвует во внедрении продукта и тренингах персонала.
Тем не менее, Digital Guardian обладает двумя недостатками. Во-первых, он не развешает архивировать электронную корреспонденцию, что затрудняет расследование инцидентов IT-безопасности, усложняет процесс поиска инсайдера и не позволяет обеспечить соответствие с различными законам и нормативными актами.
Во-вторых, Digital Guardian не производит контентную фильтрацию отправляемого по сети трафика, поскольку фильтрация, вынесенная на уровне рабочей станции, требует огромного количества аппаратных ресурсов. К такому вполне логичному выводу пришли эксперты IDC (см. "Information Leakage Detection and Prevention: Turning Security Inside-Out"): фильтрацию, с использованием лингвистического анализа, другие поставщики осуществляют на выделенных серверах. Следовательно, агенты Digital Guardian в состоянии отличить чувствительные документы от не конфиденциальных только с помощью заранее заданного списка защищаемых объектов (или помеченных цифровыми водяными знаками, что не суть важно). Отсюда, если пользователь создаст новый документ и наполнит его чувствительными сведениями, например, в рамках подготовки отчета (ведь работу с буфером обмена контролируется агентами), такой документ останется уязвимым до тех пор, пока не будет внесен в список защищаемых объектов. Именно для того чтобы исключить подобную брешь, разработчики решений в сфере выявления и предотвращения утечек применяют контентную фильтрацию.
(по: Макклуре С., Скембрей Д., Куртц Д. Секреты хакеров. Проблемы и решения сетевой защиты. Пер. с англ. -- М.: ЛОРИ. 2001. 436 с.)
Анализ уголовных дел и иной доступной информации показал, что механизм совершения компьютерных преступлений состоит в следующем:
Осуществлению преступных действий в областях автоматизации производства и бухгалтерского учета способствует, прежде всего, слабая готовность персонала, обслуживающего технические средства обработки информации, отсутствие необходимых средств контроля и информационной защиты, отсутствие или неполная проработка концепции информационной безопасности организации, а также неадекватная реализация предписаний политики: неумение реализовать систему разделения доступа, обновления паролей и ключевых слов, а также неспособность или неподготовленность осуществить администрирование и настройку использующихся сетевых сервисов.
К нынешним автоматизированным банковским системам (АБС) предъявляются очень строгие требования как со стороны банков-пользователей, так и со стороны государственных и контролирующих органов. Производители АБС должны динамически подстраивать свою продукцию под изменяющиеся нормативы и отчетные требования, предъявляемые к ведению банковского бизнеса.
Практически все бизнес-процессы финансового учреждения связаны с обработкой или пересылкой некоторой информации. Сейчас вряд ли найдется банк, не автоматизировавший процесс работы с бизнес-информацией. Постоянно растет число банков, использующих Интернет и удаленный доступ к своим системам.
Только комплексная информационная банковская система, интегрирующая различные сферы деятельности банка, способна полностью автоматизировать и объединить в единое целое бизнес-процессы финансового учреждения. Работа с клиентами, начисление процентов, предоставление всевозможных банковских услуг должны быть увязаны с внутрихозяйственной деятельностью банка, с бухгалтерией. Комплексная система, поддерживающая централизованную обработку, мультивалютность и автоматизацию основных финансовых операций, позволяет эффективно проводить управление, контроль, получение отчетов о текущей деятельности всех филиалов банка.
Прежде всего АБС является инструментом управления бизнесом. Среди функций, присущих современным комплексным АБС, можно выделить следующие:
Приведенные основные функции АБС реализуются посредством следующих технологий:
Среди первоочередных эксплутационных требований, предъявляемых АБС, в первую очередь хотелось бы выделить надежность и безопасность. Сбой программного обеспечения (ПО) или злоумышленное вторжение в территориально-распределенную банковскую информационную систему могут иметь очень печальные последствия, характеризуемые количественно (величиной ущерба) или качественно (падением имиджа, срывом переговоров и т. п.).
Многочисленные попытки взломов и успешные нападения на банковские вычислительные структуры и порталы остро ставят проблему обеспечения информационной безопасности.
Среди компонентов, образующих АБС, выделим следующие, реализуемые путем использования общедоступных сетей:
Доступ к сервисам, которые предоставляет данное программное обеспечение, осуществляется через открытые сети, использование которых таит в себе многочисленные информационные угрозы.
Наиболее часто информационное пространство банковской системы используется для передачи сообщений, связанных с движением финансов.
Для предотвращения этих злоупотреблений используются следующие средства защиты:
В общедоступных сетях распространены нападения хакеров. Это высококвалифицированные специалисты, которые направленным воздействием могут выводить из строя на длительное время серверы АБС (DoS-атака) или проникать в их системы безопасности. Практически все упомянутые угрозы способен реализовать хакер-одиночка или объединенная группа. Хакер может выступать как в роли внешнего источника угрозы, так и в роли внутреннего (сотрудник организации).
(by Andrew Tridgell) обнаруживает и пытается войти в разделяемые ресурсы, применяя задаваемые пользователем списки имен и паролей
Сканирует заданный диапазон ip на наличие расшаренных ресурсов. Имеет возможность подборки пароля
(Brandenburg University of Technology, Германия) клиент--серверная архитектура, предназначена для обнаружения подозрительной активности в локальных сетях AUBAD Automated User Behavior Anomaly Detection system (Австралия) обнаружение атак с использованием нейросетей GASSATA Genetic Algorithm for Simplified Security Audit Trail Analisys
(Ренский университет, Франция) анализ событий, получаемых из журнала регистрации ОС AIX, используется генетический алгоритм EMERALD
(SRI) Event Monitoring Enabling Responses to Anomalous Live Disturbances ориентирована на работу в крупных, распределенных сетях Defence Wall широкий набор утилит для борьбы с вторжениями Nessus
(Университет Калифорнии) система обнаружения атак в реальном режиме времени, использующая контроль состояний переходов NIDES
(SRI) использует статистический подход, определяющий отклонения от профиля нормального поведения пользователя. NNID Neural Network Intrusion Detector
(ISS) нейросетевой детектор атак, объединение нейросетевых технологий с системой обнаружения атак RealSecure Network Sensor Online Scanner и Desktop Scanner
(ISS) защита пользователей, подключающихся к интернет-банку NFR Network Flight Recorder
содержит интерпретируемый язык N-Code, ориентирован на компании малого и среднего размеров Centrax (CyberSafe) ETrust IDS (Computer Associates)
ориентирована на средства защиты, предоставляемые фирмой Cisco Dragon (Enterasys Network)
Примечание. SRI -- Stanford Research Institute ISS -- Internet Security Systems
При разделении нарушителей безопасности по классам можно исходить из его принадлежности определенным категориям лиц, мотивов действий и преследуемых целей, характера методов достижения поставленных целей, квалификации, технической оснащенности и знаний об атакуемой информационной системе.
Прежде всего разделим нарушителей на внутренних и внешних. По данным многих источников и статистических исследований, отношение внутренних инцидентов к внешним оценивается примерно в 75%. Мы бы рассматривали в данном случае классическую пропорцию 80 к 20, так как факты многочисленных нарушений часто скрываются организациями или для поддержания имиджа приписываются внешним источникам.
Потенциально к внутренним нарушителям относятся сотрудники самого банка или сотрудники организаций из сферы ИТ, предоставляющие банку телекоммуникационные и иные информационные услуги.
Среди причин, побуждающих сотрудников к неправомерным действиям, можно указать следующие:
Для предотвращения нарушений необходимо проводить специальную подготовку персонала, поддерживать здоровый рабочий климат в коллективе, проводить тщательный отбор нанимаемых сотрудников, своевременно обнаруживать злоумышленников.
По рекомендации экспертов в области информационной безопасности, особое внимание следует обращать на вновь принимаемых сотрудников в следующих профессиях: администраторы, программисты, специалисты в области компьютерной техники и защиты информации. Известны случаи внедрения сотрудников, работающих на конкурентов, поступления на работу хакера-одиночки или представителя хакерской группы. Чрезвычайную опасность представляют специалисты подобного уровня при вхождении в сговор с руководством подразделений и службы безопасности банка, а также с организованными преступными группами. В данном случае возможный ущерб и тяжесть последствий многократно увеличиваются.
Руководство банка, должно четко себе представлять, от каких видов нарушений необходимо защититься в первую очередь.
Типы нарушителей могут сильно отличаться, варьироваться по составу, возможностям и преследуемым целям. От одиночного нарушителя, действующего удаленно и скрытно, до хорошо вооруженной и оснащенной силовой группы, действующей молниеносно и напролом. Нельзя не учитывать возможности сговора между нарушителями, относящимися к различным типам, а также подкупа и реализации других методов воздействия.
Далее классификацию можно проводить по следующим параметрам.
Для защиты вычислительных сетей от злоумышленного воздействия необходимо использовать программные и программно-аппаратные комплексы и системы обеспечения информационной безопасности. Для организации защиты от внешней потенциально враждебной информационной системы используются межсетевые экраны, системы построения виртуальных частных сетей (VPN), защищенные каналы передачи данных (протоколы SSL, SOCKS, IPsec), криптографические средства (ГОСТ, AES, RSA и др.), протоколы распределения ключей и сертификаты (Х.509, SKIP, ISAKMP, PKCS, PEM и др.), системы аутентификации пользователей (PAP, S/Key, CHAP) и удаленного доступа (TACACS и RADIUS). Более подробная информация имеется в: Вакка Дж. Секреты безопасности в Internet. -- Киев: "Диалектика", 1997. -- 505 с., и Зима В. М., Молдовян А. А., Молдовян Н. А. Безопасность глобальных сетевых технологий. -- СПб.: БХВ-Петербург, 2000. -- 320 с., а также в других книгах по рассматриваемой тематике.
Наиболее распространенные и доступные программы для реализации атак и защиты от них, а также базы данных и списки уязвимостей приведены . Одна и та же программа в руках администратора защиты выступает в роли средства обеспечения информационной безопасности системы, а в руках злоумышленника становится грозным оружием для осуществления атаки или сканирования сети при проведении подготовки к атаке. По этой причине один и тот же продукт может присутствовать одновременно в двух списках.
Итак, правильное построение модели нарушителя позволяет проектировать и реализовывать систему обеспечения защиты информации в вычислительных системах банка адекватно имеющимся угрозам.
-- докт. техн. наук, профессор кафедры ВМСС МЭИ.
-- аспирант кафедры ВМСС МЭИ.
Хакеры буквально творят произвол во всемирной Сети. Они воруют номера кредитных карточек. Получают доступ к закрытым базам и оперируют со счетами пользователей. Используют информационные и сетевые ресурсы для изощренных атак. Чаще всего доступ к Интернету они также получают за счет кого-то. Они занимаются рассылкой спама и внедрением вредоносных программ на различные компьютеры в сети. Они собирают и взламывают пароли от чужих машин и систем, чтобы получить к ним полный доступ: завладеть секретной информацией, скопировать ее, удалить или модифицировать. Хакеры перехватывают и перенаправляют сетевой трафик. Устраивают настоящую войну с крупными сайтами в сети Интернет. И чаще всего не ради наживы, а ради развлечения или самоутверждения.
В результате хакерских атак может причиняться крупный ущерб, чаще всего они носят организованный характер и нередко среди соучастников могут быть представители собственного персонала. Кроме того, информационным атакам и вторжениям присуща высокая степень латентности (малый процент -- меньше 10% выявления преступлений).
Хакеры могут встраивать троянские программы, которые превращают пораженную машину в "компьютер-зомби", который совершает различные действия по указке хакера, выходя из-под контроля. Такие пораженные системы могут использоваться для дальнейшего развития атак на машины в сети и их заражения.
Действия хакеров могут нанести существенный ущерб имиджу компании, если сайт банка или его информационная система не будут должным образом работать по причине действий хакеров, если на сайте будет размещена посторонняя информация (тем более экстремистские лозунги или порнография).
В настоящее время хакеры объединяются в группировки, современное развитие коммуникационных технологий позволяет им моментально обмениваться информацией об обнаруживаемых уязвимостях, распространять программную продукцию, позволяющую взламывать корпоративные сети и веб-серверы. Интернет позволяет хакерам успешно объединяться в виртуальном пространстве, при этом оставаясь недосягаемыми в физическом.
Наиболее опасными и сильными хакерами могут стать представители военных ведомств и спецслужб различных государств. Эти ведомства обладают мощными компьютерами и высокопроизводительными пропускными каналами связи. Следует учесть, что в ведомствах могут работать недобросовестные сотрудники, которые заинтересованы в подрыве репутации или нанесении ущерба добросовестным банкам.
Существенную угрозу несут в себе вредоносные программы -- вирусы и трояны. Распространяясь по всемирной Сети, они, используя небезопасные настройки коммуникативных программ, в том числе защищенных протоколов, могут поражать банковские вычислительные системы.
В свободном доступе находится множество программ и утилит, автоматизирующих поиск и использование уязвимостей атакуемой системы.
Интернет позволяет передавать конфиденциальную информацию практически в любую точку мира, но передаваемые данные необходимо защищать как в плане конфиденциальности, так и в плане обеспечения подлинности, иначе они могут быть искажены или перехвачены. Интернет-систему необходимо защищать от подлога, несанкционированного изменения, разрушения, блокирования работы и т. д.
Для обеспечения высокого уровня информационной безопасности вычислительных систем рекомендуется проводить следующие процедуры при организации работы собственного персонала:
Security Watch -- раздел по защите в журнале Info World Стюарта Макклюра и Джоела Скембрея
защищает компьютер от падений системы, последствий вирусных атак, некорректных инсталляций, позволяя легко вернуться к той конфигурации, в которой компьютер надежно работал
обнаруживает факт установки анализатора протоколов и попытки изменения правил МЭ (межсетевого экрана)
Чаще всего строится неформальная модель злоумышленника (нарушителя), отражающая причины и мотивы действий, его возможности, априорные знания, преследуемые цели, их приоритетность для нарушителя, основные пути достижения поставленных целей -- способы реализации исходящих от него угроз, место и характер действия, возможная тактика и т. п. Для достижения поставленных целей нарушитель должен приложить определенные усилия и затратить некоторые ресурсы.
Чаще всего теоретически применяется теория игр, когда для создания защитной системы используется матрица угроз/средств защит и матрица вероятностей наступления угроз. У злоумышленника существует своя собственная матрица нападений (ценностей), в общем случае эта матрица может не совпадать с матрицей защищающейся стороны. Пользователь системы также может стать нарушителем безопасности.
Определив основные причины нарушений, представляется возможным оказать влияние на эти причины, или необходимым образом скорректировать требования к системе защиты от данного типа угроз. Вопросы безопасности вычислительных систем большей частью есть вопросы человеческих отношений и человеческого поведения. При анализе нарушений защиты необходимо уделять внимание субъекту (личности) нарушителя. Устранение причин или мотивов, побудивших к нарушению, в дальнейшем может помочь избежать повторения подобного случая.
Модель может быть не одна, целесообразно построить несколько отличающихся моделей разных типов противников информационной безопасности банка.
Для построения модели нарушителя используется информация от служб безопасности и аналитических групп о существующих средствах доступа к информации и ее обработки, о возможных способах перехвата данных на стадии передачи, обработки и хранении, об обстановке в коллективе и на объекте защиты, сведения о конкурентах и ситуации на рынке, об имевших место свершившихся случаях хищения информации и т. п.
Кроме этого, оцениваются реальные оперативные технические возможности злоумышленника для воздействия на систему защиты или на защищаемый объект. Под техническими возможностями подразумевается перечень различных технических средств, которыми может располагать злоумышленник в процессе совершения действий, направленных против системы информационной защиты.
(by Hobbit) универсальный сканер сетевых портов с большим набором различных операций
(Elcom) достаточно большое количество утилит, которые взламывают пароли к архивам ARJ, RAR, ZIP и документам Microsoft Office различных версий
Наиболее популярные современные утилиты для проведения сетевых атак. В список попали как инструменты защиты, так и хакерские программы, а также сайты, содержащие средства и информацию по этой теме. Не отмечены утилиты, входящие в стандартный комплект операционных систем (их можно найти в Windows NT Resource Kit или в SupplementII).
Анализатор сетевых протоколов. Прослушивание сетевого трафика.
Автоматический поиск интересующей информации в пакетах, передающихся в сети DSniff
мощная утилита для перехвата паролей и другой информации, передаваемой в сети Ethereal
обычный "сниффер" для UNIX-систем с отличным, надо сказать, графическим интерфейсом FireWalk
(Mike Schiffman) в режиме сканирования портов выявляет открытые порты за брандмауэром Hping
(Salvatore Sanfilippo) сканирование сквозь брандмауэры. Анализ ответов TCP Linsniff
(Brecht Claerhout) простой сыщик пакетов для Linux, SunOS, Solaris, FreeBSD, Irix Solsniff
(Michael R. Widner) сыщик, модифицированный под Sun Solaris 2.x Tcdump
(группа авторов) классический анализатор пакетов, реализован для различных платформ TCP Logger
(Михаил Калинский) Предназначен для исследований протоколов, работающих на основе протокола TCP (http, pop3, smtp и т. д.), а также для исследований серверов, сервисов, скриптов и т. д. Для Windows
(ISS) система анализа защищенности на уровне СУБД (MS SQL Server, Sybase, Oracle)
из NTRK, выводит mac-адреса сетевых адаптеров удаленных компьютеров Netdom из NTRK, информация о подключенных доменах NT
(by Jesper Luaritsen) мощное средство получения списка узлов домена и работающих в нем служб
полностью автоматический сканер расшаренных ресурсов, осуществляющий самостоятельное копирование файлов. Может работать в скрытом режиме, а также самостоятельно добавлять себя в автозапуск
сканирует порты на расшаренные ресурсы и подключает их. В данной версии возможна совместная работа с подборщикам паролей, если таковые требуются при попытке подключить сетевой диск
EssentialNetTools сканер на наличие расшаренных ресурсов. Однако включает в себя также еще несколько возможностей, не существующих в SMBscanner или Xsharez
(Дмитрий Кривов) аналог BackOrifice для Windows, но на русском языке и с простым интерфейсом
Для получения подробной информации о существующих вредоносных программах читатели могут использовать Интернет-ресурс (AVP) -- обширную энциклопедию существующих вирусов и троянских коней. Информацию о средствах борьбы с вирусоподобными программами можно найти, например, в классификаторе-поисковике Yandex. Каталог/Компьютеры и связь/Безопасность/Вирусы и антивирусы)
BindView Cgi-founder - предназначена для облегчения поиска известных CGI-уязвимостей. Файл cgi-exp.dat содержит 53 exploit'а, можно добавлять свои. В архиве есть инструкция на русском языке Cheops - утилита с графическим интерфейсом, универсальный мощный инструмент картографирования сети Chknull CyberCop Scanner от NAI - система анализа защищенности, может быть использована для сканирования сети Firewalk от Mike Schiffman Fping Fremont HackerShield от BindView Hping InspectorScan от Shavlik Internet Scanner от ISS - обнаруживает более 900 различных уязвимостей InterNetView - программа сканирования сети. Работает под Windows 95/98/NT ipEye - stealth-сканер, конкурент Nmap Kane Security Analyst Lan Auditor Network Mapper (nmap) от Fyodor NTInfoScan - удаленное идентифицирование ОС и открытых портов Pinger PortPro и Portscan - самые быстрые сканеры дляWindows NT QueSO RuNmap The Russian Network Mapper Saint - программа-"убийца" средств защиты сети, основанная на небезызвестном сканере SATAN SATAN (Security Administrator Tool for Analyzing Networks) - сканирование сетевых портов. Поиск уязвимостей в сети, которые могут быть использованы для реализации атак ShadowSecurityScanner Solarwinds Strobe (by Julian Assange) - один из самых быстрых и надежных сканеров TCP/IP Tkined (утилита из пакета Scotty) сетевой редактор, позволяющий исследовать сети IP Udp scan (by Dan Farmer& Wietse Venema in 1995) производная от SATAN, наиболее надежный UDP-сканер, правда, легко обнаруживаемый WebTrends Security Analyzer от WebTrends Whisker - сканирование веб-серверов, выявление уязвимых CGI-сценариев WS_Ping ProPack
http://www.cert.org/reports/dsit_workshop.pdf http://www.cert.org/advisories/CA-99-17-denial-of-service-tools.html tml
http://packetstorm.security.com/distributed/ http://staff.washington.edu/dittrich/misc/ddos/ Опасные утилиты в UNIX:
net view -- позволяет получить список доступных в сети доменов nltest из NTRK (NT Resource Kit) -- перечень контроллеров домена NT
Особенностью сетевых решений, объединенных торговой маркой ViPNet, является то, что, с одной стороны, это -- высокоэффективные средства создания и управления VPN (поддержка мобильных и удаленных пользователей в корпоративной VPN; объединение нескольких локальных сетей в одну глобальную).
С другой стороны, это -- интегрированные с ними средства защиты сети в целом, ее сегментов и каждого клиента сети в отдельности (защита TCP/IP-трафика, создаваемого любыми приложениями и программами; защита рабочих станций, серверов WWW, баз данных и приложений; защищенные автопроцессинг и транзакции для финансовых и банковских приложений, платежных систем - firewall.ru).
Getadmin программа для получения несанкционированного доступа к компьютеру, на котором она запущена (локальное проникновение)
Black Ice от Network Ice CyberCop Monitor от Network Associates Hidden Object Locator Ippl ITA oт AXENT Kane Security Monitor Netguard Network Flight Recorder Protolog Psionic Porlsentry из проекта Abacus RealSecure jn Internet Security Systems (ISS) Scanlogd Secured oт Memco Secure Shell (SSH) Session Wall-3 от Abir net/Platinum Technology
A.O.H.P.
(Symantec) дистанционный поиск уязвимостей на различных узлах корпоративной сети
удобная маленькая программа, которая позволяет отслеживать все соединения, очень помогает как при диагностике сетей, так и при настройке брандмауэра
мониторинг портов и перехват атак Nuke и прочих подобных атак, логирует время и IP-адрес нападавшего
помимо идентификации атаки и атакующего отправляет письмо администратору сети, из которой проводится атака
не имеет графического интерфейса, высококвалифицированному специалисту предоставляет широкий набор функций
система поддержки принятия решений в области информационной безопасности. Сбор, анализ и корреляция данных от различных средств защиты, установленных в организации. Прогнозирование изменения уровня защищенности
Очень хороший сканер безопасности. Незаменим как для админов, так и для тех, кто желает взломать какой-нибудь сервер. Выдает подозрительные на уязвимость скрипты, дыры, а также ссылку на сайт с подробным описанием найденной уязвимости и т. д.
сканер безопасности, работает чуть быстрее Xspider'a. Содержит в себе огромное количество функций. Создает удобные отчеты в формате HTML
средство контроля внешней электронной почты, получаемой и передаваемой по протоколу SMTP
средство контроля внутренней электронной почты, получаемой, передаваемой и обрабатываемой (в том числе и хранимой) с помощью Lotus Domino
средство контроля внутренней электронной почты, получаемой, передаваемой и обрабатываемой (в том числе и хранимой) с помощью MS Exchange
средство контроля и разграничения доступа к Вебу, включая защиту от утечки конфиденциальных материалов через бесплатные интернет-сервисы (например, mail.ru, чаты и доски объявлений)
средство контроля передаваемых в электронной почте порнографических картинок (дополнение к MAILsweeper)
SECRETsweeper средство контроля передаваемых в электронной почте зашифрованных сообщений, нарушающих политику безопасности компании (дополнение к MAILsweeper)
Сканер сетей класса B проверяющий веб-серверы MS IIS 4.0, 5.0, 6.0 (NT, 2000, XP) на наличие уязвимости
Универсальное средство очистки системных кэшей, временных файлов, истории просмотра/запуска файлов и т.д.
Somarsoft (dumpacl, dumpreg и т. д.)
Статья была опубликована в журнале "Банковские технологии" и на сайте Cryptography.Ru
А. Березин, ОАО "ЭЛВИС-ПЛЮС"
Обсуждение проблемы обеспечения информационной безопасности (ИБ) бизнеса становится все более и более популярной темой в различных "околокомпьютерных" СМИ. Как правило авторы статей изощряются в описании различных решений, анализируют преимущества и недостатки известных продуктов и технологий, описывают новые подходы и методики и т.д. При этом как-то само-собой разумеющимся и потому остающимся за кадром является тезис о том, что данная проблема актуальна и ею безусловно необходимо заниматься. В тени остается вопрос о том, каковы же собственно интересы Бизнеса в решении этой проблемы? Ведь стандартного тезиса о том, что критичная для Бизнеса информация должна быть доступной, целостной и конфиденциальной явно недостаточно, учитывая, что информация - понятие достаточно эфемерное; угрозы безопасности такой информации носят сугубо вероятностный характер (а как известно, пока гром не грянет, мужик не перекрестится, т.е. в данном случае руководство денег не даст), а технические и организационные решения по безопасности стоят очень конкретные, и немалые кстати, деньги!
Видимо, объяснение указанному явлению кроется в том, что обсуждается данная проблема в основном на уровне технических специалистов или специалистов, имеющих явные "технические корни". А как раз на данном уровне проблема осознана, наверное, уже в максимальной степени. Ведь кто, как не системный администратор может знать, что можно сделать с его сетью, если в нее проникнет недружественная личность с вандалистскими наклонностями? Или разрушающий программный код? Или если выйдет из строя какой-то базовый элемент корпоративной информационной системы (КИС)? Технический специалист также хорошо знает, что можно сделать с потоком данных, если его перехватить. И т.д. и т.п. Но с уровня бизнес-управления компанией этих угроз "не видно", поэтому осознание проблемы обеспечения безопасности информации КИС весьма и весьма туманное. Зато вполне осознанны другие категории: зачем тратить деньги на систему, полезность которой для бизнеса далеко не очевидна? Более того, часто можно услышать такой вопрос: А зачем нам вообще нужна информационная безопасность? На этом же нельзя заработать! Или, говоря языком бизнеса, зачем нам создавать еще один затратный центр? Их у нас и так слишком много! И с этими аргументами достаточно трудно спорить.
Особенно, если не иметь контраргументов, понятных Бизнесу. К сожалению, часто российские CIO (или директора по автоматизации; или начальника департамента информационных технологий) таких контраргументов и не имеют, хотя внутренне совершено уверены в необходимости решения данной задачи. В чем же причина?
Начнем с того, что опишем портрет типичного российского CIO. В большинстве случаев это люди с хорошим техническим образованием, большим опытом работы в отделах АСУ, прекрасно разбирающиеся в ИТ, обладающие прекрасной эрудицией в широкой предметной области, которые за годы работы в организации выросли от рядового инженера до CIO. Другими словами, это люди с теми же самыми "техническими корнями", для которых проблема ИБ очень и очень понятна. И решение проблемы они, как правило, видят тоже исключительно на техническом уровне в виде создание технической системы ИБ с набором стандартных элементов: антивирусы, межсетевые экраны, VPN, сервера доступа и др. Но язык Техники не понятен Бизнесу, равно как и язык Бизнеса далек от языка Техники. А потому для обоснования перед руководством необходимости потратить деньги на безопасность оперировать чисто техническими понятиями совершенно бесперспективно. Вас все равно не поймут! И выхода из такой ситуации для CIO всего два: либо научить технике директора, либо самому освоить язык бизнеса и на нем попробовать убедить руководство в своей безусловной правоте. Как это не странно, первый путь очень даже популярен, хотя в данном контексте хорошо видна его абсурдность.
Итак, что же нужно сделать CIO, чтобы убедить руководство в необходимости воспринимать информационную безопасность как один из корпоративных бизнес-процессов? Или, другими словами, как представить ИБ с точки зрения бизнеса?
Начнем, так сказать, "от печки", т.е. попробуем определить бизнес-задачу ИБ. Одним из основных двигателей рынка автоматизации бизнеса является стремление самого бизнеса стать более эффективным за счет использования современных ИТ.
Такое стремление понятно: не так уж много осталось реальных механизмов повышения конкурентоспособности, и все они в основном уже исчерпаны, а ИТ предлагают поистине неограниченные возможности. В том, что в автоматизации бизнеса заложен огромный потенциал для его динамического развития не сомневается сегодня, наверное, уже никто. Для этого достаточно сравнить эффективность и оперативность работы, например, корпоративной электронной почты с толпой бегающих по коридорам секретарш, качество и сроки разработки сложных технических систем с помощью CAD/CAM/CAE-систем и с помощью традиционного кульмана и др. Можно сказать, что бизнес-задача КИС, как и любой другой технической системы, состоит в том, чтобы упростить, ускорить или сделать более удобными ранее рутинные, и потому медленные и изобилующие ошибками бизнес-процессы. Или, если говорить более строго, любая действующая в интересах бизнеса техническая система в принципе должна предоставлять бизнесу какой-то тип сервиса. Такой сервис может быть самым разнообразным: доменная печь "оказывает услуги" по выплавке стали, транспортный цех - по транспортировке грузов, заводская столовая - по питанию сотрудников и т.д. Также и КИС, будучи сугубо технической системой, оказывает бизнесу свой тип сервиса - в данном случае сервис ИНФОРМАЦИОННЫЙ. И этот сервис заключается в конечном итоге в предоставлении Бизнесу необходимой ему ДЛЯ ПРИНЯТИЯ РЕШЕНИЙ Информации нужного качества, в нужное время и в нужном месте! Т.е. в конечном итоге Информации ДЛЯ УПРАВЛЕНИЯ самим бизнесом!
По сути Информация постепенно становится одним из ключевых элементов бизнеса! Ведь что такое Информация с точки зрения Бизнеса? По сути - это не что иное как некий набор формализованных (в смысле структурированных, разложенных по полочкам и имеющих средства для поиска и представления) знаний Бизнеса О САМОМ СЕБЕ! Причем в данном случае под Информацией можно понимать не только какие-то статичные информационные ресурсы, например, бухгалтерский баланс за прошедший год или текущие настройки какого-то оборудования, но и динамические информационные процессы обработки знаний в виде запрограммированной бизнес-логики работы компании в среде таких популярных приложений как электронный документооборот, ERP, CRM, службы каталогов и др.
Времена Генри Форда, когда управляющий компанией сам привинчивал гайки на конвейере, давно ушли в лету. Сегодня высшее руководство любой компании по существу имеет дело ТОЛЬКО с информацией, на основе которой оно и принимает решения. Понятно, что эту самую информацию готовят множество нижестоящих слоев достаточной сложной пирамиды, которая называется современным предприятием. И что нижние слои этой пирамиды вообще могут не иметь понятия о том, что они производят не только какую-то продукцию или услугу, но и Информацию для руководства. По нашему мнению, глубинный смысл автоматизации бизнеса и заключается как раз в том, чтобы ускорить и упорядочить информационные потоки между слоями этой пирамиды и представить на самый верх только самую необходимую, достоверную и структурированную в удобной для принятия решения форме Информацию!
Заметим, Информацию ДОСТОВЕРНУЮ! Отсюда можно заключить, что ключевой бизнес-задачей корпоративной системы ИБ является обеспечение гарантий достоверности информации, или, говоря другими словами, гарантий ДОВЕРИТЕЛЬНОСТИ информационного сервиса КИС!
А теперь попробуем провести следующий виртуальный эксперимент. Давайте сначала спросим Бизнес: Готов ли он потратить, скажем, сто тысяч долларов на закупку, например, пяти межсетевых экранов и ста лицензий на антивирусное ПО? А потом зададим тот же самый вопрос по-другому: А готов ли Бизнес потратить сто тысяч долларов на защиту информации о самом себе и на защиту сервиса, на котором основано управление компанией? Скорей всего ответ в первом случае прогнозируем: либо традиционное для России "денег нет", либо по-одесски вопросом на вопрос: А зачем? Во втором случае вариации ответов пошире: В какие сроки управимся? А где ты раньше был? И даже: Почему так мало? Разве мой бизнес столько стоит?
Но будет и вопрос, который любой нормальный Бизнес просто обязан будет задать: А почему именно сто тысяч? А не пятьдесят, или, скажем, не четыреста семьдесят две? И в таком случае наш уважаемый CIO должен быть готов дать понятый Бизнесу ответ, аргументированный необходимыми экономическими выкладками.
Т.е. по сути представить обоснование стоимости системы ИБ для Бизнеса.
Такой анализ, безусловно, возможно провести. Внимательный российский CIO наверное уже заметил, что в последнее время в печати все чаще и чаще начинают возникать новые для ИБ темы: анализ угроз ИБ, анализ информационных рисков, оценка совокупной стоимости владения системой безопасности, оценка возврата инвестиций от такой системы и т.д. Все это в виде метрики безопасности представляет собой некий экономический инструментарий, преломленный в область ИБ, который и позволяет ответить на вопрос: А почему сто тысяч? И еще это яркий показатель того, что наиболее "продвинутые" CIO уже пытаются на него ответить.
Автор не ставит своей целью даже кратко описать этот инструментарий, поскольку, во-первых, рамки журнальной статьи не позволяют обсудить эту тему достаточно серьезно, а во-вторых, заинтересованному CIO сегодня несложно найти специализированную информацию на эту тему. В том числе и на русском языке. Кроме того, уже многие российские ИТ-компании успешно предлагают консалтинговые услуги по оценке метрики безопасности. Однако, хочется обратить внимание CIO на несколько очень важных моментов, которые необходимо иметь в виду при знакомстве с данным инструментарием или при проведении переговоров с консалтинговыми компаниями. Но для этого нам придется несколько отвлечься от намеченной темы.
Попробуем найти достаточно близкую аналогию с системами ИБ в области нашей повседневной жизни. Возьмем, например, "старый добрый" сейф. И представим типичную для большинства компаний ситуацию: главному бухгалтеру необходимо хранить у себя в кабинете крупные суммы наличных денег или каких-то других ценностей. В ворах и грабителях у нас, к сожалению, дефицита нет, поэтому главбух разумно желает эти ценности как-то защитить и автоматически приходит к идее поставить в кабинете сейф. Знакомо? Еще как! Далее гдавбух идет с директору и просит его выделить деньги на покупку сейфа. Трудно представить себе ситуацию, когда директор вдруг скажет, что на это денег нет.
Скорей всего это просто не придет ему в голову, ибо деньги должны лежать в сейфе - это аксиома! Поэтому директор деньги выделит. Вопрос: сколько? Опять же трудно представить себе ситуацию, когда директор попросит главбуха подготовить экономическое обоснование оптимальной стоимости сейфа, провести оценку возврата инвестиций от покупки сейфа и т.д. Но мы предположим, что все-таки попросит. И главбух в глубокой задумчивости начнет размышлять: 1) по законам арифметики потенциальный ущерб от отсутствия сейфа в конторе равен той сумме, которую могут выкрасть потенциальные воры минус стоимость самого сейфа; 2) если стоимость сейфа еще можно как-то оценить, то как оценить ту сумму, которая потенциально будет лежать в кабинете бухгалтера В ТОТ САМЫЙ ДЕНЬ? А когда наступит ЭТОТ ДЕНЬ? А как объективно оценить, сколько раз случиться ограбление? А может ли случиться такое, что ограбления не случиться и при отсутствие сейфа? И т.д. и т.п. Поэтому, скорей всего, найти правильно обоснование оптимальной стоимости сейфа ему вряд ли удастся и на покупку сейфа, КАК ОБЫЧНО, будет выделено столько денег, сколько покажется разумным на тот момент.
Наконец, сейф куплен, установлен и эксплуатируется. Но, к сожалению, наш главбух оказывается рассеянной личностью и он вводит в код замка сейфа дату своего рождения; или ключ от сейф кладет под газетку на его крышку; или иногда просто забывает его закрывать. И однажды сейф успешно опустошают.
Из такого "лирического" отступления можно сделать три важных для нас наблюдения, которые вкупе условно можно назвать "законами сейфа":
Защита систем и коммуникаций: защита общедоступных систем. Информационная система обеспечивает целостность данных и приложений для общедоступных систем.
Лазерный диск с нулевым треком как средство защиты от копирования
, журнал CODE
Задумывались ли вы, почему нумерация треков лазерных дисков начинается с единицы, а не с нуля? Ведь говорят, чтобы отличить программиста от простого смертного достаточно дать ему команду "рассчитайсь!". Нормальный человек скажет "первый" (если он действительно первый) и будет по-своему прав. Программист же сначала уточнит в какой системе исчисления вести расчет (в двоичной, восьмеричной, шестнадцатеричной…) и затем, сделав шаг вперед, гордо скажет "нулевой". "Так ведь лазерные диски изначально разрабатывались для пользователей! – ответите вы. – А пользователи более привычны к натуральной, а не позиционной системе исчисления и потому первый трек должен быть именно первым, но никак не нулевым".
И все же, несмотря на всю убедительность своих доводов, вы будете не правы. Отсчет треков всякого диска начинается не с единицы, но с нуля. Да, нулевой номер зарезервирован за служебным треком (вводной областью диска) и его содержимое недоступно на интерфейсном уровне, но это ничего не меняет! Поле TNO (Track Number) Q-подканала Lead-In области диска равно нулю, следовательно, с точки зрения привода всякий диск начинается с трека номер ноль. Электронная начинка привода читает и адресует нулевой трек точно так же, как и любой другой трек диска, сохраняя тем самым прозрачность и упорядоченность принятой системы нумерации. С точки зрения системных программистов, разрабатывающих микропрограммные прошивки, отсчет треков всегда начинается с нуля. С точки же зрения пользователей привода – с единицы. Одним словом, и волки сыты и овцы целы!
Атрибуты нулевого трека отсутствуют в TOC, поскольку этот трек как раз и служит для хранения TOC. Давайте задумаемся, что произойдет, если одному из point'ов подлинного или фиктивного трека мы присвоим значение ноль, то есть, попросту говоря, создадим еще один нулевой трек в пользовательской области диска?
Если помимо внесения подложных данных в TOC мы еще и скорректируем содержимое Q-канала подкода, забив поле TNO нулями, то с точки зрения привода такой трек будет неотличим от вводной области диска и попытка его посекторного чтения будет обречена на провал (хотя некоторые приводы и не такое читают).
Субканальные данные нулевого трека теоретически должны быть доступны для чтения командами SEEK/READ SUBCHANNELL, но никаких гарантий на счет этого у нас нет, поскольку наличие двух подряд идущих Lead-In областей сильно нервирует привод, и его реакция становится совершенно непредсказуемой. Отказ от восстановления субканальных данных мало что меняет. Одно лишь наличие нулевого point'a в TOC'е – событие вполне неординарное и взаимно противоречивое.
Большинство приводов просто свихнутся и откажутся обрабатывать такой диск, совершенно непредсказуемым образом осуществляя чтение его оглавления. В частности, NEC при выполнении команды READ TOC возвращает ошибку, ASUS воспринимает нулевой трек как индикатор завершения TOC'а, а TEAC, столкнувшись с нулевым треком, начинает очень сильно нервничать и вместо атрибутов всех последующих треков выплевывает содержимое своих внутренних буферов вместе с мусором, оставшимся от TOC'а предыдущего диска. Короче говоря, нулевой трек делает лазерный диск практически полностью нечитабельным.
На этом, собственно, можно было бы и остановиться (кому нужна жутко конфликтная защита, работающая исключительно в лабораторных условиях и крайне нежизнеспособная на практике?!) если бы не одно "НО". Стремительное падение цены на оптические носители позволяет использовать лазерный диск не только для хранения полезной информации, но и в качестве своеобразного ключа.
Весь фокус в том, что наличие нулевого трека на диске никак не препятствует чтению субканальных данных спиральной дорожки, но подавляющее большинство копировщиков (включая Алкоголь и Clone CD) скорее зависнут, чем скопируют такой диск! Таким образом, алгоритм работы защитного механизма сводится к "ручному" чтению TOC'а командами SEEK/READ SUBCHANNEL с последующей проверкой его содержимого на предмет наличия нулевого трека.
И хотя ключевой диск не может содержать никаких других данных, кроме собственно самого проверяемого TOC'а, – это ли беда? В каком-то смысле это даже достоинство.
Пусть на одном лазерном диске, никак не защищенном от копирования, содержится демонстрационная версия программы, свободно доступная и для скачивания через Интернет. Чтобы она превратилась в полноценную полнофункциональную версию, пользователь должен вставить в привод ключевой диск, полученный от регионального дилера или переданный непосредственно самим разработчиком по почте (собственно, не обязательно постоянно держать ключевой диск в приводе, защита может запомнить флаг регистрации и в реестре, запрашивая ключевой диск лишь изредка – на тот случай если пользователь захочет одолжить его кому-нибудь). Согласитесь, это гораздо надежнее ключевого файла или регистрационного номера, которым ничего не стоит поделиться с другом или выложить в Интернет, а учитывая что cубканальные данные диска могут хранить не только ключ, но и исполняемый (интерпретируемый) код, обеспечивающий полнофункциональность зарегистрированной программы, становится ясно, что, если у хакера нет ни одной полностью работоспособной копии защищенного приложения, взломать его за разумное время будет просто нереально. Но довольно слов, перейдем к делу, попытавшись перво-наперво создать образ защищенного диска с нулевым треком внутри. Как мы сейчас и увидим, это оказывается не так-то просто сделать!
Если просто обнулить point первого трека, то Clone CD наотрез откажется открывать такой образ, ссылаясь на ошибку анализа. На самом деле этих ошибок по меньшей мере две. Первая – полная неосведомленность Clone CD о потенциальной возможности существования нулевых треков, коих он в упор не видит. Вторая – непростительный оптимизм, закладывающийся на тот факт, что каждая сессия должна содержать в себе по меньшей мере один трек (что в действительности вовсе не факт, а лишь допущение).
Алкоголик воспринимает сессию с единственным нулевым треком внутри более благодушно, корректно отображая его номер (см. листинг ниже), однако при попытке записи такого образа на диск, выпрыгивает "accessviolation" и копировщик наглухо повисает, даже не удосужившись аварийно завершить свою работу (см.
рис. 1). Вызов "Диспетчера программ" с последующим умерщвлением разбушевавшегося процесса не решает проблемы, т.к. лоток диска остается заблокированным и приходится прибегать к помощи утилиты CD.lock.exe для уменьшения счетчика блокировок на единицу.
| Тип: |
Файл-образ CloneCD |
| Путь: |
L:\CD-hack\ |
| Имя: |
IMAGE.CCD |
| IMAGE.img |
| IMAGE.sub |
| Размер: |
8.81 MB |
| Сессий: |
2 |
Треков: |
2 |
| Сессия 01: |
| Трек 00: Mode 1, Длина: 000000(0 Byte), Адрес: 000000 |
| Сессия 02: |
| Трек 01: Mode 1, Длина: 000000(0 Byte), Адрес: 013458 |
Листинг 1 Алкоголик открывает образ защищенного диска вполне успешно, честно отображая нулевой номер первого трека, правда некорректно определяет его длину.
Рисунок 1 реакция Алкоголика на попытку записи образа диска с единственным нулевым треком внутри первой сессии
Постойте, но ведь это же… Это же настоящая золотая жила! Диск с единственным нулевым треком внутри первой сессии не то, что не копируется, он даже и не прожигается! Даже если хакер каким-то неизвестным науке способом снимет с защищенного диска правильный дамп, ему будет нечем этот дамп записать!!! Правда и разработчику защищаемого приложения ключевой диск нечем записать тоже… ну, разве что он отважится на разработку собственной программы "прожига". Естественно, изготовить штампованные CD с нулевым треков вообще не проблема, но этот путь доступен далеко не всем (индивидуальным программистам он недоступен точно).
Компромиссным вариантов защиты становится добавление в искажаемую сессию хотя бы единственного ненулевого трека. Такой диск может быть изготовлен с помощью того же Clone CD и корпеть над написанием собственной "прожигалки" в этом случае не надо, что есть плюс. Однако коль скоро для создания оригинального диска используется утилита массового распространения, процесс создания несанкционированных дубликатов значительно упрощается. Хакеру достаточно снять с диска корректный дамп, а все остальное – это забота Clone CD. Необходимость разрабатывать специализированный софт для взлома при этом отпадает.
Один словом: все, что легко защищается, легко и ломается. Впрочем, квалифицированных хакеров не так уж и много, и для предотвращения "утекания" своей продукции для нас с вами достаточно добиться некопируемости ключевого диска распространенными копировщиками в автоматическом режиме. И, как мы увидим в дальнейшем, защита данного типа полностью удовлетворяет этому требованию.
Процесс подготовки защищенного диска не лишен определенных тонкостей. Создание фиктивного трека с нулевым номером не вызывает особых трудностей, но вот вопрос: где его разместить? В первой, а, может быть, лучше во второй сессии? До подлинного трека или после? Поскольку вводная область первой сессии недоступна для чтения на субканальном уровне, то прочитать TOC первой сессии вручную нельзя. Нельзя и закладываться на команду READ TOC, поскольку, как уже было сказано выше, ее корректное выполнение не гарантируется. Вводные области второй и всех последующих сессий свободно доступны на субканальном уровне и ручное чтение хранимого ими TOC'а все-таки возможно. Конкретная позиция нулевого трека внутри сессии особой роли не играет, и нулевой трек может быть с одинаковым успехом размещен как до ненулевого трека, так и после него.
Только, пожалуйста, не забывайте о необходимости коррекции point'а A0h, хранящего номер "первого" трека всякой сессии. Если его значение оставить без изменений, то образ диска запишется без каких-либо препирательств со стороны Clone CD, но никаких упоминаний о нулевом треке в TOC'е прожженного диска не окажется! Точно так же ведет себя и Алкоголь. Чтобы этого избежать, значение point'а A0h той сессии, к которой вы добавляете нулевой трек, должно быть сброшено в Zero.
Фрагмент отредактированного CCD-файла приведен ниже:
| TocEntries=13 | TocEntries=14; | корректируем количество входов в TOC |
| [Entry 8] | [Entry 8]; | это вход не обязательно должен быть восьмым… |
| Session=2 | Session=2; | …главное, чтобы Session == 2, а Point == A0h |
| Point=0xa0 | Point=0xa0; | этот Point отвечает на номер первого трека |
| ADR=0x01 | ADR=0x01; | это служебные поля ADR/Control, описывающие |
| Control=0x04 | Control=0x04; | режим обработки трека (это трек с данными) |
| TrackNo=0 | TrackNo=0; | TNO = 0 – это Lead-In область |
| AMin=0 | AMin=0; | \ |
| ASec=0 | ASec=0; | +- условный текущий абсолютный адрес |
| AFrame=0 | AFrame=0; | / |
| ALBA=-150 | ALBA=-150; | условный текущий LBA-адрес |
| Zero=0 | Zero=0; | это поле всегда равно нулю |
| PMin=2à | PMin=0; | корректируем номер "первого" трека |
| PSec=0 | PSec=0; | эти поля не имеют никакого смысла и должны |
| PFrame=0 | PFrame=0; | быть равны нулю |
| PLBA=8850 | PLBA=8850; | LBA-"адрес" номера "первого" трека |
|
|
[Entry 11]; | добавляем еще одно Entry, описывающее нулевой трек |
| Session=2; | нулевой трек должен быть не в первой сессии |
| Point=0x00; | номер трека - ноль |
| ADR=0x01; | Sub-channel Q encodes current position data |
| Control=0x04; | трек с данными |
| TrackNo=0; | это Lead-In |
| AMin=0; | \ |
| ASec=0; | + - условный абсолютный адрес Lead-In |
| AFrame=0; | / |
| ALBA=-150; | условный LBA-адрес Lead-In |
| Zero=0; | это поле должно быть равно нулю |
| PMin=3; | \ |
| PSec=1; | + - абсолютный стартовый адрес нулевого трека |
| PFrame=66; | / |
| PLBA=13458; | LBA-адрес нулевого трека |
<
Листинг 2 фрагмент CCD-файла с добавленным нулевым треком
При просмотре геометрии защищенного таким образом диска Ahead Nero выдает приблизительно следующую информацию (см. рис. 2). То, что он посчитал вторую сессию открытой ("Session is open") вполне объяснимо, так как созданный нами нулевой трек был ошибочно принят Нероном за вводную область, в результате чего шаткое равновесие между вводными и выводными областями оказалось нарушенным. Между тем, вторая сессия диска все-таки закрыта, и анализ TOC подтверждает это. А не знать, что упоминание о вводных областях никогда в явном виде не присутствует в TOC'е – глупо. Разобраться, почему нулевой трек оказался приобщен Нероном к первой сессии, несколько сложнее. По видимому, это грубая алгоритмическая ошибка, которая не делает чести ни самому Нерону, ни его разработчикам.
Рисунок 2 наличие нулевого трека на диске срывает крышу Нерону, вводя его в глубокое заблуждение относительно состояния последней сессии диска. Нерон считает, что вторая сессии открыта, хотя на самом деле это не так.
Clone CD ведет себя аналогичным образом и при попытке копирования защищенного диска на приводах ASUS и TEAC со всего маху врезается в выводную область первой сессии диска. Вторая сессия (с нулевым треком) по причине грубых алгоритмических ошибок полностью выпадает из его поля зрения и в TOC'е скопированного диска о ней даже и не упоминается. Стартовый адрес выводной области первой сессии так же определяется неправильно (Clone CD устанавливает его на стартовый адрес нулевого трека второй сессии). Point'ы B0h (стартовый адрес следующей позиции для дозаписи) и C0h (стартовый адрес первой вводной области диска) тоже оказываются потерянными. Короче говоря, TOC скопированного диска более чем существенно отличается от TOC'а оригинального, и обнаружить факт несанкционированного копирования не составит никакого труда,. Д вы их сами сравните:
| 01 |
14 |
00 |
A0 |
00 |
00 |
00 |
00 |
01 |
00 |
00 |
|
01 |
14 |
00 |
A0 |
00 |
00 |
00 |
00 |
01 |
00 |
00 |
| 01 |
14 |
00 |
A1 |
00 |
00 |
00 |
00 |
01 |
00 |
00 |
|
01 |
14 |
00 |
A1 |
00 |
00 |
00 |
00 |
01 |
00 |
00 |
| 01 |
14 |
00 |
A2 |
00 |
00 |
00 |
00 |
00 |
1D |
21 |
|
01 |
14 |
00 |
A2 |
00 |
00 |
00 |
00 |
03 |
01 |
42 |
| 01 |
14 |
00 |
01 |
00 |
00 |
00 |
00 |
00 |
02 |
00 |
|
01 |
14 |
00 |
01 |
00 |
00 |
00 |
00 |
00 |
02 |
00 |
01 |
54 |
00 |
B0 |
02 |
3B |
21 |
03 |
16 |
0E |
22 |
| 01 |
54 |
00 |
C0 |
A2 |
C8 |
E0 |
00 |
61 |
1B |
15 |
| 02 |
14 |
00 |
A0 |
00 |
00 |
00 |
00 |
02 |
00 |
00 |
| 02 |
14 |
00 |
A1 |
00 |
00 |
00 |
00 |
00 |
00 |
00 |
| 02 |
14 |
00 |
A2 |
00 |
00 |
00 |
00 |
03 |
18 |
17 |
| 02 |
14 |
00 |
00 |
00 |
00 |
00 |
00 |
03 |
01 |
42 |
<
Листинг 3 TOC оригинального ключевого диска с нулевым треком внутри второй сессии (слева; атрибуты нулевого трека выделены серой заливкой) и TOC его копии, полученной с помощью Clone CD (справа). Все несовпадения выделены жирным шрифтом.
При попытке копирования защищенного диска на приводе NEC (который, как уже отмечалось, отказывается читать TOC с нулевым треком), Clone CD удивленно спрашивает "диск пуст?" и вне зависимости от нашего ответа даже не пытается приступить к его копированию, вызывая страшный хакерский гнев и раздражение.
Алкоголь при попытке копирования защищенного диска просто виснет, едва лишь успев перед смертью выбросить исключение "accessviolation", но зато заблокировав лоток привода так, что без уменьшения счетчика блокировок извлечь диск помогает разве что тотальная перезагрузка системы.
В общем, дело – мрак! (С точки зрения "пиратов", конечно). И мы по праву можем считать, что процедура создания некопируемого ключевого диска завершилась успешно. Теперь недурно бы разобраться: как с полученным диском вообще работать и каким именно образом защитный механизм сможет отличить копию от оригинала.
Первое, что приходит нам в голову – прочитать "сырой" TOC командой READ TOC и проверить наличие трека номер ноль, а для пущей надежности – и его атрибуты. Если нулевой трек действительно присутствует в TOC'е и его атрибуты (т. е. поля Session, ADR, Control, PMin:PSec:PFarme) полностью соответствуют эталону – это оригинальный диск и, соответственно, наоборот. Достоинство такого алгоритма в том, что он очень просто реализуется, укладываясь буквально в десяток строк кода, а недостаток – в нестабильности опознавания ключевого диска на определенных моделях приводов. Привод может отказаться читать TOC ? к такому повороту событий защита должна быть заранее готова. Давайте сделаем так: если команда READ TOC возвращает ошибку, но диск присутствует в приводе и не препятствует выполнению SEEK – это оригинальный диск. Конечно, подобное эвристическое допущение значительно ослабляет защиту, однако для большинства применений ее стойкости будет вполне достаточно.
Однако безошибочное выполнение команды READ CD еще не является свидетельством того, что она выполнена успешно. Ни один известный мне привод, способный читать TOC с нулевым треком, не читает его правильно, а потому защита должна заранее учитывать характер возможных искажений TOC'а и адекватно ему противостоять.
Рассмотрим, например, какой результат возвращает привод TEAC:
| Номер сессии |
| | ADR/Control |
| | |
| TNO |
| | |
| |
| Point |
| | |
| |
| |
| |
| AM:AS:AF PM:PS:PF |
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| 01 |
14 |
00 |
A0 |
00 |
00 |
00 |
00 |
01 |
00 |
00 |
; |
point A0 |
- |
номер первого трека сессии 1 в PM |
| 01 |
14 |
00 |
A1 |
00 |
00 |
00 |
00 |
01 |
00 |
00 |
; |
point A1 |
- |
номер последнего трека сессии 1 в PM |
| 01 |
14 |
00 |
A2 |
00 |
00 |
00 |
00 |
00 |
1D |
21 |
; |
point A2 |
- |
адрес Lead-out сессии 1 в PM:PS:PF |
| 01 |
14 |
00 |
01 |
00 |
00 |
00 |
00 |
00 |
02 |
00 |
; |
point 01 |
- |
стартовый адрес трека 1 в PM:PS:PF |
| 01 |
54 |
00 |
B0 |
02 |
3B |
21 |
03 |
16 |
0E |
22 |
; |
point B0 |
- |
позиция дозаписи в AM:AS:AF |
| 01 |
54 |
00 |
C0 |
A2 |
C8 |
E0 |
00 |
61 |
1B |
15 |
; |
point C0 |
- |
стартовый адрес Lead-In в PM:PS:PF /искж |
| 02 |
14 |
00 |
A0 |
00 |
00 |
00 |
00 |
02 |
00 |
00 |
; |
point A0 |
- |
номер первого трека сессии 1 в PM |
| 02 |
14 |
00 |
A1 |
00 |
00 |
00 |
00 |
00 |
00 |
00 |
; |
point A1 |
- |
номер последнего трека сессии 2 в PM |
| 02 |
14 |
00 |
A2 |
00 |
00 |
00 |
00 |
03 |
18 |
17 |
; |
point A2 |
- |
адрес Lead-out сессии 2 в PM:PS:PF |
| 02 |
14 |
00 |
00 |
00 |
00 |
00 |
00 |
03 |
01 |
42 |
; |
point 00 |
- |
стартовый адрес трека 0 в PM:PS:PF |
| FB |
FD |
00 |
FB |
F4 |
FB |
7A |
FF |
FD |
FD |
FF |
; |
\ |
| |
как видно, встретив нулевой трек, TEAC |
| FB |
DF |
00 |
FA |
FD |
F5 |
FF |
BF |
FB |
FE |
FF |
; |
+ - мусор |
| |
вместо осмысленных данных начал изры- |
| FE |
F7 |
00 |
FB |
FF |
FD |
FB |
FF |
FF |
F7 |
FF |
; |
/ |
| |
гать мусор |
<
Листинг 4 содержимое TOC' а ключевого диска, возращенное приводом TEAC, нулевой трек выделен серой заливкой, а мусор, следующий за ним – жирным шрифтом
Что это за подозрительный мусор, расположенный вслед за нулевым треком? Это – содержимое внутренних буферов привода, попавшее сюда в результате грубой программистской ошибке в микропрограмме привода (между прочим, тестировалась самая свежая на момент написания этих строк прошивка – 1.09). Небольшое расследование убедительно доказывает, что мусор носит не случайный характер и представляет собой "хвост" TOC'а предыдущего диска.
Давайте, вставив в привод какой-нибудь диск (например, "Soul Ballet Hit Collection"), сменим его на ключевой и посмотрим что у нас из этого получится:
| 01 |
10 |
00 |
A0 |
00 |
00 |
00 |
00 |
01 |
00 |
00 |
01 |
14 |
00 |
A0 |
00 |
00 |
00 |
00 |
01 |
00 |
00 |
| 01 |
10 |
00 |
A1 |
00 |
00 |
00 |
00 |
10 |
00 |
00 |
01 |
14 |
00 |
A1 |
00 |
00 |
00 |
00 |
01 |
00 |
00 |
| 01 |
10 |
00 |
A2 |
00 |
00 |
00 |
00 |
48 |
1C |
05 |
01 |
14 |
00 |
A2 |
00 |
00 |
00 |
00 |
00 |
1D |
21 |
| 01 |
10 |
00 |
01 |
00 |
00 |
00 |
00 |
00 |
02 |
00 |
01 |
14 |
00 |
01 |
00 |
00 |
00 |
00 |
00 |
03 |
00 |
| 01 |
10 |
00 |
02 |
00 |
00 |
00 |
00 |
03 |
35 |
40 |
01 |
54 |
00 |
B0 |
02 |
3B |
21 |
03 |
16 |
0E |
22 |
| 01 |
10 |
00 |
03 |
00 |
00 |
00 |
00 |
08 |
14 |
33 |
01 |
54 |
00 |
C0 |
A2 |
C8 |
E0 |
00 |
61 |
1B |
15 |
| 01 |
10 |
00 |
04 |
00 |
00 |
00 |
00 |
0C |
21 |
0D |
02 |
14 |
00 |
A0 |
00 |
00 |
00 |
00 |
02 |
00 |
00 |
| 01 |
10 |
00 |
05 |
00 |
00 |
00 |
00 |
10 |
3A |
2D |
02 |
14 |
00 |
A1 |
00 |
00 |
00 |
00 |
00 |
00 |
00 |
| 01 |
10 |
00 |
06 |
00 |
00 |
00 |
00 |
16 |
23 |
19 |
02 |
14 |
00 |
A2 |
00 |
00 |
00 |
00 |
03 |
18 |
17 |
| 01 |
10 |
00 |
07 |
00 |
00 |
00 |
00 |
1C |
1B |
0C |
02 |
14 |
00 |
00 |
00 |
00 |
00 |
00 |
03 |
01 |
42 |
| 01 |
10 |
00 |
08 |
00 |
00 |
00 |
00 |
21 |
07 |
49 |
09 |
25 |
00 |
1F |
00 |
00 |
00 |
00 |
19 |
01 |
10 |
| 01 |
10 |
00 |
09 |
00 |
00 |
00 |
00 |
25 |
1F |
19 |
0A |
2A |
00 |
01 |
00 |
00 |
00 |
00 |
06 |
01 |
10 |
| 01 |
10 |
00 |
0A |
00 |
00 |
00 |
00 |
2A |
01 |
06 |
0B |
2D |
00 |
2D |
00 |
00 |
00 |
00 |
00 |
01 |
10 |
| 01 |
10 |
00 |
0B |
00 |
00 |
00 |
00 |
2D |
2D |
00 |
0C |
33 |
00 |
29 |
00 |
00 |
00 |
00 |
02 |
01 |
10 |
| 01 |
10 |
00 |
0C |
00 |
00 |
00 |
00 |
33 |
29 |
02 |
0D |
39 |
00 |
08 |
00 |
00 |
00 |
00 |
45 |
01 |
10 |
| 01 |
10 |
00 |
0D |
00 |
00 |
00 |
00 |
39 |
08 |
45 |
0E |
3F |
00 |
1E |
00 |
00 |
00 |
00 |
27 |
01 |
10 |
| 01 |
10 |
00 |
0E |
00 |
00 |
00 |
00 |
3F |
1E |
27 |
0F |
43 |
00 |
1E |
00 |
00 |
00 |
00 |
29 |
01 |
10 |
| 01 |
10 |
00 |
0F |
00 |
00 |
00 |
00 |
43 |
1E |
29 |
10 |
44 |
00 |
03 |
00 |
00 |
00 |
00 |
15 |
FF |
FF |
| 01 |
10 |
00 |
10 |
00 |
00 |
00 |
00 |
44 |
03 |
15 |
<
Листинг 5 TOC диска SoulBallet (слева) и TOC ключевого диска (справа), возвращенные приводом TEAC
Смотрите! Сейчас содержимое TOC' а ключевого диска существенно изменилось. Пускай не все содержимое, но вот хвост изменился точно. Причем последовательность байт "хвоста" ключевого диска соответствует последовательности байт диска "Soul Ballet". Пускай "…09 00 00 00 00 25 1F 19…" и "…09 25 00 1F 00 00 19…" и не совсем тождественные последовательности, но, если убрать паразитные нули, мы получим: "…09 25 1F 19…" и "…09 25 1F 19…", которые побайтно равны друг другу. Так что мы действительно имеем дело с ошибкой в прошивке, что не делает чести ни самому приводу, ни его разработчикам.
ASUS ведет себя более корректно, просто "обрубая" TOCпо нулевому треку, даже в том случае когда нулевой трек – не последний трек диска, что тоже расценивается как микропрограммная ошибка, пускай и не такая грубая.
| 01 |
14 |
00 |
A0 |
00 |
00 |
00 |
00 |
01 |
00 |
00 |
| 01 |
14 |
00 |
A1 |
00 |
00 |
00 |
00 |
01 |
00 |
00 |
| 01 |
14 |
00 |
A2 |
00 |
00 |
00 |
00 |
00 |
1D |
21 |
| 01 |
14 |
00 |
01 |
00 |
00 |
00 |
00 |
00 |
03 |
00 |
| 01 |
54 |
00 |
B0 |
02 |
3B |
21 |
03 |
16 |
0E |
22 |
| 01 |
54 |
00 |
C0 |
A2 |
C8 |
E0 |
00 |
61 |
1B |
15 |
| 02 |
14 |
00 |
A0 |
00 |
00 |
00 |
00 |
02 |
00 |
00 |
| 02 |
14 |
00 |
A1 |
00 |
00 |
00 |
00 |
00 |
00 |
00 |
| 02 |
14 |
00 |
A2 |
00 |
00 |
00 |
00 |
03 |
18 |
17 |
| 02 |
14 |
00 |
00 |
00 |
00 |
00 |
00 |
03 |
01 |
42 |
Листинг 6 TOC ключевого диска, возращенный приводом ASUS
NEC, как уже говорилось выше, вообще не выдает ничего, кроме ошибки, которую защитный механизм вынужден интерпретировать, как индикатор лицензионности диска, в противном случае разработчик может поплатиться своими яйцами, которые с удовольствием оторвут легальные пользователи, попытавшиеся "скормить" защищенный диск "неправильному" (с точки зрения защиты) приводу.
Тем не менее, преднамеренное ослабление стойкости защиты – не выход. Уж лучше попробовать прочитать TOC вручную. Это достаточно трудно реализуется на программном уровне, но еще труднее ломается! Если команду READ TOC легко и проэмулировать, то воссоздать особенности обработки субканальных данных практически нереально, благодаря чему усиленный вариант защиты с легкостью обойдет все копировщики, эмулирующие виртуальные диски.
Опасаясь охладить ваш воинственный программистский пыл, я все же скажу: правильно считать субканальные данные не так-то просто, как это может показаться на первый взгляд, и одних лишь спецификаций для успешной реализации защитного механизма мало. В них не отображено и доли тех "чудачеств" приводов, с которыми приходится сталкиваться на практике.
Первое и главное: абсолютные адреса секторов ни коим образом не связаны с "соответствующими" им субканальными данными, хотя бы уже потому, что одна секция субканальных данных "размазана" по нескольким секторам, причем в силу определенных конструктивных особенностей обработка субканальных данных и данных основного потока осуществляется раздельно, благодаря чему при позиционировании головки на сектор X с последующим вызовом команды READ SUBCHANNEL мы получим субканальные данные не сектора X, а сектора Y, лежащего "поблизости" от сектора X. Понятие "поблизости" всякий производитель определяет самостоятельно, зачастую уползая не на одну сотню секторов вперед.
Второе: связка команд SEEK/READ SUBCHANNEL неустойчива и обладает хреновой воспроизводимостью результатов. Никто не гарантирует, что позиционирование на сектор X+k приведет к чтению субканальных данных сектора Y+k. Привод может возвратить как данные сектора Y, так и данные сектора Y+i. Также никто не гарантирует, что повторное позиционирование не сектор X приведет к чтению субканальных данных сектора Y. (кстати, не забывайте между двумя соседними вызовами командами SEEK выдерживать паузу хотя бы в 1 сек, иначе головка просто не успеет переместиться на новое место, и привод как ни в чем не бывало возвратит уже скэшированные субканальные данные с места предыдущего позиционирования). Остается опираться лишь на текущие адреса секторов, возвращаемые в самой субканальной информации (поле "Absolute CD Address"). Встретив в этом поле адрес "своего" сектора, мы можеь быть абсолютно уверенными в том, что эта субканальная информация принадлежит именно "нашему" сектору, а не какому-то сектору еще.
Листинг 7 правильная интерпретация субканальной информации
Третье: конкретный формат субканальной информации определяется не Стандартом, а самим приводом и значительно варьируется от одной модели к другой. Наиболее непостоянны в этом смысле вводные и выводные области диска. Стандарт вообще ничего не говорит о возможности их чтения на субканальном уровне, молчаливо полагая, что это никому на хрен не нужно. Вот производители и извращаются в меру своей распущенности и фантазий. Поля абсолютных и относительных адресов могут безо всяких предупреждений меняться местами, а сами адреса могут задаваться как в формате M:S:F, так и в LBA-форме. Значения point'ов A0h, A1h и A2h (номер первого трека, номер последнего трека и адрес Lead-Out области) могут замещаться значениями 64h, 65h и 66h соответственно. Наконец, нестандартные point'ы (в том числе и нулевые point'ы) в субканальных данных зачастую попросту отсутствуют – вместо этого возвращаются данные либо предыдущей, либо последующей секций!
Все это значительно усложняет интерпретацию субканальных данных и поиск в ней нулевых треков, поэтому приходится действовать так: последовательно читая субканальные данные различных секторов диска, дожидаемся того момента, когда номера треков сменяться сначала на AAh, а затем и на 00h, что будет соответствовать переходу головки с Lead-Out области первой сессии на Lead-In область второй сессий. Продолжая читать Lead-In, мы попытаемся определить в какой закономерности изменяются поля абсолютных и относительных адресов и форму их представления (LBA или M:S:F). Собственно, формат представления определить очень легко. Если младший байт адреса принимает значения больше, чем 75 (4Bh), – это, несомненно, LBA и наоборот. Далее – поскольку поля относительных адресов в вводной области диска используются для хранения атрибутов "своего" point'а, то они чрезвычайно сильно отличаются от текущих адресов секторов – тех, на которых и осуществлялось позиционирование. Напротив, поля абсолютных адресов к текущим адресам должны быть достаточно близки.
Остается решить последнюю проблему – что делать, если в субканальных данных Lead- In области нулевого трека попросту не окажется? Не спешите делать вывод о нелицензионности диска – ведь, как уже было сказано выше, некоторые приводы нестандартные point'ы просто не возвращают. При этом абсолютные адреса секторов, хранящих субканальные атрибуты нулевого трека, в считанном TOC'е не будут присутствовать! Копия диска, полученная любым из существующих на данный момент копировщиков, по данным абсолютным адресам будет содержать атрибуты совершенно других треков, которые привод вполне корректно прочитает и возвратит, либо же вовсе откажется позиционировать головку на эту область, выдавая ту или иную ошибку.
Ну что, парни, слабо реализовать такое? Для облегчения восприятия материала ниже будут приведены субканальные данные ключевого диска, возращенные различными приводами. А подробные комментарии, щедро разбросанные автором, помогут разобраться что к чему.
| |
+internal+ Format |
|
| |
|
| |
| |
| |
| |
| |
ADR/Control |
| |
| |
| |
| |
| |
| |
| |
TNO |
| |
| |
| |
| |
| |
| |
| |
| |
Point |
| |
| |
| |
| |
| |
| |
| |
| |
| |
+- PLBA -+ +- ALBA -+ |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
|
|
|
| LBA |
- |
10D4:00 |
15 |
00 |
0C |
01 |
14 |
00 |
A0 |
00 |
00 |
22 |
92 |
00 |
00 |
11 |
6D |
; |
LBA 10D4 а 116D |
| LBA |
- |
10D5:00 |
15 |
00 |
0C |
01 |
14 |
00 |
A0 |
00 |
00 |
22 |
92 |
00 |
00 |
11 |
6D |
; |
LBA 10D5 а 116D |
| LBA |
- |
10D6:00 |
15 |
00 |
0C |
01 |
14 |
00 |
A0 |
00 |
00 |
22 |
92 |
00 |
00 |
11 |
6E |
; |
LBA 10D5 а 116E |
| LBA |
- |
10D7:00 |
15 |
00 |
0C |
01 |
14 |
00 |
A0 |
00 |
00 |
22 |
92 |
00 |
00 |
11 |
6D |
; |
LBA 10D7 а 116D (!) |
| LBA |
- |
10D8:00 |
15 |
00 |
0C |
01 |
14 |
00 |
A0 |
00 |
00 |
22 |
92 |
00 |
00 |
11 |
6E |
; |
("биение" головки) |
| LBA |
- |
10D9:00 |
15 |
00 |
0C |
01 |
14 |
00 |
A0 |
00 |
00 |
22 |
92 |
00 |
00 |
11 |
6E |
; |
LBA 2292 = 02:00:00 M:S:F |
|
| LBA |
- |
10DA:00 |
15 |
00 |
0C |
01 |
14 |
00 |
A1 |
00 |
FF |
FF |
6A |
00 |
00 |
11 |
73 |
; |
LBA FFh - 6Ah = 95h (149) |
| LBA |
- |
10DB:00 |
15 |
00 |
0C |
01 |
14 |
00 |
A1 |
00 |
FF |
FF |
6A |
00 |
00 |
11 |
73 |
; |
LBA 149 == MSF 0:0:1 |
| LBA |
- |
10DC:00 |
15 |
00 |
0C |
01 |
14 |
00 |
A1 |
00 |
FF |
FF |
6A |
00 |
00 |
11 |
74 |
; |
что удивительно, т.к. |
| LBA |
- |
10DD:00 |
15 |
00 |
0C |
01 |
14 |
00 |
A1 |
00 |
FF |
FF |
6A |
00 |
00 |
11 |
75 |
; |
последнего трека должен |
| LBA |
- |
10DE:00 |
15 |
00 |
0C |
01 |
14 |
00 |
A1 |
00 |
FF |
FF |
6A |
00 |
00 |
11 |
74 |
; |
быть в PM, но не в PF |
| LBA |
- |
10DF:00 |
15 |
00 |
0C |
01 |
14 |
00 |
A1 |
00 |
FF |
FF |
6A |
00 |
00 |
11 |
74 |
; |
учитывайте это! |
|
| LBA |
- |
10E0:00 |
15 |
00 |
0C |
01 |
14 |
00 |
A2 |
00 |
00 |
3B |
45 |
00 |
00 |
11 |
79 |
; |
продолжается биение го- |
| LBA |
- |
10E1:00 |
15 |
00 |
0C |
01 |
14 |
00 |
A2 |
00 |
00 |
3B |
45 |
00 |
00 |
11 |
79 |
; |
ловки: сектора идут не |
| LBA |
- |
10E2:00 |
15 |
00 |
0C |
01 |
14 |
00 |
A2 |
00 |
00 |
3B |
45 |
00 |
00 |
11 |
7B |
; |
упорядочено: 1179, 1179, |
| LBA |
- |
10E3:00 |
15 |
00 |
0C |
01 |
14 |
00 |
A2 |
00 |
00 |
3B |
45 |
00 |
00 |
11 |
79 |
; |
117B, 1179, 117A, 117A и |
| LBA |
- |
10E4:00 |
15 |
00 |
0C |
01 |
14 |
00 |
A2 |
00 |
00 |
3B |
45 |
00 |
00 |
11 |
7A |
; |
нету секторов 1176, 1177 |
| LBA |
- |
10E5:00 |
15 |
00 |
0C |
01 |
14 |
00 |
A2 |
00 |
00 |
3B |
45 |
00 |
00 |
11 |
7A |
; |
и 178 |
|
| LBA |
- |
10E6:00 |
15 |
00 |
0C |
01 |
14 |
00 |
02 |
00 |
00 |
34 |
92 |
00 |
00 |
11 |
80 |
; |
|
| LBA |
- |
10E7:00 |
15 |
00 |
0C |
01 |
14 |
00 |
02 |
00 |
00 |
34 |
92 |
00 |
00 |
11 |
80 |
; |
|
| LBA |
- |
10E8:00 |
15 |
00 |
0C |
01 |
14 |
00 |
02 |
00 |
00 |
34 |
92 |
00 |
00 |
11 |
80 |
; |
биение головки |
| LBA |
- |
10E9:00 |
15 |
00 |
0C |
01 |
14 |
00 |
02 |
00 |
00 |
34 |
92 |
00 |
00 |
11 |
7F |
; |
продолжается |
| LBA |
- |
10EA:00 |
15 |
00 |
0C |
01 |
14 |
00 |
02 |
00 |
00 |
34 |
92 |
00 |
00 |
11 |
80 |
; |
|
| LBA |
- |
10EB:00 |
15 |
00 |
0C |
01 |
14 |
00 |
02 |
00 |
00 |
34 |
92 |
00 |
00 |
11 |
81 |
; |
|
|
| LBA |
- |
10EC:00 |
15 |
00 |
0C |
01 |
14 |
00 |
00 |
00 |
00 |
34 |
B3 |
00 |
00 |
11 |
85 |
; |
а вот и нулевой трек, он |
| LBA |
- |
10ED:00 |
15 |
00 |
0C |
01 |
14 |
00 |
00 |
00 |
00 |
34 |
B3 |
00 |
00 |
11 |
85 |
; |
располагается в секторах |
| LBA |
- |
10EE:00 |
15 |
00 |
0C |
01 |
14 |
00 |
00 |
00 |
00 |
34 |
B3 |
00 |
00 |
11 |
86 |
; |
1185 и 1186 - запомним |
| LBA |
- |
10EF:00 |
15 |
00 |
0C |
01 |
14 |
00 |
00 |
00 |
00 |
34 |
B3 |
00 |
00 |
11 |
85 |
; |
это обстоятельство! |
|
| LBA |
- |
10F0:00 |
15 |
00 |
0C |
01 |
14 |
00 |
A0 |
00 |
00 |
22 |
92 |
00 |
00 |
11 |
8C |
; |
point A0 повторяется… |
| LBA |
- |
10F1:00 |
15 |
00 |
0C |
01 |
14 |
00 |
A0 |
00 |
00 |
22 |
92 |
00 |
00 |
11 |
8C |
; |
а вместе с ним и все |
| LBA |
- |
10F2:00 |
15 |
00 |
0C |
01 |
14 |
00 |
A0 |
00 |
00 |
22 |
92 |
00 |
00 |
11 |
8B |
; |
остальные point'ы. Читая |
| LBA |
- |
10F3:00 |
15 |
00 |
0C |
01 |
14 |
00 |
A0 |
00 |
00 |
22 |
92 |
00 |
00 |
11 |
8B |
; |
субканальные данные даль- |
| LBA |
- |
10F4:00 |
15 |
00 |
0C |
01 |
14 |
00 |
A0 |
00 |
00 |
22 |
92 |
00 |
00 |
11 |
8C |
; |
ше мы вновь встретим ну- |
| LBA |
- |
10F5:00 |
15 |
00 |
0C |
01 |
14 |
00 |
A0 |
00 |
00 |
22 |
92 |
00 |
00 |
11 |
8B |
; |
левой трек, но уже в дру- |
| LBA |
- |
10F6:00 |
15 |
00 |
0C |
01 |
14 |
00 |
A0 |
00 |
00 |
22 |
92 |
00 |
00 |
11 |
8B |
; |
гих секторах. Запомним и |
| LBA |
- |
10F7:00 |
15 |
00 |
0C |
01 |
14 |
00 |
A0 |
00 |
00 |
22 |
92 |
00 |
00 |
11 |
8B |
; |
из для надежности |
|
<
Листинг 8 результат чтения субканальной информации из Lead-In на приводе TEAC; отчетливо просматривается нулевой трек
Здесь абсолютные адреса представлены в LBA-форме, причем расхождение между адресом, на который осуществляется позиционирование головки, и адресом, чьи субканальные данные при этом читаются (далее по тексту – дельта) составляет порядка 400 секторов. Правда, равномерность "часового хода" очень хороша, абсолютные идут кучным пучком строго социалистического характера, хотя TEAC все-таки не без греха, и оплошности типа 11:6D, 11:6E, 11:6D, 11:6E случаются сплошь и рядом. Атрибуты нулевого трека присутствуют в явном виде, что не может не радовать.
А вот привод ASUS ведет себя более разболтанно:
| |
+internal+ Format |
|
| |
|
| |
| |
| |
| |
| |
ADR/Control |
| |
| |
| |
| |
| |
| |
| |
TNO |
| |
| |
| |
| |
| |
| |
| |
| |
Point |
| |
| |
| |
| |
| |
| |
| |
| |
| |
+- PLBA -+ +- ALBA -+ |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
|
|
|
| LBA |
- |
10D3:00 |
15 |
00 |
0C |
01 |
14 |
00 |
A0 |
00 |
00 |
22 |
92 |
00 |
00 |
11 |
6F |
; |
здесь субканальные данные |
| LBA |
- |
10D4:00 |
15 |
00 |
0C |
01 |
14 |
00 |
A1 |
00 |
FF |
FF |
6A |
00 |
00 |
11 |
73 |
; |
возвращаются еще более |
| LBA |
- |
10D5:00 |
15 |
00 |
0C |
01 |
14 |
00 |
A1 |
00 |
FF |
FF |
6A |
00 |
00 |
11 |
73 |
; |
беспорядочно, и потому |
| LBA |
- |
10D6:00 |
15 |
00 |
0C |
01 |
14 |
00 |
A1 |
00 |
FF |
FF |
6A |
00 |
00 |
11 |
73 |
; |
отделить соседние point'ы |
| LBA |
- |
10D7:00 |
15 |
00 |
0C |
01 |
14 |
00 |
A1 |
00 |
FF |
FF |
6A |
00 |
00 |
11 |
73 |
; |
друг от друга уже не |
| LBA |
- |
10D8:00 |
15 |
00 |
0C |
01 |
14 |
00 |
A0 |
00 |
00 |
22 |
92 |
00 |
00 |
11 |
6F |
; |
удается, между тем они |
| LBA |
- |
10D9:00 |
15 |
00 |
0C |
01 |
14 |
00 |
A0 |
00 |
00 |
22 |
92 |
00 |
00 |
11 |
6F |
; |
лежат по тем же самым |
| LBA |
- |
10DA:00 |
15 |
00 |
0C |
01 |
14 |
00 |
A0 |
00 |
00 |
22 |
92 |
00 |
00 |
11 |
6F |
; |
ALBA адресам, что и в |
| LBA |
- |
10DB:00 |
15 |
00 |
0C |
01 |
14 |
00 |
A0 |
00 |
00 |
22 |
92 |
00 |
00 |
11 |
6F |
; |
предыдущем случае, а |
| LBA |
- |
10DC:00 |
15 |
00 |
0C |
01 |
14 |
00 |
A1 |
00 |
FF |
FF |
6A |
00 |
00 |
11 |
73 |
; |
потому, ALBA адреса могут |
| LBA |
- |
10DD:00 |
15 |
00 |
0C |
01 |
14 |
00 |
A0 |
00 |
00 |
22 |
92 |
00 |
00 |
11 |
6F |
; |
служить надежной опорой |
| LBA |
- |
10DE:00 |
15 |
00 |
0C |
01 |
14 |
00 |
A1 |
00 |
FF |
FF |
6A |
00 |
00 |
11 |
73 |
; |
в идентификации point'ов |
| LBA |
- |
10DF:00 |
15 |
00 |
0C |
01 |
14 |
00 |
A1 |
00 |
FF |
FF |
6A |
00 |
00 |
11 |
73 |
; |
не зависящей от настро- |
| LBA |
- |
10E0:00 |
15 |
00 |
0C |
01 |
14 |
00 |
A2 |
00 |
00 |
3B |
45 |
00 |
00 |
11 |
79 |
; |
ения, разболтанности |
| LBA |
- |
10E1:00 |
15 |
00 |
0C |
01 |
14 |
00 |
A2 |
00 |
00 |
3B |
45 |
00 |
00 |
11 |
79 |
; |
и конструктивных особен- |
| LBA |
- |
10E2:00 |
15 |
00 |
0C |
01 |
14 |
00 |
A2 |
00 |
00 |
3B |
45 |
00 |
00 |
11 |
79 |
; |
ностей конкретных моделей |
| LBA |
- |
10E3:00 |
15 |
00 |
0C |
01 |
14 |
00 |
A1 |
00 |
FF |
FF |
6A |
00 |
00 |
11 |
75 |
; |
приводов, что значительно |
| LBA |
- |
10E4:00 |
15 |
00 |
0C |
01 |
14 |
00 |
A2 |
00 |
00 |
3B |
45 |
00 |
00 |
11 |
7A |
; |
упрощает процедуру про- |
| LBA |
- |
10E5:00 |
15 |
00 |
0C |
01 |
14 |
00 |
A1 |
00 |
FF |
FF |
6A |
00 |
00 |
11 |
75 |
; |
верки степени лицензион- |
| LBA |
- |
10E6:00 |
15 |
00 |
0C |
01 |
14 |
00 |
02 |
00 |
00 |
34 |
92 |
00 |
00 |
11 |
80 |
; |
ной "чистоты" анализиру- |
| LBA |
- |
10E7:00 |
15 |
00 |
0C |
01 |
14 |
00 |
02 |
00 |
00 |
34 |
92 |
00 |
00 |
11 |
81 |
; |
емого диска… |
| LBA |
- |
10E8:00 |
15 |
00 |
0C |
01 |
14 |
00 |
A1 |
00 |
FF |
FF |
6A |
00 |
00 |
11 |
75 |
|
|
| LBA |
- |
10E9:00 |
15 |
00 |
0C |
01 |
14 |
00 |
A2 |
00 |
00 |
3B |
45 |
00 |
00 |
11 |
7B |
|
|
| LBA |
- |
10EA:00 |
15 |
00 |
0C |
01 |
14 |
00 |
00 |
00 |
00 |
34 |
B3 |
00 |
00 |
11 |
85 |
; |
атрибуты трека 0, обрати- |
| LBA |
- |
10EB:00 |
15 |
00 |
0C |
01 |
14 |
00 |
02 |
00 |
00 |
34 |
92 |
00 |
00 |
11 |
81 |
|
|
| LBA |
- |
10EC:00 |
15 |
00 |
0C |
01 |
14 |
00 |
A2 |
00 |
00 |
3B |
45 |
00 |
00 |
11 |
7B |
|
|
| LBA |
- |
10ED:00 |
15 |
00 |
0C |
01 |
14 |
00 |
00 |
00 |
00 |
34 |
B3 |
00 |
00 |
11 |
85 |
; |
те внимание, что они рас- |
| LBA |
- |
10EE:00 |
15 |
00 |
0C |
01 |
14 |
00 |
02 |
00 |
00 |
34 |
92 |
00 |
00 |
11 |
81 |
|
|
| LBA |
- |
10EF:00 |
15 |
00 |
0C |
01 |
14 |
00 |
00 |
00 |
00 |
34 |
B3 |
00 |
00 |
11 |
86 |
; |
полгаются по тем же LBA |
| LBA |
- |
10F0:00 |
15 |
00 |
0C |
01 |
14 |
00 |
A0 |
00 |
00 |
22 |
92 |
00 |
00 |
11 |
8B |
|
|
| LBA |
- |
10F1:00 |
15 |
00 |
0C |
01 |
14 |
00 |
00 |
00 |
00 |
34 |
B3 |
00 |
00 |
11 |
85 |
; |
адресам: 1185h и 1186! |
| LBA |
- |
10F2:00 |
15 |
00 |
0C |
01 |
14 |
00 |
A0 |
00 |
00 |
22 |
92 |
00 |
00 |
11 |
8B |
|
|
|
<
Листинг 9 результат чтения субканальной информации из Lead-In на приводе ASUS
Здесь: абсолютные адреса так же представлены в формате LBA и дельта составляет все те же 400 секторов, однако степень неупорядоченности возвращаемой информации значительно выше и номера секторов начинают потихонечку "плясать" (см. поле ALBA).
| |
+internal+ Format |
|
| |
|
| |
| |
| |
| |
| |
ADR/Control |
| |
| |
| |
| |
| |
| |
| |
TNO |
| |
| |
| |
| |
| |
| |
| |
| |
Point |
| |
| |
| |
| |
| |
| |
| |
| |
| |
+- PLBA -+ +- ALBA -+ |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
|
|
|
| LBA |
- |
1171:00 |
15 |
00 |
0C |
01 |
14 |
00 |
64 |
00 |
00 |
11 |
6E |
00 |
02 |
00 |
00 |
; |
point 64 - это на самом |
| LBA |
- |
1172:00 |
15 |
00 |
0C |
01 |
14 |
00 |
64 |
00 |
00 |
11 |
6E |
00 |
02 |
00 |
00 |
; |
деле point A0 (номер пер- |
| LBA |
- |
1173:00 |
15 |
00 |
0C |
01 |
14 |
00 |
64 |
00 |
00 |
11 |
6E |
00 |
02 |
00 |
00 |
; |
вого трека), просто глу- |
| LBA |
- |
1174:00 |
15 |
00 |
0C |
01 |
14 |
00 |
64 |
00 |
00 |
11 |
6E |
00 |
02 |
00 |
00 |
; |
пый привод так нелепо его |
| LBA |
- |
1175:00 |
15 |
00 |
0C |
01 |
14 |
00 |
64 |
00 |
00 |
11 |
6E |
00 |
02 |
00 |
00 |
; |
исказил, так же обратите |
| LBA |
- |
1176:00 |
15 |
00 |
0C |
01 |
14 |
00 |
64 |
00 |
00 |
11 |
6E |
00 |
02 |
00 |
00 |
; |
внимание, что все адреса |
| LBA |
- |
1177:00 |
15 |
00 |
0C |
01 |
14 |
00 |
64 |
00 |
00 |
11 |
6E |
00 |
02 |
00 |
00 |
; |
идут к сектору 116E! |
|
| LBA |
- |
1178:00 |
15 |
00 |
0C |
01 |
14 |
00 |
65 |
00 |
00 |
11 |
74 |
00 |
00 |
00 |
00 |
; |
резкий переход адресов |
| LBA |
- |
1179:00 |
15 |
00 |
0C |
01 |
14 |
00 |
64 |
00 |
00 |
11 |
6E |
00 |
02 |
00 |
00 |
; |
с 116E на 1174 (+6) |
| LBA |
- |
117A:00 |
15 |
00 |
0C |
01 |
14 |
00 |
65 |
00 |
00 |
11 |
74 |
00 |
00 |
00 |
00 |
; |
такова дискретность SEEKа |
| LBA |
- |
117B:00 |
15 |
00 |
0C |
01 |
14 |
00 |
65 |
00 |
00 |
11 |
74 |
00 |
00 |
00 |
00 |
; |
привода NEC! |
| LBA |
- |
117C:00 |
15 |
00 |
0C |
01 |
14 |
00 |
65 |
00 |
00 |
11 |
74 |
00 |
00 |
00 |
00 |
|
|
| LBA |
- |
117D:00 |
15 |
00 |
0C |
01 |
14 |
00 |
65 |
00 |
00 |
11 |
74 |
00 |
00 |
00 |
00 |
|
|
| LBA |
- |
117E:00 |
15 |
00 |
0C |
01 |
14 |
00 |
65 |
00 |
00 |
11 |
74 |
00 |
00 |
00 |
00 |
|
|
| LBA |
- |
117F:00 |
15 |
00 |
0C |
01 |
14 |
00 |
65 |
00 |
00 |
11 |
74 |
00 |
00 |
00 |
00 |
|
|
| LBA |
- |
1180:00 |
15 |
00 |
0C |
01 |
14 |
00 |
65 |
00 |
00 |
11 |
74 |
00 |
00 |
00 |
00 |
|
|
|
| LBA |
- |
1181:00 |
15 |
00 |
0C |
01 |
14 |
00 |
66 |
00 |
00 |
11 |
7A |
00 |
00 |
3B |
45 |
|
|
| LBA |
- |
1182:00 |
15 |
00 |
0C |
01 |
14 |
00 |
66 |
00 |
00 |
11 |
7A |
00 |
00 |
3B |
45 |
|
|
| LBA |
- |
1183:00 |
15 |
00 |
0C |
01 |
14 |
00 |
02 |
00 |
00 |
11 |
7F |
00 |
00 |
34 |
92 |
; |
117F - … |
| LBA |
- |
1184:00 |
15 |
00 |
0C |
01 |
14 |
00 |
66 |
00 |
00 |
11 |
7A |
00 |
00 |
3B |
45 |
|
|
| LBA |
- |
1185:00 |
15 |
00 |
0C |
01 |
14 |
00 |
66 |
00 |
00 |
11 |
7A |
00 |
00 |
3B |
45 |
|
|
| LBA |
- |
1186:00 |
15 |
00 |
0C |
01 |
14 |
00 |
66 |
00 |
00 |
11 |
7A |
00 |
00 |
3B |
45 |
|
|
|
| LBA |
- |
1187:00 |
15 |
00 |
0C |
01 |
14 |
00 |
02 |
00 |
00 |
11 |
81 |
00 |
00 |
34 |
92 |
; |
117F - 1181 диапазон |
| LBA |
- |
1188:00 |
15 |
00 |
0C |
01 |
14 |
00 |
02 |
00 |
00 |
11 |
7F |
00 |
00 |
34 |
92 |
; |
адресов, занятых субка- |
| LBA |
- |
1189:00 |
15 |
00 |
0C |
01 |
14 |
00 |
02 |
00 |
00 |
11 |
7F |
00 |
00 |
34 |
92 |
; |
нальной информацией |
| LBA |
- |
118A:00 |
15 |
00 |
0C |
01 |
14 |
00 |
02 |
00 |
00 |
11 |
81 |
00 |
00 |
34 |
92 |
; |
point'a == 2 |
| LBA |
- |
118B:00 |
15 |
00 |
0C |
01 |
14 |
00 |
02 |
00 |
00 |
11 |
80 |
00 |
00 |
34 |
92 |
|
|
| LBA |
- |
118C:00 |
15 |
00 |
0C |
01 |
14 |
00 |
02 |
00 |
00 |
11 |
81 |
00 |
00 |
34 |
92 |
|
|
| LBA |
- |
118D:00 |
15 |
00 |
0C |
01 |
14 |
00 |
66 |
00 |
00 |
11 |
7A |
00 |
00 |
3B |
45 |
|
|
|
| LBA |
- |
118E:00 |
15 |
00 |
0C |
01 |
14 |
00 |
64 |
00 |
00 |
11 |
8B |
00 |
02 |
00 |
00 |
; |
смотрите! резкий переход |
| LBA |
- |
118F:00 |
15 |
00 |
0C |
01 |
14 |
00 |
64 |
00 |
00 |
11 |
8B |
00 |
02 |
00 |
00 |
; |
с адреса 1181 на адрес |
| LBA |
- |
1190:00 |
15 |
00 |
0C |
01 |
14 |
00 |
64 |
00 |
00 |
11 |
8B |
00 |
02 |
00 |
00 |
; |
118B - 10 секторов пропу- |
| LBA |
- |
1191:00 |
15 |
00 |
0C |
01 |
14 |
00 |
64 |
00 |
00 |
11 |
8B |
00 |
02 |
00 |
00 |
; |
щено, причем это не про- |
| LBA |
- |
1192:00 |
15 |
00 |
0C |
01 |
14 |
00 |
64 |
00 |
00 |
11 |
8B |
00 |
02 |
00 |
00 |
; |
сто биение головки - этих |
| LBA |
- |
1193:00 |
15 |
00 |
0C |
01 |
14 |
00 |
64 |
00 |
00 |
11 |
8D |
00 |
02 |
00 |
00 |
; |
секторов в субканальных |
| LBA |
- |
1194:00 |
15 |
00 |
0C |
01 |
14 |
00 |
64 |
00 |
00 |
11 |
8D |
00 |
02 |
00 |
00 |
; |
данных нет вообще! И как |
| LBA |
- |
1195:00 |
15 |
00 |
0C |
01 |
14 |
00 |
64 |
00 |
00 |
11 |
8B |
00 |
02 |
00 |
00 |
; |
раз в них и содержатся |
| LBA |
- |
1196:00 |
15 |
00 |
0C |
01 |
14 |
00 |
65 |
00 |
00 |
11 |
92 |
00 |
00 |
00 |
00 |
; |
атрибуты трека ноль, а |
| LBA |
- |
1197:00 |
15 |
00 |
0C |
01 |
14 |
00 |
65 |
00 |
00 |
11 |
92 |
00 |
00 |
00 |
00 |
; |
раз так, то трек ноль все |
| LBA |
- |
1198:00 |
15 |
00 |
0C |
01 |
14 |
00 |
65 |
00 |
00 |
11 |
92 |
00 |
00 |
00 |
00 |
; |
таки есть на диске (иначе |
| LBA |
- |
1199:00 |
15 |
00 |
0C |
01 |
14 |
00 |
65 |
00 |
00 |
11 |
92 |
00 |
00 |
00 |
00 |
; |
бы эти сектора возращ.) |
|
<
Листинг 10 результат чтения субканальной информации из Lead-In приводом NEC
Здесь: дельта "уползания" составляет порядка 10 секторов, а зачастую даже менее того, однако сама упорядоченность секторов вообще никакая, а нулевых point'ов вообще нет. Сектора с адресами 1185h и 1186h (в которых, собственно, и хранятся атрибуты нулевых треков) внаглую отсутствуют – вместо этого привод спозиционировал головку на адреса 118Bh и 118Dh, в результате чего количество 64hpoint'ов (в "девичестве" – A0h) до неприличия возросло. Ко всему прочему абсолютные адреса секторов по непонятной причине перекочевали в поле относительных адресов, и если бы мы попытались проанализировать субканальную информацию согласно Стандарту, у нашей защиты точно бы съехала крыша.
Итак, несмотря громоздкость и трудности реализации защитного механизма, он все-таки может быть реализован так, чтобы уверенно отличать ключевой диск на любой из моделей приводов. Но стоит ли овчинка выделки или, говоря другими словами, каким образом защищенный диск можно взломать?
А вот со взломом у нас туго. Да, в принципе, такой диск можно скопировать, но только не Сlone CD или Алкоголем и не на всех моделях приводах. Для взлома пригодны лишь те приводы, что уверенно читают TOC и возвращают атрибуты нестандартных point'ов, поскольку ко всему этому может привязываться защита. "Постойте! – воскликните вы, – но ведь защита не должна закладываться на доступность TOC'а и атрибуты нулевого point'а, иначе программа окажется неработоспособна на некоторых моделях приводов! " Это верно, однако, если привод соглашается читать TOC, – отчего же его не проверить?
Если привод взломщика не позволяет читать содержимое TOC, взломщик не сможет восстановить оригинальный TOC (ну разве что отдизассемблирует весь защитный механизм целиком) и потому скопированный диск будет работать лишь на его приводе!
Правда, при наличии привода, читающего TOC и хорошо смазанных подшипников в котелке копирование защищенного диска осуществляется очень просто.
Достаточно лишь, считав TOC (команда READ TOC), считать и само содержимое диска на субканальном уровне (команды SEEK/READ SUBCHANNEL), а также содержимое основного канала (команда READ CD), после чего остается лишь сформировать CCD-, -IMG- и SUB-файлы и с помощью того же Clone CD записать их на диск. Однако такой взлом по зубам далеко не всякому хакеру, а с натиском желторотых пользователей эта защита без труда справится.
document.write('');
|
|
This Web server launched on February 24, 1997
Copyright © 1997-2000 CIT, © 2001-2009 |
| Внимание! Любой из материалов, опубликованных на этом сервере, не может быть воспроизведен в какой бы то ни было форме и какими бы то ни было средствами без письменного разрешения владельцев авторских прав. |
Уникальное предложение на сайте - от института.
|
<
Информационная безопасность
Альтернативы
В качестве альтернатив помещению сервисов в CE мне видится только разнос сервисов по разным физическим машинам или виртуализация, т.е. организация на одном физическом сервере нескольких виртуальных посредством серверных решений компаний VMware, SWsoft и аналогов. В Linux существует хорошее средство виртуализации - vserver, позволяющее размещать на одном компьютере несколько систем, объединенных лишь общим ядром. Правда, оба эти метода связаны с большими накладными расходами, поэтому в ряде случаев более оправдано использовать chrooted environment, если нет возможности нарастить оборудование.
Автоматизация
Еще раз хотелось бы заострить внимание на автоматизации процесса: сисадмины, пишите скрипты! Не забывайте про китайский принцип "три года упорного труда - десять тысяч лет счастья" (c) Мао Цзе-дун.
Если серьезно, то на каждый сервис вам понадобится 3 скрипта - для начального развертывания CE, для его аккуратного апгрейда без убийства хранящихся там данных и конфигов, и скрипт запуска/остановки. Так вы сможете поддерживать сервис в актуальном состоянии - обновляете в основной системе пакет с искомым сервисом, запускаете скрипт апгрейда выбранного CE и остается только заново его запустить.
В качестве конкретного примера приведу пример стартового скрипта для Apache в CE (продолжая начатую тему веб-сервера в CE): #!/bin/sh # start/stop/restart chrooted Apache web server # Den aka Diesel
PREFIX=/chroot/httpd APACHE_PREFIX=/usr MYSQL_SOCK=/var/run/mysql/mysql.sock
# если вы хотите использовать каталоги ~/public_html в CE, установите # HOMES_BIND=1 # и постоянно синхронизируйте $PREFIX/etc/passwd с основной системой
HOMES_BIND=0
httpd_start() { if [ -x $PREFIX/$APACHE_PREFIX/sbin/httpd ]; then echo "Starting Apache web server in the chroot environment..."
if [ HOMES_BIND = 1 ]; then mount --bind /home $PREFIX/home fi if [ -e $MYSQL_SOCK ]; then ln $MYSQL_SOCK $PREFIX$MYSQL_SOCK fi if ! `/usr/sbin/chroot $PREFIX $APACHE_PREFIX/sbin/httpd` ; then echo "ERROR" httpd_stop fi fi }
httpd_stop() { killall httpd if [ HOMES_BIND = 1 ]; then umount $PREFIX/home fi if [ -e $PREFIX/$MYSQL_SOCK ]; then rm -f $PREFIX/$MYSQL_SOCK fi }
httpd_restart() { httpd_stop sleep 1 httpd_start }
case "$1" in 'start') httpd_start ;; 'stop') httpd_stop ;; 'restart') httpd_restart ;; *) echo "usage $0 start|stop|restart" esac
Базовые принципы
Итак, приступим к детальному разбору того, как этот метод работает. Сразу необходимо отметить, что делать системный вызов chroot() может только root. Это обусловлено рядом факторов - в частности, злоумышленник мог бы, имея только пользовательские привилегии, обмануть setuid программу, поместив ее в специально подготовленный CE с подтасованным passwd файлом, что позволило бы ему поднять привилегии.
Основные проблемы при создании chrooted среды создает именно тот факт, что приложение "не видит" никаких файлов за рамками своего корневого каталога. В общем - сильная сторона оказывается одновременно и слабой, как это часто бывает в этой жизни. Из этого обстоятельства вытекает тот факт, что если для нормальной работы программы нужны какие-то библиотеки и дополнительные файлы - их придется скопировать внутрь CE. Если с библиотеками вопрос в ряде случаев можно решить, статически слинковав искомое приложение и получить его в виде одного большого бинарного файла, то с остальными файлами этот трюк не пройдет. Для того, чтобы создать оптимальную изолированную "камеру" для сервиса, мы должны достаточно хорошо знать его внутреннее устройство, чтобы скопировать все нужное, не прихватив при этом в CE лишнего, т.к. жесткие диски у вас наверняка не бесконечного объема. Частично эту проблему помогают решить инструменты, входящие практически в любой современный дистрибутив Linux.
Что это такое?
Данная статья посвящена одному из приемов усиления безопасности функционирования сервисов в Linux системах - помещению их в chrooted environment (далее - "CE"). CE - это, по сути, такое программное окружение, в котором приложение считает корневым каталогом какой-то отдельный (с точки зрения основной системы) каталог.
Термин "chrooted environment" происходит от имени системного вызова chroot() и соответствующей утилиты chroot, которая производит запуск программы, имя которой передается ей в качестве аргумента, в таком окружении с измененным корневым каталогом, путь к которому также передается в качестве аргумента. Программа, запущенная в CE, ограничена в доступе к файловой системе его рамками. Во FreeBSD существует подобный подход к изоляции программ - jail (тюрьма), что более образно описывает ее назначение - целевое приложение оказывается в программной "тюрьме", из которой достаточно проблематично выбраться. Широко распространенным примером CE являются FTP-сервера, большинство из которых по умолчанию работают с chroot - клиент, зашедший на сервер, не может увидеть файлы выше каталога, назначенного администратором в качестве корневого.
Доступ до части основной файловой системы
Полная изоляция - это хорошо, но не всегда то, что надо. Пример из жизни: у пользователей на сервере есть свои веб-страницы, лежащие в ~/public_html, и адресуемые http://site/~user/. Как быть с ними, если веб-сервер в CE? Копировать пользовательские файлы - абсурд. Снова воспользоваться жесткими ссылками будет чрезвычайно неудобно при большом количестве файлов и, ко всему же, жесткие ссылки не работают для каталогов. Есть идея лучше: воспользоваться возможностью монтировать каталог в каталог (mount с опцией --bind). Т.е. мы просто при старте веб-сервера монтируем /home в /chroot/httpd/home, например, а при остановке - размонтируем. Однако здесь есть крупный подводный камень, из-за которого я и рекомендую все время размонтировать такие каталоги после остановки сервиса - на этапе настройки вы наверняка не с первого раза создадите работающее CE, и, возможно, будете несколько раз стирать /chroot/service - и не дай Бог в этот момент не отмонтировать оттуда каталоги - вы уже наверняка догадались, что произойдет в этом случае - нужные файлы отправятся прямиком в /dev/null.
Инструментарий
Вот они, наши основные помощники по помещению приложения в "тюрьму":
chroot - основная утилита, описанная выше, делает системный вызов chroot() chrootuid - функционально отличается от просто chroot лишь тем, что может еще и менять UID процесса посредствов setuid() - эта утилита может быть полезной, если вы хотите, чтобы сервис работал не от root, а его авторы не предусмотрели такой возможности (может отсутствовать в вашем дистрибутиве) ldd - выводит информацию о зависимостях от общедоступных (shared) библиотек strace - позволяет отслеживать системные вызовы и сигналы, чрезвычайно мощная утилита практический опыт - чем больше, тем лучше
Если помещенное в CE приложение не работает или работает не так, как нужно, то алгоритм отладки такой:
с помощью ldd выясняем, какие из библиотек требуются, и копируем их в CE (естественно, сохраняя структуру каталогов) внимательно смотрим вывод программы и лог-файлы - часто запускаемый сервис сам говорит, что ему не хватает для работы анализируем лог-файлы сервиса, лежащие уже внутри CE (если таковые имеются) запускаем программу через strace и сохраняем вывод STDOUT в файл для дальнейшего анализа: strace chroot /chroot/service /path/to/service 2> ./strace.log
проверяем права доступа на файлы и каталоги внутри CE в случае неудачи - пытаемся еще раз пройтись по этой цепочке, думаем, советуемся со знакомым гуру, идем гуглить и совершаем прочие эзотерические действия.
Помимо уже упомянутых утилит, существуют и более продвинутые инструментальные решения по созданию CE, например - jailkit (работающий, кстати, не только на Linux, но и на FreeBSD, OpenBSD и MacOSX). Однако, по сути, этот пакет лишь делает за вас часть рутины, в любом случае пригодится знание того, как собрать CE руками.
Еще один практический совет - автоматизируйте свой труд, создавайте shell-скрипты генерации CE, постепенно дописывая их по ходу мигрирования сервиса в CE - тем самым вы избавите себя от ненужной механической работы и снизите вероятность ошибки.
Практический пример: Apache
Наверное, один из наиболее часто помещаемых в CE сервисов - веб-сервер Apache. Про это много написано и под разными углами, но я все же рискну повториться. Рассмотрим пошагово перенос в CE программной связки Apache 1.3.x + PHP 5 с учетом взаимодействия с СУБД MySQL (классический комплекс, именуемый в народе "LAMP" - Linux + Apache + MySQL + PHP). В примере предполагается, что мы имеем дело с дистрибутивной сборкой Apache в Slackware (для вашей системы файлы могут быть расположены немного по-другому, но принцип должен быть понятен).
Вот скрипт для автоматизированного создания CE: #!/bin/sh # create chrooted environment for Apache 1.3 + PHP 5 # Den aka Diesel
PREFIX=/chroot/httpd APACHE_PREFIX=/usr PHP_PREFIX=/usr APACHE_DATADIR=/var/www
# создаем структуру каталогов:
mkdir -p $PREFIX mkdir -p $PREFIX/dev mkdir -p $PREFIX/etc mkdir -p $PREFIX/lib mkdir -p $PREFIX/tmp mkdir -p $PREFIX/var/cache/proxy mkdir -p $PREFIX/var/run mkdir -p $PREFIX/$APACHE_PREFIX/bin mkdir -p $PREFIX/$APACHE_PREFIX/lib mkdir -p $PREFIX/$APACHE_PREFIX/sbin mkdir -p $PREFIX/$APACHE_PREFIX/libexec mkdir -p $PREFIX/var/log/apache mkdir -p $PREFIX/var/run/mysql mkdir -p $PREFIX/$PHP_PREFIX/lib/php mkdir -p $PREFIX/home
# выставляем 'sticky bit' на /tmp:
chmod 1777 $PREFIX/tmp
# создаем файл устройства /dev/null:
mknod $PREFIX/dev/null c 1 3 chmod 666 $PREFIX/dev/null chown root:sys $PREFIX/dev/null
# копируем конфигурационные файлы:
cat /etc/group|egrep "apache:|nobody:|nogroup:" > $PREFIX/etc/group cat /etc/passwd|egrep "apache:|nobody:" > $PREFIX/etc/passwd cat /etc/shadow|egrep "apache:|nobody:" > $PREFIX/etc/shadow chmod 640 $PREFIX/etc/shadow cp /etc/HOSTNAME $PREFIX/etc cp /etc/host.conf $PREFIX/etc cp /etc/hosts $PREFIX/etc cp /etc/nsswitch.conf $PREFIX/etc cp /etc/resolv.conf $PREFIX/etc cp /etc/localtime $PREFIX/etc cp -R /etc/apache $PREFIX/etc
# копируем данные и лог-файлы:
cp -R $APACHE_DATADIR $PREFIX`dirname $APACHE_DATADIR` cp -R /var/log/apache $PREFIX/var/log
# копируем бинарные файлы:
cp $APACHE_PREFIX/bin/htdigest $PREFIX/$APACHE_PREFIX/bin cp $APACHE_PREFIX/bin/mm-config $PREFIX/$APACHE_PREFIX/bin cp $APACHE_PREFIX/bin/htpasswd $PREFIX/$APACHE_PREFIX/bin cp $APACHE_PREFIX/bin/checkgid $PREFIX/$APACHE_PREFIX/bin cp $APACHE_PREFIX/bin/dbmmanage $PREFIX/$APACHE_PREFIX/bin cp $APACHE_PREFIX/sbin/ab $PREFIX/$APACHE_PREFIX/sbin cp $APACHE_PREFIX/sbin/apxs $PREFIX/$APACHE_PREFIX/sbin cp $APACHE_PREFIX/sbin/httpd $PREFIX/$APACHE_PREFIX/sbin cp $APACHE_PREFIX/sbin/logresolve $PREFIX/$APACHE_PREFIX/sbin cp $APACHE_PREFIX/sbin/rotatelogs $PREFIX/$APACHE_PREFIX/sbin cp $APACHE_PREFIX/sbin/apachectl-standard $PREFIX/$APACHE_PREFIX/sbin cp $APACHE_PREFIX/sbin/apacheconfig $PREFIX/$APACHE_PREFIX/sbin cp -R $APACHE_PREFIX/libexec/apache $PREFIX/$APACHE_PREFIX/libexec
# копируем библиотеки:
for BINARY in "$APACHE_PREFIX/sbin/httpd $APACHE_PREFIX/libexec/apache/libphp5.so $APACHE_PREFIX/lib/php/extensions/mysql.so"; do for i in `ldd $BINARY|awk '{print $3}'`; do d=$(dirname $i) if [[ $d != .* ]]; then mkdir -p $PREFIX$d; fi if [[ $d != .* ]]; then cp $i $PREFIX$d; fi done done cp -d /lib/libnss_compat* $PREFIX/lib cp -d /lib/libnss_dns* $PREFIX/lib cp -d /lib/ld-* $PREFIX/lib cp -d /lib/libnsl* $PREFIX/lib cp -R -d /usr/lib/gconv $PREFIX/usr/lib cp -R $PHP_PREFIX/lib/php $PREFIX/$PHP_PREFIX/lib cp -d -R /usr/lib/locale/en_GB $PREFIX/usr/lib/locale cp -d -R /usr/lib/locale/en_GB.utf8 $PREFIX/usr/lib/locale cp -d -R /usr/lib/locale/ru_RU $PREFIX/usr/lib/locale cp -d -R /usr/lib/locale/ru_RU.koi8r $PREFIX/usr/lib/locale cp -d -R /usr/lib/locale/ru_RU.utf8 $PREFIX/usr/lib/locale
Обратите внимание на несколько моментов:
из /etc/passwd мы взяли только записи про apache, nobody, nogroup (не стоит подвергать информацию о других учетных записях опасности быть украденой при взломе этого конкретного сервиса, исключение составляет только ситуация с использованием ~/public_html/) не забывайте про /etc/localtime, если хотите, чтобы сервис жил с вами в одной временной зоне по-минимуму можно было не копировать все бинарные файлы Apache, а обойтись только httpd
обвязка ldd в этом скрипте сделана на скорую руку (однако работает в подавляющем большинстве случаев) - имя какой-нибудь библиотеки, нестандартно выведенной, может не захватиться в переменную не забывайте про /etc/nsswitch.conf и resolv.conf при помещении в CE сетевых сервисов также не забывайте про библиотеки libnss, libnss_dns и libnsl при желании уменьшить объем, занимаемый библиотеками и исполняемыми бинарными файлами - после копирования и тестирования работоспособности CE сделайте им strip
файлы из /usr/lib/gconv и /usr/lib/locale нужны для корректной работы с локалями, отличными от английской (C) - без этих файлов, например, русские буквы не будут восприниматься как корректные символы алфавита, что может сказаться на работе регулярных выражений в PHP некоторым сервисам может требоваться не только файл устройства /dev/null, но и /dev/random вместе с /dev/urandom (например, для того же BIND - иначе у него не работают корректно функции шифрования) если вам для работы каких-нибудь CGI-скриптов необходим PERL, его так же необходимо поместить в CE, не забыв про /usr/lib/perl5
учтите, что если вы не предпримете никаких дополнительных мер, PHP функция mail() не будет работать в CE, т.к. она пытается вызвать бинарный файл SMTP-клиента, который отсутствует в CE (в интернете описаны методы обхода этого с использованием модулей из репозитария PEAR) не пренебрегайте возможностью установить (с помощью утилиты chattr) флаг иммунитета к изменениям (immutable) для важных файлов, которые не должны меняться в ходе работы - например, для конфигурационных файлов
Возможно, есть еще какие-то тонкости, однако я в своей практике с ними не сталкивался, и поэтому написать ничего про них не могу. Помещение MySQL в CE производится аналогично, никаких особых подводных камней там нет, помимо уже описанных.
Уязвимости CE
Как это ни прискорбно, наш мир далек от идеала, и программное обеспечение здесь не является исключением из правил. Из CE можно "выпрыгнуть", причем, иногда очень легко. Один из методов "побега" описан прямо в документации по chroot - цитирую: In particular, the super-user can escape from a `chroot jail' by doing `mkdir foo; chroot foo; cd ..'.
Чтобы не делать из этого материала руководства по побегу из chroot, не буду развивать эту тему - она достаточно хорошо освещена на соотвествующих тематических сайтах.
Итак, существует ряд проблем с безопасной работой в CE, однако существуют и контрмеры по их устранению. Одна из наиболее эффективных подпорок CE - это набор патчей на ядро под названием grsecurity. Эти патчи достойны настоящего параноика и позволяют достаточно туго затянуть гайки (вплоть до доведения системы до самого защищенного состояния - неработающего). Из интересующего нас в аспекте усиления CE можно отметить раздел 'Chroot jail restrictions', в котором:
запрет mount запрет двойных вызовов chroot() запрет использования pivot_root() (аналога chroot()) принудительная смена текущего каталога на "/" запрет установки suid и sgid флагов на файлы запрет fchdir() (иначе из CE можно сбежать через открытый файловый дескриптор, ведущий наружу) запрет создания файлов устройств запрет использования shared memory за границами CE запрет подключения к абстрактным Unix domain sockets запрет на управление процессами вне CE (чтобы из CE нельзя было убить внешний процесс либо еще как-то на него повлиять) запрет смены приоритета процессов вне CE (иначе возможна реализация DoS при выставлении минимального приоритета на другие работающие сервисы) запрет манипулирования sysctl записями запрет подключения модулей ядра, raw I/O операций, перезагрузки системы, смены системного времени, изменения файлов с иммунитетом и многое другое
Если вы подумаете: "а зачем такой концлагерь?" - я рискуя, окончательно разрушить вашу веру в устойчивость программного обеспечения, скажу, что почти каждый из пунктов перечисленного списка позволяет "сбежать" из CE. А вообще grsecurity содержит много интересного, рекомендую принять на вооружение. Единственный неприятный момент, связанный с этим набором патчей - некоторая инертность разработчика (порой выпуски свежих версий патчей задерживаются).
При упоминании grsecurity на ум сразу приходят патчи проекта Openwall (который уже вырос в дистрибутив Openwall GNU/*/Linux, ориентированный на усиление безопасности) - однако, они менее эффективны и не предоставляют возможности тонкой настройки параметров.
В качестве заключения
"Кто осведомлен - тот вооружен" - гласит древняя мудрость, поэтому подпишитесь на пару толковых списков рассылки по безопасности, вовремя устанавливайте обновления, берегите лог-файлы (еще лучше - складируйте их на другой машине), все время делайте резервные копии важной информации (лучше - две копии), переходите улицу только на зеленый свет и вообще меняйте работу на менее нервную ;)
PS: автор благодарит за конструктивные замечания, высказанные при подготовке статьи.
Статья написана по материалам доклада на .
Взаимодействие с другими сервисами
Итак, допустим, что мы благополучно упрятали сервис в CE. Казалось бы - дело сделано, можно идти пить согревающие напитки с друзьями, но в душу закрадываются какие-то смутные подозрения о том, что это не конец. И они вовсе не беспочвенны. Типовой пример - те же самые Apache + PHP + MySQL.
Предположим, что Apache с PHP у нас загорают в "тюрьме" CE, а MySQL "остался на свободе". Но им же надо как-то взаимодействовать друг с другом! Поместить MySQL в тот же CE - не очень хорошее решение (лучше его отсадить в отдельный CE, исходя из народной мудрости, учащей раскладывать яйца по разным корзинкам). С другой стороны, нарушать целостность CE тоже не хочется - иначе какой тогда в нем смысл? В такой ситуации есть неплохое решение: настроить связь с MySQL через UNIX domain socket (по умолчанию они так и взаимодействуют) и сделать на него жесткую ссылку (hard link) в CE с Apache. Единственное ограничение - жесткие ссылки работают только внутри одного раздела диска, поэтому лучше хранить все CE на одном разделе. В этой связи возникает новая проблема - слежение за тем, чтобы этот раздел не переполнился в результате действий пользователей или раздувания логов и тем самым не заблокировалась работа сервера (если речь идет о корневом разделе основной системы). Одним из эффективных путей предотвращения таких ситуаций может стать использование файловых квот, однако это уже выходит за рамки данной статьи. Помимо этого, не забывайте о том, что файл существует до тех пор, пока существует хотя бы одна жесткая ссылка на него - поэтому рекомендую в выше рассмотренном примере с MySQL убивать при остановке MySQL все жесткие ссылки на mysql.sock, а при запуске - создавать заново.
Альтернативным подходом является использование TCP сокетов для межпроцессного взаимодействия. Выбор конкретного решения - дело каждого.
Зачем это нужно?
Например, на вашем сервере есть несколько сервисов, и вам хотелось бы изолировать их друг от друга и от основной системы, чтобы спать спокойнее - ведь не бывает идеальных программ, и всегда найдется уязвимость, которую решит использовать злобный взломщик или просто скучающий script kiddie с новым эксплоитом. Ситуация с множеством сервисов на одной Linux-машине чрезвычайно распространена в небольших сетях - там сервер, изначально задумывавшийся как просто пограничный маршрутизатор локальной сети, постепенно обрастает функциями - на него свешивают почту, веб-сервер, базу данных, FTP-сервер, файловый сервер - благо, при небольшой нагрузке это все благополучно может работать на одной-единственной железке скромной конфигурации...
Если сервис, работающий в CE, окажется скомпрометированным, это принесет в общем случае вам меньше проблем, чем, если бы все происходило в рамках основной файловой системы. Если вы не беспокоитесь о безопасности и не являетесь системным администратором, которому дороги его подшефные сервера, то эта статья вряд ли будет вам интересна. Однако, согласно классической фразе: "если у вас паранойя, это еще не значит, что за вами не следят"...
Кстати, некоторые сервисы изначально подразумевают запуск в CE - например, распространенный DNS-сервер BIND создатели рекомендуют эксплуатировать в CE (создание окружения для нормальной работы этого сервиса подробно описано в официальной документации на BIND), при этом сам демон совершает системный вызов chroot(), если ему указать в качестве аргумента расположение корневого каталога CE. Аналогичная ситуация с MySQL - в конфигурационном файле указывается расположение подготовленного окружения для сервиса, демон при запуске помимо смены UID/GID, также вызывает chroot(). Те сервисы, в которых не предусмотрена работа в CE "из коробки", можно запускать с помощью уже упоминавшейся утилиты chroot.
Журналирование
Аналогичным же образом поступаем и с журналированием событий через syslog - настраиваем его для работы через дополнительный сокет (опция -a для syslogd) или пробрасываем жесткую ссылку с /dev/log в CE. Тем самым мы получаем обычное журналирование согласно syslog.conf, как будто бы сервис и не находился в CE.
Защита домашнего компьютера
,
Цель данного очерка - представить один из путей эффективной анти-(вирусной, спамовой, рекламной, шпионской, хакерской, и т.д.) защиты компьютера.
Здесь рассматривается вариант (домашнего или офисного) компьютера с эпизодическим (не постоянным) подключением к Интернету. Выбран именно этот вариант, как более интересный и сложный по сравнению со своим антиподом - постоянным подключением к Интернету; здесь всё просто: при загрузке ОС надо тупо запускать всё установленное защитное ПО - и хай воно борется с заразой!
Несколько ремарок. Для зануд: я владею "великим и могучим" достаточно свободно (см. ), чтобы не использовать килограммами смайлики, и если где-то коверкаю слова - то не по незнанию, а подчёркивания для.
Для передорослей: если вам что-то не нравится, оставьте своё мнение при себе; форум пришлось прикрыть именно из-за воинствующих подростков. Конструктив с благодарностью принимается.
Для сторонников теории заговора: я не рекламирую ничьих продуктов/услуг и не получаю за это мзду. Высказываю своё личное мнение, рождённое опытом работы с названными продуктами.
Для чайников: здесь не разжёвывается терминология и не проводится ликбез. Ориентируюсь на грамотных пользователей.
К делу. Целевой функцией наших действий является: максимизация защиты компьютера от всякой заразы; минимизация "тормозов"; по возможности, не "грузить" пользователя этими вопросами. Шибко умной железке вполне по силам самой о себе позаботиться. Рассматривается типовой случай домашнего компьютера среднестатистического пользователя.
Для затравки: за много лет не было ни единого случая, чтобы компьютер, "окученный" мною, подхватил заразу - ни мой личный - ни тех знакомых, которые просили меня об этой услуге. Более того, некоторые знакомые, "продавшиеся" другим халтурщикам, через какое-то время упрашивали меня прийти снова и сделать всё по-своему - у них либо "тормоза" страшные (а чего вы ждали от KAV?), либо зараза замучила.
Предполагается, что мы будем строить защиту девственно чистого компьютера.
Если это не так, пролечите его, или отформатируйте винт.
Итак, шаг первый. Для защиты от спама я сам пользуюсь почтовыми ящиками на - очень эффективное средство. Рекомендую. У них там используется хороший спам-фильтр; легитимные сообщения не пропадают. Я и сам пользуюсь этим сервисом, и другим рекомендую. На прочих известных порталах тоже что-то такое есть, но... не пробовал.
Шаг второй. Для защиты от вирусов, рекламного, шпионского софта, и прочей требухи я использую антивирус . Почему-то у многих людей вопрос выбора антивируса вызывает что-то вроде религиозной истерики. Не хочу им уподобляться; скажу лишь, что меня Dr. Web устраивает как меньшими требованиями к системным ресурсам, так и большей управляемостью: я могу по своему хотению включать/отключать любые его компоненты. Кроме того, я считаю, что при корректной настройке и наличии актуальных вирусных баз любой антивирус покажет уровень защиты, сопоставимый с конкурирующими продуктами. Иными словами, если ручки не кривые и базы свеженькие, можете расслабиться.
Вопрос актуальности вирусных баз является принципиальным, поэтому для типового домашнего компьютера выбрана следующая стратегия: базы обновляются при каждом соединении с Интернетом.
Любой антивирус обеспечивает, как минимум, 3 инструмента: сканер, дисковый монитор, и монитор почтового трафика.
Сканер - это программа, которую можно "натравить" на диск или папку, и он проверит все находящиеся там файлы на предмет наличия в них вирусов; и при необходимости, вылечит/удалит/переместит в карантин/запретит доступ, и т.д. Перед началом "окучивания" компьютера его (комп) необходимо прошерстить антивирусным сканером (со свежими базами) - дабы увериться в его непорочности.
Файловый монитор - это резидентная программа, которая пропускает через себя (частично или полностью) файловый ввод-вывод - все операции чтения и записи файлов - и также пытается найти и уничтожить заразу. Именно этот компонент любого антивируса более всего "притормаживает" систему.
Поэтому так важно, во-первых, правильно настроить его (предварительно почитав документацию), а во-вторых, минимизировать его использование (время активной работы), не снизив, однако, уровень защиты. Цели прямо противоположные, но мы что-нибудь придумаем. Увы, вся наша жизнь - это цепь компромиссов. Бескомпромиссна только костлявая...
Почтовый монитор - резидентная программа, которая перехватывает почтовый трафик (протоколы POP3 и SMTP) и его анализирует всё на тот же предмет. Несколько раз он меня выручал - когда по почте приходили вирусы. Mail.ru декларирует, что вся почта, идущая через их сервер, проверяется антивирусом, но то ли базы у них несвежие, то ли ещё что, но вирусы они иногда пропускают.
В бета-версии Dr. Web 4.33 присутствует ещё один монитор: теперь уже HTTP-трафика. Он, подобно почтовому, анализирует HTTP-протокол, и вылавливает заразу ещё "в проводах" - до того, как она оформилась в виде файла и попыталась записаться на ваш диск; хотя эту попытку должен пресечь файловый монитор. Красивая идея. Полезно для любителей "понавигировать" во всемирной помойке.
Заботясь о безопасности, в наше время нельзя ограничиваться одним только антивирусом. Хороший современный брандмауэр - вот то, что нам нужно! Мне нравится . Кроме функций собственно файрволла, его дополнительные модули (плагины) выполняют полезные функции: вырезают рекламу с web-страниц, ограничивает доступ к указанным ресурсам, позволяет избирательно разрешить/запретить работу интерактивных элементов на сайтах: cookies, скриптов, Flash, Gif, всплывающих окон, и т.д.
Итак, состав нашей защиты: все компоненты , а также . Нужен ещё хороший планировщик, который умеет реагировать на события - для того, чтобы всё это добро висело в памяти и тормозило работу компьютера не постоянно, а только тогда, когда комп действительно нуждается в защите. Кроме тормозов, вызванных файловым монитором, это хозяйство ведь занимает в оперативной памяти многие десятки мегабайт! Для обладателей не самых последних конфигураций железа свопинг, вызванный этим обстоятельством, может привести к дополнительным "тормозам".
Как я уже говорил, всем этим вполне может "рулить" сам компьютер.
Итак, общая картина работы такова. "Чистенький" компьютер загружается, и ничто ему не мешает при ходьбе... Вы можете спокойно играть или работать. Как только возникает необходимость, адекватная защита сразу же появляется. Рассмотрим четыре типичных случая, когда возникает потребность в защите:
Осуществляется выход в Интернет.
1.1. Дозвон до провайдера. В этот момент в память загружаются , "Spider Guard" (файловый монитор Dr. Web), "Spider Mail" (почтовый монитор Dr. Web), "Spider Gate" (монитор HTTP-трафика).
1.2. Соединение. Сразу после соединения выполняется автоматическое обновление вирусных баз: с сайта производителя скачивается весь свежачок. А так как все три компонента используют одни и те же базы, чувствуем себя защищёнными "по самое не балуйся".
1.3. Производится синхронизация локальных часов компьютера с атомными часами - маленькое удобство.
1.4. Разрыв соединения. Всё это хозяйство (четыре защитных компонента) "вываливается" из памяти с тем, чтобы не тормозить работу в дальнейшем.
В дисковод вставляется CD или DVD-диск. При этом "взлетает" файловый монитор - мимо него не проскочит ни одна дрянь, даже если ею забит весь диск. А так как вирусные базочки у нас свеженькие (помните автообновление в каждом сеансе связи?), мы заслуженно имеем моральное удовлетворение.
2.1. При извлечении диска из привода файловый монитор сам "вывалится" из памяти - и компьютер опять не тормозит нисколечко!
В USB-порт вставляется флеш-накопитель. Всё происходит точно так же, как и в пункте 2.
В дисковод 3.5 '' вставляется дискета. Вот уж это событие я не знаю, как отследить. Поэтому всем усерам на панели быстрого запуска делаю два значка - для запуска и остановки службы "SpIDer Guard for Windows NT" - файлового монитора. И предупреждаю их: "перед вставкой дискеты нажми вот эту пимпочку, а после изъятия - эту".
Остаётся надеяться на его здравое желание оставить компьютер здравым.
Итак, мы перекрыли все каналы поступления "заразы" извне, и при этом не напрягли усера (всё крутится само собой, прям как у Емели), и не затормозили работу его системы. Честь нам и хвала!
Теперь пару слов о том, как этого добиться. Для того, чтобы всё так красиво работало, придётся наши защитные компоненты устанавливать не "по умолчанию", а с выдумкой, с огоньком. Разработчики софта, печась о нашей безопасности, иногда не думают об эффективности. Поэтому, если позволить всем служебным софтинам работать так, как им хочется, то для пользователя ресурсов может и не остаться...
Во время установки Dr. Web следует указать выборочную установку (см. ). "Родной" планировщик не стОит устанавливать: мы и так воспользуемся планировщиком, только более функциональным.
После успешной установки Dr. Web необходимо изменить метод запуска службы "SpIDer Guard for Windows NT" на ручной, а также удалить из автозагрузки (при помощи "msconfig") "spiderml" и "spidergate". Нечего им делать в отсутствие соединения с инетом.
Точно также, после установки , переводим в режим ручного запуска службу "Outpost Firewall Service".
Теперь устанавливаем планировщик . Он хорош своею компактностью, быстротою и мощностью языка заданий. А также халявностью для жителей б. СССР. Примечание. После установки и регистрации в его настройках (см. ) можно выключить "Непотопляемый режим", или отключить соответствующую службу. Лишнее это в наше время.
Не пугайтесь, вам не придётся писать скрипты для него. Я сделал это за вас. Вот, и пользуйтесь.
Единственное, что вам может понадобиться отредактировать в скрипте - это букву CD (DVD) дисковода, а также раскомментировать события "OnFlashInsert" и "OnFlashEject" и проверить правильность буквы USB-накопителя.
Если вы всё сделаете правильно, наградой вам будет надёжная защита и отсутствие тормозов в работе.
Конечно, хорошо бы периодически выполнять обновление Windows, а также запускать сканер, дабы убедиться в отсутствии всяких бяк. Но это уж оставим на совести пользователя, так как на домашнем компьютере, который включается без всякого расписания, тяжеловато запланировать эти задания так, чтобы они не мешали пользователю.
Информационная безопасность
Модель вероятностного контроля доступа к ресурсам
Как и ранее, будем считать, что чем выше полномочия субъекта и категория объекта, тем соответственно, меньше их порядковый номер в линейно полномочно упорядоченных множествах субъектов и объектов — С = {С1,…, Ск} и О = {О1,…, Оk}). Обозначим же через Pi вероятность того, что документ i-й категории «заражен» макровирусом, при этом (как было сказано выше) априори имеем: P1 < P2 <…< Pk.
Беря во внимание тот факт, что макровирус начинает действовать (что может нести в себе угрозу «заражения») лишь после прочтения его соответствующим приложением и что предотвращать следует возможность «заражения» документа более высокой категории макровирусом из документа более низкой категории (после его прочтения приложением), получаем следующую матрицу доступа F, описывающую вероятностную модель контроля доступа, реализуемую для антивирусного противодействия: 
Видим, что при реализации данной модели контроля доступа разрешается запись документов, имеющих меньшую вероятность заражения макровирусом в объекты, документы в которых имеют большую вероятность заражения макровирусом — обратное запрещено, то есть предотвращается повышение вероятности «заражения» документов более высокой категории конфиденциальности, за счет того, что одновременно с ними на одном и том же компьютере могут создаваться, обрабатываться и храниться документы более низкой категории, вероятность «заражения» макровирусом которых выше.
Видим, что при реализации данной схемы вероятность «заражения» документа более высокой категории, например, O1 (P1) не изменяется в связи с тем, что на том же компьютере обрабатывается информация более низкой категории, например, Ok (Pk). При этом будем понимать, что режимы обработки информации различных категорий могут кардинально различаться (например, при обработке на одном компьютере открытой Оk и конфиденциальной информации О1, имеем: Pk >> P1, причем в зависимости от реализованных правил и организационных мер по обработке конфиденциальных данных это отношение может составлять сотни, тысячи и более раз, то есть именно во столько раз можно снизить вероятность «заражения» конфиденциальных данных макровирусами, хранящимися в открытых данных, для которых порою, Pk = 1).
Назначение механизма контроля доступа к ресурсам
Ключевым механизмом защиты информации является контроль доступа к ресурсам, основанный на задании и реализации правил разграничения доступа к ресурсам для пользователей. Задаваемые правила доступа всегда могут быть представлены соответствующей моделью (или матрицей доступа).
Пусть множества С = {С1,…, Ск} и О = {О1,…, Оk} — соответственно линейно упорядоченные множества субъектов и объектов доступа. В качестве субъекта доступа Сi, i = 1,…, k рассматривается как отдельный субъект, так и группа субъектов, обладающих одинаковыми правами доступа (заметим, что на практике это могут быть как различные пользователи, так и один и тот же пользователь, обладающий различными правами доступа при различных режимах обработки информации), соответственно, в качестве объекта доступа Оi, i = 1,…, k может также рассматриваться как отдельный объект, так и группа объектов, характеризуемых одинаковыми правами доступа к ним.
Пусть S = {0, Чт, Зп} — множество прав доступа, где «0» обозначает отсутствие доступа субъекта к объекту, «Чт» — разрешение доступа для чтения объекта, «Зп» — разрешение доступа для записи в объект.
Каноническую модель контроля доступа (модель контроля доступа, реализующая базовые требования к механизму защиты) можно представить матрицей доступа D, имеющей следующий вид:

Под канонической моделью контроля доступа для линейно упорядоченных множеств субъектов (групп субъектов) и объектов (групп объектов) доступа понимается модель, описываемая матрицей доступа, элементы главной диагонали которой «Зп/Чт» задают право полного доступа субъектов к объектам, остальные элементы «0» задают запрет доступа субъектов к объектам.
Заметим, что каноническая модель контроля доступа описывает режим изолированной обработки информации, при котором объекты не могут служить каналами взаимодействия субъектов.
Сегодня при реализации частных решений по противодействию внутренним IT-угрозам широко используется полномочный контроль доступа. Его практическое использование в данных приложениях обусловлено тем, что в корпоративных системах, как правило, на одном и том же компьютере обрабатывается различная по уровню конфиденциальности информация, что позволяет ее категоризовать («открытая», «конфиденциальная», «строго конфиденциальная» и т.
д.), при этом необходимо обеспечить различные режимы обработки информации разных категорий на основе задания соответствующих полномочий субъектам доступа (откуда и название) к категоризованным объектам.
Основу полномочного контроля доступа составляет способ формализации понятий «группа пользователей» и «группа объектов», на основании вводимой шкалы полномочий. Наиболее широко на практике используется способ иерархической формализации отношения полномочий, состоящий в следующем. Иерархическая шкала полномочий вводится на основе категоризования данных (открытые, конфиденциальные, строго конфиденциальные и т. д.) и прав допуска к данным пользователей (по аналогии с понятием «формы допуска»). Будем считать, что чем выше полномочия субъекта и категория объекта, тем соответственно, меньше их порядковый номер в линейно полномочно упорядоченных множествах субъектов и объектов — С = {С1,…, Ск} и О = {О1,…, Оk}).
Соответствующая формализация правил доступа субъектов к объектам при этом, как правило, сводится к следующему:
субъект имеет право доступа «Зп/Чт» к объекту в том случае, если полномочия субъекта и категория объекта совпадают;
субъект имеет право доступа «Чт» к объекту в том случае, если полномочия субъекта выше, чем категория объекта;
субъект не имеет прав доступа к объекту в том случае, если полномочия субъекта ниже, чем категория объекта.
Матрица доступа D, описывающая полномочную модель контроля доступа, имеет следующий вид: 
Таким образом, основная задача, решаемая при реализации данного способа контроля доступа, состоит в предотвращении возможности понижения категории информации при ее обработке. Иногда дополнительно вводится правило, разрешающее запись информации более низкой категории в объекты более высокой категории, что также не противоречит идее противодействия понижению категории информации; матрица доступа D, описывающая полномочную модель контроля доступа, при этом имеет следующий вид: 
Возможность работы одного и того же пользователя с данными различных категорий большинством известных реализаций полномочного контроля доступа обеспечивается тем, что в системе реализуются динамические полномочия пользователя, изменяемые применительно к тому, с документом какой категории пользователь работает.
Корректность реализации полномочного контроля здесь обеспечивается тем, что разрешается изменять категорию лишь в сторону ее повышения (Ck Ck–1, …С1) — после чтения открытого документа пользователю разрешается сохранять данные в объект категории «открыто», после чтения конфиденциального документа пользователю разрешается сохранять данные в объект категории «конфиденциально», причем все открытые ранее документы категории «открыто» также разрешается сохранять только в объект категории «конфиденциально».
В порядке замечания отметим, что само это решение уже существенно снижает эффективность защиты информации, не позволяя обеспечить разные режимы обработки информации различных категорий. Поясним сказанное, при этом не будем забывать, что основу разграничительной политики доступа к ресурсам в ОС Windows составляет назначение атрибутов доступа объектам и привилегий пользователям. Среди этих привилегий есть очень важные, например, разрешить только локальный вход в систему и др. Привилегии назначаются учетной записи. При рассмотренном же подходе к решению задачи (полномочный контроль доступа), доступ к информации различных категорий осуществляется под одной и той же учетной записью, что делает невозможным при таком решений назначать различные привилегии пользователю при обработке информации различной категории. На наш взгляд, уже этого достаточно, чтобы признать подобное решение не самым удачным. Однако в статье речь пойдет о другом.
Недостатки частного решения. Комплексный
Сравним матрицы D и F. Видим, что они полностью противоречат друг другу, то есть требования к реализации полномочного контроля доступа при решении альтернативных задач защиты информации не то чтобы были различны — они противоречивы.
С точки зрения противодействия внешним IT-угрозам (в части антивирусной защиты) практическое использование механизмов полномочного контроля доступа недопустимо. Это обусловливается тем, что, как видно из проведенного исследования, при реализации частного решения, основанного на использовании полномочного контроля доступа, кардинально снижается эффективность противодействия внешним IT-угрозам.
В порядке замечания отметим, что повышение вероятности вирусного воздействия на конфиденциальные данные — это не единственная причина снижения эффективности противодействия внешним IT-угрозам при реализации полномочного контроля доступа. В этом случае повышается и вероятность успешной сетевой атаки, так как сетевые службы в этом случае запускаются под учетной записью, имеющей доступ к конфиденциальной информации, и др.
Прежде рассмотрим, какую информацию мы категоризуем, применительно к решению задачи антивирусной защиты. Естественно, что качественное отличие в обработке имеет открытая информация и конфиденциальная информация, то есть мы можем выделить две основные категории: «открыто» и «конфиденциально». При этом обработка конфиденциальной информации различных категорий, в части вероятности быть исходно «зараженной» макровирусом, уже отличается не столь существенно. С учетом сказанного на практике имеет смысл рассматривать прежде всего следующее отношение вероятностей того, что документ i-й категории «заражен» макровирусом, обозначив категорию «открыто», как k, имеем: P1 = P2 =…=Pk–1 << Pk.
Естественно, что если мы не можем разрешить ни чтения, ни запись (так как эти требования противоречивы в матрицах доступа), то остается лишь одно решение, связанное с полным запретом доступа. С учетом сказанного получаем модель полномочного контроля доступа, реализация которой позволяет решать рассмотренные альтернативные задачи в комплексе, описываемую матрицей доступа D(F): 
Заметим, что при таком подходе к реализации полномочного контроля доступа обработка открытых данных по сути полностью изолируется от обработки конфиденциальных данных. Результатом такого решения, никак не противоречащего идее обработки данных на основе полномочий пользователей и категорий объектов, является то, что повышение вероятности «заражения» макровирусом открытых данных никак не сказывается на вероятности «заражения» макровирусом конфиденциальных данных, что определяется условием: P1 = P2 = … = Pk–1 << Pk. Важным здесь является тот момент, что если на вероятность «заражения» макровирусом открытых данных повлиять практически невозможно, кроме как уменьшить ее значение, за счет применения специализированных антивирусных средств защиты (что, с одной стороны, не даст решения в общем виде, так как сигнатурный анализ позволяет находить только известные макровирусы, с другой стороны, в данных приложениях выглядит несколько странным — защищаем открытые данные, вообще говоря не очень и нуждающиеся в защите, чтобы в конечном счете уберечь от «заражения» конфиденциальные данные), то вероятность «заражения» макровирусом конфиденциальных данных можно существенно снизить (на порядки — в сотни, в тысячи, а может быть, и более раз, реализовав соответствующие организационные мероприятия по их обработке (которые и так априори должны быть реализованы, но уже с целью противодействия понижению их категории)).
Если под отдельной учетной записью реализуется доступ во внешнюю сеть, причем под этой учетной записью не разрешен доступ к конфиденциальным данным, то значительно снижается и вероятность несанкционированного доступа к конфиденциальной информации и из сети.
Матрица D(F) иллюстрирует тот факт, что при обработке на компьютере информации только двух категорий («открыто» и «конфиденциально» — наиболее распространенный случай), с точки зрения решения задачи защиты информации в комплексе использование полномочного контроля доступа недопустимо (а это ведь самый распространенный случай категоризования информации на практике).
В порядке замечания отметим, что в общем случае, используя рассмотренный подход (запрещая соответствующие права доступа), можно формировать различные правила контроля доступа (различные варианты защиты от «заражения» макровирусом конфиденциальных данных). Один из примеров соответствующей матрицы (изолируется обработка данных, наивысшей категории) доступа представлен ниже: 
В порядке замечания отметим, что при условии: P1 << P2 <<…<< Pk–1 << Pk должна быть реализована каноническая модель контроля доступа.
Видим, что при реализации комплексного подхода к решению уже не целесообразна какая-либо жестко заданная формализация отношений на основе меток безопасности (или категорий и полномочий), в данном случае целесообразно задание правил разграничения доступа субъектов к объектам на основе матрицы доступа, что позволяет реализовать необходимые для конкретных условий использования средства защиты информации правила разграничения доступа, обеспечивающие эффективное противодействие как внутренним, так и внешним IT-угрозам.
Задачи антивирусной защиты в корпоративных приложениях
Классически задача защиты информации состоит не только в защите от нарушения ее конфиденциальности, но и в обеспечении ее доступности и целостности. А в этой части особое внимание следует обратить на противодействие возможному ее «заражению» макровирусами, что является уже задачей противодействия внешним IT-угрозам.
Проиллюстрируем, в чем состоит особенность рассматриваемых приложений (обработка информации на предприятии).
Обработка категоризованной информации (например, «конфиденциально» и «открыто») априори предполагает, что в первую очередь объектом защиты является информация более высоких категорий (в частности, в первую очередь следует защищать конфиденциальную информацию, работа с открытой информацией в данных приложениях является опциональной, и ее защита не столь важна).
Обработка категоризованной информации (например, «конфиденциально» и «открыто») априори предполагает различные режимы создания, обработки и хранения информации различных категорий, причем, чем выше категория информации, тем более жесткие ограничения накладываются на ее обработку (в частности, конфиденциальную информацию, как правило, разрешается создавать только на вычислительных средствах предприятия, причем определенным набором приложений, хранение и обмен данной информацией по сети либо с использованием мобильных накопителей также осуществляется между вычислительными средствами корпоративной сети, которые должны быть защищены, что требует обработка конфиденциальных данных, открытая же информация может поступать из непроверенных источников, не предполагающих реализации каких-либо регламентов по ее созданию, обработке и хранению).
Как следствие, вероятность того, что «заражен» макровирусом открытый документ на порядки выше, чем конфиденциальный, соответственно, чем выше категория документа (жестче регламенты на режимы его обработки), тем меньше вероятность того, что документ «заражен» макровирусом.
Из всего сказанного можем сделать очень важный вывод: чем ниже категория документа, тем менее он нуждается в защите от «заражения», что, в том числе, сказывается на реализуемых режимах его обработки, как следствие, тем большей вероятностью быть «зараженным» он характеризуется.
С учетом же того, что на одном и том же компьютере обрабатывается как открытая (которая имеет большую вероятность «заражения»), так и конфиденциальная (которую необходимо защищать от «заражения») информация, может быть сформулирована задача антивирусной защиты в следующей постановке: обеспечить защиту конфиденциальных данных от макровирусов, которыми с большой вероятностью могут быть «заражены» открытые документы, то есть предотвратить распространение вируса на конфиденциальные данные. В общем же случае (при наличии нескольких категорий конфиденциальности) задача может быть сформулирована следующим образом: предотвратить распространение вируса на данные более высокой категории конфиденциальности.
В заключение отметим, что средство
В заключение отметим, что средство защиты должно решать в комплексе необходимый набор задач защиты, актуальных для конкретного приложения, в частности, применительно к защите конфиденциальной информации — обеспечивать противодействие как внутренним, так и внешним IT-угрозам.
Реализация же частных решений не должна снижать результирующей эффективности защиты информации, что возможно ввиду того, что решения для альтернативных типов угроз могут взаимно исключать друг друга, вследствие чего реализация частного решения может приводить к повышению эффективности противодействия одной группе угроз за счет снижения эффективности противодействия другой группе угроз.
Защита информации в корпоративных приложениях. Частные решения
А. Щеглов, А. Оголюк
Сегодня мало кто ставит под сомнение необходимость дополнительной защиты современных ОС семейства Windows. Однако возникают вопросы: какие задачи должно решать дополнительное средство защиты, в какой части и каким образом следует усиливать встроенные механизмы ОС?
Все многообразие угроз компьютерной безопасности можно свести к двум большим группам: внутренние и внешние IT- угрозы.
Появление понятия внутренних IT-угроз для ОС Windows связано с началом использования ОС семейства Windows для обработки конфиденциальной информации в корпоративных приложениях. Конфиденциальная информация априори является потенциальным объектом несанкционированного доступа (НСД), так как обладает потребительской стоимостью для злоумышленников, то есть является товаром.
С учетом же того, что в основе архитектуры защиты современных универсальных ОС семейства Windows (не будем забывать, что это универсальные ОС, изначально созданные как персональные для домашнего использования) лежит принцип полного доверия к пользователю, некоторые ключевые механизмы защиты, встроенные в современные ОС Windows, по этой причине не могут обеспечить эффективного противодействия внутренним IT-угрозам — угрозам НСД к информации со стороны санкционированных пользователей (инсайдеров — пользователей, допущенных к обработке конфиденциальной информации в рамках выполнения своей служебной деятельности), именно санкционированные пользователи и несут в себе наиболее вероятную угрозу хищения конфиденциальных данных предприятия. Как следствие, эта задача сегодня не решается встроенными механизмами защиты ОС Windows, поэтому ее решение должно быть возложено на добавочные средства защиты. Понятие внешних IT-угроз для ОС Windows появилось гораздо раньше, но опять же в полной мере проявилось с началом использования ОС семейства Windows для обработки конфиденциальной информации в корпоративных приложениях, что опять же связано с высокой потребительской стоимостью конфиденциальных данных для злоумышленников.
И здесь ключевой причиной, на наш взгляд, является исторический подход к созданию универсальных ОС. Несмотря на то что архитектура защиты при переходе от версии к версии претерпевает заметные изменения, она и по сей день имеет принципиальные архитектурные недостатки (например, ошибки в приложениях никак не должны сказываться на уровне безопасности информации, защиту которой осуществляет ОС). Другая проблема кроется в систематически обнаруживаемых ошибках программирования. Здесь, вообще говоря, получается некий замкнутый круг. Очевидно, необходимо кардинально менять архитектуру защиты, что требует времени и серьезной проработки решений, но рынок требует обратного — необходимо максимально быстро создавать и поставлять на рынок решения с новыми потребительскими свойствами, а это возможно лишь при условии максимального использования существующего программного кода. Когда же речь заходит о потребительских свойствах, то в первую очередь разработчиком расширяются те свойства продукта, которые максимально востребованы (если изделие максимально ориентируется на использование частными лицами, то отнюдь не обеспечиваемый уровень информационной безопасности становится его основным потребительским свойством).
В результате получаем следующую статистику уязвимости ОС Windows. В 2005 году в ОС Windows было выявлено 812 «дыр» (исследования US-CERT). Специалисты из McAfee отмечают, что из 124 «дыр», обнаруженных в Windows XP Professional на сайте Secunia (Security Provider), 29 так и остались не устраненными, что дало компании основание присвоить Windows статус критически опасной ОС. Действительно, наличие уязвимостей (или «дыр») в системе делает ее защиту просто бесполезной — что толку в том, сколько и каких механизмов защиты реализовано, если есть известный канал НСД к информации?
Вывод: на сегодняшний день в корпоративных приложениях при защите конфиденциальной информации в равной мере актуальны задачи противодействия и внутренним, и внешним IT- угрозам.
Таким образом, на основании данного вывода можно заключить, что добавочное средство защиты конфиденциальной информации, используемое в корпоративных приложениях, должно быть комплексным — должно решать задачи защиты информации в части противодействия как внутренним, так и внешним IT- угрозам.
Несмотря на это очевидное требование, сегодня на рынке средств защиты появляется все больше систем, ориентированных на решение частных задач, в том числе призванных оказывать противодействие внутренним IT-угрозам. Однако, этот эффект (как мы покажем далее) порою может достигаться за счет снижения эффективности противодействия внешним IT- угрозам, что, на наш взгляд, недопустимо.
Для иллюстрации сказанного будем рассматривать вопросы реализации лишь одного механизма защиты (правда, отметим, ключевого в части решения задач противодействия внутренним IT-угрозам) — механизма контроля доступа к ресурсам.
Информационная безопасность
Агрегирование
После консолидации событий начинается процесс их агрегирования, т.е. группирования однотипных событий вместе, что позволяет получить на экране вместо 10000 повторяющихся строк "UDP-Scan" или "SQL_SSRP_StackBo" (краткое название атаки Slammer в системе RealSecure Network 10/100) всего лишь одну строчку, которая дополнена новым параметром "число событий" (см. Таблицу 3).
Таблица 3. Снижение объема информации, отображаемой на консоли
| Степень риска |
Событие |
Число событий |
Источник |
| Низкая |
UDP-Scan |
11385 |
194.98.93.252 |
| Высокая |
Backdoor-BO2k |
1 |
194.98.93.252 |
| Высокая |
SQL_SSRP_StackBo |
1567 |
139.92.229.160 |
| : |
: |
: |
: |
Иными словами, агрегирование облегчает отображение данных и их анализ. Но и этого недостаточно. Агрегирование не спасает от появления сообщений об атаках, которые не несут с собой никакой угрозы. Нужна более интеллектуальная обработка событий, которую дает механизм корреляции.
Консолидация событий
Первый шаг в снижении нагрузки на администратора - объединение всех событий от разнородных средств защиты информации на одной консоли, т.е. консолидация, которая нужна тогда, когда администратор шалеет от постоянно мелькающих на экране сообщений, которые невозможно, не то, что проанализировать, а даже уследить (см. Таблицу 2). Несколько сотен тысяч событий в день - это уже реальность наших дней. А в крупных сетях, ежедневная порция информации, которая сваливается на администратора, может превысить миллион событий. Ни один человек не справится с такими объемами информации.
Таблица 2. Консолидация событий на примере системы RealSecure SiteProtector с установленным модулем Third Party Module
| Степень риска |
Событие |
Имя сенсора |
Тип сенсора |
| Низкая |
fw-cisco~ids-packet-not-IPSEC-packet |
cisco_fw_ras |
Cisco PIX FW |
| Высокая |
fw-checkpoint~SYN Attack |
cp_fw_dmz |
Check Point FW |
| Высокая |
Backdoor-BO2k |
network_sensor_1 |
RealSecure Network |
| : |
: |
: |
: |
Консолидация - это не просто сбор и помещение данных в единое хранилище. Это еще и их нормализация, т.е. устранение избыточной информации. Другими словами, в процессе нормализации SIMS удаляет повторяющиеся данные об атаках, полученных, например, от системы обнаружения атак и межсетевого экрана, и исключает противоречивость в их хранении. Идеальной является ситуация, когда один факт об атаке хранится только в одном месте. На этом же этапе может происходить приведение всех данных к единому времени. Это особенно важно, если управляемые средства защиты разбросаны по всем часовым поясам нашей необъятной Родины.
Учитывая, что производители средств защиты до сих пор не пришли к унификации формата сообщений об атаках, каждый разработчик SIMS по-своему решает проблему приведения всех сообщений к единому виду. Надо сказать, что задача это нетривиальная, т.к. системы обнаружения атак, межсетевые экраны, средства VPN, антивирусные системы и т.д. фиксируют разные параметры, связанные с несанкционированными действиями.
Собрав все данные в одном месте, мы не избавились от проблемы огромных объемов информации, отображаемых на консоли администратора безопасности, которую призван устранить механизм агрегирования.
Корреляция на службе безопасности
Лукацкий А.В., , опубликовано в журнале BYTE #10/2003
С чем регулярно приходится сталкиваться администратору безопасности? Разумеется с постоянным потоком сообщения от обслуживаемых им средств защиты о тех или иных проблемах с безопасностью. В качестве примера таких сообщений можно назвать:
Сканирование периметра сети Подбор пароля на узлах, видимых из Интернет Атаки червей Slammer и т.п. Использование уязвимостей Web-сервера и т.п.
Такие сообщения могут поступать от различных средств защиты, начиная от фильтрующего маршрутизатора и межсетевого экрана и заканчивая системами обнаружения атак и системами контроля содержимого. Одна из первых задач администратора безопасности отделить "зерна от плевел" и определить, какие атаки требуют немедленной реакции, какие подождут, а какие можно спокойно проигнорировать.
Все бы ничего, если бы все сообщения, сгенерированные средствами защиты соответствовали реальным атакам. Однако действительность такова, что атак, которые действительно могут нанести ущерб ресурсам корпоративной сети несоизмеримо меньше, чем событий, фиксируемых защитными механизмами.
Многие специалисты считают, что ложное обнаружение лучше, чем отсутствие сообщения об атаке. Однако это как раз та ситуация, когда количество переходит в качество. Со временем это становится головной болью любого администратора, которому приходится решать, реагировать на появившееся на консоли сообщение или проигнорировать его. В результате администратор просто перестает реагировать не только на ложные, но и на любые другие сообщения, в т.ч. и влекущие за собой тяжелые последствия. Например, в Таблице 1 показан фрагмент журнала регистрации широко известной в России системы обнаружения атак RealSecure Network 10/100, которая зафиксировала распространение червя Slammer, нашумевшего в начале этого года. Таких записей за период в один день в журнале может быть несколько десятков тысяч, ведь, как можно видеть, скорость распространения Slammer составляет несколько узлов в секунду.
Таблица 1. Атака червя Slammer
| Дата |
Время |
Событие |
Нарушитель |
Цель |
Протокол |
Порт источника |
Порт назначения |
| 4/8/2003 |
23:14:53 |
SQL_SSRP_StackBo |
194.98.93.252 |
139.92.229.160 |
UDP |
1690 |
1434 |
| 4/8/2003 |
23:14:54 |
SQL_SSRP_StackBo |
139.92.229.160 |
213.253.214.34 |
UDP |
1080 |
1434 |
| 4/8/2003 |
23:14:54 |
SQL_SSRP_StackBo |
139.92.229.160 |
213.253.214.35 |
UDP |
1081 |
1434 |
| 4/8/2003 |
23:14:54 |
SQL_SSRP_StackBo |
139.92.229.160 |
213.253.214.36 |
UDP |
1082 |
1434 |
| 4/8/2003 |
23:14:55 |
SQL_SSRP_StackBo |
139.92.229.160 |
213.253.214.37 |
UDP |
1083 |
1434 |
| 4/9/2003 |
23:14:55 |
SQL_SSRP_StackBo |
139.92.229.160 |
213.253.214.38 |
UDP |
1084 |
1434 |
| 4/9/2003 |
23:14:55 |
SQL_SSRP_StackBo |
139.92.229.160 |
213.253.214.39 |
UDP |
1085 |
1434 |
| 4/9/2003 |
23:14:56 |
SQL_SSRP_StackBo |
139.92.229.160 |
213.253.214.40 |
UDP |
1086 |
1434 |
| 4/9/2003 |
23:14:56 |
SQL_SSRP_StackBo |
139.92.229.160 |
213.253.214.41 |
UDP |
1087 |
1434 |
| 4/9/2003 |
23:14:56 |
SQL_SSRP_StackBo |
139.92.229.160 |
213.253.214.42 |
UDP |
1088 |
1434 |
| 4/9/2003 |
23:14:56 |
SQL_SSRP_StackBo |
139.92.229.160 |
213.253.214.43 |
UDP |
1089 |
1434 |
| : |
: |
: |
: |
: |
: |
: |
: |
Многие специалисты утверждают, что системы обнаружения атак уже не справляются с такими проблемами, а журналисты даже стали использовать в своих статьях громкие заголовки "системы обнаружения атак мертвы". Однако, как было замечено одним из экспертов в области обнаружения атак: "это не проблема систем обнаружения атак, это проблема управления данными и их представления".
Корреляция
Получив сообщение о том, что, например, ваша сеть атакована червем Slammer многие администраторы приходят в ужас и лихорадочно начинают вспоминать, а пропатчили ли они свои узлы. А что если, даже самая серьезная атака (например, Slammer) не нанесет вам никакого вреда по той простой причине, что у вас нет серверов на базе MS SQL? А если они у вас есть, но вы их давно защитили? Аналогичная ситуация происходит и с другими атаками, которые отвлекают внимание администратора и требуют вмешательства. А что, если на них вообще не надо реагировать (как ни парадоксально это звучит)? Ведь не каждый хакер знает всю подноготную вашей сети, и, зачастую, он наугад пытается атаковать ваши ресурсы, что приводит к тому, что атака не только не нанесет вам никакого ущерба, но и в принципе не может быть применима к вашей сети. Например, относительно недавно выпущенный SMBdie страшен только Windows-узлам, да и то, только тем, на которых не был установлен соответствующий Service Pack. Unix-машины к нему неуязвимы. Так зачем же реагировать на появление сообщения об атаке SMBdie? Хорошо, если ваша сеть небольшого размера и вы помните, что и где у вас установлено. А если нет? Куда лучше, если сообщения, не несущие никакой угрозы, вообще бы не показывались у вас на консоли и не отвлекали бы вас от более важных дел. Механизм корреляции, т.е. поиск взаимосвязей между разнородными данными, как раз и решает эту проблему, снимая с администраторских плеч нагрузку проведения ручного анализа и сопоставления разрозненных данных.
Модуль корреляции в SIMS не только автоматизирует процесс сопоставления разнородных данных, но и сам проводит анализ воздействия атаки на ваши ресурсы. Это может происходить по-разному:
Локальная корреляция, осуществляемая непосредственно на защищаемом узле. В этом процессе участвует система обнаружения и предотвращения атак уровня узла (host-based ID&PS), которая либо отражает атаку, о чем оповещает администратора безопасности, либо нет. В последнем случае требуется вмешательство специалистов, которые инициируют процесс расследования инцидентов.
В данном случае, система обнаружения и предотвращения атак должна не только зафиксировать атаку, но и оценить ее воздействие на атакуемый узел. Корреляция со сведениями об операционной системе. Если Windows-атака направлена на Unix-узел, то ее можно игнорировать и не забивать себе голову проблемой реагирования на такие нарушения. Если же атака "применима" к данной ОС, то в действие вступает следующий вариант корреляции. Корреляция атак и уязвимостей. Следуя определению атаки, она не может быть успешна, если атакуемый узел или сегмент сети не содержит уязвимости. Таким образом, сопоставляя данные об атаке с информацией об уязвимостях атакуемого узла или сегмента, можно с уверенностью будет сказать, применима ли зафиксированная атака к вашей сети и, если да, то нанесет ли она вам какой-либо ущерб.
Результатом работы механизма корреляции может служить одно из следующих сообщений в строке статуса атаки (с разъяснением причины такого вывода):
Вероятно удачная атака (узел уязвим) Вероятно неудачная атака (узел не уязвим) Вероятно неудачная атака (блокированы некоторые пакеты, составляющие атаку) Вероятно неудачная атака (атака не применима к данной операционной системе) Неудачная атака (узел блокировал атаку) Воздействие неизвестно (узел не сканировался) Воздействие неизвестно (операционная система не определена) Воздействие неизвестно (уязвимость не определена) Воздействие неизвестно (корреляция не проводилась)
Таблица 4. Результат работы механизма корреляции на примере системы RealSecure SiteProtector с установленным модулем SecurityFusion Module
| Степень риска |
Событие |
Число событий |
Статус |
| Низкая |
NMap-Scan |
139 |
Воздействие неизвестно (корреляция не проводилась) |
| Средняя |
SMTP-Sendmail-Relay |
1 |
Вероятно неудачная атака (узел неуязвим) |
| Высокая |
Backdoor-BO2k |
1 |
Неудачная атака (узел блокировал атаку) |
Существуют и другие механизмы корреляции, облегчающие работу администратора. Например, анализ шаблона атаки, позволяющий сделать вывод о применении того или иного средства реализации атаки.
Такая информация позволяет оценить квалификацию хакера и в зависимости от этого предпринимать те или иные действия. Также может быть задействована функция сопоставления данных за заданный интервал времени, что позволяет несколько однотипных или разных событий объединить единым сообщением об атаке. Например, несколько неудачных попыток входа в систему с одного из узлов сети за короткий интервал времени могут говорить о попытке подбора пароля. Или еще один распространенный пример. Сразу после обнаружения факта сканирования Web-сервера, что само по себе является частым событием в Интернет, фиксируется попытка использования уязвимости Unicode в сервере MS Internet Information Server. По отдельности эти события могут говорить, как о реальной атаке, так и ложном срабатывании. Совокупность же этих действий, разделенных очень коротким интервалом времени, с очень высокой вероятностью говорит именно о реальной атаке, направленной на взлом сайта.
Приведу более сложный пример. Один из узлов вашей сети был успешно атакован, после чего он сам стал базой для дальнейшего распространения атаки. Система корреляции, сопоставив различные данные, может обнаружить такой факт и уведомить об этом администратора, который должен в срочном порядке отреагировать на возникшую ситуацию. Вот как может выглядеть такой факт в журнале регистрации системы обнаружения атак (см. выделение цветом в Таблице 1), а вот так он будет подан системой корреляции (см. первую строчку в Таблице 5).
Таблица 5. Результат работы механизма корреляции на примере системы RealSecure SiteProtector с установленным модулем SecurityFusion Module
| Степень риска |
Событие |
Число событий |
Источник |
| Высокая |
Attack_From__Compromised_Host |
1567 |
139.92.229.160 |
| Высокая |
Targeted_Break_In_Attempt |
1 |
194.98.93.252 |
| : |
: |
: |
: |
Кстати, здесь есть очень тонкий момент, на который необходимо обращать внимание при выборе системы управления информационной безопасности. Многие из них в своих рекламных материалах упоминают про поддержку огромного количества разнородных средств защиты (до нескольких десятков) и перечисляют известнейшие имена.
Но: на самом деле под поддержкой понимается только сбор данных от этих средств, не более того. Производитель SIMS должен обновлять свое решение также часто, как и все из поддерживаемых ими систем. Более того, с выходом обновления для системы обнаружения атак или сканера система корреляции также должна пополнить свою базу знаниями о новых уязвимостях и атаках. В противном случае она не сможет анализировать неизвестные ей события. Об этом умалчивают многие производители таких средств, считая, что достаточно указать в рекламных материалах факт поддержки разнообразных средств анализа защищенности, межсетевых экранов, систем обнаружения атак, proxy-серверов и т.д. Поэтому максимум, на что вы можете надеяться, устанавливая такой продукт, - это на сбор данных из разных источников без функции агрегирования и корреляции. Честнее поступают такие производители как Internet Security Systems, Cisco и т.п. Они не обещают золотых гор, но зато гарантируют полную поддержку всех своих решений и, возможно, парочки решений от других производителей.
Об авторе
Алексей Викторович Лукацкий, руководитель отдела Internet-решений Научно-инженерного предприятия "Информзащита" (Москва). Автор книг "Обнаружение атак", "Атака из Internet" и "Protect Your Information with Intrusion Detection". Связаться с ним можно по тел. (095) 937-3385 или e-mail: .
Огласите весь список, пжалуйста!
Число систем корреляции постоянно растет и к ним, например, можно отнести:
. . . . . . .
Несмотря на рост интереса к этим системам на Западе, в России о таких решениях говорят пока мало и это закономерно. У нас далеко не все используют системы обнаружения атак и межсетевые экраны, не говоря уже о средствах, стоящих существенно выше на эволюционной шкале защитных механизмов. Однако, несмотря на это, в России уже можно найти системы управления информационной безопасностью таких известных в мире безопасности компаний, как Internet Security Systems, Cisco Systems и Symantec.
Первая из них предлагает бесплатную систему , которая обладает описанными выше механизмами консолидации, агрегирования и корреляции событий, получаемых не только от всех своих решений в области обнаружения атак и анализа защищенности, но и от межсетевых экранов Check Point Firewall-1 и Cisco PIX Firewall. Также эта система поддерживает и другие средства защиты.
Компания Cisco предлагает систему , которое построено на базе широко известной на Западе системы управления информационной безопасности одноименной компании.
Компания Symantec предлагает систему и семейство , вошедшее в пакет предложений Symantec после покупки последней компании SecurityFocus.
Приоритезация
Одна и та же атака может иметь различные последствия для разных узлов корпоративной сети. Например, узел, работающий под управлением ОС Solaris 2.5.1, уязвим для атаки Ping of Death, а узел, работающий под ОС Windows NT, не подвержен данной атаке. Можно привести и другой пример - наличие модема. Если модем подключен к компьютеру с выполнением всех требований по обеспечению информационной безопасности, то это нормальная ситуация, не требующая пристального внимания администратора безопасности. Напротив, модем, подключенный в обход межсетевого экрана, должен быть немедленно удален. Или сервис Telnet. На маршрутизаторе он нужен, а на большинстве рабочих станций - нет. Именно поэтому система централизованного мониторинга атак должна предусматривать возможность задания приоритетов для обнаруживаемых атак или уязвимостей. При этом задание приоритетов может быть как статическим (что было продемонстрировано выше на трех примерах), так и динамическим.
Зачем нужно динамическое задание приоритетов, и почему недостаточно статического метода? Допустим, на компьютере существует учетная запись Guest, с помощью которой любой злоумышленник сможет делать на компьютере все, что ему заблагорассудится. В обычных условиях эта уязвимость имеет высокий приоритет. Однако на практике, в зависимости от того, разрешена (enable) ли эта учетная запись или запрещена (disable), данная уязвимость может иметь самый высокий или самый низкий приоритет, соответственно. В такой ситуации приоритет может быть назначен только после корреляции событий, т.е. он должен задаваться динамически (сравните Таблицы 4 и 6).
Таблица 6. Результат работы механизма динамической приоритезации на примере системы RealSecure SiteProtector с установленным модулем SecurityFusion Module
| Степень риска |
Событие |
Число событий |
Источник |
| Высокая |
UDP-Scan |
11385 |
194.98.93.252 |
| Низкая |
Backdoor-BO2k |
1 |
194.98.93.252 |
| Низкая |
SQL_SSRP_StackBo |
1567 |
139.92.229.160 |
| : |
: |
: |
: |
Системы управления информационной безопасностью
Для того чтобы избежать описанных проблем, необходима эффективная система управления информационной безопасности (Security Information Management System, SIMS), которая позволяет все используемые защитные средства объединить в единый управляемый комплекс. Такая система:
унифицирует управление разнородными средствами в единых терминах политики безопасности уменьшает временные и финансовые затраты на изучение разных консолей управления позволяет эффективно обновлять все управляемые средства защиты группирует все защищаемые ресурсы по различным признакам с целью фокусировки внимания на необходимых в данный моментах узлах фильтровать события с целью устранения "шумовых" данных и снижения нагрузки на администратора безопасности позволяет коррелировать данных от разнородных средств защиты с целью снижения числа ложных срабатываний и оповещения о реально происходящих нарушениях политики безопасности.
Использование таких систем позволяет ответить на множество вопросов, постоянно возникающих в процессе обеспечения информационной безопасности, например:
Уязвим ли атакуемый узел к зафиксированной атаке? Нанесла ли атака ущерб ресурсам моей сети? Заблокировал ли установленный на атакуемом узле агент системы защиты зафиксированную атаку? Какая система атакуется в данный момент? Какие узлы моей сети являются источниками атак?
Эффективная система управления информационной безопасностью должна, помимо всего прочего, поддерживать 4 основных механизма управления событиями:
Консолидация (event consolidation). Агрегирование (event aggregation). Корреляция (event correlation). Приоритезация (event prioritization).
в области информационной безопасности определяется
Уровень зрелости компании в области информационной безопасности определяется не количеством установленных в сети межсетевых экранов и систем обнаружения атак, а умением управлять ими. Одним из таких средств являются системы управления информационной безопасностью, которые получают все большее распространение в мире. По оценкам компании IDC к 2005 году объем рынка таких систем составит 1759 миллионов долларов (в т.ч. объем рынка систем корреляции - 405 миллионов долларов). Однако, несмотря на желание применять такие системы в своей повседневной деятельности (такое желание высказывают 89% респондентов), только 5% компаний задействуют всю мощь этих решений (в России число таких компаний измеряется сотыми долями процента). Остается надеяться, что в условиях растущей угрозы кибертерроризма отношение к таким системам изменится.
Безопасность СУБД
Михаил Савельев
, #09/2005
Обеспечение безопасности корпоративных баз данных - сегодня одна из самых актуальных тем. И это понятно. Однако парадокс заключается в том, что уделяя огромное внимание защите баз данных снаружи, многие забывают защищать их изнутри.
Летом нынешнего года результаты своих исследований в этом вопросе опубликовала компания IBM. Показательно, что согласно собранным данным, защите периметра сети уделяется втрое больше внимания, чем защите от внутренних возможных нарушений.
Кроме того, если вернуться к случаям взлома БД и провести простой расчет, то он покажет несостоятельность попыток свалить всю вину за происшедшее на хакеров. Разделив объем украденных данных на типовую скорость канала доступа в Интернет, мы получим, что даже при максимальной загруженности канала на передачу данных должно было бы уйти до нескольких месяцев. Логично предположить, что такой канал утечки данных был бы обнаружен даже самой невнимательной службой безопасности.
И если перед нами стоит задача обеспечить безопасность корпоративной СУБД, давайте озадачимся простым вопросом: кто в компании вообще пользуется базой данных и имеет к ней доступ?
Существует три большие группы пользователей СУБД, которых условно можно назвать операторами; аналитиками; администраторами.
Под операторами в предложенной классификации мы понимаем в основном тех, кто либо заполняет базу данных (вводят туда вручную информацию о клиентах, товарах и т. п.), либо выполняют задачи, связанные с обработкой информации: кладовщики, отмечающие перемещение товара, продавцы, выписывающие счета и т. п.
Под аналитиками мы понимаем тех, ради кого, собственно, создается эта база данных: логистики, маркетологи, финансовые аналитики и прочие. Эти люди по роду своей работы получают обширнейшие отчеты по собранной информации.
Термин "администратор" говорит сам за себя. Эта категория людей может только в общих чертах представлять, что хранится и обрабатывается в хранилище данных. Но они решают ряд важнейших задач, связанных с жизнеобеспечением системы, ее отказо- и катастрофоустойчивости.
Но различные роли по отношению к обрабатываемой информации - не единственный критерий. Указанные группы различаются еще и по способу взаимодействия с СУБД.
Операторы чаще всего работают с информацией через различные приложения. Безопасность и разграничение доступа к информации тут реализованы очень хорошо, проработаны и реализованы методы защиты. Производители СУБД, говоря о возможностях своих систем, акцентируют внимание именно на такие способы защиты. Доступ к терминалам/компьютерам, с которых ведется работа, разграничение полномочий внутри приложения, разграничение полномочий в самой СУБД - все это выполнено на высоком техническом уровне. Честно внедрив все эти механизмы защиты, специалисты по безопасности чувствуют успокоение и удовлетворение.
Но беда в том, что основные проблемы с безопасностью приходятся на две оставшиеся категории пользователей.
Проблема с аналитиками заключается в том, что они работают с СУБД на уровне ядра. Они должны иметь возможность задавать и получать всевозможные выборки информации из всех хранящихся там таблиц. Включая и запросы общего типа "select * *".
С администраторами дело обстоит ненамного лучше. Начиная с того, что в крупных информационных системах их число сопоставимо с числом аналитиков. И хотя абсолютно полными правами на СУБД наделены лишь два-три человека, администраторы, решающие узкие проблемы (например резервное копирование данных), все равно имеют доступ ко всей информации, хранящейся в СУБД.
Между аналитиками и администраторами на первый взгляд нет никакой разницы: и те и другие имеют доступ ко всей обрабатываемой информации. Но все же отличие между этими группами есть, и состоит оно в том, что аналитики работают с данными, используя некие стандартные механизмы и интерфейсы СУБД, а администраторы могут получить непосредственный доступ к информации, например на физическом уровне, выполнив лишний раз ту же операцию по резервному копированию данных.
Какие еще защитные механизмы можно задействовать, чтобы решить проблему безопасности данных?
Попытаемся "плясать от печки". В принципе, в любой СУБД есть встроенные возможности по разграничению и ограничению доступа на уровне привилегий пользователей. Но возможность эта существует только чисто теоретически. Кто хоть раз имел дело с администрированием большой СУБД в большой организации, хорошо знает, что на уровне групп пользователей что-либо разграничить слишком сложно, ибо даже, помимо многообразия организационных ролей и профилей доступа, в дело вмешиваются проблемы обеспечения индивидуального доступа, который вписать в рамки ролей практически невозможно.
Но и это еще не все. Очень часто обработка данных ведется не самим пользователем, а созданным и запущенным в СУБД скриптом. Так, например, поступают для формирования типовых или периодических отчетов. В этом случае скрипт запускается не от имени пользователя, а от имени системной учетной записи, что серьезно затрудняет понимание того, что же на самом деле происходит в базе данных. Притом сам скрипт может содержать практически любые команды, включая пресловутое "select * *". В ходе работы скрипт может сформировать новый массив данных, в том числе и дублирующий все основные таблицы. В итоге пользователь получит возможность работать с этим набором данных и таким образом обходить установленные нами средства аудита.
Попытка использовать для разграничения доступа криптографию также обречена на провал: это долго, ресурсоемко и опасно с точки зрения повреждения данных и их последующего восстановления. К тому же возникают проблемы с обработкой информации, ибо индексироваться по зашифрованным полям бесполезно. А самое главное, что некоторым администраторам все равно придется дать "ключи от всех замков".
В результате, если перед компанией стоит задача по сохранению своих корпоративных СУБД, то ее нельзя разрешить простым ограничением и разграничением доступа к информации. Как мы разобрались, где это хоть как-то возможно, это уже сделано. Во всех остальных случаях можно лишь по факту понимать, что происходило с данными.
Задачу необходимо формулировать так: мы должны знать, кто, когда получает доступ к данным и к каким.
Попытка решить поставленную задачу средствами СУБД столкнется с вычислительными ресурсами серверов, поскольку помимо обработки данных им придется вести полное протоколирование своих действий. Но самое неприятное будет заключаться в том, что если за кражу информации возьмется один из администраторов, то его полномочий, скорее всего, хватит и на затирание следов своей деятельности в журналах регистрации.
Именно поэтому необходимо использовать внешние средства аудита.
Производители средств защиты готовы нам помочь средствами, которые способны контролировать и все входящие запросы и выборки данных на запуск скриптов для обработки информации, и обращения к отдельным таблицам. Подобные средства представляют собой некоторый сервис, работающий на сервере с установленной СУБД и контролирующий все обращения к базе.
Однако крупные хранилища данных работают под управлением специализированных ОС. Цены на решения для таких СУБД "кусаются". Ко всему прочему, администраторы начинают сильно переживать, что лишний установленный сервис если и не затормозит работу, то по крайней мере станет дополнительным "очагом нестабильности" системы в целом.
Когда нет возможности сломать этот стереотип, на помощь могут прийти средства сетевого контроля. По сути они представляют собой специализированные снифферы, которые контролируют и детально разбирают протоколы взаимодействия с базами данных. Ставятся либо непосредственно перед сервером баз данных, либо на входе в сегмент сети, где располагаются сразу несколько серверов с СУБД. При этом из сетевого может быть извлечена как информация о сделанных запросах, так и непосредственно та информация, которая была направлена пользователю. Естественно, если доступ к СУБД необходимо защищать криптографическими методами, подобное средство необходимо расположить между СУБД и окончанием VPN-тоннеля.
Таким образом мы сможем контролировать аналитиков, но не администраторов, и в этом заключается наибольшая трудность при использовании описываемых средств.
Ведь администраторы имеют доступ к серверам баз данных не только через стандартные интерфейсы, но и, например, через средства удаленного администрирования. Тут способны помочь лишь жесткие административные ограничения: все манипуляции с сервером и СУБД - только локально. При проведении такой жесткой политики администраторы скорее всего будут сопротивляться и кивать на оперативность разрешения проблем, но чаще всего эти доводы бывают слишком притянуты за уши. Если проблема небольшая, то 3 минуты, затрачиваемые на проход по коридору, ничего не решат. Если же проблема действительно большая, то им так или иначе придется работать непосредственно с севером в течение достаточно продолжительного времени. Тут очевидно противостояние: что важнее, удобство работы администратора (при всем уважении к людям, делающим эту нелегкую работу) или безопасность данных, а то и репутация компании? Полагаю, при такой постановке вопроса пробежка по коридору не должна восприниматься как весомый аргумент.
Защититься от физического доступа к базам данных также возможно только путем введения жестких регламентов съема и хранения информации и слежения за отступлениями от этих регламентов. К примеру, изготовление лишней резервной копии. Если процессы происходят по сети, с несанкционированными всплесками сетевого трафика по силам справиться средствам обнаружения и предотвращения атак. Стоит ли говорить, что отдельно надо побеспокоиться о безопасном хранении самих резервных копий. В идеале физический доступ к ним должен быть строго ограничен, а администратор, отвечающий за процесс, должен либо настроить расписание, либо иметь возможность только запустить этот процесс и контролировать его прохождение без доступа к резервным носителям информации.
Подводя итог, скажем: безопасность - процесс комплексный. И еще раз хочется предостеречь пользователей от стереотипа, что опасность корпоративным ресурсам, в том числе и базам данных, угрожает только из внешнего окружения компании или организации.
Информационная безопасность
Блочные шифры
Блочные шифры считаются более надежными, нежели поточные, поскольку каждый блок текста подвергается сложным преобразованиям. Тем не менее, одних только этих преобразований оказывается недостаточно для обеспечения должного уровня безопасности - важно, каким образом они применяются к исходному тексту в процессе шифрования.

Наиболее простой и интуитивно понятный способ состоит в том, чтобы разбить исходный текст на блоки соответствующего размера, а затем отдельно каждый блок подвергнуть шифрующему преобразованию. Такой режим использования блочных шифров называют электронной кодовой книгой (ECB - electronic codebook). Его главный недостаток состоит в том, что одинаковые блоки исходного текста при шифровании дадут одинаковые же блоки шифр-текста - а это может существенно облегчить противнику задачу взлома. Поэтому режим ECB не рекомендуется использовать при шифровании текстов, по длине превышающих один блок - в таких случаях лучше воспользоваться одним из режимов, связывающих различные блоки между собой. По умолчанию в CryptoAPI блочные шифры используются в режиме сцепления блоков шифр-текста (CBC - cipher block chaining). В этом режиме при шифровании очередной блок исходного текста вначале комбинируется с предыдущим блоком шифр-текста (при помощи побитового исключающего ИЛИ), а затем полученная последовательность битов поступает на вход блочного шифра (рис. 14). Образующийся на выходе блок шифр-текста используется для шифрования следующего блока. Самый первый блок исходного текста также должен быть скомбинирован с некоторой последовательностью битов, но "предыдущего блока шифр-текста" еще нет; поэтому режимы шифрования с обратной связью требуют использования еще одного параметра - он называется инициализирующим вектором (IV - initialization vector).
Инициализирующий вектор должен генерироваться отдельно с помощью уже известной нам функции CryptGenRandom и, как и солт-значение, передаваться вместе с ключом в открытом виде. Размер IV равен длине блока шифра. Например, для алгоритма RC2, поддерживаемого базовым криптопровайдером Microsoft, размер блока составляет 64 бита (8 байтов).
Целостность и аутентичность информации

Как удостовериться в том, что пришедшее сообщение действительно отправлено тем, чье имя стоит в графе "отправитель"? Асимметричные схемы шифрования дают нам элегантный способ аутентификации. Если отправитель зашифрует сообщение своим закрытым ключом, то успешное расшифровывание убедит получателя в том, что послать корреспонденцию мог только хозяин ключевой пары, и никто иной (рис. 6). При этом расшифровку может выполнить любой, кто имеет открытый ключ отправителя. Ведь наша цель - не конфиденциальность, а аутентификация.
Чтобы избежать шифрования всего сообщения при помощи асимметричных алгоритмов, используют хеширование: вычисляется хеш-значение исходного сообщения, и только эта короткая последовательность байтов шифруется закрытым ключом отправителя. Результат представляет собой электронную цифровую подпись. Добавление такой подписи к сообщению позволяет установить:
аутентичность сообщения - создать подпись на основе закрытого ключа мог только его хозяин; целостность данных - легко вычислить хеш-значение полученного сообщения и сравнить его с тем, которое хранится в подписи: если значения совпадают, значит, сообщение не было изменено злоумышленником после того, как отправитель его подписал.
Таким образом, асимметричные алгоритмы позволяют решить две непростые задачи: обмена ключами шифрования по открытым каналам связи и подписи сообщения. Чтобы воспользоваться этими возможностями, нужно сгенерировать и сохранить две ключевые пары - для обмена ключами и для подписей. В этом нам поможет CryptoAPI.
Цифровые конверты
Асимметричные алгоритмы позволяют легко обменяться ключами шифрования по открытому каналу связи - но работают слишком медленно. Симметричные алгоритмы работают быстро - но для обмена ключами требуют наличия защищенного канала связи и, к тому же, нуждаются в частой смене ключей. Поэтому в современных криптосистемах используются сильные стороны обоих подходов. Так, для шифрования сообщения используется симметричный алгоритм со случайным ключом шифрования, действующим только в пределах одного сеанса,- сеансовым ключом. Чтобы впоследствии сообщение могло быть расшифровано, сеансовый ключ подвергается шифрованию асимметричным алгоритмом с использованием открытого ключа получателя сообщения. Зашифрованный таким образом сеансовый ключ сохраняется вместе с сообщением, образуя цифровой конверт. При необходимости цифровой конверт может содержать сеансовый ключ в нескольких экземплярах - зашифрованный открытыми ключами различных получателей (рис. 13).
Delphi и Windows API для защиты секретов (части 1,2,3)
Константин Виноградов, Лилия Виноградова,
Как реализовать методы криптографической защиты информации при помощи подручных средств – Windows и Delphi
Электронная цифровая подпись
Для создания электронной цифровой подписи необходимо вычислить хеш заданного файла и зашифровать этот "цифровой отпечаток сообщения" своим закрытым ключом - "подписать". Чтобы подпись впоследствии можно было проверить, необходимо указать, какой алгоритм хеширования использовался при ее создании. Поэтому подписанное сообщение должно иметь структуру, показанную на рис. 11.
Подписать вычисленный хеш в CryptoAPI позволяет функция CryptSignHash (хеш, описание ключа, комментарий, флаги, подпись, длина подписи). Вторым параметром может быть либо AT_KEYEXCHANGE, либо AT_SIGNATURE (в нашем случае логичнее использовать ключ подписи). Третий параметр в целях безопасности настоятельно рекомендуется оставлять пустым (nil). Флаги в настоящее время также не используются - на месте этого аргумента должен быть нуль. Готовую электронную подпись функция запишет в буфер, адрес которого содержится в предпоследнем параметре, последний же параметр будет содержать длину подписи в байтах.
На рис. 12 показана форма, позволяющая подписать заданный файл. , реализующую процесс подписания; результатом ее работы является файл, имеющий структуру, показанную на рис. 11.
Чтобы проверить правильность подписи, получатель подписанного сообщения должен иметь файл с открытым ключом подписи отправителя. В процессе проверки подписи этот ключ импортируется внутрь криптопровайдера. Проверка выполняется функцией CryptVerifySignature (хеш, подпись, длина подписи, открытый ключ, комментарий, флаги). О последних двух аргументах можно сказать то же, что и о параметрах комментарий и флаги функции CryptSignHash, назначение же остальных должно быть понятно. Если подпись верна, функция возвращает true. Значение false в качестве результата может свидетельствовать либо о возникновении ошибки в процессе проверки, либо о том, что подпись оказалась неверной. В последнем случае функция GetLastError вернет ошибку NTE_BAD_SIGNATURE. Для примера приведем наиболее значимые фрагменты программы проверки подписи:
Полный Delphi-проект примера можно найти .
Контейнеры ключей
Каждый криптопровайдер располагает базой данных, в которой хранятся долговременные ключи пользователей. База данных содержит один или более контейнеров ключей (рис.7). Пользователь может создать несколько контейнеров с различными именами (именем контейнера по умолчанию является имя пользователя в системе).
Подключение к контейнеру производится одновременно с получением контекста криптопровайдера при вызове функции CryptAcquireContext - имя контейнера ключей передается функции вторым ее аргументом. Если второй аргумент содержит пустой указатель (nil), то используется имя по умолчанию, т. е. имя пользователя. В том случае, если доступ к контейнеру не нужен, можно передать в последнем аргументе функции флаг CRYPT_VERIFYCONTEXT; при необходимости создать новый контейнер используется флаг CRYPT_NEWKEYSET; а для удаления существующего контейнера вместе с хранящимися в нем ключами - CRYPT_DELETEKEYSET.
Каждый контейнер может содержать, как минимум, две ключевые пары - ключ обмена ключами и ключ подписи. Ключи, используемые для шифрования симметричными алгоритмами, не сохраняются. Как мы уже говорили, такие ключи не рекомендуется применять более одного раза, поэтому их называют сеансовыми (англ. session key).
Криптографические возможности Windows
Сразу договоримся, что никакая система защиты информации не может быть абсолютно надежной. Речь может идти лишь о некоторой степени надежности и рисках, связанных со взломом защиты. Поэтому с практической точки зрения есть смысл оценить важность данных и экономно подстелить соломку на случай неудачи. В наших приложениях, например, мы выдаем кредит доверия операционной системе Windows, несмотря на закрытость ее кода.
Итак, ОС мы доверяем. Чтобы криптозащиту нельзя было «обойти» с другой стороны - к примеру, перехватить из незащищенной области памяти секретные пароли - криптографические функции должны быть частью операционной системы. В семействе Windows, начиная с Windows 95, обеспечивается реализация шифрования, генерации ключей, создания и проверки цифровых подписей и других криптографических задач. Эти функции необходимы для работы операционной системы, однако ими может воспользоваться и любая прикладная программа - для этого программисту достаточно обратиться к нужной подпрограмме так, как предписывает криптографический интерфейс прикладных программ (CryptoAPI).
Разумеется, по мере совершенствования Windows расширялся и состав ее криптографической подсистемы. Помимо базовых операций, в настоящее время в CryptoAPI 2.0 поддерживается работа с сертификатами, шифрованными сообщениями в формате PKCS #7 и пр.
Описание функций CryptoAPI, помимо специальных книг, можно найти в MSDN Library.
Обмен ключами
Теперь мы располагаем набором ключей, однако все они останутся мертвым грузом, до тех пор пока мы не получим возможности обмена с другими пользователями открытыми ключами. Для этого необходимо извлечь их из базы данных ключей и записать в файл, который можно будет передать своим корреспондентам. При экспорте данные ключа сохраняются в одном из трех возможных форматов:
PUBLICKEYBLOB - используется для сохранения открытых ключей. Поскольку открытые ключи не являются секретными, они сохраняются в незашифрованном виде; PRIVATEKEYBLOB - используется для сохранения ключевой пары целиком (открытого и закрытого ключей). Эти данные являются в высшей степени секретными, поэтому сохраняются в зашифрованном виде, причем для шифрования используется сеансовый ключ (и, соответственно, симметричный алгоритм); SIMPLEBLOB - используется для сохранения сеансовых ключей. Для обеспечения секретности данные ключа шифруются с использованием открытого ключа получателя сообщения.
Экспорт ключей в CryptoAPI выполняется функцией CryptExportKey (экспортируемый ключ, ключ адресата, формат, флаги, буфер, размер буфера):
экспортируемый ключ - дескриптор нужного ключа; ключ адресата - в случае сохранения открытого ключа должен быть равен нулю (данные не шифруются); формат - указывается один из возможных форматов экспорта (PUBLICKEYBLOB, PRIVATEKEYBLOB, SIMPLEBLOB); флаги - зарезервирован на будущее (должен быть равен нулю); буфер - содержит адрес буфера, в который будет записан ключевой BLOB (Binary Large OBject - большой двоичный объект); размер буфера - при вызове функции в этой переменной должен находиться доступный размер буфера, а по окончании работы в нее записывается количество экспортируемых данных. Если размер буфера заранее не известен, то функцию нужно вызвать с параметром буфер, равным пустому указателю, тогда размер буфера будет вычислен и занесен в переменную размер буфера.
Экспорт ключевой пары целиком, включая и закрытый ключ, может понадобиться для того, чтобы иметь возможность подписывать документы на различных компьютерах (например, дома и на работе), или для сохранения страховочной копии.
В этом случае нужно создать ключ шифрования на основании пароля и передать дескриптор этого ключа в качестве второго параметра функции CryptExportKey.
Запросить у криптопровайдера дескриптор самого' экспортируемого ключа позволяет функция CryptGetUserKey (провайдер, описание ключа, дескриптор ключа). Описание ключа - это либо AT_KEYEXCHANGE, либо AT_SIGNATURE.
Экспорт асимметричных ключей во всем возможном многообразии можно осуществить при помощи формы, показанной на рис.9.
В приведены наиболее важные фрагменты программы
Экспортированные таким образом открытые части ключей понадобятся нам для проверки подписи и расшифровки сеансового ключа.
Импорт ключевых пар во вновь созданный контейнер - это самостоятельная процедура. Необходимо запросить у пользователя название контейнера и пароль, подключиться к провайдеру, создать на основании пароля ключ, считать из файла импортируемые данные в буфер, после чего воспользоваться функцией CryptImportKey (провайдер, буфер, длина буфера, ключ для расшифровки, флаги, импортируемый ключ). Если нужно обеспечить возможность экспорта импортируемой ключевой пары впоследствии, то в параметре флаги необходимо передать значение CRYPT_EXPORTABLE; в противном случае вызов для данной ключевой пары функции CryptExportKey приведет к ошибке.
Мы уже обсуждали, что при работе с асимметричными алгоритмами важно убедиться, что открытый ключ действительно принадлежит тому, кого вы считаете его хозяином, и не был подменен злоумышленником. Простейшим способом обеспечить аутентичность ключа является побайтная сверка с оригиналом, хранящимся у его хозяина. Для этого можно просто позволить пользователю просмотреть экспортированные данные в шестнадцатеричном виде - например, открыть файл, в который был записан открытый ключ, и вывести его содержимое в окно просмотра. Примерный результат показан на рис. 10.
От слов - к делу
Настало время применить все сказанное на практике, создав приложение, предназначенное для шифрования и расшифровки файлов с использованием случайных сеансовых ключей. Окно приложения показано на рис. 15. Для успешной работы программы нужно создать на компьютере собственный ключевой контейнер, экспортировать из него открытый ключ обмена ключами и обменяться открытыми ключами с адресатом. Все эти операции подробно обсуждались ранее. В простейшем случае "отправитель" сообщения может являться и "получателем" - тогда нужно просто экспортировать свой открытый ключ обмена ключами и сохранить его в каком-нибудь файле на диске.
Шифруемый файл помещается в цифровой конверт. Как мы знаем, вместе с ключом необходимо сохранить солт-значение, а при использовании блочного шифра - еще и инициализирующий вектор. В соответствии с этим наш цифровой конверт будет иметь структуру, показанную на рис. 16.
Приведем основные фрагменты процедуры, осуществляющей шифрование и расшифровку файла (обработка ошибок опущена):
В рассмотренной нами процедуре обмена шифрованными сообщениями остается одно слабое звено - обмен открытыми ключами. Ведь при этом мы не обеспечиваем подлинность полученного ключа - во время пересылки его может подменить злоумышленник. CryptoAPI для решения этой проблемы предполагает использование сертификатов. Но об этом - в следующий раз.
Полный Delphi-проект можно взять .
Продолжение статьи, посвященное сертификатам (часть 4) -
Авторы ищут издателя для публикации учебного пособия по данной теме. Персональный сайт авторов - http://www.is.svitonline.com/vilys/.
Проблема распределения ключей
В прошлый раз при помощи CryptoAPI мы решали такую "классическую" задачу как шифрование на основе пароля. Напомним, что пароль использовался для создания ключа шифрования какого-либо симметричного алгоритма. В таком случае расшифровать файл может лишь тот, кто знает пароль. А значит, для обеспечения конфиденциальности нужно держать пароль в строжайшем секрете - желательно, чтобы его знали лишь отправитель и получатель информации. (А еще лучше, если отправитель и получатель - одно и то же лицо.)
Предположим, что отправитель и получатель при личной встрече договорились использовать для конфиденциальной переписки определенный пароль. Но если они будут шифровать все свои сообщения одним и тем же ключом, то возможный противник, перехватив корреспонденцию, будеть иметь хорошие шансы взломать шифр: при современных методах криптоанализа наличие нескольких шифртекстов, полученных путем использования одного и того же ключа, почти гарантирует успешный результат. Поэтому при использовании симметричных алгоритмов шифрования настоятельно рекомендуется не применять один и тот же ключ дважды!
Однако помнить отдельный пароль для каждого зашифрованного сообщения - задача достаточно трудоемкая. А для корреспондентов, не имеющих возможности встретиться лично для согласования ключей шифрования, конфиденциальный обмен сообщениями вообще становится недоступным. Такая практическая трудность называется проблемой распределения ключей.
Спасительный способ, позволяющий шифровать сообщения, обмениваясь ключами по открытым каналам связи, был придуман в середине 70-х годов прошлого столетия, а в начале восьмидесятых появился первый реализующий его алгоритм - RSA. Теперь пользователь может сгенерировать два связанных между собой ключа - ключевую пару. Один из этих ключей по несекретным каналам рассылается всем, с кем пользователь хотел бы обмениваться конфиденциальными сообщениями (рис. 4).
Этот ключ называют открытым (англ. public key). Зная открытый ключ пользователя, можно зашифровать адресованное ему сообщение, но вот расшифровать его позволяет лишь вторая часть ключевой пары - закрытый ключ (private key). При этом открытый ключ не дает "практической" возможности вычислить закрытый: такая задача, хоть и разрешима в принципе, но при достаточно большом размере ключа требует многих лет машинного времени. Для сохранения конфиденциальности получателю необходимо лишь хранить в строгом секрете свой закрытый ключ, а отправителю - убедиться, что имеющийся у него открытый ключ действительно принадлежит адресату.

Так как для шифрования и расшифровки используются различные ключи, алгоритмы такого рода назвали асимметричными. Наиболее существенным их недостатком является низкая производительность - они примерно в 100 раз медленнее симметричных алгоритмов. Поэтому были созданы криптографические схемы, использующие преимущества как симметричных, так и асимметричных алгоритмов (рис. 5):
для шифрования файла или сообщения используется быстрый симметричный алгоритм, причем ключ шифрования генерируется случайным образом с обеспечением "хороших" статистических свойств; небольшой по размерам симметричный ключ шифрования шифруется при помощи асимметричного алгоритма с использованием открытого ключа адресата и в зашифрованном виде пересылается вместе с сообщением; получив сообщение, адресат своим закрытым ключом расшифровывает симметричный ключ, а с его помощью - и само сообщение.
Описанная схема реализована и в CryptoAPI.
Шифрование с использованием паролей
После того как мы узнали кое-что о структуре CryptoAPI, можно воспользоваться ею в практических целях. Пожалуй, самым ожидаемым действием криптографической подсистемы является шифрование файлов - так, чтобы лишь пользователь, знающий определенный пароль, мог получить к ним доступ.
Для шифрования данных в CryptoAPI применяются симметричные алгоритмы. Симметричность означает, что для шифрования и расшифровки данных используется один и тот же ключ, известный как шифрующей, так и расшифровывающей стороне. При этом плохо выбранный ключ шифрования может дать противнику возможность взломать шифр. Поэтому одной из функций криптографической подсистемы должна быть генерация «хороших» ключей либо случайным образом, либо на основании некоторой информации, предоставляемой пользователем, например пароля.
В случае создания ключа на основании пароля должно выполняться следующее обязательное условие: при многократном повторении процедуры генерации ключа на одном и том же пароле должны получаться идентичные ключи. Ключ шифрования имеет, как правило, строго определенную длину, определяемую используемым алгоритмом, а длина пароля может быть произвольной. Даже интуитивно понятно, что для однозначной генерации ключей нужно привести разнообразные пароли к некоторой единой форме. Это достигается с помощью хеширования.
Хешированием (от англ. hash - разрезать, крошить, перемешивать) называется преобразование строки произвольной длины в битовую последовательность фиксированной длины (хеш-значение, или просто хеш) с обеспечением следующих условий:
по хеш-значению невозможно восстановить исходное сообщение; практически невозможно найти еще один текст, дающий такой же хеш, как и наперед заданное сообщение; практически невозможно найти два различных текста, дающих одинаковые хеш-значения (такие ситуации называют коллизиями).
При соблюдении приведенных условий хеш-значение служит компактным цифровым отпечатком (дайджестом) сообщения. Существует множество алгоритмов хеширования. CryptoAPI поддерживает, например, алгоритмы MD5 (MD - Message Digest) и SHA (Secure Hash Algorithm).
Итак, чтобы создать ключ шифрования на основании пароля, нам нужно вначале получить хеш этого пароля. Для этого следует создать с помощью CryptoAPI хеш-объект, воспользовавшись функцией CryptCreateHash (провайдер, ID_алгоритма, ключ, флаги, хеш), которой нужно передать дескриптор криптопровайдера (полученный с помощью CryptAcquireContext) и идентификатор алгоритма хеширования (остальные параметры могут быть нулями). В результате мы получим дескриптор хеш-объекта. Этот объект можно представить себе как черный ящик, который принимает любые данные и «перемалывает» их, сохраняя внутри себя лишь хеш-значение. Подать данные на вход хеш-объекта позволяет функция CryptHashData (дескриптор, данные, размер_данных, флаги).
Непосредственно создание ключа выполняет функция CryptDeriveKey (провайдер, ID_алгоритма, хеш-объект, флаги, ключ), которая принимает хеш-объект в качестве исходных данных и строит подходящий ключ для алгоритма шифрования, заданного своим ID. Результатом будет дескриптор ключа, который можно использовать для шифрования (рис. 3).
Следует обратить внимание, что при работе с CryptoAPI мы все время имеем дело не с самими объектами или их адресами, а с дескрипторами - целыми числами, характеризующими положение объекта во внутренних таблицах криптопровайдера. Сами таблицы располагаются в защищенной области памяти, так что программы-«шпионы» не могут получить к ним доступ.
Алгоритмы шифрования, поддерживаемые CryptoAPI, можно разделить на блочные и поточные: первые обрабатывают данные относительно большими по размеру блоками (например, 64, 128 битов или более), а вторые - побитно (теоретически, на практике же - побайтно). Если размер данных, подлежащих шифрованию, не кратен размеру блока, то последний, неполный блок данных, будет дополнен необходимым количеством случайных битов, в результате чего размер зашифрованной информации может несколько увеличиться. Разумеется, при использовании поточных шифров размер данных при шифровании остается неизменным.
Шифрование выполняется функцией CryptEncrypt (ключ, хеш, финал, флаги, данные, рамер_данных, размер_буфера):
через параметр ключ передается дескриптор ключа шифрования; параметр хеш используется, если одновременно с шифрованием нужно вычислить хеш-значение шифруемого текста; параметр финал равен true, если шифруемый блок текста - последний или единственный (шифрование можно осуществлять частями, вызывая функцию CryptEncrypt несколько раз); значение флага должно быть нулевым; параметр данные представляет собой адрес буфера, в котором при вызове функции находится исходный текст, а по завершению работы функции - зашифрованный; следующий параметр, соответственно, описывает размер входных/выходных данных, последний параметр задает размер буфера - если в результате шифрования зашифрованный текст не уместится в буфере, возникнет ошибка.
Для расшифровки данных используется функция CryptDecrypt (ключ, хеш, финал, флаги, данные, рамер_данных), отличающаяся от шифрующей функции только тем, что размер буфера указывать не следует: поскольку размер данных при расшифровке может только уменьшиться, отведенного под них буфера наверняка будет достаточно.
Приведем лишь , реализующей шифрование файла с использованием заданного пароля, опустив громоздкие проверки успешности выполнения криптографических операций (что в реальной программе делать крайне нежелательно).
Полный пример приложения в формате Delphi 4 можно взять .
Конечно, шифрование вами всех файлов одним и тем же паролем облегчает «противнику» задачу их расшифровки, запоминание огромного числа паролей сильно усложняет жизнь, а их записывание в незашифрованном виде создает опасность раскрытия всей системы. CryptoAPI может предложить на этот случай ряд решений. О них поговорим ниже.
Создание ключевых пар
После создания контейнера ключей необходимо сгенерировать ключевые пары обмена ключами и подписи. Эту работу в CryptoAPI выполняет функция CryptGenKey (провайдер, алгоритм, флаги, ключ):
провайдер - дескриптор криптопровайдера, полученный в результате обращения к функции CryptAcquireContext; алгоритм - указывает, какому алгоритму шифрования будет соответствовать создаваемый ключ. Информация об алгоритме, таким образом, является частью описания ключа. Каждый криптопровайдер использует для обмена ключами и подписи строго определенные алгоритмы. Так, провайдеры типа PROV_RSA_FULL, к которым относится и Microsoft Base Cryptographic Provider, реализуют алгоритм RSA. Но при генерации ключей знать это не обязательно: достаточно указать, какой ключ мы собираемся создать - обмена ключами или подписи. Для этого используются мнемонические константы AT_KEYEXCHANGE и AT_SIGNATURE; флаги - при создании асимметричных ключей управляет их размером. Используемый нами криптопровайдер позволяет генерировать ключ обмена ключами длиной от 384 до 512 бит**, а ключ подписи - от 512 до 16384 бит. Чем больше длина ключа, тем выше его надежность, поэтому трудно найти причины для использования ключа обмена ключами длиной менее 512 бит, а длину ключа подписи не рекомендуется делать меньше 1024 бит**. По умолчанию криптопровайдер создает оба ключа длиной 512 бит. Необходимую длину ключа можно передать в старшем слове параметра флаги; ключ - в случае успешного завершения функции в этот параметр заносится дескриптор созданного ключа.
Рассмотрим пример создания ключевых пар при помощи формы, показанной на рис. 8. В поле "Контейнер" можно указать имя контейнера ключей; если оставить это поле пустым, будет использован контейнер по умолчанию. Назначение остальных элементов управления должно быть интуитивно понятным. После генерации ключа в memo-поле выводится отчет о его параметрах. Для этого используется функция CryptGetKeyParam (ключ, параметр, буфер, размер, флаги). Чтобы получить информацию о требуемом параметре, нужно через второй аргумент функции передать соответствующую константу: KP_ALGID - идентификатор алгоритма, KP_KEYLEN - размер ключа, и т. д. См. генерации ключей без операторов обработки ошибок.
Создание сеансовых ключей
CryptoAPI позволяет генерировать сеансовые ключи случайным образом - эту работу выполняет функция CryptGenKey, о которой шла речь ранее. Однако при использовании этой возможности за пределами США и Канады приходится учитывать американские ограничения на экспорт средств "сильной криптографии". В частности, до января 2000года был запрещен экспорт программного обеспечения для шифрования с использованием ключей длиной более 40 бит. Этим объясняется разработка Microsoft двух версий своего криптопровайдера - базовой и расширенной. Базовая версия предназначалась на экспорт и поддерживала симметричные ключи длиной 40 бит; расширенная же версия (Microsoft Enhanced Cryptographic Provider) работала с "полной" длиной ключа (128 бит). Поскольку алгоритм шифрования, как правило, требует использования ключа строго определенной длины, недостающее количество битв в урезанном "экспортном" ключе могло быть заполнено либо нулями, либо случайными данными, которые предлагалось передавать открыто.
В криптографической практике внесение в состав ключа определенной части несекретных данных, которые сменяются несколько раз в ходе обработки исходного или шифр-текста, используется для того, чтобы воспрепятствовать взлому шифра атакой "по словарю". В английской терминологии такие вставки называются salt values: их назначение - "подсолить" ключ (с учетом нашей ментальности можно перевести как "насолить" противнику). Поскольку этот термин используется и в CryptoAPI, будем употреблять его в транслитерированном виде - солт-значения.
Итак, CryptoAPI, в экспортном исполнении практически вынуждает нас использовать солт-значения, составляющие бОльшую часть ключа - 88 бит из 128-ми для симметричных алгоритмов в RC2; и RC4. Конечно, при такой эффективной длине ключа криптозащита не может считаться достаточно надежной. В реальной ситуации выход один - воспользоваться криптопровайдером, не ограничивающим длину ключа. Обладатели Windows XP могут прибегнуть к услугам расширенных версий провайдера Microsoft (Enhanced или Strong).
Пользователям более старых версий Windows, по-видимому, придется воспользоваться продуктами сторонних разработчиков. Например, свои версии криптопровайдеров предлагают российская компания и шведская . В Украине, насколько известно авторам, разработкой национального провайдера криптографических услуг занимается коллектив харьковских ученых под руководством профессора Горбенко, однако до широкого внедрения дело пока не дошло. Тем не менее, благодаря архитектуре CryptoAPI, прикладные программы могут разрабатываться и отлаживаться и с базовым провайдером Microsoft - так как интерфейс взаимодействия остается неизменным. Поэтому вернемся к обсуждению создания случайных сеансовых ключей.
Солт может быть сгенерирован вместе с ключом: для этого нужно в качестве флага передать функции CryptGenKey (или CryptDeriveKey) константу CRYPT_CREATE_SALT. Правда, при сохранении ключа (с помощью функции CryptExportKey) система уже не заботится о солт-значении, перекладывая ответственность на прикладную программу. Таким образом, корректная процедура создания и сохранения симметричного ключа предполагает:
1. при создании ключа функции CryptGenKey передается значение флага CRYPT_EXPORTABLE or CRYPT_CREATE_SALT;
2. с помощью функции CryptGetKeyParam с параметром KP_SALT сгенерированное солт-значение сохраняется в буфере;
3. ключ в зашифрованном виде сохраняется в буфере при помощи функции CryptExportKey, которой передается открытый ключ обмена ключами адресата;
4. зашифрованные ключевые данные сохраняются или передаются адресату вместе с экспортированным на втором шаге солт-значением.
С другой стороны, солт-значение может быть сгенерировано и отдельно от ключа. Для этого используется функция CryptGenRandom (провайдер, длина, буфер). Здесь параметр длина задает размер генерируемой случайной последовательности в байтах, а последний аргумент задает адрес буфера, в который будет записан результат. Полученное таким образом солт-значение может быть внесено в ключ с помощью функции CryptSetKeyParam (ключ, параметр, данные, флаги).Ей вторым аргументом нужно передать KP_SALT, а третьим - адрес буфера, содержащего сгенерированную последовательность. (Последний аргумент функции зарезервирован на будущее и должен быть равен нулю.)
Взаимодействие с CryptoAPI
Функции CryptoAPI можно вызвать из программы, написанной на любимом многими (в том числе и авторами) языке С++. Тем не менее, Pascal де-факто признан стандартом в области обучения программированию. (Не будем спорить о том, хорошо это или плохо, чтобы не ввязываться в драку, пусть даже и виртуальную.) Кроме того, в ряде отечественных компаний Delphi является базовым средством разработки. Поэтому все примеры были реализованы в среде Delphi. Хотя в качестве инструмента можно было бы выбрать и MS Visual C++.
Код функций криптографической подсистемы содержится в нескольких динамически загружаемых библиотеках Windows (advapi32.dll, crypt32.dll). Для обращения к такой функции из прикладной программы на Object Pascal следует объявить ее как внешнюю. Заголовок функции в интерфейсной части модуля будет выглядеть, например, так: function CryptAcquireContext ( phPROV: PHCRYPTPROV; pszContainer: LPCTSTR; pszProvider: LPCTSTR; dwProvType: DWORD; dwFlags: DWORD): BOOL; stdcall;
а в исполняемой части вместо тела функции нужно вписать директиву extern с указанием библиотеки, в которой содержится функция, и, возможно, ее имени в этой библиотеке (если оно отличается от имени функции в создаваемом модуле), например: function CryptAcquireContext; external ‘advapi32.dll’ name 'CryptAcquireContextA';
Таким образом, имея описание функций CryptoAPI, можно собрать заголовки функций в отдельном модуле, который будет обеспечивать взаимодействие прикладной программы с криптографической подсистемой. Разумеется, такая работа была проделана программистами Microsoft, и соответствующий заголовочный файл (wincrypt.h) был включен в поставку MS Visual C++. К счастью, появилась и Delphi-версия (wcrypt2.pas). Ее можно найти . Подключив модуль к проекту, вы сможете использовать не только функции CryptoAPI, но и мнемонические константы режимов, идентификаторы алгоритмов и прочих параметров, необходимых на практике.
И последнее замечание перед тем, как опробовать CryptoAPI в деле. Ряд функций был реализован только в Windows 2000. Но и на старушку Windows 98 можно найти управу: при установке Internet Explorer 5 интересующие нас библиотеки обновляются, позволяя использовать новейшие криптографические возможности. Нужно лишь задать для Delphi-проекта параметр условной компиляции NT5, после чего вызовы функций, появившихся лишь в Windows 2000, будут нормально работать.
Знакомство с криптопровайдерами
Функции CryptoAPI обеспечивают прикладным программам доступ к криптографическим возможностям Windows. Однако они являются лишь «передаточным звеном» в сложной цепи обработки информации. Основную работу выполняют скрытые от глаз программиста функции, входящие в специализированные программные (или программно-аппаратные) модули — провайдеры (поставщики) криптографических услуг (CSP - Cryptographic Service Providers), или криптопровайдеры (рис. 1).

Программная часть криптопровайдера представляет собой dll-файл, подписанный Microsoft; периодически Windows проверяет цифровую подпись, что исключает возможность подмены криптопровайдера.
Криптопровайдеры отличаются друг от друга:
составом функций (например, некоторые криптопровайдеры не выполняют шифрование данных, ограничиваясь созданием и проверкой цифровых подписей); требованиями к оборудованию (специализированные криптопровайдеры могут требовать устройства для работы со смарт-картами для выполнения аутентификации пользователя); алгоритмами, осуществляющими базовые действия (создание ключей, хеширование и пр.).
По составу функций и обеспечивающих их алгоритмов криптопровайдеры подразделяются на типы. Например, любой CSP типа PROV_RSA_FULL поддерживает как шифрование, так и цифровые подписи, использует для обмена ключами и создания подписей алгоритм RSA, для шифрования — алгоритмы RC2 и RC4, а для хеширования - MD5 и SHA.
В зависимости от версии операционной системы состав установленных криптопровайдеров может существенно изменяться. Однако на любом компьютере с Windows можно найти Microsoft Base Cryptographic Provider, относящийся к уже известному нам типу PROV_RSA_FULL. Именно с этим провайдером по умолчанию будут взаимодействовать все программы.
Использование криптографических возможностей Windows напоминает работу программы с графическим устройством. Криптопровайдер подобен графическому драйверу: он может обеспечивать взаимодействие программного обеспечения с оборудованием (устройство чтения смарт-карт, аппаратные датчики случайных чисел и пр.).
Для вывода информации на графическое устройство приложение не должно непосредственно обращаться к драйверу — вместо этого нужно получить у системы контекст устройства, посредством которого и осуществляются все операции. Это позволяет прикладному программисту использовать графическое устройство, ничего не зная о его аппаратной реализации. Точно так же для использования криптографических функций приложение обращается к криптопровайдеру не напрямую, а через CryptoAPI. При этом вначале необходимо запросить у системы контекст криптопровайдера.
Первым делом, хотя бы из любопытства, выясним, какие же криптопровайдеры установлены в системе. Для этого нам понадобятся четыре функции CryptoAPI (выходные параметры выделены жирным шрифтом, а входные - курсивом):
CryptEnumProviders (i, резерв, флаги, тип, имя, длина_имени) - возвращает имя и тип i-го по порядку криптопровайдера в системе (нумерация начинается с нуля); CryptAcquireContext (провайдер, контейнер, имя, тип, флаги) - выполняет подключение к криптопровайдеру с заданным типом и именем и возвращает его дескриптор (контекст). При подключении мы будем передавать функции флаг CRYPT_VERIFYCONTEXT, служащий для получения контекста без подключения к контейнеру ключей; CryptGetProvParam (провайдер, параметр, данные, размер_данных, флаги) - возвращает значение указанного параметра провайдера, например, версии (второй параметр при вызове функции - PP_VERSION), типа реализации (программный, аппаратный, смешанный - PP_IMPTYPE), поддерживаемых алгоритмов (PP_ENUMALGS). Список поддерживаемых алгоритмов при помощи этой функции может быть получен следующим образом: при одном вызове функции возвращается информация об одном алгоритме; при первом вызове функции следует передать значение флага CRYPT_FIRST, а при последующих флаг должен быть равен 0; CryptReleaseContext (провайдер, флаги) - освобождает дескриптор криптопровайдера.
Каждая из этих функций, как и большинство других функций CryptoAPI, возвращает логическое значение, равное true, в случае успешного завершения, и false - если возникли ошибки.Код ошибки может быть получен при помощи функции GetLastError. Возможные значения кодов ошибки приведены в упоминавшейся выше документации. Например, при вызове функции CryptGetProvParam для получения версии провайдера следует учесть возможность возникновения ошибок следующим образом:
Текст процедуры, выводящей в Memo-поле FileMemo формы информацию об установленных в системе криптопровайдерах, приведен в . Предполагается, что процедура вызывается при выборе соответствующего элемента в главном меню формы. Для краткости в тексте программы опущены фрагменты, выполняющие обработку ошибок.
На рис. 2 показан пример отчета, выдаваемого приведенным выше кодом, выполненным в среде Windows 98.
Windows и Delphi на защите секретов (часть 4)
Константин Виноградов, Первые три части статьи
Что такое сертификат? Какова его роль в защите информации? И, самое главное, - как можно использовать на практике механизм сертификации? Об этом и пойдет речь в нашей статье
Предположим, две стороны (назовем их по традиции Алисой и Бобом) решили обменяться открытыми ключами по незащищенному каналу связи, например по телефонной линии или интернету. Некто третий (по имени Ева) во время пересылки может подменить ключи и получить таким образом доступ к секретной переписке. Чтобы исключить эту угрозу безопасности, нужно иметь возможность подтвердить подлинность полученного открытого ключа. Для этого и предусмотрены сертификаты. Сертификаты
Представим себе, что существует организация, которой Боб полностью доверяет. Назовем ее Центром сертификации (Certification Authority). Алиса отсылает свой открытый ключ в Центр сертификации (ЦС). Там у нее запрашивают документы и устанавливают, действительно ли она та особа, за которую себя выдает. Затем ЦС генерирует электронный документ, содержащий информацию об Алисе и ее открытый ключ, и подписывает его своим закрытым ключом. Этот цифровой документ и является сертификатом. Сертификат может не только служить для аутентификации личности (как в случае с Алисой), но и подтверждать подлинность оборудования, веб-сайта, организации и т.п. Поэтому набор сведений, входящих в его состав, может изменяться и удовлетворять одному из стандартов. Как правило, сертификат содержит следующие данные: серийный номер сертификата;
ФИО (название) владельца сертификата;
открытый ключ владельца;
срок действия (даты начала и конца пригодности сертификата);
название ЦС;
электронная цифровая подпись ЦС.
Итак, ЦС удостоверяет личность Алисы и своей подписью заверяет связь между ней и ее ключом. Поскольку сведения об Алисе подписаны, Боб может убедиться в их целостности. Для этого ему нужно обратиться в ЦС и проверить цифровую подпись, входящую в состав сертификата. Даже если Ева, о который мы упомянули вначале, перехватит сертификат и изменит сведения об Алисе, то ей придется подделывать подпись ЦС.
Кроме того, Боб тоже может получить в ЦС "электронное удостоверение личности" - и тогда уверенностью в подлинности открытых ключей будут обладать оба корреспондента. Остался один невыясненный вопрос: на чем держится доверие к Центру сертификации? Если Алиса и Боб - сотрудники одной и той же организации, а переписку ведут в деловых целях, то в качестве ЦС может выступить сама организация. Для этого ей потребуется обзавестись штатным специалистом по защите информации и поручить ему выполнение всех процедур, связанных с выдачей и проверкой сертификатов. Ну а на чем должно основываться доверие фирмы к своему сотруднику, думаем, объяснять не нужно. В случае же, если Алиса и Боб - представители различных организаций, им придется обращаться в независимый центр сертификации. Деятельность таких центров, как правило, лицензируется службами безопасности страны или другими государственными органами. Например, украинские организации, работающие в сфере защиты информации, должны получить лицензию СБУ. Сертификату, выданному таким ЦС, можно доверять в той же степени, в какой вы доверяете паспорту гражданина некого государства. Центры сертификации могут находиться в различных странах, работать с различным программным обеспечением, поддерживать разные стандарты сертификатов и отличающиеся процедуры их выдачи. Поэтому возникает необходимость наладить отношения доверия между самими ЦС. Эта система доверительных отношений может строиться по иерархическому принципу. Существует небольшое число ЦС, называющихся корневыми (Root Certification Authority). Они удостоверяют сертификаты дочерних центров, которые, в свою очередь, подтверждают подлинность других ЦС и т.д. В глобальном масштабе структура ЦС представляет собой несколько иерархий (см. ). Поддержка сертификатов в CryptoAPI
Рассмотрим решение основных задач, возникающих при выпуске и обслуживании сертификатов на уровне библиотеки ОС Windows - CryptoAPI. Кстати говоря, для "внутреннего" употребления сертификатов (в рамках одной организации) процедуру лицензирования проходить не нужно.
Никто ведь не может запретить вам обмениваться файлами, которые по секрету от СБУ вы будете считать цифровыми документами. Чтобы обзавестись собственным сертификатом, прежде всего нужно создать запрос специального формата, который должен содержать ваше имя, открытые ключи обмена ключами и подписи. Этот запрос подписывается отправителем при помощи личного закрытого ключа и отсылается в центр сертификации. Запрос на получение сертификата
Рассмотрим процесс создания запроса более подробно. Для хранения данных запроса в CryptoAPI предназначена специальная структура - CERT_REQUEST_INFO. Она содержит ссылки на другие структуры, хранящие имя владельца сертификата, информацию об открытых ключах и, возможно, некоторые дополнительные атрибуты (). В результате для создания запроса сертификата следует выполнить следующие шаги: Создать строку, содержащую поле Subject сертификата.
Создать массив структур CERT_RDN_ATTR (в простейшем случае он будет состоять из единственного элемента) и инициализировать каждый его элемент следующими данными: строкой идентификатора объекта, типом хранимого значения, длиной строки, созданной на первом шаге, и самой этой строкой, приведенной к типу PBYTE. Аббревиатура RDN означает Relative Distinguished Name (относительные отличительные признаки). Структура RDN может хранить, например, имя пользователя, адрес, страну, наименование подразделения организации и т.п. При этом хранимые данные характеризуются идентифицирующей строкой: скажем, имя владельца сертификата должно иметь строку-идентификатор "2.5.4.3", двухбуквенный код страны - "2.5.4.6", и т.д. (подробное описание можно найти в справке по CryptoAPI). Способ представления данных строки описывается типом хранимого значения - например, CERT_RDN_PRINTABLE_STRING или CERT_RDN_ENCODED_BLOB.
Создать массив структур CERT_RDN (в простейшем случае и он будет содержать лишь один элемент) и инициализировать каждый его элемент количеством элементов в соответствующем массиве CERT_RDN_ATTR, созданном на шаге 2, и ссылкой на первый элемент этого массива.
Создать структуру CERT_NAME_INFO и инициализировать ее поля значениями количества элементов массива, созданного на шаге 3, и ссылкой на первый элемент этого массива.
Вызвать функцию CryptEncodeObject, передав ей в качестве соответствующего параметра структуру CERT_NAME_INFO из шага 4. Результатом работы функции будет структура типа CERT_NAME_BLOB, содержащая входную информацию в закодированном виде. При обращении к функции следует указать тип кодировки; документация по CryptoAPI рекомендует использовать кодировку в виде комбинации следующих констант: PKCS_7_ASN_ENCODING or X509_ASN_ENCODING (другие типы могут не поддерживаться).
Записать в поле Subject структуры CERT_REQUEST_INFO ссылку на структуру CERT_NANE_BLOB, созданную и инициализированную на шаге 5.
Если в запрос сертификата должна быть включена некоторая дополнительная информация, нужно поместить ее в заранее созданный массив структур CRYPT_ATTR_BLOB, а ссылками на такие массивы инициализировать массив CRYPT_ATTRIBUTE. Ссылка на последний массив и количество элементов в нем записывается в соответствующие поля структуры CERT_REQUEST_INFO. Для ясности изложения этот этап рассматривать не будем.
В структуру CERT_REQUEST_INFO необходимо вписать номер версии сертификата. CryptoAPI поддерживает сертификаты трех версий: 1 - сертификат содержит минимальный набор данных (работу именно с такими сертификатами мы и рассмотрим); 2 - сертификат содержит дополнительно уникальные идентификаторы владельца и издателя; 3 - сертификат включает дополнительную информацию об издателе (Центре сертификации), например его адрес электронной почты или лицензию на выпуск сертификатов.
Вызвать функцию CryptExportPublicKeyInfo, которая вернет инициализированную структуру CERT_PUBLIC_KEY_INFO, содержащую открытые части ключей пользователя.
Записать в поле SubjectPublicKeyInfo структуры CERT_REQUEST_INFO ссылку на структуру, созданную на шаге 9.
Вызвать функцию CryptSignAndEncodeCertificate, передав ей в качестве аргумента структуру CERT_REQUEST_INFO.
Эта функция закодирует структуру CERT_REQUEST_INFO и все данные, на которые в этой структуре имеются ссылки, подпишет эту закодированную информацию и еще раз закодирует уже подписанные данные.
Полученный в результате подписанный и закодированный запрос сертификата нужно сохранить в файле и отправить в центр сертификации. Далее приведен текст процедуры (без обработки ошибок), реализующей описанный выше алгоритм:
{SubjectEdit - поле формы, в которое пользователь вводит текст поля Subject сертификата; поле формы ContainerEdit может содержать имя контейнера ключей (если остается пустым, используется контейнер по умолчанию)} procedure TCreateReqForm.OKBtnClick (Sender: TObject); var nameAttr: CERT_RDN_ATTR; nameString: PChar; rdn: CERT_RDN; nameInfo: CERT_NAME_INFO; certReqInfo: CERT_REQUEST_INFO; subjNameBlob: CERT_NAME_BLOB; encNameLen: DWORD; encName: PBYTE; prov: HCRYPTPROV; pubKeyInfoLen: DWORD; pubKeyInfo: PCERT_PUBLIC_KEY_INFO; encCertReqLen: DWORD; params: CRYPT_OBJID_BLOB; sigAlg: CRYPT_ALGORITHM_IDENTIFIER; signedEncCertReq: PBYTE; cont: PChar; err: string; encType: DWORD; f: file; begin encType:= PKCS_7_ASN_ENCODING or X509_ASN_ENCODING; nameString:= StrAlloc (length (SubjectEdit.text)+1); StrPCopy (nameString, SubjectEdit.Text); nameAttr.pszObjId:= '2.5.4.3'; nameAttr.dwValueType:= CERT_RDN_PRINTABLE_STRING; nameAttr.Value.cbData:= length (SubjectEdit.text); nameAttr.Value.pbData:= PBYTE (nameString); rdn.cRDNAttr:= 1; rdn.rgRDNAttr:= @nameAttr; nameInfo.cRDN:= 1; nameInfo.rgRDN:= @rdn; {выясняем размер закодированного имени пользователя} CryptEncodeObject (encType, X509_NAME, @nameInfo, nil, @encNameLen) or (encNameLen < 1); GetMem (encName, encNameLen); {кодируем имя пользователя} CryptEncodeObject (PKCS_7_ASN_ENCODING or X509_ASN_ENCODING, X509_NAME, @nameInfo, encName, @encNameLen) or (encNameLen < 1); subjNameBlob.cbData:= encNameLen; subjNameBlob.pbData:= encName; certReqInfo.Subject:= subjNameBlob; certReqInfo.cAttribute:= 0; certReqInfo.rgAttribute:= nil; certReqInfo.dwVersion:= CERT_REQUEST_V1; if length (ContainerEdit.Text) = 0 then cont:= nil else begin err:= ContainerEdit.Text; cont:= StrAlloc (length (err) + 1); StrPCopy (cont, err); end; CryptAcquireContext (@prov, cont, nil, PROV_RSA_FULL, 0); CryptExportPublicKeyInfo (prov, AT_SIGNATURE, encType, nil, @pubKeyInfoLen); GetMem (pubKeyInfo, pubKeyInfoLen); CryptExportPublicKeyInfo (prov, AT_SIGNATURE, encType, pubKeyInfo, @pubKeyInfoLen); certReqInfo.SubjectPublicKeyInfo:= pubKeyInfo^; FillChar (params, sizeof (params), 0); sigAlg.pszObjId:= szOID_OIWSEC_sha1RSASign; sigAlg.Parameters:= params; CryptSignAndEncodeCertificate (prov, AT_SIGNATURE, encType, X509_CERT_REQUEST_TO_BE_SIGNED, @certReqInfo, @sigAlg, nil, nil, @encCertReqLen); GetMem (signedEncCertReq, encCertReqLen); CryptSignAndEncodeCertificate (prov, AT_SIGNATURE, encType, X509_CERT_REQUEST_TO_BE_SIGNED, @certReqInfo, @sigAlg, nil, signedEncCertReq, @encCertReqLen); if SaveDlg.Execute then begin AssignFile (f, SaveDlg.FileName); rewrite (f, 1); BlockWrite (f, signedEncCertReq^, encCertReqLen); CloseFile (f); end; StrDispose (nameString); FreeMem (encName, encNameLen); if cont <> nil then StrDispose (cont); FreeMem (pubKeyInfo, pubKeyInfoLen); FreeMem (signedEncCertReq, encCertReqLen); CryptReleaseContext (prov, 0); end;
Итак, запрос сертификата создан, но что с ним делать? Если вам нужен сертификат, который можно использовать для организации безопасной связи с зарубежными партнерами, нужно отправить созданный запрос в центр сертификации, предоставив необходимые подтверждающие личность документы и уплатив соответствующую сумму. Если вы собираетесь обмениваться только в рамках сети предприятия, располагающей сервером Windows 2000 и выше, можно воспользоваться Microsoft Certificate Server. Если же вашей целью, например, является только отладка программ, или если группа, внутри которой вы собираетесь организовать обмен информацией, располагает лишь компьютерами под Windows 98 (и ниже), то можно подписать сертификат самостоятельно. Подписание сертификата
При этом важно не забыть цель создания сертификата - он создавался, чтобы связь между именем пользователя и его открытым ключом удостоверялась подписью некоторой доверенной стороны. Такой "доверенный" пользователь внутри группы (будем называть его администратором) должен создать ключевую пару администратора и создать для нее сертификат, который он подписывает тем же закрытым ключом администратора. Этот сертификат называется корневым. Ключ администратора используется и для подписания сертификатов пользователей. Когда один пользователь хочет проверить подлинность сертификата другого пользователя, он проверяет подпись под ним администратора, используя для проверки тот самый корневой сертификат. Итак, сделаем из только что созданного запроса сертификата подписанный корневой сертификат. Это можно проделать при помощи функций CryptoAPI. Сама процедура в документации даже не упоминается, однако ее можно "вывести" из описания соответствующих функций. Проследим ее на примере программы, позволяющей открыть файл с запросом сертификата, проверить подпись под ним и выпустить подписанный сертификат с заданным сроком действия. Программа управляется формой, показанной на . Вначале необходимо открыть запрос и проверить подпись под ним.
Проверяем, задано ли нестандартное имя контейнера, и подключаемся к криптопровайдеру.
Открываем файл с закодированным запросом сертификата и считываем его содержимое в память (указатель reqEncoded).
Декодируем запрос:
{encType, size, rsize: DWORD; buf: PBYTE;} encType:= PKCS_7_ASN_ENCODING or X509_ASN_ENCODING; GetMem (buf, 2048); rsize:= 2048; CryptDecodeObject (encType, X509_CERT, reqEncoded, size, 0, buf, @rsize);
В декодированном запросе выделяем и декодируем информацию, предназначенную для подписания - уже знакомую нам структуру CERT_REQUEST_INFO:
{p: pointer; signedContent: PCERT_SIGNED_CONTENT_INFO; DERBLOB: CRYPT_DER_BLOB; buf2: PBYTE; pCertReqInfo: PCERT_REQUEST_INFO;} p:= buf; signedContent:= p; DERBLOB:= signedContent^.toBeSigned; rsize:= 512; GetMem (buf2, rsize); CryptDecodeObject (encType, X509_CERT_REQUEST_TO_BE_SIGNED, DERBLOB.pbData, DERBLOB.cbData, 0, buf2, @rsize); p:= buf2; pCertReqInfo:= p;
Извлекаем из полученной информации строку с именем (названием) владельца сертификата, чтобы отобразить ее на форме:
{subjNameBLOB: CERT_NAME_BLOB; subjNameString: PChar;} subjNameBLOB:= pCertReqInfo^.Subject; rsize:= CertNameToStr (encType, @subjNameBLOB, CERT_SIMPLE_NAME_STR, subjNameString, 512); subjectEdit.Text:= subjNameString;
Проверяем подпись под запросом сертификата:
signCheckBox.Checked:= CryptVerifyCertificateSignature(prov, encType, reqEncoded, size, @(pCertReqInfo^.SubjectPublicKeyInfo));
Напоследок - заполняем поля формы "Действителен с" и "Действителен по" текущей датой и датой, отстоящей на год вперед:
NotBeforeEdit.Text:= DateTimeToStr (Now); NotAfterEdit.Text:= DateTimeToStr (Now + 365);
Освобождаем выделенную память и отключаемся от криптопровайдера.
После того, как пользователь убедился в правильности подписи под запросом, откорректировал при необходимости срок действия создаваемого сертификата, указал его серийный номер, вписал название издателя (администратора, центра сертификации) и указал в поле "Контейнер" имя контейнера ключей администратора, начинаем процесс подписания.
Для этого следует создать и заполнить структуру CERT_INFO, являющуюся, как сказано в документации, "сердцем сертификата" ( - серым цветом обозначены поля, содержащие закодированную информацию).
Подключаемся к контейнеру ключей администратора.
Заполняем поля сертификата, представленного структурой CERT_INFO:
{certInfo: CERT_INFO; serNum: int64; params: CRYPT_OBJID_BLOB; nameStr: PChar; nameAttr: CERT_RDN_ATTR; rdn: CERT_RDN; nameInfo: CERT_NAME_INFO;} certInfo.dwVersion:= CERT_V1; {версия 1} serNum:= strtoint64(serNumEdit.Text); certInfo.SerialNumber.cbData:= sizeof (serNum); certInfo.SerialNumber.pbData:= @serNum; FillChar (params, sizeof (params), 0); certInfo.SignatureAlgorithm.pszObjId:= szOID_OIWSEC_sha1RSASign; certInfo.SignatureAlgorithm.Parameters:= params; nameStr:= StrAlloc (length (IssuerEdit.text)+1); StrPCopy (nameStr, IssuerEdit.Text); nameAttr.pszObjId:= '2.5.4.3'; nameAttr.dwValueType:= CERT_RDN_PRINTABLE_STRING; nameAttr.Value.cbData:= length (IssuerEdit.text); nameAttr.Value.pbData:= PBYTE (nameStr); rdn.cRDNAttr:= 1; rdn.rgRDNAttr:= @nameAttr; nameInfo.cRDN:= 1; nameInfo.rgRDN:= @rdn;
Кодируем строку, содержащую название издателя сертификата:
{encNameLen: DWORD; encName: PBYTE; issNameBLOB: CERT_NAME_BLOB;} CryptEncodeObject (encType, X509_NAME, @nameInfo, nil, @encNameLen); GetMem (encName, encNameLen); CryptEncodeObject (encType, X509_NAME, @nameInfo, encName, @encNameLen); issNameBlob.cbData:= encNameLen; issNameBlob.pbData:= encName; certInfo.Issuer:= issNameBLOB;
Кодируем даты начала и конца срока действия сертификата:
{sysTime: TSystemTime;} DateTimeToSystemTime (StrToDateTime (NotBeforeEdit.Text), sysTime); SystemTimeToFileTime (sysTime, certInfo.notBefore); DateTimeToSystemTime (StrToDateTime (NotAfterEdit.Text), sysTime); SystemTimeToFileTime (sysTime, certInfo.notAfter);
Поля сертификата, содержащие информацию о его владельце, заполняем на основании данных, содержащихся в декодированном запросе сертификата:
certInfo.Subject:= pCertReqInfo.Subject; certInfo.SubjectPublicKeyInfo:= pCertReqInfo.SubjectPublicKeyInfo;
В неиспользуемые поля вписываем нули и пустые указатели:
certInfo.IssuerUniqueId.cbData:= 0; certInfo.IssuerUniqueId.pbData:= nil; certInfo.IssuerUniqueId.cUnusedBits:= 0; certInfo.SubjectUniqueId.cbData:= 0; certInfo.SubjectUniqueId.pbData:= nil; certInfo.SubjectUniqueId.cUnusedBits:= 0; certInfo.cExtension:= 0; certInfo.rgExtension:= nil;
Подписываем и кодируем сертификат:
{encCertLen: DWORD; encCert: PByte;} CryptSignAndEncodeCertificate (prov, AT_SIGNATURE, encType, X509_CERT_TO_BE_SIGNED, @certInfo, @(certInfo.SignatureAlgorithm), nil, nil, @encCertLen); GetMem (encCert, encCertLen); CryptSignAndEncodeCertificate (prov, AT_SIGNATURE, encType, X509_CERT_TO_BE_SIGNED, @certInfo, @(certInfo.SignatureAlgorithm), nil, encCert, @encCertLen);
Сохраняем подписанный и закодированный сертификат в файле, освобождаем память и дескриптор криптопровайдера.
Хранение сертификатов
Созданный сертификат владелец может отправлять своим корреспондентам для организации безопасной связи. Чтобы сделать полученный сертификат доступным системе, его нужно поместить в одно из хранилищ сертификатов. Windows предусматривает существование нескольких системных хранилищ сертификатов: MY (для хранения сертификатов отдельного пользователя), СА (от Certification Authority - для хранения сертификатов центров сертификации) и ROOT (для хранения корневых сертификатов). Открытое (загруженное в память) хранилище сертификатов представляет собой связанный список блоков данных, каждый из которых содержит ссылку на следующий блок и на данные сертификата. Каждое хранилище сертификатов физически размещается либо в отдельном файле, либо в реестре Windows. При этом для работы с системными хранилищами не нужно знать их местоположения - достаточно указать приведенные выше имена. Для помещения сохраненного в файле подписанного сертификата в системное хранилище нужно выполнить следующие шаги. Открыть файл и считать его содержимое в буфер.
При помощи специальной функции создать контекст сертификата:
{encCertLen: DWORD; - размер закодированного сертификата encCert: PByte; - данные сертификата context: PCCERT_CONTEXT; encType: DWORD;} encType:= PKCS_7_ASN_ENCODING or X509_ASN_ENCODING; context:= CertCreateCertificateContext (encType, encCert, encCertLen);
Открыть системное хранилище сертификатов:
{store: HCERTSTORE;} store:= CertOpenSystemStore (0, 'MY');
Добавить контекст сертификата в открытое хранилище:
n:= nil; CertAddCertificateContextToStore (store, context, CERT_STORE_ADD_REPLACE_EXISTING, n)
Функции CertAddCertificateContextToStore, кроме дескрипторов хранилища и добавляемого контекста сертификата, передается параметр, определяющий действия системы в том случае, если в данном хранилище уже имеется идентичный сертификат. Использованная константа CERT_STORE_ADD_REPLACE_EXISTING предписывает в таком случае удалить старый сертификат и заменить его новым. Последний параметр функции позволяет получить указатель на указатель на копию сертификата, созданную при добавлении контекста в хранилище (если параметр равен пустому указателю, то ссылка не возвращается). Закрыть хранилище, освободить контекст сертификата и память.
CertCloseStore (store, 0); CertFreeCertificateContext (context); FreeMem (encCert, encCertLen);
Просмотреть имеющиеся в хранилище сертификаты можно с помощью функции CertEnumCertificatesInStore. Ей нужно передать дескриптор нужного хранилища и, при первом вызове, пустой указатель, а при последующих - указатель на предыдущий сертификат. Например, для просмотра содержимого одного из системных хранилищ сертификатов может быть использован следующий фрагмент программы (форма, из которой он вызывается, с результатами работы показана на ):
{store: HCERTSTORE; cont, stor: PChar; err: string; cert: PCCERT_CONTEXT; nameString: PChar; size: DWORD; nameBLOB: CERT_NAME_BLOB; подключение к криптопровайдеру считается выполненным!} err:= CertStoreBox.Text; RepMemo.Lines.Add (''); RepMemo.Lines.Add ('===================='); RepMemo.Lines.Add ('Contents of store ' + err); RepMemo.Lines.Add ('===================='); stor:= StrAlloc (length (err) + 1); StrPCopy (stor, err); store:= CertOpenSystemStore (prov, stor); cert:= CertEnumCertificatesInStore (store, nil); nameString:= StrAlloc (512); while cert <> nil do begin RepMemo.Lines.Add ('---------------'); RepMemo.Lines.Add ('Subject:'); nameBLOB:= cert^.pCertInfo^.Subject; size:= CertNameToStr (encType, @nameBlob, CERT_SIMPLE_NAME_STR, nameString, 512); if size > 1 then RepMemo.Lines.Add (nameString) else RepMemo.Lines.Add ('Error'); RepMemo.Lines.Add ('Issuer:'); nameBLOB:= cert^.pCertInfo^.Issuer; size:= CertNameToStr (encType, @nameBlob, CERT_SIMPLE_NAME_STR, nameString, 512); if size > 1 then RepMemo.Lines.Add (nameString) else RepMemo.Lines.Add ('Error'); cert:= CertEnumCertificatesInStore (store, cert); end; StrDispose (nameString);
Проверка сертификата
Получив новый сертификат, конечно, следует убедиться в корректности подписи под ним. При этом сам сертификат, скорее всего, будет помещен в личное хранилище пользователя (MY), а сертификат его издателя может находиться в хранилищах CA или ROOT. Кстати, при установке Windows в эти хранилища помещается множество сертификатов признанных центров сертификации, список которых можно просмотреть при помощи приведенной выше программы. Для выполнения проверки следует считать из проверяемого сертификата строку с именем его издателя и найти в одном из системных хранилищ его сертификат. Для облегчения операции поиска в нескольких хранилищах CryptoAPI 2.0 поддерживает механизм коллекций (или логических хранилищ) сертификатов. Коллекция может объединять данные из нескольких физических хранилищ и выполнять операции над всеми их сертификатами одновременно. Кстати говоря, в Windows 2000 и выше системные хранилища сертификатов сами представляют собой коллекции. Поиск сертификата издателя и проверка заданного сертификата выполняются одновременно функцией CertGetIssuerCertificateFromStore. Ей следует передать дескриптор хранилища сертификатов, ссылку на контекст проверяемого сертификата, возможно - ссылку на предыдущий найденный сертификат издателя (если вызов функции производится повторно) и ссылку на флаговую переменную. Эта переменная при вызове функции задает режим проверки, а при возврате - служит индикатором успеха проверки. Функция поддерживает несколько режимов проверки, которые могут комбинироваться; мы воспользуемся сочетанием двух из них - CERT_STORE_SIGNATURE_FLAG (проверить подпись издателя под заданным сертификатом) и CERT_STORE_TIME_VALIDITY_FLAG (проверить срок действия заданного сертификата). Рассмотрим процедуру проверки сертификата с заданным полем Subject на примере программы. Подключаемся к криптопровайдеру.
Открываем выбранное хранилище сертификатов.
Считываем из формы поле Subject и ищем соответствующий сертификат в хранилище:
{subj: PWideChar; err: string; cert: PCCERT_CONTEXT; тип и значение encType - см.
выше} err:= SubjectEdit.Text; GetMem (subj, 2 * length (err) + 1); StringToWideChar (err, subj, 2 * length (err) + 1); cert:= CertFindCertificateInStore (store, encType, 0, CERT_FIND_SUBJECT_STR, subj, nil); FreeMem (subj, 2 * length (err) + 1); if cert = nil then begin MessageDlg ('Certificate not found', mtError, [mbOK], 0); CertCloseStore (store, 0); exit; end;
Создаем коллекцию (логическое хранилище) сертификатов:
{collect: HCERTSTORE;} collect:= CertOpenStore (CERT_STORE_PROV_COLLECTION, 0, 0, 0, nil);
Открываем и помещаем в коллекцию интересующие нас системные хранилища сертификатов - MY, CA, ROOT:
{mystore, castore, rootstore: HCERTSTORE;} mystore:= CertOpenSystemStore (prov, 'MY'); CertAddStoreToCollection (collect, mystore, 0, 0); castore:= CertOpenSystemStore (prov, 'CA'); CertAddStoreToCollection (collect, castore, 0, 2); rootstore:= CertOpenSystemStore (prov, 'ROOT'); CertAddStoreToCollection (collect, rootstore, 0, 1)
Последним параметром функции CertAddStoreToCollection задается приоритет добавляемого хранилища в коллекции. Мы ожидаем, что сертификат издателя окажется в хранилище СА, поэтому для этого хранилища задан самый высокий приоритет, для ROOT - более низкий, а для MY - низший. Устанавливаем режим проверки:
{flags: DWORD;} flags:= CERT_STORE_SIGNATURE_FLAG or CERT_STORE_TIME_VALIDITY_FLAG;
Выполняем поиск сертификата издателя и проверку заданного сертификата:
{icert: PCCERT_CONTEXT;} icert:= CertGetIssuerCertificateFromStore (collect, cert, nil, @flags); if icert = nil then case int64(GetLastError) of CRYPT_E_NOT_FOUND: MessageDlg ('Issuer certificate not found', mtError, [mbOK], 0); CRYPT_E_SELF_SIGNED: MessageDlg ('This is root certificate', mtWarning, [mbOK], 0); else MessageDlg ('Invalid arguments', mtError, [mbOK], 0); end else if flags = 0 then MessageDlg ('Certificate is valid', mtInformation, [mbOK], 0) else MessageDlg ('Certificate is invalid', mtError, [mbOK], 0);
В результате при правильном обращении к функции может возникнуть одна из четырех ситуаций: сертификат издателя не найден - в этом случае нужно узнать издателя данного сертификата (по строке, выдаваемой, например, рассмотренной выше программой просмотра содержимого хранилища) и на его сайте взять сертификат для проверки;
проверяемый сертификат является корневым - использование таких сертификатов (если, конечно, это не ваш собственный сертификат, созданный под впечатлением этой статьи) требует предельного внимания, так как в этом случае подлинность данных сертификата ничем не подтверждается. Принимая такой сертификат, вы должны любыми путями убедиться, что он поступил из надежного источника (например, был помещен в хранилище ROOT при установке Windows). В противном случае вы рискуете подвергнуться такой, например, атаке: злоумышленник может прислать вам по электронной почте сообщение об обновлении корневого сертификата, заменит своими данными хранящийся у вас сертификат и сможет присылать вам фальшивые сертификаты пользователей, якобы заверенные подписью корневого центра сертификации;
сертификат верен - подпись издателя под проверяемым сертификатом верна, срок действия проверяемого сертификата включает текущую системную дату;
сертификат не прошел проверку - проверяемый сертификат либо просрочен, либо является подделкой. Правда, возможен еще один вариант: издатель имеет несколько сертификатов - и проверяемый сертификат подписан с использованием ключа из другого сертификата данного издателя. В таком случае нужно вызвать функцию CertGetIssuerCertificateFromStore повторно, передав в качестве третьего параметра контекст текущего сертификата издателя.
Итак, мы рассмотрели механизмы создания и управления сертификатами безопасности на основе CryptoAPI. Используя сертификаты, вы сможете выполнять действия с сообщениями при помощи многочисленных функций CryptoAPI, автоматизирующих процессы шифрования и расшифровки, подписания и проверки подписи, и представляющие результаты своих действий в соответствии с существующими стандартами.
Приложение.
Авторы ищут издателя для публикации учебного пособия по данной теме. Персональный сайт авторов - http://www.is.svitonline.com/vilys/.
Распределенные атаки на распределенные системы
А.А. Грушо (Доктор физико-математических наук)
Е.Е. Тимонина (кандидат физико-математических наук) Информационный бюллетень JET INFO
В стандарте FIPA [] агент определяется как сущность, способная вести себя автономно, выполнять план и распознавать другие сущности в протоколах, в которых они участвуют. Есть по крайней мере два протокола, в которых каждый агент ВМАС является участником. Первый — протокол взаимодействия агентов противника. Второй — это легальный протокол, содержащий агента в виде встроенного в некоторую область кода и процесса, использующего ресурсы компьютера.
Пусть компьютерная система разделена на два уровня — High и Low. Если субъект на уровне High может выполнять все свои действия и способен "видеть" действия субъекта на уровне Low, но любой субъект на уровне Low не может "видеть" никаких действий или их результатов на уровне High, то тогда система удовлетворяет условию невлияния. Если враждебный агент находится на уровне High, а механизмы защиты находятся на уровне Low, и выполняются условия невлияния, то агент не может быть "увиден" средствами защиты.
Мы должны ответить на вопрос, каким образом агент, будучи участником легального протокола, остается "невидимым" для механизмов защиты. Рассмотрим следующую примитивную схему, моделирующую механизмы "невидимости".
На приведена нормальная схема работы компьютера. Отметим, что процессор только выполняет команды, и ему все равно, кто их передает.
Рисунок 1. Схема работы компьютера
На агент "видит", что "хотят" сделать программы, куда обратиться, что и как обработать. Тогда программный агент может использовать процессор до работы легальных программ. То есть агент может "подправить" все так, как нужно ему, затем обработать реальный запрос и передать легальным программам ту информацию, которую ему нужно.
Рисунок 2. Враждебный агент в схеме компьютера
Эта модель описывает теоретическую возможность работы "невидимого" агента.
А.А. Грушо (Доктор физико-математических наук) Е.Е. Тимонина (кандидат физико-математических наук) Информационный бюллетень JET INFO
Итак, мы описали, каким образом можно построить "невидимый" канал между агентами на уровне High компьютерной системы с одной операционной системой. Но распределенная система основана на сети, в которой уровень Low, как правило, находится под контролем системы безопасности. Например, можно использовать снифферы. Здесь нет канала на уровне High. Тогда "невидимость" канала между агентами противника, использующими уровень Low, означает, что агенты уровня High могут прятать информацию в легальных каналах уровня Low. Здесь возникают три проблемы. Первая — спрятать спуск информации с уровня High на уровень Low от механизмов защиты. Вторая — это преодоление механизмов защиты, предназначенных для уничтожения скрытых каналов. И третья проблема — способность агентов быть интеллектуальными и использовать стойкие методы стеганографии.
Первая проблема может быть решена, так как организация встраивания информации уровня High в предложенных далее скрытых каналах возможна с помощью программно-аппаратных агентов в компьютерной среде. В самом деле, предположим, что функция организации скрытого канала для связи с внешней средой реализуется программно-аппаратным агентом. Тогда данный агент находится в конкретном компьютере под охраной другого агента, который делает его "невидимым" для средств защиты.
Показать, что функции построения скрытого канала доступны для программно-аппаратного агента, помогут примеры решения второй проблемы — преодоление механизмов защиты, предназначенных для уничтожения скрытых каналов.
Рассмотрим схему сети ().
Рисунок 4. Схема глобальной сети
Пусть имеется m+1 сегментов локальных вычислительных сетей, S0, S1,...,Sm, в каждом из которых есть рабочие станции со своими локальными адресами и шлюзы, соединяющие локальные сети с глобальной сетью (например, Интернет). Пусть s0, s1, ..., sm — адреса шлюзов сегментов локальных вычислительных сетей S0, S1, ..., Sm, которые представляют эти сегменты в глобальной сети.
А.А. Грушо (Доктор физико-математических наук) Е.Е. Тимонина (кандидат физико-математических наук) Информационный бюллетень JET INFO
Чтобы осуществить распределенную атаку, должна быть построена "невидимая" сеть агентов. В предыдущих разделах мы обсуждали, каким образом это можно сделать. На всех шагах распределенной атаки ВМАС должна быть интеллектуальной.
Для моделирования интеллектуальных свойств ВМАС мы использовали результаты исследований по Open Agent Architecture []. Пусть существует три класса агентов в ВМАС. Первый класс состоит из агентов-посредников. Второй класс включает в себя мета-агентов. Третий класс составляют агенты интерфейса с внешними сетями.
Агент-посредник представляет собой специализированного служебного агента, который отвечает за координацию взаимодействия агентов, их связь и кооперацию, а также за "невидимость" мета-агентов, связанных с ним. "Невидимость" агентов-посредников может быть реализована методами, описанными в соответствующем разделе выше. В некоторых случаях посредник обеспечивает хранение данных для других типов агентов, то есть предоставляет им функции "blackboard" для их взаимодействия. Посредники должны быть связаны между собой в некоторый кластер. В частном случае это может быть иерархическая структура.
Предположим, что посредники могут взаимодействовать друг с другом в определенной последовательности. Если мета-агент А выполняет план Р и ему необходим сервис S, то он обращается к агенту-посреднику F за сервисом. Агент-посредник F посылает сообщение другим агентам-посредникам о необходимости сервиса S. Каждый агент-посредник F' делает запрос своим мета-агентам на сервис S. Если F' получает отказ, то он передает запрос F на сервис S следующему агенту-посреднику F'' и т.д. Если F' получает положительный ответ от одного из своих мета-агентов, то он передает этот положительный ответ F. Пропускная способность такого канала может быть низкой, но первый шаг атаки не нуждается в скорости.
А.А. Грушо (Доктор физико-математических наук) Е.Е. Тимонина (кандидат физико-математических наук) Информационный бюллетень JET INFO
Безопасность определяется знанием возможных атак. Наиболее опасные атаки на распределенные системы — это распределенные атаки. Такие атаки могут осуществляться враждебными многоагентными системами. ВМАС может быть "невидимой" и интеллектуальной. Координация агентов в ВМАС также может быть "невидимой" и осуществляться с помощью скрытых каналов.
Эти условия могут удовлетворяться с помощью реализации модели невлияния, скрытых каналов и соответствующей организацией агентов противника.
А.А. Грушо (Доктор физико-математических наук) Е.Е. Тимонина (кандидат физико-математических наук) Информационный бюллетень JET INFO
[1] A.A. Грушо , Е.Е. Тимонина -- Модель невлияния для сети. -- Обозрение прикладной и промышленной математики, т. 7 (1), Москва: ТВП, 2000
[2] A.A. Грушо , Е.Е. Тимонина -- Двойственность многоуровневой политики безопасности. -- Тез. конф. "Методы и технические средства информационной безопасности", С.-Петербург, 2000
[3] A.A. Грушо , Е.Е. Тимонина , Э.А. Применко -- Анализ и синтез криптоалгоритмов. Курс лекций. -- Йошкар-Ола: изд-во Марийского филиала Московского открытого социального университета, 2000
[4] A.A. Грушо , Е.Е. Тимонина -- Языки в скрытых каналах. -- Труды XXX международной конференции "Информационные технологии в науке, образовании, телекоммуникации, бизнесе", Украина, 2003
[5] A.A. Грушо , Е.Е. Тимонина -- Оценка времени обучения агента для организации скрытого канала. -- Дискретная математика, Т. 15 (2), 2003
[6] A.A. Грушо , Е.Е. Тимонина -- Преодоление защиты от скрытого канала. -- Обозрение прикладной и промышленной математики, Т. 10 (3), Москва: ТВП, 2003
[7] А.А. Грушо , Е.Е. Тимонина -- Проблемы компьютерной безопасности. -- Сб. научных докладов "Информационные технологии в производстве, медицине, психологии и этике" Академии информационных управленческих технологий. — М.: Центр Управления Полетами, 2003
[8] А.А. Грушо , Е.Е. Тимонина -- Стохастические скрытые каналы. -- Материалы международн. семинара "Информатика и общество" I&S'04 (10-24 января). — Низкие Татры, 2004
[9] А.А. Грушо , Е.Е. Тимонина -- Нарушение безопасности систем с единой точкой входа. -- Материалы 8-ой международной конференции "Связь-2004", озеро Иссык-Куль, 22-29 августа, 2004, Новосибирск: ЗАО РИЦ Прайс Курьер, 2004
[10] А.А. Грушо , Е.Е. Тимонина -- Скрытые каналы с использованием HTML. -- Труды XXXII международной конференции и III международной конференции молодых ученых "Информационные технологии в науке, образовании, телекоммуникации и бизнесе.
А.А. Грушо (Доктор физико-математических наук)
Е.Е. Тимонина (кандидат физико-математических наук) Информационный бюллетень JET INFO
На практике можно разместить агента в ядре операционной системы таким образом, что он будет контролировать и модифицировать всю деятельность системы безопасности. Данная конструкция реализует метод "men-in-the-middle" [], она была выполнена в некоторых практических разработках. Программы такого типа можно найти в Интернете. Они называются руткиты.
Большинство реализаций современных руткитов могут прятать от пользователя файлы, папки и ключи реестра, скрывать запущенные программы, системные службы, драйверы и сетевые соединения. То есть злоумышленник имеет возможность создавать файлы и ключи реестра, запускать программы, работать с сетью, и эта активность не будет обнаружена пользователями, в том числе и администратором системы.
В настоящее время известно около двух десятков подобных проектов, в рамках которых разрабатываются способы маскировки файлов, работающих процессов, сеансов межсетевого взаимодействия и т.п. Приведем несколько примеров.
Hacker Defender является программным агентом, функционирующим на платформах Windows NT 4.0/2000/XP, а также на более поздних версиях систем на базе Windows NT. Основная идея данной программы состоит в перезаписи некоторых сегментов памяти во всех запущенных процессах. При этом описанные действия не должны оказывать влияния на стабильность работы системы или работающих процессов. Программа может быть абсолютно "невидима" для всех остальных процессов, в том числе и для средств защиты [, ]. Тем самым противник имеет возможность скрывать файлы, процессы, системные службы и драйверы, ключи реестра и их значения, открытые порты. Программа также осуществляет маскировку своих действий в памяти и прячет идентификаторы скрываемых процессов. Кроме того, этот агент инсталлирует скрытый "blackdoor", регистрируется как скрытый системный сервис и инсталлирует скрытый системный драйвер. Технология "blackdoor" позволяет внедрять редиректор (сетевое программное обеспечение, эмулирующее доступ прикладных программ к удаленной файловой системе как к локальной).
После запуска программы Hacker Defender перечисляет все доступные для нее процессы в системе, а затем пытается перехватить определенные вызовы API []. Перехват заключается в замене первых байт кода функции на безусловный переход к новому коду функции, предварительно сохраненному в адресном пространстве программы. Для этого выясняется адрес необходимой функции, затем в памяти программы отводится место под код нового варианта функции и ее первоначального кода, который сохраняется для дальнейшего использования. Таким образом, когда пользовательская программа вызывает функцию API, например, NtQuerySystemInformation, вызов передается функции предобработки данных. Затем может быть вызвана исходная функция, которая, в свою очередь, вернет результаты функции постобработки. Функция постобработки модифицирует данные, которые вернула исходная функция, например, удаляя некоторые записи.
Процесс перехвата вызовов API изображен на .
Рисунок 3. Процесс перехвата вызовов функции API
Получается, что программы, которые будут использовать перехваченные вызовы API, получат информацию не о реальном положении дел в системе, а уже обработанные агентом данные. Hacker Defender перехватывает функции запуска новых процессов, что позволяет агенту передавать нужный код через новые программы, запускаемые пользователем.
FU также является известным программным агентом, исходный код которого опубликован 03.09.2004. FU состоит из двух компонент: драйвера Windows 2000/XP (msdirectx.sys) и собственно исполняемого файла (fu.exe). Если драйвер успешно установлен, то противнику необходимо просто запустить файл fu.exe на исполнение. Заметим, что при этом противнику вовсе не нужно обладать какими-либо особыми правами, в том числе и правом запуска приложений. Данная программа непосредственно манипулирует объектами ядра операционной системы. FU модифицирует список PsActiveProcessList, содержащий список активных процессов, информацию из которого получает ZwQuerySystemInformation. При этом процесс остается существовать в качестве "свободного" потока и будет нормально функционировать, поскольку распределение процессорного времени Windows основано на потоках, а не на процессах.
FU позволяет нарушителю скрывать файлы, каталоги и процессы, а также изменять привилегии процесса, поднимая его до уровня администратора.
AFX Rootkit представляет собой программного агента, который функционирует на платформах Windows NT/2000/XP/2003. Текущая версия данной программы позволяет нарушителю скрывать процессы и их идентификаторы, файлы и директории, значения системного реестра, сервисы, сетевые соединения TCP/UDP, иконки в панели задач. При установке этого агента создается директория с уникальным именем, в которой противник сможет размещать необходимые ему данные, в том числе исполняемый файл (root.exe). Заметим, что данная директория абсолютно "невидима" другими процессами, файлами, библиотеками и т.д., однако все программы внутри директории не являются скрытыми друг от друга.
"Невидимый" агент может сделать другие файлы или процессы "невидимыми". Более того, "невидимый" процесс может решить проблему построения "невидимых" коммуникаций между агентами противника в рамках одного компьютера.
В работе [] мы доказали, что если есть сеть автоматов, каждый из которых удовлетворяет условию невлияния, и коммуникации на уровне High "невидимы" для механизмов безопасности, тогда сеть автоматов также удовлетворяет условию невлияния.
Мы считаем, что для общения между собой рабочие станции различных сегментов используют виртуальную частную сеть (VPN), которая работает на основе протокола IPSec следующим образом. Пакет от рабочей станции с адресом a в сегменте Si должен быть передан на рабочую станцию с адресом b в сегменте Sj. Пакет передается так:
от машины с адресом a к локальному шлюзу LG(i) в сегменте Si;далее пакет от LG(i) попадает на узел защиты G(i), в котором пакет шифруется и инкапсулируется в пакет (пакеты) с адресом отправителя si и адресом получателя sj, пакеты имеют одинаковую длину и другие одинаковые параметры;инкапсулированный пакет из G(i) попадает на хост глобальной сети PC(i), который направляет его через глобальную сеть на аналогичный хост PC(j);далее пакет направляется на узел защиты G(j), на выходе которого восстанавливается исходный пакет, посланный от a к b, этот пакет поступает на локальный шлюз LG (j);LG (j) отправляет пакет к абоненту b в сегменте Sj.
В глобальной сети и в каждом сегменте S0, S1 ,..., Sm имеются программно-аппаратные агенты противника, которые для выполнения враждебных функций должны получать инструкции от программно-аппаратного агента противника [] из глобальной сети (ПГС). Будем считать, что противник из глобальной сети через своих агентов полностью контролирует хосты PC(k), k = 0, 1, ..., m. Программно-аппаратные агенты внутри сегментов локальной сети S0, S1, ..., Sm контролируют соответственно компьютеры LG(j), j = 0, 1, ..., m. Мы считаем, что узлы защиты G(i) сделаны правильно так, что никто из злоумышленников не может их контролировать. Таким образом, управление программно-аппаратным агентом в любом из сегментов со стороны противника из глобальной сети связано с построением канала связи от PC(j) к LG(j). Утечка информации связана с построением канала от LG(j) к PC(j).
Ни один из хостов глобальной сети (в частности, каждая машина PC(j), j = 0, 1,..., m) не знает внутренние адреса сегментов. В силу того, что шифрование и формирование пакетов для отправки через глобальную сеть происходит на узлах защиты, противник не может построить канал взаимодействия с программно-аппаратным агентом сегмента, используя шифртекст или служебные атрибуты пакетов.
Таким образом, мы предполагаем, что единственными зависимыми параметрами, известными на PC(j) и LG(j) для входного потока пакетов, являются адреса отправителя пакетов. При передаче пакетов от LG(j) к PC(j) единственными зависимыми параметрами являются адреса их получателей. Эта зависимость связывает внутренние адреса каждого сегмента и внешний адрес s соответствующего шлюза.
Скрытый канал, не требующий обучения, строится следующим образом []. Возьмем часто встречающиеся адреса s1 и s2 из множества S = {s1, ..., sm}. Модулируем поток пакетов из PC(0) в G(0) следующим образом. Опишем, например, код для 1. При передаче 1 любой очередной пакет с исходящим адресом s1 передается после передачи нечетного числа пакетов с другими адресами. Поэтому все расстояния между пакетами с исходящими адресами s1 являются четными. Рассмотрим последовательность расстояний между исходящими адресами, полученными в LG(0). Все расстояния между адресами пакетов из сегмента S1 — четные (кроме ошибок вида потери или вставки пакета, которые мы считаем достаточно редкими). Агент в LG(0), обладая достаточными вычислительными ресурсами и памятью, считает четность или нечетность расстояний между повторяющимися адресами и выявляет отклонение четных расстояний от случайного распределения длин расстояний между повторяющимися адресами из S1. Аналогично, пакет с исходящим адресом s2 передается через нечетное число пакетов с другими адресами. Таким образом, преобладание четных расстояний между адресами из S1 и четных расстояний между адресами из S2 определяет 1 в коде.
Аналогично строится код для передачи 0 и x, означающий конец передачи кода 1 или 0.
Пропускная способность данного канала однозначно связана с другим параметром, связанным с данным способом скрытой передачи информации. Это число N переданных пакетов для восстановления одного бита переданной информации. Полученные асимптотические оценки показывают, что вероятность правильно принять сигнал 1 или 0 или x агентом в LG(0) стремится к 1 при N стремящемся к бесконечности.
Пусть адреса упорядочены s1 < s2 < ... < sm. Рассмотрим другой метод общения агентов. Этот метод требует обучения. Процедура обучения необходима для того, чтобы максимально полно восстановить на LG(0) порядок.
Процедура обучения состоит в следующем. РС(0) получив очередные k пакетов с адресами si1, si2, ..., sik, упорядочивает их в соответствии с возрастанием и посылает данные пакеты на узел защиты для последующей передачи LG(0). Мы доказали [], что LG(0) в реальном масштабе времени может проводить сопоставление полученных данных и восстанавливать порядок. Тогда можно передавать информацию упорядоченными k-группами адресов, переставляя их на РС(0) в нужном порядке..
Пример скрытого канала по времени, который также преодолевает IPSec, исследован в []. В данном случае для скрытой передачи информации используется задержка между передачей последовательных пакетов в потоке. В указанной работе рассмотрены четыре различных модели потока (с дискретным временем и дискретным (пакетным) трафиком, с непрерывным временем и дискретным трафиком, с непрерывным трафиком и временем, а также непрерывные трафик и время с ограничением скорости передачи). В рамках каждой из моделей для трех алгоритмов подавления (задерживающих пакеты с ограничением числа задерживаемых пакетов, величины задержки, значения средней скорости передачи) оценена зависимость пропускной способности скрытого канала от параметров алгоритма подавления. Следует отметить, что ни один из рассмотренных алгоритмов не способен полностью перекрыть скрытый канал, а может лишь снизить его пропускную способность.
При использовании задержек между пакетами в качестве "контейнера" для скрытой передачи может применяться не весь поток ТСР-пакетов, а лишь серия пакетов, отправляемых подряд без подтверждения.
Возможны и другие каналы преодоления IPSec, но они более уязвимы к уничтожению. Например, можно модулировать передачу длинами пакетов, если IPSec не производит выравнивания длин пакетов.
Рассмотрим скрытые каналы, преодолевающие PROXY-серверы [].
Прежде, чем подробно объяснить механизмы преодоления защиты, опишем общую идею. PROXY-сервер, в отличие от IPSec, устанавливает ТСР-соединения с непосредственно связанными с ним абонентами. При этом данные, передаваемые пакетами, собираются на PROXY-сервере, а затем передаются при образовании ТСР-соединения с таким же сервером на приемном конце. Сложность преодоления надежно защищенного PROXY-сервера состоит в том, что враждебный агент может манипулировать или наблюдать манипуляции с пакетами, а не с данными. Однако в основе преодоления PROXY-сервера лежит простая идея управления порядком данных с помощью задержек пакетов, передающих эти данные. Более подробно рассмотрим следующую модель.
Пусть, как и раньше, имеется m+1 сегментов локальных вычислительных сетей S0, S1, ..., Sm, в каждом из которых имеются рабочие станции со своими локальными адресами и шлюзы, используемые для соединения локальных сетей с глобальной сетью (например, Интернет). Пусть s0< s1 m упорядоченные адреса шлюзов сегментов локальных вычислительных сетей S0, S1, ..., Sm, представляющих эти сегменты в глобальной сети. Мы считаем, что для общения между собой рабочие станции различных сегментов используют виртуальную частную сеть (VPN), которая работает следующим образом. Данные от рабочей станции с адресом a в сегменте Si должны быть переданы на рабочую станцию с адресом b в сегменте Sj. Схема связи изображена на , а связь организуется следующим образом.
От машины с адресом a пакеты с передаваемыми данными, посылаются к внутреннему шлюзу — машине LG(i) в сегменте Si.Далее пакеты попадают на шлюз — узел защиты G(i). Он работает как PROXY-сервер, который устанавливает соединение с машиной с адресом а и восстанавливает данные, передаваемые от рабочей станции с адресом а на рабочую станцию с адресом b. Восстановленные данные, поступающие на PROXY-сервер от абонентов сегмента Si, выстраиваются в очередь в соответствии с порядком их восстановления на PROXY-сервере. Далее PROXY-сервер шифрует данные в очереди на ключе получателя — PROXY-сервера G(j), в сегменте которого находится получатель данных.
После этого G(i) устанавливает соединение с G(j) и передает туда пакеты, содержащие зашифрованные данные.Пакет из G(i) попадает на хост глобальной сети PC(i), который направляет его через глобальную сеть на аналогичный хост PC(j).Далее пакет направляется на узел защиты G(j), где восстанавливаются и выстраиваются в очередь данные, передаваемые на Sj. При подходе соответствующих данных в этой очереди PROXY-сервер УЗ(j) расшифровывает их и устанавливает соединение в сегменте Sj с рабочей станцией с адресом b. Данные передаются пакетами через внутренний шлюз LG(j).LG(j) отправляет пакеты к абоненту b в сегменте Sj.
Как и раньше, в глобальной сети и в каждом сегменте S0, S1, ..., Sm имеются программно-аппаратные агенты противника, которые для выполнения своих враждебных функций должны получать инструкции от программно-аппаратного агента противника из глобальной сети (ПГС). Будем считать, что ПГС полностью контролирует компьютеры PC(j), j = 0, 1, ..., m. Программно-аппаратные агенты противника внутри сегментов локальной сети S0, S1, ..., Sm контролируют соответственно компьютеры соответственно LG(j), j = 0, 1, ..., m. Мы считаем, что узлы защиты G(i) сделаны правильно так, что никто из противников не может их контролировать. Таким образом, управление программно-аппаратным агентом в любом из сегментов со стороны противника из глобальной сети связано с построением канала связи от PC(j) к LG(j). Утечка информации связана с построением канала от LG(j) к PC(j).
Как и раньше мы предполагаем, что единственными зависимыми параметрами, известными на PC(j) и LG(j) для входного потока пакетов, являются адреса отправителя пакетов. При передаче пакетов от LG(j) к PC(j) единственными зависимыми параметрами являются адреса получателей пакетов. Эта зависимость выражается в связи множества внутренних адресов каждого сегмента и внешнего адреса s соответствующего шлюза и считается в данной задаче известной.
LG(i) может влиять на порядок очереди отправляемых данных следующим образом.
Протокол ТСР гарантирует восстановление данных. Если какой-то пакет не получен, то протокол ТСР передает запрос на получение пропущенных данных. Пусть на PROXY-сервере установлено два соединения с абонентами сегмента а1 и а2, которые передают данные А1 и А2 соответственно на PROXY-сервер G(i). Естественно, что те данные, которые восстановлены первыми, будут первыми поставлены в очередь на передачу в глобальную сеть. Пусть агент в LG(i) хочет, чтобы последовательность данных в очереди на отправку была: А1 А2. Если пакеты, передающие А1, заканчиваются быстрее, чем пакеты, передающие А2 (агент наблюдает поток пакетов и может осуществлять их задержку, чтобы убедиться в том, что передача данных закончена), то агент не предпринимает никаких действий. Если пакеты, передающие А2, заканчиваются быстрее, чем пакеты, передающие А1, то агент на LG(i) задерживает или уничтожает один из пакетов (например, последний) из серии пакетов, передаваемых от а2. После этого он выжидает, когда закончится поток пакетов, передающих файл А1, и посылает последний пакет с данными А2. Тогда, если верно его предположение о том, что серия пакетов от а1 одному абоненту в другом сегменте содержала данные одного соединения А1, а аналогичная серия от а2 одному абоненту в другом сегменте содержала данные другого соединения А2, то указанная процедура поменяет естественный порядок данных в очереди на G(i) на требуемый порядок данных. Разумеется, такая же процедура перестановки на узле G(j) возможна и на потоке входящих данных с помощью агента на PC(j). Отметим, что указанная процедура носит вероятностный характер. Ясно, что вероятность правильной перестановки увеличивается для больших серий пакетов, передаваемых при отправке больших файлов.
Несмотря на возможность ошибки, можно построить язык скрытой передачи данных, использующий данный алгоритм перестановки данных в очереди. Пусть агент в LG(0) передает информацию агенту в РС(0) в глобальной сети. Тогда агент в LG(0) знает, какие данные идут на адрес получателя sj, j = 1, ..., m, серверов G(j).
С помощью алгоритма перестановки данных в очереди агент в LG(0) упорядочивает очередные пары пришедших данных.
Блоки полученной последовательности данных разбиваются на пакеты. Серии этих пакетов передаются по соответствующим адресам. В серии пакетов могут вкрапливаться отдельные пакеты, связанные, например, с установлением других соединений. Поэтому агент в РС(0) не должен учитывать эти вкрапления. Полученные таким образом серии однозначно соответствуют переданной единице. Передача нуля осуществляется последовательностью непересекающихся монотонно убывающих пар адресов. Последовательность с непересекающимися чередующимися возрастающими и убывающими парами адресов однозначно определяет символ х, соответствующий разделительному символу. При этом мы предполагаем, что PROXY-сервер последовательно устанавливает соединения с другими PROXY-серверами в соответствии с получившейся в буфере очередью данных. При этом данные, передаваемые по одному адресу, передаются в одном соединении.
В связи с описанными скрытыми каналами решена [] задача оценки r для устойчивого выделения 1, 0 и х, а также устойчивости передачи к сбоям.
В модели потока, создаваемого протоколом ТСР, для создания скрытого канала могут быть использованы задержки подтверждения. Отправив один или несколько пакетов с данными, узел ожидает подтверждения их получения, и лишь затем продолжает передачу. Число пакетов, которые могут быть переданы подряд без ожидания подтверждения, определяется размером "окна" принимающей стороны (этот параметр используется для управления скоростью передачи и задает объем данных, которые получатель способен принять, не прерывая передачу []). Таким образом, в Интернете задержки между пакетами, отправленными подряд, определяются параметрами канала передачи пакетов.
Задержки же между пакетами, перед отправкой которых узел ожидал подтверждения поставки предыдущих пакетов, в большей степени определяются скоростью обработки пакетов узлами, а также особенностями протокола уровня приложений (задержка отправки пакетов может быть вызвана ожиданием какого-либо события приложением).
Поэтому возможна манипуляция ПГС задержками подтверждений, которая может быть использована в статистическом [] скрытом канале низкой пропускной способности.
Для построения скрытого канала возможно использование модуляции скорости передачи информации через Интернет. Как и в предыдущем случае, такой скрытый канал преодолевает IPSec.
В связи с тем, что пропускная способность каналов Интернет не безгранична, а число пользователей сети неуклонно растет, поставщиками услуг Интернета повсеместно применяются ограничения пропускной способности предоставляемых пользователям каналов связи. Поскольку при этом обычно абонент соединен с оператором скоростной линией связи (например, локальной сетью), ограничение скорости передачи производится искусственно, программными средствами шлюза. Как правило, алгоритм ограничения скорости основан на следующей схеме: поступающие по "быстрому" каналу на шлюз пакеты помещаются в буфер, а затем постепенно отправляются по "медленному" каналу. При этом фактически пропускная способность "медленного" канала может быть выше заданного ограничения. Задержки при отправке пакетов, помещенных в буфер, выбираются таким образом, чтобы средняя скорость передачи соответствовала установленным ограничениям.
Чаще всего наибольшая нагрузка на канал связи возникает при последовательной передаче больших объемов данных. При этом для ускорения передачи протокол ТСР формирует пакеты определенной длины (как правило, 1500 байт) и полностью использует приемное "окно" получателя. В потоке возникают серии пакетов, отправленных с минимальными (для физического канала) интервалами. После обработки алгоритмом ограничения скорости эти интервалы увеличиваются для обеспечения заданной средней скорости. Изменение скорости передачи [] происходит за счет манипуляции интервалами между пакетами. Тогда шлюз, через который проходят пакеты, имеет возможность встраивать в поток пакетов скрытую информацию с помощью манипуляции скоростями. Для того чтобы интервалы между пакетами, определяющие скорость передачи, не изменились на маршруте от данного шлюза до получателя, серия пакетов не должна полностью помещаться в буфер ни на одном из шлюзов на этом маршруте.
В противном случае скрытая информация, содержащаяся в потоке, окажется искаженной.
Во избежание искажения интервалов для прохождения медленного канала при модуляции необходимо выбирать интервалы таким образом, чтобы они были не короче интервалов, соответствующих самому медленному каналу на маршруте. Оценка скорости самого медленного канала может быть произведена путем измерения средней скорости передачи.
Опишем способ скрытой передачи информации агенту, контролирующему единую точку входа [].
Рассмотрим схему аутентификации пользователя, обращающегося по протоколу LDAP на сервер директорий. Предположим, что там есть программно-аппаратный агент нарушителя безопасности, который знает, как работает справочная служба, но не имеет предметно-ориентированной информации и знаний по использованию своих возможностей. Можем считать, что потенциал такого агента сравним с возможностями администратора сервера в том случае, если он обладает предметно-ориентированной информацией и имеет конкретное задание по администрированию информации на сервере.
Пусть сервер аутентификации обслуживает большую распределенную сеть с большим числом пользователей и разграниченными правами доступа к ресурсам системы. Для того чтобы войти в сеть и получить права доступа к определенным ресурсам, пользователь посылает на сервер аутентификации пароль, передается по транспортной сети в шифрованном виде, причем система шифрования не зависит от идентификатора пользователя. Пусть нарушитель безопасности является легальным пользователем систем. Он может подключиться к сети на своем компьютере в случае успешной аутентификации на сервере и хочет получить доступ к запрещенным для него ресурсам системы. Права доступа к ресурсам для любого пользователя записаны в дереве директорий сервера аутентификации. Если злоумышленник пытается получить доступ к запрещенным для него ресурсам, это отражается в данных аудита.
Для решения задач нарушителя безопасности самым простым способом является передача специального пароля, известного его программно-аппаратному агенту на сервере аутентификации, с запросом необходимых для него запрещенных прав к ресурсам системы.
В этом случае программно- аппаратный агент дает права пользователю на требуемые ресурсы и может очистить данные аудита на сервере идентификации/аутентификации. Однако, имея распределенную систему аудита, доступ к запрещенной для этого пользователя информации будет отражен в других системах аудита, например, в данных аудита СУБД. При правильно работающей системе анализа данных аудита служба безопасности получит информацию о том, что данный пользователь с данной рабочей станции получил ценную информацию. Поэтому, войдя на рабочую станцию от своего имени, нарушитель безопасности должен обращаться со специальным паролем к агенту на сервере аутентификации, называя вымышленный идентификатор, то есть от чужого имени.
Таким образом, приходим к задаче создания в системе с помощью программно-аппаратного агента на сервере аутентификации ложного пользователя с большими правами по доступу к ресурсам системы. При наличии специального пароля, известного программно-аппаратному агенту, эта задача легко решается. Чтобы предотвратить такую угрозу, между системой приема сообщений от пользователя и сервером аутентификации установим узел защиты, который шифрует истинные значения идентификаторов и паролей. Пусть в дереве директорий в качестве имен используются шифртексты идентификаторов. Тогда программно-аппаратный агент не сможет получить специальный пароль от нарушителя безопасности и приписать ему особые права.
Однако эта защита может быть преодолена следующим образом. Нарушитель безопасности посылает любой настоящий идентификатор и случайный пароль к нему. После шифрования на узле защиты в дереве пользователей идентифицируется некоторый пользователь по присланному идентификатору. Естественно, присланный пароль этого пользователя отличается от истинного пароля. Выявляя этот факт, программно-аппаратный агент принимает решение о создании нового пользователя, который является листом в дереве директории для истинного пользователя, а его идентификатор соответствует присланному паролю, зашифрованному узлом защиты.
После этого он посылает на компьютер нарушителя безопасности сигнал о неправильной аутентификации полученного идентификатора пользователя. Получив этот сигнал, нарушитель безопасности посылает на сервер аутентификации идентификатор, в котором присутствует выбранное до того имя легального пользователя, дополненное переданным ранее паролем. Для данного пользователя он выдумывает специальный пароль и передает его для аутентификации ложного пользователя. Агент нарушителя находит имя ложного пользователя, созданного им на предыдущем шаге, и в качестве аутентификатора записывает шифртекст переданного пароля. Затем он посылает сигнал о правильной аутентификации, приписывает данному пользователю максимальные права, стирает данные аудита о создании нового пользователя и о присвоении ему прав, временно заканчивает свое функционирование и маскирует свое присутствие.
Потом в системе появляется ложный пользователь с большими правами. Доступ происходит по легальной процедуре идентификации и аутентификации с любой машины сети. Ложный пользователь может существовать столько времени, сколько потребуется службе безопасности на выяснение по другим данным аудита или определение по другим косвенным данным наличия в сети дополнительного получателя ценной информации. В случае контроля директории ложный пользователь может быть обнаружен в дереве директорий и уничтожен. Тогда процедура создания нового ложного пользователя должна повториться.
В случае ошибки, когда ложный пользователь создается случайно (входящий пользователь неправильно называет свой пароль), доступ к этому пользователю никто не будет иметь, и он останется незаметным. Если процедура образования ложного пользователя не завершена, агент через некоторое время его уничтожит.
Интеллектуальный программно-аппаратный агент нарушителя на сервере аутентификации может быть настроен на получение инструкций через скрытый канал. Допустим, нарушителем безопасности является группа k легальных пользователей системы, которые знают фиксированное число m, известное также программно-аппаратному агенту.
Нарушители безопасности инициируют вход в систему и выход из нее так, чтобы иметь возможность первыми из пользователей за ограниченное время набрать по m вхождений в систему.
Пусть агент обладает достаточными вычислительными возможностями для оценки промежутка времени, необходимого для m вхождений в систему любых других пользователей. Если это время не превосходит заданного порога, то агент выделяет данную группу пользователей как своего союзника. После m вхождений и выходов из системы группа нарушителей продолжает работать в обычном режиме и при этом начинается выработка языка общения агента с группой нарушителей. Если в заданном промежутке группа нарушителей вошла в систему ровно один раз, то их перестановке (порядки появления на сервере) соответствует двоичный вектор длины k. Этот вектор передается агентом к членам группы нарушителей в форме ответов о правильной или неправильной аутентификации. Достаточно сделать первую посылку вектора из всех 0 в ответ на заведомо ложные пароли, так как все двоичные вектора можно считать лексикографически упорядоченными. Тогда 2k перестановок порядка вхождения в систему данной группы воссоздадут у агента и членов группы нарушителей код, который можно использовать при дальнейшем общении агента и группы нарушителей. Любая другая комбинация вхождений в систему уже не будет считаться у агента значимой.
Рассмотрим скрытый канал через Интернет с помощью HTML []. В данном случае речь пойдет о задаче построения скрытого канала между далеко расположенными корреспондентами.
Пусть пользователь А хочет передать короткое сообщение пользователю B через Интернет. Предположим, что пользователь А имеет доступ к браузеру, а пользователь B имеет доступ к аудиту обращений на некоторую страницу Интернет. Все обращения пользователя А к информационным ресурсам Сети отслеживаются контролером U. Задача состоит в том, чтобы построить скрытый от U канал передачи информации от пользователя А к пользователю B.
В литературе описано множество скрытых каналов для решения этой задачи.
Однако доказать стойкость сокрытия факта передачи от контролера U эти методы не позволяют. Предлагаемый здесь метод позволяет доказывать такую стойкость для небольших сообщений. Однако ограниченные рамки статьи не позволяют привести это доказательство.
Изложим содержание метода. С помощью последовательности гипертекстовых ссылок пользователь А попадает на сайт, к которому имеет доступ абонент В, и выбирает оговоренный секретным ключом документ. Пусть R1, ..., RN — последовательность возможных гипертекстовых ссылок в этом документе. Тогда скрытое сообщение от пользователя А к пользователю В можно закодировать перестановкой вызовов этих гиперссылок Rj1, ..., RjN. Перестановка определяется с помощью вызовов и меток времени, находящихся в журнале аудита.
Если B1, ..., BN сайты, в которых абонент В может получить доступ к данным аудита, то перестановками Bi1, ..., BiN можно кодировать допустимые сообщения.
Пусть вместо пользователя В на сервере находится программно-аппаратный агент В1, связанный с пользователем В, который отслеживает порядок вызова гиперссылок в определенном тексте. Тогда построенная этим агентом перестановка может быть передана пользователю В, который может находиться где угодно и может общаться со своим агентом с помощью произвольного скрытого канала. Такое взаимодействие возможно с помощью протокола HTTP. Маршрут передачи информации может быть еще более сложным для создания неотслеживаемости взаимодействия пользователей А и В.
Возникает вопрос о способе кодирования сообщения с помощью перестановок. Один из вариантов кодирования можно построить следующим образом. Рассматривая некоторую нумерацию перестановок, относим номеру данной перестановки двоичное представление этого номера. Тогда сообщение можно писать на любом доступном языке, используя для его кодирования двоичные векторы. Использование данного метода ограничено вычислительными возможностями при нумерации перестановок. Приведем некоторые значения числа перестановок, показывающие возможности кодирования сообщений для различных N: 5! = 120, а 10! = 3628800.
Все мета- агенты связаны между собой через агентов-посредников. Каждый мета-агент имеет своего агента-посредника для взаимодействия в ВМАС. Мета-агенты исполняют роль ассистентов посредников при координации деятельности всех агентов. Мета-агенты могут быть сделаны "невидимыми" с помощью своих агентов-посредников. Агент-посредник и мета-агент могут играть роль "men-in-the-middle" в легальном протоколе. Это путь контроля и модификации любого легального протокола внутри одного компьютера.
Агенты-посредники и агенты интерфейса играют роль "men-in-the-middle" в легальных протоколах связи. Основная проблема здесь — сделать их быстро работающими. Агенты интерфейса могут связываться друг с другом с помощью скрытых каналов, если они находятся в различных сегментах сети под охраной своих агентов-посредников.
Мета-агенты могут создаваться и могут уничтожаться. Коды агентов могут передаваться через агентов-посредников или агентов интерфейса.
Рассмотрим, каким образом ВМАС работает в распределенной атаке.
Мета-агенты используют методы распознавания для сканирования окружающей среды. Они находят точки для модификации информации и для выстраивания "men-in-the-middle". Мета-агенты могут иметь информацию о выполнении атаки или могут ее не иметь. В последнем случае они должны найти сервис в форме, содержащей план, что делать дальше. План атаки может передаваться по сети.
Когда каждый агент, являющийся участником атаки, имеет свой план, тогда первый шаг атаки закончен. Низкая пропускная способность скрытых каналов определяет слабую синхронизацию распределенной атаки. Поэтому агент противника проходит активную фазу атаки почти автономно.
Если распределенная система разрушается, то это приводит к ущербу, но в таком случае и ВМАС также разрушается. После восстановления распределенной системы ВМАС должна создаваться с самого начала. Поэтому противник должен предпочесть нанесение ущерба с помощью ошибочных вычислений или Византийского поведения [].
Рассмотрим пример. На первом шаге ВМАС находит точки доставки данных приложениям. Тогда мета-агенты готовят планы модификации входных или выходных данных для выбранных приложений. Планы могут также содержать генератор случайных чисел для выбора момента модификации данных. Реализация атаки состоит в случайной модификации входных или выходных данных с помощью "невидимого" агента противника. Распределенная система делает ошибки, но все тесты приложений и связи не находят сбоев. Медленное изменение интенсивности ошибок может привести к разрушению отдельных приложений.
IT+S&E'2005", Украина, 2005
[11] А.В. Гусев -- Скрытый канал с модуляцией скорости передачи. -- Труды XXXII международной конференции и III международной конференции молодых ученых "Информационные технологии в науке, образовании, телекоммуникации и бизнесе. IT+S&E'2005", Украина, 2005
[12] Г. Неббет -- Справочник по базовым функциям API Windows NT/2000. -- Пер. с англ. — М.: Издательский дом "Вильямс", 2002
[13] Е.Е. Тимонина -- Скрытые каналы (обзор). -- Jet Info: изд-во компании "Джет Инфо Паблишен" — 14(114)., 2004
[14] COUGAAR Architecture Document. -- A BBN Technologies Document, Version for Cougaar 11.4, 2004
[15] A. Galatenko , А. Grusho , А. Kniazev , Е. Timonina -- Covert Channels through PROXY Server. -- The Third International Workshop "Information Assurance in Computer Networks. Methods, Models, and Architectures for Network Security", St. Petersburg: Springer, LNCS 3685, 2005 (to be printed)
[16] J. В. Giles , B. Hajek -- An Information-theoretic and Game-theoretic Study of Timing Cannels. -- IEEE Transactions on Information Theory, 2002
[17] J.A. Goguen , J. Meseguer -- Security Policies and Security Models. -- Proceedings of the IEEE Symposium on Security and Privacy, Oakland, CA, 1982
[18] J.A. Goguen , J. Meseguer -- Inference Control and Unwinding. -- Proceedings of the IEEE Symposium on Security and Privacy, Oakland, CA, 1984
[19] A.A. Grusho , E.E. Timonina -- Construction of the Covert Channels. -- International Workshop "Information Assurance in Computer Networks. Methods, Models, and Architectures for Network Security", St. Petersburg: Springer, LNCS 2776, 2003
[20] A Guide to Understanding Covert Channel Analysis of Trusted Systems. -- National Computer Security Center, NCSC-TG-030, Ver. 1, 1993
[21] L. Gumnopoulos , S. Dritsas , S. Gritzalis , C. Lambrinoudakis -- GRID Security Review. -- International Workshop "Information Assurance in Computer Networks. Methods, Models, and Architectures for Network Security", St.
Petersburg: Springer, LNCS 2776, 2003
[22] J. Hеrard -- Validation of Communication in Safety--Critical Control Systems. -- Nordtest Report TR 543, 2003
[23] D.L. Martin , A.J. Cheyer , D.B. Moran -- The Open Agent Architecture: A Framework for Building Distributed Software Systems. -- Artifical Intelligence Center SRI International, 1998
[24] J. McLean , C. Heitmeyer -- High Assurance Computer Systems: A Research Agenda. -- Center for High Assurance Computer Systems Naval Research Laboratory, Washington, DC 20375, 1995
[25] I.S. Moskowitz , O.L. Costich -- A classical Automata Approach to Noninterference Type Problems. -- Procced. Of the Computer Security Foundations Workshop 5, Franconi, NH: IEEE Press, 1992
[26] RFC 793. Transmission Control Protocol, 1981
[27] J. Rushby -- Noninterference, Transitivity, and Channel-Control Security Policies. -- Technical Report CSL-92-02, 1992
[28] H. Father -- Hooking Windows API. -- Techniques of hooking API functions on Windows, 2002
[29] H. Father -- Invisibility on NT boxes. How to become unseen on Windows NT., 2003
[30] Foundation for Intelligent Physical Agents -- Standard: FIPA TC Communications, 2002
Информационная безопасность
Эффективность защиты информации
07.08.2003
Обеспечение защиты информации на практике происходит в условиях случайного воздействия самых разных факторов. Некоторые из них систематизированы в стандартах, некоторые заранее неизвестны и способны снизить эффективность или даже скомпрометировать предусмотренные меры. Оценка эффективности защиты должна обязательно учитывать как объективные обстоятельства, так и вероятностные факторы.

Факторы, влияющие на уровень защиты информации, систематизированы в ГОСТ Р 51275-99. Однако, независимо от воли и предвидения разработчиков возникают и иные, заранее неизвестные при проектировании систем защиты информации (СЗИ) обстоятельства, способные снизить эффективность защиты или полностью скомпрометировать предусмотренные проектом меры информационной безопасности. Оценка эффективности защиты информации должна обязательно учитывать эти объективные обстоятельства, а ее характеристики, как это следует из ГОСТ Р 50922-96, должны иметь вероятностный характер. Развитие подобной методологии, включая систему нормативных документов, содержащих количественные, измеримые показатели эффективности СЗИ, обеспечит интересы как заказчиков, так и проектировщиков. Особую важность приобретает обоснование оптимальных значений показателей эффективности, учитывающее целевое предназначение информационной системы.
Для решения рассматриваемой проблемы предлагается использовать системный подход. Как отмечали авторы [8], «сама идея количественного определения эффективности с полным правом может рассматриваться как поворотный пункт истории науки».
Экономический аспект
Массовое создание, внедрение и эксплуатация информационных систем привели к возникновению спектра новых проблем в сфере безопасности личности, общества и государства. Внимание к этим проблемам закономерно. Если коммерческая организация допускает утечку более 20% важной внутренней информации, то она в 60 случаях из 100 банкротится [17]. Утверждают также [11], 93% компаний, лишившихся доступа к собственной информации на срок более 10 дней, покинули бизнес, причем половина из них заявила о своей несостоятельности немедленно.
Потребность в обеспечении безопасности связана с тем, что существует множество субъектов и структур, весьма заинтересованных в чужой информации и готовых заплатить за это высокую цену. Так, стоимость устройств подслушивания, продаваемых только в США, составляет в среднем около 900 млн. долл. в год. Суммарный урон, нанесенный организациям, против которых осуществлялось прослушивание, составляет ежегодно в США около 8 млрд. долл. А ведь существуют и, соответственно, приобретаются устройства для несанкционированного доступа к информации и по другим каналам: проникновение в информационные системы, перехват и дешифровка сообщений и т.д. В результате, по данным SANS Institute, средний размер убытка от одной атаки в США на корпоративную систему для банковского и ИТ-секторов экономики составляет около полумиллиона долларов [19]. Примерная структура последствий неэффективного обеспечения информационной безопасности в американских организациях такова [18]: кража конфиденциальной информации — 20-25% от общего годового ущерба; фальсификация финансовой информации — 21-25%; заражение вредоносными программами — 11-12%; нарушение доступа к Web-сайтам — 1-11%; срыв работы информационной системы — 4-10%; незаконный доступ сотрудников к информации — 4-9%; другие виды ущерба — 14-33%.
В таких условиях все более широко распространяется мнение, что защита информации должна по своим характеристикам быть соразмерной масштабам угроз [1, 2, 16]. Отклонение от этого правила чревато дополнительным ущербом. Скажем, если уровень защищенности информационной системы превышает уровень C2 по «Оранжевой книге», то ее подсистема защиты потребляет значительную часть общих ресурсов (для систем уровня B1 эта доля составляет 20-50%, а для уровня B2 она может превышать 90%) [16]. Для каждой системы имеется оптимальный уровень защищенности, который и нужно поддерживать [2].
Качество и его подтверждение
Зачастую заказчик СЗИ плохо представляет себе значение того или иного средства и его вклад в общий уровень безопасности и в результате происходит увеличение затрат при практической неопределенности достигнутого эффекта. Как следствие, далеко не всегда заказчик СЗИ получает то, что ему реально нужно, и не может объективно проверить и оценить качество и эффективность предложенного решения [13].
Средства защиты информации в соответствии с действующими нормами и правилами подлежат обязательной или добровольной сертификации. Однако сертификация не является совершенным инструментом и не дает необходимых гарантий. В лучшем случае проверяется только 85% всех возможных состояний, а обычно — 60-70% [14].
В [20] указывается, что сертификация продукции на соответствие требованиям государственных стандартов по безопасности информации или иных нормативных документов, утвержденных Гостехкомиссией РФ, подтверждается с определенной степенью достоверности. Однако чему конкретно должна быть равна эта достоверность, является ли этот термин эквивалентным вероятностно-статистическому пониманию, не говорится. Между тем, на испытательные центры (лаборатории), проводящие испытания образцов сертифицируемой продукции и участвующие в предварительной проверке ее производства, прямо возложена ответственность за достоверность результатов. При таком положении дел нормативное требование обеспечения достоверности результатов испытаний отдельных средств и, тем более всей СЗИ, остается пустой декларацией. Таким образом, даже если элементы СЗИ формально успешно прошли все сертификационные испытания и имеют полный комплект удостоверяющих документов, это отнюдь не означает того, что реально будет обеспечен требуемый уровень качества.
Количественная оценка гарантий защиты
В современных нормативных документах по информационной безопасности, используется, как известно, классификационный подход. Гораздо более конструктивными являются вероятностные методы, нашедшие широкое распространение в практике обеспечения безопасности в других прикладных областях. В соответствии с этими методами уровни гарантий безопасности СЗИ трансформируются в доверительные вероятности соответствующих оценок показателей. Для решения данной задачи можно рекомендовать теорию статистических решений [8, 16], позволяющую находить оптимальные уровни гарантий безопасности.
Во-первых, оценка оптимального уровня гарантий безопасности в определяющей степени зависит от ущерба, связанного с ошибкой в выборе конкретного значения показателя эффективности. Во-вторых, для получения численных оценок риска необходимо знать распределения ряда случайных величин. Это, конечно, в определенной степени ограничивает количественное исследование уровней гарантий безопасности, предоставляемых СЗИ, но, тем не менее, во многих практических случаях такие оценки можно получить, например, с помощью имитационного моделирования или по результатам активного аудита СЗИ.
Обобщенные данные о возможных показателях эффективности приведены в таблице 1, а критериев — в таблице 2.
Количественная оценка эффективности
В соответствии с современной теорией оценки эффективности систем [15], качество любого объекта, в том числе и СЗИ, проявляется лишь в процессе его использования по назначению (целевое функционирование), поэтому наиболее объективным является оценивание по эффективности применения.
Проектирование, организация и применение СЗИ фактически связаны с неизвестными событиями в будущем и поэтому всегда содержат элементы неопределенности. Кроме того, присутствуют и другие причины неоднозначности, такие как недостаточно полная информация для принятия управленческих решений или социально-психологические факторы. Поэтому, например, этапу проектирования СЗИ естественным образом сопутствует значительная неопределенность. По мере реализации проекта ее уровень снижается, но никогда эффективность СЗИ не может быть адекватно выражена и описана детерминированными показателями. Процедуры испытаний, сертификации или лицензирования не устраняют полностью неопределенность свойств СЗИ или ее отдельных элементов и не учитывают случайный характер атак. Поэтому объективной характеристикой качества СЗИ — степенью ее приспособленности к достижению требуемого уровня безопасности в условиях реального воздействия случайных факторов, может служить только вероятность, характеризующая степень возможностей конкретной СЗИ при заданном комплексе условий. В общей теории систем такая характеристика называется вероятностью достижения цели операции или вероятностью выполнения задачи системой. Данная вероятность должна быть положена в основу комплекса показателей и критериев оценки эффективности СЗИ. При этом критериями оценки служат понятия пригодности и оптимальности. Пригодность означает выполнение всех установленных к СЗИ требований, а оптимальность — достижение одной из характеристик экстремального значения при соблюдении ограничений и условий на другие свойства системы. При выборе конкретного критерия необходимо его согласование с целью, возлагаемой на СЗИ.
Обычно при синтезе системы возникает проблема решения задачи с многокритериальным показателем. Некоторые авторы рассматривают показатели эффективности, которые предназначены при решении задачи сравнения различных структур СЗИ. Предлагается также использовать показатели эффективности вероятностно-временного характера, имеющие смысл функций распределения. В частности, к ним относятся вероятность преодоления системы защиты информации за некоторое время [6].
Методическое обеспечение
Нормативные документы по оценке безопасности ИТ практически не содержат конкретных методик, в результате чего величина разрыва между общими декларациями и конкретным инструментарием по реализации и контролю их положений является недопустимой. Исходя же из своего предназначения, методическая база должна охватывать все критически важные аспекты обеспечения и проверки выполнения требований, предъявляемых к информационной безопасности. Объективным видом оценки эффективности СЗИ является функциональное тестирование, предназначенное для проверки фактической работоспособности реализованных механизмов безопасности и их соответствия предъявленным требованиям, а также обеспечивающее получение статистических данных. В силу того, что средства безопасности обладают ограниченными возможностями по противодействию угрозам, всегда существует вероятность нарушения защиты, даже если во время тестирования механизмы безопасности не были обойдены или блокированы. Для оценки этой вероятности должны проводиться дополнительные исследования. В методическом плане определение эффективности СЗИ должно заключаться в выработке суждения относительно пригодности способа действий персонала или приспособленности технических средств к достижению цели защиты информации на основе измерения соответствующих показателей, например, при функциональном тестировании. Эффективность оценивается для решения следующих задач:
принятие решения о допустимости практического использования СЗИ в конкретной ситуации; выявление вкладов различных факторов в достижение цели; установление путей повышения эффективности СЗИ; сравнение альтернативных вариантов систем.
Таким образом, при использовании современной методической базы, оценка эффективности СЗИ носит в основном нечеткий, субъективный характер [19]; практически полностью отсутствуют нормированные количественные показатели, учитывающие возможные случайные или преднамеренные воздействия. В результате достаточно сложно, а зачастую и невозможно, оценить качество функционирования информационной системы при наличии несанкционированных воздействий на ее элементы, а, соответственно, и определить, чем один вариант проектируемой системы лучше другого. Представляется, решением проблемы комплексной оценки эффективности СЗИ является использование системного подхода, позволяющего еще на стадии проектирования количественно оценить уровень безопасности и создать механизм управления рисками. Однако этот путь реализуем при наличии соответствующей системы показателей и критериев.
Нормативная база
Создание и эксплуатация ИС должны проводиться в соответствии с существующим законодательством и требованиями нормативно-технических документов. Данное положение, разумеется, применимо к любому виду организованной деятельности, однако ИТ развиваются исключительно быстрыми темпами, и почти всегда нормативная база отстает от потребностей практики. Здесь подобное отставание законов, нормативных актов, национальных и отраслевых стандартов, а также методического обеспечения, оказывается особенно критичным [5].
Трудности объективного подтверждения эффективности СЗИ коренятся в несовершенстве существующей нормативной базы, а также в сложившихся в ИТ подходах, принципиально отличающихся от разработанных в традиционной инженерии. Специалистами, например, отмечается недостаточная проработанность такого аспекта нормативного обеспечения, как система показателей информационной безопасности [12]. В неудовлетворительном состоянии находится система критериев безопасности, в том числе, таких, как эффективность СЗИ. К серьезным проблемам относится и игнорирование стохастичной природы событий и явлений, которые возникают в процессе защиты информации, абстрагирование от их экономического содержания в нормативном, методическом и прикладном аспектах.
Эти же замечания можно отнести и к международной нормативной базе по информационной безопасности, включающей около 50 международных стандартов ИСО/МЭК на критерии оценки безопасности ИТ и методы защиты средств и систем ИТ. Применение методов функциональной стандартизации в области информационной безопасности изложены в международном стандарте ИСО/МЭК 15408-99 «Критерии оценки безопасности информационных технологий». Фактически, Общие критерии предлагают набор исторически сложившихся и, самое главное, привычных в отрасли подходов к безопасности, которые используются, чтобы создавать изделия или системы, отражающие не столько потребности заказчика, сколько возможности разработчика. Важно отметить, что по своей сути они являются не критериями в полном смысле этого термина, а неким подобием общих технических требований, определяющих облик систем в зависимости от их назначения и условий функционирования.
При создании и развитии сложных, распределенных, тиражируемых информационных систем требуется, как известно, гибкое формирование и применение гармонизированных совокупностей базовых стандартов и нормативных документов разного уровня, выделение в них требований и рекомендаций, необходимых для реализации заданных функций информационных систем. Такие совокупности базовых стандартов должны адаптироваться и конкретизироваться применительно к определенным классам проектов, функций, процессов и компонентов информационных систем. В связи с этой потребностью выделилось и сформировалось понятие «профилей», как основного инструмента функциональной стандартизации [4]. Понятно, что число возможных профилей защиты во много раз превышает исходное количество документов, на которых они могут базироваться, поэтому провести априорную оценку эффективности всех возможных профилей невозможно. С другой стороны, профиль защиты должен создаваться или выбираться исходя из требований к показателям информационной безопасности, установленных заказчиком заранее. Принятые подходы, включая те из них, которые указаны в существующих стандартах, не позволяют сделать такой выбор, чрезвычайно важный для практики. Оценку же эффективности профилей защиты можно осуществить только с использованием комплексных показателей, которые имеют вероятностный или стоимостной характер. При этом следует обратить внимание, что, в отличие от официальных нормативных документов, в аналитических материалах, опубликованных сотрудниками Гостехкомиссии, прямо указывается на необходимость использования в качестве основного критерия эффективности СЗИ соответствующей вероятности [3].
Таким образом, существующие стандарты и документы на их основе не дают ответов на ряд ключевых вопросов.
Как создать информационную систему, чтобы она была безопасной на требуемом измеримом, объективно проверяемом уровне? Как практически сформировать режим безопасности и поддерживать его в условиях постоянно меняющегося внешнего окружения и структуры самой системы? Каков реальный уровень безопасности и насколько эффективна система защиты информации?
Основные причины проблем
Нет сомнений, что защита критически важных для собственников информационных систем соответствует многочисленным международным, национальным, корпоративным, нормативным и методическим документам. Применяются весьма дорогостоящие технические средства и внедряются строго регламентированные организационные мероприятия. Однако нет ответа на самый важный вопрос — насколько предлагаемое или уже реализованное решение хорошо, какова его планируемая или реальная эффективность. Такому положению, сложившемуся сейчас в информатике, но невозможному в области обеспечения интегрированной безопасности объектов традиционной инженерии (например, таких, как авиация, транспорт или энергетика) есть ряд причин:
игнорирование системного подхода как методологии анализа и синтеза СЗИ; отсутствие механизмов полного и достоверного подтверждения качества СЗИ; недостатки нормативно-методического обеспечения информационной безопасности, прежде всего в области показателей и критериев.
Системность при защите информации
Уже в первых работах по защите информации были изложены основные постулаты, которые не утратили своей актуальности и по сей день [9]: абсолютную защиту создать нельзя; система защиты информации должна быть комплексной; СЗИ должна быть адаптируемой к изменяющимся условиям.
К этим аксиомам нужно добавить и другие суждения. Во-первых, СЗИ должна быть именно системой, а не простым, во многом случайным и хаотичным набором некоторых технических средств и организационных мероприятий, как это зачастую наблюдается на практике. Во-вторых, системный подход к защите информации должен применяться, начиная с подготовки технического задания и заканчивая оценкой эффективности и качества СЗИ в процессе ее эксплуатации.
Прежде всего, СЗИ должна иметь целевое назначение. Причем, чем более конкретно сформулирована цель защиты информации, детально уяснены имеющиеся для этого ресурсы и определен комплекс ограничений, тем в большей степени можно ожидать получение желаемого результата. Если цель обеспечения информационной безопасности проста (формулируется скалярным показателем) и принципиально достижима, то оказывается достаточно сравнительно несложных по составу и структуре СЗИ. Однако при расширении круга проблем, которые нужно решать для обеспечения интегральной информационной безопасности, содержание целевого назначения системы на формализованном уровне приобретает многомерный, векторный характер. При этом значимость свойств отдельных элементов СЗИ снижается, а на первый план выдвигаются общесистемные задачи — определение оптимальной структуры и режимов функционирования системы, организация взаимодействия между ее элементами, учет влияния внешней среды и др. При целенаправленном объединении элементов в систему последняя приобретает специфические свойства, изначально не присущие ни одной из ее составных частей. При системном подходе имеют первостепенное значение только те свойства элементов, которые определяют взаимодействие друг с другом и оказывают влияние на систему в целом, а также на достижение поставленной цели.
Результативное решение задач анализа и синтеза СЗИ не может быть обеспечено одними лишь способами умозрительного описания их поведения в различных условиях — системотехника выдвигает проблемы, требующие количественной оценки характеристик. Такие данные, полученные экспериментально или путем математического моделирования, должны раскрывать свойства СЗИ. Основным из них является эффективность, под которой, согласно [7], понимается степень соответствия результатов защиты информации поставленной цели. Последняя, в зависимости от имеющихся ресурсов, знаний разработчиков и других факторов, может быть достигнута в той или иной мере, при этом возможны альтернативные пути ее реализации. Эффективность имеет непосредственную связь с другими системными свойствами, в том числе качеством, надежностью, управляемостью, помехозащищенностью, устойчивостью. Поэтому количественная оценка эффективности позволяет измерять и объективно анализировать основные свойства систем на всех стадиях их жизненного цикла, начиная с этапа формирования требований и эскизного проектирования.
Технический аспект
По статистическим данным Национального отделения ФБР по компьютерным преступлениям, от 85 до 97% нападений на корпоративные сети не только не пресекаются, но даже и не обнаруживаются. Специальная группа экспертов провела анализ защищенности 8932 военных информационных систем; в 7860 (88%) случаях несанкционированное проникновение посторонних в эти системы было успешным. Администраторы только 390 из них обнаружили атаки и всего лишь 19 сообщили о них.
Сведений об аналогичных по масштабу проверках эффективности СЗИ, проведенных в России, нет, но можно предположить, что реальный уровень обеспечения информационной безопасности у нас вряд ли выше. При этом статистическая оценка реального уровня технической эффективности СЗИ оказывается поистине удручающей.
в какой мере система защиты
Для ответа на вопрос, в какой мере система защиты информации обеспечивает требуемый уровень безопасности, необходимо оценивать эффективность СЗИ показателями, носящими вероятностный характер. Совершенствование нормативной базы, методического обеспечения в области информационной безопасности должно происходить, прежде всего, в этом направлении. Содержательные результаты по оценке эффективности систем защиты информации могут быть получены при системном подходе, более того, его обязательность прямо вытекает из ГОСТ Р50922-96 [6]. Разумеется, количественная оценка эффективности СЗИ требует больше усилий, чем используемые качественные методы [4]. Однако и отдача, прежде всего экономическая, будет намного весомее, а интересы, как заказчика, так и разработчика СЗИ, будут защищены более надежно.
Литература
А. Баутов. Стандарты и оценка эффективности защиты информации. Доклад на Третьей Всероссийской практической конференции "Стандарты в проектах современных информационных систем". Москва, 23-24 апреля 2003 г. А. Баутов, Экономический взгляд на проблемы информационной безопасности. Открытые системы, 2002, № 2. С. Вихорев, А. Ефимов, Практические рекомендации по информационной безопасности. Jet Info, № 10-11, 1996. С. Вихорев, Р. Кобцев, Как определить источники угроз. Открытые системы, 2002, № 7-8. В. Галатенко, Информационная безопасность - основы. Системы управления базами данных, 1996, № 1. А. Горбунов, В. Чуменко, Выбор рациональной структуры средств защиты информации в АСУ.
ГОСТ Р 50922-96. Защита информации. Основные термины и определения. Г. Гуд, Р. Макол. Системотехника (Введение в проектирование больших систем). М., Сов. радио, 1962. М. Де Гроот. Оптимальные статистические решения. М.: Мир, 1974. Е. Зиндер, Революционные изменения базовых стандартов в области системного проектирования. Директор информационной службы, 2001, № 5. А. Ездаков, О. Макарова, Как защитить информацию. Сети, 1997, № 8. ИСО/МЭК 15408-99 "Критерии оценки безопасности информационных технологий". В.
Козлов. Критерии информационной безопасности и поддерживающие их стандарты: состояние и тенденции. "Стандарты в проектах современных информационных систем". Сборник трудов II-й Всероссийской практической конференции. Москва, 27-28 марта 2002 года. В. Липаев, Е. Филинов, Формирование и применение профилей открытых информационных систем. Открытые системы, 1997, № 5. Г. Петухов, Основы теории эффективности целенаправленных процессов. Часть 1. Методология, методы, модели. МО СССР, 1989. В. Пугачев. Теория вероятностей и математическая статистика. М.: Наука, 1979. В. Сабынин, Специалисты, давайте говорить на одном языке и понимать друг друга. Информост - Средства связи, № 6. П. Сэйер, Lloyd страхует от хакеров. Computerworld Россия, 2000, № 30. Л. Хмелев. Оценка эффективности мер безопасности, закладываемых при проектировании электронно-информационных систем. Труды научно-технической конференции "Безопасность информационных технологий", Пенза, июнь 2001. Положение о сертификации средств и систем вычислительной техники и связи по требованиям безопасности информации. М., 1994.
Андрей Баутов (anb_main@mail.ru) — независимый эксперт.
В соответствии с определением, приведенным в ГОСТ Р ИСО/МЭК 12207:99, «система — это комплекс, состоящий из процессов, технических и программных средств, устройств и персонала, обладающий возможностью удовлетворять установленным потребностям или целям». В связи с подобным определением полезно рассматривать и определение системного проектирования, которое, согласно INCOSE (International Council on Systems Engineering), представляет собой «междисциплинарный подход и средства, делающие возможным создание успешных систем». Системное проектирование — дисциплина разработки продуктов или процессов на основе концепции систем. Оно фокусируется на определении потребностей заказчика и требуемых функций системы, установлении требований, выполнении конструкторского синтеза и аттестации с согласованием как бизнес-аспектов, так и технических аспектов данной задачи, интегрируя необходимые дисциплины и группы специалистов в одну команду на протяжении всего жизненного цикла развития системы [11]. Системный подход — методология исследования сложных объектов как объединений элементов, связанных комплексом отношений друг с другом и выступающих единым целым по отношению к внешней среде. Основной задачей системного подхода является синтез, включающий проектирование систем и организацию процессов, предназначенных для достижения определенных целей и оптимальных по выбранному критерию.
Информационная безопасность
Идентификация рисков
В любой методике управления рисками необходимо идентифицировать риски, как вариант – их составляющие (угрозы и уязвимости). Естественное требование к списку — его полнота. Сложность задачи составления списка и доказательство его полноты зависит от того, какие требования предъявляются к детализации списка. На базовом уровне безопасности, как правило, не предъявляется специальных требований к детализации классов и достаточно использовать какой-либо подходящий в данном случае стандартный список классов рисков. Оценка величины рисков не рассматривается, что приемлемо для отдельных методик базового уровня. Списки классов рисков содержатся в некоторых руководствах, в специализированном ПО анализа рисков. Примером является германский стандарт BSI (www.bsi.de, — в нем имеется каталог угроз применительно к различным элементам информационной технологии.
Достоинством подобных списков является их полнота: классов, как правило, немного (десятки), они достаточно широкие и заведомо покрывают все существующее множество рисков. Недостаток — сложность оценки уровня риска и эффективности контрмер для широкого класса, поскольку подобные расчеты удобнее проводить по более узким (конкретным) классам рисков. К примеру, класс рисков «неисправность маршрутизатора» разбивается на множество подклассов, включающих возможные виды неисправности (уязвимости) ПО конкретного маршрутизатора и неисправности оборудования.
«Использование чужого идентификатора сотрудниками организации ("маскарад")»
Для оценки угроз выбраны следующие косвенные факторы:
Статистика по зарегистрированным инцидентам. Тенденции в статистке по подобным нарушениям. Наличие в системе информации, представляющей интерес для потенциальных внутренних или внешних нарушителей. Моральные качества персонала. Возможность извлечь выгоду из изменения обрабатываемой в системе информации. Наличие альтернативных способов доступа к информации. Статистика по подобным нарушениям в других информационных системах организации.
Для оценки уязвимостей выбраны следующие косвенные факторы:
Количество рабочих мест (пользователей) в системе. Размер рабочих групп. Осведомленность руководства о действиях сотрудников (разные аспекты). Характер используемого на рабочих местах оборудования и ПО. Полномочия пользователей.
По косвенным факторам предложены вопросы и несколько фиксированных вариантов ответов, которые «стоят» определенное количество баллов. Итоговая оценка угрозы и уязвимости данного класса определяется суммированием баллов.
История вопроса
Опубликованные стандарты в области защиты информации (ISO 15408, ISO 17799, ISO 9001, NIST 800-30, BSI, BS 7799, COBIT, ITIL и пр.) рассматривают вопросы анализа и управления информационными рисками (таблица 1), однако не содержат ряда важных деталей, которые обязательно надо конкретизировать при разработке практических методик управления рисками. Конкретизация этих деталей зависит от уровня зрелости организации, специфики ее деятельности и некоторых других факторов. Таким образом, невозможно предложить некую единую, приемлемую для всех отечественных компаний и организаций, универсальную методику управления рисками, позволяющую обеспечить экономически оправданную информационную безопасность предприятия. В каждом конкретном случае необходимо адаптировать общую методику управления рисками под определенные нужды предприятия, с учетом специфики его функционирования и ведения бизнеса. Давайте рассмотрим типичные вопросы и проблемы, возникающие при разработке методик управления информационными рисками в отечественных компаниях.
Таблица 1. Вопросы управления рисками в некоторых международных стандартах
Измерение рисков
Сегодня существует ряд подходов к измерению рисков. Давайте рассмотрим наиболее распространенные подходы, а именно оценку рисков по двум и по трем факторам.
Оценка рисков по двум факторам. В простейшем случае используется оценка двух факторов: вероятность происшествия и тяжесть возможных последствий. Обычно считается, что риск тем больше, чем больше вероятность происшествия и тяжесть последствий. Общая идея может быть выражена формулой:
РИСК = P происшествия * ЦЕНА ПОТЕРИ
Если переменные являются количественными величинами, то риск — это оценка математического ожидания потерь.
Если переменные являются качественными величинами, то метрическая операция умножения не определена. Таким образом, в явном виде эта формула использоваться не должна. Рассмотрим вариант использования качественных величин (наиболее часто встречающаяся ситуация). Вначале должны быть определены шкалы.
Определяется субъективная шкала вероятностей событий, например: A - Событие практически никогда не происходит B - Событие случается редко C - Вероятность события за рассматриваемый промежуток времени – около 0.5 D - Скорее всего, событие произойдет E - Событие почти обязательно произойдет
Кроме того, определяется субъективная шкала серьезности происшествий, например: N (Negligible) – Воздействием можно пренебречь Mi (Minor) – Незначительное происшествие: последствия легко устранимы, затраты на ликвидацию последствий невелики, воздействие на информационную технологию –незначительно. Mo (Moderate) – Происшествие с умеренными результатами: ликвидация последствий не связана с крупными затратами, воздействие на информационную технологию невелико и не затрагивает критически важные задачи. S (Serious) – Происшествие с серьезными последствиями: ликвидация последствий связана со значительными затратами, воздействие на информационные технологии ощутимо, воздействует на выполнение критически важных задач. C (Critical) – Происшествие приводит к невозможности решения критически важных задач.
Для оценки рисков определяется шкала из трех значений:
Низкий риск Средний риск Высокий риск
Риск, связанный с определенным событием, зависит от двух факторов и может быть определен так:
Таблица 2. Определение риска в зависимости от двух факторов
|
Negligible |
Minor |
Moderate |
Serious |
Critical |
| A |
Низкий риск |
Низкий риск |
Низкий риск |
Средний риск |
Средний риск |
| B |
Низкий риск |
Низкий риск |
Средний риск |
Средний риск |
Высокий риск |
| C |
Низкий риск |
Средний риск |
Средний риск |
Средний риск |
Высокий риск |
| D |
Средний риск |
Средний риск |
Средний риск |
Средний риск |
Высокий риск |
| E |
Средний риск |
Высокий риск |
Высокий риск |
Высокий риск |
Высокий риск |
Шкалы факторов риска и сама таблица могут быть определены иначе, иметь другое число градаций. Подобный подход к оценке рисков достаточно распространен.
При разработке (использовании) методик оценивания рисков необходимо учитывать следующие особенности:
Значения шкал должны быть четко определены (словесное описание) и пониматься одинаково всеми участниками процедуры экспертной оценки. Требуются обоснования выбранной таблицы. Необходимо убедиться, что разные инциденты, характеризующиеся одинаковыми сочетаниями факторов риска, имеют с точки зрения экспертов одинаковый уровень рисков.
Оценка рисков по трем факторам. В зарубежных методиках, рассчитанных на более высокие требования, чем базовый уровень, используется модель оценки риска с тремя факторами: угроза, уязвимость, цена потери. Угрозу и уязвимость определим следующим образом:
Угроза — совокупность условий и факторов, которые могут стать причиной нарушения целостности, доступности, конфиденциальности информации.
Уязвимость — слабость в системе защиты, которая делает возможным реализацию угрозы.
Вероятность происшествия, которая в данном подходе может быть объективной либо субъективной величиной, зависит от уровней (вероятностей) угроз и уязвимостей:
Р происшествия = Р угрозы * Р уязвимости
Соответственно, риск определяется следующим образом:
РИСК = P угрозы * Р уязвимости * ЦЕНА ПОТЕРИ
Данное выражение можно рассматривать как математическую формулу, если используются количественные шкалы, либо как формулировку общей идеи, если хотя бы одна из шкал – качественная.
В последнем случае используются различного рода табличные методы для определения риска в зависимости от трех факторов.
Например, показатель риска измеряется в шкале от 0 до 8 со следующими определениями уровней риска:
1 — риск практически отсутствует. Теоретически возможны ситуации, при которых событие наступает, но на практике это случается редко, а потенциальный ущерб сравнительно невелик.
2 — риск очень мал. События подобного рода случались достаточно редко, кроме того, негативные последствия сравнительно невелики.
......
8 — риск очень велик. Событие скорее всего наступит, и последствия будут чрезвычайно тяжелыми.
Матрица может быть определена следующим образом:
Таблица 3. Определение риска в зависимости от трех факторов
Степень серьезности происшествия (цена потери) |
Уровень угрозы |
| Низкий |
Средний |
Высокий |
| Уровни уязвимостей |
Уровни уязвимостей |
Уровни уязвимостей |
| Н |
С |
В |
Н |
С |
В |
Н |
С |
В |
| Negligible |
0 |
1 |
2 |
1 |
2 | 3 | 2 | 3 | 4 | | Minor |
1 | 2 | 3 | 2 | 3 | 4 | 3 | 4 | 5 | | Moderate |
2 | 3 | 4 | 3 | 4 |
5 |
4 |
5 |
6 |
| Serious |
3 | 4 | 5 | 4 | 5 | 6 | 5 | 6 | 7 | | Critical |
4 | 5 | 6 | 5 | 6 | 7 | 6 | 7 | 8 |
В данной таблице уровни уязвимости Н, С, В соответственно означают: низкий, средний, высокий уровень. Подобные таблицы используются как в «бумажных» вариантах методик оценки рисков, так и в различного рода инструментальных средствах – ПО анализа рисков. В последнем случае матрица задается разработчиками ПО и, как правило, не подлежит корректировке. Это один из факторов, ограничивающих точность подобного рода инструментария.
Экономически оправданная безопасность
Сергей Петренко, Сергей Симонов, журнал "IT Manager" #15(3)/2004
Анализ и управление информационными рисками позволяет обеспечивать экономически оправданную информационную безопасность в любой отечественной компании. Для этого необходимо сначала определить, какие информационные активы компании нужно защищать, воздействию каких угроз эти активы подвержены, а затем выработать рекомендации по защите данных. Давайте посмотрим, как на практике можно оценить и управлять информационными рисками компании исходя из поставленных целей и задач.
Классы контрмер CRAMM (фрагмент)
Masquerading of User Identity by Insiders
Identification and Authentication Logical Access Control Accounting Audit Object Re-use Security Testing Software Integrity Mobile Computing and Teleworking Software Distribution System Input/Output Controls Network Access Controls System Administration Controls Application Input/Output Controls Back-up of Data Personnel Security Education and Training Security Policy Security Infrastructure Data Protection Legalisation Incident Handling Compliance Checks
Masquerading of User Identity by Contracted Service Providers
Identification and Authentication Logical Access Control Accounting Audit Object Re-use Security Testing Software Integrity Mobile Computing and Teleworking Software Distribution System Input/Output Controls Network Access Controls System Administration Controls Application Input/Output Controls Back-up of Data Personnel Security Education and Training Security Policy Security Infrastructure Outsourcing Data Protection Legalisation Incident Handling Compliance Checks
Masquerading of User Identity by Outsiders
Identification and Authentication Logical Access Control Accounting Audit Object Re-use Security Testing Software Integrity Mobile Computing and Teleworking Software Distribution System Input/Output Controls Network Security Management Network Access Controls System Administration Controls Application Input/Output Controls Back-up of Data Security Education and Training Security Policy Security Infrastructure Data Protection Legalisation Incident Handling Compliance Checks
Подобные классификаторы позволяют автоматически выбирать и предлагать конкретные варианты контрмер, возможных для рассматриваемой информационной системы. Таким образом, владелец информационных ресурсов может выбирать из них приемлемые для себя варианты. Следующий шаг – оценка эффективности контрмер.
Задача оценки эффективности контрмер является не менее сложной, чем оценка рисков. Причина в том, что оценка эффективности комплексной подсистемы безопасности, включающей контрмеры разных уровней (административные, организационные, программно-технические), в конкретной информационной системе – методологически чрезвычайно сложная задача.
По этой причине обычно используются упрощенные, качественные оценки эффективности контрмер. Примером является следующая таблица типичных значений эффективности контрмер, применяемых в методе анализа рисков RiskWatch.
Таблица 4. Ориентировочная эффективность мероприятий в области защиты информации по критерию ROI (Return of Investment – возврат вложений)
| Разработка и внедрение политики информационной безопасности |
2 |
Мероприятия по работе с персоналом (наведение справок,
контроль за поведением и т. п.) |
3 |
| Совершенствование организационной структуры |
4 |
| Анализ рисков |
5 |
| Управление жизненным циклом (управление рисками) |
5 |
| Совершенствование должностных инструкций и условий контрактов |
5 |
| Меры контроля за посетителями |
6 |
| Управление имуществом компании |
7 |
| Обучение персонала и контроль за соблюдением режима ИБ |
9 |
| Меры контроля за работой приложений |
10 |
Указанные в таблице значения являются ориентировочными оценками эффективности вложений в различные классы мероприятий в области защиты информации.
В ряде случаев используются более сложные таблицы, в которых эффективность зависит от определенных факторов. На основе подобных таблиц делаются качественные оценки эффективности контрмер.
Оценивание рисков
При оценивании рисков рекомендуется рассматривать следующие аспекты:
Шкалы и критерии, по которым можно измерять риски. Оценка вероятностей событий. Технологии измерения рисков.
Шкалы и критерии, по которым измеряются риски. Для измерения какого-либо свойства необходимо выбрать шкалу. Шкалы могут быть прямыми (естественными) или косвенными (производными). В качестве примера прямых шкал назовем шкалы для измерения физических величин, скажем - литры для измерения объемов, метры для измерения длины. В ряде случаев прямых шкал не существует, приходится использовать либо прямые шкалы других свойств, связанных с интересующими нас, либо определять новые шкалы. Примером является шкала для измерения субъективного свойства «ценность информационного ресурса». Она может измеряться в производных шкалах, таких, как стоимость восстановления ресурса, время восстановления ресурса, и других. Еще один вариант – определить шкалу для получения экспертной оценки, например имеющую три значения:
Малоценный информационный ресурс: от него не зависят критически важные задачи и он может быть восстановлен с небольшими затратами времени и денег. Ресурс средней ценности: от него зависит ряд важных задач, при утрате он может быть восстановлен за время, не превышающее критически допустимое, стоимость восстановления – высокая. Ценный ресурс: от него зависят критически важные задачи, в случае утраты время восстановления превышает критически допустимое либо стоимость чрезвычайно высока.
Для измерения рисков не существует естественной шкалы. Риски можно оценивать по объективным либо субъективным критериям. Примером объективного критерия является вероятность выхода из строя какого-либо оборудования (предположим, ПК) за определенный промежуток времени. Примером субъективного критерия — оценка владельцем информационного ресурса риска выхода из строя ПК. Для этого обычно разрабатывается качественная шкала с несколькими градациями: низкий, средний, высокий уровень. В методиках анализа рисков, как правило, используются субъективные критерии, измеряемые в качественных шкалах, поскольку:
оценка должна отражать субъективную точку зрения владельца информационных ресурсов; должны быть учтены различные аспекты, не только технические, но и организационные, психологические и т. д.
Для получения субъективной оценки в рассматриваемом примере с оценкой риска выхода из строя ПК, можно использовать либо прямую экспертную оценку, либо определить функцию, отображающую объективный данные (вероятность) в субъективную шкалу рисков.
Субъективные шкалы могут быть количественными и качественными, но на практике обычно используются качественные шкалы с 3-7 градациями. С одной стороны, это просто и удобно, с другой – требует грамотного подхода к обработке данных.
Объективные и субъективные вероятности. Термин "вероятность" имеет несколько значений. Наиболее часто встречаются два толкования этого слова, которые обозначаются сочетанием "объективная вероятность" и "субъективная вероятность". Под объективной (иногда называемой физической) вероятностью понимается относительная частота появления какого-либо события в общем объеме наблюдений или отношение числа благоприятных исходов к общему их количеству. Объективная вероятность используется при анализе результатов большого числа наблюдений, имевших место в прошлом, а также как следствия из моделей, описывающих некоторые процессы.
Под субъективной вероятностью понимается мера уверенности какого-либо человека или группы людей в том, что данное событие действительно произойдет. Как мера уверенности человека в возможности наступления события, субъективная вероятность может быть формально представлена различными способами: вероятностным распределением на множестве событий, бинарным отношением на множестве событий, не полностью заданным вероятностным распределением или бинарным отношением и другими способами. Очень часто субъективная вероятность представляет собой вероятностную меру, полученную экспертным путем. В дальнейшем именно в этом смысле мы и будем понимать субъективную вероятность. В современных работах в области системного анализа субъективная вероятность не просто передает меру уверенности на множестве событий, а увязана с системой предпочтений лица, принимающего решения (ЛПР), и в конечном итоге с функцией полезности, отражающей его предпочтения на множестве альтернатив.
Тесная связь между субъективной вероятностью и полезностью используется при построении некоторых методов получения субъективной вероятности.
Получение оценок субъективной вероятности. Процесс получения субъективной вероятности обычно разделяют три этапа: подготовительный этап, получение оценок, этап анализа полученных оценок.
Первый этап. Во время этого этапа формируется объект исследования — множество событий, ведется предварительный анализ свойств этого множества (устанавливается зависимость или независимость событий, дискретность или непрерывность случайной величины, порождающей данное множество событий). На основе такого анализа выбирается один из подходящих методов (обзор основных методов рассматривается в приложении 6) получения субъективной вероятности. На этом же этапе производится подготовка эксперта или группы экспертов, ознакомление их с методом и проверка понимания поставленной задачи экспертами.
Второй этап состоит в применении метода, выбранного на первом этапе. Результатом этого этапа является набор чисел, отражающий субъективный взгляд эксперта или группы экспертов на вероятность того или иного события, однако далеко не всегда может считаться окончательно полученным распределением, поскольку может быть противоречивым.
Третий этап состоит в исследовании результатов опроса. Если вероятности, полученные от экспертов, не согласуются с аксиомами вероятности, на это обращается внимание экспертов и производится уточнение ответов с целью приведения их в соответствие с выбранной системой аксиом. Для некоторых методов получения субъективной вероятности третий этап не проводится, поскольку сам метод состоит в выборе вероятного распределения, подчиняющегося аксиомам вероятности, которое в том или другом смысле наиболее близко к оценкам экспертов. Особую важность третий этап приобретает при агрегировании оценок, полученных от группы экспертов.
Оценка уязвимости
Ответьте на вопросы:
1. Сколько людей имеют право пользоваться информационной системой?
Варианты ответов
a От 1 до 10 0 b От 11 до 50 4 c От 51 до 200 10 d От 200 до 1000 14 e Свыше 1000 20
2. Будет ли руководство осведомлено о том, что люди, работающие под их началом, ведут себя необычным образом?
Варианты ответов
a Да 0 b Нет 10
3. Какие устройства и программы доступны пользователям?
Варианты ответов
a Только терминалы или сетевые контроллеры, ответственные за предоставление и маршрутизацию информации, но не за передачу данных -5 b Только стандартное офисные устройства и программы и управляемые с помощью меню подчиненные прикладные программы 0 c Пользователи могут получить доступ к операционной системе, но не к компиляторам 5 d Пользователи могут получить доступ к компиляторам 10
4. Возможны ли ситуации, когда сотрудникам, предупрежденным о предстоящем сокращении или увольнении, разрешается логический доступ к информационной системе?
Варианты ответов
a Да 10 b Нет 0
5. Каковы в среднем размеры рабочих групп сотрудников пользовательских подразделений, имеющих доступ к информационной системе?
Варианты ответов
a Менее 10 человек 0 b От 11 до 20 человек 5 c Свыше 20 человек 10
6. Станет ли факт изменения хранящихся в информационной системе данных очевидным сразу для нескольких человек (в результате чего его будет очень трудно скрыть)?
Варианты ответов
a Да 0 b Нет 10
7. Насколько велики официально предоставленные пользователям возможности по просмотру всех хранящихся в системе данных?
Варианты ответов
a Официальное право предоставлено всем пользователям -2 b Официальное право предоставлено только некоторым пользователям 0
8. Насколько необходимо пользователям знать всю информацию, хранящуюся в системе?
Варианты ответов
a Всем пользователям необходимо знать всю информацию -4 b Отдельным пользователям необходимо знать лишь относящуюся к ним информацию 0
Ответьте на вопросы
1. Сколько раз за последние три года сотрудники организации пытались получить несанкционированный доступ к хранящейся в информационной системе информации с использованием прав других пользователей?
Варианты ответов
a Ни разу 0 b Один или два раза 10 c В среднем раз в год 20 d В среднем чаще одного раза в год 30 e Неизвестно 10
2. Какова тенденция в статистике такого рода попыток несанкционированного проникновения в информационную систему?
Варианты ответов
a К возрастанию 10 b Остается постоянной 0 c К снижению -10
3. Хранится ли в информационной системе информация (например, личные дела), которая может представлять интерес для сотрудников организации и побуждать их к попыткам несанкционированного доступа к ней?
Варианты ответов
a Да 5 b Нет 0
4. Известны ли случаи нападения, угроз, шантажа, давления на сотрудников со стороны посторонних лиц?
Варианты ответов
a Да 10 b Нет 0
5. Существуют ли среди персонала группы лиц или отдельные лица с недостаточно высокими моральными качествами?
Варианты ответов
a Нет, все сотрудники отличаются высокой честностью и порядочностью 0 b Существуют группы лиц и отдельные личности с недостаточно высокими моральными качествами, но это вряд ли может спровоцировать их на несанкционированное использование системы 5 c Существуют группы лиц и отдельные личности с настолько низкими моральными качествами, что это повышает вероятность несанкционированного использования системы сотрудниками 10
6. Хранится ли в информационной системе информация, несанкционированное изменение которой может принести прямую выгоду сотрудникам?
Варианты ответов
a Да 5 b Нет 0
7. Предусмотрена ли в информационной системе поддержка пользователей, обладающих техническими возможностями совершить подобные действия?
Варианты ответов
a Нет 0 b Да 5
8. Существуют ли другие способы просмотра информации, позволяющие злоумышленнику добраться до нее более простыми методами, чем с использованием "маскарада"?
Варианты ответов
a Да -10 b Нет 0
9. Существуют ли другие способы несанкционированного изменения информации, позволяющие злоумышленнику достичь желаемого результата более простыми методами, чем с использованием "маскарада"?
Варианты ответов
a Да -10 b Нет 0
10. Сколько раз за последние три года сотрудники пытались получить несанкционированный доступ к информации, хранящейся в других подобных системах в вашей организации?
Варианты ответов
a Ни разу 0 b Один или два раза 5 c В среднем раз в год 10 d В среднем чаще одного раза в год 15 e Неизвестно 10
Степень угрозы при количестве баллов:
До 9 Очень низкая От 10 до 19 Низкая От 20 до 29 Средняя От 30 до 39 Высокая 40 и более Очень высокая
Степень уязвимости при количестве баллов:
До 9 Низкая От 10 до 19 Средняя 20 и более Высокая
Технология оценки угроз и уязвимостей
Обычно для оценки угроз и уязвимостей используются различные методы, в основе которых могут лежать:
Экспертные оценки. Статистические данные. Учет факторов, влияющих на уровни угроз и уязвимостей.
Один из возможных подходов к разработке подобных методик – накопление статистических данных о реально случившихся происшествиях, анализ и классификация их причин, выявление факторов, от которых они зависят. На основе этой информации можно оценить угрозы и уязвимости в других информационных системах.
Практические сложности в реализации этого подхода следующие: Во-первых, должен быть собран весьма обширный материал о происшествиях в этой области. Во-вторых, применение данного подхода оправдано далеко не всегда. Если информационная система достаточно крупная (содержит много элементов, расположена на обширной территории), имеет давнюю историю, то подобный подход, скорее всего, применим. Если система сравнительно невелика, использует новейшие элементы технологии (для которых пока нет достоверной статистики), оценки угроз и уязвимостей могут оказаться недостоверными.
Наиболее распространенным в настоящее время является подход, основанный на учете различных факторов, влияющих на уровни угроз и уязвимостей. Такой подход позволяет абстрагироваться от малосущественных технических деталей, учесть не только программно-технические, но и иные аспекты. Рассмотрим пример реализации подобного подхода, используемого в методе CRAMM 4.0 для одного из классов рисков:
Возможности и ограничения данного подхода
Несомненное достоинство данного подхода — возможность учета множества косвенных факторов (и не только технических). Методика проста и дает владельцу информационных ресурсов ясное представление, каким образом получается итоговая оценка и что надо изменить, чтобы улучшить показатели.
Недостатки: косвенные факторы и их веса зависят от сферы деятельности организации, а также от ряда иных обстоятельств. Таким образом, методика всегда требует подстройки под конкретный объект. При этом доказательство полноты выбранных косвенных факторов и правильности их весовых коэффициентов (задача малоформализованная и сложная) на практике решается экспертными методами (проверка соответствия полученных по методике результатов ожидаемым для тестовых ситуаций). Подобные методики, как правило, разрабатываются для организаций определенного профиля (ведомств), апробируются и затем используются в качестве ведомственного стандарта. По такому пути пошли и разработчики CRAMM, создав около десятка версий метода для разных ведомств (министерство иностранных дел, вооруженные силы и т. д.).
Оценки рисков и уязвимостей в рассмотренном примере являются качественными величинами. Однако подобными методами могут быть получены и количественные оценки, необходимые при расчете остаточных рисков, решении оптимизационных задач. Для этого применяется ряд методов, позволяющих установить на упорядоченном множестве оценок систему расстояний. Получение объективных количественных оценок рисков должно быть актуальным для страховых агентств, занимающимся страхованием информационных рисков.
На практике, страховые агентства пользуются в большинстве случаев качественными оценками. Простые методики, без длительного и дорогостоящего обследования, позволяют отнести информационную систему к той или иной группе риска (по классификации страховой компании) на основе интервью с рядом должностных лиц. В таких методиках также фиксируются и анализируются косвенные факторы.
Выбор допустимого уровня риска
Выбор допустимого уровня риска связан с затратами на реализацию подсистемы информационной безопасности. Как минимум существует два подхода к выбору допустимого уровня рисков.
Первый подход типичен для базового уровня безопасности. Уровень остаточных рисков не принимается во внимание. Затраты на программно-технические средства защиты и организационные мероприятия, необходимые для соответствия информационной системы спецификациям базового уровня (антивирусное ПО, МЭ, системы резервного копирования, системы контроля доступа) являются обязательными, их целесообразность не обсуждается. Дополнительные затраты (если такой вопрос будет поставлен по результатам проведения аудита ИБ либо по инициативе службы безопасности) должны находиться в разумных пределах и не превышать 5-15% средств, которые тратятся на поддержание работы информационной системы.
Второй подход применяется при обеспечении повышенного уровня безопасности. Собственник информационных ресурсов должен сам выбирать допустимый уровень остаточных рисков и нести ответственность за свой выбор.
В зависимости от уровня зрелости организации, характера основной деятельности, обоснование выбора допустимого уровня риска может проводиться разными способами. Наиболее распространенным является анализ стоимость/эффективность различных вариантов защиты, примеры постановок задач:
Стоимость подсистемы безопасности должна составлять не более 20% от стоимости информационной системы. Найти вариант контрмер, максимально снижающих уровень интегральных рисков. Уровень рисков по всем классам должен не превышать «очень низкий уровень». Найти вариант контрмер с минимальной стоимостью.
В случае постановок оптимизационных задач важно правильно выбрать комплекс контрмер (перечислить возможные варианты) и оценить его эффективность.
Выбор контрмер и оценка их эффективности
Система защиты строится комплексно, включает контрмеры разных уровней (программно-технические, административные, организационные). Для облегчения выбора комплекса контрмер в различных методиках используются таблицы, в которых классам угроз соответствуют возможные контрмеры. Ниже приводится пример классификатора контрмер, CRAMM 4:
в определении характеристик рисков корпоративной
Цель оценивания рисков состоит в определении характеристик рисков корпоративной информационной системы и ее ресурсов. В результате оценки рисков становится возможным выбрать средства, обеспечивающие желаемый уровень информационной безопасности компании. При оценивании рисков учитываются: ценность ресурсов, значимость угроз и уязвимостей, эффективность существующих и планируемых средств защиты. Сами показатели ресурсов, значимости угроз и уязвимостей, эффективность средств защиты могут быть определены как количественными методами (например, при определении стоимостных характеристик), так и качественными (например, учитывающими штатные или чрезвычайно опасные нештатные воздействия внешней среды). Таким образом, анализ и управление информационными рисками позволяет обеспечить экономически оправданную безопасность компании.
Информационная безопасность
Идентификация/аутентификация с помощью биометрических данных
Биометрия представляет собой совокупность автоматизированных методов идентификации и/или аутентификации людей на основе их физиологических и поведенческих характеристик. К числу физиологических характеристик принадлежат особенности отпечатков пальцев, сетчатки и роговицы глаз, геометрия руки и лица и т.п. К поведенческим характеристикам относятся динамика подписи (ручной), стиль работы с клавиатурой. На стыке физиологии и поведения находятся анализ особенностей голоса и распознавание речи. Биометрией во всем мире занимаются очень давно, однако долгое время все, что было связано с ней, отличалось сложностью и дороговизной. В последнее время спрос на биометрические продукты, в первую очередь в связи с развитием электронной коммерции, постоянно и весьма интенсивно растет. Это понятно, поскольку с точки зрения пользователя гораздо удобнее предъявить себя самого, чем что-то запоминать. Спрос рождает предложение, и на рынке появились относительно недорогие аппаратно-программные продукты, ориентированные в основном на распознавание отпечатков пальцев. В общем виде работа с биометрическими данными организована следующим образом. Сначала создается и поддерживается база данных характеристик потенциальных пользователей. Для этого биометрические характеристики пользователя снимаются, обрабатываются, и результат обработки (называемый биометрическим шаблоном) заносится в базу данных (исходные данные, такие как результат сканирования пальца или роговицы, обычно не хранятся). В дальнейшем для идентификации (и одновременно аутентификации) пользователя процесс снятия и обработки повторяется, после чего производится поиск в базе данных шаблонов. В случае успешного поиска личность пользователя и ее подлинность считаются установленными. Для аутентификации достаточно произвести сравнение с одним биометрическим шаблоном, выбранным на основе предварительно введенных данных. Обычно биометрию применяют вместе с другими аутентификаторами, такими, например, как интеллектуальные карты.
Иногда биометрическая аутентификация является лишь первым рубежом защиты и служит для активизации интеллектуальных карт, хранящих криптографические секреты; в таком случае биометрический шаблон хранится на той же карте.
Активность в области биометрии очень велика. Организован соответствующий консорциум (см. http://www.biometrics.org/), активно ведутся работы по стандартизации разных аспектов технологии (формата обмена данными, прикладного программного интерфейса и т.п.), публикуется масса рекламных статей, в которых биометрия преподносится как средство обеспечения сверхбезопасности, ставшее доступным широким массам.
На наш взгляд, к биометрии следует относиться весьма осторожно. Необходимо учитывать, что она подвержена тем же угрозам, что и другие методы аутентификации. Во-первых, биометрический шаблон сравнивается не с результатом первоначальной обработки характеристик пользователя, а с тем, что пришло к месту сравнения. А, как известно, за время пути... много чего может произойти. Во-вторых, биометрические методы не более надежны, чем база данных шаблонов. В-третьих, следует учитывать разницу между применением биометрии на контролируемой территории, под бдительным оком охраны, и в "полевых" условиях, когда, например к устройству сканирования роговицы могут поднести муляж и т.п. В-четвертых, биометрические данные человека меняются, так что база шаблонов нуждается в сопровождении, что создает определенные проблемы и для пользователей, и для администраторов.
Но главная опасность состоит в том, что любая "пробоина" для биометрии оказывается фатальной. Пароли, при всей их ненадежности, в крайнем случае можно сменить. Утерянную аутентификационную карту можно аннулировать и завести новую. Палец же, глаз или голос сменить нельзя. Если биометрические данные окажутся скомпрометированы, придется как минимум производить существенную модернизацию всей системы.
Лекция из курса Основы информационной безопасности
В.А.Галатенко
Интернет Университет Информационных Технологий, INTUIT.ru
Одноразовые пароли
Рассмотренные выше пароли можно назвать многоразовыми; их раскрытие позволяет злоумышленнику действовать от имени легального пользователя. Гораздо более сильным средством, устойчивым к пассивному прослушиванию сети, являются одноразовые пароли. Наиболее известным программным генератором одноразовых паролей является система S/KEY компании Bellcore. Идея этой системы состоит в следующем. Пусть имеется односторонняя функция f (то есть функция, вычислить обратную которой за приемлемое время не представляется возможным). Эта функция известна и пользователю, и серверу аутентификации. Пусть, далее, имеется секретный ключ K, известный только пользователю. На этапе начального администрирования пользователя функция f применяется к ключу K n раз, после чего результат сохраняется на сервере. После этого процедура проверки подлинности пользователя выглядит следующим образом: сервер присылает на пользовательскую систему число (n-1); пользователь применяет функцию f к секретному ключу K (n-1) раз и отправляет результат по сети на сервер аутентификации; сервер применяет функцию f к полученному от пользователя значению и сравнивает результат с ранее сохраненной величиной. В случае совпадения подлинность пользователя считается установленной, сервер запоминает новое значение (присланное пользователем) и уменьшает на единицу счетчик (n).
На самом деле реализация устроена чуть сложнее (кроме счетчика, сервер посылает затравочное значение, используемое функцией f), но для нас сейчас это не важно. Поскольку функция f необратима, перехват пароля, равно как и получение доступа к серверу аутентификации, не позволяют узнать секретный ключ K и предсказать следующий одноразовый пароль. Система S/KEY имеет статус Internet-стандарта (RFC 1938). Другой подход к надежной аутентификации состоит в генерации нового пароля через небольшой промежуток времени (например, каждые 60 секунд), для чего могут использоваться программы или специальные интеллектуальные карты (с практической точки зрения такие пароли можно считать одноразовыми). Серверу аутентификации должен быть известен алгоритм генерации паролей и ассоциированные с ним параметры; кроме того, часы клиента и сервера должны быть синхронизированы.
Основные понятия
Идентификацию и аутентификацию можно считать основой программно-технических средств безопасности, поскольку остальные сервисы рассчитаны на обслуживание именованных субъектов. Идентификация и аутентификация - это первая линия обороны, "проходная" информационного пространства организации.
Идентификация позволяет субъекту (пользователю, процессу, действующему от имени определенного пользователя, или иному аппаратно-программному компоненту) назвать себя (сообщить свое имя).
Посредством аутентификации вторая сторона убеждается, что субъект действительно тот, за кого он себя выдает. В качестве синонима слова "аутентификация" иногда используют словосочетание "проверка подлинности". (Заметим в скобках, что происхождение русскоязычного термина "аутентификация" не совсем понятно. Английское "authentication" скорее можно прочитать как "аутентикация"; трудно сказать, откуда в середине взялось еще "фи" - может, из идентификации? Тем не менее, термин устоялся, он закреплен в Руководящих документах Гостехкомиссии России, использован в многочисленных публикациях, поэтому исправить его уже невозможно.)
Аутентификация бывает односторонней (обычно клиент доказывает свою подлинность серверу) и двусторонней (взаимной). Пример односторонней аутентификации - процедура входа пользователя в систему. В сетевой среде, когда стороны идентификации/аутентификации территориально разнесены, у рассматриваемого сервиса есть два основных аспекта: что служит аутентификатором (то есть используется для подтверждения подлинности субъекта); как организован (и защищен) обмен данными идентификации/аутентификации.
Субъект может подтвердить свою подлинность, предъявив по крайней мере одну из следующих сущностей: нечто, что он знает (пароль, личный идентификационный номер, криптографический ключ и т.п.); нечто, чем он владеет (личную карточку или иное устройство аналогичного назначения); нечто, что есть часть его самого (голос, отпечатки пальцев и т.п., то есть свои биометрические характеристики).
В открытой сетевой среде между сторонами идентификации/аутентификации не существует доверенного маршрута; это значит, что в общем случае данные, переданные субъектом, могут не совпадать с данными, полученными и использованными для проверки подлинности. Необходимо обеспечить защиту от пассивного и активного прослушивания сети, то есть от перехвата, изменения и/или воспроизведения данных. Передача паролей в открытом виде, очевидно, неудовлетворительна; не спасает положение и шифрование паролей, так как оно не защищает от воспроизведения. Нужны более сложные протоколы аутентификации.
Надежная идентификация и затруднена не только из-за сетевых угроз, но и по целому ряду причин. Во-первых, почти все аутентификационные сущности можно узнать, украсть или подделать. Во-вторых, имеется противоречие между надежностью аутентификации, с одной стороны, и удобствами пользователя и системного администратора с другой. Так, из соображений безопасности необходимо с определенной частотой просить пользователя повторно вводить аутентификационную информацию (ведь на его место мог сесть другой человек), а это не только хлопотно, но и повышает вероятность того, что кто-то может подсмотреть за вводом данных. В-третьих, чем надежнее средство защиты, тем оно дороже.
Современные средства идентификации/аутентификации должны поддерживать концепцию единого входа в сеть. Единый вход в сеть - это, в первую очередь, требование удобства для пользователей. Если в корпоративной сети много информационных сервисов, допускающих независимое обращение, то многократная идентификация/аутентификация становится слишком обременительной. К сожалению, пока нельзя сказать, что единый вход в сеть стал нормой, доминирующие решения пока не сформировались.
Таким образом, необходимо искать компромисс между надежностью, доступностью по цене и удобством использования и администрирования средств идентификации и аутентификации.
Любопытно отметить, что сервис идентификации / аутентификации может стать объектом атак на доступность.Если система сконфигурирована так, что после определенного числа неудачных попыток устройство ввода идентификационной информации (такое, например, как терминал) блокируется, то злоумышленник может остановить работу легального пользователя буквально несколькими нажатиями клавиш.
идентификатор субъекта ( идентификатор пользователя, сетевой адрес компьютера и т.п.). Подобные идентификаторы являются основой произвольного (или дискреционного) управления доступом; атрибуты субъекта (метка безопасности, группа пользователя и т.п.). Метки безопасности - основа принудительного (мандатного) управления доступом.
Матрицу доступа, ввиду ее разреженности (большинство клеток - пустые), неразумно хранить в виде двухмерного массива. Обычно ее хранят по столбцам, то есть для каждого объекта поддерживается список "допущенных" субъектов вместе с их правами. Элементами списков могут быть имена групп и шаблоны субъектов, что служит большим подспорьем администратору. Некоторые проблемы возникают только при удалении субъекта, когда приходится удалять его имя из всех списков доступа; впрочем, эта операция производится нечасто.
Списки доступа - исключительно гибкое средство. С их помощью легко выполнить требование о гранулярности прав с точностью до пользователя. Посредством списков несложно добавить права или явным образом запретить доступ (например, чтобы наказать нескольких членов группы пользователей). Безусловно, списки являются лучшим средством произвольного управления доступом.
Подавляющее большинство операционных систем и систем управления базами данных реализуют именно произвольное управление доступом. Основное достоинство произвольного управления - гибкость. Вообще говоря, для каждой пары "субъект-объект" можно независимо задавать права доступа (особенно легко это делать, если используются списки управления доступом). К сожалению, у "произвольного" подхода есть ряд недостатков. Рассредоточенность управления доступом ведет к тому, что доверенными должны быть многие пользователи, а не только системные операторы или администраторы. Из-за рассеянности или некомпетентности сотрудника, владеющего секретной информацией, эту информацию могут узнать и все остальные пользователи. Следовательно, произвольность управления должна быть дополнена жестким контролем за реализацией избранной политики безопасности.
Второй недостаток, который представляется основным, состоит в том, что права доступа существуют отдельно от данных. Ничто не мешает пользователю, имеющему доступ к секретной информации, записать ее в доступный всем файл или заменить полезную утилиту ее "троянским" аналогом. Подобная "разделенность" прав и данных существенно осложняет проведение несколькими системами согласованной политики безопасности и, главное, делает практически невозможным эффективный контроль согласованности.
Возвращаясь к вопросу представления матрицы доступа, укажем, что для этого можно использовать также функциональный способ, когда матрицу не хранят в явном виде, а каждый раз вычисляют содержимое соответствующих клеток. Например, при принудительном управлении доступом применяется сравнение меток безопасности субъекта и объекта.
Удобной надстройкой над средствами логического управления доступом является ограничивающий интерфейс, когда пользователя лишают самой возможности попытаться совершить несанкционированные действия, включив в число видимых ему объектов только те, к которым он имеет доступ. Подобный подход обычно реализуют в рамках системы меню (пользователю показывают лишь допустимые варианты выбора) или посредством ограничивающих оболочек, таких как restricted shell в ОС Unix.
В заключение подчеркнем важность управления доступом не только на уровне операционной системы, но и в рамках других сервисов, входящих в состав современных приложений, а также, насколько это возможно, на "стыках" между сервисами. Здесь на первый план выходит существование единой политики безопасности организации, а также квалифицированное и согласованное системное администрирование.
Парольная аутентификация
Главное достоинство парольной аутентификации - простота и привычность. Пароли давно встроены в операционные системы и иные сервисы. При правильном использовании пароли могут обеспечить приемлемый для многих организаций уровень безопасности. Тем не менее, по совокупности характеристик их следует признать самым слабым средством проверки подлинности. Чтобы пароль был запоминающимся, его зачастую делают простым (имя подруги, название спортивной команды и т.п.). Однако простой пароль нетрудно угадать, особенно если знать пристрастия данного пользователя. Известна классическая история про советского разведчика Рихарда Зорге, объект внимания которого через слово говорил "карамба"; разумеется, этим же словом открывался сверхсекретный сейф. Иногда пароли с самого начала не хранятся в тайне, так как имеют стандартные значения, указанные в документации, и далеко не всегда после установки системы производится их смена. Ввод пароля можно подсмотреть. Иногда для подглядывания используются даже оптические приборы. Пароли нередко сообщают коллегам, чтобы те могли, например, подменить на некоторое время владельца пароля. Теоретически в подобных случаях более правильно задействовать средства управления доступом, но на практике так никто не поступает; а тайна, которую знают двое, это уже не тайна. Пароль можно угадать "методом грубой силы", используя, скажем, словарь. Если файл паролей зашифрован, но доступен для чтения, его можно скачать к себе на компьютер и попытаться подобрать пароль, запрограммировав полный перебор (предполагается, что алгоритм шифрования известен). Тем не менее, следующие меры позволяют значительно повысить надежность парольной защиты:
наложение технических ограничений (пароль должен быть не слишком коротким, он должен содержать буквы, цифры, знаки пунктуации и т.п.);
управление сроком действия паролей, их периодическая смена; ограничение доступа к файлу паролей; ограничение числа неудачных попыток входа в систему (это затруднит применение "метода грубой силы"); обучение пользователей; использование программных генераторов паролей (такая программа, основываясь на несложных правилах, может порождать только благозвучные и, следовательно, запоминающиеся пароли). Перечисленные меры целесообразно применять всегда, даже если наряду с паролями используются другие методы аутентификации.
Ролевое управление доступом
При большом количестве пользователей традиционные подсистемы управления доступом становятся крайне сложными для администрирования. Число связей в них пропорционально произведению количества пользователей на количество объектов. Необходимы решения в объектно-ориентированном стиле, способные эту сложность понизить. Таким решением является ролевое управление доступом (РУД). Суть его в том, что между пользователями и их привилегиями появляются промежуточные сущности - роли. Для каждого пользователя одновременно могут быть активными несколько ролей, каждая из которых дает ему определенные права (см. рис. 10.2).
 Рис. 10.2.
Пользователи, объекты и роли. Ролевой доступ нейтрален по отношению к конкретным видам прав и способам их проверки; его можно рассматривать как объектно-ориентированный каркас, облегчающий администрирование, поскольку он позволяет сделать подсистему разграничения доступа управляемой при сколь угодно большом числе пользователей, прежде всего за счет установления между ролями связей, аналогичных наследованию в объектно-ориентированных системах. Кроме того, ролей должно быть значительно меньше, чем пользователей. В результате число администрируемых связей становится пропорциональным сумме (а не произведению) количества пользователей и объектов, что по порядку величины уменьшить уже невозможно. Ролевой доступ развивается более 10 лет (сама идея ролей, разумеется, значительно старше) как на уровне операционных систем, так и в рамках СУБД и других информационных сервисов. В частности, существуют реализации ролевого доступа для Web-серверов. В 2001 году Национальный институт стандартов и технологий США предложил проект стандарта ролевого управления доступом (см. http://csrc.nist.gov/rbac/), основные положения которого мы и рассмотрим. Ролевое управление доступом оперирует следующими основными понятиями:
пользователь (человек, интеллектуальный автономный агент и т.п.);
сеанс работы пользователя;
роль (обычно определяется в соответствии с организационной структурой);
объект (сущность, доступ к которой разграничивается; например, файл ОС или таблица СУБД);
операция (зависит от объекта; для файлов ОС - чтение, запись, выполнение и т.п.; для таблиц СУБД - вставка, удаление и т.п., для прикладных объектов операции могут быть более сложными); право доступа (разрешение выполнять определенные операции над определенными объектами).
Ролям приписываются пользователи и права доступа; можно считать, что они (роли) именуют отношения "многие ко многим" между пользователями и правами. Роли могут быть приписаны многим пользователям; один пользователь может быть приписан нескольким ролям. Во время сеанса работы пользователя активизируется подмножество ролей, которым он приписан, в результате чего он становится обладателем объединения прав, приписанных активным ролям. Одновременно пользователь может открыть несколько сеансов.
Между ролями может быть определено отношение частичного порядка, называемое наследованием. Если роль r2 является наследницей r1, то все права r1 приписываются r2, а все пользователи r2 приписываются r1. Очевидно, что наследование ролей соответствует наследованию классов в объектно-ориентированном программировании, только правам доступа соответствуют методы классов, а пользователям - объекты (экземпляры) классов.
Отношение наследования является иерархическим, причем права доступа и пользователи распространяются по уровням иерархии навстречу друг другу. В общем случае наследование является множественным, то есть у одной роли может быть несколько предшественниц (и, естественно, несколько наследниц, которых мы будем называть также преемницами).
Можно представить себе формирование иерархии ролей, начиная с минимума прав (и максимума пользователей), приписываемых роли "сотрудник", с постепенным уточнением состава пользователей и добавлением прав (роли "системный администратор", "бухгалтер" и т.п.), вплоть до роли "руководитель" (что, впрочем, не значит, что руководителю предоставляются неограниченные права; как и другим ролям, в соответствии с принципом минимизации привилегий, этой роли целесообразно разрешить только то, что необходимо для выполнения служебных обязанностей).
Фрагмент подобной иерархии ролей показан на рис. 10.3.
 Рис. 10.3.
Фрагмент иерархии ролей.
Для реализации еще одного упоминавшегося ранее важного принципа информационной безопасности вводится понятие разделения обязанностей, причем в двух видах: статическом и динамическом.
Статическое разделение обязанностей налагает ограничения на приписывание пользователей ролям. В простейшем случае членство в некоторой роли запрещает приписывание пользователя определенному множеству других ролей. В общем случае данное ограничение задается как пара "множество ролей - число" (где множество состоит, по крайней мере, из двух ролей, а число должно быть больше 1), так что никакой пользователь не может быть приписан указанному (или большему) числу ролей из заданного множества. Например, может существовать пять бухгалтерских ролей, но политика безопасности допускает членство не более чем в двух таких ролях (здесь число=3).
При наличии наследования ролей ограничение приобретает несколько более сложный вид, но суть остается простой: при проверке членства в ролях нужно учитывать приписывание пользователей ролям-наследницам.
Динамическое разделение обязанностей отличается от статического только тем, что рассматриваются роли, одновременно активные (быть может, в разных сеансах) для данного пользователя (а не те, которым пользователь статически приписан). Например, один пользователь может играть роль и кассира, и контролера, но не одновременно; чтобы стать контролером, он должен сначала закрыть кассу. Тем самым реализуется так называемое временное ограничение доверия, являющееся аспектом минимизации привилегий.
Рассматриваемый проект стандарта содержит спецификации трех категорий функций, необходимых для администрирования РУД:
Административные функции (создание и сопровождение ролей и других атрибутов ролевого доступа): создать/удалить роль/пользователя, приписать пользователя/право роли или ликвидировать существующую ассоциацию, создать/удалить отношение наследования между существующими ролями, создать новую роль и сделать ее наследницей/предшественницей существующей роли, создать/удалить ограничения для статического/динамического разделения обязанностей.
Вспомогательные функции (обслуживание сеансов работы пользователей): открыть сеанс работы пользователя с активацией подразумеваемого набора ролей; активировать новую роль, деактивировать роль; проверить правомерность доступа.
Информационные функции (получение сведений о текущей конфигурации с учетом отношения наследования). Здесь проводится разделение на обязательные и необязательные функции. К числу первых принадлежат получение списка пользователей, приписанных роли, и списка ролей, которым приписан пользователь.
Все остальные функции отнесены к разряду необязательных. Это получение информации о правах, приписанных роли, о правах заданного пользователя (которыми он обладает как член множества ролей), об активных в данный момент сеанса ролях и правах, об операциях, которые роль/пользователь правомочны совершить над заданным объектом, о статическом/динамическом разделении обязанностей.
Можно надеяться, что предлагаемый стандарт поможет сформировать единую терминологию и, что более важно, позволит оценивать РУД-продукты с единых позиций, по единой шкале.
Сервер аутентификации Kerberos
Kerberos - это программный продукт, разработанный в середине 1980-х годов в Массачусетском технологическом институте и претерпевший с тех пор ряд принципиальных изменений. Клиентские компоненты Kerberos присутствуют в большинстве современных операционных систем. Kerberos предназначен для решения следующей задачи. Имеется открытая (незащищенная) сеть, в узлах которой сосредоточены субъекты - пользователи, а также клиентские и серверные программные системы. Каждый субъект обладает секретным ключом. Чтобы субъект C мог доказать свою подлинность субъекту S (без этого S не станет обслуживать C), он должен не только назвать себя, но и продемонстрировать знание секретного ключа. C не может просто послать S свой секретный ключ, во-первых, потому, что сеть открыта (доступна для пассивного и активного прослушивания), а, во-вторых, потому, что S не знает (и не должен знать) секретный ключ C. Требуется менее прямолинейный способ демонстрации знания секретного ключа. Система Kerberos представляет собой доверенную третью сторону (то есть сторону, которой доверяют все), владеющую секретными ключами обслуживаемых субъектов и помогающую им в попарной проверке подлинности. Чтобы с помощью Kerberos получить доступ к S (обычно это сервер), C (как правило - клиент) посылает Kerberos запрос, содержащий сведения о нем (клиенте) и о запрашиваемой услуге. В ответ Kerberos возвращает так называемый билет, зашифрованный секретным ключом сервера, и копию части информации из билета, зашифрованную секретным ключом клиента. Клиент должен расшифровать вторую порцию данных и переслать ее вместе с билетом серверу. Сервер, расшифровав билет, может сравнить его содержимое с дополнительной информацией, присланной клиентом. Совпадение свидетельствует о том, что клиент смог расшифровать предназначенные ему данные (ведь содержимое билета никому, кроме сервера и Kerberos, недоступно), то есть продемонстрировал знание секретного ключа. Значит, клиент - именно тот, за кого себя выдает. Подчеркнем, что секретные ключи в процессе проверки подлинности не передавались по сети (даже в зашифрованном виде) - они только использовались для шифрования.
Как организован первоначальный обмен ключами
между Kerberos и субъектами и как субъекты хранят свои секретные ключи - вопрос отдельный.
Проиллюстрируем описанную процедуру.
 Рис. 10.1.
Проверка сервером S подлинности клиента C.
Здесь c и s - сведения (например, имя), соответственно, о клиенте и сервере, d1 и d2 - дополнительная (по отношению к билету) информация, Tc.s - билет для клиента C на обслуживание у сервера S, Kc и Ks - секретные ключи клиента и сервера, {info}K - информация info, зашифрованная ключом K.
Приведенная схема - крайне упрощенная версия реальной процедуры проверки подлинности. Более подробное рассмотрение системы Kerberos можно найти, например, в статье В. Галатенко "Сервер аутентификации Kerberos (Jet Info, 1996, 12-13). Нам же важно отметить, что Kerberos не только устойчив к сетевым угрозам, но и поддерживает концепцию единого входа в сеть.
Управление доступом в Java-среде
Java - это объектно-ориентированная система программирования, поэтому и управление доступом в ней спроектировано и реализовано в объектном стиле. По этой причине рассмотреть Java-среду для нас очень важно. Подробно о Java-технологии и безопасности Java-среды рассказано в статье А. Таранова и В. Цишевского "Java в три года" (Jet Info, 1998, 11-12). С разрешения авторов далее используются ее фрагменты. Прежде всего, остановимся на эволюции модели безопасности Java. В JDK 1.0 была предложена концепция "песочницы" (sandbox) - замкнутой среды, в которой выполняются потенциально ненадежные программы (апплеты, поступившие по сети). Программы, располагающиеся на локальном компьютере, считались абсолютно надежными, и им было доступно все, что доступно виртуальной Java-машине. В число ограничений, налагаемых "песочницей", входит запрет на доступ к локальной файловой системе, на сетевое взаимодействие со всеми хостами, кроме источника апплета, и т.п. Независимо от уровня достигаемой при этом безопасности (а проблемы возникали и с разделением свой/чужой, и с определением источника апплета), наложенные ограничения следует признать слишком обременительными: возможности для содержательных действий у апплетов почти не остается. Чтобы справиться с этой проблемой, в JDK 1.1 ввели деление источников (точнее, распространителей) апплетов на надежные и ненадежные (источник определялся по электронной подписи). Надежные апплеты приравнивались в правах к "родному" коду. Сделанное послабление решило проблемы тех, кому прав не хватало, но защита осталась неэшелонированной и, следовательно, неполной. В JDK 1.2 сформировалась модель безопасности, используемая и в Java 2. От модели "песочницы" отказались. Оформились три основных понятия:
источник программы; право и множество прав;
политика безопасности.
Источник программы определяется парой (URL, распространители программы). Последние задаются набором цифровых сертификатов. Право - это абстрактное понятие, за которым, как и положено в объектной среде, стоят классы и объекты.
В большинстве случаев право определяется двумя цепочками символов - именем ресурса и действием. Например, в качестве ресурса может выступать файл, а в качестве действия - чтение. Важнейшим методом "правовых" объектов является implies(). Он проверяет, следует ли одно право (запрашиваемое) из другого (имеющегося).
Политика безопасности задает соответствие между источником и правами поступивших из него программ (формально можно считать, что каждому источнику соответствует своя "песочница"). В JDK 1.2 "родные" программы не имеют каких-либо привилегий в плане безопасности, и политика по отношению к ним может быть любой. В результате получился традиционный для современных ОС и СУБД механизм прав доступа со следующими особенностями:
Java-программы выступают не от имени пользователя, их запустившего, а от имени источника программы. (Это весьма глубокая и прогрессивная трактовка, если ее правильно развить, см. следующий раздел); нет понятия владельца ресурсов, который мог бы менять права; последние задаются исключительно политикой безопасности (формально можно считать, что владельцем всего является тот, кто формирует политику); механизмы безопасности снабжены объектной оберткой.
Весьма важным понятием в модели безопасности JDK 1.2 является контекст выполнения. Когда виртуальная Java-машина проверяет права доступа объекта к системному ресурсу, она рассматривает не только текущий объект, но и предыдущие элементы стека вызовов. Доступ предоставляется только тогда, когда нужным правом обладают все объекты в стеке. Разработчики Java называют это реализацией принципа минимизации привилегий.
На первый взгляд, учет контекста представляется логичным. Нельзя допускать, чтобы вызов какого-либо метода расширял права доступа хотя бы по той причине, что доступ к системным ресурсам осуществляется не напрямую, а с помощью системных объектов, имеющих все права.
К сожалению, подобные доводы противоречат одному из основных принципов объектного подхода - принципу инкапсуляции.
Если объект A обращается к объекту B, он не может и не должен знать, как реализован B и какими ресурсами он пользуется для своих целей. Если A имеет право вызывать какой-либо метод B с некоторыми значениями аргументов, B обязан обслужить вызов. В противном случае при формировании политики безопасности придется учитывать возможный граф вызовов объектов, что, конечно же, нереально.
Разработчики Java осознавали эту проблему. Чтобы справиться с ней, они ввели понятие привилегированного интервала программы. При выполнении такого интервала контекст игнорируется. Привилегированная программа отвечает за себя, не интересуясь предысторией. Аналогом привилегированных программ являются файлы с битами переустановки идентификатора пользователя/группы в ОС Unix, что лишний раз подтверждает традиционность подхода, реализованного в JDK 1.2. Известны угрозы безопасности, которые привносят подобные файлы. Теперь это не лучшее средство ОС Unix перекочевало в Java.
Рассмотрим дисциплину контроля прав доступа более формально.
Класс AccessController (встроенный менеджер безопасности) предоставляет единый метод для проверки заданного права в текущем контексте - checkPermission (Permission). Это лучше (по причине параметризуемости), чем множество методов вида checkXXX, присутствующих в SecurityManager - динамически изменяемом менеджере безопасности из ранних версий JDK.
Пусть текущий контекст выполнения состоит из N стековых фреймов (верхний соответствует методу, вызвавшему checkPermission(p)). Метод checkPermission реализует следующий алгоритм (см. Листинг 10.1).
i = N; while (i > 0) { if (метод, породивший i-й фрейм, не имеет проверяемого права) { throw AccessControlException } else if (i-й фрейм помечен как привилегированный) { return; } i = i - 1; }; // Выясним, есть ли проверяемое право у унаследованного контекста inheritedContext.checkPermission (p);
Листинг 10.1. Алгоритм работы метода checkPermission класса AccessController. (, )
Сначала в стеке ищется фрейм, не обладающий проверяемым правом.
Проверка производится до тех пор, пока либо не будет исчерпан стек, либо не встретится "привилегированный" фрейм, созданный в результате обращения к методу doPrivileged(PrivilegedAction) класса AccessController. Если при порождении текущего потока выполнения был сохранен контекст inheritedContext, проверяется и он. При положительном результате проверки метод checkPermission(p) возвращает управление, при отрицательном возникает исключительная ситуация AccessControlException.
Выбранный подход имеет один недостаток - тяжеловесность реализации. В частности, при порождении нового потока управления с ним приходится ассоциировать зафиксированный "родительский" контекст и, соответственно, проверять последний в процессе контроля прав доступа.
Отметим, что этот подход не распространяется на распределенный случай (хотя бы потому, что контекст имеет лишь локальный смысл, как, впрочем, и политика безопасности).
В целом средства управления доступом в JDK 1.2 можно оценить как "наполовину объектные". Реализация оформлена в виде интерфейсов и классов, однако по-прежнему разграничивается доступ к необъектным сущностям - ресурсам в традиционном понимании. Не учитывается семантика доступа. Имеют место и другие отмеченные выше концептуальные проблемы.
Возможный подход к управлению доступом в распределенной объектной среде
Представляется, что в настоящее время проблема управления доступом существует в трех почти не связанных между собой проявлениях: традиционные модели (дискреционная и мандатная); модель "песочница" (предложенная для Java-среды и близкой ей системы Safe-Tcl); модель фильтрации (используемая в межсетевых экранах).
На наш взгляд, необходимо объединить существующие подходы на основе их развития и обобщения. Формальная постановка задачи разграничения доступа может выглядеть следующим образом. Рассматривается множество объектов (в смысле объектно-ориентированного программирования). Часть объектов может являться контейнерами, группирующими объекты-компоненты, задающими для них общий контекст, выполняющими общие функции и реализующими перебор компонентов. Контейнеры либо вложены друг в друга, либо не имеют общих компонентов. С каждым объектом ассоциирован набор интерфейсов, снабженных дескрипторами (ДИ). К объекту можно обратиться только посредством ДИ. Разные интерфейсы могут предоставлять разные методы и быть доступными для разных объектов. Каждый контейнер позволяет опросить набор ДИ объектов-компонентов, удовлетворяющих некоторому условию. Возвращаемый результат в общем случае зависит от вызывающего объекта. Объекты изолированы друг от друга. Единственным видом межобъектного взаимодействия является вызов метода. Предполагается, что используются надежные средства аутентификации и защиты коммуникаций. В плане разграничения доступа локальные и удаленные вызовы не различаются. Предполагается также, что разрешение или запрет на доступ не зависят от возможного параллельного выполнения методов (синхронизация представляет отдельную проблему, которая здесь не рассматривается). Разграничивается доступ к интерфейсам объектов, а также к методам объектов (с учетом значений фактических параметров вызова). Правила разграничения доступа (ПРД) задаются в виде предикатов над объектами. Рассматривается задача разграничения доступа для выделенного контейнера CC, компонентами которого должны являться вызывающий и/или вызываемый объекты.
ДИ этого контейнера полагается общеизвестным. Считается также, что между внешними по отношению к выделенному контейнеру объектами возможны любые вызовы.
Выполнение ПРД контролируется монитором обращений.
При вызове метода мы будем разделять действия, производимые вызывающим объектом (инициация вызова) и вызываемым методом (прием и завершение вызова).
При инициации вызова может производиться преобразование ДИ фактических параметров к виду, доступному вызываемому методу ("трансляция интерфейса"). Трансляция может иметь место, если вызываемый объект не входит в тот же контейнер, что и вызывающий.
Параметры методов могут быть входными и/или выходными. При приеме вызова возникает информационный поток из входных параметров в вызываемый объект. В момент завершения вызова возникает информационный поток из вызываемого объекта в выходные параметры. Эти потоки могут фигурировать в правилах разграничения доступа.
Структурируем множество всех ПРД, выделив четыре группы правил:
политика безопасности контейнера; ограничения на вызываемый метод; ограничения на вызывающий метод;
добровольно налагаемые ограничения.
Правила, общие для всех объектов, входящих в контейнер C, назовем политикой безопасности данного контейнера.
Пусть метод M1 объекта O1 в точке P1 своего выполнения должен вызвать метод M объекта O. Правила, которым должен удовлетворять M, можно разделить на четыре следующие подгруппы:
правила, описывающие требования к формальным параметрам вызова; правила, описывающие требования к семантике M; реализационные правила, накладывающие ограничения на возможные реализации M; правила, накладывающие ограничения на вызываемый объект O.
Метод M объекта O, потенциально доступный для вызова, может предъявлять к вызывающему объекту следующие группы требований:
правила, описывающие требования к фактическим параметрам вызова; правила, накладывающие ограничения на вызывающий объект.
Можно выделить три разновидности предикатов, соответствующих семантике и/или особенностям реализации методов:
утверждения о фактических параметрах вызова метода M в точке P1; предикат, описывающий семантику метода M; предикат, описывающий особенности реализации метода M.
Перечисленные ограничения можно назвать добровольными, поскольку они соответствуют реальному поведению объектов и не связаны с какими-либо внешними требованиями.
Предложенная постановка задачи разграничения доступа соответствует современному этапу развития программирования, она позволяет выразить сколь угодно сложную политику безопасности, найти баланс между богатством выразительных возможностей и эффективностью работы монитора обращений.
Информационная безопасность
База данных СКС
База данных СКС - это, пожалуй, один их самых востребованных компонентов Системы Обнаружения Несанкционированных Подключений. При ее наличии Сервер Мониторинга на этапе анализа SNMP сообщения может по номеру порта сетевого коммутатора с точностью до настенной розетки определить вероятное месторасположение подключенного компьютера.
К сожалению, не во всякой компании ведется строгий учет соединений СКС. В этом случае можно начать с реализации БД СКС в виде простого файла, содержащего IP адрес коммутатора и описание его месторасположения и обслуживаемых им помещений. Таким образом, на первом этапе, удастся локализовать месторасположение искомого подключения.
Другие возможности
Однако, на этом возможности СОНП не ограничиваются. Используя рассмотренный выше алгоритм, как основу, несложно использовать Систему для выполнения следующих функций.
От мониторинга к проактивному управлению:
При обнаружении запрещенного подключения СОНП автоматически выключает соответствующий порт коммутатора. При обнаружении нового подключения СОНП автоматически помещает соответствующий порт коммутатора в гостевой VLAN.
Интеграция с другими системами:
Система заявок - ИТ регистрирует заявку на новый компьютер. После одобрения заявки службой информационной безопасности информация о новом разрешенном соединении автоматически заносится в БД Соединений. Система заявок - при возникновении тревожного события соответствующий инцидент автоматически генерируется в системе регистрации заявок и направляется на исполнение службе информационной безопасности. БД СКС, поэтажные планы - вывод информации о месторасположении несанкционированного подключения на поэтажном плане. Базы данных учета компьютерного оборудования и СКС - при регистрации нового разрешенного соединения информация о подключенном компьютере автоматически заносится в БД учета компьютерного оборудования и БД СКС.
Ведение журналов истории соединений:
Ведение истории физического перемещения устройств в сети. Ведение журнала включений и выключений устройств в сети.
Конечно, при проектировании и реализации подобной системы необходимо отталкиваться в первую очередь от запросов клиента - службы Информационной Безопасности компании. Если какие-то из описанных выше функций уже реализованы с помощью других информационных систем, то остается только с умом воспользоваться уже имеющимися наработками. Если же в компании не внедрены сопутствующие системы (учета инцидентов, диспетчерского центра, управления СКС), то начать можно с реализации основной функции - обнаружения несанкционированных подключений к локальной сети компании.
Как можно полагаться на MAC-адреса?
Кое-кто предполагает, что идентификация соединения на основе MAC-адреса не может считаться достоверной. В целом, это утверждение можно считать верным, т.к. современные программные средства, доступные любому начинающему хакеру, позволяют с легкостью изменять MAC-адрес компьютера. Однако, существует несколько доводов в пользу выбранного метода.
Поскольку система знает все разрешенные MAC-адреса и хранит их привязку к портам сетевого оборудования, то для того, чтобы ее "обмануть" придется попотеть - найти компьютер уже подключенный в сеть, "украсть" его MAC-адрес (при этом, легальный компьютер необходимо отключить) и подключиться в тот же порт сетевого коммутатора. По-настоящему защищенную сеть можно создать только с использованием различных средств защиты на всех уровнях. Описанная в настоящей статье СОНП может выступать, как система раннего оповещения о возможном несанкционированном проникновении в сеть. Можно даже сравнить ее с интеллектуальной системой видеонаблюдения, постоянно записывающей изображение с камер, но включающей сигнал оповещения только в случае возникновения подозрительного движения.
Полное или частичное цитирование данной статьи запрещено
Обнаружение несанкционированных подключений к локальной сети в режиме реального времени
Многие крупные и средние компании, заботящиеся о своей информационной безопасности, наверняка сталкивались с проблемой обнаружения несанкционированных подключений к своей локальной сети. Ведь ни для кого не секрет, что 80% атак происходит изнутри компании и важной задачей хакера является подключение своего компьютера или шпионского устройства к сети компании.
Для эффективного решения этой задачи необходимо обеспечить работу системы обнаружения в режиме реального времени, причем информация о неавторизованном соединении должна содержать не только сетевые параметры (MAC адрес, IP адрес, VLAN, IP адрес и номер порта коммутатора), но и географическое расположение подключенного компьютера (здание, этаж, номер комнаты, номер розетки).
Ниже мы рассмотрим технологию построения Системы Обнаружения Несанкционированных Подключений (СОНП), основывающуюся на анализе нотификационных SNMP сообщений об изменении статуса порта, получаемых от сетевых коммутаторов, и определение неавторизованных подключений на основе отсутствия MAC адреса устройства в базе данных авторизованных хостов сети.
Обработка SNMP сообщений - ядро
SNMP сообщение, содержащее IP адрес коммутатора и номер вновь включившегося порта, посылается сетевым коммутатором на центральный сервер мониторинга при изменении статуса любого порта с "Выключен" на "Включен". Отправку таких сообщений поддерживают даже самые простые модели сетевых коммутаторов, поэтому реализовать инфраструктуру мониторинга всех портов локальной сети достаточно просто.
В качестве серверной части, обеспечивающей сбор SNMP сообщений, может выступать существующий в компании сервер сетевого мониторинга (HP OpenView, IBM Tivoli, Microsoft MOM, и т.п.).
Далее сообщение поступает на обработку, где производится определение (discovery) основных идентификационных параметров подключения.
Первым делом необходимо определить всю возможную информацию о новом соединении. Как показано на , в качестве источников информации о соединении могут быть сами сетевые коммутаторы, база данных СКС компании (о ней мы поговорим отдельно), а также база данных разрешенных соединений, в которой сохраняются все когда-либо обнаруженные подключения.
Анализ соединения позволяет определить важную информацию о сетевых свойствах (MAC адрес, IP адрес, VLAN, номер порта сетевого коммутатора, сетевое имя), и месторасположение подключенного компьютера.
После этого, с помощью базы данных соединений, хранящей информацию о соединениях и их статусе "Разрешено/Запрещено", производится проверка соединения на легитимность. Если обрабатываемое соединение зарегистрировано в базе, как разрешенное, то на этом его обработка завершается. Т.е. система просто игнорирует произошедшее события, расценивая его, как нормальную активность.
Если же соединение опознано как Запрещенное или неопознанное (новое) на консоль Администратора безопасности высылается Тревожное сообщение, а в БД Соединений заносится информация о факте нового или запрещенного соединения.
Почему SNMP?
В последнее время все большее распространение получает протокол 802.1x, обеспечивающий авторизацию любого подключаемого к сети компьютера. Почему не использовать 802.1х вместо SNMP. К сожалению, эта технология обладает рядом серьезных недостатков.
Во-первых, используя 802.1х практически невозможно обеспечить полное покрытие всей локальной сети предприятия. Все устройства в сети (включая активные сетевые устройства) должны поддерживать этот протокол. На сегодняшний день абсолютное большинство принтеров, сканеров, а также нестандартных сетевых устройств (системы видео-наблюдения и т.п.) не поддерживают 802.1х. Для подключения их к сети приходится либо организовывать выделенные сети (что не всегда удобно, например, для принтеров), либо отключать авторизацию 802.1х на портах активного сетевого оборудования, к которым подключены эти устройства. Таким образом, злоумышленнику достаточно найти сетевой принтер или другое устройство, которое не поддерживает авторизацию 802.1х и подключить туда свой компьютер - поскольку авторизация на этом сетевом порту не включена, то определить или запретить это подключение не удается.
Кроме того, протокол 802.1х не обладает собственными средствами мониторинга, т.е. служба информационной безопасности не может получить сигнала о том, что в каком-либо месте сети произошла попытка неавторизованного подключения.
И наконец, протокол 802.1х требует для своей реализации построения инфраструктуры PKI в масштабах всей локальной сети, что само по себе является достаточно трудоемкой задачей.
Рабочее место Администратора Безопасности
Уведомление Администратора Безопасности может быть реализовано любым из множества доступных способов. Например, если в компании реализован диспетчерский центр на базе таких продуктов, как HP OpenView, IBM Tivoli или Microsoft MOM, то можно выводить уведомления на консоль диспетчера. Другими возможными вариантами являются уведомления по электронной почте, SMS, всплывающие сообщения на экран рабочей станции Администратора безопасности.
По получении уведомления, Администратор Безопасности должен иметь возможность просмотреть детали соединения, чтобы принять решение о его разрешении или запрещении. В этот момент Администратор Безопасности может либо осуществить физическую проверку подключенного компьютера, имея информацию о расположении подключенного компьютера внутри здания, либо, обладая данными о сетевых параметрах подключения, запросить службу IT о легитимности нахождения данного устройства в корпоративной сети.
При положительном решении Администратор безопасности регистрирует Соединение, как разрешенное. Информация об этом заносится в БД Соединений.
Если данное соединение рассматривается, как нежелательное, предпринимаются соответствующие административные меры, а информация об устройстве заносится в БД соединений с пометкой "Запрещенное". Любое последующее подключение этого устройства в сеть вызовет тревожное уведомление.
Информационная безопасность
Чем измерить безопасность Интернет?
Статья была опубликована в журнале "Технологии и средства связи"
Мир реальный
Угроза терроризма растет с каждым днем и, понимая это, Министерство национальной безопасности США (Homeland Security Department) в 2002 году разработало специальную шкалу (), позволяющую любому человеку в мгновение ока оценить текущий уровень угрозы со стороны террористов. Эта шкала содержит 5 уровней, названных "состояниями угрозы" () и которые описывают текущий уровень риска террористических атак. Самый безопасный, нижний, уровень (Low Condition) присваивается, когда опасность террористических атак невелика. Самый высокий и, значит, опасный, уровень - пятый (Severe Condition). Самый яркий пример, когда мог быть назначен этот уровень - 11 сентября 2001 года в США или 23 октября 2002 года в Москве.
Такая шкала - не изобретение Министерство национальной безопасности. До него ее активно использовало и использует до сих пор Министерство Обороны США. Те же 5 уровней угрозы получили название - , позже переименованные в FPCON (Force Protection Condition). Отсутствие угрозы получило название - Normal, а реальная угроза со стороны террористов именуется - Delta (между этими уровнями также существуют Alpha, Bravo и Charlie).
Мир виртуальный
Однако угрозу обычного терроризма я оставлю за рамками данной статьи и сконцентрируюсь на кибертерроризме, который также все чаще поднимает голову. Все большее число традиционных и электронных СМИ пестрят сообщениями о той или иной проделке хакеров - от взлома сайта никому неизвестной компании "Голохвостов и компания" до проникновения в сети ядерных центров (см. статью ). Хуже того. Даже обычный домашний пользователь может стать жертвой кибертеррористов, т.к. различные эпидемии захлестывают Интернет все чаще и чаще. RedCode, Nimda, Klez, Slammer… Как долго это будет продолжаться и как рядовой пользователь Интернет может противодействовать этой угрозе?
Не надо изобретать велосипед. Идею можно позаимствовать у спецслужб и перенести систему оповещения об уровне угрозы в виртуальный мир. Некоторые известные в мире информационной безопасности компании так и поступили и теперь любой администратор или домашний пользователь может заранее узнать о возможной эпидемии или массовой атаке и соответствующим образом подготовить к ней свою или сеть или компьютер.
На сегодняшний день можно выделить 3 основных источника информации об уровне защищенности Интернет. Первой по праву идет компания , которая уже не первый год поддерживает ежедневно обновляемый сервис , который не только позволяет оценить текущий уровень киберугрозы, но и понять, почему группа экспертов X-Force компании ISS приняла такое решение. Ключевым достоинством AlertCon является наличие рекомендаций, позволяющих быстро устранить причину проблемы.
Вторым источником информации об уровне угроз в Интернет можно назвать широко известный специалистам сайт , который был в прошлом году куплен компанией Symantec. Данный сервис, немудрствуя лукаво был назван , как и аналогичная шкала Министерства Обороны. Он , также как и AlertCon, содержит 4 постепенно нарастающих уровня угрозы - от нижнего до экстремального. Единственное отличие Symantec ThreatCon от ISS AlertCon - в отсутствии рекомендаций по защите своей сети.
Третьим по эффективности можно назвать сервис Infocon, поддерживаемый центром анализа Internet-атак . Данный сервис также как и другие информирует пользователей о текущем уровне угрозы, но не содержит ни подробного описания текущего состояния безопасности Интернет, ни тем более рекомендаций по защите. Однако, хотя сервис Infocon и не столь информативен, этот недостаток компенсируется сайтом центра, на котором специалист по информационной безопасности найдет много интересного - начиная от наиболее часто атакуемых сервисов и портов и заканчивая регулярно обновляемым списком адресов злоумышленников. Аналогичную информацию предоставляет и компании Symantec и Internet Security Systems. Первая предлагает услугу , а вторая - . Однако данные услуги не бесплатны и доступны только зарегистрированным пользователям. Однако в отличие от Internet Storm Center компании ISS и Symantec предлагают информацию персонифицированную для конкретного пользователя, например, все атаки и уязвимости для ПО, используемого заказчиком.
Учитывая постоянный рост числа инцидентов, хакерских атак и эпидемий червей хотелось бы, чтобы и в России появился аналогичный сервис, облегчающий отечественным пользователям Интернет анализ текущего уровня Интернет-безопасности.
Кстати, учитывая все возрастающую угрозу со стороны обычных террористов в России, отечественный спецслужбы также могли бы разработать инструмент аналогичный американскому Threat Advisory, облегчающему жизнь рядовому обывателю и позволяющему ему адекватно оценивать текущую опасность.
Информационная безопасность
Безопасность сети: то, что должен знать каждый
Елена Полонская, Обеспечение безопасности сети требует постоянной работы и пристального внимания к деталям. Пока "в Багдаде все спокойно", эта работа заключается в предсказании возможных действий злоумышленников, планировании мер защиты и постоянном обучении пользователей. Если же вторжение состоялось, то администратор безопасности должен обнаружить брешь в системе защиты, ее причину и метод вторжения Формируя политику обеспечения безопасности, администратор прежде всего проводит инвентаризацию ресурсов, защита которых планируется; идентифицирует пользователей, которым требуется доступ к каждому из этих ресурсов, и выясняет наиболее вероятные источники опасности для каждого из этих ресурсов. Имея эту информацию, можно приступать к построению политики обеспечения безопасности, которую пользователи будут обязаны выполнять. Политика обеспечения безопасности - это не обычные правила, которые и так всем понятны. Она должна быть представлена в форме серьезного печатного документа. А чтобы постоянно напоминать пользователям о важности обеспечения безопасности, можно разослать копии этого документа по всему офису, чтобы эти правила всегда были перед глазами сотрудников. Хорошая политика обеспечения безопасности включает несколько элементов, в том числе следующие: Оценка риска. Что именно мы защищаем и от кого? Нужно идентифицировать ценности, находящиеся в сети, и возможные источники проблем. Ответственность. Необходимо указать ответственных за принятие тех или иных мер по обеспечению безопасности, начиная от утверждения новых учетных записей и заканчивая расследованием нарушений. Правила использования сетевых ресурсов. В политике должно быть прямо сказано, что пользователи не имеют права употреблять информацию не по назначению, использовать сеть в личных целях, а также намеренно причинять ущерб сети или размещенной в ней информации. Юридические аспекты. Необходимо проконсультироваться с юристом и выяснить все вопросы, которые могут иметь отношение к хранящейся или генерируемой в сети информации, и включить эти сведения в документы по обеспечению безопасности. Процедуры по восстановлению системы защиты. Следует указать, что должно быть сделано в случае нарушения системы защиты и какие действия будут предприняты против тех, кто стал причиной такого нарушения.
Физическая безопасность
Предотвращение неавторизованного доступа к сетевым ресурсам означает, прежде всего, невозможность физического доступа к компонентам сети - рабочим станциям, серверам, сетевым кабелям и устройствам, и т.п. Когда сетевое соединение выходит за пределы вашей зоны влияния, например в точке подключения к внешнему провайдеру интернета, то контроль за физическими аспектами сети, разумеется, теряется - и остается полагаться на другие методы, такие как шифрование и туннелирование. Но оборудование в помещении компании должно находиться под пристальным наблюдением. Как бы глупо это ни звучало, но от несанкционированного доступа часто спасает простой дверной замок. Серверы, на которых хранятся важные или уязвимые данные, не должны стоять открыто на столе или в незапертой комнате, куда может зайти кто угодно. Аналогичным образом должны защищаться маршрутизаторы, концентраторы, коммутаторы и другие устройства. Комнаты с компьютерами должны закрываться на замок или находиться под круглосуточным наблюдением. Если кто-то из сотрудников компании работает круглосуточно, то это комнату закрывать не обязательно - но только в том случае, если персонал не дежурит по одному. В идеале доступ в подобные помещения должен контролироваться, например, путем регистрации в журнале. Резервные носители, такие как ленты или перезаписываемые компакт-диски, должны быть защищены так же, как и исходные данные. Недопустимо хранить резервные копии на сервере или рабочей станции, оставлять картриджи и CD на столе или в незапертом ящике.
Идентификация пользователей
Если в сети не хранятся сверхсекретные данные, то для доступа к ресурсам обычно достаточно логина и пароля. Управление такими системами обычно не представляет сложностей. В Windows 2000/XP и Server 2003 можно создавать обособленные защищенные зоны управления - домены. Сетевой администратор может предоставить пользователям домена права доступа к ресурсам любого компьютера, будь то сервер или рабочая станция. Кроме того, при сотрудничестве администраторов между доменами могут быть установлены доверительные отношения, в результате чего пользователи получат доступ к сетевым ресурсам другого домена по той же учетной записи и паролю. В Windows 2000 и более поздних версиях для разграничения доступа к важным ресурсам могут применяться групповые политики. В Novell NetWare для этого применяется служба Novel Directory Services, которая предоставляет пользователю регистрационное сетевое имя. Каждый пользователь представляется в каталоге объектом User, в свойствах которого содержится информация о его паролях и соединениях. В операционных системах Unix концепция домена отсутствует. Вместо этого каждый хост Unix содержит файл паролей, где хранится информация о каждом пользователе, включая шифрованный пароль. Для доступа к ресурсам других сетевых хостов пользователь Unix должен либо зарегистрироваться на этом компьютере, либо использовать прокси. Утилиты TCP/IP, такие как FTP и Telnet, часто пересылают пароли пользователей по сети открытым текстом и поэтому являются легкой добычей для хакера. В Unix для выполнения обычных сетевых операций, таких как копирование или печать файлов, или регистрация на удаленной системе, используются утилиты удаленной работы, обычно называемые r-командами (их имена начинаются буквой r). Такие утилиты очень полезны в сетевой среде, где один пользователь работает на нескольких компьютерах, но часто вызывают проблемы с безопасностью: ведь для выполнения команды на удаленном хосте пользователю достаточно иметь действительную для этого хоста учетную запись.
Вместо пароля право доступа определяется записью в файле /etc/hosts.equiv или.rhosts. Удаленный компьютер доверяет компьютеру, на котором пользователь выполняет r-команду, если находит в одном из этих файлов соответствующую запись. Каждая запись файла /etc/hosts.equiv содержит имя хоста и имя пользователя и позволяет идентифицировать пользователей и хосты, которым разрешено выполнять соответствующие команды. Поэтому ввода пароля не требуется. Считается, если пользователь зарегистрировался на удаленном хосте, то он уже прошел аутентификацию. Файл.rhosts работает подобным образом, но находится в домашнем каталоге пользователя. Удаленные пользователи, указанные в этом файле, могут выполнять действия на основании своих учетных записей.
Несмотря на то, что в большинстве операционных систем Unix и Linux сохранились базовые r-команды, теперь у них появилась альтернатива - утилиты защитной оболочки (Secure Shell, SSH), обеспечивающие передачу данных подобно r-командам, но с аутентификацией и шифрованием. Более подробные сведения о SSH можно получить поадресу, а бесплатные версии SSH-утилит - на веб-сайте.
Все это очень напоминает механизм доверительных отношений Windows NT/2000/Server 2003/XP - но все же это разные механизмы. Злоумышленник легко может выдать себя за удаленный узел и получить доступ к системе Unix/Linux посредством r-команд.
Классификация вторжений
Список ресурсов, которые обычно являются целями вторжений, можно найти в документе . Все вторжения можно разделить на пять классов, в зависимости от того что является их целью. Аппаратные средства - рабочие станции и серверы, принтеры, дисковые накопители и сетевые кабели, а также такие межсетевые устройства, как мосты, маршрутизаторы и коммутаторы. Программное обеспечение. Любое программное обеспечение, работающее на любом компьютере в сети, является потенциальной "дверью" для злоумышленника. Это могут быть программы, купленные у внешних разработчиков и программное обеспечение для внутреннего использования, созданное собственным отделом программистов. Именно поэтому операционные системы нуждаются в регулярной установке патчей. Информация. Наиболее значительной ценностью, конечно же, являются данные, которые создаются или используются в сети. Программное обеспечение и операционные системы можно переустановить - а если подвергнутся разглашению важные данные, такие как списки клиентов, сведения о продажах или корпоративные секреты, то ущерб бизнесу может быть значительным. Люди. В "группу риска" входят все пользователи, имеющие доступ к сети или к любому подключенному к ней устройству. Документы. Об этом очень важном для хакеров ресурсе часто забывают. Пароли записываются на бумажках; отчеты, содержащие конфиденциальную информацию, распечатываются, а потом все это часто выбрасывается в мусорную корзину. Лучше измельчить эти бумаги на мелкие кусочки или сделать их нечитаемыми другим способом - и только потом выбросить.
Одной из величайших угроз компьютерной безопасности являются заметки-"липучки". Вспомните, сколько раз вам приходилось видеть такие липучки с именем пользователя и паролем, приклеенные сбоку монитора? Хорошая политика обеспечения безопасности, понятная всем пользователям,- это нечто гораздо большее, чем просто средство предотвращения некоторых возможных проблем. Хорошей практикой является процедура регулярного повторного ознакомления пользователей с этой политикой, наравне с инструктажем по техника безопасности на рабочем месте. Это не должно быть пустой формальностью. Важно, чтобы пользователи сознавали, какую ответственность они берут на себя одновременно с правом доступа к корпоративной компьютерной сети.
заметившие или получившие подобные материалы,
Пользователи, заметившие или получившие подобные материалы, должны сразу сообщить об этом инциденте своему руководителю. Все, что создано на компьютере, в том числе сообщения электронной почты и другие электронные документы, может быть проанализировано руководством Компании. Пользователям не разрешается устанавливать на компьютерах и в сети Компании программное обеспечение без разрешения системного администратора. Пользователи не должны пересылать электронную почту другим лицам и организациям без разрешения отправителя. Электронная почта от юриста Компании или представляющего ее адвоката должна содержать в колонтитуле каждой страницы сообщение: "Защищено адвокатским правом/без разрешения не пересылать". Пользователям запрещается изменять и копировать файлы, принадлежащие другим пользователям, без разрешения владельцев файлов. Запрещается использование без предварительного письменного разрешения компьютерных и телекоммуникационных ресурсов и служб Компании для передачи или хранения коммерческих либо личных объявлений, ходатайств, рекламных материалов, а также разрушительных программ (вирусов и/или самовоспроизводящегося кода), политических материалов и любой другой информации, на работу с которой у пользователя нет полномочий или предназначенной для личного использования. Пользователь несет ответственность за сохранность своих паролей для входа в систему. Запрещается распечатывать, хранить в сети или передавать другим лицам индивидуальные пароли. Пользователи несут ответственность за все транзакции, которые кто-либо совершит с помощью их пароля. Возможность входа в другие компьютерные системы через сеть не дает пользователям права на подключение к этим системам и на использование их без специального разрешения операторов этих систем.
Образец политики корпоративной безопасности
Цель: гарантировать использование по назначению компьютеров и телекоммуникационных ресурсов Компании ее сотрудниками, независимыми подрядчиками и другими пользователями. Все пользователи компьютеров обязаны использовать компьютерные ресурсы квалифицированно, эффективно, придерживаясь норм этики и соблюдая законы. Следующая политика, ее правила и условия касаются всех пользователей компьютерных и телекоммуникационных ресурсов и служб компании, где бы эти пользователи ни находились. Нарушения этой политики влечет за собой дисциплинарные воздействия, вплоть до увольнения и/или возбуждения уголовного дела.
Данная политика может периодически изменяться и пересматриваться по мере необходимости.
Руководство компании имеет право, но не обязано проверять любой или все аспекты компьютерной системы, в том числе электронную почту, с целью гарантировать соблюдение данной политики. Компьютеры и бюджеты предоставляются сотрудникам Компании с целью помочь им более эффективно выполнять свою работу. Компьютерная и телекоммуникационная системы принадлежат Компании и могут использоваться только в рабочих целях. Сотрудники Компании не должны рассчитывать на конфиденциальность информации, которую они создают, посылают или получают с помощью принадлежащих Компании компьютеров и телекоммуникационных ресурсов. Пользователям компьютеров следует руководствоваться перечисленными ниже мерами предосторожности в отношении всех компьютерных и телекоммуникационных ресурсов и служб. Компьютерные и телекоммуникационные ресурсы и службы включают в себя (но не ограничиваются) следующее: хост-компьютеры, серверы файлов, рабочие станции, автономные компьютеры, мобильные компьютеры, программное обеспечение, а также внутренние и внешние сети связи (интернет, коммерческие интерактивные службы и системы электронной почты), к которым прямо или косвенно обращаются компьютерные устройства Компании. Пользователи должны соблюдать условия всех программных лицензий, авторское право и законы, касающиеся интеллектуальной собственности. Неверные, навязчивые, непристойные, клеветнические, оскорбительные, угрожающие или противозаконные материалы запрещается пересылать по электронной почте или с помощью других средств электронной связи, а также отображать и хранить их на компьютерах Компании.
Программный доступ
Кроме физического, следует ограничить и программный доступ к сети. И все равно, независимо от того насколько хорошо налажен контроль доступа, всегда найдется человек, который нарушит эту защиту. Поэтому необходимо иметь возможность проследить сетевые события и определить по ним, не пытался ли кто-то вторгнуться в сеть и насколько это удалось. Существует несколько типовых механизмов управления доступом к сети: пользовательские учетные записи и пароли; физические идентификаторы; защита ресурсов.
Во многих операционных системах важной частью этой схемы является концепция владения ресурсами. Например, в OpenVMS и Windows 2000/Server 2003 отслеживаются пользователи, создающие ресурсы (такие как файлы). Владельцы таких ресурсов имеют право изменять режим защиты файла и предоставлять другим пользователям полномочия, необходимые для работы с этим файлом. То же самое, хотя и в меньшей степени, можно сказать об операционных системах Unix/Linux.7
Системные демоны и службы
Фоновые процессы, выполняющие различные функции на серверах Windows, называются службами. В операционных системах Unix также есть аналогичные фоновые процессы, называемые демонами. И те, и другие процессы являются фоновыми - не требуют взаимодействия с клавиатурой и выполняются на компьютере, ожидающем запуска некоторой функции. Иногда они могут стать причиной нарушения системы защиты.
Следует ознакомиться с фоновыми процессами, выполняемыми на всех серверах сети, и отключить лишние. Например, в системах Unix есть много фоновых демонов, связанных с набором протоколов TCP/IP. На одних компьютерах они, нужны, на других же используются, в лучшем случае, только некоторые из них. Ниже перечислены некоторые демоны, которые нередко можно отключить.
Службы TCP/IP, которые иногда можно отключить
uucp- копирование с одного компьютера Unix на другой finger - получение информации о пользователях tftp - простейший протокол передачи файлов (Trivial File Transfer Protocol) talk - возможность обмена данными по сети между пользователями bootp - предоставление клиентам информации о сети systat - получение информации о системе netstat - получение информации о сети, такой как текущие соединения rusersd - получение информации о пользователях, зарегистрированных в данный момент rexd - удаление работающей утилиты
Например, служба tftp является упрощенным вариантом FTP. Она компактна и обычно легко реализуется в виде перепрограммируемого ПЗУ. Поэтому эта служба полезна в некоторых устройствах, требующих загрузки операционной системы с хоста. Однако следует учесть, что, в отличие от FTP, служба tftp не имеет доступа к механизмам управления и, таким образом, имя пользователя и пароль для нее неприменимы. А поскольку аутентификации нет, то отсутствие правильной настройки - например, разрешения использования только в определенных целях - может привести к серьезным нарушениям системы защиты. На серверах Windows есть две утилиты из состава Resource Kit, которые позволяют установить и запустить в режиме службы практически любую программу или пакетный файл. Это INSTRV.EXE, которая применяется для установки исполняемых программ, и SRVANY.EXE, которую можно использовать для превращения в службу других файлов. На сервере, где часто регистрируется несколько пользователей, можно внести в план регулярного обслуживания просмотр работающих служб и отключение или удаление тех из них, которые не были установлены при исходной установке операционной системы или не поставляются с продуктами, установленными на данном компьютере. Для этого нужно регулярно проводить инвентаризацию всего, что работает на каждом сервере. Информация, полученная в результате такой инвентаризации, может использоваться и в других целях - например, при переустановке сервера после аварии (см. инвентаризация).
Утилизация старых компьютеров
При обновлении сети и установке новых рабочих станций и серверов старое, ненужное оборудование часто передают сотрудникам компании или другим организациям, например школам. В политике обеспечения безопасности должно быть правило, согласно которому со всех жестких дисков, подлежащих списанию, должны быть удалены данные, а при необходимости - заново установлена легальная копия операционной системы. Там же должна быть описана процедура утилизации использованных дискет, компакт-дисков и картриджей с резервными копиями. При малейшем подозрении, что на них могла сохраниться важная информация, которую можно восстановить, лучше сначала разбить эти носители и только потом выбросить. Хорошим средством уничтожения информации с таких носителей является магнитное устройство "тотального" стирания.
Информационная безопасность
Атаки на абонентские пункты
Необходимо понимать, что абонентские пункты, реализованные на базе персонального компьютера являются менее защищенными устройствами, чем специальные IP-телефоны. Этот тезис также применим и к любым другим компонентам IP-телефонии, построенным на программной основе. Это связано с тем, что на такие компоненты можно реализовать не только специфичные для IP-телефонии атаки. Сам компьютер и его составляющие (операционная система, прикладные программы, базы данных и т.д.) подвержены различным атакам, которые могут повлиять и на компоненты IP-телефонии. Например, Internet-черви Red Code, Nimda, различные троянцы и вирусы, DoS-атаки и их распределенные модификации - все это способно, если не вывести из строя голосовую IP-инфраструктуру, то существенно нарушить ее функционирование. При этом, даже если в самом ПО не найдено уязвимостей (до поры до времени), то используемые им другие программные компоненты третьих фирм (особенно широко известные) могут снизить общую защищенность до нуля. Ведь давно известно общее правило - "защищенность всей системы равна защищенности самого слабого ее звена". Для примера можно привести Cisco CallManager, который использует для своего функционирования Windows 2000 Server, MS Internet Information Server и MS SQL Server, каждый из которых обладает своим букетом дыр.
Атаки на диспетчеры
Злоумышленники могут атаковать и узлы (Gatekeeper в терминах H.323 или Redirect server в терминах SIP), которые хранят информацию о разговорах пользователей (имена абонентов, время, продолжительность, причина завершения звонка и т.д.). Это может быть сделано, как с целью получения конфиденциальной информации о самих разговорах, так и с целью модификации и даже удаления указанных данных. В последнем случае биллинговая система (например, у оператора связи) не сможет правильно выставлять счета своим клиентам, что может нарушить функционирование или нанести ущерб всей инфраструктуре IP-телефонии.
Атаки на обычную телефонию применимы и для ее IP-родственницы.
IP-телефония, являясь прямой родственницей обычной телефонии и IP-технологии, вобрала в себя не только их достоинства, но и их недостатки. Т.е. атаки, присущие обычной телефонии, также могут быть применены и для ее IP-составляющей. Перечислю некоторые из них, часть их которых я рассмотрю более подробно:
Подслушивание телефонных переговоров Отказ в обслуживании Подмена номера Кража сервисов Неожидаемые вызовы Несанкционированное изменение конфигурации Мошенничество со счетом.
Аутентификация
Различные IP-телефоны поддерживают механизмы аутентификации, которые позволяют воспользоваться его возможностями только после предъявления и проверки пароля или персонального номера PIN, разрешающего пользователю доступ к IP-телефону. Однако надо заметить, что данное решение не всегда удобно для конечного пользователя, особенно в условиях ежедневного использования IP-телефона. Возникает обычное противоречие "защищенность или удобство".
которая реализует некоторые механизмы безопасности
H.323 - протокол, который позволяет построить VoIP-систему от начала и до конца. H.323 включает в себя ряд спецификаций, в т.ч. и H.235, которая реализует некоторые механизмы безопасности (аутентификацию, целостность, конфиденциальность и невозможность отказа от сообщений) для голосовых данных.
Аутентификация в рамках стандарта H.323 может быть реализована как с помощью алгоритмов симметричной криптографии (в этом случае не требуется никакого предварительного обмена между взаимодействующими устройствами и не так интенсивно нагружается центральный процессор), так и с помощью сертификатов или паролей. Кроме того, спецификация H.235 позволяет использовать в качестве механизма аутентификации IPSec, который также рекомендуется к применению и в других стандартах IP-телефонии.
После установки защищенного соединения, которое происходит через 1300 tcp-порт, узлы, участвующие в обмене голосовыми данными, обмениваются информацией о методе шифрования, которое может быть задействовано на транспортном (шифрование пакетов RTP-протокола) или сетевом (с помощью IPSec) уровне.
Безопасность MGCP
Стандарт MGCP, определенный в RFC 2705 и неприменяемый на оконечных устройствах (шлюзы MGCP могут работать как с компонентами, поддерживающими H.323, так и с компонентами, поддерживающими SIP), использует для защиты голосовых данных протокол ESP спецификации IPSec. Может также использоваться и протокол AH (но только не в сетях IPv6), который обеспечивает аутентификацию и целостность данных (connectionless integrity) и защиту от повторений, передаваемых между шлюзами. В то же время, протокол AH не обеспечивает конфиденциальности данных, которая достигается применением ESP (наряду с другими тремя защитными функциями).
 Рис. 2 Архитектура протоколов IP-Телефонии
Безопасность SIP
Данный протокол, похожий на HTTP и используемый абонентскими пунктами для установления соединения (не обязательно телефонного, но и, например, для игр), не обладает серьезной защитой и ориентирован на применение решений третьих фирм (например, PGP). В качестве механизма аутентификации RFC 2543 предлагает несколько вариантов и, в частности, базовую аутентификацию (как в HTTP) и аутентификацию на базе PGP. Пытаясь устранить слабую защищенность данного протокола, Майкл Томас из компании Cisco Systems разработал проект стандарта IETF, названный "SIP security framework", который описывает внешние и внутренние угрозы для протокола SIP и способы защиты от них. В частности, к таким способам можно отнести защиту на транспортном уровне с помощью TLS или IPSec. Кстати, компания Cisco в своей архитектуре безопасности корпоративных сетей SAFE, очень большое внимание уделяет практическим вопросам защиты IP-телефонии.
Дополнительные ресурсы
Архитектура безопасности корпоративных сетей SAFE компании Cisco Systems - Архитектура SAFE для IP-телефонии: (SAFE: IP Telephony Security in Depth) - Thomas, Michael. "SIP Security Framework" 12 July 2001 - Liu, Jing. "The Security Architecture of H.323" -
Физическая безопасность
Желательно запретить неавторизованный доступ пользователей к сетевому оборудованию, в т.ч. и коммутаторам, и по возможности все неабонентское оборудование разместить в специально оборудованных серверных комнатах. Это позволит предотвратить несанкционированное подключение компьютера злоумышленника. Кроме того, следует регулярно проверять наличие несанкционированно подключенных к сети устройств, которые могут быть "врезаны" напрямую в сетевой кабель. Для определения таких устройств можно использовать различные методы, в т.ч. и сканеры (например, Internet Scanner или Nessus), дистанционно определяющие наличие в сети "чужих" устройств.
IP-опасность для бизнесаНаучно-инженерное предприятие "Информзащита" Опубликовано в журнале "Мир связи. Connect"
IP-телефония (VoIP) сейчас переживает бум - о ней говорят все и вся, расписывая ее несомненные достоинства (сокращение расходов за междугородние и международные переговоры, возможность совместной передачи данных и голоса по одним физическим каналам связи, интеграция с различными приложениями и т.д.). Но как быть с безопасностью IP-телефонии? IT-специалистам, включая и специалистов по защите информации, крайне желательно знать возможные угрозы компонентам инфраструктуры IP-телефонии и возможные способы защиты от них, включая и возможности существующих VoIP-стандартов с точки зрения информационной безопасности.
Контроль доступа
Еще один достаточно простой способ защиты инфраструктуры VoIP - контроль MAC-адресов. Не разрешайте IP-телефонам с неизвестными MAC-адресами получать доступ к шлюзам и иным элементам IP-сети, передающей голосовые данные. Это позволит предотвратить несанкционированное подключение "чужих" IP-телефонов, которые могут прослушивать ваши переговоры или осуществлять телефонную связь за ваш счет. Разумеется, MAC-адрес можно подделать, но все-таки не стоит пренебрегать такой простой защитной мерой, которая без особых проблем реализуется на большинстве современных коммутаторов и, даже, концентраторов.
Узлы (в основном, шлюзы, диспетчеры и мониторы) должны быть настроены таким образом, чтобы блокировать все попытки несанкционированного доступа к ним. Для этого можно воспользоваться как встроенными в операционные системы возможностями, так и продуктами третьих фирм. А так как мы работаем в России, то я рекомендую применять средства, сертифицированные в Гостехкомиссии России, тем более что таких средств немало.
Межсетевой экран
Для защиты корпоративной сети обычно используется межсетевые экраны, которые с тем же успехом могут быть использованы и для защиты VoIP-инфраструктуры. Единственное, что необходимо сделать - добавить ряд правил, учитывающих топологию сети, местоположение установленных компонентов IP-телефонии и т.д. Например, доступ к Cisco CallManager из Internet или демилитаризованной зоны обычно блокируется, однако в случае использования Web-ориентированного управления такой доступ должен быть разрешен, но только для 80-го порта и только для ограниченного диапазона внешних адресов. А для защиты SQL-сервера, входящего в состав Cisco CallManager, можно запретить доступ со всех портов кроме 1433-го.
Кстати, существует два типа межсетевых экранов, которые могут быть использованы для защиты компонентов IP-телефонии. Первый из них, корпоративный, ставится на выходе из корпоративной сети и защищает сразу все ее ресурсы. Примером такого МСЭ является CiscoSecure PIX Firewall. Второй тип - персональный, защищающий только один конкретный узел, на котором может стоять абонентский пункт, шлюз или диспетчер. Примерами таких персональных МСЭ являются RealSecure Desktop Protector или BlackICE PC Protector. Кроме того, некоторые операционные системы (например, Linux или Windows 2000) имеют встроенные персональные межсетевые экраны, что позволяет задействовать их возможности для повышения защищенности инфраструктуры VoIP.
В зависимости от используемого стандарта IP-телефонии применение межсетевых экранов может повлечь за собой разные проблемы. Например, после того, как с помощью протокола SIP абонентские пункты обменялись информацией о параметрах соединения, все взаимодействие осуществляется через динамически выделенные порты с номерами больше 1023. В этом случае МСЭ заранее "не знает" о том, какой порт будет использован для обмена голосовыми данными и, как следствие, будет такой обмен блокировать. Поэтому межсетевой экран должен уметь анализировать SIP-пакеты с целью определения используемых для взаимодействия портов и динамически создавать или изменять свои правила. Аналогичное требование предъявляется и для других протоколов IP-телефонии.
Еще одна проблема связан с тем, что не все МСЭ умеют грамотно обрабатывать не только заголовок протокола IP-телефонии, но и его тело данных, т.к. зачастую важная информация находится внутри него. Например, информация об адресах абонентов в протоколе SIP находится именно в теле данных. Неумение межсетевого экрана "вникать в суть" может привести к невозможности обмена голосовыми данными через межсетевой экран или "открытии" в нем слишком большой дыры, которой могут воспользоваться злоумышленники.
Отказ в обслуживании
Традиционная телефонная связь всегда гарантирует качество связи даже в случае высоких нагрузок, что не является аксиомой для IP-телефонии. Высокая нагрузка на сеть, в которой передаются оцифрованные голосовые данные, приводит к существенному искажению и даже пропаданию части голосовых сообщений. Поэтому одна из атак на IP-телефонию может заключаться в посылке на сервер IP-телефонии большого числа "шумовых" пакетов, которые засоряют канал передачи данных, а в случае превышения некоторого порогового значения могут даже вывести из строя часть сети IP-телефонии (т.е. атака "отказ в обслуживании"). Что характерно, для реализации такой атаки нет необходимости "изобретать велосипед" - достаточно использовать широкие известные DoS-атаки Land, Ping of Death, Smurf, UDP Flood и т.д. Одним из решений этой проблемы является резервирование полосы пропускания, которого можно достичь с помощью современных протоколов, например, RSVP. Более подробно способы защиты будут рассмотрены далее.
Перехват данных
Перехват данных - самая большая проблема, как обычной телефонии, так и ее IP-родственницы. Однако в последнем случае эта опасность намного выше, т.к. злоумышленнику уже не надо иметь физический доступ к телефонной линии. Ситуацию ухудшает еще и тот факт, что множество протоколов, построенных на базе стека TCP/IP, передают данные в открытом виде. Таким грехом страдают HTTP, SMTP, IMAP, FTP, Telnet, SQL*net и, в том числе, протоколы IP-телефонии. Злоумышленник, который смог перехватить голосовой IP-трафик (а он по умолчанию между шлюзами не шифруется) может без труда восстановить исходные переговоры. Для этого существуют даже автоматизированные средства. Например, утилита vomit (Voice Over Misconfigured Internet Telephones), которая конвертирует данные, полученные в результате перехвата трафика с помощью свободно распространяемого анализатора протоколов tcpdump, в обычный WAV-файл, прослушиваемый с помощью любого компьютерного плейера. Эта утилита позволяет конвертировать голосовые данные, переданные с помощью IP-телефонов Cisco и сжатые с помощью кодека G.711. Мало того, помимо несанкционированного прослушивания злоумышленники могут повторно передать перехваченные голосовые сообщения (или их фрагменты) для достижения своих целей.
Однако сразу хочу отметить, что перехват голосовых данных - не такая простая задача, как кажется на первый взгляд. Злоумышленник должен иметь информацию об адресах шлюзов или абонентских пунктов, используемых VoIP-протоколах (например, H.323) и алгоритмах сжатия (например, G.711). В противном случае, злоумышленнику будет трудно настроить ПО для перехвата трафика или объем перехваченных данных и время для их анализа превысит все допустимые пределы.
Перехват данных может быть осуществлен как изнутри корпоративной сети, так и снаружи. Квалифицированный злоумышленник, имеющий доступ к физической среде передаче данных, может подключить свой IP-телефон к коммутатору и таким образом подслушивать чужие переговоры. Он также может изменить маршруты движения сетевого трафика и стать центральным узлом корпоративной сети через который проходит интересующий его трафик. Причем, если во внутренней сети вы можете с определенной долей вероятности обнаружить несанкционированно подключенное устройство, перехватывающее голосовые данные, то во внешней сети обнаружить ответвления практически невозможно. Поэтому любой незашифрованный трафик, выходящий за пределы корпоративной сети, должен считаться небезопасным.
Подмена номера
Для связи с абонентом в обычной телефонной сети вы должны знать его номер, а в IP-телефонии - роль телефонного номера выполняет IP-адрес. Следовательно, возможна ситуация, когда злоумышленник, используя подмену адреса, сможет выдать себя за нужного вам абонента. Именно поэтому задача обеспечения аутентификации не обойдена вниманием во всех существующих VoIP-стандартах и будет рассмотрена чуть позже.
Принцип действия
Принцип действия технологии IP-телефонии прост. Центральным ее компонентом является сервер (шлюз), который отвечает за соединение телефонной и IP сетей, т.е. он подключен как к телефонной сети и может дозвониться до любого обычного телефона, так и к сети передачи данных (например, Internet) и может получить доступ к любому компьютеру. В функции данного устройства входят:
Ответ на вывоз вызывающего абонента Установление соединение с удаленным шлюзом и вызываемым абонентом Оцифровка (кодирование), сжатие, разбиение на пакеты и восстановление сигнала
Данный шлюз (например, Cisco Catalyst 4000 Access Gateway Module или Cisco VG200) на вход принимает обычный телефонный сигнал, оцифровывает его (если сигнал не цифровой) и проводит сжатие полученных данных, после чего передает в IP-сеть в виде обычных пакетов (но не очень большого размера). На другом конце шлюз восстанавливает сигнал в обратном порядке. Данный компонент может и не использоваться, если вы не планируете интегрировать свои IP-телефоны в телефонную сеть общего пользования (см. рис.1).
Для того чтобы можно было построить распределенную сеть IP-телефонии необходимо наличие диспетчера, который отвечает за распределение вызовов между шлюзами (например, Cisco CallManager). Помимо этой задачи диспетчер проводит аутентификацию и авторизацию абонентов, а также обладает интерфейсом к биллинговой системе.
Для удобства администрирования большого числа удаленных шлюзов и диспетчеров может использоваться специальное программное обеспечение, называемое монитором. Ну и, наконец, последним обязательным элементом сети IP-телефонии является абонентский пункт, который может быть реализован как программным (например, Cisco IP SoftPhone), так и аппаратным способом (например, Cisco IP Phone, подключаемые напрямую к Ethernet-порту коммутатора). Причем в первом случае звонки можно осуществлять даже через домашний компьютер, оснащенный звуковой картой и микрофоном, а во втором случае, в качестве абонентского пункта выступает т.н. IP-телефон.
Еще одним компонентом архитектуры IP-телефонии можно назвать специализированные пользовательские приложения, возникшие благодаря интеграции голоса, видео и данных (call-центры, системы унифицированной обработки сообщений).
 Рис. 1 Компоненты инфраструктуры IP-Телефонии
RFC 1918 и трансляция адресов
Не рекомендуется использовать для VoIP IP-адреса, доступные из Internet, - это существенно снижает общий уровень безопасность инфраструктуры. Поэтому при возможности используйте адреса, указанные в RFC 1918 (10.x.x.x, 192.168.x.x и т.д.) и немаршрутизируемые в Internet. Если это невозможно, то необходимо задействовать на межсетевом экране, защищающем вашу корпоративную сеть, механизм трансляции адресов (network address translation, NAT).
Шифрование
Шифрование должно использоваться не только между шлюзами, но и между IP-телефоном и шлюзом. Это позволит защитить весь путь, который проходят голосовые данные из одного конца в другой. Обеспечение конфиденциальности не только является неотъемлемой частью стандарта H.323, но и реализовано в оборудовании некоторых производителей. Однако этот механизм практически никогда не задействуется. Почему? Потому что качество передачи данных является первоочередной задачей, а непрерывное зашифрование/расшифрование потока голосовых данных требует времени и вносит зачастую неприемлемые задержки в процесс передачи и приема трафика (задержка в 200 250 мсек может существенно снизить качество переговоров). Кроме того, как уже было сказано выше, отсутствие единого стандарта не позволяет принять всеми производителями единый алгоритм шифрования. Однако справедливости ради надо сказать, что сложности перехвата голосового трафика пока позволяют смотреть на его шифрование сквозь пальцы.
Кстати, если вы все-таки решитесь использовать шифрование, то помните, что, шифруя голосовые данные, вы скрываете их не только от злоумышленника, но и от средств обеспечения контроля качества (QoS), которые не смогут предоставить им соответствующую полосу пропускания и приоритетное обслуживание. Устранив одну проблему (беззащитность), перед вами встает другая (качество обслуживания). И можно быть уверенным, что при таком раскладе вы предпочтете решение второй проблемы, пренебрегая решением первой. Кстати, шифровать можно тоже не все подряд. Сигнальные протоколы, используемые в IP-телефонии, шифровать не рекомендуется, т.к. в этом случае вы зашифруете и всю служебную информацию, необходимую для поддержания работоспособности всей сети.
Но не стоит сразу отказываться от шифрования - все-таки обезопасить свои переговоры также необходимо. Поэтому стоит с умом подходить к шифрованию VoIP-данных. Например, компания Cisco рекомендует вместо туннеля GRE или применения VPN-концентраторов Cisco VPN 3000 использовать команду Crypto в операционной системе IOS своего оборудования, что позволяет защитить данные при сохранении качества обслуживания. Кроме того, можно использовать выборочное шифрование только для определенных полей в VoIP-пакетах.
 Рис. 3 Фрагмент защищенной сети IP-Телефонии
Системы обнаружения атак
Выше уже было рассказано о некоторых атаках, которые могут нарушить работоспособность VoIP-инфраструктуры. Для защиты от них можно использовать хорошо себя зарекомендовавшие и известные в России средства обнаружения атак (intrusion detection system), которые не только своевременно идентифицируют нападения, но и блокируют их, не давая нанести вред ресурсам корпоративной сети. Такие средства могут защищать как целые сетевые сегменты (например, RealSecure Network Sensor или Snort), так и отдельные узлы (например, CiscoSecure IDS Host Sensor или RealSecure Server Sensor).
Стандарты IP-телефонии и механизмы их безопасности
Отсутствие единых принятых стандартов в данной области (см. рис.2) не позволяет разработать и универсальные рекомендации по защите устройств IP-телефонии. Каждая рабочая группа или производитель по-своему решает задачи обеспечения безопасности шлюзов и диспетчеров, что приводит к необходимости тщательного их изучения перед выбором адекватных мер по защите.
VLAN
Технология виртуальных локальных сетей (VLAN) обеспечивает безопасное разделение физической сети на несколько изолированных сегментов, функционирующих независимо друг от друга. В IP телефонии эта технология используется для отделения передачи голоса от передачи обычных данных (файлов, e-mail и т.д.). Диспетчеры, шлюзы и IP-телефоны помещают в выделенную VLAN для передачи голоса. Как я уже отметил выше, VLAN существенно усложняет жизнь злоумышленникам, но не снимает всех проблем с подслушиванием переговоров. Существуют методы, которые позволяют злоумышленникам перехватывать данные даже в коммутированной среде.
Возможные угрозы
Главная проблема с безопасностью IP-телефонии в том, что она слишком открыта и позволяет злоумышленникам относительно легко совершать атаки на ее компоненты. Несмотря на то, что случаи таких нападений практически неизвестны, они могут быть при желании реализованы, т.к. атаки на обычные IP-сети практически без изменений могут быть направлены и на сети передачи оцифрованного голоса. С другой стороны, похожесть обычных IP-сетей и сетей IP-телефонии подсказывает нам и пути их защиты, но об этом чуть дальше.
Выбор правильной топологии
Не рекомендуется использовать для VoIP-инфраструктуры концентраторы, которые облегчают злоумышленникам перехват данных. Кроме того, т.к. оцифрованный голос обычно проходит по той же кабельной системе и через тоже сетевое оборудование, что и обычные данные, стоит правильно разграничить между ними информационные потоки. Это, например, может быть сделано с помощью механизма VLAN (однако не стоит полагаться только на них). Сервера, участвующие в инфраструктуре IP-телефонии желательно размещать в отдельном сетевом сегменте (см. рис.3), защищенном не только с помощью встроенных в коммутаторы и маршрутизаторы механизмов защиты (списки контроля доступа, трансляция адресов и обнаружение атак), но и с помощью дополнительно установленных средств защиты (межсетевые экраны, системы обнаружения атак, системы аутентификации и т.д.).
Вы должны помнить, что передача голосовых данных по вашей корпоративной сети накладывает на ее проектирование особый отпечаток. Большое внимание вы должны уделить вопросам высокой доступности и отказоустойчивости. Если пользователи еще могут привыкнуть к непродолжительному выходу из строя Web-сервера или почтовой системы, то привыкнуть к нарушению телефонной связи они не смогут. Обычная телефонная сеть так редко выходит из строя, что многие пользователи закономерно наделяют свойством безотказности и ее IP-сестру. Поэтому сбой в работе VoIP-инфраструктуры может подорвать к ней доверие со стороны пользователей, что в свою очередь может привести к отказу от ее использования и нанесению материального ущерба ее собственнику.
Зачем атакуют IP-телефонию?
Сети IP-телефонии - хорошая цель для хакеров. Некоторые из них могут подшутить над вами, послав вам голосовое сообщение от имени руководства компании. Кто-то может захотеть получить доступ к голосовому почтовому ящику вашего руководства или даже захочет перехватить голосовые данные о финансовых сделках, которыми обмениваются сотрудники финансового департамента или бухгалтерии. Ваши конкуренты могут захотеть подорвать вашу репутацию путем выведения из строя шлюзов и диспетчеров, тем самым, нарушая доступность телефонных услуг для ваших абонентов, что, в свою очередь, может также привести к нанесению ущерба бизнесу ваших клиентов. Существуют и другие причины, например, звонки за чужой счет (кража сервиса).
и объемность темы не позволяет
Разносторонность и объемность темы не позволяет подробно рассмотреть все аспекты обеспечения информационной безопасности IP-телефонии. Но те аспекты, которые мне удалось осветить и знания о которых вы можете расширить с помощью дополнительных ресурсов, все же показывают, что VoIP - не такая закрытая и непонятная область, как это кажется на первый взгляд. К ней могут быть применены уже известные по обычной телефонии и IP-сетям методы нападения. А относительная легкость их реализации ставит безопасность на первое место, наряду с обеспечением качества обслуживания IP-телефонии.
Информационная безопасность
Четыре к одному
Современные системы IPS развивались в нескольких направлениях. Некоторые производители развили имеющиеся у них IDS, оснастив их гораздо более эффективными механизмами предотвращения атак. Например, в системах IDS использовалась простая посылка TCP-пакетов с флагом RST или реконфигурация МСЭ и сетевого оборудования. Эффективность этой "защиты" для классических IDS составляет всего около 30% - ведь трафик через устройство не проходит и о реагировании в реальном времени говорить не приходится (существует хоть и минимальная, но задержка). Однако было найдено простое решение: поместить систему IDS между защищаемыми и незащищаемыми ресурсами (весь трафик между ними проходит через IDS). Так появились системы под названием inline-IDS, позже переименованные в IPS. По этому пути пошли компании ISS, Cisco, NFR и Sourcefire.
Однако технологии IPS не ограничивались только эволюцией систем IDS. Современные МСЭ, оснащенные механизмом глубокого анализа трафика, также могут быть отнесены к разряду IPS. Нехватка расширенных механизмов анализа в МСЭ привела к тому, что их стали оснащать функциями не только анализа заголовка пакета, но и глубокого проникновения в тело данных и "понимания" передаваемых протоколов. Производители по-разному называют эту функциональность: Deep Packet Inspection, Application Intelligence и т. д., но суть ее от этого не меняется. МСЭ с такими функциями способны обнаруживать многие нарушения политики безопасности, например скрытие в протоколе HTTP запрещенных приложений (ICQ, P2P и т. п.), отклонение от стандартов RFC и т. д. Разумеется, современные МСЭ не обладают такими же механизмами обнаружения атак, что и IDS, но со временем слияние этих систем все же произойдет. По пути оснащения своих МСЭ новыми возможностями пошли компании Check Point, Cisco, Fortinet и iPolicy Networks.
Существует еще третье направление, которое послужило толчком к становлению современных систем предотвращения атак, - создание антивирусов. Начавшие свой путь как средства лечения загрузочных, файловых и макровирусов, эти средства защиты "нарастили мышцы" за счет обнаружения троянцев, червей и других вредоносных программ. В итоге, читая описания современных антивирусов, очень сложно понять, о чем идет речь - об антивирусной программе или системе IPS.
Четвертым витком эволюции стало создание "чистых" систем IPS, которые изначально были ориентированы на предотвращение атак. По такому пути пошли компании OneSecure и IntruShield, выпустившие в 2000-2001 годах первые IPS. В эту же категорию попали такие пионеры отрасли, как Network ICE и Tipping Point. Но, как говорится, иных уж нет, а те далече - все названные компании были куплены более крупными игроками: McAfee, NetScreen, ISS и т. п.
Сейчас в сегменте собственно IPS появились новые "ростки" - V-Secure, Reflex Security, DeepNines Technologies и другие.
Почему проекты внедрения IPS проваливаются, или Что нас ждет в будущем?
В начале XXI века некоторые эксперты предрекали системам IDS скорую смерть, ссылаясь на три основные проблемы при их внедрении: высокий процент ложных срабатываний, большое число управленческих задач и автоматизация реагирования. Системы IPS справились только с последней. Какие же действия предпринимают производители для решения проблем, способных похоронить эту технологию защиты?
Прежде всего рассмотрим проблему ложных срабатываний. Представьте, что мимо вас в детскую комнату летит комар. Вы его обнаружили, но этого мало. Вы не знаете, находится ли ваш ребенок в детской, а если находится, то намазался ли он средством против комаров. В результате вы сломя голову бежите в комнату и убиваете комара. За эти секунды на плите убегает и выплескивается на плиту варенье-"пятиминутка", а нет ничего страшнее для керамической варочной панели, чем засохший сахар. С системами обнаружения и предотвращения атак ситуация похожая: обратив внимание на первый сигнал тревоги и не зная, насколько реальна опасность, вы можете упустить из виду более серьезное событие, поступившее на консоль администратора вторым. Более того, существуют специальные утилиты, которые генерируют потоки ложных событий, чтобы ввести администратора в заблуждение. Поэтому первое, на что надо обращать внимание при выборе систем защиты описываемого класса, - борьба с ложными срабатываниями (false positive).
Для решения этой проблемы применяются системы корреляции событий, которые в состоянии определить, что скрывается за атаку емыми IP-адресами, и сделать вывод, подвержена ли цель такой атаке. Если нет, то событием можно пренебречь и оставить его . Однако, чтобы принять решение о реальности атаки, необходимо знать, какие ОС и ПО установлены на атакуемом узле. Если, например, червь SQL Slammer атакует Linux-сервер, то последнему ничего не угрожает, так как SQL Slammer наносит ущерб только серверам с СУБД MS SQL Server без соответствующих заплаток. Информация о ПО и ОС может быть добыта двумя путями (ручное задание этих параметров для всех атакуемых узлов вряд ли можно рассматривать как перспективный способ).
Например, с помощью дистанционного сканирования и получения необходимой информации от самого атакуемого узла. Этот способ наиболее прост в реализации - достаточно просканировать сеть и связать информацию об атаках с конкретными версиями ОС, ПО и уязвимостями (это и есть процесс корреляции). Однако у данного метода есть серьезное ограничение - системы корреляции стоят немалых денег.
Решение указанной проблемы заключается в использовании облегченных и интегрированных в системы предотвращения атак подсистем корреляции. Такая система регулярно проводит сканирование сети и запоминает состояние составляющих ее узлов. В момент атаки происходит связывание сведений об атаке с информацией об атакуемом узле. Если связь есть, то атака не ложная; если связь не обнаружена, то приоритет атаки снижается и администратор не тратит на нее время и энергию. Этот способ отсеивания ложных срабатываний появился недавно и пока не получил широкого распространения. В принципе, установленная на узле система персональной защиты (например, HIPS) сама сигнализирует сетевому сенсору, какая атака может нанести ущерб, а какая нет.
Другая, пока не до конца решенная проблема - большое число управленческих задач, к которым относятся обновление сигнатур, интерпретация сигналов тревоги, настройка системы и т. д. Каждый производитель решает их по-своему, единых стандартов и рекомендаций еще не существует. Если же этому аспекту должного внимания не уделить, то система IPS из средства защиты сама может превратиться в источник проблем. К примеру, неграмотно настроенная функция блокирования вторже- ния может стать причиной отказа в обслужи- вании (denial of service) для какого-либо узла или приложения.
Между тем существует еще целый ряд проблем, ожидающих своего решения. Первая заключается в отказоустойчивости системы IPS. Ведь если решение выйдет из строя, то в канале связи образуется затор и трафик не сможет дойти до адресата. Рекомендации, даваемые на заре использования IPS ("лучше не допустить проникновения или утечки и блокировать доступ в сеть в случае выхода IPS из строя, чем оставить сеть открытой и незащищенной"), сегодня уже устарели.
Многие бизнес- приложения являются более приоритетными, нежели системы защиты, и снижение доступности первых недопустимо, даже в ущерб защищенности. Поэтому теперь большинство систем IPS оснащаются различными механизмами отказоустойчивости (программными или аппаратными bypass-системами).
Второй проблемой стало предотвращение атак в коммутируемых сетях. Когда речь заходит о применении IDS в коммутируемых сетях, то особых проблем это уже не вызывает. Можно использовать различные механизмы и технологии, самая распространенная из которых - использование SPAN-порта на коммутаторе, куда подключается сенсор системы обнаружения. Однако как только от обнаружения мы переходим к предотвращению, ситуация коренным образом меняется. Мы уже не можем просто подключить IPS к SPAN-порту и блокировать все атаки, ведь трафик должен проходить через само устройство защиты. Первый вариант решения проблемы сегодня доступен только в решениях компании Cisco (в коммутаторе Cisco Catalyst 6500), которые имеют интегрированный модуль, способный блокировать проходящий через него трафик. А если ваша сеть построена на коммутаторах другого производителя? Устанавливать сенсоры IPS между коммутатором и защищаемым узлом слишком дорого - число сенсоров будет равно числу защищаемых ресурсов, что сделает инфраструктуру отражения атак поистине золотой.
Использование многоинтерфейсных сенсоров (например, с четырьмя или восьмью портами) ситуацию кардинально не меняет - инфраструктура все равно получается очень дорогой. Выходом может стать метод, появившийся совсем недавно и получивший название Inline-on-a-Stick. Суть его проста: на интерфейс устройства IPS поступает трафик одной из VLAN и после обработки через этот же интерфейс уходит обратно. Если учесть возможность поддержки до 255 пар VLAN-соединений на одном порту сенсора, то можно контролировать очень большие локальные сети (с восьмьюпортовой картой число контролируемых соединений составляет примерно 2000).
Третья - кооперация с IPS других производителей.
Некоторые заказчики, имея финансовые ресурсы и следуя пословице "не кладите все яйца в одну корзину", строят инфраструктуру предотвращения атак на решениях разных производителей. При этом компании хотят контролировать разнородные сенсоры с одной консоли управления. Вариантов решения задачи два: применение внешних систем управления информационной безопасности (SIMS, Security Information Management System, или SEMS, Security Event Management System) и поддержка стандарта SDEE (Security Device Event Exchange). Второй путь более экономичен и позволяет передавать сигналы тревоги, полученные сенсором одного производителя, на консоль другого производителя.
Четвертая проблема - это увеличение пропускной способности. Лучшие с точки зрения производительности системы IPS работают на скоростях 2-5 Гбит/с, чего более чем достаточно для периметра корпоративной сети, но не хватает для локальной сети. Например, 5-Гбит система IPS может защитить только пять серверов с 1-Гбит сетевыми картами или 50 рабочих станций с 100-Мбит сетевыми интерфейсами. Поэтому сейчас многие производители пошли по пути сетевых лидеров и начали использовать технологии ASIC или FPGA для реализации логики работы системы предотвращения атак. Это может существенно ускорить работу IPS.
Пятая проблема скрывается в поддержке новых приложений. Ранее атаки концентрировались на сетевом уровне, и возможностей IPS было достаточно для их отражения. В последнее время фокус атак сместился на прикладной уровень - на веб-сервисы, XML, SOAP, ERP, CRM, СУБД, IP-телефонию и прочее. Сетевые системы IPS перестали справляться с атаками, так как они не работают на уровне их реализации. Поэтому одним из направлений развития IPS станет поддержка новых технологий и протоколов.
Предотвращение сетевых атак: технологии и решения
Алексей Лукацкий, менеджер по развитию бизнеса Cisco Systems
Системы предотвращения атак (IPS) сегодня очень популярны. Они объединяют целый ряд технологий безопасности и достаточно далеко шагнули от своих предков - систем обнаружения вторжений. Тем не менее, некоторые аналитики критикуют IPS за объективные недостатки и даже предсказывают скорую смерть таких систем. Рассмотрению современных технологий предотвращения атак, анализу их сильных и слабых сторон, а также перспектив их существования посвящена данная статья.
Раньше было всего два класса защитных средств, устанавливаемых на периметре, - межсетевые экраны (firewall) и системы обнаружения вторжений (IDS). Межсетевые экраны (далее МСЭ) пропускали трафик через себя, но не "заглядывали" внутрь пересыла емых данных, фокусируясь только на заголовке IP-пакета. Системы IDS (Intrusion Detection System), напротив, анализировали то, что упускалось из виду межсетевыми экранами, но не были способны блокировать атаки, так как трафик через них не проходил. Поэтому на стыке двух технологий родился новый класс защитных средств - системы предотвращения вторжений (IPS).
IPS (Intrusion Prevention System) оказались настолько популярными, что многие производители стали рекламировать свои классические IDS как системы предотвращения атак, то есть IPS. Не меняя сути своих продуктов, но подставив букву P вместо D, эти поставщики открыли для себя новые рынки и новых клиентов. Но признаками настоящей системы IPS эти решения не обладали. Во-первых, IPS функционирует в режиме inline (пропускает трафик через себя) на скорости канала. Другими словами, решение не становится "бутылочным горлышком" и не снижает скорость передачи данных. Во-вторых, система IPS обеспечивает сборку передаваемых пакетов в правильном порядке и анализирует эти пакеты с целью обнаружения следов несанкционированной активности. В-третьих, во время анализа используются различные методы обнаружения атак: сигнатурный и поведенческий, а также идентификация аномалий в протоколах. Наконец, в-четвертых, система IPS в состоянии блокировать вредоносный трафик (но не путем разрыва соединения с помощью команды RESET протокола TCP). Таким образом, чтобы получить систему IPS из IDS, надо сделать не один шаг (заменить букву в названии), а целых четыре - добавить новые технологии и изменить принципы работы решения.
Варианты внедрения
Обычно при упоминании систем IPS в голову приходят выделенные устройства, которые могут быть установлены на периметре корпоративной сети и, в ряде случаев, внутри нее. Внедрение в качестве систем защиты таких аппаратных устройств (security appliance) - наиболее распространенный вариант, но далеко не единственный. Такие шлюзы безопасности, несмотря на хорошую краткосрочную и среднесрочную перспективу, в дальнейшем постепенно уйдут в тень, и их место займут решения, интегрированные в инфраструктуру, что гораздо эффективнее со многих точек зрения.
Во-первых, стоимость интегрированного решения ниже стоимости автономного (stand-alone) устройства. Во-вторых, ниже и стоимость внедрения (финансовая и временная) такого решения - можно не менять топологию сети. В-третьих, надежность выше, так как в цепочке прохождения трафика отсутствует дополнительное звено, подверженное отказам. Наконец, в-четвертых, интегрированные решения предоставляют более высокий уровень защиты за счет более тесного взаимодействия с защищаемыми ресурсами.
Сама интеграция может быть выполнена различными путями. Самым распространенным способом в настоящий момент является использование маршрутизатора (router). В этом случае система IPS становится составной частью данного устройства и получает доступ к анализируемому трафику сразу после поступления его на определенный интерфейс. Интегрированная в сетевое оборудование система IPS может быть реализована в виде отдельного модуля, вставляемого в шасси маршрутизатора, или в виде неотъемлемой части операционной системы маршрутизатора. Первой в данном направлении развития систем IPS стала компания Cisco Systems, имеющая как отдельные модули для своих маршрутизаторов, так и подсистему Cisco IOS IPS, входящую в состав операционной системы Cisco IOS. Примеру Cisco последовали и другие сетевые производители: Extreme, 3Com и т. д.
Но система IPS, интегрированная в маршрутизатор, умеет отражать атаки только на периметре сети, оставляя внутренние ресурсы без защиты.
Поэтому второй точкой интеграции являются коммутаторы локальной сети (switch), в которые с успехом могут быть внедрены механизмы предотвращения атак, причем как в виде части ОС, так и в виде отдельного аппаратного модуля. Первое слово в данной области сказала компания ODS Networks, предложившая коммутаторы с встроенной системой IPS. Позже ODS была куплена компанией SAIC, а технология интеграции IPS в коммутаторы на время забыта, пока ее не возродила Cisco Systems в своем семействе Cisco Catalyst.
Третий тип устройств, через которые может проходить трафик, нуждающийся в анализе, представлен точками беспроводного доступа (wireless access point). Сегодня это направление активно развивается, что связано со всплеском интереса к беспроводным технологиям (Wi-Fi, WiMAX, RFID). По пути интеграции пошли такие производители, как Cisco Systems и Aruba, оснастившие свое оборудование необходимыми функциями. Такого рода системы, помимо обнаружения и предотвращения различных атак, умеют определять местонахождение несанкционированно установленных беспроводных точек доступа и клиентов. Другие производители (например, Trapeze Networks) не имеют собственных решений, поэтому интегрируются с производителями самостоятельных систем предотвращения атак в беспроводных сетях - AirDefense, AirMagnet, AirTight, Network Chemistry и Newbury Networks.
Последним рубежом обороны, где может быть установлена система IPS, является рабочая станция или сервер. В этом случае IPS реализуется несколькими путями. Во-первых, как программное обеспечение, интегрированное в операционную систему. Пока таких решений немного и все они ограничиваются системами семейства UNIX, поскольку их ядро можно скомпилировать вместе с подсистемой отражения атак. Во-вторых, система IPS на рабочей станции или сервере может представлять собой прикладное ПО, устанавливаемое "поверх" операционной системы. Выпускается большим числом производителей: Cisco Systems, ISS, McAfee, Star Force и другими. Эти системы называются Host IPS (HIPS).
Кроме отражения сетевых атак, они обладают еще большим количеством полезных функций: контроль доступа к USB, создание замкнутой программной среды, контроль утечки информации, контроль загрузки с посторонних носителей и т. д. В-третьих, система IPS может представлять собой отдельную подсистему отражения атак, реализованную в сетевой карте. Некоторые производители (в частности, D-Link) выпускают такого рода устройства, однако их распространенность оставляет желать лучшего. Ситуация может измениться только в том случае, когда такой функционал будет базовым для любой сетевой карты.
Если же вернуться к выделенным средствам предотвращения атак, то основными игроками этого рынка являются компании Cisco Systems, ISS, Juniper; из малоизвестных в России - 3Com, McAfee, Sourcefire, Top Layer, NFR и другие. И уж совсем неизвестны такие производители, как V-Secure, StillSecure, DeepNines, NitroSecurity и Reflex Security.
Особняком стоит технология обнаружения и блокирования аномалий в сетевом трафике, которую поддерживают Arbor Networks, Cisco Systems, Lancope, Mazu Networks и Q1 Labs. Однако данные решения отличаются от классических систем IPS. Прежде всего, они работают не в режиме inline, они имеют дело не с самим трафиком, а, например, с Netflow. Кроме того, продукты данного класса не автономны, а тесно связаны с другими решениями (как правило, с сетевым оборудованием). Наконец, системы обнаружения и блокирования аномалий не предот вращают атаки, а действуют реактивно - изменяют списки контроля доступа (ACL, Access Control Lists) уже после обнаружения атаки.
в области предотвращения сетевых атак.
Мы рассмотрели современные технологии и решения в области предотвращения сетевых атак. Из обзора становится понятно, что до предрекаемой смерти систем IPS еще очень много времени. Разумеется, если их развитие продолжится вместе с информационными технологиями. Сама по себе технология IPS не является панацеей, и ее эффективность зависит от грамотного применения имеющихся инструментов и их интеграции с другими защитными и сетевыми технологиями. Только в случае построения комплексной инфраструктуры защиты системы IPS будут надежным кирпичиком в неприступной стене, опоясывающей вашу организацию.
Информационная безопасность
Avaya – первая и вторая попытки
Первая конфигурация, которую представила компания Avaya для проведения тестирования безопасности VoIP-сети, имела минимальный набор дополнительных сетевых элементов (см. рис.). Фактически в данной конфигурации полностью отсутствовала какая-либо сетевая инфраструктура третьего уровня.
Схема IP-телефонной сети компании Avaya
Все IP-подсети проходили через "плоскую" инфраструктуру коммутируемой Ethernet-сети второго уровня, при этом они, однако, были разделены на несколько изолированных виртуальных ЛВС (VLAN): одна – для голоса, другая – для данных.
Также в сети не были использованы межсетевые экраны. Несмотря на такую "аскетичную" сетевую инфраструктуру, VoIP-решение от Avaya имеет ряд встроенных механизмов безопасности, как-то: система управления вызовами (состоит из двух резервируемых медиасерверов S8700), которая подключается к специальной выделенной ЛВС, которая, в свою очередь, отделена и изолирована от "рабочей" ЛВС предприятия. Серверы подключаются только к специализированному системному IP-интерфейсу, находящемуся в шасси медиашлюза G650; система голосовой почты, которая подключается с помощью аналогового интерфейса. По утверждению компании Avaya, это является преимуществом – даже в случае полного выхода из строя IP-телефонной подсети, например, в результате хакерской атаки, вызовы из телефонной подсети общего пользования могут перенаправляться на систему голосовой почты вне зависимости от состояния IP-подсистемы; для удаленной диагностики и управления системой применяется безопасное выделенное модемное соединение, а не интернет-канал связи. Хоть это и значительно снижает число возможных IP-атак, последним достижением техники его сложно назвать; инсталляция системного программного обеспечения, состоящая из двух этапов. Первый этап заключается в том, что администратор загружает ПО на переносной ПК, а затем только – на систему управления вызовами.
Однако в решении от Avaya управляющая информация не шифруется, а систему паролей, используемую для аутентификации IP-телефонов, вряд ли можно назвать криптографически сильной.
Коммутатор Avaya Cajun P333 также предлагает некоторые средства обеспечения безопасности. Например, в данном случае использовались следующие: для обеспечения безопасности сетевых портов администратор может ограничить число MAC-адресов, подключаемых к нему одним, двумя или тремя. В нашем тестировании для каждого порта определялся только один MAC-адрес. При этом, если пользователя необходимо переключить с одного порта на другой, администратору приходится вручную переконфигурировать устройство. Однако хакерский компьютер может использовать поддельный MAC-адрес реального пользователя или IP-телефона, и коммутатор не почувствует никакой разницы; ограничение доступом к управлению – на коммутаторе можно запретить доступ к системной консоли через IP-сеть (вэб- и Telnet), разрешив управление только через последовательный порт консоли; SNMP-ловушки могут быть сконфигурированы для сигнализации нарушений VLAN или других изменений конфигурации коммутатора.
Команда "хакеров" не смогла получить информацию из SNMP-базы IP-телефонов Avaya, используя доступ с помощью стандартного имени public, к тому же телефоны не могут быть реконфигурированы, выключены или еще каким-то образом выведены из нормального режима работы посредством SNMP.
Два основных "трюка", проделанных командой "хакеров" с оборудованием Cisco, удались и на этот раз – атакующая сторона смогла установить пассивный зонд в соединение IP-телефона с сетью и производить сбор и анализ трафика. При этом VoIP-потоки от/к Avaya 4620 IP-телефонам были зашифрованы.
"Хакеры" также подключили свои ноутбуки к голосовой VLAN и далее производили "опрос" устройств в этой VLAN, однако они не смогли "подделать" IP-телефон или перевести в свою сторону IP-телефонное соединение. Атакующей стороне удалось также выявить две серьезные уязвимости, которые могут быть использованы для того, чтобы прервать нормальное функционирование телефонной сети. Первой эффективной атаке подверглись только IP-телефоны, она была достаточно сложной и включала в себя два этапа.
На первом этапе на IP- телефоны передавался специальный поток пакетов с высокой интенсивностью, что приводило к тому, что устройство перезагружалось, а затем следовала вторая фаза атаки. На последнем этапе телефон получал небольшую порцию IP-пакетов, после которой выходил из строя на 20 минут.
Таким способом можно выключать большое количество IP-телефонов один за одним, а повторно передавая специальный поток пакетов в течение 20-минутного промежутка, IP-телефоны могут быть выведены из строя на продолжительный период времени.
Другая обнаруженная уязвимость состояла в том, что дополнительный порт Ethernet на IPтелефонах Avaya пропускает пользовательские Ethernet-кадры с любыми установленными тегами VLAN. Это значительно упрощает задачу хакеров, так как в данном случае нет необходимости отключать IP-телефон от сети – нужно просто подключить к нему ноутбук и установить необходимый тег VLAN на сетевом адаптере. Кроме того, было выявлено, что определенный тип трафика, пересылаемый на оборудование установки вызовов, может значительно увеличить время установки соединения. Таким образом, хакер может просто "положить" IP-телефонную сеть.
Avaya: второй раунд
Компания Avaya предложила второй вариант своего решения с большим количеством средств обеспечения безопасности (рис. крайний справа). Специалисты компании заменили в IP-телефонной сети коммутаторы второго уровня Cajun P333 на более совершенные устройства третьего уровня от компании Extreme, партнера Avaya.
Новыми ключевыми элементами, вошедшими в состав сети, стали шлюз безопасности Avaya SG208 ($15,000), коммутаторы Extreme Summit 300-48 ($8,000) и Extreme Alpine 3804 ($10,000). При этом набор VoIP-оборудования и версии его ПО не изменились (включая шлюзы, модули и IPтелефоны). Модуль CLAN имел версию ПО под номером 9; модуль медиаобработки – 75, IP-телефоны – 2.0.
Коммутатор Avaya Cajun P333, который использовался в предыдущем тесте, был заменен на Summit 300-48. Таким образом, стоимость оборудования, призванного повысить уровень безопасности IP-телефонной сети от Avaya, составила около $30,000.
Поддержка в сети IP-маршрутизации позволила снизить число возможных хакерских атак. Основными средствами, обеспечивающими безопасность сети, стали: ограничение трафика: коммутатор Summit позволяет ограничить величину широковещательного TCP- или UDP-трафика значением 1 Мбит/с; индивидуальные VLAN: для каждого порта, к которому подключен IP-телефон, была создана своя собственная виртуальная ЛВС.
При этом один IP-телефон не может напрямую связываться с другим IP-телефоном, поскольку они находятся в различных ВЛВС. Естественно, трафик между ними должен маршрутизироваться. При этом он может дополнительно проверяться и блокироваться в зависимости от типа протокола и т.д.
Надо отметить, что настройка отдельной VLAN для каждого IP-телефона является сложной работой для системного администратора, особенно когда число IP-телефонов достигает нескольких сотен. Поэтому масштабируемость такого решения затруднительна.
Также в IP-телефонах была отключена возможность обмениваться напрямую RTP-трафиком, минуя модуль медиаобработки, что делает сеть централизированной и повышает безопасность ее работы.
Однако в этом случае модуль медиаобработки может стать "бутылочным горлышком" для производительности сети. По данным компании Avaya, модуль медиаобработки может обрабатывать до 64-х одновременных вызовов, что опять же снижает масштабируемость решения.
Коммутатор Extreme Alpine мог ограничивать трафик по MAC-адресу источника, и чтобы начать атаку, команде "хакеров" необходимо было "украсть" существующий MAC-адрес IP-телефона. Это было достигнуто опять-таки с использованием пассивного зонда.
Межсетевой экран SG208 был сконфигурирован таким образом, чтобы пропускать трафик только с определенных портов на контроллер вызовов. Только трафик с узкого диапазона UDPпортов мог поступать на модуль медиаобработки и только порты и протоколы, ответственные за передачу H.323-информации управления и сигнализации, могли поступать на CLAN-модуль. Однако команде "хакеров" не понадобилось много времени для того, чтобы определить номера открытых портов с помощью известной техники. Используя "украденные" идентификаторы IPтелефона, "хакеры" смогли установить контакт с контроллером вызовов и получить от него ответ. При этом не нужно эмулировать все аспекты работы реального IP-телефона или даже знать его пароль, для того чтобы получить доступ к контроллеру вызовов. Полная эмуляция работы IP-телефона и знание его пароля необходимы лишь для того, чтобы произвести неавторизированный вызов. Однако большинство хакеров преследует более простые цели.
Как и при первом тестировании сети Avaya, а также сети Cisco, атакующая сторона смогла применить пассивный зонд и подключить его к сетевой инфраструктуре для подключения IP-телефонов, чтобы таким образом производить сбор необходимых данных и мониторинг трафика, однако "разобрать" зашифрованный голосовой трафик не удалось.
Аналогично при помощи собранной информации "хакеры" смогли подключить собственный ноутбук вместо IP-телефона, установив необходимый MAC- и IP-адрес, а также номер VLAN реального IP-телефона, и так получить доступ к VoIP-инфраструктуре.
Многие атаки, которые были успешны в предыдущем случае, уже не работали в усовершенствованной сети, однако команда "хакеров" снова смогла выявить уязвимости. Передавая не большую по объему "пачку" пакетов к контроллеру вызовов и используя определенный тип протокола и номер tcp-порта, "хакеры" могли сорвать процедуры регистрации IP-телефонов. Однако реально это может повлиять на работу только очень небольшого числа IP-телефонов, поскольку процедура регистрации телефона происходит только при его первом подключении к сети. Поэтому если телефон не переключен в другой порт или выключен, ему не нужно проходить процедуру регистрации.
Компания Avaya заявила, что для ликвидации этой уязвимости необходимо установить программную заплату на ПО управления, которую она намерена выпустить в ближайшем будущем. Итоговая оценка безопасности для последнего решения компании от Avaya, учитывая сравнительно не большую опасность выявленных уязвимостей, – "Устойчивое".
Безопасность IP–телефонии — полевые зарисовки
Александр Веселов,
Вопрос сетевой безопасности сегодня достаточно актуален. Каковы же основные аспекты и проблемы безопасности, возникающие в IP+телефонных сетях таких ведущих производителей, как Avaya и Cisco?
Можно ли защитить IP-телефонную сеть от атак хакеров? Да, можно. По крайней мере, это показало тестирование систем IP-телефонии. Однако позитивный результат зависит и от того, IP-УАТС какого производителя используется, и от того, готовы ли вы вкладывать дополнительные средства в планирование, и, разумеется, обеспечение сетевой безопасности. Целью этого тестирования было установить, насколько оборудование IP-телефонии ведущих производителей защищено от преднамеренных атак хакеров. Принять участие в тестировании предложили пяти ведущим поставщикам IP-телефонных решений, однако на это согласились только компании Cisco и Avaya.
Максимально защищенная VoIP-конфигурация от Cisco включала в себя сервер управления вызовами и голосовой почты CallManager, коммутаторы третьего уровня Catalyst 4500 и 6500, a также дополнительно систему обнаружения вторжений (IDS) и межсетевой экран (PIX firewall). Эта конфигурация получила наивысшую оценку по надежности (критерии оценки приведены в таблице справа). Специальной команде "хакеров" не удалось приостановить или даже дестабилизировать работу IP-телефонной сети Cisco в течение трех дней непрерывных атак.
Компания Avaya представила две конфигурации – с минимальным набором средств защиты и соответственной стоимостью, а также максимально защищенное альтернативное решение, которое включало в себя межсетевой экран и коммутаторы третьего уровня производства компании Extreme Network. Уровень безопасности базового решения от Avaya можно оценить как "уязвимый" (см. таблицу справа), в то время как система, оснащенная дополнительными средствами защиты, получила более высокую оценку – "устойчивая". Правила тестирования при этом несколько ограничивали возможности команды "хакеров", состоящей из четырех человек.
Так, например, они могли использовать только хакерский инструментарий, доступный в интернете, атаки должны были осуществляться с сетевого интерфейса пользователя или IP-телефона, как если бы хакер имел возможный доступ к рабочему месту пользователя. При этом основной задачей "хакеров" было приостановить нормальную работу IP-телефонной сети. Команда "хакеров" использовала для этого различные средства сканирования и ряд других методов для определения топологии и конфигурации сети, поскольку не было никакой информации о конфигурации представленных производителями сетей. После проведения разведки на местности и определения целей удара, "хакеры" производили одновременно около десятка различных типов атак в различных комбинациях и последовательности.
Следует учитывать, что согласно нашим правилам тестирования и ограниченной длительности тестов, атаки, проведенные на оборудовании вышеуказанных производителей, не были такими жесткими, какие могли бы произвести настоящие хакеры. Специалисты по безопасности, участвовавшие в тестировании, также отметили, что данные атаки имели среднюю интенсивность и степень опасности.
Крепкий орешек
Компания Cisco в очередной раз доказала, что она способна построить VoIP-сеть, которая может серьезно противостоять изощренным хакерским атакам: они не смогли остановить и даже серьезно помешать ее работе.
Выбранная IP-телефонная сеть (рис.) с использованием сетевой инфраструктуры третьего уровня и дополнительных средств безопасности – наиболее совершенное решение на сегодняшний день, использующее все доступные средства защиты. Необходимо подчеркнуть, что представленная топология состоит из гораздо большего количества средств безопасности, чем используется большинством пользователей. Дополнительно оборудование включает в себя два отдельных межсетевых экрана PIX firewalls ($8,000 каждый), модуль межсетевого экрана для магистрального коммутатора Catalyst 6500 ($35,000), модуль системы IDS для шасси 6500 ($30,000), а также отдельную сеть управления и различные средства управления.
Схема IP-телефонной сети компании Cisco
При этом стоимость межсетевых экранов и системы IDS несколько превышает $80,000. По этому поводу представители компании Cisco говорят, что использовалось оборудование, которое оказалось под рукой, а вообще можно применять гораздо менее дорогостоящие межсетевые экраны и системы IDS от Cisco.
Использование межсетевых экранов значительно повышает безопасность VoIP-сети, поскольку они позволяют определить доверяемые и недоверяемые интерфейсы. При этом недоверяемые интерфейсы всегда были направлены в сторону хакеров. Использование фильтрации трафика с учетом состояния соединения (stateful) позволяет пропускать только необходимый VoIP-трафик и соединения, установленные в необходимом направлении (от сервера к клиенту или наоборот).
Среди других возможностей межсетевых экранов, которые использовались во время тестирования, можно назвать следующие: фильтрация трафика управления установкой VoIP-соединений и возможность передачи трафика управления через NAT и сетевые туннели; TCP-перехват, который обеспечивает проверку закрытия TCP-сессий, что позволяет защищаться от ряда атак типа отказа в обслуживании (DoS) на CallManager; поддержка протокола Secure SCCP (Secure Skinny Call-Control Protocol).
Этот протокол гораздо лучше защищен, чем протокол управления SCCP, ранее использовавшийся в оборудовании компании Cisco для построения VoIP-сетей. Протокол Secure SCCP использует TCP-транспорт вместо UDP и шифрует всю информацию управления.
Четвертая версия ПО 4.0 CallManager, которое управляет процедурой установки вызовов и является "сердцем" VoIP-решений компании Cisco, включает в себя ряд новых функций безопасности. Ключевой среди них можно назвать впервые реализованную в данном релизе CallManager возможность шифрования VoIP-трафика. В настоящее время возможность шифрования данных реального времени протокола RTP (Real-time Transfer Protocol) поддерживается только новыми IPтелефонами серии 7970.

В последних версиях CallManager и в поставляемой с ним специальной версии Windows 2000 также были усилены меры безопасности, что в нашем случае означает, что были отключены неиспользуемые порты и сервисы. Впечатляющий набор средств самозащиты был включен и в последние версии ПО коммутаторов Catalyst. Так, мы использовали IOS 12.2(17b)sxa на магистральном устройстве Catalyst 6500 и IOS 12.1(20)ew на входных Catalyst 4500. Из всего набора оборудования данные коммутаторы являлись основными средствами защиты от поступающих атак, поскольку они расположены на границе сети в первом эшелоне обороны.
В перечень функций защиты входят: ограничение и представление гарантируемой полосы пропускания, что позволяет эффективно подавлять DoS-атаки; Layer 2 port security (ограничивает число устройств с различными MAC-адресами, подключенными к одному порту); Layer 2 Dynamic Host Configuration Protocol snooping, предотвращающий атаки на исчерпание пула адресов DHCP-сервиса; Dynamic Address Resolution Protocol inspection (предотвращает засорение таблиц ARP и "воровство" адресов). Эта функция сорвала очень много запланированных атак; IP Source Guard, который предотвращает атаки с анонимных адресов; Virtual LAN ACL (access control lists), ограничивающий адреса узлов, которые могут передавать данные IP-телефонам.
Агент безопасности Cisco (CSA) – это ПО для обнаружения вторжений, устанавливаемое на отдельном узле, и сегодня оно является неотъемлемой частью CallManager IP-телефонных серверов. Также данное ПО устанавливается для сервера голосовой почты Ciscо Unity и ряда других серверов Win 2000. Агенты CSA после установки запускаются автоматически и постоянно отслеживают сетевые атаки.
Также они обеспечивают ряд мощных дополнительных возможностей: защиту от переполнения буферов сервера; определение приложений типа "троянский конь", "червь"; недопущение запуска незарегистрированных приложений; защиту от атак типа syn flood на стек протокола TCP-сервера; определение сканирования портов, которое обычно производится хакерами для обнаружения запущенных сервисов и их возможных уязвимостей перед началом атаки.
После трех дней непрерывных атак команда "хакеров" не смогла существенно нарушить работу IP-телефонной сети. При этом можно отметить лишь два слабых места в решении от Cisco.
Первое – это то, что "хакерам" удалось подключить пассивный зонд к соединению IP-телефона с сетью. С этого плацдарма они смогли собирать и анализировать поступающий трафик – типы протокола, адреса, а также захватывать RTP-трафик, с помощью которого в сети передаются речевые сообщения. Однако голосовой трафик для IP-телефонов Cisco 7970 может быть зашифрован с использованием 128-битного ключа, который атакующая сторона так и не смогла расшифровать.
Второй негативный момент заключается в том, что с помощью собранной информации "хакеры" смогли подключить свои собственные ПК к сети, получить доступ к голосовой ВЛВС и передавать трафик другим устройствам, находящимся в этой ВЛВС. При этом, однако, они не смогли перевести ни одного соединения или эмулировать IP-телефон. Также команде "хакеров" удалось выявить ошибки в конфигурации двух сетевых устройств, но это уже остается на совести персонала компании.
VoIP безопасен?
Итак, данное исследование выявило основные условия обеспечения сетевой безопасности: эффективными меры безопасности могут быть только тогда, когда они покрывают все уровни сетевой инфраструктуры.
Так, компания Cisco применяет такие средства защиты: на втором и третьем уровнях – модели ЭМВОС (коммутаторы Catalyst), четвертом и пятом – межсетевые экраны и системы обнаружения вторжений, шестом – шифрование RTPголосовых потоков (пока, правда, только для определенных моделей телефонов), и на седьмом уровне – с помощью серверных приложений Cisco Security Agent.
В то же время решения компании Avaya имеют ограниченный набор средств безопасности на втором-третьем уровнях и выше, за исключением шестого уровня. К своей чести, компания Avaya предлагает надежную схему шифрования RTPтрафика (уровень 6) и поддерживает его для всех своих IP-телефонов. Решения компании с максимально задействованными средствами безопасности имеют более эффективные средства защиты на третьем, четвертом и шестом уровнях, хотя при этом не лишены ряда уязвимостей. Следует отметить, что безопасность IP-телефонных решений в связи с их растущей популярностью станет решающим фактором при выборе оборудования того или иного производителя помимо таких стандартных факторов, как цена, производительность, функциональность и т.д.
Подготовлено по материалам "ComputerWorld Украина"
Информационная безопасность
IPSec: панацея или вынужденная мера?
Евгений Патий,
Мало-помалу мы все же пришли к тому, к чему должны были прийти еще лет десять назад, - уважительному отношению к обеспечению безопасности. Имеются в виду не только "режимность", административные меры и прочие механизмы влияния на человеческий фактор, но и вполне обоснованные и логически оправданные технические средства.
Однако, безопасность безопасности рознь. С одной стороны, дискеты (утрирую, конечно, где ж их сейчас встретишь) выносить из офиса запрещается, а с другой - подключение региональных филиалов нередко производится в "открытом" виде... Как-то незаметно коммуникационные технологии стали нормой, редкая компания, ну разве что самая начинающая, не подключена к Интернету стационарным каналом, а слова "эксплойт", "хакеры" и "эпидемия" из комиксных ужастиков перекочевали в обыденную жизнь. И на сообщения новостных сайтов типа "взломана сеть компании Ericsson" или "эпидемия червя Mytob принимает катастрофические масштабы" рядовой пользователь если и обращает внимание, то реагирует довольно вяло. К такому положению вещей все привыкли.
К счастью, подобного рода апатия обусловлена не столько привычкой, сколько существованием эффективных средств противодействия. Новый вирус? В браузере скрипты отключить, подозрительные вложения не открывать. И так далее, каждая ситуация, как известно, требует индивидуального подхода.
К великому удовольствию продвинутых пользователей, имеются весьма действенные, я бы сказал, фундаментальные механизмы, которые пригодятся всегда, несмотря на появление новых технологий и стандартов. В качестве конкретного примера приведем все тот же Wi-Fi, при всех неоспоримых преимуществах и удобствах имеющий колоссальный недостаток: безопасность этого вида связи практически равна нулю. Невзирая на наличие алгоритмов шифрования, скрытия идентификатора сети и прочих средств, опытный взломщик способен проникнуть в сеть максимум за один час. Помнится, на начальном этапе массового распространения Wi-Fi в Сети появились "рецепты приготовления" направленной антенны для перехвата данных, в основе которой лежала алюминиевая пивная банка.
А уж за программным обеспечением и подробнейшими инструкциями по взлому дело не стало.
Но, как уже говорилось, существуют проверенные в боях методы защиты. На фоне их многообразия краеугольными камнями безопасности выглядят IPSec и SSL: два разных подхода, соответственно две сферы применения. Об одном из них и пойдет речь - это IPSec, завоевавший заслуженную популярность у специалистов и рядовых пользователей.
Итак, IPSec (Internet Protocol Security) - набор стандартов, разработанных специально для создания защищенных соединений "точка-точка" (как раз к вопросу о подключении региональных филиалов). Стандарты были разработаны Internet Engineering Task For (IETF) для организации защищенных соединений в публичных или частных сетях TCP/IP. Конечно же, наибольшая выгода появляется при создании защищенного соединения сквозь публичную сеть. Постараемся раскрыть основы и принципы, на которых базируется IPSec, приведем практические примеры его применения и перечислим некоторые продукты, использующие в своей работе IPSec.
Конкуренты IPSec
Многие продукты, которые могут использовать IPSec, взаимодействуют с альтернативной технологией шифрования, именуемой "Уровень защищенных сокетов" (Secure Sockets Layer, SSL). Основное различие между IPSec и SSL в том, что IPSec работает на уровне сети, обеспечивая зашиту сетевого соединения от начала и до конца. SSL же действует на уровне приложений, обеспечивая защиту лишь выбранному приложению, например веб-браузеру или программе для работы с электронной почтой. Хотя как IPSec, так и SSL призваны обеспечить конфиденциальность обмена информацией, что достигается совершенно различными способами. SSL был разработан компанией Netscape для защиты трафика HTTP, проходящего через программу-браузер. SSL - протокол уровня отдельной сессии, и в этом отношении он, несомненно, проигрывает IPSec, который позволяет построить постоянный туннель, не зависящий от проходящего сквозь него сетевого трафика.
Протокол SSL основан на клиент-серверной модели и обычно используется для защиты на отрезке "хост-хост". В связи с тем, что IPSec взаимодействует на сетевом уровне, возможны такие варианты, как "подсеть-подсеть", "сеть-сеть" или "сеть-хост". Это наводит на мысль, что IPSec допускает маршрутизацию, а SSL - нет.
Хотя многие пользователи считают SSL и IPSec конкурирующими разработками, данное утверждение не совсем точно, поскольку IPSec и SSL призваны решать различные проблемы. Если для развертывания IPSec требуется предварительное планирование инфраструктуры, то с SSL все намного проще. Как правило, если и клиент, и сервер изначально способны работать с SSL, то процедура настройки защищенной сессии сводится к крайне тривиальному набору действий, доступному даже начинающему пользователю.
Основы IPSec
В глобальном смысле IPSec - это "каркас", который является частью продуктов, требующих следующей функциональности: организация защищенного соединения между точкой А и точкой В. Используя мощное шифрование и криптование на основе публичных ключей, IPSec может обеспечить защиту соединений от несанкционированного доступа.
IPSec представляет собой набор алгоритмов и протоколов с достаточно гибкой внутренней структурой, что позволяет производителям различных устройств, поддерживающих IPSec, самостоятельно выбирать оптимальные с их точки зрения ключи, алгоритмы и методы аутентификации.
Набор протоколов и алгоритмов шифрования включает следующие позиции: IKE (Internet Key Exhange protocol) ISAKMP (Internet Security Association and Key Management Protocol) AH (Authentication Header protocol) ESP (Encapsulating Security Payload protocol) STS (Station-to-Station protocol) HMAC (Hash Message Authentication Code) MD5 (Message Digest 5) SHA-1 (Security Hash Algorithm) 3DES (Triple Data Encryption Standard) XAUTH (Extended Authentication) AES (Advanced Encryption Standard)
Два важнейших протокола применительно к IPSec - AH (Authentication Header) и ESP (Encapsulating Security Payload). Как ясно из названия, AH используется для аутентификации отправителя информации и обеспечения целостности данных - с целью убедиться, что данные не были изменены в процессе связи. AH не шифрует данные и не обеспечивает конфиденциальности, этот протокол лишь "подписывает" целый пакет данных.
В отличие от AH, ESP способен обеспечить конфиденциальность информации, так как непосредственно шифрует данные совместно с проверкой подлинности и целостности. Отличие от AH состоит и в том, что ESP не подписывает каждый пакет, оперируя лишь данными.
IPSec способен функционировать в двух режимах: транспортном и туннельном, которые представляют собой два разных подхода к обеспечению безопасности. В транспортном режиме шифруются только полезные данные сообщения - непосредственно информация, подлежащая передаче в процессе сеанса связи.
В туннельном - шифрованию подлежат данные, заголовок и маршрутная информация. Нет необходимости говорить, что применение IPSec в транспортном режиме гораздо более рискованно, нежели в туннельном.
Туннельный режим, как правило, используется при построении различных вариаций виртуальных частных сетей (VPN), предоставляя защиту всего трафика от отправителя к получателю. Виртуальные частные сети с IPSec представляют собой сетевые соединения, построенные с использованием криптографии на основе публичных и приватных ключей. Пользователи IPSec VPN генерируют публичные и приватные ключи, которые ассоциируются лишь с ними. Когда сообщение уходит от отправителя к получателю, оно автоматически подписывается приватным ключом пользователя, а получатель использует публичный ключ отправителя для того, чтобы дешифровать принятое сообщение. Конечные точки виртуальной частной сети действуют как базы данных, которые управляют и распространяют ключи и прочую служебную информацию подобно тому, как это делает Certificate Authority (CA).
Преимущества и недостатки IPSec
Наиболее типично применение IPSec для достижения конфиденциальности и целостности данных при их транспортировке по незащищенным каналам. Изначально IPSec предназначался для защиты данных в публичных сетях, однако его различные практические реализации нередко используются для увеличения безопасности частных сетей, так как компании не всегда могут быть уверены, что их корпоративные сети изначально не подвержены вторжениям извне.
Хотя IPSec наиболее популярное и, пожалуй, наилучшее решение для создания виртуальных частных сетей, имеются и некоторые ограничения. В случае его применения в транспортном режиме не исключается возможность атак со стороны, что вызвано некоторыми ограничениями протокола ISAKMP.
Взлом сессии IPSec вполне вероятен, если не используется заголовок аутентификации AH. При таком типе атаки данные злоумышленника могут быть вставлены в полезную передающуюся информацию, например, в случае Unix-систем достаточно вставить в поток команду rm -R, чтобы получатель в итоге недосчитался многих, а то и всех файлов на жестком диске.
Поскольку трафик IPSec маршрутизируем, различные практические реализации IPSec могут подвергнуться более "изящной" атаке - подмене изначального маршрута. Оговоримся, что данный вид атаки возможен лишь при использовании IPSec в транспортном режиме, если же он применяется для построения туннеля, вся роутинговая информация в этом случае шифруется и подобный вид атаки успеха иметь не будет.
Специалисты компании AT&T Research отмечают, что многие потенциально слабые места IPSec являются следствием определенных недостатков алгоритмов шифрования, использованных в конкретной реализации IPSec. Следовательно, с увеличением надежности этих алгоритмов IPSec может стать намного более защищенным.
В настоящее время IPSec - это часть IPv6, но не IPv4. Хотя, конечно же, имеются и реализации IPSec для протокола IP четвертой версии. В реализации для IPv6 некоторые слабые места IPSec, которые все же присутствуют в версии для IPv4, устранены. Так, например, поля фрагментации в заголовке пакета IPv4 потенциально могут быть изменены, поэтому при функционировании IPSec в транспортном режиме злоумышленник может перехватить пакет и изменить поле фрагментации, а затем вставить необходимые данные в передаваемый поток. В IPv6 же промежуточные маршрутизаторы не допускают изменения полей фрагментации.
Типичные применения IPSec
С распространением корпоративных беспроводных сетей компаниям имеет смысл озаботиться развертыванием виртуальных частных сетей VPN. Сегодня организация VPN поверх имеющейся беспроводной сетевой инфраструктуры признана лучшим способом обеспечить конфиденциальность информационного обмена.
Так как беспроводные точки доступа являются устройствами второго уровня, организация VPN-over-Wireless является столь же несложной задачей, как и развертывание VPN на базе проводной сети. Ниже мы рассмотрим пример построения такой виртуальной частной сети с помощью типичного оборудования: ноутбука с Windows XP и программного роутера под управлением популярной операционной системы FreeBSD.
Исходные данные таковы:
Ноутбук Samsung V30 с беспроводной PCMCIA-картой Gigabyte WLMR-101 (802.11b), Windows XP Professional SP2. Точка доступа D-Link DWL-700AP. Коммутатор 3Com OfficeConnect DualSpeed 8 ports. Программный маршрутизатор (Intel Pentium 233MMX, RAM 160 Мбайт SDRAM, SCSI HDD 2 Гбайт), FreeBSD 5.2.1-RELEASE.
Компоненты соединены по схеме, приведенной ниже.

Задача: создать VPN на базе шифрованного туннеля между ноутбуком, имеющим IP-адрес 192.168.1.253, и сервером (192.168.1.1). Предпосылки к этому таковы: имеющиеся средства, которыми производитель предлагает защитить конфиденциальность данных, недостаточны. WEP-шифрование может быть без труда разрушено, а MAC-адрес беспроводной карты - "подслушан" и подменен злоумышленником. В этом случае, естественно, ни о какой безопасности речи быть не может - весь беспроводной трафик попадет к злоумышленнику, а уж последствия зависят от его фантазии и намерений. Поэтому единственный выход - подняться на более высокую ступень эволюции, создав VPN на основе IPSec, ну а взлом такой конфигурации - задача гораздо более сложная. В операционной системе FreeBSD технология IPSec реализована на уровне ядра - то есть, чтобы полноценно ею пользоваться, необходимо собрать ядро с поддержкой IPSec и протокола ESP:
options IPSEC #IP security options IPSEC_ESP #IP security (crypto; define w/ IPSEC) options IPSEC_DEBUG #debug for IP security
После компиляции ядра активизируем эту поддержку в основном конфигурационном файле /etc/rc.conf:
ipsec_enable="YES" ipsec_file="/файл правил"
Описанные выше процедуры уже позволяют организовать VPN на базе IPSec, но для этого нужно еще определить правила в указанном файле, на основе которых будет строиться защищенный туннель. Обычно это файл /etc/ipsec.conf.
Важно учитывать, что мы создаем туннель от ноутбука к серверу, другими словами, трафик будет шифроваться лишь на этом участке; если же сервер является еще и шлюзом для выхода в Интернет (как в описываемом примере), то за пределами сервера трафик окажется уже нешифрованным.
IPSec использует базу данных для того, чтобы решить, как обращаться с трафиком. Эта база данных содержит правила: какой трафик и как именно его шифровать. Правила делятся на два типа: Policy и Association; Security Policy Database (SPD) определяет, какой трафик шифровать, а Security Association Database (SAD) - методы шифрования этого трафика.
Основной инструмент в FreeBSD для управления этими базами данных называется setkey. Определим правила ipsec.conf для нашего случая и рассмотрим их подробнее:
add 192.168.0.1 192.168.1.253 esp 691 -E rijndael-cbc "1234567890123456"; add 192.168.1.253 192.168.0.1 esp 693 -E rijndael-cbc "1234567890123456";
spdadd 192.168.1.0/24 0.0.0.0/0 any -P in ipsec esp/tunnel/192.168.1.253-192.168.0.1 /require; spdadd 0.0.0.0/0 192.168.1.0/24 any -P out ipsec esp/tunnel/192.168.0.1 192.168.1.253 /require;
Первые два правила add - это вхождения SAD, последние два (spdadd) - SPD. Пункты add устанавливают ключи шифрования между двумя компьютерами, а spdadd непосредственно описывают сам туннель. Необходимо четко прописывать правила для каждого направления трафика, так как применительно к IPSec понятия "первый компьютер" и "второй компьютер" слишком расплывчаты, а значит, описание механизма взаимодействия должно быть максимально точным - иначе туннель просто не будет функционировать. Правило 1 определяет индекс 691 и алгоритм шифрования rijndael-cbc с публичным ключом 1234567890123456 между компьютерами 192.168.0.1 и 192.168.1.253. Правило 2 описывает аналогичные требования для обратного направления: от 192.168.1.253 к 192.168.1.1, но с индексом 693. Правило 3: все сетевые соединения внутри 192.168.1.0/24 и "наружу" (0.0.0.0/0) обязательно проходят сквозь туннель. Правило 4: то же, что и правило 3, но в обратном направлении.
Итак, мы выбрали и описали следующую стратегию: ни одного байта мимо туннеля, весь трафик шифруется. После описания правил перезагружаемся с ядром, поддерживающим IPSec, - при этом правила, описанные в /etc/ipsec.conf, загружаются автоматически. Сервер готов к "поднятию" туннеля, но необходимо описать его на ноутбке. Для этого нужно запустить службу IPSec, если она не запущена по умолчанию, и воспользоваться мастером установки сетевых соединений Windows.
Весьма желательно установить на сервере и программное обеспечение для автоматического обмена ключами шифрования - Racoon, иначе на клиентских машинах придется вручную прописывать ключи в дебрях управляющих консолей Windows.
Проста ли настройка IPSec? Пожалуй,
Проста ли настройка IPSec? Пожалуй, проста. Стоит ли внедрять эту технологию вместо ненадежного WEP-шифрования беспроводных сетей? Несомненно, стоит. А тем временем технология IPSec получает крайне неоднозначные оценки специалистов в области безопасности. С одной стороны, отмечается, что протокол IPSec является лучшим среди всех других протоколов защиты передаваемых по сети данных, разработанных ранее (включая разработанный Microsoft PPTP). С другой стороны, присутствует чрезмерная сложность и избыточность протокола - это в принципе не так уж страшно, если овчинка стоит выделки, но некоторые ортодоксально настроенные сетевики отмечают, что имеются серьезные проблемы безопасности практически во всех главных компонентах IPSec.
Соответственно, ответ на вопрос, панацея ли IPSec или вынужденная мера, по нашему мнению, выглядит так: это панацея, потому что вынужденная мера.
Информационная безопасность
Девять мифов о незащищённости ip-телефонии
© ,
IP-телефонию все чаще начинают применять в компаниях. Она повышает эффективность ведения бизнеса, позволяет осуществить многие прежде невозможные операции (например, интеграцию с CRM и другими бизнес-приложениями, создание эффективных call-центров и т. п.), а также снизить издержки на построение и эксплуатацию телекоммуникационной инфраструктуры и совокупную стоимость владения системой.
Более того, ведущие производители рынка телефонии перестали вкладывать деньги в исследования традиционной телефонии - только в IP-телефонию. Однако ее активное развитие сдерживается слухами об ее низкой безопасности. Попробуем развенчать некоторые сложившиеся мифы о незащищенности IP-телефонии.
Архитектура инфраструктуры IP-телефонии состоит из нескольких компонентов:
IP-телефоны, подключаемые к локальной сети и предоставляющие помимо самих звонков широкий спектр дополнительных сервисных возможностей. Например, с телефона на своем рабочем месте я могу принять одновременно несколько звонков, получить доступ к корпоративному и персональному телефонному справочнику, узнать расписание поездов и самолетов или прогноз погоды, уточнить персональное расписание встреч, а также просмотреть электронную и прослушать голосовую почту. Надо отметить, что IP-телефоны могут быть выполнены и в виде программного решения, устанавливаемого на компьютер пользователя (например, на ноутбук); сервер управления, отвечающий за установление телефонных соединений и обеспечивающий ряд дополнительных административных функций; голосовой шлюз, решающий задачу интеграции инфраструктуры IP-телефонии с имеющимися в компании системами традиционной телефонии и выход в телефонные сети общего пользования (ТфОП); голосовые приложения, облегчающие пользователям решение бизнес-задач, - голосовая почта, голосовые меню, система управления звонками для секретарей и операторов, персональная система управления звонками, связанная с личным расписанием сотрудника, система проведения аудиоконференций, интеллектуальные центры обработки вызовов и т. п.
Каждый из этих компонентов может стать мишенью для хакеров, и поэтому каждый из компонентов должен содержать в себе развитые механизмы защиты. Учитывая, что разные производители по-разному подходят к решению этого вопроса, я
остановлюсь на подходе только одного из них - компании Cisco Systems и ее архитектуры AVVID (Architecture for Voice, Video and Integrated Data). И этот выбор не случаен. По данным отчета "WorldWide Enterprise Voice Market: Q2 CY2004" консалтинговой фирмы Synergy Research Group, компания Cisco захватила четыре первых места по продаже различных компонентов IP-телефонии.
Итак, начнем развенчание мифов.
Миф 1. IP-телефония не защищает от подслушивания
"Продвинутые" решения IP-телефонии используют несколько технологий и механизмов, обеспечивающих конфиденциальность телефонных разговоров. Во-первых, это направление голосового трафика в выделенный сегмент сети и разграничение доступа к голосовому потоку путем использования правил контроля доступа на маршрутизаторах и межсетевых экранах. Во-вторых, весь голосовой трафик может быть защищен от несанкционированного прослушивания с помощью технологии построения виртуальных частных сетей (VPN). Протокол IPSec позволяет обезопасить телефонный разговор, осуществляемый даже через сети открытого доступа, например Интернет.
И наконец, некоторые компании реализовали в своих IP-телефонах специально разработанный для обеспечения конфиденциальности голосового потока протокол SecureRTP (SRTP), не позволяющий посторонним проникнуть в тайну телефонных переговоров.
Миф 2. IP-телефония подвержена заражению червями, вирусами и троянцами
Для защиты инфраструктуры IP-телефонии от заражения различными вредоносными программами используется целый ряд защитных мер, позволяющих построить эшелонированную оборону, препятствующую не только внедрению, но и распространению червей, вирусов, троянских коней и других типов вредоносной "фауны".
Первой линией обороны является применение наряду с антивирусами межсетевых экранов и систем обнаружения и предотвращения атак, разграничивающих доступ к инфраструктуре IP-телефонии. Вторая линия обороны строится на использовании систем предотвращения атак и антивирусов на оконечных узлах, участвующих в инфраструктуре IP-телефонии.
Последняя по счету, но не последняя по важности линия обороны - инициатива Network Admission Control. В рамках этой инициативы все не соответствующие политике безопасности (в том числе с неустановленными или неактуальными антивирусным ПО, "заплатками" и т. п.) рабочие станции и серверы не смогут получить доступ к корпоративной сети и, в частности, к сегменту IP-телефонии и нанести ущерб ее ресурсам.
Для незащищенных узлов будет доступен только специально выделенный карантинный сегмент сети, в котором они смогут получить последние обновления для своего антивируса, "заплатки" для ОС и т. п.
Миф 3. IP-телефония не защищает от подмены телефонов и серверов управления
Для защиты от устройств, пытающихся замаскироваться под авторизованные IP-телефоны или несанкционированно подключенных к сетевой инфраструктуре, можно и нужно использовать не только уже упомянутые выше правила контроля доступа на маршрутизаторах и межсетевых экранах, но и развитые средства строгой аутентификации всех абонентов инфраструктуры IP-телефонии (включая сервер управления телефонными соединениями), для подтверждения подлинности которых используются различные стандартные протоколы, включая 802.1x, RADIUS, сертификаты PKI X.509 и т. д.
Миф 4. Злоумышленник с административными
В "серьезных" серверах управления предусмотрены расширенные возможности по наделению системных администраторов только теми правами, которые им нужны для выполнения своих обязанностей. К таким правам могут быть отнесены: доступ к конкретным настройкам только на чтение, полное отсутствие доступа к ним, доступ на изменение и т. д.
Кроме того, все производимые администратором действия должны фиксироваться в специальном журнале регистрации и могут быть проанализированы в любой момент в поисках следов несанкционированной активности.
Поскольку инфраструктура IP-телефонии является достаточно разветвленной, то управление конфигурацией IP-телефонов и взаимодействие их с сервером управления должно осуществляться по защищенному от несанкционированного доступа каналу, позволяющему предотвратить любые попытки прочтения или модификации управляющих команд. Для защиты канала управления могут использоваться различные протоколы - IPSec, SSL, TLS и т. д.
Миф 5. IP-телефонию легко вывести из строя
Несмотря на то что различные компоненты IP-телефонии потенциально подвержены атакам типа "отказ в обслуживании", компании, уделяющие серьезное внимание вопросам сетевой безопасности, предлагают целый ряд защитных мер, предотвращающих как сами DoS-атаки, так и их последствия. Для этого можно использовать встроенные в сетевое оборудование механизмы обеспечения информационной безопасности и дополнительные решения, например:
разделение корпоративной сети на непересекающиеся сегменты передачи голоса и данных, что предотвращает появление в "голосовом" участке распространенных атак, в том числе и DoS; специальные правила контроля доступа на маршрутизаторах и межсетевых экранах, защищающих периметр корпоративной сети и отдельные ее сегменты; системы предотвращения атак на узлах; специализированные системы защиты от DoS- и DDoS-атак; специальные настройки на сетевом оборудовании, предотвращающие подмену адреса, часто используемую при DoS-атаках, и ограничивающие полосу пропускания, не позволяющую вывести из строя атакуемые ресурсы большим потоком бесполезного трафика.
Миф 6. К IP-телефонам можно осуществить несанкционированный доступ
Сами IP-телефоны содержат целый ряд специальных настроек, препятствующих несанкционированному доступу к ним. К таким настройкам можно отнести, в частности, доступ к функциям телефона только после предъявления идентификатора и пароля или запрет локального изменения настроек и т. д.
С целью предотвращения загрузки на IP-телефон несанкционированно модифицированного ПО и конфигурационных файлов их целостность контролируется электронной цифровой подписью и сертификатами X.509.
Миф 7. Сервер управления можно перегрузить большим числом звонков
Максимальное число звонков в час на один сервер управления составляет от 100 000 (в зависимости от конфигурации) до 250 000 при использовании кластера управляющих серверов. При этом администратор может использовать специальные настройки, ограничивающие число входящих звонков необходимым значением.
И наконец, в случае потери связи с одним из серверов управления возможна автоматическая перерегистрация IP-телефона на резервном сервере.
Миф 8. В IP-телефонии легко совершить мошенничество
Сервер управления инфраструктурой IP-телефонии содержит ряд возможностей, позволяющих снизить вероятность телефонного мошенничества, таких, как кража услуг, фальсификация звонков, отказ от платежа и т. п.). Так, для каждого абонента можно:
заблокировать звонки на определенные группы номеров и с них; заблокировать возможность переадресации звонков на различные типы номеров - городские, мобильные, междугородные, международные и т. д.; отфильтровывать звонки по различным параметрам и т. д.
Все эти действия осуществляются независимо от того, с какого телефонного аппарата абонент звонит. Это реализуется путем аутентификации каждого абонента, получающего доступ к IP-телефону. Если пользователь не проходит процесс подтверждения своей подлинности, то он может звонить только по заранее определенному списку телефонных номеров, например в скорую помощь, милицию или внутренний отдел поддержки.
Миф 9. Традиционная телефония более защищена, чем IP-телефония
Это самый распространенный миф в области телефонии. Традиционная телефония, разработанная десятилетия назад, обеспечивает более низкий уровень защищенности, чем новая и более совершенная технология IP-телефонии.
В традиционной телефонии гораздо легче подключиться к чужому разговору, подменить номер, "наводнить" звонками и произвести множество других угроз, даже не имеющих аналогов в IP-телефонии (например, war dialing). Защита традиционной телефонии обеспечивается гораздо более дорогими средствами и механизмами, чем в IP-телефонии, в которой эти средства встроены в сами компоненты этой технологии.
Например, для защиты от прослушивания традиционная телефония использует специальные устройства - скремблеры, централизованное управление которыми невозможно; не говоря уже о дороговизне их приобретения и установки перед каждым телефонным аппаратом.
Вопросы безопасности новых информационных технологий (а к ним относится и IP-телефония) сейчас находятся в центре внимания многих. Никто не хочет, внедряя у себя новомодное решение, помогающее бизнесу, привносить в компанию и новые угрозы. Поэтому сейчас информационная безопасность становится во главу угла при выборе новых ИТ-систем. Этой теме посвящаются и различные публикации.
Например, совсем недавно известный журнал NetworkWorld совместно с независимой тестовой лабораторией Miercom провели полномасштабное исследование защищенности ряда известных решений для построения сетей IP-телефонии. С его результатами можно ознакомиться на сайте . В заключение хочу отметить, что, несмотря на слухи, циркулирующие в среде ИТ-специалистов, насчет низкой защищенности IP-телефонии, на самом деле эта технология гораздо более защищена, чем ее традиционная "сестра". При этом стоимость защиты существенно ниже, а управление намного удобнее и эффективнее, чем в привычной нам телефонии.
Отсюда можно сделать вывод: переход к IP-телефонии, предоставляющей гораздо более привлекательные для бизнеса услуги и функции, - всего лишь вопрос времени. И первый, кто поймет это и осуществит его, станет лидером в своем сегменте рынка.
Что общего между шифрованием и линией Мажино?
Научно-инженерное предприятие "Информзащита" Опубликовано в журнале"PCWeek/RE"
В 1929-34 гг., опасаясь военного вторжения со стороны Германии, французский военный министр А. Мажино предложил построить систему неприступных укреплений по всему периметру северо-восточной границы Франции от Швейцарии до Бельгии. Эта система оборонительных укреплений, протянувшаяся на 380 километров и состоящая из 5600 долговременных огневых сооружений, врытых на глубину до 30 метров, получила название "линия Мажино". Охранял этот, считавшийся неприступным, рубеж гарнизон, насчитывающий около 200 тысяч солдат. Однако в 1940 после того как генерал-фельдмаршал немецкой армии фон Бок обошел данные укрепления через Бельгию и взял Париж, "линия Мажино" пала, лишний раз подтвердив поговорку "не все то золото, что блестит". К сожалению, такая же ситуация складывается в настоящий момент и с шифрованием, которое преподносится многими как панацея от всех бед. И на первый взгляд, может показаться, что это действительно так. Почему-то считается, что шифрование - спасает от неусыпного ока государства, хакеров и им подобных любителей заглянуть в замочную скважину. Если данные скрыты от посторонних глаз и согласно математическим расчетам на вскрытие шифра потребуется сотни лет, то многие закономерно считают, что этого достаточно для безопасности своих данных. Но, как поется в художественном детском фильме "Айболит-69" и как продемонстрировал германский генерал фон Бок: "Нормальные герои всегда идут в обход".
Многие видели на городских улицах банковские бронированные КАМАЗы, перевозящие деньги от одной точки к центральному хранилищу. Закованные в броню КАМАЗы, в недрах которых могут находится баснословные ценности, - это точная аналогия шифрования информации. Кстати, а вы уверены, что эти КАМАЗы перевозят огромные ценности? Может быть они перевозят обеды для сотрудников удаленного офиса? Однако оставим вопрос соизмеримости стоимости защитных мер со стоимостью защищаемой информации за рамками данной статьи и вспомним любой гангстерский боевик, в котором грабители нападают на грузовики, перевозившие ценности.
Как они это делали? Случаи грубого взрыва автомобиля или его угона с последующей безрезультатной тратой не одного месяца на вскрытие бронированной двери автогеном практически не встречаются. А если они и происходят, то только по причине неопытности нападавших. Более "продвинутые" грабители идут другим путем. Они или заставляют сидевших в грузовике инкассаторов самим открыть двери фургона, либо совершают свои опустошительные набеги в момент загрузки или выгрузки мешков с деньгами. В других фильмах, в которых бездарные злоумышленники безуспешно пытались проникнуть за бронированную перегородку, перебирая все возможные вариации или крутя диск на дверце сейфа, "продвинутые" грабители подсматривали в подзорную трубу нужную комбинацию. Эти фильмы и подсказывают нам все слабые места шифрования.
Слышали ли Вы о случаях взлома каких-либо шифров по причине слабой математики? И не просто о гипотетической возможности взлома, а о реально произошедшей в каком-либо банке или военном ведомстве примере? Я - нет (если не брать в расчет слухи о том, что Кучма взломал шифры посольств стран НАТО, о чем повествовала "Новая газета" 30 сентября 2002 года). Все о чем мне доводилось слышать - это о различных попытках полного перебора возможных ключей шифрования для распространенных алгоритмов шифрования (например, DES и RC5). Наиболее известный проект - distributed.net, направленный на привлечение свободных сетевых компьютеров для участия в распределенных вычислениях ключа шифрования. Даже для алгоритмов с длиной ключа 64 бит время перебора составляет не менее 3 лет, а современные алгоритмы используют ключи длиной 128 и больше бит. Немного забегая вперед, скажу, что почти все известные случаи взлома шифров были осуществлены другими способами. Например, чтение засекреченных данных немецких военных во время второй мировой войны стало возможным благодаря тому, что в руки союзников попала шифровальная машина Энигма. В других случаях, ключи шифрования попадали в руки военных агентурными или иными (но, как правило, не математическими) методами.
Однако это только так кажется, что шифр ломается только специалистами-математиками, и только используя сложные алгоритмические преобразования. На практике все гораздо прозаичнее и ореол таинственности, которым себя окружают различные спецслужбы, сквозит прорехами, через которые мы и заглянем в эти "тайны". Можете ли вы запомнить ключ "cю}БТфР9" (0x63DE7DC154F4D039)? А ведь именно такой ключ использовался в проекте distributed.net по взлому 64-битного алгоритма RC5. А можете ли вы сами создать такой ключ? Скорее всего, для ключа шифрования вы воспользуетесь гораздо лучше запоминаемым словом. Понимая это, злоумышленники концентрируются на совсем иных способах проникновения за завесу тайны, чем обычный метод "грубой силы". Во-первых, на человеческом факторе. Зная, КАК пользователи выбирают себе пароли, злоумышленник может существенно сэкономить себе время. А как происходит такой выбор? Пользователь, как существо по природе своей ленивое, не хочет утруждать себя процедурой выработки правильного ключа шифрования и тем более заниматься тестированием качества созданного им пароля. Мало того, даже если кто-то побеспокоился о пользователе и создал для него стойкий ключ, пользователь не захочет напрягать свои мозговые клетки для запоминания сложной комбинации цифр и букв в верхнем и нижнем регистрах. В большинстве случаев пользователь выберет для такого ключа свое имя, название своей компании, имя жены или любимой рыбки, номер телефона или автомобиля и т.п. В "лучшем" случае пользователь для ключа выбирает какое-то осмысленное слово, но и здесь его подстерегает ловушка. Несмотря на то, что всех возможных комбинаций букв русского языка очень много, 17-томный "Словарь современного русского литературного языка" включает в себя всего 120480 слов (кстати, 4-хтомный "Словарь живого великорусского языка" В.И. Даля содержит около 200000 слов). Но где вы встречали человека, который оперирует таким многообразием слов? Даже Пушкин оперировал всего 22000 словами ("Словарь языка А.С.
Пушкина" включает 21 290 разных слов), а словарный запас современного взрослого образованного человека, по данным ученых, не превышает 10-12 тысяч слов. Осуществить их полный перебор не составляет большого труда даже для персонального компьютера средней мощности. А зная область интересов человека, ключ или пароль которого необходимо узнать, число возможных вариантов сокращается еще больше. Известен анекдотичный случай, когда при запросе "Введите пароль:" около трети американских военных вводили… "пароль". Еще больше число возможных вариантов сокращается, если знать, что большинство паролей вводится только в нижнем регистре без применения цифр, знаков препинания и иных символов. Ну и, наконец, в Internet можно найти уже готовые файлы, содержащие 200 самых распространенных паролей", "1000 самых распространенных паролей" и т.п. Таким образом, спецслужбам нет нужды заниматься сложными алгоритмическими преобразованиями, направленным на взлом того или иного шифра. Достаточно знать основы человеческой психологии в применении к информационной безопасности.
Другой способ обойти все шифровальные препоны - проникнуть в устройство, осуществляющее шифрование. Другими словами, достаточно внедрить на ваш компьютер троянца и все, "ваше дело в шляпе". Злоумышленники смогут получить доступ ко всей важной информации, в т.ч. к паролям и ключам шифрования. Так, например, поступили в 1999 году агенты ФБР, пытавшиеся получить доказательства преступной деятельности мафиози Никодемо Скарфо, делающего деньги на нелегальном игровом бизнесе в Нью-Джерси. Этот субъект шифровал все компрометирующие себя файлы (по некоторым данным с помощью известной программы PGP). Однако агенты ФБР оказались тоже "не лыком шиты", - они внедрили на компьютер Скарфо клавиатурного шпиона, который регистрировал все нажатия клавиш, в т.ч. и в момент ввода пароля доступа к засекреченным данным. После этого ФБР смогло собрать все необходимые доказательства и улики, и в феврале 2002 года Скарфо был осужден американским правосудием.Именно поэтому в инструкциях ко многим средствам криптографической защиты написано, что пользователь обязан обеспечить защиту своего компьютера и ключей. Но кто из, считающих себя продвинутыми, пользователей читает документацию?
Эти два примера лишний раз показывают, что шифрование само по себе не решает никаких проблем. Без применения дополнительных мер защиты (технических и организационных) использование шифрования лишь введет вас в заблуждение по поводу вашей защищенности. А нет ничего хуже чувства ложной безопасности. Вы будете думать, что ваши данные надежно скрыты от любопытных глаз, а на самом деле к ним смогут получить доступ все желающие.
В заключение хочу только привести слова известного во всем мире специалиста по информационной безопасности Юджина Спаффорд о шифровании: "это эквивалентно применению бронированного автомобиля для перевозки кредитной карты от кого-то, живущего в картонной коробке, кому-то, живущему на скамейке в парке".
Информационная безопасность
Альтернативная ОС надежнее Windows?

| ОС | Достоинства | Недостатки | | Windows XP Professional | Защищенная регистрация пользователя; шифрование файлов; простейший защитный экран; автоматический, полуавтоматический и ручной режимы обновления; обилие коммерческих и бесплатных программных защитных экранов (см. "Безоговорочная безопасность сети: установка межсетевого экрана для отдельного хоста", "К+П" N2/2004) и антивирусов (см. "Сам себе антивирус", "К+П" N2/2004) | Возможности встроенного защитного экрана ограничены: он блокирует только входящие соединения и по умолчанию отключен (в SP2 будет включен). Патчи для обнаруживаемых недостатков в системе защиты появляются через несколько дней или месяцев. Огромное количество вирусов и интернет-червей предназначено специально для этой ОС | | Linux (ядро 2.4) | Защищенная регистрация пользователя; управления доступом к файлам на уровне пользователя; двунаправленный защитный экран; в некоторых дистрибутивах предусмотрены автоматический, полуавтоматический и ручной режимы обновления; есть много коммерческих и бесплатных защитных экранов; необходимость в антивирусе возникает редко; недостатки системы защиты обычно устраняются в тот же день | Шифрование файлов требует глубоких знаний операционной системы; то же самое в некоторых дистрибутивах касается защитного экрана; в большинстве дистрибутивов защитный экран отключен | | Mac OS X | Защищенная регистрация пользователя; управления доступом к файлам на уровне пользователя; шифрование файлов методом drag-and-drop; двунаправленный защитный экран; автоматический, полуавтоматический и ручной режимы обновления; много защитных экранов и антивирусов; вирусов и интернет-червей для этой ОС меньше, чем для Windows | Защитный экран с GUI- интерфейсом блокирует только входящие соединения и по умолчанию отключен. Настройка двунаправленного защитного экрана выполняется вручную или посредством приобретаемых дополнительно утилит. Известные недостатки системы защиты Патчи для обнаруживаемых недостатков в системе защиты появляются через несколько дней или недель |
Автоматическое обновление основных программ
Независимо от того, сколько сил вы прилагаете к защите ПК, вас могут подвести "дыры" в операционной системе и приложениях, через которые на компьютер из интернета попадает всякая нечисть.
Некоторые специалисты рекомендуют отказаться от автоматической загрузки и установки обновлений, приводя довольно веский аргумент: что, если патч окажется несовместим с важной программой или компонентом операционной системы? Другие считают, что риск не так велик и игра стоит свеч, ведь слишком многие пользователи попросту ленятся самостоятельно скачать и установить обновление, и однажды у них на руках оказывается компьютер, взломанный через "дыру", патч к которой вышел на прошлой неделе.
Операционные системы Windows 2000, на которых установлен Service Pack 3, допускают автоматическое обновление, однако активируется эта функция несколько сложно. Microsoft подробно объясняет процедуру настройки. Что же касается Windows XP, то для того чтобы компьютер стал получать автоматические обновления, щелкните правой кнопкой мыши на пиктограмме My Computer, выберите команду Properties, перейдите на вкладку Automatic Updates, включите режим Keep my computer up to date, выберите в разделе Settings один из трех режимов загрузки и установки обновлений и щелкните на кнопке OK.
Современные антивирусные программы обычно задерживают вирусы, интернет-червей и "троянские" программы из интернета, при условии регулярного обновления базы данных вирусных сигнатур. Многие (но не все) антивирусные программы загружают и устанавливают собственные обновления и обновления вирусной базы автоматически, по умолчанию. Проверьте настройки программы (и загляните в документацию), чтобы убедиться, что программа поставлена на максимально высокую степень защиты.
Безопасность без проводов
Беспроводные сети - привлекательная новинка, которая только начала вступать в свои права. Но в отношении безопасности это сущий кошмар. Если не изменить стандартную настройку беспроводной локальной сети, то в такую сеть может с ногами влезть всякий желающий, кто так или иначе попал в пределы ее радиодиапазона - любой сосед, прохожий или проезжий. Вот некоторые простейшие мероприятия, которые повысят безопасность беспроводной сети. Настройте точку беспроводного доступа или беспроводной маршрутизатор так, чтобы они не рассылали свой SSID (имя точки доступа). Большинство точек доступа по умолчанию каждые несколько секунд рассылает короткие сообщения всем компьютерам, находящимся в зоне досягаемости. Если отключить эту функцию, все проходящие мимо вашей Wi-Fi именно пройдут мимо. Замените стандартный SSID. Даже если маршрутизатор не рассылает SSID, стандартное имя, предлагаемое ведущими производителями, обычно хорошо известно заинтересованным людям. Достаточно заменить в этом имени всего один символ - и посторонним станет гораздо труднее проникнуть в вашу сеть. Шифруйте соединения с помощью нового кода WPA или более старой, но все еще применимой схемы WEP. Это самый высокий уровень защиты точки доступа, трудноугадываемый пароль, который остановит если не всех, то большинство взломщиков. Если точка доступа не поддерживает WPA, можно получить у производителя и установить новую программную прошивку, поддерживающую шифрование. Включите фильтрацию MAC-адресов. Каждый сетевой адаптер - для кабельной или беспроводной сети - имеет уникальный MAC-адрес. Можно настроить точку доступа таким образом, чтобы она предоставляла доступ к беспроводной сети только компьютерам с определенными MAC-адресами. Будьте осторожны, пользуясь общественной беспроводной сетью - такие сети начинают появляться в аэропортах, гостиницах и офисах высокого класса. Другие пользователи такой сети могут без особого труда узнать ваш пароль, когда вы будете проверять почту, а также прочитать ваши электронные сообщения и другие данные, которые вы получаете или передаете. Если в офисе есть виртуальная частная сеть (Virtual Private Network, VPN), всегда используйте ее при доступе через общественную сеть Wi-Fi. Если же VPN отсутствует, попросите вашего провайдера предоставить вам защищенные параметры почтового сервера или используйте для электронной почты защищенный веб-интерфейс. Включая режим совместного использования файлов в Windows, вы откроете доступ к ним любому, кто сидит за соседним столом. Так что лучше отключить эту функцию или заблокировать доступ с помощью программного защитного экрана.
Биометрическая защита

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

Самые лучшие, схемы шифрования, сложнейшие пароли, жесточайшая система обеспечения безопасности не скроют данные от любопытного сотрудника, если держать компьютер открытым. (Да и дома многие не прочь закрыть некоторые каталоги от любопытных отпрысков, которые слишком рано узнали, откуда берутся файлы.) По данным Федерального бюро расследований, в США 45% случаев несанкционированного доступа виновниками оказываются "свои" - постоянные сотрудники или работники по контракту. Задача обнаружения вторжения в этом случае осложняется тем, что обнаружить таких злоумышленников и закрыть им доступ сложнее, чем неизвестному хакеру, который ломится в сеть через защитный экран. Тем не менее, следует принять хотя бы элементарные меры безопасности - возможно, они не спасут от злого умысла, но преградят путь праздному любопытству (см. также "Безопасность информации: защищаться нужно грамотно", "К+П" N7/2003, "Строим забор своими руками, или создание отдела информационной безопасности", "К+П" N11/2003)
Какая программа "стучит"?
Бывает так, что на компьютере ничего не делается, а модем мигает лампочками. Возможно, это загружается и устанавливается обновление какой-нибудь программы или выполняется другая обслуживающая процедура. Но иногда такое поведение компьютера является свидетельством того, что ПК захвачен извне и общается c новым хозяином.
В WindowsXP можно просмотреть список всех программ и выяснить, с кем они ведут "разговор". Для этого, подключившись к интернету, выберите команду Start > Run, введите в поле Open команду cmd, щелкните на кнопке OK и введите еще одну команду:
netstat -no
В ответ Windows выдаст список всех активных сетевых соединений, указав в том числе IP-адрес вашего компьютера, IP-адрес приемника данных и идентификатор процесса (PID) той программы, которая, работая на вашем компьютере, установила это соединение. Любая программа, даже фоновая, имеет уникальный PID. Для того чтобы определить, какая программа соответствует тому или иному PID, необходимо обратиться к списку процессов в Task Manager. Для того чтобы открыть это окно, нажмите <Секд+Alt+Del> и щелкните на кнопке Task Manager. Затем перейдите на вкладку Processes и найдите в столбце PID интересующий вас номер. Есть и более удобные способы получения той же информации - с помощью бесплатных утилит, таких как , а также из журналов, которые ведутся программными защитными экранами.
Если в одном из таких списков вам встретится программа с незнакомым именем, не спешите тревожиться: многие компоненты Windows имеют очень замысловатые названия. Обратитесь к WinTasks Process Library или проконсультируйтесь с Google. Если выяснится, что "незнакомец" - это "червь" или "троянский конь", обновите антивирусный пакет, отключитесь от интернета (на всякий случай выдерните кабель из разъема) и как следует просканируйте жесткий диск. В самом худшем случае - от чего храни вас Дух интернета! - придется переформатировать жесткий диск и установить Windows "с нуля". Надеемся, вы заблаговременно создали резервную копию важных файлов…
Компьютер на замке
Елена Полонская,
Хакеры, спамеры, недобросовестные сотрудники и коллеги… Плохишам и просто праздным любопытным вход в компьютер должен быть заказан. Как и важным данным - выход оттуда
Вместе с распространением новых компьютерных технологий - портативных и карманных ПК, беспроводных сетей и устройств для них - появляются новые методы взлома компьютеров и похищения информации. Впрочем, старые методы, рассчитанные не столько на технику, сколько на слабости человеческие, тоже исправно работают - как говаривал г-н Воланд, люди не изменились. И многое делают по привычке, не раздумывая. Разумеется, привычки эти люди заинтересованные знают наизусть и успешно используют. Мы не берем на себя смелость полагать, что после прочтения этой статьи вы заживете как-то иначе. Мы только надеемся, что некоторые из высказанных здесь соображений приведут вас к мысли изменить привычку.
Нет данных - нет риска
Настолько ли важны данные, что их потеря или повреждение стали бы настоящим бедствием?
Если сверхсекретный файл списывается на ноутбук без шифрования, и ноутбук затем вывозится из офиса, вряд ли стоит особенно удивляться, если однажды содержимое этого файла станет известно тем, кому вам меньше всего хотелось бы его сообщать. Вместо того чтобы повсюду носить с собой подобную ценность, не лучше ли оставить ее на сервере или на компакт-диске в надежном сейфе, и удалить все важное с жесткого диска, которым вы пользуетесь каждый день (см. "Центр восстановления информации", "К+П" N6/2003)?
Нет - спаму!
Вероятно, одним из главных рассадников "заразы" на компьютере является папка для входящей электронной почты. Именно отсюда начинают свой путь вирусы, "черви" и "рыболовные" программы, обманом заставляющие пользователя раскрыть свой пароль, номер кредитной карточки и другие персональные данные. Вот несколько способов навести порядок в "злачном месте", каким подчас является почтовая программа. Используйте встроенный в почтовый клиент или внешний фильтр спама (см. "Фильтры спама", "К+П" N11/2003), чтобы отсеять большую часть спама. Никогда не запускайте файл, прикрепленный к сообщению электронной почты, не "пропустив" его через антивирусную программу. Настройте Windows так, чтобы вирусные вложения не маскировались под обычные файлы. Для этого откройте Control Panel, выберите команду View > Folder Options, перейдите на вкладку View, отключите режим Hide extensions for known file types в разделе Advanced settings и щелкните на кнопке OK.
Ноутбук - бумажник для файлов
Специалисты по безопасности и просто опытные люди советуют всегда держать ноутбук, КПК или электронную записную книжку при себе, как кошелек или паспорт, не забывая при этом регулярно удалять с них важные файлы и шифровать все остальное.
Сегодня все чаще встречаешь в библиотеках, вузовских коридорах, кафе, залах ожидания и других общественных и полуобщественных местах людей с ноутбуками. Оставлять такую вещь с незашифрованными файлами в подобном месте - не просто рискованно, а безрассудно.
Конечно, можно поступить на манер владельцев велосипедов и прикрепить компьютер проводом к чему-нибудь неподвижному - к полу, стене, ножке стола (если он закреплен неподвижно). Но, разумеется, такое срабатывает ненадолго и только на достаточно открытой местности. Где-нибудь в гостиничном номере у злоумышленника будет достаточно времени, чтобы отсоединить провода. Многие ноутбуки, некоторые настольные ПК и даже ЖК-мониторы имеют встроенные стандартные слоты для такой кабельной блокировки.
Пароль на BIOS
Большинство типов BIOS допускает парольный вход при запуске системы. Такой администраторский пароль не даст злоумышленнику изменить параметры BIOS (например, отключить пароль загрузки). О том, как запускается программа настройки BIOS, можно узнать из справочного руководства к компьютеру или из его электронной справочной системы. Как правило, для настройки BIOS нужно перезапустить компьютер и, пока на экране светится первая заставка, нажать , , или другую клавишу или комбинацию клавиш - часто эта комбинация сообщается в заставке. Некоторые новые модели компьютеров поставляются с конфигурационной программой, позволяющей изменять настройку BIOS из Windows. Когда программа настройки запустится, найдите раздел паролей или безопасности, внимательно прочтите экранные инструкции, введите пароль, сохраните измененные параметры и перезапустите систему.
Пароль, который вы введете, очень важен. Поэтому некоторые рекомендуют записать его (очень внимательно, с учетом регистра букв) где-нибудь в таком месте, где вы его найдете, но любой другой человек - нет. Однако предупреждаем: многие места хранения, которые нам представляются надежными, в сущности, достаточно тривиальны, и любой заинтересованный человек быстро раскроет наш секрет. Поэтому, если вы хоть сколько-нибудь сомневаетесь в собственной изобретательности, лучше полагаться на память и никогда не доверять пароль бумаге.
И, конечно же, следует помнить, что пароль BIOS остановит далеко не каждого. В конце концов, нужно же предусмотреть что-то для спасения данных на случай, если пользователь забудет свой пароль? В некоторых системах для этого есть "мастер-пароли", списки которых встречаются в интернете. На других моделях можно обойти пароль с помощью определенных комбинаций клавиш или манипуляций мышью.
Наконец, если у злоумышленника появится возможность вскрыть системный блок, то он просто отменит пароль, изменив положение переключателей на материнской плате или удалив батарейку питания на чипе памяти BIOS. Если такое может произойти, просто поставьте замок на корпус.
Пароль на Outlook
Часто наиболее важные данные хранятся в папке входящей или исходящей почты. К счастью, есть ряд программ для шифрования и дешифрования почты.
Например, для шифрования писем в Outlook2000 и 2003 нужно выбрать команду File > Data File Management > Settings > Change Password, ввести пароль в поля New password и Verify password и щелкнуть на кнопке OK. После этого только тот, кому известен пароль, сможет просмотреть полученные сообщения, хранящиеся в основных и созданных вами дополнительных папках Outlook.
В Outlook Express можно защитить паролем только идентификаторы электронной почты (файл, в котором хранятся имя пользователя и пароль учетной записи). Для этого нужно выбрать команду File > Identities > Manage identities, выбрать учетную запись, которую вы хотите защитить, щелкнуть на кнопке Preferences, включить режим Require a password и щелкнуть на кнопке OK. Тогда злоумышленник не сможет воспользоваться вашим почтовым ящиком, чтобы получить новую почту. Однако при наличии определенных навыков это не помешает ему импортировать ваши сообщения в другую программу. Вообще, специалисты советуют по возможности не использовать браузер и почтовый клиент Microsoft, так как слишком многие хулиганы интернета направляют свои усилия на взлом именно этих программ.
Программная безопасность
Если физически все устройства защищены, пора подумать о том, чтобы программное обеспечение - и операционная система, и приложения - не допускали взлома, похищения или повреждения данных. Прежде всего, следует закрыть все программные лазейки, которые разработчики ПО по умолчанию оставляют открытыми. Необходимо также использовать дополнительные функции, такие как парольная защита, которые не позволят совать нос в ваши файлы кому попало.
Шифрование файлов
Если вам все-таки приходится хранить на рабочем ПК важные файлы, возможно, их стоит зашифровать, особенно если ПК портативный. В Windows 2000 и XP Professional (но не XP Home) есть встроенные функции шифрования для отдельных файлов и папок. Впрочем, если они вам не понравятся, можно установить специальное программное обеспечение для шифрования.
Шифрование значительно затруднит злоумышленнику запуск компьютера с загрузочного или аварийного диска, подбор паролей и получение контроля над операционной системой.
Длят ого чтобы зашифровать папку в Windows 2000 или XP Professional, щелкните правой кнопкой мыши в окне Explorer (Проводник), выберите команду Properties, щелкните на кнопке Advanced, включите режим Encrypt contents to secure data и два раза щелкните на кнопке OK. Затем еще раз щелкните на кнопке OK, чтобы принять предлагаемое по умолчанию условие - Apply changes to the selected items, subfolders, and files.
Однако все хорошо в меру: шифрование всего диска займет много времени, снизит скорость работы системы и повысит вероятность того, что однажды вы тоже потеряете доступ к файлам. В общем, если только диск не забит сведениями чрезвычайной важности, подобная мера - все равно что пушка против воробьев.
Шпионские штучки
Если на панели задач или браузера неожиданно появляются новые пиктограммы, возможной причиной этого может оказаться "шпионская" или рекламная программа, незаметно проникшая на компьютер. Для того чтобы такого не случилось, нужно следить за тем, какие компоненты устанавливаются при инсталляции различных бесплатных программ, и использовать антишпионоские утилиты, такие как PepiMM Software Spybot или . Хуже обстоит дело с "разрешенными" шпионскими программами, установленными начальником или ревнивой супругой (ссылка на статью в том же номере).
Убить вирус
Из всех опасностей, подстерегающих компьютер в интернете, больше всего неприятностей приносят, пожалуй, вирусы и их вариации - "троянские кони" и "черви". Использование антивирусной программы со свежей базой предотвратит большинство вирусных атак, но если вирус поразит компьютер до того, как вы обновите базу, компьютер и сам пострадает от инфекции, и другие машины заразит. Для того чтобы защититься от неизвестных атак, необходимо предупредить действия хакеров и закрыть от вируса наиболее уязвимые места компьютера прежде, чем атака случится. Вот несколько таких профилактических мер.
Резервное копирование. Интернет-червь MyDoom, поразивший в свое время тысячи компьютеров, к счастью, оказался сравнительно безвредным - он не разрушал файлы и не похищал информацию. Представьте себе, что было бы, если бы это произошло… но вы заблаговременно создали резервную копию важных данных. А ведь следующий червь может оказаться н таким безвредным.
Своевременное обновление. От нашествия червя Blaster пострадало много народу… но только те, кто не установил патч, выпущенный несколько месяцев
Уходя, заприте дверь
Всегда, всегда одно и то же: пароль не должен быть датой, именем или словом, которое есть в словаре. Пароль обязательно должен содержать большие и маленькие буквы, цифры и хотя бы один специальный символ. Пароль не должен быть логичным - и тем не менее, лучше его запомнить. Если же потеря данных может обойтись очень дорого, можно потратиться на биометрическое устройство.
Отходя от компьютера даже "на минутку", сделайте так, чтобы вашим отсутствием никто не воспользовался. Проще всего придумать хороший пароль и закрывать на него компьютер, куда бы вы ни отлучались - на обед или в уборную. Для этого в Windows2000 выберите команду Start > Shutdown > Log off <имя пользователя>, а в Windows XP - StartрLog off. Для того чтобы сеанс завершался автоматически, щелкните правой кнопкой мыши на рабочем столе Windows, выберите команду Properties и перейдите на вкладку Screen Saver. Затем в Windows 2000 выберите хранитель экрана, включите режим Password protected и щелкните на кнопке OK, а в Windows XP - введите в поле Wait достаточно короткий период простоя (некоторым хватает 3-5 мин, но если вы любите сидеть за экраном, задумавшись, то лучше увеличить это время до 15 мин), включите режим On resume, password protect и щелкните на кнопке OK.
Вход - только по паролю
Система регистрации в Windows2000 или XP сильно затрудняет доступ к вашим файлам другим людям, даже если они пользуются тем же компьютером - в отличие от паролей Windows 98 и Me, обойти которые до смешного легко. Проблема заключается в том, что ни одна из операционных систем Windows не требует использования пароля - это только одна из функций, которой можно воспользоваться, а можно и нет. По умолчанию в Windows 2000 и XP Home Edition пользовательские учетные записи создаются без пароля и пользователь регистрируется автоматически, даже если его учетная запись принадлежит к всесильной администраторской группе. При отсутствии пароля учетной записи любой может украсть ПК, получить доступ ко всем данным и ввести свой пароль, который не даст вам сделать то же самое, или создать свою запароленную учетную запись, с помощью которой он сможет делать все, что угодно. То же самое касается "пустых" паролей, который только делают систему более уязвимой через интернет.
Для того чтобы создать пароль для учетной записи в Windows 2000, нужно открыть Control Panel (команда Start > Settings > Control Panel), дважды щелкнуть на пиктограмме Users and Passwords и поставить "птичку" против надписи Users must enter a username and password to use this computer. Затем нажмите и щелкните на кнопке Change Password. Если до того пароля не существовало, поле Old Password будет недоступно; если же пароль был, введите оба варианта - старый и новый - в соответствующих полях и щелкните на кнопке OK. Для того чтобы выполнить аналогичную операцию в Windows XP, откройте User Accounts Control Panel, выберите учетную запись, которую хотите защитить паролем, и щелкните на кнопке Create a password.
Загрузка с паролем
Максимальная длина пароля Windows - 26 символов, среди которых могут быть буквы, цифры и специальные символы. Казалось бы, достаточно, чтобы у хакера закипели мозги. Но что пользы в пароле, если жесткий диск можно прочесть и не запуская Windows? Для этого достаточно загрузочной дискеты или компакт-диска, знания команд DOS или хотя бы Volkov Commander.
Для того чтобы закрыть эту дверь, запретите в BIOS запуск компьютера с любых устройств, кроме жесткого диска (или, если это невозможно, поставьте жесткий диск в качестве первого загрузочного устройства). Если компьютер стоит в людном месте, где сложно уследить за доступом к нему, возможно, стоит вообще удалить из него дисковод, привод CD (DVD), а также отключить или удалить порты USB и FireWire, чтобы кто-нибудь не запустил ПК в DOS или Linux с диска, IPod, флэш-памяти USB или жесткого диска FireWire.
Защищенный интернет

Internet Explorer - самый распространенный веб-браузер. В том числе у хакеров и спамеров. Поэтому на бедного пользователя буквально дождем сыплются рекламные объявления, спам и прочий мусор, создатели которого досконально изучили возможности IE. Дело может зайти далеко, от непрошеных "всплывающих окон" и "хелперов" до установки рекламного ПО, замены информации на домашней странице и даже кражи данных.
Многих опасностей можно избежать, просто усилив режим безопасности самого Internet Explorer, отказавшись от установки элементов управления ActiveX, которые предлагается загрузить на некоторых веб-страницах. Для этого нужно, открыв Internet Explorer, выбрать команду Tools > Properties, перейти на вкладку Advanced и включить соответствующие режимы в разделе Security.
Но еще лучше отказаться от IE в пользу другого браузера, не поддерживающего ActiveX, - например, или .
Защита администратора прежде всего
Главная учетная запись, которую необходимо защитить паролем, - это учетная запись администратора. Простое переименование будет малоэффективным. Кроме того, напоминаем еще раз: пользоваться этой учетной записью следует только для обновления системы, установки новых программ или конфигурирования оборудования.
Защита сети
Наибольшей опасности компьютер подвергается тогда, когда подключается к интернету. Учитывая невероятное количество изощренных интернет-червей и спама, остается только удивляться, почему так сравнительно мало компьютеров превратилось в зомби, подчиняющиеся командам хакеров. Впрочем, вот несколько способов уменьшить угрозу.
Защитный экран - на каждый ПК
На любой компьютер, подключенный к интернету, независимо от типа соединения - телефонное, широкополосное или беспроводное - следует установить защитный экран (firewall), который оградил бы ПК от сетевых атак и программ-мошенников, передающих данные с вашего компьютера кому-то в сеть. На самом деле лучше всего использовать два защитных экрана: внешний, (аппаратный) например, встроенный в маршрутизатор, и программный, установленный на самом ПК и следящий за деятельностью приложений.
Помимо блокировки нежелательного входящего и исходящего трафика, аппаратные защитные экраны выполняют трансляцию сетевых адресов (Network Address Translation, NAT). В сочетании со встроенным в маршрутизатор DHCP-сервером (Dynamic Host Configuration Protocol, протокол динамической конфигурации хоста) при трансляции адресов истинные IP-адреса компьютеров маскируются и не выходят за пределы локальной сети, отчего ПК становится практически недоступным. Поскольку аппаратные защитные экраны находятся на первой линии обороны от сетевых атак, очень важно правильно настроить их в соответствии с документацией, предоставляемой производителем. В частности, необходимо обеспечить надежный администраторский пароль, чтобы никто, кроме вас, не смог контролировать защитный экран.
Программные защитные экраны воюют против внутренних врагов - вирусов, "троянских" и шпионских программ, если таковым все-таки удастся проникнуть в ПК (см. также "Самооборона от "троянцев"", "К+П", N2/2004).
Методика построения корпоративной системы защиты информации
Сергей ПЕТРЕНКО
Большинство директоров служб автоматизации (CIO) и информационной безопасности (CISO) российских компаний наверняка задавалось вопросом: “Как оценить уровень защищенности информационных активов компании и определить перспективы развития корпоративной системы защиты информации?”. Давайте попробуем найти ответ на этот актуальный вопрос.
Темпы развития современных информационных технологий значительно опережают темпы разработки рекомендательной и нормативно-правовой базы руководящих документов, действующих на территории России. Поэтому решение вопроса об оценке уровня защищенности информационных активов компании обязательно связано с проблемой выбора критериев и показателей защищенности, а также эффективности корпоративной системы защиты информации. Вследствие этого, в дополнение к требованиям и рекомендациям стандартов1, Конституции и федеральным законам2, руководящим документам Гостехкомиссии России и ФАПСИ3, приходится использовать ряд международных рекомендаций. В том числе адаптировать к отечественным условиям и применять на практике методики международных стандартов, таких, как ISO 17799, 9001, 15408, BSI4 и другие, а также использовать методики управления информационными рисками в совокупности с оценками экономической эффективности инвестиций в обеспечение защиты информации компании.
Современные методики управления рисками, проектирования и сопровождения корпоративных систем защиты информации должны позволять решить ряд задач перспективного стратегического развития компании.
Во-первых, количественно оценить текущий уровень информационной безопасности компании, что потребует выявления рисков на правовом, организационно-управленческом, технологическом, а также техническом уровнях обеспечения защиты информации.
Во-вторых разработать и реализовать комплексный план совершенствования корпоративной системы защиты информации для достижения приемлемого уровня защищенности информационных активов компании. Для этого необходимо:
обосновать и произвести расчет финансовых вложений в обеспечение безопасности на основе технологий анализа рисков, соотнести расходы на обеспечение безопасности с потенциальным ущербом и вероятностью его возникновения;
выявить и провести первоочередное блокирование наиболее опасных уязвимостей до осуществления атак на уязвимые ресурсы;
определить функциональные отношения и зоны ответственности при взаимодействии подразделений и лиц по обеспечению информационной безопасности компании, создать необходимый пакет организационно-распорядительной документации;
разработать и согласовать со службами организации, надзорными органами проект внедрения необходимых комплексов защиты, учитывающий современный уровень и тенденции развития информационных технологий;
обеспечить поддержание внедренного комплекса защиты в соответствии с изменяющимися условиями работы организации, регулярными доработками организационно-распорядительной документации, модификацией технологических процессов и модернизацией технических средств защиты.
Решение названных задач открывает новые широкие возможности перед должностными лицами разного уровня.
Руководителям верхнего звена это поможет объективно и независимо оценить текущей уровень информационной безопасности компании, обеспечить формирование единой концепции безопасности, рассчитать, согласовать и обосновать необходимые затраты на защиту компании. На основе полученной оценки начальники отделов и служб смогут выработать и обосновать необходимые организационные меры (состав и структуру службы информационной безопасности, положение о коммерческой тайне, пакет должностных инструкций и инструкции действия в нештатных ситуациях). Менеджеры среднего звена смогут обоснованно выбрать средства защиты информации, а также адаптировать и использовать в своей работе количественные показатели оценки информационной безопасности, методики оценки и управления безопасностью с привязкой к экономической эффективности компании.
Практические рекомендации по нейтрализации и локализации выявленных уязвимостей системы, полученные в результате аналитических исследований, помогут в работе над проблемами информационной безопасности на разных уровнях и, что особенно важно, определить основные зоны ответственности, в том числе материальной, за ненадлежащее использование информационных активов компании.
При определении масштабов материальной ответственности за ущерб, причиненный работодателю, в том числе разглашением коммерческой тайны, следует руководствоваться положениями гл. 39 Трудового кодекса РФ.
Разновидности аналитических работ по оценке защищенности
Аналитические работы в области информационной безопасности могут проводиться по следующим направлениям:
1) “Комплексный анализ информационных систем (ИС) компании и подсистемы информационной безопасности на правовом, методологическом, организационно-управленческом, технологическом и техническом уровнях. Анализ рисков”;
2)“Разработка комплексных рекомендаций по методологическому, организационно-управленческому, технологическому, общетехническому и программно-аппаратному обеспечению режима ИС компании”;
3) “Организационно-технологический анализ ИС компании”;
4) “Экспертиза решений и проектов”;
5) “Работы по анализу документооборота и поставке типовых комплектов организационно-распорядительной документации”;
6) “Работы, поддерживающие практическую реализацию плана защиты”;
7) “Повышение квалификации и переподготовка специалистов”.
Давайте кратко рассмотрим каждое из них.
Исследование и оценка состояния информационной безопасности ИС и подсистемы информационной безопасности компании предполагают проведение их оценки на соответствие типовым требованиям руководящих документов Гостехкомиссии при Президенте РФ, типовым требованиям международных стандартов ISO и соответствующим требованиям компании-заказчика. К первой области также относятся работы, проводимые на основе анализа рисков, инструментальные исследования (исследование элементов инфраструктуры компьютерной сети и корпоративной информационной системы на наличие уязвимостей, исследование защищенности точек доступа в Internet). Данный комплекс работ также включает в себя и анализ документооборота, который, в свою очередь, можно выделить и как самостоятельное направление.
Рекомендации могут касаться общих основополагающих вопросов обеспечения безопасности информации (разработка концепции информационной безопасности, разработка корпоративной политики охраны информации на организационно-управленческом, правовом, технологическом и техническом уровнях), применимых на многих компаниих.
Также рекомендации могут быть вполне конкретными и относится к деятельности одной единственной компании (план защиты информации, дополнительные работы по анализу и созданию методологического, организационно-управленческого, технологического, инфраструктурного и технического обеспечения режима информационной безопасности компании).
Организационно-технологический анализ ИС компании в основном предполагает проведение оценки соответствия типовым требованиям руководящих документов РФ к системе информационной безопасности компании в области организационно-технологических норм и анализ документооборота компании категории “конфиденциально” на соответствие требованиям концепции информационной безопасности, положению о коммерческой тайне, прочим внутренним требованиям компании по обеспечению конфиденциальности информации. При этом собственно внутрифирменная концепция информационной безопасности (ИБ) и положение о коммерческой тайне должны соответствовать действующему законодательству, а именно требованиям Конституции РФ, ст.ст. 128 и 139 Гражданского кодекса РФ, Федерального закона “Об информации, информатизации и защите информации”, Федерального закона “Об участии в международном информационном обмене”, других нормативных актов.
Правильная экспертиза решений и проектов играет важную роль в обеспечении функционирования всей системы информационной безопасности и должна соответствовать требованиям по обеспечению информационной безопасности экспертно-документальным методом. Экспертиза проектов подсистем – требованиям по безопасности экспертно-документальным методом.
Работы по анализу документооборота и поставке типовых комплектов организационно-распорядительной документации, как правило, включают два направления:
анализ документооборота компании категории “конфиденциально” на соответствие требованиям концепции информационной безопасности, положению о коммерческой тайне, прочим внутренним требованиям компании по обеспечению конфиденциальности информации;
поставку комплекта типовой организационно-распорядительной документации в соответствии с рекомендациями корпоративной политики ИБ компании на организационно-управленческом и правовом уровне.
Работы, поддерживающие практическую реализацию плана информационной безопасности, в частности, заключаются в следующем:
разработка технического проекта модернизации средств защиты ИС, установленных на фирме по результатам проведенного комплексного аналитического исследования корпоративной сети;
подготовка компании к аттестации (к аттестации объектов информатизации заказчика на соответствие требованиям руководящих документов Гостехкомиссии при Президенте РФ, а также на соответствие требованиям безопасности международных стандартов ISO 15408, ISO 17799, стандарта ISO 9001 при обеспечении требований информационной безопасности компании);
разработка расширенного перечня сведений ограниченного распространения как части политики безопасности;
разработка пакета организационно-распорядительной документации в соответствии с рекомендациями корпоративной политики ИБ компании на организационно-управленческом и правовом уровне;
поставка комплекта типовой организационно-распорядительной документации в соответствии с рекомендациями корпоративной политики ИБ компании на организационно-управленческом и правовом уровнях.
Уровень информационной безопасности компании во многом зависит от квалификации специалистов. В целях повышения квалификации и переподготовки кадров рекомендуется проводить тренинги по применению средств защиты информации, технологии защиты информации, обучать сотрудников основам экономической безопасности.
Немаловажную роль играет и ежегодная переоценка состояния информационной безопасности компании.
Методика построения корпоративной системы защиты информации
В соответствии со ст. 20 Федерального закона “Об информации, информатизации и защите информации” целями защиты информации являются в том числе: предотвращение утечки, хищения, утраты, искажения, подделки информации; предотвращение несанкционированных действий по уничтожению, модификации, искажению, копированию, блокированию информации; предотвращение других форм незаконного вмешательства в информационные ресурсы и информационные системы.
Главная цель любой системы информационной безопасности заключается в обеспечении устойчивого функционирования объекта: предотвращении угроз его безопасности, защите законных интересов владельца информации от противоправных посягательств, в том числе уголовно наказуемых деяний в рассматриваемой сфере отношений, предусмотренных Уголовным кодексом РФ5, обеспечении нормальной производственной деятельности всех подразделений объекта. Другая задача сводится к повышению качества предоставляемых услуг и гарантий безопасности имущественных прав и интересов клиентов6.
Для этого необходимо:
отнести информацию к категории ограниченного доступа (служебной тайне)7;
прогнозировать и своевременно выявлять угрозы безопасности информационным ресурсам, причины и условия, способствующие нанесению финансового, материального и морального ущерба, нарушению его нормального функционирования и развития8;
создать условия функционирования с наименьшей вероятностью реализации угроз безопасности информационным ресурсам и нанесения различных видов ущерба9;
создать механизм и условия оперативного реагирования на угрозы информационной безопасности и проявления негативных тенденций в функционировании, эффективное пресечение посягательств на ресурсы на основе правовых, организационных и технических мер и средств обеспечения безопасности10;
создать условия для максимально возможного возмещения и локализации ущерба, наносимого неправомерными действиями физических и юридических лиц, и тем самым ослабить возможное негативное влияние последствий нарушения информационной безопасности11.
При выполнении работ можно использовать следующую модель построения корпоративной системы защиты информации (рис. 1), основанную на адаптации Общих Критериев (ISO 15408) и проведении анализа риска (ISO 17799). Эта модель соответствует специальным нормативным документам по обеспечению информационной безопасности, принятым в Российской Федерации, международному стандарту ISO/IEC 15408 “Информационная технология – методы защиты – критерии оценки информационной безопасности”, стандарту ISO/IEC 17799 “Управление информационной безопасностью” и учитывает тенденции развития отечественной нормативной базы (в частности, Гостехкомиссии РФ) по вопросам защиты информации.
Рис. 1. Модель построения корпоративной системы защиты информации
Представленная модель защиты информации – это совокупность объективных внешних и внутренних факторов и их влияние на состояние информационной безопасности на объекте и на сохранность материальных или информационных ресурсов.
Рассматриваются следующие объективные факторы:
угрозы информационной безопасности, характеризующиеся вероятностью возникновения и вероятностью реализации;
уязвимости информационной системы или системы контрмер (системы информационной безопасности), влияющие на вероятность реализации угрозы;
риск – фактор, отражающий возможный ущерб организации в результате реализации угрозы информационной безопасности: утечки информации и ее неправомерного использования (риск в конечном итоге отражает вероятные финансовые потери – прямые или косвенные).
Для построения сбалансированной системы информационной безопасности предполагается первоначально провести анализ рисков в области информационной безопасности. Затем определить оптимальный уровень риска для организации на основе заданного критерия. Систему информационной безопасности (контрмеры) предстоит построить таким образом, чтобы достичь заданного уровня риска.
Предлагаемая методика проведения аналитических работ позволяет полностью проанализировать и документально оформить требования, связанные с обеспечением информационной безопасности, избежать расходов на излишние меры безопасности, возможные при субъективной оценке рисков, оказать помощь в планировании и осуществлении защиты на всех стадиях жизненного цикла информационных систем, обеспечить проведение работ в сжатые сроки, представить обоснование для выбора мер противодействия, оценить эффективность контрмер, сравнить различные варианты контрмер.
В ходе работ должны быть установлены границы исследования. Для этого необходимо выделить ресурсы информационной системы, для которых в дальнейшем будут получены оценки рисков. При этом предстоит разделить рассматриваемые ресурсы и внешние элементы, с которыми осуществляется взаимодействие.
Ресурсами могут быть средства вычислительной техники, программное обеспечение, данные, а также в соответствии со ст. 2 Федерального закона “Об информации, информатизации и защите информации” – информационные ресурсы – отдельные документы и отдельные массивы документов, документы и массивы документов в информационных системах (библиотеках, архивах, фондах, банках данных, других информационных системах). Примерами внешних элементов являются сети связи (абз. 4 ст. 2 Федерального закона “О связи”), внешние сервисы и т.п.
При построении модели будут учитываться взаимосвязи между ресурсами. Например, выход из строя какого-либо оборудования может привести к потере данных или выходу из строя другого критически важного элемента системы. Подобные взаимосвязи определяют основу построения модели организации с точки зрения ИБ.
Эта модель, в соответствии с предлагаемой методикой, строится следующим образом: для выделенных ресурсов определяется их ценность, как с точки зрения ассоциированных с ними возможных финансовых потерь, так и с точки зрения ущерба репутации организации, дезорганизации ее деятельности, нематериального ущерба от разглашения конфиденциальной информации и т.д. Затем описываются взаимосвязи ресурсов, определяются угрозы безопасности и оцениваются вероятности их реализации.
На основе построенной модели можно обоснованно выбрать систему контрмер, снижающих риски до допустимых уровней и обладающих наибольшей ценовой эффективностью. Частью системы контрмер будут рекомендации по проведению регулярных проверок эффективности системы защиты.
Обеспечение повышенных требований к ИБ предполагает соответствующие мероприятия на всех этапах жизненного цикла информационных технологий. Планирование этих мероприятий производится по завершении этапа анализа рисков и выбора контрмер. Обязательной составной частью этих планов является периодическая проверка соответствия существующего режима ИБ политике безопасности, сертификация информационной системы (технологии) на соответствие требованиям определенного стандарта безопасности.
По завершении работ, можно будет определить меру гарантии безопасности информационной среды, основанную на оценке, с которой можно доверять информационной среде объекта. Данный подход предполагает, что большая гарантия следует из применения больших усилий при проведении оценки безопасности. Адекватность оценки основана на вовлечении в процесс оценки большего числа элементов информационной среды объекта, глубине, достигаемой за счет использования при проектировании системы обеспечения безопасности большего числа проектов и описаний деталей выполнения, строгости, которая заключается в применении большего числа инструментов поиска и методов, направленных на обнаружение менее очевидных уязвимостей или на уменьшение вероятности их наличия.
Формирование организационной политики безопасности
Прежде чем предлагать какие-либо решения по системе информационной безопасности, предстоит разработать политику безопасности. Организационная политика безопасности описывает порядок предоставления и использования прав доступа пользователей, а также требования отчетности пользователей за свои действия в вопросах безопасности. Система информационной безопасности (СИБ) окажется эффективной, если она будет надежно поддерживать выполнение правил политики безопасности, и наоборот. Этапы построения организационной политики безопасности – это внесение в описание объекта автоматизации структуры ценности и проведение анализа риска, и определение правил для любого процесса пользования данным видом доступа к ресурсам объекта автоматизации, имеющим данную степень ценности.
Организационная политика безопасности оформляется в виде отдельного документа, который согласовывается и утверждается Заказчиком.
Прежде всего необходимо составить детализированное описание общей цели построения системы безопасности объекта, выражаемое через совокупность факторов или критериев, уточняющих цель. Совокупность факторов служит базисом для определения требований к системе (выбор альтернатив). Факторы безопасности, в свою очередь, могут распределяться на правовые, технологические, технические и организационные.
Требования гарантии достигаемой защиты выражаются через оценки функций безопасности СИБ объекта. Оценка силы функции безопасности выполняется на уровне отдельного механизма защиты, а ее результаты позволяют определить относительную способность соответствующей функции безопасности противостоять идентифицированным угрозам. Исходя из известного потенциала нападения, сила функции защиты определяется, например, категориями “базовая”, “средняя”, “высокая”. Потенциал нападения определяется путем экспертизы возможностей, ресурсов и мотивов побуждения нападающего.
Перечень требований к системе информационной безопасности, эскизный проект, план защиты (далее – техническая документация, ТД) содержит набор требований безопасности информационной среды объекта, которые могут ссылаться на соответствующий профиль защиты, а также содержать требования, сформулированные в явном виде.
В общем виде разработка ТД включает:
уточнение функций защиты;
выбор архитектурных принципов построения СИБ;
разработку логической структуры СИБ (четкое описание интерфейсов);
уточнение требований функций обеспечения гарантоспособности СИБ;
разработку методики и программы испытаний на соответствие сформулированным требованиям.
На этапе оценки достигаемой защищенности производится оценка меры гарантии безопасности информационной среды. Мера гарантии основывается на оценке, с которой после выполнения рекомендованных мероприятий можно доверять информационной среде объекта. Базовые положения данной методики предполагают, что степень гарантии следует из эффективности усилий при проведении оценки безопасности. Увеличение усилий оценки предполагает:
значительное число элементов информационной среды объекта, участвующих в процессе оценивания;
расширение типов проектов и описаний деталей выполнения при проектировании системы обеспечения безопасности;
строгость, заключающуюся в применении большего числа инструментов поиска и методов, направленных на обнаружение менее очевидных уязвимостей или на уменьшение вероятности их наличия.
Заключение
В целом рассмотренная выше методика позволяет оценить или переоценить уровень текущего состояния защищенности информационных активов компании, а также выработать рекомендации по обеспечению (повышению) информационной безопасности компании. В том числе снизить потенциальные потери компании путем повышения устойчивости функционирования корпоративной сети, разработать концепцию и политику безопасности компании. Также рассмотренная методика позволяет предложить планы защиты конфиденциальной информации компании, передаваемой по открытым каналам связи, защиты информации компании от умышленного искажения (разрушения), несанкционированного доступа к ней, ее копирования или использования.
1 ГОСТ 51583-00 "Защита информации. Порядок создания автоматизированных систем в защищен-ном исполнении. Общие требования." ГОСТ Р 51624-00 "Защита информации. Автоматизирован-ные системы в защищенном исполнении. Общие требования."
2 Федеральный закон "Об информации, информатизации и защите информации", № 24-ФЗ, 1995 г., ст. 2, Конституция Российской Федерации, ст. 23, Гражданский кодекс Российской Федерации, часть I, ст.ст. 139, 128.
3 См. сноску 1, ГОСТ Р ИСО 7498-2-99 "Информационная технология. Взаимосвязь открытых систем. Базовая эталонная модель. Часть 1. Архитектура защиты информации".
4 Международные стандарты безопасности ISO разработаны the International Organization for Standartization (ISO) и the International Electrotechnical Commission (IEC) и регламентируют вопросы информационной безопасности. В России стандарты ISO пока не являются общепринятыми, за ис-ключением ISO 15408, адаптированная версия которого была принята Госстандартом и Гостехкомис-сией летом 2002 года. ISO не вступают в противоречие с действующими в РФ стандартами и реко-мендациями Гостехкомиссии при Президенте РФ, ФАПСИ и рекомендуются к применению ведущими специалистами в области информационной безопасности. Тексты ISO можно найти по адресу:
5 УК РФ, 1996 г., ст.ст. 183, 272 - 274.
6 Румянцев О. Г., Додонов В.Н., Юридический энциклопедический словарь, М., "ИНФРА-М", 1997 г.
7 Указ Президента Российской Федерации от 6 марта 1997 г. № 188 "Об утверждении Перечня све-дений конфиденциального характера". Постановление Правительства Российской Федерации от 5 декабря 1991 г. № 35 "О перечне сведений, которые не могут составлять коммерческую тайну".
8 См. сноску 1, 2.
9 Федеральный закон "Об информации, информатизации и защите информации", № 24-ФЗ, 1995, ст.
10 См. сноску 8, Конституцию Российской Федерации, ст. 23.
11 См. сноску 9, Гражданский кодекс РФ, часть I, ст.ст. 139, 128.
Информационная безопасность
Итак, приступим: основные понятия и определения.
Во-первых. В чём главное отличие стеганографии от других методов защиты, в частности от той же криптографии? Дело в том, что первоочередной задачей стеганографии является скрытие самого существования канала связи, задача извлечения информации тут отступает на второй план и решается в большинстве случаев стандартными криптографическими методами. Есть области стеганографии, когда факт внедрения данных известен: это цифровые водяные знаки, так называемые "отпечатки пальцев", и заголовки, но их я рассматривать не буду.
Во-вторых. Почему НЗБ? Потому что это один из самых простых методов цифровой стеганографии, дающий скрытый канал с достаточно большой пропускной способностью. Определения просты, но понятны:
Контейнер - некоторая информация, в частности файл, в которую можно внедрить другую информацию, не предназначенную для посторонних глаз. Пустой контейнер - контейнер, в который ещё не внедрена информация. Соответственно, когда информацию внедрили, то контейнер становится заполненным. Сообщение - секретная информация, наличие которой в контейнере необходимо скрыть, то, из-за чего весь сыр-бор. Это может быть файл, текст, что угодно. Исторически сложилось, что это всё называется сообщением. Канал передачи - путь, по которому контейнер попадает от отправителя к получателю (пусть будут Юстас и Алекс, для интереса. Или Алиса и Боб, что тоже хорошо…). Наблюдатель - промежуточное звено, задачей которого является определение, не передаётся ли от Юстаса Алексу чего-то скрытое и насквозь запрещённое в обычном их общении. Существует три типа наблюдателей: пассивный, активный и злонамеренный. Самый безопасный пассивный - он не может разрушить сообщение, или скажем заменить его ложным, все его возможности сконцентрированы на одном: смотреть, смотреть и еще раз смотреть… и быть тревогу, если что-то там высмотрит.
Предположим, что у нашего канала связи появился пассивный наблюдатель (бороться с активным можно только с помощью полной замены применяемого алгоритма, метод НЗБ не выдерживает такой атаки).
Допустим, от Юстаса Алексу непрерывно пересылаются невинные - на первый взгляд - файлы. Если наблюдатель обоснованно определит, что в этих файлах не всё чисто, то это явится основанием для приглашения в гестапо, где, как известно, скорость перебора паролей очень высока, ибо прямо пропорциональна температуре паяльника. Или утюга, кому что больше нравится.
Способов внедрения и защиты данных в контейнере может быть множество даже в рамках одного типа контейнеров. Первое и главное из требований к методам внедрения - незаметность. Это означает, что посторонний наблюдатель в канале связи не должен на глаз определить наличие или отсутствие внедрения. Это требование большая часть самопальных программ худо-бедно, но выполняет (иначе зачем бы они были нужны?..). Вот сейчас мы и посмотрим, как именно.
Как с этим бороться
Начать, пожалуй, нужно с того, что все BMP контейнеры нужно разделить на два класса: "чистые" и зашумленные. В "чистых" картинках прослеживается связь между младшим битом, в который мы так бесцеремонно влезаем, и остальными 7-ю битами элементов цвета, а также прослеживается существенная зависимость самих младших битов между собой. Внедрение сообщения в "чистую" картинку разрушает существующие зависимости, что, как видно из вышеприведенной иллюстрации, очень легко выявляется пассивным наблюдателем. Если же картинка зашумлена (например, получена со сканера или фотокамеры), то определить вложение становиться на порядок сложнее, но продвинутый наблюдатель может призвать на помощь науку (раз уж сам не справляется) - теорию вероятностей, матстатистику и др.
Различить, какой контейнер попал вам под руку, можно тоже побитным просмотром картинки. Например, сканированное изображение, в которое ничего не внедрялось, выглядит так:
А вот - изначально компьютерное: 
Объясняется это тривиальным шумом матрицы сканера (или цифровой камеры). Опять же, несколько отступая в сторону, следует сказать, что просмотром и анализом распределения НЗБ иногда очень просто определить факт компьютерной обработки (подчистки) картинки:
А вот это же изображение, но с внедрением: Чётко видна граница между "своим" шумом и шумом, возникшим в результате внедрения сообщения. Отсюда вытекает еще одно необходимое правило - всегда нужно распределять биты сообщения по всем младшим битам контейнер (например, внедрять не последовательно, а в каждый 2-й, 3-й и т. д. НЗБ) или же дополнять чем-то (шумом с тем же законом распределения) длину сообщения так, чтобы она стала равна объему НЗБ контейнера.
Есть еще одно интересное решение - подбор картинки под сообщение: из множества имеющихся картинок подобрать такую, которая исказится менее всего при внедрении указанного сообщения.
Резюме, оно же вывод
В данной статье я пытаюсь показать, что скрывать данные нужно с умом. И применение простейших методов скрытия может быть достаточно надёжным только тогда, когда понимаешь и учитываешь ограничения и область применимости этих методов. В частности, не стоить доверять свои секреты "чистым" картинкам-контейнерам, а перед использованием той или иной стеганографической программы лучше все же проверить, дает ли она хотя бы какой-то минимум надежности.
document.write('');
|
 |
|
| This Web server launched on February 24, 1997
Copyright © 1997-2000 CIT, © 2001-2009 |
| Внимание! Любой из материалов, опубликованных на этом сервере, не может быть воспроизведен в какой бы то ни было форме и какими бы то ни было средствами без письменного разрешения владельцев авторских прав. |
Фирма «VEGA» предлагает самые выгодные условия на сегодняшний день в Москве, приезжайте, мы Вам это докажем.
| |
<
Собственно НЗБ
Что такое метод НЗБ? Это метод скрытия данных с искажением контейнера, основанный на особенностях человеческого восприятия. Конкретнее, идея метода заключается вот в чём: если взять картинку в формате BMP (или, скажем, как альтернативу 8 и более- битный оцифрованный звук), лучше всего TrueColor, в 24-х битном формате и взять да изменить младшие значащие биты цвета, то на глаз это будет незаметно. Почему 24 бита? Существует такой немаловажный фактор, как объём контейнера - сколько всего можно впихнуть в картинку, пока это не станет явным. Логично предположить, что чем больше контейнер, тем больше можно и внедрить, а распространенные на сегодня 24-х битные BMP - самая благодатная почва.
24 бита есть удобный формат хранения информации об изображении. При таком представлении за один цветовой канал отвечает один байт, чем все и пользуются. Оно и правильно. Внедрение может осуществляться так:
Берём сообщение и предварительно подготавливаем его: шифруем и пакуем. Этим достигается сразу две цели - повышение КПД и увеличение стойкости системы (см. далее). В начало для удобства можно записать сигнатуру метода, что не секретно, зато просто. Берём контейнер и внедряем подготовленное сообщение в младшие его - контейнера -биты любым удобным для нас способом. Самое простое:
раскладываем упакованное сообщение в битовую последовательность; заменяем избыточные биты (НЗБ) контейнера битами сообщения. Просто и со вкусом.
А вот тут-то собака обычно и закапывается… Надежность такого внедрения прямо пропорциональна соответствию характера распределения НЗБ в контейнере и сообщении. А распределения эти в подавляющем большинстве случаев совпадать-то и не будут. А еще в некоторых случаях это будет визуально заметно на картинке, построенной из одних только младших битов контейнера. Вот простейший пример, послуживший поводом к написанию статьи - берём исходную картинку:
и внедряем в неё некоторое количество информации при помощи не так давно публиковавшейся здесь в исходном коде программы Stegograph (сие не в упрёк этой программе, она просто приведена для примера). Что мы видим? 
При помощи очень простой программки, показывающей картинку побитно (то есть, только интересующие нас биты нужных цветовых компонентов) очень ясно видно внедрение данных. Более того, можно легко представить себе картину внедрения (какие биты, какие компоненты цвета), а при некоторых дополнительных усилиях и извлечь спрятанную информацию. Да, это ещё только полдела - нужно эту информацию ещё и расшифровать, но факт передачи уже определён.
Конечно, для большинства наблюдателей достаточно и того, что "на глаз не видно", но… слабые места своей защиты надо знать.
Стеганография. Особенности использования программ на основе метода наименьшего значащего бита.
Алексей Кошкин, Наталья Кошкина
Королевство Delphi
Информационная безопасность
Моделирование процессов создания и оценки эффективности систем защиты информации
- эксперт по вопросам информационной безопасности, к.т.н.
www.security.ukrnet.net
- эксперт по вопросам информационной безопасности, к.т.н.
www.security.ukrnet.net

Рис. 4. Координата ОСНОВЫ
- эксперт по вопросам информационной безопасности, к.т.н.
www.security.ukrnet.net

Рис. 2. Требования к модели СЗИ
- эксперт по вопросам информационной безопасности, к.т.н.
www.security.ukrnet.net

Рис. 5. Координата НАПРАВЛЕНИЯ
- эксперт по вопросам информационной безопасности, к.т.н.
www.security.ukrnet.net

- эксперт по вопросам информационной безопасности, к.т.н.
www.security.ukrnet.net


Рис. 7. Пример нумерации элемента матрицы №321
Моделирование процессов создания
- эксперт по вопросам информационной безопасности, к.т.н.
www.security.ukrnet.net
, , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , ,
Описание подхода к формированию модели ИБ
Как составить такое представление об информационной безопасности, что бы охватить все аспекты проблемы? Человек получает наиболее полное представление об интересующем его явлении, когда ему удается рассмотреть это нечто неизвестное со всех сторон, в трехмерном измерении.
Воспользуемся этим принципом.
Рассмотрим три "координаты измерений" - три группы составляющих модели СЗИ.
Из чего состоит (ОСНОВЫ)
Для чего предназначена (НАПРАВЛЕНИЯ)
Как работает (ЭТАПЫ)

Рис. 3. Три "координаты измерений" - три группы составляющих модели СЗИ
ОСНОВАМИ или составными частями практически любой сложной СИСТЕМЫ (в том числе и системы защиты информации) являются:
Законодательная, нормативно-правовая и научная база;
Структура и задачи органов (подразделений), обеспечивающих безопасность ИТ;
Организационно-технические и режимные меры и методы (политика информационной безопасности);
Программно-технические способы и средства.
Рис. 4. Координата ОСНОВЫ
НАПРАВЛЕНИЯ формируются исходя из конкретных особенностей ИС как объекта защиты. В общем случае, учитывая типовую структуру ИС и исторически сложившиеся виды работ по защите информации, предлагается рассмотреть следующие направления: Защита объектов информационных систем;
Защита процессов, процедур и программ обработки информации;
Защита каналов связи;
Подавление побочных электромагнитных излучений.
Управление системой защиты;
Рис. 5. Координата НАПРАВЛЕНИЯ
Но, поскольку каждое из этих НАПРАВЛЕНИЙ базируется на перечисленных выше ОСНОВАХ, то элементы ОСНОВ и НАПРАВЛЕНИЙ, рассматриваются неразрывно друг с другом. Например, одну из ОСНОВ под названием "Законодательная база…" необходимо рассматривать по всем НАПРАВЛЕНИЯМ, а именно:
Законодательная база защиты объектов…
Законодательная база защиты процессов, процедур и программ…
Законодательная база защиты каналов связи…
Законодательная база подавления побочных электромагнитных излучений…
Законодательная база по управлению и контролю самой системы защиты…
Аналогично следует рассматривать остальные грани ОСНОВ (структуру…, меры…, средства) по всем НАПРАВЛЕНИЯМ.
Как видите, для формирования самого общего представления о конкретной системе защиты необходимо ответить минимально на 20 (4*5=20) самых простых вопросов. Но и это еще не все... Далее необходимо рассмотреть ЭТАПЫ (последовательность шагов) создания СЗИ, которые необходимо реализовать в равной степени для каждого в отдельности НАПРАВЛЕНИЯ с учетом указанных выше ОСНОВ.
Проведенный анализ существующих методик (последовательностей) работ по созданию СЗИ позволяет выделить следующие ЭТАПЫ: Определение информационных и технических ресурсов, а также объектов ИС(!) подлежащих защите;
Выявление полного множество потенциально возможных угроз и каналов утечки информации;
Проведение оценки уязвимости и рисков информации (ресурсов ИС) при имеющемся множестве угроз и каналов утечки;
Определение требований к системе защиты информации;
Осуществление выбора средств защиты информации и их характеристик;
Внедрение и организация использования выбранных мер, способов и средств защиты.
Осуществление контроля целостности и управление системой защиты.

Рис. 6. Этапы создания систем защиты информации
Поскольку ЭТАПОВ семь, и по каждому надо осветить 20 уже известных вам вопросов то в общей сложности для формирования представления о конкретной системе защиты необходимо ответить на 140 простых вопросов. Совершенно очевидно что по каждому вопросу (элементу) возникнет несколько десятков уточнений.
В общем случае количество элементов матрицы может быть определено из соотношения
K = Oi*Hj*Mk
Где
К - количество элементов матрицы
Oi - количество составляющих блока "ОСНОВЫ"
Hj - количество составляющих блока "НАПРАВЛЕНИЯ"
Mk - количество составляющих блока "ЭТАПЫ"
В нашем случае общее количество элементов "матрицы" равно 140
K=4*5*7=140.
поскольку Oi=4, Hj=5, Mk=7
Все это можно представить в виде своеобразного кубика Рубика, на гранях которого образовалась мозаика взаимосвязанных составляющих элементов системы защиты.
А теперь для простоты понимания попробуем преобразовать трехмерную фигуру в двухмерную. Для этого развернем трехмерный куб на плоскости (на листе бумаги) и получим трехмерную матрицу в виде двухмерной таблицы, которая поможет логически объединить составляющие блоков "ОСНОВЫ", "НАПРАВЛЕНИЯ" и "ЭТАПЫ" по принципу каждый с каждым.
Напомним, что матрица в виде двухмерной таблицы появляется не сама по себе, а формируется в каждом конкретном случае, исходя из конкретных задач по созданию конкретной СЗИ для конкретной ИС.
Представление элементов матрицы
Элементы матрицы имеют соответствующую нумерацию. Следует обратить внимание на обозначения каждого из элементов матрицы, где:
первое знакоместо (Х00) соответствует номерам составляющих блока "ЭТАПЫ",
второе знакоместо (0Х0) соответствует номерам составляющих блока "НАПРАВЛЕНИЯ",
третье знакоместо (00Х) соответствует номерам составляющих блока "ОСНОВЫ".
На Рис.7 представлен пример, элемента матрицы 321, который формируется с учетом следующих составляющих:
300 - Проведение оценки уязвимости и рисков (составляющая № 3 блока "ЭТАПЫ");
020 - Защита процессов и программ (составляющая № 2 блока "НАПРАВЛЕНИЯ")
001 - Нормативная база (составляющая № 1 блока "ОСНОВЫ")
Рис. 7. Пример нумерации элемента матрицы №321
Приведем пример содержания информации для элементов матрицы № 321, 322, 323, 324, которые объединяют следующие составляющие:
№ 3 (300 проведение оценки уязвимости и рисков) блока "ЭТАПЫ",
№ 2 (020 защита процессов и программ) блока "НАПРАВЛЕНИЯ"
№ 1, 2, 3, 4 (001 нормативная база, 002 структура органов, 003 мероприятия, 004 используемые средства) блока "ОСНОВЫ".
Вот что получилось:
Элемент № 321 содержит информацию о том насколько полно отражены в законодательных, нормативных и методических документах вопросы, определяющие порядок проведения оценки уязвимости и рисков для информации используемой в процессах и программах конкретной ИС?
Элемент № 322 содержит информацию о том имеется ли структура органов (сотрудники), ответственная за проведение оценки уязвимости и рисков для процессов и программ ИС?
Элемент № 323 содержит информацию о том определены ли режимные меры, обеспечивающие своевременное и качественное проведение оценки уязвимости и рисков для информации используемой в процессах и программах ИС?
Элемент № 324 содержит информацию о том применяются ли технические, программные или другие средства, для обеспечения оперативности и качества проведения оценки уязвимости и рисков в процессах и программах ИС?
Это содержание только четырех вопросов из ста сорока, но ответы на них уже позволяют сформировать некое представление о состоянии дел по защите информации в конкретной ИС.
В общем случае рассматриваются все 140 вопросов (по числу элементов матрицы). Полное содержание 140 элементов матрицы можно посмотреть здесь. Описание этих вопросов позволяют составить полное представление о СЗИ и оценить достигнутый уровень защиты.
Сложно? Да! Однако именно такой подход дает возможность держать правильное направление в процессе создания сложных систем защиты. "…Верной дорогой идете, товарищи…". А поскольку при этом постоянно учитываются взаимные логические связи между многочисленными элементами СЗИ, то есть шанс построить именно СИСТЕМУ, а не набор решений. Напомним, что матрица не сществует сама по себе, а формируется исходя из описания конкретной ИС и конкретных задач по защите информации в этой системе, см. рисунок:
Программа оценки эффективности систем защиты информации "Оценка СЗИ"
Программа "Оценка СЗИ" иллюстрирует работу модели СЗИ представленной в виде трехмерной матрицы, описание которой приведено выше, она разработана с целью демонстрации преимуществ системного подхода к созданию и оценке эффективности систем защиты информации.
С помощью указанной программы осуществляется расчет условных показателей эффективности СЗИ, а также графическое представление состояния достигнутого уровня безопасности по отношению к заданному.
Программа "Оценка СЗИ" реализована на языке программирования Delphi и предназначена для оценки эффективности мероприятий, проводимых при создании и функционировании систем защиты информации.
Предложенная модель СЗИ в виде трехмерной матрицы позволяет не только жестко отслеживать взаимные связи между элементами защиты, но может выступать в роли руководства по созданию СЗИ. Если вы, приступая к созданию системы защиты, не знаете с чего начать, попробуйте ответить на предлагаемые в матрице вопросы, начиная с любого из них. И когда вы пройдетесь по всем вопросам, то поймете что уже сделано, а чего не хватает для достижения поставленной цели.
Если желаете поставить задачу на создание СЗИ, то заполнив 140 элементов (вопросов) матрицы соответствующими требованиями, получим достаточно полное техническое задание. Причем сформулировать эти требования можно на основе любых стандартов - международных, европейских, американских., российских, украинских…
Ну а как оценить эффективность создаваемой или уже функционирующей СЗИ?
Снова поможет подход на основе трехмерной матрицы. Только теперь по 140 показателям (элементам матрицы) надо выставить соответствующие оценки. Существует много методов оценок, выбирайте любой понятный и прозрачный для вас. Наиболее популярный на сегодняшний день метод "Три П" - пол, палец, потолок.
Интерфейсы программы с некоторыми комментариями представлены на рисунках 9, 10, 11, 12.
При внимательном рассмотрении можно узнать уже знакомую нам "матрицу знаний СЗИ" в несколько другом представлении.
На Рис. 9. показан интерфейс ввода данных. Заказчик определяет необходимые требования к системе защиты и устанавливает заданный уровень безопасности в соответствующие элементы матрицы. Экесперты в процессе проведения оценки качества созданной системы защиты определяют реализован ли заданный уровень безопасности и свои оценки выставляют в тех же элементах матрицы, только в режиме "достигнутый"

Рис. 9. Интерфейс ввода данных
На рис. 10 можно посмотреть графическеое представление количественных и качественных оценок по каждому из элементов матрицы. Здесь наглядно показано как сравнивается заданный уровень безопасности с достигнутым.

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

Рис. 11. Графичекое представление оценки эффетивности СЗИ.
Не стоит забывать, что требования к СЗИ имеют разную степень важности, которую необходимо учитывать при расчетах, используя соответствующие коэффициенты важности. Интерфес для ввода коэффициентов важности представлен на рис. 12.

Рис. 12. Интерфес для ввода коэффициентов важности.
Системный подход
Понятие системности заключается не просто в создании соответствующих механизмов защиты, а представляет собой регулярный процесс, осуществляемый на всех этапах жизненного цикла ИС. При этом все средства, методы и мероприятия, используемые для защиты информации объединяются в единый целостный механизм - систему защиты.
К сожалению, необходимость системного подхода к вопросам обеспечения безопасности информационных технологий пока еще не находит должного понимания у пользователей современных ИС.
Сегодня специалисты из самых разных областей знаний, так или иначе, вынуждены заниматься вопросами обеспечения информационной безопасности. Это обусловлено тем, что в ближайшие лет сто нам придется жить в обществе (среде) информационных технологий, куда перекочуют все социальные проблемы человечества, в том числе и вопросы безопасности…
Каждый из указанных специалистов по-своему решает задачу обеспечения информационной безопасности и применяет свои способы и методы для достижения заданных целей. Самое интересное, что при этом каждый из них в своем конкретном случае находит свои совершенно правильные решения. Однако, как показывает практика, совокупность таких правильных решений не дает в сумме положительного результата - система безопасности в общем и целом работает не эффективно.
Если собрать всех специалистов вместе, то при наличии у каждого из них огромного опыта и знаний, создать СИСТЕМУ информационной безопасности зачастую так и не удается. Разговаривая об одних и тех же вещах, специалисты зачастую не понимают друг друга поскольку у каждого из них свой подход, своя модель представления системы защиты информации. Такое положение дел обусловлено отсутствием системного подхода, который определил бы взаимные связи (отношения) между существующими понятиями, определениями, принципами, способами и механизмами защиты…
Постановка задачи.
Одиннадцать отдельно взятых футболистов (даже очень хороших) не составляют команду до тех пор, пока на основе заданных целей не будет отработано взаимодействие каждого с каждым.
Аналогично СЗИ лишь тогда станет СИСТЕМОЙ, когда будут установлены логические связи между всеми ее составляющими.
Как же организовать такое взаимодействие? В футболе команды проводят регулярные тренировки, определяя роль, место и задачи каждого игрока. Качество или эффективность команд оценивается по игре в матчах, результаты которых заносятся в турнирную таблицу. Таким образом, после проведения всех встреч команд (каждой с каждой), можно сделать вывод об уровне состояния мастерства как команды в целом, так и отдельных ее игроков. Побеждает тот, у кого наиболее четко организовано взаимодействие…
Выражаясь терминами современного бизнеса, для решения вопросов взаимодействия нужно перейти от "чисто" технического на "конкретно" логический уровень представления процессов создания и функционирования СИСТЕМ защиты информации. Хотелось бы, чтобы все специалисты, считающие себя профессионалами в информационных технологиях, поднялись чуть выше "багов" и "кряков" и уже сейчас задумались над тем как их знания и опыт будут логически увязаны со знаниями и опытом других специалистов.
В "строгой научной постановке" задача автора состоит в предоставлении пользователям вспомогательного инструмента "елки" - (модели СЗИ), а задача читателя (пользователя) - украсить эту "елку" новогодними игрушками - (своими знаниями и решениями). Даже если "игрушек" пока еще нет, наличие "елки" поможет выбрать и приобрести нужные "украшения".
Конечный результат работы (степень красоты елки) зависит от ваших желаний, способностей и возможностей. У кого-то получится хорошо, у кого-то - не совсем… Но это естественный процесс развития, приобретения знаний и опыта.
Кстати, оценить красоту елки (эффективность системы защиты) весьма проблематично, поскольку у каждого из нас свои требования и вкусы, о которых, как известно, не спорят, особенно с руководством.
Таким образом, многообразие вариантов построения информационных систем порождает необходимость создания различных систем защиты, учитывающих индивидуальные особенности каждой из них.
В то же время, большой объем имеющихся публикаций вряд ли может сформировать четкое представление о том как же приступить к созданию системы защиты информации для конкретной информационной системы, с учетом присущих ей особенностей и условий функционирования. Как сказал классик юмора: "…многообразие ваших вопросов порождает многообразие наших ответов…"
Возникает вопрос: можно ли сформировать такой подход к созданию систем защиты информации, который объединил бы в нечто единое целое усилия, знания и опыт различных специалистов? При этом желательно что бы указанный подход был универсальным, простым, понятным и позволял бы в одинаковой степени удовлетворить любые вкусы (требования) гурманов информационной безопасности?
Модель представления системы информационной безопасности.
Практическая задача обеспечения информационной безопасности состоит в разработке модели представления системы (процессов) ИБ, которая на основе научно-методического аппарата, позволяла бы решать задачи создания, использования и оценки эффективности СЗИ для проектируемых и существующих уникальных ИС. Что понимается под моделью СЗИ? Насколько реально создать такую модель? В упрощенном виде модель СЗИ представлена на Рис.1.

Рис.1. Модель СЗИ
Основной задачей модели является научное обеспечение процесса создания системы информационной безопасности за счет правильной оценки эффективности принимаемых решений и выбора рационального варианта технической реализации системы защиты информации.
Специфическими особенностями решения задачи создания систем защиты являются: неполнота и неопределенность исходной информации о составе ИС и характерных угрозах;
многокритериальность задачи, связанная с необходимостью учета большого числа частных показателей (требований) СЗИ;
наличие как количественных, так и качественных показателей, которые необходимо учитывать при решении задач разработки и внедрения СЗИ;
невозможность применения классических методов оптимизации.
Свойства матрицы
Предложенная модель представления СЗИ в виде трехмерной матрицы позволяет не только жестко отслеживать взаимные связи между элементами защиты, но может выступать в роли руководства по созданию СЗИ. Если вы, приступая к созданию системы защиты, не знаете с чего начать, попробуйте ответить на предлагаемые общие вопросы, начиная с любого из них. И когда вы пройдетесь по всем, то поймете что уже есть, а чего не хватает для достижения поставленной цели.
Если желаете поставить задачу на создание СЗИ, то заполнив 140 элементов матрицы соответствующими требованиями, получим достаточно полное техническое задание. Причем сформулировать эти требования можно на основе любых стандартов - международных, европейских, американских., российских, украинских…
Ну а как оценить эффективность создаваемой или уже функционирующей СЗИ?
Снова поможет подход на основе трехмерной матрицы. Только теперь по 140 показателям (элементам матрицы) надо выставить соответствующие оценки. Существует много методов оценок, выбирайте любой понятный и прозрачный для вас. Наиболее популярный на сегодняшний день метод "Три П" - пол, палец, потолок.
Наглядно указанные свойства матрицы приведены на Рис.8.

Рисунок 8. Свойства матрицы информационной безопасности
Требования к модели
Такая модель должна удовлетворять следующим требованиям (Рис. 2.): Использоваться в качестве: Руководства по созданию СЗИ
Методики формирования показателей и требований к СЗИ
Инструмента (методика) оценки СЗИ
Модели СЗИ для проведения исследований (матрица состояния)
Обладать свойствами: Универсальность
Комплексность
Простота использования
Наглядность
Практическая направленность
Быть самообучаемой (возможность наращивания знаний)
Функционировать в условиях высокой неопределенности исходной информации
Позволять: Установить взаимосвязь между показателями (требованиями)
Задавать различные уровни защиты
Получать количественные оценки
Контролировать состояние СЗИ
Применять различные методики оценок
Оперативно реагировать на изменения условий функционирования
Объединить усилия различных специалистов единым замыслом
Рис. 2. Требования к модели СЗИ
Вместо заключения (Read me)…
Хочется напомнить золотое правило: если после долгих попыток ничего не получается, ознакомьтесь, наконец, с инструкцией для пользователя! Прежде чем приступить к использованию программы "Оценка СЗИ", желательно разобраться с особенностями похода к рассмотрению вопросов информационной безопасности, предложенного автором.
Здесь можно скачать файл инсталляции программы оценки эффективности систем защиты информации...
Программу оценки эффективности систем защиты можно скачать здесь (zip-архив, 664КБ). Программа предназначена для свободного использования.
Получить консультацию или обсудить предложенный подход можно в форуме на авторском сайте к.т.н. Домарева Валерия Валентиновича www.security.ukrnet.net.
| |