company_banner

Пыщ-пыщ и pentest


    Современный подход к информационной безопасности

    Люблю ИБ. С одной стороны бизнес часто требует выкатывать полусырые прототипы, с деплоем раз в час. С другой — суровая и неприступная твердыня сотрудников информационной безопасности. На них все держится. И даже разработки в области 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.

    image

    Источник

    Подобные варианты проверок обычно отлично интегрируются с тем же корпоративным GitLab.
    При этом обычно есть хороший информативный вывод в консоль:

    safety check --full-report


    В идеале, после всех манипуляций, у вас должен появиться полный pipeline, где вы поэтапно проверяете все требования по безопасности к своему приложению.

    image

    Источник

    Типовые проверки:

    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, который просто сразу дает веер готовых векторов атаки на веб-сервис. Очень рекомендую присмотреться.

    Что-то вроде вывода



    Смерть человекам — слава роботам!

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



    RUVDS.com
    VDS/VPS-хостинг. Скидка 10% по коду HABR

    Комментарии 2

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

      Примеров много — некритичные уязвимости в одной из библиотек фреймворка. Саму библиотеку обновлять некорректно, нужно обновлять весь фреймворк (если в новой версии эта библиотека обновлена). Но в базе уязвимостей это не будет считаться за фикс — явно проблемы ИБ и их базы
      Или например критичная «уязвимость» в скрипте тестирования, который собственно и задумывался для теста конкретной уязвимости. И этот скрипт работает только в тестовом енвайрнменте, и в продакшене его естественно даже физически нет. Но прекрасно интегрированная ИБ система понятия не имеет о таких кейсах и ИБ макаки инженеры шлют отчеты о том, что есть уязвимость и в прод это нельзя, и ругаться с ними бесполезно.
      Подобные случаи наблюдал в разных проектах, особенно если какая-то интегрированная ентерпрайз ИБ система интегрируется товарищами из известной аутсорс страны №1 в мире.
        0

        Сложные взаимоотношения с ИБ) У нас довольно комфортно выстраиваются отношения с ними. Но такая автоматизация действительно требует очень грамотного подхода в построению процессов.

      Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

      Самое читаемое