В ИБ‑отрасли GR‑директор должен глубже разбираться в технологиях (DPI, NGFW, EDR), чем его коллеги из FMCG‑сегмента. Каковы, на ваш взгляд, основные технологические аспекты, которые необходимо знать GR‑директору компании, занимающейся информационной безопасностью?
Чтобы продукт в сфере ИБ успешно продавался, он должен иметь набор необходимых артефактов: запись в реестре Минцифры/Минпромторга, сертификат ФСТЭК/ФСБ и т.д. Получение некоторых из них, например сертификата ФСТЭК России, требует от продукта реализации определенных требований, в том числе конкретных функций безопасности для различных классов СЗИ. Исходя из этого, GR‑директор должен знать, для каких классов СЗИ у регулятора есть требования по безопасности информации или профилю защиты, а для каких нет (однако эти классы должны удовлетворять определенному уровню доверия); знать, для каких сегментов рынка необходима сертификация на тот или иной уровень и, соответственно, какие СЗИ на какие сегменты рынка ориентированы; понимать, какие подразделения задействованы на разных стадиях сертификации, то есть какие требования регулятора относятся к архитектуре, документации, тестированию, и своевременно планировать соответствующие ресурсы. Вот примерно на таком уровне погружения GR‑директор в сфере ИБ должен разбираться в технологиях.
В условиях действия перечня недружественных стран, активной блокировки запрещенного контента и расширения требований ФСТЭК какие три качества GR‑руководителя могут помочь развитию бизнеса компании-вендора, а какие, наоборот, скорее помешать?
Мне как директору по работе с государственными структурами помогает хладнокровие. Важно оставаться собранным и не поддаваться эмоциям. Думать не о проблеме, а о решении. Как правило, оно есть, и вопрос лишь в том, насколько быстро ты его найдешь и насколько оно окажется эффективным. Вторым качеством я бы назвал прагматичность. Как говорил американский генерал времен Второй мировой войны Джордж Смит Паттон младший: «Хороший план сегодня лучше безупречного плана завтра». Надо всегда держать в голове план B, а лучше еще и план С, для всех более‑менее реалистичных негативных сценариев. И тогда в случае их наступления ты начинаешь действовать немедленно, имея уже какие‑то наметки и не теряя драгоценного времени на раздумья. Ну и третьим качеством я бы назвал коммуникабельность. Большинство проблем можно если не решить сразу, то хотя бы понять, как их можно решить, просто совершив «звонок другу». Но для этого у тебя в телефоне должно быть достаточно много проверенных людей из разных профессиональных сфер. Ну а помешать, в свою очередь, может болтливость. Работа GR неразрывно связана с конфиденциальной информацией. Умение ее получать и хранить стоит очень дорого. Суетливости тоже нужно избегать. Излишней, непродуманной бурной деятельностью по решению проблемы можно создать еще больше проблем. Помешать может и ригидность. Мир меняется, независимо от того, нравится нам это или нет. Иногда эти изменения могут вызывать проблемы для отдельно взятой страны, отрасли, компании, личности. Это надо принять априори и всегда быть готовым к адаптации.
Государство требует от вендоров прозрачности кода, а практика ведения бизнеса — защиты ноу‑хау. Как должен вести себя GR‑директор, чтобы убедить госзаказчика, что он не «шпион», а партнер, при этом не раскрывая ключевых технологических секретов?
Тут всё относительно просто. Код при сертификации продукта можно показывать проверяющим «из своих рук», то есть в офисе или же с ноутбука сотрудника. Это нормальная практика. Там важен не сам исходный код, а артефакты по результатам различных видов тестирования (статическое, фаззинг, функциональное и т.д.). А уже полученный по итогам сертификат регулятора является необходимым и достаточным аргументом для госзаказчиков, что продукт безопасен и соответствует требованиям к конкретному классу СЗИ. И заказчику ведь не сами ноу‑хау интересны, а крутые функциональные и нефункциональные характеристики, являющиеся следствием использования в продукте того или иного решения. Это, в свою очередь, подтверждается результатами тестирования: внутреннего, независимого или же в ходе пилотирования непосредственно у клиента.
Допустим, вы находитесь на совещании с регулятором, где лоббисты конкурентов уже оставили негативный осадок о вашей компании. Как GR‑директор в ИБ показывает отличие «нашего подхода» от их?
Безотказно работает золотое правило: «О конкурентах или хорошо, или ничего». Я лично всегда говорю не просто «конкуренты», а «наши коллеги-конкуренты». Потому что по линии GR мы на самом деле больше коллеги, чем конкуренты. И это сразу меняет тональность разговора. Кроме того, надо всегда оперировать фактами, которые подтверждены наблюдениями или измерениями, а не чьими‑то субъективными суждениями и выводами, сделанными на основании неверной интерпретации событий.
Еще 5–7 лет назад для регуляторов было важно наличие «железки», сегодня — импортонезависимость, завтра — ИИ для SOC. Как в этой связи меняется повестка и лексикон GR‑директора и успеваете ли вы за этой технологической и лингвистической гонкой?
По роду своей деятельности я подписан на несколько десятков профильных чатов и каналов, ежедневный мониторинг которых позволяет быть в теме всех актуальных трендов. Единственная проблема, что сейчас на этот самый мониторинг надо более основательно закладывать рабочее время. То есть это уже не 5–10 минут в день, а скорее 30–40. И это просто чтобы бегло пробежаться и отложить объемные материалы на выходные. Соответственно, примерно раз в неделю я трачу еще пару часов на чтение отложенных лонгридов: статей, обзоров, проектов НПА и т.д.
Всё чаще звучит мнение, что «импортозамещение закончилось». При этом нередко его можно услышать не только от аналитиков, но и от чиновников. В этом контексте можете ли вы описать сценарий, при котором жесткий стиль общения GR‑директора отечественного вендора с клиентами принес бы лучший результат, чем мягкий подход?
Блажен, кто верует. Если кому‑то удается успешно отчитаться о завершении импортозамещения, можно за него только порадоваться. Давать рассматриваемому процессу столь однозначные оценки — за пределами нашей компетенции. Что касается выбора стиля общения, предлагаю взглянуть на это с иного, менее категоричного ракурса. В общении с клиентами мы всё же стараемся оперировать не только и не столько жесткими регуляторными требованиями, сколько реальной пользой, приносимой нашей продукцией. Другими словами, всегда есть выбор, либо реализовать требования по импортозамещению (и любые другие требования законодательства и регулятора) чисто для галочки, всё равно при этом потратив время, деньги и не получив в конечном счете никакой ощутимой пользы, а может быть, даже ухудшив бизнес-процессы в организации. Так часто работает «бумажная безопасность»: много регламентов, запретов, ограничений. По факту же реальной безопасности не прибавилось, а вот работать людям станет сложнее. Либо же реализовать эти требования путем реального усиления защищенности организации посредством внедрения современных отечественных СЗИ, потратив, может быть, больше денег и времени, но при этом получив ощутимую пользу и не ухудшив существующие процессы.
Среди специалистов компаний, использующих защитное ПО, да и самих его разработчиков можно встретить мнение, что нормы 152‑ФЗ или приказов ФСТЭК местами слишком строги и избыточны. Как, по вашему мнению, GR‑директору следует доносить до регуляторов имеющуюся критику, чтобы его не запомнили как вечно недовольного смутьяна?
Через кейсы, то есть сугубо на конкретных примерах, и оперируя фактами. Если требования или какие‑то нормы НПА избыточны, — это полбеды. Времена нынче неспокойные, а безопасности много не бывает. А вот если они в принципе нереализуемы, — это уже проблема. К сожалению, иногда случается, что тот или иной регулятор в своих безусловно благих намерениях опережает текущие возможности индустрии. Мы собираем факты и, как правило, от лица профильных ассоциаций доносим информацию до соответствующего ведомства, после чего начинается конструктивный диалог.
Если завтра крупный телеграм‑канал напишет, что UserGate пропускает атаки из‑за сырого кода после ухода западных архитекторов, какова будет первая фраза или действие GR‑директора для госорганов?
Хорошо зная преимущества нашего продукта, и особенно в сочетании с нашей же ИБ‑экспертизой, я бы начал со знаменитой фразы из к/ф «Красная жара»: «Какие ваши доказательства?». Писать можно много — бумага всё стерпит. Перефразируя Глеба Жеглова, можно сказать, что «качество продукта измеряется не наличием уязвимостей, а умением вендора их устранять». И тысячи внедренных решений нашего производства на живой ИТ‑архитектуре клиентов в этом контексте говорят сами за себя: нам доверяют и нас выбирают часто по результатам длительной и кропотливой процедуры пилотирования. Также могу заявить, что далеко не все архитекторы уехали вслед за западными вендорами, — некоторые выбрали остаться на Родине и даже работают в нашей компании, добавляя доверия нам и нашим продуктам.
Предположим, что была обнаружена критическая уязвимость в ИБ-продукте. Госзаказчик паникует. Как GR‑директор должен выглядеть на экстренном совещании в ведомстве — в образе «кающегося грешника» или «уверенного инженера с планом»?
Он должен выглядеть инженером с планом. CVE случаются и устраняются — это жизнь, тут нет смысла истерить или паниковать. Снова отошлю к варианту цитаты выше. Если продукт действительно отечественный и вендор полностью владеет исходным кодом и используемыми технологиями, то устранение происходит очень оперативно.
В среде ИБ всё еще сильна «техническая патриархальность». Должен ли GR‑директор соответствовать образу «брутальный мужчина-технарь 40+», или сегодня есть спрос на другие типажи?
Знаете, я и сам своего рода брутальный мужчина-технарь 40+, так что, наверное, поддержу именно эту версию. Но честно признаю, что в этой роли стали чаще встречаться и девушки. Я вообще против любого сексизма и эйджизма. Соответствие той или иной роли заключается исключительно в наборе личных качеств, релевантном опыте и степени удовлетворения от своей работы.
Назовите действенный прием в переговорах с госструктурой, к которому опытный GR‑директор изредка, в особенных ситуациях, может прибегнуть. И почему молодым специалистам это лучше не повторять?
Сразу скажу, что не люблю манипуляции, так как это очень плохая история на долгосрочном горизонте, и никогда их не использую, — все мои коллеги в госорганах это знают. Но если говорить об эффективных приемах, применяемых раз в два‑три года, то есть один такой. Называется он… «попросить». Жизнь устроена таким образом, что иногда люди друг друга о чём‑то просят. И иногда эти просьбы выполняют. За более‑менее продолжительную и содержательную карьеру у энергичного руководителя может накопиться достаточно много людей, которым он когда‑то чем‑то помог. И, опять же изредка, в какой‑то сложной нестандартной ситуации можно одного из таких людей, близкого к теме проблемы, попросить об ответной услуге. Человек очень не любит быть должен, поэтому схема, как правило, работает. А молодым это не дано просто по причине отсутствия необходимого жизненного багажа — тут работает только длительное время, проведенное в определенных кругах. Ну и эмпатия, конечно.
Предположим, что во время массированной атаки на госсектор именно ваш продукт дал сбой из‑за перегрузки. Как должен измениться образ GR‑директора для СК, Минцифры и для внутренней команды?
Вне зависимости от ситуации мой образ не меняется. Личность GR‑директора всегда должна быть цельной и сильной, тем более в критической ситуации. Формальная же сторона может выглядеть так. Предположим, случается сбой. Раз он происходит из‑за гипотетической перегрузки, значит, в целом это не проблема продукта. Дело в том, что у любого решения есть заявленная производительность, за пределами которой оно перестает в полной мере выполнять свои функции. В случае наших продуктов производительность подтверждается объективными результатами нагрузочных тестирований. Таким образом, мы приходим к тому, что проблема, очевидно, заключается в плохо спроектированной ИТ/ИБ‑инфраструктуре. При этом мы всегда поможем нашим клиентам разобраться, отчего произошел тот или иной сбой, и устранить его последствия, чтобы их инфраструктура, а вместе с ней и наш продукт продолжили работать в штатном режиме. Да и в целом проблема перегруза относительно быстро и легко решается путем наращивания мощности (установка более высокопроизводительных изделий, объединение изделий в кластеры с балансировщиком нагрузки и т.д.), то есть всё это регулируется условиями эксплуатации на стороне клиента. Ровно это и должен транслировать GR‑директор в процессе коммуникации. Меньше говорить, больше действовать, оперативно привлекая все возможные ресурсы внутри компании для минимизации ущерба для клиентов с целью повышения уровня их доверия к нам как к ИБ‑вендору и архитектору сетевой безопасности.