Открытие дверей

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

В п.3 упоминалось одно из свойств сервиса - открывание дверей (a.k.a. "door opener"). Это, действительно, нормальная практика проверки эффективности используемых решений с помощью инструментов и методов другого производителя, и результативность любого из assessment-ов будет здесь объективной демонстрацией. Чтобы такой подход работал, необходимо, чтобы сервис был либо нейтральным к поставщику (vendor agnostic), либо имел возможность работать на решениях других поставщиков. Подобная нейтральность - не проблема для анализа защищенности, а для Compromise Assessment (СА) имеет значительные инфраструктурные сложности, так как, чтобы обрабатывать телеметрию и алерты, уже используемые решения необходимо интегрировать в платформу сбора и анализа - это значимая проблема, объясняющая почему, как правило, СА проводится с помощью собственных инструментов поставщика. Кроме того, как было отмечено чуть выше, проверять эффективность используемых у заказчика инструментов логично с помощью иных инструментов, в данном случае - решений поставщика. А, держа в голове задачу открывания дверей, ибо маржинальность любого продукта несравненно выше маржинальности любого сервиса и поэтому непоследней целью является продажа продуктов и решений, СА имеет смысл оказывать именно провайдерскими инструментами, что позволит продемонстрировать их эффективность по сравнению с используемыми у заказчика, что может быть весомым аргументом для обоснования необходимости смены используемых решений. Успешный СА на используемых у заказчика инструментах, напротив, продемонстрирует их эффективность и результативность, а, следовательно, менять их необходимости нет, надо просто научиться ими пользоваться. Итак, с позиции поставщика СА оказывать сервис на решениях, уже развернутых у заказчика, и крайне сложно технологически (в условиях, когда решения могут быть абсолютно любыми - невозможно, поскольку требуются непросто прогнозируемые затраты на исследования и разработку), и не имеет смысла в точки зрения стратегии расширения клиентской базы.

Но допустим, наша стратегия выглядит несколько иначе, и у нас стоит задача оказывать сервис на уже развернутых у заказчика решениях. Например, это может быть актуально для некой разновидности SOC-as-a-Service, когда поставщик к своей инфраструктуре подключает используемые у заказчика системы мониторинга. Такая стратегия имеет большие перспективы, поскольку позволяет быть действительно vendor agnostic и сделать предложение для любого заказчика и сразу начать с ним работу, а случае ее продолжительной плодотворности начать прорабатывать вопрос миграции на свои решения. Обоснование необходимости такой миграции не будет нерешаемой задачей, поскольку можно привести бесконечное множество аргументов почему поставщик на своих решениях будет более эффективен и результативен, принцип Алана Кея я уже обсуждал, ибо профессионалам требуются профессиональные инструменты.

Задача организации эффективной работы с любыми продуктами любых вендоров не имеет супер-простого и быстрого решения, причем, чем шире номенклатура поддерживаемых сторонних инструментов (как по типу, так и по вендору), тем сложнее эта задача. А поскольку от успешности работы такого сервиса зависит перспективность дальнейшего диалога с заказчиком, цена неудачи здесь очень высока. При такой стратегии провайдер должен инвестировать в платформу и технологические инструменты оказания сервиса, проще говоря, в развитие сервиса, что в условиях обсуждаемого подхода к выделению ресурсов разработки по принципу мгновенной максимальной прибыли не может быть обеспечено.

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

1. Оказывать сервис надо на собственных инструментах. В этом случае поставщик максимально использует результаты своих исследований, не стоят вопросы нехватки компетенций исполнителя и сложностей интеграции, взаимной корреляции и совместного анализа. Результаты такого сервиса - объективная демонстрация преимуществ используемых провайдером инструментов перед применяемыми в исследуемой инфраструктуре.

2. Раскатывать сторонние инструменты может быть инфраструктурно сложно, а в ряде проектов может быть стоп-фактором, поэтому необходимо иметь возможность оказывать сервис надо на уже развернутых у заказчика инструментах. Такой провайдер, за счет поддержки 3rd party решений, имеет возможность просто заходить к новым для себя заказчикам. Но в этом случае предъявляются повышенные требования к платформе оказания сервиса, а ее разработка и развитие требует больших инвестиций.