Перейти к содержанию

Рекомендуемые сообщения

Опубликовано

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

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

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

Сейчас новым кандидатом, проходящим тест на полезность, стал XDR. И в данном случае под XDR я буду подразумевать платформу, в состав которой входит как минимум EDR, NTA, TI, SIEM и SOAR/IRP. То есть защита сети и конечных точек, система мониторинга и автоматизации реагирования (плейбуки разной степени вложенности и вот это все).

И, возможно, наша нелюбовь к изменениям — это очень даже неплохо. Как будто бы это поможет нам подготовиться и выжать из XDR максимум пользы. Мы же помним, что в стратегиях MITRE есть одна из заповедей, которая говорит, что надо обязательно «максимизировать пользу от закупленных технологий». Да и вообще, вдруг нам не нужен XDR? Как понять, стоит ли отдать много денег вендору?

Как понять, не пора ли купить XDR?

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

Получается, если мы хотим использовать XDR — нам надо сначала выстроить все процессы. От выявления до реагирования. Давайте посмотрим, что тут можно сделать своими руками, без волшебной «XDR-коробки» от вендора. А потом подумаем, в каком случае она все-таки может нам пригодиться.

Если посмотреть на классические определения SOC, то вы увидите, что это либо исключительно команда аналитиков, либо совокупность людей, процессов и только в последнюю очередь — технологий.

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

 

Посмотреть статью полностью

Опубликовано

Я не знаю, что такое XDR. Честно не знаю. Решил почитать статью и... Редакторы, делайте вычитывание, пожалуйста.

 

Quote

«ущерб от потери статус-кво воспринимается как больший, чем потенциальная выгода»

Цитата из Википедии и она не полная. Эта цитата создаёт ощущение у читателя, что суть с самом статусе. Но нет, полная цитата из Вики не оставляет двоякости восприятия:

Quote

ущерб от потери статус-кво воспринимается как больший, чем потенциальная выгода при его смене на альтернативный вариант

Только второе предложение и уже лажа. Впрочем, в вики описание тоже такое себе. Я часто решаю сохранять как есть в разных вопросах, потому что выработанные стратегии эффективны, а изменение не бесплатное. Потенциальная выгода может быть, а может не быть. Если же стратегия не эффективная, то без проблем можно менять. Разумеется, частный пример не считается, но просто такого объяснения в вики не было (или я не увидел), что ставит статью под сомнение. И, как итог, эту статью, которая использует цитирование из Вики. А, и кстати, тоже интересное замечание. Приведённая цитата в Вики была взята из источника, которого более не существует. Других ссылок нет. То есть вот эта статья про XDR (я ещё не знаю, что это) начинается с НЕПРАВИЛЬНОЙ цитаты того, что даже уже проверить нельзя. Источник удалён. Единственный источник.

 

 

 

Quote

человек больше ценит вещи, которыми уже владеет, а не те, которыми может овладеть

Снова из википедии цитата. Полез проверять, там так и написано. А я сижу и не понимаю, а как может иначе то быть? У меня ЕСТЬ вещь и я её ЦЕНЮ. У меня НЕТ вещи и как тогда я могу её ценить? Но внизу этот статьи есть всего одно вот такое предложение:

Quote

Они провели более надежный эксперимент с теми же товарами, используемыми Канеманом, Кнетчем и Талером[5] (шоколадные батончики и кружки) и этот эффект не подтвердился.

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

 

1 hour ago, KL FC Bot said:

И еще 13 разных искажений, которые заставляют нас предпочитать то, во что уже вложены время и усилия

Все остальные такие же не пришей кобыле хвост?

 

Quote

Сейчас новым кандидатом, проходящим тест на полезность, стал XDR. И в данном случае под XDR я буду подразумевать платформу, в состав которой входит как минимум EDR, NTA, TI, SIEM и SOAR/IRP. То есть защита сети и конечных точек, система мониторинга и автоматизации реагирования (плейбуки разной степени вложенности и вот это все).

Да что это такое?! Чем это отличается от уже существующих систем, которые под капотом грепают логи и рисует графики для бездельников на экране?

 

Quote

Но очень велик шанс, что нам никто не разрешит просто так взять и заблокировать что-то где-то — это потребует согласования.

Не имеет отношения к делу. Это вопрос организации работы. Тут вообще никакое решение, кроме антивируса не требуется:

  1. Антивирус обнаруживает проблему
  2. Сообщает на сервер администрирования об инциденте
  3. Сервер переводит его в карантинную подсеть. Туда можно добраться для пролечивания и проверок удалённых, но нельзя добраться до других узлов. Просто изолированная подсеть

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

 

Quote

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

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

 

Quote

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

  1. Ценность ресурса, созданная низким фактором автобуса — это ложная ценность
  2. Что такое плейбук?
  3. Так что такое XDR? Грепалка логов, рисующая графики в браузере?

image.png.5d0b9ef7c2a989d3eaf6a7fa4acd0df8.png

Честно, я себя тупым чувствую.

Опубликовано
56 минут назад, Umnik сказал:

Я не знаю, что такое XDR. Честно не знаю.

https://encyclopedia.kaspersky.ru/glossary/xdr-extended-detection-and-response/
и это не тоже самое 
https://ru.wikipedia.org/wiki/External_Data_Representation
хотя я не понял, про какую именно статью речь, цитату из которой вы привели

58 минут назад, Umnik сказал:

Цитата из Википедии и она не полная

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

Пожалуйста, войдите, чтобы комментировать

Вы сможете оставить комментарий после входа в



Войти
  • Похожий контент

    • KL FC Bot
      Автор KL FC Bot
      До недавнего времени злоумышленники в основном интересовались криптокошельками исключительно домашних пользователей. Однако, по всей видимости, бизнес все чаще стал использовать криптовалюту — теперь злоумышленники пытаются добраться и до кошельков организаций. За примерами далеко ходить не надо. Недавно исследованный коллегами зловред Efimer, рассылаемый организациям, умеет подменять адреса криптокошельков в буфере обмена. В России организации не имеют права рассчитываться криптовалютой, но, тем не менее, некоторые используют ее в качестве инвестиций. Поэтому функциональность, связанная с криптокошельками, появилась даже в зловредах, используемых в атаках исключительно на российские организации. Вредоносное ПО семейства Pure, например, не только подменяет адреса в буфере, но также охотится и за учетными данными программных криптокошельков. Поэтому мы не очень удивились, когда увидели и криптовалютный фишинг, направленный не только на домашних, но и на корпоративных пользователей. Чему мы удивились, так это легенде и, в целом, качеству этого фишинга.
      Фишинговая схема
      Сама по себе схема нацелена на пользователей аппаратных криптокошельков Ledger: Nano X и Nano S Plus. Злоумышленники рассылают фишинговое письмо, в котором многословно извиняются за допущенный промах — якобы из-за технического недочета сегменты приватного ключа от криптокошелька были переданы на сервер Ledger. И он в общем-то был очень хорошо защищен и зашифрован, но вот команда обнаружила очень сложную утечку, в ходе которой атакующие эксфильтрировали фрагменты ключей и при помощи крайне продвинутых методов расшифровали их и реконструировали часть ключей, что привело к краже криптоактивов. И чтобы через эту уязвимость не взломали еще и ваш криптокошелек, авторы письма рекомендуют немедленно обновить микропрошивку устройства.
      Фишинговое предупреждение о необходимости обновления микропрошивки
       
      View the full article
    • KL FC Bot
      Автор KL FC Bot
      Технологию ключей доступа (КД, passkeys) рекламируют все ИТ-гиганты как эффективную и удобную замену паролям, которая может покончить с фишингом и утечками учетных данных. Суть в следующем — человек входит в систему при помощи криптографического ключа, сохраненного в специальном аппаратном модуле на его устройстве, а разблокирует эти данные при помощи биометрии или ПИН-кода. Мы подробно разобрали текущее положение дел с passkeys для домашних пользователей в двух статьях (терминология и базовые сценарии использования, сложные случаи), но у компаний к ИБ-технологиям совершенно другие требования и подходы. Насколько хороши ключи доступа и FIDO2 WebAuthn в корпоративной среде?
      Мотивы перехода на passkeys в компании
      Как и любая крупная миграция, переход на ключи доступа требует бизнес-обоснования. В теории passkeys решают сразу несколько злободневных проблем:
      Снижают риски компрометации компании с использованием кражи легитимных учетных записей (устойчивость к фишингу — главное заявленное преимущество КД). Повышают устойчивость к другим видам атак на identity, таким как перебор паролей — brute forcing, credential stuffing. Помогают соответствовать регуляторным требованиям. Во многих индустриях регуляторы обязуют применять для аутентификации сотрудников устойчивые методы, и passkeys обычно признаются таковыми. Снижают затраты. Если компания выбрала passkeys, хранящиеся в ноутбуках и смартфонах, то высокого уровня безопасности можно достичь без дополнительных затрат на USB-устройства, смарт-карты, их администрирование и логистику. Повышают продуктивность сотрудников. Хорошо налаженный процесс аутентификации повседневно экономит время каждому сотруднику и снижает процент неудачных входов в ИТ-системы. Также переход на КД обычно увязывают с отменой всем привычных и ненавистных регулярных смен пароля. Снижают нагрузку на хелпдеск за счет уменьшения числа заявок, связанных с забытыми паролями и заблокированными учетными записями.  
      View the full article
    • KL FC Bot
      Автор KL FC Bot
      Исследователи Маттео Риццо и Энди Нгуен из компании Google опубликовали работу, в которой предложили усовершенствованную атаку Retbleed. Как мы объясняли в одном из предыдущих постов, атака Retbleed эксплуатирует уязвимости в процессорах AMD Zen и Zen 2, а также в процессорах Intel поколений Kaby Lake и Coffee Lake. Аппаратные уязвимости такого рода крайне сложно использовать на практике, из-за чего всевозможные варианты Spectre, а также производные атаки, типа Retbleed, остаются по большому счету теоретическими. Хотя методы борьбы с ними внедряют и создатели процессоров, и разработчики ПО. Суть работы исследователей Google заключается в повышении эффективности атаки Retbleed. Не меняя ничего кардинально в архитектуре атаки, они смоги использовать особенности процессоров AMD Zen 2, чтобы читать произвольные данные из оперативной памяти.
      Кратко о Retbleed
      Retbleed, как и Spectre, эксплуатирует особенности так называемой системы предсказания ветвлений центрального процессора. Предсказание ветвлений позволяет процессору выполнять инструкции заранее, не дожидаясь результатов предыдущих вычислений. Иногда предсказание оказывается неправильным, но в норме это должно приводить только к небольшому и незаметному для пользователя замедлению работы программы.
      Атака Spectre в 2018 году показала, что неправильные предсказания могут быть использованы для кражи секретов. Это возможно благодаря двум ключевым особенностям. Во-первых, систему предсказания ветвлений можно натренировать так, что произойдет обращение к области памяти с секретными данными, и они будут загружены в кэш-память процессора. Во-вторых, был найден способ вытащить эти секретные данные из кэш-памяти по стороннему каналу, измеряя время выполнения определенной инструкции.
       
      View the full article
    • KL FC Bot
      Автор KL FC Bot
      Подключенную к компьютеру веб-камеру обычно подозревают в подглядывании, но теперь ей придумали роль в традиционных кибератаках. На конференции Black Hat описали атаку BadCam, которая позволяет перепрошить камеру, а затем выполнять на компьютере, к которому она подключена, вредоносные действия. По сути это вариант давно известной атаки типа BadUSB, однако главное отличие BadCam заключается в том, что атакующим необязательно заранее готовить вредоносное устройство — они могут использовать изначально «чистую» и уже подключенную к компьютеру камеру. Еще одно неприятное новшество — атака может быть произведена полностью дистанционно. Хотя исследование провели этичные хакеры и BadCam еще не используется в реальных атаках, злоумышленникам будет несложно разобраться в ней и воспроизвести нужные действия. Поэтому организациям стоит понять механику BadCam и принять защитные меры.
      Возвращение BadUSB
      Атаку BadUSВ тоже представили на Black Hat, правда в 2014 году. Ее суть в том, что безобидное на вид устройство, например USB-накопитель, перепрограммируют, дополняя его прошивку. При подключении к компьютеру этот вредоносный гаджет «представляется» составным USB-устройством, имеющим несколько компонентов, таких как USB-накопитель, клавиатура или сетевой адаптер. Функции накопителя продолжают исправно работать, пользователь работает с флешкой как обычно. Одновременно скрытая часть прошивки, имитирующая клавиатуру, отправляет на компьютер команды, например клавиатурную комбинацию для запуска PowerShell и последующего ввода команд для загрузки из Сети вредоносных файлов или запуска туннеля к серверу атакующих. Функции BadUSB часто используют в работе современных red team, для этого обычно применяются специализированные «хакерские мультитулы» вроде Hak5 Rubber Ducky или Flipper Zero.
       
      View the full article
    • KL FC Bot
      Автор KL FC Bot
      Современные злоумышленники всеми силами пытаются выдать свою активность за какие-либо нормальные процессы. Они используют легитимные инструменты, организовывают связь между зловредом и серверами управления через публичные сервисы, маскируют запуск вредоносного кода под действия пользователя. С точки зрения традиционных защитных решений такая активность практически незаметна. Однако если анализировать поведение конкретных пользователей или, например, служебных учетных записей, то можно выявить определенные аномалии. Именно в этом и заключается метод выявления киберугроз под названием UEBA — User and Entity Behavior Analytics (поведенческий анализ пользователей и сущностей). И именно он реализован в последней версии нашей SIEM-системы Kaspersky Unified Monitoring and Analysis Platform.
      Как работает UEBA в рамках SIEM
      Согласно определению, UEBA, или «поведенческий анализ пользователей и сущностей», это технология выявления киберугроз, основанная на анализе поведения пользователей, а также устройств, приложений и иных объектов в информационной системе. В принципе, такая технология может работать в рамках любого защитного решения, однако, на наш взгляд, наиболее эффективно ее использование на уровне SIEM-платформы. Используя машинное обучение для установления «нормального поведения» пользователя или объекта (машины, сервиса и так далее), SIEM-система, оснащенная правилами детектирования UEBA, может анализировать отклонения от типичного поведения. Это, в свою очередь, позволит своевременно обнаруживать APT, целевые атаки и инсайдерские угрозы.
      Именно поэтому мы оснастили нашу SIEM-систему KUMA пакетом правил UEBA, предназначенным для комплексного выявления аномалий в процессах аутентификации, в сетевой активности и при запуске процессов на рабочих станциях и серверах, работающих под управлением Windows. Это позволило сделать систему умнее в плане выявления новых атак, которые сложно обнаружить с помощью обычных правил корреляции, сигнатур или индикаторов компрометации. Каждое правило в пакете правил UEBA основано на профилировании поведения пользователей и объектов. Сами правила делятся на два типа.
      Статистические правила, которые рассчитываются с использованием межквартильного размаха для выявления аномалий на основе данных о текущем поведении. Правила на основе исторических данных, которые фиксируют отклонения от нормального поведения, определяемого путем анализа опыта предыдущей работы учетной записи или объекта. При обнаружении отклонений от исторических норм или статистических ожиданий происходит генерация алертов, а также повышается риск-оценка соответствующего объекта (пользователя или хоста). О том, каким образом наше SIEM-решение использует ИИ для риск-оценки объектов, можно прочитать в одной из прошлых статей.
       
      View the full article
×
×
  • Создать...