понедельник, 27 мая 2013 г.

СОИБ. Анализ. Способы обхода DPI, WAF, DLP и д.р.


В рамках недавней PHDays проходил ряд докладов связанных с анализом эффективности существующих средств защиты:
·        В обход DPI, Олли-Пекка Ниеми (Opi)
·        Теория лжи: обход современных WAF, Владимир Воронцов
·        Десяток способов преодоления DLP-систем, Александр Кузнецов, Александр Товстолип

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

1.             
В своем докладе Олли-Пекка рассказал про пентестовую утилиту Evader, некоторые техники обхода средств защиты (evasion).  Сама утилита Evader – вещь отличная, но у доклада было несколько минусов:
·        Во-первых, несоответствие содержания и названия. К DPI никакого отношения. Область действия Evader и описываемых способов обхода – в основном сигнатурные сетевые системы защиты (NGFW, IPS)
·        Во-вторых, доклад не оправдывал уровень сложности – 200. Вполне хватило бы и 100. Так как это был краткий пересказ определений различных техник обхода и демонстрация интерфейса Evader
·        В-третьих, старая тема. Аналогичный доклад я уже слышал в Stonesoft 2 года назад. С того времени новых слов не прибавилось

Теперь по сути вопроса: так как в докладе не прозвучало какие именно средства какими недостатками обладают, нам потребуется самостоятельно развернуть тестовый стенд Evader, о котором я уже писал ранее. Прогнать его используя mongbat со всеми возможными комбинациями обхода (evasion), определить те, которые не обнаруживаются нашим сетевым средством защиты. Дополнительно настроить средства защиты, так чтобы обнаруживать атаки даже с техниками обхода (уверен, что в 90% случаев это можно сделать). А для оставшихся 10% необнаруживаемых атак принять решение о необходимости иных “компенсирующих” мер.


Например, если у нас web приложение, а FW и IPS не могу определить атаки, то нужен WAF. Либо, как предлагает Stonesoft, использовать временную меру Stonesoft Evasion Prevention System (EPS), которую можно впихнуть в любую работающую инфраструктуру.

2.             
Доклад про обход WAF был очень хорош в части презентационных навыков докладчика и интересности – слушался легко и непринуждённо.  НО полезной информации, которая была нужна мне и о которой я писал выше, там не было:
·        Сам докладчик говорит, по ряду недостатков WAF (DoS, Protocol-Level Evasion, защищаемые Hostname, HTTP Protocol Pollution), говорит что они связаны с плохой настройкой средства защиты, потом совершает логическую ошибку и говорит что плохи сами WAF.
·        Техники обхода перечислялись в режиме пересказа, без демонстраций, деталей и т.п.
·        По ходу дела докладчик неоднократно говорит “в корпоративных WAF всё настолько плохо, что я не буду их рассматривать в данном разделе, рассмотрю только open source средства защиты”. Из этого я делаю вывод, что у докладчика всё настолько плохо с получением “корпоративных” WAF на тестирование и с опытом их настройки, что он не хочет трогать эту больную тему
Для подтверждения того что утверждение докладчика не очевидно, привожу следующий аналитический отчет

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

·        Часть уязвимостей, приведенных автором, являются уязвимостями конечных сервисов и приложений и не имеют отношения к WAF (который их отлично детектирует). Зачем автор привел их в данной теме? Наверное, решил выложить все, что он знает в безопасности web.
·        В самом конце докладчик говорит, что разрабатывает собственное принципиально новое средство защиты web приложений (вот и открылись истинные причины критики WAF)

На самом деле, в WAF есть достаточно много правил нормализации и контроля протоколов, надо только их корректно настроить. Вполне возможно автор доклада не потратил достаточно времени на изучение возможных вариантов настройки “корпоративных” WAF.

Сами принципы и технологии работы современных корпоративных WAF сильно отличаются от того, про что рассказывал докладчик, это давно уже не набор детектируемых сигнатур. В них уже есть:
·        система полномочного разграничения доступа, в которой мы задаем явно, что можно делать пользователю в web приложении (не путать с блокированием запросов по сигнатурам атак)
·        динамическое профилирование, в рамках которого система автоматически стоит профили запросов нормальных пользователей и обнаруживает аномальное отклонение
·        защита от автоматизированных атак (Automated Attack), в рамках которой обнаруживаются внешняя инвентаризация, перебор, фазинг и т.п.
·        корреляция с системами защиты БД, в рамках которого WAF получает информацию, о том какой реально запрос и ответ прошел от сервера web приложения к серверу БД
Эти механизмы не упоминались и делаю вывод, что они докладчику были неизвестны.

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


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

4.            Общей же мыслью всех трех докладчиков является необходимость грамотной настройки средств защиты информации, постоянному мониторингу и оптимизации настройки. Принцип “поставил и забыл” в мире реального ИБ – не работает.

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

Часто заказываются бюджетные варианты с типовыми настройками. И я не уверен, что администраторы самостоятельно получают достаточное обучение  по настройке продукта, настраивают и поддерживают все необходимые функции. Если настройки остаются по умолчанию, то слова всех докладчиков будут справедливы – злоумышленник может быстро подобрать меры по обходу средств защиты.

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

6.            Ещё один вывод – Чтобы хакер смог понять, как обойти нашу систему защиты, ему нужно развернуть и протестировать у себя точный аналог. Если мы используем дорогое корпоративное решение, то обычному хакеру этот вариант недоступен.

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


пятница, 24 мая 2013 г.

СОИБ. Онлайн семинар. Фильтрация трафика оператором связи с применением DPI


Наверное, все уже слышали про изменения законодательства РФ касающегося операторов связи в последний год:

·        Федеральный закон Российской Федерации от 28 июля 2012 г. № 139-ФЗ «О внесении изменений в Федеральный закон «О защите детей от информации, причиняющей вред их здоровью и развитию» и отдельные законодательные акты Российской Федерации» (часть его, не касающаяся детей называют законом о “Едином реестре запрещённых сайтов”)
·        Федеральный закон от 29 декабря 2010 года № 436-ФЗ "О защите детей от информации, причиняющей вред их здоровью и развитию" (изменения связанные с категорированием, маркировкой информационной продукции и ограничении доступа детей к немаркированной информации)
·        Федеральный закон от 05.04.2013 № 50-ФЗ "О внесении изменений в отдельные законодательные акты Российской Федерации в части ограничения распространения информации о несовершеннолетних, пострадавших в результате противоправных действий (бездействия)"
·        Постановление Правительства Российской Федерации от 26 октября 2012 г. N 1101 г. Москва "О единой автоматизированной информационной системе "Единый реестр доменных имен, указателей страниц сайтов в информационно-телекоммуникационной сети "Интернет" и сетевых адресов, позволяющих идентифицировать сайты в информационно-телекоммуникационной сети "Интернет", содержащие информацию, распространение которой в Российской Федерации запрещено""

На первых этапах реализации законодательства возникло много вопросов и проблем, которые операторы донесли до Роскомнадзора. В том числе проблему о некорректности блокирования трафика только по IP-адресу.

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

Далее Роскомнадзор публиковал детальные результаты анализа возможных методик блокировки запрещенной информации сети Интернет обсудил с экспертами перспективы методик блокировки

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

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

В связи с этим компаниями Микротест совместно Cisco Systems 28 мая 2013 год в 11:30 проводят бесплатный онлайн-семинар "Создание услуг оператора связи с помощью DPI-решения Cisco SCE. Услуги «Родительский контроль» и «Безопасный web-серфинг». Технические особенности решения"

На мероприятии будут обсуждаться:
·        Детали требований законодательства РФ для операторов связи
·        Текущая ситуация в операторских сетях и возникающие проблемы
·        Возможности решений DPI
·        Выгоды операторов связи от внедрения решений DPI

К участию приглашаются: ИТ-директора, директора по информационной безопасности, технические директора и специалисты операторов связи


среда, 22 мая 2013 г.

Общее. Посмотреть на PHDays


Наверное, одно из немногих мероприятий, на которых были ненулевые доклады (доклады с глубоким погружением в тему) – это международный форум Positive Hack Days. В этом году мне приходило приглашение как блогеру, была возможность поучаствовать от компании, но в итоге лично не получилось поехать. Но на радость мне и вам, организаторы обеспечили возможность онлайн просмотра конференции, так что буду смотреть видеотрансляцию.

Что лично я планирую посмотреть?

В первую очередь хочется посмотреть технические доклады, ведь они бывают всего 2 раза в году, а бизнес-мероприятия почти каждый день. Но не все технические  доклады применимы в тех областях, которые мне интересны: проектировании, внедрении, настройке, эксплуатации средств и систем защиты информации. Поэтому выбираю эти:
·        Нужны ли модели АСУ ТП при обеспечении информационной безопасности промышленных систем? (Руслан Стефанов), 200, 23, 10-00
·        В обход DPI (Олли-Пекка Ниеми), 200, 23, 10-00
·        Мастер-класс по RFID (Науэль Грисолия), 23, 10-00
·        Ловушки умеют кусаться: обратное проникновение (Вячеслав Егошин), 200, 23, 11-00
·        SCADA Strangelove: как создать собственный Stuxnet (Positive Technologies), 200, 23, 14-00
·        Моделирование атак, вычисление метрик защищенности и визуализация в перспективных SIEM-системах (Игорь Котенко), 300, 24, 10-00
·        Методология атаки на SAP (Дмитрий Гуцко, Олег Ключников), 24, 10-00
·        Индустриальная IPS своими руками (Дмитрий Дудов), 200, 24, 12-00
·        Теория лжи: обход современных WAF (Владимир Воронцов) , 200, 24, 14-00
·        SPAN-агрегация и анализ сетевого трафика на наличие угроз: возможности и ограничения, плюсы и минусы (Андрей Дугин), 24, 15-00
·        Мошенничество в SMS-банкинге (Денис Горчаков, Ольга Кочетова), 24, 15-00
·        Динамическое обнаружение шелл-кода в электронных документах (Игорь Агиевич, Павел Марков), 24, 16-00
·        Механизмы безопасности Microsoft SQL Server 2012 (Вениамин Берестов), 24, 16-00
·        Безопасность мобильных банковских приложений (Артем Полторжицкий), 24, 17-00
·        Анализ функциональности репутационных сервисов (Павел Коростелёв), 24, 17-00
·        Локпикинг и физическая безопасность (Девиант Оллам, Бабак Жавади, Кит Хоуэлл), 200, 24, 15-00
·        Десяток способов преодоления DLP-систем (Александр Кузнецов, Александр Товстолип), 24, 17-00

Посмотрю и несколько бизнес секций (потому что регуляторы с такими докладами нечасто, а SDLC новая полезная тема):
·        Сертифицированное и защищенное, или От теории к практике (Виталий Сергеевич Лютиков), 100, 23, 15-00
·        SDLC – блажь, веяние моды или требование регуляторов? (Алексей Лукацкий), 100. 23, 17-00
·        Инспекционные проверки регуляторов (Андрей Валерьевич Федичев), 24, 15-00

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

Смотреть CTF как на месте, так и онлайн – бесполезно. Есть визуализатор, но он абсолютно не отражает того, что происходит на самом деле – анализируется код, исследуются приложения, ищутся флаги, пишутся сплоиты, пишутся автоматизаторы их применения, исправляются уязвимости, отключаются или включаются сервисы и т.п.

Самое интересное в CTF для стороннего наблюдателя – это сценарий, который придумали организаторы (обычно PT выдает что-то суперское и в этом году похоже на старинную стратегию с замками, ресурсами, драконами и подземельями) и потом прочитать отчеты участников 


вторник, 21 мая 2013 г.

СЗПДн. Анализ. Приказ ФСТЭК №21 (UPD)

Как вы, наверное, уже заметили, Минюст зарегистрировал и опубликовал новый приказ ФСТЭК №21 от 18.02.2013 "Об утверждении состава и содержания организационных и технических мер по обеспечению безопасности персональных данных при их обработке в информационных системах персональных данных".

Хотя я и участвовал в совершенствовании документа (SOISO), специально не хотел публиковать каких-то аналитических статей для широкого круга пользователей, потому что слишком уж в России быстро и сильно меняются конечные версии документов по сравнению с их проектами. И большая радость может  неожиданно сменится на большую печаль.

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


(Кликать по ссылке1 - картинка JPG, но лучше загружайте в формате PDF - там лучшее качество текста. Стрелки со сплошными линиями - значит есть явное требование в приказе, с пунктирными - мои личные соображения)

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

·        В общем, в документе  не говорится о необходимости применения именно сертифицированных СЗИ. Но неприятная фраза в конце пункта 8.12 требует 4 уровень контроля отсутствия НДВ для ИСПДн 1 и 2 уровня защищенности и ИСПДн, для которых актуальны угрозы 2-ого типа.
“Для обеспечения 1 и 2 уровней защищенности персональных данных, а также для обеспечения 3 уровня защищенности персональных данных в информационных системах, для которых к актуальным угрозам отнесены угрозы 2-ого типа, применяются средства защиты информации, программное обеспечение которых прошло проверку не ниже чем по 4-ому уровню контроля отсутствия недекларированных возможностей”
Других способов обеспечить 4 уровень контроля отсутствия НДВ кроме сертификации я нет, поэтому считаю,  что для части систем сертификация требуется в явном виде.
Вообще моё мнение что эта игра с угрозами 1 и 2 типов (НДВ) была затеяна именно для того, чтобы протащить требования по сертификации на отсутствие НДВ.  Для того, чтобы ФСТЭК Р и ФСБ Р получили доступ к исходным кодам иностранных СЗИ, либо те будут вытеснены.
А целая группа экспертов наивно предположила что речь идет о защите интересов операторов или субъектов и пытались разработать правильные меры.

·        Если раньше определение необходимых мер защиты производилось в зависимости от ключевых характеристик ИСПДн и  актуальности угроз, то теперь добавилось ещё и понятие “экономической целесообразности”. Пока не совсем понятно что это за инструмент и как им можно будет пользоваться. Если идти по классическому пути, то это очень похоже на оценку рисков, определение приемлемых рисков и понижение неприемлемых рисков до приемлемых

·        В документе  не говорится о том, необходимо ли применение данных требований для существующих ИСПДн и СЗПДн? Это ещё одна проблема и корупцигенный фактор.
Операторы вынуждены или принимать регуляторные риски или переделывать уже принятые меры

·        В документе появился новый старый термин “оценка эффективности системы защиты”. Опять же тут простор для творчества.
Подходит аттестация, но не хотелось бы чтобы аттестация применялась для большого процента операторов. Так как она подходит только для жестко ограниченных и редко меняющихся ИС. В какой-то степени это шаг назад, в обратную сторону от развития.
Хотелось бы проработать и альтернативные варианты оценки эффективности, такие ка внешний аудит и самооценка.
Кстати если говорить о самооценке, то новый виток развития могут получить средства и системы для простой самооценки операторами своих СЗПДн, как это было с самооценкой СТО БР полтора года назад.

·        В документе предусмотрена возможность для сочинения новых угроз, применения дополнительных мер, сверх требуемого. Будет ли кто-то этим пользоваться? Да, только в случае если удастся уйти от обязательной сертификации СЗИ. Добровольно никто не будет обвешивать себя двумя – тремя слоями сертифицированных продуктов. (ведь можно эти дополнительные решения провести за рамками СЗПДн, быстрее, дешевле и иметь в будущем меньше проблем с ограничениями сертифицированных СЗИ)

·        В документе  не говорится о том, необходимо ли применение данных требований для существующих ИСПДн и СЗПДн? Это ещё одна проблема и корупцигенный фактор.
Операторы вынуждены или принимать регуляторные риски или переделывать уже принятые меры

·        В случае использования сертифицированных СЗИ, не определено на соответствие чему должны быть сертифицированы СЗИ отличные от СОВ, МЭ и САЗ? Например DLP. Как я понимаю можно сертифицировать на то что “просто работает”.

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


PS: Думаю прямо сейчас разбирать конкретные меры смысла нет, а позже сделаю пример анализа для какой-нибудь простой ИСПДн.

PPS: Статьи коллег блогеров с анализом нового приказа ФСТЭК (буду пополнять):





вторник, 14 мая 2013 г.

СОИБ. Проектирование. Сертифицированный защищенный удаленный доступ (Remote VPN) часть 2


В продолжение предыдущих части 0 и части 1

В этот раз рассмотрим самый простой вариант Remote VPN КС1 и сравниваем – на сколько он сложнее чем вообще не сертифицированный Remote VPN

1.      Операционные системы (смотреть таблицы в Приложении 1). Если мы посмотрим на статистику использования ОС и мобильных ОС можно сделать следующие вывод - примерно 13% наших пользователей с ноутбуками (с операционными системами Windows 8, OS X, Linux) останутся без Remote VPN.  С мобильными устройствами совсем беда – есть решение только у одного вендора и только для iOS. То есть за бортом остается ощутимая часть сотрудников.

В не сертифицированном варианте покрытие ОС и технических средств почти 100% 

Статистика по ОС тут и тут 


2.      В зависимости от решения по разному могут быть предъявлены требования к защите  от влияния аппаратных компонентов технических средств на функционирование СКЗИ при защите ПДн.
Например, в варианте С-терра VPN Client (Приложение 2 - 9) для этого требуется проводить тематические исследования BIOS. Стоимость таких работ на порядок больше чем стоимость самого решения.
В варианте Stonegate VPN Client (Приложение 2 - 12) рекомендуется проводить исследования BIOS ещё и на технических средствах субъектов ПДн,  данные которых обрабатываются у нас!!    :O  (кто мог такое придумать, это ж работа для исследователей BIOS на годы вперед обеспечена)

3.      При подключении технического средства с СКЗИ к сетям связи общего доступа (а Remote VPN и предназначен для работы через такие подключения) требуется использовать сертифицированные средства межсетевого экранирования (Приложение 2 – 13 и Приложение 2 – 15). То есть либо использовать Remote VPN со встроенным МЭ либо применять дополнительный.

4.      Для защиты среды в которой работает сертифицированное СКЗИ должны использоваться сертифицированные ФСТЭК и ФСБ средства антивирусной защиты из перечня (Касперский, Nod32, Dr. Web) (Приложение 2 – 16). Есть вероятность что придется менять наш любимый антивирус. Ещё и перечень ОС, под которыми работают сертифицированные антивирусы ограничен  (см. соответствующие формуляры на антивирусы) и не позволяет нам использовать их на экзотических ОС  (определенные Linux, Mac OS, iOS,)

5.      При использовании для аутентификации пользователей Remote VPN сертификатов PKI (а именно такой вариант более надежен, по сравнению с паролями) необходимо использование Удостоверяющего центра, сертифицированного по классу криптографической защиты, не меньшему чем решение Remote VPN (Приложение 2 - 1) при этом для некоторых  решений явно разрешено использование предопределенных ключей pre-shared key (Приложение 2 - 11)

6.      Разворачивание в организации сертифицированного удостоверяющего центра, помимо приобретения лицензий, серверов, АРМ оператора, средств защиты от НСД, влечет за собой в том числе установку МЭ, сертифицированного ФСБ (Приложение 2 - 8).
Итого:
Использование внешнего сертифицированного УЦ увеличит стоимость решения примерно на 2000 руб. на пользователя ежегодно.
Использование собственного сертифицированного УЦ увеличит стоимость решения примерно на 2000 руб. на пользователя.
Использование имеющихся в организации несертифицированных УЦ  (таких как Microsoft Active Directory Certificate Cervices) нелегитимно.

7.      При использовании сертифицированного Remote VPN мы ограничены при определении срока действия сертификата пользователя. Мы обязаны менять его раз в год, а максимальный срок жизни не может превышать 1 год и 3 месяца. (Приложение 2 – 3 и Приложение 2 - 10). В случае с несертифицированным мы можем выбирать срок в соответствии с корпоративной политикой – например 3 года и соответственно уменьшить трудозатраты на эксплуатацию решения.

8.      При хранении закрытых ключей или сертификатов пользователя на локальном диске или реестре (случай когда не применяются eToken) мы обязаны для технических средств (ноутбуков) принимать меры, аналогичные ключевым носителям (Приложение 2 - 3). А меры по защите ключевых носителей требуются немаленькие (смотреть содержание нормативных актов из Части 0), в том числе регистрировать их как носители, регистрировать помещения в которых на них работаем, обеспечивать отсутствие к ним доступа посторонних лиц, убирать во внерабочее время в сейф и т.п.

9.      При использовании сертифицированных Remote VPN  заброшено использование беспроводных каналов связи (Приложение 2-4 и Приложение 2-7). Скажите “нет” WiFi, 3G, 4G, bluetooth, NFC. Что остается мобильному пользователю с ноутбуком?
Так-же придется отключать беспроводные мышки и клавиатуры.

10.   При использовании сертифицированного Remote VPN потребуется внедрить обязательные организационные меры, разработать и поддерживать порядка 17 документов (Приложение 3)

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

Организациям, внедряющим полностью легитимный сертифицированный Remote VPN надо учитывать, что его стоимость будет в разы превосходить стоимость несертифицированного аналога и использовать это при выборе контрмер и определении необходимости сертифицированного ФСБ Р решения.

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

PS: Наверное вам интересно, почему в названии статьи Remote VPN а не просто VPN? Ведь большинство пунктов справедливо для любого сертифицированного VPN решения.  

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


Приложение 1.
ОС, поддерживаемые СКЗИ



СЗИ от НСД, которые необходимо использовать для классов больших чем КС1 ( для КС2-КС3)

Итоговая сводная таблица по клиентам Remote VPN (не шлюзам)


Приложение2.
Наиболее интересные ограничения и условия (прошу внимательно прочитать и проверить что у вас они соблюдаются):
1.      Криптопро CSP 3.6.1 Формуляр ЖТЯИ.00050-03 30 01.
“1.2 Эксплуатация СКЗИ  ЖТЯИ.00050-03 должна проводиться в соответствии с эксплуатационной документацией, предусмотренной настоящим Формуляром
1.4 При эксплуатации СКЗИ ЖТЯИ.00050-03 должны использоваться сертификаты открытых ключей, выпущенные Удостоверяющим центром, сертифицированным по классу защиты не ниже класса защиты используемого СКЗИ.”

2.      Криптопро CSP 3.6.1 Формуляр ЖТЯИ.00050-03 30 01.
“1.5 При встраивании СКЗИ ЖТЯИ.00050-03 в прикладные системы необходимо проводить оценку влияния аппаратных, программно-аппаратных и программных средств сети (системы) конфиденциальной связи, совместно с которыми предполагается штатное функционирование СКЗИ, на выполнение предъявленных к СКЗИ требований:
- для исполнения 3 (класс защиты КС3) – во всех случаях;
- для исполнений 1 (класс защиты КС1) и 2 (класс защиты КС2) - в следующих случаях:
1) если информация, обрабатываемая СКЗИ, подлежит защите в соответствии с законодательством Российской Федерации;
2) при организации защиты информации, обрабатываемой СКЗИ, в федеральных органах исполнительной власти, органах исполнительной власти субъектов Российской Федерации;”

3.      Криптопро CSP 3.6.1 Формуляр ЖТЯИ.00050-03 30 01.
“7.8 При эксплуатации СКЗИ ЖТЯИ.00050-03 должны соблюдаться следующие сроки использования пользовательских закрытых ключей и сертификатов: максимальный срок действия закрытого ключа ЭП (ключа ЭП) - 1 год 3 месяца;
Допускается хранение закрытых ключей на HDD ПЭВМ (в реестре ОС Windows, в разделе HDD при работе под управлением других ОС) при условии распространения на HDD или на ПЭВМ с HDD требований по обращению с ключевыми носителями.”

4.      Криптопро CSP 3.6.1 Руководство администратора. Часть 16. ЖТЯИ.00050-03 90 02
“16. Должна быть запрещена работа СКЗИ при включенных в ПЭВМ штатных средствах выхода в радиоканал
20. ЗАПРЕЩАЕТСЯ использование беспроводных клавиатур и компьютерных мышей”

5.      Криптопро CSP 3.6.1 Руководство администратора. Часть 16. ЖТЯИ.00050-03 90 02
“17. При функционировании исполнения 2 СКЗИ в программно-аппаратных средах Windows XP/2003 , ОС Solaris 9/10 (sparc, ia32, x64) инициализация ПДСЧ должна производиться с использованием внешней гаммы.”

6.      Криптопро CSP 3.6.1 Руководство администратора безопасности. Использование СКЗИ под управлением ОС iOS.  ЖТЯИ.00050-03 90 02-07
“2. Для операционной системы iOS КриптоПро CSP не поставляется в виде конечного приложения. КриптоПро CSP для iOS представляет собой фреймворк для разработки, который содержит в себе объектный файл, реализующий функции CSP, ресурсы и заголовочные файлы. Фреймворк не имеет механизма самостоятельной установки в операционную систему. Установка осуществляется в составе прикладной программы, разработанной на основе фреймворка теми средствами, которые предлагает разработчик прикладной программы.

7.      Криптопро CSP 3.6.1 Руководство администратора безопасности. Использование СКЗИ под управлением ОС iOS.  ЖТЯИ.00050-03 90 02-07
10. Ежесуточная перезагрузка ПЭВМ.
15. Должна быть запрещена работа СКЗИ при включенных в ПЭВМ штатных средствах выхода в радиоканал.”

8.      КриптоПро УЦ. Формуляр. ЖТЯИ.00067-02 30 01.
“3. Межсетевой экран должен быть сертифицирован ФСБ России на соответствие требованиям к устройствам типа межсетевой экран по 4 классу защищенности. Не входит в комплект поставки, поставляется по согласованию с заказчиком.”

9.      С-терра CSP VPN Client 3.11 Правила пользования РЛКЕ.00005-02 90 02. 
“4.5…. Для всех исполнений СКЗИ для исключения возможности влияния аппаратных компонентов СФК на функционирование СКЗИ должны быть выполнены следующие требования:
в случае обработки информации, подлежащей обязательной защите в соответствии с законодательством Российской Федерации, необходимо проводить исследования ПО BIOS СВТ, на котором установлен ПК "CSP VPN Gate", на соответствие требованиям "Временных методических рекомендаций к проведению исследований программного обеспечения BIOS по документированным возможностям"

10.   С-терра CSP VPN Client 3.11 Правила пользования РЛКЕ.00005-02 90 02. 
“4.7 Требования к обращению с ключевыми документами
Требования к ключам регламентируются документом «Руководство администратора безопасности» КриптоПро CSP, согласно которому срок действия открытых и закрытых ключей шифрования – 1 год 3 месяца.”

11.   StoneGate Firewall/ VPN Client 5. Программный комплекс криптографической защиты «StoneGate Firewall/VPN» версия 5 ПРАВИЛА ПОЛЬЗОВАНИЯ 89625543.4012-001 90 02
“6. …. Аутентификация пользователей при обращении к шлюзу StoneGate Firewall/VPN возможна с использованием метода аутентификации на основе сертификатов. Возможна комбинация методов аутентификации по сертификатам c другими методами для предоставления пользователю доступа к функциям системы.
Аутентификация абонентов при взаимодействии шлюза StoneGate Firewall/VPN с другими шлюзами возможна с использованием методов аутентификации на основе сертификатов и на основе предварительно распределяемых ключей. При использовании метода аутентификации на основе предварительно распределяемых ключей каждая пара шлюзов должна иметь уникальный ключ длиной 256 бит (при использовании для генерирования и распределения ключей для шлюзов StoneGate Firewall/VPN функций системы управления SMC это требование выполняется автоматически)
При использовании для аутентификации абонентов сертификатов, требования к аутентификации аналогичны предъявляемым при функционировании соответствующих используемых в комплексе StoneGate Firewall/VPN исполнений СКЗИ «КриптоПро CSP 3.6.1». При использовании иных методов аутентификации требования к аутентификации определяются настоящими Правилами.

12.   StoneGate Firewall/ VPN Client 5. Программный комплекс криптографической защиты «StoneGate Firewall/VPN» версия 5 ПРАВИЛА ПОЛЬЗОВАНИЯ 89625543.4012-001 90 02
“6. Если с помощью StoneGate Firewall/VPN обрабатывается информация, подлежащая обязательной защите в соответствии с законодательством Российской Федерации, должно быть обеспечено соответствие ПО BIOS СВТ оператора такой информации (включая оператора персональных данных), на котором установлены компоненты комплекса, «Временным методическим рекомендациям к проведению исследований программного обеспечения BIOS по документированным возможностям». Проверка соответствия ПО BIOS СВТ субъекта данных (например, субъекта персональных данных) не требуется, но рекомендуется”

13.   StoneGate Firewall/ VPN Client 5. Программный комплекс криптографической защиты «StoneGate Firewall/VPN» версия 5 ПРАВИЛА ПОЛЬЗОВАНИЯ 89625543.4012-001 90 02
“6.1 …
- при использовании СКЗИ на ПЭВМ, подключенных к общедоступным сетям связи, с целью исключения возможности несанкционированного доступа к системным ресурсам используемых операционных систем, к программному обеспечению, в окружении которого функционируют СКЗИ, и к компонентам СКЗИ со стороны указанных сетей должны использоваться дополнительные методы и средства защиты (межсетевые экраны). При этом возможно задействовать функции разграничения сетевого доступа шлюза StoneGate Firewall/VPN (данный функционал имеет сертификат ФСТЭК);”

14.   Криптопро CSP 3.6.1 Руководство администратора. Часть 16. ЖТЯИ.00050-03 90 02
“15.... при использовании СКЗИ на ПЭВМ, подключенных к общедоступным сетям связи, с целью исключения возможности несанкционированного доступа к системным ресурсам используемых операционных систем, к программному обеспечению, в окружении которого функционируют СКЗИ, и к компонентам СКЗИ со стороны указанных сетей, должны использоваться дополнительные методы и средства защиты (например: установка межсетевых экранов, организация VPN сетей и т.п.). При этом предпочтение должно отдаваться средствам защиты,  имеющим сертификат уполномоченного органа по сертификации.”

15.   МАРШ!

В настоящее время производитель устанавливает на МАРШ! только Linux. Идет тестирование Windows Embeded. Если МАРШ! будет поставляться в составе с Windows, то условия формуляра  позволяют использовать такой вариант для класса КС2

16.      Криптопро CSP 3.6.1 Формуляр ЖТЯИ.00050-03 30 01.
“2. При эксплуатации СКЗИ ЖТЯИ.00050-03 должны выполняться следующие требования:
…4. СКЗИ должно использоваться со средствами антивирусной защиты. Класс антивирусных средств защиты определяется условиями эксплуатации СКЗИ в автоматизированных системах”
Криптопро CSP 3.6.1 Руководство администратора. Часть 16. ЖТЯИ.00050-03 90 02
“13….Программное обеспечение СКЗИ ЖТЯИ.00050-03 должно использоваться со средствами антивирусной защиты, сертифицированными ФСТЭК и ФСБ России:
Антивирус Касперского
Антивирус Dr.Web
Антивирус NOD32.”



Приложение 3.
Типовой комплект документов при использовании сертифицированных СКЗИ для защиты ПДн (ссылки на пункты типовых требований149/6/6-622 ФСБ России по защите ПДн, которые в свою очередь скопированы  из приказа 152 ФАПСИ):
·        заключение о возможности эксплуатации криптосредств (п. 2.3);
·        журнал учета используемых криптосредств (п. 3.4);
·        журнал учета технической документации к криптосредствам (п. 3.4);
·        приказ о назначении лиц (пользователей криптосредств), допущенных к работе с криптосредствами (п. 2.3);
·        документ, устанавливающего порядок обеспечения безопасности ПДн при помощи криптосредств (п. 1.3);
·        документ, устанавливающего порядок организации контроля за соблюдением условий использования криптосредств (п. 2.3);
·        приказ о назначении ответственного пользователя криптосредств (п. 2.6);
·        описание функциональных обязанностей ответственного пользователя криптосредств  (п. 2.7);
·        лицевые счета на пользователей криптосредств (п. 3.5);
·        технический (аппаратный) журнал регистрации разовых ключевых носителей  (п. 3.6);
·        приказ о назначении комиссии по уничтожению ключевых документов (п. 3.22);
·        документ, устанавливающий требования к режимным помещениям, в которых эксплуатируются криптосредства (п. 4.1);
·        журнал учета хранилищ (п. 4.5);
·        журнал проверок исправности сигнализации (п. 4.7);
·        журнал учета ключей от хранилищ ключевых документов и технической документации (п. 4.8);
·        журнал службы охраны (п. 4.9).