Управление требованиями безопасности в Agile проектах
| June 22, 2012 | Posted by admin under Практики, Статьи |
Автор: Rohit Sethi
http://www.infoq.com/articles/managing-security-requirements-in-agile-projects
Обращение к требованиям безопасности ( security requirements) уже на ранних фазах разработки –наиболее эффективный способ предотвращения ошибок безопасности. Большинство требований безопасности относятся к Нефункциональным требованиям (Non-Functional Requirements – NFRs). Опыт показывает, что обращение к требованиям безопасности и к другим NFRs в agile проектах – это непросто, по двум причинам:
- Отображение NFRs на управляемые фичами пользовательские истории – это не тривиально.
- Управляющие элементы безопасности (security controls) страдают от отсутствия наглядности. Agile процессы, как правило, смещают активность разработчиков в сторону создания фич, которые расширяют опыт заказчика или исправляют дефекты.
В этой статье мы остановимся на обоих вопросах.
Отображение NFRs в пользовательских историях
Несколько agile экспертов предлагают методы для определения нефункциональных требований в движимых пользовательскими историями процессах разработки. Mike Cohn написал об этом, а несколько комментаторов дали интересные советы. Scott Ambler написал статьи по этому вопросу, утверждая, что не все NFRs могут быть заключены в пользовательскую историю. Dean Leffingwell вероятно уделил наибольшее внимание этой теме – он сделал целую главу для NFRs в своей книге Agile Software Requirements. Большинство экспертов соглашаются с тем, что мы можем поделить NFRs на два обширных типа:
- Нефункциональные пользовательские истории: Блоки тестируемой функциональности, написанные в формате пользовательских историй. Актерами в этих историях может быть внутренний IT персонал. Например: “Как аналитик безопасности, я хочу чтобы система прекращала неудачные попытки аутентификации, так чтобы приложение не было подвержено грубым атакам”.
- Ограничения: Это общие вопросы, которые могут отражаться на нескольких пользовательских историях. Это своего рода “налог” на соответствующие работы. Например, требование чтобы все разработчики валидировали данные из полей HTTP форм в web приложениях – это ограничение.
Управление первой категорией очевидно. Создайте соответствующий наборNFR историй и добавьте их в рабочую очередь, такую как баклог продукта.
Проблемы с NFR ограничениями
Управление второй категорией, однако, намного сложнее. Agilist-ы предлагают для этого несколько решений, включая:
- Добавление подходящих ограничений в качестве критериев приемки (acceptance criteria) в определенные пользовательские истории
- Поддержка списка ограничений в центральном репозитории, таком как документ, закрепленный на видном месте на стене, или wiki
Ни один из подходов не предлагает механизм для определения того, какие из ограничений могут быть применены к данной истории. Более того, наш опыт с отображением требований безопасности на SD Elements таков, что эти методы плохо масштабируются. Возьмем например следующее подмножество ограничений безопасности для стандартного web приложения:
- Привязать переменные SQL выражениях , чтобы предотвратить внедрение SQL кода
- Убедиться в целостности поставляемых клиентом read-only данных, чтобы предотвратить манипуляции с параметрами
- Избегать непроверенных данных в HTML, HTML атрибутах, CSS и JavaScript, чтобы предотвратить Межсайтовый скриптинг (Cross Site Scripting – XSS)
- Избежать межсайтового скриптинга через DOM (DOM-based XSS) в клиентских JavaScript-ах
- Использовать безопасную арифметику чтобы избежать целочисленное переполнение (integer overflow)
- Запретить внешние переадресации, чтобы предотвратить открытые переадресации (open redirects)
- Авторизовывать защищенные страницы, чтобы предотвратить повышение привилегий (privilege escalation)
- Использовать токены против межсайтовой подделки запросов (cross site request forgery -CSRF)
- Проверять входящие данные
- Использовать регулярные выражения, которые не являются уязвимыми для атак типа «отказ в обслуживании» (Denial of Service)
- Реализовать аутентификацию транзакций для транзакций с высокой стоимостью
- Не зашивать в код пароли
Это может составлять меньше половины всех ограничений безопасности, которые нужно учесть разработчикам при реализации пользовательской истории. Однако, набор ограничений значительно вырастает, когда принимают во внимание нормативные требования, такие как Промышленный стандарт безопасности данных платежных карт (Payment Card Industry Data Security Standard – PCI DSS). Если вы начинаете добавлять другие NFR ограничения, такие как удобство доступа, список ограничений может расти подавляюще быстро для разработчиков. После того, как список становится громоздким, разработчики, как показывает наш опыт, начинают игнорировать его целиком. Вместо этого, они полагаются на свою память в применении NFR ограничений. В такие областях, как безопасность приложений, количество NFRs значительно растет, что делает когнитивную нагрузку на мозг разработчиков существенной. Поэтому акцент делается на статический анализ нарушений NFR ограничений в коде. Исследования показывают, что статический анализ может выявлять до 40% предотвратимых дефектов. Это ведет к тому, что большое число ограничений не выявляются статическим анализом, включая специфические для домена управляющие элементы безопасности. Не говоря уже о проблемах с ложными срабатываниями, которые возникают при статическом анализе без настройки.
Решение проблем с NFR ограничениями
Для решения проблемы безмерных NFR ограничений, мы должны обратиться к следующим четырем основным пунктам:
- Приоритезация: NFR ограничения должны иметь разные приоритеты, также как пользовательские истории и дефекты. Например, кодирование или проверка ненадежных данных в заголовке HTTP ответа для предотвращения расщепления HTTP запроса (HTTP Response Splitting)обычно не так важно, как исключение ненадежных данных в HTML для предотвращения постоянного межсайтового скриптинга. Допустите, что разработчикам редко хватает времени на реализацию всех ограничений, и обеспечьте механизм для предложения относительных приоритетов ограничений. Мы говорим “для предложения” потому что приоритеты могут меняться в зависимости от контекста, и разработчикам нужно вынести суждение о том, каковы будут относительные приоритеты для их специфичного кода. Вы можете выбрать простые приоритеты вроде “Высокий, Средний, Низкий” или числовую шкалу от одного до десяти.
- Фильтрация: Используя простые критерии, вы часто можете уменьшить или убрать большой объем NFR ограничений для определенной пользовательской истории. Например, допустим, вы работаете над пользовательской историей, которая не затрагивает уровень представления. Вы можете спокойно проигнорировать большое число ограничений, специфичных для уровня представления. Используя систему тэгов или просто Excel фильтры, вы можете убрать большое число ограничений для определенной пользовательской истории. Вот некоторые примеры фильтров, относящиеся к web приложениям:
– Использует ли пользовательская история входные данные, поставляемые пользователем?
– Использует ли пользовательская история конфиденциальные данные, такие как пароли, кредитные карточки или непубличные финансовые данные?
– Приводит ли пользовательская история к новым или измененным выходным данным для пользователя, таким как web страницы?
– Включает ли пользовательская история взаимодействие с базой данных?
– Пользовательская история показывает или использует данные из RESTful или SOAP API вызовов?
– Включает ли пользовательская история доступ к защищенным данным (например, данным, которые могут видеть/изменять не все пользователи)?
- Контекст: Разработчики лучше запоминают и применяют ограничения, когда они в контексте написания кода или определения ticket-ов/пользовательских историй. Идеально если вы встроите ваш список ограничений внутрь IDE (Integrated Development Environment – Интегрированная среда разработки) или ticketing системы, тогда разработчики будут иметь доступ к нужным ограничениям во время кодирования. Обратите внимание, что многие IDE поддерживают встроенные web браузеры; поэтому использование легковесного web или SharePoint сайта поможет достичь этой цели.
- Фреймворк: Фреймворк может значительно уменьшить “нагрузку” ограничений. Например, фреймворк вроде Django , который обеспечивает CSRF защиту по умолчанию, это означает что разработчики могут спокойно игнорировать это ограничение, если только они не пытаются обойти встроенную защиту. По нашему опыту, большинство крупных приложений имеют в том или ином виде собственный фреймворк, который может незаметно справиться с высокоприоритетными ограничениями. Такая настройка фреймворка может потребовать значительных инвестиций, но если вы думаете об ограничениях как о “налоге” на пользовательские истории, то уменьшение числа ограничений аналогично постоянному снижению налоговой ставки.
Валидация
Постоянное внимание к NFRs не отменяет валидацию. Если у вас есть практика ревью кода вручную, ревьюеры могут проверить NFRs явно перечисленные в качестве критерия приемки в пользовательских историях. Многие ограничения однако сложно найти вручную. Инструменты статического анализа автоматически проверяют соблюдение стандартов кодирования. Некоторые продукты направлены именно на безопасность. Конфигурация вашего инструмента статического анализа для непрерывной интеграции поможет обеспечить постоянное соблюдение стандартов кодирования. Однако будьте осторожны, не полагайтесь исключительно на ревью кода. NFRs, которые защищают от специфичных для домена уязвимостей, таких как манипулирование HTTP параметрами, требуют понимания бизнес домена. Комбинация ручного и автоматизированного регрессионного тестирования для специфических атак поможет вам построить систему, устойчивую к специфичным для домена уязвимостям.
Наглядность
Еще один фактор, тормозящий интеграцию безопасности в agile проектах, – это недостаток наглядности. Встречи с участием заказчиков, такие как Ревью спринта в Scrum, смещают работы в сторону историй и исправления ошибок для улучшения пользовательского опыта взаимодействия. Некоторые нефункциональные атрибуты, такие как юзабилити и производительность, имеют осязаемый эффект при взаимодействии с системой и легко демонстрируются заказчикам. Другие, такие как безопасность, редко приводят к чисто положительному опыту для клиента во время ревью спринта. На самом деле, некоторые фичи безопасности, вроде блокирования учетной записи, могут иметь негативное влияние на опыт взаимодействия. Большинство фич безопасности не имеют заметного влияния на обычных пользователей. Таким образом, NFRs безопасности невидимы, и их нужно делать с более видимыми фичами для того, чтобы цикл разработки имел ценность. Вопрос о издержках на работы по невидимым требованиям стоит особенно остро на ранних стадиях разработки, когда разработчики должны встроить безопасность в систему.
Делаем безопасность видимой
Не существует простого решения, которое позволило бы сделать безопасность высшим приоритетом для agile команды в начале разработки. Есть, однако, несколько способов, чтобы сделать NFRs безопасности видимыми для заказчиков и/или product owner-ов:
- Диаграммы для историй с требованиями безопасности: Если у вас достаточно экспертизы по безопасности приложения, вы можете сделать исчерпывающий набор управляющих элементов безопасности, чтобы справиться со слабыми местами безопасности. Затем вы можете взять управляющие элементы, которые соответствуют NFR историям (в отличие от ограничений) и построить простую диаграмму, иллюстрирующую число реализованных и нереализованных пользовательских историй по безопасности в системе. Эта диаграмма может занять место среди других ваших Больших наглядных диаграмм.
Рис 1: диаграмма пользовательских историй по безопасности
- Конечно, вам не обязательно ограничивать эту диаграмму только историями по безопасности. Вы можете включить другие важные NFRs в туже диаграмму. Вы можете использовать story point-ы вместо числа пользовательских историй, для того, чтобы отобразить затраченные усилия. Вы можете ограничиться диаграммой только для высокоприоритетных историй / управляющих элементов для вопросов с высокой степенью риска. Каждая реализуемая вами история поможет увеличить число “Реализованных” и соответственно поможет вам сделать прогресс видимым для заказчика и /или product owner-а.
- Демонстрация уязвимостей: Ничто так не заставляет людей понять последствия слабых сторон безопасности, как демонстрация уязвимости. Это ключевое отличие между тестом на проникновение извне и оценкой уязвимости . Если усилия оправданы, вы можете продемонстрировать успешное вторжение на предыдущей версии приложения и затем показать, как новая версия не допускает такого вторжения. Вы можете объяснить последствия слабых сторон безопасности в терминах влияния на бизнес и/или заказчиков. Это может значительно помочь при оправдании времени, затраченного на управляющие элементы безопасности.
Заключение
Активное внимание к нефункциональным требованиям, и безопасности в частности, нетривиально в контексте agile. Несколько экспертов дают советы о том,как обращаться с такими требованиями, и как они относятся к пользовательским историям. Работа с обширным набором ограничений – это серьезная проблема. Принимая во внимание предложения, обсуждаемые в этой статье вы можете значительно увеличить значимость поддержки библиотеки ограничений. Даже если вы не можете выполнить все четыре пункта по улучшению управления ограничениями, любое улучшение, которое вы сделаете, может дать значительные преимущества в долгосрочной перспективе. Добавление валидации обеспечит уверенность в том, что ваша команда успешно придерживается NFRs. Наконец, сделав безопасность видимой, вы сможете оправдать время, которое потратили на те улучшения в системе, которые обычно не улучшают опыт взаимодействия пользователя.
