28.5.13

Treolan покупает Safeline

Слияния и поглощения на российском рынке ИБ - это редкость и поэтому тут обычно возникает желание развернуться и поразмышлять "что" да "почему". Но часто бывает, что ты либо о слиянии знаешь что-то инсайдерское и не хочешь раскрывать то, что раскрывать не надо, либо слияние вызывает одни вопросы, остающиеся без ответов. Так произошло и с объявленной вчера сделкой о покупке компанией Treolan, входящей в ГК Ланит, компании Safeline, входящей в ГК "Информзащита". По публично озвученной версии "продажа Safeline продиктована желанием акционеров ГК «Информзащиты» сосредоточить усилия на развитии основных направлений своего бизнеса – разработке средств защиты информации и оказании услуг в области ИБ". Правда, ровно этот же мотив, в 2007-м году назывался, когда создавался Safeline. Сначала создают, чтобы сконцентрироваться на основном. Потом продают, чтобы сконцентрироваться на том же самом. Парадокс...

А вообще данная покупка напоминает продажу Crossbeam'а компании Blue Coat, которые обе принадлежали одному владельцу - инвестиционному фонду Thoma Bravo.


К черту контент, важен контекст!

После того, как в 21-м приказе ФСТЭК появилась мера по контролю утечек персональных данных (аналогичная мера по конфиденциальной информации будет и в 17-м приказе), а Банк России в Магнитогорске заявил о проработке вопроса о создании отдельного документа по DLP с банковской спецификой тема контроля утечек вновь стала более чем актуальной. Кто-то стал разрабатывать новые решения по части DLP, кто-то стал в очередной раз пиарить свой продукт. Вообще я уже не раз проходился по этой тематике, но хочу в очередной раз потроллить тему ;-) Да и на PHD III рассказывали как обойти современные DLP. Как будто это настолько распространенный продукт, что он стал стандартом де-факто в корпоративной среде.

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


Что это? Буква "В" русского алфавита? Буква "B" английского алфавита? Несчастливое число "13"? А вот фиг его знает. Мы не знаем. Да и DLP тоже не знает. Если не рассматривать анализ графических файлов и опять ограничить область распространения голым текстом, то максимум, что DLP может определить, что это символ какого-то алфавита или число.. 
Так и в более сложных случаях. Допустим мы встречаем в тексте набор "ключевых" фраз - "месторождение", "объем запасов", "миллион кубометров". По всем параметрам это утечка информации. А оказывается, что кто-то просто переслал рекламную листовку с соответствующими текстовыми вкраплениями. А все потому, что мы контролировали контент, забывая про контекст.
Я привел немного упрощенный пример, который просто показывает, что современные средства защиты (и не только DLP) уже давно устарели в своем желании контролировать адреса и направлении взаимодействия. И в желании контролировать контент они тоже устарели - сегодня этого не хватает. Нужно контролировать контекст. Под контекстом я понимаю не только ответ на вопрос «ЧТО можно», т.е. анализ трафика на сетевом и прикладном уровне, но и ответы на вопрос «КОГДА можно» (привязка ко времени попытки доступа), «КУДА и ОТКУДА можно» (куда и откуда осуществляется доступ), «КОМУ можно» (привязка не только к IP-адресу, но и к учетной записи пользователя), «КАК можно» (с какого устройства можно осуществлять доступ – с личного или с корпоративного, со стационарного или с мобильного). Все это позволяет более гибко выстраивать политики доступа и учитывать постоянно изменяющиеся потребности современного предприятия с точки зрения информационной безопасности.


Не могу сказать, что мысль нова. Но в последнее время становится все более понятно, что по другому (по старинке) выстраивать систему защиты уже неправильно. Она перестает выполнять стоящие перед ней задачи, а точнее выполняет их процентов на 20-30. Вот, например, что может сделать обычная система анализа сетевого трафика:
 

Ничего сверхестественного. Ну видим, что с определенных адресов уходит большой объем данных, на порядок превышающий установленные лимиты. Но в среде с динамической адресацией, это ничего и никому ни о чем не говорит. А если добавить контекст?


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


Тут вам и беспроводной и проводной доступ, доступ с личных (BYOD) и корпоративных устройств, доступ со станционарных и мобильных устройств, доступ с устройств, за которыми пользователь аутентифицируется и за которыми он не работает (IP-телефон или игровая приставка), пользователи, которые прошли оценку соответствия и которых дополнительно аутентифицируют по сертификатам... Очень гибкая схема, отличающаяся от стандартной "пользователю ivanov111 можно получить доступ к IP-адресу 10.10.10.10".

Думаю, что за такими системами будущее.

27.5.13

Корпоративная ИБ идет в дома

В январе я написал заметку про революцию в деятельности корпоративных служб ИБ; потом из нее выросла целая статья для февральского номера журнала "IT Manager". В ней я писал о том, что очень много потребительских технологий (BYOD, Dropbox, Google.Docs, соцсети и т.п.) приходит в корпоративную среду и это надо учитывать службам информационной безопасности. Но ведь существует и обратное движение.

Достаточно вспомнить, что лет десять назад у многих дома был только один компьютер и больше никаких иных IP-устройств не присутствовало. Время шло, благосостояние росло, число устройств увеличивалось. Свой компьютер, компьютер супруга (супруги), компьютер детей, планшетник (а то и на каждого члена семьи), смартфон (и тоже на каждого члена семьи), хранилище файлов, видео, музыки, мультимедиа-центр, игровые приставки... Кто-то идет дальше и обустраивает дома систему видеонаблюдения (CCTV), подключает к Интернет холодильник, кофеварку, пианино (для скачивания новых мелодий и прошивок). Устройство много и все они разные. Как и разная на них информация хранится, доступ к которой имеют разные категории пользователей для решениях различных задач.

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

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

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

Объекты доступа

Очевидно, что тут не полный перечень объектов доступа. Не хватает сетевого оборудования (маршрутизаторы, коммутаторы, а также точки беспроводного доступа), игровых приставок, принтера, сканера, да много ли еще чего. Например, в загородном доме может быть интерфейс для управления системой жизнеобеспечения дома через Интернет. А у продвинутых пользователей и бытовая техника может быть привязана к Интернет. Например, у Cisco есть такая штука как Home Energy Controller, который позволяет управляет "домашней АСУ ТП" и отслеживать все ключевые показатели деятельности домашних потребителей энергии; в т.ч. и через Интернет.




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

ЗЫ. Хотя у многих безопасников ничего такого дома нет ;-) Сапожники без сапог ;-(

23.5.13

Как защититься рядовому чиновнику в Интернет?

Вчера, по приглашению Правительства Москвы, я выступал на ИТ-дне, организованном Департаментом информационных технологий г.Москвы. Мероприятие было очень недурно организовано и посетило его, по моим оценкам, около 300-400 человек, представляющих различные департаменты, отделы и подведомственные учреждения московского Правительства. Зачастую люди далекие от ИТ и тем более безопасности. Поэтому меня просили за 45-50 минут рассказать о том, что делать рядовому пользователю для защиты своего присутствия в Интернет. Родилась вот такая презентация...



21.5.13

Vista Equity Partners покупает Websense

20-го мая инвестиционный фонд Vista Equity Partners объявил о намерении приобрести известную и в России ИБ-компанию Websense. Интересных моментов в этой сделке несколько. Во-первых, это сумма сделки, которая не только открыта, но и достаточно велика, чтобы считать эту сделку одной из самых крупных рынке ИБ-поглощений за последние годы. Величина сделки - около 1 миллиарда долларов (оборот Websense около 360 миллионов). Во-вторых, Websense вел переговоры с несколькими покупателями. И судя по размеру сделки, эти покупатели были явно из первой пятерки игроков ИТ-рынка (что-нибудь уровня Dell, Oracle и т.п.). В-третьих, после поглощения Websense станет непубличной компанией.

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

Что касается будущего Websense, то пока прогнозы строить рано. Менеджмент заявляет о продолжении развития компании, но цель приобретения и стратегия развития после поглощения как обычно не озвучена. Кроме стойкого желания продать купленный актив подороже ничего не понятно. Но с продажей подороже тоже не все просто. Купить компанию дороже чем за миллиард?.. Таких покупателей не так и много в мире. Раздробить на мелкие части и продать по отдельности? Что-то не припомню на рынке ИБ таких сделок. В общем будем следить, как и за судьбой инвестиционного фонда Thoma Bravo, накупившего немало ИБ-компаний.

О грядущем PHDays III, Жириновском, будущем молодежи, SDLC и другие размышления

Осталось всего два дня до начала третьего форума Positive Hack Days. Пора уже рассказать о том, что я там буду делать и прокомментировать некоторые одиозные высказывания людей, далеких от понимания того, что и ради чего организовывается на PHD.

Начну с конца - в первый день я буду модерировать секцию про SDLC, в которой примут участие Антон Карпов (руководитель службы ИБ Яндекса), Денис Баранов (руководитель группы по безопасности Web-приложений), Рустем Хайретдинов (генеральный директор Appercut Security) и ваш покорный слуга. Говорить мы будем о анализе качества кода с точки зрения информационной безопасности. Антон и я будем делиться практическим опытом того, как это устроено в наших компаниях (Яндекс и Cisco), а Денис и Рустем расскажут о том, как использовать SAST/DAST/IAST в контексте поиска уязвимостей и поиске закладок в исходном коде. Ну и нельзя будет обойти вниманием вопрос реализации механизма работы автоматического анализа в виде локального сканера и облачного сервиса. И хотя времени на секцию выделено немного, попробуем осветить ключевые моменты и сделать ее практической.

Вторая секция является "молодежной". Аннотация у нее следующая: "Сегодня, в 2013-м году мы находимся на пороге серьезных изменений в отрасли информационной безопасности, которые коренным образом меняют современную картину мира многих специалистов в области ИБ. Stuxnet, Duqu, Flame, Red October, Wikileaks, «Лунный лабиринт», операция «Аврора»… Атаки становятся изощреннее, а методы борьбы с ними остаются прежними. Прежние люди, отдавшие службе Родине не один десяток лет, прежние документы, мало поменявшиеся с 90-х годов. При этом современная молодежь чувствует себя лишней на этом «празднике жизни». Снижение качества образования в области информационной безопасности, нехватка специалистов, ориентация на «бумажную безопасность»… Все это отторгает молодежь от современной отечественной отрасли ИБ. Она не до конца понимает, чем она может пригодиться своей Родине. У многих молодых выпускников возникает понятное желание побыстрее заработать на своих знания, что зачастую приводит к уходу одаренных специалистов в полукриминальный или полностью криминальный бизнес; в киберпреступность. Как бороться с этой проблемой? Какие шаги предпринимают государство и бизнес для решения данной задачи? Как направить свои знания и умения в правильное русло? Об этом пойдет разговор на секции, куда приглашены представители всех основных «профильных» организаций, ответственных за информационную безопасность в Российской Федерации".

Иными словами на этой секции не будет хардкора, не будет техники, не будет шоу. Будет серьезный разговор представителей Совета Федерации, Министерства связи и массовых коммуникаций,  ЦИБ ФСБ, представителей ruCTF и Defcon Russia, представителей бизнеса с участниками PHD, с молодежью. Не будет нравоучений. Будет интересная дисскусия. Причем не односторонняя, а с активным участием тех, на кого и рассчитана секция.

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

Заходим на сайт и читаем "международный форум по практической безопасности, организованный компанией Positive Technologies. Беспрецедентный по масштабу ИБ-марафон, объединяющий на одной площадке специалистов с разных сторон баррикад, теорию и практику, профессиональную дискуссию и захватывающие соревнования. На PHDays III соберется рекордное число участников — более 2000 человек, среди которых ведущие эксперты в области ИБ, важнейшие фигуры хакерской сцены, студенты и молодые ученые, представители государственных организаций, CIO и CISO крупнейших российских и зарубежных компаний". Что видим? Теория и практика, разные стороны баррикад, госорганы и бизнес, ученые и студенты... Где хардкор? В том-то и прелесть этого мероприятия, что в нем найдет баланс между техническими и бизнесовыми докладами, между правовыми и практическими аспектами ИБ, между выступления бизнеса и госорганов. Я уже в третий раз буду участвовать в PHD и могу сказать, что никогда не рассматривать его как хакерскую тусовку. даже в самый первый раз я там читал тему про кибервойны и про законодательное регулирование криптографии в России. Во второй раз говорил опять про законодательство и про плохие документы ФСТЭК. В этот раз с моими темами докладов (опять про законодательство и про безопасность M2M) меня завернули, но и без этого в программе немало "бизнесовых" выступлений, которые не тянут на хардкор, но при этом не менее интересны.

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

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

PS. Да, кстати. Будет у меня еще одно выступления, как от представителя спонсора ;-) Расскажу о предлагаемых Cisco продуктах в области ИБ, о которых мало кто вообще слышал в России - о CTD, о WAF, и о AntiDDoS ;-) Аккурат на 15 минут ;-)

20.5.13

Обновленная статистика по нормотворчеству в области ИБ в России

Обновил статистику по появлению нормативных актов по ИБ в России. Озвученная полгода назад цифра в 4-5 нормативных акта в месяц остается в силе - темп наши законодатели и регуляторы пока не снижают. Вот так выглядит разбивка по месяцам с июня 2011-го года.


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

17.5.13

Jaibreak or not jailbreak?

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

Потребитель тоже стоит перед выбором и взвешивает, какие риски выше? Применения несертифицированной СКЗИ на легальной iOS (например, Cisco AnyConnect или множества иных VPN-клиентов) или сертифицированной СКЗИ на "взломанной" iOS? При этом варианты использование специализированного прикладного ПО с встроенной сертифицированной СКЗИ я не рассматриваю - спектр их применения не очень велик ввиду их заточенности под конкретные применения.

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

ФСБ - не единственный регулятор, который "не смотрит" на интеллектуальную собственность разработчиков средств защиты. ФСТЭК в своей системе сертификации средств защиты по требованиям безопасности тоже не сильно "напрягается" на эту тему. Иначе как еще можно объяснить возможность подачи заявки на сертификацию средств защиты, минуя разработчика? Вообще это нонсенс - компания-разработчик узнает о проведенной сертификации либо задним числом, либо вообще может не знать о том, что кто-то взял ее продукт, "распотрошил" его с целью оценки защитных свойств и выдал на результат потрошения сертификат соответствия! А ведь именно так и обстоит дело с большинством продуктов иностранного происхождения, присутствующих на российском рынке. В массе своей заявителями сертификации по линии ФСТЭК являются либо продавцы средств защиты, либо покупатели. Не буду говорить за других вендоров, но по Cisco, в реестре сертифицированных средств защиты присутствует около 30-40 сертификатов на маршрутизаторы Cisco ISR и столько же примерно на межсетевые экраны Cisco ASA 5500. При этом большая часть сертификатов выдана на схожие версии продуктов, но в сертификатах указаны разные заявители, разные классы защищенности МСЭ, разные классы АС/ИСПДн, в которых возможно применение средств защиты, разные ограничения на эксплуатацию... И при этом Cisco про эти сертификации никто не уведомлял. Все бы ничего, если бы такие сертификационные исследования не были бы запрещены партнерскими договорами и лицензионными соглашениями. Но при приеме средства защиты на сертификацию этот вопрос обходится вниманием. Допускаю, что по незнанию, но проблема от этого менее острой не становится.

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

Да и фиг с ним, с правом на интеллектуальную собственность. Это все буржуйские заморочки и нарушение прав потребителей, которые могут делать с купленным товаром все, что угодно. Распространенная точка зрения. Именно ею мотивируют jailbreak'и многие его сторонники. Я не буду говорить, что с точки зрения безопасности тот же jailbreak это хорошо. Он не дает запускаться приложениям с административными привилегиями. Он не дает осуществлять некоторые системные вызовы и обращаться к некоторым областям памяти. Он создает для приложений некий аналог "песочницы". Он не дает копировать/красть установленные приложения. И вообще он не дает устанавливать "левые", непроверенные приложения.

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

Аналогичная ситуация с подменой стандартной библиотеки MS GINA, которую часто подменяют для реализации расширенных процедур входа в систему на базе Windows. На сайте Microsoft четко написано, что да, третьи лица часто подменяют MS GINA для своих целей (например, подключение аутентификации по токену или расширение стандартной парольной аутентификации биометрией), но это несет за собой риски некорректной загрузки системы или даже невозможности такой загрузки. Безусловно гарантия, которая по лицензионному соглашению Microsoft и так не сильно велика, в этом случае может быть утеряна. Схожая ситуация с встраиванием отечественной сертифицированной криптографию в продукцию Microsoft. Как прямо заявляют разработчики "MS не предоставил способа "честно" встраивать локализованную криптографию".

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

16.5.13

Приказ ФСТЭК по ПДн зарегистрирован в Минюсте

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

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

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

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

Ну и в заключение поста напомню, что за последнее время было принято еще несколько нормативных актов по части ПДн:
  • приказ РКН "Об утверждении перечня иностранных государств, не являющихся сторонами Конвенции Совета Европы о защите физических лиц при автоматизированной обработке персональных данных и обеспечивающих адекватную защиту прав субъектов персональных данных"
  • закон "О внесении изменений в некоторые законодательные акты РФ в связи с принятием ФЗ «О ратификации Конвенции Совета Европы о защите физических лиц при автоматизированной обработке персональных данных".
Европа должна в ближайшее время принять новую редакцию Евроконвенции. В следующем году станет ясно, в каком варианте будут приняты новые Директивы по ПДн. В обозримом будущем должен быть принят приказ РКН по методам обезличивания, приказ ФСБ по шифрованию ПДн, отраслевая модель угроз ПДн Банка России. Из менее понятных с точки зрения прогнозов могут быть приняты поправки в КоАП по увеличению штрафов за нарушение правил обработки ПДн, проект Постановления Правительства по надзору в сфере ПДн, поправки в ФЗ-152, законопроект Аксакова, новые составы в ст.13.12 КоАП за нарушение правил защиты информации.

Так что этот год станет очень насыщенным с точки зрения законодательства по ПДн. Очень насыщенным...

15.5.13

Обновление программы курса по защите информации в НПС

Обновил программу курса по НПС. В текущей версии 1.9 добавлены следующие темы

  • Поправки в ФЗ о банках и банковской деятельности и «О центральном банке»
  • Указание от 25.06.2012 №2840-У по операционным рискам
  • План работ ТК122 
  • Стандарт безопасности банкоматов и платежных терминалов (ЦБ, ГУУР и ГУВО МВД, АРБ)
  • Деятельность Ассоциации НПС
  • Легитимность применения СКЗИ иностранного производства
  • Национальный операционный клиринговый центр
  • Национальная система фрод-мониторинга
  • Проект Плана мероприятий Банка России по реализации Стратегии развития национальной платежной системы в контексте защиты информации
  • Почему следователи отказывают в возбуждении уголовных дел по ст.159

Как провести поиск НДВ в продукции американского происхождения

Межпраздничная дискуссия в блоге и в Фейсбуке в очередной раз высветила некоторые проблемы с оценкой соответствия в форме поиска недекларированных возможностей и доказывания их отсутствия. Если посмотреть на проблему с точки зрения американской компании. Таких исследований, к счастью, никто не проводил, но по моим личным оценкам из 65-70% средств защиты иностранного происхождения присутствующих в России, до 75-80% из них приходится на продукцию, изготавливаемую в США. Поэтому рассмотрение проблемы в таком аспекте является достаточно интересным для достаточно широкого круга специалистов (особенно в органах по сертификации, испытательных лабораториях, экспертных организациях и регуляторах).

Итак, недекларированные возможности. Даже сертификация на 4-й уровень их отсутствия требует предоставления достаточно чувствительной информации. Исходные коды только один из вариантов такой информации, причем далеко не всегда самый важный и критичный. Например, для компании, выпускающей программно-аппаратные, а не только программные средства защиты, гораздо более конфидениальной является информация о системотехнике, архитектуре, функциональные спецификации и т.п. Предоставление этой информации относится к лицензируемому виду деятельности и требует разрешения от Бюро по промышленности и безоппасности, являющегося частью Министерство торговли США. Задача данного подразделения - блюсти экономические интересы США и контролировать среди прочего экспорт высоких технологий и технологий двойного назначения. В частности в т.н. Commerce Control List (CCL) есть параграф "5A002 "Information security" systems, equipment and components therefor, as follows". В него (он не единственный, но один из основных) входит немало того, что требует получения лицензии американского Минпромторга. Также к контролируемым относятся позиции 5A992 и 5B002. Иными словами первый вопрос, на который надо ответить, ЧТО экспортируется и средства защиты, включая средства шифрования, а также элементы, разработанные для работы средств защиты (специальные модули, операционные системы, приложения, микросхемы и т.п.) полностью подпадают под экпортные ограничения из США.

Однако ответа на вопрос ЧТО недостаточно для принятия решения об экспорте средств защиты. Надо ответить на вопрос КУДА, т.е. определить страну, в которую будет экспортироваться средство защиты. У Минпромторга есть регулярно обновляемая т.н. Commerce Country Chart, которая содержит список стран с указанием причины экспортного контроля. Как можно заметить Россию включили в этот список по направлениям "химическое и биологическое оружие", "национальная безопасность", "стабильность в регионе" и "преступность". Иными словами, средства защиты, будучи контролируемыми вообще, могли и не попасть под контроль для России, но увы... Если посмотреть на CCL, то в нем против каждой контролируемой позиции указаны причины (для средств защиты - это "национальная безопасность" и "антитерроризм".

Затем мы должны ответить на вопросы КТО будет использовать то или иное средство защиты. Например, поставка средств защиты в государственные органы контролируется более серьезно, чем в коммерческие предприятия и уж тем более в малый бизнес. А вообще в США есть несколько "черных" списков стран, организаций и лиц, которым запрещена поставка той или иной продукции. И, наконец, последний вопрос - ЗАЧЕМ. Может быть в производстве оружия массового поражения?

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

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

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

14.5.13

Зачем фиксировать IP, MAC, IMEI, если их легко модифицировать?

В планируемой к выпуску новой версии 382-П одно из основных изменений коснулась требования по фиксации действий клиентов, осуществляющих перевод денежных средств. Это по сути проект 262-П, который вызвал немало вопросов в свое время, перенесенный в 382-П и выпавший из под контроля Росфинмониторинга. В 382-П необходимо будет фиксировать "идентификационную информацию, используемую для адресации устройства, с использованием которого осуществлен доступ к автоматизированной системе, ПО с целью осуществления переводов денежных средств, которой в зависимости от технической возможности является IP-адрес, МАС-адрес, номер sim-карты, номер телефона и (или) иной идентификатор устройства".

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

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

Во-вторых, IP- или MAC-адрес легко подменить. Либо путем прямой манипуляции с компьютером, либо путем ARP Spoofing'а, IP Spoofing'а и других аналогичных сценариев. С номером телефона, идентификатором телефона (IMEI), серийным номером SIM-карты ситуация сложнее, но как оказывается и они могут быть подменены. Например, недавно, после обнаружения вредоносной программы Pincer для Android, эксперты из Sourcefire Vulnerability Research Team проанализировали код Pincer и, основываясь на его коде, смогли подменить IMEI, телефонный номер, модель телефона.

До и после изменения идентификационных данных на Android

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

Собственно, получается что большого смысла все попытки фиксировать IP, MAC, IMEI, номер телефона и т.п. не имеют. Злоумышленники могут их легко обойти, а вкладывать инвестиции в более надежные способы нецелесообразно. Особенно в условиях, когда даже обнаруженный и пойманный злоумышленник может выйти сухим из воды из-за пробелов в отечественном законодательстве. Мне кажется, что для борьбы с мошенниками все силы надо бросать на изменение Уголовного и Уголовно-процессуального кодексов, а также на обучение сотрудников правоохранительных и судебных органов. Технические меры безусловно важны, но и заменить ими организационно-правовые методы борьбы с киберпреступниками не получится.

13.5.13

Приколы нашего "Городка" или немного об особенностях отечественной системы сертификации средств защиты информации

Помните рубрику "Приколы нашего городка" в программе "Городок"? Готовя тут один документ, составил список приколов и в "нашем" городке, имя которому "сертификация средств защиты информации в РФ". Надо заметить, что ко многим из них мы (разработчики, продавцы, потребители, органы по сертификации, испытательные лаборатории, регуляторы) настолько привыкли (или закрываем глаза), что даже не задумываемся над сложившейся практикой сертификации средств защиты, которая почти не менялась с серидины 90-х годов, когда появились 608-е Постановление Правительства и 199-й приказ. Но под влиянием внешних факторов задумался и вот что получилось (в немного юмористической и местами утрированной форме):
  1. Только в РФ регулятор выдает сертификат на СЗИ даже не спросив о легальности испытаний с точки зрения прав на интеллектуальную собственность 
  2. Только в России продавец может подать средство защиты на сертификацию, не поставив в известность вендора и нарушив партнерский договор
  3. Только в России потребитель может подать средство защиты на сертификацию, не поставив в известность вендора и нарушив лицензионный договор
  4. Только в России, чтобы сертифицировать СКЗИ для мобильной платформы, производитель ОФИЦИАЛЬНО рекомендует сделать jailbreak ;)
  5. Только в России за сертификацию средств защиты (исключая ГТ) несет ответственность НЕ их производитель, а потребитель ;)
  6. Только в России испытательная лаборатория и орган по сертификации могут сосуществовать в одном юридическом лице, извлекающем прибыль из своей деятельности, что позволяет органу по сертификации, получив результаты интеллектуальной собственности и ноу-хау разработчиков и других испытательных лабораторий, использовать их как свои наработки будучи уже в качестве испытательной лаборатории по другим проектам.
  7. Только в России испытательная лаборатория и орган по сертификации могут сосуществовать в одном юридическом лице, участвовать борьбе за заказчика как ИЛ, а если проиграет, стать для выигравшего конкурента органом по сертификации и отомстить.
  8. Только в России производителем средства защиты может считаться не тот, кто реально его разработал и производит, а тот, кто подал его на сертификацию.
  9. Только в России качество и возможности средства защиты определяются не его реальными характеристиками и защитными свойствами, а голограммой и копией сертификата.
  10. Только в России средство защиты может быть сертифицировано на соответствие ТУ или ЗБ, которые тщательно скрываются от потребителя. 
  11. Только в России сертификация на отсутствие недекларированных возможностей, требующая обязательного предоставления исходных кодов, может быть проведена без предоставления исходных кодов. 
  12. Только в России в один момент времени могут существовать несколько копий одной версии одного средства защиты, сертифицированные по разным требованиям и даже по разным классам защищенности. 
  13. Только в России сертификат соответствия на средство защиты, сертифицированное в одной системе сертификации, не признается в другой системе сертификации, даже если он там сертифицировался по тем же самым требованиям.
  14. Только в России срок действия сертификата на средство защиты определяется не сроком эксплуатации сертифицированного средства защиты в условиях неизменности среды функционирования, а сроком, установленным Правительством. 
  15. Только в России условия применения, ограничения по использованию и другие характеристики сертифицированного средства защиты могут быть отнесены к коммерческой тайне и не выдаваться по запросу потребителей или разработчиков. 
  16. Только в России специалист по сертификации средств защиты может быть не знаком с принципами функционирования оцениваемого им средства защиты и вообще не видеть его в глаза. 
  17. Только в России пройдя всего лишь по 10-20% всех ветвей алгоритма исходных кодов ПО средства защиты испытательная лаборатория делает вывод об отсутствии недекларированных возможностей. 
Сейчас только ФСТЭК затеяла обновление своего старого "Положения о сертификации средств защиты информации по требованиям безопасности информации" (199-й приказ). Уже разработан проект положения об оценке соответствия продукции (работ, услуг), используемой для защиты информации ограниченного доступа, а также процессов ее разработки, производства, монтажа, наладки, эксплуатации и хранения. Но желаемых изменений в этом проекте нет ;-( Зато явно прописано, что теперь оценка соответствия будет распространяться не только на традиционные средства защиты, но и на "средства, в которых они реализованы, т.е. многофункциональные программные, технические, программно-технические средства, которые могут использоваться в целях защиты информации, а также объекты информатизации". Зато срок действия сертификата (при единичных экземплярах и партии) становится бессрочным ;-) Может быть и остальные недостатки действующей системы исправят?

Все, что творится в недрах 8-го центра ФСБ и ЦЛСЗ, обычно является тайной за семью печатями, но насколько я понимаю, никаких изменений не планируется.

8.5.13

Управление взаимоотношениями с поставщиками решений по информационной безопасности

Вчерашняя заметка про потенциальное поглощение Stonesoft и в блоге и на Facebook вызвала оживленную дискуссию, которая оказалась далекой от первоначальной темы. Обсуждали все - кто и как не умеет читать список сертификатов ФСТЭК, какие сертификаты ФСБ есть у Cisco, как я в своем личном блоге рекламирую работодателя, как в список сертификатов на отсутствие НДВ попали компании, которые никаких исходных кодов не предоставляли, как плохо сработали PR-службы российских McAfee и Stonesoft, какие бывают акционеры, отказывающиеся от получения дохода, превышающего 10-кратный размер первоначальных активов, и т.д. И даже тема, поднятая Рустемом Хайретдиновым, плавно переключилась на совершенно иное обсуждение; хотя мысли о M&A-сделках на рынке ИБ звучали там интересные. А ведь Руст говорил о вполне конкретной теме, которую я и хотел бы развить. Имя ей vendor management или управление взаимотношениями с поставщиками (вендорами).

В зависимости от масштаба компании это может быть как отдельное подразделение (причем именно как vendor management office, а не как расширение отдела закупки /procurement/), так и просто набор функций, которыми занимается сотрудник компании. Идея управления взаимоотношениями с поставщиками проста и понятна - эффективное планирование всеми аспектами взаимодействия с поставщиками тех или иных продуктов и услуг (в нашем случае - по ИБ).

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

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

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

Что могло бы войти в состав такого чеклиста, который мог бы стать отправной точкой при общении с поставщиками решений по ИБ? Увы, четкого ответа нет. Его нет даже для продуктов, а уж тут-то выбирать, кажется, проще всего. Но увы... 10 лет назад я написал для PCWeek/RE статью "Сделай правильный выбор" - про то, как выбирать средства защиты. Метод не новый, но до сих является одним из самых оптимальных. Вопрос только в критериях оценки, которые сильно зависят от конкретной ситуации, и от весовых коэффициентов, которые также меняются от компании к компании.

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

Какие вопросы включают зарубежные CISO в свой чеклист? Например, такие:
  • финансовые показатели и корпоративные анонсы
  • ротация топ-менеджмента и организационные изменения
  • изменения в продуктовой линейке и направлениях бизнеса
  • истории успеха у заказчиков
  • уровень удовлетворенность заказчиков
  • структура и прозрачность ценообразования
  • партнерская сеть
  • инсталлированная база
  • roadmap и объем инвестиций в R&D.

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

Да ну эту всю теорию, кому она нужна? Частично соглашусь. Многим не нужна. Многие руководители служб ИБ либо чисто интуитивно выбирают себе партнера на долгие годы, либо не сталкиваются с такой проблемой. А кто-то и вовсе считает ее нестоящей и выеденного яйца. Особенно если выбирается решение/компания для некритичного направления бизнеса.
 
Причем понятие "критичности" у всех тоже может быть разное и на его трактовку могут влиять:
  • Важность и число процессов, в которые могут быть вовлечены (а также глубина вовлечения) приобретаемые или просто выбираемаые ИБ-решения. Одно дело выбрать 2-3 токена для хранения ЭП бухгалтера и гендиректора и совсем другое дело выбирать полноценное IdM-решение в масштабе всего предприятия.
  • Уровень доступа к конфиденциальной информации. Этот критерий скорее важен при выборе консалтинговой компании, а не поставщика продуктов.
  • Уровень затрат на решения выбираемого вендора. Потратить/потерять 1-2% от своего бюджета и 35%... Это заставляет задуматься и более серьезно подойти к выбору компании-партнера.
  • Уровень интеграции внутри компании. Одно дело IdM, с которым сталкиваются все подразделения компании и совсем другое дело - SIEM, результаты работы которого видны только службе ИБ.
  • Длительность планируемых отношений. На пентест или разовый аудит заказного ПО можно пригласить не очень известную компанию и критерием выбора тут может служить цена (к примеру). А вот для защиты АСУ ТП, жизненный цикл которой (не говоря уже о потенциальном ущербе в случае реализации инцидента ИБ) может измеряться десятилетиями, число достойных кандидатов будет гораздо меньше.
  • Наличие субподрядчиков. Одно дело довериться одной-единственной компании и совсем другое, когда тендер выигрывает генподрядчик, предложивший лучшую цену или каждые выходные играющий в гольa с вашим гендиректором, и который привлекает для выполнения работ малоизвестные и невысоко себя ценящие конторки.

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

7.5.13

McAfee покупает Stonesoft. Что это значит для российских потребителей?

Обычно я сделкам слияния и поглащения не уделяю много внимания, но тут особый случай. 6 мая американская корпорация McAfee (часть Intel) объявила о подписании соглашения о приобретении финской Stonesoft за 389 миллионов долларов наличными. В мировом масштабе сделка не особо интересная, т.к. Stonesoft - компания нишевая и с небольшими оборотами, что не позволяло ей "светиться" в различных сравнениях, отчетах, квадратах и т.п. У себя в компании, иногда задавая вопрос коллегам из США или Западной Европы о сравнении решений Cisco и Stonesoft, постоянно слышу: "А Stonesoft - это что?" ;-) Но в России Stonesoft компания известная; в первую очередь тем, что смогла получить сертификат ФСБ на свой SSL Gate став второй зарубежной компаний после Cisco, получившей официальный статус от этого регулятора. Поэтому вопрос о том, что несет с собой это слияние, непраздный и в Facebook вчера мы немало внимания посвятили дискуссии на эту тему. Здесь я выскажу свою личную позицию по этому вопросу.

Сразу скажу, что обсуждать что-то конкретное рано. Я думаю, даже в самих компаниях еще не понимают конкретных шагов по интеграции и тех последствий, которые эта интеграция влечет за собой (достаточно посмотреть на письмо Ilkka Hiidenheimo, гендиректора и основателя Stonesoft по партнерам). Наблюдая за ИБшным M&A-рынком на протяжении последних лет 10-12, могу сказать, что перспективы поглощенных компаний почти всегда печальны ;-( Разработчики и архитекторы уходят в другие компании, руководство создает новые стартапы, технологии если и интегрируются, то очень небыстро. Какие-то технологии вообще прекращают свое существование. Партнерская и ценовая политика претерпевает серьезные изменения. Гибкости становится меньше. А вот поглотитель, как правило, в выигрыше ;-) Он либо устраняет конкурента, либо получает в свое портфолио новые технологии, либо получает клиентскую базу. В крайнем случае для него вообще ничего не меняется ;-) Но вернемся к сделке McAfee и Stonesoft.

Судя по пресс-релизу, цель приобретения заключалась в технологии межсетевых экранов. Именно о них говорят то-менеджеры обеих компаний в своих цитатах. Про IPS сказано вскользь, про VPN вообще ни слова. Это закономерно. Свои решения по IPS у McAfee есть и технологии Stonesoft скорее всего вольются в McAfee, а не наоборот. Хотя надо заметить, что судьба IPS как самостоятельного сегмента рынка сейчас в мире находится под вопросом. Очень уж активно пересекаются технологии IPS и FW NG. А учитывая заявления аналитиков и многие по-настоящему серьезные исследования по рынку сетевой безопасности, могу предположить, что через 2-3 года самостоятельных IPS в мире почти не останется - они вольются в межсетевые экраны и UTM-решения, как их неотъемлемая часть.

С VPN от Stonesoft ситуация, на мой взгляд, еще хуже. В портфолио McAfee, насчитывающем с 4-5 десятков различных продуктов, нет ни одного, который бы касался VPN. Есть фрагментарно разбросанные функции, но как самостоятельного направления нет. Учитывая мировые тенденции, можно предположить, что и эти продукты Stonesoft прикажут долго жить. Частично этот функционал может быть включен в МСЭ, частично в решения по мобильной безопасности.

Но в России же решения Stonesoft VPN имеют перспективы, скажете вы. Да еще и в контексте сертификации в ФСБ. Если смотреть с точки зрения России да. А если с точки зрения международного бизнеса? Россия одна из немногих стран в мире, где VPN-решения существуют как самостоятельный сегмент рынка, что связано с нашей регуляторикой. Во всех других регионах VPN - это одна из функций МСЭ, балансировщика нагрузки, маршрутизатора, UTM-устройств... Я более чем уверен, что McAfee не будет оставлять в своем портфолио продукт только для одного локального рынка, доход с которого измеряется 10-20 миллионами долларов. Это для финской компании это серьезный вклад в финансовое благополучие; для транснациональной корпорации - это в пределах погрешности. Я, конечно, не могу принимать решений за McAfee, но учитывая, что и сам работаю в американской компании и знаю, как принимаются такие решения, могу с высокой степенью достоверности предположить, что судьба VPN-продуктов Stonesoft предрешена (о них, кстати, в пресс-релизе о слиянии ни слова).

А что будет с сертификацией Stonesoft? Тут ситуация еще сложнее. О ней вообще мало кто думает - причем со всех сторон. Отечественный потребитель и интегратор о ней просто не знает. Российское представительство вендора либо не знает, либо не понимает как подступиться к ее решению. А американской штаб-квартире на нее вообще с высокой колокольни ;-) Американцы считают, что весь мир живет по их правилам и поэтому для них бывает большим открытием, что, например, в Россию нельзя взять и просто ввезти средство с шифрованием по AES или 3DES. Они не знают, что в России не действуют сертификаты по FIPS и "Общим критериям". Они всегда удивляются, когда им пытаешься рассказать о специфике российского регулирования. А когда они понимают, они начинают пытаться состыковать отечественную регуляторику со своей собственной. А она там тоже есть и не менее серьезная, чем у нас, а местами и более серьезная.

Например, там нельзя взять и просто вывезти какие-то технологии,  имеющие значение для национальной безопасности. Необходимо получить согласование Министерства коммерции и, в частности, его бюро промышленности и безопасности (Bureau of Industry and Security). Чтобы получить разрешение на встраивание отечественной криптографии в американский продукт (не забывайте, что после завершения сделки продукция Stonesoft становится американской, а не финской) необходимо получить соответствующую лицензию. Получение такой лицензии - очень непростой процесс; может занимать до года и более. Чтобы впрягаться в эту игру, McAfee должна понимать не только сложности, но и преимущества. Нужен серьезный бизнес-кейс. 10-20 миллионов - это не бизнес-кейс для компании масштаба McAfee (по моим ощущениям). Аналогичную лицензию и еще большее количество согласований внутри американских госорганов небходимо получать в случае сертификации на отсутствие недекларированных возможностей, требующей предоставления исходных кодов.

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

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

Могут ли быть иные сценарии? Теоретически да. Например, сделку могут не разрешить вовсе. Но это было бы более чем вероятное событие (как, например, в ситуации когда Check Point'у запретили поглощение Sourcefire) если бы Stonesoft решил  купить McAfee, а не наоборот. Stonesoft могут оставить в качестве независимого подразделения, зарегистрированного в Финляднии. Тоже верится с трудом (пока такого на рынке "американских" поглощений почти не наблюдалось). Последний вариант - McAfee будет нарушать закон. Но это еще менее вероятный сценарий (после скандала с бывшем основателем одноименной компании McAfee сейчас меньше всего нужна негативная шумиха). Прав я или нет, покажет время. Но пока мои прогнозы, которые я делал раньше относительно поглощенных компаний, сбывались.

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

6.5.13

Avast покупает Secure.me

Чешская компания AVAST Software 30-го апреля анонсировала приобретение небольшой компании secure.me, сфокусированной на решениях по безопасному серфингу и пользованию социальными сетями. Детали сделки не разглашаются.

О Таллинском руководстве по ведению кибервойн

НАТОвский центр повышения квалификации в области киберобороны 3 года назад пригласил группу независимых международных экспертов, которым была поставлена задача изучить, как существующие международные нормы права применяются к новым формам ведения войн в киберпространстве. В итоге родилось так называемое Таллинское руководство (The Tallinn Manual on the International Law Applicable to Cyber Warfare), которое иногда (особенно в России) преподносится как набор рекомендаций по ведению кибервойн и право на применение физической силы в ответ на кибернападения. Это не совсем так.

Во-первых, Таллинское руководство не является официальным документом ни центра CCD COE, ни НАТО, ни стран, которые входят в НАТО. Это всего лишь частная точка зрения участников рабочей группы, которая и написала Таллинское руководство. Да и с самим руководством немало мифов связано. Например, часто считается, что Таллинское руководство разрешает физическое устранение хакеров, участвующих в военных действиях в киберпространстве. Это не совсем так. Группа экспертов вообще не пришла к четкому мнению о том, относить ли тех или иных лиц к участникам киберконфликтов. Например, если кто-то напишет вредоносную программу, которая потом будет использована в кибервойнах, то будет ли автор вредоносной программы участником кибервойн? При этом авторы четко зафиксировали в 33-й статье правило, известном многим российским юристам, - "любые сомнения в виновности лица должны трактоваться в пользу подозреваемого". В Таллинском руководстве написано, что "в случае возникновения сомнений относительно того, является ли лицо гражданским, это лицо считается гражданским".

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

Ключевые выводы, сделанные авторами документа таковы:
  • Государства ответственны за кибероперации против других государств, которые ведутся с их территории,  даже если такие операции ведутся не спецслужбами, но при этом государство дает "хлеб и кров" тем, кто атакует другие страны. Например, если какой-либо государственный чин призывает хакеров помочь в проведении кибер-операций против других государств, то призывающее государство будет нести все бремя ответственности за последствия, как будто само проводило такие действия. Кстати, этот вывод сразу разбивает все доводы экспертов, считающих, что Таллинское руководство написано НАТО (читай США) для обоснования своих действий в киберпространстве. Ведь именно руководство АНБ призывало американских хакеров "помочь Родине".
  • Запрет на применение силы, включая и силу в киберпространстве. Четкого ответа, что является применение киберсил, эксперты не дают, но сходятся в том, что это, как минимум, должно сопровождаться нанесением ущерба отдельным лицам или даже повреждением тех или иных объектов. При этом действия, вызывающие раздражение или неудобство у той или иной страны, к применению силы не относится.
  • Государства имеют право применять различные контрмеры против незаконных киберопераций. При этом данные контрмеры могут быть признаны незаконными, но только не в случае ответных действий (в этом случае их применение считается оправданным).
  • Государство, ставшее жертвой "вооруженного нападения" в киберпространстве, повлекшего человеческие жертвы или иной серьезной ущерб, имеет право ответить с помощью силы в киберпространстве или физическом мире. Вот этот тезис достаточно часто приводит к спорам и дискуссиям, но на мой взгляд ничего сверхествественного в нем нет (при условии четкой идентификации нападавшей стороны). Также хочу отметить, что в России, в стратегии, приписываемой МинОбороны, есть аналогичный пункт - "В условиях эскалации конфликта в информационном пространстве и перехода его в кризисную фазу воспользоваться правом на индивидуальную или коллективную самооборону с применением любых избранных способов и средств, не противоречащих общепризнанным нормам и принципам международного права".
  • Применение контрмер, в т.ч. и на территории иностранных государств, допустимо в отношении кибертеррористов.
  • Вполне допустимо относить вооруженные конфликты полностью ведущиеся в киберпространстве к международному понятию "вооруженный конфликт". Это, в свою очередь, применять нормы международного гуманитарного права.
  • Вооруженные конфликты, перетекшие в военные преступления, влекут за собой уголовную ответственность для тех лиц, которые руководят кибер-операциями, ведомыми в рамках вооруженного конфликта.
  • Кибер-операции, направленные против гражданских объектов и лиц, не приводящие к нанесению вреда жизни и здоровью, не запрещены международным гуманитарным правом. При этом запрещено использовать кибер-операции для того, чтобы сеять страх среди населения (недавний взлом Twitter'а Associated Press сюда замечательно попадает на мой взгляд).
  • Руководство кибероперациями, повлекшими за собой жертвы среди гражданского населения (или могущие повлечь такой ущерб) классифицируются как военные преступления.
  • Кибератаки должны направляться против конкретных целей и объектов. "Веерные" атаки, которые могут задеть гражданских, должны быть под запретом.
  • Объекты, необходимые для выживания гражданского населения (лечебные учреждения, продовольственные магазины, ЖКХ-объекты), а также медицинский персонал и служители церкви подпадают под международное гуманитарное право и на них не должны быть направлены кибероперации (даже случайно).