Geum.ru

100 Мифы и заблуждения информационной безопасности Лукацкий

Вид материалаДокументы

Содержание


Миф №48 "Сертификат ФСТЭК гарантирует защищенность системы"02.07.2009 12:44
Подобный материал:
1   ...   31   32   33   34   35   36   37   38   ...   69

Миф №48 "Сертификат ФСТЭК гарантирует защищенность системы"02.07.2009 12:44


Алексей Лукацкий - менеджер по развитию
бизнеса Cisco Systems

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

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

На соответствие каким же требованиям проверяется система защиты? С 1992 года их появилось немало:

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

· Автоматизированные системы. Защита от несанкционированного доступа к информации. Классификация автоматизированных систем и требования по защите информации

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

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

· Профиль защиты "Контролируемый доступ" (ПЗ КД)

· Профиль защиты "Меточная защита"

· Профиль защиты "Операционные системы"

· Профиль защиты "Одноуровневые операционные системы"

· Профиль защиты "Многоуровневые операционные системы"

· Профиль защиты "Операционные системы. Клиентские операционные системы"

· Профиль защиты "Системы управления базами данных"

· Профиль защиты "Межсетевые экраны корпоративного уровня"

· Профиль защиты "Межсетевые экраны провайдерского уровня"

· Профиль защиты "Средства построения виртуальных локальных вычислительных сетей"

· Профиль защиты "Средства построения виртуальных частных вычислительных сетей"

· Профиль защиты "Удостоверяющие центры инфраструктуры открытых ключей"

· Профиль защиты "Билинговые системы"

· Профиль защиты "Средства защиты ресурсов компьютера от несанкционированного доступа на начальном этапе его загрузки".

Но только первые 4 документа получили широкое распространение в процессе сертификации. Все оставшиеся «профили», появившиеся в то время, когда Россия пыталась войти в список стран, признающих международные требования по сертификации средств защиты - «Общие критерии», так и не стали активно использоваться в нашем государстве. Уж слишком непохожий на сертификацию по старым руководящим документам процесс они пропагандировали. Да и в государственных структурах, которые поглощают не менее трети всего рынка средств ИБ, они не прижились - предпочтение отдавалось и отдается сертификатам с указанием понятных классов защищенности, а не оценочных уровней доверия.

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

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

Ситуация ухудшается еще и тем, что изменение окружения, которое прописано в сертификате (версия системы защиты, аппаратная платформа, на которой она работает, отключенные сервисы и периферийные устройства, конфигурация и т.д.) сводят его «на нет». Я уже не говорю про установку обновлений. Еще один парадокс сертификации - установка патчей, призванная повысить защищенность системы, устранив обнаруженные уязвимости, невозможна, т.к. делает систему несертифицированной.

Но давайте представим, что мы смогли разработать актуальные современной ситуации требования безопасности и сертификат описывает не статическую систему. Фантастика? Но все-таки. Может ли в данном случае сертификат гарантировать защищенность системы? Опять нет.

Дело в том, что по статистике на 1000 строк кода существует 13-15 ошибок, из которых 5% критических. Умножаем это на сотни тысяч или миллионы строк кода, составляющих современные системы защиты. Можно представить себе сколько уязвимостей они в себе содержат. А сколько ветвлений и комбинаций программы надо проверить в процессе сертификации? А теперь еще вспомним 16-й миф. В нем я ссылался на теоремы Райса и Успенского, которые применительно к отрасли ИБ доказывают, что грамотно подготовленную закладку обнаружить невозможно. Иными словами в системах защиты могут оказаться как случайные ошибки и уязвимости, так и специально оставленные недекларированные возможности. О какой гарантии защищенности может идти речь в этом случае?

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

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