13.08.14

Тенденции законодательства по ИБ. Презентация с семинара RISC

Моя презентация с мастер-класса для RISC по тенденциям российского законодательства в области ИБ. Запись будет выложена на сайте RISC.

12.08.14

IBM покупает Lighthouse Security Group и CrossIdeas

Вчера, 11 августа компания IBM объявила о приобретении провайдера услуг IAM облачной безопасности - Lighthouse Security Group. Детали сделки не разглашаются.

Неделей ранее, 31-го июля, IBM приобрела другую компанию на рынке ИБ - CrossIdeas, которая является разработчиком ПО для обеспечения доступа пользователей к корпоративным и облачным приложениям. Детали сделки также не разглашаются. 

11.08.14

Gemalto покупает SafeNet

8-го августа голландская Gemalto объявила о планах приобрести американскую SafeNet за 890 миллионов долларов.

Страх как тормоз развития ИБ

Намедни встречался я с одним чиновником, в функции которого входило принятие решения по одному нормативному акту. Решение он принял отрицательное, попутно говоря о государственности, ответственности перед детьми, новом курсе России, и использовал иные аналогичные сентенции. А уже на пути от него я подумал, что причина его отказа кроется не в нежелании что-то делать, а в страхе! Да-да, в страхе неизвестного.

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

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

Тут впору вспомнить эффект Даннинга-Крюгера, который тоже имеет место у чиновников, но разговор не о нем. Непонимание объекта регулирование приводит к тому, что предсказать, чем закончится “да” проекту нормативного акта заранее нельзя. Может стать как хорошо (чиновнику), так и плохо. Вдруг не только по головке не погладят, но и выпорят еще за отсутствие следования линии партии. А раз в результате положительного решения чиновника сквозит полная неопределенность, то ему проще сказать “нет”. Что чиновник как правило и делает.

Геронтолог Обри ди Грей в статье “Чувство меры в страхе перед неизвестным” так высказался об этом: “Один аспект этой проблемы особенно важен с точки зрения желания общественности избежать некомфортных для себя ситуаций — это неприятие риска. Когда неопределенность проявляется в таких областях, как этика (если речь идет о ядерном трансфере) или экономическая политика (как в вопросе вакцинации против гриппа), соответствующее планирование помогло бы избежать потенциальных проблем. Но когда дело касается отношения общества к риску, все намного сложнее… Да, решение приняли органы власти, но в полном согласии с общественным мнением.

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

Обри ди Грей продолжает: “Реакция на соотношение риска и пользы в области передовых технологий — пример страха перед неизвестным. Это иррациональная склонность придавать большее значение риску, закрывая глаза на преимущества”. Вспомните, сколько раз ФСБ запрещала применение новых технологий? А ФСТЭК (по крайней мере до 2013 года)? А ЦБ, который только до сих пор не имеет требований по безопасности платежных карт или облачных АБС или банкоматов (а ведь они применяются не первый год)? А все просто - у ЦБ нет ни того, ни другого, ни третьего. Они не знают (не знали) как подступиться к регулированию этой темы и поэтому бездействовали, откладывая ее “на потом”.

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

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

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

06.08.14

“Доверяй, но проверяй”? Или доверие пора выбросить в унитаз?

Большинство из нас училось информационной безопасности на концепции доверия. Есть сеть внутренняя, а есть внешняя. Есть пользователи доверенные, а есть не очень. Есть зона контролируемая, а есть бесконтрольная. Есть доверительные отношения между доменами, а есть обычные. Есть соединения доверенные, а есть небезопасные. Есть доверенный интерфейс у МСЭ (как правило, внутренний), а есть недоверенный (как правило, внешний). У некоторых средств сетевой безопасности интерфейсы даже так и назывались trusted и untrusted. Знакомая концепция, не правда ли?

И вот пришел… Нет, не Дед Мороз. И не тот самый пушной зверек. Обычный американский парень - Эдвард Сноуден. А до него был другой Эдвард - Бредли Эдвард Меннинг, который совсем недавно стал Челси Элизабет Меннинг (кстати, тем, кто задумал украсть корпоративные секреты своего работодателя, стоит задуматься о том, к чему приводят действия против закона :-) Они ярко продемонстрировали, что даже в святая святых органов обороны и нацбезопасности поговорка “чужие здесь не ходят” не работает. Скорее наоборот. Не совсем понятно, откуда вообще взялась идея, что в безопасности можно кому-то или чему-то доверять? Это ведь корень всех провалов. Стоит скомпрометировать доверенного пользователя, узел, приложение… и безопасности приходит конец; надо все перестраивать с нуля. И так каждый раз, когда проявляется новый Сноуден, Меннинг, Филби, Рейли, Розенберг, Фишер, Коэн, Пеньковский. Я не берусь сейчас оценивать действия данных лиц с моральной или какой-либо иной точки зрения. Разведчики они или предатели… Не так уж и важно. Я хотел бы оценить эти события только с точки зрения информационной безопасности. Выше я перечислил несколько имен, которые на протяжении последних ста лет показывали порочность практики “доверительных отношений” в ИБ. Не пора ли от нее отказываться? Об этом не первый год говорят как в англоязычной среде, продвигая концепцию Zero Trust, так и у нас, ругая концепцию “контролируемой зоны” от ФСТЭК. Я тоже не обошел внимание эту тему, выступив в 2012-м году на PHDays с соответствующей презентацией.

Вчера я сдал статью в очередной номер "!БДИ", в которой писал о том, почему управление ИБ дает сбой. В качестве причин назвал я и концепцию доверия, а также неготовность к неожиданностям, которая вытекает из этого доверия. Ну какие неожиданности могут быть от администратора СУБД или даже руководителя службы ИБ? А от вендора, с которым мы работаем уже не первый год? А от контрагентов, с которыми у нас заключены договора на поддержку? Так думаем мы и ошибаемся.

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

Кстати, об уровне сети. Какие самые популярные средства сетевой безопасности у нас обычно ставятся? МСЭ и IPS. И те, и другие на периметре сети. Иногда еще и на отдельных участках внутренней сети, но современная коммутируемая сеть (да еще и с виртуализацией или SDN) ставит крест на попытках найти отдельные точки контроля, в которые стекается весь трафик. Но даже если представить, что мы смогли пропустить весь трафик через несколько точек контроля и они не превратились в узкие бутылочные горлышки, то что дальше? А если на доверенном узле, чей трафик разрешен на МСЭ, незаметно работает фрагмент APT или бот? Он будет работать от имени доверенного пользователя или узла, которому разрешено многое. Сетевой трафик не может быть доверенным в принципе. Именно поэтому появляются такие технологии как 802.1x, NAC/ISE, NBAD/CTD, разрабатываемые из расчета, что одной аутентификации пользователя недостаточно и нужно более пристально всматриваться в сетевой трафик, идущий между устройствами (особенно если пользователь за устройством вообще не присутствует и никакой аутентификации не проходит).

“Ни фига!”, - возразите мне вы. Я могу контролировать все, что есть в моей сети и на подступах к ней! У меня множество средств защиты (Forrester насчитывает 17 основных типов средств сетевой безопасности, используемых сегодня по всему миру), они все именитые, на них потрачено много денег и они не могут меня обманывать! Я им доверяю! Вот! Почему вы им доверяете? У вас есть основания? Вы лично проверили эффективность всех средств защиты или просто верите производителю на слово? Как показывает статистика такое доверие дорого обходится. В известных случаях вредоносный код “сидел” внутри по несколько лет и успевал за это время стянуть несколько терабайт данных. И все это при наличии разнородных средств защиты. Значит ли это, что все они плохи? Нет! А можно где-то найти решение, реализующиее технологию “нулевого доверия”? Тоже нет! Их не существует в природе!

Потому что концепция Zero Trust не означает новой серебряной пули или очередной революции на рынке средств ИБ. Это просто смена парадигмы, которая может быть реализована за счет существующих решений и технологий. Надо поменять свое сознание и строить систему ИБ на предприятии исходя из того, что никому и ничего доверять нельзя. Нельзя “доверять, но проверять” - можно только “проверять и никогда не доверять”! Проверять ПО перед установкой и после нее. Проверять все сетевые соединения снаружи и внутри. Проверять все попытки доступа любых пользователей независимо от их роли. Проверять все устройства, подключаемые к сети. Проверять трафик на всех TCP-портах, а не только на тех, которые, как мы считаем, доступны в сети. Проверять прикладной трафик, включая и возможную инкапсуляцию в него чего-то вредоносного или просто нарушающего политику ИБ.
Эксперты выделяют три составляющих концепции “нулевого доверия”, с которыми я склонен согласиться:
  1. Контролируйте и защищайте все. Неважно, кто, откуда, когда, как и зачем осуществляет подключение. Важно проверять все - тогда уровень безопасности сети повысится, а число неприятных сюрпризов существенно уменьшится. Для специалистов по ИБ не должно быть разницы между защитой внутренних активов от внутренних нарушителей и защитой внешних активов от внешних злоумышленников. Для этого достаточно будет пересмотреть правила и настройки существующих средств защиты.
  2. Минимум привилегий и контроль доступа на всех уровнях. Этот принцип должен быть реализован не только на уровне ОС, приложений или периметра. Важно реализовать его и во внутренней сети с помошью встроенных в сетевое оборудование или наложенных средств защиты (первые предпочтительнее). Для этого необходимо использовать средства контроля сетевого доступа (NAC) и производные от него (например, TrustSec).
  3. Инспекция и регистрация сетевого трафика. Нарушитель сегодня в состоянии выдать себя за легального субъекта доступа - пользователя, узел, приложение, процесс. В конце концов злоумышленник может и вовсе оставаться невидимым для средств защиты навесных или установленных не в том месте сети (такое часто бывает, когда в сети появляются несанкционированные 3G/4G-модемы или беспроводные точки доступа). Поэтому необходимо фиксировать весь сетевой трафик и проводить его инспекцию на предмет нарушений политики безопасности (ее, кстати, тоже надо пересмотреть в контексте “нулевого доверия”). Для этого необходимо использовать решения класса NBAD (Network-based Anomaly Detection) и SIEM.
Разумеется, отказ от идеи “доверяй, но проверяй” в пользу “проверяй, никогда не доверяй” - это не сиюминутная задача и не одноразовый проект. Это, в первую очередь, смена классической парадигмы, которой до сих пор учат выпускников ВУЗов по ИБ. Главное, поменять сознание. А уж затем планомерно и последовательно внедрять эту идею на существующих средствах защиты, возможно, приобретая и что-то новое, чего раньше не было (обычно это средства или встроенные механизмы защиты внутренней сети). При этом не всегда это требует серьезных финансовых затрат - очень часто все необходимые компоненты уже присутствуют и их просто надо правильно настроить.

Дело осталось за малым - начать!..

05.08.14

ИБ-требования к разным этапам жизненного цикла АБС вступают в силу с 1-го сентября

На прошлой неделе Банк России выложил у себя на сайте рекомендации в области стандартизации Банка России «Обеспечение информационной безопасности организаций банковской системы Российской Федерации. Обеспечение информационной безопасности на стадиях жизненного цикла автоматизированных банковских систем» (РС БР ИББС-2.6-2014), которая вводится в действие с 1-го сентября 2014-го года.

Идея у данного документа достаточно простая - немалое количество проблем с безопасностью в кредитных организациях происходит по причине не очень высокой защищенности АБС, используемых в банках. Но если выстраивать процессы ИБ вокруг АБС банки умеют, то что делать с приобретаемой и местами дырявой системой было непонятно. Влиять на разработчиков Банк России напрямую не может; к мнению заказчиков многие разработчики тоже прислушиваются редко. И вот был предложен способ, который может повлиять на ситуацию в лучшую сторону. ЦБ дает указание банкам, а те транслируют его исполнителям - разработчикам АБС, которые выполняют не "хотелки" заказчика, а распоряжение отраслевого регулятора. И вот именно такое распоряжение и представляет собой РС 2.6.

Документ разбит, по крупному, на 3 части, последние 2 из которых вынесены в приложения:
  • Требования по организации работ на разных стадиях жизненного цикла АБС.
  • Список из 122 типовых проблем АБС с точки зрения безопасности.
  • Рекомендации по контролю исходного кода АБС и оценке ее защищенности, включая проведение пентестов.
Выделяется 7 этапов, для каждой из которых прописаны свои требования по ИБ.

  1. Стадия разработки технического задания
  2. Стадия проектирования АБС
  3. Стадия создания и тестирования АБС
  4. Стадия приемки и ввода в действие
  5. Стадия эксплуатации 
  6. Сопровождение и модернизация АБС
  7. Стадия снятия с эксплуатации.

Многие мои комментарии и замечания были устранены еще на этапе обсуждения этого документа в ТК122, за исключением двух. Во-первых, документ ну вот совсем никак не рассматривает такое нередкое у нас явление, как иностранные АБС. И особенно АБС (или их компоненты), которые установлены в штаб-квартирах иностранных банках, которые используются и их российскими дочками. А второе мое замечание касалось облачных АБС. Яркий пример - Factura.ru. Вот как к такой АБС применить требования РС 2.6? Она вроде и не банком разрабатывается, и ПО не покупается (покупается сервис), и не разворачивается на стороне банка... Один сплошной диссонанс :-)

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

01.08.14

LANDesk покупает LetMobile

А вот еще пропущенное поглощение :-) Тоже в мае, а точнее 21-го. LANDesk приобретает игрока сегмента мобильной безопасности - LetMobile, которая выпускала решения по защите мобильной почты, мобильному DLP, мобильному контролю доступа и т.п.

31.07.14

Proofpoint покупает NetCitadel

Упустил эту новость раньше. 20-го мая калифорнийская компания Proofpoint, известная на рынке Security-as-a-Service, приобрела за 24 миллиона долларов также калифорнийскую компанию NetCitadel, выпускающую решения по автоматизированному управлению инцидентами. 

30.07.14

BlackBerry покупает Secusmart

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

29.07.14

Разъяснение ФСТЭК по 31-му приказу

Как я и говорил во время семинара, ФСТЭК опубликовала разъяснение по поводу 31-го приказа и его соотнесения с ранее выпущенными документами по ключевым системам информационной инфраструктуры (КСИИ). Разъяснение небольшое - в нем всего несколько тезисов:

  1. АСУ ТП являются подмножеством КСИИ, но защищаться должны по новому 31-му приказу.
  2. Моделирование угроз для АСУ ТП может осуществляться по прежним двум документам ФСТЭК - "Базовой модели угроз КСИИ" и "Методике определения актуальных угроз КСИИ".
  3. Методические документы по КСИИ - "Рекомендации" и "Общие требования" - по-прежнему действуют и могут использоваться для изучения особенностей АСУ ТП. Правда, эти документы имеют гриф "ДСП".
  4. 31-й приказ вступает в силу с момента его официального опубликования (должно скоро произойти) и будет действовать для всех АСУ ТП, вводимых в действие после этого момента. АСУ ТП, введенные в действие до вступления в силу 31-го приказа, могут "жить" по старому. Однако ФСТЭК настойчиво рекомендует следовать и для "старых" систем новым требованиям.
  5. Сертификация средств защиты является неединственной формой оценки соответствия - возможны и другие, по решению заказчика АСУ ТП. Аналогичная ситуация и с аттестацией АСУ ТП.
Этим разъяснением ФСТЭК открывает новую ветку в выпуске методических документов по вопросам защиты информации в АСУ ТП. В разработке находятся методички по реагированию на инциденты, по анализу уязвимостей, по управлению конфигурацией, по аттестации. Кроме того, в следующем году ФСТЭК планирует внести изменения в приказ №17 и расширить состав мер по аналогии с приказом №31 (что логично, т.к. в 17-м не хватает вопросов планирования, реагирования на инциденты, управления конфигурацией и работы с людьми). Также планируется разработка методички "Меры защиты АСУ ТП" по аналогии с "Мерами защиты ГИС". 

25.07.14

Транспортная безопасность теперь еще и от кибератак

На портале, информирующем о разработке новых нормативных актов, появилось два финальных варианта Постановлений Правительства, касающихся транспортной безопасности:

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

  1. Необходимо обеспечивать защиту баз данных пропусков от доступа посторонних.
  2. Необходимо обеспечивать защиту технических средств обеспечения транспортной безопасности объектов транспортной инфраструктуры и транспортных средств от несанкционированного доступа к элементам управления, обработки и хранения данных.
Как обеспечивать такую защиту в нормативном акте не сказано, но на эту тему у нас есть 31-й приказ ФСТЭК, который недавно был утвержден Минюстом. Как написано в преамбуле к 31-му приказу, он распространяется и на область транспортной безопасности.

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

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

24.07.14

Запись и презентация с вебинара по 31-му приказу ФСТЭК по защите АСУ ТП

Провел сегодня вебинар по 31-му приказу ФСТЭК по защите АСУ ТП. Выкладываю презентацию:



Сама запись с голосовым сопровождением доступна на сайте Webex. К сожалению, первые 5-6 слайдов не отображаются - я забыл включить отображение :-( Но в презентации они есть и их можно посмотреть.

Juniper продает свои активы по мобильной безопасности и выигрывает суд у Palo Alto

Спустя ровно 4 года с момента приобретения за 70 миллионов долларов небольшой компании SMobile компания Juniper продает все активы, связанные с мобильной безопасностью американскому инвестиционному фонду Siris Capital за 250 миллионов. Все это делается в рамках объявленной стратегии по реструктуризации бизнеса с целью фокусировки на основных направлениях деятельности. Видимо безопасность в число фокусных теперь не входит.

При этом Juniper умудряется из такого отсутствия фокуса все равно извлекать прибыль. Помимо поулчения 180 миллионов долларов прибыли от продажи подразделения по мобильной безопасности, Juniper в конце мая выиграла суд у компании Palo Alto, которая была обвинена в краже интеллектуальной собственности. В итоге 28-го мая суд обязал Palo Alto выплатить Juniper'у 175 миллионов долларов. Все-таки в патентном троллинге что-то есть :-)

22.07.14

Что считать отечественным ПО: хроники Совета Федерации

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

Во-вторых, мало кто понимает, что такое программное обеспечение. Точнее никто не задумывается над этим, считая, что речь идет только об операционных системах на базе Lunix и приложениях под Windows/Linux. Про микрокод для аппаратуры, который тоже относится к ПО, никто не заикается, но критерии "отечественности" хотят распространить и на него.

В-третьих, всем плевать на безопасность - важно получить преференции при госзакупках. Именно такая идея высказывалась на заседании. Попытка представителей ФСТЭК и ФСБ показать неправильность данного направления утонула в мелких деталях и историях о том, как кто-то пытался еще "до рождения Гейтса" предложить иностранным компаниям сугубо отечественные разработки и их послали, несмотря на то, что отечественная разработка по словам ее автора была более функциональной и занимала всего 40 Кб, а не 200, как у иностранцев.

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

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

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

В итоге заседание закончилось общим мнением продолжать развитие данной темы путем внесения поправок как минимум в 44-ФЗ о госзакупках. Все остальное достаточно туманно... 

Гарнитура с шифрованием - как защитить голос независимо от телефона или ПК?

В апреле я уже писал про законопроект, который должен был запретить пользоваться чиновникам несертифицированными мобильными устройствами, так как они, по мнению автора законопроекта, представляют собой угрозу национальной безопасности. Еще бы! Если бы американские спецслужбы узнали, о чем говорят наши депутаты, то тогда бы они поняли, что нашу страну им никогда не одолеть! Ведь если мы как-то развиваемся с такими избранниками, то что же тогда станет с нами, если в Госдуму придут адекватные люди?..

В прошлый раз я рассмотрел различные альтернативы привычным депататам iPhone'ам, но всех их объединяет одно - надо отказываться от привычного телефона и переходить на новый аппарат или носить с собой второй, специально для конфиденциальных переговоров. Удобно ли это? Конечно нет. Поэтому я в самом конце прошлой заметки и предположил, что от своих Vertu и iPhone'ов никто по своей воле не откажется. И вот тут мне на днях журналисты задали вопрос - а не слышал ли я про российские гарнитуры для мобильных устройств, которые шифруют голосовой трафик начиная сразу от гарнитуры?.. Я не слышал, но копать стал. Собственно, краткие результаты моего копания (без претензий на полноту).

Итак, если отбросить вариант с обеспечением конфиденциальности на самом телефоне (слишком большая зависимость от версии мобильной ОС и платформы) и с применением специального телефонного аппарата (неудобно), то у нас остается целых два варианта решения задачи:

  • шифровать в самой гарнитуре
  • шифровать в "прослойке", промежуточном крипто-модуле между гарнитурой и телефоном.
Про первый вариант мне и говорили и журналисты, упоминая при этом "Росэлектронику", которая должна наводнить российский рынок специализированными гарнитурами с встроенным шифрованием. Но как я не искал, я так и не нашел предприятие, которое бы уже выпускало такие устройства. Думалось мне, что это может быть тульское ОКБ "Октава", которое специализируется на выпуске именно гарнитур для силовиков, спецслужб, МЧС и т.п., но у них я не нашел ничего, чтобы имело отношение к криптографии. Было еще заявление "Росэлектроники" про выпуск криптомодулей для YotaPhone, но к гарнитурам оно имеет мало отношение - четкая зависимость от платформы аппарата.

В принципе, современные гарнитуры, например, Plantronics или Jabra, шифруют голос от микрофона до компьютера (или иного устройства, к которому подключается гарнитура)  с помощью 128-битного алгоритма E0, являющегося частью протокола Bluetooth. Но данный вариант не обеспечивает защиты голосового соединения от абонента до абонента. Скорее это решение для защиты беспроводного соединения от гарнитуры до компьютера или телефона, между котороми может быть до 100-120 метров. Логично предположить, что такой канал в незащищенном варианте легко прослушивается и поэтому требует защиты.

Больше СКЗИ, встроенных в гарнитуры я не нашел. Но зато нашел несколько реализаций второго упомянутого мной решения. Например, TopSec Mobile от Rode-Schwarz. 

Это аппаратное устройство, которое не зависит от модели телефона или компьютера, к которому присоединяется. Переговоры ведутся либо через сам TopSec Mobile, подносимый ко рту во время разговора, либо через гарнитуру, подключаемую к криптомодулю. Единственным минусом этого подхода является наличие выделенного сервера управления звонками, между зарегистрированными на сервере абонентами. Но это необходимое условие построения распределенных систем взаимодействия. 


Вторым найденным мной устройством был скремблер "GUARD Bluetooth" отечественной компании ЛОГОС. Исконно совковое устройство. Дизайна нет как такового. Гарнитуры намертво "вшита" в устройство и заменить ее можно только вместе с устройством. Зато гарантируется защита переговоров - устройство подключается по Bluetooth к передатчику - компьютеру или телефону (про защиту Bluetooth-канала с помощью E0 ни слова не сказано). Устройство не тестировал, но в сети можно найти его обзор. Внешний вид "GUARD Bluetooth" в сравнении с тем же TopSec Mobile дает очень хорошее представление о том, как соотносятся отечественные и западные СКЗИ (и по внешнему виду, и по удобству работы, и по функционалу). Зато для работы данного устройства не требуется никакой внешний сервер - возможна работа "точка-точка".


Последним решением, которое мне бы хотелось рассмотреть, является IndependenceKey, задача которого защитить различные виды взаимодействия между пользователями. Среди защищаемых типов общения есть и голосовая связь. Однако данное устройство является неким промежуточным вариантом между независимым криптомодулем и защитным ПО. В частности, к модулю IndependenceKey подключается гарнитура, с которой передается голос, шифруемый в модуле, но затем он поступает на ПО, установленное на персональным компьютере, куда, в USB-разъем, и вставляется IndependenceKey. К телефону его подключить будет проблематично.


Вот такие решения. Правда, ни одно из них не сертифицировано, и врядли будет. Может быть "Росэлектроника" порадует чем-нибудь интересным в ближайшем будущем?..

15.07.14

Индустриальный сегмент АСУ ТП поверх офисной сети: возможно ли?

Всегда думал, что индустриальные и офисные сегменты должны быть физически разнесены между собой и по офисной сети ну никак не стоит передавать трафик индустриальных приложений по протоколам OPC, Modbus, DNP3 и т.п. Но тут, готовясь к тренингу по безопасности АСУ ТП, наткнулся на интересный кейс от Боинга, в котором как раз ставилась задача по интеграции двух ранее физически разнесенных сегментов.

Раньше индустриальные сегменты выделялись особо с точки зрения дизайна, требований по сходимости, надежности, отказоустойчивости и т.п. У Cisco даже есть отдельное руководство, разработанное совместно с Rockwell Automation по данной теме - свыше 600 страниц подробных инструкций и рекомендаций.


Общая суть таких дизайнов - сегментация и разделение индустриальной и офисной сети.


Но очевидно, что такое разделение несет с собой и ряд сложностей. Вот только ряд из них:

  • Управление VLAN
  • Управление конфигурацией
  • Дублирование СКС
  • Увеличение стоимости
  • Рост числа ошибок.

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

За основу была взята идея оверлейных сетей, которую сейчас активно продвигают в связи с виртуализацией сетевых функций, программируемых (SDN) сетей и т.п. Но для ее реализации мало было просто навесить метки на разные типы трафика - вопрос с совместимостью и защищенностью все равно оставался.



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

  • передача индустриальных протоколов поверх офисной сети за счет инкапсуляции
  • изоляция АСУ ТП от офисной сети с помощью простого индустриального МСЭ
  • защита коммуникаций между ретрансляторами с помощью протокола Host Identity Protocol (HIP).



Решение (LSM) было реализовано в виде открытой архитектуры на базе open source решений. Среди планов Tofino - встроить LSM либо на уровень оконечных устройств (HMI, БД, OPC-сервера и т.п.), либо сразу на уровне контроллеров.

Вот такое интересное решение. Надо заметить, что согласно недавно зарегистрированному приказу ФСТЭК №31 такой подход возможен и у нас. Только вот решений, реализующих эту схему, у нас почти что и нет. Хотя я сторонник все-таки традиционного подхода с физическим, а не логическим разделением индустриальных и офисных сетей.

ЗЫ. Кстати, по поводу 31-го приказа мы (Cisco) проводим онлайн-семинар 24-го июля в 11 утра по московскому времени. Кому интересно, приходите

14.07.14

Первый прецедент наказания за провоз шифровального средства в личных целях через границу РФ

2 года назад я писал про новый нормативный акт российской таможни, фактически требующей декларировать все мобильные устройства, пересекающие границу Таможенного союза (Россия, Белоруссия и Казахстан) воздушным путем должны декларироваться. В комментариях к заметке, а также в Фейсбуке мне возражали, что все фигня и никто не будет на таможне (если нет явного указания) контролировать ввоз мобильников и ноутбуков. И вот первый прецедент. На жителя Ульяновской области могут завести административное дело за покупку смартфона Motorola Moto G в немецком интернет-магазине. Данный смартфон в России еще не продается и  соответствующих нотификаций не имеет. Так что с точки зрения закона таможня в своем праве.

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

  1. Если вы ввозите/вывозите оборудование продаваемое и купленное в России
    • Проверьте в базе зарегистрированных нотификаций свою модель
    • Если модель есть, то просто распечатайте нотификацию или ее номер и возьмите с собой в путешествие
    • Если модели в базе нет, то у продавца должна быть таможенная декларация на ввезенное оборудование, в которой и должна быть указана модель вашего устройства
    • Если ни нотификации, ни таможенное декларации на вашу модель нет, то... непонятно, как оно продается в России. Возможно имеет смысл спросить об этом производителя, который должен обязательно знать о том, на каких основаниях ввозится его оборудование в РФ. В любом случае, отсутствие нотификации/декларации - это потенциальный риск конфискации оборудования, направление материалов в суд и выставление штрафа.
  2. Если вы ввозите/вывозите оборудование продаваемое в России, но купленное заграницей
    • Повторяете все те же действия, что в предыдущем пункте.
  3. Если вы ввозите/вывозите оборудование, в России непродаваемое и купленное заграницей
    • Ввоз оборудования может быть признан изначально незаконным со всеми вытекающими отсюда последствиями. Ввозится такое оборудование только в надежде на то, что не обнаружат на таможне.
Хочу отметить, что стоит обратить внимание на определение шифровальных средств, подпадающих под контроль российской таможни (как с этим обстоят дела в Белоруссии или Казахстане не знаю, хотя закон у нас единый). Это не то, что думаете вы - VPN и т.п. Это более широкая номенклатура позиций. И доказывать, что в вашем смартфоне или ноутбуке нет средств шифрования вы можете сколько угодно, но и смартфоны и ноутбуки включены в список контролируемых позиций.

Так что делайте выводы и оценивайте свои риски...

UPDATE: Нотификации должны быть не только на само устройство, но и на весь софт, который на нем установлен. Но это вообще утопия :-) Особенно для open-source или самописного ПО.

11.07.14

Беспрецедентное право о запрете хранения ПДн

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

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

  • Персональные данные россиянина уходят с территории РФ на Интернет-сервис, который затем хранит эти данные там же, заграницей. На иллюстрации ниже это вариант №1. По этому сценарию сейчас работают почти все зарубежные социальные сети, а также сайты отелей, бронирования билетов, организации мероприятий, лечения за рубежом и т.п. Именно против такого сценария и направлен, по моему мнению, принятый закон.
  • Персональные данные россиянина уходят с территории РФ на Интернет-сервис, который хранит эти данные в России. Это вариант №2. Никакой проблемы с нарушением требований закона в этом случае я не вижу; нужно только соблюсти требования по трансграничной передаче ПДн.
Кстати, о трансграничной передаче. Многие коллеги высказывают мысль, что ее-то никто не запрещал. Да, это так. Только попробуйте задаться вопросом - а что такое передача? Это стратегические бомбардировщики могут у нас летать, не приземляясь и заправляясь "на ходу". При передаче ПДн всегда есть точка отправления и точка получения ПДн. Всегда! Персональные данные не передаются в никуда (вариант №3 на иллюстрации). Поэтому они должны где-то "приземлиться". В случае трансграничной передаче они "приземляются" либо в России, либо за ее пределами. Первый случай хорошо описан в сказке Катаева "Цветик-семицветик":

Лети, лети, лепесток,
Через запад на восток,
Через север, через юг,
Возвращайся, сделав круг
Вот в этом случае персданные, трансгранично передаваясь, возвращаются в Россию, и мы получаем вариант №2. А если данные не возвращаются, то мы получаем вариант №1. Иными словами, трансграничная передача ПДн никому не нужна, если их запрещено хранить за рубежом. При этом формально ст.12 Евроконвенции, о которой тоже многие коллеги говорили, не ограничивается. В ней же говорится о трансграничной передаче, а не о хранении. Передача по-прежнему разрешена, а вот хранение нет :-(




Есть и других два, менее распространенных варианта:
  • Персональные данные россиянина уходят из-за границы также заграницу. Формально, ФЗ-152 не распространяется на иностранные юрлица, которые не могут и не должны знать о наших депутатах, столь рьяно беспокоящихся о гражданах своей страны. И формально они могут делать с ПДн все, что угодно и передавать их в рамках своего государства или за его пределы как угодно. Только вот мы забываем про вторую часть принятого закона, которая по объему больше первой и третьей частей. Она подробно расписывает процедуру блокирования доступа к сайтам-нарушителям. Нарушителям по мнению Роскомнадзора, а не зарубежного оператора ПДн. И если нарушение есть (а по мнению РКН и депутатов оно будет), то доступ к иностранному сайту будет блокирован (в варианте №1 он также будет блокирован). А вот дальше уже оператор ПДн будет доказывать в российском суде, что он не верблюд. И какова вероятность, что иностранный оператор будет с этим разбираться? А что он пойдет в суд? А что он выиграет дело? То-то и оно. Формально он может быть и будет прав, но фактически доступ к его сайту будет для россиян, не пользующихся VPN, закрыт.
  • Персональные данные россиянина уходят из-за границы в Россию. Это почти такой же вариант, что и предыдущий. Как только данные попадают в РФ, то на их обработку распространяется по мнению РКН ФЗ-152 в полном объеме и мы вновь возвращаемся к предыдущему сценарию.
И, наконец, последний, совсем уж редкий и вырожденный вариант - персональные данные россиянина уходят из-за границу обратно в заграницу транзитом через Россию. Я такой вариант представляю себе с трудом, но он тоже возможен. Но с точки зрения законодательства разницы между ним и предпоследним вариантом почти никакой.

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

А вот с иностранными ситуация обстоит иначе. Они изначально в невыигрышном положении и им придется доказывать, что они данные не хранят за границей. Поэтому им надо будет представлять какой-то договор на хостинг БД с ПДн в России. Пойдет ли на это какой-нибудь австрийский небольшой семейный отель, в котором российский чиновник любит проводить зимние каникулы? Или швейцарская элитная школа, где учатся дети депутата? Или компания SABRE, благодаря которой депутат заказывает авиабилеты в Майями, чтобы проведать свою недвижимость? Или оператор Web-сайта международного экономического форума в Давосе, куда как мухи на мед слетаются депутаты? Или владелец магазина эксклюзивных алкогольных напитков и сигар в Лондоне, который обслуживает депутатов? Нет, не пойдут. Они будут либо нарушать ФЗ, либо перестанут работать с ПДн россиян.

Кстати, в последней фразе есть два важных момента. Что такое персональные данные? И что такое ПДн россиянина? Я за последние две недели смог вспомнить только один случай, когда у меня при заполнении хоть какой-либо анкеты спрашивали гражданство. Это было виза. Все! Больше случаев не припомню. Ну еще получение загранпаспорта. А в остальных случаях - гражданство не указывается. Ни во время заказа автомобиля в Hertz. Ни во время заказа билетов в Аэрофлоте. Ни во время бронирования билетов в парк Aventura. Ни во время бронирования на booking.com. Нигде. И как, позвольте спросить, иностранный оператор ПДн должен узнать, что он хранит ПДн россиян? По имени? Так они часто совпадают у славян, которые населяют и сопредельные государства, где нет таких идиотских законов. По фамилии? Та же ситуация. По IP-адресу? Он тоже не имеет "гражданства". Оператор может сказать, что он не хранит ПДн россиян и формально будет прав. Но только РКН это все равно никак не помешает заблокировать доступ к такому сайту. Еще можно сослаться на то, что иностранный оператор не хранит ПДн вовсе. Ведь, что такое ПДн, определяет он сам в своих локальных актах. Тот же РКН считает, что номер мобильного телефона, e-mail и логин не являются ПДн. А если добавить сюда еще и адрес? Тоже, скорее всего, нет. Но вот добавив ФИО можно говорить о ПДн. А если не ФИО, а только ФИ? Вопросы, вопросы, вопросы... Но так ли они важны?

На мой взгляд, совершенно не важна юридическая или техническая сторона данного закона. Можно долго спорить о том, как надо читать статьи закона - отдельно или в совокупности? Важно другое. У РКН появилась возможность блокировать сайты преимущественно иностранных компаний, которые якобы нарушают российское законодательство. Формально это будет выглядеть очень корректно. РКН направит запрос иностранному оператору ПДн (как обычно на русском языке). Тот его проигнорирует (он же не знает русского, как ни странно). РКН заблокирует доступ к сайту. Именно доступ, а не самого оператора. А дальше уже оператор будет пытаться (если захочет) что-то сделать. Когда вьетнамский "РКН" аналогичную махинацию с локальным хранением провернул у себя в стране с целью принудить Yahoo создать локальные хранилища, Yahoo послала вьетнамский "РКН" в пешее эротическое путешествие и ушел с вьетнамского рынка. У нас будет ситуация аналогичная, чего, на мой взгляд, и добиваются российские власти, так и не договорившись с Facebook, Google и Twitter (последним особенно). И их поставили перед выбором - либо за 2 с небольшим года они "исправятся", либо пойдут лесом. Аналогичный финт российские власти провернули с Visa и Mastercard, которых вынуждают играть по правилам РФ. Но если для последних Россия - это хоть и незначительный, но все-таки лакомый кусок бизнеса, то для западных социальных сетей, это скорее всего не так. Поэтому не исключаю, что через пару лет мы столкнемся с импортозамещением еще и социальных сетей. Если, конечно, в закон вновь не внесут поправки, а это вполне реальная вещь, видя как депутаты сначала принимают закон, а потом либо отменяют его, либо вносят поправки, отменяющие первичный запрет. Иными словами, данный закон разрабатывался и принимался (а скорость его принятия - это вообще песня) только с геополитической целью, а не для защиты прав российских граждан.

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


А как же права субъекта? А никак. У нас давно права субъекта никого не интересуют. Даже уполномоченный орган по их защите. А как же право на доступ к информации, свободу перемещений, свободу слова, дарованные нам Конституцией? А никак. Мало ли у нас нарушений Конституции? Вон и Президент на днях, якобы совершил такое нарушение. А если гражданин считает себя ущемленным, то милости просим в Конституционный суд. А как же Евроконвенция? А никак. У нас уже скоро 8 лет как ст.19 ФЗ-152 противоречит Конвенции и ничего.

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

Но вот что интересно в законе, так это третья часть, о которой все благополучно молчат и только Михаил Емельянников про нее заговорил первым и, пока, единственным. Речь о внесении изменений в ФЗ-294 "о проверках", согласно которым, надзор за обработкой ПДн и информации в Интернет исключается из общих норм ФЗ-294. Иными словами, после вступления в силу этой нормы РКН может уже не формировать списки плановых проверок, не согласовывать проверки с прокураторой, не соблюдать частоту плановых проверок раз в три года и многое другое. Вот это, на мой взгляд, самое опасное в этом законе, т.к. несет с собой вполне конкретные риски для российских операторов ПДн, которые теперь будут ходить постоянно под Дамокловым мечом, не зная, когда к ним придет проверка РКН. А учитывая законопроект по штрафам, вышедшим на финишную прямую, картина и вовсе становится зловещей...

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