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 Phases | Security Processes |
| Requirements | Security analysis for requirements and check abuse/misuse cases |
| Design | Security risks analysis for designing. Development of test plan including security tests |
| Coding and Unit Testing | Static and Dynamic Testing and Security white box testing |
| Integration Testing | Black Box Testing |
| System Testing | Black Box Testing and Vulnerability scanning |
| Implementation | Penetration Testing, Vulnerability Scanning |
| Support | Impact 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.
