Комментарии 11
На сколько я понял из картинки, вы собираете логи с помощью Zabbix? Каким образом потом логи передаются на ArcSight?
WAF as a service
Вы сотрудничаете с другими поставщиками таких услуг или сами устанавливаете и управляете WAFами? Если не секрет, что за WAF предпочитаете?
Комплектный контроль защищенности
Сканируете только периметр или еще и сканируете внутреннюю сеть организации? Если второе — то проводите выездные проверки, размещаете агент сканера, организуете разовый удаленный доступ или постоянно имеете удаленный доступ к сети организации?
WAF as a service
Вы сотрудничаете с другими поставщиками таких услуг или сами устанавливаете и управляете WAFами? Если не секрет, что за WAF предпочитаете?
Добрый день, собственного WAF`а у нас нет. В рамках оказания сервиса мы сотрудничаем как с некоторыми отечественными решениями (SolidWall, PT WAF), так и лидерами зарубежного рынка – Imperva, F5.
Наша основная функция — проактивная эксплуатация. Мы берем на себя функции по управлению, профилированию, тюнингу политик, мониторингу и реагированию на атаки, и, конечно, контролируем работу самого WAF с точки зрения доступности и работоспособности.
Благодаря партнерским соглашениям с вендорами у нас также есть возможность предоставлять WAF в аренду заказчику совместно с нашим сервисом.
Комплектный контроль защищенности
Сканируете только периметр или еще и сканируете внутреннюю сеть организации? Если второе — то проводите выездные проверки, размещаете агент сканера, организуете разовый удаленный доступ или постоянно имеете удаленный доступ к сети организации?
В рамках сервиса мы осуществляем сканирование как периметра, так и внутренней инфраструктуры компании. В рамках сканирований, помимо стандартного vulnerability management и инвентаризации, мы проверяем конфигурации хостов с целью выявления индикаторов компрометации различными вредоносами (поиск IoC на хостах).
С точки зрения доступа существует несколько вариантов:
1. Если используется Qualys, управление virtual appliance осуществляется из облака самого Qualys. Заказчик может разделить функции по сканированию и дальнейшему анализу отчетов по нескольким учетных записям, поэтому инженер подключается для сканирования, а анализирует отчет аналитик.
2. Если используется MaxPatrol, то, в зависимости от «закрытости» сегмента, есть возможность выезда инженера на площадку или подключения по VPN — одноразово или на постоянной основе в рамках site-to-site с нашим ЦОДом. Второй вариант используется при комплексном сервисе совместно с мониторингом инцидентов, когда необходимо оперативно подгружать информацию из сканера защищенности в SIEM-систему и запускать сканирования по факту срабатывания сетевых кусков репутационных баз наших партнеров (обращения к потенциально опасным хостам).
В любом случае, при сканированиях всегда запускается процесс согласования с заказчиком (RFC), выбирается время, скоуп и тип сканирования в соответствии с критичностью сканируемой системы.
Пардон, оговорился:
Конечно, имелась в виду проверка с целью выявления индикаторов компрометации различных вредоносов, а не различными вредоносами).
мы проверяем конфигурации хостов с целью выявления индикаторов компрометации различными вредоносами
Конечно, имелась в виду проверка с целью выявления индикаторов компрометации различных вредоносов, а не различными вредоносами).
Спасибо за развернутый ответ.
А как налаживаете процесс работы с администраторами организаций — теми, кто проверяет, что атака была успешной/неуспешной? Как вы учитываете время их реакции — оно каким-то образом связано с вашими показателями SLA? Как уменьшаете количество ложных срабатываний в подобных ситуациях:
К примеру, нет WAF, фиксируется попытка заливки веб-шелла (СОВ), потом обращение к веб-шеллу для проверки успеха атаки (логи веб-сервера) и пусть код ответа 404. Но что, если скрипт шелла сам возвращает не 200-й код, а 404-й к каждому обращению к нему. Если реагировать только по логам и не проверять сервер на наличие шелла, то можно пропустить атаку. А уведомление об атаке = время на проверку.
А как налаживаете процесс работы с администраторами организаций — теми, кто проверяет, что атака была успешной/неуспешной? Как вы учитываете время их реакции — оно каким-то образом связано с вашими показателями SLA? Как уменьшаете количество ложных срабатываний в подобных ситуациях:
К примеру, нет WAF, фиксируется попытка заливки веб-шелла (СОВ), потом обращение к веб-шеллу для проверки успеха атаки (логи веб-сервера) и пусть код ответа 404. Но что, если скрипт шелла сам возвращает не 200-й код, а 404-й к каждому обращению к нему. Если реагировать только по логам и не проверять сервер на наличие шелла, то можно пропустить атаку. А уведомление об атаке = время на проверку.
Добрый день.
С администраторами работа идет по-разному. На первых этапах в большинстве компаний точкой входа является сотрудник ИБ. В дальнейшем взаимодействие, действительно, строится напрямую с владельцами систем и ответственными администраторами. Схем множество — начиная от переписки в почте, заканчивая интеграцией тикет-систем (нашей и Заказчика), либо использованием нашей.
В SLA очень сложно «запихнуть» ответы Заказчика, а так же образмерить дальнешие шаги с нашей стороны, поэтому в SLA мы образмериваем лишь время реакции и первого оповещения на инцидент.
Ложные срабатывания уменьшаются тем быстрее, чем лучше клиент знает свою инфраструктуру. Процесс, опять же, разнообразный:
— По сильно флудящим инцидентам мы можем предоставлять сводную ежедневную (еженедельную) информацию, если у нас нет возможности фильтрации FP и заказчик не может предоставить критерии
— По ситуациям, которую Вы описали — всегда включаем максимальный режим паранойи, тренируем первую линию с помощью case review, либо внезапными проверками по часто повторяющимся инцидентам
В любом случае работа по инцидентам всегда совместная с заказчиком и, зачастую, именно он определяет, как и когда проверять, мы лишь можем посоветовать.
С администраторами работа идет по-разному. На первых этапах в большинстве компаний точкой входа является сотрудник ИБ. В дальнейшем взаимодействие, действительно, строится напрямую с владельцами систем и ответственными администраторами. Схем множество — начиная от переписки в почте, заканчивая интеграцией тикет-систем (нашей и Заказчика), либо использованием нашей.
В SLA очень сложно «запихнуть» ответы Заказчика, а так же образмерить дальнешие шаги с нашей стороны, поэтому в SLA мы образмериваем лишь время реакции и первого оповещения на инцидент.
Ложные срабатывания уменьшаются тем быстрее, чем лучше клиент знает свою инфраструктуру. Процесс, опять же, разнообразный:
— По сильно флудящим инцидентам мы можем предоставлять сводную ежедневную (еженедельную) информацию, если у нас нет возможности фильтрации FP и заказчик не может предоставить критерии
— По ситуациям, которую Вы описали — всегда включаем максимальный режим паранойи, тренируем первую линию с помощью case review, либо внезапными проверками по часто повторяющимся инцидентам
В любом случае работа по инцидентам всегда совместная с заказчиком и, зачастую, именно он определяет, как и когда проверять, мы лишь можем посоветовать.
И еще вопрос: по заказчикам услуг. Кто они (госы, банки, больницы...)? И откуда они? Все из Москвы/Нижнего Новгорода? Или есть ли кто-то из регионов?
Заказчиков много, примерно 60% банки, остальные — совершенно различные сферы:
Ритейл
ТЭК
Транспортные компании
Медиа-компании
Регионов представлено много и постоянный прирост. Из публичных заказчиков — СТС Медиа, S7 Airlines, Яндекс.Деньги, Почта Банк, МТС Банк, Уральский банк реконструкции и развития
Ритейл
ТЭК
Транспортные компании
Медиа-компании
Регионов представлено много и постоянный прирост. Из публичных заказчиков — СТС Медиа, S7 Airlines, Яндекс.Деньги, Почта Банк, МТС Банк, Уральский банк реконструкции и развития
1) Расскажите еще, пожалуйста, про то, как взаимодействуете с заказчиками: в плане какие действия/запросы/изменения/требования обязательно и жестко фиксируете на бумаге, а какие ведете в электронном виде. К примеру, согласование профилей легальной активности (http://www.securitylab.ru/analytics/473903.php), согласование способов информирования об атаках (те же перечни телефонов, почт), согласование ответственных лиц, возможно категории инцидентов, тот же перечень контролируемых хостов/сервисов на них.
Ограничиваетесь базовым договором, а все остальное — в электронной форме (через тикеты)?
2) А также вопрос: как понять параметр SLA «Время обнаружения инцидента (мин)». Когда начинается отсчет времени и каким событием он заканчивается?
Ограничиваетесь базовым договором, а все остальное — в электронной форме (через тикеты)?
2) А также вопрос: как понять параметр SLA «Время обнаружения инцидента (мин)». Когда начинается отсчет времени и каким событием он заканчивается?
Добрый день.
Отвечу по-порядку:
1) на бумаге обязательно фиксируем договор с количеством источников подключаемых в рамках сервиса, режимом SLA, а так же сроками по реализации запросов заказчика и регламентов взаимодействия — все то, что идет более менее универсально от заказчика к заказчику.
В электронной форме обязательно фиксируется профиль услуги, где мы намечаем те инциденты, которые будем фиксировать, сроки их реализации и постоянно актуализируем информацию (когда новый тип инцидента запускается в мониторинг). Так же в электронной форме фиксируются маршруты уведомлений и способы, список подключенных источников. Тут фиксация идет в переписке с заказчиком и обязательно публикуется в нашей тикет-системе для руководителя департамента, других аналитиков, сервис-менеджеров и специалистов первой линии (ограниченно).
Все профили согласовываются в электронной переписке, а далее заносятся в арксайт. Добавление новых записей происходит по письму заказчика (напр, что действие легитимно и надо добавить в профиль). На каждое письмо заказчика о просьбе добавления в профиль создается заявка и назначается ответственный
2) Обнаружение инцидента — это время в течение которого специалист первой линии обязан взять кейс в работу. В арксайте есть параметр manager receipt time — это время фактического прихода события в систему. Время прихода события в систему (либо время прихода последнего события в цепочке, в случае, например, брутфорсов) совпадает с временем генерации правила (если в явном виде не задана задержка), на основании которого и заводится инцидент. В ArcSight есть так же время Start и End time которые говорят о фактическом времени начала и конца события. При штатной работе системы разница между End Time и manager receipt time составляет 10 секунд — 2 минуты. А нештатные ситуации контролируются правилами.
Отвечу по-порядку:
1) на бумаге обязательно фиксируем договор с количеством источников подключаемых в рамках сервиса, режимом SLA, а так же сроками по реализации запросов заказчика и регламентов взаимодействия — все то, что идет более менее универсально от заказчика к заказчику.
В электронной форме обязательно фиксируется профиль услуги, где мы намечаем те инциденты, которые будем фиксировать, сроки их реализации и постоянно актуализируем информацию (когда новый тип инцидента запускается в мониторинг). Так же в электронной форме фиксируются маршруты уведомлений и способы, список подключенных источников. Тут фиксация идет в переписке с заказчиком и обязательно публикуется в нашей тикет-системе для руководителя департамента, других аналитиков, сервис-менеджеров и специалистов первой линии (ограниченно).
Все профили согласовываются в электронной переписке, а далее заносятся в арксайт. Добавление новых записей происходит по письму заказчика (напр, что действие легитимно и надо добавить в профиль). На каждое письмо заказчика о просьбе добавления в профиль создается заявка и назначается ответственный
2) Обнаружение инцидента — это время в течение которого специалист первой линии обязан взять кейс в работу. В арксайте есть параметр manager receipt time — это время фактического прихода события в систему. Время прихода события в систему (либо время прихода последнего события в цепочке, в случае, например, брутфорсов) совпадает с временем генерации правила (если в явном виде не задана задержка), на основании которого и заводится инцидент. В ArcSight есть так же время Start и End time которые говорят о фактическом времени начала и конца события. При штатной работе системы разница между End Time и manager receipt time составляет 10 секунд — 2 минуты. А нештатные ситуации контролируются правилами.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Solar JSOC – опыт построения коммерческого SOC