Intelligent Enterprise: Насколько выросли требования бизнеса по адаптации к изменениям? Что грозит тем, кто «не успел»?
Райнхольд Вохнер: В последнее время цифровые технологии очень активно развиваются и быстро внедряются. Появляются и новые, базирующиеся исключительно на их использовании бизнес-модели. Наиболее красноречивые примеры тут — Uber и Airbnb, но их количество постоянно растет, в том числе и в финансовой сфере. Конечно же при внедрении этих решений необходимо соблюдать требования информационной безопасности.
Стоит учитывать и то обстоятельство, что развитие технологий в разных странах происходит неравномерно, даже если у них общее прошлое. И мы, работая на государственных территориях, возникших при распаде СССР или Югославии, постоянно с этим сталкиваемся. В Боснии, например, очень слабо развита культура карточных платежей и мобильного банкинга, тогда как Словения, также бывшая югославская республика, входит в число передовых стран по проникновению этих сервисов.
Но все же те, кто «не успел», рискуют как минимум получить серьезные проблемы. Так, одно из крупнейших в Австрии риелторских агентств не оценило вовремя Интернет как важный канал коммуникаций с клиентами. Они не ушли с рынка, но в значительной степени растеряли свой потенциал. Бывают, однако, и исключения. Скажем, некоторые старые отели демонстрируют свою эксклюзивность тем, что не позволяют забронировать номер через Интернет. Но спрос на номера в этих отелях очень велик, и стоит задача не привлечь новых клиентов, а скорее отсечь потенциально проблемных. Однако если так будут действовать гостиницы и гостиничные сети, ориентированные на массового клиента, то их не ожидает ничего хорошего.
Часто ли ИТ являются препятствием для развития компании?
Всё зависит от профиля компании и принятой в ней мотивации. Если это коммерческий ЦОД, где всё корректно работает по установленным правилам и при этом никаких дополнительных требований не предъявляется, то новые технологии здесь не только не смогут ни в чём помогать, но наоборот, будут даже мешать нормальной работе. А если перейти на другую сторону баррикад, то есть к компаниям, которые пользуются услугами внешнего ЦОДа, особенно когда речь идет об облачной модели, то тут всё меняется. И нам останется лишь поддерживать безопасность новой инфраструктуры. Но это не даст никакого эффекта, если сотрудники и руководители не поймут, что переход в облако будет способствовать развитию бизнеса. В таком случае возможно и сопротивление со стороны ИТ-отдела, поскольку это означает как минимум его серьезное переформатирование.
Как быстро меняется ситуация с угрозами в банковской сфере?
Сейчас банки интенсивно «оцифровываются». Процесс этот начался с появления систем дистанционного банковского обслуживания, использующих публичный Интернет, а в последнее время и мобильные устройства.
Но вещи, повышающие удобство для пользователя, часто создают проблемы для банка. И не успев внедрить адекватную защиту новых технологий, вы очень сильно рискуете.
Раньше у банков было несколько недель для того, чтобы внести необходимые изменения, протестировать полученную инфраструктуру и исправить замеченные ошибки, чреватые дальнейшими проблемами (например, переместить приложение на другой сервер). Теперь же пользователь рассчитывает, что банк решит все проблемы в течение суток. И если проблему решить не удается, то следуют серьезные санкции. Примеры тому уже есть. В течение этого года были оштрафованы на весьма чувствительные суммы целый ряд итальянских и германских банков.
Но и сам пользователь должен думать о безопасности. Не стоит «засвечивать» свою карту на явно ненадежных сайтах. Ну а требование назвать PIN-код карты — это и вовсе однозначный симптом того, что ресурс является мошенническим. Соблюдать осторожность необходимо при выходе в Интернет через незащищенную сеть Wi-Fi.
С другой стороны, банки должны вводить какие-то меры по защите мобильных платежей. Например, блокировать работу мобильного приложения, если на смартфоне или планшете обнаружено вредоносное ПО. Большинство банковских мобильных приложений не удастся установить на устройство с джейлбрейком или с правами суперпользователя. Хотя тут многое зависит от законодательства той или иной страны.
Нередко совместно с банковским приложением устанавливается еще и антивирус. Хотя и тут нужна осторожность, связанная с глобализацией. Ведь пользователи, для которых язык такого приложения не родной, могут испытывать, мягко говоря, дискомфорт. Мне самому пришлось столкнуться с приложением одного из китайских банков, которое принудительно установило дополнительное ПО, сканировавшее мой телефон. А я не знаю китайского и не понял, что именно делает это приложение. Должна быть гарантия, что такое ПО не нарушит законодательство той страны, где проживает владелец счета. Да и одно только антивирусное ПО может оказаться бесполезным, поскольку атаки на мобильные устройства все чаще становятся многовекторными.
Еще одной мерой являются ограничения на размер платежей, проводимых по дистанционным каналам. Вполне возможно, что крупные платежи, например, связанные с куплей-продажей недвижимости, придется проводить традиционным способом и никак иначе. Тут речь идет о больших деньгах, и риски вмешательства некоей третьей стороны необходимо всячески минимизировать. В случае меньших сумм такие риски принять уже можно. Карл Сумманен, вице-президент российского банка ВТБ, на конференции BISS ‘2016 высказался примерно в том же ключе.
Как добиваться высокого уровня информационной безопасности в условиях постоянных изменений? Есть ли у вас какой-то опыт?
Сотрудникам подразделений информационной безопасности, а их в нашей группе шестнадцать, приходится постоянно взаимодействовать с архитекторами, разработчиками новых финансовых сервисов, а также с теми, кто отвечает за работу с поставщиками и регуляторами. Принято считать, что защищаться нужно на все сто процентов, а значит, хорошая безопасность должна быть дорогой. Но такой подход по вполне понятным причинам не находит понимания. Как и то, что служба ИБ часто задает много вопросов, задерживая выполнение проектов.
Мы накопили определенный опыт в том, как вписать информационную безопасность в процессы банка. Активно используем в своей работе методологию управления проектами SCRUM. Именно ее применение позволяет нам гибко и быстро реагировать на изменения. Пока мы используем эту методологию в трех странах нашего присутствия, но их количество будет расширяться. И Россия входит в число тех, где внедрение произойдет уже в самом ближайшем будущем. Насколько мне известно, соответствующие работы уже идут.
Обычно создание ПО проводится по цепочке планирование — разработка — тестирование — развертывание. Все работы при традиционном подходе занимали довольно длительное время, где-то около месяца или даже больше, и у департамента ИБ было достаточно времени, чтобы контролировать процесс. Но сейчас бизнес требует резкого сокращения сроков разработки. Иногда на это дают лишь два дня. И если в таких условиях ИБ-служба будет работать так же, как привыкла, то об успехе говорить не приходится.
Прежде всего нам необходимо понять подход SCRUM. В нем есть собственник продукта, который планирует его разработку. И тут важно выстроить взаимодействие ИБ-служб с архитектором, или SCRUM-мастером, который обеспечивает связь между разработчиками и собственником продукта. Мы должны обучить SCRUM-мастера и постоянно быть с ним в контакте. Таким образом можно добиться того, чтобы вопросы безопасности решались на уровне владельца продукта, а не кого-то еще.
В команду SCRUM обычно входит от четырёх до девяти человек, которые отвечают за разные направления. При этом необходимо добиться, чтобы среди них был инженер по безопасности. Постановка проблем, связанных с поддержанием безопасности в сервисах и приложениях, обязательно должна быть доведена до исполнителей. А при формировании соответствующих задач для разработчиков нужно использовать понятный им язык. Иначе высокая скорость работы может просто убить всё, что связано с поддержанием безопасности.
Методология SCRUM очень прозрачна, и этим она мне нравится. Мы видим, что сделано и как получить выгоду от этого. Ведь в коллективах разработчиков очень часто нет ясного понимания того, кто чем занимается. А использование SCRUM дает уверенность, что всё делается в соответствии с планом.
Тем самым разработчики и служба ИБ работают в партнерстве, подпитывая друг друга информацией. Руководитель ИБ-департамента лучше понимает происходящее, и все говорят на одном языке. При этом решение обратной задачи — донести до разработчиков требования ИБ — тоже дает хороший результат. Иными словами, безопасность органично вплетается в повседневную деятельность разработчиков и сохраняются высокие темпы создания новых приложений и сервисов, как того требует подход agile.
Но это ещё не всё. ИБ-служба сама должна предлагать инструменты автоматизации для решения определенных задач. Например, у нас в Австрии действует сложная директива оценки паролей, согласно которой требуется проводить вычисления по довольно громоздкой модели. Однако использование механизмов автоматизации сильно упрощает эту задачу. Возможно автоматизировать и построение модели угроз.
В работу необходимо вовлекать и руководство бизнеса. Это касается как высших руководителей, так и глав линейных бизнес-подразделений. Они тоже используют инструменты agile, в частности SLIM и 6Sigma, которые им позволяют лучше контролировать ситуацию в компании, а нам — оценить, насколько эффективно мы работаем, причем во вполне объективных показателях.
Какие угрозы несут в себе fintech- и blockchain-технологии, которые очень быстро набирают популярность?
Fintech — отличная штука, и с соответствующими компаниями надо сотрудничать. Равно как и с разработчиками систем для Интернета вещей. Поэтому следующий год будет очень непростым, ведь нам придется приложить немало усилий для того, чтобы быть более гибкими и подготовленными. Эти технологии дают большие возможности, но при этом чреваты многими «детскими болезнями».
Blockchain весьма интересна с технологической точки зрения. Я сам буду пристально следить за ее развитием. Да, с ее помощью можно проводить анонимные платежи, какое-то время оставаясь незамеченным. Но сейчас сложно укрыться от разного рода аналитических систем, анализирующих поведение. Так что насколько долго можно будет оставаться «ниже радаров», абсолютно неизвестно. Именно поэтому многие компании отказываются от поддержки blockchain. Особенно в свете того, что злоумышленники уже научились взламывать некоторые реализации этой технологии.
Однако у нее есть потенциал, связанный с увеличением скорости прохождения платежей. Не так давно компания SAP продемонстрировала, как за пятнадцать минут провести платеж, для осуществления которого раньше требовалось не меньше трех бизнес-дней. Не исключено, что этот потенциал будет востребован совсем в других отраслях, например, в здравоохранении.
В группе Raiffeisen давно используется ITIL/ITSM. В какой степени это помогает вам в реальной работе?
Использование подходов ITIL/ITSM на первый взгляд практически незаметно. Но так происходит до того момента, когда случается какой-то форс-мажор, на который необходимо быстро отреагировать. И тут данные методологии помогают, причем помогают хорошо. Особенно если нужно обеспечить взаимодействие разных структурных подразделений. Эти вопросы закрываются всяческого рода регламентами и процедурами, в отсутствие которых требовалось бы множество согласований, отнимающих очень много времени, а время, как известно, — весьма критичный ресурс. Очень полезна ITSM и в тех случаях, когда стоит задача добиться полной прозрачности в понимании того, что каждый из нас делает. Это дает возможность устранить бреши и оптимизировать потенциальные узкие места. Наконец, ITIL/ITSM так же, как и некоторые agile-инструменты, позволяет нам говорить на языке бизнеса.
Роль регулятора. Каким его хотелось бы видеть?
Здесь опять же всё зависит от специфики каждой конкретной страны. Ведь везде установлены разные требования и разный уровень их детализации. Но если регулятор выполняет свои функции хорошо, то это только облегчает жизнь банкам. Меньше всего проблем с регуляторами отраслевыми, такими как консорциум PCI DSS. Там есть стандарты с четко прописанными требованиями, которые абсолютно понятны. По такому же пути идут и многие государственные регуляторы, например, в Польше. Хотя иногда на согласование каких-то моментов уходит довольно много времени.
Так что обычно всё сводится к тому, что есть требование, которое надо выполнить, и есть меры, которые необходимо принять, чтобы этому требованию соответствовать. Часто регуляторы, в той же Польше или в Сингапуре, очень жестко требуют соблюдения установленных ими нормативов, и пренебрежение здесь может привести к отзыву лицензии. Так что нужно эти требования понимать и прописать, каким образом можно добиться соответствия им.
А в некоторых странах есть и не очень положительная практика взаимоотношений с регуляторами. Переговоры ведутся долго, а вот требования и конечные цели совершенно не очевидны, а значит, непонятно, как им соответствовать.
И снова agile помогает нам выстроить взаимоотношения с регуляторами. Мы можем, например, консолидировать необходимую информацию в одном защищенном хранилище. А затем посмотреть эту информацию — разные её пласты, разные уровни, под разными углами и обменяться ею по защищенному каналу. Этот же канал можно использовать для связи с поставщиками или аудиторами. И никто из них не будет иметь доступа к основному массиву наших систем.
Интервью у Райнхольда Вохнера взял научный редактор Intelligent Enterprise Яков Шпунт
