О безопасности в тестировании
Читал в интернете много статей про то, как тестировать безопасность в разработке, причём в основном пишут их в основном тестировщики, которые не представляют, что есть безопасность и какие у неё цели.
Так как около 8 лет я работал в сфере инфраструктурной безопасности, получил высшее образование в области ИБ, а последние 4 года занимаюсь автоматизацией тестирования на различных проектах, то решил и я вставить свои пять копеек в тему тестирования безопасности и немного попытаюсь систематизировать представление тестировщиков о безопасности и рассказать безопасникам, в чём же могут помочь тестировщики, в т. ч. автоматизаторы.
Приступим к разбору полётов
План сегодняшней статьи будет такой. Мы разберёмся, с какими проблемами сталкивается современный проект в части информационной безопасности, и посмотрим, какую помощь могут оказать тестировщики в рамках обеспечения безопасности проекта.
Итак, представим типовой проект современной разработки. У нас есть какой-то веб-сервис, который мы храним на Git. Скорее всего, есть какой-то CI, тестируем его, допустим, в докере. И деплоим мы наш проект в облако или на собственные сервера в каком-нибудь дата-центре в Германии или Чехии с помощью Configuration Management инструментов типа Salt, Ansible или Puppet. В процессе создания и эксплуатации проекта, как правило, участвуют девопсы, админы (здесь и далее будем считать админами в т. ч. безопасников), разработчики и QA.
У проекта есть три этапа, которые крутятся по циклу: 1. Разработка. 2. Тестирование. 3. Эксплуатация.
На каждом из этих этапов необходимо обеспечивать безопасность проекта, но везде будут разные инструменты и ответственные.
Что такое уязвимость?
Прежде чем определить ответственных за обеспечение безопасности на каждом этапе и инструменты, которые они будут использовать, давайте ответим на вопрос, что же такое уязвимость. Как меня учили в университете и такое же определение даёт уязвимости википедия, уязвимость — это недостаток в системе, который может вызвать реализацию угроз ИБ (нарушение целостности, доступности или конфиденциальности информации).
Отличное, на мой взгляд, определение, но недостаточно конкретное. Если смотреть более конкретно, то уязвимость — это код низкого качества или неправильно настроенный софт, который в перспективе может привести к реализации угроз ИБ, т. е. не любая криво настроенная или написанная система уязвима. И вот эта самая перспектива является здесь ключевым моментом, который, на мой взгляд, должен влиять на процессы устранения и поиска уязвимостей.
Кто отвечает за безопасность на этапе эксплуатации?
Начнём с того, на чём я бы хотел в меньшей степени остановится в своей статье — это на обеспечении безопасности на этапе эксплуатации, которая касается обычно криво настроенного софта. Например, кто-то оставил дефолтный пароль для админки либо забыл отключить работу приложения без шифрования или использует старые пакеты.
Кто в этом случае должен обнаружить проблемы — это однозначно админы/безопасники. А устранять будут админы или девопсы. Почему они? Да потому, что это уже этап эксплуатации, а не разработки или тестирования. При этом тестировщики здесь никак помочь не могут, ведь, как правило, не влияют на конфигурацию софта при деплое любой из сред и тестируют прежде всего продукт, а не его окружение. Более того, какие-то настройки на среде тестирования могут отличатся от продакшн-среды.
Кто отвечает за некачественный код?
Переходим к основному вопросу — проблемам, вызванным некачественным кодом. Кто и как их должен устранять? Ответ здесь опять же очевиден — это разработчики вместе с тестировщиками.
Какие инструменты они будут использовать? Опять же, всё просто: для разработчиков подходят статические анализаторы кода, ревью кода перед мержем и так далее. Причём ревью кода здесь сыграет более важную роль нежели статические анализаторы кода, которые оставляют желать лучшего. А уж сканеры безопасности кода по моему опыту вообще никогда не находят ничего серьёзного (если знаете стоящий сканер безопасности кода для Python, C/C++, напишите в комментариях, буду благодарен).
Также важную роль здесь играют юнит-тесты, которые как раз и помогают понять, насколько качественно работает код, который написал разработчик, насколько он устойчив к нестандартным входным данным и т. п. Какая же роль здесь у тестировщиков, особенно у автоматизаторов, нужны ли им чудесные сканеры безопасности, которые ищут возможность проведения SQL-инъекций или кросс-сайт скриптинга?
Очевидно, что нет, т.к. всё, что нужно тестировщику, — это максимально качественно протестировать продукт с максимально широким объёмом тестовых данных, проверить, какие данные валидируются, какие нет, сделал ли разработчик типизацию данных на входе и т. д. и т. п. То есть если тестировщик сделал свою работу качественно, то проблем не будет, а чтобы он делал её качественно, он должен уметь, прежде всего, тестировать, а не знать набор уязвимостей OWASP Top-10, про которые старательно пытаются рассказывать в статьях про автоматизацию тестирования безопасности руками тестировщиков.
На этом всё, и не забудьте посоветовать стоящий сканер безопасности кода для Python, C/C++!
