31.8.10

ФАИТ доигрался - его закрыли - 2

Ну вот и долгожданный текст указа Президента о расформировании ФАИТ.

Как Роскомнадзор свою конференцию организовывал...

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

Во-первых, они ошиблись в названии. Занимаясь защитой прав субъектов ПДн, они назвали конференцию просто "Защита ПДн". Хотя слухи о том, что они хотят подвинуть ФСТЭК и ФСБ на технической поляне ходят давно.

Во-вторых, они выбрали самую неудачную дату для мероприятия. На следующий день после межотраслевого съезда директоров по ИБ, проходящего в Москве. Какой нормальный руководитель отпустит своих подчиненных или будет участвовать сам  в двух подряд идущих конференциях длительность по 2 дня каждая? А т.к. на форуме директоров по ИБ будет и тема ПДн и множество других интересных выступлений, то боюсь, что аудиторию РКНовская тусовка просто не соберет, акромя чиновников, интеграторов и журналистов ;-)  К слову сказать, в даты проведения конференции РКН будет проходить и 11-я CiscoExpo. Там хоть аудитории и не сильно пересекаются, но все же.

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

Четвертая классическая ошибка, вытекающая из третьей, попытка дать слово всем желающим, чтобы не обидеть ненароком "высокого чина". А раз так, то всем дают по 15 минут на выступление. Ну как можно за 15 минут рассказать о новом СТО Банка России?

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

На остальные мелочи даже внимания не буду заострять и так все понятно.

ЗЫ. Может кто из организаторов посмотрит эту заметку и сделает выводы... но что-то не верится ;-(

30.8.10

О рисках получения лицензии ФСБ

Весной я описывал ситуацию с ФЗ-57, который любое предприятие имеющее лицензию ФСБ делает стратегически важным для обороноспособности страны. А следовательно любые инвестиции в такие предприятия должны быть согласованы с ФАС и ФСБ. Невыполнение этого условия может привести к аннулировании сделок, инвестиций и т.п. И вот первый пример работы этого закона. Royal Bank of Scotland запретили увеличить долю в ЗАО "Королевский банку Шотландии", ссылаясь именно на этот закон.

Вот теперь и думай - получать лицензию ФСБ или нет? А еще Правительство и Президент возмущаются, почему это в Россию так мало инвестиций идет...

ArcSight ищет покупателя

Недавно я писал про новое приобретение HP и заметил, что скоро мелких игроков на зрелых сегментах рынка почти не останется. И вот новая новость, подтверждающая правило, - ArcSight выставил себя на аукцион и готов продаться тому, кто купит этого SIEM-игрока. Потенциальных покупателей называют несколько. Среди них таже HP, Oracle, IBM, EMC и CA. Причем три последних уже имеют в своем порфолио SIEM-решения.

Для российского рынка эта новость имеет непосредственное и немалое значение. Учитывая, что после потери лидерских позиций компании netForensics, именно ArcSight заняла первое место по продажам на российском рынке. И вот неприятная для покупателей новость. Для существующих она неприятна тем, что судьба продукта теперь неясна. Если его купят IBM, EMC или CA, то что и куда вольется совсем неочевидно. ArcSight в том виде, в котором его все знают, может прекратить существование. А если его купят HP или Oracle, то все может и обойдется. Главное, чтобы продукт не постигла судьба решений ISS или OpenSolaris.

27.8.10

DDoS в мультфильме

Orange на базе продуктов Ciscoв области ИБ запустил услугу по защите от DDoS. Но сейчас не об этом, а о ролике, который они сделали про DDoS. Зачетный мульт ;-)

Интернет-ТВ по безопасности

Некоторое время назад я приложил руку к созданию первоапрельской шутки-новости на SecurityLab. Начиналась она так: "Группа компаний «Информзащита» объявила о создании целого пула игроков рынка информационной безопасности. К уже имеющимся 6 компаниями, входящим в группу (интегратор "Информзащита", УЦ "Информзащита", дистрибутор SafeLine, Национальный аттестационный центр, "Код безопасности" и Trustverse), было создано еще 3. "SecureTV" – компания, в сферу деятельности которой будет входить создание своего телеканала, пропагандирующего вопросы информационной безопасности и рассказывающего об этой теме непосвященному зрителю".

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

26.8.10

Шифрование и обезличивание

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

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

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

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

25.8.10

HP покупает Fortify

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

Описанная мной пару лет назад тенденция о скупке мелких игроков гигантами ИТ-рынка продолжается. HP купил Fortify, Intel купил McAfee... Не исключаю что кто-то скоро купит Check Point. Главное в таких сделках, чтобы приобретаемый продукт не прекратил свое существование в том виде, в котором его привыкли видеть заказчики. А то получится как с OpenSolaris, который Oracle все-таки прикрыл ;-(

Как законно неиспользовать сертифицированные СКЗИ при передаче ПДн через Интернет?

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

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

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

24.8.10

О балансе интересов

Про баланс интересов я уже как-то писал. Это классное исключение, когда не надо получать согласие субъекта ПДн. И РКН часто заявляет, что они бы и рады следовать Евроконвенции, где это исключение есть, но не могут, т.к. в российском законодательстве его нет. Но они ошибаются. В Гражданском Кодексе есть классная глава - 50 - "Действия в чужом интересе без поручения". Согласно 980-й статьи этой главы: "Действия без поручения, иного указания или заранее обещанного согласия заинтересованного лица в целях предотвращения вреда его личности или имуществу, исполнения его обязательства или в его иных непротивоправных интересах (действия в чужом интересе) должны совершаться исходя из очевидной выгоды или пользы и действительных или вероятных намерений заинтересованного лица и с необходимой по обстоятельствам дела заботливостью и осмотрительностью". Т.е. многие ситуации, для которых сложно получить согласие, могут быть уведены под эту статью. Например, можно запросить БКИ о кредитоспособности заемщика (правда БКИ не имеет права отвечать, но это отдельная песня). Можно вести видеонаблюдение или контролировать посещаемые сайты (в целях обеспечения обязательств по содержанию имущества работодателя в целости и сохранности, а также в целях защиты информационных систем работодателя от вредоносного кода на Web-сайте). Ну и т.п.

А 2-й пункт 980-й статьи говорит, что даже если у госсоргана нет согласия гражданина на обработку его ПДн, то это и не нужно, т.к. для них "такие действия /в чужом интересе без согласия - А.Л./ являются одной из целей их деятельности".

23.8.10

Сбер опять жжет ;-)

Вы обращали внимание, что у Сбера на прошлой неделе появился новый раздел на главной странице - "Сотрудники, уволенные из Сбербанка". Вот интересно, как это соотносится с ФЗ-152 и требованием получать согласие у субъекта ПДн? А главное, какая цель записана у Сбера для обработки этих персданных? Ведь заранее ее было сложно предусмотреть, а найти в законодательство основание для такой публикации непросто. ЖКХшников за это Роскомнадзор наказывал. А у тех цель была благая - защита от неплательщиков.

20.8.10

Детальная карта курса по инцидентам

Меня попросили раскрыть программу курса по управлению инцидентами, что и я делаю. Совсем все не раскрываю, ибо оно тогда совсем не влезет на страницу А4.

Incident Management (Detail Map)

Intel покупает McAfee

19 августа Intel объявил о покупке McAfee за почти 8 миллиардов (!) долларов! Цель Intel - включить технологии безопасности в устройства, ранее обойденные вендорами по безопасности, - мобильные и беспроводные устройства, ТВ, автомобили, медицинские устройства, банкоматы и т.д. Учитывая, что Intel выпускает процессоры и материнские платы, то она может встроить безопасность именно на этом уровне.

19.8.10

Как Сбербанк подвинул ФСБ в части криптографии

12 августа г-н Путин подписал распоряжение 1344-р "Об организации предоставления государственных и муниципальных услуг с использованием универсальной электронной карты". Текст распоряжение очень короткий - "В соответствии с частью 3 статьи 28 Федерального закона "Об организации предоставления государственных и муниципальных услуг" и в целях организации предоставления государственных и муниципальных услуг с использованием универсальной электронной карты определить федеральной уполномоченной организацией, осуществляющей функции, предусмотренные главой 6 указанного Федерального закона, открытое акционерное общество "Универсальная электронная карта". А вот следствия из этого распоряжения далеко идущие и вот почему.

Дело в том, что ОАО УЭК - детище трех банков (Сбербанка, Уралсиба и АкБарса), активно участвующих в проекте т.н. социальной карты, которая призвана стать единым идентификатором гражданина при оказании госуслуг, банковских услуг и т.п. И хотя отцом данного проекта является Уралсиб основную роль в проекте сейчас играет именно Сбербанк. Минэкономразвития уже даже объявило тендер на выполнение первого этапа работ по теме "Разработка пакета нормативных, методических и организационных документов по внедрению и использованию универсальной электронной карты гражданина".

И что спросите вы? Что тут такого? Очередная инициатива по отмыванию денег в государственных масштабах. Может быть, но... Так и не запустив в нормальном режиме Сберкарту (а потом и ОРПС) у Грефа сейчас появляется возможность реабилитироваться и он постарается ее не упустить. И вот тут и кроется изюминка. Дело в том, что данный проект, ориентированный на всех граждан России, будет построен на базе международного стандарта EMV, созданного American Express, JCB, MasterCard и Visa (почти те же игроки создали PCI DSS). А EMV ничего не знает об отечественной криптографии и требованиях ФСБ по использованию сертифицированных СКЗИ на базе ГОСТов при защите персональных данных и оказании госуслуг. Текущая спецификация стандарта EMV использует алгоритмы RSA, DES, 3DES, а также предлагает использовать в качестве дополнительного варианта криптографию на базе эллиптических кривых. Собственно тот же 3DES и сейчас используется в технологии DUET в ОРПС.

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

А там и до обещанной либерализации недалеко... ;-)

18.8.10

То, что обычно не считают

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

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

17.8.10

Где взять текст 330-ПП?

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

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

16.8.10

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

Писал уже про создание курс по управлению инцидентами. И вот на днях обновил его. Обновления коснулись следующих тем:
  • Пошаговая процедура управления инцидентами SANS
  • Какими инцидентами обычно управляют в организациях?
  • Примеры отчетов об оформлении инцидентов
  • Стратегии управления инцидентами "защитить и забыть" и "найти и наказать"
  • Детальный план создания CSIRT
  • Сколько человек должно управлять инцидентами в организации?
  • Как общаться с неизвестным абонентом, заявляющим об инциденте?
  • Показатели качества CSIRT (а не только инцидентов)
  • Модели существования CSIRT в организации
  • Бизнес-модели существования CSIRT
  • Бизнес-план создания CSIRT для руководства
  • План создания CSIRT в MS Project
  • Статистика мировых CSIRT по различным вопросам их существования
  • Как оценить стоимость инцидента?
  • Каков должен быть состав CSIRT?
  • Программное обеспечение для работы CSIRT (трекинг инцидентов)
  • Как приоритезировать инциденты? 9 различных схем
  • Где можно найти доказательства инцидента?
  • Как собирать доказательства?
  • Где хранятся доказательства?
  • Где искать следы на ПК?
  • Что надо помнить о носителях данных?
  • Управление отдельными видами инцидентов (ПК, маршрутизатор Cisco, Интернет, e-mail)

Общая схема курса теперь выглядит следующим образом:

3.8.10

Новый законопроект по лицензированию

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

    2.8.10

    Регулирование Интернет - версия законопроекта другого ведомства

    В пятницу я писал о законопроекте Шлегеля в части регулирования Интернет. Сегодня пройдемся по законопроекту Минкомсвязи, который тоже планирует регулировать Интернет. Но как и в прошлый раз посмотрим на изменения только в части информационной безопасности. Предложения Минкомсвязи касаются внесения изменения сразу в несколько законов - трехглавого, о СМИ, УК РФ, ГК РФ и т.д.

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

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

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

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

    Также вводится новое понятие: "угрозы информационной безопасности – действие или событие, которое может привести к разрушению, искажению, невозможности своевременного использования информации, а также несанкционированному использованию ресурсов информационно-телекоммуникационной сети".

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