Привет, Хабр! Я Алена Караваева, в Positive Technologies возглавляю направление защиты конечных устройств от целевых атак. Мое главное детище — это MaxPatrol EDR, который входит в состав MaxPatrol Endpoint Security, комплексного решения для защиты конечных точек, рабочих станций и серверов.

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

В результате я давно перестала смотреть на роадмап только как на список фич: для меня это, скорее, карта того, как мы усиливаем киберустойчивость клиента и какой риск берем на себя, когда принимаем каждое продуктовое решение. Мой главный вызов в работе — внутренний: гарантировать с помощью MaxPatrol Endpoint Security такой уровень киберустойчивости любой компании, чтобы, как говорится, можно было спать спокойно.

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

Коротко о комплексном решении и нашей команде

MaxPatrol Endpoint Security — средство защиты конечных устройств. В нем одновременно «живут» механизмы для обнаружения угроз и мониторинга, контроля устройств и приложений, сбора данных, антивирусные компоненты, политики защиты и множество других функций. Добавьте сюда экспертизу, накопленную более чем за 20 лет, всевозможные способы выявления массовых, сложных и целевых атак, а также известных киберугроз. Украсьте все гибкой архитектурой, чтобы клиенты могли легко отключать ненужные им модули, выбирать сценарии защиты под свои задачи, применять по своему усмотрению уникальные экспертные данные антивирусной лаборатории нашего экспертного центра безопасности (PT ESC). Представили, какой чудный уровень сложности получается? А теперь берем скотч, ножницы — и упаковываем все это в понятный пользовательский опыт с шаблонами и предустановками, чтобы минимизировать рутину по администрированию и настройке.

Повторите 10 раз, ведь недавно вышла 10-я версия MaxPatrol Endpoint Security, где мы добавили развертывание за 1 день, установку агентов сразу из интерфейса, контроль активности устройств и приложений, восстановление файлов с помощью модуля «Антишифровальщик». Сложно? Нет, это будни нашей команды более чем из 70 человек. Около 50 из них — R&D-специалисты, для которых я ежедневно и с большой любовью балансирую на раскаленных углях.

В поисках золотой середины, или Баланс, которого нет

Очень неприятно падать лицом на угли. Нельзя каждый день обновлять MaxPatrol Endpoint Security у клиента и исправлять возникшие проблемы. А они будут, ведь в сложной корпоративной среде невозможно заранее предусмотреть абсолютно все варианты поведения.

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

Когда я была юным розовощеким продактом, мы с командой договорились, что идеальный баланс выглядит так: 30% ресурсов тратится на реализацию бизнес-фич, еще 30% — на частичное погашение технического долга и на поддержку внутренних процессов (чтобы средство защиты информации развивалось равномерно и каждая новая доработка не нарушала имеющуюся архитектуру, а скорее наоборот — способствовала более легкому внедрению будущих функций). Оставшиеся 40% отводятся на исследовательскую работу, экспериментальные улучшения, процессы и стратегические инициативы.

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

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

• Большая фича, которую команда будет делать несколько месяцев.

• Небольшое изменение в защитном механизме.

• Технический долг.

• Исследование технологии, которая сегодня вообще не имеет очевидного бизнес-кейса, но через год может оказаться критически важной.

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

Если свести все это к одной формуле, можно получить красивый score — и совершенно не тот роадмап, который нужен продукту.

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

Еще одна из причин нарушения идеальной пропорции — задачи безопасности, которые нельзя закрыть частично: они идут одним блоком во временной точке роадмапа, которые требуется выполнить в полном объеме в одной временной точке в роадмапе. Например, в области мониторинга нам нужно было разово сделать качественный скачок, чтобы обновление средства защиты не выглядело для клиентов как россыпь мелких малозаметных улучшений. Во главу угла мы всегда ставим понятную ценность, которую получит компания, если примет решение об установке новой версии продукта. Обновление в нашей парадигме — не просто смена номера версии, а предоставление более качественного результата для обеспечения реальной кибербезопасности. Именно такие приоритеты порой вынуждают нас перекраивать бэклог, из-за чего равномерность долей становится скорее исключением, чем правилом.

Как мы ранжируем 500+ фич и всегда держим слово перед клиентами

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

Мы перепробовали множество классических для индустрии фреймворков приоритизации (RICE, MoSCoW, Kano), но ни один не прижился. У меня нет хорошего совета, как ранжировать и держать актуальным список из полтысячи айтемов в бэклоге (простите!). Мы просто используем смесь опыта, стратегии, кусочков разных фреймворков, мнения клиентов и чутья. Это почти как материнский инстинкт: ты просто знаешь, почему твой клиент или разработчик плачет и что ему нужно будет через пять минут, потому что ты его любишь и хочешь, чтобы он вырос в большого инженера или его бизнес остался жив.

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

Отталкивайтесь от специфики своей команды и просто делайте так, чтобы на рынок не уходили пустые обещания. Дальше расскажу как.

У нас в едином бэклоге больше 500 задач. При этом команды разработки достаточно специализированы. Одна из них разрабатывает функциональность ядра MaxPatrol Endpoint Security — то есть фичи-мастодонты, требующие времени, тщательной декомпозиции и соблюдения строгого линейного процесса. Другая группа отвечает за защитные модули, за сбор данных, антивирусные компоненты и другие динамические задачи, жизненный цикл которых итеративнее и быстрее. Поэтому вариант решения проблемы из разряда «эта фича очень срочная, давайте просто отдадим ее другой команде» не работает. У каждой команды есть своя область экспертизы и технический контекст.

Чтобы унифицировать поставку фич с максимальной пользой — от выявления потребности клиента до передачи в разработку, совместно с лидами мы сформировали процесс, который позволяет нам делать публичные коммиты по функциям продукта. Да, в релиз выходит больше фич, чем мы обещаем рынку, но то, что мы обещаем — мы выполняем в указанный срок в обещанном объеме в 100% случаев уже более двух лет. Это история про доверие к нашим обещаниям и про большую подготовку, которая состоит из следующих этапов:

1. Анализ бэклога

   • Все задачи находятся в единой очереди и распределяются по стратегическим направлениям.

   • Нужно следить, чтобы все стратегические треки равномерно росли в течение года. Например, трек «Мониторинг» включает в себя около 40 задач-фич. Я не могу заниматься только им весь год, ведь у меня есть еще 7 других треков, но я могу брать несколько конкретных ценностей из него и доставлять их в релизах.

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

   • Бэклог общий для трех продактов, каждый из которых отвечает за свои модули MaxPatrol Endpoint Security (моя зона ответственности — MaxPatrol EDR). Наша совместная цель — удерживать баланс между векторами с учетом жесткой специализации команд разработки, о которой я рассказывала выше. Поэтому мы обязаны продуманно и выверенно распределять между ними нагрузку, чтобы выпускаемый релиз представлял собой не разрозненный набор фич, а целостную функциональность с реальной ценностью для конечного пользователя.

2. Требования к фиче

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

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

   • Обычно над фичей есть эпик, который описывает, куда идет весь трек в целом. Это позволяет учесть в архитектуре, что стоит «положить» туда сразу.

3. Оценка

   • Первая появляется в процессе фрейминга фичи:

     • Лиды разработки формируют несколько вариантов решения по поставленной фиче, и мы совместно выбираем наиболее оптимальный.

     • На базе выбранного варианта ставится оценка «в майках», и фича передается на системный анализ.

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

   • Вторая рассчитывается после системного анализа. Ее выставляет команда разработки — как совокупную оценку всех задействованных ролей. По ней можно построить диаграмму Ганта и понять, какие обещания мы даем рынку. На базе этой оценки формируется публичный роадмап продукта, которым мы делимся с партнерами и клиентами.

«Боже, вот вы замороченные! Можно же проще, вот у меня бряк-шмяк — и в продакшен» — можете подумать вы. И это тоже правда: такой подход может работать у вас. Вы можете миленько беседовать с Claude и каждый день делать релизы с минимальным ревью от команды; вы можете разрабатывать внутренний продукт, где нет и половины из тех артефактов, которые я перечислила. Но рано или поздно вы придете в точку, где:

? у вас не будет времени решать, а команда будет ждать фичу, и вам будет нужен сквозной приоритизированный бэклог;

? вы получите фичу, которую по заголовку извратили так, что теперь все надо переделать, и лучше бы вы поставили задачу сами;

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

Когда я получала профильное образование, я думала, что буду строить самые крутые системы и бизнес-процессы. Когда я заканчивала магистратуру, я думала, что буду все измерять и у меня будет во всем порядок и данные для принятия управленческих решений. Спустя более чем 10 лет системного анализа и пару лет управления продуктом, повидав все варианты подходов к продукту и процессы ради процессов, я могу сказать только одно: не так важно, что работает у вас; важно, как это качественно превращается в результат для пользователя вашего продукта. Наш процесс позволяет выстроить доверительные отношения с клиентом и не брать лишнее, чтобы не пришлось жертвовать качеством.

Еще одна вещь, которую я со временем переосмыслила: релиз не должен быть просто сменой номера версии. Для защитного продукта особенно странно выпускать новую версию с формулировкой «мы добавили еще несколько функций». Мне важнее ответить на другой вопрос: что принципиально изменится в уровне защиты клиента? Я считаю, что релиз должен продавать не новые возможности, а новый результат.

Бабулины политики, или От байки к фиче

Наверное, у каждого продакта есть с пяток историй «больше никогда» и с десяток самых любимых фич, с которыми у вас что-то личное.

Никогда не стоит реализовывать UI/UX-запрос клиента буквально. Однажды ребята из нашего SOC (по сути, внутренние пользователи MaxPatrol Endpoint Security) попросили поменять информацию об устройстве на ту, которую считали более правильной, чтобы узнать, что это за компьютер. Мы уточнили их потребности. Аргументы звучали убедительно, и запрос был выполнен в точности. Затем те же ребята пришли с вопросом «Зачем вы это сделали?» и попросили вернуть как было.

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

Выученный урок

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

Я никогда не превращаю пожелание напрямую в функциональность. Вместо этого я интерпретирую даже примитивное добавление галочки для какой-то настройки в сценарий, на основе которого могу как сформировать запрос на улучшение, так и предложить решение задачи уже имеющимися в продукте инструментами. Такой подход к обработке клиентских запросов более целесообразен, элегантен и позволяет создать фичу, которая будет полезна не одиночному клиенту, а еще, например, трем другим, обратившимся к нам с похожими пожеланиями.

Особенно хорошо подход сработал на политиках безопасности. У нас долго существовала проблема, довольно типичная для сложных продуктов в сфере ИБ. Одни клиенты говорили: «У вас слишком много настроек, мы в них путаемся». Другие: «Нам не хватает настроек для тонкой конфигурации». И все были правы.

При этом компании регулярно обращались к нам с просьбами добавить функции, которые уже существовали в продукте. В какой-то момент значительная часть моей работы превратилась в объяснение: «Эта возможность уже есть. Вот здесь находится нужная кнопка, она открывает такую-то форму…». Для меня это был очевидный сигнал: проблема уже не в отсутствии функциональности. Проблема в самом способе управления продуктом.

Так появилась концепция с политиками безопасности, которые будут понятны даже моей бабушке, — то есть с бабулиными политиками. Это ироничное название родилось из байки: моя бабушка 4 года говорила, что я бухгалтер, потому что у меня в вузе преподавали бухгалтерский учет (прикладная информатика для нее была чем-то непонятным). Название пустило корни, и теперь мы его используем во внутренних переписках и на созвонах.

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

Вот как маленький UX-запрос превратился в гораздо более крупную продуктовую фичу. Мы не уменьшили количество возможностей — мы уменьшили количество решений, которые пользователь должен принимать самостоятельно. Для сложного продукта это иногда намного ценнее.

О факапах и почему сложно быть новаторами

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

В нашей компании мы единственные разрабатываем средство защиты, которое устанавливается на конечные устройства. Остальные команды сфокусированы на системах ИБ других классов. Поэтому, принимая решения, мы, как правило, остаемся наедине с собой и эпизодически — с рынком. Другие игроки крайне неохотно делятся в публичном поле своими роадмапами, промежуточными результатами, ошибками и инсайтами.

Не имея открытой информации для сравнения подходов, инструментов и итогов работы, мы не можем даже просто свериться с кем-то, а правильным ли путем идем. Большую часть решений наша R&D-команда акцептует опираясь на фрагментарные данные с рынка и собственную экспертизу. В таких условиях страшно в моменте, но риск неизбежен. Когда мы приступаем к новой фиче, у нас есть уверенность в ее необходимости и несколько способов реализации. MaxPatrol Endpoint Security — часть защиты крупных организаций, и даже незначительный недочет в фиче дорого обойдется клиентам. Представим гипотетическую ситуацию: решение классифицировало легитимный трафик как хакерскую атаку и заблокировало его, остановив основную деятельность компании. Тогда нам потребуется в экстренном режиме отключить эту функцию, чтобы быстро восстановить процесс, иначе в компании встанет всё — от принтеров до интернета.

Подчеркну, что в MaxPatrol Endpoint Security можно остановить работу любого компонента и отменить последние изменения. Это базовое условие эксплуатации сложных решений в сфере ИБ — его необходимо соблюдать, чтобы поддерживать стабильность корпоративных процессов. В первую очередь защитный продукт должен быть гибким, так как нештатных ситуаций избежать невозможно.

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

Один из таких провалов произошел с компонентом eBPF — механизмом, который использовался для сбора событий. Задача казалась вполне понятной. Подобные сборщики существовали у других игроков рынка. Мы сделали собственную реализацию, протестировали ее внутри компании, проверили нагрузку и работу политик. Все выглядело нормально. А потом пришел реальный клиент. На одном из устройств компонент начал получать аномально большое количество событий: число было значительно выше того, что мы ожидали увидеть. В результате потребление ресурсов, в том числе памяти и сети, выросло — и рабочая машина оказалась фактически парализована.

Вот здесь особенно хорошо видно отличие лабораторного тестирования от реального использования продукта. Мы проверили сценарий, но не весь спектр реальности. У конкретной машины была своя специфика, из-за которой количество событий оказалось существенно больше ожидаемого. В такой ситуации можно долго обсуждать, какой именно тест должен был это поймать, но клиенту от этого не легче. В результате первым делом мы отключили сбор данных с помощью eBPF на проблемном рабочем месте и минимизировали последствия, а дальше уже разбирались с первопричиной.

Для меня этот случай важен, так как он показывает, почему в сфере ИБ недостаточно думать только о happy path. Когда твоя система сама принимает решения на конечном устройстве, механизм безопасного выключения — обязательная часть фичи.

Заключение

За несколько лет работы я пришла к довольно простой формуле.

Продакт обычного B2B-решения в первую очередь спрашивает:

? «Это принесет клиенту ценность?»

Продакт решения для информационной безопасности должен задавать как минимум три вопроса:

? «Это принесет клиенту ценность?»

? «Это действительно повысит его защищенность?»

? «А что произойдет, если мы ошиблись?»

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

Я не воспринимаю бэклог как список задач, которые нужно когда-нибудь закрыть. Это, скорее, набор гипотез о том, как сделать защиту клиента лучше. Часть этих гипотез подтверждается, часть приходится переделывать. Некоторые мы выбрасываем. Некоторые становятся большими продуктами. А иногда приходится признать: мы ошиблись.

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

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