Современный подход к информационной безопасности
Люблю ИБ. С одной стороны бизнес часто требует выкатывать полусырые прототипы, с деплоем раз в час. С другой — суровая и неприступная твердыня сотрудников информационной безопасности. На них все держится. И даже разработки в области IoT, где S — это security становятся еще надежнее под их присмотром.
Ключевая проблема оценки диаметра дырок технологических отверстий в вашем продукте — это время. Я хочу еще раз немного поговорить о классической пирамиде тестирования, но уже в разрезе информационной безопасности. А еще попробую поделиться опытом в организации построения удобного процесса, когда разработчики не ожидают неделями одобрения от ИБ, а ПО при этом не светится всеми возможными уязвимостями во внешний мир. Спойлер: можно выкатывать и без одобрения.
И список. Все любят списки. Отдам свой небольшой набор нужного ПО, который сильно скрашивает мои будни.
Если что-то скучное — надо автоматизировать
Классическая пирамида тестирования. Где-то в основании многочисленные юнит-тесты, которые покрывают всякие мелочи, вроде проверки того, что приложение не падает, если пользователь вводит свой пароль на хинди. Или что-то еще странное отправил. А то были прецеденты с "لُلُصّبُلُلصّبُررً ॣ ॣh ॣ ॣ 冗" на iPhone, если помните. Этот тип тестирования прекрасен своей автоматизацией, но покрывает только узкие кейсы, которые часто не в состоянии дать полной картины и уверенности в том, что приложение не потечет в неожиданном месте.
На самом верху уже полностью ручное тестирование. Кроме проверки стандартных кейсов оно может предусматривать «свободное творчество», когда специалисту дается задача что-то сломать любым экзотическим способом на свой вкус. Как всегда, подобный творческий подход приводит к тому, что этот вид тестов является одновременно и самым дорогим. Не только в плане денег, но и пресловутого time-to-market, когда надо выкатить новые фичи вот-прям-вчера-на-совещании-уже-обещали.
Традиционная проблема, с которой сталкиваются многие компании — долгие и печальные согласования по каждому пункту с ИБ. Не потому, что они такие злые и недружелюбные. Просто у них задача в минимизации рисков. Вот они и минимизируют как могут, попутно останавливая половину процессов в бутылочном горлышке своих проверок. Собственно в доаджайловые времена, когда можно было неторопливо полировать свой код это работало. А сейчас к твоему полированному решению первой версии уже выйдет 47 полусырых прототипов от конкурентов с monkey coders. И все. Ты уже проиграл рынок, все пользователи залипают в очередной Тик-Так.
Pipeline для всего подряд
На самом деле, чаще всего проблема в плохой интеграции процессов ИБ в уже привычные разработчиками пайплайны. Почему-то каждый пуш сопровождается множеством проверок со стороны того же flake8 и mypy, сам собирается в пакет, заливается в контейнер GitLab runner'а и радостно улетает протестированный в Artifactory. Или проваливает этап и возвращается на доработку.
И только информационная безопасность часто руками под лупой каждый релиз, пролистывая код и тыкая палочкой в открытые порты приложения. Мне кажется, что одно из оптимальных решений — перенос основной части проверок безопасности в автоматический процесс, а ручное тестирование ограничить во времени. У ИБ остается право вето, если они находят критичную уязвимость, но по умолчанию приложение улетает в прод, если не было возражений с их стороны. Звучит на первый взгляд пугающе, но подобное построение процесса мотивирует максимально автоматизировать все рутинные процедуры и тратить время только на действительно сложные вещи.
Меня немного пугают эти аббревиатуры вида DevSecOps и прочие TriCeraTops, но это именно то, что чаще всего нужно организовать для снижения временных издержек. Давайте глянем на примере python. Начать стоит с линтеров. Я думаю, что почти все прикрутили те или иные варианты базовых линтеров вроде flake8 и mypy. Я тут еще бы порекомендовал расширенный вариант flake8 — wemake-python-styleguide.
Устанавливается и запускается традиционно:
pip install wemake-python-styleguide
flake8 your_module.pyОсновная проблема этого линтера — может вызывать желание разбить монитор клавиатурой поначалу. Особенно в старых легаси-проектах из разряда «проще сжечь, чем исправить». Тем не менее, если исключить лишние проверки — получите довольно суровый контроль за качеством базового кода.
После того, как мы проверили сам код на кривые конструкции, плохую читаемость и высокую цикломатическую сложность, стоит прогнать статический security-линтер. Да, в языках с нестрогой типизацией подобные линтеры не столь хороши, но они позволяют выявить типичные проблемы вроде password = 'qwerty123' в коде. Тут можно использовать тот же bandit.
Это все отлично работает, но проблема бесплатных решений чаще всего в менее актуальных базах уязвимостей. Чаще всего имеет смысл добавить еще что-то вроде safety.
Подобные варианты проверок обычно отлично интегрируются с тем же корпоративным GitLab.
При этом обычно есть хороший информативный вывод в консоль:
safety check --full-report
В идеале, после всех манипуляций, у вас должен появиться полный pipeline, где вы поэтапно проверяете все требования по безопасности к своему приложению.
Типовые проверки:
git secret check — проверяем отсутствие открытых секретов в коде
SCA — проверяем, что внешние зависимости и библиотеки не имеют уязвимостей. Важно, если вы замораживаете старую версию библиотеки
SAST — статический анализ кода на уязвимости
Container audit — аудит образа контейнера, который будет использоваться для деплоя. Они тоже часто бывают дырявыми. Особенно, если вы используете экзотические бутерброды из множества разношерстных слоев.
DAST — деплой приложения, регистрация, логин под легитимным пользователем и проведение типовых атак на фронтенд
Что остается для ИБ
Теперь, когда мы разгрузили бесполезные мясные создания людей от рутинной работы, можно передать им те задачи, которые требуют по-настоящему творческого подхода.
Тут будет все тот же нестареющий арсенал из средств для анализа, сетевого тестирования и подбора паролей. Wireshark, hashcat, Hydra и остальные утилиты никто на пенсию не отправлял.
Но даже среди знакомых инструментов появляется что-то новое и иногда довольно полезное. Я предложу обратить внимание на некоторые из них.
Nikto2
github.com/sullo/nikto
Nikto — это сканер веб-серверов с открытым исходным кодом. Он совершенно не тихий. Серьезно, если вы запустили его с рабочего места и в течение 15 минут вы еще не лежите лицом в пол в окружении сотрудников безопасности, то у вас проблемы с обнаружением вторжений.
Софт выполняет комплексные тесты на веб-серверах для множества элементов, включая более 6700 потенциально опасных файлов / программ. Он также проверяет элементы конфигурации сервера, такие как параметры HTTP-сервера, и пытается идентифицировать установленные веб-серверы и программное обеспечение. Элементы сканирования и плагины часто обновляются и могут обновляться автоматически.
Fuzzdb
Тоже очень крутой инструмент для автоматизированной атаки на веб-приложения с использованием типовых паттернов и уязвимостей. Радостно засыплет ваше приложение кучей стандартных атак и заодно проверит, не забыли ли вы прикрыть урезанными правами доступ к админке и лог-файлам. Позволяет снять много головной боли и рутинных проверок.
Nmap + Vulners
Vulners — это агрегатор всевозможных CVE, вендорских бюллетеней безопасности, эксплойтов в Metasploit и просто результат ручного вылавливания уязвимостей на тематических форумах. По сути, они предоставляют API для запросов к своей БД. Меня просто покорил их плагин к всем известному nmap, который просто сразу дает веер готовых векторов атаки на веб-сервис. Очень рекомендую присмотреться.
Что-то вроде вывода
Смерть человекам — слава роботам!
А если серьезно, то постарайтесь минимизировать рутину и передать ее тому, кто должен ей по-настоящему заниматься — бездушным скриптам и пайплайнам. А люди пусть занимаются творчеством. Это правильнее.
Автор: oldadmin
