Представляю вашему вниманию перевод третьей главы Owasp Testing Guide. В этой главе будет рассмотрена типовая программа тестирования, которая может быть создана внутри организации.

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

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

Для начала нужно понять, почему построение непрерывной программы тестирования является критичным для оценки и улучшения программной безопасности. В книге «Writing Secure Code» [https://www.microsoft.com/mspress/books/5612.aspx] о безопасном коде написано, что выпуск бюллетеня по безопасности стоит Microsoft 100 000$, но значительно дороже обходится установка патчей безопасности их клиентам. Также в ней упоминается о сайте правительства США по борьбе с киберпреступностью [https://www.justice.gov/criminal-ccips/], где описываются недавние инциденты и потери от них для организаций. Средняя сумма убытков там значительно превышает 100 000 американских долларов.

При такой экономике легко объясняется переход вендоров ПО от тестирования безопасности методом чёрного ящика, что возможно только на разработанном приложении, к тестированию начиная с ранних стадий ЖЦ.

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

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

Есть множество методологий по разработке, например:

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

Работы, выполняемые в рамках программы тестирования, распределены по стадиям ЖЦ:

  • Перед началом разработки
  • Определение требований и проектирование
  • Разработка
  • Внедрение
  • Поддержка и эксплуатация

Стадия 1: Перед началом разработки

1.1: Определить процессы в жизненном цикле

До начала разработки приложения необходимо определить состав работ и стадии ЖЦ, в каждую из которых должны быть включены проверки безопасности.

1.2: Проанализируйте используемые политики и стандарты

Убедитесь в том, что имеются все необходимые политики, стандарты и подготовлена вся документация. Это даёт командам разработчиков возможность опираться на информацию в них во время своей работы. Люди могут поступать правильно только если они знают, что понимается под «правильным».

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

1.3: Разработайте критерии для метрик и убедитесь в их отслеживаемости

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

Стадия 2: Определение требований и проектирование

2.1: Проанализируйте требования безопасности

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

Например, если есть требование о том, что пользователи должны быть зарегистрированы перед тем, как они смогут получить доступ к определённой странице вебсайта, как его правильно трактовать: пользователь должен быть зарегистрирован в системе, или пользователь должен быть аутентифицирован? Удостоверьтесь в том, что все требования недвусмысленны.

При поиске упущений в требованиях, следует уделить внимание следующим механизмам безопасности:

  • Управление пользователями
  • Аутентификация
  • Авторизация
  • Конфиденциальность данных
  • Целостность
  • Идентифицируемость
  • Управление сессией
  • Безопасность передачи данных
  • Изоляция слоёв системы
  • Соответствие стандартам и законодательству (включая стандарты конфиденциальности, государственные и отраслевые)

2.2: Проанализируйте итоги проектирования и архитектуру

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

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

Если по итогу анализа были обнаружены проблемы, они должны быть представлены системному архитектору для определения альтернативных подходов.

2.3: Разработайте и проанализируйте UML-модели

После окончания проектирования и построения архитектуры можно построить UML-модели, которые описывают то, как приложение работает. В некоторых случаях они могут быть созданы автоматически. Используйте их чтобы достигнуть взаимопонимания с системными архитекторами о том, как работает приложение. Если слабые места были обнаружены, они должны быть переданы системным архитекторам для поиска альтернативных подходов.

2.4: Разработайте и проанализируйте модели угроз

Разработайте реалистичные модели угроз. На основе анализа архитектуры убедитесь в том, что угрозы по всем возможным векторам атак были смягчены, приняты бизнесом либо назначены на третью сторону (например, на страховую компанию). Если среди обнаруженных угроз есть те, по которым отсутствует стратегия по смягчению, пересмотрите архитектуру с системным архитектором, возможно, что-то нужно будет изменить.

Стадия 3: Разработка

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

3.1: Поэтапный анализ

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

Целью данного этапа является не сам разбор кода, а высокоуровневое понимание хода его работы, организации и структуры.

3.2: Анализ кода

Понимая, как код структурирован и почему некоторые моменты в нём были реализованы именно так, как есть, тестировщик может проанализировать код на предмет дефектов для безопасности.

Статические проверки кода подтверждают соответствие кода проверочному списку, который включает:

  • Учёт бизнес требований к доступности, конфиденциальности и целостности;
  • Стойкость к уязвимостям OWASP (глава 4) или топ-10 уязвимостям (в зависимости от глубины анализа);
  • Учёт особых случаев, относящихся с используемому языку или фреймворку (например, работа «A Study In Scarlet» по уязвимостям PHP, или руководство от Microsoft «Secure Coding Guidelines» при работе с ASP.NET);
  • Прочие отраслевые требования, такие как Sarbanes-Oxley 404, COPPA, ISO/IEC 27002, APRA, HIPAA, Правила платёжной системы VISA и др.

Говоря о возврате инвестированных ресурсов (по большей части времени), стоит отметить, что статические проверки кода дают более качественные результаты, чем прочие методы анализа безопасности, и опираются в меньшей степени на навык проверяющего. Но данный метод не является серебряной пулей и должен быть использован с осторожностью во всесторонней программе тестирования.

Больше информации по спискам для проверки безопасности можно найти в главе 4 данной работы, либо на странице [https://www.owasp.org/index.php/Testing_Checklist]. Актуальную версию топ-10 уязвимостей по версии OWASP можно найти здесь [https://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project].

Стадия 4: Внедрение

4.1: Тестирование на проникновение

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

4.2: Проверка управления конфигурацией

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

Стадия 5: Поддержка и эксплуатация

5.1: Проводите проверки оперативного управления

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

5.2: Проводите периодический анализ состояния приложения

Необходимо проводить месячные или квартальные проверки состояния приложения и инфраструктуры чтобы убедиться в том, что новые риски нарушения безопасности не появились и текущий уровень защищённости ещё актуален.

5.3: Убедитесь в наличии анализа влияния при изменениях

После каждого изменения, которое было утверждено, протестировано на среде контроля качества и внедрено на боевую среду, обязательно нужно проверять, не повлияло ли это изменение на уровень защищённости в целом. Эта проверка должна быть включена в процесс управления изменениями.

Типовая программа тестирования в жизненном цикле

Типовая программа тестирования OWASP