24 апреля, 2017, BIS Journal №2(25)/2017

Партнерство с бизнесом и Agile


Янсон Иван

бизнес-партнер по информационной безопасности (ПАО Сбербанк)

Новые инструменты кибербезопасности

Продолжаем публикацию цикла материалов об изменениях в работе Службы кибербезопасности ПАО «Сбербанк России». На вопросы BIS Journal отвечает Иван Янсон, бизнес-партнер по информационной безопасности ПАО «Сбербанк России».
 
СБЕРБАНК – ЭТО МАСШТАБ

BIS Journal: Ваш большой опыт работы в сфере информационной безопасности банков дает Вам возможность и право сравнивать. Чем Служба кибербезопасности Сбербанка отличается от служб безопасности других финансовых структур?

И.Янсон: В первую очередь масштабностью, большим многообразием и высокой специализацией выполняемых функций. Следствием этого является наличие редких и даже уникальных подразделений в его составе.  Наиболее заметные – это Центр киберзащиты (CDC), Дирекция по управлению программами кибербезопасности, а также Центр обеспечения взаимодействия с бизнесом, в котором работают бизнес-партнеры по информационной безопасности. Все эти подразделения по-своему уникальны, аналоги не часто встречаются, например, я не слышал о том, чтобы в каком-то банке было подразделение, похожее на Центр взаимодействия с бизнесом.

МНОГО НОВОГО

Наименования других подразделений Службы более привычны для уха безопасника, но это не означает, что за этими названиями не стоит ничего нового. Например, отдел информационной безопасности в ИТ-проектах. Подобные подразделения или, по крайней мере, отдельные специалисты такой направленности, есть во многих банках, но мало где это подразделение участвует в обеспечении ИБ почти на всех стадиях жизненного цикла автоматизированных банковских систем (АБС). В Сбербанке же отдел ИБ в ИТ-проектах участвует и при проектировании, и при разработке, и на стадии приемки в эксплуатацию – на приемо-сдаточных испытаниях АБС. Свыше 30 сотрудников закладывают элементы подсистемы ИБ в многочисленные АБС Банка, участвуя в сотнях ИТ-проектов в течение года. Они закладывают требования ИБ в бизнес-требования, концептуальные архитектуры, проверяют выполнение этих требований в спецификациях и технических заданиях, контролируют реализацию при приемке систем в эксплуатацию. В каком-то смысле, это фабрика информационной безопасности, как в плане непрерывного участия в ИТ-проектах, так и в плане масштабности работы.

BIS Journal: Расскажите, пожалуйста, подробнее о структуре, которая занимается взаимодействием с бизнесом…

И.Янсон: Сотрудники, работающие в Центре обеспечения взаимодействия с бизнесом, называются бизнес-партнерами по информационной безопасности. Их основная функция – быть своего рода коннекторами между бизнесом и подразделениями ИБ, причем, коннекторами, призванными ускорять, улучшать это взаимодействие в обоих направлениях, как от безопасности к бизнесу, так и от бизнеса к безопасности.

БИЗНЕС-ПАРТНЕР – НЕ ПЕРЕВОДЧИК

Что это означает? Многие, когда слышат слова «бизнес-партнер», думают, что речь идет о сотрудниках, которые должны переводить требования безопасности с языка безопасности на язык бизнеса. На самом деле, переводить никому ничего не нужно. Бизнес-подразделения и ИТ-подразделения, внедряющие бизнес-продукты, как правило, достаточно хорошо понимают необходимость обеспечения безопасности и неплохо разбираются в способах и средствах ее обеспечения. Конечно, иногда приходится выполнять и роль «переводчика», но это не основная функция бизнес-партнера. Основная – ускорение взаимодействия безопасности и бизнеса.

Как уже говорилось, в Сбербанке ведутся сотни проектов, требующих доработок ИТ-систем. Есть бизнес-подразделения и ИТ-подразделения, которые вовлечены в такие проекты. Есть линейные подразделения ИБ, которые обеспечивают наличие подсистемы безопасности в рамках таких доработок. Во взаимодействии указанных подразделений иногда возникают сложности, например, с очередностью участия специалистов Службы кибербезопасности в ИТ-проектах. И тут бизнес-партнер, хорошо понимая потребности бизнеса, выстраивает приоритеты при решении соответствующих задач, помогает выполнить их более оперативно. Приоритет запросов может определяться плановыми датами открытия проектов, датами включения доработок в плановые интеграционные релизы, сроками запуска банковских услуг и продуктов, которые могут быть не известны сотрудникам безопасности. Чтобы повысить приоритет того или иного запроса необходимо согласовать его с заказчиками других доработок, с которыми приходится меняться местами, что бывает непросто в ситуации недостаточного ресурса. 

Сложности могут возникать не только с медленной обработкой запросов. Время от времени возникает ситуация, когда требования моих коллег вызывают неполное понимание со стороны заказчиков. Эти требования могут быть или сложно выполнимыми, или затрудняющими быстрый ввод
в эксплуатацию продуктов, или вовсе запретительными по отношению
к внедряемым бизнес-продуктам. В таких случаях бизнес-партнер погружается в суть проекта, разбирается в том, что же требуют его коллеги из безопасности, и что мешает, вызывает проблемы у бизнеса. Для устранения проблемы бизнес-партнер может предложить постоянные или временные альтернативные решения, организовать совместный поиск таких решений силами безопасности и бизнеса. Иногда приходится вести и разъяснительную работу, чтобы коллеги поняли, почему нельзя не внедрять те или иные защитные меры и механизмы, чем чревато их отсутствие.

Кроме того, важной задачей бизнес-партнера является оказание помощи коллегам-безопасникам в продвижении решений информационной безопасности и в эскалации проблем. Чаще всего это бывает при необходимости устранения тех или иных уязвимостей. Необходимо донести до бизнес-подразделений сигнал об угрозах, реализовавшихся или возможных инцидентах, объяснить, какие это может иметь последствия для клиентов, Банка, договориться о выделении ресурса разработчиков, ускорении внедрения защитных мер. Линейным подразделениям кибербезопасности может быть сложно, а подчас просто некогда заниматься эскалацией проблем на руководителей бизнес-подразделений, и в этом мы, бизнес-партнеры, помогаем своим коллегам.

АЛЬТЕРНАТИВНЫЕ РЕШЕНИЯ

BIS Journal: Можете привести пример поиска альтернативных решений?

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

Такое решение позволит быстрее осуществить тестирование, а значит и внедрение ресурса и связанного с ним бизнес-продукта или услуги. В другом случае требование безопасности говорит о необходимости автоматизированной проверки электронной подписи под поступающими электронными документами. Но на период опытной эксплуатации на ограниченных объемах можно предложить использовать проверку ЭП силами клиентских менеджеров на их компьютерах, либо применить автоматизированную проверку, но не в целевой системе. А автоматизированную проверку в самой целевой системе реализовать на втором этапе при переходе к промышленной эксплуатации.

Отмечу, что часто для того, чтобы найти подходящее постоянное или временное альтернативное условие, бывает достаточно собрать причастных специалистов разных подразделений для совместного обсуждения вопроса. И здесь как раз роль бизнес-партнера состоит в том, чтобы, рассмотрев задачу в целом, созвать достаточный для коллегиальной выработки решения консилиум, состоящий из сотрудников ИБ разных специальностей. Кстати, даже при штатной работе это тоже бывает полезно, так как позволяет быстрее получить сводный результат в случаях, когда задействованы специалисты разных направлений ИБ.

BIS Journal: Вы говорили о сотнях ИТ-проектов. То есть у вас происходят какие-то серьезные изменения внутри банка?

И.Янсон: Количество ИТ-проектов не говорит о том, что происходят какие-то специальные изменения, просто Сбербанк живет очень динамичной жизнью. В каждом бизнес-блоке есть проектный офис, который ведет несколько десятков, а в крупных блоках даже более сотни проектов по автоматизации в год.  Каждый проект по автоматизации означает, что либо внедряется новый бизнес-продукт, либо меняется существующий. Перед бизнесом стоят весьма амбициозные задачи, его главный тренд – это всеобщая дигитализация продуктов, перевод их в дистанционные каналы. Очень активно все происходит, очень масштабно.

ПЕРЕХОД НА AGILE

Количество проектов по автоматизации, сроки ввода в эксплуатацию продуктов и сервисов продиктовали банку необходимость внедрения нового подхода по ведению доработок. Раньше доработки велись классическим проектным путем, который в Сбербанке носит название сквозного производственного процесса. Это, безусловно, хороший путь, но он не позволяет вносить много изменений в продукты. В ближайшие же годы банки будут конкурировать не между собой, а с такими современными ИТ-компаниями, как Google, Amazone, которые умеют очень быстро внедрять изменения в свои ИТ-платформы. Соответственно, мы должны идти с ними, как минимум, в ногу. Руководством Сбербанка был взят курс на внедрение гибкой методологии разработки - Agile.

BIS Journal: Методология управления проектами Agile стала трендом во многих сферах, и не везде ее понимают одинаково. Давайте уточним, что такое Agile в сфере ИБ?

И.Янсон: Agile в ИБ (да и в любой другой сфере) – это прежде всего эффективная практика организации труда, которая подразумевает гибкость организации команд, переход к коллаборативности (сотрудничеству и самоорганизации) сотрудников.
 
Внедряя методы Agile, Сбербанк преследует такие цели, как максимальная удовлетворенность клиентов, лучший клиентский опыт, непрерывные и быстрые улучшения продуктов и процессов за счет внешних и внутренних инноваций, уменьшение времени выхода продукта (Time-to-Market), добавление новой функциональности в продукт каждые две недели, повышение эффективности и продуктивности, а также удовлетворенности и вовлеченности персонала и т.д.

ИЗМЕНЕНИЯ

В рамках Agile-трансформации будут проведены масштабные изменения. От многоуровневой иерархической организации и согласований многих решений через руководство Сбербанк переходит к плоской структуре с тремя уровнями иерархии от Правления банка. Изменения становятся основой повседневной деятельности, они становятся децентрализованными, построенными на доверии, делегировании полномочий.

От организационно-функциональных колодцев банк переходит к применению кросс-функциональных команд и трайбов. От частичного вовлечения сотрудников в разные проекты к Full time работе в одной команде/над одной задачей, от так называемой водопадной модели работы и глобальных изменений с длительным процессом их подготовки к разработке Minimum Viable Product (MVP) – минимальной версии продукта либо новой крупной функциональности в нем, внедряемой для ранней обратной связи от клиентов. Создание MVP можно перефразировать так: «Не надо все и сразу, создавайте продукт инкрементально!».

СТРУКТУРА

В основе структуры Agile-организации Сбербанка лежат такие организационные единицы, как трайбы, команды и чаптеры.

Команда – это кросс-функциональная совместно работающая группа специалистов, обладающая всеми навыками, инструментами и полномочиями, достаточными для самостоятельной разработки конечного продукта. Численность команды – порядка 10 сотрудников. Трайб – это группа взаимосвязанных команд, сформированная вокруг определенного продукта/бизнес-цели и отвечающая за бизнес-результат. Численность трайба – не более 150 человек. Специалисты одной области компетенции из разных команд трайба объединяются в чаптеры.

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

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

Процесс работы над задачей или продуктом разбивается на спринты, которые длятся 2 недели. Спринты объединяются в суперспринты. Супеспринт длится ровно 12 недель и состоит из 6 спринтов.

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

ОБРАТНАЯ СВЯЗЬ

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

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



Аналогичная горизонталь вводится для бизнеса. Целостность каналов и продуктов обеспечивается Бизнес-горизонталью.

РОЛЬ БЕЗОПАСНИКОВ В AGILE

Agile также потребует от безопасности более гибкого участия в создании продуктов и услуг. Специалисты по ИБ выполняют роль экспертов предметной области. Они привлекаются к работе трайбов по мере необходимости получения экспертизы по вопросам информационной безопасности. Они могут привлекаться в команду, как временные участники с загрузкой 100% или с меньшей загрузкой. В первой волне Agile-трансформации, которая продолжалась до февраля этого года, участвовали 8 трайбов, сфокусированных на макропотребностях клиента, и 1 платформенный трайб. В эти трайбы входили сотрудники отдела информационной безопасности в ИТ-проектах. Часть своего времени они проводили в Agile-командах, а часть – работали по привычной схеме в офисе.

В перспективе большая часть ИБ-специалистов Сбербанка перейдет на такой режим работы. Участие с их стороны в работе команд требуется достаточно часто, так как изменения в продукт будут вноситься быстро (напомню, что инкремент продукта выпускается по окончании каждого спринта, MVP должен внедряться не реже одного раза в течение суперспринта). При этом появляется задача организации процесса поддержания уровня компетенции у сотрудников ИБ. То есть время от времени специалистов ИБ надо будет «выдергивать» из трайба и отправлять на внутреннюю или внешнюю учебу/инструктаж.

В целом, обеспечение требований ИБ на стадиях разработки АБС Банка, выполняемой по методологии Agile, – это довольно интересная задача для информационной безопасности, к решению которой мы уже приступили в ряде проектов Банка. По мере приобретения практического опыта мы готовы поделиться им с читателями BIS Journal. 

 

Смотрите также

Подпишись на новости!
Подписаться