Часто при построении SOC возникает вопрос, как оценить его эффективность? По каким метрикам отследить это и на что обратить внимание? На онлайн питч-сессии v. 2.0 «Опыт ошибок SOC: срывая покрывала» начальник отдела обеспечения ИБ МТС Андрей Дугин выделил в качестве критериев временные отрезки начала инцидента, его обнаружения и предотвращения. В то как директор Solar JSOC «Ростелеком-Солар» Владимир Дрюков считает главным критерием просто увидеть атаку.
«Если процесс — начало инцидента, его обнаружение и предотвращение — оцифрован и его формула «время-деньги» работает, тогда оценить довольно просто. Но не все процессы оцифрованы, не все инциденты оцифрованы на тему денег, поэтому в некоторых случаях получается немножко сложнее. Но вкратце оцениваем таким образом: а вот если бы мы это не увидели и не среагировали, что бы произошло? Это один их подходов», — поделился своим опытом Андрей Дугин.
Далее он подробно рассказал, как эта схема работает у них в компании. Условно говоря, они запускают в инфраструктуру пентестеров, где те начинают делать свои «чёрные» дела, и SOC при этом не предупреждают. Для начала пентестер пытается проникнуть в инфраструктуру. По словам Андрея Дугина, у них на входе стандарт IEEE 802.1X, который можно либо обмануть, либо пробить. При этом он признался, что никогда не видел, чтобы его пробивали, чтобы обманывали — видел. И пентестер либо обманывает каким-то образом, либо говорит, что не может пройти и просит впустить. Во втором случае в компании ставят себе галочку, что мера защиты работает. Дальше, после того как пентестер попадает в корпоративную сеть, он начинает что-то делать — тут включается счётчик. От начала противоестественных действий пентестера и до того, как SOC это увидит — это счётчик времени реагирования. Дальше у SOC есть на эту тему плейбуки. Эти плейбуки говорят, что при таком-то действии выполняем то-то. Как правило, если какой-то хост начинает что-то сканировать, какую-то противоестественную деятельность генерировать, блокируется порт, на котором сидит этот пользователь, либо блокируются атрибуты его доступа в корпоративную сеть, чтобы он не попал через другой порт (в зависимости от технологии, по которой он подключается). Соответственно, это время реагирования и время отражения.
«Получается, можно сделать такой квадратик на подобие Декартовой системы координат, когда плюс-минус. Плюс — это значит, что всё быстро сделали. Минус — это значит, что медленно сделали. То есть если мы быстро обнаружили, быстро отразили, это говорит, что мы, как информационная безопасность, как SOC — молодцы, но нам стоит подумать в сторону полной автоматизации этого действия либо введения превентивных мер. Если мы быстро среагировали, но медленно отразили, особенно если это касается взаимодействия с другими подразделениями — тут вопрос в процессах взаимодействия между SOC и подразделением, которого рычаги для отражения. Если мы медленно обнаружили просто по каким-то косвенным признакам, но быстро отразили — это означает, что мы где-то не дособираем информацию либо мы ее плохо коррелируем и здесь нужно докручивать то, что у нас в SOC. И если мы и медленно обнаружили, и медленно отразили — нам нужно усовершенствовать и тот, и другой процессы», — пояснил Андрей Дугин.
Помимо этого важной метрикой является зона покрытия SOC, которая тоже выявляется за счёт пентеста. Однако есть ещё и «серые» зоны, когда ни SOC не показал, ни пентестер не показал. И тут тоже возможные разные варианты. Например, что этой самой «серой» зоны в инфраструктуре просто нет. Или, наоборот, это полное и настолько теневое ИТ, что его не смогли обнаружить ни SOC, ни пентестеры. «И я для себя понял, чтобы найти «серые» зоны, нужно сравнивать отчёты SOC и пентестеров с системой инвентаризации», — добавил Андрей Дугин.
Немного другой точки зрения придерживается Владимир Дрюков. По его словам, ключевая метрика для оценки эффективности SOC — «это просто увидеть».
«Если SOC не смог увидеть, идентифицировать атаку, то всё остальное — насколько быстро он прореагировал, насколько быстро ликвидировали последствия — вторично. Поэтому сейчас есть тренд, что реагирование ставят впереди и более значимым, чем мониторинг. И как раз на вопросе с мониторингом история с red team или тестированием становится значимой — накосячить можно где угодно», — пояснил Владимир Дрюков.
