«Это напоминает бег по тонкому льду: чем быстрее ты бежишь, тем быстрее под тобой ломается лед… Остановился — утонул»

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

— В рамках ДИТ, существует 30 продуктовых команд, которые реализуют те или иные сервисы, разделенные, как правило, по отраслям: государственные услуги, ЖКХ, медицина и т.д. В каждой команде есть свои подразделения информационной безопасности либо выделенные специалисты. Кроме этого, есть продукт «Информационная безопасность», который, собственно, я и представляю. Моя задача агрегировать лучшие практики, которые есть на рынке, спроецировать их на некую уникальную структуру и декомпозировать их на продукты. Это могут быть стандарты, технологические решений, весь best practice, что есть на рынке, либо наши собственные мысли.

В чем проблема такой модели? Она очевидна, она на поверхности. Каждый специалист по информационной безопасности в продуктовой команде должен быть профессионалом широкого профиля. Как говорится, и швец, и жнец, и на дуде игрец. Он должен глубоко понимать риски информационной безопасности, наложенные на риски ИТ, кроме этого, он должен хорошо разбираться в инфраструктуре, понимать, что представлено на рынке, какие существуют best practice, стандарты и правила, а также уметь их применять в собственном продукте. Таких людей на рынке труда немного. У нас работают высококвалифицированные специалисты, но тем не менее идеального с точки зрения компетенции сотрудника не бывает — это всегда идеальный «набор» людей. Соответственно, имея 30 команд разработки, нужно создать 30 идеальных «наборов» групп по ИБ, а это очень непросто.

— Сейчас мы выстраиваем историю с двухуровневой информационной безопасностью, которая предполагает предоставление части функций ИБ как универсальных централизованных сервисов, и наблюдаем, насколько она может быть эффективна. Это все же история про некую экспериментальную модель. Москва уникальна. У нас единственная столица, единственная Москва, у которой свои проблемы и свои достижения. И, собственно, нет компании аналогичной нашему департаменту, поэтому и проблемы, с которыми приходится сталкиваться ДИТу, в некоторой части уникальны. Бороться с ними можно только экспериментальным путем. Конечно, мы смотрим на best practice других столиц, других крупных мегаполисов и других крупных компаний. Это всегда история про комбинации тех или иных успешных решений или практик, и попытки их спроецировать на наши проблемы, но они все же наши.

— Хороший вопрос. На самом деле есть два направления. Одно обычное — то хакерское сообщество, которое пытается заработать денег, монетизируя свои компетенции с «темной стороны силы». Это вирусная активность, методы социальной инженерии, попытки получения какой-то информации, которую можно потом монетизировать. А с другой стороны, Москва — это особый город, как я уже говорил выше, — это столица нашей Родины, и, безусловно, у нас есть векторы угроз со стороны других государств. Самое распространенное в этом плане для нас — достаточно широкие и глубокие DDoS- атаки. В принципе, у нас не бывает времени, когда бы мы не были под атакой.

— Я могу говорить только про нашу стратегию в плане пентестов. Как выглядит жизненный цикл этого направления. В первую очередь это машинные тесты, выстраивание процесса управления уязвимостями, далее — подключение труда человека — это пентесты. Наша цель — переход в итоге на Bug Bounty систему. Это то, к чему мы будем стремиться, то к чему мы планируем переходить. Полезнее ли использовать интеграторов для поиска уязвимостей, а не машинные тесты? Да, конечно, это полезно, это увеличивает количество найденных уязвимостей. Но интегратор — это всегда некоторое ограничение, касающееся количества сотрудников, — которые будут выполнять эту работу, поэтому привлечение интернет-сообщества для поиска уязвимостей — это следующий шаг. Но это не отменяет всех остальных шагов, нельзя выдавать сырую систему в паблик, тем более в Bug Bounty. Пентест обязательно предшествует этому шагу. При этом нельзя рассматривать пентест как некую законченную сущность, которая позволит добиться определенного результата, и на этом остановиться.

— Что такое Security Operation Center — SOC? Это набор компетенций и технических средств, которые позволяют вам управлять инцидентами информационной безопасности, проблемами, событиями. Это инструмент. Можно привести аналогию с лоскутной автоматизацией. Например, у вас в холдинге есть 20‒30 компаний со своими небольшими ИT-подразделениями. Их компетенция, бюджет и возможности ограничены, и результаты, которых они добиваются, тоже сильно ограничены. Объединение таких разрозненных ИT-подразделений в одну структуру помогает добиться больших результатов при меньших инвестициях. Централизация эффективнее и с финансовой, и с административной точки зрения. Что делаем мы? Проектируем Security Operation Center уровня Москвы, который должен помочь нам решать проблему мониторинга и реагирования. Я считаю, что SOC — это в первую очередь методология, а во вторую уже инструмент, которыми эта методология автоматизируется. Это может быть SIEM, Ticket Management, BI и прочее, что туда может или должно входить. Сейчас перед нами стоит задача оптимизировать источники получения событий, выстроить методологию, написать регламенты и правила, и самое главное — собрать команду профессионалов, которая и будет реагировать на инциденты. Для начала SOC должен помочь реагировать на инциденты, а впоследствии предотвращать их.

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

Я вижу на рынке ИБ-тренд на специализацию центров мониторинга и накопление определенных компетенций. Так вот, их привлечение, их знания продуктов, проблем отрасли, может дать эффект синергии, что на мой взгляд, может быть крайне полезно. Говорить об этом пока рано — все же Security Operation Center столицы — это не проект на пять минут.

— Наверное, есть две основные модели, каким образом можно регулировать область информационной безопасности в стране. Первое — это рыночная модель, когда сама компания должна принимать решение о методах, способах и инструментах, которыми она защищает свою информацию. Как правило, это коммерческие структуры, у которых все понятно: если они не защищают информацию или системы, они теряют определенное количество денег, поэтому бюджет на ИБ составляет часть из возможных потерь; не теряете деньги — получаете маржинальность. С точки зрения государственных структур, на мой взгляд, для самостоятельного развития ИБ не хватает ясного и понятного риска, который можно пересчитать в деньгах. Если мы посмотрим на предмет защиты — это будет защита суверенитета, защита репутации, персональные данные граждан, которые обрабатывает государство. Каким образом их можно пересчитать в те средства, которые государство должно инвестировать в информационную безопасность? Я таких методик не знаю, и, мне кажется, это основная проблема регулирования ИБ в госсекторе, в госструктурах — отсутствие методики, методологии для корректной конвертации рисков в материальную составляющую государственных рисков, потому что тот же суверенитет — как его пересчитать в рублях? Можно ли посчитать цифровой суверенитет? Такая методика, разработанная регуляторами ИБ, была бы крайне полезна в госсекторе.

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

— Я могу говорить только о своем опыте выстраивания взаимоотношений: сначала как специалист информационной безопасности, потом как человек, курирующий и ИБ, и ИT, потом как человек, управляющий ИБ и ИT в Тульской области, а сейчас как человек, курирующий ИБ в ДИТ Москвы. Такая вот спиралевидная история. Именно этот опыт позволяет мне примирять ИT и ИБ. Я понимаю, что хочет ИТ и в чем его риски: нужно вывести некое решение в production завтра утром, и оценивать его безопасность либо организовывать систему защиты какими-то наложенными средствами, просто нет времени. Постоянный цейтнот — основная проблема ИT. Вернее, не проблема, это основной критерий ИT, который разводит по разные стороны баррикад безопасность и информационные технологии. Информационная безопасность — это регулирование, регламентирование и закручивание гаек. Это запрет, это то, когда нельзя. ИT — это комфорт, сервисность, это то, когда можно и хочется. И вот это «нельзя» и «хочется» достаточно сложно свести воедино. Выстроить отношения здесь можно только через компромиссы, через стратегию win-win. Как только какая-то сторона считает себя проигравшей, начинаются разборки в виде эскалации на руководителей, дальше — разделение бюджетов, конфронтации. В этом случае что-то неизбежно будет теряться: либо темп развития ИТ, либо ИБ как таковое. Допустить этого нельзя. Как мы с этим боремся? По двум направлениям. Первое — регламентация правил информационной безопасности: как правильно жить с точки зрения ИБ без перекручивания гаек, но обеспечивая три критерия: доступность, целостность, конфиденциальность. Второе — это личные коммуникации.

Я считаю важным, чтобы ИТ и ИБ договорились о понятных и прозрачных правилах. Если ваш сервис будет недоступен в течение недели, потому что в нем остались уязвимости, это равно несозданному сервису, т.е. инвестиции в ИТ без учета ИБ были не эффективны — это понятно любому разумному человеку. Безусловно, ИT — это разумные люди, с гибким умом — другие у нас не работают. Конечно, их цель в том числе обеспечить качество сервиса, которое они выводят вовне. Поэтому, когда правила безопасности помогают им это сделать, они воспринимаются нормально. Это первое, а второе — это личные коммуникации, это пояснения, разъяснения этих правил… И главное вовремя услышать боль ИT, чтобы помочь ее решить, — в таком случае информационная безопасность становится частью организма, а не чем-то внешним.

— У каждого здесь свой путь…У меня мой. Все достаточно просто. Сначала нужно увидеть риски бизнеса, важно понять, что его беспокоит, что ему мешает работать хорошо. Это может быть периметровая защита, не выстроенные или выстроенные неэффективно процессы, необходимость соответствовать нормативным требованиям или требованиям регуляторов, репутационные и финансовые потери — это может быть все, что угодно. Я в своей работе всегда исхожу из принципа Парето: 20% усилий должны закрывать 80% результата, и наоборот. Сначала первая часть, наоборот — это потом, 80% усилий при 20% результата — это потом.

— Опять же есть два направления. Первое направление — это внутренний опыт, внутреннее ощущение, внутренняя практика того самого CISO, который реализует безопасность в компании или продукте. Во вторую очередь это методология… Но ни одна методология не написана конкретно под ту организацию, в которой ты получаешь заработную плату и работу которой ты должен сделать безопасной. Поэтому в любом случае берешь собственные мозги и проецируешь на ту компанию, в которой ты обеспечиваешь ИБ. Я поступаю именно так.

.

— Как таковой обмен опытом, на мой взгляд, выстроен… Его можно улучшать, безусловно… как любой процесс, но он выстроен. Инструментов здесь достаточно много: это те конференции и форумы, которые организуют интеграторы, вендоры, регуляторы. Примером такой площадки для встреч и обмена компетенциями можно назвать комиссию по информационной безопасности, которая организована в каждом федеральном округе, внутри каждого региона, субъекта Российской Федерации.

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

Здесь мне проще говорить, опираясь на свой опыт работы в Тульской области. Мне приходилось очень много общаться и обмениваться опытом, потому что готового шаблона нет. Никто и никогда не придет и не скажет, возьми вот этот журнал, прочитай вот эту статью или выполни вот этот guide, и ты получишь ту безопасность, о которой мечтал. Такого нет и, наверное, не будет никогда. Все же у нас федеративное устройство, поэтому решения так или иначе принимаются регионами самостоятельно. Что показывает практика? Практика показывает, что централизация — это хорошо, централизация финансов — тоже хорошо, централизация компетенции тоже хорошо, централизация идей тоже хорошо, включение гражданского общества — это вообще прекрасная история с точки зрения самих идей и их реализации. Главное здесь — не останавливаться, вовремя признавать ошибки, пытаться эти ошибки устранить либо просто отбросить, если то направление, по которому вы пошли, оказалось неэффективным. Такое бывает, человек слаб, он ошибается… Ни в коем случае нельзя останавливаться. Мне это напоминает бег по тонкому льду: чем быстрее ты бежишь, тем быстрее под тобой ломается лед, но остановиться ты не можешь, поэтому приходится бежать все быстрее и быстрее. Только такой подход позволяет достичь результата.

С точки зрения обмена опытом по ИБ, на мой взгляд, сейчас инструментов достаточно. Возможно, было бы полезно увидеть чуть больше усилий со стороны регуляторов. Что я имею в виду… Мне кажется, было бы замечательно иметь площадку, организованную под их эгидой, для обмена мнениями и общения. Да, мероприятий, посвященных ИБ, сейчас хватает, но их организаторы — это либо интеграторы, либо вендоры. Если говорить откровенно, цель интегратора или вендора — заработать денег, и в этом нет ничего зазорного, но, к сожалению, такой формат мероприятий не позволяет обмениваться информацией максимально открыто, тем более, если мы говорим про госрегулирование. Я вижу потребность в «закрытом» пространстве для обмена опытом, именно поэтому мы сейчас обсуждаем возможность создания такого пространства с ФСТЭК.

Второе — внутренний драйвер, двигающий это направление вперед. Если драйвер находит понимание у лиц, принимающих решение, и может защитить свою позицию, направление движется. Регионы сильно отличаются наличием или отсутствием такого драйвера. Поэтому вернемся на несколько вопросов назад в нашей беседе… Деятельность регуляторов необходима. Это не пряник, это кнут, и он нужен. Он выравнивает общее положение. Но есть другая сторона медали: такое регулирование создает сложности для регионов, которые развиваются с использованием собственного внутреннего драйвера, потому что регулирование направлено на среднюю температуру по больнице. Когда ты за эту среднюю температуру выходишь, например, в плюс — в 39 °С, тебе становится тесно в этих правилах и рамках.

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