Pull to refresh

Comments 4

Интересен ваш опыт по Incident Response с точки зрения людей.

Насколько я помню по прошлым публикациям у вас есть 2 линии обработки инцидентов. Первая линия «массовка» обрабатывает «типовые» сценарии. Вторая «тру-антихакеров» подключается в сложных случаях.

Как обучаете 1-ю линию? Проводите ли «Курс молодого бойца» по разбору инцидентов? Есть ли инструкции на каждый типовой инцидент (при бруте делай то, смотри туда)?

А 2 линия «тру-антихакеры» у вас свободные художники которые разбирают APT стоящие вне типовых задач? Какие критерии подключения к делу (порог критичности инцидента) этих более опытных товарищей?
Интересен ваш опыт по Incident Response с точки зрения людей.

Насколько я помню по прошлым публикациям у вас есть 2 линии обработки инцидентов. Первая линия «массовка» обрабатывает «типовые» сценарии. Вторая «тру-антихакеров» подключается в сложных случаях. Как обучаете 1-ю линию? Проводите ли «Курс молодого бойца» по разбору инцидентов? Есть ли инструкции на каждый типовой инцидент (при бруте делай то, смотри туда)?

Про это мы чуть позже напишем отдельный материал, но общая механика такая:

  • Да, первую линию обучаем — и основам информационной безопасности, и опыту работы с логами, и тому как устроены Kill Chain, и какой импакто может лежать за каждым инцидентом.
  • Инструкции по типовым инцидентам есть, но они не пошаговые — cлишком много сценариев и вариантов. Это скорее описание того, что нужно найти по итогам инцидента, основных мест, где можно анализировать информацию, и того, что обязательно надо проверить (критерии false-positive, обязательная к предоставлению информация по инциденту и т.д.)

Дальше много нюансов, но это уже в отдельной статье :)

А 2 линия «тру-антихакеры» у вас свободные художники которые разбирают APT стоящие вне типовых задач? Какие критерии подключения к делу (порог критичности инцидента) этих более опытных товарищей?

За 2-й линией стоит еще и 3-я, и 4-я, и отдельная команда форенсики, но да, идея примерно такая. У инженеров 2-й линии больше опыта и есть некоторая специализация по задачам. К анализу инцидента они подключаются в нескольких случаях:

  • когда инцидент априори сложный или еще не обкатан массово по 1-й линии;
  • когда с заказчиком согласована углубленная аналитика по инциденту;
  • когда конкретный инженер 1-й линии или не может справиться с задачей, или увидел «странное»;
  • ну, и наконец, когда очень высока нагрузка и нужно просто помочь 1-й линии. SOC — это командная работа :)
Спасибо. Ждём статью.
Не хватает варианта.
«SOC — модная фишка и всё. Новый виток развития сервиса удалённого админа.»
Вы непротив включить и этакой вариант?

Sign up to leave a comment.