Проблемы информационной безопасности в гибкой методологии разработки программного обеспечения Agile Scrum

Корнилов С.А.

выпускник группы MBA CSO 17

Школы IT-менеджмента 

РАНХиГС при Президенте РФ

Данная работа освещает проблемы встраивания практик информационной безопасности в процесс разработки программного обеспечения. Целью написания работы было обобщение накопленного опыта и подготовка рекомендаций для специалистов по информационной безопасности, а также разработчиков. Ввиду отсутствия на российском рынке квалифицированных специалистов по веб безопасности, а также отсутствием достаточных компетенций по безопасности у разработчиков, компании сталкиваются с проблемами создания и написания безопасного кода. Это в свою очередь приводит к дополнительным затратам на исследования безопасности продуктов, увеличению сроков вывода продуктов на рынок, затратам на покупку и эксплуатацию дополнительных технических средств безопасности и прочим негативным последствиям. Некоторые проекты и компании прибегают к помощи фирм, специализирующихся на вопросах информационной безопасности, которые проводят исследования и предоставляют отчеты о выявленных уязвимостях. Но так как процесс разработки продолжается, то актуальность подобных отчетов исчезает со временем. Крупные компании могут позволить себе собственную программу bug bounty и привлекают необходимые ресурсы на свободном рынке труда за хорошие вознаграждения для обнаружения уязвимостей в программном коде. Но что делать небольшим компаниям? Методика, освещенная в данной работе может быть принята компаниями, имеющими сравнительно небольшой штат разработчиков, 40-50 человек. Наиболее ценно то, что представленные принципы могут быть адаптированы и отдельными командами разработки, а затраты на изучение и внедрение минимальны.

В первой части работы представлено описание методологии управления проектами разработки программного обеспечения Agile.  Перед тем как внедрять практики информационной безопасности в гибкие процессы разработки, необходимо представлять себе как эти процессы устроены изнутри, чем они отличаются от традиционных подходов, какие принципы преследуют. Данная глава предназначена для менеджеров и специалистов по информационной безопасности, которые нечетко представляют принципы этой методологии. Так как бизнес окружение это постоянно меняющаяся среда, то и компании, как часть этой среды должны уметь быстро и без потерь адаптироваться к изменениям вокруг и внутри себя. Здесь вы найдете для себя ответ, почему традиционные модели управления проектами разработки программного обеспечения (waterfall) уступают место новым, гибким моделям.

Сегодня в условиях жесткой конкуренции на первый план выходят такие критерии, как time-to-market. В 90-х компании использовали модель waterfall и ttm был 3 года, к началу 2000-х этот показатель сократился до года, а к середине 2000-х до трех месяцев. Сейчас же передовые ИТ компании преследуют подходы непрерывной поставки изменений. В течении одного дня может проводится несколько обновлений продукта. Иными словами, кто первым выводит на рынок свой продукт, тот получает больший профит. В то время как показатель time to market при использовании agile растет, то эффективность команд разработки – какую ценность приносит команда в единицу времени, падает. Если в модели waterfall, где используется детальная документация, команда сидит и пишет код, то при использовании agile необходимо значительное время для общения с людьми. В agile на первое место выходит работающий продукт и продуктовая команда. Ответственность также сдвигается в сторону разработки, причем эта ответственность коллективная, т.е. вся команда в полном составе отвечает за результаты. В этом есть как плюсы, так и минусы, но на мой взгляд плюсов все таки больше. Если вы решили использовать в компании agile, будьте готовы к тому, что роль большинства топ менеджеров будет размываться. Так как продуктовая команда самостоятельно формирует стратегию и тактику развития продукта, то зачем ей нужен менеджер? Поэтому господа директора, не за горами то время, когда нужно будет работать не только головой, но и руками. Для себя я вижу переквалификацию топ менеджеров во владельцев продукта. Человек на этой роли должен обладать знаниями во многих областях – начиная от продуктового маркетинга, технологий и заканчивая психологией общения в коллективе, умением разрешать возникающие конфликты. Каждый участник agile команды должен каждый день приносить ценность в продукт. Ежедневные встречи, на которых обсуждают всего 3 вопроса: что делал, что будешь делать и какие были проблемы, сразу сигнализируют, кто из участников команды является слабым звеном. Такая самоорганизация возможна при построении правильной системы мотивации. Показатели, с помощью которых оценивается работа команды и каждого ее члена в отдельности должны быть актуальными в каждом проекте и отражать реальную картину мира для каждого сотрудника.

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

При использовании scrum разработка продукта происходит итеративно, т.е. в течении определенного промежутка времени, который называется спринтом, происходит наращивание функционала. Такие функциональные наращивания по окончании каждого спринта должны быть полными или законченными, так как на их базе будут строится следующие и т.д. В этой полноте скрыто понятие качества программного обеспечения. Кроме функциональных требований, к программному обеспечению предьявляют и нефункциональные требования – например, отказоустойчивость или надежность. Безопасность программного обеспечения в целом является его качественным показателем и основывается на нефункциональных требованиях. При встраивании в scrum процесс практик написания безопасного кода, необходимо помнить о двух основных критериях, рост которых может привести к нарушению процесса разработки и как следствие снижению бизнес показателей. Первым является так называемый технический долг. Как уже подчеркивалось, каждое приращение должно иметь определенный уровень качества, если в угоду функционалу, мы будем закрывать глаза на нефункциональные требования, то будет происходить постепенное накопление технического долга. Тоже самое касается и безопасности программного обеспечения. Откладывая на потом части доработок, касающиеся безопасности, в будущем приведет к дополнительным затратам на средства защиты, тестирование и т.д. Вторым барьером на пути могут стать очереди. Когда scrum, процесс выстроен, очереди отсутствуют, т.е. разработчики не простаивают в ожидании решения каких либо вопросов или освобождении ресурсов, которые не дают им начать свои доработки. Если на каком то из этапов информационная безопасность станет причиной накопления очередей, то это разрушитscrum процесс, а скорее всего все ваши предложения будут “отклонены”.

            Специалистам в области информационной безопасности хорошо знакомы такие понятия, как:

·        Оценка рисков

·        Моделирование угроз

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

В ходе расширения стандартного scrum и насыщения его практиками информационной безопасности следует избегать:

·      Столкновения культур (безопасность по waterfall будет проблемой)

·      Становиться препятствием потоку разработки – вас скорее всего “отодвинут”.

·      Позволить владельцу продукта принимать решение о применении той или иной фичи информационной безопасности – в угоду функциональным требованиям безопасность уйдет на второй план.

·      Ожидать, что кто то будет читать многостраничные тексты требований.

·      Добавлять требования после окончания грумминг сессии.

Чтобы преуспеть, необходимо:

·        Обеспечивать необходимое обучение по информационной безопасности для разработчиков.

·        Убедиться, что разработчики понимают ценность безопасности продукта для заказчика, каждый раз демонстрировать эту ценность, давать быструю обратную связь.

·        Гибко мыслить – строить сценарии использования разрабатываемого программного обеспечения с точки зрения злоумышленника.

·        Консультировать и советовать как можно раньше, чтобы избежать задержек.

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

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

Теперь можно сформулировать 4 основных принципа, которые лягут в основу культуры компании и команд разработки. Эти принципы похожи на манифест Agile, но касаются безопасности программного обеспечения.

1.                      Полагайтесь на разработчиков и тестировщиков в большей степени, чем на специалистов по информационной безопасности.

Не отрицая ценности специалистов по информационной безопасности этот принцип говорит, что в большинстве случаев безопасность программного обеспечения должна являться частью процесса разработки этого программного обеспечения. Непрерывная интеграция и непрерывное развертывание (CI/CD) не могут ждать внешних проверок безопасности, для того чтобы отправить код в сборку. Безопасность должна стать частью ежедневной разработки и тестирования кода. Команда разработки должна отвечать за безопасность точно таким же образом, как она отвечает за надежность, производительность и все другие нефункциональные требования. Важной частью данного принципа является утверждение, что безопасность программного обеспечения это не чья то там другая работа. Безопасность – это первая и основная работа продуктовой. Специалисты по информационной безопасности участвуют в процессе гибкой разработки точно таким же образом, что и другие члены команды. Они помогают команде понять, как можно достичь целей в области безопасности. Они могут выполнять сложные задачи, требующие специальных навыков и знаний, например интеграции инструментов безопасности в цепочку инструментов разработки и CI/CD.

2. Занимайтесь безопасностью в процессе создания программного обеспечения, а не после его окончания.

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

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

3.                      Разрабатывать все функции безопасно лучше, чем добавлять функции безопасности.

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

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

4.                      Снижать риски лучше, чем исправлять баги.

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

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

После изучения ряда методик, сравнения результатов, которые были получены, общения с экспертами в отрасли, было принято решение остановиться на использовании методологии secure scrum. В 2015 году ее описали, провели исследования и проверили на практике в Мюнхенском университете прикладных наук. Авторы исследования сравнили результаты работы 3 групп разработчиков, которые должны были выполнить разработку прототипа по одинаковым требованиям, но с использованием различных методологий. Итогом данного исследования стала наглядная демонстрация того, что предлагаемая методология secure scrum позволяет не нарушая стандартного scrum процесса и динамики команд встраивать требования по информационной безопасности в разработку программных продуктов. Самое главное преимущество методологии состоит в том, что она не сложна в понимании и применима на практике. Вам не придется создавать отдельную проектную команду для внедрения данной методологии, ее можно адаптировать в пределах одной продуктовой команды и по результатам, распространить на остальные и всю компанию в целом.