Pull to refresh
15
0
Send message

Вообще у серии постов (это третья часть, самая наверное скучная) было три цели:

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

  2. Другие сервис-провайдеры, интеграторы, в том числе те, которые лишь в начале пути запуска своих сервисов, осознали какие вещи обещать не стоит заказчику, чтобы потом не было разочарований. Я часто слышу в паблик, например, лозунги - "мы дадим заказчику только 3ю линию SOC и это будет нормально работать". Но нет - не будет.

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

ОООк) продолжим

По SSH — все так, только VPN дает сильно больше и сильно проще, нежели SSH. Я не спорю, что SSH можно настроить безопасно, но с VPN с точки зрения доступа к корпоративной инфраструктуры возможностей сильно больше по использованию корпоративных ресурсов. Те компании, которые приходили к нам с просьбой расследовать, расшифровать не использовали сертификаты на ssh, более того, даже root не блочили. Куча ботов ежедневно сканит интернет по 445, 22, 3389 портам. И если 22 входит и его сканят — значит «если звезды зажигаются, значит это кому-то нужно» и есть профит от этого.

По WiFi — речь была про безопасность ДОМАШНЕЙ сети. И от соседа мальчика 12 лет cloaking вполне норм. Хэндшейк захватить — устройство нужно, которое коннектится, а днем, когда сосед-бездельник пришел со школы и ему скучно, многие работают и не юзают точку. В корпоративных сетях использовать пароль для точки WIFI очень странно, там совершенно по-другому строится защита. Надеюсь свои «вредные» советы пояснил
А можно просто поднять CentOS сервер, открыть ssh и настроить auditd и смотреть)
По первому вопросу — VPN можно сделать с сертификатом (как я и указал в комменте) или onetimepass например, ну и брут VPN можно контролировать — рубить ip-шник или учетку при превышении количества запросов

По второму — прежде чем подобрать пароль, нужно узнать SSID )
Я бы ответил следующим образом:
1. Забрутить RDP или SSH, торчащий наружу вопрос времени и, с развитием текущих мощностей и возможностей распределенного брутфорса — это часы и дни, а не годы. Ну и помимо этого есть еще непропатченные версии, дефолтовые пароли и учетки. Буквально недавно у одной из пилотируемых компаний (крупных) обнаружили tomcat tomcat в торчащем наружу сервисе и это не редкость
2. По безопасности домашней сети есть несколько тезисов:
— сейчас роутеры провайдеров стали очень и очень продвинутыми. Там и DMZ можно организовать и IPSEC построить и уж VPN поднять не проблема. В любом случае VPN всегда безопасней чем RDP/SSH. Да еще и сертификат выпустить можно на поднятом CA
— Если очень хочется открыть RDP, SSH наружу — открывайте для определенных IP, если используется статика для подключения к домашней инфраструктуре
— Уберите в настройках публикацию интерфейса администрирования в WAN интерфейс, так как на многих роутерах по умолчанию он торчит в интернет.
— Используйте скрытый SSID WiFi
— Меняйте пароли WiFi хотя бы раз в месяц
— И обязательно обновляйте прошивки железки. Взломанные микротики стали притчей воязыцех
Добрый день! Анализ вредоносного ПО производится несколькими способами: это и ручной анализ (используется ПО для деобфускации и декомпиляции), и анализ поведения с помощью стендовой машины, которая подключена на уровне локальных и сетевых логов к арксайт + wireshark + processhacker и пр. У группы форенсики и реверса есть список ПО, которое они используют каждодневно и у нас планируется отдельная статья
Спасибо за комментарий!

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

По поводу потенциально опасных ресурсов — мы используем различные источники:
1. Open Source — malwaredomainlist, ransomwaretracker, atlas feeds и другие
2. Коммерческие репутационные базы от отечественных и зарубежных вендоров. Чаще всего это антивирусные вендоры
3. Информация от CERT`ов (отечественных и зарубежных)
4. Собственные наработки нашей forensic-команды + информация агрегируемая в рамках расследования инцидентов у заказчиков и (по возможности) используется в рамках «перекрестного опыления»
Конечно же 10 тысяч rdp-сеансов не было. Количество сеансов было сильно меньше. В скобках я указал количество соединений, зафиксированных на сетевом оборудовании по порту 3389. Учитывайте, что все сканеры из Китая и Голландии так же сюда входят, так как хост торчал наружу с белым адресом и открытым портом. Количество адресов, с которых были именно сессии за все время, пока злоумышленники «жили» на хосте — 6 уникальных адресов

Так же могу отметить, что с хоста фиксировались до 150 попыток исходящих соединений по rdp на внешние адреса (из списка тех 500, что были найдены в файле на хосте)
Добрый день! ОС была семерка. Папка Documents and Settings залинкована в седьмой версии с users. При этом многие программы для сбора информации с образа отображают папку users как documents and settings.
ArcSight позволяет писать парсеры, так же понимает CEF, JSON. Парсеры могут содержать регулярки или select`ы в базу. Каждый случай решается индивидуально, но возможностей великое множество.
Чаще всего пишется парсер для flex-коннекторов различных типов, который читает файл, смотрит базу или парсит syslog. А выгрузка на стороне системы делается регулярной любым способом — хоть скрипт, хоть руки
Добрый день!
Как раз такие публикации и планируются в ближайшее время. Постараюсь подробно осветить и механизм обследования бизнес-процессов и инфраструктуры в целом для подключения к JSOC. Обязательно расскажу про процедуру создания нетиповых правил и профилирования активностей.
Добрый день.

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

2) Обнаружение инцидента — это время в течение которого специалист первой линии обязан взять кейс в работу. В арксайте есть параметр manager receipt time — это время фактического прихода события в систему. Время прихода события в систему (либо время прихода последнего события в цепочке, в случае, например, брутфорсов) совпадает с временем генерации правила (если в явном виде не задана задержка), на основании которого и заводится инцидент. В ArcSight есть так же время Start и End time которые говорят о фактическом времени начала и конца события. При штатной работе системы разница между End Time и manager receipt time составляет 10 секунд — 2 минуты. А нештатные ситуации контролируются правилами.
Заказчиков много, примерно 60% банки, остальные — совершенно различные сферы:
Ритейл
ТЭК
Транспортные компании
Медиа-компании

Регионов представлено много и постоянный прирост. Из публичных заказчиков — СТС Медиа, S7 Airlines, Яндекс.Деньги, Почта Банк, МТС Банк, Уральский банк реконструкции и развития
Добрый день.

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

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

Ложные срабатывания уменьшаются тем быстрее, чем лучше клиент знает свою инфраструктуру. Процесс, опять же, разнообразный:
— По сильно флудящим инцидентам мы можем предоставлять сводную ежедневную (еженедельную) информацию, если у нас нет возможности фильтрации FP и заказчик не может предоставить критерии
— По ситуациям, которую Вы описали — всегда включаем максимальный режим паранойи, тренируем первую линию с помощью case review, либо внезапными проверками по часто повторяющимся инцидентам

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

Information

Rating
Does not participate
Works in
Registered
Activity