Артём Гутник: Ключевой KPI компании НСПК — уровень надёжности 99,999 %

Артём Гутник, руководитель направления кибербезопасности Национальной системы платежных карт (НСПК), ответил на вопросы генерального директора Anti-Malware.ru Ильи Шабанова. Из интервью вы узнаете о том, что такое НСПК и каковы её основные направления деятельности, как достичь практически стопроцентного уровня отказоустойчивости, зачем нужны MirAccept и CryptoMIR, как комплаенс влияет на сектор пластиковых карт, а также об использовании в компании коммерческих, опенсорсных и самописных решений.

Я хотел бы начать с такого вопроса: насколько информационная безопасность важна для такой компании, как НСПК, и какие ключевые задачи стоят перед вашим департаментом на данный момент?

А. Г.: У НСПК есть три основные задачи. Первая — обработка всех внутрироссийских платежей по картам международных платёжных систем. Когда в России мы платим с помощью Visa, MasterCard или других платёжных систем, в том случае, когда операция — межбанковская (то есть эквайрер и эмитент — разные банки), все эти операции проходят через нас, через компанию НСПК. Второе направление деятельности — наша российская платёжная система «Мир», которая, кстати, уже вышла на международный рынок. Сегодня картой «Мир» уже можно расплатиться в 11 странах. И третье — это Система быстрых платежей, СБП, которая появилась совсем недавно, но уже бьёт все рекорды по количеству операций. С 2019 года объём переводов через СБП превысил 2 трлн рублей, а услугой воспользовались почти 25 млн человек. При этом россияне всё чаще оплачивают покупки с помощью СБП: только с начала года число таких операций выросло в полтора раза по сравнению со всем 2020-м и достигло 6 млрд рублей. По сути, это и есть три основных направления деятельности компании.

На самом деле, направления деятельности как раз и диктуют те необходимые меры «кибербеза», которые мы должны у себя соблюдать. Один из ключевых KPI компании — это уровень надёжности «пять девяток» (99,999 %. — Прим. ред.). У нас нет возможности устраивать какие-то технологические окна, на день что-то отключать, потому что в этом случае «встают» операции по всей России. Например, та же СБП доступна 24×7 365 дней в году, а зачисления средств с помощью сервиса происходят мгновенно.

Ну да, не будет оплаты по карте или переводов по СБП — сразу возникнет тьма проблем.

А. Г.: Безусловно. И, соответственно, это накладывает на нас определённые обязательства, в том числе по «кибербезу», потому что, как все мы знаем, «кибербез» влияет и на доступность.

Я услышал цифры про KPI по доступности — 99,999 %, — которые, конечно, говорят о том, что в таких значимых предприятиях невозможно ничего отключить, действительно невозможно сделать некое «окно обслуживания». Потому что предприятие важно для страны, для всей банковской отрасли, да и вообще в мире — если компания уже вышла на международный уровень и рынок. Здесь уже наблюдаются все признаки критической информационной инфраструктуры, КИИ.

А. Г.: Да, конечно. НСПК и создавалась для поддержания платёжного суверенитета Российской Федерации, поэтому можно сказать, что закон о КИИ создан как будто специально для нас. На самом деле это не так страшно, потому что компанию, по сути, строили с чистого листа в 2014 году — она довольно молода относительно других. Понимая, что компания строится для платёжного суверенитета, «хардверные», «софтверные» и прочие решения подбирали с учётом возможных ограничений, поэтому большинство используемых у нас решений соответствуют КИИ.

Кроме того, создать национальную платёжную систему и операционный клиринговый центр по платежам в РФ «из коробки» нельзя. Соответственно, когда создавалась НСПК, было сделано очень много своего софта. Он пишется и сейчас: у нас очень большая команда разработки.

Если посмотреть на те три составляющие бизнеса, которые были перечислены ранее — платёжная система «Мир», СБП и обработка операций по картам международных платёжных систем, — то какие ключевые риски с точки зрения кибербезопасности здесь возникают? С одной стороны, физически деньги не находятся у вас (как, например, у банка) и их нельзя украсть. С другой стороны, на первый план выходит та самая доступность и её обеспечение (нельзя, чтоб всё это «легло») — отсюда возникают ключевые риски.

А. Г.: На технологическом уровне я бы разделил на разные риски, на разные подходы к их минимизации и ликвидации. Но по факту у нас бывает два подхода: CP (Card Present, с предоставлением карты) и CNP (Card Not Present, без предоставления).

Риски понятны, поэтому если мы говорим про CNP, то тут используется MirAccept 2.0 — технология аутентификации для веба (так называемая 3D Secure); это, опять же, наша платформа. Когда вы оплачиваете что-то по российской карте в российском магазине, у вас всегда платёж будет идти через наш сервис (MirAccept 2.0). В любом случае (и CP, и CNP) используются только самые надёжные методы токенизации и аутентификации карты и её держателя.

Также у нас есть Сервис принятия решений. Он работает на основе анализа рисков (RBA) в сегменте операций e-com. Сервис анализирует большое количество данных при проведении держателем карты «Мир» операции в интернете (например, информацию о пользователе, его поведение и т. д.). Он направляет участникам вердикт с оценкой уровня доверенности операции и её обоснованием. Это необходимо для принятия решения, нужно ли дополнительно подтверждать проведение операции у держателя карты (например, направить ему SMS-сообщение с кодом или отклонить её) или можно провести операцию без этого.

На текущий момент этот сервис в среднем оценивает 1,2 млн аутентификаций в день. По результатам его работы в 2020 году 33 % аутентификаций были оценены как доверенные (при этом точность оценки составила 99,9989 %), а как высокорисковые — 1,3 % (с соизмеримой точностью оценки). В ПС «Мир» используются наиболее передовые технологии и алгоритмы, рисковая модель сервиса принятия решений производит оценку аутентификации используя более чем сто параметров (внутренних и внешних данных) и математических моделей.

Также у нас есть различные аналитические платформы, например система фродмониторинга. Она позволяет нам отслеживать и предотвращать различные мошеннические атаки на банки — участники ПС «Мир». С её помощью мы оперативно информируем банки о замеченной нами подозрительной активности по их картам или контрагентам.

По поводу антифрода хотелось бы уточнить: вам пришлось создавать свою систему, независимо от того, что есть на стороне коммерческих банков?

А. Г.: Да, задачи по антифроду мы решаем всё-таки другие. Как платёжная система «Мир» мы не занимаемся фродмониторингом каждой конкретной транзакции: это — обязанность банков, и это прописано в законе.

Но при этом нас в любом случае волнует уровень безопасности «Мира», потому что мы стремимся к тому, чтобы он был самым безопасным, и делаем всё для этого. Поэтому нам важно контролировать уровень фрода в каждом конкретном банке.

Банки на своём уровне борются с фродом, но нам важен высокий уровень безопасности каждой транзакции, поэтому мы дополнительно реализовываем ещё один уровень борьбы с фродом на стороне платёжной системы. Нам важно понимать, сколько фрода в каждом конкретном банке наблюдается по картам «Мир» — и эту задачу наш антифрод и решает. Нюанс — в том, что «коробочные» антифродовые решения действуют «потранзакционно», в нашем случае они не работают, поэтому у нас есть наше кастомное решение конкретно для наших задач.

Я видел на нескольких конференциях технические доклады от ваших специалистов по архитектуре, системам безопасности и по некоторым используемым технологиям — выглядит всё по-хорошему серьёзно (и сама концепция, и то, сколько там всего сделано и «наворочено», и сколько планировалось сделать — всё впечатляло). Если пробежаться по последним вашим достижениям, что можно особо выделить, «поставить в плюс» из задач, которые не просто важны для вас сейчас, а вообще никем не решались до вас в России?

А. Г.: Если говорить про «кибербез», то я бы отметил следующее: у нас есть внешний продукт, который мы сделали для банков, и несколько внутренних. Внешний — это CryptoMIR. Мы создали две платформы: CryptoMIR и CryptoMIR СБП. В банках (и у нас) очень много криптографии: всё взаимодействие банков с нами происходит с обширным её использованием. Это порождает огромное количество сертификатов, которые банки должны получать у нас. Банки должны следить за сроком их действия, выпускать и так далее. Это — большие операционные затраты для них, поскольку всю эту историю нужно поддерживать.

CryptoMIR — это, по сути, автоматизированная платформа, которая позволяет выпускать сертификаты без длительной переписки банков с нами, что упрощает ряд процессов. Есть веб-интерфейс, где банк может разместить запрос на выпуск сертификата. Система проверяет запрос на корректность по всем критериям, после чего сертификат автоматизированно выпускается в удостоверяющем центре и направляется инициатору. Плюс, как дополнительный бонус, в системе отслеживается срок действия сертификата. Если он скоро закончится, а банк не предпринял никаких попыток по перевыпуску, то мы заблаговременно банк об этом уведомляем.

Мы запустили платформу в конце прошлого года, сейчас начали активно подключать к ней банки. Для банков это абсолютно бесплатно. И позволяет, во-первых, снижать операционные затраты, а во-вторых, как раз не допускать того, чтоб у них что-то могло сломаться по причине «протухания» сертификата.

Вам пришлось всё это делать на алгоритмах шифрования по ГОСТу, получать лицензию ФСБ России на разработку?

А. Г.: Да, безусловно

Что касается антифрода: тут тоже бесконечная история, он постоянно «докручивается», я подозреваю?

А. Г.: Да, безусловно, такая работа ведётся и все мы понимаем, что она очень важна. Наверное, все видели, что Банк России делает большую работу для безопасности СБП и прикладывает всевозможные усилия для того, чтобы банки соблюдали требования — в том числе и на нас возлагает эту работу. Мы тоже занимаемся антифродом в СБП плюс контролируем то, как банки этим занимаются.

Из других проектов что-то ещё имеет смысл отметить?

А. Г.: Из внешних — нет. Но при этом у нас очень большая и сложная инфраструктура. Для того чтобы SOC (Security Operations Center, операционный центр безопасности) работал эффективно, площадь, которую он покрывает, должна быть максимально большой. За счёт того, что инфраструктура очень велика, у нас есть задача собирать огромное количество (миллиарды) всевозможных логов, коррелировать и обрабатывать их. Это — очень сложная задача. Какие-то «коробочные» решения используются, но у нас — большая, сложная, кастомная история для SOC. Хочется отметить, что в прошлом году мы объединили и автоматизировали всё, что связано с добычей и получением логов, и появился наш Security Data Lake (как бы пошло ни звучало, это — Big Data, куда сливаются все логи и где они первично обрабатываются). Кажется несложным, но на таком количестве данных это — задача совсем другого уровня, которую как раз удалось решить. В прошлом году решение было разработано и в целом сейчас очень активно используется.

А SOC вы изначально запланировали строить самостоятельно или были какие-то попытки использовать аутсорсинговый SOC? И почему история с аутсорсингом вам не подошла?

А. Г.: SOC — полностью наш. Почему не аутсорс? На самом деле, вопрос хороший. Объёмы журналов и тот уровень безопасности, которые есть у нас, очень сложно соединяются с коммерческим SOC, поэтому такой задачи мы перед собой не ставили и решаем это своими силами (я думаю, ничуть не хуже).

Вам пришлось строить SOC преимущественно на отечественных продуктах и технологиях? Или вы используете какие-то зарубежные компоненты в своём SOC, вследствие того что нет российских аналогов?

А. Г.: Мы используем много отечественного софта, плюс у нас очень много Open Source.

Для своей разработки используете опенсорс?

А. Г.: Да, в том числе и для SOC. У нас половина SOC, в принципе, на Open Source, а остальное — то, что мы сами писали.

Этой весной у нас было несколько интересных эфиров AM Live, где мы в том числе активно обсуждали тему DevSecOps. Я полагаю, что тема непрерывной безопасности цикла разработки вам тоже должна быть близка. Вы же не можете отключить какие-то сервисы, разработку нужно вести. Эта концепция очень хорошо соответствует вашим процессам.

А. Г.: По поводу DevSecOps — для себя за всё время я бы выделил несколько тезисов, которые я понимаю благодаря тому опыту, который приобрёл.

Первое: современные подходы к управлению и разработке (a DevSecOps на них завязан) — это в первую очередь гибкие методологии. Частый выпуск релизов требует нового подхода к обеспечению безопасности приложений. Необходимы всеобъемлющее внедрение автоматизации и инкрементальный анализ, потому что если ждать релиза, то мы ничего не успеем.

Второе — это тоже боль, и все это осознают, — команда безопасности не может расти одновременно с командой разработки. Соответственно, нужно повышать качество работы, автоматизировать, вводить выборочные проверки и, самое главное, риск-ориентированный подход. Даже в одной компании создаются продукты с разным негативным «импактом», и поэтому уровень безопасности должен коррелировать с уровнем критической значимости. Как мне кажется, чтобы эффективно работать, необходимо внедрять риск-ориентированный подход.

Должно быть, для вас становится очень актуальной задача контроля исходного кода, в том числе открытого, в рамках DevSecOps? В конце концов, нужно обеспечивать его неизменность и целостность, контролировать количество присутствующих и возникающих в нём уязвимостей — ведь их постоянно обнаруживают. Эти задачи вы тоже каким-то образом автоматизировали?

А. Г.: Да, конечно. Во-первых, к Open Source (как и к собственному коду) нужно относиться как к некоему недоверенному источнику. Поэтому, когда мы куда-то внедряем опенсорс, его нужно проводить через те же самые проверки, через которые мы «прогоняем» внутренний код.

С точки зрения автоматизации и автоматизированных проверок — кажется, рынок давно устоялся, в первую очередь это SAST и DAST, статический и динамический анализ кода. Безусловно, есть автоматизированные решения, которые проводят эти проверки; но это — лишь половина проблемы, потому что их нужно тонко настраивать: по умолчанию, «из коробки», они дают очень много ложных срабатываний. Поэтому в любом случае вокруг SAST и DAST наращивается некая система (уже самописная), которая как раз позволяет ликвидировать эти ложные срабатывания, помечать их, если они уже были, и контролировать исправление найденных уязвимостей. Безусловно, у нас разработана своя платформа для этих целей.

Третье, немаловажное, — это некая кросс-проверка. Мы молодцы, но нужно себя проверять. Поэтому у нас есть регулярные тестирования на проникновение, когда мы полностью просматриваем свою инфраструктуру, и к тому же сейчас мы внедряем Red Teaming: по сути, у нас идёт беспрерывный пентест, который как раз даёт нам возможность быть уверенными, что мы — в безопасности (не потому, что мы так считаем, а потому, что так оно и есть).

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

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

Поэтому всевозможные секреты очень часто оказываются в хардкоде. И это — очень плохо, потому что, во-первых, это — ещё один вектор атаки, а во-вторых, к сожалению, иногда исходные коды той или иной компании (и мировая практика это много раз демонстрировала) по вине разработчика или третьих лиц попадают в публичный доступ и эти секреты выходят наружу.

Поэтому задачу нужно решать двумя способами. Первое — нужно дать внутренний сервис, «секретницу», в которой можно безопасно и удобно хранить эти секреты. У нас это используется и максимально везде внедряется. Второе — это опять же кросс-проверка, которая удостоверяет, что секреты не попадают куда не следует. Там есть специальные средства, с помощью которых мы делаем так, чтобы секреты не попадали в наши внутренние репозитории. Такая работа ведётся давно и кажется довольно успешной.

Продукты класса SСA — Software Composition Analysis — умеют обнаруживать заимствование кода. Мы, допустим, используем компоненты Open Source; где и какой код у нас в модулях применяется, где и какие части у нас заимствуются — с помощью SCA все эти внутренние зависимости можно отслеживать. Если обнаруживается уязвимость в одном из компонентов Open Source или нашего внутреннего продукта, то мы сразу понимаем, какие решения это затрагивает и что нам нужно в первую очередь править.

А. Г.: Такое решение у нас тоже кастомное, которое мы делали сами. Мы разворачивали довольно большую платформу управления уязвимостями, в хорошем смысле этого слова, то есть это — и про разработку, и про эксплуатацию (я имею в виду уязвимые компоненты на серверах).

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

С другой стороны, мы берём актуальные опубликованные уязвимости CVE. Опять же получается две истории: первая — интеграция с коммерческими и некоммерческими продуктами, которые поставляют CVE, вторая — наш Threat Intelligence, который мы проводим в ручном и автоматическом режиме, чтобы получать эти всевозможные CVE.

В итоге, когда у нас есть граф того, как мы выглядим и из чего состоим, это в каждый момент времени даёт нам понимание того, что у нас не безопасно, какие риски это за собой несёт и так далее.

Выше вы говорили про собственное «озеро данных» для кибербезопасности. Получается, что у вас есть база для использования такой перспективной концепции, как XDR — расширенное обнаружение угроз и реагирование на них. Как вы смотрите на это направление? Насколько оно, с вашей точки зрения, интересно и перспективно?

А. Г.: Detection and Response, продукты наподобие Kaspersky EDR? Мы про это говорим?

Да, Kaspersky Endpoint Detection and Response (KEDR), плюс у них есть платформа Kaspersky Anti Targeted Attack (KATA). Но XDR — немного более широкая концепция, которая предполагает, что мы можем для пополнения Data Lake подключать какие угодно источники данных: это могут быть и почтовые серверы, и веб-шлюзы, и любые другие совершенно уникальные системы. Потом все эти логи мы можем определённым образом анализировать и ядро XDR будет находить там аномалии, быстро сужать задачу для команды SOC. Идея — в этом, насколько я её понимаю.

А. Г.: Решение такого класса мы уже используем. Я даже больше скажу: мы уже давно перешли от анализа индикаторов компрометации к анализу векторов, то есть мы раскладываем и анализируем угрозы по матрице MITRE; всё это давно реализовано, для этого Data Lake и создавался.

С точки зрения внедрения того или иного продукта — тоже хорошая история, потому что продуктов на рынке очень много, а времени все их пробовать, к сожалению, нет. Поэтому как раз для этого мы развернули внутри НСПК лабораторию кибербезопасности — место, где мы можем тестировать различные решения, как новые, так и те, которые у нас уже есть. Например, в песочнице мы тестируем, насколько правильно, хорошо и эффективно работают правила Web Application Firewall. Есть специальные генераторы, с помощью которых мы пытаемся «поломать» WAF и пройти дальше, плюс ведётся аналогичная работа вручную.

Есть требование Банка России, согласно которому все банки должны перейти на ГОСТ TLS в СБП в следующем (2022-м) году — а это нетривиальная задача. Песочница позволила нам максимально быстро проанализировать все решения, которые есть на рынке, с точки зрения ГОСТ TLS. Опять же оказывают своё влияние «пять девяток» — у нас были довольно сильные требования к решению, нужно было найти оптимальное для себя и уже сейчас попробовать внедрить его. Такого уровня задачи мы тоже решаем.

Идея про лабораторию кибербезопасности мне понравилась — тестирование всего интересного, что появляется на рынке, у себя в песочнице. Правильный, взрослый подход.

А. Г.: Да, по сути, она представляет собой отчуждённый сегмент сети, у которого своя безопасность, и он «живёт» отдельно от основной инфраструктуры. Это позволяет максимально быстро развёртывать разные решения без лишних препон, и туда же можно приглашать вендоров, если они сами хотят разворачивать.

Действительно, это — не такая сложная и масштабная задача, но эффективности она принесла, как ни странно, очень много.

Хотелось бы уточнить про обеспечение бесперебойности работы. Насколько сложной оказалась эта задача на практике и как её пришлось решать?

А. Г.: Если говорить про надёжность и бесперебойность в целом, то, безусловно, они являются особыми архитектурными решениями, которые используются при разработке программ. Также это — многократные резервирования, как с точки зрения софта, так и с точки зрения «железа». И, как я уже сказал, на надёжность и бесперебойность влияет «кибербез». Как показала практика многих лет, эту задачу мы решаем хорошо. Чтобы в компании было достаточно безопасно для обеспечения этого уровня доступности и надёжности.

Мы почти ничего не сказали про платёжную карту «Мир». Я понимаю, что в целом это — очень интересный проект, и сам по себе, и с точки зрения кибербезопасности. Потому что нужно было учесть опыт платёжных зарубежных систем и сделать чуть лучше. Я как раз хотел понять: есть ли какие-то отличия ИБ платёжной карты «Мир» от зарубежных аналогов?

А. Г.: Вопрос в одно и то же время и сложный, и лёгкий. Я не хочу сейчас уходить в обсуждение EMV-чипов — это довольно сложная область со своими нюансами, и, наверное, это ни к чему. Но вот самое главное (как бы забавно это ни звучало): безопасность, когда мы говорим про «пластиковый» бизнес, — это комплаенс-история. Все эти стандарты (PCI DSS и прочие) были написаны довольно давно, плюс у нас есть внутреннее законодательство. И как раз эшелонирование на его уровне позволяет нашим российским решениям быть ещё безопаснее, потому что комплаенса больше. Это тянет за собой технологическую историю про необходимые уровни криптографии, про алгоритмы, которые используются, и так далее.

Финансовая история с картами, с «пластиком» — очень консервативная, очень старая, уже давно всё было написано (к сожалению, многое — «кровью») для того, чтобы процесс был безопасен.

Спасибо! Желаю успехов!