Продуктовое перепутье: пишем свое сами или закупаем чужое у вендора
Вы глава ИТ-отдела быстроразвивающейся компании. Стартап вчера и гордый представитель среднего бизнеса сегодня, ваша компания все еще максимально полагается на внутренние мощности в том, что касается написания программного обеспечения для корпоративных нужд. За плечами ваших разработчиков создание таск-менеджера, CRM-системы и даже внутреннего мессенджера.
Быстро растущий штат ставит вас перед необходимостью внедрить решения для кадрового учета и электронного документооборота. Неоднократно сталкиваясь со сложностями работы новых сотрудников с внутренним ПО и проблемами дальнейшего развития продукта в отсутствие его авторов, вы думаете о том, чтобы дать шанс решению под ключ.
Взгляд мельком
Чаще всего в пользу самописного продукта можно услышать такой аргумент – высокий уровень кастомизации под выполнение индивидуальных, нестандартных задач. Еще один плюс – мобильность, которую заказчик приобретает в ходе его создания: компания может избежать пролонгации процесса постановки технического задания и его дальнейшей оценки, связанной с привлечением контрагентов, и лишней бюрократии. Сотрудники компании принимают решение о том, какие задачи должен решать софт, подбирают подходящий продукт open source и оперативно реализуют нужную функциональность. С точки зрения операционных возможностей на этом достоинства самописного продукта заканчиваются.
Что дает вендор? Главное преимущество продуктов от крупных поставщиков –техническая поддержка на всем жизненном цикле приобретенного оборудования (разве что за редким исключением, когда вендор объявляет об отсутствии обратной совместимости и прекращении поддержки продукта). Разработчик поможет довести функциональность технологии до необходимого заказчику уровня и адаптировать ее под решение проблем, которые в динамике – с ростом компании и усложнением процессов – могут меняться. Популярные решения также обычно имеют подробную документацию, которая помогает обеспечить их максимально эффективное использование внутри инфраструктуры, настроить дополнительные функциональные модули или самостоятельно разобраться в тонкостях их интеграции. Косвенным плюсом использования больших корпоративных разработок становится широкая аудитория пользователей – ответ на нужный вопрос можно найти в огромном комьюнити клиентов, не обращаясь к вендору, что иногда ускоряет решение возникших вопросов.
Рыночная гибкость
От корпоративных решений чаще всего отказываются под предлогом их стандартизованности, высокой стоимости или ограниченной функциональности, которая может препятствовать внедрению новых процессов. Однако вендоры проявляют все большую готовность идти навстречу заказчикам в вопросе доработки продукта под их нужды. Многие не решаются обратиться к разработчику, думая, что их предложение по развитию продукта невостребовано среди других клиентов и поэтому будет встречено отказом.
Тем не менее, как показывает опыт Group-IB, спрос на доработку технологии не единственный критерий, на основании которого принимается решение о том, будет продукт изменен в соответствии с требованиями или нет.
Как вендор в сфере кибербезопасности, Group-IB получила два разных обращения с просьбой о доработке нашего решения для защиты от сложных киберугроз Threat Detection System. В первом случае спрос на изменение был гораздо выше, чем во втором, однако процесс, о котором просил заказчик, снижал производительность системы примерно в три раза и требовал длительной и неоправданно дорогой доработки продукта. Но мы решили взяться за дело и показать заказчику, что будет, если...
Смоделировав процесс реализации новой функциональности (она касалась возможности подгружать события из сторонней Intrusion Detection System (IDS) в TDS), аналитики Group-IB пришли к выводу, что при неочевидных положительных эффектах такая «новая фича» приведет к существенному повышению стоимости решения и в перспективе потребует разработки и поддержки API других IDS-систем.
Второе предложение «докрутить» TDS поступило от двух клиентов, однако разработка нового процесса не нуждалась в дополнительных мощностях и потенциально имела обширный рынок.
Речь шла о файловых хранилищах, в которых сотрудники обменивались документами – заказчики хотели анализировать загружаемые в них файлы на предмет вредоносов. Было решено, что потенциально новая функциональность привлечет больше клиентов и повысит конкурентоспособность TDS. Поэтому доработка была реализована даже при небольшом спросе, так как в перспективе обещала окупаемость инвестиций. В дополнение, поскольку нередко такие хранилища являются пограничными между закрытым сегментом сети и DMZ, мы расширили требуемую функциональность и «научили» TDS перекладывать файлы после успешного подтверждения безопасности в DMZ-хранилище. Теперь вся эта функциональность доступна «из коробки».
Таким образом, спрос далеко не всегда является основным драйвером модернизации продукта, есть еще такие важные критерии, как потенциальное расширение клиентской базы и повышение качества выполнения функций продукта. У большинства разработчиков корпоративных решений есть своеобразное окно допустимых изменений, главное условие которых – соблюдение баланса между затрачиваемыми ресурсами и приобретаемой выгодой. Вендоры всегда заинтересованы в том, чтобы их продуктом пользовались на постоянной основе, не меняя поставщика, поэтому к ним стоит обращаться с любой идеей – возможно, вендор предложит альтернативы. Если разработчик не готов взяться за реализацию идеи самостоятельно, он может предложить решения через так называемые бандлы с технологическими партнерами, которыми эта функциональность уже была реализована.
Софт с подвохом
Имея на одной чаше весов кажущееся преимущество самописных продуктов в виде высокой кастомизируемости, на другой чаше вы найдете многочисленные трудности, связанные с обслуживанием уникального решения. Такая технология имеет ограниченный цикл эффективного функционирования и в руках ограниченного числа пользователей – его разработчиков.
Поскольку в основе большинства самописных продуктов – open source (открытое программное обеспечение), его бесперебойный цикл работы, как правило, возможен в одной версии. Допустим, компании для работы отдела ИБ понадобилась «песочница» и сотрудники решили использовать популярный open source: они взяли определенную версию софта и над ним выстроили дополнительные функциональные возможности. Затем появилась новая версия исходного ПО – с более широкой функциональностью или, скажем, патчем уязвимости. У этой версии другие API и другие интеграционные возможности, и всё, что компания создавала для старой версии, не работает с новой, поскольку такие решения не имеют обратной совместимости.
Контроль версионности – еще один вызов, с которым сталкиваются пользователи кастомного софта. Обычно перед авторами внутренней разработки стоит задача решить определенную проблему в максимально сжатые сроки и перейти к следующему вопросу. Это обусловлено экономической целесообразностью – как правило, у компаний, сделавших выбор в пользу самописного продукта, ресурсов на то, чтобы детально описать всю свою разработку, попросту нет. Как результат, контроль версионности отсутствует либо ведется не систематически. При отсутствии документации и мануалов по использованию решения, а также технической поддержки, работа новых сотрудников с внутренним продуктом будет, мягко говоря, затруднительна. А в отдельном сценарии – ухода разработчиков – плюс все те же беды с мануалами, версионностью и потенциально большим количеством «костылей» в разработке – внутренним продуктом пользоваться будет попросту невозможно.
Справедливости ради отметим, что и с меньшей вероятностью, но и в вендоре может оказаться не все гладко. Примеров, когда продукт останавливался или «замораживался» из-за проблем в команде разработки, немало. Так, недавно не заладилось у Google в команде Pixel, отвечающей за создание смартфонов. Гигант припозднился с выпуском бюджетного Pixel 4a, не так давно стало известно, что в случае с Pixel 5 все же было решено отказаться от установки топовой платформы в пользу Snapdragon 765G. Инсайдеры на форумах в один голос говорят о том, что компания могла отменить выход Pixel 5 из-за проблем с командой: якобы виной всему уход ряда ключевых членов команды разработчиков Google Pixel.
А это точно безопасно?
С точки зрения кибербезопасности преимущества корпоративных и самописных продуктов вытекают из их функциональных особенностей. При использовании популярных разработок клиент получает поддержку от вендора в плане обновлений – если в продукте обнаружена уязвимость, то вендор заинтересован в ее устранении в кратчайшие сроки. Второй плюс продукта под ключ – это большое комьюнити, занятое поиском этих уязвимостей. Когда решения массовые, то и анализом их надежности занимается крупное сообщество исследователей по всему миру. Причем за большие деньги. Так, один из лидеров рынка bug bounty, компания Apple, увеличила размер вознаграждения за найденную уязвимость нулевого дня до $1 млн. Конечно, такой прайс не для всех типов CVE: баг с обходом экрана блокировки/извлечения данных пользователя поможет заработать $100 тыс., доступ к ядру у iOS – $250 тыс., а удаленный несанкционированный доступ к личным данным – $500 тыс. Согласитесь, стимул искать баги вполне рабочий.
Но у всех медалей есть две стороны: при некорректном патч-менеджменте такой подход оборачивается лишь большими проблемами. Для того чтобы правильно обновлять продукт, компании требуются специалисты, которые внимательно следят за апдейтами, выпускаемыми вендором, и получают от него рекомендации по их установке. Согласно этим рекомендациям, обновления должны быть установлены без каких бы то ни было задержек. На практике это соблюдается далеко не всегда.
Возьмем как пример государственный сектор: здесь часто используют не обновленные версии операционных систем, то же самое наблюдается в промышленности – программное обеспечение, используемое в технологическом сегменте, зачастую работает только с операционными системами Windows XP и Windows 7, которые уже не поддерживаются с точки зрения безопасности. В условиях, когда об уязвимостях корпоративных решений становится известно широкому кругу лиц, отсутствие критически важных обновлений открывает для злоумышленника прямой доступ в целевую систему.
В случае с внутренней разработкой, как было сказано выше, все упирается в вопрос использования дополнительных ресурсов. Бизнес-интересы редко отвечают поиску потенциальных изъянов безопасности, поэтому человеческий ресурс на эти цели, как правило, не выделяется. Соответственно, патч-менеджмент как таковой отсутствует.
Неравный бой
Итак, самописные решения отвечают принципу «здесь и сейчас» и в долгосрочной перспективе не могут составить полноценную конкуренцию корпоративным продуктам. Зачастую общие затраты на последние оказываются ниже, чем на доработку и надстройку дополнительных модулей внутренней разработки. Они быстрее и проще во внедрении, при этом при грамотном взаимодействии с вендором можно добиться функциональности, вполне сопоставимой с продуктами собственной разработки.
Для того, чтобы достичь нужной степени кастомизации и выбрать решение, подходящее для специфических задач, проведите анализ существующих продуктов, разработайте к ним конкретные функциональные требования и проведите сравнительные пилотные тестирования. Так вы сможете обеспечить наиболее эффективное функционирование внешней разработки внутри вашей инфраструктуры с учетом ее особенностей.
Смотреть все статьи по теме "Информационная безопасность"
Опубликовано 24.08.2020
