пятница, 26 июля 2013 г.

СОИБ. Проектирование. Выбор мер по защите информации для виртуализированных инфраструктур


Недавно ассоциация RISSPA  опубликовала аналитическую статью о проблеме выбора средств защиты информации для виртуализированных инфраструктур.

Будучи в отпуске пропустил эту новость, но сейчас внимательно ознакомился.

Авторам документа скажу спасибо, так как подобной комплексной подборки СЗИ я не встречал даже среди англоязычных материалов.  Не говоря о привязке к мерам защиты ПДн, которые ФСТЭК представил совсем недавно.

Интересная таблица по соответствию мер и средств защиты



Таблица с подборкой актуальных сертификатов ФСТЭК на приведенные выше средства защиты


Но хочу сделать и несколько замечаний к статье:
1.      С моей точки зрения, авторы зря сузили рассмотрение проблемы до выбора только СЗИ.  Есть ещё возможность при реализации системы защиты применять организационные и технические меры защиты отличные от СЗИ (например, дублирование серверов, каналов связи между ними, ограничение физического доступа к серверам инфраструктуры виртуализации). Таких мер немного  и их стоило бы упомянуть и отметить в табличке соответствия требованиям приказа ФСТЭК №21
2.      Стоило бы рассмотреть возможности по защите встроенные в виртуализированные инфраструктуры (VMware vSphere, VMware vCenter   MS Hyper-V) и добавить анализ их соответствия требуемым мерам защиты. Если какие-то функции уже выполняются самой инфраструктурой, зачем нам дублировать их средствами защиты (или дублировать, но понимать что дублируем)?
Например, в недавно сертифицированном VMware vCenter есть функции:
·        Идентификация и аутентификация пользователей
·        Ролевой принцип контроля доступа при администрировании компонентов виртуальной инфраструктуры
·        Регистрация действий пользователей и администраторов виртуальной инфраструктуры
·        Изоляция виртуальных машин
3.      Стоило бы рассмотреть средства защиты семейства VMware vCloud Networking and Security. Так как это комплексный набор средств защиты от самого производителя решения виртуализированной инфраструктуры, то они будут интегрироваться в эту инфраструктуру наилучшим образом.
4.      На счет классических сетевых средств защиты (FW, IPS, VPN, SSL) в виде виртуальных аплаенсов. Почти у всех современных вендоров есть варианты реализации своих шлюзов в виде виртуальных, поэтому не понятно, почему выбор ограничен только IBM, HP, Check Point, Cisco и Stonesoft. Аналогичные виртуальные аплаенсы есть и у Juniper Networks,  Palo Alto, Fortinet, Imperva и других.
5.      Непонятно почему включен в рассмотрение аппаратный МЭ Cisco ASA 5585-X и не включены все остальные аналоги? С моей точки зрения его надо исключать из этого сравнения.
6.      Не были рассмотрены решения, шифрующие виртуальные машины. Например, SafeNet ProtectV. С моей точки зрения это перспективное и востребованное направление.
7.      Так-же не согласен с методологией сравнения средств защиты. Авторы предлагают учитывать возможности средств защиты, которые направлены на самих себя. Например, разграничение доступа к административной консоли средства защиты или регистрация событий внутри средства защиты.
Ведь основная цель у нас – это защита вируализированной инфраструктуры, а не защита средств защиты. Несмотря на то, что МЭ выполняет функцию разграничения доступа к своему административному интерфейсу мы не называем его СЗИ от НСД.

Уверен, что это в конечном счете запутает неискушенного читателя.
Например, он может посчитать что установки МЭ Cisco ASA 5585-X будет достаточно для реализации всех мер, за исключением 5 и 9. А это не так – МЭ возможно будет участвовать в реализации этих мер, но никак не перекрывать их полностью.

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

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

Так например, напротив Cisco ASA 1000V, Cisco Virtual Security Gateway, Check Point VE, HP SVF, Stonegate  FW  я бы оставил только: 4, 10




четверг, 18 июля 2013 г.

СЗПДн. Анализ. Выбор мер обеспечения безопасности общедоступных ПДн 2

В одной из предыдущих заметок я приводил демонстрацию анализа и выбора мер защиты по новому комплекту документов (ПП 1119, Приказ ФСТЭК №21) на примере ИСПДн с общедоступными ПДн.

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

Я решил рассмотреть ещё раз ту же задачу с теми же исходными данными и с приведенным выше подходом.

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

Будем делать МУ по методическому документу ФСТЭК. Для данного примера я использую базовый перечень угроз + дополняю его парой угроз связанных с НДВ. Для примера их будет достаточно. А в реальной ИС, вы дополните всеми необходимыми угрозами, специфичными для Вас.

Напоминаю, что уровень исходной защищенности у меня получился низкий (Y1=10). Деталей расчета не привожу. Там всё очевидно и для своей ИС вы легко посчитаете.

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

Базовые угрозы довольно крупные и далее их будет неудобно использовать (вы это увидите), так как с одной крупной угрозой связано слишком много мер.

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



среда, 17 июля 2013 г.

СОИБ. Проектирование. Чего мы ещё лишаемся требуя использовать сертифицированную криптографию

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

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

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

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

Вариант 1 с примирением сертифицированных криптошлюзов (с минимальным возможным влиянием на характеристики СПД)


Вариант 2 с примирением защиты каналов по AES реализованной на аппаратном уровне сетевого оборудования

Сравним плюсы и минусы вариантов:

Вариант 1. Защита с использованием криптошлюзов
Вариант 2. Защита с использованием возможностей сетевого оборудования
Плюсы
“Надежный алгоритм” шифрования по ГОСТ 28147-89
Сертифицированное ФСБ Р решение
Надежный алгоритм шифрования AES
Более быстрая СПД
Более надежная СПД
Меньшая стоимость создания СПД
Меньшая стоимость обслуживания и поддержки СПД
Минусы
Более медленная СПД
Менее надежная СПД + СКЗИ
Большая стоимость создания СПД + СКЗИ
Большая стоимость обслуживания и поддержки СПД + СКЗИ
Несертифицированное ФСБ Р решение

Плюсы второго варианта настолько хороши, что стоит за него побороться.

А вариантов не использовать криптографию внутри сети немало:
·        Уменьшить количество информационных потоков, в рамках которых передается информация, подлежащая защите в соответствии c законодательством РФ (например, обезличивая ПДн)
·        Обеспечить контролируемость каналов не криптографическими способами. Так как в общем случае жесткий набор мер, которые надо принять для обеспечения контролируемого канала отсутствует, можно проявить творческий подход - разработать внутренний документ, который будет требовать, например, мониторинг портов оборудования, находящегося за пределами КЗ. Если этого мало, то опечатывания + периодического осмотра + пары видеокамер может быть уже достаточно
·        При моделировании угроз признать вероятность перехвата информации в каналах между зданиями низкой или “нулевой”, возможный ущерб небольшим, угрозу неактуальной, внешнего нарушителя имеющего физический доступ к каналу между зданиями неактуальным
·        При выборе мер защиты не требовать условия, что для нейтрализации угрозы перехвата информации между зданиями необходимо сертифицированное СКЗИ
·        При выборе варианта реализации мер защиты использовать подход экономической нецелесообразности решений на криптошлюзах и замены контрмеры на альтернативную

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