Запросили процедуру реагирования на киберинциденты — кто у нас в таком масштабе будет её писать и с чего начать?

Крупные компании теперь включают эти пункты в стандартные договоры, чтобы управлять рисками поставщиков. Только не вздумайте копипастить из интернета текст, где встречаются термины вроде «команда SOC», «центр безопасности». Если завтра при мелкой накладке вас спросят «а вы применили свою процедуру?», вы не отмажетесь.

Прямо сейчас возьмите лист А4 и поставьте сверху телефонную цепочку экстренной связи. 1) Кто сообщит тому, кто первым заметил инцидент? 2) Кто отрубит рубильник или интернет? 3) По какому шаблону письма уведомят клиента? Оформить это в Word и утвердить — и дело сделано.

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

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

Ваш клиент требует только наличия документа или вместе с процедурой запросил ещё и приложения вроде отчёта об учениях за последний год или результатов пентеста? Вы внимательно посмотрели остальные пункты техзадания?

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

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

Эти документы, которые требуют отделы корпоративных закупок, по большей части нацелены на базовые контроли стандарта ISO 27001. Если в подготовленном тексте вы отразите обязанности по уведомлению об утечках данных по KVKK и механизм утверждения руководством, это обеспечит полную защиту и с точки зрения юридического соответствия.

После того случая мой взгляд на вещи изменился. Решения, работающие в малом масштабе, рушатся при росте, я узнал это слишком поздно.

Оставлю как заметку, пригодится.

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

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

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

Удачи.

Появились три разных мнения, они дополняют друг друга. Безопасность не бывает абсолютной; цель — сделать атаку нецелесообразной.

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

Согласен с этим. Когда пытаешься изменить всё сразу, ничего не приживается.

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

Этот совет подойдет не всем, на мой взгляд. Все, кто торопится с процедура реагирования на киберинциденты, спотыкаются на одном и том же.

Интересно, есть ли те, кто делает иначе.

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

испраавьте если я ошибаюсь.

Именно так. Доступность резервной копии в той же сети и под той же учетной записью делает ее частью цели атаки.

Когда пытаешься изменить всё сразу, ничего не приживается.

Этот совет подойдет не всем, на мой взгляд. Спешка в решениях оборачивается исправлениями через полгода.

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

Давайте немного раскрою техническую сторону. Автоматический отчет о сканировании и пентест — это не одно и то же.

Если напишете результат здесь, это поможет и другим.