|
|
Андрей Щеглов: Встроенные механизмы защиты бесполезны при работе в корпоративной средеНа вопросы CNews ответил Андрей Щеглов, генеральный директор НПП «Информационные технологии в бизнесе». CNews: Возможности встроенных механизмов защиты современных ОС постоянно расширяются, и многие считают, что существующего функционала вполне достаточно. Каково ваше мнение на данный счет? Андрей Щеглов: Давайте сразу сузим предметную область, чтобы разговор был более конкретным, и остановимся на наиболее распространенных сегодня ОС семейства Windows. Дело в том, что данные ОС являются универсальными, то есть изначально не ориентированы на корпоративные приложения. Они используются и в домашних условиях, и на предприятии, а ведь для данных альтернативных приложений в корне различна сама постановка задачи защиты. В первом случае, все вопросы защиты возлагаются на пользователя, который не имеет (да и не должен иметь) какой-либо квалификации и специальных знаний в области защиты информации. Да и какой-либо конфиденциальной информации он не обрабатывает. Ему нужна простейшая защита, а главное, механизмы защиты «до нельзя» упрощенные в администрировании и в эксплуатации, в сложной системе он просто не разберется. Кстати говоря, отчасти, это объясняет широкое использование антивирусных средств защиты, основанных на сигнатурном анализе. Это не средства защиты — это средства сравнения с эталоном. Как следствие, с одной стороны они очень просты в эксплуатации, с другой стороны, реализация подобного подхода в принципе не позволяет обеспечить сколько-нибудь эффективную защиту. Но повторюсь, она особо и не нужна при использовании компьютера в домашних условиях. Когда же речь заходит о корпоративных приложениях, мы должны осознавать, что в этом случае информация становится потенциальным «товаром», причем не только в смысле ее возможного хищения, но и в смысле несанкционированного уничтожения, чем уже можно нанести серьезный вред предприятию, особенно конкуренту. В свою очередь, пользователь, допущенный к ее обработке, является потенциальным «нарушителем», как следствие, все вопросы обеспечения информационной безопасности должны концентрироваться «в руках» доверенных ответственных лиц, которые должны являться специалистами в области защиты информации. Поэтому я соглашусь с теми, кто говорит, что встроенных механизмов достаточно для домашнего пользователя. Но добавлю, что от них нет проку при работе в корпоративной среде. CNews: Что конкретно не позволяют сделать внутренние механизмы защиты ОС и какие функции берут в этом случае на себя СЗИ от НСД? Андрей Щеглов: В общем случае можно рассматривать возникающую проблему через призму внешних и внутренних угроз. Внутренние угрозы в корпоративных приложениях — это угрозы, связанные с несанкционированными действиями пользователей. В данном случае именно пользователь является той сущностью, которой мы не доверяем, следовательно, должна быть реализована разграничительная политика доступа пользователей к ресурсам. Отчасти она в ОС реализуется, но разграничения можно задать между пользователями. Сразу возникает задача и реализации режима обработки данных для каждого отдельного пользователя. Это связано с тем, что в корпоративных приложениях на одном и том же компьютере одним и тем же пользователем может обрабатываться как открытая, так и конфиденциальная информация. Соответственно должна быть возможность задания различных режимов обработки информации различной категории (например, конфиденциальные данные не должны отправляться во внешнюю сеть, а открытые должны). Вот в решении этой задачи встроенные механизмы универсальных ОС становятся полностью бесполезными. Это значит, что невозможно разграничить доступ при работе с внешними устройствами или при организации доступа к ресурсам, невозможно разграничить буфер обмена между учетными записями при запуске приложения с правами другого пользователя и т.д. Внешние угрозы во многом связаны с некорректностью работы приложений (именно на них осуществляются атаки из сети). Для решения данной задачи защиты вообще кардинально должна быть изменена разграничительная политика доступа к ресурсам — субъектом доступа здесь уже должен выступать процесс, а не пользователь. В этом случае для любого приложения можно при помощи СЗИ от НСД таким образом задать разграничительную политику доступа к ресурсам, что атака на него станет просто бессмысленной. Большинство универсальных ОС подобной возможности не предоставляет, то есть и для решения этой задачи защиты механизмы из состава ОС бесполезны. CNews: Казалось бы, вы говорите вполне доступные вещи. Тогда почему все это невозможно реализовать средствами ОС Windows? Андрей Щеглов: Во-первых, во встроенных в ОС механизмах защиты присутствуют серьезные архитектурные недостатки. Таковым является невозможность в полном объеме разграничить права доступа для системных пользователей, как результат — наличие множество известных атак на расширение привилегий, невозможность в полном объеме разделить файловые объекты между всеми пользователями и т.д. Естественно, что без устранения подобных архитектурных недостатков о какой-либо эффективной защите говорить просто не приходится. Во-вторых, несмотря на многообразие встроенных механизмов, ряд ключевых механизмов защиты, в том числе, и требуемых нормативными документами в области защиты информации, в универсальных ОС просто отсутствует. Например, не реализовано гарантированное удаление информации. Естественно, что подобные механизмы должны быть включены в средство защиты. Кроме того, следует рассматривать и совершенно иной аспект защиты информации –эксплуатационную безопасность, позволяющую оценить реальную эффективность защиты за определенный период времени. Особенность этой оценки состоит в том, что не рассматриваются архитектурные особенности построения системы, анализируются лишь два параметра — интенсивность выявления ошибок и интенсивность их исправления разработчиком. Далее, по простой формуле можно рассчитать защищенности системного средства в произвольный момент времени. Анализ эксплуатационной безопасности современных универсальных ОС дает весьма плачевный результат: даже при гипотетически идеальной ситуации (когда обнаруживается одна ошибка за год) вероятность редко превышает 0,8. А когда ошибок десятки? Это связано с тем, что в таком сложном ПО, как ОС, вероятность ошибки программирования очень высока, а исправление ошибок занимает много времени. Реальное же полученное нами расчетное значение эксплуатационной безопасности — значение вероятности того, что в любой момент времени системное средство защищено, для современных универсальных ОС составляет менее 0,2. О какой безопасности здесь вообще можно говорить? Таким образом, может быть поставлена под сомнение сама возможность обеспечения высокого уровня эксплуатационной безопасности при использовании встроенных в ОС механизмов защиты, ввиду сложности данного ПО, обусловливающей как высокую вероятность наличия в нем ошибок, так и высокую трудоемкость их исправления. Вот и еще одна задача, которая должна решаться СЗИ от НСД — задача повышения эксплуатационной безопасности системного средства. Как видим, проблем не мало, и своем большинстве они сводятся не к решению каких-либо частных задач защиты, а к полному замещению механизмов защиты, присутствующих в составе ОС. На мой взгляд, СЗИ от НСД должна быть самодостаточной, ее механизмов должно хватать для решения всей рассмотренной выше совокупности функциональных задач защиты информации. Только в этом можно говорить о достижении какого-либо осмысленного уровня эффективности защиты. CNews: Представленные на рынке СЗИ от НСД реализовывают требования одних и тех же нормативных документов в области защиты информации. В чем же состоит причина многообразия рынка СЗИ от НСД? Андрей Щеглов: Тому есть как объективные, так и субъективные причины. Очевидно, что в общем случае причиной уязвимости может являться либо некорректность реализации механизма защиты, либо недостаточность набора механизмов для условий использования защищаемого объекта информатизации. Вообще говоря, свойства корректности реализации и полноты являются основополагающими свойствами любой технической системы, в том числе, и свойствами системы защиты информации. Требования к корректности реализации механизмов защиты определены Гостехкомиссией России в руководящем документе «Средства вычислительной техники. Защита от несанкционированного доступа к информации. Показатели защищенности от НСД к информации». Отметим, что в подобных документах в принципе невозможна детализация требований, особенно с учетом архитектурных особенностей различных системных средств. Т.е. данные требования могут носить только общий характер, как следствие, сразу получаем возможность неоднозначного их толкования, соответственно и возможность создания различных технических решений. Проиллюстрируем сказанное простыми примерами. Одним из важнейших требований к АС класса 1Г (защита конфиденциальной информации) является следующее: «Должен осуществляться контроль доступа субъектов к защищаемым ресурсам в соответствии с матрицей доступа». А что является защищаемым ресурсом — вот и неоднозначность. Трудно себе представить, что к подобным ресурсам можно не отнести, например, объекты реестра ОС, устройства во всем их многообразии, ресурсы внешней сети и т.д. Вместе с тем, в явном виде это не прописано, вот и появляются усеченные по набору механизмов защиты СЗИ от НСД. На наш взгляд, требование к достаточности в принципе может быть реализовано только при условии наличия в СЗИ от НСД механизма контроля монтирования к системе устройств. Тогда требование к достаточности принимает следующий вид: «Должен осуществляться контроль монтирования к системе устройств, ко всем устройствам, монтирование которых разрешено к системе, должен осуществляться контроль доступа в соответствии с матрицей доступа». Тогда становится «прозрачной» и область применения СЗИ от НСД, и нет необходимости выдумывать какие-либо организационные меры при аттестации объекта информатизации. К другой объективной причине можно отнести то, что информационные технологии и вычислительные средства развиваются, причем очень бурно, «не стоит на месте» и такая научно-техническая область знаний, как защита информации, требования же к механизмам защиты, сформулированные в нормативном документе, остаются неизменными. Приведем пример. Одним из основных механизмов защиты в корпоративных приложениях считается мандатный принцип контроля доступа, призванный противодействовать понижению категории (в конечно счете, изменению режима обработки) данных. Вместе с тем, можно показать, что такое решение кардинально повышает угрозу «заражения» конфиденциальных данных макро-вирусом в результате обработки на том же компьютере открытых данных. Вот пример, когда механизмом защиты решается одна задача НСД за счет другой. Невольно, потребитель ставится перед выбором, что для него важнее? Нужно ли рассматривать вопрос целесообразности реализации подобного решения? На мой взгляд — необходимо! Все это, в конечном счете, приводит к тому, что разработчик во многом сам формулирует и, в первую очередь, решает при создании СЗИ от НСД наиболее актуальные на сегодняшний день задачи защиты информации, которые в явном виде не нашли своего отражения в формализованных требованиях. В качестве примера можно привести задачу противодействия внешним угрозам. Ее решение принципиально невозможно без реализации разграничительной политики доступа к ресурсам, прежде всего, к файловым объектам и к объектам реестра ОС, для процессов. Именно процессам, а не пользователям, в этом случае следует назначать права доступа к ресурсам, а это далеко не одно и то же. Но подобного требования к реализации механизма контроля доступа к ресурсам в нормативных документах не существует. Естественно, что СЗИ от НСД при подобном подходе к их построению разработчиками, будут различаться. К субъективным причинам можно отнести неоднозначность некоторых формулировок, присутствующих в требованиях к построению механизмов защиты. Одним из важнейших механизмов защиты, регламентируемых к реализации в СЗИ от НСД, является принцип дискреционного контроля доступа. Заметим, что под дискреционной моделью управления доступом принято считать модель, основывающуюся на предоставлении доступа к объектам владельцами этих объектов. Следуя данному определению, в схему контроля доступа должна быть включена сущность «Владелец» — непривилегированный пользователь, которому предоставляется возможность задавать права доступа к созданным им объектам иным пользователям. Вместе с тем, рассмотрим требования к реализации принципа дискреционного контроля доступа, сформулированные в том же документе. Среди этих требований видим следующее: «Право изменять ПРД (правила разграничения доступа) должно предоставляться выделенным субъектам (администрации, службе безопасности и т.д.)». Вот два полностью противоречащих друг другу требования, так какому из них следовать разработчику? Казалось бы, очевидно, что сущность «Владелец», когда вопрос защиты касается корпоративных приложений, должна быть исключена как таковая — только в этом случая реализуемо требование к индуктивности модели безопасности, тогда почему данная сущность используется при реализации соответствующих механизмов защиты в некоторых СЗИ от НСД? А если коснуться принципа мандатного контроля доступа. Здесь дела обстоят еще хуже! Ключевым требованием к его реализации, следуя нормативному документу, является: «Для реализации этого принципа должны сопоставляться классификационные метки каждого субъекта и каждого объекта, отражающие их место в соответствующей иерархии».Это означает, что субъектам, которым не назначена метка, не должен предоставляться какой-либо доступ к объектам, соответственно, не должен предоставляться и доступ к объектам, которым не назначена метка. Но ведь существуют системные субъекты и объекты (например, пользователь «System», системный диск), существуют неразделяемые системой и приложениями ресурсы и т.д. При этом, если мандатный механизм контроля доступа реализован корректно (в соответствии с требованиями), он априори неработоспособен (для корректного функционирования системы и приложений нельзя вводить более одной метки), если некорректно, то от его практического использования больше вреда чем пользы (будут присутствовать «каналы» понижения категории информации). И что с этим делать разработчику, как реализовать подобное требование? Мы рассмотрели лишь основные причины наличия широкого ассортимента СЗИ от НСД, сильно различающихся своими функциональными возможностями, но, несмотря на это, реализующих одни и те же требования к механизмам защиты. На наш взгляд, требования к корректности реализации механизмов защиты и достаточности их набора, применительно к условиям использования системного средства, должны быть жестко регламентированы, в противном случае, мы рискуем получить еще большее «многообразие» СЗИ от НСД. Но при этом надо понимать, что средство защиты не может быть хорошим или не очень хорошим — оно либо защищает, либо нет. CNews: Как правило, СЗИ от НСД позиционируются разработчиками как некие специализированные средства, призванные решать одну, в крайнем случае, некоторое весьма ограниченное число задач. Вы же заявляете о реализации комплексной защиты информации от НСД. В чем она заключается и в чем ее преимущества? Комплексная система защиты и комплекс специализированных средств — это совершенно различные, с точки зрения эффективности, решения. Никогда комплексированием готовых специализированных средств не обеспечить той эффективности защиты, которая присуща комплексной системе. Например, я уже говорил, почему мандатный принцип контроля доступа к ресурсам не должен применяться при построении комплексной системы защиты. Вместе с тем, в той или иной мере, он может быть использован для решения отдельно взятой задачи противодействия хищению данных инсайдерами. Используйте данный механизм, и актуальность задачи антивирусной защиты для вас многократно возрастет. Но беда то в том, что два специализированных решения не заменят одной комплексной системы, что вы не добавляйте, а мандатный принцип останется, т.е. комплексирование должно осуществляться на уровне создания собственно механизмов, а не путем объединения готовых средств и механизмов защиты. Заметим, что все сказанное относится ко всем уровням иерархии комплексирования решений. Например, в некоторых СЗИ от НСД, предназначенных для противодействия внутренним угрозам, реализуется такая схема. Под одной учетной записью обрабатываются данные различных категорий, при этом права доступа пользователя к файловым объектам формируются исходя из того, данные какой категории им прочитаны. Все вроде бы хорошо — противодействуем понижению категории данных. Теперь рассматриваем вопросы непротиворечивости. Оказывается, что к остальным ресурсам в этом СЗИ от НСД возможно задать разграничения только по пользователям. Выходит, что к любому иному ресурсу разграничения можно назначить для пользователя, вне зависимости от того, данные какой категории он обрабатывает. А как же здесь «поживает» основной принцип, который должен быть реализован в данных приложениях защиты информации — обеспечить различные режимы обработки различной категории конфиденциальности? При таком же решении мы обречены на обработку данных различной категории конфиденциальности с одними и теми же привилегиями. А ведь подобные СЗИ от НСД существуют, самое парадоксальное, что некоторые из них востребованы. Данный ряд примеров можно продолжить. Как видим, без реализации системного подхода к построению СЗИ от НСД, подчас, и одна-то задача защиты не решается корректно. В порядке замечания хочется остановиться на следующем. А часто ли вообще производители СЗИ от НСД четко позиционируют назначение своих средств защиты? Найдите указание на это в документации для большинства СЗИ от НСД, кроме реализуемого ими класса в соответствии с требованиями нормативных документах. Реализует средство некий набор механизмов защиты, а как ими воспользоваться конкретному потребителю для решения конкретных функциональных задача защиты информации, например, для противодействия внешним угрозам? Потребителю остается только гадать. Здесь хотелось бы акцентировать ваше внимание на нашей разработке — на Комплексной системе защиты информации (КСЗИ) «Панцирь-К» для ОС Windows 2000/XP/2003. Сегодня это если не единственная, то одна из немногих комплексных систем защиты информации, решающая в совокупности большинство задач защиты информации: противодействие внешним и внутренним угрозам, антивирусная защита, защита от вредоносных и шпионских программ, от сетевых атак и т.д. Познакомьтесь с этой системой, и увидите, насколько реализованные в ней технические решения (на эти решения получено 11 патентов) отличаются от соответствующих решений, реализованных в СЗИ от НСД иных производителей. CNews: Некоторые разработчики СЗИ от НСД позиционируют простоту настройки и эксплуатации средства защиты, чуть ли не как его основное потребительское свойство. Каково ваше мнение, за счет чего возможно упрощение средства защиты, не скажется ли это на его эффективности? Андрей Щеглов: На мой взгляд, с точки зрения безопасности — это очень «опасная» позиция. Да, действительно, проблема квалификации администраторов безопасности пока еще существует. Следствием этого, является и потенциально возможный спрос на простые решения. А если есть спрос, то будет и предложение. «Беда» таких решений состоит в том, что возможен лишь один способ кардинального упрощения СЗИ от НСД — это исключение из ее состава тех механизмов защиты и тех возможностей, которые сложны в настройке и в эксплуатации. При этом сразу получим некорректное решение задачи и недостаточность механизмов защиты, применительно к условиям использования системного средства, другими словами, уязвимое средство защиты. Нельзя просто настроить такие механизмы защиты, как замкнутость программной среды, контроль сервисов олицетворения и т.д. Также можно все свести к абсурду — реализовать в СЗИ от НСД пару механизмов защиты (для «красоты» еще и реализовать возможность их удаленной настройки, заявив о наличии «сервера», т.к. при этом умалчивается, как настраивать удаленно остальные необходимые для эффективной защиты механизмы, пусть даже и из состава ОС) и попытаться убедить потребителя, что они просты в настройке и в эксплуатации, да еще при этом и заинтересовать его низкой ценой. Возможно, что потребитель, не особенно разбирающийся в вопросах защиты информации, и «клюнет» на подобное предложение. А если потребитель начнет задавать вопросы о других задачах защиты, то всегда можно сослаться на встроенные в ОС механизмы, правда при этом уже нужно забыть о «простоте» данного комплекса средств. На самом деле, этот вопрос сильно взаимосвязан с вопросом формализации требований к корректности реализации механизмов защиты и к достаточности их набора, применительно к условиям использования системного средства. На наш взгляд, подобные «простые» СЗИ от НСД не должны появляться на рынке средств защиты, по крайней мере, уж точно не должны иметь соответствующих сертификатов. Если серьезно говорить об информационной безопасности в корпоративных приложениях, то в качестве первоочередной задачи следует рассматривать именно вопросы квалификации лиц, отвечающих за защиту информации. Будет квалификация, будет и выбор эффективных решений, будет и эффективная защита информации. В противном случае, получим иллюзию защиты, самое интересное, за собственные деньги! Кстати говоря, следует различать проблемы «простоты системы» и «удобства администрирования». Вот об удобстве администрирования, в предположении, что средство защиты не может быть простым в настройке и в эксплуатации, разработчикам СЗИ от НСД следует позаботиться, т.к. с удобством напрямую связаны и ошибки администрирования, приводящие к уязвимости средства защиты. Однако, это уже совершенно иной и так же достаточно непростой вопрос. При его решении опять же важно, чтобы упрощение администрирования не привело к снижению эффективности средства. Вот лишь простой пример, иллюстрирующий возможности кардинального изменения (по сравнению с интерфейсными решениями, реализованными в ОС) интерфейсов настройки механизмов защиты. Основу реализации разграничительной политики доступа к ресурсам в корпоративных приложениях составляет назначение прав доступа пользователям, т.е. здесь уместно говорить о присвоении подобных прав учетным записям, а не атрибутов доступа объектам. Вот вам и наглядность, когда в одном окне интерфейса можно увидеть все права доступа пользователя, и возможность использования механизма масок, сразу же может быть поставлен вопрос о минимизации подобных прав, не сложно показать, что всю их номенклатуру можно свести лишь к трем: чтение, запись, выполнение (остальные права могут задаваться СЗИ от НСД автоматически) и т.д., и т.п. CNews: Какие бы Вы могли дать практические рекомендации корпоративному потребителю, в части выбора эффективной СЗИ от НСД, как провести сравнительный анализ эффективности альтернативных технических решений? Андрей Щеглов: Общие рекомендации здесь дать сложно. На мой взгляд, бесспорно следующее. Во-первых, необходимо для себя решить, что настало время защищать информацию, тогда появятся и желание, и средства, и возможности по решению всех организационных проблем. Если для потребителя защита информации это не осознанная необходимость, то он будет искать простых и дешевых средств и иных способов формального решения задачи. Если же выбор сделан в пользу эффективной защиты, то начинать необходимо с подбора кадров, либо с обучения своих сотрудников. При этом заметим, что, в первую очередь, администратор безопасности должен обладать соответствующим уровнем компьютерной грамотности и навыками системного администратора. Это ключевой вопрос, без решения которого не будет никакой защиты информации, какие СЗИ от НСД не устанавливай. После этого уже можно переходить к прикладным вопросам. Когда есть знание, остается четко сформулировать задачу, и, что самое сложное, определиться с требованиями к корректности, достаточности и непротиворечивости ее решения, и провести сравнительный анализ представленных на рынке СЗИ от НСД, в части сформулированных вами требований. Это, действительно, очень сложная задача, возможно, что для ее качественного решения потребителю будет не обойтись без привлечения сторонних специалистов. Вот здесь рекомендуем обращаться к разработчикам, желательно, к разработчикам тех средств, реализованные технические решения в которых, вам покажутся наиболее обоснованными. Лучше, чем они, никто не знает реальных проблем, которые должны решаться СЗИ от НСД для конкретного системного средства с учетом конкретных особенностей области его использования. При этом не забудьте «сделать скидку» на то, собственное средство разработчика при проведении им сравнительного анализа СЗИ от НСД, всегда окажется самым хорошим. Не случайно, объективность экспертной оценки всегда достигается при учете мнения лишь нескольких независимых экспертов. CNews: Спасибо. |