31.1.19

Алаверды Дмитрию Кузнецову про сертификацию "комбайнов" и UTM-решений

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

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

Я начну с того факта, что сертифицируется обычно законченное решение, а встраивается отдельный модуль (например, антивирусный движок). Например, есть у меня Kaspersky Endpoint Security for Windows, который сертифицирован как антивирус (и не только). Он обладает набором функций, начиная от обнаружения вредоносного кода и обновления и заканчивая системой управления, контролем состояния и т.п. Так вот когда я хочу встроить антивирус в свой продукт, я беру не весь антивирус "из коробки" с определенными контрольными суммами, а только его часть, которая позволит моему продукту обнаруживать вирусы. И, например, систему управления я выброшу, так как антивирусный движок будет интегрирован с моей системой управления. И вот уже получается, что антивирусный движок не выполняет часть требований по безопасности и у него также не совпадают контрольные суммы с тем решением, на которое и выдан сертификат ФСТЭК. Поэтому считать встраиваемый антивирусный движок сертифицированным я никак не могу.

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

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

Представим, что вы разработали системы класса Endpoint Protection (EPP), которая включает в свой состав антивирусный модуль. Вы не имеет экспертизы в разработке антивируса, поэтому заключаете соглашение с Лабораторией Касперского, которая вам предоставляет свою прекрасную продукцию. Так как вы разработали средство защиты сразу для двух платформ - Windows и Linux (тему с форками Linux я оставлю в стороне), то вы взяли от ЛК их два продукта - KES for Windows и KES for Linux. Обратите внимание, эти два продукта получали свои сертификаты ФСТЭК в разное время и продлевали их в разное время. Поэтому и сроки окончания их действия тоже разнятся. Если вы разработали свое средство защиты в 2015-м году и 29 февраля 2016 года (срок взят с потолка) получили сертификат, то срок его действия должен закончиться через 3 года (обычно). В такой ситуации никакой проблемы нет - оба сертификата на KES перекрывают срок действия сертификата на ваше средство защиты. А теперь представим, что вы решили (а почему бы и нет) продлить срок действия сертификата своего решения еще на 3 года. ФСТЭК пошла вам на встречу и... вы надеетесь, что получите сертификат, продленный до 29 февраля 2022 года. Но... Согласно правилам ФСТЭК сертификат вам будет выдан исходя из срока сертификата, который заканчивается раньше всех. В данном случае это будет 25.11.2019 (по сроку KES10 for Windows).


Если же вы подождали бы до конца января, то вы могли бы встроить в свой EPP новую версию KES11 for Windows, которая была сертифицирована 22 января 2019 года. Правда, тут речь идет уже о новом продукте... Я не знаю, как будет трактовать ФСТЭК эту ситуацию. Если они отнесутся к встраиванию нового продукта лояльно (а почему бы и нет - производители-то свои, патриотически настроенные), то... срок действия продленного сертификата на ваше средство защиты будет заканчиваться... нет, 22 января 2024 года, и не 29 февраля 2022 года, а 18 ноября 2020 года. Именно тогда заканчивается срок действия сертификата на KES10 for Linux.

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

30.1.19

12 причин, почему бизнес "не видит" ИБ, или кибербезопасность Шредингера

А продолжу-ка я тему с чеклистами и визуализацией :-) Тем более, что вчерашняя тема зашла очень хорошо - Андрей Прозоров даже флешмоб замутил и несколько человек в Фейсбуке на него уже откликнулись, опубликовав свои чеклисты CISO. Сегодня будет список из 12 причин, описывающих почему бизнес "не видит" ИБ и не ценит ее. Хотя после прочтения отчета anti-malware, в котором написано, что 63% компаний имеют бюджет менее полумиллиона рублей, становится понятно, почему. Это же в пределах погрешности для многих предприятий. За что любить ИБ, которая и не делает ничего (ибо не на что), и не тратит ничего, и не приносит ничего. Кибербезопасность Шредингера, которая вроде бы и есть, а вроде бы и нет :-(
Ну а чтобы заметка не выглядела совсем уж куце, прокомментирую эти причины.
  1. Вы считаете, что лучше знаете, что нужно бизнесу. Я поставил этот пункт первым, как и во вчерашнем первым стоял пункт, что вы знаете, что нужно бизнесу. Но вчера это звучало как выполненная после общения с бизнесом задача, а сегодня - как частая ошибка многих безопасников, считающих, что именно они могут диктовать своему работодателю, что ему нужно с точки зрения кибербезопасности.
  2. Вы прекрасно защищаете свою организацию, но совершенно не умеете “продать” это наверх. Говорите со своей аудиторией на ее языке! Я про это писал и говорил уже много раз - повторяться не буду (хотя одну ссылку приведу). Но планирую в блоге писать больше про это и публиковать больше примеров того, как можно доносить до бизнеса свою задачи и свои достижения.
  3. Вы не получили вовремя грамотную помощь или ее не было вовсе. Очень мало кто способен самостоятельно разобраться в том, чем живет бизнес, что ему нужно и как работают бизнес-процессы. В ВУЗах этому не учат, MBA безопасники пока массово не посещают (дорого). Отсюда и результат.
  4. Вы не делегируете. Один в поле не воин. В крупной организации, да и в небольшой тоже, нельзя все делать самому. Нужно уметь делегировать часть задач подчиненным, беря на себя контроль их исполнения. Наймите правильных сотрудников или отдайте задачи на выполнение подрядчикам. Все делать самому - значит не успеть все. Так делает бизнес, этого он ждет и от безопасника. 
  5. У вас нет бизнес-плана/цели/миссии, включая план действий на случай провала. Ну тут вроде все понятно и так :-)
  6. Вы ничем не отличаетесь от внутренних конкурентов, которые тоже хотят внимания руководства и бизнеса. Конкуренция сопровождает почти любой бизнес (только РЖД у нас монополист в России :-), как снаружи, так и внутри организации. На что потратить деньги? На кофе, туалетную бумагу, картриджи для принтера или безопасность? Надо уметь бороться с внутренними конкурентами; иначе проиграешь!
  7. Вы не относитесь к своей работе всерьез. Без комментариев.
  8. Вы тратите неоправданно мало на безопасность, стараясь сделать все подешевле и попроще. Бизнес умеет считать деньги, но это не значит, что он готов покупать дешевку. Он хочет получить то, что нужно, и с предсказуемым результатом. Нужен миллион? Хорошо. Но обоснуйте. Нужно десять? Обоснуйте. Можете сделать все бесплатно? Обоснуйте (бесплатный сыр только в мышеловке и чтобы бесплатное решение заработало возможно нужен соответствующий недешевый персонал).
  9. Вы тратите неоправданно много на безопасность. А это обратная сторона медали. Вы приносите бизнесу счет на проект по ПДн стоимостью в полмиллиона рублей. Ну ОК? А что теряет бизнес от невыполнения законодательства? 10 тысяч рублей? Дебет с кредитом не сходится - никакого смысла в такой инвестиции нет. Затраты в 50 раз превышают возможные предотвращаемые потери? Ну-ну...
  10. В вашей стратегии ИБ нет фокуса - вы пытаетесь защитить все. Защитить все нельзя - нужна концентрация на ключевых задачах и проектах. Нет ее, значит вы не умеете выделять главное, что и сказывается на отношении бизнеса.
  11. Вы не умеете сотрудничать. Научитесь общаться с бизнес-подразделениями, чтобы получать от них данные для своей работы, чтобы заручиться их поддержкой при защите проектов, чтобы понять их нужды, чтобы помогать им, а не мешать. 
  12. Вы склонны недооценивать, сколько времени и денег потратите, пока ваша служба встанет на ноги. Неумение считать деньги и время - это плохой знак для вас и для бизнеса. Как вам можно поручать задания и выделять бюджеты, если вы не умеете ими распоряжаться?
Если приглядеться внимательно, то эти 12 причин совпадают с вчерашним чеклистом, который направлен на их устранение. Здравый смысл подсказывает, что начать надо было с проблем, чтобы потом наметить пути их решения, но я решил немного нарушить логику и сделал наоборот. И получилось хорошо - мне, по крайней мере, понравилось как повернулась тема, - дискуссия, флешмоб, новые идеи и мысли...

ЗЫ. Тут можно скачать файл в PDF.

29.1.19

План CISO на 2019 год (чеклист)

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


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

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

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

28.1.19

В плену иллюзий относительно сертификации по требованиям ФСТЭК

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

Многие заказчики, партнеры, да и производители тоже, живут в плену иллюзий касательно темы сертификации по требованиям безопасности (не исключаю, что и я тоже). Они по-прежнему ориентируются на позицию регулятора 3-4-хлетней давности и ничтоже сумняшеся разносят эту позицию по рынку, как сеятель в известном романе "12 стульев" Ильфа и Петрова. Хотелось бы прокомментировать некоторые из этих высказываний, опираясь на то, что часто звучит на мероприятиях ФСТЭК из уст ее руководителей, а также развивая темы, поднятые мной ранее на страницах блога (тут, тут и тут).


Обновление в реальном времени из-за зарубежа

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

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

Встраивание антивируса в свои продукты

Не секрет, что многие отечественные производители встраивают в свои решения чужие модули. Обычно речь идет об антивирусе, а точнее об антивирусном движке, который в сетевом решении представляет собой возможность поиска вредоносных файлов в сетевом трафике, а в хостовом решении - ищет следы малвари на диске или в памяти. Например, "Код безопасности" объявил год назад о сотрудничестве с Лабораторией Касперского, а MultiScanner от Positive Technologies включает в свой состав сразу несколько антивирусных движков. Вообще это одна из стратегий развития продуктов по ИБ (купить кого-то, разработать свое или интегрироваться с кем-то), которая позволяет быстро удовлетворить задачи своих заказчиков. Так вот согласно требованиям ФСТЭК, чтобы сертифицировать такое решение на класс 5 и выше, заявитель обязан представить исходные тексты каждого из модулей. Без этого сертификация конечного решения невозможна.

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



Практическая невозможность сертификации UTM и NGFW

Схожая ситуация с UTM-решениями и NGFW. Чтобы сертифицировать целиком продукт данного класса, вы должны отдать на проверку все модули (МСЭ, СОВ, АВЗ, URL-фильтрацию, VPN и т.п.). И проверяться такой продукт будет на соответствие отдельным РД (на МСЭ, на СОВ, на антивирусы и др.). Если на какой-то функционал нет РД, вы должны в задание по безопасности включить соответствующий функционал. Иными словами вы не можете иметь в рамках сертифицируемого продукта несертифицированные компоненты. Или все, или... А что или? Регулятор считает, что компонент, который не будет сертифицироваться должен быть исключен из продукта. На логичный вопрос, а может просто не активировать его лицензией (например, в NGFW купить только функционал контроля приложений, без обнаружения вторжений и антивируса) регулятор дает закономерный ответ - низззяяя, а вдруг в непроверенном коде есть вредоносная составляющая?

Вывод 3. Либо отказаться от NGFW/UTM и использовать набор отдельных продуктов, легко сертифицируемых по отдельным РД, либо расширять область сертификации, увеличивая время на сертификацию (и инспекцию) и стоимость решения.

Шифрование канала управления

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

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

Неопределенность с решениями без гарантийного обслуживания

Дальше будет две неопределенности, связанные с новыми требованиями ФСТЭК из приказов по КИИ, которые требуют использовать только те средства защиты, которые имеют действующую техническую и гарантийную поддержку. И вот тут возникает два вопроса. Что делать с open source решениями, которые не имеют никакой официальной поддержки со стороны... кого? Ни производителя, ни службы поддержки, ни договоров (кроме оферты без ответственности). Если верить обзору с anti-malware.ru, то у 63% компаний бюджет на ИБ составляет менее 500 тысяч рублей в год, что ставит перед организацией вопрос о необходимости применения решений с нулевой стоимостью. Open Source подходит для этого лучше всего. Но нельзя :-( Наверное.

Аналогичная неопределенность с ПО, которое снято с поддержки. Например, на многих объектах КИИ в промышленности, энергетике и др. до сих пор используется Windows 2000, снятая с поддержки в 2010-м году. Так можно ее теперь использовать или нет? И если нет, то что делать?


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

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

25.1.19

Анализ реестра сертифицированных ФСТЭК в 2018-м году средств защиты информации

Вчера на портале anti-malware.ru вышла первая часть обзора российского рынка ИБ, которая вызывает лично у меня вопросы (у 63% компаний в России бюджет на ИБ меньше 500 тысяч рублей????), но которая при этом ставит перед собой цель проанализировать общее (и оно, судя по отчету, удручащее) состояние ИБ в нашей стране. Я же параллельно провел уже ставшее традиционным исследование реестра сертифицированных ФСТЭК в 2018-м году средств защиты информации.

Если сравнивать результаты с 2017-м годом, то может сложится впечатление, что ситуация хуже не стала, а местами даже лучше. Общее число выданных за год сертификатов выросло на 18%, а число сертификатов на иностранные решения выросло на 2%. Но на самом деле ситуация немного иная. Например, 77% всех сертификатов у "иностранцев" выдано на решения Cisco. Да, мне, как работнику Cisco, приятно видеть доминирование своей компании, но в целом картина получается той, которую я предсказывал в прошлом году - "иностранцы" уходят с рынка сертифицированных решений, не имея возможности соответствовать все более жестким требованиям регулятора. В списке сертификатов за 2018-й год я не увидел ни одного сертификата от Check Point или Fortinet, а они были достаточно агрессивны в части выполнения требований своих продуктов требованиям ФСТЭК в прошлые годы. Да, на продукты этих компаний действующие сертификаты еще есть, но не на текущие версии ПО (некоторое ПО уже не продается и не поддерживается).


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


С момента введения санкций против России и начала курса на импортозамещение прошло уже почти 5 лет. Достаточно большой срок, чтобы российские производители выпустили аналоги иностранным решениям по ИБ. Интерес со стороны заказчиков есть. Поддержа государства (не деньгами, так нормативкой) тоже есть. Конкуренция снижается. А рынок так ничем и не может заполнить возникший вакуум :-( Лидером по числу выданных сертификатов является направление межсетевых экранов, коих получено 22% от общего числа бумажек с голограммой. В то время как весь мир уже давно бороздит мировой океан движется в сторону прикладной ИБ, занимается решениями по ИБ на блокчейне и искусственном интеллекте, борется с целевыми угрозами, мы по-прежнему основную ставку в защите делаем на межсетевые экраны :-( Правда, стоит снова отметить, что 78% сертификатов на МСЭ выдано на продукцию Cisco. А вот сегмент, который рванул с прошлого года - это системы обнаружения вторжений - их стало больше в три раза. Причем 78% всех сертификатов - это российская продукция. Это, на мой взгляд, тоже объяснимо. Бери иностранные Snort, Surricata или Bro и строй на них "свою" IDS. Затрат минимум - один профит. Можно даже сигнатуры свои не писать, а брать чужие.


Еще ряд интересных наблюдений - из сертифицированных ОС (а их 4), три были иностранного происхождения. Некоторые решения по старинце сертифицировались как СВТ, хотя являлись по сути либо средствами защиты базами данных, либо операционными системами. Кстати, средств защиты СУБД, сертифицированных по ТУ или НДВ, было больше одного (4, если быть точнее). Новый WAF в реестре появился только один, средств защиты виртуализации - три, средство анализа кода - одно, недоSIEM (от СерчИнформа и Ankey) - два, средств анализа защищенности - тоже два.

Кстати, мне можно возразить, что отсутствие новых сертификатов в 2018-м году может означать, что решение было сертифицировано в 2017-м и поэтому, при сроке действия сертификата в течение 3-х лет, оно не требует обновления бумаги от регулятора. Отчасти это так, но... А как же новые версии ПО? Или их за год так и не появилось?

Новых выводов не будет - сделанные год назад подтверждаются. Иностранные решения из сегмента сертифицированных выживают, российских решений больше не становится; закрыть все потребности заказчиков и все пункты из 17/21/31/239 приказов они не могут. Что делать заказчикам, не совсем понятно. Остается вспомнить только птицу Говоруна из мультфильма "Тайна третьей планеты": "Держаться нету больше сил..." :-)

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

22.1.19

Почему хостовые средства защиты не так хороши, как их описывает Сергей Солдатов :-)

Возвращаюсь к давно забытому формату, когда блогер не согласен с блогером и начинает с ним заочно спорить (правило двух блогеров от Сергея Борисова). Вот и я сегодня хочу поспорить с Сергеем Солдатовым, который позавчера написал заметку, в которой зачем-то противопоставил сетевые и хостовые средства защиты и стал доказывать, что хостовые лучше/эффективнее сетевых. В качестве одного из доводов Сергей ссылался на матрицу MITRE ATT&CK, которая описывает поведенческие индикаторы и в которой хостовых индикаторов в пять раз больше, чем сетевых. Не ставя под сомнение арифметику Сергея и с уважением относясь к MITRE ATT&CK хочу только отметить, что матрица техник, тактик и процедур для Windows, то есть для хоста, по определению будет содержать больше хостовых индикаторов, чем любых иных :-)

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

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


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

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

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


ЗЫ. Отчет Forrester с приведенной выше статистикой о важности автоматизации и интеграции средств защиты можно скачать тут.

17.1.19

Что общего между ИБ и кухней?

Есть три вещи, которые меня раздражают в российских новогодних праздниках - безделье (но я научился с ним бороться), фейрверки в новогоднюю ночь до 4-х утра и бесконечная еда (кого-то еще раздражает постоянные возлияния горячительными напитками, но не меня). Вот про еду мы сегодня и поговорим :-) Когда-то я написал несколько заметок, которые проводили параллели между ИБ и ремонтом, поясом верности, женщиной, медициной, футболом, автомобилем и, наконец, фауной. Это было несколько лет назад и я решил вернуться к теме аналогий, проведя параллели между ИБ и кухней.
  1. Вы готовите блюда. Будучи шеф-поваром, ваша задача приготовить блюдо, которое устроит ваших клиентов, имеющих совсем разные вкусы и разные потребности. Так и в ИБ - ваша служба должна удовлетворить их все. У кого-то изысканный вкус, у кого-то его и вовсе нет; кому-то нужны специфичные блюда по ИБ, а кого-то устроит и обычный фастфуд. При этом именно шеф службы ИБ отвечает за все.
  2. У вас должно быть меню. Когда вы приходите в ресторан, вы врядли самостоятельно набираете ингредиенты и указываете поварам, как их готовить (хотя такие фишки у ресторанов бывают). Вот и в ИБ вам нужно меню, в котором будут ваши фирменные блюда, то есть сервисы ИБ, которые должны удовлетворять потребности клиентов. При этом, в зависимости от "высоты" вашей кухни у вас будут либо только типовые "блюда" - борьба с DDoS, контроль утечек, защита периметра, антивирус и т.п., либо вы сможете приготовить и рецепты высокой кухни - безопасность промышленных систем, защита ERP, BYOD, DevSecOps и т.п.
  3. Вам нужны правильные ингредиенты. Качество ваших блюд зависит от ингредиентов - их качества, свежести, количества. А что является ингредиентом в ИБ? Данные, которые позволяют принимать нужные решения - события ИБ, инциденты, атаки, потоки, транзакции и т.п. От того, насколько они полны и вовремя поданы и будет зависеть ваше блюдо. Вот нет у вас событий с облачной инфраструктуры и вкус вашей безопасности уже не тот. А если у вас Netflow, то в вашем меню будут отсутствовать "блюда", связанные с внутренней ИБ. Важную роль играет и комбинация этих ингредиентов. Например, данные от оконечных устройств, скоррелированные с данными Netflow, взятые с существующей сетевой инфраструктуры, позволяют детектировать сложные атаки, а решения UEBA так и вовсе не могут функционировать без набора разных данных - от ПК, сети, СУБД, приложений и т.п.
  4. Вам нужны квалифицированные повара разных специализаций. Вы смотрели сериал "Кухня"? Там повара имеют свою специализацию - кто-то кондитер, кто-то по мясу, кто-то по рыбе специализируется. В других ресторанах есть также сомелье, бариста и даже вителье (специалист по сигарам). В ИБ все тоже самое - для приготовления правильных блюд нужны специалисты разного профиля - аналитики, криптографы, писатели политик, реверсеры малвари, специалисты по расследованию и реагированию на инциденты и т.п. И все они должны быть квалифицированными и, более того, регулярно повышать свою квалификацию и компетенции.
  5. Шеф-повар. Какие бы ингредиенты и повара у вас не были, кухню "играет" шеф-повар. Именно от него зависит, получит ваша кухня звезду Мишлена, не будет иметь наград, но будет славиться среди клиентов, или при наличии огромных ресурсов ваша кухня будет достойна только привокзальной столовки где-нибудь на перегоне на Кольском полуострове. Так и с CISO, от которого зависит правильный замес всех элементов - данных, безопасников, средств защиты и т.п. 
  6. Вам нужна правильная посуда! Правильная, а не дорогая или широко разрекламированная. Понятно, что иногда это синонимым, но все-таки эти понятия неравнозначны. Так и в ИБ - вам нужные разные инструменты для аудита, инвентаризации, построения векторов атак, моделирования угроз, блокирования и обнаружения разных типов атак, реагирования на инциденты, мониторинга и т.п. Недорогой инвентарь (open source) может быть компенсирован классным поваром, а слайсеры или наборы поварских ножей (SOAR, SIEM, UEBA, NTA, CASB и др.) могут нивелировать некоторые слабости поваров.
  7. Помещение. Кухня - это еще и помещение, от правильной расстановки мебели в которой, а также от вентиляции, освещения, давления, наличия окон и т.п. зависит очень многое. Помните, я писал про особенности дизайна и проектирования помещений для Security Operations Center (SOC)? Эта заметка неплохо показывает важность этих вопросов в обеспечении ИБ. Комнатушка, в которой толкутся и сидят на коленях друг у друга безопасники, явно не делает их работу легче (хотя и сближает).
  8. Рецептура. Моя жена говорит, что я достиг идеала в приготовлении шашлыка (мне и самому нравится :-) и это не случайно. Я не являюсь кулинаром от бога, просто строго соблюдаю рецептуру. Точное количество ингредиентов, точное время приготовления, точная последовательность действия, точная подготовка мяса и маринада. Вот и в ИБ самодеятельность и хаотичность вредят результату. Нужна книга рецептов ИБ, то есть то, что иностранцы любят называть словом Playbook и Runbook. Неслучайно в названии многих книжек по ИБ или презентаций часто используют слово cookbook (кулинарная книга) или recipe book (книга рецептов). Кстати, время приготовления блюда очень важно и в ИБ - долгое расследование или несвоевременное реагирование влекут за собой ущерб, нарушение сроков внедрения системы защиты также влечет за собой ущерб, нарушение сроков согласования договора может привести к прекращению срока действия лицензии на систему защиты и ее останову, то есть опять к ущербу.
  9. Анализ трендов. Вы замечали, что как и в модной индустрии, в ресторанном бизнесе есть свои течения, свои новинки, свои "горячие" блюда, которые вдруг появляются сразу во многих местах? Да, в кулинарии тоже важно отслеживать тенденции на рынке и своевременно им следовать их. В ИБ все тоже самое - анализ трендов по ту сторону баррикад (Threat Intelligence), тенденций в области технологий ИБ, в области законодательства и т.п.
  10. Вы гоняетесь за "звездами Мишлена". Люди (и организации) падки на похвалу и награды. Это касается шеф-поваров, ресторанов, директоров по ИБ и ИБ-проектов. У нас в отрасли нет своего "красного гида Мишлена", но зато есть различные отраслевые награды - SC Award, Best Security Blogger, Top100 CISO, "Маяк безопасности", ЗУБР, "Информационная безопасность банков" и т.п. 
  11. Проверки. Рестораны, как места общественного питания и обслуживания населения, постоянно проверяют - санэпидемстанция, налоговая, пожарники, и куча других надзорных органов. Да-да, вы поняли, куда я клоню. В ИБ тоже полно своих надзорных органов - ФСТЭК, ФСБ, РКН, ЦБ и др.
  12. Правильная подача. От того, как вы подадите свое блюдо (блюда) зависит отношение к вам клиентов. Их лояльность, их желание поделиться с вами деньгами и желание посещать вашу кухню снова и снова. Так и в ИБ - от того, как вы "продаете" свои блюда целевой аудитории (преимущественно руководству вашей компании) зависит судьба службы ИБ, ее статус и ее ресурсы. Помните другую мою заметку про мониторинг бизнес-показателей со стороны SOC? Она как раз об этом. 

Дюжина совпадений. На самом деле их гораздо больше. У ИБ вообще очень много схожего с различными сферами нашей жизни и деятельности. А тему кулинарии я выбрал неслучайно - дело в том, что именно она выбрана заглавной на весеннем CISO Forum, который так и называется "XII Международный Форум CISO FORUM: Кулинарная книга CISO". Мастер-классы от шеф-поваров, разговоры об ингредиентах, гастрономические клубы, кухни разных регионов мира, разнообразное меню, выставка инструментов... А в качестве вишенки на торте - настоящая кулинарная книга рецептов от руководителей служб ИБ российских предприятий. Кстати, если вы любите и умеете готовить, у вас есть любимые рецепты и вы готовы поделиться своей тайной с коллегами, то вы тоже можете поучаствовать в создании кулинарной книги рецептов CISO - присылайте свои рецепты организаторам мероприятия!

До встречи на CISO Forum!

ЗЫ. Я на CISO Forum планирую проводить киберучения и, возможно, будет еще что-то - пока есть время до мероприятия и формирования моих планов.

15.1.19

Впечатления от курса CompTIA Cybersecurity Analyst CySA+

Новогодние праздники достаточно длинны и их можно тратить на что-то более полезное, чем обжирание и пьянство :-) Вот и я, после чтения купленных на праздники книг по математике и регулярных коньков, перемежающихся расчисткой дорожек от снега на даче, решил пройти обучение. Давеча завершил я прохождение онлайн курса про программе CompTIA Cybersecurity Analyst CySA+ и хотел бы поделиться впечатлениями.


Не могу сказать, что мне это обучение было нужно, но где-то я увидел его упоминание, как один из возможных вариантов для аналитиков SOC, и поэтому решил пройти его, чтобы понять, чему нынче учат тех, кто сидит в первой линии SOC (да-да, я не сторонник того, что эта линия нужна, но со мной многие несогласны :-)


Этот курс, как написано в описании, дает глубокое понимание основ и принципов кибербезопасности. И в этом я целиком согласен с аннотацией. 21 час, 4 модуля, 17 уроков посвящены рассмотрению почти всех тем по ИБ - от kill chain до пентестов, от выбора защитных мер до обзора нормативки, от анализа различных защитных технологий до рассмотрения процесса реагирования на инциденты, от SDLC до SABSA.


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


Согласно аннотации курс относится к уровню Intermediate и я склонен с этим согласиться. Хотя по ряду тем курс ближе к pre-intermediate, а по ряду к post-intermediate.



Практики нет, но ряд заданий можно выполнять самостоятельно, повторяя за инструкторами, запускающими nmap, wireshark, SET и другие утилиты Kali Linux, демонстрирующими основные положения первой части курса. Во второй, процессной части, практики почти нет, что обусловлено материалом.

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


ЗЫ. Проходил курс на www.safaribooksonline.com в рамках корпоративной подписки. Экзамен не сдавал - необходимости нет. 

14.1.19

Крупные мероприятия по информационной безопасности на 2019 год

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


В итоге пришлось повторить перечень мероприятий по ИБ, обновив в нем только даты. Новых в нем почти нет (разве, что Сберовские ICC и Offzone, а также промышленный и итоговый Коды ИБ). Скачать файл можно по ссылке на Dropbox (если вы не хотите обходить блокировки Роскомнадзора).



Повторю критерия внесения в список:
  • известная дата
  • возможность попасть со стороны (пусть и за деньги, но не по приглашениям и закрытым спискам)
  • невендорские
  • достаточно массовые
  • очные (онлайн/вебинаров в списке нет - что-то можно у Сергея Борисова посмотреть)
  • только Россия
  • широко известные (про многие региональные мероприятия я просто ничего не знаю) 
  • ИБшные (ИТшные с вкраплениями ИБ не включаю)
  • неВУЗовские (у них своя целевая аудитория и специфика).

ЗЗЫ. Проект http://risc.events все-таки, похоже, умер - никакой активности ни на сайте, ни в его Твиттере я не видел давно. А жаль :-(

ЗЗЫ. Если будут новые, то буду обновлять только файл на Dropbox (на Slideshare поменяли правила игры и теперь там нельзя обновить файл - надо заливать новый).

11.1.19

Сертификат о прочтении моего блога и засчитывании его в качестве программы повышения квалификации по ИБ

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

Что я могу сказать? Мне лестно читать такие отзывы о блоге. Значит не зря я все это затеял больше 10 лет назад. В любом случае я решил отблагодарить всех читателей и разработал сертификат, подтверждающий прочтение моего блога, что можно (по числу записей) благополучно засчитать за прохождение повышения квалификации в количестве 512 часов :-) Так что, если кому-то нужно подтверждение, что он прочитал мой блог, то вот вам сертификат. Скачивайте, вписывайте свое имя над кровавой полосой и вешайте к себе на стену. Если кому-то нужен PDF, то он тоже доступен.


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

10.1.19

2 новых примера повышения осведомленности

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


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

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

9.1.19

Блиц-обзор новостей по ИБ за прошедшие праздники

Уже по традиции решил сделать блиц-обзор новостей, которые попали в поле моего зрения за последние почти две праздничные недели. Ничего похожего на прошлогодние Spectre и Meltdown не произошло, но были другие интересные события:

  • Число утечек продолжает активно расти и новогодние праздники не стали исключением - почти на всех материках (кроме Антарктиды) зафиксированы инциденты с персональными данными - в Австралии утекли данные работников правительства штата Виктория (еще в Австралии было 4 утечки, но не столь массовых), утечка у игровой компании BlankMediaGames, в Германии утекли персональные данные немецких политикой, включая и Ангелу Меркель, у американской металлургической компании украдены данные покупателей. Не обошли утечки и компании, занимающиеся безопасностью - произошла утечка данных 24 миллионов пользователей парольного менеджера Blur. Вообще, утечка данных десятков миллионов пользователей уже не представляет из себя ничего уникального - таких примеров уже десятки, а общее число утекших данных превысило 4 миллиарда записей и скоро достигнет общей численности земного шара. В 2019-м году эта тенденция только продолжится, о чем я уже писал в нашем корпоративном блоге на Хабре.
  • Эксперты отмечают рост внимания злоумышленников к провайдерам услуг и вот первый пример этого года - атака шифровальщиком Ryuk облачного провайдера Data Resolution.
  • Уязвимости
    • Очередная, но неплохая обзорная публикация о том, что Телеграм небезопасен
    • Злоумышленники стали использовать новую тактику для обхода антифишинговых средств - скрытие исходного кода фальшивых страниц с помощью пользовательских цeb-шрифтов
    • Zerodium поднял цены на скупку уязвимостей. Цена на дыры в iOS возросла до 2 миллионов долларов (рост на 25%), в WhatsApp - до миллиона (рост на 50%). Цена на RCE в Chrome цена выросла в 2,5 раза до полумиллиона долларов, а цена на RCE в Windows в 2 раза - до 1 миллиона долларов.
  • Новые тулы
    • Анонсирована новая децентрализованная платформа обмена Threat Intelligence на блокчейне - Polyswarm. Предполагается, что она будет отличаться от VirusTotal двумя моментами - привлечением независимых аналитиков вместо антивирусных движков и вознаграждением работы аналитиков.
    • Стало известно, что на грядущей RSA Conference АНБ откроет сообществу свой open source реверс-инжиниринговый тул GHIDRA, который упоминается в утечке Vault 7 на Wikileaks 
  • Новогодние праздники ознаменовались двумя отключениями Интернет в африканских странах, Конго и Габоне, в которых проходили демократические выборы.
  • Геополитика
    • В России задержали американца за получение секретных сведений на флешке от неизвестного лица (На флешке? В эпоху Интернета?). Считается, что этого "шпиона" будут менять на задержанную в США Бутину или на Сайпане Макаренко. После этого МИД выпустил предупреждение россиянам, о том, что стоит соблюдать остороность при поездках заграницу. Некоторые американские специалисты по ИБ уже написали в соцсетях, что они воздержатся от посещения России (даже те, кто и не планировал никогда сюда ехать) из-за опасности задержания с целью последующего обмена. Помимо нас и американцев в эпопею с задержаниями активно включился Китай, который, после задержания топ-менеджера Huawei в Канаде, задержал у себя на территории 13 канадцев. К ИБ это имеет мало отношения - тут чистая геополитика, но держать в голове этот факт при планировании поездок стоит. 
    • Вдруг на праздниках американцы стали активно обсуждают офицера ГРУ Нетыкшо и его в/ч, якобы замешанных в кибератаках на американскую демократию. В чем причина такого интереса разных специалистов к Нетыкшо я пока не понял - вроде никаких причин для этого нет - обвинения к нему американский Минюст предъявил еще летом 2018-го года.
    • Американские эксперты начинают прямо говорить, что кибервойна с Китаем гораздо опаснее "русских хакеров". Если с нами все предельно понятно и просто, то китайцы действуют медленно и незаметно, что гораздо опаснее. Кроме того, китайцы ставят перед собой цель мирового экономического господства, что делает их попытки кражи интеллектуальной собственности в США достаточно серьезными.
    • Американское сообщество разведывательных органов начинает кампанию помощи частным американским компаниям против угроз (преимущественно из киберпространства), исходящих от иностранных государств, в первую очередь Китая, России, Северной Кореи, Ирана. 
  • Япония ввела новый налог с выезжающих из страны по морю или воздуху, который пойдет на компенсацию затрат на сбор биометрии.
Еще в мое поле зрения только на праздниках попал канадский список защитных мероприятий, которые должны решить большинство проблем с ИБ. Этот список, выпущенный в октябре, идеологически схож с австралийским списком 4/8/35 мер DSD и американским CIS Controls (бывший SANS Top 20). Ничего нового, но все равно интересно :-)