В этом разделе мы подробно обсудим, как подготовить вашу организацию к запуску и реализации успешной программы раскрытия уязвимостей, включая практические советы о том, как заполнить выявленные вами пробелы.
Поиск ошибок
Дополнение существующей программы безопасности сторонними исследователями безопасности — отличный способ найти сложные проблемы и скрыть уязвимости. Однако использование VDP для поиска основных проблем безопасности, которые могут быть обнаружены внутри компании, является пустой тратой ресурсов.
Управление активами
Когда дело доходит до поиска ошибок, единственный способ узнать, с чего начать, — это иметь хорошее представление о том, что там происходит. Вы можете купить сотню инструментов безопасности, но это не будет иметь никакого значения, если команды будут запускать приложения, системы и сервисы без вашего ведома, особенно если у вас нет способа обнаружить и выполнить оценку безопасности на их основе. ресурсы. Свяжитесь с отдельными лицами и командами, которые отвечают за поддержку новых приложений, систем и сервисов, чтобы узнать, есть ли у них процесс создания и ведения реестра того, что создается и кому это принадлежит. Если текущего процесса еще нет, это прекрасная возможность сотрудничать с этими командами для его создания. Лучшее начало при определении поверхности атаки — это понимание активов вашей организации. В рамках этого процесса группа безопасности должна участвовать в разработке реализации новой инфраструктуры для проведения проверок безопасности . Хорошей практикой является наличие обширной инвентаризации активов и владельцев. Этот вид инвентаризации полезен при применении новых исправлений, которые требуют временного отключения определенных систем. Он представляет собой дорожную карту отдельных лиц или групп, которых необходимо проинформировать, и какие системы затронуты. Наличие надежного процесса управления активами гарантирует, что владельцы будут идентифицированы на ранней стадии процесса, будут регулярно обновляться и что все системы в организации будут работать должным образом.
В дополнение к упреждающему управлению активами подумайте, какие ответные меры вы можете принять, а также выявить активы, которые принадлежат вашей организации, но ускользнули из ваших стандартизированных процессов управления активами. Это может включать в себя использование тех же «разведывательных» процессов, которые используются исследователями безопасности, которые участвуют в VDP и программах вознаграждения за обнаружение ошибок . Например, вы можете использовать бесплатные инструменты с открытым исходным кодом, которые сканируют и подсчитывают диапазоны IP-адресов или домены, выходящие в Интернет, которые могут принадлежать вашей организации. Поиск в Google по запросу bug bounty recon выдаст множество советов и подсказок, которые помогут вам выявить активы вашей организации, о которых вы не знали.
Базовое сканирование уязвимостей
Теперь, когда у вас есть прочная основа для поиска проблем безопасности, давайте углубимся в то, как вы на самом деле это делаете. Существуют различные уровни глубины, которые вы можете изучить в зависимости от ресурсов вашей организации, но вам необходимо найти баланс между вашими внутренними усилиями по обеспечению безопасности и внешним хакерским сообществом с помощью вашей программы раскрытия уязвимостей. Этот баланс различен для каждой организации и зависит от имеющихся ресурсов.
Выберите свои инструменты
Существует множество различных инструментов, помогающих выявить уязвимости. Некоторые инструменты сканирования уязвимостей доступны бесплатно, а другие — за дополнительную плату. Выбор инструментов зависит от ваших индивидуальных потребностей.
- Требования вашей организации
- Насколько хорошо каждый инструмент удовлетворяет этим требованиям
- Если польза от инструмента перевешивает затраты (финансовые и реализацию).
Вы можете использовать этот шаблон требований ( OpenDocument .ods , Microsoft Excel .xlsx ) для оценки различных инструментов на соответствие вашим требованиям. Некоторые примеры требований включены в шаблон, но вам следует обсудить их с отделами безопасности, ИТ и инженерами, чтобы согласовать необходимые возможности. Прежде чем запускать программу раскрытия уязвимостей, вам как минимум необходимо иметь возможность выполнять сканирование уязвимостей любых внешних ресурсов (таких как веб-сайты, API, мобильные приложения). Это поможет вам найти и устранить легко обнаруживаемые уязвимости, прежде чем приглашать внешних исследователей безопасности для тестирования этих активов и сервисов.
Настройка сканирования
Автоматическое сканирование уязвимостей может обнаружить множество проблем, но оно также может давать ложные срабатывания. Вот почему необходимо иметь ресурсы для проверки результатов, прежде чем делиться ими с затронутыми командами. Вам потребуется внедрить процессы, обеспечивающие регулярное выполнение проверок и фактическое рассмотрение результатов этих проверок. Для каждой организации это будет выглядеть по-разному, но вам необходимо как минимум определить:
- Частота сканирования
- Непрерывный
- Еженедельно
- Ежемесячно
- Какие активы сканируются
- Реквизиты для входа
- Сканирование с аутентификацией и без аутентификации
- (подсказка: если вы не сканируете с использованием учетных данных, а затем исследователь безопасности проверяет учетные данные при запуске VDP, вы можете получить большой всплеск выявленных уязвимостей)
- Роли и обязанности
- Определите членов команды, ответственных за выполнение сканирования.
- При необходимости настройте ротацию
- Результаты сканирования
- Проверка результатов сканирования
- Регистрация ошибок для проверенных уязвимостей
- Определение владельцев для исправления ошибок
- Консультирование владельцев по поводу ремонта
Мы более подробно рассмотрим, как обеспечить устранение выявленных проблем безопасности, в разделе «Исправление ошибок» далее в этом руководстве.
Процесс проверки безопасности
Хотя сканирование уязвимостей — отличный способ оперативно выявить проблемы безопасности в вашей организации, внедрение процессов проверки безопасности может помочь предотвратить появление уязвимостей в первую очередь. В данном руководстве термин « проверка безопасности» относится к любой ситуации, которая требует ручной проверки членом вашей команды безопасности. Обычно это включает в себя право блокировать изменение, если оно считается слишком рискованным. Если ваша команда безопасности не имеет возможности блокировать рискованные изменения, вам все равно потребуется иметь процессы для документирования риска. Это может помочь гарантировать, что тот, кто настаивает на изменениях, знает о связанном с этим риске и активно принимает этот риск.
Критерии проверки безопасности
Когда следует проводить проверки безопасности? Создание набора критериев, запускающих проверку безопасности, помогает гарантировать, что все находятся на одной волне. Ниже приведены несколько примеров сценариев, которые могут вызвать проверку безопасности.
- Предлагается новый функционал, связанный с конфиденциальными данными пользователей.
- Новая функция, которая позволяет пользователям делиться своим местоположением на карте.
- Запрос потенциально конфиденциальной информации от пользователей, такой как их домашний адрес, дата рождения или номер телефона.
- Выполнены крупные обновления существующего функционала.
- Взять существующие пользовательские данные и использовать их по-новому, чего пользователи могут не ожидать, не давая им возможности отказаться.
- Изменения любых функций, связанных с аутентификацией, авторизацией и управлением сеансами.
- Изменения в производственной среде компании
- Изменения конфигурации сети, особенно изменения, которые могут привести к внешнему доступу к службам.
- Установка нового программного обеспечения, которое обрабатывает конфиденциальные пользовательские данные, которое в случае взлома может быть косвенно использовано для доступа к конфиденциальным пользовательским данным.
- Внедрение новых систем или услуг
- Взаимодействие с новым поставщиком или изменение способа работы с существующим поставщиком.
- Привлечение нового поставщика, который будет обрабатывать конфиденциальные данные пользователей.
- Изменения в работе с существующим поставщиком, в результате которых поставщик обрабатывает конфиденциальные пользовательские данные.
Это не исчерпывающий список, но он должен заставить вас задуматься о том, какие изменения требуют проверки безопасности. Определив критерии того, что требует и не требует проверки безопасности, обсудите это с ключевыми заинтересованными сторонами в организации, чтобы гарантировать:
- Заинтересованные стороны имеют возможность рассмотреть критерии и оставить отзыв о них.
- Заинтересованные стороны согласны с критериями
- Заинтересованные стороны соглашаются активно запрашивать проверки безопасности
Задокументируйте эти критерии, а также то, как запросить проверку безопасности (например, внесение ошибки в очередь, которую контролирует группа безопасности), чтобы вашей организации было как можно проще следовать этому процессу.
Ресурсы для проверки безопасности
В отличие от автоматического сканирования, проверки безопасности могут требовать больше ресурсов. У каждой команды безопасности есть ограниченное количество времени в день для выполнения множества задач, поэтому вам нужно будет оценить, сколько проверок безопасности может быть создано на основе ваших критериев. Если вы обнаружите, что ваша команда перегружена и отстает, те, кто ждет запуска своих функций, будут недовольны командой безопасности. Это может вызвать культурный сдвиг в организации, в результате чего команду безопасности будут рассматривать как блокирующую, а не как партнера. Если процесс проверки безопасности неэффективен, многие люди и команды попытаются полностью его обойти. Если ресурсы ограничены, рассмотрите возможность смягчения критериев требования проверки безопасности и будьте готовы принять еще один остаточный риск. Если инциденты действительно происходят из-за нехватки ресурсов для проведения проверок безопасности, это поможет оправдать потребность в дополнительных ресурсах безопасности.
Проведение проверок безопасности
Когда дело доходит до принятия решения о том, какие проверки безопасности выполнять и как их выполнять, вам понадобится очередь с приоритетами, из которой можно будет извлечь данные. Создайте стандартизированный способ, позволяющий другим сотрудникам вашей организации запросить проверку безопасности, предоставив любую информацию, которая вам потребуется, чтобы правильно расставить приоритеты. Например, рассмотрим анкету, включающую такие вопросы, как характер изменения, включая краткое описание изменения и типы пользовательских данных, которые могут быть затронуты. Вы можете автоматически классифицировать потенциальные проверки безопасности на изменения с высоким, средним или низким уровнем риска на основе ответов на эти вопросы. Если изменение представляет собой высокий риск, вам может потребоваться более тщательная проверка безопасности. Если изменение представляет меньший риск, вы можете реализовать более упрощенный процесс проверки безопасности, который поможет сократить требуемые ресурсы и ускорить процесс, улучшая возможности бизнеса. Рассмотрите возможность организации ротации внутри вашей команды, чтобы отвечать за управление очередью проверок безопасности, следить за тем, чтобы члены вашей команды получали новые проверки безопасности, и следить за ходом существующих проверок безопасности. Фактический процесс проверки безопасности будет варьироваться в зависимости от того, что исследуется. Например, новая функция вашего мобильного приложения может потребовать от инженера по безопасности проверки кода и поиска потенциальных уязвимостей. Возможно, потребуется проверка нового устанавливаемого программного обеспечения, чтобы убедиться, что контроль доступа настроен правильно. Работа со внешними поставщиками может представлять собой совершенно другой процесс. Для справки прочитайте Анкету Google по оценке безопасности поставщиков .
Исправление ошибок
Находить ошибки важно, но безопасность улучшается только после их исправления. Знать, какие риски существуют для вашей организации, — это хорошо, но иметь возможность эффективно устранять эти риски — еще лучше.
Управление уязвимостями
Уязвимости возникают из различных источников, включая внутренние усилия (например, сканирование уязвимостей и проверки безопасности), сторонние тесты на проникновение и аудит или даже внешние исследователи безопасности, которые уведомляют вас по каналам поддержки до официального запуска вашего VDP. Вашей организации нужен способ классифицировать новые и существующие уязвимости, чтобы гарантировать, что они будут доведены до сведения нужных заинтересованных сторон, правильно расставлены по приоритетам и своевременно устранены. Когда вы запустите VDP, у вас появится новый поток уязвимостей, входящих в ваши процессы управления уязвимостями. Наличие надежных процессов для обработки этих уязвимостей поможет вам отслеживать ход исправления и отвечать на запросы внешних исследователей безопасности об обновлениях. Возможность быстро определить приоритетность уязвимости и сообщить участникам VDP о сроках устранения уязвимости повысит взаимодействие с сообществом исследователей безопасности, а также улучшит репутацию службы безопасности вашей организации. В следующих разделах описываются различные аспекты вашей программы управления уязвимостями, которые вам следует иметь в наличии перед запуском VDP.
Установите стандарты серьезности и сроки устранения последствий.
Создание общего языка в отношении серьезности уязвимостей и идеальных сроков устранения, связанных с каждой серьезностью, упрощает установление стандартных ожиданий для вашей организации. Если к каждой уязвимости относиться как к чрезвычайной ситуации, ваша организация исчерпает свои ресурсы и начнет возмущаться командой безопасности. Если каждая уязвимость считается низкоприоритетной, уязвимости никогда не будут устранены, и риск взлома возрастает. Каждая организация имеет ограниченные ресурсы, поэтому вам необходимо установить уровень серьезности. Этот рейтинг предоставляет критерии, которые помогают вашей организации понять, к какой серьезности относится уязвимость, а также ожидаемые сроки устранения, связанные с каждой серьезностью. Составьте набор рекомендаций по серьезности и поделитесь им с ключевыми заинтересованными сторонами в вашей организации для получения обратной связи. Например, если в разработке ваших стандартов серьезности участвуют инженеры, они, скорее всего, поддержат эти стандарты и будут их соблюдать, когда придет время исправить уязвимость в течение определенного периода времени. Эти рекомендации по серьезности могут различаться в зависимости от того, какие риски характерны для вашего бизнеса. Возможно, вы захотите рассмотреть возможность моделирования угроз, чтобы подумать о том, какие угрозы наиболее вероятны и опасны для вашей организации, и включить примеры проблем, которые попадают в каждую категорию серьезности. Ниже приведен пример стандартов серьезности и сроков устранения нарушений для финансовой организации.
| Строгость | Описание | График исправления | Примеры) |
|---|---|---|---|
| Критический | Проблемы, которые представляют непосредственную угрозу для наших пользователей или нашего бизнеса. | Владелец: основной владелец, обеспечивающий устранение уязвимости, должен быть определен в течение 8 часов. Звоните и пейджингуйте ресурсы по мере необходимости, даже в нерабочее время. Исправление: саму проблему следует устранить или, по крайней мере, снизить риск как можно скорее или максимум в течение трех рабочих дней. | Взлом производственной базы данных, включая финансовые записи всех пользователей. Злоумышленник получает доступ к коммерческой тайне, например к нашим собственным инвестиционным алгоритмам. Активный инцидент, включающий получение злоумышленником доступа к нашей внутренней сети или конфиденциальным производственным системам. |
| Высокий | Проблемы, использование которых может привести к значительному ущербу. | Владелец: Основной владелец должен быть идентифицирован в течение одного рабочего дня. Исправление: в течение 10 рабочих дней (~ 2 недель). | Уязвимости, которые могут привести к доступу к конфиденциальным пользовательским данным или функциям (например, возможность любого пользователя украсть средства у другого пользователя). |
| Середина | Проблемы, которые сложнее использовать или которые не приводят к прямому ущербу. | Владелец: Основной владелец должен быть идентифицирован в течение пяти рабочих дней. Исправление: в течение 20–40 рабочих дней (~ 1–2 месяца). | Подтвержденные проблемы, выявленные автоматическими сканерами, например исправления для обновлений безопасности без известных эксплойтов. Проблемы раскрытия информации, которые, вероятно, помогут в дальнейших атаках. Проблемы ограничения скорости, которые потенциально могут быть использованы (например, возможность постоянно подбирать пароли пользователя). |
| Низкий | Проблемы с минимальным воздействием; в основном используется для регистрации известных проблем. | Никаких требований по поиску владельца или ремонту в оговоренные сроки. | Раскрытие информации, не представляющее вероятного риска, но при этом информация не должна быть доступна извне. |
Уход за ошибками
Мы не говорим здесь о стрижках, мы говорим о том, чтобы ошибки были отформатированы правильно, чтобы их можно было легко исправить. Используя предыдущую таблицу в качестве руководства, установите свои собственные определения серьезности. Эти определения используются для классификации ошибок по степени серьезности и сообщения о них владельцам.
Помимо присвоения каждой уязвимости серьезности, вам необходимо убедиться, что ваши ошибки представлены в стандартном формате, который облегчит обработку принимающим группам. Уязвимости будут входить в ваши процессы управления уязвимостями в различных форматах (например, в результатах автоматического сканирования или в ручных отчетах по результатам проверок безопасности). Потратив время на преобразование каждой уязвимости в стандартный формат, вы увеличите шансы принимающей команды быстро понять и решить проблему.
Этот формат или шаблон могут различаться в зависимости от вашей организации и от того, какая информация наиболее полезна для владельцев, чтобы исправить назначенные им ошибки, но вот пример шаблона, который вы можете использовать. Вы сможете повторно использовать этот шаблон позже, когда создадите форму подачи заявки на участие в программе раскрытия уязвимостей для исследователей.
Заголовок: <описание проблемы в одну строку, обычно тип уязвимости и какой актив/услуга/и т. д. подвергается воздействию; при необходимости укажите серьезность или сопоставьте серьезность с полем в вашем трекере> Краткое описание: <краткое описание уязвимости и почему это важно> Шаги воспроизведения: <пошаговые инструкции о том, как показать существование уязвимости> Влияние / Сценарий атаки: <как эта уязвимость может быть использована и каковы будут последствия для вашей организации?> Шаги по устранению: <как можно напрямую устранить эту уязвимость, или любой другой совет, который поможет хотя бы снизить риск, связанный с этой проблемой>Вот пример потенциальной уязвимости высокой степени серьезности:
Заголовок: [ВЫСОКИЙ] Небезопасная прямая ссылка на объект (IDOR) на страницах профиля . Краткое описание: в функциях страниц профиля нашего приложения был обнаружен IDOR, который позволял любому пользователю получить несанкционированный доступ для просмотра и редактирования профиля другого пользователя, включая полное имя другого пользователя. , домашний адрес, номер телефона и дату рождения. Мы просмотрели журналы и обнаружили, что эта проблема еще не была использована. Эта проблема была обнаружена внутри компании. Этапы воспроизведения:
- Настройте прокси (например, Burp Suite) для перехвата трафика на мобильном устройстве с установленным приложением.
- Посетите страницу своего профиля и перехватите соответствующий HTTP-запрос.
- Измените ProfileID=###### на ProfileID=000000 (это тестовый пользователь) и отправьте HTTP-запрос.
- Приложение отобразит профиль пользователя 000000, и вы сможете просматривать и редактировать его информацию.
Сценарий атаки/воздействие: любой пользователь может использовать эту уязвимость для просмотра и редактирования профиля другого пользователя. В худшем случае злоумышленник может автоматизировать процесс получения информации о профиле каждого пользователя во всей нашей системе. Хотя мы не считаем, что эта проблема еще была использована, важно относиться к ней как к стандартной проблеме ВЫСОКОЙ серьезности. Если мы обнаружим доказательства эксплуатации, степень серьезности может возрасти до КРИТИЧЕСКОЙ. Действия по исправлению: реализуйте проверки на стороне сервера, чтобы гарантировать, что пользователь, делающий запрос, имеет доступ для просмотра/редактирования профиля, запрошенного через значение ProfileID. Например, если Алиса вошла в систему и имеет идентификатор профиля 123456, но замечено, что Алиса запросила идентификатор профиля 333444, пользователь должен увидеть ошибку, и эта попытка доступа к профилю другого пользователя должна быть зарегистрирована. Дополнительную информацию об IDOR и способах его исправления можно найти в материалах OWASP по этой ошибке .
Вы можете сэкономить время и ручные усилия, найдя способы автоматизировать преобразование уязвимостей из различных источников в ваш стандартный формат. По мере того, как вы создаете больше уязвимостей, вы можете обнаружить общие темы на этапах исправления. Помимо общего шаблона формата ошибок, вы можете захотеть создать дополнительные шаблоны для распространенных типов уязвимостей.
Поиск владельцев
Возможно, одним из самых сложных аспектов управления уязвимостями является выявление владельцев, которые могут помочь в исправлении ошибок, а также получение их согласия на выделение ресурсов для фактического исправления ошибок в установленные сроки. Если вы настроили процессы управления активами , это будет немного проще. Если нет, то это может послужить мотивацией для этого. В зависимости от размера вашей организации поиск владельца может быть довольно простым или невероятно сложным. По мере роста вашей организации также возрастают усилия по определению ответственных за устранение вновь обнаруженных проблем безопасности. Рассмотреть возможность проведения оперативной ротации дежурств. Дежурный ответственен за проверку неназначенных уязвимостей, отслеживание владельцев и определение приоритетов в зависимости от серьезности. Даже если вы сможете определить, кто несет ответственность за исправление уязвимости, и поручить им эту ошибку, вам также придется убедить их потратить время на ее фактическое исправление. Этот подход может варьироваться в зависимости от команды или отдельного человека, а также от того, над какими другими задачами они работают. Если вы добились поддержки со стороны организации в отношении ваших стандартов серьезности и сроков исправления , вы можете обратиться к ним, но иногда может потребоваться дополнительное убеждение, чтобы заставить кого-то исправить ошибку. Вот несколько общих советов по устранению уязвимостей:
- Объяснить, почему : Когда кому-то поручают исправить уязвимость, обычно это неожиданная работа. Объясните, почему важно своевременно устранить эту проблему (например, сценарий воздействия/атаки) и убедитесь, что владелец понимает это.
- Сбор контекста . В некоторых случаях только один человек обладает знаниями, необходимыми для исправления ошибки, и у него могут быть другие задачи, над которыми он работает. Потратьте время, чтобы выяснить, что это такое — возможно, что другие задачи могут быть более важными, чем устранение этой уязвимости в ближайшем будущем. Демонстрация сочувствия и гибкости в отношении сроков исправления поможет завоевать расположение и укрепить ваши отношения с теми, кто вам нужен для устранения уязвимостей. Только будьте осторожны и не давайте слишком большой свободы действий, иначе ваша организация не будет серьезно относиться к срокам исправления.
- Объясните, как: даже если вы включите в ошибку рекомендации по ее устранению, владелец, исправляющий проблему, может быть сбит с толку или ему понадобится помощь в изучении того, как исправить ошибку. Если им нужна помощь, чтобы понять, как это исправить, помогите научить их. Если просто выбрасывать ошибки владельцам, не помогая им, это повредит отношениям организации с командой безопасности. Если вы будете максимально помогать другим, это даст им возможность исправлять нынешние и будущие уязвимости, а также помогать обучать других.
- Адаптируйте ваш запрос : Различные команды и отдельные лица могут иметь существующие процессы приема и определения приоритетности входящих рабочих запросов. Некоторые команды могут захотеть, чтобы все входящие запросы проходили через их менеджеров. Другие захотят, чтобы запросы о помощи были поданы в стандартном формате. Некоторые будут работать только с тем, что было заранее определено в спринте. В любом случае, если вы потратите немного дополнительного времени на то, чтобы адаптировать свой запрос к формату, который команда или отдельный человек обычно использует для приема запросов о помощи, это увеличит вероятность того, что ваш запрос будет расставлен по приоритету и будет принят к исполнению.
- Эскалация в крайнем случае . Если вы испробовали все вышеперечисленное, а человек или команда, ответственные за устранение уязвимости, просто не тратят время на устранение серьезной проблемы безопасности, рассмотрите возможность эскалации до руководства при необходимости. Это всегда должно быть крайней мерой, поскольку это может испортить ваши отношения с конкретным человеком или командой.
Анализ причин
Помимо поиска и устранения отдельных уязвимостей, анализ первопричин (RCA) может помочь вам выявить и устранить системные проблемы безопасности. Ресурсы у каждого ограничены, поэтому возникает соблазн пропустить этот шаг. Однако, потратив время на анализ тенденций в данных об уязвимостях, а также на дальнейшее изучение критических и серьезных ошибок, можно сэкономить время и снизить риск в долгосрочной перспективе. В качестве примера предположим, что вы заметили, что один и тот же тип уязвимости (например, перенаправление намерений ) появляется снова и снова во всем вашем приложении. Вы решаете поговорить с командами, которые внедряют эту уязвимость в ваше приложение, и понимаете, что подавляющее большинство из них не понимают, что такое перенаправление намерений, почему оно важно и как его предотвратить. Вы составляете доклад и руководство, которые помогут рассказать разработчикам в вашей организации об этой уязвимости. Эта уязвимость, вероятно, не исчезнет полностью, но скорость ее появления, скорее всего, снизится. Когда вы запускаете свой VDP, каждая уязвимость, о которой вам сообщает третья сторона, является чем-то, что ускользнуло от ваших существующих внутренних процессов безопасности. Выполнение RCA при обнаружении ошибок в вашем VDP даст еще больше информации о том, как систематически улучшать вашу программу безопасности.
Обнаружение и реагирование
Обнаружение и реагирование относятся к любым инструментам и процессам, которые у вас есть для обнаружения и реагирования на потенциальные атаки на вашу организацию. Это может быть как приобретенное, так и самостоятельно разработанное решение, которое анализирует данные для выявления подозрительного поведения. Например, в разделе «Устранение ошибок» мы говорили о регистрации каждый раз, когда пользователь пытается получить несанкционированный доступ к профилю другого пользователя. У вас может быть сигнал или предупреждение, которое генерируется, если вы заметили, что пользователь совершает большое количество неудачных попыток доступа к профилям других пользователей за короткий период времени. Вы можете даже автоматизировать процесс блокировки доступа этого пользователя к любой из ваших служб на определенный период или на неопределенный срок, пока ситуация не будет рассмотрена и восстановлен доступ вручную. Если у вас еще нет механизмов обнаружения и реагирования, рассмотрите возможность сотрудничества с экспертом-консультантом, который поможет вам создать программу цифровой криминалистики и реагирования на инциденты (DFIR) для вашей организации. Если у вас уже есть механизмы обнаружения и реагирования, вам следует подумать о последствиях проведения тестирования пятью, десятью или даже сотней исследователей безопасности на ваших поверхностях атак, обращенных к Интернету. Это может оказать большое влияние на любую установленную у вас IDS/IPS (систему обнаружения и предотвращения вторжений).
Потенциальные риски включают в себя:
- Перегрузка оповещениями: поток оповещений или сигналов, которые выглядят как вредоносные атаки, но на самом деле являются нормальными, одобренными исследователями безопасности, участвующими в вашем VDP. Может быть создано так много шума, что становится трудно отличить настоящие атаки от законного тестирования безопасности.
- Ложные тревоги при реагировании на инциденты. Если у вас есть процессы, которые оповещают людей в 2:00 ночи в субботу, они не будут рады просыпаться и расследовать потенциальное нарушение, которое на самом деле было просто исследователем безопасности, выполняющим законное тестирование.
- Блокировка исследователей безопасности. Если у вас установлена агрессивная IPS (система предотвращения вторжений), вы можете в конечном итоге заблокировать IP-адрес исследователя безопасности, который пытается запустить сканирование, ручное тестирование и т. д., чтобы выявить уязвимости и сообщить о них вам. Если исследователя безопасности заблокируют после пяти минут тестирования, особенно в случае с VDP, он может потерять интерес и вместо этого сосредоточиться на программе другой организации. Это может привести к полному отсутствию участия в вашей программе исследователей безопасности, что увеличивает риск того, что уязвимости останутся необнаруженными (и, следовательно, неизвестными вашей организации). Хотя вы, возможно, и не захотите снижать уровень своей IPS, есть и другие меры, которые вы можете предпринять, чтобы снизить риск отстранения исследователей.
Способ устранения этих рисков во многом зависит от того, какой подход вы хотите использовать в работе с внешними исследователями безопасности. Если вам нужен стиль тестирования в стиле «черного ящика» , имитирующий реальные атаки, то вы можете ничего не делать. В этом случае трафик исследователя будет генерировать оповещения, и ваша команда может предпринять действия для расследования и отреагировать соответствующим образом. Это поможет вашей команде попрактиковаться в реагировании на то, что выглядит как настоящие атаки, но может снизить взаимодействие с исследователями безопасности, особенно если им запрещено тестирование. Это также может привести к тому, что вы пропустите реальную атаку, потратив время на расследование законного тестирования. Если вам нужен подход «серого ящика» , вы можете рассмотреть возможность сотрудничества с исследователями безопасности, чтобы каким-либо образом самостоятельно идентифицировать их тестовый трафик. Это позволит вам внести в белый список или иным образом отфильтровать трафик при их тестировании и полученных оповещениях. Ваша команда сможет лучше отличать реальные атаки от одобренного тестирования, а исследователи получат возможность находить уязвимости и сообщать вам об уязвимостях, не испытывая препятствий со стороны ваших систем предотвращения вторжений. Некоторые организации просят исследователей безопасности отправить форму для подачи заявки на получение уникального идентификатора, который можно прикрепить к заголовкам в запросах, созданных исследователем. Это позволяет организации внести трафик исследователя в белый список, а также определить, начинает ли исследователь выходить за рамки согласованного объема тестирования. Если это произойдет, вы можете обратиться к исследователю и попросить его подождать, пока вы вместе не разработаете план тестирования.