Лучшая защита – это нападение, причем на себя любимого. Все чаще бизнес выстраивает информационную безопасность именно по такому принципу. Своевременный пентест или Read Teaming, когда привлеченные подрядчики пытаются взломать корпоративную IT-инфраструктуру, помогает команде ИБ заранее обнаружить и закрыть бреши и сделать организацию по-настоящему неприступной для реальных злоумышленников. Однако Offensive Security не лишен нюансов и подводных камней.

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

Offensive Security обсуждали:

Дмитрий Калинин. Руководитель отдела по работе с уязвимостями информационных систем в Бастион.
Егор Зайцев. Директор департамента противодействия киберугрозам в «Информзащита».
Сергей Куприн. Генеральный директор «CTRLHack».
Юлия Воронова. Директор по консалтингу центра компетенции в Positive Technologies.
Александр Борисов. Руководитель направления по анализу защищенности в INNOSTAGE.
Модератор – Сергей Рысин, независимый эксперт.

Вопрос 1. Для чего нужен Offensive Security?

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

Юлия Воронова. Даже самая слаженная и квалифицированная команда ИБ не может со всей уверенностью утверждать, что подконтрольная ей инфраструктура неприступна. Единственный способ проверить это – нанять тех, кто попытается взломать сеть.

Форматы работы возможны разные в зависимости от особенностей бизнеса и прочих деталей: пентест, Read Teaming или что-то еще. Но глобальная цель одна – найти возможные пути реализации недопустимых для бизнеса событий.

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

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

Сергей Куприн. Как показывает статистика, 95% успешных кибератак в мире на деле можно предотвратить имеющимися у компаний ресурсами. Без регулярной валидации того, что выстроенная система цифровой безопасности работает правильно, любые средства защиты используются лишь на 40 – 50%. И Offensive Security позволяет добиться от них максимальной эффективности.

Дмитрий Калинин. От себя дополню, что часто в компаниях применяются самые современные средства защиты и трудятся первоклассные ИБ-специалисты. Но они действуют бессистемно и «латают дыры», поскольку не выстроены процессы. Offensive Security, помимо прочего, помогает увидеть эти процессные недочеты, чтобы правильно организовать работу команды.

Егор Зайцев. Конечные цели Offensive Security могут различаться в зависимости от отраслевой специфики бизнеса. Возьмем для примера сектор KИИ горнодобывающей промышленности. Где-нибудь в забое на АСУ ТП у сотрудников не всегда есть физическая возможность внедрять средства защиты, обновлять ПО или хосты. В этом случае чисто технологически нельзя говорить о полном устранении определенных рисков. Нужно хотя бы проинформировать о них заказчика, чтобы у того было четкое представление, через какие именно бреши ожидать незваных гостей и как реагировать в подобных ситуациях.

Вопрос 2. Чему уделить внимание при обращении к подрядчикам за мероприятиями Offensive Security?

Юлия Воронова. «Сделайте мне пентест или Read Teaming» – неверная постановка вопроса. Для начала следует определиться с целеполаганием и сформулировать конкретные задачи подрядчику исходя из потребностей бизнеса. Например, нужно понять, насколько вообще сложно взломать инфраструктуру на текущий момент, есть ли в сети zero day и другие эксплойты. Или, опять же, требуется выявить зоны развития собственной команды ИБ.

Одновременно заказчику необходимо четко сформулировать для себя самого и подрядчика недопустимые для бизнеса события без погружения в технические детали. Как все это «ложится» на информационные системы, что именно проверять, какие векторы и форматы (пентест, Read Teaming или еще что-то) для этого использовать – уже решит сам подрядчик. Здесь лучше доверится его опыту и экспертизе, если, конечно, таковые имеются.

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

Егор Зайцев. Иногда и сам заказчик может определить, какие форматы Offensive Security для него предпочтительны, чтобы не переплачивать и не усложнять себе жизнь. Скажем, если бизнес находится в становлении, а процессы не достигли высокой зрелости, бессмысленно заказывать услугу Read Teaming. Это преждевременно и слишком дорого. Лучшим решением будет так называемый Purple Teaming, когда «красная команда» взаимодействует с внутренним SOC заказчика. Вместе они при помощи автоматизации выявляют некое процентное покрытие сети средствами защиты. Лишь когда оно станет оптимальным, а собственная команда ИБ перейдет на новый уровень зрелости, в пору проводить полноценный Read Team-проект. До этого вполне хватит упомянутого Purple и пентестов.

Вопрос 3. Как выбрать подрядчика по Offensive Security и проверить его компетенции?

Юлия Воронова. Все очень просто. Нужно изучить портфолио подрядчика и посмотреть его статистику по успешным и провальным проектам за предыдущий год или другой период. Если у него статистика пробоев сетей, допустим, 30% – это повод насторожиться.

Александр Борисов. Хороший знак – когда специалисты подрядчика работают по общепризнанным и зарекомендовавшим себя фреймворкам, таким как AVASP или OSCTM. Они дают хорошую точку входа для общения с исполнителем, помогают составить примерный чек-лист важных вопросов на старте. Впрочем, следование данным фреймворкам не обязательно означает достижение всех целей по Offensive Security. Ни один подход не учитывает любые возникающие на практике нюансы.

Дмитрий Калинин. Также из актуальных фреймворков, использование которых говорит в пользу подрядчика, хотел бы упомянуть ISAF и BTS. Они относятся непосредственно к проведению инфраструктурных пентестов.

Соглашусь с коллегой, что все эти подходы – не стопроцентная гарантия на успех и не пошаговая инструкция для пентестеров или других специалистов. Желательно, чтобы команда подрядчика сформировала на базе таких фреймворков и своего проектного опыта собственную методологию и рассказала о ней заказчику. Для последнего работа исполнителей станет более прозрачной, появится понимание реализуемых процессов.

Сергей Куприн. Если говорить не о точечном пентесте, а о длительном Read Team-проекте, то заказчику не повредит хотя бы концептуальное знакомство с матрицами MITTRE ATT&CK. Тогда представители бизнеса смогут общаться с подрядчиком на одном языке и оценить по достоинству применяемые техники.

Вставлю свои пять копеек и в пользу автоматизированных BAS-систем, то есть инструментов симуляции кибератак. Когда заказчик имеет опыт работы с подобными решениями, будь то Open-source-продукты или ПО уровня энтерпрайз, у него есть базовое понимание атакующих техник. Значит, ему проще сориентироваться и досконально расспросить обо всем подрядчика.

Егор Зайцев. Важно и наличие у подрядных исполнителей базовых сертификатов: OSCP, OSEP. Такие документы, как минимум, говорят о знакомстве специалиста с основами Read Teaming.

Вопрос 4. Всегда ли бизнесу нужен Offensive Security?

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

Если упростить, то киберпреступникам для их черных дел необходимо, чтобы в инфраструктуре имелись сетевые уязвимости вроде one day или zero day, не сработали как нужно средства защиты и специалисты по ИБ. В отдельных случаях ретроспективного анализа оказывается достаточно для вынесения вердикта о том, имеются ли подобные окна возможности у злоумышленников.

Модератор. Я бы добавил, что прежде всего у хакеров должен быть интерес к компании. Если она не обрабатывает данные, которые представляют хоть какую-то ценность для киберпреступников, то заниматься Offensive Security незачем.

Егор Зайцев. И снова нужно учитывать зрелость и масштабы бизнеса. Молодой компании с инфраструктурой, скажем, в 200 хостов нет никакого смысла рваться с места в карьер. Сначала нужно выстроить собственные процессы и наладить работу внутреннего SOC.

Александр Борисов. Перед обращением к подрядчику за услугами Offensive Security неплохо «выжать» максимум из собственных средств защиты и аналитики. Так, уже упомянутые BAS-системы позволяют оценить, как функционируют команда ИБ и СЗИ, какое у последних покрытие, справились они в критической ситуации или нет и т. д. Когда такая внутренняя работа налажена и поставлена на поток, можно привлекать внешних исполнителей и полноценно заниматься наступательной кибербезопасностью.

Вопрос 5. Как строится взаимодействие при пентестах и Read Teaming?

Сергей Куприн. Я бы условно разграничил «епархии» пентестов и Read Teaming следующим образом. Первые – это мероприятия, которые помогают выявить уязвимости, мисконфиги в инфраструктуре. Read Teaming же показывает, как условный злоумышленник будет использовать выявленные слабые стороны сети при APT-атаке и как на это ответит команда ИБ, а заодно и средства защиты.

Дмитрий Калинин. Еще один важный нюанс в том, что Read Teaming обычно проводится без предупреждения внутренней службы ИБ-компании (синей команды или blue team). В то время как при пентестах «синяя» команда обязательно информируется обо всем происходящем. Делается это хотя бы для того, чтобы защищающиеся смогли отличить работу пентестеров от реальной APT-атаки, если такая по стечению обстоятельств произойдет в данное время.

Александр Борисов. В ходе пентестов заказчик не всегда следит за каждым шагом подрядчика. Но, как минимум, есть контрольные точки, когда обсуждаются детали. Помимо чисто практической пользы, здесь важен и психологический аспект. Заказчик хочет знать, что происходит, насколько устойчива его сеть. Иногда нужно его попросту успокоить, обеспечив полную прозрачность процесса.

Что касается непосредственно повышения защищенности клиентской инфраструктуры, то зачастую это долгая и муторная работа в формате Purple Teaming. Условно говоря, подрядчик садится за стол с внутренней командой ИБ и говорит: «Пока вы пили свой утренний кофе, я смог получить доступ к вашей CRM-системе со всеми ее драгоценными данными. Давайте подумаем вместе, как получше защитить этот критичный для бизнеса сервис». Подобных примеров можно привести массу, но общий контекст взаимодействия примерно такой.

Егор Зайцев. Бывает, что внутренняя команда пентестеров заказчика взаимодействует с внешней Read Team. Тогда не помешает проводить обучение по итогам работ – некий «разбор полетов».

Вопрос 6. Какие эпичные и курьезные случаи происходят во время мероприятий по Offensive Security?

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

Дмитрий Калинин. Вспоминается кейс, когда мы в ходе пентеста искали валидные учетки у заказчика и между делом решили «клацнуть» на иконку специальных возможностей на экране приветствия. Увиденное нас, мягко говоря, удивило. Открылось окно командной строки с системными привилегиями, после чего сеть была полностью скомпрометирована. Скорее всего, сами администраторы заказчика когда-то сбрасывали пароли и забыли за собой «подчистить», оставив злоумышленникам даже не лазейку, а открытые ворота.

Юлия Воронова. Из эпичного на ум приходят случаи, когда в ходе реализации бизнес-рисков на эндпойнте бухгалтера вдруг обнаруживается Excel-таблица, где подробно расписаны все роли по процессам и финансовым операциям (кто за что отвечает, согласующие лица и т. д.). По сути, это пошаговая инструкция для злоумышленника, как без проблем вывести денежные средства из организации и согласовать любую платежку.

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

В ходе одного проекта нам удалось без предварительной подготовки проникнуть на территорию крупной киностудии, не имея никаких доступов и пропусков. В итоге мы с легкостью реализовали главные бизнес-риски заказчика: «захватили» серверную, эфирную и кабинет генерального директора, где хранятся самые критичные для бизнеса данные.

Вопрос 7. Как часто нужно проводить мероприятия по Offensive Security?

Егор Зайцев. Пожалуй, «физику» стоит выполнять примерно два раза в год. Во-первых, на основе регулярных тестов мы можем разработать для заказчика определенную методологию по физической защите IT-инфраструктуры. Во-вторых, такие проверки помогают противодействовать еще и проникновениям в сети с помощью различных гаджетов, которые постоянно развиваются и совершенствуются. Взять хотя бы случаи применения мультитулов Flipper Zero для взломов. Вспоминаются и кейсы, когда злоумышленник «хекал» инфраструктуру через СКУД, используя так называемое Crazyradio в связке со смартфоном.

Переходя к стандартным мероприятиям по Offensive Security, я бы рекомендовал порядка 3 пентестов и одного Read Teaming ежегодно. После каждого пентеста следует проводить дополнительную проверку уязвимостей по факту их устранения.

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

Юлия Воронова. Все зависит от масштаба IT-инфраструктуры и зрелости бизнеса. Крупным корпорациям с развитыми процессами я бы вообще советовала проводить Read Teaming нон-стоп. Если это слишком накладно или нецелесообразно по мнению бизнеса, менее затратной альтернативой станет объявленное Bug Bounty по недопустимым событиям в инфраструктуре с адекватным вознаграждением.

Дмитрий Калинин. Профилактический пентест мы рекомендуем устраивать хотя бы раз в год. Стоит проводить такие мероприятия и ситуационно, например, если произошла успешная APT-атака и в инфраструктуру проникли. Тогда после нейтрализации инцидента не помешает проверить, а можно ли взломать сеть еще какими-то способами. Другой повод для внепланового пентеста – существенные пертурбации в инфраструктуре в связи с открытием новых филиалов, слияниями и поглощениями компаний и т. д.

Александр Борисов. Не будет лишним внеочередной пентест и при смене топ-менеджмента: IT-директора, руководства службы ИБ и т. д. Одно дело, что рассказывают тебе коллеги о степени защищенности сети, другое – результаты конкретной проверки беспристрастными внешними экспертами. Периодичность же плановых пентестов во многом зависит от возможностей самого заказчика: как быстро он сможет отработать собранные в отчете рекомендации по укреплению сети.

Вопрос 8. Насколько быстро устраняются выявленные у заказчиков проблемы на практике и как это проверяется?

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

Сергей Куприн. Если говорить про устранение уязвимостей при помощи BAS-решений, то это непрерывный процесс. Когда у специалистов ИБ есть время, они всегда могут запустить систему, затюнить ее и начать проверять стойкость инфраструктуры, изучать, как закрепляется атакующий.

Юлия Волкова. Проблемы, связанные с эксплойтом one day, обычно устраняются за сутки. Мы исправляем все сразу, не дожидаясь окончания работ и подготовки финального отчета. Заказчику предоставляется краткая справка о данной уязвимости. Когда дело в zero day, уже предлагаем услугу Read Teaming и рекомендуем тренировать «команду синих» противостоять таким атакам.

Иногда проблема вообще не устраняется. Чаще всего так происходит, если заказчик не считает найденную уязвимость критичной и предпочитает закрыть на нее глаза.

Отмечу, что мы принципиально не проводим контроль устранения по итогам пентестов. Ведь главное – не отдельные уязвимости, а причины их возникновения и векторы атаки. Именно последние мы и ищем в ходе проверок. Если нужно посмотреть, как в итоге изменился вектор, то проводим полноценный повторный пентест.

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

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

Александр Борисов. Нейтрализация проблем длится от нескольких дней до… бесконечности. Как уже отметили коллеги, не все уязвимости заказчик бросается устранять. Тут встает вопрос: а разъяснили ли мы ему реальную критичность обнаруженных багов и брешей в защите?

Доходит до комичного. Однажды мы в ходе пентеста добрались до критичной CRM-cистемы организации и увидели, что она в режиме дебага раскрывает пароли с ФИО пользователей в plain-text. Мы сразу же отрапортовали обо всем заказчику, и уже через два дня баг устранили. Каково было наше удивление, когда через месяц на ретесте уязвимость всплыла снова. В подобных ситуациях приходится разбираться в клиентских процессах и даже помогать их оптимизировать.

Вопрос 9. Имеет ли значение объем отчета по итогам мероприятий Offensive Security?

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

Дмитрий Калинин. Сам по себе объем отчета не является критерием его качества. Документ должен быть, прежде всего, понятным для заказчика. Но, даже если в ходе мероприятий по Offensive Security не удалось выявить ничего критичного, отчет не может состоять из нескольких страниц. В нем следует хотя бы расписать предпринятые меры, последовательность выполненных шагов и их результаты, обозначить проверенные сервисы и участки инфраструктуры.

Александр Борисов. Соглашусь, что количество страниц – еще не показатель хорошего или плохого отчета. Главное – это польза и доступность изложенной информации. Как служба ИБ, так и системные администраторы заказчика должны понимать представленные в документе выводы и рекомендации.

Вопрос 10. Как не нужно проводить пентест или Read Teaming?

Сергей Куприн. Думаю, не стоит проводить пентест или Read Teaming просто для галочки, без четкого плана и целеполагания.

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

Дмитрий Калинин. Не нужно «сорить» и оставлять в инфраструктуре заказчика следы компрометации, созданные пентестерами учетные записи и т. д. Как минимум, это неэтично. К тому же такая «нечистоплотность» может в дальнейшем привести к ненужным инцидентам в части ИБ.

Егор Зайцев. Большая ошибка со стороны подрядчика – забыть обсудить основные риски с заказчиком. Допустим, у последнего «торчат наружу» жизненно важные для производственных и других процессов сервисы, и даже минутное прерывание их работы выливается в серьезные материальные потери для бизнеса. Если не проговорить такие моменты «на берегу», команда подрядчика рискует не просто вызвать недовольство клиента, но и нарваться на серьезные штрафные санкции.

Юлия Воронова. Мне на ум скорее приходят советы, как не нужно вести себя заказчику. Иногда он требует, чтобы команда пентестеров или Read Team действовала по его методологии и даже сам расписывает каждый шаг. Так делать точно не стоит: лучше довериться внешним экспертам и предоставить им свободу действия в пределах разумного. Да и вообще любые моменты, которые заказчик просит учесть на старте проекта, должны быть обоснованными, а не просто опираться на «хотелки».

Вопрос 11. Можно ли в рамках пентестов использовать разработанное подрядчиком ПО для обхода систем защиты?

Александр Борисов. На мой взгляд, не только можно, но и нужно. Ведь это часть той самой внутренней экспертизы подрядчика по Offensive Security, за которой к нему и обращается заказчик.

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

Сергей Куприн. Разумеется, без специализированного ПО никуда. Без него невозможно имитировать APT-атаку и создать необходимые для работы артефакты в инфраструктуре.

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

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

Вопрос 12. Как оценить проделанную работу по Offensive Security?

Юлия Воронова. У нас в компании для этого используются специальные метрики и критерии. Прежде всего, должна быть полностью исключена возможность реализации любого недопустимого для бизнеса события в части ИБ. Добиваемся мы и того, чтобы взломать инфраструктуру получалось только с использованием zero day. Если векторы с one day и другими эксплойтами все еще представляют угрозу, значит работа не выполнена.

Егор Зайцев. Соглашусь, что парирование угрозы недопустимых событий – существенный показатель эффективности Offensive Security. Добавлю сюда время выявления уязвимостей и реализации мер по их устранению.

Дмитрий Калинин. Дополню, что нужно оценивать еще и полноту проделанной работы. Даже если цели мероприятий по каким-то причинам не достигнуты, важно понимать, что и в каком объеме вообще было выполнено подрядчиком.

Вопрос 13. Занимаются ли специалисты по Offensive Security только одним или сразу несколькими проектами в моменте?

Егор Зайцев. У нас в ходе Read Teaming команда закрепляется за одним проектом и занимается исключительно им. Ведь цели таких работ крайне масштабны: нужно найти различные векторы атак, подробно их описать. В рамках пентеста все куда проще и скромнее – достаточно «пробить» инфраструктуру заказчика. Здесь уже возможно параллельное участие специалистов в целом ряде проектов.

Юлия Воронова. Чтобы качественно выполнить Read Teaming, необходимо полное погружение 10 – 12 специалистов в один проект в режиме full-time. Речь не только непосредственно о пентестерах, но и об аналитиках. Иногда по ситуации привлекаются дополнительные участники, которые работают сразу над несколькими проектами. Это могут быть команды эксплойт-девелопмента или специалисты по взлому каких-то узкоспециализированных систем.

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

Александр Борисов. Мы закрепляем каждую команду только за одним проектом, будь то пентест или Read Teaming. Другое дело – Purple Teaming: тут вполне возможно совмещение.

Вопрос 14. Приведите примеры случаев, когда заказчик был недоволен результатами проделанной работы по Offensive Security

Егор Зайцев. Львиная доля таких эпизодов связана с тем, что заказчику нужны какие-то дополнительные работы, которые не проговаривались на старте и не отражены в договоре. Часто мы идем навстречу клиенту и выходим за очерченные рамки проекта. Когда подобное не представляется возможным, стараемся сгладить углы и максимально корректно донести свою позицию до заказчика. Так или иначе, выход находится из любой спорной ситуации.

Сергей Куприн. В ходе одного из пилотов мы запустили у заказчика проверки при помощи нашей BAS-системы. Оказалось, что антивирус попросту не видит большую часть сформированных нами артефактов. Сперва ИБ-специалисты заказчика нам не поверили и потребовали дополнительных доказательств. Мы выполнили проверку повторно, но уже в более тесном взаимодействии с клиентским SOC. Только тогда его сотрудники убедились, что никто их не обманывает.

Юлия Воронова. Нередко трения клиентов с нами на самом деле объясняются их разочарованием в собственной инфраструктуре. Заказчик потратил немалые средства на повышение кибербезопасности, проделал серьезную работу и уверен, что корпоративная сеть неприступна. И тут он получает отчет о ее уязвимостях на 400 или 800 страниц. Начинается классическая психологическая цепочка: отрицание, гнев, торг, депрессия, принятие.

Порой клиентская служба ИБ воспринимает итоги нашей работы как упрек в свой адрес: «Вы виноваты, вы не справились». Стараемся сразу обговорить с заказчиком, что цель Offensive Seсurity – не обвинить или наказать кого-либо. Это совместная работа, когда клиент и подрядчик находятся «в одной лодке».

Дмитрий Калинин. Мы тоже стремимся еще на старте проекта обсудить все скользкие моменты, чтобы избежать претензий в свой адрес. Но случается разное. Как-то мы проводили пентест в одной крупной и зрелой компании, которая уже далеко не первый раз занималась Offensive Security. Объективно не найдя серьезных брешей и уязвимостей, мы предоставили заказчику практически «зеленый» отчет. Более того, до этого компания обращалась еще к нескольким подрядчикам, и результаты оказались аналогичные. Заказчик никак не мог поверить в то, что его сети так хорошо защищены, и обвинял нас и других исполнителей в некомпетентности.

Александр Борисов. Чаще всего «красной тряпкой» становится отчет по итогам пентеста или Read Teaming. Первым делом мы утверждаем у заказчика форму и наполнение будущего документа, и только после этого приступаем к работе. И все же, когда дело доходит до практики, иногда возникают вопросы. Заказчику требуется добавить в отчет какие-то моменты, чтобы ему было удобнее отрабатывать рекомендации и выстраивать свои внутренние коммуникации. Обычно мы подстраиваемся под запросы клиента и вносим в документ нужные корректировки.

Вопрос 15. Как проходит процесс изучения и развития уязвимостей и эксплойтов?

Сергей Куприн. У нас как у вендора BAS-систем нет задачи писать какие-то новые эксплойты, находить zero day и т. д. Мы просто берем существующие инструменты, об эксплуатации которых есть информация в публичном доступе, обкатываем их на стендах, добавляем себе в систему и автоматизируем. Тем самым мы даем возможность клиентам проводить проверки в своей инфраструктуре. Какие-то проблемные эксплойты (например, zerologon) мы вообще не даем эксплуатировать в системе, а просто обозначаем, что такие имеются.

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

Егор Зайцев. Наверное, вопрос был прежде всего о PoC, которые отражают механику уязвимости, но не дают какого-то импакта. Да, каждый поставщик услуг Offensive Security должен заниматься написанием эксплойтов из PoC. Следует расширять их функционал, автоматизировать какие-то шаги, что позволит ускорить и упростить эксплуатацию таких инструментов.

Дмитрий Калинин. Обкатанные эксплойты мы применяем прямо в инфраструктуре заказчика без дополнительного изучения. Менее известные – сперва апробируем у себя на стендах. Зачастую дорабатываем взятые из паблика эксплойты, чтобы использовать их более эффективно.

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

Вопрос 16. Как будет развиваться Offensive Security в течение ближайшего года?

Александр Борисов. Лично я надеюсь, что продолжат набирать популярность автоматизированные BAS-системы. Они помогают бизнесу эффективно выстроить защиту и повышают прозрачность инфраструктуры. Как итог, служба ИБ экономит время и успешно предотвращает инциденты.

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

Юлия Воронова. Мне кажется, в краткосрочной перспективе хороший потенциал имеет практика Bug Bounty. Не потеряет своей актуальности и Read Teaming. Пентест же медленно, но верно отходит на второстепенные позиции. Средства защиты постоянно совершенствуются и усложняются, и такой формат далеко не всегда позволяет реализовать все их возможности.

Сергей Куприн. Думаю, на ближайшее время можно прогнозировать развитие концепции Purple Teaming, в фокусе которой не просто наличие или отсутствие каких-то уязвимостей. Подобная планомерная работа дает ИБ-специалистам лучшее понимание механизмов APT-атак и способов им противодействовать.

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

Все об Offensive Security: о чем говорили на круглом столе AM Life