От нас требуют классифицировать инциденты по «таксономии» — что это вообще и почему всё так усложняет?

Не усложняйте. Заведите обычную таблицу с колонками: «Дата», «Категория», «Уровень критичности», «Затронутый ресурс» и «Принятые меры». Вам не придется строчить туда тысячи строк ежедневно — фиксируйте только реальные кейсы, куда вы вмешивались руками, раз в неделю или месяц.

Мы пару лет назад выкатили классификацию на 15 категорий, в итоге команда только формы заполняла вместо работы, а среднее время реагирования подскочило с получаса до двух часов. В прошлом году урезали всё до 3 базовых разделов — теперь абсолютно все инциденты фиксируются вовремя и без нытья.

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

Аудиторам и страховым компаниям эта таксономия нужна по одной причине: они хотят быть уверены, что в случае ЧП вы сможете внятно вскрыть первопричину. Чтобы при утечке данных вы не разводили руками «сервер упал», а четко фиксировали «несанкционированный доступ через социальную инженерию».

При оценке любого кейса используйте 3 золотых фильтра: 1) Пострадала ли целостность или конфиденциальность данных? 2) Упал ли сервис для клиентов? 3) Возникли ли юридические или договорные обязательства по уведомлению? Если везде ответ «нет», то это не инцидент для реестра, а обычный системный лог.

А в анкете страховой прописан конкретный стандарт (скажем, ISO 27035 или NIST SP 800-61), или их устроит любая зафиксированная внутренняя методика? Обычно своего регламента на пару страниц хватает за глаза.

Крупные консалтинговые конторы подают это так, будто бизнесу на 5 человек кровь из носу нужен круглосуточный SOC. На практике на большинстве клиентских аудитов показываешь аккуратную табличку на одну страницу со словами «мы вот так размечаем инциденты» — и вопросы сразу отпадают.

перед нашим первым аудитом мы тоже запаниковали и стянули из сети 40-страничную таксономию по стандартам НАТО. аудитор только усмехнулся и спросил: «Вы реально по этому работаете?». чем система проще тем она жизнеспособнее.

У меня будет вопрос, не хочу уходить от темы, но... Главное не цифра, а то, на основе чего она получена.

Я бы пошел этим путем.

Я столкнулся с тем же два года назад. То, что делают все, не значит, что это правильно.

Надеюсь, это будет полезно.

взял на заметку, спасибо.

Именно так и при этом об этом мало кто знает. Меры, принятые без инвентаризации оставляют открытыми двери, о которых вы не знаете.

Вы правы.

Извините, но это верно не во всех случаях. Если на один вопрос вы получаете три разных ответа, вопрос задан неправильно.

Ошибка, сделанная на стороне таксономия инцидентов ИБ, обычно исправима, но дорого. Это мое мнение, не утверждаю, что оно единственно верное.

Очень актуальная тема.

Здесь есть ловушка, не могу промолчать. Чем сложнее отменить решение, тем медленнее его принимайте.

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