Услуги
Аудит информационной безопасности

Аудит информационной безопасности компании – многоплановая задача, в
которую входит несколько направлений анализа
ИТ-инфраструктуры и оценки защищенности приложений и устройств

Подробнее
Решения
Решения

Аккумулировав весь опыт Digital Security, мы подготовили отдельные решения по аудиту безопасности. Каждое решение объединяет специализированные услуги для конкретной отрасли бизнеса или сферы исследования. Вы можете выбрать любую из них или несколько — в комплексе

О нас
Digital Security

Практическая информационная безопасность – наша специализация и любимое дело. Уже 18 лет мы помогаем нашим клиентам уберечь сервисы и системы от киберугроз, а также активно участвуем в развитии мирового ИБ-сообщества

Подробнее
Экспертиза
Экспертиза

Для клиентов Digital Security работает команда экспертов ИБ мирового уровня. Мы получаем благодарности за вклад в обеспечение безопасности от лидеров ИТ-индустрии, а также подтверждаем свои навыки международными сертификатами в области ИБ

Подробнее
Ресурсы
Ресурсы

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

Подробнее

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

Посмотреть раздел

Масштабные исследования и аналитические обзоры. Описания хакерских инструментов и техник

Статьи и аналитические работы, полезные для бизнеса. Экспертное мнение об актуальных проблемах информационной безопасности

Видеоархив наших вебинаров и конференций. А также анонсы предстоящих мероприятий

Руководства, презентации, чек-листы. Гайды для повышения уровня осведомленности в вопросах ИБ

Наверх

Фаззинг — важный этап безопасной разработки

21.08.2019 /
Прочитать позже

    Отправим материал на:

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

    В мире разработки давно появились такие понятия, как Security Development Life Cycle (SDLC), и сравнительно недавно такие, как DevSecOps или SecDevOps, но используются эти техники далеко не всеми. Суть у них одна — внедрять подходы к повышению безопасности с первых этапов разработки, а лучше начинать с обучения сотрудников. И, конечно, важно уделять внимание защищенности продукта от атак на протяжении всего его жизненного цикла.

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

    Как раз во время написания статьи в ленте твиттера мелькнули заметки на тему использования фаззинга от Дмитрия Вьюкова.

     

    Он как раз обращает внимание на то, что с помощью фаззинга можно обнаружить большое количество ошибок в коде, которые в противном случае никуда не исчезнут даже по прошествии времени.

    Обычно фаззингом завершают процесс разработки, но фаззить можно и отдельные функции разрабатываемого продукта.

    Преимущества фаззинга перед другими методами тестирования:

    • фаззер можно запустить и забыть о нем до момента окончания тестирования, а работать уже с результатами;
    • автоматизированное тестирование может выявить те ошибки, которые не удалось найти методом ручного тестирования, за счет бОльшего покрытия кода;
    • позволяет собрать общее представление о защищенности тестируемого кода.

    Одним из нашумевших случаев, когда фаззинг сделал свое доброе дело, можно назвать обнаружение пятидесяти CVE в Adobe Reader за 50 дней. Исследователи смогли найти такое количество уязвимостей, не имея доступа к исходному коду, и трудно предположить, сколько их обнаружилось бы, будь у них исходники.

    Если поискать в открытых источниках информацию на тему использования фаззинга среди разработчиков, то первым попадется Microsoft. Эта компания — одна из пионеров фаззинга в SDLC. У них есть Security Risk Detection — сервис, позволяющий пользователям загружать бинарные файлы для их фаззинга. То, какие данные будут подаваться на вход, решает пользователь. Итогом работы фаззера являются найденные ошибки и данные, которые их породили.

    Google тоже использует фаззинг, и у них есть очень много инструментов в открытом доступе. Наиболее интересный из них — OSS-Fuzz. Его суть в том, что любой человек может сделать пулл реквест со своим фаззером. Обычно это фаззеры, когда-то созданные разработчиками для своих небольших проектов. Помимо этих фаззеров, Google использует ClusterFuzz для обнаружения ошибок в Chrome. За несколько лет было обнаружено более 16 тысяч уязвимостей в браузере и более 11 тысяч в 160 опенсурсных проектах.

    Некоторые компании, разрабатывающие софт, предоставляют всем желающим ночные сборки для фаззинга. Так делает Mozilla и VLC. Любой желающий может скачать сборку и попробовать поискать в ней ошибки и уязвимости.

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

    Вопросы мы задали следующие:

    Используете ли вы fuzzing в процессе разработки своих продуктов?

    На этот вопрос положительно ответила треть респондентов.

    Если не используете, то почему? Или что, на ваш взгляд, обычно останавливает от включения этапа fuzzing в процесс разработки продукта?

    Возможные варианты ответа:

    1. Нечего фаззить
    2. Безопасность продукта не является приоритетной задачей
    3. Отсутствуют подходящие инструменты
    4. Отсутствуют соответствующие специалисты
    5. Отсутствует соответствующая инфраструктура
    6. Другое

    Респонденты могли выбрать сразу несколько причин отказа от использования фаззинга в процессе разработки.

    На диаграмме показано процентное соотношение актуальности причин отказа от фаззинга в процессе разработки.

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

    Некоторые из опрошенных, выбравшие вариант ответа «Другое», дали интересные развернутые ответы. Вот некоторые из причин отказа от фаззинга:

    • отдел информационной безопасности не оценил инициативу одного из разработчиков написать свой фаззер;
    • отсутствие методик ФСТЭК по поиску уязвимостей.

    Среди ответов были и уточнения о том, что используются AFL-фаззеры и libfuzzer-ы, что не может не радовать.

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

    Больше интересных статей

    Подпишитесь на наши обновления

    Узнавайте все новости первыми

      Мы используем куки. Никогда такого не было, объясните

      ОК