Представьте встречу производителя средств информационной безопасности с потенциальным заказчиком. Пресейл-инженер открывает презентацию на 48 слайдов. Сначала история компании, затем карта офисов, награды, сертификаты, партнёры и внушительный список технологий. Через полчаса заказчик уже знает, что SIEM обрабатывает тысячи событий в секунду, а NGFW поддерживает десятки механизмов защиты. Но зачем покупать продукт, по-прежнему непонятно.
Возможно, решение действительно хорошее. Возможно, заказчику давно не хватает именно такой системы. Однако технический специалист рассказывает о возможностях продукта, тогда как руководитель ИБ пытается понять, какие проблемы исчезнут после внедрения, сколько придётся потратить и кто будет обслуживать новую инфраструктуру.
Пресейл в информационной безопасности сложнее обычной демонстрации программного обеспечения. Продукт часто продаётся ради предотвращения событий, которые ещё не произошли. Нельзя достоверно подсчитать количество атак, которые система предотвратит в будущем, а снижение киберрисков далеко не всегда превращается в прямую экономию денег.
Поэтому сильная пресейл-презентация строится вокруг другого принципа. Не пытайтесь доказать, что продукт умеет много. Покажите, какую конкретную проблему заказчика продукт способен решить, какие условия для этого потребуются и как проверить результат.
Разберём подготовку первой технической встречи, структуру презентации из 14 слайдов, особенности продажи SIEM, DLP, NGFW и EDR. Заодно выясним, какие цифры действительно убеждают заказчика, почему демонстрации часто вводят в заблуждение и как превратить красивое обещание в проверяемый пилотный проект.
1. До презентации нужно выяснить, что заказчик собирается купить на самом деле
Обычная ситуация. Менеджер сообщает пресейл-инженеру, что крупная компания интересуется SIEM. Инженер готовит архитектуру платформы, описание корреляции и демонстрацию расследования инцидента. На встрече выясняется, что у заказчика уже работает SIEM, а настоящая проблема заключается в дорогом хранении событий и недостатке специалистов для сопровождения правил.
В результате поставщик полчаса продаёт функции, которые у заказчика уже есть.
Похожая история возникает с DLP. Компания запрашивает систему предотвращения утечек, но в действительности руководство хочет контролировать отправку документов через несколько конкретных каналов. Презентация универсальной платформы с десятками функций не отвечает на вопрос, насколько хорошо продукт справится именно с нужными сценариями и сколько ложных блокировок создаст.
Пресейл начинается с выявления задачи, а не выбора красивого шаблона PowerPoint.
Семь вопросов, которые нужно задать до встречи
Оптимально провести предварительный разговор с заказчиком продолжительностью около 20–30 минут. Время условное, но даже короткая беседа полезнее, чем подготовка презентации исключительно по названию интересующего продукта.
| Вопрос | Зачем спрашивать | Как использовать ответ |
|---|---|---|
| Почему проект появился сейчас? | Выяснить причину интереса к покупке. | Связать предложение с инцидентом, аудитом, модернизацией, ростом инфраструктуры или другими реальными обстоятельствами. |
| Что не устраивает в текущей защите? | Отделить потребность в новой технологии от проблем настройки существующей. | Показать конкретные ограничения, которые продукт способен устранить. |
| Какие системы уже используются? | Определить возможности интеграции и вероятные конфликты. | Подготовить архитектуру с учётом действующих средств защиты. |
| Какие процессы занимают больше всего ресурсов? | Найти потенциальные точки экономии времени и снижения нагрузки. | Выбрать измеримые рабочие сценарии. |
| Какие ограничения нельзя нарушать? | Выяснить требования к размещению, совместимости, доступности, сертификации и обработке данных. | Не предлагать архитектуру, которую невозможно внедрить. |
| Кто принимает решение? | Понять интересы технической команды, руководства и закупок. | Подготовить аргументы для каждого участника. |
| По каким критериям выберут поставщика? | Выяснить, что будет считаться успешным результатом. | Связать презентацию с критериями технической оценки и последующего пилота. |
Есть ещё один вопрос, который продавцы задают редко. Что произойдёт, если заказчик вообще ничего не купит?
Допустим, команда SOC получает слишком много уведомлений. Возможно, проблему решит новая SIEM. Но не исключено, что достаточно пересмотреть существующие правила корреляции, отключить бесполезные источники событий и наладить процессы обработки инцидентов.
Если покупку можно заменить небольшой доработкой, заказчик рано или поздно обнаружит альтернативу. Лучше обсудить её сразу, чем построить коммерческое предложение на ложной предпосылке.
Не все участники встречи покупают одно и то же
Для начальника SOC ценность SIEM заключается в качестве обнаружения и удобстве расследования. Руководитель ИБ оценивает покрытие существенных рисков. Финансовый директор смотрит на полную стоимость владения, а системный архитектор опасается новой точки отказа и сложной интеграции.
Разговор с каждым участником требует собственного уровня аргументации.
| Участник | Что хочет узнать | Что показать |
|---|---|---|
| Руководитель ИБ | Какие риски станут более управляемыми? | Угрозы, целевое состояние, критерии результата и остаточные риски. |
| Руководитель SOC | Как изменится обнаружение и реагирование? | Сценарии атак, качество уведомлений, процесс расследования. |
| Технический архитектор | Совместимо ли решение с инфраструктурой? | Архитектуру, интеграции, производительность и отказоустойчивость. |
| Эксплуатационная команда | Сколько работы добавит продукт? | Обновления, резервирование, мониторинг, сопровождение и поддержку. |
| Финансовый директор | Сколько стоит решение и чем оправданы расходы? | Полную стоимость владения, измеримые результаты и альтернативы. |
| Закупки и комплаенс | Соответствует ли предложение обязательным условиям? | Документы, подтверждённые характеристики, условия поставки и поддержки. |
Нельзя механически применять совет «не начинайте с сертификатов» ко всем сделкам. Если заказчик прямо обозначил обязательное требование к сертификации или реестровому статусу продукта, соответствие придётся подтвердить до обсуждения преимуществ. Однако после прохождения обязательного критерия сертификаты уже не заменяют доказательство эффективности.
Сформулируйте ценность продукта одним предложением
Перед созданием слайдов полезно написать короткую формулировку.
«Для компании, которая сталкивается с [конкретной проблемой], наше решение позволяет [изменить процесс или снизить риск] за счёт [технического механизма]. Результат можно проверить по [измеримым критериям] при [необходимых условиях]».
Например, для EDR.
«Компания хочет быстрее расследовать подозрительную активность на рабочих станциях. EDR собирает сведения о процессах, файлах и сетевых соединениях, связывает действия в единую последовательность и предоставляет средства реагирования. Во время пилота проверим обнаружение согласованных сценариев, время расследования и влияние агента на работу компьютеров».
Фраза не обещает абсолютной защиты от вредоносного ПО. Зато заказчик понимает, что именно предлагается проверить.
Подобный подход помогает отделять кибербезопасность как бизнес-результат от покупки конкретной технологии. В NIST Cybersecurity Framework 2.0 задачи управления киберрисками также описываются через желаемые результаты, а не через обязательный набор продуктов. Поэтому сначала полезно определить нужный результат и только затем выбирать средство защиты.
Для подготовки можно использовать четыре рабочих документа. Краткую карточку заказчика, список проблем, перечень неподтверждённых гипотез и таблицу критериев успеха. Неизвестные сведения нельзя выдавать за факты даже ради эффектного первого слайда.
2. Готовая структура пресейл-презентации из 14 слайдов
Универсального числа слайдов не существует. Для первой предметной встречи обычно достаточно 10–15 содержательных страниц, если подробные технические сведения вынесены в приложение.
Предлагаемая структура состоит из 14 слайдов. Основной пример посвящён SIEM для условной организации с несколькими площадками, действующими средствами защиты и собственной командой SOC. Сведения о заказчике вымышленные, чтобы показать принцип построения презентации.
Что разместить на каждом слайде
| Слайд | Задача | Пример содержания |
|---|---|---|
| 1. Какой результат предлагаем | Сразу объяснить смысл встречи. | «Как сократить ручной поиск связанных событий при расследовании атак». Подзаголовок о сборе данных, корреляции и едином контексте инцидента. Название продукта и логотип производителя присутствуют, но не занимают большую часть страницы. |
| 2. Что известно о заказчике | Показать понимание инфраструктуры и задач. | Несколько площадок, действующие средства защиты, собственная команда SOC. Рядом отдельно указаны гипотезы, которые потребуется подтвердить. |
| 3. Где возникает проблема | Показать существующий рабочий процесс. | Аналитик получает события из разных консолей, вручную сопоставляет данные и собирает контекст для расследования. Схема основана на подтверждённом процессе заказчика. |
| 4. Чем проблема обходится компании | Связать технические трудности с последствиями. | Трудозатраты, вероятность пропустить связанную активность, длительность расследований, сложность отчётности. Числа приводятся только при наличии измерений. |
| 5. Как должен выглядеть процесс | Показать целевое состояние. | События поступают в единую систему, связываются с контекстом активов, аналитик получает карточку инцидента и действует по регламенту. |
| 6. Реалистичный сценарий атаки | Сделать проблему конкретной. | После компрометации учётной записи злоумышленник выполняет подозрительные входы и обращается к критическому серверу. Показано, какие события нужны для выявления последовательности. |
| 7. Как продукт решает задачу | Объяснить технический механизм. | Сбор журналов, нормализация, корреляция, обогащение сведениями об активах, приоритизация и передача инцидента аналитику. |
| 8. Архитектура внедрения | Объяснить размещение компонентов. | Источники, коллекторы, обработка событий, аналитическая подсистема, хранилище и консоль SOC. Отдельно показаны границы сети и основные требования к ресурсам. |
| 9. Интеграция с существующими системами | Снизить неопределённость проекта. | Подключение контроллеров домена, EDR, межсетевых экранов, серверов и системы заявок. Для каждого подключения обозначены необходимый протокол, версия и ограничения. |
| 10. Почему выбрана такая архитектура | Обосновать преимущества без рекламного сравнения. | Два-три критерия проекта, например обработка нужных источников, удобство расследования и требования к размещению. Преимущества связаны с проверяемыми возможностями продукта. |
| 11. Какие доказательства уже есть | Подтвердить реалистичность предложения. | Сопоставимый проект, результаты технических испытаний или воспроизводимая демонстрация. Масштаб и условия указаны явно. |
| 12. Как выглядит работа системы | Показать законченный сценарий. | Открытие инцидента, изучение событий, проверка актива, принятие решения и передача задачи на реагирование. |
| 13. Сколько ресурсов потребуется | Обсудить внедрение и эксплуатацию. | Лицензирование, объём событий, вычислительные ресурсы, хранение, настройка правил, обучение, сопровождение, план миграции и существенные риски. |
| 14. Что проверим на пилоте | Предложить конкретный следующий шаг. | Перечень источников, сценарии обнаружения, метрики, критерии приёмки, ответственные и порядок принятия решения после испытаний. |
Последовательность принципиальна. Слайды 1–5 объясняют проблему и желаемые изменения. Слайды 6–10 связывают задачу с техническим механизмом. Слайды 11–14 переводят обещания в доказательства и план действий.
Если первая встреча назначена с техническими специалистами, можно увеличить время на архитектуру и демонстрацию. Для руководства лучше сократить описание внутренних компонентов и подробнее разобрать риски, экономику и условия внедрения.
Не нужно пытаться разместить весь технический паспорт продукта на 14 слайдах. Развёрнутые таблицы совместимости, схемы отказоустойчивости, сертификаты, перечни поддерживаемых платформ и лицензионные условия лучше держать в приложении.
Как адаптировать презентацию под SIEM, DLP, NGFW и EDR
Каркас остаётся общим, но ценность каждой технологии различается. Замена логотипа и нескольких технических терминов полноценной адаптацией не считается.
| Продукт | Заголовок первого слайда | Центральный сценарий | Что нужно доказать |
|---|---|---|---|
| SIEM | «Как SOC быстрее расследовать связанные события из разных систем» | Подозрительные входы, изменение привилегий и обращение к критическому серверу. | Полноту нужной телеметрии, качество корреляции, удобство расследования и стоимость хранения. |
| DLP | «Как контролировать передачу конфиденциальных документов без постоянных ложных блокировок» | Сотрудник пытается отправить тестовый документ с чувствительными данными через контролируемый канал. | Качество классификации, охват каналов, работу политик и отсутствие чрезмерных ограничений. |
| NGFW | «Как ограничить нежелательный сетевой доступ без потери устойчивости бизнес-сервисов» | Скомпрометированный сервер пытается обратиться к защищённому сегменту. | Работу правил, необходимую производительность, отказоустойчивость и совместимость. |
| EDR | «Как обнаруживать подозрительные действия на узлах и быстрее переходить к расследованию» | Подозрительный процесс запускает последовательность действий на тестовой машине. | Качество обнаружения, контекст инцидента, доступные меры реагирования и влияние агента. |
У DLP есть дополнительная сложность. Контроль конфиденциальных документов может затрагивать переписку и другие данные сотрудников. Поэтому необходимо обсудить не только обнаружение утечек, но и доступ аналитиков к собранной информации, сроки хранения и правила работы с персональными данными.
У NGFW особенно критична производительность с активированными защитными механизмами. Шифрованный трафик, проверка содержимого и разные профили соединений могут существенно менять нагрузку. Указанная в паспорте скорость пересылки пакетов не равнозначна производительности при конкретной политике безопасности.
О том, как ошибки тестирования и особенности конфигурации влияют на выбор межсетевого экрана, мы уже подробно разбирали в материале о тестировании NGFW.
Для EDR отдельной темой становится поддержка операционных систем. Наличие агента для Linux или Windows ещё не доказывает одинаковую функциональность на всех версиях и конфигурациях. Потребуется проверить совместимость с критическим ПО, исключения, автономную работу и поведение при потере связи с сервером управления.
SIEM, в свою очередь, особенно зависит от состава и качества журналов. Даже хорошее правило корреляции бессильно, если нужные события не собираются, запаздывают или приходят с несогласованными временными метками. Подробнее устройство такой платформы можно изучить в разборе архитектуры SIEM.
3. Как превратить технические характеристики в доказательство ценности
«Высокопроизводительная аналитическая платформа с интеллектуальными механизмами корреляции и машинным обучением» звучит солидно. Но заказчику трудно понять, какие рабочие процессы изменятся после покупки.
Пресейл-инженеру полезно различать три уровня аргументации.
Функция описывает техническую возможность. Преимущество объясняет, почему возможность полезна. Ценность показывает измеримое изменение в конкретной работе заказчика.
Например, «EDR поддерживает изоляцию конечной точки» является описанием функции. «Аналитик может ограничить сетевое взаимодействие подозрительной машины из консоли» объясняет преимущество. А «во время тестового инцидента команда сможет проверить, насколько быстро изолирует узел без ручной перенастройки сетевого оборудования» переводит техническую возможность в проверяемый результат.
Разница хорошо заметна на типичных формулировках производителей.
| Рекламная характеристика | Что лучше сказать заказчику |
|---|---|
| «SIEM поддерживает тысячи правил корреляции». | «Проверим, обнаруживает ли система наиболее существенные для вашей инфраструктуры цепочки атак и сколько ручной работы потребуется для сопровождения правил». |
| «DLP использует интеллектуальную классификацию документов». | «Проверим, отличает ли система конфиденциальные документы от похожих разрешённых файлов и как часто ошибается». |
| «NGFW обладает высокой пропускной способностью». | «Измерим скорость и задержки на вашем профиле трафика с включёнными необходимыми функциями защиты». |
| «EDR обеспечивает автоматическое реагирование на угрозы». | «Проверим, какие действия можно выполнить без участия администратора и не создают ли автоматические блокировки недопустимый риск простоя». |
Технический термин сам по себе не запрещён. Если презентация предназначена инженерам, упрощать устройство продукта до уровня рекламного ролика бессмысленно. Но даже технической аудитории нужно объяснить, какую проблему решает конкретный механизм.
Одна атака лучше двадцати скриншотов интерфейса
Наиболее убедительная часть технической презентации часто строится вокруг законченного сценария.
Предположим, поставщик показывает SIEM. Вместо последовательного открытия меню, правил, панелей и справочников инженер демонстрирует действия условного злоумышленника.
- В тестовой среде происходит подозрительный вход под учётной записью.
- Система получает сведения об аутентификации и последующих действиях.
- Заранее определённое правило связывает события при выполнении условий корреляции.
- Аналитик открывает карточку инцидента и видит доступный контекст.
- Специалист проверяет актив, оценивает риск и выбирает дальнейшее действие.
Получается понятная история. Заказчик видит не просто модуль корреляции, а рабочий процесс обнаружения и расследования.
Для систем обнаружения полезно связывать испытания с техниками MITRE ATT&CK. База позволяет систематизировать поведение злоумышленников и подбирать реалистичные сценарии.
Но распространённое рекламное обещание «Покрываем 95% MITRE ATT&CK» почти ничего не значит без методики. Одна техника может реализовываться несколькими способами. Наличие правила обнаружения не доказывает, что продукт увидит все варианты поведения. Для практической оценки нужно учитывать условия, источники телеметрии, качество уведомлений и вероятность пропуска.
Поэтому вместо общей карты с зелёными клетками лучше показать три сценария, непосредственно относящихся к угрозам заказчика, и честно объяснить, что система обнаруживает, а что остаётся вне её возможностей.
Архитектура должна показывать не только преимущества, но и цену внедрения
Популярный архитектурный слайд выглядит как облако с десятками логотипов и стрелками во все стороны. Обычно такая схема демонстрирует широкий набор потенциальных интеграций, но не отвечает на практические вопросы заказчика.
Куда поступают журналы? Сколько сетевого трафика появится? Что произойдёт при отказе коллектора? Кто отвечает за обновления и резервное копирование? Сколько места потребуется под хранение?
Для SIEM технически полезная схема выглядит гораздо проще.
Источники событий → коллекторы → нормализация и обработка → хранение и аналитика → карточка инцидента → аналитик SOC.
Далее необходимо показать, где размещается каждый компонент, какие данные передаются через сетевые границы, какие системы остаются у заказчика и какие ресурсы предоставляет поставщик.
Особенно полезно уже на пресейле оценить поток данных. Возьмём условную SIEM, получающую 1000 событий в секунду. Если средний размер передаваемого события составляет 1 килобайт, объём исходных данных за сутки приблизительно равен 86,4 ГБ. За 30 суток получится около 2,59 ТБ.
Расчёт не учитывает накладные расходы, индексы, репликацию, различия между объёмом исходных и нормализованных данных, компрессию и архитектуру хранения. Тем не менее предварительная оценка быстро показывает, почему стоимость SIEM нельзя определять исключительно по лицензии.
У разных продуктов единицей лицензирования могут служить события в секунду, объём данных, устройства, пользователи, вычислительные ресурсы или комбинация параметров. Поэтому конкретную модель необходимо проверять до коммерческого расчёта.
Для NGFW полезно показывать не только схему сетевых соединений, но и режим высокой доступности, особенности переключения на резервный узел и политику поведения при неисправности. Нельзя обещать бесшовное сохранение всех сеансов без проверки конкретной реализации.
Для DLP схема должна раскрывать контролируемые каналы, размещение агентов и шлюзов, правила хранения инцидентов и права доступа специалистов. Для EDR потребуются границы распространения агентов, механизм управления, порядок обновлений, исключения и действия при потере связи.
Какие цифры действительно убеждают заказчика
Число обработанных событий, объём памяти или количество правил характеризуют возможности продукта, но не являются самостоятельным доказательством эффективности защиты.
Более полезны показатели, связанные с рабочими задачами.
| Продукт | Полезные метрики | Типичная ловушка |
|---|---|---|
| SIEM | Доля обнаруженных проверочных сценариев, время появления уведомления, время расследования, доля лишних тревог, стоимость обработки и хранения данных. | Правила заранее настроены под известные тесты, а ложные срабатывания не проверялись. |
| DLP | Обнаруженные запрещённые передачи, ошибочные блокировки, охват требуемых каналов, время разбора инцидентов. | Тестируют только явно помеченные документы, не проверяя похожие разрешённые файлы. |
| NGFW | Пропускная способность с рабочими настройками, задержка, соединения, проверка правил, устойчивость к отказам. | Заявленную скорость измеряли с отключённой частью защитных механизмов. |
| EDR | Обнаруженные сценарии, полнота контекста, ложные тревоги, время реагирования, нагрузка агента и стабильность работы. | Испытания ограничены заранее известными сценариями на одной поддерживаемой версии ОС. |
Особенно аккуратно следует обращаться с метриками MTTD и MTTR. Под MTTD обычно понимают среднее время обнаружения, однако разные команды могут по-разному определять начальную и конечную точку измерения. MTTR ещё неоднозначнее, поскольку сокращение может обозначать время реагирования, восстановления или устранения проблемы.
Прежде чем сравнивать показатели, нужно зафиксировать, какое событие запускает отсчёт и в какой момент измерение заканчивается. Иначе поставщик и заказчик будут обсуждать разные процессы под одним названием.
Как посчитать экономическую выгоду без фантазий
Допустим, SOC ежедневно разбирает 80 однотипных уведомлений. В среднем первичная обработка занимает семь минут. После внедрения и настройки нового инструмента тот же класс событий специалисты обрабатывают за четыре минуты.
Все числа условные, пример показывает только метод расчёта.
До внедрения
80 × 7 = 560 минут в день
После внедрения
80 × 4 = 320 минут в день
Разница
560 − 320 = 240 минут
или 4 часа в день
За 20 рабочих дней
4 × 20 = 80 часов
Получается потенциальное высвобождение 80 рабочих часов за месяц. Однако результат ещё не означает экономию зарплат или окупаемость продукта.
Компания может направить освободившееся время на расследование сложных атак, развитие правил обнаружения и другие задачи. Кроме того, новый продукт потребует собственных ресурсов на обслуживание, а реальный эффект может отличаться для разных категорий инцидентов.
Чтобы говорить о подтверждённой выгоде, необходимо сравнивать одинаковые сценарии, учитывать качество расследования и фиксировать методику испытаний. Практический подход к выбору и оценке таких показателей даёт NIST SP 800-55.
Полная экономическая модель должна включать расходы за несколько лет. Обычно учитывают лицензии, оборудование или облачные ресурсы, услуги интегратора, настройку, обучение, поддержку, обновления, хранение данных и трудозатраты внутренних специалистов.
Иногда новая система не снижает прямые расходы вообще. Компания платит больше, зато получает возможность обнаруживать ранее незаметные атаки или быстрее реагировать на критические события. В таком случае аргумент следует строить вокруг управления риском, а не искусственно рассчитывать денежную окупаемость.
Кейсы и сравнительные таблицы без маркетинговых фокусов
Формулировка «Крупный заказчик повысил уровень безопасности на 70%» выглядит впечатляюще, но технически почти бессодержательна. Непонятно, как определяли уровень безопасности и что конкретно измеряли.
Сильный кейс содержит исходные условия, поставленную задачу, архитектуру, ограничения, критерии измерения и достигнутый результат.
Например, полезно показать обезличенный проект, в котором известны количество контролируемых узлов, состав источников событий, категории атак, перечень интеграций и изменение конкретных показателей работы SOC. Если информация конфиденциальна, детали согласовывают с заказчиком или исключают.
Сравнивать собственный продукт с конкурентами тоже необходимо аккуратно. Таблица с зелёными галочками напротив своего решения и красными крестиками у остальных чаще говорит о методике маркетингового отдела, чем о действительных преимуществах.
Лучше использовать матрицу требований конкретного заказчика. Например, проверить поддержку нужных операционных систем, работу в изолированной инфраструктуре, возможности отказоустойчивости, совместимость с действующими средствами защиты и стоимость владения.
Неизвестные возможности конкурентов должны оставаться неизвестными, а не превращаться в отрицательные оценки.
Отдельно стоит различать четыре уровня доказательств. Заявленная производителем характеристика, результат лабораторного испытания, результат у другого клиента и результат в инфраструктуре текущего заказчика. Переносить показатели между уровнями без проверки нельзя.
4. Демонстрация, пилот и ошибки, которые губят даже хорошую презентацию
Пресейл-презентация не обязана закончиться подписанием договора. Для сложной ИБ-системы более реалистичная цель первой встречи заключается в согласовании технических требований и условий последующей проверки.
Задача демонстрации состоит в том, чтобы показать рабочий процесс. Задача пилота состоит в том, чтобы установить, воспроизводится ли заявленный результат в согласованных условиях.
Как провести демонстрацию, которой поверит инженер
Плохая демонстрация начинается с экскурсии по меню. Пресейл-инженер показывает консоль управления, переключает вкладки, перечисляет настройки и подробно рассказывает о функциях, которые заказчик не просил.
Сильная демонстрация начинается с задачи.
Для DLP можно показать тестовый документ с чувствительной информацией, попытку его передачи через контролируемый канал, реакцию политики и последующий разбор события. Затем следует выполнить разрешённую операцию с похожим документом, чтобы проверить отсутствие нежелательной блокировки.
Для EDR аналогичным образом демонстрируют подозрительную активность в тестовой системе, появление события, контекст расследования и допустимые меры реагирования.
Для NGFW полезно показать применение сетевых политик, разрешённый трафик, блокировку нежелательного соединения и изменение производительности при включении механизмов защиты.
Именно негативные тесты, в которых система должна не мешать нормальной работе, часто раскрывают пригодность продукта лучше эффектной блокировки вредоносной программы.
Демонстрации атак, блокировок и изоляции узлов следует проводить только в согласованной тестовой среде. Используйте специально подготовленные данные, избегайте реальных секретов и заранее определяйте допустимые действия. Для тестов в рабочей инфраструктуре нужны разрешение владельца систем, согласованный объём испытаний и план восстановления.
При подготовке стоит предусмотреть запасной вариант показа. Если стенд недоступен, можно использовать запись заранее проведённого испытания, но необходимо прямо обозначить запись как подготовленную демонстрацию. Выдавать видео за живую работу продукта не следует.
Как превратить последний слайд в проверяемый пилот
Финальный слайд «Спасибо за внимание» обычно не помогает перейти к следующему этапу. Гораздо полезнее предложить пилот с согласованными условиями и критериями приёмки.
При этом критерии следует определить до начала испытаний. Если поставщик выбирает успешные сценарии уже после демонстрации, заказчик получает красивый отчёт, но не объективную оценку продукта.
В пилотном плане должны быть описаны область испытаний, тестовая инфраструктура, версии программного обеспечения, сценарии, метрики, ответственность сторон и условия завершения проекта.
| Продукт | Пример проверяемой задачи | Как установить критерий успеха |
|---|---|---|
| SIEM | Обнаружить выбранные цепочки подозрительной активности в журналах нескольких систем. | Заранее согласовать сценарии, необходимую телеметрию, допустимую задержку, качество контекста и уровень ложных тревог. |
| DLP | Выявлять запрещённые передачи тестовых документов и пропускать разрешённые операции. | Сформировать набор запрещённых и разрешённых примеров, указать контролируемые каналы и допустимое число ошибок. |
| NGFW | Обеспечить необходимые сетевые ограничения при заданной нагрузке. | Зафиксировать профиль трафика, включённые механизмы защиты, требования к задержкам, доступности и переключению кластера. |
| EDR | Обнаруживать выбранную подозрительную активность и поддерживать расследование. | Определить тестовые техники, поддерживаемые платформы, полноту данных, допустимую нагрузку и порядок безопасного реагирования. |
Числовые пороги нужно выбирать по требованиям конкретной компании, а не копировать из универсального шаблона. Для одной системы задержка обнаружения в несколько минут приемлема, для другой может быть недопустимой.
Полезно включать в испытания не только известные поставщику сценарии, но и заранее согласованные проверки, точные параметры которых команда демонстрации не получает до теста. Такой подход снижает вероятность, что положительный результат объясняется исключительно предварительной настройкой системы под конкретные образцы.
Отдельно необходимо зафиксировать, кто настраивает продукт. Сценарий, который за несколько дней подготовила команда разработчиков производителя, нельзя автоматически считать доступным обычному администратору сразу после установки.
Пилот также должен предусматривать удаление тестовых данных, отключение агентов и восстановление конфигурации после завершения работ. Для критической инфраструктуры и производственных систем такой план особенно существенен.
Ошибки, которые чаще всего мешают продать ИБ-решение
| Ошибка | Почему опасна | Что сделать |
|---|---|---|
| Начинать с истории производителя | Заказчик не понимает, какое отношение корпоративные достижения имеют к его задачам. | Перенести информацию о компании в приложение, если отсутствуют обязательные требования к её квалификации. |
| Показывать все функции сразу | Поток характеристик скрывает наиболее полезные возможности. | Выбрать несколько сценариев и связать функции с результатом. |
| Обещать полную защиту | У любой технологии остаются ограничения, зависимости и способы обхода. | Описывать конкретное покрытие и остаточные риски. |
| Ссылаться на проценты без методики | Невозможно проверить корректность расчёта. | Показывать исходные условия, выборку и способ измерения. |
| Считать лабораторную производительность реальной | Настройки безопасности и профиль нагрузки могут менять результат. | Проверять систему в конфигурации, близкой к рабочей. |
| Скрывать эксплуатационные ограничения | После покупки могут появиться дополнительные расходы и потребность в специалистах. | Заранее обсудить обновления, поддержку, хранение, отказоустойчивость и сопровождение. |
| Выдавать планы разработки за готовые функции | Заказчик может купить решение в расчёте на недоступную возможность. | Различать работающие функции, тестовые версии и планы развития. |
| Обещать интеграцию по одному логотипу | Совместимость зависит от версий, протоколов и доступных данных. | Подтверждать нужный способ интеграции в целевой конфигурации. |
| Проводить только выигрышные тесты | Не видны ложные тревоги, проблемы совместимости и влияние на бизнес-процессы. | Включать отрицательные проверки и нормальную рабочую активность. |
| Заканчивать встречу без плана | У сторон остаются разные ожидания. | Согласовать следующий технический шаг, ответственных и критерии результата. |
Есть ещё одна ошибка, которая особенно характерна для интеграторов. Пресейл-инженер обещает возможность продукта, но не объясняет, входит ли настройка соответствующей функции в стоимость внедрения.
Например, поддержка интеграции с определённым источником событий не означает, что адаптация формата, разработка правил обнаружения и последующее сопровождение выполняются бесплатно. Состав проектных работ должен быть понятен до согласования бюджета.
Производителю, в свою очередь, следует различать собственные обязательства и ответственность партнёра. Наличие технической функции в продукте не гарантирует её корректную настройку конкретным интегратором.
Когда новая ИБ-система действительно не нужна
Пресейл-презентация не должна любой ценой подводить заказчика к покупке. Существуют ситуации, когда от внедрения лучше отказаться или отложить проект.
Если в компании нет специалистов и процессов реагирования, покупка сложной SIEM сама по себе не обеспечит круглосуточное обнаружение инцидентов. Возможно, потребуется управляемый сервис мониторинга или предварительное развитие внутренней команды.
Если DLP внедряют без понимания, какие данные считаются конфиденциальными и кто вправе их обрабатывать, продукт способен создать поток спорных инцидентов и конфликтов с рабочими процессами.
Если NGFW выбирают без обследования сетевой архитектуры, неверное включение в критический канал может нарушить доступность бизнес-сервисов. Для EDR аналогичный риск возникает при автоматической изоляции важных серверов и несовместимости агента с прикладным программным обеспечением.
Поэтому зрелый пресейл иногда заканчивается рекомендацией изменить проект, сократить его масштаб или сначала устранить организационные проблемы. Для долгосрочной работы с заказчиком такой подход полезнее продажи неподходящего продукта.
Частые вопросы о пресейл-презентациях в ИБ
Сколько времени должна занимать пресейл-презентация?
Для первой предметной встречи можно ориентироваться на 15–25 минут основного выступления, оставляя остальное время для вопросов и обсуждения. Глубокая техническая защита архитектуры может потребовать отдельной встречи. Продолжительность определяют задачи аудитории, а не число страниц.
Нужно ли показывать стоимость ИБ-продукта на первой встрече?
Если известны параметры проекта, полезно показать предварительный бюджет или диапазон. При недостатке данных следует объяснить, какие показатели влияют на цену и что нужно измерить для расчёта. Предварительную оценку необходимо отличать от окончательного коммерческого предложения.
Что делать, если заказчик не раскрывает подробности инфраструктуры?
Используйте типовые отраслевые сценарии и прямо обозначайте предположения. Покажите возможные варианты архитектуры без утверждений об их полной совместимости. После встречи согласуйте перечень данных, необходимых для технической оценки. При работе с конфиденциальной информацией можно использовать обезличенные схемы и согласованные процедуры обмена документами.
Как убедить заказчика заменить уже работающий продукт конкурента?
Сначала установите причины возможной замены. Новый продукт должен решать конкретную проблему лучше действующего решения с учётом расходов на миграцию, перенастройку, обучение и эксплуатацию. Если текущая система соответствует требованиям, убедительного основания для покупки может не быть.
Можно ли обещать снижение киберрисков на определённый процент?
Такое утверждение требует модели риска, обоснованных исходных данных и понятного метода оценки. Процент обнаруженных тестовых атак нельзя автоматически считать процентом снижения риска. Лучше показывать измеримые изменения конкретных процессов и отдельно обсуждать, как они могут влиять на последствия инцидентов.
Чем отличается презентация производителя от презентации интегратора?
Производитель главным образом доказывает возможности продукта, архитектурные особенности и качество технологии. Интегратор дополнительно должен обосновать проект внедрения, совместимость решений, сроки миграции, распределение ответственности, обучение и сопровождение. Поэтому у интегратора больше внимания занимает реализация проекта в инфраструктуре заказчика.
Как проводить пресейл, если у продукта ещё нет известных клиентов?
Не заменяйте отсутствующие кейсы неподтверждёнными обещаниями. Покажите доступные испытания, ограничения и предложите воспроизводимый пилот. Для нового продукта особую роль играют прозрачная методика проверки, возможность независимо оценить результаты и готовность поставщика исправлять выявленные проблемы.
Как проверить качество собственной презентации перед встречей?
Попросите коллегу, не участвовавшего в подготовке, ответить после просмотра на пять вопросов. Какую проблему решает продукт, какой механизм обеспечивает результат, что требуется от заказчика, сколько ресурсов нужно и как проверить обещания. Если ответы неочевидны, презентация перегружена характеристиками либо не раскрывает ключевые условия проекта.
Вывод. Хорошая пресейл-презентация не обязана впечатлять количеством слайдов, красотой интерфейса или длинным списком функций. Продукт информационной безопасности покупают ради конкретных изменений. Заказчик хочет лучше видеть угрозы, быстрее реагировать, контролировать важные данные или защищать критические сервисы без неприемлемых расходов и простоев.
Начните с изучения реальных проблем и ограничений компании. Затем соберите 14 слайдов, которые последовательно объясняют исходную ситуацию, целевой процесс, технический механизм, архитектуру, экономику и доказательства. Выберите несколько характерных сценариев и подготовьте воспроизводимую демонстрацию.
Не обещайте абсолютную защиту, гарантированную окупаемость или производительность вне условий испытаний. Лучше сразу обозначить границы применимости продукта, показать стоимость эксплуатации и согласовать критерии пилота.
Если после презентации заказчик понимает, какую проблему решает система, почему выбранная архитектура подходит его инфраструктуре, сколько ресурсов потребуется и как самостоятельно проверить результат, пресейл выполнил свою задачу. Следующий этап уже не спор о рекламных характеристиках, а предметная техническая и коммерческая оценка.
