О безопасности в тестировании

QA_Deep_11.3_site-5020-e321bd.png

Читал в интернете много статей про то, как тестировать безопасность в разработке, причём в основном пишут их в основном тестировщики, которые не представляют, что есть безопасность и какие у неё цели. Их статьи обычно заканчиваются перечислением уязвимостей и рекомендаций от OWASP Top-10, что грустно, потому что начинается хаос и неразбериха из-за того, что смешивают всё в кучу.

Так как около 8 лет я работал в сфере инфраструктурной безопасности, получил высшее образование в области ИБ, а последние 4 года занимаюсь автоматизацией тестирования на различных проектах, то решил и я вставить свои пять копеек в тему тестирования безопасности и немного попытаюсь систематизировать представление тестировщиков о безопасности и рассказать безопасникам, в чём же могут помочь тестировщики, в т. ч. автоматизаторы.

Приступим к разбору полётов

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

Итак, представим типовой проект современной разработки. У нас есть какой-то веб-сервис, который мы храним на Git. Скорее всего, есть какой-то CI, тестируем его, допустим, в докере. И деплоим мы наш проект в облако или на собственные сервера в каком-нибудь дата-центре в Германии или Чехии с помощью Configuration Management инструментов типа Salt, Ansible или Puppet. В процессе создания и эксплуатации проекта, как правило, участвуют девопсы, админы (здесь и далее будем считать админами в т. ч. безопасников), разработчики и QA.

У проекта есть три этапа, которые крутятся по циклу: 1. Разработка. 2. Тестирование. 3. Эксплуатация.

На каждом из этих этапов необходимо обеспечивать безопасность проекта, но везде будут разные инструменты и ответственные.

Что такое уязвимость?

Прежде чем определить ответственных за обеспечение безопасности на каждом этапе и инструменты, которые они будут использовать, давайте ответим на вопрос, что же такое уязвимость. Как меня учили в университете и такое же определение даёт уязвимости википедия, уязвимость — это недостаток в системе, который может вызвать реализацию угроз ИБ (нарушение целостности, доступности или конфиденциальности информации).

Отличное, на мой взгляд, определение, но недостаточно конкретное. Если смотреть более конкретно, то уязвимость — это код низкого качества или неправильно настроенный софт, который в перспективе может привести к реализации угроз ИБ, т. е. не любая криво настроенная или написанная система уязвима. И вот эта самая перспектива является здесь ключевым моментом, который, на мой взгляд, должен влиять на процессы устранения и поиска уязвимостей.

Кто отвечает за безопасность на этапе эксплуатации?

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

Кто в этом случае должен обнаружить проблемы — это однозначно админы/безопасники. А устранять будут админы или девопсы. Почему они? Да потому, что это уже этап эксплуатации, а не разработки или тестирования. При этом тестировщики здесь никак помочь не могут, ведь, как правило, не влияют на конфигурацию софта при деплое любой из сред и тестируют прежде всего продукт, а не его окружение. Более того, какие-то настройки на среде тестирования могут отличатся от продакшн-среды.

Кто отвечает за некачественный код?

Переходим к основному вопросу — проблемам, вызванным некачественным кодом. Кто и как их должен устранять? Ответ здесь опять же очевиден — это разработчики вместе с тестировщиками.

Какие инструменты они будут использовать? Опять же, всё просто: для разработчиков подходят статические анализаторы кода, ревью кода перед мержем и так далее. Причём ревью кода здесь сыграет более важную роль нежели статические анализаторы кода, которые оставляют желать лучшего. А уж сканеры безопасности кода по моему опыту вообще никогда не находят ничего серьёзного (если знаете стоящий сканер безопасности кода для Python, C/C++, напишите в комментариях, буду благодарен).

Также важную роль здесь играют юнит-тесты, которые как раз и помогают понять, насколько качественно работает код, который написал разработчик, насколько он устойчив к нестандартным входным данным и т. п. Какая же роль здесь у тестировщиков, особенно у автоматизаторов, нужны ли им чудесные сканеры безопасности, которые ищут возможность проведения SQL-инъекций или кросс-сайт скриптинга?

Очевидно, что нет, т.к. всё, что нужно тестировщику, — это максимально качественно протестировать продукт с максимально широким объёмом тестовых данных, проверить, какие данные валидируются, какие нет, сделал ли разработчик типизацию данных на входе и т. д. и т. п. То есть если тестировщик сделал свою работу качественно, то проблем не будет, а чтобы он делал её качественно, он должен уметь, прежде всего, тестировать, а не знать набор уязвимостей OWASP Top-10, про которые старательно пытаются рассказывать в статьях про автоматизацию тестирования безопасности руками тестировщиков.

На этом всё, и не забудьте посоветовать стоящий сканер безопасности кода для Python, C/C++!

Автор
1 комментарий
0

В статье все красиво написано, но наши админы не смогли вовремя обнаружить проблемы на этапе эксплуатации. Как итог - атака и утечка данных. Дыру залатали, но поиск остальных уязвимостей пришлось передать специалистам. Спасибо компании Tomhunter за помощь в этом вопросе

Для комментирования необходимо авторизоваться