Для обеспечения кибербезопасности в проектах Sbergile (методология гибкой разработки Сбербанка) введена соответствующая роль — эксперт предметной области, или ЭПО по кибербезопасности, или просто ЭПО. На ЭПО возложена непростая, но очень интересная задача — обеспечивать кибербезопасность там, где она никак не обозначена. Напомним, что в главном документе Agile — «Манифесте гибкой методологии разработки ПО» (англ. Agile Manifesto) нет ни одного слова про обеспечение безопасности. Однако учитывая, что в Манифесте заложена ценность личного общения, деятельность ЭПО начинается со знакомства с командами.
Знакомство
Вам будет интересно:Как сделать общественную точку доступа
Первая встреча команды и ЭПО очень напоминает встречу двух миров, двух вселенных или, как минимум, двух мировоззрений. На стороне agile-команды — скорость, инициатива и желание создавать. На стороне ЭПО — требования регуляторов, знание и умение выявлять и чувствовать потенциальные риски, а также опыт реализованных рисков. Чтобы наладить эффективную работу, необходимо перекинуть между этими «мирами» мост. Причем мост должен строиться с обеих сторон — и со стороны команды, и со стороны ЭПО. Только совместными усилиями возможна успешная интеграция кибербезопасности в проекты Agile.
Вам будет интересно:Как сделать сетевое хранилище из роутера Netgear
Выстраивание взаимоотношений с командой требует от ЭПО не только отличного знания требований кибербезопасности и основных инструментов их выполнения, но и обладания навыками дипломатии и передачи знаний. При взаимодействии с командой одной из самых важных компетенций ЭПО становится умение работать с бизнес-процессами, проводить экспресс-оценку риска и критичности этих процессов. Одним из ключевых параметров эффективности работы команд является «срок вывода продукта на рынок» (Time To Market) и, следовательно, ЭПО не должен быть замедляющим, а уж тем более блокирующим фактором, понижающим эффективность команд. ЭПО необходимо научиться жить в той же парадигме, что и команде, понимать ее потребности, желания и цели, при этом не в ущерб кибербезопасности и эффективности мер защиты.
Вам будет интересно:Итог 2017 года: искусственный интеллект больше не волшебная палочка
Именно поэтому ЭПО не готовят в вузах, нет курсов повышения квалификации ЭПО, до ЭПО нужно дорасти, пройти «огонь, воду и медные трубы». Только обладая опытом, как в профессиональном, так и житейском плане, ЭПО может стать полноценным участником команды, ее союзником. Диалог со всеми участниками рабочей группы позволяет оперативно подключаться к сложным участкам, понимать проблемы, с которыми сталкивается команда. ЭПО следует всегда помнить, что продукт реализуют простые программисты, и от того, насколько они погружены в проблематику кибербезопасности, зависит качество и безопасность выпускаемого продукта.
Общий язык
Первая проблема, с которой приходится столкнуться ЭПО при общении с командой, — терминология. Методология Agile насыщена специализированными понятиями, и в них необходимо разбираться. Например, следует понимать, чем «эпик» отличается от «фичи» и как с ними соотносится пользовательская история. Без общего языка разговор с командой будет сложным, а порой и невозможным.
Начнем с команды Agile. Команда Agile — это кросс-функциональная совместно работающая группа специалистов, обладающая всеми навыками, инструментами и полномочиями для самостоятельной разработки действующего продукта.
Лидером команды является владелец продукта (Product Owner), он отвечает за своевременный выпуск качественного и безопасного решения, соответствующего потребностям клиента. Кроме того, он определяет требования и задачи команды.
За эффективность рабочего процесса, выстраивание взаимодействий с другими командами и подразделениями отвечает участник команды с ролью скрам-мастер. Организация взаимодействия с ЭПО тоже в его зоне ответственности.
Вам будет интересно:Как безопасно подключиться к публичной сети Wi-Fi
Деятельность команды по созданию и развитию продукта можно условно назвать процессом реализации эпиков продукта. Эпик — это описание клиентского опыта с продуктами или сервисами банка (описание инструмента или логически обособленного набора функций). Эпики используются для описания абстрактных, еще не изученных идей, которые при проработке разбиваются на фичи.
Фича — описание одной из составляющих клиентского опыта с продуктами или сервисами банка (описание одной из составляющих инструмента или набора функций). В свою очередь, фича делится на пользовательские истории (User Story).
Пользовательская история — пример цельного клиентского опыта с продуктами или сервисами команды (набор элементарных компонентов функции или инструмента). Пользовательская история формируется по шаблону «Я как [категория клиентов/пользователей] могу [описание функциональности], чтобы [описание желаемого результата]».
Эпики, фичи и истории не имеют формальных границ. Порой бывает сложно определить, где заканчивается описание эпика и начинается описание фичи или пользовательской истории. Одна и та же формулировка может являться эпиком, фичей, или историей в зависимости от сложности исполнения.
Следующий важный вопрос — жизненный цикл разработки Agile. Понимание жизненного цикла позволяет ЭПО гибко влиять на процесс разработки.
Начинается все с этапа формирования идеи. Сырая идея обсуждается командой. Когда идея сформирована, она фиксируется в виде эпика в списке задач команды (бэклоге). Это необходимо для того, чтобы все участники команды понимали, что именно им предстоит сделать, к какому результату они идут. Чтобы задачи были взяты в работу, необходимо провести планирование спринта. Это этап работы команды, в ходе которого создается новая версия продукта (обычно 1–2 недели). Дальше необходимо провести оценку сложности реализации (грумминг). Когда план работ определен, а задачи декомпозированы и оценены, начинается спринт. По результатам выполнения работ проводится демонстрация — показ продукта, полученного по итогам спринта. Ну и завершает этот цикл ретроспектива. При проведении ретроспективы происходит обсуждение вопросов совершенствования процессов работы команды и выявление факторов, мешающих продуктивной деятельности.
Командный игрок
Эффективное взаимодействие ЭПО с командой невозможно без важного фактора — доверия. ЭПО не является постоянным членом команды, и отношение к нему поначалу прохладное. Особенно это заметно, если команда не особо утруждала себя вопросами кибербезопасности. В команде срабатывают стереотипы «ЭПО, как и любой другой специалист по кибербезопасности, — это некий субъект с набором стандартов, требований и предписаний». Этот человек, по их мнению, не в состоянии оценить инициативу и полет фантазии, у него есть только два основных правила: держать и не пускать.
Для того чтобы команда изменила свое отношение к деятельности ЭПО, ему просто необходимо применить все свои дипломатические навыки. Нужно показать и доказать, что ЭПО также заинтересован в выпуске безопасного продукта, причем безопасного не только для эксплуатации продукта клиентом, но и для всей окружающей данный продукт экосистемы.
Невозможно заставить команду Agile выполнять требования, которые эта команда не понимает. Команде нужно объяснить важность соблюдения регламентов и показать основные угрозы, характерные для выпускаемого продукта. ЭПО предстоит научить и заинтересовать команду в соблюдении принципов кибербезопасности. Сделать это непросто, нельзя действовать «лихим кавалерийским наскоком». Необходимо беседовать с командой, проводить с ней встречи, посвященные кибербезопасности. Нужно объяснить, что требования, которые выставляет ЭПО, не взяты из какого-то древнего документа, а определены существующими здесь и сейчас угрозами. ЭПО должен влиться в команду разработчиков, но таким образом, чтобы вся команда стала участником процессов обеспечения кибербезопасности.
Интеграция
В арсенале ЭПО тоже есть действенный инструмент — цикл Деминга (известный PDCA). Новое — это хорошо забытое старое, и данный механизм может являться решением в условиях Agile. Попробуем совместить обе методологии.
Вам будет интересно:ЕММ, или Что необходимо сделать компании, чтобы стать мобильной
Оба метода могут вполне эффективно сосуществовать. Первый этап цикла «Планирование» покрывает такие этапы Agile, как «Формирование идеи», «Декомпозиция и оценка сложности», ну и собственно «Планирование спринта». Активное участие ЭПО на данном этапе позволяет не только скорректировать сложность реализации той или иной идеи (в связи с необходимостью выполнения требований по кибербезопасности), но и задать общий вектор развития продукта. Важно донести до команды следующие аспекты:
Разумное планирование позволяет не только избежать сложностей на дальнейших этапах, но и более адекватно оценить нагрузку на команду, правильно «рассчитать силы».
Важно определить и зафиксировать показатели и маркеры, благодаря которым можно будет понять, что цель достигнута и все основные требования выполнены.
Планирование и контроль малых частей (спринтов) значительно облегчает выпуск качественного продукта в целом. Обнаружение ошибок и неточностей на ранних этапах позволяет оперативно их устранить.
Следующий этап «Выполнение» полностью совпадает с этапом «спринта» в Agile. На данном этапе роль ЭПО, скорее, консультационная — на тот случай, если в процессе реализации того или иного решения возникнут непредвиденные проблемы или поступят новые вводные.
По результатам выполнения спринта команды проводят демонстрацию или демо-встречу участников команды и других заинтересованных лиц для показа продукта команды, созданного за данный спринт. Эта активность совпадает с этапом «контроль» — «cheсk». На данном этапе ЭПО осуществляет контроль выполнения установленных требований, реализации достигнутых решений. В том случае, если в результате спринта реализуется эпик или продукт готов к релизу, проводятся приемо-сдаточные испытания. Они могут считаться расширенными демо — увеличивается масштаб контроля, контролируется взаимодействие с другими системами, проверяется сквозной бизнес-процесс. Основной задачей ЭПО на данном этапе является не столько проверка выполнения требований кибербезопасности, сколько оценка готовности продукта к опытной или промышленной эксплуатации.
По итогам спринта и демонстрации выполненных работ команда проводит ретроспективу. По сути, это этап «Воздействие» — act цикла PDCA. Ретроспектива —встреча участников команды, владельца продукта и скрам-мастера, а также ЭПО по кибербезопасности для обсуждения совершенствования процессов деятельности команды и выявления факторов, мешающих продуктивной работе. На этом этапе происходит в том числе и оценка действий команды по обеспечению кибербезопасности, а также формируются подходы к более эффективному сотрудничеству.
Еще одним важным аспектом интеграции является ведение и учет достигнутых договоренностей — артефактов. Agile пропагандирует минимизацию сопроводительной документации, но необходимость фиксации достигнутых договоренностей остается актуальной. Именно по артефактам ЭПО может проконтролировать процесс разработки, включая реализацию требований. Учет артефактов также позволит по прошествии времени поднять историю создания продукта, использовать ранее полученный опыт, оценить адекватность и правильность принятых решений.
Мост построен?
Текущий опыт выстраивания процессов взаимодействия ЭПО с командами Sbergile показывает, что это позволило более широко раскрыть преимущества методологии Agile. ЭПО уже не воспринимается командами как полицейский, запрещающий движение. Для команд ЭПО, скорее, полноценный участник процесса, советник по вопросам кибербезопасности. Исчезло недоверие и предвзятое отношение к ЭПО. С другой стороны, владелец продукта и команда больше погрузились в вопросы обеспечения кибербезопасности в продукте. Многие вопросы безопасности уже не требуют постоянного внимания со стороны ЭПО, а функциональные тесты включают вопросы кибербезопасности. Владелец продукта, понимая необходимость соблюдения принципов кибербезопасности, сам организует работы по развитию продукта в этом направлении. Тем самым достигается основное преимущество Agile — гибкая, оперативная разработка и выпуск качественного и безопасного продукта.
Автор: Антон Каралкин, руководитель направления отдела розничных клиентов Управления экспертизы кибербезопасности Сбербанка.
