Показаны сообщения с ярлыком управление инцидентами. Показать все сообщения
Показаны сообщения с ярлыком управление инцидентами. Показать все сообщения

7.6.21

Куда движутся SOCи? Взгляд с RSA Conference 2021

Занимаясь проектами по SOC (как проектированием, так и оценкой существующих и разработкой их улучшений) постоянно сталкиваюсь с темой развития центров мониторинга в соответствие с лучшими практиками. Готовя такие планы, обычно включаешь в них только то, что уже проверено и действительно дает эффект. Понятно, что есть различные идеи и технологии, которые вроде и появились на рынке, но пока непонятно, насколько они полезны на практике. Рекомендовать их в рамках консалтинга не совсем правильно, но и скрывать тоже не имеет смысла. Поэтому решил вкратце пройтись по интересным новациям, которые были представлены в рамках прошедшей в конце мая RSA Conference 2021, где одной из популярных тем стал именно мониторинг ИБ. И хотя в условиях провального импортозамещения все это так и останется красивой сказкой, но кому-то может и поможет. Итак, что добавляют различные компании, производители и потребители, в свои SOCи для повышения их эффективности.

Во-первых, это решения класса Security Intelligence Automation, которые обладают следующими отличительными особенностями:

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

Ключевыми тут являются последние две возможности, которые позволяют не ждать, когда занятые аналитики соблаговолят записать свои действия и облегчит себе жизнь, а заставить "робота", наблюдая за действиями аналитика, записать их и потом их будет гораздо проще проверить, "согласовать" и ввести в действие.

Вторым интересным рассмотренным на RSAC направлением стали решения класса Attack Surface Management, которые позволяют в непрерывном режиме оценивать потенциальные точки проникновения в организацию. Делают они это за счет нескольких функций:

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


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

Другой проблемой, на которой были направлены усилия отрасли, стала снижение числа ложных срабатываний, с которыми сталкиваются почти все организации (число фолсов достигает 50% и выше). Одним из способов борьбы с этим является внедрение риск-ориентированной аналитики в SIEM, в рамках которой происходит не просто обычная корреляция событий ИБ, но к ней добавляется учет TTP по MITRE ATT&CK (увы, ТТУ от ФСТЭК не поддерживается), уровень риска узла или системы или пользователя и ряд других показателей (у Splunk такой механизм называется RBA - Risk Based Alerting).

Пример риск-ориентированной оценки активов в SIEM

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

Последним в этой заметке я упомяну решения класса no code, которые начали завоевывать рынок (сложно от всех требовать умения программировать), в том числе и в ИБ. В частности сегмент SOAR стал одним из первых, в которых стали появляться решения no code, позволяющие описывать плейбуки и интеграции с другими решениями без написания отдельных коннектов. Причем в этом направлении сейчас идут многие игроки - от стартапов типа Tines, sirp.io, D3 Security:

Пример описания workflow без программирования

до крупных игроков типа Spunk (с Phantom) или Cisco (с бесплатным SecureX):

Пример встроенных коннекторов с разными решениями по ИБ

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

16.3.21

Список идей для штабных киберучений

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

Фрагмент сценария с киберучений "Зомби атакуют"

Итак список идей для сценариев выглядит таким образом:

  • Утечка важной для бизнеса информации (например, планов поглощения и слияния или планов выпуска новой продукции)
  • Нарушение контрактных обязательств из-за действия шифровальщика
  • Инициация конкурентами проверки со стороны регулятора
  • Шантаж со стороны мошенников/хакеров
  • Санкционная тематика (отключение средства защиты или его обновления)
  • Внезапная публикация в СМИ информации об инциденте (да, если вы за 4 часа не среагировали, то вы проиграли эту информационную битву)
  • Массовое заражение шифровальщиком, включая цифровую АТС и почтовый сервер
  • Злой айтишник
  • Фишинг от имени руководства компании
  • Сервер компании заражен ПО для майнинга
  • Инцидент на новогодние праздники

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

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

  1. Знающий о своем увольнении системный администратор устанавливает закладки на все критичные сервера (или разработчик это делает в отношении ключевых компонентов разрабатываемого ПО).
  2. После увольнения бывший админ (разработчик) входит в ИТ-системы бывшего работодателя и крадет информацию, нарушая целостность всех баз данных и их резервных копий.
  3. Сисадмин находит на черном рынке покупателя на украденную информацию и продает ее.
  4. Покупатель требует выкуп; иначе угрожает опубликовать данные в СМИ. СМИ все равно узнают о данном шантаже и публикуют новость об этом.
Обратите внимание, задание правильных вопросов на каждом из 4-х этапов позволит прокачать как технические моменты (сбор артефактов и доказательств противоправной деятельности нарушителя или необходимость отключения учетных записей увольняемых сотрудников и контроль их наследия), так и организационные (взаимодействие со СМИ или анализ Darknet) и юридические (возбуждение уголовного дела и предоставление юридически значимых доказательств).

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

Фрагмент сценария с киберучения на "Магнитке" в феврале 2021

В любом случае все начинается с идеи, часть которых я накидал выше. 

Но как вы понимаете, это только часть задач при организации киберучений. О других я еще напишу в блоге, а кроме того, о них мы поговорим в рамках выделенной сессии на Antifraud Spring Russia'2021 28 апреля, которая будет посвящена киберучениям. Ну а чтобы прокачаться перед ней, можно посмотреть уже упомянутый ранее эфир AM Live.

8.12.20

Обзор SOCstock или что я не услышал на SOC Live. Часть 2.5 :-)

Не успел закончиться SOC Live, презентации и видео с которого выложили вчера в открытый доступ, как через день в США прошло другое онлайн-мероприятие, целиком посвященное теме SOC - SOCstock. По задумке организаторов, компании Siemplify, называющей себя независимым игроком рынка SOAR №1 (просто других некупленных уже не осталось), это должно было дать отсылку к знаковому концерту в Вудстоке, который собрал всех хиппи того времени. SOCstock тоже собрал немало специалистов по SOC - по заявлениям, не менее полутора тысяч человек (в реальности - около 600), которые в течение 9 часов слушали в два потока рассказы разных экспертов о тех или иных аспектах функционирования центров мониторинга ИБ. И, как это не парадоксально, если с точки зрения концепции и формата мероприятия SOCstock и SOC Live оказались очень похожи, то по контенту они практически идеально дополняли друг друга. Если у нас больше говорилось об аутсорсинговых услугах SOC, различных кейсах при расследовании, взаимодействии с ГосСОПКОЙ, работе с заказчиками и т.п., то на супостатном SOC "Forum" больше говорили об автоматизации, персонале, выгорании, threat hunting'е, threat intelligence, зрелости SOCов и т.п. Да, там тоже была реклама, но, как правило, она была завуалирована в очень интересных докладах и докладчики не сильно злоупотребляли рассказом о местах своей работы.

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

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

В последовавшей за ключевым докладом дискуссии руководители нескольких американских SOCов рассказывали о текущем состоянии своей деятельности. Пересказывать ее не имеет смысла - ее надо слушать. Кстати, о том, почему везде висит значок Zoom. В отличие от SOC Live, в котором спикеры участвовали очно из студии, спикеры SOCstock подключались с разных концов США и поэтому собрать их вместе не предстаавлялось возможным. Поэтому видео-поток с Zoom транслировался уже через платформу мероприятия. Было не так живо, как на SOC Live, но иначе и не получилось бы для такой децентрализованной страны как США. 

Затем конференция разделилась на 2 потока, в каждом из которых доклады длились по 30 минут. Кстати, мне кажется, что 30-тиминутные доклады для таких форматов (и 45 минут для дискуссий) лучше заходят, чем 20-тиминутные, как на SOC Live. По крайней мере мне не хватило этих 10 минут в обоих своих выступлениях - и про мониторинг ИБ удаленного доступа, и про две другие альтернативы между своим и аутсорсинговым SOC. Из интересных докладов я бы отметил следующие.

Gert Jan Bruggnik рассказывал про adversary playbook, инструмент, который позволяет описать профиль нарушителя, его техники и тактики, чтобы эффективно и оперативно использовать эти сведения про мониторинге и атрибуции инцидентов, а также, в большей степени, для организации red team'инга. Куча примеров, куча ссылок на различные Интернет-ресурсы, никакой рекламы (кроме своей книги). Отличный был доклад.


Не менее интересным был доклад и от компании Siemplify, которая рассказала как о том, что такое SOAR и зачем нужна автоматизации в SOC, так и привела немало сценариев, в которых автоматизация действительно помогает специалистам по мониторингу ИБ. Причем это были как достаточно стандартные сценарии типа фишинговой атаки или подбора пароля, так и менее распространенные, такие как утечка данных из облака или обработка фидов о киберугрозах во время пандемии COVID-19.      

Как я уже писал выше, некоторые доклады были не очень интересными, так слишком явно продвигали определенные продукты по ИБ. Например, из доклада про Threat Hunting я смог вытащить только этот слайд:
из доклада про EDR только этот:

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

А вот Роб ван Ос не обманул ожиданий - рассказал и о том, как оценивать эффективность (про это спрашивали многих докладчиков и участников пленарных сессий) и зрелость центра мониторинга, и какие модели использовать для оценки возможностей SOC и т.д. Кстати, на последний вопрос, как ни странно, ответ оказался не модель SOC-CMM от авторства самого Роба. В списке популярных она занимает 3-е место после MITRE ATT&CK и NIST CSF. DeTT&CT, CIS 20, CREST SOC и другие тоже были упомянуты, но они оказались не столь популярными.


Как я написал выше, одной из популярных тем SOCstock было выгорание персонала, его карьерный рост, формирование заинтересованности в работе аналитика SOC и т.п. Об этом говорили на еще парочке дискуссий, а также в докладе Аманды Феннели, CISO из Relativity. Она делилась опытом, как можно сделать SOC еще лучше, если фокусироваться не на технологиях, а на людях и процессах. 

Представитель Anomali не смог обойтись без рекламы свой платформы по анализу угроз, но очень грамотно вплел ее в рассказ о том, что такое нормальный процесс Threat Intel, чем он отличается от просто сбора фидов и какую пользу можно получить, если оперировать не просто фидами с IOCами от внешних источников (привет ГосСОПКА и ФинЦЕРТ), но и активно добавлять в них свой собственный контекст, которые сообща только и дают возможность на основе TI-процесса принимать адекватные решения, а не просто загружать индикаторы в SIEM и думать, что вот оно, счастье наступило.


Карсон Циммерман, автор руководства MITRE по "10 стратегиям первоклассного SOC", которое сейчас переводится на русский язык компанией R-Vision, рассказывал о том, как вывести обнаружение угроз на новый уровень. Подход "поставил сенсор и забыл" больше не работает и поэтому надо более внимательно относиться к покрытию SOCом различных систем, используемым технологиям мониторинга, их настройке, а не использованию "из коробки", и т.п. Примерно о том же я начал писать в ноябре и продолжу в декабре.

Еще одним хедлайнером SOCstock стал Антон Чувакин, который закрывал программу форума рассказом о том, что изменилось в SOCах за последние годы. Мне этот доклад напомнил выступление Антона в мае 2017-го года в Москве, когда Gartner собирал ограниченный круг заказчиков, для которого Антон рассказывал о SOCах и других технологиях ИБ. А может просто я слишком много материалов по SOC просмотрел "имени Gartner", что у меня уже в глаза двоится. Из интересного запомнилось заключение выступления, в котором подняли классическую тему о том, что <технология ИБ> мертва. Такое говорили о системах предотвращения вторжения, о SIEMах и вот теперь о SOCах. Антон не опроверг, но и не подтвердил этот тезис, уточнив, что если речь идет о SOC, как о помещении с плазмами, то да, такой подход мертв. И тут впору вспомнить требования ФСТЭК к SOCам, которые требуют не только указания в лицензии места совершения преступления оказания лицензируемого вида деятельности, но и аттестации информационной системы SOCа. До свидения виртуальные и мобильные SOC с распределенным персоналом. Кстати, ФСТЭК закрывает глаза на те SOCи, которые для оказания услуг используют облачные SIEM, размещенные зарубежом, а также сотрудников, которые вот уже скоро год как работающих удаленно, из дома, что, разумеется, в лицензии ФСТЭК не указано.


Вот такое было мероприятие. Материалы с него пока недоступны и не факт, что будут (кроме доступа к записи онлайн-трансляции), что не позволяет разместить ссылку на них. Но хочу вновь отметить, что программа оказалась прям дополняющей наш SOC Live, что и позволило мне в заголовке заметки написать про "часть 2.5". За сим откланиваюсь и буду готовить еще одну заметку про SOC Live, завершающую эту серию.

2.12.20

Обзор выступлений с SOC Live. Часть 1

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

Пленарная дискуссия врядли стоит того, чтобы писать про нее отдельно. Каких-то откровений или имеющих практическую ценность мыслей не прозвучало. Хакеры атакуют... Государство регулирует... Мир во всем мире... Космические корабли бороздят.... Скучно, предсказуемо и ни о чем. Но традиция есть традиция. Жаль, что не было заявленного Виталия Лютикова из ФСТЭК и незаявленного представителя ФСБ. Видимо двум основным регуляторам по ИБ нечего сказать по теме SOC, мониторинга ИБ, реагирования на инциденты и т.п. А жаль... 

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

Рассказ Алексея Новикова не из НКЦКИ, а из Positive Technologies, про проведенный месяцем ранее The Standoff не поразил ничем, так как по сути это была победная реляция о проведенном мероприятии без каких-либо практических выводов и рекомендаций, которые можно было бы применить в жизни. Человек слаб... Учения позволяют отработать навыки... Positive крут... Я следил за атаками на The Standoff с помощью Cisco Stealthwatch Cloud и видел многие атаки, которые там происходили, и мне кажется, что можно было бы из опыта этого мероприятия вытянуть чуть больше практических рекомендаций, которыми можно было бы поделить со слушателями SOC Live. 

А вот третье выступления в этом треке мне понравилось. Алексей Зайцев из Лаборатории Касперского делился опытом проведения тестирования защищенности организации, отличия пентестов от киберучений и redteam'инга, источниками лучших практик для них и множеством других лайфхаков. Сугубо практический доклад, по окончании которого можно было брать упомянутые ссылки и идти формировать план проверок своей защищенности или искать подрядчика для проведения внешних проверок.

После этого потока были задействованы другие форматы - викторина "Голос истины" (по примеру "100 к 1") и Анти-Пленарка с неподражаемым Алексеем Качалиным, который, пригласив на сцену ряд известных в сокостроении лиц, заставил отстаивать их определенные позиции. Было динамично, весело и время пролетело очень быстро. В отличие от утренней пленарки лично у меня появилось желание пересмотреть этот эфир и более внимательно послушать доводы каждого из участников дискуссии. Завершившая развлекательный блок "Наша игра" (догадайтесь, кто для нее писал вопросы) также прошла в ожесточенной борьбе. Оно и понятно - на кону были ценнейшие призы в виду часов Apple Watch, наушников Airpods и ТВ-приставки Apple TV. Жаль, что не смог поучаствовать в игре - все призы мне пришлись бы кстати :-) 

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


Аутсорсинг - конечно, штука, полезная и интересная. И особенно там, где хочется фокусироваться на основных компетенциях, а все непрофильное отдать вовне. Но есть у этой модели (помимо всего прочего) и такой отрицательный момент, как отсутствие роста внутренних компетенций и потеря производительности. Об этой дилемме говорил Александр Лимонов из Леруа Мерлен, рассказывая про их процесс управления инцидентами, использования аутстаффинга для него. Отдельно он рассказал о том, как автоматизирован процесс реагирования на инциденты и как компания выбирала между коммерческой IRP-платформой и решениями класса open source.

Продолжился трек с клиентским опытом рассказом специалистов Банка "Санкт-Петербург", Евгения Алексеева и Дмитрия Бабкова, которые рассказали о том, как они организуют киберучения в своей организации и проверяют возможности SOCа обнаруживать и отражать спланированные атаки. Это выступление также изобиловало богатой практикой и, на мой взгляд, хорошо дополнило ранее упомянутое выступление Лаборатории Касперского про Red Team'инг.


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


Завершал секцию клиентского опыта Антон Юдаков из Ростелеком-Солар (не совсем клиент все-таки), который приоткрывал завесу расследования и реагирования в своем SOCе. Взяв за основу схожий с Игорем Залевским, с которого я начал эту заметку, подход к рассказу - на базе кейсов, Антон добавил в презентацию то, чего не хватало Игорю, - выводы и извлеченные уроки.

Завершал этот канал поток с разбором ошибок, которые совершались в процессе построения и эксплуатации различных SOCов. Это стало отличительной особенностью SOC Live от многих других мероприятий по ИБ, на которых компании и люди деляться своими достижениями, умалчивая о своих провалах и факапах. На SOC Live не стали замыливать и эту тему - о своих ошибках рассказывали Владимир Дрюков (Ростелеком-Солар), Андрей Дугин (МТС), Владимир Дмитриев (CyberART), Тимур Зиннятуллин (Angara) и Антон Юдаков (снова Ростелеком-Солар).

 
На этом я завершу рассказ о первом канале SOC Live, который я комментировал и доклады которого я слушал. Завтра попробую описать то, что происходило на втором канале, который комментировал Алексей Комаров, но в программе которого я выступал дважды и успел послушать ряд докладов, которые были до и после моих выступлений.

ЗЫ. Предвосхищая вопрос о презентациях и видео с SOC Live. Все скоро будет выложено на сайте конференции после обработки.

10.11.20

Требуется консультант по безопасности личного профиля (навеяно Дзюбой)

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

  1. Месть "бывшей". Вполне возможный вариант, повлиять на который мы не в состоянии никак. По крайней мере информационная безопасность тут ни причем. 
  2. Случайность. Всякое бывает. Я тут в Whatsapp хотел отправить картинку в сообщении и случайно вместо одной кликнул на соседнюю. Размер экрана смартфона и толстые пальцы - это вообще сложносовместимые вещи, а уж если в фотопотоке рядом соседствуют обычные и интимные фото и видео, то тем более. К ИБ это тоже отношения не имеет, по крайней мере пока смартфоны не научились распознавать содержимое видео и фото и не задавать вопросов "Вы уверены, что хотите разместить в публичном доступе этот контент?" Ну либо соцсети должны оперативно выявлять и блокировать такой контент (правда, если он попал туда случайно).
  3. Смартфон был взломан и злоумышленники вытащили все самое ценное, что было в нем. Вспоминая уязвимости Bluesnarfing/Bluebugging/Bluejacking/Bluesnipping в Bluetooth, понимаешь, что такое возможно; особенно, если смартфон давно не обновляли. Тут даже физический доступ к смартфону получать было необязательно.
  4. Было взломано облачное хранилище, в котором хранились фотографии, видео и, возможно, резервные копии смартфона. При отсутствии многофакторной аутентификации или затроянивании домашнего компа с доступом к облаку такой сценарий тоже вполне возможен.
  5. Ну и, наконец, дипфейк. В истории, послужившей причиной для данной заметки, вроде как это не так, но в теории такое вполне может быть. В Интернете публикуется видео или фото с подменой лица и потом иди и доказывай, что ты не верблюд. Может быть ты это и докажешь, но "осадочек остался".

В 2014-м году Сколково и АСИ выпустило атлас новых профессий, в котором говорилось о том, что до 2020-го года должна появиться такая профессия, как консультант по безопасности личного профиля. 4 года назад я уже писал о том, что у меня были идеи замутить бизнес на эту тему. Но пока я благополучно работаю в Cisco, а прогноз Сколково и АСИ не сбылся, временно возьму на себя роль такого консультанта и дам ряд советов по 3-5-м пунктам:

  1. Регулярно обновляйте свой смартфон, особенно если он на Андроиде, уязвимость которого изначально выше из-за архитектуры и подхода Google к работе с этой платформой и распространением приложений для нее.
  2. Настраивайте права доступа мобильных приложений и не разрешайте им то, что не нужно. Например, зачем приложению с прогнозом погоды доступа к вашей адресной книге и фотографиям?
  3. Установите на смартфоне PIN-код длиннее 8 символов (если он символьный).
  4. Настройте многофакторную аутентификацию при работе с внешними сервисами, особенно облачными сервисами, хранящими фотопоток (например, iCloud, Google Фото, OneDrive, Яндекс.Диск, Облако Mail.ru, Dropbox и т.п.) и резервную копию.
  5. Сыграйте с собой в игру "А что, если?.." Если вы достаточно известный человек, то что вы будете делать, если в Интернете появится ваши нелицеприятные видео или фото? И дело тут не только в дикпиках. Представьте, что вы жрете козявки перед web-камерой? :-) Или чешете себе "Гондурас" регулярно... Неприятно, да. Но это уже не исправить и не удалить, а попытка потребовать удаления каких-то материалов из Интернет приведет только к эффекту Стрейзанд. Неплохо бы подготовить (хотя бы в голове) какое-нибудь заявление по поводу, пытаясь не усугублять негатив, повернув его в более позитивное русло. 
  6. В развитие предыдущего совета, подумайте о том, что даже если вы весь белый и пушистый и web-камера у вас заклеена изолентой как у Цукерберга, то существует такое явление как Deep Fake, которое позволяет приделать ваше лицо к чужому телу. И это не игрушки, когда используется Photoshop (как в рекламе для SOC Live, где к одному телу приделали поочередно головы меня, Володи Дрюкова и Антона Шипулина). Речь и применении специальных алгоритмов, которые очень грамотно накладывают фото на чужое лицо, подстраивают его под движения, мимику, добавляют речь, синхронизируют ее с движением губ и т.п. Отличить фейк от реального человека становится очень сложно. Не даром говорят, что порнография драйвит технологии. Так и тут. На порносайтах сейчас создают отдельные каталоги таких фейков, а в Телеграмме появилось куча каналов, которые позволяют "раздеть" любого человека, убрав всю одежду и сгенерировав фотографию обнаженного человека. При этом в последнем случае лицо будет настоящим, и телосложение тоже. Только вот человек уже будет без одежды. Вы готовы к таким дипфейкам?  

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

ЗЫ. Да, для особо настойчивых. Это заметка не про Дзюбу (я вообще не знаю, за какую команду он играет) и не про нарушение закона "О персональных данных" и распространение спецкатегории ПДн без согласия субъекта. Это всего лишь повод хайпануть обратиться к теме персональной кибербезопасности и обратить на нее внимание.

15.9.20

Как ловить кибермафию с помощью анализа DNS (презентация)

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

Презентация выложена на Slideshare и в моем канале в Telegram.


20.5.20

О дашбордах для SOC - часть 4. Инциденты и тикеты

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

Но только попробую. Потому что тема визуализации этой темы достаточно объемна и, самое главное, зависит от целей этого самого мониторинга и реагирования. Можно ограничиться только визуализацией числа инцидентов ИБ, которые обрабатывает SOC (можно даже с динамикой изменения этого числа). Например, вот так:


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


Смотря на рекламные материалы некоторых аутсорсинговых SOCов, удивляешься, когда SOC пишет, что они за 15 минут реагируют на инцидент. Тут либо манипуляция терминами и под словом "реагирование" они понимают "принимают в обработку" (но тогда чем тут хвалиться)? Либо речь идет о непонимании реальной работы SOC, в котором время принятия инцидента в обработку может составлять минуты (пока прилетит сигнал тревоги в SIEM, пока он скоррелируется, пока он приоритезируется). Поэтому одной из важных метрик в SOC будет время принятия инцидента в обработку первой линией. Виджет, который это будет показывать, может выглядеть так:


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

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


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


Если инцидент не был разрулен на первой линии SOC, то он передается на вторую линию (не эскалируется, как ошибочно считают многие). Посколько аналитиков второй линии в SOC обычно меньше (бывают исключения) и они дороже обходятся компании, то их избыточная нагрузка может негативно сказаться на показателях работы SOC. Аналитики L1 могут по ошибке, незнанию или умышленно передавать даже простые инциденты на вторую линию, чтобы соблюсти свои показатели деятельности (своевременно закрыт инцидент). Поэтому нам надо отслеживать, какие инциденты передаются на L2 и по какой причине, например, так:


По идее у вас должна быть выстроена воронка инцидентов, когда по мере перехода от L1 к L2 и L3  число инцидентов существенно сокращается. 

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


С занятостью напрямую связана производительность аналитика, когда мы оцениваем и число взятых в обработку инцидентов и среднее время взятия в обработку или длительность обработки инцидента. Сопоставление этих позиций нам помогает понять, кто из аналитиков работает хорошо, а кому нужен волшебный пендаль или отправка на повышение квалификации. Кстати, на виджете ниже, показана прикольная фишка, которую мы реализовывали в одном из SOCов - геймификация. Исходя из показателей оценки работы аналитика вычислялись баллы, которые ранжировались по диапазонам и каждому из них присваивались соответствующие статусы (SOC Master, COS Newbie, SOC Expert и т.п.). Учитывая возраст аналитиков в этом SOC и некий соревновательный дух среди его состава, такая геймификация позволила улучшить показатели реагирования на инциденты (без снижения его качества). 


Обрабатываемые инциденты можно визуализировать с помощью диаграммы, в которой показать соотношение между разными типами, приоритетами, источниками или аналитиками. Так как в данном случае у меня нет цели свести какой-то тип или приоритет инцидента к нулю (ну если начальство вдруг не поставило такую задачу ради PR), то диаграмма будет вполне к себе к месту. Ниже показан схожий пример, но вместо инцидента у нас отображаются тикеты в системе управления деятельностью SOC, которую иногда разворачивают на базе SOAR, а иногда применяют что-то самостоятельное, для чего даже придумали термин "Security GRC". Это вообще странная конструкция, но почему-то очень популярная у производителей ИБ, которые, видимо, хотят показать свою близость к бизнесу, в котором GRC применяются достаточно давно. Или они берут пример с производителей IT GRC?..


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


Вообще тема визуализации метрик ИБ в виде отчетов и дашбордов сегодня очень мало кем прорабатывается. Она гораздо сложнее, чем даже просто тема измерения эффективности SOC. Ну считаете вы классические TTD/TTC/TTR. Может быть вы добавляете к ним MTTI, MTTQ, MTTV или MTTM. А может быть вы все-таки оцениваете еще и другие параметры (число переданных на L2 инцидентов, число открытых инцидентов критического уровня, точность эскалации инцидентов или число пострадавших активов/устройств). Допускаю. Но вот правильно их сочетать и визуализировать - это совершенно иное умение, которое и помогает быстро принимать правильные решения, направленные на улучшение деятельности центра мониторинга.

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

28.1.20

7 уроков из сотен расследованных инцидентов

Наткнулся я тут на презентацию службы реагирования на инциденты Cisco, которая по результатам более 100 проведенных расследований у наших заказчиков, сформулировала 7 ключевых наблюдений/уроков, которые мне показались достаточно интересными, чтобы про них написать. Ну а учитывая, что они не касаются продуктов, то это не стоит рассматривать как product placement.

Helpdesk всегда знает, где закопано тело

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


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

Следите за изменениями

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

Хакеры знают сеть лучше админов

В большинстве инцидентов выяснялся любопытный факт - хакеры знали свою жертву лучше, чем она сама. Нередко от специалистов по ИТ или ИБ звучала фраза "А что, так можно было?", когда им рассказывали про то, как происходило проникновение, что стало точкой входа и почему инцидент так долго не был обнаружен. Чтобы безопасникам знать свою сеть если не лучше хакеров, то хотя бы на том же уровне, им стоит активнее привлекать Red Team в своей деятельности. И не забывать, что фокусироваться надо не только на расследовании инцидентов, но и на понимании мотивов злоумышленников и того, зачем им вас атаковать.

Сегментация и доступ

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

Хакеры редко используют 0Day

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


Редактирование выбора пользователей 

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


Будьте бдительны при закрытии инцидента

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

В качестве финального аккорда отмечу еще несколько сделанных наблюдений:

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

15.1.20

Метод "пяти почему" в ИБ

Основатель компании Toyota, господин Тойода, постоянно пользовался правилом "пяти почему" или "пять зачем", которое помогало ему добраться до сути многих сложных процессов и разбираться во многих непонятных ситуациях.

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

Спрашиваете себя - почему я хочу сертифицированный МСЭ? Это первое «почему». Отвечаете: потому что так написано в законодательстве. ОК, переходим ко второму «почему». Почему вы думаете, что так написано в законодательстве? Ответ: Потому что все про это говорят и продавцы МСЭ тоже. Третье «почему»: Почему все, включая продавцов, говорят о необходимости сертификации МСЭ? Ответ: Потому что они хотят заработать денег на мне. Четвертое «почему». Почему они хотят заработать денег? Ответ: Потому что по другому их продукция не продается. Пятое «почему». Почему она не продается? Ответ: Потому что их продукция говно менее функциональная и может похвастаться только сертификатом с высоким уровнем соответствия требованиям регулятора. Ну вроде очевидный ответ, но он ни слова не говорит вам, почему именно вам нужен именно сертифицированный МСЭ? Может вас устроит и несертифицированное решение?

Давайте попробуем пройти эту процедуру еще раз. Начнем сразу со второго "почему". Почему вы думаете, что так написано в законодательстве? Ответ: Потому что я верю тем, кто говорит средства защиты должны иметь сертификат. Третье «почему». Почему я им верю на слово? Ответ: Потому что они лучше меня разбираются в законодательстве. Четвертое «почему»: Почему они лучше разбираются? Ответ: Потому что им надо продать мне свою продукцию. Пятое «почему»: Почему она не продается? Ответ: Потому что их продукция говно... Ой, опять тоже самое :-)

Давайте снова запустим метод "пяти почему". Начнем с третьего "почему". Почему я им верю на слово? Ответ: Потому что я сам не разбирался в хитросплетениях нашего сложного законодательства. Четвертое «почему»: Почему я не разбирался в законодательстве? Ответ: Потому что мне не хочется разбираться в скучном законодательстве. Пятое «почему»: Почему мне не хочется разбираться в скучном законодательстве? Ответ: Потому что... вот тут может несколько причин. Мне не хочется спорить с регуляторами. У меня нет юридического образования. У меня нет юристов, которые бы помогли мне. Мне, у меня, я... Последнее "почему" можно сформулировать проще, не прячась за отговорками. Я НЕ ХОЧУ НАПРЯГАТЬСЯ и МНЕ ТАК ПРОЩЕ.

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

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

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


Господин Тойода считал, что в ответе на пятое "почему" и кроется первопричина наших (или не наших) поступков и действий, которая на первый взгляд не прослеживается. Именно она отражает то, что мы скрывали сами от себя и что действительно является важным.

9.1.20

Новости ИБ за новогодние праздники

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

  • Убийство официального лица Ирана, генерала Сулеймани, привело к тому, что американское агенство по информационной безопасности выпустило предупреждение о возможных геополитических кибератаках, особенно со стороны Ирана, который пообещал 13 катастрофических сценариев ответных действий на агрессию со стороны США (и уже искал экспертов для атак на критическую инфраструктуру США). Это уже привело к тому, что отдельные штаты начали отчитываться о том, что они фиксируют десятки тысяч кибератак со стороны Ирана (хотя в реальности они фиксируют всего лишь сканирования портов). Но, думаю, мы еще увидим последствия этой эскалации в киберпространстве.
  • ФБР снова просит Apple разблокировать iPhone двух обвиняемых в незаконной стрельбе.
  • Dell ищет покупателя на подразделение RSA Security, а также конференцию RSA Conference.
  • Конгресс подготовил отчет, который должен быть представлен в марте-апреле и реализация мероприятий которого должно повысить уровень защищенности частных американских компаний. Интересно, что они, по слухам, хотят чуть ли не вписать правило "1-10-60" как рекомендацию по ИБ.
  • Accenture покупает бизнес услуг ИБ Symantec, включая и 6 SOCов, разбросанных по всему миру. Вообще Accenture за последние несколько лет скупил уже с полдесятка ИБ-стартапов,  желая стать серьезным игроком этого рынка.
  • Исследователи смогли реализовать новую, более эффективную и практичную атаку на SHA-1.
  • Было несколько успешных атак шифровальщиков, заставивших жертв выплатить выкуп, кииберпреступникам. Но мне запомнился один кейс с одной из фирм США, занимающейся телемаркетингом. После неудачного восстановления от последствий шифровальщика, за день до Рождества, 300 сотрудников компании получили письмо от генерального директора о том, что они могут искать новую работу, так как компания не смогла восстановиться после кибератаки.
  • MITRE выпустила новую матрицу техник, тактик и процедур злоумышленников - на этот раз для промышленных систем. Это первая версия, которая готовилась более двух лет, но которая продолжает наполняться новыми TTP.