08.05.2013

Управление взаимоотношениями с поставщиками решений по информационной безопасности

Вчерашняя заметка про потенциальное поглощение Stonesoft и в блоге и на Facebook вызвала оживленную дискуссию, которая оказалась далекой от первоначальной темы. Обсуждали все - кто и как не умеет читать список сертификатов ФСТЭК, какие сертификаты ФСБ есть у Cisco, как я в своем личном блоге рекламирую работодателя, как в список сертификатов на отсутствие НДВ попали компании, которые никаких исходных кодов не предоставляли, как плохо сработали PR-службы российских McAfee и Stonesoft, какие бывают акционеры, отказывающиеся от получения дохода, превышающего 10-кратный размер первоначальных активов, и т.д. И даже тема, поднятая Рустемом Хайретдиновым, плавно переключилась на совершенно иное обсуждение; хотя мысли о M&A-сделках на рынке ИБ звучали там интересные. А ведь Руст говорил о вполне конкретной теме, которую я и хотел бы развить. Имя ей vendor management или управление взаимотношениями с поставщиками (вендорами).

В зависимости от масштаба компании это может быть как отдельное подразделение (причем именно как vendor management office, а не как расширение отдела закупки /procurement/), так и просто набор функций, которыми занимается сотрудник компании. Идея управления взаимоотношениями с поставщиками проста и понятна - эффективное планирование всеми аспектами взаимодействия с поставщиками тех или иных продуктов и услуг (в нашем случае - по ИБ).

В России взаимодействие с поставщиками часто воспринимается только в контексте выбивания скидок или оформления различных схем с "возвратом инвестиций", а на самом деле обычно в это понятие включаются следующие элементы:
  • стратегия выбора поставщиков и управление портфелем продуктов и услуг
  • формирование и контроль SLA при взаимодействии с поставщиками (аутсорсинг сюда также можно запихнуть)
  • бюджетирование и анализ затрат
  • оценка, аудит и выбор поставщиков
  • управление списком разрешенных поставщиков
  • управление ценами и скидками
  • сбор требований от внутренних подразделений и обработка полученных спецификаций от поставщиков
  • управление RFP-процессом
  • переговоры с поставщиками
  • оформление договоров
  • анализ рисков
  • поощрение и наказание поставщиков.

Например, вчерашняя тема про Stonesoft относится сразу к нескольким пунктом этого списка - к анализу рисков и стратегия выбора. Допустим, речь идет о крупной компании, у которой "денег куры не клюют" и она способна приобретать продукты с целью "потестировать, а вдруг подойдет". Ей по сути все равно, кого купить сегодня, а кого завтра. А если взять компанию, представляющую малый или средний бизнес? Для нее выбор компании, которую завтра могут поглотить, может стать пустой тратой, а то и потерей, денег. Для госоргана может быть не так важно будущее продуктовой линейки (я тут обратил внимание, что в последнем списке сертификатов ФСТЭК вновь всплыли Cisco Pix, которые мы сняли с продаж в 2008-м году, а поддержка заканчивается в 2013-м), сколько возможность продления сертификатов (или сертификации вообще). И таких примеров, когда наличие стратегии управления поставщиками может помочь принять правильное в долгосрочной перспективе решение можно привести множество.

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

Что могло бы войти в состав такого чеклиста, который мог бы стать отправной точкой при общении с поставщиками решений по ИБ? Увы, четкого ответа нет. Его нет даже для продуктов, а уж тут-то выбирать, кажется, проще всего. Но увы... 10 лет назад я написал для PCWeek/RE статью "Сделай правильный выбор" - про то, как выбирать средства защиты. Метод не новый, но до сих является одним из самых оптимальных. Вопрос только в критериях оценки, которые сильно зависят от конкретной ситуации, и от весовых коэффициентов, которые также меняются от компании к компании.

Но не продуктом единым... Необходимо учитывать и ряд других факторов; уже на уровне производителя. В статье шестилетней давности "Западный или российский производитель ИБ: кого выбрать" я показал разницу между двумя "школами", которую можно учитывать при выборе будущего партнера в области ИБ. Но вендор вендором, но, как правило, между ним и потребителем стоит партнер, а то и вовсем представитель, отстаивающий интересы западной компании, не пожелавшей открывать в России свой офис. И тут на сцену выходит третий набор критериев для оценки и попадания в чеклист - техподдержка (время, язык, скорость реагирования), наличие лицензий (если они являются обязательными), результаты оценки соответствия в форме обязательной или добровольной сертификации, легальность ввоза, скорость поставки и т.п. 9 лет назад я про эту сторону выбора вкратце упоминал в статье "Теория и практика выбора межсетевого экрана".

Какие вопросы включают зарубежные CISO в свой чеклист? Например, такие:
  • финансовые показатели и корпоративные анонсы
  • ротация топ-менеджмента и организационные изменения
  • изменения в продуктовой линейке и направлениях бизнеса
  • истории успеха у заказчиков
  • уровень удовлетворенность заказчиков
  • структура и прозрачность ценообразования
  • партнерская сеть
  • инсталлированная база
  • roadmap и объем инвестиций в R&D.

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

Да ну эту всю теорию, кому она нужна? Частично соглашусь. Многим не нужна. Многие руководители служб ИБ либо чисто интуитивно выбирают себе партнера на долгие годы, либо не сталкиваются с такой проблемой. А кто-то и вовсе считает ее нестоящей и выеденного яйца. Особенно если выбирается решение/компания для некритичного направления бизнеса.
 
Причем понятие "критичности" у всех тоже может быть разное и на его трактовку могут влиять:
  • Важность и число процессов, в которые могут быть вовлечены (а также глубина вовлечения) приобретаемые или просто выбираемаые ИБ-решения. Одно дело выбрать 2-3 токена для хранения ЭП бухгалтера и гендиректора и совсем другое дело выбирать полноценное IdM-решение в масштабе всего предприятия.
  • Уровень доступа к конфиденциальной информации. Этот критерий скорее важен при выборе консалтинговой компании, а не поставщика продуктов.
  • Уровень затрат на решения выбираемого вендора. Потратить/потерять 1-2% от своего бюджета и 35%... Это заставляет задуматься и более серьезно подойти к выбору компании-партнера.
  • Уровень интеграции внутри компании. Одно дело IdM, с которым сталкиваются все подразделения компании и совсем другое дело - SIEM, результаты работы которого видны только службе ИБ.
  • Длительность планируемых отношений. На пентест или разовый аудит заказного ПО можно пригласить не очень известную компанию и критерием выбора тут может служить цена (к примеру). А вот для защиты АСУ ТП, жизненный цикл которой (не говоря уже о потенциальном ущербе в случае реализации инцидента ИБ) может измеряться десятилетиями, число достойных кандидатов будет гораздо меньше.
  • Наличие субподрядчиков. Одно дело довериться одной-единственной компании и совсем другое, когда тендер выигрывает генподрядчик, предложивший лучшую цену или каждые выходные играющий в гольa с вашим гендиректором, и который привлекает для выполнения работ малоизвестные и невысоко себя ценящие конторки.

На крупных предприятиях и в холдинговых структурах процесс закупки и взаимодействия с поставщиками обычно худо-бедно выстраивается и стоило бы перенять оттуда уже отработанные механизмы в процесс работы с ИБ-компаниями. А иногда стоит и привнести вопросы ИБ в процесс закупки. Но про это отдельный разговор будет. Если не забуду ;-)

4 коммент.:

mike комментирует...

Алексей.
Замечательный пост ни о чем.
об этом чуть позже.

но я случайно кликнул на ссылку Теория и практика выбора межсетевого экрана. Посмеялся вдоволь.
Если кто не понял:

статья 2004 года написана "Алексей Лукацкий,
руководитель отдела Интернет-решений НИП "Информзащита"
luka@infosec.ru "

Алексей пишет = "Своей работой в управлении информационных технологий одного из банков я обязан обыкновенным компьютерным воришкам...." . Вот кто не знает, Алексей с 1997 года в Информзащите работал ..... Интересно а работал в банке до этого? в linkedin ответа нет.
Но больше всего насмешила фраза в статье: "...в данном банке очень широко использовался протокол динамической адресации DHCP. ... в список требований нужно было также включать поддержку динамической адресации." --- фраза уровня а напряжение будем измерять напряжометром! Вообще в DHCP есть понятие времени аренды.... И вопросы с переводом адреса в имя пользователя раньше у все решались примерно похожим способом ... Алексей ты знаешь каким способом тогда делали это? назови плиз ?

вот тут встает вопрос вопрос а когда именно это было ????

Если это происходило до 1997 года, а упоминается ПЕРВОЕ задание - то давайте вспомним а что тогда было? И возникали тогда вопросы про воришек, когда интернет был не у всех банков? Ну допустим это было в 2004 году - тогда непонятно в 2004 году человек участвующий в написании раздела книги Атака на интернет ( могу ошибаться в точном названии) получает ПЕРВОЕ задание ?????

Алексей, а когда всетаки это было ????
ну просто интересно .....
И всетаки удалось найти тогда ( до 1997 года) экран который тогда поддерживал Динамическую Адресацию???
Или это просто художественный вымысел????



Алексей Лукацкий комментирует...

Миша, я смотрю новость о поглощении Stonesoft не лучшим образом повлияла на твои аналитические способности. Вот тебе еще одна моя статья 2007-го года - http://www.computerra.ru/cio/old/it-expert/311300/. Она написана от имени руководителя службы ИБ.

Попробуй еще раз предположить, почему был выбран именно такой стиль изложения ;-)

ЗЫ. А в банке я работал ;-) Не суди о человеке по профилю в социальной сети - там публикуется то, что человек считает нужным опубликовать ;-)

mike комментирует...

Алексей Лукацкий пишет...

"Попробуй еще раз предположить, почему был выбран именно такой стиль изложения ;-)

ЗЫ. А в банке я работал ;-)"

Алексей. Стиль изложения в другой статье понятен - художественный вымысел.... А в первой нет. И выходит, что это ты с компьютерными воришками боролся в 1997 году. Хотя если перейти в 2004 то в одном из интервью ( можно поискать в инете) ты признавался, что времени нет ни на что, кроме презентаций и статей ....
А вот на что обратил внимание, и что ты старательно обошел - в дежурном тексте про экраны - ты видимо собирал что можно не потрудился узнать как именно проблемы с DHCP решаются .... такого понятия то поддержка динамической адресации никто не применял .... Это и называлось по другому. А всетаки знаешь как это всегда делали ? :)


Алексей Лукацкий комментирует...

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

А может ты пытаешься меня публично унизить, обвинив в некомпетентности? Так я могу облегчить тебе задачу. Выложить мои диктанты, которые я в 3-м классе писал? Ты там сразу кучу ошибок найдешь и успокоишься может быть.

Хотя нет. Это ж ты опять потратишь время на несвойственную тебе деятельность. Ты же у нас один в России работаешь, а все остальные фигней страдают. Ты один умеешь сертифицировать продукты. Ты один умеешь писать статьи. Ты один знаешь как работают МСЭ. Ты один знаешь как обойти любую IPS. Признаю твою единственность и неповторимость. Ты гений! Можешь распечатать это мое признание твоей крутизны и при любом случае показывать его всем! Преклоняюсь перед тобой, о непревзойденный гуру информационной безопасности. Аминь!