Сиюминутность ИБытия или анализ страхования рисков и блокчейна в исторической перспективе

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

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

Другой пример - страхование киберрисков. После статьи в Коммерсанте о готовящейся инициативе по обязательному страхованию киберрисков (по аналогии с ОСАГО), все заговорили о том, как это своевременно и нужно. Однако мало кто вспомнил, что теме страхования информационных рисков в России уже 20 лет (будет в следующем году). Еще в 1998-м году было подписано Соглашение о сотрудничестве в области страхования информационных рисков между Госкомсвязи России и страховыми организациями (№6836 от 10.11.98). Спустя месяц было Госкомсвязью было подписано Указание от 4 декабря 1998 года №121-У "О реализации соглашения о сотрудничестве в области страхования информационных рисков", в котором упоминались среди прочего уже разработанные документы, которые должны были лечь в основу нового законодательства по страхованию информационных рисков (в точ числе и обязательного). Среди этих документов:

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

Второй виток интереса к теме страхования информационных рисков случился 5-тью годами позже (основным застрельщиком был ВНИИПВТИ), когда возникла тема с законопроектом об обязательной гражданской ответственности государственных информационных систем. В трехглавый закон "Об информации, информатизации и защите информации" планировали внести новую статью 22.1 "Страхование информационных ресурсов, систем, технологий и средств их обеспечения" с всего двумя пунктами  (аналогичная норма должна была войти в закон "Об информационных ресурсах и информатизации в г.Москве"):

1. Государственные информационные ресурсы, системы, технологии и средства их обеспечения подлежат обязательному страхованию. Порядок и условия страхования определяются законодательством Российской Федерации.
2. Негосударственные информационные ресурсы, системы, технологии и средства их обеспечения страхуются в порядке, установленном законодательством Российской Федерации.

Позже планировалось разработать отдельный закон "Об обязательном и добровольном страховании информационных рисков", а также внести ряд поправок в нормативно-правовые акты по страхованию, банковской деятельности и т.п.

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

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

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

Подробнее…

Рынок труда по ИБ ждет жестокая драка за место под солнцем. Вы к ней готовы?

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

Год назад я уже задавался философским вопросом: "Кому ты будешь нужен через 5 или 10 лет?" И про замену человека искусственным интеллектом тоже писал (длительные перелеты способствуют философским рассуждениям). Сейчас я хочу вновь вернуться к этому вопросу, но немного с иной точки зрения. Все мы знаем, что выпускники ВУЗов, идущие на свою первую работу, обычно хотят денег - много и сразу. Отчасти, потому что это свойственно молодости, переоценивающей свои навыки и квалификацию. Отчасти, потому что эти выпускники прочитали/услышали, что специалистов по ИБ не хватает. По разным оценкам такая нехватка составляет не менее 1 миллиона человек по всему миру. В России же не хватает по оценкам Минтруда около 50-60 тысяч специалистов по ИБ. Отсюда многие делают вывод, что в условиях дефицита можно требовать много денег. Увы... Читая новости про отсутствующий миллион специалистов по ИБ, все забывают, что речь идет о квалифицированном персонале, а не вообще о тех, кто готов называть себя ИБ-специалистом.

Такая нехватка приводит к тому, что компании (и потребители, и производители) начинают искать выход и находят его в двух направлениях:

• автоматизация операций, которые раньше выполнял человек; причем не только рутинных
• аутсорсинг (в том числе и ввиде перехода на облачные технологии).

Обратите внимание, больше специалистов делать никто не хочет (зато хотят запретить им выезд заграницу). Во-первых, это долго (минимум 4 года, а то и все 6, в зависимости от специальности) и рынок не готов столько ждать. Во-вторых, число ВУЗов, готовящих таких специалистов, сокращается. Если сравнить текущий список учебных заведений, входящих в УМО по ИБ, с тем, что было еще несколько лет назад, то разница составит не менее 25% и динамика эта негативная. В-третьих, уровень преподавания в ВУЗах оставляет желать лучшего (почему - это отдельная тема). Отсюда и нежелание заниматься увеличением числа выпускников и рост дефицита безопасников. Но дефицит этот будет компенсироваться не за счет людей.

Рустем Хайретдинов в Facebook последнее время не раз уже писал про замену людей роботами. И если отбросить фантастический флер, которым овеян термин "робот", то это тенденция действительно имеет место в индустрии ИБ. Машинное обучение, аналитика, автоматизация, API... Все это снижает зависимость от человека, возможности которого по борьбе с современными динамично изменяющимися угрозами сильно ограничены. Зачем нужен человек, если программа готова пропускать через себя триллионы событий ежедневно и гораздо быстрее обнаруживать в них признаки аномалий и иной несанкционированной активности, чем человек? Зачем нужен homo sapiens, которому еще и свойственно ошибаться, терять концентрацию, делать неправильные выводы? Аналитические системы и подсистемы (в различных их проявлениях) постепенно вытесняют человека, оставляя ему все меньше функций и дел.

Если посмотреть на современный рынок ИБ, то он уходит в облака и аутсорсинг. У многих продуктов появляется SaaS-версии, которые пока являются интересной, но все-таки опцией. Со временем же эта опция станет доминировать, а потом и заменит свои on-premise решения. Эта тенденция совсем не видна в России (у нас нет SaaS-решений по ИБ), но она очень хороша заметна на Западе. Классические производители программных и аппаратных решений по ИБ стали уходить в облака, предлагая своим заказчикам новые возможности по управлению ИБ. И это связано не только и не столько с желанием заработать, сколько с потребностями самих заказчиков, которые не в состоянии в круглосуточном режиме заниматься своей ИБ.

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

Что, все вот так плохо? И да, и нет. Я немного сгущаю краски, беря самый пессимистичный сценарий развития событий. Да, для него есть все предпосылки, но все-таки и 100%-вероятным его считать нельзя. С другой стороны, то, что происходит на мировом рынке, говорит именно о таком исходе. Подготовить нужное количество квалифицированных людей сегодня просто невозможно - гораздо эффективнее попробовать заменить их на "роботов", что я и наблюдаю, посещая различные мероприятия (Gartner, RSA, Cisco, InfoSecurity и т.п.).

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

Есть ли у вас план на такой случай? 

Я не буду делать никаких выводов - каждый их сделает сам. Просто задумайтесь, не откладывая решение этого вопроса "на потом". Скоро на рынке труда будет жестокая драка за место под солнцем и никакие прошлые заслуги и регалии не помогут.

Подробнее…

Почему лицензирование технологий - это не всегда хорошо с точки зрения ИБ

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

Лицензирование технологий - это популярный метод у разработчиков тех или иных технологий ускорить выпуск своего продукта на рынок. Далеко не всегда есть время, а иногда и компетенции на разработку функционала, который уже кто-то реализовал и готов им поделиться. Самый банальный вариант - использование open source компонентов при создании собственных решений. Кто-то берет целый Hadoop для своих решений, кто-то ограничивается обычной библиотекой OpenSSL. Результат один - мы задействуем чужие технологии в своих продуктах и затем предлагаем их заказчикам, которые обычно не сильно задумываются о том, из чего состоит купленное ими изделие и какие риски они должны учитывать при выборе ИБ-решений (да и ИТ тоже).

Возьмем уже старый, но близкий мне пример. Компания Cisco лицензировала у компании netForensics одноименную систему управления событиями безопасности, которую затем стала предлагать под новым именем Cisco SIMS (Security Information Management System). Мы ее некоторое время успешно продавали через свой канал продаж, но потом столкнулись с тем, что у компании netForensics сильно ухудшилась внутренняя ситуация - качество продукта снизилось, поддержка стала работать из рук вон плохо, число нареканий от заказчиков стало возрастать. А повлиять на чужой продукт мы были не в состоянии. Итог закономерен - мы прекратили сотрудничество с netForensics (с 2012-го года они переименовались в BlackStratus), а Cisco SIMS исчез из нашего прайс-листа. И для нас и для заказчиков риски были минимизированы, но ситуация все равно неприятная.

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

А теперь обратимся к отечественному рынку ИБ и посмотрим на сотрудничество “Код безопасности” с компанией Agnitum, которая лицензировала свои технологии и разрешила “Коду безопасности” встроить свой движок по борьбе с вредоносным кодом в Secret Net Studio. А потом компания Agnitum была куплена Яндексом, который не пожелал (и это его право) продолжать ранее заключенные договора лицензирования технологий Agnitum. Итог - “Код безопасности” потерял часть своего функционала и вынужден был в спешном режиме искать альтернативу, с которой все непросто. Антивирусный движок остался только один - зарубежный Nod32 от ESET, который не будет сертифицироваться в ФСБ и по высоким классам ФСТЭК. Модуль HIPS оказался потерян полностью и сейчас "Код безопасности" пытается написать его самостоятельно (что делать текущим пользователям - не совсем понятно).

Ситуация с “Кодом безопасности”, Agnutum и Яндекс не уникальна для российского рынка. Сейчас многие российские компании идут по пути лицензирования чужих (и не всегда российских) технологий. Кто-то WAF лицензирует, кто-то SIEM (например, OSSIM или ArcSight), кто-то антивирус (тот же Nod32), кто-то анализатор кода (например, Fortify), кто-то системы контроля доступа (какой-нибудь SSH Security Communications), кто-то системы управления идентификацией (например, Identity Manager). И дело тут не в отсутствии компетенций по разработке аналогичных решений. Просто в условиях, когда страна декларирует курс на импортозапрещение, зарабатывать на западных решениях становится сложнее, а ниша, в которую могут потечь денежные потоки, не уменьшается. Логично что у ряда разработчиков возникает идея по-быстренькому сваять “российский” продукт на базе уже имеющихся технологий (западных или отечественных). Я уже как-то писал про то, что это не совсем импортозамещение, но сейчас мне хотелось рассмотреть эту проблему под другим углом зрения.

Что будет, если разработчик приобретаемой технологии “загнется” или будет куплен более крупным игроком, который не захочет развивать это направление своей деятельности? Что будет делать производитель, использующий чужие технологии? А что будет делать потребитель? Вот возьмем, к примеру, Attack Killer от Infowatch. Продукт, который базируется на решениях четырех разных компаний - Infowatch Appercut, Infowatch Targeted Attack Detector (решение от Cezurity), Wallarm WAF и Qrator AntiDDoS. Когда в Интернет утек черновик этой статьи, Рустем Хайретдинов накидал мне еще фактов про Attack Killer, поэтому просто процитирую его: "На самом деле всё гораздо хуже - внутри Апперката есть SQLite, а внутри Валларма - ngnix. InfoWatch Traffic Monitor содержит десятки лицензируемых компонентов - СУБД Oracle или PostgreSQL на выбор, голосовые перехватчики от ЦРТ, OCR от ABBY, а скоро ещё и КППС, и т.п. Апперкату ещё сложнее - он пишется на Java, который принадлежит Oracle, который грозится запретить его лицензирование." Допустим, Wallarm, активно смотрящий на Запад, будет там куплен каким-нибудь IBM, Dell или Cisco, не имеющих в своем портфолио Web Application Firewall. Или Oracle все-таки запретит лицензирование Java Как это скажется на Attack Killer? Рустем пишет, что этот риск проработан на уровне договоров и там где это возможно, существуют резервные/дублирующие технологии. Тот же Oracle может быть заменен на PostgreSQL. В любом случае это тот риск, который стоит рассматривать до приобретения решения, а не после.

Но это не единственный риск лицензируемых технологий. Другой вопрос заключается в устранении уязвимостей в них. Тут впору вспомнить историю с уязвимостью Heartbleed в библиотеке OpenSSL, на базе которой построено немалое количество продуктов в мире, включая и российские. Среди них были и сертифицированные по требованиям ФСТЭК решения. И когда ФСТЭК обратилась к их разработчикам с просьбой сообщить об устранении серьезной дыры в сертифицированных решениях часть разработчиков ответила, что не имеет возможности Heartbleed устранить, так как у них нет компетенций в этой области, а код чужой и копаться в нем они тоже не умеют. История умалчивает, что стало с сертификатами на эти решения, но умалять от этого проблему не стоит. Если продавец не может устранить уязвимость в применяемых чужих open source компонентах (OpenSSL, Kibana, Elasticsearch, Hadoop, OSSIM, Snort и т.п.), то как это скажется на безопасности потребителя? Это второй из возможных рисков, о котором стоит, как минимум, помнить.

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

Подробнее…

Можно ли считать Snort отечественной системой обнаружения атак и может ли он защищать гостайну?

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

Но удивило меня не это (косяки или некоторые преувеличения в конкурентных сравнениях допускают все). Вопрос в другом. Как можно было при использовании разработанного в США Snort (кстати, не самой последней версии),

Фрагмент документации

при использовании американской базы сигнатур атак (а Emerging Threats, чьей базой пользуется "Детектор атак", принадлежит американской Proofpoint),

Фрагмент с сайта

говорить о том, что

Я даже сейчас вопрос с ОС (а там все построено на базе FreeBSD, OpenBSD, Linux и Windows) не поднимаю, а они явно разработаны не компаниях-"разработчиках" систем обнаружения вторжений. Тут хотя бы по движку IDS решить. Можно ли его называть разработанным в России, да еще конкретной компанией? Как мне кажется, нет! А уж по в отношении всего ПО и его составных частей тем более.

Кстати, когда я уже писал эту заметку, в голову залетела шальная мысль: "А как вообще американская Emerging Threats может продавать в России свою продукцию, которая используется в организациях, находящихся под санкциями?" Это ж риски для потребителя, который в определенный момент просто не сможет получать актуальные сигнатуры атак...

При этом все эти системы могут не только интегрироваться в ГосСОПКУ (это, кстати, 8-й Центр ФСБ вполне допускает), но и защищать гостайну.

Выводов никаких не делаю - делал еще в прошлый раз.

ЗЫ. Увы, но недавние дискуссии в Facebook по поводу переделанной под гостайну и местами неработающей так как от нее ждут ОС Astra Linux показывают, что даже с open source у нас до конца не смогли разобраться.

Подробнее…

Сказ о том, как о моем неутекшем пароле побеспокоились

Вчера я получил от Parallels письмо следующего содержания:

Вроде все понятно. Произошла компрометация большого числа почтовых учетных записей Яндекса, Mail.ru и Gmail. Некоторые компании, у которых пользователи регистрировались с указанием e-mail с указанных почтовых сервисов, решили побеспокоиться о своих клиентах и, кто-то просто предупредил о необходимости сменить пароль, кто-то решил сработать на опережение и заблокировал учетные записи, так сказать "во избежание".

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

Что сделал Parallels, решив побеспокоиться обо мне? Заблокировал учетку и попросил доказать, что я - это я. И вот дальше самое интересное. Я захожу по ссылке на сайт Parallels, где меня просят указать мой... якобы "скомпрометированный" e-mail. Зачем? Вот какой в этом потаенный смысл? Если мой почтовый ящик не скомпрометирован, то мне достаточно было бы прислать напоминание о необходимости более внимательно относиться к своей безопасности или попросить привязать мою учетную запись не только к e-mail, но и к номеру мобильного телефона или использовать другой механизм (тот же Google Authenticator).

 

Если же мой почтовый ящик скомпрометирован, а Parallels именно это и подозревает (иначе нафига было блокировать мою учетную запись), то зачем отправлять на скомпрометированный e-mail инструкцию и ссылку на восстановлению доступа? Получается замкнутый круг :-(

Спустя какое-то время я получаю на ту же самую почту стандартное письмо с ссылкой на смену пароля.

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

Собственно винить Parallels тут и сложно и должно. Сложно, потому что у них врядли есть мои контакты кроме e-mail. Должно, потому что давно стоило бы использовать многофакторную аутентификацию и не просто запросить у меня номер мобильного телефона (такое поле есть в профиле пользователя, но оно необязательное), но и использовать его для восстановления доступа к учетной записи. Но другим компаниям, которые используют регистрацию пользователей на своих сайтах стоит подумать над изменением процесса регистрации, а точнее механизма идентификации пользователя.

ЗЫ. Единственное, что меня смущает во всей этой истории - позиция CISO Parallels. Алексей утверждает, что восстановление пароля по описанной мной процедуре не зависит от компрометации почтового ящика и полностью безопасно. Возможно это и так, и от пользователей просто скрывается сверхсекретная и сверхзащищенная процедура идентификации пользователя скомпрометированного почтового ящика. Но вот гложут меня сомнения все-таки... 

Подробнее…

О риск-ориентированном подходе и статистике инцидентов ИБ в АСУ ТП

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

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

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

Подробнее…

Хакеры голубые, хакеры розовые, хакеры зеленые...

Вы думали, что тему хакеров-геев забыта? Ан нет. Никто не забыт и ничто не забыто. Но к хакерам-голубым (и розовым из Фемен) добавились хакеры-зеленые, которые после инцидентам с судном Гринписа "Арктик Санрайз" начнут донимать Россию всеми правдами и неправдами. Вот об этом среди прочего другого мы и говорили на круглом столе по информационной безопасности крупных спортивных мероприятий, который я модерировал на Инфобез-Экспо.

Сначала я описал объект защиты, т.е. современный спортивный объект с точки зрения применяемых на нем информационных технологий.

ИТ на современных спортивных объектах from Cisco Russia&CIS

Затем Олег Кузьмин (АйТеко) рассказал об основных угрозах ИБ в ходе проведения массовых спортивных мероприятий и их последствиях. Презентация изобиловала большим количеством примеров из практики, в т.ч. и с последнего Чемпионата мира по легкой атлетики, проходившего в Москве.

презентация спорт инфобез2013 from Oleg Kuzmim

Третий рассказ был посвящен репутационным рискам ИБ применительно к сочинской зимней Олимпиаде. Доклад был подготовлен Игорем Елисеевым (АИС), для которого это стало одновременно и дебютом за последние годы отсутствия презентационной практики. Игорь справился на 5, а мы узнали о высокоуровневой модели угроз, разработанной по просьбе Совета Федерации.

Infobez olimp2014 from Игорь Елисеев

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

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

Подробнее…

Писателям сплойтов посвящается...

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

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

Допустим безопасник-технарь совершил чудо и смог продемонстрировать ущерб от дыры на сайте в деньгах. Допустим он выбрал правильную методику, понятную бизнесу и принятую им. Допустим. Но возникает вторая часть утверждения "ай-яй-яй, какие последствия наступят". Речь идет о слове "наступят". Коль скоро мы говорим об угрозах или рисках, то одним из элементов этих понятий (помимо последствий или ущерба) является вероятность. Бизнес хочет видеть вероятность реализации риска использования уязвимости на сайте. А ее нет! В принципе нет! Точнее есть какие-нибудь отчеты E&Y, KPMG, CSI, OWASP; в них приводится статистика по использованию уязвимостей. Но это как средняя температура по больнице. Любой бизнес спросит: "А я-то тут причем? Почему у меня должна быть такая же вероятность? Может быть у меня и вовсе такого риска не наступит?" И ответить тут будет нечего - потому что мало кто тратит время на нормальный подсчет значения вероятности. Хотя методов немало.

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

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

Резюмировать можно просто: ПОКАЖИ ДЕНЬГИ, прежде чем обвинять бизнес в тупости и непонимании безопасности. Бизнес также считает тупым безопасника, который не понимает потребностей бизнес и не умеет с ним разговаривать на понятном бизнесу языке. В конце концов, именно бизнес платит зарплату или оплачивает договора. Стоит иногда прислушиваться к мнению бизнеса, а не тупо навязывать свое.

ЗЫ. Как показывает дискуссия в Twitter демонстрация value (в деньгах) пока не находит понимания у безопасников-технарей. Разрыв сохраняется. Безопасность остается в загоне.

ЗЗЫ. Вот еще одно доказательство тем, кто считает, что взлом компании (очень громкий взлом) как-то влияет на бизнес. Кстати, руководитель безопасности этой компании был назван CSO года ;-)

Подробнее…

Психология в деятельности CISO

Психология в деятельности CISO

View more presentations from Alexey Lukatsky.

Подробнее…

Безопасность электроэнергетики

Про безопасность электроэнергетики в разрезе защиты SmartGrid и АСУ ТП я уже неоднократно писал. Но тема не теряет своей актуальности, о чем говорит возрастающее число зарубежных материалов по этой теме. Например, большой исследовательский отчет Pike Research о безопасности SmartGrid, в котором не только озвучивается сумма инвестиций в это направление (18 миллиардов долларов до 2018 года), но и говорится, что 63% этих ресурсов пойдут на защиту АСУ ТП, используемых в электроэнергетике.

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

Многие же вообще не понимают специфики и не знают о существующих наработках в области защиты АСУ ТП. Например, в марте этого года Министерство энергетики США выпустило проект документа "Electricity SubSector Cybersecurity Risk Management Process". Документ на 89 страниц. Выглядит очень достойно - подробно расписаны все шаги управления рисками, но... не для АСУ ТП. Такое впечатление, что авторы взяли за основу NIST Special Publication (SP) 800-39 "Managing Information Security Risk" и даже не удосужились применить положения 800-39 именно к теме критических инфраструктур. В тексте указано, что обычные ИТ-системы и АСУ ТП имеют разные требования по ИБ. И стоят перед ними немного разные задачи и цели в контексте ИБ. По сути авторы приравняли обычные ИТ и АСУ ТП и написали документ про управление рисками первых, но не вторых.

Сам документ ссылается на NISTIR 7628 "Guidelines for Smart Grid Cyber Security" (часть 1, часть 2, часть 3 и часть 4) и стандарты по ИБ Североамериканской электрической корпорации (NERC). А их там, к слову, 20 стандартов. И доступны они всем и никакого грифа на них нет; в отличие от наших документов по КСИИ. Но дело не в этом. Проект документа американского Минэнерго ни слова не говорит о ISA99, основном наборе стандартов в области безопасности систем управления технологическими процессами. Напрашивается вопрос: "А авторы проекта документа вообще имели дело с АСУ ТП?" Остается надеяться, что практика опубликования проектов документов и привлечения сообщества к доработке, известная в США многие годы, даст свои плоды и эксперты донесут до Минэнерго проблему разработанного документа. Хотя как описание процесса управления общими рисками ИБ документ интересен.

И пока отношение к данной теме не изменится, мы будем регулярно видеть вот такие новости.

Подробнее…

Как считать риски?

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

Я к теме оценки рисков не обращался уже года два. Мне казалось я все сказал еще на InfoSecurity 2008. Но видимо придется тезисно повторить. Как было сказано в одной статье: "Анализ рисков, оценка их вероятности и тяжести последствий похожа на посещение игроками Лас-Вегаса - зал общий, а система игры у каждого своя". И действительно. Методов оценки вероятности существует большое пяти (я знаю семь). Методов оценки ущерба - больше трех десятков. Методик оценки рисков вообще под полсотни. А результат все равно никого не устраивает. Особенно бизнес, которому результат такой оценки пытаются втюхать.

За 2 года ситуация совсем не изменилась. Оценка рисков как была больше исскуством, чем наукой, так и осталась. Если не сказать больше. Оценка рисков ИБ сегодня - это шаманство. Резюме было подведено давно, в стандарте ISO 13335, в котором было сказано, что лучшая методика оценки рисков та, которая устраивает все стороны - и того, кто считает риски, и того, кому их демонстрируют. А уж какая она, совсем неважно. В прошлом ноябре, на конференции "Ведомостей", мне понравилось выступление Виталия Задорожного, директора по операционным рискам Вымпелкома. На вопрос о том, как он общается с руководством, он ответил просто - есть три сценария. Либо надо показать, что дает ИБ бизнесу (это всегда под вопросом). Либо риски от невыполнения требований должны быть катастрофическими. Либо руководство должно доверять своему CRO/CSO/CISO. И вот в последнем случае мнение оценщика и есть та самая методика оценки, которая устраивает всех.

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

Подробнее…

Банки богатые - пусть платят!

Именно это известное высказывание бывшего первого зама 8-го Центра ФСБ напомнило мне норму нового финансового законодательства.

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

Что гласит данная норма ст.9 ФЗ "О национальной платежной системе" (вступает в силу через 18 месяцев после вступления в силу ФЗ)? А гласит она всего-навсего, что в случае любой хакерской атаки и незаконного снятия средств со счетов клиентов, банк будет обязан вернуть украденные деньги.

Приостановить мошеннический платеж (при условии, что его своевременно выявили) банк не имеет права по банковским правилам - это может сделать только клиент. По закону об НПС банк обязан перевести средства незамедлительно. Т.к. снятие средств со счетов обычно проводится в очень сжатые сроки и с момента перевода до момента обналичивания может пройти всего 3-4 часа, то большинство клиентов не в состоянии своевременно дать указание банку о незаконном списании средств со счета. Нередко деньги списываются за 20-30 минут до рейса и банк уже не в состоянии их своевременно вернуть.

Что у нас получается в этом случае? Банк всегда в проигрыше! Остановить мошенничество он не имеет права, а по закону деньги необходимо вернуть проштрафифшемуся клиенту.

Немного спасает ситуацию ч.13 ст.7 закона об НПС. Согласно ей банк обязан незамедлительно после перевода средств уведомить клиента об исполнении распоряжения на перевод. Об этом же говорит и ч.4 ст.9. Если клиент не сообщит в однодневный срок о том, что распоряжение незаконное, то дальше вступают в силу уже условия договора между клиентом и банком, а не требования закона. Однако по ФЗ банк "обязан обеспечить возможность направления ему клиентом уведомления об утрате электронного средства платежа и (или) о его использовании без согласия клиента". Кто его знает, что имел ввиду законодатель. Могу предположить, что речь идет о опубликовании контактов для связи и обеспечение бесперебойной работы этих контактов. В любом случае, банку остается надеяться на то, что он уведомил клиента, который забыл сообщить о незаконном списании средств. Только в этом случае банк освобождается от необходимости возмещения украденных денег.

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

ЗЫ. Кстати, в ч.4 ст.9 прописан срок хранения информации по электронным платежам - эту норму можно использовать и в контексте сроков хранения ПДн.

ЗЗЫ. Банк в соответствии с ч.3 ст.9 теперь обязан до заключение договора "информировать клиента об условиях использования электронного средства платежа, в частности о любых ограничениях способов и мест использования, случаях повышенного риска использования электронного средства платежа". Т.е. теперь это уже не просто пожелание - сообщать клиенту о рисках и требованиях по ИБ, но и обязанность банка.

Подробнее…

Анализ рисков по графу атак

NIST вновь порадовал интересным документом "Security Risk Analysis of Enterprise Networks Using Probabilistic Attack Graphs", посвященном использованию вероятностных графов атак в анализе рисков (я этот метод рассматриваю в курсе по моделированию угроз). Интересно, что этот метод даже автоматизирован в ряде программных продуктов SIEM-класса (в России, правда, неизвестных).

Подробнее…

Новое руководство NIST по оценке рисков

NIST опубликовал проект впервые пересмотренного рукодства по проведению оценки рисков - SP 800-30 "Guide for Conducting Risk Assessments". Это пятый документ NIST в серии по управлению рисками. Если хотите высказать свои замечания по этому проекту, то до 4-го ноября это может сделать любой желающий.

Подробнее…

Как разные культуры относятся к риску?

Брюс Шнайер опубликовал ссылку на интересное исследование "The Cultures of Risk Tolerance", которое показывает разницу в уровне терпимости к риску в разных странах и культурах. В исследовании приняли участие 4000 человек из 23 стран мира; Россия, к сожалению, в список не попала. Если сразу перейти к выводам, то уровень терпимости к риску достаточно высок в странах с низким уровнем доходов (т.е. и в России тоже). Высокий уровень означает нетерпимость и желание снизить риски или переложить их на кого-то. В странах с высоким уровнем доходов, в странах с преимущественно индивидуалистичным стилем жизни, в странах, в которых граждане живут в определенной гармонии с собой и окружащим миром уровень терпимости низкий, а значит граждане более доверчивы, чем, собственно, и пользуются многие мошенники.

Подробнее…

Интересные документы по безопасности Web и Social Media

За последнее время наткнулся на несколько интересных документов по ИБ. Информацию о них я кидал в Twitter, но не факт, что все видели эти ссылки.

Первый документ, а точнее его проект, подготовлен OWASP (The Open Web Application Security Project). Документ называется "Application Security Guide For CISOs" и это название говорит само за себя. Собственно сам документ сейчас как раз и создается ;-) Содержание документа ориентировано именно на руководителей ИБ и почти не содержит техники - один бизнес:

• выделение бюджета на защиту приложений
• измерение защиты приложений - потери, бизнес-воздействие, оптимизация затрат, ROI
• ценность информации
• выбор проблем, которые требуют внимания и выделения бюджета в первую очередь
• метрики.

Первые три пункта уже описаны; остальные в процессе.

Второй документ "SOCIAL MEDIA RISKS AND MITIGATION" описывает риски и стратегию управления ими для социальных медиа (социальные сети, блоги, твиттер и т.д.). Документ очень подробный и описывает social media с трех сторон - использование для общения с заказчиками, использование сотрудниками в личных целях и использование сотрудниками за пределами компании. И хотя документ ориентирован на финансовые организации, он будет полезен и всем остальным.

Мне понравился раздел по compliance, который описывает применение social media с точки зрения различных нормативных актов (иностранных) - в контексте персданных, в контексте законодательства о труде, в контексте PCI DSS, в контексте законодательства о рекламе и т.п.

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

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

Резюмируя, могу сказать, что оба документа достойны для изучения. Они могут лечь в основу собственной стратегии использования social media в организации.

Подробнее…

О выборе актуальных угроз

Время от времени я обращаюсь к теме психологии в ИБ и вот снова. В курсе про моделирование угроз я делаю экскурс в психологию восприятия риска, которая объясняет, почему мы принимаем те или иные решения, почему в одинаковой ситуации разные люди составляют разные списки разных угроз. И вот новое доказательство - статья (http://www.kommersant.ru/doc/1638757), показывающая особенности выбора и принятия решения в зависимости от культурологических особенностей разных наций.

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


- Posted using my iPhone

Подробнее…

Киберапокалипсис: как это показывает ТВ

В середине апреля пригласили меня вновь на телевидение; теперь на ток-шоу "Слово за слово" МТРК "Мир". Программа была посвящена киберапокалипсису. Достаточно забавная передача получилась. В отличие от РБК ТВ в этот раз был непрямой эфир, а запись. Совершенно иной формат, иной стиль, иная внутренняя кухня.



ЗЫ. Теперь мне стало понятно, как снимают такие ток-шоу и что за люди приходят в них участвовать со стороны аудитории ;-)

Подробнее…

У Leta новый проект

Компании, входящие в группу Leta продолжают радовать своей аналитикой. Совсем недавно Group-IB выпустила отличный отчет по состоянию "русской" компьютерной преступности, в котором рассматриваются основные угрозы, связанные с различными видами хакерской активности, анализируются основные услуги, предлагаемые компьютерной мафией, даются оценки доли «русского» сегмента общемирового рынка киберпреступности, а также приводятся прогнозы относительно тенденций развития данного рынка в этом году.

И вот у Leta новый отчет - "Информационная безопасность. Обзор Рисков. Ритейл". Если быть точным, это первый документ в рамках проекта по выпуску обзоров отраслевых рисков информационной безопасности. В целом неплохо, но я обратил внимание, что при ориентации на описании рисков, в документе не приводится ни оценка их вероятности, ни оценка размера ущерба. Хотя бы в качественной форме, чтобы иметь возможность приоритезировать описываемые риски. Но все может поменяться - Leta предлагает всем заинтересованным лицам принять участие в корректировке отчетов.

Подробнее…

57-ФЗ снова в прицеле ньюсмейкеров

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

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

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

Остается ждать, чем все-таки завершится эта история...

Подробнее…