×Закрыть

Security Testing vs Penetration Test — кто кого?

Есть ли разница между «security testing» и «penetration test»? С вопросом, ответ на который, как мне казалось, лежит на поверхности, я столкнулся на конференции для специалистов по тестированию Testing Stage в начале июня. И хотя выступал я с другой темой, именно этот момент вызвал интерес и резонанс публики. Для большей части моих коллег термины «security testing» и «penetration test» равнозначны. Так ли это на самом деле? Давайте разбираться!

В общем понимании «тестирование на проникновение» представляет собой продукт или услугу по санкционированной попытке обхода средств защиты информационной системы. Результатом теста является отчет, который может/должен содержать список обнаруженных уязвимостей, использованных векторов атаки, достигнутых результатов, рекомендаций по исправлению. Обращаю ваше внимание именно на термин «информационная система» в связи с тем, что это понятие включает в себя не только программное или аппаратное обеспечение, а также данные, персонал, организационные мероприятия, документацию и иные процессы. Т. е. результаты «пентеста» информационной системы зависят не только от качества и условий настройки и эксплуатации реализации программного обеспечения, а также от аналогичных метрик аппаратного обеспечения, корректности действий персонала, налаженности и согласованности операционных процессов и т. д. В то же время «security testing» — это итеративный процесс тестирования безопасности функционирования инфраструктуры в целом, который учитывает все этапы и контроли, и в этом случае «penetration test» — обязательный элемент общей модели «security testing».

Очень классно этот подход описан в OSSTM (Open Source Security Testing Methodology). Он включает в себя: тестирование периметра, человеческого фактора, всех видов коммуникаций и взаимодействий, операций над данными в любой форме и т. д. Данная модель отлично подходит для любого типа аудита: от формального «compliance» до практического «pentest». Кроме нее, существует еще достаточное количество иных моделей и методологий, каждая из которых обладает собственными особенностями.

В иной трактовке «security testing» — процесс тестирования безопасности функционирования программного и аппаратного обеспечения, начиная с этапов проектирования и дизайна и заканчивая тестированием готовой продукции. Данный процесс включает в себя оценку рисков, сканирование уязвимостей, контроль кода, нагрузочное тестирование и т. д., и, что самое главное, предусматривает опять же итеративность этих процессов.

Очень часто встречается ситуация следующего характера: «Нам нужен пентест приложения». В этом случае подразумевается разовая проверка безопасности функционирования программного обеспечения (по опыту — чаще всего уже готового релиза, выход которого намечен на ближайшее время). Эффективен ли такой подход? Идеалисты скажут — нет, реалисты — да, но это уже тема для дальнейших дискуссий. Так же как и использование разнообразных средств и методологий. Но я обращаю ваше внимание на следующий момент: подобный подход — это демонстрация или простого отсутствия средств, или незнания/непонимания принципов «application security», частью которого является «software security testing» (именно этот термин, на мой взгляд, более точно отражает контекст данной публикации). С другой стороны, «software security testing» — часть общего процесса тестирования программного обеспечения, которая отлично встраивается в общую модель SDLC (Software development lifecycle). Указанная по ссылке таблица как нельзя лучше описывает эти процессы:

SDLC PhasesSecurity Processes
RequirementsSecurity analysis for requirements and check abuse/misuse cases
DesignSecurity risks analysis for designing. Development of test plan including security tests
Coding and Unit TestingStatic and Dynamic Testing and Security white box testing
Integration TestingBlack Box Testing
System TestingBlack Box Testing and Vulnerability scanning
ImplementationPenetration Testing, Vulnerability Scanning
SupportImpact analysis of Patches

Таблица 1. Соответствие фаз жизненного цикла разработки ПО и процессов обеспечения безопасности

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

Обращаю ваше внимание на моменты тестирования, связанные с третьим этапом. Статический и динамический анализы безопасности кода (Static Application Security Testing, SAST, и Dynamic Application Security Testing, DAST соответственно) являются отдельными направлениями в тестировании. Анализаторов для проведения SAST и DAST хватает: IBM, HP, Veracode и т. д. Общаясь с участниками конференций, я сделал для себя вывод, что про использование подобных средств и про то, что SAST и DAST уже предоставляются вендорами по модели Software as a Service (SaaS) и не требуют особых дополнительных мощностей и инфраструктуры, знают немногие, а точнее единицы. Некоторые производители предлагают компаниям-разработчикам ПО полностью готовые инфраструктуры разработки, в которые, кроме IDE, хранилищ, баз данных и т. д., входят анализаторы и виртуализаторы не только для автоматизированного функционального тестирования, но и для тестирования безопасности.

Что касается анализа требований, оценки рисков, разработки тест-планов в разрезе «software security testing», то эта тема точно заслуживает отдельного обсуждения, т. к. теоретических методологий и подходов чуть-чуть больше, чем их приверженцев, и эта дискуссия может перерасти в неплохой holy war. Если будет большой интерес к данной теме, готов написать отдельную заметку.

Подвожу краткий итог. Сейчас на рынке мы имеем достаточно заметный недостаток понимания и осознания необходимости «software security testing» в ходе разработки, как со стороны производителей ПО, так и со стороны заказчиков. Для многих понятия «pentest» и «software security test» эквивалентны. Но я уверен, что эта ситуация уже имеет явные тенденции к исправлению в лучшую сторону. Да, проблемы и вопросы кибербезопасности уже у всех на слуху, да — тестирование на проникновение уже является распространенной услугой со сформировавшимся рынком, но необходимость учета вопросов безопасности еще на этапе разработки и тестирования пока понятна не всем. Исправим?

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

Myth #1 We don’t need a security policy as we have a small business.
Myth #2 There is no return on investment in security testing.
Myth #3: Only way to secure is to unplug it.
Myth #4: The Internet isn’t safe. I will purchase software or hardware to safeguard the system and save the business.

LinkedIn

2 комментария

Подписаться на комментарииОтписаться от комментариев Комментарии могут оставлять только пользователи с подтвержденными аккаунтами.

Как бы у Microsoft это неплохо описано еще www.microsoft.com/en-us/sdl и плюс docs.sonarqube.org/...​AR/Security-related rules

Андрій, да 100%! Як би ж то народ цікавився цим :)

Подписаться на комментарии