От нас требуют план реагирования на инциденты по NIST — внедрять его или делать свой вариант?

Без нормальной работы с логами никакой аудит по NIST вы не пройдете. Настройте базовый сброс логов с серверов, админских входов и фаерволов в отдельное хранилище в режиме read-only. Если при инциденте вы не сможете доказать, что злоумышленник не потер за собой логи, весь этап анализа пойдет коту под хвост.

При составлении регламента четко зафиксируйте три вещи: 1) Градация инцидентов (низкий, средний, критический) — по каким критериям? 2) В какой срок вы обязаны уведомить клиента и регуляторов (в часах)? 3) Кому переходят полномочия, если ЛПР недоступен? Проверяющие первым делом смотрят именно туда.

Корпоративные аудиторы обычно приходят со стандартными чек-листами. Вы расшибетесь в лепешку, вылизывая NIST до идеала, а аудитор просто проставит галочки в своей форме. Не усложняйте себе жизнь: сделайте аккуратный драфт под минимальные требования и заранее согласуйте его с клиентом.

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

Главное правило: прописывайте в регламенте роли и должности, а не конкретные имена. Напишете «Ahmet гасит сервер» — сотрудник уволится, и документ придется переделывать. Пишите «Системный администратор изолирует узел», «Менеджер проекта уведомляет заказчика». Так регламент будет жить годами.

А штабные учения — это как на практике выглядит? честно просто садимся в переговорке и гоняем сценарий на словах, или надо реально тестовые сервера ронять и проверять руками?

Обратите внимание на сроки уведомления об инцидентах: сверьте их с вашим основным договором и NDA с клиентом. Сроки в плане NIST не должны быть больше, чем зафиксировано в контракте, иначе при первой же проблеме налетите на юридические претензии.

Насколько я понимаю, суть не в том, чтобы строчить тома макулатуры. Нужно распределить роли, обезопасить логи, набросать схему изоляции и раз в год оформлять протокол учений. Для небольших команд этого более чем достаточно.

хорошо что вы созздали эту тему потом две недели ведения заметок дают лучший результат чем шестимесячные прогнозы.

непроверенная реервная копия — не резервная копия потом честно удачи.

Эта тема в архиве. Если делаете впервые, начните с малого, масштабирование потом.

Любой пункт, не зафиксированный письменно, в будущем обе стороны будут помнить по-разному.

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

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

На что обратить внимание при выполнении этого. Начните с небольшого эксперимента не привязывайте всё сразу.

То что делают все, не значит, что это правильно. Пишите, если есть вопросы, отвечу по мере возможности.

Не знал об этом.

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

Я тоже так считаю. Без измерений мы всегда приходим к одному и тому же.

На этом всё, извините, если затянул.

Вы правы.

Я сталкивался с тем же.

Мы тоже какое-то время назад застряли на том же месте. Решения, работающие в малом масштабе, рушатся при росте, я узнал это слишком поздно.

Проверено опытом.