А не маловато функций чтобы именоваться SOC, у нас тогда любой отдел ИБ по этим признакам является SOCом

SOC - это всего лишь хайповый термин, взятый на флаг одной из российских компаний. За термином скрываются процессы и именно они важны. Если у вас есть названные мной выше процессы (сбор, реагирование, обмен), то можно говорить, что у вас уже есть SOC 😊  Но именно процессы, а не инструменты (SIEM,  IRP и т.п.). А дальше уже SOC вы можете набивать дополнительными сервисами - от Red Team до киберучений

В идеале менеджмент инцидентов и реагирование на атаки - это совсем разные активности. Реагирование на атаку начинается в момент появления первых подозрений и в идеале заканчивается на "хрен вам, а не доступ в АСУ ТП". Это - задача ИБшников и примкнувших к ним ИТшников.

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

Поэтому да, обнаружение атак и реагирование на них требует совсем других действий и совсем других участников

Я ни слова не сказал про инструменты)))

В идеале, а что мы регистрируем в случае атаки? Не будет ли это дублированием карточки инцидента?

Всё таки на SOC, чуть шире смотрим, подразумеваем автоматизацию этих процессов, единую консоль.

Автоматизация да. Единая консоль - недостижимое желание

Алексей, а есть какие-то международный опыт с подобным законодательством, или. как скажем в США устроенна подобна система с их обьектами критической инфраструктуры?

Законодательство есть. ГосСОПКИ у них под КИИ  нет

Как единую консоль SCOM было желание допилить, но навыков не хватило.

Цель в масштабе страны - сделать так, чтобы владельцы бизнеса не превращали свои проблемы в проблемы окружающих :) Всем глубоко наплевать на остановку контроллера в цеху, но ровно до тех пор, пока эта остановка не приведет к срыву поставок по ГОЗ :)

Спасибо!

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

CWE-428 The service path in some Yokogawa applications are unquoted and contain spaces.When the service path is unquoted and contain spaces, a local attacker could execute malicious file by the service privilege.

CVSS v3 Base Score: 8.4, Temporal Score: 8.0AV:L/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H/E:H/RL:O/RC:C

Yokogawa products: Exaopc(R1.01.00 - R3.77.00)• Exaplog(R1.10.00 - R3.40.00) • Exaquantum(R1.10.00 - R3.02.00)• Exaquantum/Batch(R1.01.00 - R2.50.40)• Exasmoc(All Revisions) • Exarqe(All Revisions) • GA10(R1.01.01 - R3.05.01) • InsightSuiteAE (R1.01.00 - R1.06.00)

https://bdu.fstec.ru/vul/2019-03319
https://web-material3.yokogawa.com/1/28032/files/YSAR-19-0003-E.pdf

Бигдатое машинное обучение жеж всех спасет

Вменяемая концепция всех спасет. А бездумное применение тех или иных инструментов только усугубит проблему. ☺️

SIEM регистрирует алерты. Смотрящий за SIEMом (в SOCе - первая линия SOC) отбрасывает FP, по оставшимся алертам зовет кого-то более компетентного. Необходимый минимум уже зарегистрирован в SIEM, заводить дополнительную бюрократию не вижу смысла.

Если оказалось, что алерт действительно связан с атакой - реагируем на действия атакующего. В идеале давим его, не дав развернуться и рисуем звездочку на фезюляже. Для лучшей лучшести можно задокументировать кейс, если они относительно редки.

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

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

Деньги в бюджете закончатся раньше :)