В мягкое и податливое можно так глубоко влезть, что уже никогда не вылезешь
(Ассоциация)
На секции Сбербанка SOC-Форума 2017 единодушным пожеланием пользователей производителям систем ИБ было наличие открытых API с целью максимально гибкой адаптации решения под свои нужды. А нужно ли это? Если вы - не технологическая компания, то, скорее, нет.
1. Не надо распыляться. Если вы работаете в производственной компании, в реальном секторе экономики, то ваш ключевой бизнес - не ИТ, тем более, не ИБ, а ИБ для вас - операционные косты, которые всячески стремятся снижать. А раз так, то и менеджеру ИБ в этом случае следует приоритезироваться на наиболее важные задачи. Здесь не до перфекционизма, не до построения стратегии ИБ на 10 лет в течение года, не до многолетних проектов построения супер-эффективной СУИБ, не до "допиливания" коммерческих продуктов до соответствия какому-то ощущению прекрасного, - правильно взять готовое решение и, по-максимуму используя его возможности из коробки, с минимальными затратами на адаптацию насколько возможно быстро начать его использовать.
2. Не надо желать от коммерческого продукта свойств opensource. Если вы хотите бесконечные возможности по доработке - возьмите opensource - зачастую это хороший компромисс между коммерческой коробкой и собственной разработкой. Не надо требовать от коммерческого продукта гибкости opensource - это невозможно, так как чем больше возможностей вендоры вам предоставляют, тем больше их риск получить от вас конфигурацию, которая будет несовместима со стабильностью\надежностью\функциональностью продукта, которые вендоры должны поддерживать. Производители ПО не могут и не должны отвечать за то, что полет вашей фантазии сломает их продукт, поэтому они вынуждены ограничивать вас в возможностях.
3. Коммерческая компания всегда имеет задачу заработать. Незначительно, но все же здесь прослеживается и коммерческая составляющая: вендоры лучше интегрируются со своими продуктами или с продуктами своих партнеров, чтобы мотивировать потребителя приобретать их продукты, и иметь возможность продемонстрировать, что ценность интегрированного комплексного решения превышает ценность суммы составных частей.
4. Чем больше инвестируете в решение, тем меньше шансов сменить вендора. Чем больше вы инвестируете в кастомизацию дефолтного функционала, тем меньше шансов, что вы когда-нибудь уйдете с этого вендора и\или партнера. Действительно, неразумно вложить столько в подготовительные работы, потратив на них N лет, а затем - сменить решение. И вот тут-то из вас все
5. Инвестиции в "обвес" увеличивают OpEx, а их надо снижать + куча других "неожиданностей". Не стоит забывать о законе сохранения, о гибкости и сложности, и о том, что глубокая кастомизация может очень близко граничить с заказной разработкой. Вы уверены, что вы этого хотите?
Поразмыслив можно придумать еще аргументов против бесконечной гибкости решения, но, думаю, приведенных вполне достаточно. Конечно, правда где-то по середине и здесь, как и везде, важен баланс гибкости и сложности. Поскольку этот баланс (именно баланс, а не исключительно гибкость) - конкурентное преимущество, уверен, все успешные вендоры, понимая очевидные вещи, здесь описанные, соблюдают этот баланс в предлагаемых продуктах, и поэтому наши претензии в отсутствии API, которых нет, вероятнее всего, не обоснованы.
3 comments:
Хм. А не слишком ли менеджерский у тебя взгляд на вопрос?
Ведь когда-то ты писал про мотивацию: http://reply-to-all.blogspot.ru/2013/05/blog-post.html
Хорошему инженеру не интересно ставить коробку за коробкой, осваивая бюджет. Он всегда попробует что-то подкрутить и адаптировать, чтобы получить удовлетворение от хорошо работающей системы.
Кроме того, мне кажется, системы ИБ в ближайшее время не станут чисто коробочными продуктами, потому-что они должны учитывать архитектуру и решения используемые в защищаемой информационной системе.
Перефразирую - нам продают коробки, которые начинают мигать лампочками сразу, после установки. В принципе красиво и ты наслаждаешься некоторое время. Но потом, ты понимаешь, что лампочки горят не так - эту нужно убрать, эту сделать поярче и добавить пяток новых. И если ты дошел до этого момента, то ты хочешь api, гибкость и тп. А если ты торопишься купить новую коробку и до старой тебе дела уже нет - тогда да - ты прав, твой подход верен.
Вернемся к варианту, когда ты хочешь подкрутить - купив коробку, ты ожидаешь, что она будет ехать не только по прямой дороге, но и уметь заезжать в переулки и делать параллельную парковку. А если тебе захочется прокатиться по проселку, то тебе очень хочется сделать лифтинг, поменять резину и так далее. Но если диски приварены насмерть - это уныло.
Вот мы снова выходим на вопрос аутсорсинга: что делать самому, а что поручить. Хорошо детерминированную работу, по которой есть зрелое предложение на рынке надо аутсорсить. Многие из нас уже давно не чинят машины сами (и даже не моют), не кладут плитку в ванной, не меняют сантехнику, не строят дома, не штукатурят потолок, потому что есть полно людей, которые это сделают луше. С другой стороны, есть вещи, которые никто за меня не сделает вообще, но которые надо делать. Например, если у меня куча самописного ПО, то никто не займется его безопасностью, если у меня есть ощущения, что моя операционная безопасность неэффективна, то оптимизировать бизнес-процессы лучше самому, - удивительно думать, что если я сам не могу разобраться в себе, то пришедший головастый консультант разберется в этом лучше. Далее, риски ИБ надо снижать на всех уровнях, не только на уровне инфраструктуры, но и на уровне приложений, на уровне взаимодействия подразделений, на уровне стратегии компании. Чем выше уровень, тем выше степень корпоративной специфики, и тем ниже будет эффективность наемного консалтинга (аутсорсинга), а там, где аутсорсинг неэффективен - не надо его пытаться применять, - это задача корпоративного безопасника.
Проблема в том, что придя в позицию CISO люди начинают продолжать делать то, что они умеют (== то, что они делали в прошлой жизни). Если человек в прошлом админ - он бросается в инфраструктурную безопасность: администрирует фаерволы, даже сетевое оборудование, антивирусы, тогда как эта функция практически не зависит от бизнеса предприятия и поэтому прекрасно аутсорсится. Другие, пришедшие из регуляторов, начинают делать тотальный комплайнс, предполагая, что из этого получится безопасность (я писал о том, что из безопасности получится комплайнс, но не наоборот).
А нужно оценить свои слабые и сильные места, а также слабые и сильные места потенциальных аутсорсеров и собрать Безопасность по частям из сильных сторон, своих и аутсорсеров.
Поэтому, я считаю что инфраструктурную безопасность вообще по-минимуму надо делать самому, тем более по-минимуму надо тратить время на "допиливание" коммерческих решений. Если степень ваших доработок превышает 50% дефолтного функционала - задумайтесь о смене решения. Не надо делать ЭТО - это работа производителя, интегратора, но не интерпрайзного безопасника.
Но пост о том, что глубокое допиливание - опасно, так как высокая степень кастомизации позволяет назначать персональную стоимость владения, очевидно, она будет не меньше цены для типовой конфигурации, поэтому будет дорого, а сменить решение тоже не будет возможности, ибо уже столько туда вложили. Поэтому запрашивая гибкость, API и т.п. - вы сами залезаете в болото из которого будет невозможно вылезти, вы увеличивается OpEx-ы, которые надо стремиться снижать. Если хочется гибкости - посмотрите на opensource, а хотеть от коммерческого продукта возможностей opensource - неправильно, как минимум, потому что производитель не может отвечать за то, что ваша кастомизация нарушила работу его продукта.
Желание клиента - закон. Если клиент готов за это платить, почему бы такой функционал не сделать? К сожалению, всё чаще наблюдаю тенденцию, что СрЗИ (преимущественно отечественные) разрабатываются не для защиты пользователя, а для зарабатывания денег.
Post a Comment