Три признака того, что ваш поставщик кибербезопасности может обмануть систему
Для тех из вас, кто посетил RSA Conference Я уверен, что в апреле продолжается бомбардировка электронными письмами поставщиков, телефонными звонками и приглашениями на встречи в LinkedIn. Хотя я готов поспорить, что многие поставщики, просящие о встречах, предлагают продукты или услуги, которые не находятся в вашем поле зрения в 2023-2024 годах, вероятно, есть несколько, которых вы хотели бы протестировать, чтобы увидеть, смогут ли они обеспечить лучшие результаты, чем что вы сейчас используете. Для этих поставщиков после обязательной вводной встречи, некоторого технического обсуждения или даже телефонного разговора с клиентом вам будет предложено подтверждение концепции (иногда его также называют доказательством ценности). Эта проверенная временем традиция позволяет «Протестируйте продукт сами».
Во время PoC поставщик пытается показать вам, как его продукт предотвращает больше атак, обнаруживает больше фишинговых писем, обнаруживает больше вредоносных веб-сайтов и т. д., чтобы подтвердить свои маркетинговые заявления. Намерение предложить PoC имеет смысл и должно помочь покупателям избежать покупки продуктов с возможностью перепроданности. Но, к сожалению, слишком часто продукты, которые, казалось бы, хорошо себя зарекомендовали во время PoC, не дают аналогичных результатов после полного развертывания в среде покупателя.
Как это может быть? За мои почти 20 лет строительства, продаж и маркетинга информационной безопасности продуктов, я видел практически все способы, которыми поставщики пытались обмануть эти PoC. Вот три признака того, что ваш PoC может быть неудовлетворительным.
«Мы предоставляем все данные в нашей среде, поэтому вам не о чем беспокоиться».
Дело в том, что тщательное тестирование информационной безопасности продукты, которые полагаются на какую-то внешнюю угрозу или огромный объем внутренних данных для обучения моделей машинного обучения, могут быть громоздкими. Поскольку ни один специалист по безопасности не будет и не должен соглашаться тестировать неизвестный продукт в своей производственной среде, ему потребуется достаточно надежная среда тестирования, чтобы протестировать этот новый продукт. Учитывая это требование, будет заманчиво принять предложение поставщика провести тест с использованием его данных в среде поставщика. Если вы задумаетесь об этом на минутку, это все равно, что попросить студентов написать вопросы для выпускного экзамена. Не думаете ли вы, что тестирование в среде поставщика с использованием его данных может исказить результаты в его пользу? Конечно. Хотя никто не хочет, чтобы их PoC занимало больше времени, чем хоккейный сезон НХЛ, вам необходимо предоставить данные для правильной проверки продукта. Некоторые поставщики могут предложить использовать некоторые инструменты, имитирующие атаки, что вполне разумно, если у вас, как у потенциального клиента, есть выбор, использовать их или нет. Лучший способ сократить длину PoC — выбрать максимум два или три варианта использования, на которые вы ориентируетесь, и предоставить необходимые данные только для этих вариантов использования. В идеале продукты, которые вы тестируете, облегчат интеграцию продуктов, генерирующих данные, в вашу среду.
«Какую версию мы тестируем? Это во многом наш продукт GA. Вы не заметите разницу».
Когда я пришел в индустрию кибербезопасности и готовился к PoC, мы попросили потенциальных клиентов установить сервер, отвечающий нашим минимальным требованиям. Затем я вручную устанавливал продукт на машину, чтобы участники PoC могли видеть, какую версию продукта мы собираемся использовать для тестирования.
В современном мире, где SaaS является стандартом, знание версии тестируемого продукта может показаться путешествием в червоточину. К сожалению, я слышал ужасные истории от практиков, когда они были в PoC с поставщиком, и результаты были выдающимися, поэтому они заключили контракт на покупку продукта. Перенесемся на месяц или два вперед, и специалисты и руководство будут крайне разочарованы. Продукт, установленный в их среде, совсем не похож на то, что они тестировали. Функции отсутствуют, интеграций, которые они использовали, нигде не найти, а поставщик говорит: «Эта версия должна скоро выйти». В некоторых случаях я не вижу проблем с использованием невыпущенной версии продукта для PoC, если поставщик прозрачен для потенциального клиента. К сожалению, когда клиент чувствует, что поставщик пытается что-то от него скрыть, отношения между клиентом и поставщиком, которые должны быть совместными, могут мгновенно стать враждебными.
«Мы ни разу не пропустили угрозу во время PoC».
В 1941 году Тед Уильямс, также известный как Великолепный осколок, провел волшебный сезон на тарелке, завершив свой сезон в «Бостон Ред Сокс» с ошеломляющим средним показателем 406 и процентом попаданий на базу 553. Многие историки бейсбола утверждают, что Тед Уильямс был самым чистым нападающим, когда-либо игравшим в эту игру. На сегодняшний день ни один отбивающий в AL или NL не превзошел средний показатель за год в 400. Итак, какое отношение Тед Уильямс имеет к блогу о PoC в области кибербезопасности? Дело в том, что ничто, будь то продукт кибербезопасности или лучший игрок, когда-либо игравший в игру, не всегда идеально. Можете ли вы протестировать продукт на определенном наборе векторов угроз, и продукт выявит их все? Абсолютно. Может ли он делать это последовательно с новыми угрозами в течение двух дней, 5, 10 или даже 100 дней? Но насколько я знаю, что в сезоне 1941 года Тед Уильямс забил 27 раз, наступит день, когда ваш блестящий новый информационной безопасности продукт упускает угрозу, которую, как вы думали, он обнаружит.
Если во время PoC необработанные результаты тестирования продукта не будут доступны немедленно или вы заметите людей от поставщика, работающих над проектом, с которыми вы никогда не встречались, будьте осторожны. Вы являетесь свидетелем того, как отдел продаж обращается за помощью к разработчикам, исследователям угроз или инженерам-программистам, работающим над вашим развертыванием, и пытается выяснить, почему они пропускают угрозы или какая-то функция не работает. Опять же, могут ли дефекты программного обеспечения выявиться во время PoC? Абсолютно. Когда они это сделают, наверняка, вы сможете найти разработчиков и инженеров, отлаживающих код вживую. Ключевым моментом здесь является прозрачность. Этические поставщики будут откровенны с вами, если и когда обнаружится дефект. Они также объяснят, почему во время PoC была пропущена угроза (если таковая имеется). Помните, что при запуске PoC продукта вам следует сравнивать результаты с тем, что вы используете в настоящее время, и с другими продуктами, которые вы тестируете, а не с мифической системой, которая постоянно обнаруживает 100% угроз. Вы ищете значительно лучших результатов, а не совершенства.
PoC для людей
Поскольку на рынке представлено так много продуктов, претендующих на схожие возможности, преимущества и результаты, практически невозможно определить, что подойдет вам лучше всего, не запуская PoC. Поэтому я являюсь поклонником PoC, поскольку при честном использовании он дает конкурирующим продуктам шанс конкурировать в реальном мире.
Пусть победит лучший продукт.
