Тестирование методом белого и черного ящика: что нужно знать бизнесу о безопасности программ и приложений

Уязвимости в приложениях, используемых бизнесом в работе, — основной вектор атаки киберпреступников. Почти в 90% случаев атаки на корпоративные информационные системы реализуются как раз через программное обеспечения и приложения. Их защите нужно уделить должное внимание.

Абсолютно неуязвимых приложений не бывает. Поэтому лучше не надеяться на удачу, а позаботиться о поиске уязвимостей программного обеспечения своими силами. Бизнес может реализовать это без штатных разработчиков и тестировщиков. С этой целью мы разработали статистический анализатор безопасности приложений Solar appScreener. Он осуществляет проверку методом SAST, которую принято называть тестированием методом белого ящика (whitebox-анализ). Чтобы понять эффект для бизнеса от его использования, целесообразно сравнить методики «черного» и «белого» ящиков.

Тестирование методом черного ящика

Его считают самым простым и распространенным. Часто тестирование методом черного ящика отождествляют с DAST – динамическим анализом.

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

Организовать воздействие на анализируемое приложение несложно. За счет этого тестирование методом черного ящика и получило широкое распространение. Но есть здесь свои нюансы. Среди них:

• Необходимость развертывания приложения для его проверки. Причем желательно тестировать нерабочую (не использующуюся бизнесом для работы) копию программного обеспечения, чтобы ничего «не сломать» в бизнес-процессах. Такое развертывание может потребовать немало ресурсов. Далеко не каждой компании под силу это реализовать.
• Невысокая скорость проверки. Нужно воссоздать, перебрать различные ситуации, оценить реакцию программного обеспечения на них. Часто не удается реализовать все задуманное в течение выделенного на тестирование времени.
• Снижение эффективности при усложнении программного обеспечения, протокола и ряда других факторов. Чем сложнее программа, тем труднее реализовать ее тестирование методом черного ящика.

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

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

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

Тестирование программного продукта методом белого ящика

Whitebox-тестирование отождествляют с SAST. Это статический анализы, который не требует запуска и выполнения программного обеспечения. Анализ производится с доступом к исходному коду. При разработке Solar appScreener мы делали упор именно на эту технологию.

SAST-инструмент сканирует исходный код программ и приложений, выявляет потенциальные уязвимости. Среди плюсов такого подхода:

• Высокая эффективность. Ведь при тестировании программного продукта методом белого ящика покрывается 100% исходного кода программы.
• Расширенные функциональные возможности, позволяющие оценить уровень защищенности приложения. Например, с помощью этой методики можно реализовать тестирование архитектуры и качества программного обеспечения. А эти показатели связаны с уровнем защищенности: качественная программа с выверенной архитектурой будет хорошо защищена.
• Возможность анализа приложений любых типов и разных компонентов одной программы. «Белый ящик» позволяет тестировать исполняемые (бинарные) файлы, программы-«полиглоты» (при написании которых используется одновременно несколько языков). Возможность такой проверки реализована в ограниченном количестве анализаторов кода, одним из которых является Solar appScreener, способный работать с 36 языками программирования.

Среди нюансов и возможных сложностей использования white box метода можно выделить:

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

Благодаря Solar appScreener, а также аналогичным SAST-инструментам, организовать тестирование на уязвимости методом белого ящика можно без привлечения разработчиков. Итоговая информация предоставляется в формализованном виде, удобном для восприятия даже человеком, далеким от сферы разработки. Такие решения ориентированы на специалистов по информационной безопасности. Это дополнительная составляющая защиты корпоративной IT-инфраструктуры, с помощью которой вы сможете повысить уровень ее защищенности от различных угроз.