Есть компании на рынке которые за анализ логов при инциденте берут 2+ млн рублей и это вызывает некоторое недоумение

🤣я вчера работал

У тебя ночь была - ты спал. Не обманывай нас тут

😒

Я вчера тож работал 😁

пошли в личку пофлудим)))

Ребят, а много кто видел внедренный arcsight/qradar +инхауас сок? Но так, что на эндпоинтах нет сисмона и никто не видит, что происходит внутри эндпоинта

не для барселонского, случайно? (:

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

Воркшопы с рандомных дефконов и доклады от adsecurity только

> А как считаете, SOC не занимающийся расследованием инцидентов, а только их обнаружением имеет место быть

SOC — это организационный юнит, или отдел, занимающийся обеспечением защищенности.

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

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

@reednessfox
> или это неэффективно?

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

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

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

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

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

Хорошими примерами таких данных являются логи DHCP, DNS и Proxy (HTTP Transactions), а также NetFlow и PCAP (все у кого сейчас возникло желание подискутировать о сборе дампов — давайте отложим до решения основного топика).

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

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

Эта часть процесса является проводником ко всем последующим, поскольку от полученных ответов будет зависеть то, как эта угроза будет Сдерживаться (Containment), Ликвидироваться (Eradication), какие действия необходимо будет произвести чтобы восстановить исходное состояние систем (Recovery) и какие изменения внести  в системы для предотвращения повторения инцидента в будущем (Lessons Learned).

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

Спасибо за отлично расписанное мнение

@FederationRR
>>> При мониторинге и так собираются события инфраструктуры, почему бы дополнительно не реализовать и расследование

Ruslan
>> Людей с нужной квалификацией тупо нет обычно.

@FederationRR
> мне кажется это прям должны бывшие разработчики, хорошо знакомые с реверсом, дизасемблированием и интресом именно к ИБ, типичная вторая линия не потянет

Если говорить про расследования, а именно про компьютерную криминалистику (Digital Forensics), то она не обязательно требует знания реверса и его методов.

Во-первых, Digital Forensics и Incident Respone это не одно и то же.

Digital Forensics — это один из методов Incident Respone, который может применяться в отрыве от процесса реагирования.

Классический пример — инцидент уже произошел, угроза миновала (потому что собственно угрожать уже нечему, например все деньги/данные уже увели), и специалистов пригласили провести расследование с целью поиска преступника и проведения Root Cause Analysis (RCA).

Во-вторых, DF с технической стороны можно разделить на три области:

- Network Forensics
- Disk Forensics (включает в себя логи и любые другие артефакты хранящиеся на диске)
- Memory Forensics

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

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

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

И если у DF команды нет своей экспертизы по RE, это не так сильно влияет на качество их работы, как например, отсутствие экспертизы по фундаментальным направлениям — сети, ОС, файловая система, логи, конечно же, угрозы.

И таких примеров масса. Жил был челикс, всю жизнь был оторван от фундаментальных дисциплин, не знает ничего об угрозах, изучил курсы SANS, научился пользоваться инструментарием, и вроде как может генерить таймлайны. Все, пора обновлять тайтл в линкдин. Найдете его по запросу "Senior Digital Forensics Investigator".

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

@yugoslavskiy =))))

Где-то сейчас всплакнули 90% «форензиков»

все 5?))

😂

Я не про организацию. Тут масштаб страны)

я тоже про человеков