Этих людей ничего не исправит ;-(

Еду после семинара в метро. На Пушкинской захожу в вагон и, видя свободное место, хочу на него сесть. Но вдруг вижу под сиденьем бесхозный чемоданчик от инструментов. Первая реакция - отойду от греха подальше, что и делаю, отойдя к соседней двери. Над чемоданчиком садится какой-то мужчина. Потом вступает в игру натура безопасника и я иду к кнопке вызова, чтобы сообщить о подозрительном предмете машинисту. В этот момент вижу, как женщина, сидевшая напротив чемоданчика, говорит мужчине, что стоило бы нажать на кнопку вызова, находящуюся у него над головой. Ответ парадоксален: "А я сейчас выхожу". Тогда женщина сама жмет на кнопку вызова... эффекта ноль! Связь с машинистом не работает. Попутно место около чемоданчика освобождается - соседи встают и уходят в другие части вагона, косясь на "бомбу".

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

Подходим ко второй кнопке - она тоже не работает! Появляется станция "Улица 1905-го года". Мы с девушкой, пытавшейся связаться с машинистом выходим. Она переходит в соседний вагон (видимо решила проверить кнопку вызова еще и там); я ищу милицию. Нахожу. Сообщаю о бесхозном чемоданчике и номере вагона (выбит под кнопкой вызова). Какова должна быть реакция представителя правоохранительных органов в таком случае? Правильно, сообщить по маршруту об опасности, что милиционер и делает, но... Делает он это не по рации, не по селектору на станции. Он звонит с личного мобильного телефона коллеге на соседней станции! Вы говорили когда-нибудь в метро по телефону, когда к станции приближается поезд? Не слышно ни фига и приходится повторять все заново по 2-3 раза ;-( В итоге милиционер не успевает - опасный поезд уже проезжает "Беговую" в сторону "Полежаевской". Заканчивается тем, что он сообщает коллеге, чтобы они все-таки попробовали найти бесхоз. Говорит мне "Спасибо" и мы расстаемся. Я сажусь в свой поезд и, Слава Богу, спокойно доезжаю до конечной (видимо никакой бомбы в чемоданчике не было).

Вот спрашивается, как часто должны быть взрывы в метро, чтобы:
1. Люди перестали быть беспечными и стали реагировать.
2. Власти оснастили милицию нормальными средствами связи, предназначенными для работы под землей и в шумном месте?

Подробнее…

Текущее значение индекса безопасности

Помните в 2011-м году я писал про индекс кибербезопасности, который отражает меру воспринимаемого экспертами риска ИБ. В мае значение было таким.

Подробнее…

SilverSky покупает MSS-подразделение от StillSecure

5 июня американская SilverSky, занимающаяся облачной безопасностью, объявила о приобретении подразделения Managed Security Services от другой американской компании StillSecure. За счет этого приобретения SilverSky сможет предложить своим заказчикам теперь еще и услуги по облачному управлению логами и облачный WAF. Детали сделки не разглашаются.

Подробнее…

Malwarebytes покупает ZeroVulnerabilityLabs

20 июня Malwarebytes, известная своими решениями по борьбе с вредоносным кодом, купила небольшую калифорнийскую компанию ZeroVulnerabilityLabs, малоизвестную в России и занимающуюся исследованиями и разработками в области угроз и уязвимостей. Детали сделки не разглашаются.

Подробнее…

Управление информационными потоками: с чем его едят?

Есть у нас в 17-м и 21-м приказах ФСТЭК такая защитная мера как УПД.3 и звучит она как "Управление (фильтрация, маршрутизация, контроль соединений, однонаправленная передача и иные способы управления) информационными потоками между устройствами, сегментами информационной системы, а также между информационными системами". Для среды виртуализации есть требование аналогичное - ЗСВ.4 - "Управление (фильтрация, маршрутизация, контроль соединения, однонаправленная передача) потоками информации между компонентами виртуальной инфраструктуры, а также по периметру виртуальной инфраструктуры". Что значат эти требования? Как их реализовывать?

Одно из критических замечаний к обоим приказам ФСТЭК было именно то, что перечисленные защитные меры слишком высокоуровневые и не совсем понятно, как трактовать то или иное требование? Кстати, аналогичная высокоуровневость присуща и 382-П Банка России. Там также прописано общее требование, а механизм его реализации отдан на откуп самого участнику Национальной платежной системы. В случае с ФСТЭК на самотек ничего не пущено и сейчас готовится отдельный документ, который разъясняет, как можно реализовывать ту или иную защитную меру. Вспомните иерархию нормативных актов по защите госорганов в США. У нас, по ходу, идея такая же.

Что же понимают американцы под управлением информационными потоками (Information Flow Enforcement)? У них, ни много ни мало, а в SP800-53 21 механизм реализации этой защитной меры. Очко! Это у нас под управлением потоками часто и неправильно понимают только использование межсетевого экрана или его замены в виде списков контроля доступа на маршрутизаторах или VLAN'ов на коммутаторах. Но традиционное и слишком узкое восприятие термина "управление информационными потоками". В США это всего лишь последний, 21-й механизм - "physical/logical separation of information flows". Обратите внимание нет ни слова про межсетевые экраны, ACL, VLAN... Почему? Да потому что нельзя ограничить управление потоками только этими тремя мезанизмами. Это только в локальной сети Ethernet и на традиционном IP-периметре это сработает. А что делать в сетях хранения данных (SAN)? Там нет VLANов. Но там есть VSAN. Там есть soft/hard zoning. Там есть LUN masking. А в MPLS сетях какие механизмы управления потоками? VRF! А в виртуализированных средах? Там для управления потоками свои атрибуты безопасности, зачастую отличные от IP-адресов. В SP800-53 использование атрибутов безопасности - это самый первый механизм управления потоками. А работа с атрибутами - это вообще отдельная защитная мера, которая может быть реализована с помощью 12-ти различных механизмов. Но вернемся к управлению потоками. Что еще наши заокеанские "друзья" включили в свой "17-й приказ" (выборочно):

• Контроль использования зашифрованного трафика
• Контроль инкапсулированного трафика
• Контроль метаданных
• Однонаправленная передача (в индустриальных системах часто применяются такие межсетевые экраны, в которых на физическом уровне обеспечивается только односторонняя передача трафика. Она, кстати, упомянута в 17-м и 21-м приказах ФСТЭК)
• Использование фильтров безопасности (в качестве критериев применяется не только и не столько IP-адресация источника и получателя и не порты источника и получателя, а длина передаваемого файла, его тип или расширение, ключевые слова и т.п. Фильтры могут работать как со структурированными данными, так и с неструктурированными.
• Человеческий контроль (да-да, есть и такой механизм).
• И т.д.

У американцев информационные потоки не ограничены только сетевым уровнем - они учитывают и прикладные потоки. А это делают спектр возможных решений по реализации этого требования гораздо шире, чем просто обычные межсетевые экраны. Это же, кстати, ставит вопрос и о будущей сертификации средств управления информационными потоками. Одно дело сертифицировать межсетевые экраны по документу 97-го года и совсем другое - сертифицировать даже межсетевой экран для виртуализированной среды. А уж про средства управления потоками в сетях хранения данных на базе Fibre Channel или iSCSI или в фабриках блейдов я вообще молчу.

А ведь есть еще такое понятие как мандатное разграничение доступа на уровне сети. Разумеется, на самом деле оно называется не совсем так, но суть у него именно такая. На информационный поток вешается метка (security group tag, SGT), которая и позволяет управлять потоками в одной сетевой инфраструктуре, не давая им пересекаться, и являясь более гибкой и динамичной схемой, чем статические метки VLAN. Это управление информационными потоками? Да. Но, что тут сертифицировать? Тут нет одной железки, которая стоит на периметре? Тут вся инфраструктура осуществляет управление потоками. Физические и виртуальные коммутаторы, маршрутизаторы, точки беспроводного доступа, межсетевые экраны - все это и управляет потоками.

Кстати, идеология SGT показывает, что традиционный, периметро-ориентированный взгляд на управление потоками сегодня уже устарел. Есть периметр, на нем поставили МСЭ и вуаля - дело в шляпе. А как быть, когда у нас нет явно очерченного периметра или сегментация нужна внутри сети. Тут и помогает security group tagging, в этом случае у нас отсутствует одна точка контроля, как на периметре. А значит и подходы к оценке такого рода механизмов тоже надо менять. Причем как к оценке соответствия в форме сертификации, так и к оценке в форме аттестации. Прийти и спросить: "А где у вас тут стоит файрвол?" уже не получится.

А если пойти выше сетевого уровня и поговорить об управлении потоками в сети не физической, а виртуальной? Как реализовать меру ЗСВ.4 из 17-го и 21-го приказа? Нужны средства управление потоками в виртуализированной среде. Межсетевые экраны или виртуальные коммутаторы, которые с этой задачей справятся, но как видно из иллюстрации ниже, они не стоят на периметре. Есть варианты, когда виртуальный межсетевой экран ставится на каждый физический сервер. Есть варианты, когда виртуальный межсетевой экран просто ставится на виртуальную машину и он один контролирует трафик между другими виртуальными машинами на разных физических серверах (например, у нас так построен Cisco Virtual Security Gateway). Тут, главное, идеологию и мировозрение поменять - управление потоками может быть не только сетевым и не только на периметре.

А если посмотреть еще дальше - на SDN (программно конфигурируемые сети)? В них управление потоками и вовсем отделено от самих устройств и реализуется программно. Зачастую само прикладное приложение может управлять информационными потоками. И такой механизм тоже попадает под требования 17/21-го приказов. Вот только как их сертифицировать непонятно. По крайней мере, пока непонятно.

Вот такая картина вырисовывается только с одной из нескольких десятков защитных мер, предусмотренных новыми документами ФСТЭК. Очень глубокие документы и очень гибкие. Главное, чтобы ФСТЭК не загнала эти преимущества в жесткие рамки слишком приземленных требований и не стала требовать одинакого уровня сертификации для разного класса реализуемых механизмов управления потоками. Все-таки отдельно стоящий и выделенный под задачи безопасности межсетевой экран и функциональность сегментация виртуального коммутатора (например, Cisco Nexus 1000V) - это две большие разницы и предъявлять к ним одинаковые требования не совсем разумно. Более того, основная нагрузка смещается с отдельного устройства на уровень систем управления или отдельных контроллеров. Именно от того, что делается там зависит, как будут защищены информационные потоки. И это тоже надо будет учитывать как тем, кто будет реализовывать управление потоками, так и тем, кто будет проводить оценку соответствия или разрабатывать требования по оценке соответствия.

Подробнее…

8-й Центр ФСБ. Размышления на тему.

Незапланированный пост. Под впечатлением участия в CTCrypt в Екатеринбурге. Хорошее мероприятие, интересное. Изначально было ориентировано на общение криптографов из научной и академической среды. В этом году попытались включить еще и "общественность", т.е. понять и услышать потребности бизнеса и общества в современной криптографии. Чем может помочь регулятор и научная среда в части криптографии?.. Первый опыт. Получилось динамично, хотя и не до конца это оказался круглый стол, как было заявлено ;-) Язык не поворачивается назвать его круглым, если в президиуме в гордом одиночестве сидит Алексей Сергеевич Кузьмин (первый зам.начальника 8-го Центра), а вся остальная аудитория перед ним. Вспомнился сразу мультфильм "Маугли" и "мудрый Каа" ;-)

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

А дальше слово взял Алексей Сергеевич Кузьмин и опроверг меня по всем пунктам ;-) Обвинив меня в незнании законодательства, поверхностном знании рынка и непонимании момента, оказалось, что у нас нет ни одной из названных проблем. Все давно уже решено. И криптографию можно ввозить (правда, по непростой процедуре и с непрозрачными правилами выдачи разрешений на ввоз). И вывозить ее тоже можно (правда тоже по очень непростой процедуре). И ФСБ, оказывается, несет ответственность за взлом сертифицированной криптографии (правда, почему-то к ФСБ никто исков не хочет предъявлять). И реализовывать наши ГОСТы можно без получения лицензии ФСБ (правда, только если разработчик зарубежный и продает он такие СКЗИ также за пределами России). Как будто мы в разных мирах живем ;-)

Мне эта дискуссия живо напомнила общение с Барановым Александром Павловичем. Будучи первым замом в 8-м Центре, он высказывался точно также. Но стоило ему уйти в ФНС, как его взгляды поменялись и он достаточно активно стал критиковать Службу примерно по тем же направлениям, что я и озвучивал. Взгляд на криптографию с точки зрения потребителя отрезвляет и многие догмы уже не кажутся таковыми, когда сталкиваешься на практике с процедурой ввоза и эксплуатации СКЗИ ;-)

Вторая часть круглого стола прошла более живо и такого противостояния уже не было. Были озвучены реальные задачи, стоящие перед отраслью - высокоскоростное шифрование, обновление ГОСТ 28147-89, открытие требований к разработке СКЗИ, M2M-шифрование, криптография в АСУ ТП, телемедицине, трейдинге. Многие из них были восприняты регулятором и помечены, как актуальные. Это позитивно. Кого интересуют детали - смотрите мой Twitter (я там публиковал избранные тезисы).

А теперь немного философии. Вчера я прочитал в "Русском репортере" интересный материал "Душа фээсбэшника". Не буду особо комментировать текст - к нему можно относиться по разному. Но там показан очень интересный взгляд представителя спецслужбы на "интересы государства". Вот именно такой позиции, как мне кажется, придерживается и 8-й Центр ФСБ. Ведь с точки зрения "интересов государства" все, что делают в России иностранные ИТ-компании - это потенциальная (а местами и реальная) угроза национальной безопасности. Какие нафиг интересы гражданина и общества? Это академик Рыжов мог думать о национальной безопасности в контексте приоритета защиты прав гражданина. ФСБ думает в контексте приоритета прав государства. И с этой позиции либерализация ввоза зарубежных СКЗИ, разрешение TLS с AES в Интернет, отделение "гражданской" криптографии с отказом от ее регулирования, экспорт шифрования (как технологий двойного назначения), сертификация СКЗИ не на ГОСТе - это все угроза государству, которой нельзя дать реализоваться. Ну и что, что это замедляет прогресс. Ну и что, что это не дает гражданам реализовывать свое право на свободный доступ к информации. Ну и что, что это мешает инвестициям в российскую экономику. Ну и что, что российским предприятиям приходится платить в 5-6 раз больше за российские СКЗИ, которые по своим потребительским характеристикам хуже западных аналогов. Ну и что, что нет прозрачных правил и все решается "в частном порядке". Что с того, если на кону безопасность России! И это не пафосное заявление. Сотрудники ФСБ реально так думают.

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

Такая позиция неплоха и нехороша. Это просто позиция. С ней можно соглашаться, а можно спорить. Ее можно принимать, а можно пытаться исправить ситуацию. Лично я ее понимаю, но принять не могу. Но мое мнение регулятора не интересует (хотя я знаю, что этот блог они читают). Это позиция регулятора, который имеет вес в государстве. И имеет историю и специфический бэкграунд. И Президент нашей страны тоже из этой же структуры и думает он также. А поэтому можно сколь угодно долго и много разглагольствовать о том, что подход этот неверен и надо искать компромиссы и находить баланс между интересами государства и гражданина, но результата у этих разглагольствований не будет. Не будет пока сам регулятор этого не захочет. А он этого не хочет. И не видит смысла. И считает свою позицию непоколебимой.

Справедливости ради надо отметить, что ситуация постепенно сдвигается с мертвой точки. Если раньше регулятор был в глухой обороне и напрочь закрыт от комментариев и высказывания своей позиции по тем или иным вопросам, то сейчас стало чуть лучше. Регулятор уже готов слушать. Не факт, что прислушиваться, но как минимум слушать. А это уже первый шаг в сторону нахождения компромисса. Регулятор слушал и даже отвечал на РусКрипто. Регулятор слушал и отвечал на конференции АЗИ. Регулятор слушал и отвечал на CTCrypt. И это только за это год. Значит и ФСБ может меняться, когда видит, что в этом есть необходимость. Но очень уж медленно. Остается только ждать и верить...

Подробнее…

Почему я не завидую ФСТЭК: аттестация облачного оператора ГИС

Про 17-й приказ ФСТЭК пока мало кто пишет, привыкая пока к 21-му приказу того же регулятора. Я же хочу сразу погрузиться в глубины 17-го приказа и рассмотреть одну тему, которая всплывет у многих государственных и муниципальных органов, которых силком загоняют в облака Ростелекома. Но пока начну с прелюдии.

В 13-м пункте приказа №17 перечислены следующие защитные мероприятия:

• формирование требований
• разработка системы защиты
• внедрение системы защиты
• аттестация информационной системы
• обеспечение защиты в ходе эксплуатации
• обеспечение защиты при выводе из эксплуатации.

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

Начнем с формирования требований по защите. Логично предположить, что делает это обладатель информации, т.е. государственный или муниципальных орган. Ну а кто еще может за обладателя информации решить, какие требования по защиты должны быть реализованы? Отраслевое министерство? ФСТЭК? ФСБ? Могут. По 17-му приказу они этого делать не могут, но я думаю это не является большим препятствием. Заказчик (потребитель) ГИС просто принимает спущенные сверху требования. При формировании требований обладатель информации должен учесть:

• состав и класс защищаемой информации
• классификацию информационной системы
• актуальные угрозы.

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

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

Кто организует внедрение системы защиты? Опять обладатель информации, т.е. заказчик. Но кто ж его пустит на облачную инфраструктуру, за которую отвечает провайдер? Правда,  в п.16 написано, что к внедрению привлекается оператор ИС, в случае если он определен таковым в соответствии с законодательством РФ. А что значит определен? Кем определен? А если не определен?

Аттестацию у нас проводит или заказчик или оператор ГИС. Тут все как бы и просто, а как бы и нет. Давайте обратимся к новоиспеченному ГОСТу РО 0043-003-2012 по аттестации. В нем говорится, что заявителем аттестации может быть только владелец аттестуемого объекта информатизации. А кто является владельцем в ситуации, когда защищаемая информация находится у одного лица (госоргана), облачная инфраструктура принадлежит другому лицу, а приложения, обрабатывающие защищаемую информацию, вообще третьему? С точки зрения здравого смысла, владельцем должен быть тот, кому принадлежит информация - ведь только он знает ее ценность и может принимать решение об аттестации. Но на практике все наоборот - аттестацию затевают владельцы ЦОДов, которые сдают их потом в аренду различным заказчикам. А т.к. аттестовать "по максимуму" невыгодно (затраты могут и не окупиться), то большинство облачных/аутсорсинговых провайдеров аттестуют "в среднем по больнице", тем самым ставя в неловкое положение своих заказчиков, которым может либо не хватить уровня аттестации, либо наоборот - часть мероприятий будет излишней.

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

Идем дальше. Обеспечение защиты в ходе эксплуатации ГИС осуществляет... нет, не заказчик ГИС, а ее оператор. Вроде бы в облачной среде логично, но... Известно, что в облачных вычислениях роль заказчика в контексте ИБ смещается от, собственно, самой защиты в сторону ее контроля. Т.е. на обладателя информации возлагается задача контроля (мониторинга) за обеспечением уровня защищенности информации, содержащейся в информационной системе. Но по 17-му приказу все мероприятия по обеспечению защиты ложатся на плечи только одного лица - оператора ГИС. Он же, кстати, заводит и удаляет учетные записи пользователей в ГИС. А какже Federated Identity? Вот как, например, схематично это работает у нас в Cisco. Управление учетными записями осуществляем мы, а не только облачный провайдер. И как быть, если у нас заработает Единая система идентификации и аутентификации в инфраструктуре, обеспечивающей информационно-технологическое взаимодействие информационных систем, используемых для предоставления государственных и муниципальных услуг в электронной форме?

Что у нас получается? А то, что приказ 17-й сложно реализуем (а иногда и вовсем нереализуем) в случае перехода к хранению информации в облачных информационных системах, которые достаточно активно применяются в государственных органах в последнее время.

Справделивости ради, надо признать, что при разработке 17-го приказа тема обработки информации госорганов в облаках всплывала. И ее даже пытались каким-то образом решить, но в итоге было принято решение, что надо есть слона по частям. Сначала решить первую задачу - запустив приказ в том виде, в котором мы его получили, - ориентированном на защиту обладателями информации собственных информационных систем. Следующим шагом должна стать адаптация 17-го приказа, а может быть и выработка нового, под облачную специфику. Когда это будет, сложно сказать. Могу только отметить, что разработка ГОСТа по защите облачных вычислений запланирована в ТК362 в 2013-2014-м годах. А пока остается только ждать, когда наши регуляторы станут учитывать те технологии, которые активно продвигаются (навязываются) Минкомсвязью и Правительством.

Подробнее…

Безопасность облаков. Просто? А вот фиг!

Все как сговорились и все пишут и пишут про безопасность облаков, про то, как это легко сделать на той-то или иной платформе. Правда, рассматривают этот вопрос почему-то с точки зрения облачного провайдера и только с технологической точки зрения. Обычно все приводят примерно такую схему и начинают ее обсуждать. А вот в IaaS можно сделать так и активно задействовать механизмы защиты на уровне виртуализации. А вот в PaaS мы можем на приложения возложить механизмы защиты. Ну и т.д.

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

 

И вопрос в этом случаев звучит уже не только "как защитить инфраструктуру облачного провайдера?", но и "как безопасным образом работать с инфраструктурой облачного провайдера?". А по статистике (не помню чьей) до 90% предприятий передают в облаков свои данные вообще без защиты. И какой тогда смысл в защите облака, если на подступах к нему все передается в открытом виде?

Но допустим мы решили и эту проблему и включили между облаком и потребителем облачных услуг функция шифрования. И вот тут нам подлянку подкидывает визуализация. Как обычно мы изображем облако? Правильно, как облако ;-) И мы забываем, что на самом деле это может 2, 5, 10, 20 площадок, разбросанных по России или по миру. И правильная реализация подключения к облаку подразумевает адаптивный и динамический выбор "ближайшего" облачного шлюза. Ближайшего по критериям времени отклика, загруженности и другим параметрам. Ограничить подключение потребителя определенным шлюзом неразумно; сразу теряется смысл половина смысла перехода к модели облачных вычислений.

И вот тут вступает в силу российское законодательство, которое в ряде случаев обязывает нас применять только сертифицированные средства защиты, включая и криптографические. А сертифицировать можно только то, что реализует наши ГОСТы. И вот тут всплывает то, на что обычно большинство облачных провайдеров в России пока забивает болт. Чтобы облачная схема на отечественной криптографии заработала в полный рост, каждую площадку надо оснастить отечественной СКЗИ с ее "удобными" механизмами управления ключами, не всегда присутствующей интеграцией с PKI, без отзыва сертификатов и т.п. А чтобы оснастить кажду площадку, ее надо вывезти за пределы России и ввезти в пределы той страны, где расположен ЦОД облачного провайдера. Задача не из легких. А еще и на мобильных клиентах (включая iPad, iPhone, BlackBerry, Android) поставить сертифицированную криптографию.

Но это тоже не все. В Cisco есть такая штука, которая называется Cisco Cloud Risk Assessment Framework. Вот ее фрагмент, включающий 10 ключевых областей, которые мы изучаем, прежде чем принять решение о переходе на облачные вычисления. К слову сказать, Cisco использует свыше 400 облачных и аутсорсинговых провайдеров по всему миру и поэтому для нас защита при переходе на облака - это не просто маркетинг, а реальная и ежедневная бизнес-задача.

Итак Cisco Cloud Risk Assessment Framework. Обратите внимание, что безопасность инфраструктуры, о которой в-основном только и говорят - это всего один из вопросов. И находится он далеко не на первом месте. Давайте обратимся к третьему домену - регулятивному. Это то, что касается облачных провайдеров во всем мире, но имеет особую специфику в России. В частности, вспомним позицию ФСТЭК по лицензированию деятельности по ТЗКИ. Что она означает? А то, что облачному провайдеру нужна (по мнению регулятора) лицензия ФСТЭК на ТЗКИ. Да и лицензия ФСБ по ПП-313 тоже не помешает. А они есть? Увы. Является ли это проблемой для потребителя? Нет?! А может да? Но пойдем дальше.

Посмотрим на пресловутый ФЗ-152. Персональные данные... Тема, ставшая притчей воязыцех, но по-прежнему актуальная. Но не в контексте 21-го приказа. С ним-то как раз все ясно. А что у нас с выполнением статей 6 и 9 закона, предусматривающих наличие согласия на обработку персональных данных. Ну, допустим, мы можем получить согласие не только у корпоративного потребителя, но и у частного (хотят тут и есть сложности с электронной формой согласия). Но что делать с трансграничной передачей в страны, необеспечивающие адекватную защиту прав субъектов ПДн? Например, США не относятся к адекватным странам. И как быть, если у облачного провайдера площадка в США (например, у Amazon)? Статья 12 подразумевает получение письменного согласия. А облачный SaaS-провайдер, который может сам арендовать мощности у провайдеров IaaS или PaaS, знает, в каких странах находятся площадки, где будут храниться и обрабатываться ПДн? А если знает, то берет ли он согласие на трансграничку во все эти страны? С каждого субъекта? А облачный провайдер - это одно юрлицо или множество (в каждой стране свое)? А не имеют ли доступ к ПДн третьи лица, обслуживающие инфраструктуру ЦОДа? А согласие на передачу ПДн этим третьим лицам есть?

А ведь есть еще 351-й Указ Президента. Депутат Железняк 19-го июня предложил законодательно запретить хранить за границей персональные данные россиян и информацию госорганов. Фиг с ними с персданными. Ну не смогут патриоты Госдумы пользоваться Visa и MasterCard и летать к своим детям и недвижимости заграницу (SABRE-то хранит все не в России). Ну и ладно! А вот идея с запретом хранения данных госорганов за рубежом могла бы быть новацией, если бы не 351-й Указ Президента, датированный 2008-м годом и не определяющий того же. Его, правда, писали люди грамотные. Они ничего не запрещали, а регламентировали обработку информации госорганов в Интернет, в т.ч. и за пределами РФ. И одним из условий такой обработки было использование сертифицированных средств защиты информации. В случае с облаками их надо использовать везде, где могут оказаться данные органов государственной власти РФ. А оказаться они могут везде. Достаточно вспомнить, как могут перемещаться виртуальные машины между физическими серверами и даже отдельными площадками в рамках облачной инфраструктуры (вы, кстати, не задумывались - а информация при перемещении внутри облака шифруется?).

А ведь еще и вопрос аттестации может возникнуть, если провайдер планирует обрабатывать данные из государственных или муниципальных информационных систем. По 17-му приказу ФСТЭК аттестация должна быть проведена обязательна. А как ее провести аттестационной лаборатории, если данные хранятся не у обладателя информации, а у облачного провайдера? А если у него несколько площадок и есть зарубежные, то ситуация становится вообще патовой. Это, кстати, причина, почему Банк России не очень любит облака в банковской деятельности. Дело даже не в том, что остается открытым вопрос передачи банковской тайны организации, которая не имеет права с ней работать. Дело в другом - банковский надзор любит "руками щупать" то, что проверяет. А что он может пощупать в облаке, принадлещаем не проверяемому банку? Ничего. И выводы по результатам проверок он может сделать не те, на которые рассчитывают апологеты облаков. Тут, кстати, совет - пишите письма в ЦБ, чтобы финансовый регулятор сформулировал свою позицию по облакам в банковской деятельности.

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

ЗЫ. Сейчас запущен ряд инициатив по адаптации российского законодательства к облачным вычислениям. ФСТЭК также готовит ГОСТ по безопасности облаков. А вот у ФСБ пока никаких изменений - они стабильно требуют лицензирования и сертифицированной криптографии.

Подробнее…

Ах, обмануть меня не трудно, я сам обманываться рад...

Вчера вокруг "нашей" темы свершилось два события. Первое - очередная волна вокруг PRISM, вызванная заседанием в Совете Федерации. В Twitter'е я вел почти прямой репортаж и могу сказать, что заявления многих персонажей были предсказуемы заранее ;-) Не это стало поводом для написания заметки. И не поездка в Совбез, где обсуждался еще один интересный документ ;-) Речь пойдет об РЖД. Но не в контексте персональных данных... И даже не совсем про РЖД...

Как написали РИА Новости: "Информацию о якобы имевшей место отставке президента РЖД Владимира Якунина, разосланную в среду вечером неизвестными лицами от имени правительственной пресс-службы, распространили все российские информагентства и другие крупнейшие СМИ, включая основные ТВ-каналы". В заметке РИА дан разбор полетов, а я хотел бы вспомнить свою апрельскую заметку про атаки третьего поколения. Она была написана аккурат после ложного сообщения в Twitter'е Associated Press о взрывах в Белом Доме и ранении Барака Обамы. А ведь ни фальшивое сообщение от имени Правительства, ни твит от AP, не были сюрпризом для специалистов по ИБ. Я про это писал еще в 2000-м году. И российские госорганы с этим уже тоже сталкивались. Вот два (первый и второй) примеры с Федеральной службой судебных приставов. А вот пример с Арбитражным судом.

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

Лаборатория Касперского в прошлом декабре давала советы, как бороться с такой проблемой. Но эти советы неприменимы в случаях, похожих на "якунинский". Он не имел никаких ссылок, он повторял пресс-релизы, которые Правительство действительно регулярно рассылает. А вот разумный совет "перепроверить" в случае с такого рода информационными поводами не работает. Каждое СМИ хочет быть первым - тут не до проверки - успеть бы опубликовать раньше других. Отсюда и все проблемы. Вчера на программном комитете грядущей InfoSecurity Moscow Рустем Хайретдинов как раз поднял тему, что есть множество бизнес-сценариев, когда безопасность просто лишняя, т.к. работает очень медленно. Например, при финансовых транзакциях, производимых с частотой в милисекунды. Никакая проверка ЭЦП не работает с такой скоростью; особенно с привлечением третьей доверенной стороны. И в ряде сценариев работы индустриальных объектов тоже безопасность не работает ;-( Хотя в данной ситуации проблема была бы решена, внедрив Правительство на своих почтовых серверах технологию DKIM или SPF. Если 8-й Центр ФСБ (а по идее именно он отвечает у нас за информационную безопасность Правительства) не в состоянии настроить почтовый сервер, то может быть стоило приобрести отдельные средства защиты входящей и исходящей электронной почты. Их немало на рынке представлено. Но это лирика. Заметка не об этом. Она о доверии ;-) Да-да, именно о доверии к тому, что написано в Интернет.

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

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

А вообще это философский вопрос ;-) Доверять или нет, хранить или нет? Но в случае с электронной почтой стоит хотя бы просто настроить почтовые сервера, чтобы исключить в будущем такие подставы.

ЗЫ. А вообще число таких атак будет возрастать. Стоит готовиться...

Подробнее…

Обновление программы курса по оценке эффективности ИБ

Обновил программу курса по оценке эффективности ИБ. В текущей версии 1.6 добавлены следующие темы:

• Процесс измерения эффективности ИБ по NIST SP800-55
• Связь ИТ/ИБ-задач с целями бизнеса по COBIT
• Метод оценки (сравнения) двух и более средств защиты информации
• Метрики оценки средств аудита ИБ
• 6 причин защиты информации
• Оценка возможностей, которые дает ИБ
• Связь курсовой стоимости акций с инцидентами ИБ
• Финансовые методы оценки ИТ/ИБ (TVO, TEI, REJ, EVA, EVS, CI, IE, AIE)
• Конкретные примеры оценки эффективности проектов/продуктов по ИБ (удаленный защищенный доступ, рост продуктивности, контроль доступа к внутренним ресурсам, антиспам, контроль доступа в Интернет, Managed VPN, Managed VPN на сертифицированной криптографии и т.п.)
• Специализированные решения по оценке эффективности ИБ
• Примеры визуализации метрик ИБ
• Стандарты и инициативы по измерениям ИБ.

Подробнее…

Повышение осведомленности по вопросам SDLC: один из примеров

Про SDLC я писал неоднократно. И про повышение осведомленности тоже. И вот решил совместить ;-) Выложу несколько наших плакатов, которые направлены на формирование у разработчиков правильных мыслей о безопасном ПО.

Подробнее…

Бизнес-модели в деятельности безопасников

На казанском IT & Security Forum читал вот такую презентацию. Она продолжила тему альтернативного курса по ИБ, которую я начал в своей утренней презентации и которую выложил вчера.

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

Бизнес-модели в деятельности безопасника from Alexey Lukatsky

Наверное, в будущем разовью эту тему и дополню ее новыми примерами применения бизнес-моделей в деятельности безопасника.

Подробнее…

Очередной законопроект по персданным

В пятницу, когда прогрессивное человечество находилось в Казани на IT & Security Forum, депутаты, одновременно с рассмотрением вопроса о запрете орального секса в России, приняли во втором чтении законопроект № 47538-6 "О внесении изменений в подраздел 3 раздела I части первой Гражданского кодекса Российской Федерации".

Идея у законопроекта красивая - обновить и привести в соответствие с реалиями Гражданский Кодекс. С этой целью и была затеяна еще при Медведеве эта эпопея и вот ее продолжение. Вносили его в апреле прошлого года и никаких относящихся к нам тем, в законопроекте не было. Но вот в начале июне ряд малоизвестных депутатов решили тоже поиграть на теме персональных данных и дополнить статью 152 Гражданского кодекса, которая нам больше известна по сценариям обработки изображения лица, новым содержанием. А точнее статьей 152.2 "Охрана частной жизни гражданина". Очень своебразная норма.

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

А вот следующий абзац вполне себе интересен. Звучит он так. "Неправомерным распространением полученной с нарушением закона информации о частной жизни гражданина считается, в частности, ее использование при создании произведений науки, литературы и искусства, если такое использование нарушает интересы гражданина." Т.е. написать эпос о субъекте ПДн без его согласия нельзя. И даже небольшое эссе или фельетон тоже.

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

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

Но главный вопрос в другом. Почему нельзя было внести эти нормы в ФЗ-152, а создавать отдельную статью 152.2 в ГК?

ЗЫ. Планируется, что вступить в силу данный законопроект должен с 1 октября этого года.

Подробнее…

Кто такой новый ИБшник?!..

Тема некачественного обучения по вопросам ИБ поднималась уже неоднократно; и у меня в блоге и на различных мероприятиях. Искать и изучать причины сейчас бессмысленно - лучше подумать над тем, как ситуацию изменить. Как сделать так, чтобы выпускники ВУЗов получали востребованные на практике знания, а не устаревшие и теоретические сведения, которые скорее мешают, чем помогают при выборе своего пути и своей профессии. Повлиять на Министерство образования я не могу. Да и не горю желанием погружаться в эту клоаку подковерных игр и конфликтов интересов. Но могу попробовать сформировать свое видение тех тем, которые должен знать и понимать любой безопасник. Независимо от того, кем и где он будет работать дальше. Став администратором ИБ, аудитором, руководителем службы ИБ, служащим ФСТЭК, разработчиком средств защиты, сотрудником ЦИБ ФСБ или БСТМ МВД, выпускник должен иметь общие представления о разных направлениях ИБ. А дальше выпускник может уже либо продолжить обучение по выбранному направлению (если найдет, где), либо заняться самообразованием.

На прошедшем казанском IT & Security Forum я делал презентацию, посвященную краткому описанию того, как у нас должно строиться высшее образование по ИБ, как оно строится, и чего точно не хватает в тех ФГОСах, которые утверждены Министерством образования и которые должны стать основой для любой из существующих специализаций. Сейчас настало время чуть расширить эту презентацию за счет дополнительных размышлений.

Альтернативный курс по информационной безопасности from Alexey Lukatsky

Итак, вспоминая Лукьяненковские "Дозоры", всю образовательную программу в части спецдисциплин я бы разбил на 4 больших блока:

1. Светлая сторона, т.е. то, чем мы и занимается - защитой информации.
2. Темная сторона, т.е. рассказ об угрозах, нарушителях, их мотивации и бизнес-моделях. При этом данная тема требует ежегодного пересмотра и выдачи новых материалов для студентов. Да и в рамках повышения квалификации ввиду динамичности этой темы надо ее обновлять постоянно.
3. Инквизиция. В этом блоке студентам нужно давать тематику, связанную с надзором в области ИБ, правоприменительную практику, криминологию и расследование инцидентов, вопросы лицензирования деятельности и т.п.
4. Технологии, которые мы защищаем. ИБ обычно имеет непосредственное отношение к ИТ и поэтому необходимо иметь представление как о существующих, так и перспективных технологиях, которые могут повлиять на ИБ или возникающие риски. Как и в случае с угрозами, необходимо регулярно пересматривать данный раздел курса ввиду непрерывной изменчивости технологий.

По сути, предлагаемый мной список - это прообраз ФГОС в части спецпредметов (исключая общие дисциплины). Хотя этот список может быть использован и в менее глобальной и более приземленной задаче - повышении квалификации по темам, которые выпали из предыдущего опыта и образования.

Практика... В ФГОСах она прописана. Точнее говорится, что она должна быть. В какой форме - стандарты умалчивают, отдав это на откуп ВУЗам. А те, кто во что горазд. Мне кажется, что правильнее было бы развивать движение CTF. Это прикольно, это интересно, это свежо. Никаких лаб в душных помещениях на устаревшем оборудовании, которое и в реальности-то уже не использует. Вон и ФСБ на последнем PHDays III поддержало идею CTF (мало кто оценил это выступление Оксаны из ЦИБ ФСБ, но оно само по себе является небольшой революцией в доселе закрытой конторе, которая не любит высказывать позицию по таким вопросам).

Кто должен двигать тему "альтернативного" курса по ИБ, а точнее включение описанных в презентации тем в ФГОСы? Вариантов я вижу несколько.

• Сам Минобраз. Маловероятный сценарий, т.к. адекватных людей, способных и желающих продвигать и продвинуть эту тему ни в нем, ни в УМО по ИБ я не видел. Именно способных и желающих. Первых много. Вторых гораздо меньше. А вот сочетание двух качеств также редко, как и редкоземельные элементы. Может просто не очень везло или в образовании у нас такая жопа, что любые начинания там рубятся на корню и тонут как в болоте. Примерная ситуация у наших законодателей. Казалось бы, есть умный, инициативный человек. Болеет за дело. А попадает в ГД и все, превращается в полного зомби ;-(
• ВУЗы. Это более вероятный вариант, чем предыдущий. Хотя в условиях, когда над ВУЗами Дамокловым мечом висит вероятность их сокращения ввиду неэффективности, высовываться никто не будет. Кто-то пытается вводить у себя факультативы, но на такую самодеятельность тоже есть ограничения. Выше ФГОСа сильно не прыгнешь.А там еще и преподаватель должен подхватить этот флаг... И опыт у него должен быть. И время заниматься новой темой.
• Бизнес. Тоже вероятный... в будущем вариант. Надеюсь, что со временем бизнес будет не только брать выпускников и переучивать их, но и более активно устанавливать требования к выпускникам и участвовать в формировании программ обучения, в которых Минобраз будет заинтересован.
• Минкомсвязь. Это министерство озвучило, что к 2018-му году число ИТ-специалистов должно быть увеличено вдвое. Думаю не в последнюю очередь и за счет безопасников, которых начинать готовить по новому надо уже сейчас. Смогут ли наладить два министерства диалог?
• ФСТЭК. Это темная лошадка на старте. С одной стороны, кто как не основной регулятор может и должен заниматься подготовкой достойной смены? С другой - до недавнего времени ФСТЭК была очень консервативной "теткой за 50", самоустранившейся от развития отрасли в глобальном масштабе. Но с конца 2012-го начались изменения во ФСТЭК и возможно она вновь превратится в серьезную методологическую базу для отрасли и сможет продвинуть и образовательную тему. В конце концов программы ФГОС согласовываются с же регуляторами. Почему и не вставить свое веское слово?
• ФСБ? Именно со знаком вопроса. Не знаю, не уверен. 8-ка, по сути, узурпировала тему ИБ и ввела на нее монополию. Так было раньше, так остается и сейчас. Но узурпация при полном отсутствии какого-то поступательного движения вперед ;-( Да и вся Контора достаточно консервативна и закрыта, чтобы надеяться на то, что она поднимет тему образования на свое древко. Достаточно вспомнить эпопею с ПП-313 в контексте требований по квалификации, когда даже не предусмотрев переходного периода, ФСБ начала кошмарить бизнес, требуя от него подтверждения 500-сотчасового обучения при полном отсутствии на тот момент учебных центров с согласованными программами.
• Сами абитуриенты. Неплохо бы, но тоже маловероятно. Абитуриент просто не знает, что ему понадобится в будущем. А когда он понимает, что обучают его "старперы", а не "стартаперы", бывает либо поздно, либо поменять ничего нельзя. Хотя ФГОСы и подразумевают возможность выбора студентами предметов для изучения. Но тут и ВУЗ должен иметь возможность дать требуемое студенту. А если он не можать дать?..

Какой-то длинный пост получился. Видимо, наболело... Если вдруг сейчас еще не поздно и в планируемые к 1 сентября новые ФГОСы (уже четвертого поколения) можно внести изменения, то пусть кто-нибудь причастный внесет их...

Подробнее…

Какую тему выбрать для диплома по ИБ?

Нашел тут старую презентацию 2010-го года, которую я читал на заседании УМО вузов по информационной безопасности. Она рассказывает о ключевых направлениях развития исследований в области ИБ в России и в США. Так как нередко мне задают вопрос или я вижу на тематических форумах вопросы: "Какую тему выбрать для диплома по ИБ?", то вот вам на выбор ;-)

Будущие исследования ИБ from Alexey Lukatsky

Подробнее…

Почему мы никак не дождемся от 8-го Центра ФСБ моделей угроз ПДн?

Давайте взглянем на ст.19 ФЗ-152 в разрезе определения угроз безопасности персональных данных. В соответствие с п.1 ч.2 ст.19, это то, с чем начинается процесс обеспечения безопасности ПДн. Кто может определять такие угрозы? В соответствие с частью 5 той же статьи 19 могут это делать только:

• Федеральные органы исполнительной власти, осуществляющие функции по выработке государственной политики и нормативно-правовому регулированию в установленной сфере деятельности,
• Органы государственной власти субъектов Российской Федерации,
• Банк России,
• Органы государственных внебюджетных фондов,
• Иные государственные органы в пределах своих полномочий,

согласовав полученные модели угроз с ФСТЭК или ФСБ в удобной для всех сторон форме, как это и указано в части 7 статьи 19. Указанные модели угроз в соответствие с частью 6 статьи 19 могут быть расширены ассоциациями, союзами и иными объединениями операторов ПДн. Если такое желание у кого-то возникнет (пока таких прецедентов я не встречал), то получившаяся расширенная модель должна быть также согласована с ФСТЭК и ФСБ в соответствии с частью 7 статьи 19 в порядке, установленным 940-м Постановлением Правительства.

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

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

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

А есть и третий сценарий. Если внимательно посмотреть на часть 5 статьи 19, то федеральным органом исполнительной власти, осуществляющим функции по выработке государственной политики и нормативно-правовому регулированию в рассматриваемой области, является... Федеральная служба безопасности. Ведь именно в ее епархии находится сфера деятельности под названием "защита персональных данных". Почему бы не запросить у достопочтенного регулятора, который так много усилий приложил для роста уровня защищенности ПДн в России и несмотря на все предложения экспертов, так и не поменял ни статью 19, ни Постановление Правительства №1119, разработанную ими модель угроз?..

Подробнее…

8 типов шифровальных средств, существующих в России!

Продолжу тему ликбеза по криптографии с точки зрения нормативного регулирования. Почти 4 года назад в рамках написания книги "Мифы и заблуждения информационной безопасности" я опубликовал миф №50 "В нашем шифраторе мы используем ГОСТ 28147-89 и поэтому чисты перед законом". Но до сих пор бытует мнение, что если взять и реализовать ГОСТ, то это решит все проблемы с легальностью применения шифровального средства. Ни фига! Важно учитывать, кто и где реализует этот ГОСТ по криптографии.

Вот почему, как вы думаете, западные разработчики средств защиты еще не сделали встроенную поддержку ГОСТа в своих продуктах? Это что сложно? Нет. Это требует офигенной квалификации? Нет. Алгоритм засекречен? Нет. Тогда почему? А зачем?! Что даст такая реализация? Она облегчит ввоз продукта? Нет! Она облегчит сертификацию? Нет. Она облегчит применение? Нет. Ведь ни в одном нормативном документе не сказано, что шифровальное средство должно реализовывать ГОСТ 28147-89. Говорится о сертифицированных и несертифицированных СКЗИ. А почему включение ГОСТа не облегчит сертификацию? А потому, что в соответствие с российским законодательством заниматься разработкой шифровальных средств у нас может только российская компания на территории Россиийской Федерации.

Но наличие российского юридического лица также не делает разработанную в России криптографию легитимной. Существует немало примеров, когда отечественный разработчик средств защиты реализует западные криптоалгоритмы. Или реализует ГОСТ, но не имеет лицензии ФСБ на разработку СКЗИ. Или имеет лицензию, но не имеет сертификата ФСБ на готовое изделие.

Чтобы разобраться в этих хитросплетениях я и начертил вот такой куб. Он позволяет быстро понять, что в России явно разрешено и хорошо описано только применение сертифированной криптографии на ГОСТе (а иначе ее не сертифицируют), разработанной российской компанией (а иначе ей не разрешат разрабатывать СКЗИ и в итоге его не сертифицируют). 

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

Собственно, в очередной раз хочу отметить, что я не против сертификации, как формы оценки соответствия, как таковой. Она важна и нужна, но... не так, как это сделано в России. ФСТЭК потихоньку начинает выруливать в правильном направлении, приводят свои систему сертификации в соответствие с реалиями жизни. И только 8-й Центр с ЦЛСЗ живут в прошлом веке ;-( 3 года назад я написал пост, кратко перечисляющий сценарии, когда сертифицированных СКЗИ нет. И что поменялось с того момента в позиции регулятора? Ничего. Все решается "в частном порядке". А вот технологии, в которых используется криптография, продвинулись вперед и некоторые даже дошли до России. Например, высокоскоростное шифрование. 3 года назад я писал про необходимость шифрования на скоростях в 40 Гбит/сек. А уже спустя два года (прошлым летом) Баранов Александр Павлович, работающий сейчас в ФНС, а до этого практически возглавлявший 8-й Центр ФСБ, заявил, что ФНС ищет решение на 100 Гбит/сек! А их нет ;-( А еще в России начинает активно развиваться направление M2M, для которого также отсутствует сертифицированная криптография. Если, конечно, не вспоминать ситуацию с тахографами ;-) А еще... Да таких "еще" может очень много.

Мне кажется давно пора признать, что регулятор в области шифрования (даже при  Президенте с его прошлым) не справляется и уже не справится с сертификацией такого количества устройств и приложений, использующих шифрование. Давно пора четко разделить всю криптографию на гражданскую и стратегически важную для национальной безопасности и регулировать именно последнюю, как и делается во всем мире. Если уж так хочется держать руку на пульсе, то контролировать можно на уровне выдачи разрешений на ввоз (как изначально и задумывалось). И эти однократно выдаваемые разрешения надо приравнять к разрешению на применение и вывести из под лицензирования деятельности по ПП-313. И тогда уже сложившаяся практика примет юридически значимые очертания. И все наконец-то скажут, что регулятор действительно действует на принципах законности, уважения и соблюдения прав и свобод человека и гражданина, как это и записано в ст.5 ФЗ-40 от 3 апреля 1995 года "О федеральной службе безопасности"

ЗЫ. А еще мы на прошлой неделе замутили ролик про то, что современному миру не хватает современной криптографии ;-)

Подробнее…

4 ветви регулирования криптографии в России

Про регулирование криптографии я уже писал неоднократно. И специализированные семинары проводились тоже неоднократно. И в рамках других выступлений и курсов я про это тоже говорил неоднократно. А вопросы всплывают постоянно. Долгие годы. И все без официального ответа. Складывается такое впечатление, что 8-му Центру ФСБ и ЦЛСЗ выгодна такая ситуация и они делают все, чтобы у потребителей и дальше была полная сумятица в голове относительно того, что можно, а что нельзя в области криптографии. ФСТЭК по сравнению с ними - овечка. Попробую еще раз сформулировать ключевые положения законодательства по криптографии.

Начну с того, что существует 4 разных ветви регулироания криптографии. ЧЕТЫРЕ! Ввоз СКЗИ на территорию России, их применение, деятельность с использованием СКЗИ и их вывоз за пределы РФ. Любая организация, которая хочет защищать какую-либо информацию с помощью шифровальных средств попадает под эти ветви законодательства. Может быть не под все сразу, но под две минимум (применение и деятельность), а при наличии трансграничного обмена еще и под оставшиеся две.

И касаются эти ветви регулирования не только западной криптографии, но и отечественной; сертифицированной и несертифицированной; применяемой в госорганах и на коммерческих предприятиях; на ГОСТе и без него.

Допустим, вы хотите вы хотите применить VPN-модуль Cisco + С-Терра. Ввозить его не надо, т.к. продукт разработан в России, - эта ветвь регулирования минует вас. Вопрос с его применением тоже решается без проблем, т.к. модуль имеет сертификат ФСБ. Но вот дальше возникает вопрос. А для чего я буду применять этот модуль? Какие виды работ мне понадобится оказывать с его помощью? Не являются ли данные виды работ лицензируемыми? А есть ли у меня лицензия ФСБ, выданная в соответствие с ПП-313, на указанные виды работ? Т.е. я и мог бы применять модуль NME-RVPN (как продукт), но как у организации у меня может и не быть такого права. Например, по причине отсутствия у вас специалистов с подтвержденной квалификацией. Для ФСБ это является основанием для отказа в выдаче лицензии. А деятельность без лицензии по мнению регулятора - это уголовное преступление, наказуемое по статье 171 УК РФ (и такие прецеденты есть).

Теперь возьмем к примеру маршрутизатор Cisco ISR 881 с функцией VPN. Продукт не имеет сертификата ФСБ и изготовляется за пределами России. Но при этом часто используется для защиты различных платежных терминалов и банкоматов. Что нам говорит законодательство по этому поводу? Можно ли его применять? Да. В том же 382-П Банка России ограничений для этого нет. А можно ли его ввезти на территорию РФ? Да, по облегченной схеме, т.к. на данный продукт (с кодом PCI в part number) выдана нотификация (что такое нотификация смотрите тут). Но вопросы с лицензированием деятельности остаются.

Теперь возьмем какой-нибудь западный VPN-продукт, на который устанавливается сертифицированная криптография в России. Напомню, что если просто так взять и поставить что-то сертифицированное, это еще не делает получившийся продукт легальным в России. Но допустим вопрос с установкой на западный VPN решен и мы можем применять получившийся симбиоз в России для каких-то криптографических задач. И допустим у нас даже есть лицензия ФСБ. Но вопрос с ввозом остался. Но как же? Мы же не используем иностранную криптографию и навешиваем отечественную. Но иностранная-то криптография в ввозимом продукте же осталась - ее никто не убирал, а следовательно ввозимый продукт по-прежнему попадает под регулирование ввоза шифровальных средств. И тут надо либо исключать из продукта шифрование вовсе (например, Cisco даже специально сделала специальную версию IOS-NPE для данной задачи), либо пытаться попасть под исключения, благодаря которым можно попробовать получить нотификацию (т.е. право на облегченную процедуру ввоза) на ввозимое шифровальное средство.

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

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

Что в сухом остатке. А все просто. Вы можете применять, но можете не иметь возможности ввезти. Вы можете ввезти, но можете не иметь возможности применить. Вы можете и ввезти и применить, но не можете вообще заниматься деятельностью, связанной с криптографией. И таких комбинаций из 4-х элементов получается много. И никто и нигде не разъясняет этих хитросплетений российского законодательства ;-( Через наши семинары по этой тематике прошло, уже наверное, около трех-четырех тысяч человек. А вопросы все задают и задают. У основного же регулятора по этой теме ответ один - "Будем решать все в частном порядке" ;-(

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

Чтобы стоило бы сделать на мой взгляд?

1. Уменьшить число видов работ, требующих лицензирования, и сделать оставшийся перечень более конкретным и прозрачным.
2. Разработать и узаконить процедуру "ввоза" средств шифрования путем скачивания через Интернет.
3. Совместить процедуры получения разрешения на ввоз с получением разрешения на применение СКЗИ (из одного должно автоматически вытекать второе).
4. Уменьшить число случаев, когда решение о том, какие СКЗИ можно использовать для защиты информации, обладателем которой является не государство, принимает ФСБ, а не сам обладатель.
5. Облегчить процедуру вывоза СКЗИ и сделать ее более прозрачной.

Подробнее…