Каким должен быть «ящик» в проекте по анализу защищенности

Анализ защищенности, тесты на проникновение, ASV-сканирование — все это нестареющие темы. Предложений на рынке хватает, и каждый исполнитель предлагает свою методику: простое сканирование на наличие уязвимостей или тесты на проникновение, исследование «черным», «серым» или «белым ящиком», DDoS-атаки, фишинговые рассылки, «дорожное яблоко» и множество других опций на выбор. Очевидно, что не все методики одинаково полезны и выбор должен зависеть от преследуемой цели. Давайте же попытаемся разобраться, как наиболее оптимальным образом сформулировать задачу по анализу защищенности.

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

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

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

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

У врачей есть хорошая поговорка: «Не бывает абсолютно здоровых людей, бывают недообследованные». Так и с уязвимостями. Никогда нельзя быть полностью уверенным в их отсутствии. Рано или поздно уязвимости обнаруживаются почти в каждом приложении. Весь вопрос в том, сколько усилий нужно приложить для поиска очередной уязвимости.

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

В общем случае метод тестирования должен также выбираться исходя из критичности приложения. Иногда достаточно автоматизированного тестирования. Более эффективным, но и более затратным является исследование на уровне исходных кодов. Для критичных приложений рекомендуется встраивать процедуры анализа безопасности в цикл разработки приложения. Общее правило таково: чем больше исходных данных будет у исследователя безопасности, тем больше уязвимостей будет найдено.

Тесты на проникновение и ASV-сканирование включены во многие стандарты по информационной безопасности как обязательные процедуры. Например, соответствие стандарту PCI DSS предполагает проведение ASV-сканирования не реже, чем раз в квартал. Стандарт ISO/IEC 27001 включает в себя дисциплину по управлению уязвимостями. Приказ ЦБ России №382-П содержит требования по применению организационных мер или технических средств для выявления и предотвращения эксплуатации уязвимостей. Оценка защищенности также включена в качестве императивного требования в состав 17-го, 21-го и 31-го приказов ФСТЭК.

Поскольку такие тесты выполняются, что называется, «для галочки», часто задача формулируется в минимальном объеме. Без излишеств. Главное, чтобы полученные результаты были применимы в целях compliance.

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

На этом — все. Ставьте правильные цели и выбирайте оптимальные пути их достижения. Удачи!

Артур Котылевский
Директор по развитию бизнеса, Акрибия