вторник, 25 декабря 2012 г.

Свои выводы ноябрь-декабрь 2012 г.

Слава богу, рабочий год подходит к концу. Вроде бы разобрался со всеми делами, но пока разгребался, к сожалению, пропустил все самое интересное в экспертном сообществе, ставлю себе незачот ))). Опишу свое мнение обо всем происходящем, постараюсь быть кратким.
С тем, что инициативы регулятора новые, и тенденция сама по себе хорошая, согласен полностью. То, что специалисты отправляли свои мнения по РД, и регулятор их частично (при этом не обструктивно) принимал, тоже замечательно. 
Теперь, что касается некоторого напряжения, вызванного открытым письмом Геннадия Атаманова. Сначала по содержанию - с большей частью претензий к тексту РД я согласен, но речь не об этом. Что по факту мы получили - весьма показательное явление и вызвано оно отсутствием организованности в тех новых начинаниях, которые предложил ФСТЭК. Все вышло на уровне самодеятельности. Отсюда и огрехи в формулировках и теоретические несостыковки в РД. Теперь выводы из этой ситуации:
1) Да самодеятельность, да подход "по-русски" со всеми вытекающими, но что вы хотите от первых шагов в новом направлении? Я согласен с точкой зрения Евгения Родыгина, главное в проектах новых РД - это их целевая аудитория. А целевая аудитория разрабатываемых РД - операторы, и для них необходимо было создать относительно простой и понятный документ, при этом не противоречащий уже сформулированным подходам НПА более высоких уровней. Исходя из этих целей, и с учетом обстоятельств, в которых все мы, в том числе регулятор, находимся, задача выполнена достаточно эффективно.  
2) Что делать дальше?  Ответ напрашивается сам собой - если подобная инициатива регулятора будет практиковаться и дальше, то экспертному сообществу необходимо организовываться в вопросах формирования и представления своих мнений. По поводу теоретической базы ИБ (так сказать её парадигмы) вопрос очень сложный, и если реально смотреть на вещи, то решить его получится не сегодня и даже не завтра. Главное, что нужно делать сейчас - это сохранить и укрепить тенденцию сотрудничества между регулятором и экспертами.
Ну и ещё одна маленькая ремарка, не могу без техчасти. Алексей Лукацкий говорит, что определение типа угроз, актуальных для ИС (угрозы, связанные с наличием НДВ) будет выполняться исключительно оператором. Но мне не дает покоя формулировка "и в соответствии с НПА..." п.7 ПП 1119. Вот пока не увижу окончательных документов ФСТЭК, и что в них НЕ указывается для кого какой тип угроз устанавливается, буду в этом сомневаться ))).

пятница, 28 сентября 2012 г.

Обналичка за обезличку..

Ни для кого не секрет, что обезличивание персональных данных является одним из способов понижения требований к системе их защиты. Однако конкретные вопросы применения данного механизма на сегодняшний день в отечественной нормативной базе не проработаны. Непонятно, какие можно использовать методы обезличивания, не определены условия их применимости, регламенты использования и прочее, прочее, прочее. Например, в одном форуме, мне заявляли, что обязательным условием обезличивания является невозможность обратного преобразования данных персоналом системы. Сильно в этом сомневаюсь, на мой взгляд техническая возможность этого должна быть, но должны присутствовать организационные и технические меры, четко описывающие и контролирующие когда, кому и в связи с чем это можно делать. Единственным отечественным документом, который мне попался на глаза, хоть как-то перечисляющим возможные методы обезличивания являются "Методические рекомендации по выполнению законодательных требований при обработке персональных данных в организациях банковской системы Российской Федерации" (там кстати тоже предусматриваются ситуации, когда в ИСПДн возможны операции, обратные обезличиванию). При этом перечисленные в этом документе методы взяты из NIST SP800‐122.
Так вот, 31 августа произошло интересное на мой взгляд событие - был опубликован конкурс на право выполнения работ по разработке требований и методов обезличивания персональных данных (ссылка). Я посмотрел техническое задание - предлагается создать классификатор с указанием перечня самих методов, а также различных условий и свойств каждого из них. В общем работа по систематизации. Заказчиком конкурса является РКН. Т.е. что мы имеем - регулятор обращается к специалистам по информационной безопасности с предложением выполнить экспертную работу, это может стать началом хорошей традиции. Условия работы мне показались вполне адекватными как по срокам, так и по квалификации. Никаких качественных оценок комиссии, что могло бы создать условия для лоббирования чьих-то интересов. Единственным критерием компетентности является количество работ по созданию ИСПДн, что создаст преимущество крупным игрокам (и это в данном случае думаю правильно, поскольку у крупных интеграторов больше возможностей по научным и аналитическим исследованиям). В первой половине октября станет ясно, кто победил и в результате чьих исследований (если они конечно будут, и все не скатится просто к дублю с международных стандартов) по этому вопросу РКН впоследствии выкатит документ, регламентирующий обезличивание. Как только информация по победителю появится - вставлю в комментарии. Страна должна знать своих героев ))



четверг, 30 августа 2012 г.

Вот вам и ФИПС

Сегодня случайно столкнулся с автоматизированной системой безбумажного делопроизводства экспертизы изобретений (система удаленной подачи заявок на изобретения) Федерального Института Промышленной Собственности и сильно удивился. Ребята взяли и развернули все на CheckPoint. В том числе сделали VPN SSL портал с ГОСТ-шифрованием. То, что CheckPoint реализовал у себя поддержку ГОСТ-шифрования через интеграцию с КриптоПро CSP уже давно не секрет, но их позиция была принципиальной в нежелании (или отсутствии возможности) проходить сертификацию в ФСБ. В своих презентациях они писали, что данную процедуру с их продуктами проходить не нужно. Не знаю, насколько они правы. Сейчас это один из камней преткновения, воюют все: регуляторы с вендорами, вендоры с покупателями и т.д. и т.п. Моя личная позиция в этом плане была "от греха подальше пользовать только сертифицированные СКЗИ для гос.заказчика". Да и как-то не слышал я, про реальные проекты, где бы использовали ГОСТ-VPN на CheckPoint. И вот пожалуйте. Уж не знаю, как они протащили такой проект, но система уже реально работает. Заявки на изобретение - это коммерческая тайна и с одной стороны владелец информации вправе сам устанавливать для неё меры по защите, но здесь речь идет в том числе и о государственных организациях, а значит необходимо использовать:
1) сертифицированные СКЗИ (в том числе сертифицированные VPN);
2) и/или ПО, прошедшее оценку влияния в случае взаимодействия прикладного ПО с СКЗИ.
В случае VPN SSL ещё можно попытаться перед регулятором уйти от сертификации к оценке влияния. В процессе обсуждения с одним из вендоров аргументы, которые мне привели на этот счет, технически мне показались обоснованными. Для установления ясности даже пришлось послать запрос в ФСБ по этому вопросу, но никакого ответа я к сожалению не получил, так что остается неясность. Как бы то ни было, про успешное выполнение ни первого, ни второго варианта относительно продуктов CheckPoint я не слышал. Но факт остается фактом.
Вот ссылочка на посмотреть ФИПС ))

вторник, 28 августа 2012 г.

Истории о сертификации

Решил коротенечко рассказать некоторые интересные моменты по сертификации средств защиты из своего опыта. Мало ли кому пригодится.

История №1 - не слушайте испытательные лаборатории

Заявлял я как-то на сертификацию несколько продуктов. Встал закономерный вопрос - сертифицировать их как что? Единственным документом на сегодня, определяющим что может быть средством защиты, является положение о сертификации №199 т 27.10.95 (и то оно для гостайны). И вот смотрю я перечень типов средств защиты в приложении 1 и понимаю, что некоторые продукты не попадают под этот список. Начинаю звонить в испытательную лабораторию (названия приводить не буду). Рассказываю, что хочу сертифицировать, говорю, что пойдем по схеме "на соответствие ТУ + отсутствие НДВ". На что мне уверенным голосом заявляют, что так не получится, ибо ни в каком РД ФСТЭК не упоминается такой тип средств защиты, а значит придется сертифицировать просто как защищенное средство обработки информации на отсутствие НДВ. Договариваемся, выдают цену. Тут я хочу посоветовать запросить цены по нескольким лабораториям, лично я нашел ту, в которой мне согласились выполнить работу в 1,5 раза дешевле. И вот дальше становится интересней. В процессе согласования заявки на сертификацию во ФСТЭК его представители мне вдруг заявляют, что сертифицировать надо все-таки по схеме ТУ+НДВ как средство защиты, попытка транслировать слова представителей испытательной лаборатории не менее уверенно отвергается. Отсюда делаем практический вывод - мнение о том что, если функционал (тип) средства защиты не упоминается ни в одном из РД ФСТЭК, то его сертифицировать как средство защиты нельзя - неверно.

История №2 - что такое ключевая информация

Одним из продуктов, которые подавались на сертификацию, являлся генератор паролей. Вобщем-то ничего особенного с функциональной точки зрения, но когда есть требования по сложности паролей, то штука удобная. И вот тут, ФСТЭК меня вообще удивила - мне было сказано, что данное средство не может быть сертифицировано в рамках их нормативной базы, поскольку существуют требования к генераторам случайных чисел в ФСБ и мне нужно обратиться туда. Я полез разбираться и выяснил, что данные требования устанавливаются только при формирования ключевой информации. Нас же продукт генерировал только пароли, которые никакого отношения к термину "ключевая информация" в рамках нормативной базы ФСБ не имеют. Но представители ФСТЭК были непреклонны, мне было отказано даже в попытке сертифицировать продукт на отсутствие НДВ, что вообще меня удивило. Единственное, что мне удалось - это получить от них письмо с официальным отказом в сертификации. Какой отсюда вывод? Общеизвестный - переубедить представителей регулятора как минимум крайне сложно (у меня не получилось).

История №3 - бонус затрат к сертификации

Ну этот момент пожалуй даже подводным камнем не назовешь, просто для тех, кто будет проходить эту процедуру впервые. Учтите, помимо сертификационных испытаний, которые вам проведет испытательная лаборатория, нужно будет пройти также через экспертное заключение корректности выводов испытательной лаборатории независимой организацией. Т.е. с вас после всего ещё сдерут порядка 80000-100000 руб за каждый продукт.

Вот такие вот истории пришли на память.

четверг, 12 июля 2012 г.

Старые и новые сертифицированные системы обнаружения атак

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


Итак, первое. Новые требования распространяются только на вновь разработанные IDS. Что эта фраза означает? Ответ следующий - требования накладываются на IDS, которые, условно скажем, разработаны (с точки зрения нормативной базы ИБ - поданы на сертификацию) с момента вступления в силу новых требований. Т.е. действия старых сертификатов никто не отменил.


Читаем информационное письмо ФСТЭК №240 от 01.03.2012 об утверждении требования к системам обнаружения атак..."Выполнение Требований является обязательным при проведении работ по оценке соответствия (включая работы по сертификации) средств технической защиты информации и средств обеспечения безопасности информационных технологий, применяемых для формирования государственных информационных ресурсов, организуемых ФСТЭК России в пределах своих полномочий." Толкование на мой взгляд следующее - если вы используете IDS для защиты ГИР, и этот ГИР организуется ФСТЭК-ом России, то да, применяемые IDS в этом случае должны отвечать новым требованиям. Здесь надо уточнять, какой-то это особый вид ГИР, которые организует ФСТЭК, или имеются ввиду все ГИР, поскольку их защита регламентируется в том числе ФСТЭКом. Мне это пока непонятно. В любом случае, даже если речь идет обо всех ГИР, а ГИР это информация в ГИС, то к примеру не каждая ИСПДн государственной организации является ГИСом, все зависит от положений, на основании которых система была создана. Что такое ГИС и с чем ее едят, можно найти на форумах. И опять же фраза "проведение работ по оценке соответствия (в том числе сертификации)" адресует интеграторов к термину "аттестация", поскольку в рамках этой процедуры проверяется соответствие средств защиты нормативным требованиям, и при этом она не является сертификацией. Это значит, что для защиты ГИР можно использовать IDS, сертифицированные на ТУ, главное чтобы при аттестационной проверке они отвечали всем новым требованиям нужного класса IDS.


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


Какой отсюда можно сделать вывод? Мнение о том, что в ИСПДн можно использовать только IDS, сертифицированное по новым требованиям на мой взгляд неверное. Необходимо рассматривать, является ли она ГИС...и опять же фраза "организуемых ФСТЭК" не дает мне покоя. Для защиты персональных данных во всех негосударственных информационных системах в любом случае можно использовать IDS, сертифицированные на ТУ.


Теперь по поводу не совсем относящегося к теме вопроса о том "можно ли использовать сертифицированные по старой практике на ТУ IDS для защиты государственной тайны?". Сейчас на этот вопрос дает процитированное мной выше положение с ГИР-ом. Если же эта фраза распространяется не на все ГИР, то можно либо: 
1) смотреть тексты сертификатов и ТУ этих IDS, там должны быть прописаны условия в которых можно их использовать, в частности класс АС и ИСПДн. 
2) если эта информация там не указана, смотреть документ ФСТЭК РД на отсутствие НДВ. В самом его начале сказано, что он разработан в дополнение к РД ФСТЭК на АС, который является основным для определения требований к системе защиты для АС (а значит и защиты гостайны). Соответственно ограничением по использованию IDS для защиты гостайны является наличие у него соответствующего сертификата на отсутствие НДВ.

пятница, 6 июля 2012 г.

Веселые тендеры

Посмотрел я сейчас на волну тендеров централизованных бухгалтерий Краснодарского края...Технические задания меня слегка удивили. Какой-то шустрый товарищ сделал предварительный анализ нужных средств защиты и выдал очень интересную спецификацию. Не долго думая, заложил механизмы обнаружения атак ПО ViPNet Client в состав системы обнаружения атак на ИСПДн. Ну правильно ViPNet Client же сертифицирован, зачем себя ещё какими-то рассуждениями озадачивать? А то, что он сертифицирован как МЭ, как СКЗИ, на отсутствие НДВ, но никакого сертификата как система обнаружения атак не имеет, это конечно ерунда. И все бы ничего, но заложена в работу аттестация системы. Вот я думаю - исполнителей туда уже несколько штук набралось, а как победитель собирается аттестовать ИСПДн без сертифицированной IDS? 
Вобщем написал я Заказчику запрос на разъяснение...В понедельник обещали выложить, мне очень интересно, что же там напишут. 
Но эпопея на этом не заканчивается. Стоит в ТЗ у них требование для подсистемы межсетевого экранирования и защиты каналов связи. Всё бы ничего, но указали они там класс КС2. Если кто-то внимательно читал формуляр на СКЗИ ViPNet Client КС2, то там указано, что исполнений этого ПО два, и уровень КС2 выполняется только совместно с электронным замком Соболь или Аккорд. Цена ViPNet Client порядка 6-6,5 тыс. рублей. А вот замочек стоит где-то 10 тыс. Теперь вопрос, как вы думаете, при формировании первичного предложения кто-то этот вопрос отслеживал? Правильно - нет!!! Запросили ориентировочные спеки без всяких замков, и в ТЗ, не долго думая, вкатили КС2. Я не поленился посчитать насколько вырастет бюджет, если закупить замки для выполнения требования по КС2. Цена сразу выросла под первичную цену тендера. А ведь нужно ещё делать работы, аттестацию проводить. А теперь самый интересный вопрос, как вы думаете, хоть кто-нибудь из потенциальных Исполнителей озаботился этим? Ой сомневаюсь. Вот я и посмотрю как будет выкручиваться победитель. Запрос Заказчику для разъяснений по этому поводу я тоже послал.

среда, 20 июня 2012 г.

Защищенный доступ к web-серверу или когда стоит проводить оценку влияния на СКЗИ

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

Для тех, кто не в курсе. Что такое "оценка влияния" и с чем её едят - ну допустим взяли вы какое-нибудь ПО или написали сами и хотите интегрировать в него нашу, любимую сердцу, отечественную криптографию (для шифрования данных или подписания с помощью ЭЦП и т.п.). Наиболее часто встречающаяся задача такого типа - это организация защищенного доступа к web-серверу через TLS-соединения (HTTPS-сервер, если проще). Понятно, что для этого нужно взять отечественное криптоядро (СКЗИ типа КриптоПро CSP, ViPNet CSP или других). И вот тут встает вопрос (на самом деле у многих по незнанию он даже не встает) - а достаточно ли просто использования сертифицированного ФСБ такого криптоядра или нужно ещё что-то? Вот в рамках ответа на этот вопрос и ФСБ и говорит об оценке влияния ПО на СКЗИ. Процедура это нетривиальная, нужно писать ТЗ с моделью нарушителя, согласовывать его в ФСБ, проводить испытания, при этом проводить их должны организации с лицензией ФСБ или вообще испытательные лаборатории ФСБ (в зависимости от класса применяемого СКЗИ). Сложно!!! Я постараюсь разнести все по полочкам, чтобы было ясно, как можно избежать этой процедуры.

Первое, что вы должны сделать - это посмотреть формуляр на криптоядро (вы можете скачать его с сайта вендора или запросить, если он не опубликован). Внимательно его изучите. Там указывается когда и при каких условиях следует проводить оценку влияния ПО на СКЗИ. Для ViPNet CSP, например, это п. 9 раздела 3, для КриптоПро CSP - п.1.5 раздела 1. Прочитали - и поняли, надо вам её делать или нет. Есть правда в данном моменте одна юридическая несостыковка. Существует ещё такой документ в ФСБ - ПКЗ-2005, где описывается порядок разработки, эксплуатации и прочего СКЗИ для информации, не составляющей гос. тайну. Так вот в нем также указана необходимость проведения оценки влияния (п.35), есть в нем и п.3, который один в один совпадает с теми условиями, которые прописаны в формулярах СКЗИ. Но!!! есть и п.4, который определяет условия, когда положения ПКЗ-2005 являются только рекомендациями (в том числе и п.35), и вот это в формулярах не учтено. Т.е. возможны условия, когда по ПКЗ-2005 мы на оценку влияния не выходим, а вот по формуляру почему-то должны (к примеру при защите коммерческой тайны негосударственными органами).

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

Таким образом, делаю заключительный практический вывод - если вам надо организовать например защищенный доступ к веб-серверу с передачей защищаемой законом информации или вы являетесь органом исполнительной власти (см. п.3 ПКЗ-2005) и вы не хотите проходить через оценку влияния - организуйте его встроенными средствами ОС, подходящей под выбранное криптоядро. Для продуктов КриптоПро CSP и ViPNet CSP - это брузер IE, веб-сервер IIS, веб-сервер Apache (из состава ОС Linux). Для подтверждения своих выводов публикую официальный ответ представителей ФСБ на этот счет.




Да граждане, на забываем, что все это касается только работы с прикладным ПО, если мы говорим о VPN-системах, то здесь нужна обязательная отдельная сертификация ФСБ, об этом уже много где говорилось.