Нам ставят условие «команда реагирования на киберинциденты» — реально ли это нужно компании из 15 человек?

Крупные корпорации копируют свои внутренние стандарты и кладут их перед поставщиком. Поговорите напрямую с их службой безопасности. Они и сами знают, что в структуре из 15 человек нельзя создать внутреннюю команду CSIRT. Если покажете договор с внешней поддержкой и внутреннюю матрицу эскалации, они дадут одобрение.

Похожий пункт встал и перед нашей командой из 20 человек в Дубае. За 12.000 AED в год мы заключили договор на реагирование по вызову с одной компанией по безопасности. Они обязались реагировать в течение 4 часов. Аудиторский отдел клиента принял этот документ, и мы подписали контракт.

edit: исправил несколько опечаток.

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

Не смотрите на то, что менеджер говорит "это не обсуждается" — они просто посредники. Пункты по безопасности согласовываются напрямую с CISO или риск-командой заказчика. Если уровень данных, к которым получает доступ ваша компания не критичен, этот пункт можно вообще вывести за рамки — вплоть до полного исключения.

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

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

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

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

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

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

Попробую.

У меня есть возражение. Забытые тестовые среды становятся входом в систему чаще чем продакшн.

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

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

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

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

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

это мое мнение не утверждаю, что оно единственно верное.

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

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

Не могли бы вы это пояснить? Автоматический отчет о сканировании и пентест — это не одно и то же.

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

Я долго занимался этим вопросом. Чем сложнее отменить решение, тем медленнее его принимайте.

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

Абсолютно. Если добавить к этому: Не полагайтесь на одну меру защиты; действуйте слоями.

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