Ввиду невозможности обеспечения безопасности на iPhone, переезжаем на Huawei. Сразу замечу, по моему мнению, что если не хочется сложностей на пустом месте (отсутствие Google Play и т.п.), то лучше брать Samsung или Xiaomi (иногда я думаю, что Huawei и Xiaomi - это как Hyundai и Kia 😂)... Но мы не ищем легких путей и переезжаем на Huawei!

В этой и следующей статьях расскажу о своих упражнениях с эко-системой Huawei для отслеживания показателей здоровья.

#здоровье

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

#здоровье

Традиционно, в январе я подбиваю аналитику нашего сервиса за предыдущий год. Сегодня смотрел географию и сделал приятное наблюдение – добавились 10 новых стран нашего присутствия. Обычно, в отчетах мы не даем глобальный срез по странам, тем более, не даем динамику из года в год, но мне ее прекрасно видно, поскольку собственноручно каждый январь упражняюсь с Jupyter-ом. Аналитики, действительно, очень много, и всю ее уместить в отчет сложно, но интересными наблюдениями и мыслями буду делиться здесь, а если будет что-то совсем интересное, напишу на какой-нибудь CFP, например, там расскажу более систематизировано, если комиссия одобрит.

Итак, в 2023 у нас появились заказчики из следующих стран по регионам:
LATAM: CR, CL, AR;
APAC: LK, JP, TH;
META: CI, MR, MG, AE
Потерь стран присутствия в прошлом году не замечено.

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

#mdr

Каждый год в отчете MDR мы даем раздел «Эффективность реагирования». Он формируется на основе анализа количества алертов в инцидентах. Логика следующая: в нашем случае инцидент публикуется если требуется какая-то реакция со стороны Заказчика (или пояснение относительно легитимности наблюдаемого), нечасто, но бывает, что мы публикуем инцидент для информации: мы обнаружили, отреагировали либо MDR-ом, либо продуктом (EPP) и, в общем случае, дополнительной реакции не требуется (когда есть теоретическая возможность что-то поблочить на периметре, мы об этом стараемся писать). Пока мы и\или Заказчик не отреагировали, инцидент продолжается, а значит, мы продолжаем получать релевантные алерты, т.е. количество алертов в инциденте характеризует скорость и, в общем случае, эффективность реакции.

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

Наглядно незначительность «долгих инцидентов» видна вот на этой картинке. Привожу ее с кодом, чтобы было понятнее что она отображает. Видно, что инцидентов, где количество алертов превышает даже 5, едва ли превышает 5%

#mdr

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

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

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

Формальности – полезная вещь, когда они способствуют повышению эффективности, однако, когда они приводят ровно к обратному надо включать голову, быть профессионалами и прогнозировать последствия наших действий, хотя бы очевидные. Давайте будем стараться видеть лес за деревьями!

#пятница #vCISO

В январе 1986 года увидел свет альбом Ночь группы Кино. Альбом был у меня на виниловом диске, и слушал я его на магниторадиоле Романтика-106. На альбоме много известных композиций - Видели ночь, Последний герой, Мама-анархия и др, но мне больше всех нравилась Игра.

С тех пор прошло уже более 30 лет и любимую тогда Игру я почти никогда не играл, но в 2022 году "Наше радио" проводило конкурс "Спой Кино"...

Делюсь с вами своим вариантом Игры.

#музыка

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

В новой статье попытался ответить на этот вопрос, а также расписать работу схемы классификации инцидентов в условиях гибридного SOC

#vCISO

Проскакивала какая-то тема подкастов по ИБ..., вот попалась более-менее свежая подборка. В целом, все, что я когда-либо слушал, там перечислено

https://habr.com/ru/companies/bastion/articles/745518/

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

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

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

Давненько мы ничего не писали про нашу любимую eBPF технологию, которую мы активно у себя в Luntry используем. И вот, вышла замечательная статья "BPF Memory Forensics with Volatility 3", позволяющая заглянуть в недра данной технологии. Но сразу отметим что не со стороны разработчика, а со стороны исследователя, который на руках исходных код может и не иметь ... То есть будем анализировать скомпилированный код и память. И все это с помощью утилиты Volatility 3. Если быть еще быть более точным, то статья будет больше полезна вирусным аналитикам, что хотят исследовать malware, rootkit на базе eBPF (писали и рассказывали уже о таком тут, тут и тут).

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

На днях читал драфт исследования о нехватке персонала в различных областях ИБ, которое меня попросили прокомментировать по части SOC в РФ, поскольку, согласно этому опросу в РФ самая большая нехватка аналитиков SOC по миру.

Уверен, что я не единственный, от кого буду спрашивать экспертного мнения и объяснений, поэтому, очевидные причины, типа, что можно жить в РФ и работать в зарубежном SOC за зарубежные деньги (как минимум, в исследованиях – точно, поскольку лично получал такие предложения от лондонских контор) и т.п. , – оставил другим экспертам.

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

Дорогие друзья, помимо мониторинга ИТ-инфраструктуры есть масса других задач по ИБ, которые "никто кроме нас" (с) не сделает, поэтому давайте фокусировать свои усилия туда, а фокусировка и правильная приоритезация – залог получения максимального результата минимальными усилиями, давайте будем эффективными!

#vCISO

Хорошая статья от Алексея Викторовича, и даже со ссылкой на нашу утилитку.
Единственное, что хочется добавить относительно мысли о том, что "раньше такого не было", что раньше и турбулентности в мире было поменьше, а, как известно нам охотникам, чем больше активности, тем заметнее она становится, поэтому то, что раньше казалось незаметным и долетало только отголосками в виде последствий атаки на иранскую ядерную программу, постепенно входит в нашу обыденность, сдвигая планку того, что "нормально".

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

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

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

Контроль – это не значит «делать самому»!

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

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

Эффективные рабочие коммуникации – не менее важный компонент безопасности, чем целостность, конфиденциальность, доступность, аутентичность и прочие перспективы

#пятница #vCISO

Как обещал, скидываю слайды с PHD2023 . Доклад назывался "Metrics in Security Operations"

В одном из аналитических обзоров от наших коллег по цеху, тоже поставщиков услуг SOC/MDR, увидел что в 2023 "доля критичных инцидентов от общего числа атак снизилась по сравнению с 2022 годом: от 40-45% до 20-25%". Не будем брать во внимание, что более чем каждый третий, чуть ли не каждый второй, инцидент – это сильно (!), и что вообще вкладывается в понятие "критичный инцидент" – это очевидные причины разброса процентов и здравого смысла...

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

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

В период с 2001 по 2002, два года я отдал программированию, писал на С/C++ и Perl, параллельно, учась в Бауманке, в "Специалисте" читал Java, правда, очень недолго. И ко всем языкам программирования я относился крайне спокойно (даже С со своим ручным управлением памятью!), особое негодование вызывал только Python, на который я был вынужден перейти с любимого Perl, который стал плохо поддерживаться и развиваться.

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

Может, я что-то не знаю\не понимаю\делаю неправильно?