Обзор подготовлен	При поддержке

Уязвимости больше не страшны ОС?

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

Ко второму типу можно отнести те процессы, которые запускаются в системе с привилегированными правами, например, под учетной записью System, а также процессы, которые наиболее вероятно могут быть подвержены атакам, например, сетевые службы. Атаки на подобные процессы наиболее критичны, что связано с возможностью расширения привилегий, в пределе — получения полного управления системой.

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

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

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

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

Шифруем данные

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

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

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

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

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

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

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

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

Заключение

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

Андрей Щеглов, д.т.н., проф.

Александр Соколов: Информационная безопасность нужна, если известна цена информации

О проблемах и перспективах отрасли информационной безопасности России рассказал CNews Александр Соколов, генеральный директор компании «Элвис-Плюс».

CNews: В минувшем году рост ИТ-рынка России замедлился более чем вдвое. Отразилось ли это на рынке ИБ и в частности на вашей компании? Какие причины повлияли в наибольшей степени на изменение объемов рынка ИБ?

Александр Соколов: В целом, конечно, отразилось. Информационная безопасность прочно связана с ИТ-рынком. Поэтому, если сокращается объем работ на ИТ-рынке, это тут же сказывается на его сегменте — рынке ИБ. Наибольшее влияние на отрасль оказала административная реформа. Она задержала многие запланированные проекты, что вызвало замедление темпов роста. На примере нашей компании могу сказать, что в 2004 г. рост не превысил 10%. Мы работаем с очень крупными заказчиками, поэтому оказались особенно чувствительны к проведенной реформе. Дело в том, что такие клиенты тесно связаны с макроэкономикой, независимо от того являются ли они государственной структурой или коммерческой, и любое изменение на государственном уровне приводит к замедлению процесса взаимодействия с ними. Однако уже этот год значительно активней предыдущего, ИТ-рынок растет хорошими темпами, а проведенная административная реформа вызвала лишь временное замедление роста, поскольку других объективных причин нет.

Полный текст интервью